Review on UI changes (Task 98, already merged)

@longpdo
98_review.pdf
Generally:

every clickable object should be clearly evident. This applies to most of the objects, using the change of mouse cursor to hand. It doesn’t apply to the new icons (add/edit/delete/logout). This should be adjusted to keep consistency.

we have to distinguish between „delete user from app“ and „remove user from project“. For that I had adjusted the confirmation message accordingly (DELETE vs. REMOVE). The appropriate icons should also be differentiated like that - to not confuse the admins with the same icon used for two different actions -> change icon of „remove user from project“ to something that represents „remove“ (maybe something like a red arrow)

you removed the back buttons, that is ok, since the browser’s back button is working now. But now this is also affecting the „tabs“ (Projects/Users and ProjectTickets/ProjectUsers), which are handled as different pages currently. This drastically worsens the navigation through the WebApp and is not a normal behavior for „back“ -> The „tabs“ should be implemented as real tabs to improve the navigation. I will try to implement that in the next sprint.

TicketChat:

„added refresh page after sending a message“ - ok

„cleared text input field after sending a message“ - ok

„send button only useable after entering a message - avoiding messages without text“ - ok

„added usability feature: send via 'Enter' key“ - not working properly (according to previous point), because the admin is able to send a message without text by using ‚Enter’

ProjectAdd:

„fixed bug: add button clickable even without inputing data“ - still not working properly. Entering only an entryKey enables the add button. This could result in a project without name, which makes no sense.

„fixed bug: text from before was still in input line“ - working for clicking on „add“ after entering text. Not working for clicking on „cancel“ after entering text.

TicketCreate and UserAdd:

„fixed bug: texts from before was still in input lines“  - working for clicking on „add“ after entering text. Not working for clicking on „cancel“ after entering text.

Other relevant changes:

„replaced buttons with icons (home, logout, add, edit, delete)“ - ok (supposing that are free icons)

Okay, thanks for insight!
to 1. Yeah, I also noticed that problem. What i figured out that the icons having a URL attached to them have the change mouse to hand. The icons without this change don't have them since those are associated with popups (thats why the home button which links to project list has this change and add/edit/delete which opens up a popup doesn't)
to 2. Yeah, thats a good suggestion. Lets see what the rest says in the meeting.
to 3. That wasn't caused by the removing of the back buttons but due to URL linking. That is why the different tabs are handled as different pages since they are right now as this enables the user to directly access the Projects tab or the Users tab from an URL/bookmark.
7-10. I've fixed them locally and I will commit the fixes during the day.

Yeah actually free but I still have to check something else. I report on that issue directly in the next meeting.

to 1. I just found a fix for that..gonna commit them soon on a new branch.

That is correct. But I think you can change the mouseover event easily.
Yeah. But removing the back buttons forces the admin to use the browser's back button which is just not suitable for navigation as long as we have this "tabs" handled as different pages. I think we have two option here: Add the back buttons again, or change the tab handling (which I would prefer, since this only will disable bookmarking the userlist). We should discuss this in the upcoming meeting.
7-10. Great!


Make all templates consistent

See https://github.com/dotnet/dotnet-template-samples/pull/20#issuecomment-330354670
We should update the templates to use the same naming patterns.

Cross-ref for the topic repo work that goes along with this: https://github.com/dotnet/docs/issues/3175

@sayedihashimi I'm asking [@]mairaw if she'll let me take care of the topic. If she says :+1:, I'll need to know what name you (or your assignee here) would like to use.

Is there anything else outside of the identity and shortname to change?
What values would you like to use for identity and shortname?

I'll track this and be on stand-by until more is known.

I agree that we should define values for shared (common) variables used across project examples. I looked a little bit more, and found that there are inconsistencies even among first 15 examples. I will post a detailed info soon.

Thanks @neman


Fix to GUI class

Fixed the issue with plots not clearing properly.

The observed problem that is fixed by this commit manifests in the appending of new plots when changing the GUI display (instead of substituting the old display with the new display). Origin of this problem is not clear, but there are some indications that updates of jupyter and/or ipywidgets and/or matplotlib may be responsible.


Content box

Now that percent unit support has been added to the library, I was wondering if you've considered exposing the content box on top of the element box. What do you think? It currently seems hard to know the exact size of the padding inside the box.

I would prefer to only support border-box sizing. Can you give an example of what is hard the achieve with the current model?

Oh, sure, I completely agree with using border-box. My point was that because units can now be percents, some values need to be resolved one way or the other to be added or substracted to others. For example, let's say I want to get the content width of an element like this:
<div style="width: 500px; padding-left: 5%; padding-right: 10%;" />

I currently need to apply the resolve logic myself:
let contentWidth = myDiv.getComputedWidth();
contentWidth -= myDiv.getPadding(EDGE_LEFT).value / myDiv.getParent().getComputedWidth() * 100;
contentWidth -= myDiv.getPadding(EDGE_RIGHT).value / myDiv.getParent().getComputedWidth() * 100;

