Update sbt-scalajs-crossproject to 0.6.1

Updates org.portable-scala:sbt-scalajs-crossproject from 0.6.0 to 0.6.1.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention @scala-steward in the comments below.
Have a fantastic day writing Scala!

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

labels: semver-patch

Codecov Report

Merging #1185 into master will decrease coverage by 0.1%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1185      +/-   ##
==========================================
- Coverage   85.82%   85.71%   -0.11%
==========================================
  Files          89       89
  Lines        2885     2885
  Branches      119      115       -4
==========================================
- Hits         2476     2473       -3
- Misses        409      412       +3

Impacted Files
Coverage Δ

...rc/main/scala/io/circe/shapes/SizedInstances.scala
78.57% <0%> (-14.29%)
:arrow_down:

.../core/shared/src/main/scala/io/circe/Decoder.scala
85.96% <0%> (-0.51%)
:arrow_down:

...re/shared/src/main/scala/io/circe/JsonNumber.scala
91.86% <0%> (ø)
:arrow_up:

...d/src/main/scala/io/circe/NonEmptySeqDecoder.scala
100% <0%> (+8.33%)
:arrow_up:

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 17735b7...d79baa7. Read the comment docs.


The "Verification: never" option is unintuitively named

We've discussed "manual" as a possible alternative.

Note that the option is currently named "automated verification". Given that name, "never" seems more correct than "manual". We could also change the option name to "when to run verification", with options "manually", "on change" and "on save", but what's incorrect about that is that when you use "on save", you can still run verification manually before saving.


Pivot table not responding to added filters.

Hello,
I have installed the pivot table on kibana version 6.2.4.
I found that upon applying filters the pivot table, that is applying a restriction over the data, the pivot does not respond at all and it continues to show me all data.
Is there a solution for that?
One more point, is there any method to add the option to click on the pivot table itself, and the pivot respond to that action?
Thanks in advance.
Ganessen.

Same problem for us


Needs more information

The documentation does not describe how the options affect team collaboration. What’s the real difference between creating a private channel or open channel? If you create a private channel, even though you’re the owner of the channel and team you won’t be able to view uploaded files in dynamics under files or documents on the record. And also, if you delete a channel it still remains in dynamics but as a broken link. So in the collaboration wizard you can see the channel but it’s not in teams anymore. Please provide a lot more information

@cxr-dev looks like you removed the metadata information from the issue so we don't know what article you refer to. Please create a new issue from the article in question and help us with some context about the documentation in question. We need that to find the right person to address the feedback.
Thanks,
Michael


Separate subtitle edit "save" and "trigger workflow" buttons -> prevent editing freeze for 60+ minutes

Saving edits to subtitles automatically triggers a new workflow, freezing the editing mode for e.g. 60+ minutes for a typical 1-hour video.
This can be inconvenient because:

Editors often notice final fixes just after saving.
Editors want to save their changes frequently in order to prevent any loss of their progress

It would be helpful to separate the "save" button, for saving the edits, from the "trigger workflow" button.

What also might be useful a "workflow running" indicator, so that you can at least know when you cannot make edits

Thank you for filing this enhancement request. We have added this to our backlog to review.

@bquast Thanks for submitting the feedback. We've carefully considered your feedback and have decided not to include this  feature in a future release of this solution.


statistics function

The data structure behind the expenses-management-tool is a huge DataFrame. It contains the following columns:

expense
amount
importance
category
date
label for good day or bad day

for the statistics function:
A large menu of analyses should appear when opening the statistics function. A subdivision into graphical plots and the key facts could be a good subdivision.
previous analyses:

please always add new analyses to the list

Donut chart could be interesting if we would like to compare percentage of our monthly expenses by categories or importance.
Example of donut chart:

At the centre of the donut, we could write total monthly expenses.

I really like donuts and donuts charts. 😂
great idea Adham


server needs SDL2 to build

The server currently needs SDL2 to build ..
This should be fixed by -DSTANDALONE but somehow got lost with the introduction of cmake..

Moved here: https://github.com/inexor-game/code/issues/196
(this is not a bug)

@Fohlen You tried -DBUILD_CLIENT=false but it sill failed

the bug appears bc module_RPC would need to be built 2 times: one time for the server and one time for the client. (one with standalone and one without)


Client should store image-resources

The client loads some image-resources (stream icons, conference logo, sometimes even speaker data) via rest/image-resources.json. The data should be stored into the indexdb and it should be checked every now and then if they have changed as we do with the talk data).

Made a first attempt to fix the HTML so it doesn't load the resource multiple times

Works good enough in old client, works better in new pwa client.


Replace Bio::DB::Fasta with faidx_xs

Benefits:

can index bgzipped FASTA files (though note Ensembl distributes gzipped, must be converted to bgzipped before use). Human toplevel file is ~1.1g bgzipped, 40g uncompressed.
indexes much more robust, won't tolerate corrupted/partial index like Bio::DB::Fasta
around 10x faster retrieving sequence

Requires:

htslib (https://github.com/samtools/htslib)
faidx_xs (https://github.com/Ensembl/faidx_xs)
bgzipped FASTA file

The .travis.yml install of htslib and faidx_xs is non-ideal as it avoids using "make install" by compiling the module into the home directory. Much better if you have sudo access to do "make install" properly for each.

Looks sensible.

Same for me, OK!


Update installation command

So it will install as a development dependency as default.

Great suggestion, thank you!

Great suggestion, thank you!


Add OculusBrowser to "niche browser" ignore list

Fixes #479 - an issue where the Oculus Browser (VR browser) is picked up as an outdated browser.  Currently its a relatively niche browser.

Thanks!


[pytorch] Upgrade PyTorch to 2.0.0

Description
Brief description of what this PR is about

If this change is a backward incompatible change, why must this change be made?
Interesting edge cases to note here

Codecov Report
Patch coverage: 72.64% and project coverage change: +1.59 :tada:

Comparison is base (bb5073f) 72.08% compared to head (6f994cf) 73.68%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@             Coverage Diff              @@
##             master    #2525      +/-   ##
============================================
+ Coverage     72.08%   73.68%   +1.59%
- Complexity     5126     6934    +1808
============================================
  Files           473      684     +211
  Lines         21970    30277    +8307
  Branches       2351     3140     +789
============================================
+ Hits          15838    22310    +6472
- Misses         4925     6439    +1514
- Partials       1207     1528     +321

Impacted Files
Coverage Δ

api/src/main/java/ai/djl/modality/cv/Image.java
69.23% <ø> (-4.11%)
:arrow_down:

...rc/main/java/ai/djl/modality/cv/MultiBoxPrior.java
76.00% <ø> (ø)

.../main/java/ai/djl/modality/cv/output/Landmark.java
100.00% <ø> (ø)

...i/djl/modality/cv/translator/BigGANTranslator.java
21.42% <0.00%> (-5.24%)
:arrow_down:

.../modality/cv/translator/ImageFeatureExtractor.java
0.00% <0.00%> (ø)

.../ai/djl/modality/cv/translator/YoloTranslator.java
27.77% <0.00%> (+18.95%)
:arrow_up:

...ain/java/ai/djl/modality/cv/util/NDImageUtils.java
67.10% <0.00%> (+7.89%)
:arrow_up:

api/src/main/java/ai/djl/modality/nlp/Decoder.java
63.63% <ø> (ø)

api/src/main/java/ai/djl/modality/nlp/Encoder.java
66.66% <ø> (ø)

.../main/java/ai/djl/modality/nlp/EncoderDecoder.java
64.00% <ø> (ø)

... and 228 more

... and 352 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


On click listener on the text lable

Hi. How can i add onClickListner to text label in action menu item?
i can setOnClickListener to ActionMenu value, but in this case it can only responds when i  pressing on icon.
Thank you.

Just set yout OnClickListener on FAB inside the menu and label will also become clickable.

Can u explain more detailed ?
Look, this is how i create listner:
FloatingActionButton actionMenu = new FloatingActionButton(getApplicationContext());
actionMenu.setOnClickListener(new View.OnClickListener(){...}
Where i need to set listner to do label clicable ?

Labels are enabled only if the FAB is placed inside the FAM.

I've already added the OnClickListener inside the menu and the label keeps unresponsive to click.

Me too, my FAB placed iside te FAM

Please paste your code here so I could look at it.

This happens to me only if the FAB is added programmaticlly. When added in XML it works.

There's an example of how to add FAB programmatically. Please look at the sample's module code.

i'm doing like this:
or (final Sport sport : Sport.values()) {
FloatingActionButton fab = new FloatingActionButton(getActivity());
fab.setImageResource(sport.getResource());
fab.setLabelText(getString(sport.getName()));
fab.setColorNormal(ContextCompat.getColor(getActivity(), R.color.accent));
fab.setColorRipple(ContextCompat.getColor(getActivity(), R.color.primary_dark));
fab.setColorPressed(ContextCompat.getColor(getActivity(), R.color.primary_dark));
fab.setButtonSize(FloatingActionButton.SIZE_MINI);
fab.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
createNewChallenge(sport);
}
});
mFabMenu.addMenuButton(fab);
}

Thanks! Will fix this in the next build. For now set your OnClickListener after you have added the FAB into the FAM.

Thanks! Will fix this in the next build. For now set your OnClickListener after you have added the FAB into the FAM.

This is not fixed.
While the label is now clickable, it triggers the event with the label's view as an argument, and not the fab's view and you can't use it since its not possible to relate it to its fab.
If you use the code from @jzeferino's comment the bug is there.
A workaround using version 1.6.4 is to:

create the button instance
add the button to the menu and
then add the listener (should be last)

This bug is result of the workflow of it. The logic should be to create, configure and then attach it. Not create, attach and then configure. One good and permanent solution could be to use the builder pattern for adding menu items.


How to reference the work item on creation

The documentation doesn't reference how you specify which work item the attachment should be related to. Please provide details. Thx

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

ID: 90676f49-e50a-9dfa-c047-f2b7d39ca795
Version Independent ID: 2078122b-0830-464b-a958-a49e3eac1e67
Content: Attachments (Azure DevOps Work Item Tracking)
Content Source: docs-ref-autogen/5.1/wit/Attachments.yml
Product: devops
Technology: devops-ref
GitHub Login: @wnjenkin
Microsoft Alias: whjenkin

I have the same problem - it does not say how to link the attachment to a work item.
Please advise


Using domain doesn't work

should it work with docs.github.com domain rule , then it's working as intended. atleast for now.
Honestly I was confused about handling the case of sub-domains. Maybe In future, I can have extra option for also including sub-domains as a checkbox.

I assumed that the subdomain would be included.


LLVM Version required?

I've met many compilation error while compile the main program.... My LLVM version is 9.0.0
Should I try to compile it with a higher or lower version of LLVM?
Thanks.

Could you try a lower version (probably  6)?

2 weeks, no more comments. Must have worked with v6 :)


GPRC DNS name resolution fails

