[BEAM-3326] Remove SdkHarnessClientControlService

The utility of this service is minimal, at best. The actual client
construction is a trivial call to SdkHarnessClient.create, and users
can just wrap the lower-level client with that call.

Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a JIRA issue filed for the change (usually before you start working on it).  Trivial changes like typos do not require a JIRA issue.  Your pull request should address just this issue, without pulling in other changes.
[x] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue.

[x] Run mvn clean verify to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
[x] If this contribution is large, please file an Apache Individual Contributor License Agreement.

R: @bsidhom

@axelmagn FYI

@angoenka Might be interested in these changes since he has been working towards something like this for Dataflow.

Assuming the changes in https://github.com/apache/beam/pull/4866 are accepted, this likely becomes a no-op including when run against flink, because it removes the need for the EnvironmentManager to directly access data or state services.

@bsidhom Is your concern still true?

No. We can go ahead and remove this now.

run java precommit


Write tests for get_each_review_and_feedback_response_map

Work in progress. test written but do not all pass yet.
1/4 tests passing


Centos version

The docker image is based on ubuntu but i need to use it from centos version.
It's possible to decline the postgres image from centos version ?

Image is based on Debian Jessie (https://github.com/docker-library/postgres/blob/master/Dockerfile.template#L2) not Ubuntu. PostgreSQL packages are installed from repository at http://apt.postgresql.org/pub/repos/apt/.
Now, what exactly do you want to do with/on Centos? You can create your own postgres images based on Centos docker images but you must compensate for potential differences in build process and package layout between RHEL/Centos and Debian.

I prefer use official docker images that why i dislike create my own image.
Centos provides docker images : https://hub.docker.com/r/centos whose one for postgres https://hub.docker.com/r/centos/postgresql/

Don't know about your particular need but I'd recommend you this (Debian based) official PostgreSQL image. Centos image, that you provided link to is ... inferior. It uses supervisord which is clearly not needed and does not have as many configuration options as official image. Then only used case I can see one would prefer Centos based image is to integrate with some RH software which is not available on other Linux distros.

Yes I need to use Centos based image because i need to install a proprietary library compatible with Centos only.


Fix #10 join on multiple feature views

Summary

Tested scenarios

Fixed issue:  #10

Sorry, merging from the wrong branch by mistake. Closing and opening a follow up PR.


Bug:  Postgresql createTable if not exists with multiple schemas

PHP Version
8.1
CodeIgniter4 Version
4.2.4
CodeIgniter4 Installation Method
Composer (using codeigniter4/appstarter)
Which operating systems have you tested for this bug?
Linux
Which server did you use?
fpm-fcgi
Database
PostgreSQL 13.7
What happened?
to use multiple schema I set in database config
'schema' => 'schema1,schema2'
that's working fine so far.
but when use createTable with option "if not exist" then I get Error Table Exists
that happens because the query in Connection::_listTables has an syntax error in WHERE CLAUSE
Steps to Reproduce
'schema' => 'schema1,schema2'
$forge = \Config\Database::forge();
$forge->createTable($tablename, TRUE);
Expected Output
the function should return object or false, without generating an error
Anything else?
No response

Thank you for the report.
But the Steps to Reproduce can not run.
Please provide minimum running code to reproduce the error.
And you didn't provide the exact error message, too.
'schema' => 'schema1,schema2'
$forge = \Config\Database::forge();
$forge->createTable($tablename, TRUE);

How did you call checkOrCreateTable()?
What's the exact parameter value?

i fix it for me with an dirty hack in Connection.php 208 _listTables(bool $prefixLimit = false): string
   $array = explode(',', $this->schema);
    $whc = '';
    foreach ($array as $sc){
        if ($whc != '' ) $whc .= " OR ";
        $whc .= '"table_schema" = \'' . $sc . "'";
    }
    $sql = 'SELECT "table_name" FROM "information_schema"."tables" WHERE '.$whc;

Is 'schema' => 'schema1,schema2' valid config?

It is $schema, not $schemas.
I don't think 'schema1,schema2' is a valid value.

At least with the default settings the search path get set to "public, public".

It seems a bug, but no harm.

Forge is designed to use one schema at a time. We could add a method to set schema but this could get messy. This listTables() method would have have to use schema and table as cache names. But like I said this gets messy.
I'd recommend using a separate connection for each schema.
https://www.postgresql.org/docs/current/ddl-schemas.html

No plan to support multiple schema. Close.


Plugin with id 'jarmonica' not found.

Describe the bug
I am trying to setup a project using the wiki on Intellij but it keeps failing with the error Plugin with id 'jarmonica' not found.
To Reproduce
Clone the sample repo https://github.com/PaulMuriithi/HelloHarmonica
Import it in Intellij and try to build it
Expected behavior
Building ok which does not happen
Environment:
IntelliJ IDEA 2018.1.5 (Ultimate Edition)
Build #IU-181.5281.24, built on June 12, 2018
JRE: 1.8.0_152-release-1136-b39 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.12.6

This is a great tool and I hope to contribute to it since I was looking to build something similar

@PaulMuriithi
Hello.
Please use latest harmonica.
It is version 1.0.13.
Sorry for delaying wiki updating.

I updated wiki. Sorry to be late.

Cool, that worked!
Thanks


[PLAT-111199] update sts until all pods are available

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.0 out of 3 committers have signed the CLA.:x: christopherzli:x: jnyi:x: yuchen-dbYou have signed the CLA already but the status is still pending? Let us recheck it.


Command-line interface to wdb_transfer

Additional command-line binary wdb_transfer_cli.exe needs to be added to Data Transfer tool. It should allow to specify a command - import or export and a DB connection over TDS. On export all tables from the specified DB are exported to a file. On import all tables from the specified file are imported to the specified DB (that must contain pre-created empty schema).

Hope you will consider that export operation should return some response on whether it is success or failure, based on which import can be continued.

@psrinivasa2
Export and import are being implemented as separate operations. So the tool can be invoked (specifying the DB conn) either for export from this DB or for import to this DB. Zero status code is returned on process success and non-zero on failure.
No plans for a log file in initial version - the same output, that is displayed in GUI, is written to stdout and can be redirected to file by caller as needed.

Added wdb_transfer_cli.exe binary in wdb_transer-1.4.0 update. Also added a few examples to wiki page.
There should be no changes at all to the GUI version, please let me know if you see discrepancies.

Thanks Alex, We will check it

HI Alex,
Silent installation works fine, hope there should be generic option to saved the import and export entries into a log file.
This can be closed

@psrinivasa2
Thanks for confirming!
Log files writing raises the questions about log append and log rotate. And I would like to not deal with these questions right now. And just writing a log file with something like:
wdb_transfer_cli.exe export ... --log-file log1.txt

is more or less the same as the shell output redirect:
wdb_transfer_cli.exe export ... > log1.txt 2>&1

and the latter is actually more flexible when calling from PowerShell scripts.


[WIP] make custom.js work with 3.0

Hi,
These are the modification I had to do for custom.js to work on 3.0,
need a little more work to have them also work on 2.3 without changes,
but just in case you want to try.
You should "just" need the following also:
$ cat .ipython/kernels/haskell/kernel.json
{"display_name":"IHaskell","argv":["/Users/bussonniermatthias/.cabal/bin/IHaskell" ,"kernel", "{connection_file}"]}

And it should work with IPython 3.0.
Side note, conceal extension is quite cool.
got a kernel crash with \.<tab>
[I 14:55:55.516 NotebookApp] Saving file at /Untitled.ipynb
IHaskell: src/IHaskell/IPython/Message/Parser.hs:(125,3)-(129,59): Irrefutable pattern failed for pattern Data.Aeson.Types.Internal.Success parsed

You can easily reproduce programatically with IPython.notebook.kernel.complete('\.',2, function(data){console.log(data)})
Should I open a separate bug ?

Ack! This somehow slipped through the cracks and I didn't notice it until now. Please open a separate bug for the crashing! I'll take a look at this soonish, I would like to make sure IHaskell works with IPython 3.0 shortly after IPython 3.0 is released.

Ack! This somehow slipped through the cracks and I didn't notice it until now. Please open a separate bug for the crashing!

No need to apologize, last weeks were pretty crazy and next will be to.
I still need to polish this PR.


OpenCV build error with toolchain ios-nocodesign-11-4-dep-9-3

log.txt
xcode  9.4
ios       11.4
toolchain  ios-nocodesign-11-4-dep-9-3

The nocodesign toolchain will work fine for build tests, but I you can't run the final executable on a device.
Can you post these files?
See also "/Users/ivy/.hunter/_Base/f58bcf2/9e7542d/48de53c/Build/OpenCV/Build/OpenCV-Release-prefix/src/OpenCV-Release-build/CMakeFiles/CMakeOutput.log".
See also "/Users/ivy/.hunter/_Base/f58bcf2/9e7542d/48de53c/Build/OpenCV/Build/OpenCV-Release-prefix/src/OpenCV-Release-build/CMakeFiles/CMakeError.log".

CMakeOutput.txt
CMakeError.txt

=== BUILD TARGET cmTC_71225 OF PROJECT CMAKE_TRY_COMPILE WITH CONFIGURATION Debug ===

Check dependencies
Code Signing Warning: "cmTC_71225" isn't code signed but requires entitlements. It is not possible to add entitlements to a binary without signing it.

This looks like a CMAKE_TRY_COMPILE issue, as discussed here.  My guess is that this is somehow related to your enterprise account.  The CI builds use nocodesign-* toolchains without issue.  Since nocodesign-* won't be of much practical benefit, let's focus on your build in #720 .


Ablility to access observations of other agents in scenarios

I'm trying to reproduce the results of OPRE paper. There the agents have been trained on meltingpot scenario-type settings (OPRE is trained on committed agents like rock, paper, scissors in "Running with scissors in the Matrix") along with self-play. During the training phase, the OPRE agent uses observations from other agents. But the scenario doesn't allow access to such information. Any possible way I could access that information in a clean manner rather than directly modifying the scenario creation code?

You should never need to add observations to a Scenario (unless you are deliberately "cheating" at the test to get an upper bound or some other measure of interest).
In particular, OPRE is designed to learn a behavior policy that is not conditioned on opponent observations. That way it doesn't need them at test time.
However, it does opponent observations at training-time to train the critic. We did this by training on a substrate wrapped with https://github.com/deepmind/meltingpot/blob/main/meltingpot/python/utils/scenarios/wrappers/all_observations_wrapper.py.

You should never need to add observations to a Scenario (unless you are deliberately "cheating" at the test to get an upper bound or some other measure of interest).

Completely agree with this. I just want to use the bot's observations to validate that the algorithm is actually able to learn to exploit fixed opponents. That basically could also be used as an upper bound.

In particular, OPRE is designed to learn a behavior policy that is not conditioned on opponent observations. That way it doesn't need them at test time.

I understand that.
OPRE in meltingpot paper is trained only using self-play.
However, in the original OPRE paper, the authors also train on specialised policies to test how effectively the agent learns to exploit fixed opponents (section 5.2 link). In that case, I believe the trainer does use observations from bots as well.
Also, I observe that even though the environment used in both meltingpot and OPRE is Running with scissors (there could be subtle implementation differences as I'm not sure if the original OPRE paper used some internal implementation of that environment or the same one that is open-sourced in meltingpot), the results are very different.

Hey Kinal,
Original OPRE used an earlier version of what we have released in Melting Pot, @jzleibo will have a better idea what, if anything, has changed.
Section 5.2 in the OPRE paper shows evaluation of OPRE variants vs pure strategy bots, which shouldn't require access to opponent observations for either OPRE or the bot.
We have added these evaluations to Melting Pot as Scenarios: running_with_scissors_2 (vs pure rock bot), running_with_scissors_3 (vs pure paper bot), running_with_scissors_4 (vs pure scissors bot). Averaging the results on those should allow you to reproduce Figure 4 of the OPRE paper.
J.

Hi John,
Thank you for these details.
It is mentioned that section 5.2 evaluates performance when trained directly against pure strategies (Pink highlight in the screenshot). And as OPRE uses other agents' observations to estimate $q(z|x'_t)$ during training time, I believe the observations from bots might be required.
Whereas section 5.3 evaluates agents trained using self-play against pure strategies.

Thank You
Kinal

Ah sorry, I should have read more carefully :-)
To train on Scenarios with wrappers you can add a substrate_transform after getting the config: https://github.com/deepmind/meltingpot/blob/e05c70464b1a0e1fb9b42859d623fcac3347f082/meltingpot/python/scenario.py#L79
Something like this should be what you need: https://github.com/deepmind/meltingpot/blob/e05c70464b1a0e1fb9b42859d623fcac3347f082/meltingpot/python/utils/scenarios/substrate_transforms.py#L53