Which means that I have to embed some layout logic inside my code (thankfully, most of those relative properties all depends on the parent width, otherwise it would have required extra steps to detect whether we should use the parent width or height).
To give you a better idea of what I mean, I've run some experiments by adding the following code in entry-common.js, and found it quite useful (it also automatically resolve EDGE_HORIZONTAL into EDGE_LEFT + EDGE_RIGHT, and EDGE_VERTICAL into EDGE_TOP + EDGE_BOTTOM):
for (let fnName of [ `Margin`, `Border`, `Padding` ]) {

	let method = lib.Node.prototype[`get${fnName}`];

	if (method == null)
		throw new Error(`Assertion failed; get${fnName} seems meesing`);

	patch(lib.Node.prototype, `getComputed${fnName}`, function getComputed(_, edge) {

		if (edge === constants.EDGE_HORIZONTAL)
			return getComputed.call(this, _, constants.EDGE_LEFT) + getComputed.call(this, _, constants.EDGE_RIGHT);

		if (edge === constants.EDGE_VERTICAL)
			return getComputed.call(this, _, constants.EDGE_TOP) + getComputed.call(this, _, constants.EDGE_BOTTOM);

		let value = method.call(this, edge);

		if (typeof value === `number`)
			return value;

		switch (value.unit) {

			case constants.UNIT_UNDEFINED: {
				return constants.UNDEFINED;
			} break;

			case constants.UNIT_PIXEL: {
				return value.value;
			} break;

			case constants.UNIT_PERCENT: {
				let relativeSize = this.getParent() ? this.getParent().getWidth() : 0;
				return value.value * relativeSize / 100;
			} break;

		}

	});

}

Ah ok this has recently been added to the C version. Seems like the javascript wrapper is missing just 👍  https://github.com/facebook/yoga/blob/master/yoga/Yoga.h#L200 gets the computed layout padding after calculation.

@arcanis does this look like what you need?

Sounds like it! 👍 How would you feel about adding border & margin counterparts, and the EDGE_HORIZONTAL & EDGE_VERTICAL support? Can I open a PR with these changes?

I would be fine with border and margin support. I'm not sure about EDGE_HORIZONTAL & EDGE_VERTICAL support as i'm not certain what that would mean? If you get the horizontal padding of a node with 5 in left padding but 10 in right padding then what should it return?

It would return 15, the sum of left + right. So computing the content width would work like this:
let contentWidth = node.getComputedWidth();
contentWidth -= node.getComputedBorder(EDGE_HORIZONTAL);
contentWidth -= node.getComputedPadding(EDGE_HORIZONTAL);

Instead of:
let contentWidth = node.getComputedWidth();
contentWidth -= node.getComputedBorder(EDGE_LEFT);
contentWidth -= node.getComputedBorder(EDGE_RIGHT);
contentWidth -= node.getComputedPadding(EDGE_LEFT);
contentWidth -= node.getComputedPadding(EDGE_RIGHT);

I don't think we should add that as it works differently than setting horizontal padding (setMargin(EDGE_HORIZONTAL, 10) sets 10 on both sides) and it is easy enough to get left and right and add them together 👍 .

Ok :) How do you feel about implementing YGNodeGetBorder if we don't support additional edge values? Because the borders are unitless, it would just be an alias to YGStyleGetBorder. I think that this alias should be implemented, because even if those functions have the same return value they won't have the same semantic. What do you think?

@arcanis I agree. Please split it up in two PRs though.


#162630266 Add testimonies slide to the landing page

What does this PR do?
Adds testimonies slide to the landing page
Description of Task to be completed?

Improve testimonies layout by adding user's photo
Implement a slide using css only

How should this be manually tested?

Navigiate to the landing page
Scroll down to the animated testimonies

What are the relevant pivotal tracker stories?
#162630266

Codecov Report

Merging #40 into develop will decrease coverage by 0.04%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##           develop      #40      +/-   ##
===========================================
- Coverage    82.16%   82.12%   -0.05%
===========================================
  Files           25       25
  Lines          443      442       -1
===========================================
- Hits           364      363       -1
  Misses          79       79

Impacted Files
Coverage Δ

server/src/controllers/parcels.js
96.29% <ø> (ø)
:arrow_up:

server/src/helpers/mailer.js
100% <100%> (ø)
:arrow_up:

server/src/models/BaseModel.js
73.49% <100%> (ø)
:arrow_up:

server/src/controllers/auth.js
93.1% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


push the view how to hide SMXTabBar

This isn't an issue with SMTabBar, more how your app is structured and where views are pushed from.


Enhancement default value for bigint should not has to be quoted

Proposed changes
Issue Number: open #20670

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Feature Request: add Ctrl+o shortcut key to toggle back and forth between micro and the main terminal

Description of the problem or steps to reproduce
The CLI file manager called GNU Midnight Commander (install with sudo apt install mc, then run with mc) has a really convenient Ctrl+o shortcut which toggles back and forth between the main terminal and the mc file manger. Please test it to see what I'm talking about.
I'd really like to see the same thing in micro, ideally which would work well with mc, so that pressing Ctrl+o repeatedly would cycle through terminal-->mc-->micro-->back to terminal, etc., repeatedly.
The minimum request though is a shortcut key which toggles just between micro and the main terminal, just like mc can do.
Specifications

Commit hash: 225927b9
OS: Linux Ubuntu 22.04
Terminal: terminator 2.1.1

As a workaround you can enter command term bash in command line Ctrl-E

@237dmitry , thanks. For now I'll use the Ctrl+E then term bash work-around. That looks pretty useful. I do think I'd prefer the mc functionality, however, even if Ctrl+O isn't the shortcut key we decide to use for micro.

For anyone wondering:

Ctrl+O is here: https://github.com/zyedidia/micro/blob/master/runtime/help/defaultkeys.md#file-operations
The term cmd is here: https://github.com/zyedidia/micro/blob/master/runtime/help/commands.md:

term exec?: Open a terminal emulator running the given executable. If no executable is given, this will open the default shell in the terminal emulator.