Happens during server setup (i.e. on the surefire client side) with camel-2.23.1 on eap-7.2 and prevents the GRPCIntegrationTest to run.
09:59:28,394 INFO  [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0010: Deployed "camel-grpc-tests.jar" (runtime-name : "camel-grpc-tests.jar")
09:59:28,760 INFO  [org.jboss.arquillian.testenricher.cdi.container.BeanManagerProducer] (pool-8-thread-2) BeanManager not found.
09:59:28,908 INFO  [org.apache.camel.impl.DefaultCamelContext] (pool-8-thread-2) Apache Camel 2.23.1 (CamelContext: camel-1) is starting
09:59:28,910 INFO  [org.apache.camel.management.ManagedManagementStrategy] (pool-8-thread-2) JMX is enabled
09:59:28,977 INFO  [org.wildfly.extension.camel] (pool-8-thread-2) Camel context starting: camel-1
09:59:28,977 INFO  [org.wildfly.extension.camel] (MSC service thread 1-1) Bound camel naming object: java:jboss/camel/context/camel-1
09:59:29,915 INFO  [org.apache.camel.impl.converter.DefaultTypeConverter] (pool-8-thread-2) Type converters loaded (core: 195, classpath: 2786)
09:59:30,014 INFO  [org.apache.camel.impl.DefaultCamelContext] (pool-8-thread-2) StreamCaching is not in use. If using streams then its recommended to enable stream caching. See more details at http://camel.apache.org/stream-caching.html
09:59:30,016 INFO  [org.apache.camel.impl.HeadersMapFactoryResolver] (pool-8-thread-2) Detected and using custom HeadersMapFactory: org.apache.camel.component.headersmap.FastHeadersMapFactory@28a3631b
09:59:30,041 INFO  [org.apache.camel.component.grpc.GrpcProducer] (pool-8-thread-2) Creating channel to the remote gRPC server localhost:1100
09:59:30,173 INFO  [org.apache.camel.impl.DefaultCamelContext] (pool-8-thread-2) Route: route1 started and consuming from: direct://start
09:59:30,174 INFO  [org.apache.camel.impl.DefaultCamelContext] (pool-8-thread-2) Total 1 routes, of which 1 are started
09:59:30,175 INFO  [org.apache.camel.impl.DefaultCamelContext] (pool-8-thread-2) Apache Camel 2.23.1 (CamelContext: camel-1) started in 1.268 seconds
09:59:30,223 ERROR [stderr] (grpc-default-executor-0) Exception in thread "grpc-default-executor-0" java.lang.AssertionError
09:59:30,223 ERROR [stderr] (grpc-default-executor-0) 	at io.grpc.internal.DnsNameResolver.getResourceResolver(DnsNameResolver.java:529)
09:59:30,223 ERROR [stderr] (grpc-default-executor-0) 	at io.grpc.internal.DnsNameResolver.access$500(DnsNameResolver.java:59)
09:59:30,223 ERROR [stderr] (grpc-default-executor-0) 	at io.grpc.internal.DnsNameResolver$1.run(DnsNameResolver.java:206)
09:59:30,224 ERROR [stderr] (grpc-default-executor-0) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
09:59:30,224 ERROR [stderr] (grpc-default-executor-0) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
09:59:30,224 ERROR [stderr] (grpc-default-executor-0) 	at java.lang.Thread.run(Thread.java:748)
09:59:35,187 INFO  [org.apache.camel.impl.DefaultCamelContext] (pool-8-thread-2) Apache Camel 2.23.1 (CamelContext: camel-1) is shutting down
09:59:35,210 INFO  [org.apache.camel.impl.DefaultShutdownStrategy] (pool-8-thread-2) Starting to graceful shutdown 1 routes (timeout 300 seconds)
09:59:35,213 INFO  [org.apache.camel.impl.DefaultShutdownStrategy] (Camel (camel-1) thread #2 - ShutdownTask) Waiting as there are still 1 inflight and pending exchanges to complete, timeout in 300 seconds. Inflights per route: [route1 = 1]
09:59:35,216 INFO  [org.apache.camel.impl.DefaultShutdownStrategy] (Camel (camel-1) thread #2 - ShutdownTask) There are 1 inflight exchanges:
	InflightExchange: [exchangeId=ID-MacBook-1549011568814-0-1, fromRouteId=route1, routeId=route1, nodeId=to1, elapsed=0, duration=5024]
09:59:36,218 INFO  [org.apache.camel.impl.DefaultShutdownStrategy] (Camel (camel-1) thread #2 - ShutdownTask) Waiting as there are still 1 inflight and pending exchanges to complete, timeout in 299 seconds. Inflights per route: [route1 = 1]

You can debug the setup like this
mvn clean install -Dtest=GRPCIntegrationTest -DargLine=-agentlib:jdwp=transport=dt_socket,address=5001,server=y,suspend=y

Fixed by
<module xmlns="urn:jboss:module:1.3" name="sun.jdk.ext">
    <dependencies>
        <system export="true">
            <paths>
                <!-- default DOM impl lookup -->
                <path name="com/sun/org/apache/xerces/internal/dom" />
                <!-- needed by castor -->
                <path name="com/sun/org/apache/xml/internal/serialize" />
                <!-- needed by grpc-->
                <path name="com/sun/jndi/dns" />
                <!-- needed by hadoop -->
                <path name="com/sun/security/auth/module" />
            </paths>
        </system>
    </dependencies>
</module>


Unable to drop a pin or enter an address on assert page

A few users have reported that they were unable to enter an address in the address field or drop a pin by panning around on the map. This is during the add hotspot flow.
This is happening on iOS and android, wallet address and physical address used in the discord message: https://discord.com/channels/404106811252408320/733699201887764511/814547381373894707

This issue may be only for specific Hotspots. I found I'm not able to assert the Hotspot in any location because the wheel doesn't stop spinning to load. The Hotspot ID is 4C:E2.

@timtamothee which wheel is this? would you be able to dm me a video showing this behavior?

Update: Hotspots not on the onboarding server will encounter this issue.
We'll update the error message to be more meaningful and communicate next steps.
"Unable to find Hotspot in the Onboarding Server. Please contact the Hotspot manufacturer for next steps."


Add AND filtering to teams page

Currently the filtering is OR based. I think it would also be helpful to be able to narrow teams down by members.
EG: toggle between showing all teams with Xiangling AND Bennett / all teams with Xiangling OR Bennett

Resolved in https://github.com/frzyc/genshin-optimizer/pull/1740


Account label is displayed twice

Context information
application version: dev
device:
browser:
operating system:
Steps to reproduce

Open ak_QcxSaniCR8VZrQpDqYcNuKvZDMfUzG6QTwEZhzRGiQm8Bsjwi

What is expected?

Account label is displayed once

What is actually happening?

Account label is displayed two times

Closing as it's been already fixed


Mythril reports different outputs for the same input

Describe the bug
Mythril produces two different outputs on the same input. It seems to be some caching-effect coming into play. On running it several times over, the "correct" output gets printed.
To Reproduce
I run the following command:
myth -xo json file_path.sol
I'm running the following source code -
https://etherscan.io/address/0x00000b233566fcc3825f94d68d4fc410f8cb2300#code
I've copied the code from there and placed it in a file on my local machine where I'm running Mythril.
Expected behavior
Mythril is supposed to detect possible integer overflows.
However, on most runs, it outputs the following -
{"error": null, "issues": [], "success": true}
And in a one-off run, it dumps the seemingly correct output -
{
   "error":null,
   "issues":[
      {
         "address":1595,
         "code":"     emit Transfer(owner, to[i], values[i]);\n        }\n        return(i);\n    }\n}",
         "debug":"calldata_ApproveAndCallFallBack_4: 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffc\ncalldata_ApproveAndCallFallBack_0: 0xaad41a4100000000000000000000000000000000000000000000000000000000\ncalldatasize_ApproveAndCallFallBack: 0x4\ncallvalue: 0x0\n",
         "description":"A possible integer overflow exists in the function `multisend(address[],uint256[])`.\nThe addition or multiplication may result in a value higher than the maximum representable integer.",
         "filename":"sol_0x00000b233566fcc3825f94d68d4fc410f8cb2300.sol",
         "function":"multisend(address[],uint256[])",
         "lineno":274,
         "title":"Integer Overflow ",
         "type":"Warning"
      },
      {
         "address":1826,
         "code":"k(spender).receiveApproval(msg.sender, tokens, this, data);\n        return true;\n    }\n\n\n    // ------------------------------------------------------------------------\n    // Owner can transfer out any accidentally sent ERC20 tokens\n    // ------------------------------------------------------------------------\n    function t",
         "debug":"calldata_ApproveAndCallFallBack_32 + 36: 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffc\ncalldata_ApproveAndCallFallBack_0: 0xcae9ca5100000000000000000000000000000000000000000000000000000000\ncalldatasize_ApproveAndCallFallBack: 0x4\ncallvalue: 0x0\n",
         "description":"A possible integer overflow exists in the function `approveAndCall(address,uint256,bytes)`.\nThe addition or multiplication may result in a value higher than the maximum representable integer.",
         "filename":"sol_0x00000b233566fcc3825f94d68d4fc410f8cb2300.sol",
         "function":"approveAndCall(address,uint256,bytes)",
         "lineno":241,
         "title":"Integer Overflow ",
         "type":"Warning"
      },
      {
         "address":6549,
         "debug":"The exception is triggered under the following conditions:\n\ncalldata_ApproveAndCallFallBack_4 + calldata_ApproveAndCallFallBack_4: 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\nstorage_0: 0x0\ncaller: 0x0\ncalldata_ApproveAndCallFallBack_0: 0xaad41a4100000000000000000000000000000000000000000000000000000000\ncalldatasize_ApproveAndCallFallBack: 0x4\nmem_128 +\n32 +\n32*\ncalldata_ApproveAndCallFallBack_4 + calldata_ApproveAndCallFallBack_4: 0x0\ncallvalue: 0x0\n",
         "description":"A reachable exception (opcode 0xfe) has been detected. This can be caused by type errors, division by zero, out-of-bounds array access, or assert violations. This is acceptable in most situations. Note however that `assert()` should only be used to check invariants. Use `require()` for regular input checking. ",
         "filename":"sol_0x00000b233566fcc3825f94d68d4fc410f8cb2300.sol",
         "function":"multisend(address[],uint256[])",
         "lineno":278,
         "title":"Exception state",
         "type":"Informational"
      },
      {
         "address":8556,
         "code":"quire",
         "debug":"calldata_ApproveAndCallFallBack_32 + 36: 0x800000000000000003ffd0badcb9b7000000002781000000000000000006bfff\nstorage_keccac_1461501637330902918203684832716283019655932542975_&\n1461501637330902918203684832716283019655932542975_&\n1461501637330902918203684832716283019655932542975_&\ncalldata_ApproveAndCallFallBack_32_+_4: 0x800000000000000000008eb2e34648ee0801030820000000000000000000a000\nstorage_keccac_1461501637330902918203684832716283019655932542975_&\n1461501637330902918203684832716283019655932542975_&\ncaller: 0x800000000000000003ffd0badcb9b7000000002781000000000000000006bfff\nstorage_keccac_1461501637330902918203684832716283019655932542975_&\n1461501637330902918203684832716283019655932542975_&\n1461501637330902918203684832716283019655932542975_&\ncalldata_ApproveAndCallFallBack_4: 0x800000000000000003ffd0badcb9b7000000002781000000000000000006bfff\nstorage_1: 0xff00\ncalldata_ApproveAndCallFallBack_0: 0x23b872dd00000000000000000000000000000000000000000000000000000000\ncalldatasize_ApproveAndCallFallBack: 0x4\ncallvalue: 0x0\n",
         "description":"A possible integer overflow exists in the function `transferFrom(address,address,uint256)`.\nThe addition or multiplication may result in a value higher than the maximum representable integer.",
         "filename":"sol_0x00000b233566fcc3825f94d68d4fc410f8cb2300.sol",
         "function":"transferFrom(address,address,uint256)",
         "lineno":19,
         "title":"Integer Overflow ",
         "type":"Warning"
      }
   ],
   "success":true
}

Screenshots

Desktop (please complete the following information):

OS: Ubuntu, 16.04.4 LTS
Latest codebase pulled from Mythril's github account

Was looking up other issues - seems to be related to @305
Will try tweaking Z3's timeout.
In any case, if Z3 is indeed timing out on the default time provided, the current output shown
{"error": null, "issues": [], "success": true}
is just not right! It should have an appropriate message letting the user know that Z3 has timed out.

@shashank-srikant thanks for the report.
First of all, could you try (that should fix your problem):
myth -xo json file_path.sol:NRM

I think this is actually caused by our implementation that doesn't (internally) always order contracts in the same way. If you don't specify the contract name, then it will pick the last one it can find (which is not always the same contract) so you'll get different results.
@b-mueller What was the expected behavior here? Intuitively I'd think that if you don't specify a contract, then it just analyzes all (which it doesn't :innocent:).
As to the z3 timeout, z3 is the constraint solver we use. In some cases its super hard/undecidable to say if something is satisfiable, in which case we don't want the solver to keep working forever. This isn't a super weird situation, and the timeout just tells the solver how extensively to look for a certain situation. In the end we need to make a tradeoff between how much possibilities we can explore (smt solving, and symbolic execution) vs resource costs. We are planning on providing customization options through the cli, to allow the user to choose these parameters (fitting them to their resources and requirements).  I'll add a logging rule (that logs timeouts) which will make it easier to find what values work best

Thanks.
What then is the current way to analyze all the contracts in a script? Without knowing the contract names a priori? Is there anything convenient? Or should i get the names off of the script's AST and then supply those one by one to myth?
Regarding Z3 timeouts -- yup. i'm perfectly fine with timing out Z3. There's no other way around it. I was under the assumption that this output {"error": null, "issues": [], "success": true} was reported in cases when Z3 would time out.

@shashank-srikant Like I said, I think the expected behavior should be to analyze all contracts (or at least give a message to the user with the options).
Because I fully understand how this might be confusing, and it might give people the assumption that everything is fine while its not. I'm keeping the issue open until we have decided what good behaviour would be in this case (which is also why I wanted @b-mueller s input)

I agree, analyzing all contracts by default makes more sense.

yup; sure. thank you.
but while we wait for others' inputs, i wanted to make progress with my analysis -- and hence wanted to know what i could do in the existing framework to push in names of all the contracts. any pointers? thanks again.

should i get the names off of the script's AST and then supply those one by one to myth?

Currently I'm afraid that's the best option.

For the contract you had its:
NRM
Owned
SafeMath

I think I can get it fixed rather quickly

also, would be great if the output had a field which reflected the name of the contract which was analyzed. that'll be super useful as well, i'm guessing.
in case someone encounters a stray output blurb, they'll be able to discern which contract it corresponds to.
something like this -
{"error": null, "issues": [], "success": true, "contract_name":file_path.sol:NRM}
currently, the file name, function name, and the line number gets added in this error key in the dict, but nowhere is the name of the contract mentioned.

@shashank-srikant That is now in master ^^


#451 java time support from 310 bp

I started from scatch for 100% legal transparrency:

comitted 100% pristine code from https://github.com/ThreeTen/threetenbp
added/comitted automated migration tool for TeaVM classlib migration (written by me)
used tool to migrate code and comitted results -  as git is a little stupid first move/rename committed and then changes, some small extra commits for improvement of tool
added/comitted automated tool to generate TZDB as hardcoded Java code (written by me)
did the hard work to resolve compile errors, migrate tests from TestNG to JUnit (puhh, endless tedious work, after I started using AssetJ in my projects this really hurts). (all done by me)

However, we now have a great intermediate result:

All T* classes present and compiling
A unit tests running 2065 tests green
format package fully functional
full chonology support (inc. Japanese, Thai, ...) - does not hurt if not used as not connected to core classes.
relatively efficient TZDB as pure Java code that can be regenerated anytime with my tool included.
Only limitations: dropped serialization support (on purpose, use JSON in the browser, Java serialization is source of evil, CVEs, simply sucks) and no custom ZoneRulesProvider is supported (could be added later if required but I have never ever seen anybody crazy enough using this at all in Java - doubt that this will ever on earth be required in Browser).

Left to do:

[ ] make it really work in the browser (not yet complete)
[x] upgrade to Java8+ with default methods for better code and compatibility with JDK (does TeaVM care about Java < 1.8 at all? IMHO all dead and out of support).
[x] final legal clarification to change license and update headers - headers from original authors still present for code copied from threetenbp. IMHO every author has to be asked if the license is changed - even in case of MIT -> ASL2.0. For My work I already fully assign to ASL2.0. You can do whatever you want with my code as long as it remains free OSS and no copyleft is applied. I hereby guarantee that I did not copy any code from JDK and only used threetenbp and combined with my personal work. For the record I want to notice that the TZDB generator is using JVM zones as input that themselves come from IANA.

final legal clarification to change license and update headers

@jodastephen would you officially confirm that we may your modified code under ASL 2.0?

For the record, TheeTen-Backport project is BSD licensed and can be used in accordance with that license.

We know. But we have to completely modify all classes and reworked it a lot (See the diffs if you want to know more) and will have to include it into TeaVM classlib so that people could compile Java code using java.time into JavaScript or potentially WebAssembly and use it in WebBrowsers or node.js. This would IMHO be very beneficial for the Java ecosystem and for java.time.
p.s.: If you have contract to your co-authors and they could also confirm this would be absolutely awesome. Thanks for taking care and considering this support.

CheckstyleExecutorException: There are 4768 errors reported by Checkstyle 6.2 with ../checkstyle.xml ruleset.

If you want to keep checkstyle with the current ruleset, you will need to assist here. I have already spent many nights and weekends and still have lots of work to do. But satisfying checkstyle is not driving my motivation to be honest.

What are the rules in TeaVM for nested types (inner classes/interfaces)?
Do they require the T* prefix to be used from TeaVM client code?
TMap.Entry vs. TAbstractList.TListIteratorImpl? To me it seems that nested types should not have to carry the T* prefix if they correspond to an official Java nested type.
@konsoletyper If that is not correct, please let me know.

I am facing a strange effect: All tests are green in Eclipse.
However in maven I reproducibly get these errors both with JDK 1.8 and JDK 11:
[ERROR] Failures:
[ERROR]   TestFractionPrinterParser.test_print_nanos:106 expected:<.0000000[02.0000000]2> but was:<.0000000[]2>
[ERROR]   TestFractionPrinterParser.test_print_nanos_noDecimalPoint:125 expected:<0000000[020000000]2> but was:<0000000[]2>
[ERROR]   TestFractionPrinterParser.test_print_seconds:153 expected:<.[05.]1> but was:<.[]1>
[ERROR]   TestFractionPrinterParser.test_print_seconds_noDecimalPoint:172 expected:<[05]1> but was:<[]1>
[ERROR]   TestFractionPrinterParser.test_reverseParse:187 expected:<-2> but was:<9>
[ERROR]   TestFractionPrinterParser.test_reverseParse_followedByNonDigit:221 expected:<-2> but was:<9>
[ERROR]   TestFractionPrinterParser.test_reverseParse_noDecimalPoint:204 expected:<-2> but was:<9>
[ERROR]   TestFractionPrinterParser.test_reverseParse_preceededByNonDigit:238 expected:<-3> but was:<10>
[ERROR]   TestFractionPrinterParser.test_reverseParse_seconds:264 expected:<-2> but was:<2>
[ERROR] Errors:
[ERROR]   TestFractionPrinterParser.test_parse_nothing:293 ClassCast java.lang.Integer c...
[ERROR]   TestZoneIdParser.test_parse_exactMatch:138 ClassCast java.lang.String cannot b...
[INFO]
[ERROR] Tests run: 2814, Failures: 9, Errors: 2, Skipped: 0

Indeed maven is correct. No clue what Eclipse was actually doing here... Will fix the broken tests.

OK. When I select the time package in Eclipse an run as JUnit tests, then only the tests in this package but not the ones from sub-packages are executed (unlike when selecting src/test/java).
Therefore I had a blind spot for all tests in the subpackages of java.time.
I could already fix all except one single test which is TestZoneIdParser.test_parse_exactMatch. In this case I can not find a problem with the TestNG conversion. Maybe something broke in org.teavm.classlib.java.time.format.TDateTimeFormatterBuilder.ZoneIdPrinterParser.

The general approach is to leave the BSD license header in the file but add the Apache one with your copyright above it. See how the java.time.* classes are in the JDK (with the GPL header at the top). Assuming this is done, you have complied with the BSD license from my perspective.

added/comitted automated migration tool for TeaVM classlib migration (written by me)

I don't think there's need in such tool, at least here (in this particular PR, and in teavm core repository at all). So please remove it from this PR.

added/comitted automated tool to generate TZDB as hardcoded Java code (written by me)

I told you that TeaVM already comes with tzdata support, so I won't accept this tool. Rationale: if someone uses both java.time and java.util.TimeZone in their codebase, they'll have two distinct instances of tzdata in the generated JS, which is unwanted overhead. Second point: I already spent some time to make tzdata as small as possible and make its compilation as fast as possible. You can compare your tzdata with mine and share results.

does TeaVM care about Java < 1.8 at all?

No, TeaVM is not supported on java < 1.8

But satisfying checkstyle is not driving my motivation to be honest.

But you have to. I believe code should be formatted in unified style, otherwise it will look strange. You can suggest your own formatting rules and try to convince me they are better than mine. And in case I agree, you'll have to create a huge PR that applies these rules to existing TeaVM code base. And then I have to spend time reviewing this PR. As a temporary solution you can exclude java.time code from checking with checkstyle and then gradually reformat code (after I approve this PR).

What are the rules in TeaVM for nested types (inner classes/interfaces)?
Do they require the T* prefix to be used from TeaVM client code?

No, they don't. Inner classes in JVM are simply top-level classes which are named as OuterClassName$InnerClassName, so you should just add T prefix to this whole name, which is done automatacally by javac.

I am facing a strange effect: All tests are green in Eclipse.

Right. That's because you should do additional configuration of corresponding launch configuration. Add these VM options:
-Dteavm.junit.target=target/js-tests -Dteavm.junit.js.runner=htmlunit -Dteavm.junit.threads=4 -Dteavm.junit.minified=true -Dteavm.junit.js.decodeStack=false

You can play with true/false settings for decodeStack option, which gives you better exception stack traces for slower compilation.

OK. When I select the time package in Eclipse an run as JUnit tests, then only the tests in this package but not the ones from sub-packages are executed (unlike when selecting src/test/java).

That's the question not to me, but to Eclipse authors. I strongly suggest to use IDEA, which I personally use to work on TeaVM. You can ask me such things regarding IDEA and I can give some advice.

Also, you should move your tests to tests module and put @RunWith(TeaVMTestRunner.class) annotation on each class. Please, look through existing tests.

I don't think there's need in such tool, at least here (in this particular PR, and in teavm core repository at all). So please remove it from this PR.

As you were concerned about legal issues, I wanted to give transparrency. It is in src/test/java where it hurts nobody. However, I will remove it as requested.

I told you that TeaVM already comes with tzdata support, so I won't accept this tool.

You should know that ZoneRules are pretty much different. But if you want to play harsh, you can also take over this PR and do the rest of the work. I do not see how the existing tzdata can easily be used for java.time as it is IMHO more accurate and complex.

But you have to.

@konsoletyper I spend lots of private spare-time and many sleepless nights into this PR.  As I already stated I am unable to spent 200 more hours just to satisfy checkstyle.

...

Thanks for the other claification and feedback. I will try to improve the tests accordinly to TeaVMTestRunner.
Did you read the comment from Steven and do you comply with the header and "dual license" approach?

I could already fix all except one single test which is TestZoneIdParser.test_parse_exactMatch.

The test fails with ZoneId GMT0 and the ZoneIdPrinterParser returns a parse length of 3 while 4 is expected ("GMT0".length()). Debugging the original code of threetenbp reveals that GMT0 is never tested by the TestNG provider:
    @DataProvider(name = "zones")
    Object[][] populateTestData() {

        Set<String> ids = ZoneRulesProvider.getAvailableZoneIds();
        Object[][] rtnval = new Object[ids.size()][];
        int i = 0;
        for (String id : ids) {
            rtnval[i++] = new Object[] { id, ZoneId.of(id) };
        }
        return rtnval;
    }

So there is some significant difference between the TZDB of threetenbp and JDK11. As I wanted to get the best support for Java users, I have build the TZDB from JDK what contains "GMT0". This way the test differs from what happened in threetenbp and therefore now it fails as the test is not designed for this purpose.

Also, you should move your tests to tests module and put @RunWith(TeaVMTestRunner.class) annotation on each class. Please, look through existing tests.

I did this for the first tests. They run both if I reference the T* classes or the official JDK classes. It seems from your tests it would be preferable to use the JDK api and the test then seems to be run via TeaVM (so is all running in an emulated JavaScript environment including JUnit itself when launched via TeaVMTestRunner? It's magic...).

You should know that ZoneRules are pretty much different. But if you want to play harsh, you can also take over this PR and do the rest of the work. I do not see how the existing tzdata can easily be used for java.time as it is IMHO more accurate and complex.

Can you please provide a couple of examples where ZoneRules is much different and what's missing in tzdata?

I spend lots of private spare-time and many sleepless nights into this PR.  As I already stated I am unable to spent 200 more hours just to satisfy checkstyle.

 However, I can't be satisfied with your "disable Checkstyle completely" approach. You should read its documentation and find how to exclude particular packages related to java.time. I can reformat java.time myself gradually and remove these exclusions.

Did you read the comment from Stephen and do you comply with the header and "dual license" approach?

Yes, I read his comment and this approach seems ok. But it's not dual license, it's Apache license, since code here is derivative work which is licensed under Apache license and it is based on code that was licensed under compatible BDS-like license. Also, I'd mentioned threetenbp in NOTICE file.

I did this for the first tests. They run both if I reference the T* classes or the official JDK classes. It seems from your tests it would be preferable to use the JDK api and the test then seems to be run via TeaVM

Yes, it's not only preferrable approach to not use T* classes from tests, but it's the only acceptable approach. If you have some problems with tests behaving differently in TeaVM and JVM, you can use @SkipJVM or @Ignore annotation for now. I encountered issues here often myself. The worst thing is when test passes on JDK8 but then starts to fail on JDK11. Yes, sometimes JDK just break things between versions.

 However, I can't be satisfied with your "disable Checkstyle completely" approach. You should read its documentation and find how to exclude particular packages related to java.time. I can reformat java.time myself gradually and remove these exclusions.

Perfect compromise. I never indendet to disable checkstyle completely. This is just a draft PR and I rather wanted to see test results than checkstyle complaining for the moment. I will later reactive checkstyle, try to fix what I can do easily and then exclude java.time for the rest. Thanks, mate :)

Yes, I read his comment and this approach seems ok. But it's not dual license, it's Apache license, since code here is derivative work which is licensed under Apache license and it is based on code that was licensed under compatible BDS-like license. Also, I'd mentioned threetenbp in NOTICE file.

Awesome. Also agreed. I will then update the headers accordingly in this PR.

Yes, it's not only preferrable approach to not use T* classes from tests, but it's the only acceptable approach. If you have some problems with tests behaving differently in TeaVM and JVM, you can use @SkipJVM or @Ignore annotation for now. I encountered issues here often myself. The worst thing is when test passes on JDK8 but then starts to fail on JDK11. Yes, sometimes JDK just break things between versions.

Thanks for clarification. I will move and update tests accordingly. I assume that surely some of them will not work (yet) in TeaVM but that is what the tests are for so we know about it. With your suggestions and hints I will be able to proceed for the tests I can not make work easily.

Can you please provide a couple of examples where ZoneRules is much different and what's missing in tzdata?

I will try to explain my problems:

First of all the ids between java.util and java.time differ.  Here is the link to America/St_Johns which is one of the most complex ones:
https://github.com/hohwille/teavm/blob/feature/451-java-time-310-bp/classlib/src/main/java/org/teavm/classlib/java/time/zone/TTzdbInternalAmerica.java#L179
If you can tell me a way how to retrieve this information from java.util.TimeZone I am happy, but I am clueless how to do it. Maybe @jodastephen could give us some hints as he surely has to most expertise in this regard. I also extracted the tzdata2019b.zip that you included in classlib. I assume you are not unzipping and parsing this clutter in the browser. Here is the corresponding data (I can correlate a few infos but not all):

# Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
Rule	StJohns	1917	only	-	Apr	 8	2:00	1:00	D
Rule	StJohns	1917	only	-	Sep	17	2:00	0	S
# Whitman gives 1919 Apr 5 and 1920 Apr 5; go with Shanks & Pottenger.
Rule	StJohns	1919	only	-	May	 5	23:00	1:00	D
Rule	StJohns	1919	only	-	Aug	12	23:00	0	S
# For 1931-1935 Whitman gives Apr same date; go with Shanks & Pottenger.
Rule	StJohns	1920	1935	-	May	Sun>=1	23:00	1:00	D
Rule	StJohns	1920	1935	-	Oct	lastSun	23:00	0	S
# For 1936-1941 Whitman gives May Sun>=8 and Oct Sun>=1; go with Shanks &
# Pottenger.
Rule	StJohns	1936	1941	-	May	Mon>=9	0:00	1:00	D
Rule	StJohns	1936	1941	-	Oct	Mon>=2	0:00	0	S
# Whitman gives the following transitions:
# 1942 03-01/12-31, 1943 05-30/09-05, 1944 07-10/09-02, 1945 01-01/10-07
# but go with Shanks & Pottenger and assume they used Canadian rules.
# For 1946-9 Whitman gives May 5,4,9,1 - Oct 1,5,3,2, and for 1950 he gives
# Apr 30 - Sep 24; go with Shanks & Pottenger.
Rule	StJohns	1946	1950	-	May	Sun>=8	2:00	1:00	D
Rule	StJohns	1946	1950	-	Oct	Sun>=2	2:00	0	S
Rule	StJohns	1951	1986	-	Apr	lastSun	2:00	1:00	D
Rule	StJohns	1951	1959	-	Sep	lastSun	2:00	0	S
Rule	StJohns	1960	1986	-	Oct	lastSun	2:00	0	S
# From Paul Eggert (2000-10-02):
# INMS (2000-09-12) says that, since 1988 at least, Newfoundland switches
# at 00:01 local time.  For now, assume it started in 1987.

# From Michael Pelley (2011-09-12):
# We received today, Monday, September 12, 2011, notification that the
# changes to the Newfoundland Standard Time Act have been proclaimed.
# The change in the Act stipulates that the change from Daylight Savings
# Time to Standard Time and from Standard Time to Daylight Savings Time
# now occurs at 2:00AM.
# ...
# http://www.assembly.nl.ca/legislation/sr/annualstatutes/2011/1106.chp.htm
# ...
# MICHAEL PELLEY  |  Manager of Enterprise Architecture - Solution Delivery
# Office of the Chief Information Officer
# Executive Council
# Government of Newfoundland & Labrador

Rule	StJohns	1987	only	-	Apr	Sun>=1	0:01	1:00	D
Rule	StJohns	1987	2006	-	Oct	lastSun	0:01	0	S
Rule	StJohns	1988	only	-	Apr	Sun>=1	0:01	2:00	DD
Rule	StJohns	1989	2006	-	Apr	Sun>=1	0:01	1:00	D
Rule	StJohns	2007	2011	-	Mar	Sun>=8	0:01	1:00	D
Rule	StJohns	2007	2010	-	Nov	Sun>=1	0:01	0	S
#
# St John's has an apostrophe, but Posix file names can't have apostrophes.
# Zone	NAME		STDOFF	RULES	FORMAT	[UNTIL]
Zone America/St_Johns	-3:30:52 -	LMT	1884
			-3:30:52 StJohns N%sT	1918
			-3:30:52 Canada	N%sT	1919
			-3:30:52 StJohns N%sT	1935 Mar 30
			-3:30	StJohns	N%sT	1942 May 11
			-3:30	Canada	N%sT	1946
			-3:30	StJohns	N%sT	2011 Nov
			-3:30	Canada	N%sT

# most of east Labrador

# The name 'Happy Valley-Goose Bay' is too long; use 'Goose Bay'.
# Zone	NAME		STDOFF	RULES	FORMAT	[UNTIL]
Zone America/Goose_Bay	-4:01:40 -	LMT	1884 # Happy Valley-Goose Bay
			-3:30:52 -	NST	1918
			-3:30:52 Canada N%sT	1919
			-3:30:52 -	NST	1935 Mar 30
			-3:30	-	NST	1936
			-3:30	StJohns	N%sT	1942 May 11
			-3:30	Canada	N%sT	1946
			-3:30	StJohns	N%sT	1966 Mar 15  2:00
			-4:00	StJohns	A%sT	2011 Nov
			-4:00	Canada	A%sT

First of all the ids between java.util and java.time differ. We can try to map them obviously but already the count does not match:

I think it does not matter. You can try to sort both lists and print them item by line, then compare in any diff tool.

If you can tell me a way how to retrieve this information from java.util.TimeZone I am happy, but I am clueless how to do it.

java.util.TimeZone imlementation uses org.teavm.classlib.impl.tz.DateTimeZone internally which is slightly updated version of jodatime class. It's capable of providing DST offset changes. Is this enough for you?

assume you are not unzipping and parsing this clutter in the browser.

Of course not. I parse tzdata at compile time and convert it into binary time offset database. I spent some time inveting compact representation of this database. Also, I strip too old records (that gives you wrong results for really old years, but I think it readlly does not matter). You can try to compile java.util.TimeZone example and example that uses timezones in your format and compare sizes.

[ERROR] Failures:
[ERROR]   TestZoneIdParser.test_parse_exactMatch:146 expected:<3> but was:<4>

Any ideas why @Ignore is not honored in travis build?
https://github.com/hohwille/teavm/blob/feature/451-java-time-310-bp/classlib/src/test/java/org/teavm/classlib/java/time/format/TestZoneIdParser.java#L152

OK, So I will now continue with ZoneDB as you suggested.

java.util.TimeZone imlementation uses org.teavm.classlib.impl.tz.DateTimeZone internally which is slightly updated version of jodatime class.

Thanks for the hint. Looks good. I will try my best.
I also found that Java has a method java.util.TimeZone.toZoneId() that will return java.time.ZoneId. I will implement this class in TTimeZone and if I can make this, I will remove my entire generated zone DB for java.time emulation. I assume it will be a little tricky, but sounds very promising and will be the best solution.
When this works, I can delete the generator and migrator as well and should be done for a merge. Surely there will be more options to improve but having this feature working in general would be very beneficial.

Locally build is working while it still fails with travis:
java.lang.AssertionError: Method java.lang.Math.floorDiv(JI)J was not found

Methods like Math.foorDiv have been introduced since 1.8. In this feature branch, I have added them properly to TMath. However, since Java 9 such methods have been added with signature (long, int) therefore build with Java11 was broken.

I am trying to implement TZoneRules based on DateTimeZone but there are problems where I would need help. As I already said the java.time zone DB is somewhat more complex or at least exposes more internals.
DateTimeZone only provides nextTransition and previousTransition methods. With that I am unable to implement TZoneRules.getTransitions() that needs to return List<TZoneOffsetTransition>. There are other similar problems that are not trivial to solve...
So should we instead extend DateTimeZoneProvider with the ability to create TZoneRegion together with TZoneRules from TimeZoneResource?

Still the same error:
java.lang.AssertionError: Method java.lang.Math.floorDiv(JI)J was not found

So it is neither the JDK itself nor the TMath implementation causing this error?
Can you enlighten me what could go wrong here? Some test magic based an a hardcoded JVM emulation in JS? Do I need to migrate all code in org.teavm.classlib.java.time.zone to use TMath instead? Or am I just missing something?

The message clearly states that
java.lang.AssertionError: Method java.lang.Math.floorMod(JI)I was not found

I looked at your implementation of floorMod and it returns long instead of int. How do you build project locally? Do you get these messages?

With that I am unable to implement TZoneRules.getTransitions() that needs to return List

You can implement getTransitions in DateTimeZone yourself. However, I don't see the way to implement this method for some of DateTimeZone implementation, for example, for DSTZone. This method looks strange to me, it's interesting what was motivation of introducing it.

There are other similar problems that are not trivial to solve...

What are they?

So should we instead extend DateTimeZoneProvider with the ability to create TZoneRegion together with TZoneRules from TimeZoneResource?

How are you going to extract such information from TimeZoneResource? If it's possible, why not just to extend DateTimeZoneProvider with all required functions?

I looked at your implementation of floorMod and it returns long instead of int.

Indeed. Sometimes just a second pair of eyes is needed. Thank you very much. One problem less.

How do you build project locally? Do you get these messages?

Maybe due to JDK or due the fact that I am on MacOS (or any other magic circumstance) I did not get this error locally. However, solved and history. Focusing on the remaining issues.

With that I am unable to implement TZoneRules.getTransitions() that needs to return List

You can implement getTransitions in DateTimeZone yourself. However, I don't see the way to implement this method for some of DateTimeZone implementation, for example, for DSTZone. This method looks strange to me, it's interesting what was motivation of introducing it.

I assume without assistance from experts like @jodastephen it will be extermely tricky to find out (especially if the result should not only compile but lead to correct results including conversion between ZoneIds).
Reading the code with constructs like OfYear.iMode is not self-explanatory to me.
AFAIK when jodatime was taken as input for JSR310 a lot of discussion and redesign took place. If I get it properly, from jodatime the DateTimeZone has somehow become ZoneRules and ZoneOffset in java.time. As I said initially, I am unsure if we have all information available that are needed to create ZoneRules from that.
Further even for the simple cases like this I am not sure if this would be correct:
    public TZoneOffset getOffset(TInstant instant) {

        int millis = this.dateTimeZone.getOffset(instant.getEpochSecond());
        return millis2offset(millis);
    }

    private TZoneOffset millis2offset(int millis) {

        return TZoneOffset.ofTotalSeconds(millis / 1000000);
    }

There are other similar problems that are not trivial to solve...

What are they?

Implementating getOffset for LocalDateTime for instance what is based on getOffsetInfo in java.time.
In the end I see more chances for success to dump out all the structured data we can internally get from your TZDB with DateTimeZone and on the other hand compare this with the data that I generated with my code-generator that creates proper instances of TStandardZoneRules that are really functional. If I compare the raw data of both worlds and might be able to find how to calculate one from the other, it might be doable.
Otherwise I would question if it could be suitable to start with my redundant generated TZDB to get this feature basically functional and merged but file an issue to remove that hardcoded generated TZDB Java code and properly solve it with a single TZDB that can server both java.util and java.time.

Now travis says:

No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.

So it seems the test is too slow for travis or I have bugs creating an infinity look. I will dig into this JUnit and try to debug locally.

So in plain Java the test TestLocalDate succeeds within 0.7 secs.
When I add your suggested JVM opts:
-Dteavm.junit.target=target/js-tests -Dteavm.junit.js.runner=htmlunit -Dteavm.junit.threads=4 -Dteavm.junit.minified=true -Dteavm.junit.js.decodeStack=false
then the same test (TestLocalDate) seems to run as JavaScript. It does not fail but takes > 5 minutes to run all test methods and then hangs. If I see this correcly some test methods seem to hang and do not return properly (samller green arrows).

However, looking at the code this is not related to an infinity loop but more due to massive loops with tests that might reveal a memory leak in the testing toolstack...
What can we do about this?
I might be forced to put many tests on @Ignore to get this work in travis... After all I am impressed that this feature is already quite functional and so many tests are working even in JS.

basicTest_query(org.teavm.classlib.java.time.TestLocalTime)  Time elapsed: 0.328 sec  <<< FAILURE!
java.lang.AssertionError: Method java.util.EnumSet.range(Ljava/lang/Enum;Ljava/lang/Enum;)Ljava/util/EnumSet; was not found
    at org.teavm.classlib.java.time.TestLocalTime.<clinit>(TestLocalTime.java:123)
    at org.teavm.junit.TestEntryPoint.before
    at org.teavm.junit.TestEntryPoint.run(TestEntryPoint.java:25)
    at org.teavm.junit.TestEntryPoint.main(TestEntryPoint.java:44)

	at org.teavm.junit.TeaVMTestRunner.compile(TeaVMTestRunner.java:488)
	at org.teavm.junit.TeaVMTestRunner.runChild(TeaVMTestRunner.java:301)
	at org.teavm.junit.TeaVMTestRunner.run(TeaVMTestRunner.java:197)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

Travis failed with this message:
The job exceeded the maximum time limit for jobs, and has been terminated.

@hohwille sure, travis has 40 minutes limit per build. How many tests did you add? How long does it take to run them?

How many tests did you add?

42 test classes with 2373 test methods in total.

How long does it take to run them?

Taking 5 secs (5.392s) in total to run in JVM and >> 10 hours in TeaVM/JS.

42 test classes with 2373 test methods in total.

That's really huge number. I guess TeaVM classlib has even less in total. Is it possible to exclude some of the tests?

That's really huge number. I guess TeaVM classlib has even less in total.

The total number of test methods is now 4473 so this feature is roughly duplicating the number of tests.

Is it possible to exclude some of the tests?

Sure but selecting the right ones would IMHO be massive effort.
I am still convinced that TeaVM is structured too monolithic. Just as a thought assuming this java.time support for classlib could be an own repository with its own tests and its own travis job, you could do a lot to reduce waste of energy as tests for java.time would not have to rerun every time the documentation gets changed or someone changes jso, etc.

I am still convinced that TeaVM is structured too monolithic.

I'm not agree and won't do anything with this, and I'm not going to discuss this, sorry

Please, look at this patch. It helps to reduce compilation time and size:

Eliminate uses of java.util.regex, which is very heavyweight. You should go even further and eliminate regular expressions completely.
Eliminate use of unnecessary reflection. I guess Locale.getUnicodeLocaleType should be implemented, but I have no idea what it does and how to implement it.

Also, most of generated js file (about 3 Mb) is generated tzdb, which is a bad idea from the very start (and I keep asking you to get rid of them).
Another way to improve performance of tests is to introduce per-class compilation instead of per-method. There were reasons to compile each test separately and there are still reasons to keep compiling some of the tests this way, so it must be a matter of choice for particular test classes.

Also, most of generated js file (about 3 Mb) is generated tzdb, which is a bad idea from the very start (and I keep asking you to get rid of them).

I thought that in this PR we agreed on this already. I already spend days of work to get this done and we discussed about the progress and the remaining problems.

Another way to improve performance of tests is to introduce per-class compilation instead of per-method.

Sounds promising.

There were reasons to compile each test separately and there are still reasons to keep compiling some of the tests this way, so it must be a matter of choice for particular test classes.

I fully agree. If there is a way (e.g. annotation) how I could opt-in such feature for tests in java.time, please let me know.

Eliminate uses of java.util.regex, which is very heavyweight. You should go even further and eliminate regular expressions completely.

I have seen in your diffs that lazy initialization of regex patterns can help. I will have a look. Elimination of regex entirely seems not doable (look at the formatter package - I suggested to skip support for this initially but you insisted on this). Maybe JS regex could be used instead.

Eliminate use of unnecessary reflection. I guess Locale.getUnicodeLocaleType should be implemented, but I have no idea what it does and how to implement it.

Locale used to be simple as LL_cc_var but became much more complicated.
Supporting only this method in TeaVM should not be too hard but supporting the whole idea behind these concepts will take a hole lot of effort.
So I went for KISS and kicked this out. I can support it, once TeaVM has full Locale support.
To be honest I still see this PR never to get merged if we end up in perfection.
IMHO we should focus on the important TODOs:

[ ] solve the TZDB issue
[ ] get java.time work functional in browser via TeaVM and even do some manual testing
[ ] select a minimum set of JUnits to ensure the build is working in travis (kick out or @Ignore all others)
[ ] create an issue with all nice to have improvements (e.g. rescue more tests that had to be stripped, do optimizations, fixes for edge-cases, clean code-style, etc.)
[ ] get this PR reviewed and merged
[ ] bring out a new TeaVM release so the feature can actually bring value to the world
[ ] start working on the issue with improvements (once java.time is in the code base people could file individual small PRs with improvements, monster PRs like this tend to get stuck and require a lot of attention and effort).

For the record:
TeaVM tests do not work (even without this PR) on MacOS:
Tests run: 53, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 52.926 sec <<< FAILURE! - in org.teavm.classlib.java.io.FileTest
equalsLjava_lang_Object(org.teavm.classlib.java.io.FileTest)  Time elapsed: 0.008 sec  <<< FAILURE!
java.lang.AssertionError: File system is case insensitive
	at org.junit.Assert.fail(Assert.java:88)
	at org.junit.Assert.assertTrue(Assert.java:41)
	at org.teavm.classlib.java.io.FileTest.equalsLjava_lang_Object(FileTest.java:689)

Already getting a lot better (The failing test is the MacOS problem I posted above):
Tests run: 4640, Failures: 1, Errors: 0, Skipped: 8

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for TeaVM 0.7.0-SNAPSHOT:
[INFO]
[INFO] TeaVM .............................................. SUCCESS [  0.225 s]
[INFO] TeaVM metaprogramming API .......................... SUCCESS [  4.250 s]
[INFO] TeaVM interop API .................................. SUCCESS [  1.315 s]
[INFO] TeaVM core ......................................... SUCCESS [ 18.041 s]
[INFO] TeaVM JavaScript objects ........................... SUCCESS [  1.085 s]
[INFO] TeaVM JavaScript APIs .............................. SUCCESS [  4.093 s]
[INFO] TeaVM platform ..................................... SUCCESS [  2.223 s]
[INFO] TeaVM JavaScript objects - implementation .......... SUCCESS [  1.581 s]
[INFO] TeaVM metaprogramming API implementation ........... SUCCESS [  2.056 s]
[INFO] TeaVM Java class library ........................... SUCCESS [ 35.852 s]
[INFO] TeaVM tooling core ................................. SUCCESS [  2.160 s]
[INFO] TeaVM JUnit runner ................................. SUCCESS [  1.923 s]
[INFO] TeaVM html4j support ............................... SUCCESS [02:54 min]
[INFO] TeaVM Incremental C builder ........................ SUCCESS [  1.180 s]
[INFO] TeaVM maven ........................................ SUCCESS [  0.006 s]
[INFO] TeaVM maven plugin ................................. SUCCESS [  2.457 s]
[INFO] TeaVM maven web application archetype .............. SUCCESS [  0.659 s]
[INFO] TeaVM debugging backend for Google Chrome RDP ...... SUCCESS [  1.688 s]
[INFO] TeaVM Dev Sever .................................... SUCCESS [  3.780 s]
[INFO] TeaVM tests ........................................ FAILURE [  02:14 h]
[INFO] TeaVM slf4j ........................................ SKIPPED
[INFO] TeaVM samples ...................................... SKIPPED
[INFO] TeaVM Hello world web application .................. SKIPPED
[INFO] TeaVM performance benchmark ........................ SKIPPED
[INFO] TeaVM Web Storage web application .................. SKIPPED
[INFO] TeaVM HTML5 video web application .................. SKIPPED
[INFO] TeaVM CPS demo ..................................... SKIPPED
[INFO] TeaVM Kotlin web application ....................... SKIPPED
[INFO] TeaVM Scala example ................................ SKIPPED
[INFO] TeaVM Web gamepad web application .................. SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  02:18 h
[INFO] Finished at: 2020-02-26T12:44:44+01:00
[INFO] ------------------------------------------------------------------------

[INFO] Total time:  02:18 h

So should I convert most of the tests back to regular Java tests based on T* classes?
Or put @Ignore on most of the tests?
Or even delete entire tests from this PR?
Any better ideas?
My suggestion would be to introduce JUnit categories and therefore allow to enable additional Tests via a Maven profile that is disabled by default (or at least in travis). WDYT?
IMHO it is a must have that travis build is working and giving proper CI feedback.

I just added support for per-class compilation of tests. You can rebase to latest master and add @WholeClassCompilation annotation on your classes. Also, are these test include generated tzdb?

I just added support for per-class compilation of tests. You can rebase to latest master and add @WholeClassCompilation annotation on your classes.

Thank you. Excellent. I applied this to all java.time tests and it massively spees up the tests. Now build is fast enough for travis. Great.
I still have a test that fails in travis that worked locally:
Tests run: 4642, Failures: 1, Errors: 0, Skipped: 8
...
org.teavm.classlib.java.time.TestLocalTime
now_ZoneId(org.teavm.classlib.java.time.TestLocalTime)  Time elapsed: 0.009 sec  <<< FAILURE!
java.lang.AssertionError: expected:<22:57:47.096926> but was:<22:57:47.096924>
	at org.junit.Assert.fail(Assert.java:88)
	at org.junit.Assert.failNotEquals(Assert.java:743)
	at org.junit.Assert.assertEquals(Assert.java:118)
	at org.junit.Assert.assertEquals(Assert.java:144)
	at org.teavm.classlib.java.time.TestLocalTime.now_ZoneId(TestLocalTime.java:249)

This seems to be just a problem of exact accuracy so I would just compare with a little epsylon of tolerance here.
Finally, I still seem to have some reflection nonsense to tidy up here:
Running org.teavm.classlib.java.time.TestOffsetDateTime
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.teavm.classlib.java.time.TestOffsetDateTime (file:/home/travis/build/konsoletyper/teavm/tests/target/test-classes/) to constructor java.time.OffsetDateTime(java.time.LocalDateTime,java.time.ZoneOffset)
WARNING: Please consider reporting this to the maintainers of org.teavm.classlib.java.time.TestOffsetDateTime
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

Will keep working once I have time but it is looking great. IMHO we only have this TZDB problem left as main issue. So I hope I can complete this within the next couple of weeks.

From travis:
[INFO] Reactor Summary for TeaVM 0.7.0-dev-1053:
[INFO]
[INFO] TeaVM .............................................. SUCCESS [  0.355 s]
[INFO] TeaVM metaprogramming API .......................... SUCCESS [  8.586 s]
[INFO] TeaVM interop API .................................. SUCCESS [  3.678 s]
[INFO] TeaVM core ......................................... SUCCESS [ 40.461 s]
[INFO] TeaVM JavaScript objects ........................... SUCCESS [  3.336 s]
[INFO] TeaVM JavaScript APIs .............................. SUCCESS [  8.778 s]
[INFO] TeaVM platform ..................................... SUCCESS [  5.608 s]
[INFO] TeaVM JavaScript objects - implementation .......... SUCCESS [  5.004 s]
[INFO] TeaVM metaprogramming API implementation ........... SUCCESS [  5.123 s]
[INFO] TeaVM Java class library ........................... SUCCESS [ 48.391 s]
[INFO] TeaVM tooling core ................................. SUCCESS [  4.949 s]
[INFO] TeaVM JUnit runner ................................. SUCCESS [  4.219 s]
[INFO] TeaVM html4j support ............................... SUCCESS [ 40.510 s]
[INFO] TeaVM Incremental C builder ........................ SUCCESS [  3.372 s]
[INFO] TeaVM maven ........................................ SUCCESS [  0.008 s]
[INFO] TeaVM maven plugin ................................. SUCCESS [  4.805 s]
[INFO] TeaVM maven web application archetype .............. SUCCESS [  0.597 s]
[INFO] TeaVM debugging backend for Google Chrome RDP ...... SUCCESS [  4.781 s]
[INFO] TeaVM Dev Sever .................................... SUCCESS [  9.148 s]
[INFO] TeaVM tests ........................................ SUCCESS [06:32 min]
[INFO] TeaVM slf4j ........................................ SUCCESS [  3.283 s]
[INFO] TeaVM samples ...................................... SUCCESS [  0.006 s]
[INFO] TeaVM Hello world web application .................. SUCCESS [  6.356 s]
[INFO] TeaVM performance benchmark ........................ SUCCESS [01:28 min]
[INFO] TeaVM Web Storage web application .................. SUCCESS [  4.881 s]
[INFO] TeaVM HTML5 video web application .................. SUCCESS [  3.502 s]
[INFO] TeaVM CPS demo ..................................... SUCCESS [  4.394 s]
[INFO] TeaVM Kotlin web application ....................... SUCCESS [  6.165 s]
[INFO] TeaVM Scala example ................................ SUCCESS [ 16.735 s]
[INFO] TeaVM Web gamepad web application .................. SUCCESS [  5.101 s]
[INFO] TeaVM CLI .......................................... SUCCESS [ 10.059 s]
[INFO] TeaVM IDEA plugin parent ........................... SUCCESS [  0.027 s]
[INFO] TeaVM IDEA artifacts ............................... SUCCESS [ 26.705 s]
[INFO] TeaVM IDEA JPS common artifact ..................... SUCCESS [  2.208 s]
[INFO] TeaVM IDEA JPS plugin .............................. SUCCESS [  0.952 s]
[INFO] TeaVM IDEA plugin .................................. SUCCESS [  6.258 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  12:59 min
[INFO] Finished at: 2020-03-01T16:20:00Z
[INFO] ------------------------------------------------------------------------

But:
The command "node start.js $BASE_PATH/tests/target/js-tests" exited with 1.

Locally maven also succeeds (if I disable the filesystem test that always fails on MacOS).
So js-tests is doing what? Executing the JUnits again with Node.js?
/org/teavm/classlib/java/time/zone/TestStandardZoneRules/undefined:
null: expected:<[Dublin]> but was:<[Greenwich Mean Time]>
Error: Java exception thrown
    at $rt_exception (file:///home/travis/build/konsoletyper/teavm/tests/target/js-tests/org/teavm/classlib/java/time/zone/TestStandardZoneRules/classTest-min.js:11:306)

So how could I debug things like this in order to be able to fix it?

So js-tests is doing what? Executing the JUnits again with Node.js?

No, JUnit without special flags does not run tests at all, it just runs tests in JVM and compiles them to JavaScript. In order to actually run tests in Rhino, you should pass -Dteavm.junit.js.runner=htmlunit in command line (BTW, I never run tests through Maven locally, I use IDEA runner). Also you may add something like -Dteavm.junit.threads=6 to improve performance a little.
In travis I dont use Rhino to run tests. First, Rhino is slower than V8. Second, I want to be sure that generated JavaScript run in the browser, since Rhino is not 100% equivalent of browser JS due to possible bugs. I could not invent the way to automate this from JUnit runner or from Maven.
To run JavaScript tests in the way Travis does, you need two things:

Install node.js
Open tests/src/test/js/index.html in the browser
Run tests/src/test/js/run.sh from command line

So how could I debug things like this in order to be able to fix it?

Generated JavaScript can be found at tests/target/js-tests. Previously TeaVM runner also created html files for convenience to run these tests quickly. I broken this behaviour when added @WholeClassCompilation. You should modifiy these html to look like this:
<!DOCTYPE html>
<html>
<head>
  <title>TeaVM JUnit test</title>
  <meta http-equiv="Content-Type" content="text/html;charset=UTF-8"/>
</head>
<body>
<script type="text/javascript" src="../classTest.js"></script>
<script type="text/javascript">
    main(["TEST_IDENTIFIER"], function(result) {
        var message = result instanceof Error ? buildErrorMessage(result) : "OK";
        document.body.appendChild(document.createTextNode(message))
    });

    function buildErrorMessage(e) {
        var stack = "";
        if (e.$javaException && e.$javaException.constructor.$meta) {
            stack = e.$javaException.constructor.$meta.name + ": ";
            stack += e.$javaException.getMessage() || "";
            stack += "\n";
        }
        stack += e.stack;
        return stack;
    }
</script>
</body>
</html>

where TEST_IDENTIFIER has following format: <package.name>.<ClassName>.<methodName>()V

Previously TeaVM runner also created html files for convenience to run these tests quickly. I broken this behaviour when added @WholeClassCompilation

Fixed

JodaTime is mainly using DateTimeZoneBuilder.PrecalculatedZone internally to represent a time zone (besides simple fixed ones). Those have to be adapted or transformed to [T]StandardZoneRules.

Maybe iWallOffsets corresponds to wallOffsets.
Then iStandardOffsets could correspond to standardOffsets.
No clue about the rest.
Further problem is that the APIs of time zone representations both in JodaTime and java.time do not reveal the internals so I have no clue how to get these internals inside TeaVM to build TStandardZoneRules from the values. Further the APIs are so incompatible that I can not directly adapt from JodaTime to java.time. What I tried so far is:
class DateTimeZoneZoneRules extends TZoneRules implements TSerializable {

    private final DateTimeZone dateTimeZone;

    public DateTimeZoneZoneRules(DateTimeZone dateTimeZone) {

        super();
        this.dateTimeZone = dateTimeZone;
    }

    @Override
    public boolean isFixedOffset() {

        return this.dateTimeZone.isFixed();
    }

    @Override
    public TZoneOffset getOffset(TInstant instant) {

        int millis = this.dateTimeZone.getOffset(instant.getEpochSecond());
        return millis2offset(millis);
    }

    private TZoneOffset millis2offset(int millis) {

        return TZoneOffset.ofTotalSeconds(millis / 1000000);
    }

    @Override
    public TZoneOffset getOffset(TLocalDateTime localDateTime) {

        return null;
    }

    @Override
    public List<TZoneOffset> getValidOffsets(TLocalDateTime localDateTime) {

        return null;
    }

    @Override
    public TZoneOffsetTransition getTransition(TLocalDateTime localDateTime) {

        // TODO Auto-generated method stub
        return null;
    }

    @Override
    public TZoneOffset getStandardOffset(TInstant instant) {

        int millis = this.dateTimeZone.getStandardOffset(instant.getEpochSecond());
        return millis2offset(millis);
    }

    @Override
    public TZoneOffsetTransition nextTransition(TInstant instant) {

        long millis = this.dateTimeZone.nextTransition(instant.getEpochSecond());
        // return TZoneOffsetTransition.of(transition, offsetBefore, offsetAfter);
        return null;
    }

    @Override
    public TZoneOffsetTransition previousTransition(TInstant instant) {

        long millis = this.dateTimeZone.previousTransition(instant.getEpochSecond());
        return null;
    }

    @Override
    public List<TZoneOffsetTransition> getTransitions() {

        // TODO Auto-generated method stub
        return null;
    }

    @Override
    public List<TZoneOffsetTransitionRule> getTransitionRules() {

        // TODO Auto-generated method stub
        return null;
    }
}

The first two methods may be trivial to implement as adapter, but the others are tricky or even impossible to implent. That is what as I was telling from the start. The java.time time-zones are complex and I have no clue how to adapt them. If neither @jodastephen nor you have any further idea, I am kind of stuck here.
I assume that the "adapter" approach is doomed and will never work out.
So I would need to get the "raw" data that is internally used to build the DateTimeZone instances inside TeaVM. However, I am also quite unable to understand the TimeZoneResource that seems to use StorableDateTimeZone what again is using PrecalculatedZone.readZone(id, flow).
So maybe the best approach would be the following:
Change DateTimeZone inside TeaVM such that it provides a method to convert to TZoneRules. Then implement this method in implementations such as PrecalculatedZone with full access to internal private fields and creating TStandardZoneRules directly from converting that data. Might still require some wisdom but maybe can be done with an initial best guess and then improving with trial&error via failing tests. Any better ideas?

Here is my hackish code to analyse the conversion between the two worlds:
import java.lang.reflect.Field;
import java.time.LocalDateTime;
import java.time.ZoneId;
import java.time.ZoneOffset;
import java.time.zone.ZoneOffsetTransitionRule;
import java.time.zone.ZoneRules;
import java.util.Arrays;
import java.util.Set;

import org.joda.time.DateTimeZone;
import org.joda.time.tz.CachedDateTimeZone;
import org.joda.time.tz.FixedDateTimeZone;

public class Joda2Jsr310Test {

  private static Field STANDARD_TRANSITIONS;

  private static Field STANDARD_OFFSETS;

  private static Field WALL_OFFSETS;

  private static Field SAVINGSINSTANT_TRANSITIONS;

  private static Field SAVINGS_LOCAL_TRANSITIONS;

  private static Field LAST_RULES;

  private static Field I_WALL_OFFSET;

  private static Field I_STANDARD_OFFSET;

  static {
    try {
      STANDARD_TRANSITIONS = ZoneRules.class.getDeclaredField("standardTransitions");
      STANDARD_TRANSITIONS.setAccessible(true);

      STANDARD_OFFSETS = ZoneRules.class.getDeclaredField("standardOffsets");
      STANDARD_OFFSETS.setAccessible(true);

      WALL_OFFSETS = ZoneRules.class.getDeclaredField("wallOffsets");
      WALL_OFFSETS.setAccessible(true);

      SAVINGSINSTANT_TRANSITIONS = ZoneRules.class.getDeclaredField("savingsInstantTransitions");
      SAVINGSINSTANT_TRANSITIONS.setAccessible(true);

      SAVINGS_LOCAL_TRANSITIONS = ZoneRules.class.getDeclaredField("savingsLocalTransitions");
      SAVINGS_LOCAL_TRANSITIONS.setAccessible(true);

      LAST_RULES = ZoneRules.class.getDeclaredField("lastRules");
      LAST_RULES.setAccessible(true);

      I_WALL_OFFSET = FixedDateTimeZone.class.getDeclaredField("iWallOffset");
      I_WALL_OFFSET.setAccessible(true);

      I_STANDARD_OFFSET = FixedDateTimeZone.class.getDeclaredField("iStandardOffset");
      I_STANDARD_OFFSET.setAccessible(true);

    } catch (Exception e) {
      // TODO Auto-generated catch block
      e.printStackTrace();
    }
  }

  public static void main(String[] args) {

    Set<String> availableIDs = DateTimeZone.getAvailableIDs();
    for (String tzId : availableIDs) {
      System.out.println();
      System.out.println("Time-Zone-ID=" + tzId);
      DateTimeZone tz = DateTimeZone.forID(tzId);
      ZoneId zid = null;
      try {
        zid = ZoneId.of(tzId);
        if (zid != null) {
          System.out.println("  java.time.ZoneRules:");
          ZoneRules rules = zid.getRules();
          long[] standardTransitions = (long[]) STANDARD_TRANSITIONS.get(rules);
          System.out.println("standardTransitions=" + Arrays.toString(standardTransitions));
          ZoneOffset[] standardOffsets = (ZoneOffset[]) STANDARD_OFFSETS.get(rules);
          System.out.println("standardOffsets=" + Arrays.toString(standardOffsets));
          long[] savingsInstantTransitions = (long[]) SAVINGSINSTANT_TRANSITIONS.get(rules);
          System.out.println("savingsInstantTransitions=" + Arrays.toString(savingsInstantTransitions));
          LocalDateTime[] savingsLocalTransitions = (LocalDateTime[]) SAVINGS_LOCAL_TRANSITIONS.get(rules);
          System.out.println("savingsLocalTransitions=" + Arrays.toString(savingsLocalTransitions));
          ZoneOffset[] wallOffsets = (ZoneOffset[]) WALL_OFFSETS.get(rules);
          System.out.println("wallOffsets=" + Arrays.toString(wallOffsets));
          ZoneOffsetTransitionRule[] lastRules = (ZoneOffsetTransitionRule[]) LAST_RULES.get(rules);
          System.out.println("lastRules=" + Arrays.toString(lastRules));
        }
        if (tz instanceof CachedDateTimeZone) {
          tz = ((CachedDateTimeZone) tz).getUncachedZone();
        }
        System.out.println("  " + tz.getClass().getName() + ":");
        if (tz instanceof FixedDateTimeZone) {
          int iWallOffset = (int) I_WALL_OFFSET.get(tz);
          System.out.println("iWallOffset=" + iWallOffset);
          int iStandardOffset = (int) I_STANDARD_OFFSET.get(tz);
          System.out.println("iStandardOffset=" + iStandardOffset);

        } else if (tz.getClass().getName().equals("class org.joda.time.UTCDateTimeZone")) {

        } else if (tz.getClass().getName().equals("org.joda.time.tz.DateTimeZoneBuilder$PrecalculatedZone")) {
          Field field = tz.getClass().getDeclaredField("iTransitions");
          field.setAccessible(true);
          long[] iTransitions = (long[]) field.get(tz);
          System.out.println("iTransitions=" + Arrays.toString(iTransitions));
          field = tz.getClass().getDeclaredField("iWallOffsets");
          field.setAccessible(true);
          int[] iWallOffsets = (int[]) field.get(tz);
          System.out.println("iWallOffsets=" + Arrays.toString(iWallOffsets));
          field = tz.getClass().getDeclaredField("iStandardOffsets");
          field.setAccessible(true);
          int[] iStandardOffsets = (int[]) field.get(tz);
          System.out.println("iStandardOffsets=" + Arrays.toString(iStandardOffsets));
          field = tz.getClass().getDeclaredField("iNameKeys");
          field.setAccessible(true);
          String[] iNameKeys = (String[]) field.get(tz);
          System.out.println("iNameKeys=" + Arrays.toString(iNameKeys));
        }
      } catch (Exception e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
      }
    }
  }

}

As an example the first time-zone output is:
Time-Zone-ID=Africa/Abidjan
  java.time.ZoneRules:
standardTransitions=[-1830383032]
standardOffsets=[-00:16:08, Z]
savingsInstantTransitions=[-1830383032]
savingsLocalTransitions=[1912-01-01T00:00, 1912-01-01T00:16:08]
wallOffsets=[-00:16:08, Z]
lastRules=[]
  org.joda.time.tz.DateTimeZoneBuilder$PrecalculatedZone:
iTransitions=[-9223372036854775808, -1830383032000]
iWallOffsets=[-968000, 0]
iStandardOffsets=[-968000, 0]
iNameKeys=[LMT, GMT]

So as we can see iWallOffsets can really be converted to wallOffsets as it contains the ZoneOffset as raw milliseconds (as int value). For 0 we need to provide ZoneOffset.UTC (which is displayed as Z).
In this example the 2nd argument of iTransitions is the standardTransitions as well as savingsInstantTransitions in milliseconds that has to be converted to seconds (/1000). Looking at more complex examples I can not figure the first argument of iTransitions but all args starting from the 2nd always seem to correspond to savingsInstantTransitions. Further, the standardTransitions seems to be a kind of sub-set of savingsInstantTransitions.
Maybe the first argument of iTransitions somehow corresponds to the base LocalDateTime from savingsLocalTransitions. This is still unclear but it might get doable with some more fiddling.

I converted the ZoneOffsets to millis so the output can be compared easier.
It seems we can entirely ignore this pointless information.

Time-Zone-ID=WET
savingsInstantTransitions=[228877200, 243997200, 260326800, 276051600, 291776400, 307501200, 323830800, 338950800, 354675600, 370400400, 386125200, 401850000, 417574800, 433299600, 449024400, 465354000, 481078800, 496803600, 512528400, 528253200, 543978000, 559702800, 575427600, 591152400, 606877200, 622602000, 638326800, 654656400, 670381200, 686106000, 701830800, 717555600, 733280400, 749005200, 764730000, 780454800, 796179600, 811904400, 828234000, 846378000, 859683600, 877827600]
iTransitions             =[228877200, 243997200, 260326800, 276051600, 291776400, 307501200, 323830800, 338950800, 354675600, 370400400, 386125200, 401850000, 417574800, 433299600, 449024400, 465354000, 481078800, 496803600, 512528400, 528253200, 543978000, 559702800, 575427600, 591152400, 606877200, 622602000, 638326800, 654656400, 670381200, 686106000, 701830800, 717555600, 733280400, 749005200, 764730000, 780454800, 796179600, 811904400, 828234000, 846378000]
wallOffsets =[0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0]
iWallOffsets=[0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0, 3600000, 0]

For such cases as above where the entries are identical except that java.time has two additional entries, I assume that joda.time is just outdated and java.time more accurate. So such cases should not be a big issue.

Not matching Time-Zone IDs:
Only in Jodatime:

Canada/East-Saskatchewan
EST
GMT-0
GMT+0
HST
MST
ROC

Only in java.time:

America/Fort_Nelson
America/Punta_Arenas
Asia/Atyrau
Asia/Barnaul
Asia/Famagusta
Asia/Qostanay
Asia/Tomsk
Asia/Yangon
Europe/Astrakhan
Europe/Kirov
Europe/Saratov
Europe/Ulyanovsk
SystemV/AST4
SystemV/AST4ADT
SystemV/CST6
SystemV/CST6CDT
SystemV/EST5
SystemV/EST5EDT
SystemV/HST10
SystemV/MST7
SystemV/MST7MDT
SystemV/PST8
SystemV/PST8PDT
SystemV/YST9
SystemV/YST9YDT

Tavis will fail:
[ERROR] Tests run: 11, Failures: 0, Errors: 11, Skipped: 0, Time elapsed: 0.015 s <<< FAILURE! - in org.teavm.classlib.java.time.format.TestFractionPrinterParser
[ERROR] test_parse_nothing(org.teavm.classlib.java.time.format.TestFractionPrinterParser)  Time elapsed: 0.01 s  <<< ERROR!
java.lang.UnsatisfiedLinkError: org.teavm.classlib.impl.tz.DateTimeZoneProvider.getResource()Lorg/teavm/platform/metadata/ResourceMap;

So it seems that DateTimeZoneProvider that I now use can not be tested in JUnit.

Please, don't work on this PR anymore. I thought you abandoned it and tried to revive it myself, but found that it's better to do everything myself rather than trying to deal with mistakes you made. I chosen a bit different direction and don't transform code manually, but using package mapping techniques and implementing testng support.

I abandoned PR #464 and not this one.
In the end I am happy if one way or the other TeaVM has support for java.time.
To better motivate your contributors it would be better to tell them the positive things rather than that their PR and their work will be closed because of their mistakes ;)
I hope that my work was not entirely wasted and helped you proceeding.

I chosen a bit different direction and don't transform code manually, but using package mapping.

I hope you are aware that the initial code of 310bp is not fully java.time compatible and I invested quite some time to resolve this.

Any updates on the topic? Are you still working on java.time support for TeaVM? What is the status? Is there a new PR?

I'm still working on java.time support, but it required a lot of efforts and I don't have much spare time to work on it. Most of the tests pass, now I'm trying to fix rest of them.

Any updates? Could you create a PR (as work in progress) with the state of your work? There is no public visible progress on this topic since my last commit 9 months ago. I also spent lots of effort into this topic and would still be available to support working on it as I have need for this feature. However, if you are only working on private local branch this is pretty much a black box.

Any updates? Could you create a PR (as work in progress) with the state of your work? There is no public visible progress on this topic since my last commit 9 months ago. I also spent lots of effort into this topic and would still be available to support working on it as I have need for this feature. However, if you are only working on private local branch this is pretty much a black box.


[docs] Correct by and enum typo in api.md

by and enum should be by an enum
(The rest of the file looks good 😉)

@G-Rath It's a great first pull request on Material-UI 👌🏻. Thank you for giving it a shot!


Fix grammar typo

@GitHubPang : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Looks good; thanks @GitHubPang.


replace some magic numbers in process_nmea0183()

While studying the NMEA sentences, I noticed some magic numbers in process_nmea0183() which I replaced, so the code is a bit more readable I think.
I checked the generated asm before and after also, there is no difference (other than the .loc debug info of course) meaning the compiler replaces the strlen(...) + 1 with the constant 5. (Line addq	$5, %rdx is what we are interested in.)
Before:
.L5868:
	.loc 2 2346 5 view .LVU8752
	cmpb	$42, (%rsi,%rdx)
	jne	.L5869
	.loc 2 2348 4 is_stmt 1 view .LVU8753
	.loc 2 2348 13 is_stmt 0 view .LVU8754
	addq	$5, %rdx
	.loc 2 2349 4 view .LVU8755
	movl	$gprmc, %edi
	.loc 2 2348 13 view .LVU8756
	movq	%rdx, gprmclen(%rip)
	.loc 2 2349 4 is_stmt 1 view .LVU8757
	call	memcpy

After:
.L5868:
	.loc 2 2346 5 view .LVU8752
	cmpb	$42, (%rsi,%rdx)
	jne	.L5869
	.loc 2 2348 25 is_stmt 1 view .LVU8753
	.loc 2 2348 34 is_stmt 0 view .LVU8754
	addq	$5, %rdx
	.loc 2 2349 4 view .LVU8755
	movl	$gprmc, %edi
	.loc 2 2348 34 view .LVU8756
	movq	%rdx, gprmclen(%rip)
	.loc 2 2349 4 is_stmt 1 view .LVU8757
	call	memcpy

Thanks. Good idea, I have modified it a little bit.
Please see my commit.

We are talking about the last field of a NMEA0183 message:
delimiter - checksum - CR - LF (**xxCRLF") - a define NMEA0183_CC_CR_LF is pretty readable.

I agree, better this way.

Great. Now we make sure everybody will realize that this is a checksum.
This checksum is mandatory to verify the integrity of a NMEA0183 message.
GPSBabbel will not convert to other formats if the checksum is bad.


Update private-endpoint-overview.md

Updated the section that talks about when creating a private endpoint to mention that a NIC is AUTOMATICALLY created for you as a result of creating the private endpoint.  The original verbiage was not clear that the additional NIC resource gets created automatically.  This can lead to confusion when deploying a private endpoint manually through the portal or through IaC.

@richie-insight : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#label:"aq-pr-triaged"

@ktoliver : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Issue with member.fetch in which it fetches user even if it is a webhook

Please describe the changes this PR makes and why it should be merged:
This fixes an issue where the meber.fetch will try and fetch the webhook "authorid"
Status

[X] Code changes have been tested.

Semantic versioning classification:

[ ] This PR changes the library's interface (methods or parameters added)
[ ] This PR includes breaking changes (methods removed or renamed, parameters moved or removed)
[ ] This PR only includes non-code changes, like changes to documentation, README, etc.

Please run pnpm run prettier to comply with our prettier config


Feature request: Real-time Preview Processing

Expected behaviour
Use-case
While in camera preview mode, it is able to detect object such as "Rectangle" or "Facial" and draw a rectangle around the object.
Is it possible to achieve the use-case in javascript, such as having a new onPreivew() method that returns the image and then perform the detection algorithm on the image?
Thanks, any advice are welomed.

I'd like to add to this - I'm currently attempting to add an event that returns the preview image so that additional processing can be done. Taking captures is just too slow on Android (iOS is fairly quick). On Android this looks to be fairly straightforward as the byte[] is available, but for iOS its seems a bit more involved. Though any pointers are welcome, as Obj-C isn't a language I know :)

@dotnetprofessional  Have you tried master?  There are some changes which may improve capture performance on android that I don't think have been released yet.
The iOS version of the android byte[] is here i think.

@npomfret Thanks for the details - I've not tried master. I took a look at the iOS link you gave me, but that's if you do a capture. I'm looking at getting the byte[] from a preview so that its really fast. My scenario (which is odd I'll admit) is to capture the video preview and save the image as a JPG so that a webview can keep refreshing it. The idea is to provide a pysdo stream within a webview ie a web page. We can use WebRTC on Android but iOS doesn't support that.

please take a look at anyline ocr react-native demo for this

@barron9 Thanks but the pricing model would bankrupt us given our product.

What are the rules regarding plugging commercial products on here?

no just take the idea, their custom camera draws rectangles around objects words etc in every 10 or 20 ms. to recognize cam refreshes itself so processes while on preview

+1

@dbishai is this https://github.com/dbishai/react-native-camera/commit/75553a6a1d09842558ad16fd6cb16abcd67cdcad performa performatic?

@sibelius, what does "performa performatic" mean?

This should be reopened
Related: #2984


handle runtime dependencies of python modules in message recipes

The message recipes, e.g. std-msgs, geometry-msgs, nav-msgs, provide the msg files (in usr/share/ of the common package), the C headers (only in the dev-package) and the generated python modules.
Some ROS packages depend on the C headers for the compilation, other ROS packages depend during the run time on the python modules.
If messages depend on other messages, the corresponding recipes must add a DEPENDS for the other message for the C headers, and a RDEPENDS for the python modules. This was discovered in a recent commit [1].
To keep the image as small as possible, shall we split the message recipes into separate packages (e.g. '...-plain' for only the msg file, and '...-python' for the python files) and explicitly add the runtime dependencies to those packages?
[1] https://github.com/bmwcarit/meta-ros/commit/997876732d2f09164da1f82b7a7be75950e0d151

@bulwahn < Can this issue be closed?

"Silence implies consent" (see http://wiki.c2.com/?SilenceImpliesConsent).


Fix missing bottom border on tabs container

fixing small regression from tabs container

@alioso  could you include cursory notes for testing?

@patthiel goof call, will do indeed


Trancate Bug

If use the truncate, the event will not be recorded.

Tested on percona 5.6.39 and recived event

=== Event query ===
Date: 2018-05-15T06:38:34+00:00
Log position: 327
Event size: 88
Database: test1
Execution time: 0
Query: TRUNCATE TABLE `fff`
Memory usage 2.08 MB

@dulumao I added integration tests for that (so event is generated in mysql 5.6, 5.7 and mariadb 10.3). Can you send me how your php configuration or example how you test it ?
You shoud recive truncate in QueryEvent (more in https://github.com/krowinski/php-mysql-replication/blob/master/tests/Integration/BasicTest.php#L246)

@krowinski I re-tested and found normal.


uwp input interface

uwp inputinterfaceSample ，Demo program does not work properly

You appear to have opened just the vcxproj directly. You need to open open the sln which contains two projects. If you are having trouble with the sample browser ZIPs, you can clone the whole repo.

You appear to have opened just the vcxproj directly. You need to open the sln which contains two projects. If you are having trouble with the sample browser ZIPs, you can clone the whole repo.

I added directxtk to the solution as prompted, but the three. H files referenced by "include" did not load normally and were not displayed in the solution view

I've set the correct path for the project reference, but it still doesn't work.

@walbourn


bytearray() buffers in addition to array.array

Any objection to a PR to support bytearray in addition to array.array buffers? bytearray() has the advantage that you can specific the length when you create it instead of needing an initializer object.
Context is this commit which added the implicit readinto support: https://github.com/pyusb/pyusb/commit/1028dc6d213d027d0f1b0b9dceb7157a4bbff47d

Some methods already support this (those using _interop.as_array, e.g. Device.write).
Others currently don't support it (e.g. Device.read), and I'm not sure it's practical to change them: in the case of Device.read, internally we convert the buffer to array('B'); therefore we would need to make sure that the conversion and back are zero-copy, and actually remember to convert it back to a bytearray before returning, or if any exception is raised...

I think memoryview() would help in the conversion. (It'd also make the "returns less than requested" case zero copy.)
You could invert the test to create a buffer and only do it when given an int. Anything else you'd want to treat as something that implements the buffer protocol.

Can you send a draft PR?
Please note that I don't intend to introduce breaking changes to this API. There's still some leeway in what can be defined as an acceptable change (since every visible side-effect of the current API definition and implementation is probably depended on by someone), but at the very least I don't intend to make programs that are unquestionably correct today break tomorrow.


refactor logical view

Please note that for legal reasons we require you to sign the
Contributor Agreement
before we can accept your pull requests.

Just running the PR tests on it. Once green, this is ready to be merged back.

PR tests as green as they get currently. Can be merged.