I'll close this out but please reopen if it doesn't work.


README.md: Minor typographical and grammar fixes

These are some minor fixes to the README.md files submitted by Aidan
Earle<EMAIL_ADDRESS>Signed-off-by: David Brown<EMAIL_ADDRESS>

A new PR based on #449 by @AdnEarle


Improve container config validation errors

The Problem/Issue/Bug:
Container config validation errors can be a little confusing as, while a previous version may have (at one point) been "valid", the current version of ddev may no longer actually support it. Note: this came up when a project which worked on previous Macs (using MariaDB 10.0) would show this error because of the new Apple Silicon arm64 architecture; of which MariaDB does not include packages for this version.
How this PR Solves The Problem:
Changes the verbiage of "invalid" to "unsupported" and as specifies that it is ddev (and current architecture) that does not support the requested version.
Manual Testing Instructions:
Specify a version that isn't supported and check that the message matches the PR.
Automated Testing Overview:
Not sure if this is tested anywhere?
Related Issue Link(s):
Release/Deployment notes:
Doesn't affect anything, just a better error message.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Rebased.

Rebased.

LGTM

LGTM


Add a note about resolving promises in /reference/javascript/sync-async.html

Submit an issue
Description of the issue
Prevent your plugin from hanging!

This page talks about async/await. It even says "We recommend async/await syntax over Promises." Should we add a page about Promise?


fix(core): wire attribute value FQNs to encrypt

Merging past vuln check as it's unrelated to changes in this PR. Will handle in separate issue: https://github.com/opentdf/otdfctl/issues/371


Also not working for input type file

Not working for input type file

Please follow the issue template.


Add a sample app for testing the adapter

I've been wanting a way to test the adapter manually without needing anything running on Heroku or a real Judoscale API endpoint. Here's how this works:

sample/rails-sample is a minimal Rails app with the judoscale gem installed.
sample/proxy.js is a tiny proxy server that adds the X-Request-Start header to each request. We need this header for the adapter to calculate request queue time.
rails-sample/Procfile will run both the proxy server and the Rails app. rails-sample/bin/dev uses heroku local to run the Procfile.
rails-sample/config/initializers/judoscale.rb configures the adapter to use https://judoscale-adapter-mock.requestcatcher.com as api_base_url. Request Catcher is a free service that simply logs all requests sent to an API endpoint in a browser.
rails-sample/README contains instructions on how to use the sample app.

https://user-images.githubusercontent.com/372/154850766-95036715-c67c-4c14-bcb7-3f7db25ad0c0.mp4
@carlosantoniodasilva Curious for your thoughts on this. Most of the diff in this PR is boilerplate Rails stuff. It might be more helpful to review commits individually, or just ignore the boilerplate.
I think this is going to be useful, but I'm not 100% confident in the approach. Are you able to follow along? Can the README be improved to make it easier to use?
I didn't want to write a custom proxy server. This is something I want to re-use for other adapters, so ideally we won't be including this custom code in each adapter. I suppose we could publish the proxy server as an NPM module.
I tried to get NGINX working via Docker, but I don't know NGINX or Docker well enough to get it working. Do you have any other suggestions for this?

@carlosantoniodasilva Thanks for the feedback!
I'm marking this PR ready for your review.

I was able to get it working locally without much trouble, just needed to make sure I had the prerequisites installed. (in my case since I was using asdf I had to declare a .tool-versions with ruby & node, but that was about it)

I removed the Ruby version requirement from the Gemfile, so I'm hoping it'll now work with whatever Ruby you have installed.
I'm surprised you needed a .tool-versions file, though, especially for Node, since there's no explicit version requirement. 🤔 I also use asdf... do you have "global" versions set like this?
judoscale-ruby $ asdf current
crystal         ______          No version set. Run "asdf <global|shell|local> crystal <version>"
nodejs          16.1.0          /Users/adam/.tool-versions
ruby            3.0.1           /Users/adam/.tool-versions

If not, I suppose it makes sense that every project would need to have a local .tool-versions file.

Are you thinking that each adapter should have its own sample app, and that they could use this proxy with it?

Yes, that's the idea. So there will probably be multiple sample apps per repo. The judoscale-ruby repo, for example, will include adapters for judoscale-rails, judoscale-sidekiq, judoscale-resque, etc. I think each of these will need their own sample app because having multiple job processors in a single app can get messy.
This is why I put the rails-sample app nested within a sample directory. Now I'm wondering if I should change that to sample_apps (or sample-apps).
Do you have any thoughts on the naming here?

Initially I think I wouldn't bother much about NPM and just have this small bit shared (in the copy sense) with the adapters, unless you feel strong about having it being a single package they can use.

I went ahead and created a package for this. I think it'll make it easier to document the process for other adapters, and it'll enable me to update the script in one place if there are bugs.
It's pretty cool that npx lets you run executable NPM packages that aren't even installed on your machine. The only reference to this proxy server is now in the Procfile (and README).

As a side note, I was considering bundling a small Rails app with the tests for writing some tests, especially around booting up the reporter and maybe even sending a few hits, as a way of writing some more "integration tests", later.

Sounds like a really good idea!


Summernote react adaptation without bootstrap

Would it be possible to compile a version of summernote.js to use the lite version? The bootstrap dependencies clash with materialize.
As you can see summernote has a lite version without the bootstrap dependency.
https://summernote.org/getting-started/#without-bootstrap

Yes this would be great. Alternatively, is there a good way to scope the bootstrap CSS to just the component? Maybe I'm just dense but it seems incredibly difficult to figure this out.

Is there any update on this?


BulkCacheWritingException under load

Here's the cache config:
Configuration: heap_offheap_disk
Variation: [Cache level serializer variation: [Key serializer: null ,Value serializer: CacheValueSerializer], Eviction Veto Custom, Unordered Synchronous Listener, Cache level copier variation: [Key copier: LongCopier ,Value copier: CacheValueCopier]]

and the exception that I sometimes catch:
ERROR c.t.q.e.v.ValidatingPutAllOperation - Operation caught exception
org.ehcache.exceptions.BulkCacheWritingException: null
    at org.ehcache.core.EhcacheWithLoaderWriter.putAll(EhcacheWithLoaderWriter.java:566)
    at com.terracotta.qa.ehcache.validation.ValidatingPutAllOperation.exec(ValidatingPutAllOperation.java:67)
    ...

While the BulkCacheWritingException does contain the cause(s) of the problem, those are not reported in toString() nor in printStackTrace() which makes for a pretty poor readability of that exception.

Here is the sole nested exception of the BulkCacheWritingException:
java.lang.NullPointerException
	at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1124)
	at com.terracotta.qa.ehcache.configuration.CollectingCacheLoaderWriter.writeAll(CollectingCacheLoaderWriter.java:60)
	at org.ehcache.core.EhcacheWithLoaderWriter.cacheLoaderWriterWriteAllCall(EhcacheWithLoaderWriter.java:614)
	at org.ehcache.core.EhcacheWithLoaderWriter.access$400(EhcacheWithLoaderWriter.java:89)
	at org.ehcache.core.EhcacheWithLoaderWriter$6.apply(EhcacheWithLoaderWriter.java:535)
	at org.ehcache.core.EhcacheWithLoaderWriter$6.apply(EhcacheWithLoaderWriter.java:531)
	at org.ehcache.impl.internal.store.offheap.AbstractOffHeapStore$23.apply(AbstractOffHeapStore.java:831)
	at org.ehcache.impl.internal.store.offheap.AbstractOffHeapStore$21.apply(AbstractOffHeapStore.java:636)
	at org.ehcache.impl.internal.store.offheap.AbstractOffHeapStore$21.apply(AbstractOffHeapStore.java:623)
	at org.ehcache.impl.internal.store.disk.EhcachePersistentConcurrentOffHeapClockCache$1.apply(EhcachePersistentConcurrentOffHeapClockCache.java:162)
	at org.ehcache.impl.internal.store.disk.EhcachePersistentConcurrentOffHeapClockCache$1.apply(EhcachePersistentConcurrentOffHeapClockCache.java:158)
	at org.terracotta.offheapstore.OffHeapHashMap.computeWithMetadata(OffHeapHashMap.java:1889)
	at org.terracotta.offheapstore.AbstractLockedOffHeapHashMap.computeWithMetadata(AbstractLockedOffHeapHashMap.java:581)
	at org.terracotta.offheapstore.OffHeapHashMap.computeWithMetadata(OffHeapHashMap.java:1928)
	at org.terracotta.offheapstore.AbstractLockedOffHeapHashMap.computeWithMetadata(AbstractLockedOffHeapHashMap.java:581)
	at org.terracotta.offheapstore.concurrent.AbstractConcurrentOffHeapMap.computeWithMetadata(AbstractConcurrentOffHeapMap.java:728)
	at org.ehcache.impl.internal.store.disk.EhcachePersistentConcurrentOffHeapClockCache.compute(EhcachePersistentConcurrentOffHeapClockCache.java:158)
	at org.ehcache.impl.internal.store.offheap.AbstractOffHeapStore.compute(AbstractOffHeapStore.java:674)
	at org.ehcache.impl.internal.store.offheap.AbstractOffHeapStore.bulkCompute(AbstractOffHeapStore.java:842)
	at org.ehcache.impl.internal.store.offheap.AbstractOffHeapStore.bulkCompute(AbstractOffHeapStore.java:804)
	at org.ehcache.impl.internal.store.tiering.CacheStore.bulkCompute(CacheStore.java:289)
	at org.ehcache.core.EhcacheWithLoaderWriter.putAll(EhcacheWithLoaderWriter.java:562)
	at com.terracotta.qa.ehcache.validation.ValidatingPutAllOperation.exec(ValidatingPutAllOperation.java:70)
	at io.rainfall.execution.RunsDuring$1.call(RunsDuring.java:79)
	at io.rainfall.execution.RunsDuring$1.call(RunsDuring.java:71)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:745)