Tab navigation is here: https://github.com/zyedidia/micro/blob/master/runtime/help/defaultkeys.md#tabs

Alt+, navigates left one tab, so long as you're not in a terminal tab, as the terminal captures micro's shortcuts otherwise
Alt+. navigates right one tab, so long as you're not in a terminal tab, as the terminal captures micro's shortcuts otherwise

Feature request: since the terminal captures all of micro's shortcut keys when running inside micro, I'd still like some mc-like rapid shortcut key such as Ctrl+o or similar to quickly jump back and forth between micro and the terminal, even if the terminal is running as a tab within micro.

Another work-around:
Considering that micro can run a terminal inside it as a tab, and considering it can handle multiple tabs, it has some tmux-like features in it.
So, here is another work-around to get micro, mc, and the main terminal all playing nicely together and rapidly interchangeable:
Steps:

Run micro in your main terminal, to open micro.
Press Ctrl+T in micro to open up a new tab
Press Ctrl+E and type term bash to open a bash terminal inside this new tab within micro
Inside this terminal within the tab within micro, type mc to start the Midnight Commander CLI GUI-like file manager
Now, press Ctrl+o repeatedly to toggle between mc and this terminal running within micro
Since this is all running inside micro, you can click back to a micro editor tab at the top of the screen with your mouse too.
Question: how can I have a shortcut (such as Ctrl+, or Ctrl+.) to move left one tab or right one tab to change micro tabs while pressing said command from a terminal inside a micro tab?

Inside this terminal within the tab within micro, type mc to start the Midnight Commander

I want to ask, does mc work badly for you if you run it directly from the micro term mc?

@237dmitry , term mc doesn't work right for me either. It displays ok, but I cannot click around inside mc like normal.
So, you are right. There's a bug there. I think micro intercepts all mouse and keyboard activity, blocking it from reaching mc. I will keep running mc outside micro then...


Create a lightweight data science template

Thanks for submitting an issue to the MOOC Workbench. Please follow the structure below so we can easily try and categorize your issue.
Also, please check if it hasn't been reported already before submitting a new issue and if you happen to have a screenshot, that would helpful as well! Thanks!
Summary
The default templates are a good starting point, but do require a large amount of learning for new users. To ease new users into the use of the workbench, a good idea might be to create an extra data science template for Python that is very lightweight and only contains the absolute required files.
Expected behavior
During experiment creation, researchers have the option to select an extra lightweight data science template.
Additional notes

Created a new template in https://github.com/jlmdegoede/lightweight-workbench-template


[Task]  manager/controller/MonitorControllerTest.java

Description
Help us impl Unit Test For manager/controller/MonitorControllerTest.java

You can learn and refer to the previous test cases impl.

controller example unit case:  https://github.com/dromara/hertzbeat/blob/master/manager/src/test/java/com/usthe/manager/controller/AccountControllerTest.java
service example unit case:  https://github.com/dromara/hertzbeat/blob/master/manager/src/test/java/com/usthe/manager/service/TagServiceTest.java
jpa sql dao example unit case: https://github.com/dromara/hertzbeat/blob/master/manager/src/test/java/com/usthe/manager/dao/MonitorDaoTest.java

Task List

[ ] Impl Unit Test For manager/controller/MonitorControllerTest.java

Let me have a try

👍 has published at version v1.2.1


subsurface: move parent link to state

Move the wlr_subsurface parent link to the subsurface state.
 This shouldn't result in
any behavior change.

We need to be a bit careful here, the wlr_subsurface_state is actually an "add-on" for the parent wl_surface's state. It's not applied on child commit, it's applied on parent commit.
      Sub-surfaces also have another kind of state, which is managed by
      wl_subsurface requests, as opposed to wl_surface requests. This
      state includes the sub-surface position relative to the parent
      surface (wl_subsurface.set_position), and the stacking order of
      the parent and its sub-surfaces (wl_subsurface.place_above and
      .place_below). This state is applied when the parent surface's
      wl_surface state is applied, regardless of the sub-surface's mode.
      As the exception, set_sync and set_desync are effective immediately.

cc @vyivel

the wlr_subsurface_state is actually an "add-on" for the parent wl_surface's state

That looks a bit confusing, considering that other state addons belong to the base surface state. I'd rename it to wlr_subsurface_parent_state, which later will have addon with the child subsurface as owner.

Indeed, sounds like a good idea to me. Added a commit which does that, and also introduces a small comment to explain why it's special.

LGTM, but I'd like to leave this unmerged for now, until a PR for actual subsurface state caching is written.

https://github.com/swaywm/wlroots/pull/3125 took another approach, so I suppose this is not required anymore.

Merged as part of https://github.com/swaywm/wlroots/pull/3169


Datasets with missing measurements

Hi, I'm trying to create datasets definitions using eo-datasets, but I'm running into a problem regarding incomplete datasets.
I have created and correctly indexed a Product Definition having 6 measurements. Unfortunately in same cases there are datasets for which I only have 5 measurements to provide - due to the nature of the data I'm working with - and when I call datacube dataset add I get:
ERROR The dataset is not specifying all of the measurements in this product.
How can I force ODC to index the dataset even if not all measurements are provided? Thanks!

I have found a related discussion on GIS StackExchange, support has been added for eodatasets>=0.23, although I noticed only the write_measurement method supports multi-band images, but not the note_measurement one.

I have found a related question on GIS StackExchange, it seems it is not currently possible to cleanly handle these cases.


Possible Java version error with APIM CLI 1.14.4

APIM-CLI version
1.14.4
API-Management version
<IP_ADDRESS>30830
Bug description
Entered on behalf of a customer.
Using APIM CLI 1.14.4, there is an error running the command:
java.lang.UnsupportedClassVersionError: graphql/schema/idl/errors/SchemaProblem has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
Could it be that the most recent version was compiled with Java 11?
Thanks
Steps to reproduce
Use latest version of CLI with Java 8.
Relevant log output
java.lang.UnsupportedClassVersionError: graphql/schema/idl/errors/SchemaProblem has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

@nvidgren,  CLI needs Java 11 and above.


Allow private Oozie installation.

Add support for metadata oozie-repo-url parameter, which allows to specify GCS bucket and folder where RPM/APT and JAR resources are stored. That allows running this action in an environment with no Internet access and thus control the source of packages.

/gcbrun

/gcbrun


Build artifacts and include files are copied during cmake and make

We have found that during the cmake stage itself all the header files of tdi and its third-party are copied to ${CMAKE_INSTALL_PREFIX}/include/
Few instances here:
https://github.com/p4lang/tdi/blob/22cb07ac887491450d2efdb65cca727f99ecd317/CMakeLists.txt#L15C1-L17C26
https://github.com/p4lang/target-utils/blob/455fc4787a199978e0ae53bd2a6eb0cd2af1b790/CMakeLists.txt#L54
Also during make, libraries are copied to ${CMAKE_INSTALL_PREFIX}/lib. Such as below:
├── libcjson.a
├── libclish.so
├── libtarget_sys.so
├── libtarget_utils.so
├── libtdi_json_parser.so
├── libtdi_pna.so
├── libtdi_psa.so
├── libtdi.so
└── libtdi_tna.so
Is this a standard practice?
From a usability point, these are the following customer requirements we are not able to meet (because of it):

until make install is called the customer wants ${CMAKE_INSTALL_PREFIX} to be untouched.
make uninstall should clean any file copied or created in ${CMAKE_INSTALL_PREFIX}

Probable alternative:
Copy all the libs/artifacts to ${CMAKE_BINARY_DIR} so that we can internally include/link and proceed with the build.
Only "make install" should ideally copy the artifacts.
In this way we can reverse everything done by make install by using make uninstall.

Feel free to take it up as long as the same artifacts are installed during make install


Support prepared statements

Prepared statements are currently not supported:
-PREPARE is5 AS
FROM GRAPH_TABLE (snb
MATCH (m:message where m.id = $1)-[au:hasAuthor]->(p:person)
COLUMNS (p.id, p.firstName, p.lastName)
) tmp;
Will return Binder Error: PREPARE has not been implemented yet for DuckPGQ queries
Seems a bit more tricky to implement than first thought. The implementation currently throws Binder Error: Unable to find DuckPGQ Parse Data

Started work on this in https://github.com/cwida/duckpgq-extension/tree/75-support-prepared-statements


Unable to build server

Environment
Operating System: Linux
Node Version: v20.15.1
Nuxt Version: 3.13.2
CLI Version: 3.15.0
Nitro Version: 2.10.1
Package Manager<EMAIL_ADDRESS>Builder: -
User Config: default
Reproduction

Describe the bug
When I try to build my Nuxt project I get the next warning and then the build crashes:
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module
resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.

I was able to build my project before, I think is related with commit https://github.com/nitrojs/nitro/commit/51faaf30806f37db446d0019f1c130d0d3d1682f
Additional context
No response
Logs
No response

Can you please share a runnable reproduction? 🙏

Turns out the Solid Start bare starter reproduces this, fun! Made a quick MRE: https://github.com/agoldstein03/nitro-issue-2841-mre

Full logs
> vinxi build

vinxi v0.4.3

⚙  Building your app...
removing C:/Users/agold/Worksheets/nitro-issue-2841-mre/.vinxi/build/ssr
removing C:/Users/agold/Worksheets/nitro-issue-2841-mre/.vinxi/build/client
removing C:/Users/agold/Worksheets/nitro-issue-2841-mre/.vinxi/build/server-fns
vinxi v0.4.3

⚙ Building your router ssr...

📦 Compiling ssr router...
vinxi building router ssr in http mode
vite v5.4.10 building SSR bundle for production...
transforming...
✓ 23 modules transformed.
rendering chunks...
.vinxi/build/ssr/.vite/manifest.json       0.20 kB
.vinxi/build/ssr/assets/ssr-DW3Qht_s.css   0.70 kB
.vinxi/build/ssr/ssr.js                   14.22 kB
✓ built in 474ms
[success] build done
⚙ Built your router ssr successfully
vinxi v0.4.3

⚙ Building your router client...

📦 Compiling client router...
vinxi building router client in client mode
vite v5.4.10 building for production...
transforming...
virtual:$vinxi/handler/client (1:111): "default" is not exported by "src/entry-client.tsx", imported by "virtual:$vinxi/handler/client".
✓ 20 modules transformed.
rendering chunks...
computing gzip size...
.vinxi/build/client/_build/server-functions-manifest.json   0.03 kB │ gzip: 0.04 kB
.vinxi/build/client/_build/.vite/manifest.json              0.23 kB │ gzip: 0.16 kB
.vinxi/build/client/_build/assets/client-DW3Qht_s.css       0.70 kB │ gzip: 0.42 kB
.vinxi/build/client/_build/assets/client-wtgGv7Hr.js       13.69 kB │ gzip: 5.69 kB
✓ built in 870ms
[success] build done
⚙ Built your router client successfully
vinxi v0.4.3

⚙ Building your router server-fns...