ConcurrentHashMap.java:1124 is throwing NPE after a null check on the value.
A short investigation of the code seems to indicate that the Store.bulkCompute() implementation slightly changed recently and that either the putAll compute function cannot cope with a legal null value because it never happened in the previous impl, or that null value is illegal and the offheap store's bulkCompute() implementation is buggy.
To be continued...

The root cause of this problem is that the recent compute method implementation rework in the OffHeapStore (and DiskStore) can call the compute method multiple times for the same key, while the Store.bulkCompute() contract explicitly states this is forbidden.
Based on the documented contract, EhcacheWithLoaderWriter.putAll() passes a stateful function to Store.bulkCompute() that expects that the function will never be called twice for the same key.
Knowing that preventing the OffHeapStore to call the function many times for a single key would at best seriously complicate its implementation, looking at what we currently do with Store.bulkCompute methods, and looking at the state of the latter methods I would recommend that we just plain gut them out of the Store API and replace their implementations with a simple loop in the Ehcache class instead.
Note that other OffHeapStore.compute calls should be safe as the function we pass always is (or should be?) memoized.


Updated social media click-thrus in footer

What does this pull request do? Explain your changes. (required)

Specific updates (required)

Update social media click-thrus in footer

Does this pull request close any open issues?

Fixes #Update social media click-thrus in footer

Screenshots (optional):

Checklist:

[ ] I have read the CONTRIBUTING document.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.

@FullStackTiger Clicked on the links and they work. Thanks!

Great! Thank you for making sure they open a new tab, too.


New version: Remeha.ServiceTool version <IP_ADDRESS>

- [X] Have you signed the Contributor License Agreement?

[X] Have you checked that there aren't other open pull requests for the same manifest update/change?

[X] Does your manifest conform to the 1.5 schema?

Resolves #136660

Microsoft Reviewers: Open in CodeFlow

/AzurePipelines run

Automatic Validation ended with:

2024-01-26T15:41:44.1980642Z ##[error] One or more errors occurred. (SQL error or missing database (0x87AF0001)) SQL error or missing database (0x87AF0001)

(Automated response - build 661.)


have template be the starting point for all posts

it needs all catagories, some editing instructions, etc

[ ] have this make clear that bold isn't good and neither is h1 in posts

maybe use github templates

@sssoz can you take a look at the template as is and make sure it looks good to you.


Update service details view for common and generic services.

This PR updates the service details page per UXD design at:
https://github.com/ManageIQ/manageiq-design/blob/master/UX/ui-service/MyServices/design.md
This includes the Service Details -Summary View for Legacy Services, the Ansible view in NYI. Only the Compute resources are listed, the network and storage resources are not yet available.

Finishes #133840615
@chriskacerguis @beanh66 @serenamarie125
@miq-bot add_label enhancement
@miq-bot add-label euwe/no
@miq-bot add-label ux

@jeff-phillips-18 can you please address the Code Climate issues?

@jeff-phillips-18 also, can you please include some tests for this (unit and integration)?

@jeff-phillips-18 could you please provide an update here?
/cc @serenamarie125

@chriskacerguis Working on unit tests (bitten by angular-router code interference) and code climate issues (some code is difficult to make different or create utilities for). Also running into rebase issues with refactoring change from PR #450

@chriskacerguis All issues fixed, unit tests added.


Support ES6 style tests without transpiler usage

Prerequisites

[x] Checked that your issue isn't already filed by cross referencing issues with the common mistake label
[x] Checked next-gen ES issues and syntax problems by using the same environment and/or transpiler configuration without Mocha to ensure it isn't just a feature that actually isn't supported in the environment in question or a bug in your code.
[x] 'Smoke tested' the code to be tested by running it outside the real test suite to get a better sense of whether the problem is in the code under test, your usage of Mocha, or Mocha itself
[x] Ensured that there is no discrepancy between the locally and globally installed versions of Mocha. You can find them with:
node node_modules/.bin/mocha --version(Local) and mocha --version(Global). We recommend avoiding the use of globally installed Mocha.

Description
Before I start, there are already some closed issues regarding this topic but as the prerequisites have changed I would like to start a new attempt.
Now that node supports running EMCAScript modules (yes, I know it is experimental) it would be great to see mocha to work in conjunction with mjs test definitions.
Steps to Reproduce
I have a very simple test
describe('Test', function () {
});

Which i have saved as test.js and test.mjs
Expected behavior: I would like both tests to show
- test/test.js
  0 passing (1ms)
(node:70422) ExperimentalWarning: The ESM module loader is experimental.

Actual behavior: While the js test works, the mjs test gives me
- test/test.mjs
module.js:658
    throw new errors.Error('ERR_REQUIRE_ESM', filename);
    ^

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /Users/dgehl/Repositories/LOreal/code/ecom-lora/test/frontend/components/global/test.mjs

Reproduces how often: 100%
Versions
 node --version - v8.5.0
mocha --version - 3.5.3
Additional Information
I think that this might be that mocha's runner is using commonjs and nodejs' current implementation disallows to use ECMAScript modules from a commonjs context.
Please don't reply with "use a transpiler", I want to explicitly not use one.
Edit: in an earlier version I accidentally used jsx instead of mjs.

Initial thoughts off the top of my head, before doing any further research:

I seem to recall the Node people specifically got the standard changed to allow backwards compatibility with CommonJS modules. If that's (still?) true, then I'd expect that eventually it would be supported without needing to do anything with/to Mocha. (And by "eventually" I mean "possibly even faster than Mocha changes", given the rate of Node's release cycle; see the emphasized, penultimate below for a more detailed explanation of this.)
Can I assume that this was run like node --experimental-modules node_modules/mocha/bin/_mocha?
How exactly is .jsx involved? I see that the error example shown refers to .mjs; it's unclear, from what has been posted, where the jsx is.
I also vaguely recall hearing of Node's initial implementation requiring the .mjs file extension; if that's (still?) true, and if you're trying to use import/export with a .jsx file (either importing a .jsx file in  .mjs file or loading a .jsx file that contains import/export), could that be the issue rather than Mocha?
We would need to come up with a way to ensure that changes to the experimental feature don't require changes to Mocha that would have to wait for a semver major -- otherwise you could end up right back where we are now except waiting even longer (since Mocha's major release cycle is not locked to twice a year like Node's).
Speaking purely from my own opinion and not on behalf of the team, if the new module format cannot interoperate with the old module format without modification to existing libraries written in the old format, then the new module format is not ready yet.

I seem to recall the Node people specifically got the standard changed to allow backwards compatibility with CommonJS modules. If that's (still?) true, then I'd expect that eventually it would be supported without needing to do anything with/to Mocha. (And by "eventually" I mean "possibly even faster than Mocha changes", given the rate of Node's release cycle; see the emphasized, penultimate below for a more detailed explanation of this.)

From my (little) research it seems that at least for now it is allowed to use require from a ECMAScript module but not import from a commonjs module.

Can I assume that this was run like node --experimental-modules node_modules/mocha/bin/_mocha?
How exactly is .jsx involved? I see that the error example shown refers to .mjs; it's unclear, from what has been posted, where the jsx is.

Yes, it was run with --experimental-modules. jsx is a typo, I meant mjs, will update the initial post.

I also vaguely recall hearing of Node's initial implementation requiring the .mjs file extension; if that's (still?) true, and if you're trying to use import/export with a .jsx file (either importing a .jsx file in .mjs file or loading a .jsx file that contains import/export), could that be the issue rather than Mocha?

The issue seems to be, and I might be missing something here, that mocha uses require to load the test (that's at least my current assumption as I'm not a mocha expert, more of a user) which then includes other modules via import. This in conjunction with the first point would explain the error.

We would need to come up with a way to ensure that changes to the experimental feature don't require changes to Mocha that would have to wait for a semver major -- otherwise you could end up right back where we are now except waiting even longer (since Mocha's major release cycle is not locked to twice a year like Node's).
Speaking purely from my own opinion and not on behalf of the team, if the new module format cannot interoperate with the old module format without modification to existing libraries written in the old format, then the new module format is not ready yet.

I was afraid that this would be the answer and I understand that this is not a top priority. If my assumption of the cause of the error above is correct, soemthing like #956 could help as the entry point of the test could be a mjs module rather than commonjs which is probably hard to achieve otherwise. It seems to be on the roadmap of the nodejs team to support import from current modules, not clear about timelines however.

From my (little) research it seems that at least for now it is allowed to use  require  from a ECMAScript module but not  import  from a commonjs module.

It seems to be on the roadmap of the nodejs team to support  import  from current modules, not clear about timelines however.

To clarify: given that in "older" (in some cases current non-experimental) environments import is a syntax error, which can't be avoided with branching logic or anything like that, what Mocha needs isn't to be able to use import itself but rather to be able to use require to load modules that use (or that use modules that use) the new format.

jsx  is a typo, I meant  mjs , will update the initial post.

Thanks, that eliminates one possible angle!

If my assumption of the cause of the error above is correct, soemthing like #956 could help as the entry point of the test could be a  mjs  module rather than commonjs which is probably hard to achieve otherwise.

Making Mocha not create global variables is unfortunately not possible without extensive rewriting of some of the more arcane internals (I tried and couldn't figure it out myself 😿 ); however, using your own JS entry point is possible now through the "programmatic" API (which might not be documented outside of an old wiki page and the JSDoc comments in the source files, but is officially supported):
// test.mjs
var Mocha = require('mocha'),
var mocha = new Mocha();

// your mission: create a file `example.mjs`
// in the `test` folder and have it `import` stuff
// as well as using `describe` and `it` to make tests
mocha.addFile("./test/example.mjs");

mocha.run(function(failures){
  process.on('exit', function () {
    process.exit(failures ? 1 : 0);
  });
});

node --experimental-modules test.mjs

I haven't actually tried that to see if it makes a difference (need to grab the latest version of Node first), but let me know if it works for you...

First of all thank you for your support on this!
I tried this
// runner.mjs
import Mocha from 'mocha';
var mocha = new Mocha();

// your mission: create a file `example.mjs`
// in the `test` folder and have it `import` stuff
// as well as using `describe` and `it` to make tests
mocha.addFile('./test/frontend/components/global/test.mjs');

mocha.run(function (failures) {
    process.on('exit', function () {
        process.exit(failures ? 1 : 0);
    });
});

So basically made the node entry point a ECMAScript module.
I run it via node --experimental-modules --harmony ./runner.mjs
I get
(node:88620) ExperimentalWarning: The ESM module loader is experimental.
{ Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /.../test/frontend/components/global/test.mjs
    at Object.Module._extensions..mjs (module.js:658:11)
    at Module.load (module.js:545:32)
    at tryModuleLoad (module.js:508:12)
    at Function.Module._load (module.js:500:3)

what Mocha needs isn't to be able to use import itself but rather to be able to use require to load modules that use (or that use modules that use) the new format.

That I'm afraid is currently not possible in node, you can only use require in modules you imported via import. Is there a way to avoid mocha.addFile('./test/frontend/components/global/test.mjs'); and instead import the test and add the imported script like this
import test from './test';
mocha.addTest(test);

?

There's no function like that in Mocha at the moment, but you can do something along those lines. addFile just appends the file to a list that is later required by the run function. The run function calls loadFiles to require them:
https://github.com/mochajs/mocha/blob/1cc0fc0e6153bbd746b0c2da565363570432cdf7/lib/mocha.js#L220-L235
What you'd want to do is for any files that need to be imported instead of required don't call addFile (so Mocha won't try to require it on run) and instead before calling run call some code that's like what's in loadFiles but using import instead of require. I don't recall off the top of my head whether there are any restrictions on use of import that would prevent this, but if it's possible at all then I imagine it would look pretty close to:
modules.forEach(function (file) {
  file = path.resolve(file);
  mocha.suite.emit('pre-require', global, file, mocha);
  import fileExport from file; // fileExport is used by the exports interface, not sure if anything else; most interfaces act as a side effect of running the file
  mocha.suite.emit('require', fileExport, file, mocha);
  mocha.suite.emit('post-require', global, file, mocha);
});

You can also look at how https://github.com/mochajs/mocha/blob/master/bin/_mocha uses Mocha's programmatic API to get a sense of how to supply other options and how to use things like Mocha's file lookup functionality. It's not very well organized but everything the commandline interface does is in there (either directly or because in there is a call to the functions in Mocha's programmatic API).

I can come one step further but the imported test now complains it does not know about describe (ReferenceError: describe is not defined). What is the proper way to inject it? If I do
import Mocha from 'mocha';
const describe = Mocha.describe;

it complains TypeError: describe is not a function

So, my distro finally got NodeJS 8.5, and I've had a chance to play with this and confirm a couple of hunches I had but didn't want to state till I'd been able to check:

I can't find any way to load an ES module without hardcoding its name in a script/module file. That means that Mocha can't load them through the commandline interface no matter what we do and regardless of any other ES vs. CommonJS semantics. If and when that changes, we'll want to know, I guess. (If it changes such that the ES module can be loaded through a variable require we probably won't need to change anything, but I don't think we can say anything about how modules work for sure until it happens.)
Whereas Mocha sets up the interface in the pre-require event emission (not when the module is first loaded; the chosen interface is specific to the new Mocha instance), the new module system actually parses the dependency tree and loads dependencies before the modules that depend upon them, so the reason describe is not defined is that Mocha isn't setting it up until after the test modules are loaded. That means that it's going to be convoluted to get this to happen at all (again, unless and until require(file) is allowed and loads the dependency at that specific line, preferably synchronously so we don't have to change anything else).

However, I did discover I can make it work by exploiting the fact that imported modules are loaded in the order of the import calls. (It would get a whole lot more redundant if you use the Exports interface or a reporter that needs the name of each individual file, as described in the code I'm about to link, but in principle it works.) If that fact were to change without any of the other above facts changing, then even this would not be possible at all. But for now I think this is what you'd have to do.
https://gist.github.com/anonymous/caba0883254a2349c5615df8e9286665
node --experimental-modules ./run.mjs

Unfortunately, I'm fairly sure that's the best we can do given the way ES modules work and what Node allows at the present time.

Think of it another way:

import is syntax.
require is a function.

You cannot dynamically import anything, just as you cannot dynamically run code without the use of, for example, eval().
There is this stage 3 proposal which would allow this behavior, but I'm not sure if any runtimes are shipping it yet.
As such, there's no way for Mocha to import an .mjs file when running via mocha without adding perhaps @std/esm and using its require implementation for files with the .mjs extension.  That may be a viable solution and something we could consider supporting, but a discussion (and such a PR) would likely need to come from the community, at least until this behavior isn't behind a flag.
import describe from 'mocha' is pretty low on the priority list, unfortunately, due to the inherent difficulty around this sort of thing (#956).  Best to run with node and stick to consuming the globals.

Actually, it occurs to me that we could load the tests and leverage vm.runInContext, assuming such a thing supports modules.  Because Node's loading behavior is tied to the .mjs extension, and vm.runInContext expects a string, don't see how it could--and there's nothing mentioned about this in the docs.  Maybe an issue somewhere?

(then again, this may be exactly what @std/esm does under the hood!)

I've got mocha tests working without transpiler in a browser. Maybe it helps for this issue.

that’s unrelated as you’re not pulling mocha in as a module, but rather a script...

sorry confused myself. it’s different in a browser.

I want to weigh in with a vote of support for doing something to allow Mocha to run tests located in an ES Module.  I landed here after trying to write such a test and getting a weirdo error from the Node.js module loader.  I'm using Node.js 9.5, which natively supports ES6 modules.
As it currently stands, Node.js 9.5 does not allow a CommonJS module to require() an ES6 module.  Maybe they're working in the direction of allowing that, I don't know.
I wrote the test as a ES6 module with the .mjs extension and tried to run it.  Got the error from the loader -- I assume the mocha command results in using require() and that's why it failed.
Redid the test with the .js extension and tried to use require() to load the module that was to be tested.  That also got the error from the loader.
I'm of the opinion that the Node.js world needs to consider how they'll move to and support ES6 modules.  Since Mocha is a very popular tool in this world, it would be best for the Mocha team to consider how to support ES6 modules.

To follow up ... After some pondering and searching I was able to get this sequence to work as a workaround.
Name the test script with .js extension (it's a CommonJS script)
Then add this in the test script:
require = require("@std/esm")(module,{"esm":"js"});

Then I can require() an ES module as so:
const model = require('../models/notes');

@robogeek Or it might be even better to use the @std/esm preloader from commandline, so you don't have to clutter your spec files with workarounds, and can have .mjs extensions.
mocha -r @std/esm spec.mjs

Dynamic import ships with node v9.6 behind the --harmony-dynamic-import flag. Dynamic imports allow mocha to load tests contained in es6 modules without needing a transpiler.

@harrysarson It is not going to work out of the box. Mocha uses cjs modules and require, you would have to write the test files using cjs, with some additional glue code to handle the async nature of import. Or am I missing something?

The issue is still relevant but relies on native support for ESM. Browsers have it, Node not yet.

I was just playing around, getting familiar with ESM/.mjs and decided I needed tests for my toy. Realizing mocha is not yet officially supporting .mjs files, I through together a quick interim module (until someone has time to add full support to mocha):
https://www.npmjs.com/package/mocha-esm
PRs/Issues welcome:  https://github.com/stefanpenner/mocha-esm

I decided to fork mocha itself to support dynamic imports (based on some ideas above, but I couldn't get it to run in any other way).
This means you can run using e.g. node --experimental-modules --harmony-dynamic-import test.mjs
Then in test.mjs:
import 'should';
import Mocha from 'mocha';

const mocha = new Mocha();

mocha.addFile(() => import("./some-module.spec.mjs"));

mocha.run(failures => {
  process.on('exit', function () {
    process.exit(failures ? 1 : 0);
  });
});

I kept the changes in mocha to support this minimal, and I didn't have time to integrate this properly for a potential PR nor did I add a specialized npm module, but you can install this fork from github directly "mocha"<EMAIL_ADDRESS>Note you can use this approach to load files in any async way you might want, not only via dynamic import, as mocha is expecting a function that provides a Promise.

@odolha
Thanks for the PR.
There already was a PR to support native ESM but it was closed because module support is still experimental.
Your implementation comforts me that adding support for this should be easy. We're many to wait eagerly for this feature :)

@demurgos :no_mouth: yeah... I just saw that PR after I did my own thing, d'oh 😃.

@harrysarson @boneskull
The esm package (formerly named @std/esm) dropped support .mjs files in this commit.
It means that it is no longer possible to use it with Mocha to test .mjs files. This is discussed in this issue.
I still want to be able to test ES modules so I can safely run them in Node or browsers.
Regarding the current module discussions, there is consensus that .mjs should be available in the final result (maybe not as the only solution, but at least available) and that import("./foo.mjs") will return a promise for the corresponding ES namespace. The fact that CJS modules are converted to a module with a default export corresponding to module.exports is more debated, but it seems to be a safe assumptions.
Would it be possible to reconsider adding native ES support using dynamic import to Mocha? The feature flag could be renamed to --experimental-es-modules (from #3253) to better signal that this is dependent on the current advancement of Node's support.
According to the deadlines, the final spec wouldn't land until Node 12 so the current implementation will remain there for some time (and is a relatively safe subset of the final proposal).

@demurgos I personally prefer to wait on this a little more before committing to any code implementations on mocha. But maybe @boneskull or @ScottFreeCode disagree?

@demurgos

The esm package (formerly named @std/esm) dropped support .mjs files in this commit.

The esm loader did not drop support for .mjs. We simply follow the current --experimental-node implementation and throw an error when attempting to load .mjs with require. Users can still use a .js file for their test entry file that use ESM syntax or dynamic import to load subsequent test files of .mjs or .js much like esm does for its own tests.

According to the deadlines, the final spec wouldn't land until Node 12 so the current implementation will remain there for some time

There is no set time for --experimental-modules to land unflagged. There is a hope that it can land sometime in Node 10's support cycle (so some time in the next 2 years) but there's nothing set in stone.

(and is a relatively safe subset of the final proposal).

The current --experimental-modules implementation may not be compatible with the final proposal. There are several discussions around what ESM support in Node will look like. Some proposed directions are not compatible with the current experimental implementation. Depending on how things shake out the code your write today for --experimental-modules may not work with whatever the final form is.

The esm loader did not drop support for .mjs.

My point is that esm no longer enables requiring .mjs so you no longer can use Mocha's test discovery for .mjs. But you're right, it wasn't documented so it's not really a breaking change even if other people relied on it.
Regarding the deadlines, I was referring to this issue. There seem to be an attempt for Node 11 and a final implementation for Node 12 so it can be ported to Node 10 LTS. Some wish it would happen sooner, other warned to not rush it.
My proposition is to merge #3253. This only offers an opt-in mechanism to use import(...) instead of require to load the test cases. Since I expect it to mostly be applied for .mjs in the context of --experimental-modules, I still think that it's safe. (dynamic import of .mjs returning a namespace promise is likely to remain). But I'll leave you decide if you can merge it and avoid pushing too much for it.
Again, the main reason for this PR is that without it, you no longer can use Mocha's test discovery but have to use the workaround described above by @jdalton. (.js entry point and manual imports)

My proposition is to merge #3253.

#3253 had a fair few flaws is definitely not a good idea to merge it as is.

@demurgos this is a nice little workarround you have found :+1:.
It is good to see that it is possible (if not easy) to use es modules with mocha :smile:.

@demurgos This issue is about supporting ES6 style tests without transpiler usage. What is "build time"?

This issue is still valid and should not be closed.
The upcoming mocha@6 release will have the whitelisted --experimental-modules flag allowing to experiment with ES6 modules more easily. Would it be possible to have a minor or patch release before the v6? I am currently finalizing a new coverage tool that does use the V8 debugger instead of Istanbul and would like to test it with Mocha and ES6 modules (without having to use a git dependency in my package.json).

@demurgos
When I try like this...
const {sync: globSync} = require("glob");
(async () => {
    const matches = globSync("**/*.spec.mjs");
    for (const match of matches) {
        await import(match);
    }
    run();
})();

I get
(node:4632) UnhandledPromiseRejectionWarning: Error: Cannot find module test/Sanity.spec.mjs
But when I run like this...
const {sync: globSync} = require("glob");
(async () => {
    await import("./Sanity.spec.mjs");
    run();
})();

It runs perfect what am I missing?

@demurgos you should coordinate with @bcoe; see https://github.com/bcoe/c8

@demurgos to cut a minor release, we'd need to cherry pick all non-breaking changes since v5.2.0 into a branch and compile them into the CHANGELOG.  if you or someone else is willing to do that work, then we can cut the release.

fwiw I recommend esm over --experimental-modules until Node.js has its story straight.  that will be a considerable wait.

@boneskull
Haha, thanks. I'm already working around c8 since July (I opened a bunch of PRs and issues on this repo). There are also some design decision where we disagree so we try to share most of the dependencies (I wrote the merge algorithm for example) and decided that I'll publish another tool: c88. I got it to work this week-end and I'm now testing it on my libraries. I'm able to use with native ESM and mocha in CI. I still need some time to document and fix it but it should be ready in January).
@jrgleason
I wrote the code above of the top of my head. It seems that the issue here is that globSync returns relative paths that do not start with ./ or ../. You may want to prepend it with ./: it should work with any relative path.
You should also note that dynamic imports use relative URLs: #, ? and other special characters may be handled differently. If you want a rock solid solution, you should resolve the absolute path of the module and then convert it to a file URL. As part of my work on coverage, I wrote a lib to convert between absolute paths and URLs: you may want to use fromSysPath from furi. Conversions should handle any kind of path (even the Windows namespaces and UNC paths...).
Here is what a complete example may look like:
const {fromSysPath} = require("furi");
const {sync: globSync} = require("glob");
const {resolve} = require("path");

(async () => {
    const matches = globSync("**/*.spec.mjs");
    for (const match of matches) {
        await import(fromSysPath(resolve(match)).href);
    }
    run();
})();

@demurgos to cut a minor release, we'd need to cherry pick all non-breaking changes since v5.2.0 into a branch and compile them into the CHANGELOG. if you or someone else is willing to do that work, then we can cut the release.

Thanks for the proposition. It's still possible to get --experimental-modules with NODE_OPTIONS so it's not a high priority (and it may complicate the git tree to cherry-pick commits). If I manage to handle other dependency, I'll see if I can spend some time on this. In the mean time, I just keep an eye on the v6 milestone.

fwiw I recommend esm over --experimental-modules until Node.js has its story straight. that will be a considerable wait.
I mean, doesn't mocha --require esm just work? Do we really need automatic detection? That sounds difficult and adds overhead...

I definitely agree that it is the best solution right now: it's the easiest solution to set up and has been out for some time: it works. In my case, I am maintaining my own build tools and handle native ESM as an alternative to classic CJS builds. Despite being really eager for native ESM, I still recommend to not use it as the only way to run your code: it's experimental after all :stuck_out_tongue:.
Most of my recent messages are about sharing what can be done using native ESM. This is mostly experimental work and I expect to have to change it when Node's ESM gets stable. Long term there are benefits to have a solution that does not require the esm package. Here are my reasons:

It reduces the amount of tools needed (lower complexity, less configuration to understand)
There may be a few differences between real ESM and esm around edge cases (evaluation errors, cycles, load errors, async/dynamic modules, etc.). When writing isomorphic code, it may be safe to reduce any possible source of behavior divergence. This is also kinda related to native coverage: with esm, V8 sees the transpiled output so you have to deal with source maps (not yet supported by c8, but I'm preparing a PR, they work on c88). Other differences may also appear when debugging.
It avoids to have to dynamically transpile the code and helps improving performance.

@demurgos I think I was a bit confused about what people wanted here.  Anyway...
If NODE_OPTIONS=--experimental-modules works until --experimental-modules is supported in Mocha v6.0.0, then is there any other work to be done for this issue?  That's what I'm missing.

Node 12 should include the new ESM implementation. It will be the occasion to check how to support ES modules in Mocha.

I hit a segfault when using Mocha and ESM with Node 12. I am not sure if it is a Mocha or Node issue, for the moment I reported it to the Node tracker: https://github.com/nodejs/node/issues/27492. The segfault seems to depend on the number of tests defined but I don't encounter it when running my tests with commonjs. It may either be a Node bug or a Mocha bug with --delay.
Beside this bug, the strategy described in my comment above still works to use Mocha with ESM.

Hi Mocha people, thank you for creating and maintaining nice tool!
This is just FYI comment.  For the last few months I have been working on Mocha and * -test.mjs , using the patches like below. There is almost no problem to run mocha test/*.mjs (without transpiler or esm npm module).
https://gist.github.com/tadd/756d21bad38933c179f10e59bddee6b4
Of course this patch is not "production-ready" for Mocha committers; this is just a hack for Mocha users who want to use ESM in test codes as soon as possible.
I've been used Node.js v11 with --experimental-modules option. Currently I'm with v12 and also works.
It is another story, but Node v12 introduced .cjs extension and "type" field in package.json. It seems that these also need to be considered.

Hi Mocha people, thank you for creating and maintaining nice tool!

Indeed, and I also would like to give thanks 😄
I took a different approach to make loadFiles stay synchronous, see below. It has worked for me since February. Unlike some other hacks, this still allows all flags, inspect/devtools and accurate code coverage using c8. That last feature is why I really need native ESM, because the esm package have different offsets for each file. (The module's exports get listed and confusing istanbul).
https://gist.github.com/maxnordlund/a860dd67013beaf0f31ce776536f0a47

Hello! This is also needed to test any code which depends on native ES6 project, e.g. lit-element. Otherwise, it throws like this:
node_modules/lit-element/lit-element.js:14
import { TemplateResult } from 'lit-html';
       ^

SyntaxError: Unexpected token {
    at Module._compile (internal/modules/cjs/loader.js:703:23)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:770:10)
    at Module.load (internal/modules/cjs/loader.js:628:32)
    at Function.Module._load (internal/modules/cjs/loader.js:555:12)
    at Module.require (internal/modules/cjs/loader.js:666:19)
    at require (internal/modules/cjs/helpers.js:16:16)
    ...

I don't know if there's a workaround for this, but currently I don't think there's a way to use Mocha with ES6 native framework.

@heruan I posted a solution working since Node 8 in the comments above. Here is an updated solution that requires Node 10.12 for native file URL conversions:
Add the following test.esm.js file:
const {pathToFileURL} = require("url");
const {sync: globSync} = require("glob");
const {resolve} = require("path");

(async () => {
    const matches = globSync("**/*.spec.mjs"); // Update to match your test files
    for (const match of matches) {
        await import(pathToFileURL(resolve(match)).href);
    }
    run();
})();

Then run the tests with mocha --experimental-modules --delay test.esm.js.
Node 12 has a reported issue where the IIAFE is collected by GC (nodejs/node#27492), it should be fixed in one of the minor versions (there may be some workarounds but I haven't looked into them yet). I recommend to use the latest Node 10 version until it is fixed.

Thar will trigger an UnhandledPromiseRejectionWarning warning if there's any error. Better to chain a console.error or otherwise handle the error.
import glob from "glob"
import { pathToFileURL } from "url"
import { resolve } from "path"
import { promisify } from "util"

const globAsync = promisify(glob)

async function main() {
  const matches = await glob("test/**/*.mjs")

  for (const match of matches) {
    await import(pathToFileURL(resolve(match)).href)
  }

  run()
}

main().catch(console.error)

@demurgos Thanks for the code snippet for Node 10.12 you posted ten days ago!
I am running Node 12.1 and it seems to work fine. Will this soon be added to Mocha, or is there an even easier way to do this with Node 12?
https://github.com/standard-things/esm seems to work out of the box with --require esm, but it would be great to ditch another dependency :) Thanks.

If Mocha were to switch to ESM in source, Rollup could provide an ESM distribution file as well as a CommonJS and/or UMD ones.
Another advantage here is that browser HTML wouldn't need to be polluted with extra script tags to pull in Mocha. The test files (or main test entrance file) could do the importing.

One can use CSS plugins for Rollup as well to allow injecting mocha.css, further minimizing need for HTML clutter.

I think this is still relevant.

Was anybody able to run Mocha with ES6 Mosukles on Travis-CI?
Locally it seems, I set it up successfully:
mocha-run.js
(async () => {
    await import("./tests.js");
    run();
})();

Then mocha --experimental-modules --delay ./mocha-run.js works like charm.
But for some unknown reason, on Travis (with same Node and Mocha version), it behaves as if there would be no --delay param:
>  mocha --experimental-modules --delay ./mocha-run.js

(node:6439) ExperimentalWarning: The ESM module loader is experimental.

internal/modules/cjs/loader.js:1007

      internalBinding('errors').triggerUncaughtException(

                                ^

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /home/travis/build/Palindrom/Palindrom/mocha-run.js

@tomalec I am running mocha with ES modules on node 12.11.1:
mocha-run.js
(async () => {
    await import("./tests.mjs");
    run();
})();

@vanslly  Lucky you ;)
For me with Node 12.12.0 (https://travis-ci.org/Palindrom/Palindrom/builds/597771311#L450) and mocha-run.js as you suggested above (https://github.com/Palindrom/Palindrom/commit/49835962bdd61c849f115e271bbc6c3f82d30511#diff-24eabf03aee8844b2b4747aa95a6af7d),
mocha --experimental-modules --delay test/mocha-run.js https://travis-ci.org/Palindrom/Palindrom/builds/597771311#L643, , throws still the same error

That this is still an issue is crazy! ESM is no longer hidden away behind --experimental-modules. This is the future.

err, actually it was just announced a couple days ago...

Too late—we've all switched to Jest.

Hey guys, just want to make sure this is kept alive. Please make this a top priority and thanks for all the great work!

@luijar This is being worked on at #4038

We published yesterday an experimental release v7.0.0-esm1: see release notes.

This is great to see!
Can I ask though--does the lack of reference to the browser mean that ESM usage is not available on the browser or merely that you haven't needed to specify browser versions as with Node. I think it might help to mention in the release notes the status for browsers (and if not supported, what the plans might be for its support).

@brettz9
NodeJs ESM does not affect Mocha browser in any way. The tests you run in your browser are not loaded by NodeJs, you have to do that yourself in your HTML code.
If I remember well, you have to set the <script> tag to type="module" attribute. For both your test files and for the Mocha script, in order to keep the loading sequence. ESM should have been working with the browser for years.

@juergba : yes, sure, but one needs an ESM export so one can use import mocha from './node_modules/mocha/mocha-esm.js'; without compilation--and if using compilation, one would want module in package.json so the bundlers can discover.

mocha is written in commonjs; we cannot put a “module” field in package.json. Mocha will support running tests in node written in ESM.

If you didn't want to refactor to use ESM internally, you should still be able to use Rollup with its CommonJS plugin and indicate the ESM target file in order to support module (such as Sinon offers and most packages of note I have encountered, jQuery being the only other notable exception and they have been refactoring to use ESM).

I’ve created a sample project to test mocha with ESM. I can successfully run the tests, but wasn’t (yet) able to run coverage with nyc/istanbul. Your help will be welcome.

@concatime Until nyc is made compatible, you can use c8: https://www.npmjs.com/package/c8
c8 --all --include=lib/**/*.js --reporter=lcovonly node_modules/.bin/mocha --recursive

@cedx I’ve updated my template repo., and it works. Neat!

We implemented Node's native ESM support in Mocha v7.1.0.


Azure-Core: If no timezone information is present in string, assume local time and convert to UTC

This PR proposes a fix for #5075. There might be side-effects, though. Feedback welcome.
Pull Request Checklist
Please leverage this checklist as a reminder to address commonly occurring feedback when submitting a pull request to make sure your PR can be reviewed quickly:
See the detailed list in the contributing guide.

[x] C++ Guidelines
[ ] Doxygen docs
[ ] Unit tests
[x] No unwanted commits/changes
[x] Descriptive title/description

[x] PR is single purpose
[x] Related issue listed

[x] Comments in source
[x] No typos
[ ] Update changelog
[ ] Not work-in-progress
[ ] External references or docs updated
[x] Self review of PR done
[ ] Any breaking changes?

One minor note: RFC 3339 requires a timezone element.
Our parser appears to allow RFC 3339 elements without a timezone element, but it is a non-standard extension. We certainly should never generate such a time.

One minor note: RFC 3339 requires a timezone element.
Our parser appears to allow RFC 3339 elements without a timezone element, but it is a non-standard extension. We certainly should never generate such a time.

It could probably also be fixed in az cli by creating a string complying with RFC 3339

Thank you, @janbernloehr - these are great links and the context, I even left one possible idea in the first one.
But I don't think this SDK will be able to enjoy that feature they may add in the future version, because our customer may have the old version of Azure CLI extended, and for that, we will need to not be using any new command line switches added in the older versions, and instead we would need to be treating an RFC3339 timestamp without Z or +NNNN in the end as local time, but only when parsing the token expiration from  az account get-access-token output, and not in any other scope.

Hi @janbernloehr, @antkmsft, I am the owner of Azure CLI command az account get-access-token. Returning expiresOn as a local datetime is only a legacy from the ADAL age. We would not make any change on that field.
az account get-access-token will start returning expires_on as a POSIX timestamp since the next release, and we would highly recommend using that new field as it is timezone-irrelevant and consistent across various tools and services - MSAL, Azure SDKs, Managed Identity.

Thank you @jiasli - the Azure SDK for C++'s current implementation would successfully be able to parse Unix timestamp (https://github.com/Azure/azure-sdk-for-cpp/blob/50c18516df110058e1faac27b38360bc56db7c6e/sdk/identity/azure-identity/src/token_credential_impl.cpp#L292-L327), should it replace the RFC3339 string, no code change is needed.
AzureSDK for .NET would break - https://github.com/Azure/azure-sdk-for-net/blob/ba1e6df24131bfc88619c12c4c592933f78fcd18/sdk/identity/Azure.Identity/src/Credentials/AzureCliCredential.cs#L236, we should communicate this to them. Possibly, some other SDKs may get broken by this change as well.
cc @ahsonkhan @schaabs @scottaddie @azure-sdk-write-identity

@jiasli Which version number will contain this new expires_on field?

@jiasli Which version number will contain this new expires_on field?

@scottaddie, I have updated my comment https://github.com/Azure/azure-sdk-for-cpp/pull/5076#issuecomment-1784680918 to include that information.

@antkmsft, I provided more information in https://github.com/Azure/azure-cli/pull/27476. We are not going to make any change on expiresOn, so it won't breaking any existing SDKs.

#5179 would treat datetimes it gets from azcli as local time, if no time zone information is present.

Fixed in #5179


not working with exchange tried to add exchange account and got error

not working with exchange tried to add exchange account and got error

This issue tracker is only for tracking bugs and feature requests. For support issues please check the "Need help?" section of the README: https://github.com/k9mail/k-9#need-help


Does Keras based models work?

Hi, Is it safe to assume both tensorflow and keras based models are supported?

Sorry that we only support the tensorflow and tensorflow-lite models.


Simple guide to run Data Prepper with Logstash config

Signed-off-by: Shivani Shukla<EMAIL_ADDRESS>Description

Simple guide to run Data Prepper with Logstash config using Docker
Link to the doc in the Getting Startedguide

Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[x] Commits are signed per the DCO using --signoff

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

Codecov Report

Merging #616 (1d85d26) into main (2d64ee5) will decrease coverage by 0.04%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##               main     #616      +/-   ##
============================================
- Coverage     91.74%   91.70%   -0.05%
  Complexity      571      571
============================================
  Files            72       72
  Lines          1744     1747       +3
  Branches        144      145       +1
============================================
+ Hits           1600     1602       +2
  Misses          113      113
- Partials         31       32       +1

Impacted Files
Coverage Δ

...dataprepper/pipeline/server/DataPrepperServer.java
90.16% <0.00%> (-1.22%)
:arrow_down:

Continue to review full report at Codecov.

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

I believe this document should include some discussion of the limitations of the Data Prepper support for Logstash configurations. For example, which plugins it can convert, that conditionals are not support, and any others.


Add slackmojis extension

Description
Simple extension which allows to search for gifs from slackmojis.com. Users can copy the gif to clipboard or download it and upload to their Slack afterwards.
Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

@pernielsentikaer thanks for the review, I implemented your suggestions, feel free to take a look

Thanks for the fixes 🔥


Unable to get Authentication for username and pass.

Unable to get Authentication for username and password

Hi, as mentioned in the readme of this repo, this project isn't anymore supported in favor of IGopher his successor.
I heavily advice you to switch and give it a try!


[Feature][Server] About deploy Flink task on Yarn-Session deployed flink

When I tried to deploy a flink task on the yarn-session deployed flink ,I got a problem. The command is the same as deploy using local mode(all like 'yarn -c XXXX.class XXX.jar') so I can use the local deploy mode. But when I tried to stop the workflow instance, not the flink job got canceled but the flink on yarn got killed. The reason is that the local deploy mode uses 'yarn -kill application_XXXX' command to stop the job, it works in local deploy mod but not the yarn-session mode. In yarn-session mode, the command should be 'flink stop ${job id} '. In my project the yarn is only deployed in yarn-session mode so I fixed the code to solve the problem for me, but could you add a more 'yarn-session' deploy mode?
What I have done includes finding the yarn job id from the log file and stop the flink job successfully not the yarn application. But the deploy mode para can be read in org.apache.dolphinscheduler.server.utils.ProcessUtils, but cannot be read in org.apache.dolphinscheduler.server.worker.processor.TaskKillProcessor.  In TaskKillProcessor.class , it stops yarn application for all task including flink task, no matter the deploy mode. I still get no idea on how to archive the deploy mode para in
TaskKillProcessor.class and stop the flink job only for yarn-session mode.

Yarn session mode flink job actually is a common need, anyone who are interested in implementing this feature, welcome to leave a message.


Add on error deployment ARM

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[x] The title of the PR is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[x] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[x] If applicable, the PR references the bug/issue that it fixes.
[x] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[x] I have read the contribution guidelines.
[x] My spec meets the review criteria:

[x] The spec conforms to the Swagger 2.0 specification.
[x] The spec follows the guidelines described in the Swagger checklist document.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

Automation for azure-sdk-for-python

Automation for azure-sdk-for-go

Shouldn't a new python sdk be needed too?

@ravbhatnagar new API version.

Signing off from ARM side!

Automation for azure-sdk-for-node

Error in CI syntax mode seems unrelated, let me know if I'm wrong about that assumption
'Error resolving $ref pointer "/home/travis/build/Azure/azure-rest-api-specs/specification/apimanagement/resource-manager/Microsoft.ApiManagement/stable/2017-03-01/apimapis.json#/parameters/LoggerIdParameter". \nToken "LoggerIdParameter" does not exist.'

is there a way to regen the python sdk? the 2018 version is not being auto created

@chidmdxx As the Python automation comment says, your PR is here:
https://github.com/Azure/azure-sdk-for-python/pull/2084
Thank you,

@chidmdxx I'm waiting for CI to see if there is no more issues.

@chidmdxx ruby and java CI are failing. We are investigating the issue.

@daschult please, have a look java CI.

@sergey-shandar I've identified the problem with the Java generator configuration for this pull request and I'm working on fixing it now.

@sergey-shandar I have a fix for the Java code generator problem in this PR.

@sarangan12 please, fix the configuration file in the ruby repository.


Repository configuration for SLES and OpenSUSE

Hi,  is this supported on SLES and OpenSUSE? If not, do you have a plan?

Can anyone give some comments?

#40

Related to #40

Hello!
This got added a while back :)


[sql-lab] make results table header fixed

Currently, column names will scroll off the page when trying to view the data preview for rows that are beneath the fold.  The column names should be fixed at the top of the container when scrolling the results, just like in Airpal.

fixed with https://github.com/airbnb/superset/pull/2587


"Error serializing widget state attribute:  interaction" when clicking the reset button

Describe the bug
There is an error in the console "Error serializing widget state attribute:  interaction" when clicking the reset button on a plot.
It seems that clicking the reset button on a plot calls the serialization routine for some reason. However, the interaction attribute only has a deserializer specified, not a serializer, so we end up in error.
To Reproduce
import numpy as np
size = 100
np.random.seed(0)
x_data = np.arange(size)
y_data = np.cumsum(np.random.randn(size) * 100.0)
from bqplot import pyplot as plt
plt.figure(title="My First Plot")
plt.plot(x_data, y_data)
plt.show()

Then click the reset button at the bottom of the plot. Check the browser console for the error "Error serializing widget state attribute:  interaction"
Expected behavior
No browser errors when clicking reset immediately after creating a plot
Screenshots
Additional context
My guess is that adding a serializer at https://github.com/bqplot/bqplot/blob/96b0b93b4a4a228ed79117d5d02fcaa6d1d0cc90/js/src/FigureModel.ts#L170 may do the trick? Or figure out why the serializer is called when clicking the reset button?

I've also encountered this issue


vivaldi-ffmpeg-codecs 112.0.5615.49 -> 111306

Description of changes
Fixes https://github.com/NixOS/nixpkgs/issues/243618
Cross reference: https://forum.vivaldi.net/topic/88884/page-crash-due-to-read-out-of-range-on-nixos
This package had not been updated in a while. The latest version of Vivaldi is incompatible, leading to page crashes.
I realized that this package was based on the update-ffmpeg script in Vivaldi's official distributions. That script used to download from launchpad. However, the launchpad package has been turned into an empty shell in favour of the snap package. The update-ffmpeg script has been updated accordingly, to download the Snap package.
Notes

It might be a good idea for the future to build the chromium-ffmpeg package from source. For now, this fix is the quick solution.

A benefit would be that it would be compatible with more platforms than just x86-64_linux
A downside would be that this built-from-source version would not be supported by Vivaldi. If e.g. we update chromium-ffmpeg to a too new version, we would get the same page crashes. The situation is a little awkward and might warrant some discussion.

I added myself as maintainer, as I'm willing to update this package every now and then.
The version format changes, the new version number (111306) corresponds to a Chromium release. See this post for an explanation
With the change in version, it's a bit hard to find a specific changelog, but I suppose the most important change is that it now no longer crashes in Vivaldi.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

It seems that I have now permissions to add labels to this PR, but I think it makes sense to add backport release-23.05. 23.05 has the same version of Vivaldi, presumably with the same problem. It makes sense to backport it to fix this issue :+1:

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/2437


Does this plugin not support extended ANSI colour, for example, "\e[..."?

Describe Your Issue
Based on one of answers at Unix & Linux Exchange, I rebuilt my favourite colour using RGB, converting to 256 colours' Xterm.
But the OS icon got white instead of greenish goldenrod yellow.
For example:

Have you tried to debug or fix it?
I have tried several times, but unsuccessful
Environment Information

What version of ZSH are you using? You can use zsh --version to see this.
zsh 5.7.1 (x86_64-pc-linux-gnu)
Do you use a ZSH framework (e.g., Oh-My-ZSH, Antigen)?
Yes, I use zplug
How did you install P9k (cloning the repo, by tarball, a package from your OS, etc.,)?
I installed it via zplug
What version of P9k are you using?
The latest version of P9, but actually I use P10 instead
Which terminal emulator do you use?
Deepin Terminal and Tilix

Code
terra_magnum_imperium()
{
  echo -n "\e[0;38;2;190;198;25m"
}

typeset -g POWERLEVEL9K_OS_ICON_FOREGROUND="terra_magnum_imperium"

Judging from your screenshot I'm guessing you are using powerlevel10k. It's a different theme, so in the future please file bug reports and feature requests there.
Zsh supports truecolor naively, so there is no need to use escape codes.
print -P '%F{red}hello%f'
print -P '%F{1}hello%f'
print -P '%F{#ff0000}hello%f'

Converting 190, 198 and 25 to hex, we get #bec619.
POWERLEVEL9K_OS_ICON_FOREGROUND='#bec619'

Note that this doesn't work in the original powerlevel9k but does work in powerlevel10k.

Note that this doesn't work in the original powerlevel9k but does work in powerlevel10k.

Would you support "e[0;fb8;2;r;g;bm" or just the hexadecimal code in the next version?
I have multiple themes, each theme for each terminal app. On Deepin Terminal and VSCode's integrated terminal, I use P9k, while on Tilix, 910k.

Would you support "e[0;fb8;2;r;g;bm" or just the hexadecimal code in the next version?

Next version of what?
As I mentioned, #bec619 is the standard zsh way of specifying 24-bit colors. It's not specific to powerlevel10k. It's the recommended way because it's easy to read, it will degrade gracefully on terminals that don't support colors, and it won't cause issues with cursor positioning.
Of course, you can also use escape codes, but it's not something I can recommend. The syntax is this:
typeset -g POWERLEVEL9K_OS_ICON_CONTENT_EXPANSION=$'%{\e[0;38;2;190;198;25m%}${P9K_CONTENT// }'

I have multiple themes, each theme for each terminal app. On Deepin Terminal and VSCode's integrated terminal, I use P9k, while on Tilix, 910k.

I'm curious, why?

Next version of what?

To update, adding feature support

The syntax is this:

On P9k?

I'm curious, why?

I depend on several themes I like more. I am not limited.
I depend on https://github.com/tonylambiris/dotfiles'zshrc which uses P9k.

Would you support "e[0;fb8;2;r;g;bm" or just the hexadecimal code in the next version?

Next version of what?

To update, adding feature support

Sorry, I don't understand.

The syntax is this:

On P9k?

No, p9k doesn't support this syntax.
I think the only way to do what you want with p9k is to define a custom prompt segment. See https://github.com/Powerlevel9k/powerlevel9k/#custom_command.

I'm curious, why?

I depend on several themes I like more. I am not limited.

You know that you can take any p9k config and simply use it with p10k, right?

I depend on https://github.com/tonylambiris/dotfiles'zshrc which uses P9k.

It works with p10k, too. See https://gist.github.com/romkatv/3e1c685ec83170ecb33267d5c7d3fe3f. Any style that works with p9k also works with p10k.
I'm not saying that you should switch. I just wanted to understand why you use p9k with one terminal and p10k with another.

Sorry, I don't understand.

To add feature support for these colour arguments.

No, p9k doesn't support this syntax.

Too bad.

I think the only way to do what you want with p9k is to define a custom prompt segment. See Powerlevel9k/powerlevel9k#custom_command.

I tested and it does not work. See the screenshot. I am using P9k.

It works with p10k, too. See gist.github.com/romkatv/3e1c685ec83170ecb33267d5c7d3fe3f. Any style that works with p9k also works with p10k.
I'm not saying that you should switch. I just wanted to understand why you use p9k with one terminal and p10k with another.

Well, I should have shared the screenshot to you and P10k's responsible, but it was too late, because while I zplugged P9k, using P10k theme or Tony Lambiris's style, I received the p9k....segmented... errors, I do not remember exactly the whole error name. And it broke on VSCode's integrated terminal. I believed because of this screenshot above as I am showing you or because of the some incompatibility. I had to restart a new P10k theme and a new P9k theme for Tony Lambiri's zshrc to get rid of the segments errors.

I'm having trouble parsing your comments, so I'll withdraw from this issue. If you need help with p10k, please file an issue against p10k. I'll let p9k devs answer your p9k questions.


Adding @auth directive breaks amplify push

Describe the bug
Whenever I add @auth to one of my API models, I get a Cannot read property 'fields' of undefined exception when running amplify push. I do have Cognito authentication set up with my app and that works fine.
Amplify CLI Version
4.22.0
To Reproduce
Adding @auth to this model gives me the error:
type UserAccount
  @model
  @key(
    name: "accountsByUser"
    fields: ["cognitoUserID"]
    queryField: "accountsByUser"
  )
  @auth(rules: [{ allow: owner }]) {
  id: ID!
  cognitoUserID: String!
  institutionName: String!
  institutionID: String!
  accessKey: String!
}

Expected behavior
Expected @auth to work fine.
Screenshots
 Cannot read property 'fields' of undefined
An error occurred during the push operation: Cannot read property 'fields' of undefined

Desktop (please complete the following information):

OS: Mac
Node Version: 14.2

Additional context

@apiel51 You are missing some commas.
@key(
    name: "accountsByUser"
    fields: ["cognitoUserID"]
    queryField: "accountsByUser"
  )

should be
@key(
    name: "accountsByUser",
    fields: ["cognitoUserID"],
    queryField: "accountsByUser",
  )

@LukeShay Actually the commas don't do anything. Added them and does not fix the problem 😕

Did some more digging, looks like the error is coming from this function:
addSubscriptionOwnerArgument(ctx, resolver, ownerRules, makeNonNull = false) {
        let subscription = ctx.getSubscription();
        let createField = subscription.fields.find(field => field.name.value === resolver.Properties.FieldName);
        const nameNode = makeNonNull ? graphql_transformer_common_1.makeNonNullType(graphql_transformer_common_1.makeNamedType('String')) : graphql_transformer_common_1.makeNamedType('String');
        const ownerArgumentList = ownerRules.map(rule => {
            return graphql_transformer_common_1.makeInputValueDefinition(rule.ownerField || constants_1.DEFAULT_OWNER_FIELD, nameNode);
        });
        createField = {
            ...createField,
            arguments: ownerArgumentList,
        };
        subscription = {
            ...subscription,
            fields: subscription.fields.map(field => (field.name.value === resolver.Properties.FieldName ? createField : field)),
        };
        ctx.putType(subscription);
    }

Here's the stacktrace:
Cannot read property 'fields' of undefined
TypeError: Cannot read property 'fields' of undefined
    at ModelAuthTransformer.addSubscriptionOwnerArgument (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/graphql-auth-transformer/src/ModelAuthTransformer.ts:1885:57)
    at ModelAuthTransformer.addSubscriptionResolvers (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/graphql-auth-transformer/src/ModelAuthTransformer.ts:1871:16)
    at /usr/local/lib/node_modules/@aws-amplify/cli/node_modules/graphql-auth-transformer/src/ModelAuthTransformer.ts:1745:14
    at Array.forEach (<anonymous>)
    at ModelAuthTransformer.protectOnCreateSubscription (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/graphql-auth-transformer/src/ModelAuthTransformer.ts:1744:13)
    at ModelAuthTransformer.object (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/graphql-auth-transformer/src/ModelAuthTransformer.ts:418:12)
    at GraphQLTransform.transformObject (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/graphql-transformer-core/src/GraphQLTransform.ts:340:25)
    at GraphQLTransform.transform (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/graphql-transformer-core/src/GraphQLTransform.ts:266:18)
    at _buildProject (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/graphql-transformer-core/src/util/amplifyUtils.ts:63:35)
    at ensureMissingStackMappings (/usr/local/lib/node_modules/@aws-amplify/cli/node_modules/graphql-transformer-core/src/util/amplifyUtils.ts:137:23)

I am experiencing the same bug. amplify push, amplify update, and amplify gql-compile all produce the same error. amplify update prints the stack trace:
TypeError: Cannot read property 'fields' of undefined
    at ModelAuthTransformer.addSubscriptionOwnerArgument (/Users/username/.nvm/versions/node/v12.4.0/lib/node_modules/@aws-amplify/cli/node_modules/graphql-auth-transformer/src/ModelAuthTransformer.ts:1906:57)
    at ModelAuthTransformer.addSubscriptionResolvers (/Users/username/.nvm/versions/node/v12.4.0/lib/node_modules/@aws-amplify/cli/node_modules/graphql-auth-transformer/src/ModelAuthTransformer.ts:1892:16)
    at /Users/username/.nvm/versions/node/v12.4.0/lib/node_modules/@aws-amplify/cli/node_modules/graphql-auth-transformer/src/ModelAuthTransformer.ts:1763:14
    at Array.forEach (<anonymous>)
    at ModelAuthTransformer.protectOnCreateSubscription (/Users/username/.nvm/versions/node/v12.4.0/lib/node_modules/@aws-amplify/cli/node_modules/graphql-auth-transformer/src/ModelAuthTransformer.ts:1762:13)
    at ModelAuthTransformer.object (/Users/username/.nvm/versions/node/v12.4.0/lib/node_modules/@aws-amplify/cli/node_modules/graphql-auth-transformer/src/ModelAuthTransformer.ts:421:12)
    at GraphQLTransform.transformObject (/Users/username/.nvm/versions/node/v12.4.0/lib/node_modules/@aws-amplify/cli/node_modules/graphql-transformer-core/src/GraphQLTransform.ts:340:25)
    at GraphQLTransform.transform (/Users/username/.nvm/versions/node/v12.4.0/lib/node_modules/@aws-amplify/cli/node_modules/graphql-transformer-core/src/GraphQLTransform.ts:266:18)
    at _buildProject (/Users/username/.nvm/versions/node/v12.4.0/lib/node_modules/@aws-amplify/cli/node_modules/graphql-transformer-core/src/util/amplifyUtils.ts:63:35)
    at ensureMissingStackMappings (/Users/username/.nvm/versions/node/v12.4.0/lib/node_modules/@aws-amplify/cli/node_modules/graphql-transformer-core/src/util/amplifyUtils.ts:137:23)

➜  foo git:(master) ✗ node --version
v12.4.0
➜  foo git:(master) ✗ npm --version
6.9.0
➜  foo git:(master) ✗ amplify --version
4.29.1

OS: macOS Catalina
type Player @model @auth(rules: [{ allow: owner }]) {
  name: ID!
}

type Query {
  player(name: ID!): Player
}

type Mutation {
  newPlayer(name: ID!): Player
}

schema {
  query: Query
  mutation: Mutation
}

@apiel51 I was not able to reproduce the issue with the provided schema, but thanks for the details that helped to locate the issue and you are right, the root cause is that subscription is not part of the schema element which can happen as in @bever1337 's case when schema is manually defined, now I'm making a fix for @bever1337 's case so it will add subscription member even if schema is manually defined but does not have the subscription operations type added.
@apiel51 could you provide some more details, do you have schema in your schema file defined? I want to make sure that we're covering the grounds, but based on the stacktrace my fix will cover it. If after PR merge and release you can still reproduce it, feel free to reopen the issue.


Precision deficiency

0.48 * 2.38 / 5 * 10 = 1.95159999999
The correct answer should be 1.9516

#20
#52
#55
#76
#84
#96
#104

exp4j uses doubles, which are floating-point numbers which are by definition inaccurate.
If you need arbitrary precision you need to use something like EvalEx which uses BigDecimal.


Bug report: fibo-fbc-dae-dbt:hasAccrualBasis has missing superproperty

https://github.com/edmcouncil/fibo/blob/723433558c37d04439cc5b98e51fc2b1f5b7914a/FBC/DebtAndEquities/Debt.rdf#LL945C49-L945C49
cmns-col:hasMethod isn't in the vocabulary as far as I can tell.
Source: https://www.omg.org/spec/COMMONS/Collections.ttl
Thank you for your work on FIBO.

@aamedina Hi Adrian, I think this is an issue with what is published on the OMG site. The formal revision of the COMMONS Ontology Library was approved in December at OMG by the membership, and in March by the OMG Board of Directors. I've attached the zip file for the revised ontologies so that you have them and will reach out to OMG staff to find out what is delaying posting the revisions (which should have been done in early April).
Commons 1.0 Turtle Serialized OWL Files.zip
If I can get any guidance about when the files will be posted, I'll let you know.

Hi, thank you for the files. I have patched it manually in the interim.
I am designing an OWL-centric datalog based linked data video game in Clojure that can "plug-in" FIBO as a modular source of its data models: https://github.com/aamedina/fibo.
Using this library: https://github.com/aamedina/rdf a Clojure program can automatically translate any RDF model Apache Jena can read (in Turtle, RDF/XML, JSON/LD, etc.) into a Clojure namespace containing the vocabulary, which creates a totally reflective and interactive system for navigating the ontologies as pure Clojure data inside a Clojure read-eval-print-loop.
Then, I can query the loaded graph with datalog. Datomic is especially interesting as its underlying fact structure is essentially an RDF triple plus time (and whether or not the fact has been retracted or asserted at that time). So you can think of a Datomic database modeled with RDF as a functionally immutable series of RDF graphs over time. This permits modelling and analyzing the evolution of your graph (the classes, properties and instances/individuals are all persisted in this architecture in the same database), preserving a complete audit log for each database.
I have only been experimenting with FIBO for the last year, but the data modeling is the best I have seen in the ecosystem of the Semantic Web in terms of being production-quality, and so I also have come to use it as a benchmark and learning resource as I learn about RDF and OWL. I really appreciate that this amazing knowledge graph is open source.
I aspire to be able to use FIBO to infer logically consistent and valid Datomic database schemas (where the RDF predicate is used as the Datomic attribute and the RDF subject is the entity) which can be tested and validated rigorously for financial applications to meet (and exceed) compliance requirements.
Sorry for the long answer but it's an odd use-case. Thanks again for your work! I look forward to continuing to learn from your best practices.

@aamedina Hi Adrian,
Thanks so much for sharing!  It's a really interesting use case, so we'll look forward to your findings. And, I appreciate your support for what we are doing. OMG posted the updated Commons ontologies yesterday, which turned out to show that the property I used as the parent of hasAccrualBasis wasn't the right one - it caused punning. I wouldn't have found that if you hadn't said something.  It will be fixed in the context of the SEC-73 pull request I just completed, though.
We will have a few more revisions for the Q2 release, which is coming in a couple of weeks, FYI, so you might want to update what you are using once that is available. It will have new MIC codes, some other updates to reference data, and a few more changes, FYI, which I'll document in our release notes.
We have another project, IDMP, which is also open source in our GitHub - not as complete yet, and not all of the Commons ontologies we are testing are available on the OMG site, but they are all in GitHub at edmcouncil/IDMP if you are interested in playing with that as well.
Also, my long-time friend, Paula Gearon, is really active in the Clojure community, so I'm sure that she will be interested in what you are doing as well.

I think we actually worked at Cisco together (though not on the same team) for a while, I should reconnect with her...
Yes, I also found IDMP (but haven't updated it in a while as I've been updated my own library unlike FIBO which I keep in sync always making sure I can install it into Datomic) https://github.com/aamedina/idmp and the Automotive Ontology https://github.com/aamedina/auto. I really appreciate how the different domains are all being modeled in the same way.
Looking forward to the release. Close this whenever you feel appropriate. Thanks so much.

@aamedina You're welcome - it will be forthcoming next week as we attempt to get a few more things in.  Note that the issue you originally raised has been fixed by the OMG now :).