📦 Compiling server-fns router...
vinxi building router server-fns in http mode
vite v5.4.10 building SSR bundle for production...
transforming...
✓ 19 modules transformed.
rendering chunks...
.vinxi/build/server-fns/_server/.vite/manifest.json       0.38 kB
.vinxi/build/server-fns/_server/assets/app-DW3Qht_s.css   0.70 kB
.vinxi/build/server-fns/_server/app.mjs                   0.43 kB
.vinxi/build/server-fns/_server/entry.mjs                58.88 kB
✓ built in 830ms
[success] build done
⚙ Built your router server-fns successfully
[warn] [nitro] No valid compatibility date is specified.
[info] [nitro] Using `2024-04-03` as fallback.
  Please specify compatibility date to avoid unwanted behavior changes:
     - Add `compatibilityDate: '2024-11-03'` to the config file.
     - Or set `COMPATIBILITY_DATE=2024-11-03` environment variable.

⚙  Preparing app for node-server...
[success] [vinxi] Generated public .output/public
[info] [vinxi] Building Nitro Server (preset: `node-server`, compatibility date: `2024-04-01`)
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[plugin commonjs--resolver] It appears a plugin has implemented a "resolveId" hook that uses "this.resolve" without forwarding the third "options" parameter of "resolveId". This is problematic as it can lead to wrong module resolutions especially for the node-resolve plugin and in certain cases cause early exit errors for the commonjs plugin.
In rare cases, this warning can appear if the same file is both imported and required from the same mixed ES/CommonJS module, in which case it can be ignored.
[success] [vinxi] Nitro Server built
[success] [vinxi] You can preview this build using `node .output/server/index.mjs`

I added a fixed branch which changes the nitropack version to 2.10.0, which resolves the issue and builds much quicker:

Full logs
> vinxi build

vinxi v0.4.3

⚙  Building your app...
removing C:/Users/agold/Worksheets/nitro-issue-2841-mre/.vinxi/build/ssr
removing C:/Users/agold/Worksheets/nitro-issue-2841-mre/.vinxi/build/client
removing C:/Users/agold/Worksheets/nitro-issue-2841-mre/.vinxi/build/server-fns
vinxi v0.4.3

⚙ Building your router ssr...

📦 Compiling ssr router...
vinxi building router ssr in http mode
vite v5.4.10 building SSR bundle for production...
transforming...
✓ 23 modules transformed.
rendering chunks...
.vinxi/build/ssr/.vite/manifest.json       0.20 kB
.vinxi/build/ssr/assets/ssr-DW3Qht_s.css   0.70 kB
.vinxi/build/ssr/ssr.js                   14.22 kB
✓ built in 878ms
[success] build done
⚙ Built your router ssr successfully
vinxi v0.4.3

⚙ Building your router client...

📦 Compiling client router...
vinxi building router client in client mode
vite v5.4.10 building for production...
transforming...
virtual:$vinxi/handler/client (1:111): "default" is not exported by "src/entry-client.tsx", imported by "virtual:$vinxi/handler/client".
✓ 20 modules transformed.
rendering chunks...
computing gzip size...
.vinxi/build/client/_build/server-functions-manifest.json   0.03 kB │ gzip: 0.04 kB
.vinxi/build/client/_build/.vite/manifest.json              0.23 kB │ gzip: 0.16 kB
.vinxi/build/client/_build/assets/client-DW3Qht_s.css       0.70 kB │ gzip: 0.42 kB
.vinxi/build/client/_build/assets/client-wtgGv7Hr.js       13.69 kB │ gzip: 5.69 kB
✓ built in 903ms
[success] build done
⚙ Built your router client successfully
vinxi v0.4.3

⚙ Building your router server-fns...

📦 Compiling server-fns router...
vinxi building router server-fns in http mode
vite v5.4.10 building SSR bundle for production...
transforming...
✓ 19 modules transformed.
rendering chunks...
.vinxi/build/server-fns/_server/.vite/manifest.json       0.38 kB
.vinxi/build/server-fns/_server/assets/app-DW3Qht_s.css   0.70 kB
.vinxi/build/server-fns/_server/app.mjs                   0.43 kB
.vinxi/build/server-fns/_server/entry.mjs                58.88 kB
✓ built in 580ms
[success] build done
⚙ Built your router server-fns successfully
[warn] [nitro] No valid compatibility date is specified.
[info] [nitro] Using `2024-04-03` as fallback.
  Please specify compatibility date to avoid unwanted behavior changes:
     - Add `compatibilityDate: '2024-11-03'` to the config file.
     - Or set `COMPATIBILITY_DATE=2024-11-03` environment variable.

⚙  Preparing app for node-server...
[success] [vinxi] Generated public .output/public
[info] [vinxi] Building Nitro Server (preset: `node-server`, compatibility date: `2024-04-01`)
[success] [vinxi] Nitro Server built
[success] [vinxi] You can preview this build using `node .output/server/index.mjs`

Thanks for reproduction dear @agoldstein03! https://github.com/nitrojs/nitro/pull/2842 should fix it.

Thanks for the quick PR @pi0! Also curious, is this something that a test could catch in the future before it's published? I'm unfortunately not familiar enough with the codebase, sorry. I could see how these types of warnings would be less stable to test for, but it seems like a regression test for build performance might be worth it to catch if build times suddenly double. Thoughts?

To be honest i believe it is something could be caught using rollup types. If passing argument is necessary, it should have been required. But also we don't have many usecases of this so test is probably not necessary.

@pi0 My original message was not very clear, apologies. I understand this specific rollup issue is unlikely to occur again, but since it also had a significant negative impact on build times (which is also undesirable), it seems to me that adding general tests to track whether build times stay within some generous window (+/- 25% expected, for example, to account for runtime variation) even just before releases might be worth it.
This would provide early warning for any future issues which the tests don't otherwise catch but also happen to negatively impact build times as a byproduct (and trigger a closer look at logs, for example), in addition to testing performance regression.
As best as I can tell, the current tests do include a production build, but only test whether or not they build successfully or error. Would an additional check like as described above for build duration be considered?

It might be a viable thing to do once we have an ecosystem CI. diff in this case was so low (1.5s => 1.6s on my system) and most of the time it will be noticed when using Nitro in more complex setups only.


Port to reflect Ansible 2.5 include_tasks behavioural changes

c.f. https://github.com/ansible/ansible/pull/35199
Related issue: https://github.com/ansible/ansible/issues/35459

Fixed by #5


replace Picasso with Glide

With Picasso, large image tend to not showing on screen. I've bad experience with Picasso with my previously project. After I change to Glide, my problem solved. It would be beneficial if this plugin also use Glide.

Glide also provide SVG support.

yes i will integrate Glide in this release. thanks @azizimusa @Mauker1

Hi. Thanks for adding support for Glide. But how do i start using it? can't found any documentation.

yes, this is the exact implementation. thanks for the update.

I have found that Recently the performance for running glide isnt better than picasso. I will hold on with this library while we can mix with both libraries to get the best supports and performance.


⚠ ReportPortal Server has degraded performance

In 6eca3e1, ReportPortal Server (https://reporting.its-telekom.eu/) experienced degraded performance:

HTTP code: 200
Response time: 13405 ms

Resolved: ReportPortal Server performance has improved in ae2f546.


Add support for AppAuth

AppAuth is a client SDK for native apps to authenticate and authorize end-users using OAuth 2.0 and OpenID Connect. See: https://appauth.io/
Maybe it's a  good idea to use this flutter wrapper and use the internal S3I OAuthProxy only on the web.

https://github.com/luis901101/oauth_webauth Looks nice too. But in my opinion, it is more insecure if a custom browser is used than the system one because the users can't be sure that the app won't stole their credentials. Therefore an independent browser is better.

There is now a new class AppAuthFlow which uses the FlutterAppAuth package when running on android/ios and throws unsupported errors on the other platforms.

One important note: See Android Setup and iOS Setup to prepare the app to be used with the new package.

There is a problem with AppAuth if the client contains a colon ":" as we use in the S3I for all clients. This is a big problem cause either AppAuth fixes this bug or we need an option to create a new client without the s3i:UUID syntax.

Another problem with the current ApAuth implementation is that only ios and android are supported. Since we can't conditional export only for those two platforms we're losing Windows/Linux/MacOS support in s3i_flutter. See the last pub dev score run: ["sdk:flutter","platform:android","platform:ios","platform:web","is:null-safe","license:mit"]


functional tests: capture SIGTERM in inspect

In TestService, we start a systemd service running a rkt image that
prints a message every second. Then we stop the unit and check it's not
in the service list.
This was working before because we weren't propagating the exit status
of apps in the pod to the outside.
Now that we do it, stopping the unit file means that SIGTERM will be
sent to nspawn, which will trigger a shutdown of systemd inside the pod,
which means SIGTERM will be sent to all the apps and that makes the
inspect binary exit with a non-zero status. Transient units that exit
with a failed status remain on the services list, so our test fails.
Capture SIGTERM in inspect and return 0 in that case, so the test
passes.
Fixes https://github.com/coreos/rkt/issues/2323

Could you only do that if /inspect is called with a parameter --silent-sigterm or something? Then you could use that only in the test that needs it.

Updated

LGTM
/cc @alban

LGTM as well :)


Fix #2159

Fixes #2159 .

Pull Request Test Coverage Report for Build 7528

17 of 18 (94.44%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.05%) to 54.469%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

sharding-core/sharding-core-execute/src/main/java/org/apache/shardingsphere/core/execute/sql/execute/result/MemoryQueryResult.java
0
1
0.0%

Totals

Change from base Build 7527:
0.05%

Covered Lines:
8593

Relevant Lines:
15776

💛  - Coveralls


Prevent Consecutive Execution of Identical Commands in execution_agent

In the interactions.py file of the AGiXT project, the execution_agent function currently does not check if the same command with the same arguments is being executed consecutively. This can lead to redundant operations and potentially undesirable behavior. The task is to implement a mechanism that identifies when a command with the same arguments is about to be executed consecutively and prevents this from happening, ensuring more efficient and controlled command execution.

For reference:

Resolved in #1291


Add Travis config files

These files are needed to activate Travis support

The build fails because the bus snapshot artifacts are not in JBoss Snapshots repo

From IRC
<tsegismont> Alerts cannot be built on Travis because the bus snapshot artifacts are not in JBoss Snapshots repo
<tsegismont> https://travis-ci.org/hawkular/hawkular-alerts/builds/50197352#L237
<lponce> tsegismont: yes, we depend on the work of the bus, mazz was working in an assembly, so once it's finished we can automate it
<tsegismont> What do you mean? The build needs org.hawkular.bus:hawkular-bus-mdb:jar:1.0.0.Alpha1-SNAPSHOT
<tsegismont> and probably other artifacts
<lponce> tsegismont: mvn clean install, only executes local junit test, but not integration tests, those ones are separated into a different rest profile
<lponce> tsegismont: I want to put it together in an automated way, to be able to deploy and run integration tests also, but I need some work in bus to do that, like a similar plugin for wildfly but with the bus
<tsegismont> Ok. But the problem here is just the compile phase
* jdoyle s'appelle maintenant jdoyle_away
<lponce> tsegismont: yeap, you are right, there is some artifacts from the bus project that are missing
<lponce> but how it can be addressed that ? because we depend of artifacts that are in SNAPSHOT state
<lponce> so I don't see as a good rule to perform a formal release for those
<lponce> travis can download/execute a mvn clean install for bus to populate its internal repo ?
<lponce> as similar we do in a local environment ?
<lponce> I'm not familiar with travis, may be I'm asking something trivial or impossible to do, I don't know :)
* jdoyle_away s'appelle maintenant jdoyle
<tsegismont> Ideally, all dependency should be in an external repo
<tsegismont> It should be possible to clone and build the bus project in pre-install phase
<tsegismont> But that means any time we want to test a PR on alerts we're also testing bus master branch
<lponce> if we are talking about adding 3 more minutes, I don't think is bad at all, as we can test is some last commit in bus can broke its dependencies
<lponce> but anyway, I don't know if that is acceptable
<lponce> for it can be if there is not an easier workaround
<tsegismont> I'll add it like this for now. but we'll need to remove this later when bus deps stabilize
<lponce> +1

So we will build Hawkular bus before testing alerts. Now Travis builds passes but before merging I'd like to make the bus build quiet (if not failing).

Ready for merging

Reviewed. It looks OK. Thanks to add alerts into travis world :-).


Trying to fix circelci failure related to spm_auditory

Trying to fix circleci failure

What was the problem? How did vol_to_file stop working? Was it replaced by new version of NIbabel that we use now?
Why was this not caught in the tests? Is it because of dataset caching? If so I will add another job to circleci, run occasionaly (once a day) to build without cache to catch such problems.

@kchawla-pi this thread might give you some details https://github.com/nipy/nibabel/issues/107
It is that nibabel loaded Nifti images cannot be save to files to the disk with extension .img, in particular using to_filename. Whereas nibabel.save can whether it is .img or .nii.gz extension.


Greedy Algorithm (Activity Selection) in JAVA with link attached in Readme file

Have you read the Contributing Guidelines on Pull Requests?
(Write your answer here.)
Description
(Write your answer here.)
Checklist

[x] I've read the contribution guidelines.
[x] I've checked the issue list before deciding what to submit.
[x] I've edited the README.md and link to my code.

Related Issues or Pull Requests
(Write your answer here.)

Waiting for the maintainers to merge the request

Waiting for the maintainers to merge the request.

It is now more than 10 days. I have done some more work waiting dor this request to merge first


skydns command cannot be found in docker container

I have successfully built the skydns follow the instruction
go get github.com/skynetservices/skydns
cd $GOPATH/src/github.com/skynetservices/skydns
go build -v

it works well on my host machine, but when i try to run the skydns in docker container, the terminal responds with "docker: Error response from daemon: Container command not found or does not exist..". And im sure the skydns binary file is exist in the root directory.
$ docker run -dP skydns
5a1dd21f1eb752587f3a8866a9243638767934a18c6ffd73d527934184810ddb
docker: Error response from daemon: Container command not found or does not exist..

$ docker run -ti --entrypoint=/bin/sh skydns
/ # ls -al
total 18984
drwxr-xr-x   17 root     root          4096 Apr 17 14:27 .
drwxr-xr-x   17 root     root          4096 Apr 17 14:27 ..
-rwxr-xr-x    1 root     root             0 Apr 17 14:26 .dockerenv
-rwxr-xr-x    1 root     root             0 Apr 17 14:26 .dockerinit
drwxr-xr-x    2 root     root          4096 Apr  1 18:56 bin
drwxr-xr-x    5 root     root           380 Apr 17 14:26 dev
drwxr-xr-x   13 root     root          4096 Apr 17 14:26 etc
drwxr-xr-x    2 root     root          4096 Apr  1 18:56 home
drwxr-xr-x    5 root     root          4096 Apr  1 18:56 lib
lrwxrwxrwx    1 root     root            12 Apr  1 18:56 linuxrc -> /bin/busybox
drwxr-xr-x    5 root     root          4096 Apr  1 18:56 media
drwxr-xr-x    2 root     root          4096 Apr  1 18:56 mnt
dr-xr-xr-x  231 root     root             0 Apr 17 14:26 proc
drwx------    2 root     root          4096 Apr 17 14:26 root
drwxr-xr-x    2 root     root          4096 Apr  1 18:56 run
drwxr-xr-x    2 root     root          4096 Apr  1 18:56 sbin
-rwxr-xr-x    1 root     root      19380864 Apr 17 00:36 skydns
dr-xr-xr-x   13 root     root             0 Apr 17 14:12 sys
drwxrwxrwt    2 root     root          4096 Apr  1 18:56 tmp
drwxr-xr-x    7 root     root          4096 Apr  1 18:56 usr
drwxr-xr-x   10 root     root          4096 Apr  1 18:56 var
/ # ./skydns
/bin/sh: ./skydns: not found

the Dockerfile is
FROM alpine:latest
MAINTAINER Miek Gieben<EMAIL_ADDRESS>(@miekg)
RUN apk --update add bind-tools && rm -rf /var/cache/apk/*
ADD skydns skydns
EXPOSE 53 53/udp
ENTRYPOINT ["/skydns"]

finally, I copy the skydns binary file into ubuntu:14.04 container, and it works well.
$ docker run -ti ubuntu:14.04 /bin/bash
$ docker cp skydns 49b3d:/

root@49b3d865abb2:/# ./skydns
2016/04/17 15:08:04 skydns: falling back to default configuration, could not read from etcd: client: etcd cluster is unavailable or misconfigured
2016/04/17 15:08:04 skydns: metrics enabled on :/metrics
2016/04/17 15:08:04 skydns: ready for queries on skydns.local. for tcp://<IP_ADDRESS>:53 [rcache 0]
2016/04/17 15:08:04 skydns: ready for queries on skydns.local. for udp://<IP_ADDRESS>:53 [rcache 0]

Why the command skydns cannot be found in alpine based container?
my docker version is

 Client:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   20f81dd
 Built:        Sat Mar 12 19:18:57 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   20f81dd
 Built:        Sat Mar 12 19:18:57 2016
 OS/Arch:      linux/amd64

uname -a
Linux arch-docker 4.5.0-1-ARCH #1 SMP PREEMPT Tue Mar 15 09:41:03 CET 2016 x86_64 GNU/Linux

Hello there,
Concerning your first point, as the go build command has no interaction with Docker, did you followed these steps (as describe in the README) beforehand ?
$ cd $GOPATH/src/github.com/skynetservices/skydns
$ GOOS=linux go build -a -tags netgo -installsuffix netgo
$ docker build -t skydns .

$ docker images | grep skydns
skydns              latest              9fff2b6a3de0        6 seconds ago       27.49 MB

And the image is actually working as it should :
$ docker run -ti skydns
2016/04/29 08:12:21 skydns: falling back to default configuration, could not read from etcd: client: etcd cluster is unavailable or misconfigured
2016/04/29 08:12:21 skydns: metrics enabled on :/metrics
2016/04/29 08:12:21 skydns: ready for queries on skydns.local. for tcp://<IP_ADDRESS>:53 [rcache 0]
2016/04/29 08:12:21 skydns: ready for queries on skydns.local. for udp://<IP_ADDRESS>:53 [rcache 0]

$ docker version
Client:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   20f81dd
 Built:        Sat Mar 12 19:18:57 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   20f81dd
 Built:        Sat Mar 12 19:18:57 2016
 OS/Arch:      linux/amd64

$ uname -a
Linux thinkpad 4.5.1-1-ARCH #1 SMP PREEMPT Thu Apr 14 19:19:32 CEST 2016 x86_64 GNU/Linux


Added query for cell types per anatomical structure

I modified this query  made for Ushma (https://api.triplydb.com/s/DD0PLAoD8) and added it to the grlc repo as a query.

@andreasbueckle
please add summary and description to the query like this:
https://github.com/hubmapconsortium/ccf-grlc/blob/main/hra-scratch/ftu-cell-summaries.rq#L1-L2

Done, see https://github.com/hubmapconsortium/ccf-grlc/pull/2/commits/0a7e921bb2e30bc23ae382b53971381f0ff3c766.


JS errors on first run

Hi,
interesting project! By following your instructions literally, I'm getting three JS errors on chrome:
Uncaught ReferenceError: vjs is not defined(anonymous function) @ videojs-vast-vpaid.js:2748(anonymous function) @ videojs-vast-vpaid.js:4823
vpaid.html:7 Uncaught ReferenceError: vjs is not defined(anonymous function) @ vpaid.html:7
video.js:59 Uncaught TypeError: this[a] is not a function

My head looks like this:
<script src="http://vjs.zencdn.net/4.12/video.js"></script>
<script src="videojs-vast-vpaid.js"></script>
<link href="http://vjs.zencdn.net/4.12/video-js.css" rel="stylesheet">
<link href="https://raw.githubusercontent.com/MailOnline/videojs-vast-vpaid/master/bin/videojs-vast-vpaid.css" rel="stylesheet">

Hi @sdistefano I am sorry for the late response. We were not expecting people to try the plugin so soon. Still it is great that you have done so.
Also you have discovered a very unexpected problem. It seems that the mangled version of videojs is removing the global variable vjs and other functions from the player component.
I have created an issue asking about this problem https://github.com/videojs/video.js/issues/2279 I can work around the vjs global variable but we need to have access to some of the player function in particular player.hasStarted to solve a problem we found when we updated videojs-contrib-ads.  https://github.com/videojs/videojs-contrib-ads/issues/93
I really wish I had a better solution but for the moment if you want to try the plugin, you will have to do so against an unmangled version of videojs.
I will try to find a solution for the problem as soon as possible.
Thanks a lot for trying the plugin

Hi! Thanks a lot for the explanation. Yes, it's a pity we can't just use the videojs CDN and enjoying caching among multiple sites. I'll try embeeding the unmnagled videojs in my project for now then.
Thanks, I'll report back if I find anything

Any update on this issue? I'm looking to use the CDN version as well..

It seems that we won't have any problem with version 5.x.x but the problem will remain in version 4.x.x.
We are putting all our focus on supporting VPAID ads. Once we finally support them I will come back to this issue to try to find a solution.


Add Databricks

Adds the following events or companies:

Databricks

Checklist

[x] I have updated the event or company counts
[x] I have put the most recent relevant date in the "Last Update" column
[ ] I have linked to the article about the change, not the company's website

Hi there! We recently re-worked the site to use yaml data files. We'd be happy to accept your PR once it's been reworked to use the right format.
Thanks!

New PR at https://github.com/phildini/stayinghomeclub/pull/489