forceUpdatePeriod doesn't work with non-fresh sbt run

relates to Add forceUpdatePeriod
@ajsquared
Steps
sbt.version = 1.5.2
Part 1 (publish some SNAPSHOT library)

Create some dummy sbt project as a library.
Note, that it should be published to some artifactory (thus no via publishLocal)

name := "my-library-3"

ThisBuild / scalaVersion := "2.13.5"
ThisBuild / organization := "org.example"
ThisBuild / version      := "0.1-SNAPSHOT"

// Configure your own repository here
credentials += Credentials(Path.userHome / ".sbt" / "my.credentials")
resolvers += MyResolvers.myRepository
publishTo := Some(MyResolvers.myRepository)

In the library sources create some test object with method foo1

object MyObject3 {
  def foo1(): Unit = {
    println(s"hello from: ${this.getClass}")
  }
}

Publish the library with publish command

Part 2 (use the library in another project)

Create another sbt project which will use the library:

import scala.concurrent.duration.DurationInt

name := "library-reindex"
version := "0.1"
scalaVersion := "2.13.5"

ThisBuild / forceUpdatePeriod := Some(0.seconds) // doesn't help :(

libraryDependencies ++= Seq(
  "org.example" %% "my-library-3" % "0.1-SNAPSHOT" /*withSources()*/,
)

myTask2 := myTaskDef2.value

// TODO: provide same resolvers as in library project
credentials += ???
resolvers += ???

In this project create some task which depends on update task:
in build.sbt add:

myTask2 := myTaskDef2.value

in project/commons.scala:
import org.jetbrains.sbt.CreateTasks.`enrich TaskKey`
import org.jetbrains.sbt.{Options, StructureKeys, UpdateReportAdapter}
import sbt.Def.Initialize
import sbt._

object commons {
  def myTaskDef2: Initialize[Task[String]] = Def.task {
    val result = Keys.update.value
    println(s"! $result")
    "done task 2"
  }
}

Run sbt for the second project

Run update just in case

Ensure that the library was resolved by courier.
Go to something like:
.../Coursier/cache/v1/https/<repository_path>/org/example//my-library-3_2.13/0.1-SNAPSHOT
and ensure that my-library-3_2.13-0.1-SNAPSHOT.jar exits

Part 3 (modify the snapshot library, republish, and see that it's not updated when update is called indirectly)

First, ensure that you disable Coursier TTL.
Without this, whatever you do in SBT, Coursier will not update the library from the server.
According to https://get-coursier.io/docs/ttl you can disable TTL using COURSIER_TTL=0 environment variable.
Also you can use JVM property -Dlmcoursier.internal.shaded.coursier.ttl=0.
(BTW, it should be -Dcoursier.ttl=0 according to the coursier sources, but for some reason, in SBT it's different (I inferred it from the bytecode). Probably this is due to the shading rules: https://github.com/coursier/sbt-coursier/blob/master/build.sbt#L57)

Change method from foo1 to foo2 in the library project, and republish it using publish

Go to the second project, open sbt and do update

See that library jar was updated.
Class contains method foo2 now.
This is the expected behaviour according to the docs:
Directly running the update task (as opposed to a task that depends on it) will force resolution to run, whether or not configuration changed.

You can use this bash script to quickly check the .jar in the coursier cache folder:
stat my-library-3_2.13-0.1-SNAPSHOT.jar ; \echo "" ; \
unzip -p my-library-3_2.13-0.3-SNAPSHOT.jar MyObject3$.class > temp.class ; javap temp.class | grep foo

Change method from foo2 to foo3 in the library project, and republish it using publish
Go to the second project, open sbt and run myTask2.
Note 1: myTask2 depends on update
Note 2: the project has ThisBuild / forceUpdatePeriod := Some(0.seconds) setting
See that the library jar WAS NOT updated. The class still contains foo2
Close sbt in the second project , remove all target folders, restart sbt
Again, run myTask2
See that the library jar WAS updated. The class now contains foo3

problem
When you have a non-fresh SBT context
(you already run some commands and caches in target folder are poluted)
forceUpdatePeriod setting doesn't work as expected.
expectation
forceUpdatePeriod should force update in any circumstances
After step 13 and 14 the class should contain method foo3
notes
The code responsible for that is located in
sbt.Classpaths.updateTask0
Looks like some wrong folder is used to detect the last update timestamp:
val fullUpdateOutput = cacheDirectory / "out"

in the debugger fullUpdateOutput.exists() returned false when I was doing myTask2

Test src/sbt-test/dependency-management/force-update-period/test only tests fresh sbt run.
Some test for non-freash sbt run should be added

to some degree relates to https://youtrack.jetbrains.com/issue/SCL-18764

related: Update ttl.md

@adpi2 Could yo please also comment on this part?

...
Also you can use JVM property -Dlmcoursier.internal.shaded.coursier.ttl=0.
(BTW, it should be -Dcoursier.ttl=0 according to the coursier sources, but for some reason, in SBT it's different (I inferred it from the bytecode). Probably this is due to the shading rules: https://github.com/coursier/sbt-coursier/blob/master/build.sbt#L57)

Also mentioned in this comment

Maybe we should use the forceUpdatePeriod to configure Coursier TTL.


How to visualize the graph of the asr model?

maybe you can try VisualDL https://www.paddlepaddle.org.cn/documentation/docs/zh/guides/advanced/visualdl_usage_cn.html

How do I save the graph definition?
Do I have to edit the source code?

first export model, please see  https://github.com/PaddlePaddle/PaddleSpeech/blob/develop/examples/wenetspeech/asr1/local/export.sh


Sharing modules across apps

I want to invoke the service using the generated client in a different elixir service.
What are the common/best practices to achieve this?

One approach is to use an umbrella application where one of the (sub)applications is dedicated to just the generated Thrift code. Then, other applications can depend on that code (either as clients or servers).

@jparise , I was doing something similar
  {:base, path: "../light_base"}

But I am a bit worried about this appoach as well.
My application name is Light
The generated modules are Light.Base.*
If we move it to a different application, the module names have to be different ex: LightBase
Keeping it as Light.Base in a different application seems like an antipattern.

In our case, we used a different namespace for the generated Thrift modules (e.g. LightThrift or LightGen).

Oh okay. I guess I will do something on the similar lines then.
Thanks for the info


Change page to 1 on filter

Question: Do we do this on sorting as well? @sadmann7

Oh need to change page state as well...
PR still under dev


Change get_energy_timeseries function to pypsa dispatch function

Feature Request
We should change our get_energy_timeseries(n) function to the pypsa.statistics.StatisticsAccessor.dispatch() method. The advantage of this is that we can simplify our code and take advantage of pypsa testing their functions. Note, we need to double check we care assuming same logic for link power dispatch
Suggested Solution
I believe these two are equivalent:

(current) get_energy_timeseries(n)
(proposed) StatisticsAccessor(n).dispatch(aggregate_time=False).T

Additional Info
No response

dispatch will also bring in the demand timeseries, which will further simplify the plot_production graphs


jspm incorrectly considers a local dependency to be commonjs

$ mkdir pkg
$ npm i @jspm/generator
$ mkdir subpkg
$ echo '{"name": "subpkg", "version": "0.0.0", "main": "index.js"}' > subpkg/package.json
$ echo 'console.log("hello!")' > subpkg/index.js
$ cat > generate.mjs
import { Generator } from '@jspm/generator';

const generator = new Generator({
  mapUrl: import.meta.url,
  defaultProvider: 'nodemodules',
  env: ['production', 'browser', 'module'],
});

await generator.install('./subpkg');
$ node generate.mjs
file:///tmp/pkg/node_modules/@jspm/generator/dist/generator-0681485c.js:2565
            throw new JspmError(`Unable to trace ${resolved}, as it is a CommonJS module. Either enable CommonJS tracing explicitly by setting "GeneratorOptions.commonJS" to true, or use a provider that performs ESM transpiling like jspm.io via defaultProvider: 'jspm.io'.`);
                  ^

JspmError: Unable to trace file:///tmp/pkg/subpkg/index.js, as it is a CommonJS module. Either enable CommonJS tracing explicitly by setting "GeneratorOptions.commonJS" to true, or use a provider that performs ESM transpiling like jspm.io via defaultProvider: 'jspm.io'.
    at TraceMap.visit (file:///tmp/pkg/node_modules/@jspm/generator/dist/generator-0681485c.js:2565:19)
    at async Generator.install (file:///tmp/pkg/node_modules/@jspm/generator/dist/generator-0681485c.js:3854:13)
    at async file:///tmp/pkg/generate.mjs:11:1 {
  jspmError: true,
  code: undefined
}

Node.js v19.7.0

It looks like jspm is considering my subpkg/index.js file to be a CommonJS file, despite not using any CommonJS features and being entirely possible to import via ESM. Even if I explicitly declare it as a non-CommonJS file using package.json conditional exports, jspm still throws this error. I can work around it by passing commonJS: true, but as a library author I'd like to avoid requiring my users to do that.
Note that while this is a toy example, my real use-case is more serious: I'm trying to distribute a library that will seamlessly support both CJS and ESM users with the same codebase. To do so, I use side effects when the library is loaded via ESM to pass out its exports without violating CJS syntax.

Fixed in https://github.com/jspm/generator/pull/261.


TF Extrapolation Error during runtime

Occasionally during simulation (with the gazebo sim_time set to TRUE), the following error will show:
Extrapolation Error: Lookup would require extrapolation -0.033000000s into the future.  Requested time 1192.266000000 but the latest data is at time 1192.233000000, when looking up transform from frame [map] to frame [base_footprint]

This issue seems to originate from regulated_pure_pursuit_controller.cpp Line 494-497
As a consequence, the robot localization will jump about erratically.

Upon further inspection using rosrun tf tf_monitor, there seems to be a negative average delay in the tf monitor for the odom frame, as explained in this ROS Answer, it could be the case that AMCL is stamping data in the future.

The apparent delocalization of the robot in simulation is not caused by the "TF Extrapolation Error" but rather, by the incorrect settings of the libgazebo_ros_diff_drive plugin within Gazebo. The parameter publishWheelJointState must be set to true, otherwise, the AMCL particles will diverge with each motion step, the underlying mechanism is not clear but it seems to affect the odom to base frame TF, and hence the AMCL convergence.
The issue does not lie with Regulated Pure Pursuit Controller but rather with the gazebo configs.

CORRECTION: The issue was not with the above gazebo pluging parameter, but rather AMCL was not scan matching against the correct map, as we were changing maps using map server (and AMCL was scan matching against the previously loaded map). One fix we employed was to simply set the AMCL parameter ~use_map_topic  to true, thereby subscribing to the current map and scan-matching against the correct map


Allow plugins to provide metadata

Right now there is really no good way for plugins to provide metadata about a song. I think an API like this would work
void metadata_callback(void* user_data,
     void (*set_metadata)(enum type, const char* text, const char* extra)) {
  ..
  set_metadata(Type_Title, "Foobar sings again", "English");
  set_metadata(Type_Title, "おはよう。", "Japanese");
  set_metadata(Type_CreationTool, "Protracker 3.6", "");
  set_metadata(Type_Addititonal, "Anything goes", "");
  ...
}

This also allows the plugin to not have to care about ownership of the data. the set_metadata API will take ownership/clone the data.

Implemented


Message after choosing domain to issue ..

Hi,
Thank you very much for doing this plugin;
I installed it, and the icon appears properly on cpanel ( although in whm it times out if I click the plugini icon ) and I am able to go all the way to the "Choose Domain" .. once I choose the domain,
it works for a few seconds and a message, flagged in red appears:
Executed: /usr/bin/openssl req -new -sha256 -utf8 -key /home/live/.letsencrypt/live/dotboss.digital/dotboss.digital.key -config /home/live/tmp/2ZfKbUmuxr.conf -reqexts SAN -subj / -out /home/live/.letsencrypt/live/sea.com/sea.com.csr
and nothing else;
if I reload, or go re-enter the plugin there is no domains with SSL ..
What am I missing ?
I have root access and can paste any logs here; .. just not sure which one.
Thank you very much in advance for any kind attention this may get,
cordially,
s

I'm getting the same issue described above. When executing the command manually I get some further output:
error on line -1 of /home/client/tmp/T2lBSzgux1.conf
140049201268640:error:02001002:system library:fopen:No such file or directory:bss_file.c:169:fopen('/home/client/tmp/T2lBSzgux1.conf','rb')
140049201268640:error:2006D080:BIO routines:BIO_new_file:no such file:bss_file.c:172:
140049201268640:error:0E078072:configuration file routines:DEF_LOAD:no such file:conf_def.c:197:

This happened after upgrading to the latest commit (8971c55e510e95a22e4c7a49746a8aefd51f23b3).
A workaround is to use the autossl feature of WHM, which supports let's encrypt now.


Unneeded message when closing the wallet pop up

What happened?
In our internal testing for the Mac client, someone reported that they received an unneeded message when closing the wallet pop up.
Steps to reproduce

Click coinbase, and don't log in, just close the pop up.
It says's "Something went wrong. accounts received is empty. Reload"

Operating System
MacOS, version not specified
Wallet
None, played as guest
CPU
Not specified
GPU
Not specified
RAM
Not specified
Kernel Version
Not specified
Unity Version
Not specified
Realm
No response
NameTag
No response

Acknowledged,
Could reproduce with the provided steps, will check it out!

@fzavalia do you have news about this issue?


Is this repo still under maintenance, I am facing few issues and would like to make a pull request.

@babyman

Life is crazy busy but if you have code that makes sense to include into this project I would be very happy to review and merge it =)
Evan


Add base components, redesign videoroom home page

This is a redesign of the videoroom home page. It also configures tailwind and adds base, reusable components like Input or Link

Please add a Jira task ID (MV-240) at the begging of PR name


Adding 1.0.1 archive for legacy support

Sorry, we're only going to support the latest version for each release. Otherwise the repo would be flooded with stale tags. I believe 1.0.6 should be compatible with 1.0.1.


'NavBar'

In NavBar.js export const NavBar throws an error "Identifier 'NavBar' has already been declared. this is breaking the scroll listener

Fixed #53 @61ZM07H36R3ML1N @yossijaki  @Trkzi-Omar @hacker-kun

Fixed #53 @61ZM07H36R3ML1N @yossijaki @Trkzi-Omar @hacker-kun

what was the issue? because the code doesn't look different?

In NavBar.js export const NavBar throws an error "Identifier 'NavBar' has already been declared. this is breaking the scroll listener

Of course, we can't import "NavBar" and export "NavBar" in the same file.
A fix would be to simply change the name of the component and its usages.
For example: CustomNavBar

In NavBar.js export const NavBar throws an error "Identifier 'NavBar' has already been declared. this is breaking the scroll listener

Of course, we can't import "NavBar" and export "NavBar" in the same file.
A fix would be to simply change the name of the component and its usages.
For example: CustomNavBar

Thank you for your response


Horseshoe speed and armor values are constantly changing.

Yes it is fluctuate, to better see it just install Better F3 mod, and activate the actual speed options, then run them horses.

https://streamable.com/jwa1w9
See the absolute velocity on top-left


⚠ Bofrost.be has degraded performance

In 910b96e, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1553 ms

Resolved: Bofrost.be performance has improved in 8389cb1.


[bug] Two sets of device files exist in docker images and most recent device files from node-zwave-js are not used

Version
Build/Run method

[X] Docker
[ ] PKG
[ ] Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: 1.2.3
Describe the bug
In a docker image built on the cc/hail node-zwave-js branch, and the #84 branch, two copies of the device files exist within the docker image. (I believe this exists in all of the images I've built off the recent node-zwave-js master.) The new device files amended to include the compat flag are in one directory, and the old ones in another. The devices are setup with the old ones, not the new ones. I didn't notice this while testing the compat flag as I'd replaced both of them in the image while testing.
As such, as built double tap events still update the current value and the BasicCC is mapped. Manually amending the additions into the (old one) below and refreshing the node results in the compat flag being respected and double tap working. Confirmation that the (old one) is the one being read.
As an example:
(new one<EMAIL_ADDRESS>(with associations and compat sections)
// Jasco Products GE 14294 (ZW3005)
// In-Wall Dimmer Switch
{
	"manufacturer": "Jasco Products",
	"manufacturerId": "0x0063",
	"label": "GE 14294 (ZW3005)",
	"description": "In-Wall Dimmer Switch",
	"devices": [
		{
			"productType": "0x4944",
			"productId": "0x3038"
		}
	],
	"firmwareVersion": {
		"min": "0.0",
		"max": "255.255"
	},
	"supportsZWavePlus": true,
	"associations": {
		// One entry for each association group
		"1": {
			"label": "Lifeline",
			"maxNodes": 5,
			"isLifeline": true
		},
		"2": {
			"label": "Basic - Local Load",
			"maxNodes": 5
		},
		"3": {
			"label": "Basic - Double Tap", // required
			"maxNodes": 5,
			"isLifeline": true
		}
	},
	"paramInformation": {
		"3": {
			"label": "Night Light",
			"description": "Defines the behavior of the blue LED. Default is on when switch is off.",
			"valueSize": 1,
			"minValue": 0,
			"maxValue": 2,
			"defaultValue": 0,
			"readOnly": false,
			"writeOnly": false,
			"allowManualEntry": false,
			"options": [
				{
					"label": "LED on when switch is OFF",
					"value": 0
				},
				{
					"label": "LED on when switch is ON",
					"value": 1
				},
				{
					"label": "LED always off",
					"value": 2
				}
			]
		},
		"4": {
			"label": "Invert Switch",
			"description": "Invert the ON/OFF Switch State.",
			"valueSize": 1,
			"minValue": 0,
			"maxValue": 1,
			"defaultValue": 0,
			"readOnly": false,
			"writeOnly": false,
			"allowManualEntry": false,
			"options": [
				{
					"label": "No",
					"value": 0
				},
				{
					"label": "Yes",
					"value": 1
				}
			]
		},
		"5": {
			"label": "Ignore Start-Level (Receiving)",
			"description": "This dimmer will start dimming from its current level.",
			"valueSize": 1,
			"minValue": 0,
			"maxValue": 1,
			"defaultValue": 0,
			"readOnly": false,
			"writeOnly": false,
			"allowManualEntry": false,
			"options": [
				{
					"label": "No",
					"value": 0
				},
				{
					"label": "Yes",
					"value": 1
				}
			]
		},
		"7": {
			"label": "On/Off Command Dim Step",
			"description": "Indicates how many levels the dimmer will change per step.",
			"valueSize": 1,
			"minValue": 1,
			"maxValue": 99,
			"defaultValue": 3,
			"readOnly": false,
			"writeOnly": false,
			"allowManualEntry": true
		},
		"8": {
			"label": "On/Off Command Dim Rate",
			"description": "This sets how often the dim level will change.",
			"valueSize": 2,
			"minValue": 1,
			"maxValue": 255,
			"defaultValue": 3,
			"readOnly": false,
			"writeOnly": false,
			"allowManualEntry": true
		},
		"9": {
			"label": "Local Control Dim Step",
			"description": "How many levels the dimmer will change for each step.",
			"valueSize": 1,
			"minValue": 1,
			"maxValue": 99,
			"defaultValue": 3,
			"readOnly": false,
			"writeOnly": false,
			"allowManualEntry": true
		},
		"10": {
			"label": "Local Control Dim Rate",
			"description": "This sets how often the dim level will change.",
			"valueSize": 2,
			"minValue": 1,
			"maxValue": 255,
			"defaultValue": 3,
			"readOnly": false,
			"writeOnly": false,
			"allowManualEntry": true
		},
		"11": {
			"label": "ALL ON/ALL OFF Dim Step",
			"description": "How many levels the dimmer will change per step.",
			"valueSize": 1,
			"minValue": 1,
			"maxValue": 99,
			"defaultValue": 1,
			"readOnly": false,
			"writeOnly": false,
			"allowManualEntry": true
		},
		"12": {
			"label": "ALL ON/ALL OFF Dim Rate",
			"description": "This sets how often the dim level will change.",
			"valueSize": 2,
			"minValue": 1,
			"maxValue": 255,
			"defaultValue": 1,
			"readOnly": false,
			"writeOnly": false,
			"allowManualEntry": true
		}
	},
	"compat": {
		"disableBasicMapping": true
	}
}

(old one<EMAIL_ADDRESS>(no new additions)
(Note the duplicate node_modules directories, I suspect this is the issue
// Jasco Products GE 14294 (ZW3005)
// In-Wall Dimmer Switch
{
    "_approved": true,
    "manufacturer": "Jasco Products",
    "manufacturerId": "0x0063",
    "label": "GE 14294 (ZW3005)",
    "description": "In-Wall Dimmer Switch",
    "devices": [
        {
            "productType": "0x4944",
            "productId": "0x3038"
        }
    ],
    "firmwareVersion": {
        "min": "0.0",
        "max": "255.255"
    },
    "supportsZWavePlus": true,
    "paramInformation": {
        "3": {
            "label": "Night Light",
            "description": "Defines the behavior of the blue LED. Default is on when switch is off.",
            "valueSize": 1,
            "minValue": 0,
            "maxValue": 2,
            "defaultValue": 0,
            "readOnly": false,
            "writeOnly": false,
            "allowManualEntry": false,
            "options": [
                {
                    "label": "LED on when switch is OFF",
                    "value": 0
                },
                {
                    "label": "LED on when switch is ON",
                    "value": 1
                },
                {
                    "label": "LED always off",
                    "value": 2
                }
            ]
        },
        "4": {
            "label": "Invert Switch",
            "description": "Invert the ON/OFF Switch State.",
            "valueSize": 1,
            "minValue": 0,
            "maxValue": 1,
            "defaultValue": 0,
            "readOnly": false,
            "writeOnly": false,
            "allowManualEntry": false,
            "options": [
                {
                    "label": "No",
                    "value": 0
                },
                {
                    "label": "Yes",
                    "value": 1
                }
            ]
        },
        "5": {
            "label": "Ignore Start-Level (Receiving)",
            "description": "This dimmer will start dimming from its current level.",
            "valueSize": 1,
            "minValue": 0,
            "maxValue": 1,
            "defaultValue": 0,
            "readOnly": false,
            "writeOnly": false,
            "allowManualEntry": false,
            "options": [
                {
                    "label": "No",
                    "value": 0
                },
                {
                    "label": "Yes",
                    "value": 1
                }
            ]
        },
        "7": {
            "label": "On/Off Command Dim Step",
            "description": "Indicates how many levels the dimmer will change per step.",
            "valueSize": 1,
            "minValue": 1,
            "maxValue": 99,
            "defaultValue": 3,
            "readOnly": false,
            "writeOnly": false,
            "allowManualEntry": true
        },
        "8": {
            "label": "On/Off Command Dim Rate",
            "description": "This sets how often the dim level will change.",
            "valueSize": 2,
            "minValue": 1,
            "maxValue": 255,
            "defaultValue": 3,
            "readOnly": false,
            "writeOnly": false,
            "allowManualEntry": true
        },
        "9": {
            "label": "Local Control Dim Step",
            "description": "How many levels the dimmer will change for each step.",
            "valueSize": 1,
            "minValue": 1,
            "maxValue": 99,
            "defaultValue": 3,
            "readOnly": false,
            "writeOnly": false,
            "allowManualEntry": true
        },
        "10": {
            "label": "Local Control Dim Rate",
            "description": "This sets how often the dim level will change.",
            "valueSize": 2,
            "minValue": 1,
            "maxValue": 255,
            "defaultValue": 3,
            "readOnly": false,
            "writeOnly": false,
            "allowManualEntry": true
        },
        "11": {
            "label": "ALL ON/ALL OFF Dim Step",
            "description": "How many levels the dimmer will change per step.",
            "valueSize": 1,
            "minValue": 1,
            "maxValue": 99,
            "defaultValue": 1,
            "readOnly": false,
            "writeOnly": false,
            "allowManualEntry": true
        },
        "12": {
            "label": "ALL ON/ALL OFF Dim Rate",
            "description": "This sets how often the dim level will change.",
            "valueSize": 2,
            "minValue": 1,
            "maxValue": 255,
            "defaultValue": 1,
            "readOnly": false,
            "writeOnly": false,
            "allowManualEntry": true
        }
    }
}

To Reproduce
Steps to reproduce the behavior:

Go to Build docker image

Expected behavior
Only one set of device files should be included and they should be the most current version.
Additional context
This docker was built as follows:
DOCKER_BUILDKIT=1 docker build --build-arg SRC=git-clone-src --build-arg Z2M_BRANCH=fix#23 --build-arg ZWJ_BRANCH=cc/hail --no-cache -f zwavejs2mqtt/docker/Dockerfile.contrib -t zwavejs2mqtt .

@AlCalzone I'm unsure if this lies with node-zwave-js or zwavejs2mqtt. I opened it here since I suspect it is a docker issue.

@AlCalzone I'm unsure if this lies with node-zwave-js or zwavejs2mqtt. I opened it here since I suspect it is a docker issue.

I assume it has to do with the docker build process which seems a bit funky. The double node modules happen usually when a different version of a lib is installed later with different dependencies that can't be deduplicated.

I assume it has to do with the docker build process which seems a bit funky. The double node modules happen usually when a different version of a lib is installed later with different dependencies that can't be deduplicated.

@AlCalzone I can confirm that #181 results in only one set of device files, but they are stale files. The recent changes for double-tap switches are not included.

@AlCalzone I can confirm that #181 results in only one set of device files, but they are stale files. The recent changes for double-tap switches are not included.

@robertsLando @AlCalzone I built the docker image command by command. The correct device file exists in the node-zwave-js folder upon cloning, but then there are two after I run yarn install. The zwavejs2mqtt folder has no device files, but then after yarn install it has a stale copy of the device file. So that is where the stale device files are being introduced.

@robertsLando @AlCalzone I built the docker image command by command. The correct device file exists in the node-zwave-js folder upon cloning, but then there are two after I run yarn install. The zwavejs2mqtt folder has no device files, but then after yarn install it has a stale copy of the device file. So that is where the stale device files are being introduced.

@AlCalzone @robertsLando I've run this down. It is an error introduced in #181. I posted the correction in a comment there to be incorporated.

@AlCalzone @robertsLando I've run this down. It is an error introduced in #181. I posted the correction in a comment there to be incorporated.


[Bug]: NameError: name 'os' is not defined

What happened?
This Webui is really useful, and I appreciate your contributions.
However, when I opened it today, I received the following error message:
"NameError: name 'os' is not defined".
I thought that I might have accidentally damaged the operating files during operation, so I reinstalled and deployed them on Google Drive and Google Colab.
However, the problem was not resolved after redeployment.
What should I do to fix it?
Or could you please fix the issue in the "RUN" program?
Thank you very much.
Console logs

NameError                                 Traceback (most recent call last)
 in <cell line: 64>()
62 get_ipython().system('mkdir /content/drive/MyDrive/stable-diffusion-webui-colab/stable-diffusion-webui/extensions/deforum-for-automatic1111-webui/models')
63
---> 64 if not os.path.exists(f"/content/drive/MyDrive/stable-diffusion-webui-colab/stable-diffusion-webui/models/CLIP"):
65   os.mkdir(f"/content/drive/MyDrive/stable-diffusion-webui-colab/stable-diffusion-webui/models/CLIP")
66 get_ipython().system('aria2c --console-log-level=error -c -x 16 -s 16 -k 1M https://openaipublic.azureedge.net/clip/models/b8cca3fd41ae0c99ba7e8951adf17d267cdb84cd88be6f7c2e0eca1737a03836/ViT-L-14.pt -d /content/drive/MyDrive/stable-diffusion-webui-colab/stable-diffusion-webui/models/CLIP -o ViT-L-14.pt')
NameError: name 'os' is not defined
Which colab and model(s) were you using when the error occurred?
https://github.com/camenduru/stable-diffusion-webui-colab/tree/drive
Which Public WebUI Colab URL were you using when the error occurred?
remote.moe
If you used HiRes mode when the error occurred, please provide the Hires info
No response

I think this is caused by the latest commit: https://github.com/camenduru/stable-diffusion-webui-colab/commit/58b77cfed199659ea18cf17ccd991b70496ab42d
You can try to add back the deleted part first or just add import os

You should add it to the top of the file and re-run it.

Okay, I'll try it tomorrow, the Google Colab's free server is busy now.
Thank you very much.

I think this is caused by the latest commit: 58b77cf You can try to add back the deleted part first or just add import os

This is it, thanks

Sorry, I accidently deleted import os and forgot to test. 😔

Sorry, I accidently deleted import os and forgot to test. 😔

It has returned to normal, thanks a lot!
Also thanks for the suggestion from @elvis972602  .


preview1: Update semantics of seeking on appending files

This commit updates the semantics of fd_{seek,tell} on preview1 to match native Unix when used with appending files. On Unix write claims to always update the file position pointer to the end of the file, so this commit implements that instead of the previous logic of ignoring the position update for appending files. This currently requires an extra roundtrip via stat to figure out the size of the file, but for now that seems to be the best that can be done.
Closes #7583

For the Unix behavior I'm reading this site, specifically the "NOTES" section


Save/Load certificate

Save secret key to document directory and load it on view load with name rpc.cert

Will raise PR again


action bug

action property have bug in the logic where change the value twice..

Are you able to provide any more information? Perhaps a .gif of the bug (http://recordit.co/) and a snapshot of your machine's ember  version command

here my code where my actoin defined
every one click it toggle the value twice...
  actions: {
    toggleMenu:function(value){
      console.log(value);
      }
  }
// logging
// true
// false

I'm not able to reproduce this, I pulled up the demo page put a breakpoint in the action handler and it only gets hit once per click. Closing this issue, if you can provide a more concrete example, or an example repository then I could take a look at it.


fix(plugin-vue): invalidate script module cache when it changed in hot update

Description

fixes #11008
Additional context

What is the purpose of this pull request?

[x] Bug fix
[ ] New Feature
[ ] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[x] Read the Contributing Guidelines.
[x] Read the Pull Request Guidelines and follow the Commit Convention.
[x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[x] Ideally, include relevant tests that fail without this PR but pass with it.

@sapphi-red cc

@sapphi-red  cc

Thanks! I think the code makes sense. Would you add a test for this?

Done


REST Server: refine user errors.

#807

Coverage increased (+15.4%) to 66.291% when pulling 528b239e509627a20244adcef4bcf8c13d49b0bf on qixcheng/rest-server-refine-error/user into 84a395bc7472b734a898590efb676d1b2907e0ad on qixcheng/rest-server-refine-errors.

Coverage increased (+15.4%) to 66.291% when pulling 528b239e509627a20244adcef4bcf8c13d49b0bf on qixcheng/rest-server-refine-error/user into 84a395bc7472b734a898590efb676d1b2907e0ad on qixcheng/rest-server-refine-errors.

@abuccts admin parameter back to optional


docs: added api-sync card in community plugins

I hope I'm doing this right. Let me know if not

CLA Assistant Lite bot: Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

I have read the CLA Document and I hereby sign the CLA

You can retrigger this bot by commenting recheck in this Pull Request

I have read the CLA Document and I hereby sign the CLA

Thank you!


Remove workarounds to have causal_mask in uint8 for GPT2, GPT-J and CodeGen

What does this PR do?

See #181 and #318. Booleans seems to be now supported in HCCL.
Before submitting

[ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
[ ] Did you make sure to update the documentation with your changes?
[ ] Did you write any new necessary tests?

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.


feat: enable composer to call a remote skill

Description
In this PR, I updated the bot project and enable composer to connect to a remote skill.
Note: A remote skill right now could not be a normal skill, It should have the ability to send and handle EndOfConversation type of Activity.  Refer to https://github.com/microsoft/botbuilder-dotnet/tree/master/FunctionalTests/Skills/SimpleBotToBot/EchoSkillBot to create a remote skill.
How to connect to a remote skill:
Step1: configure settings. to call a remote skill, the bot must be registered with a MicrosoftAppID and MicrosoftPassword, and also SkillHostEndpoint, which is the skill endpoint of the current bot.
"MicrosoftAppPassword": "",
"MicrosoftAppId": "",
"SkillHostEndpoint": "http://localhost:3978/api/skills/" // http://localhost:3978 is the endpoint of the caller not callee.
Step2: add SkillDialog in the bot, for example:
{
"$kind": "Microsoft.SkillDialog",
"skillAppId": "3083d5b8-a3b6-4d50-82c7-af10aa96b20c",   // the remote skill MicrosoftAppId
"skillEndpoint": "http://localhost:1205/api/messages",  // the remote skill endpoint
"activity": "Hi"
}
Note: step2 can be added in Composer UX after the UX part is ready.
Step3: Click StartBot and Test in Emulator.
This PR is only to enable Composer to call a remote skill. It doesn't include creating a "remote skill" using composer.
Task Item

fixes #696
Screenshots

@luhan2017 can we introduce the AdaptiveSkillDialog component schema in this PR as well?


[BUG] The Error Code "TokenInvalid" did not show the error message correctly

Describe the bug
The error code is "TokenInvalid" and the code did not identify. Instead, it thought that is a different error code other than "TokenInvalid" and shows the error message that is other than the it's own "TokenInvalid" error message.
To Reproduce
Steps to reproduce the behavior:

Run the code with "node ." or "npm run bot"
Don't use a real bot token (Type a random letter or number.)

Expected behavior
It should say "☒ | An error occurred: The discord bot token you've provided is not valid." '🔃 | Please try to run the code again and enter a valid token. Usage: "node ." or "npm run bot"'
Desktop (please complete the following information):

OS: Windows
Browser: Chrome
Version: 1.2.2

New update v1.2.3 should patch this bug and this bug issue will close.


Corrects description for proxy.config.http.origin_max_connections

Backport Rationale: The fixes the description for the same functionality in older ATS.

[ci approve doc]

[ci approve docs]

[approve ci docs]


Fixed #26537, #26538 -- Fixed inconsistent and duplicate form fields on inline formsets

Did a force push to redo the commit with the proper import order (didn't realize capitalization trumped alphabetical).

@timgraham, would you like me to force push the commit again with a commit message which matches the changed title?

Not necessary. I made a couple edits to the docstrings to simplify them by dropping the "Ensures that" prefix in favor of stating the expected behavior and merged in a5c8a6ce19eabd96bf3b8c7bb4fb487f53928f3b, thanks!

Sounds good, thanks.


solveFor() returns emtpy list in case the equation contains multiplication with one

How to reproduce?
const solveConversion = (
  currentUnit: string,
  currentUnitValue: number,
  targetUnit: string,
  conversionString: string,
) => {
  const conversion = nerdamer(conversionString)
  const convertedExpression = conversion
    .evaluate({ [currentUnit]: currentUnitValue })
    .solveFor(targetUnit)
  const convertedValue = convertedExpression[0].text()
  return Number(convertedValue)
}

Call this function with the following parameters:
solveConversion('x', 10, 'y', 'x = 1 * y')
Expected behaviour: The function returns 10.
If the same function is called with a different equation string e.g. 'x = 2 * y' it works.
Whenever we multiply by 1 convertedExpression variable will be an empty list.

.solveFor() does the job, but it doesn't always return an array (contrary to the docs). Check the result with
if (!Array.isArray(convertedExpression)) {convertedExpression = [convertedExpression]}
and your code should work.

@hannaszepesi did you try this with Nerdamer or Nerdamer-prime?

@hannaszepesi did you try this with Nerdamer or Nerdamer-prime?

I have used Nerdamer, sorry if I should have created the issue it in that project. :)

No, this is the right place, Nerdamer is archived. Anyway, I hope you can use the work-around, I will fix this internally when I have a little time.

But you need to use Nerdamer-prime if you want me to look at anything, I won't be debugging the old Nerdamer anymore. Thanks!

Fixed in<EMAIL_ADDRESS>


[velten-group/velten-group.github.io] Run failed: on-pull-request

I've got this problem when I tried to start an action with my user.
Problem seem to be that i has to be started as "root"
see link:
https://github.com/actions/checkout/issues/391#issuecomment-897809557

solved.


Desktop version

Implements Desktop version

Portfolio: desktop version
This branch implements the desktop version of the portfolio project.

No linters errors
Use GitHub flow
Looks like Figma design
Uses media queries for mobile version (width less than 640px), tablet version (between 641px and 991px), desktop version(between 992px and 1100px) and wide desktop version (wider then 1101px)
Uses CSS grid and Flexbox
Replicates the Figma design as much as possible


Change rail quality

Adds options to change the quality of the track.
Since this alters the geometry of the rails (by scaling it), it is possible this will affect physics.
I have yet to test this code but thought of making a PR to get some early feedback.

On an additional note, should there also be an option to change the track bed quality? Similar options (kink scale and frequency) are available in BaseType, and should be able to do exactly this.

Everything looks good to me at a glance. Would it make sense to tie track bed quality to the rail quality?

I thought about that, but I'd honestly need to see how it looks ingame. Hopefully also not too much contrast when next to switches...

There's an issue I can't figure out, but it seems to only apply the changes after going into the game and back to the menu again.

That issue is now fixed, also covers the ballast width not changing.
The EquiPointSet for the track bed and quality was being cached on Awake. When RailwayMeshGenerator searched for RailTrack objects, Awake had already been called on them and so couldn't be changed.
The whole loop was thus moved to an Awake patch on each track.


Postgres Support for ISS Key Storage

Problem
The ISS Health Checker is currently only capable of using GCP to store its keys.
Solution
Support has been added for storing keys using the existing PGSQL database instead of GCP.
Testing

Unit tests for postgres storage were added & verified to be passing
This has been deployed on WYDOT's Test VM and the logs indicate it is working.

Lets add updates to the K8s files so we support the updates to deployment in those as well.

The k8s files for this project have been updated to include the new environment variables. This is ready for re-review @drewjj

I have opened a corresponding PR for including the new environment variables in our deployment scripts.

This is ready for re-review @payneBrandon


[BUG] : Not able to downlod PDF

Describe the bug
not able to download pdf since yesterday
Product Flavor

[x] Managed (https://rxresu.me)
[ ] Self Hosted

To Reproduce

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior

Screenshots

Desktop (please complete the following information):

OS:
Browser
Version

Additional context

The issue should be fixed now, sorry for the delay and inconvenience.


Clean install: HMR broken!

When creating a new project, using Vue CLI 3, both in CLI and UI mode.
Then adding vue-cli-plugin-nativescript-vue.
HMR simply keeps reloading the whole app & relaunching.
File change detected. Starting incremental webpack compilation...
....webpack compilation details here....
Webpack compilation complete. Watching for file changes.
Webpack build done!
Preparing project...
Project successfully prepared (iOS)
Successfully transferred bundle.js on device C023E95A-72B0-46B7-AD24-4B7480318E72.
Restarting application on device C023E95A-72B0-46B7-AD24-4B7480318E72...
Successfully synced application org.nativescript.application on device C023E95A-72B0-46B7-AD24-4B7480318E72.

When adding useLegacyWorkflow: false in nsconfig.json it then loads changes but those don’t get applied until force-quitting the app on device & opening again?
Tried running:

tns run ios using default webpack
npm run debug:ios
npm run serve:ios
a custom option using npm run setup-webpack-config && tns run ios --hmr --env.development

This does not happen when setting up a new project using nativescript-vue/vue-cli-template, in which case HMR is perfect.

I've added a commit to the dev branch that will hopefully address this.
Create a new vue project as normal and then install and invoke like this to test this out:
npm install git+https://github.com/nativescript-vue/vue-cli-plugin-nativescript-vue/tree/dev
npm invoke vue-cli-plugin-nativescript-vue
Once we have some validation HMR appears to be working, i'll push to master and update the npm package.

Great! Though getting an error (repo not found):
npm ERR! Error while executing:
npm ERR! /usr/bin/git ls-remote -h -t https://github.com/nativescript-vue/vue-cli-plugin-nativescript-vue/tree/dev
npm ERR!
npm ERR! fatal: repository 'https://github.com/nativescript-vue/vue-cli-plugin-nativescript-vue/tree/dev/' not found
npm ERR!
npm ERR! exited with error code: 128

Will fiddle around a bit more now and see

Apparently npm install git+https://github.com/nativescript-vue/vue-cli-plugin-nativescript-vue.git#dev should work, installed & testing

Got this:
><EMAIL_ADDRESS>serve:ios /Users/vpiskunov/code/nativescript/canwego-ui2
> npm run setup-webpack-config && tns run ios --bundle --env.development

><EMAIL_ADDRESS>setup-webpack-config /Users/vpiskunov/code/nativescript/canwego-ui2
> node ./node_modules/vue-cli-plugin-nativescript-vue/lib/scripts/webpack-maintenance pre

copying CLI 3 version of webpack.config.js to project
Skipping node_modules folder! Use the syncAllFiles option to sync files from this folder.
Searching for devices...
Running webpack for iOS...
starting nativeConfig
Bundling application for entryPath ./main.native...
/Users/vpiskunov/code/nativescript/canwego-ui2/node_modules/webpack-cli/bin/cli.js:74
				throw err;
				^

TypeError: nsWebpack.getSourceMapFilename is not a function
    at nativeConfig (/Users/vpiskunov/code/nativescript/canwego-ui2/node_modules/vue-cli-plugin-nativescript-vue/index.js:184:37)
    at module.exports (/Users/vpiskunov/code/nativescript/canwego-ui2/node_modules/vue-cli-plugin-nativescript-vue/index.js:125:81)
    at plugins.forEach (/Users/vpiskunov/code/nativescript/canwego-ui2/node_modules/@vue/cli-service/lib/Service.js:80:7)
    at Array.forEach (<anonymous>)
    at Service.init (/Users/vpiskunov/code/nativescript/canwego-ui2/node_modules/@vue/cli-service/lib/Service.js:79:18)
    at Object.<anonymous> (/Users/vpiskunov/code/nativescript/canwego-ui2/webpack.config.js:9:11)
    at Module._compile (/Users/vpiskunov/code/nativescript/canwego-ui2/node_modules/v8-compile-cache/v8-compile-cache.js:192:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (/Users/vpiskunov/code/nativescript/canwego-ui2/node_modules/v8-compile-cache/v8-compile-cache.js:161:20)
    at WEBPACK_OPTIONS (/Users/vpiskunov/code/nativescript/canwego-ui2/node_modules/webpack-cli/bin/utils/convert-argv.js:115:13)
    at requireConfig (/Users/vpiskunov/code/nativescript/canwego-ui2/node_modules/webpack-cli/bin/utils/convert-argv.js:117:6)
    at /Users/vpiskunov/code/nativescript/canwego-ui2/node_modules/webpack-cli/bin/utils/convert-argv.js:124:17
    at Array.forEach (<anonymous>)
    at module.exports (/Users/vpiskunov/code/nativescript/canwego-ui2/node_modules/webpack-cli/bin/utils/convert-argv.js:122:15)
    at yargs.parse (/Users/vpiskunov/code/nativescript/canwego-ui2/node_modules/webpack-cli/bin/cli.js:71:45)
    at Object.parse (/Users/vpiskunov/code/nativescript/canwego-ui2/node_modules/webpack-cli/node_modules/yargs/yargs.js:567:18)
    at /Users/vpiskunov/code/nativescript/canwego-ui2/node_modules/webpack-cli/bin/cli.js:49:8
    at Object.<anonymous> (/Users/vpiskunov/code/nativescript/canwego-ui2/node_modules/webpack-cli/bin/cli.js:375:3)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at Object.<anonymous> (/Users/vpiskunov/code/nativescript/canwego-ui2/node_modules/webpack/bin/webpack.js:156:2)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:754:12)
Executing webpack failed with exit code 1.
npm ERR! file sh
npm ERR! code ELIFECYCLE
npm ERR! errno ENOENT
npm ERR! syscall spawn
npm ERR<EMAIL_ADDRESS>serve:ios: `npm run setup-webpack-config && tns run ios --bundle --env.development`
npm ERR! spawn ENOENT

Will retry creating a new project, as I've upgraded vue-cli & cli-plugin-babel & cli-plugin-eslint in this one

Amazing! It worked on the clean project.
Another issue - possibly related - after installing the plugin, HMR is also broken on serve:web - due to the plugin installing an addition dependency webpack instance.
Symptoms:
[HMR] Waiting for update signal from WDS...
[HMR] Waiting for update signal from WDS...

& Page reload +RangeError on update:
Uncaught RangeError: Maximum call stack size exceeded
at hotAddUpdateChunk (VM4024 app.js:979)
at webpackHotUpdateCallback...

I've found the workaround, which is to create project, install plugin & then:
npm rm @vue/cli-service
npm i --save-dev @vue/cli-service

Perhaps it's a simple fix, by ensuring the plugin doesn't add a separate webpack dep in package.json? I'm just guessing, but think there's the assumption of webpack being already installed when project requires vue-cli.

Glad you got it mostly working.  Sorry about giving you the incorrect link for the install.  That's what get for trying to do it from my phone.
I'm not sure about why webpack would be doing that.  We have webpack as a dev dependency of the plugin so it shouldn't be installing a second copy of it as far as I know.
Can you show me what you have globally installed:  npm list -g --depth=0

Global npm list:
├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>
Though I think what's relevant is npm list inside project:
npm ls webpack
├─┬<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>

Actually the workaround is not just reinstalling @vue/cli-service, but also webpack:
npm rm webpack
npm i --save-dev<EMAIL_ADDRESS>npm rm @vue/cli-service
npm i --save-dev @vue/cli-service

Notice webpack uses<EMAIL_ADDRESS>- important to fix the issue.
Without the version specified, the issue persists.
During the installation, plugin adds following to package.json:
 "webpack": "^4.29.6",
Which causes it to install @4.32.2. Before adding the plugin, there is no direct dependency in package.json (it's installed in vue/cli-service as a dep, using the @4.28.4)

Perhaps there might be a way to set the version, by first running a hook (pre-install or something?) to detect current vue-cli's webpack version?

this project will need to try and make sure the version of webpack being included as a dev-dependency matches what the vue-cli is currently pinned to.

Will test on #dev and let you know

For some reason npm run serve:web spat out this:
 ERROR  Failed to compile with 1 errors3:37:57 PM

 error  in ./src/main.js

Module build failed (from ./node_modules/eslint-loader/index.js):
Error: You need to provide a target platform!
    at module.exports (/Users/vpiskunov/code/nativescript/canwego/node_modules/vue-cli-plugin-nativescript-vue/index.js:116:11)
    at /Users/vpiskunov/code/nativescript/canwego/node_modules/@vue/cli-service/lib/Service.js:80:7

That was when it ran from Vue UI. Not sure what caused it. First running serve:web was fine, but if ran serve:ios first, then this was triggered.
Tried adding --env.development --env.web to the serve:web command in package.json. Running from UI, still had that error. Then tried from CLI, error vanished. Then removed --env.development --env.web back from the serve:web and it's still working in CLI.
UI works too after refresh. No clues so far.

Another thing - on the webpack dependency resolution, I'm suspecting the dual instance may occur as this plugin adds webpack to the project package.json, rather than it's own (node_modules/vue-cli-plugin-nativescript-vue/package.json).
Perhaps moving the dep inside might help?

I cannot reproduce the UI issue. However, I do know that with the UI, it will sometimes mess with the parameters being passed to the CLI behind the scenes.  What you can do is tell the UI to not set the environment based on what it thinks it should be, but instead, to follow what's explicitly set in the npm script.
To do this:

Click the Parameters button next to the Run Task button.
In Specify env mode dropdown, choose (unset)
Click Save

All that said, I just pushed a commit to dev to move the webpack dependency out of the generated project and into the devDependencies of the plugin itself.  Let's see if this is works as you suggested in your most recent comment.

Same error keeps (UI bug)
Seems it's running vue-cli-service serve --mode development.web --dashboard - this is the same, even after I've used the (unset) in the dropdown.
Here's a full log:
$ vue-cli-service serve --mode development.web --dashboard
starting webConfig

 INFO  Starting development server...

clean-webpack-plugin: /Users/vpiskunov/code/nativescript/test-plugin-patch-dev/dist/**/* has been removed.

 12% building 20/22 modules 2 active ...server/node_modules/strip-ansi/index.jsError resolving webpackConfig Error: You need to provide a target platform!
    at module.exports (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/vue-cli-plugin-nativescript-vue/index.js:116:11)
    at plugins.forEach (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:80:7)
    at Array.forEach (<anonymous>)
    at Service.init (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:79:18)
    at Object.<anonymous> (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/webpack.config.js:9:11)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at Object.exports.resolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-import-resolver-webpack/index.js:69:27)
    at v2 (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:94:23)
    at withResolver (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:99:16)
    at fullResolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:116:22)

Error resolving webpackConfig Error: You need to provide a target platform!
    at module.exports (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/vue-cli-plugin-nativescript-vue/index.js:116:11)
    at plugins.forEach (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:80:7)
    at Array.forEach (<anonymous>)
    at Service.init (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:79:18)
    at Object.<anonymous> (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/webpack.config.js:9:11)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at Object.exports.resolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-import-resolver-webpack/index.js:69:27)
    at v2 (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:94:23)
    at withResolver (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:99:16)
    at fullResolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:116:22)
Error resolving webpackConfig Error: You need to provide a target platform!
    at module.exports (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/vue-cli-plugin-nativescript-vue/index.js:116:11)
    at plugins.forEach (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:80:7)
    at Array.forEach (<anonymous>)
    at Service.init (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:79:18)
    at Object.<anonymous> (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/webpack.config.js:9:11)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at Object.exports.resolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-import-resolver-webpack/index.js:69:27)
    at v2 (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:94:23)
    at withResolver (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:99:16)
    at fullResolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:116:22)
Error resolving webpackConfig Error: You need to provide a target platform!
    at module.exports (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/vue-cli-plugin-nativescript-vue/index.js:116:11)
    at plugins.forEach (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:80:7)
    at Array.forEach (<anonymous>)
    at Service.init (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:79:18)
    at Object.<anonymous> (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/webpack.config.js:9:11)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at Object.exports.resolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-import-resolver-webpack/index.js:69:27)
    at v2 (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:94:23)
    at withResolver (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:99:16)
    at fullResolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:116:22)
Error resolving webpackConfig Error: You need to provide a target platform!
    at module.exports (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/vue-cli-plugin-nativescript-vue/index.js:116:11)
    at plugins.forEach (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:80:7)
    at Array.forEach (<anonymous>)
    at Service.init (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:79:18)
    at Object.<anonymous> (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/webpack.config.js:9:11)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at Object.exports.resolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-import-resolver-webpack/index.js:69:27)
    at v2 (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:94:23)
    at withResolver (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:99:16)
    at fullResolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:116:22)
Error resolving webpackConfig Error: You need to provide a target platform!
    at module.exports (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/vue-cli-plugin-nativescript-vue/index.js:116:11)
    at plugins.forEach (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:80:7)
    at Array.forEach (<anonymous>)
    at Service.init (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:79:18)
    at Object.<anonymous> (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/webpack.config.js:9:11)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at Object.exports.resolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-import-resolver-webpack/index.js:69:27)
    at v2 (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:94:23)
    at withResolver (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:99:16)
    at fullResolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:116:22)
Error resolving webpackConfig Error: You need to provide a target platform!
    at module.exports (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/vue-cli-plugin-nativescript-vue/index.js:116:11)
    at plugins.forEach (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:80:7)
    at Array.forEach (<anonymous>)
    at Service.init (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:79:18)
    at Object.<anonymous> (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/webpack.config.js:9:11)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at Object.exports.resolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-import-resolver-webpack/index.js:69:27)
    at v2 (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:94:23)
    at withResolver (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:99:16)
    at fullResolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:116:22)
Error resolving webpackConfig Error: You need to provide a target platform!
    at module.exports (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/vue-cli-plugin-nativescript-vue/index.js:116:11)
    at plugins.forEach (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:80:7)
    at Array.forEach (<anonymous>)
    at Service.init (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:79:18)
    at Object.<anonymous> (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/webpack.config.js:9:11)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at Object.exports.resolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-import-resolver-webpack/index.js:69:27)
    at v2 (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:94:23)
    at withResolver (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:99:16)
    at fullResolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:116:22)
Error resolving webpackConfig Error: You need to provide a target platform!
    at module.exports (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/vue-cli-plugin-nativescript-vue/index.js:116:11)
    at plugins.forEach (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:80:7)
    at Array.forEach (<anonymous>)
    at Service.init (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:79:18)
    at Object.<anonymous> (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/webpack.config.js:9:11)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at Object.exports.resolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-import-resolver-webpack/index.js:69:27)
    at v2 (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:94:23)
    at withResolver (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:99:16)
    at fullResolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:116:22)
Error resolving webpackConfig Error: You need to provide a target platform!
    at module.exports (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/vue-cli-plugin-nativescript-vue/index.js:116:11)
    at plugins.forEach (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:80:7)
    at Array.forEach (<anonymous>)
    at Service.init (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:79:18)
    at Object.<anonymous> (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/webpack.config.js:9:11)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at Object.exports.resolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-import-resolver-webpack/index.js:69:27)
    at v2 (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:94:23)
    at withResolver (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:99:16)
    at fullResolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:116:22)

 87% record chunks RecordIdsPlugin ERROR  Failed to compile with 1 errors4:11:45 PM

 error  in ./src/main.js

Module build failed (from ./node_modules/eslint-loader/index.js):
Error: You need to provide a target platform!
    at module.exports (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/vue-cli-plugin-nativescript-vue/index.js:116:11)
    at plugins.forEach (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:80:7)
    at Array.forEach (<anonymous>)
    at Service.init (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/lib/Service.js:79:18)
    at Object.<anonymous> (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/@vue/cli-service/webpack.config.js:9:11)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at Object.exports.resolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-import-resolver-webpack/index.js:69:27)
    at v2 (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:94:23)
    at withResolver (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:99:16)
    at fullResolve (/Users/vpiskunov/code/nativescript/test-plugin-patch-dev/node_modules/eslint-module-utils/resolve.js:116:22)

 @ multi (webpack)-dev-server/client?http://<IP_ADDRESS>:8080/sockjs-node (webpack)/hot/dev-server.js ./src/main

But the HMR seems fixed(web)! no double message [HMR] and modules seem to reload correctly!
Hopefully last thing: eslint is angry on ~ being used in paths like import App from '~/App.vue' .
It's fine when @ is used, but `Unable to resolve path to module (import/no-unresolved.
Perhaps it's a separate issue, but I'm guessing there is some quick-fix you're using?
After installing latest #dev:
npm ls webpack
<EMAIL_ADDRESS>/Users/vpiskunov/code/nativescript/test-plugin-patch-dev
├─┬<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>deduped
├─┬<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>deduped
└─┬<EMAIL_ADDRESS>  └──<EMAIL_ADDRESS>

Ok, I went digging down the UI bug rabbit-hole.
The issue seems to be from the linter. Due to vue project's default settings of "lint on save", it runs the linter in any case where it starts the server, or a file has changed.
It's weird that it works sometimes - I'd be guessing there is a few invocation mechanisms for the linter.
Looking at package.json, npm run lint would call vue-cli-service lint without any options/env.
When I ran it directly npx vue-cli-service lint, it failed in the same style:

But when running npx vue-cli-service lint --mode development.web, it works fine.
I've just amended the lint option in package.json - works so far. Will re-confirm soon. If this is it, perhaps we need to add this to generator, to have
"lint": "vue-cli-service lint --mode development.web" in package.json

The webpackConfig error above is being generated from here:
https://github.com/nativescript-vue/vue-cli-plugin-nativescript-vue/blob/1fbbfe4bc00507002b864b3f9c60fad41ed56756/index.js#L116
What that tells me is that for some reason for you, the UI is interfering with the env variable in some way.  It's not happening to me, so there is something in your setup that I haven't accounted for when trying to parse out env.
I had just uncommented that error check out in the dev branch only as I thought things had been fixed that were previously causing this to fail.  That error check is in the nativescript-dev-webpack project's Vue template so that is why I left it in.  Long term, i'd like to have it there, but short term, I can comment it back out so that it's doesn't trip you up.
However, the better long term solution is to try and figure out why it's causing you an issue.  Let me know if you are willing to continue to troubleshoot why it's failing that error check and I'll give you some guidance on what you can do to help me troubleshoot without you having to create a new project and install the dev branch everytime.

Sure, I can help figure this out. Let me know what the flow is - and yes, I have like 8 repos already from fresh installs ;)
The issue didn’t happen every time - it seems to have been intermittent, but latest project was giving the error every time.
It’s weird, as whenever it happened from UI-launched serve:web, if I tried running from CLI, no error and works every time.
I’ve already tried enabling the option “Override hard coded arguments” in the UI. Yet I got a feeling as if that didn’t quite change anything.
Changing lint command in package.json seems to have worked though - at least in my testing.
I don’t think disabling the check is the best option - let’s not do that for the time being. If it’s being tripped - then seems the env is not passed around where it should be & so it might end up silently breaking another part of the deploy/flow.

Do you have any suggestion on the ~ imports?
See comment above: https://github.com/nativescript-vue/vue-cli-plugin-nativescript-vue/issues/16#issuecomment-497713708 ?

ok....i'm going to make one more commit to dev that includes some added console logging that will hopefully help us understand they the env variable seems to be having an issue.  I've also changed one of the if statements a bit to be more accurate in terms of what's really be checked for.
after this commit, we can continue further troubleshooting by directly editing the plugin inside of node_modules.
As for the ~ imports.  I'm not sure why it's being caught.  However, ~ and @ are essentially the same thing from a pathing perspective.  We've aliased them to ./src or ./app depending on if it's a code-sharing project or not.
So, if you want to change all of the ~ to @ for imports, then that should in theory work.  I'm beginning to wonder if the fact you have eslint and associated plugins installed globally is interfering with something in the project itself.  I don't have eslint installed globally and just go with the local copy of eslint and associated plugins that vue-cli puts in.

I know the ~ & @ should resolve to the same paths, but after looking into vue’s webpack config(under node_modules), I only found it has the @ alias defined, but not ~.
To see it, do a search in all files under node_modules/@vue for '@, as can’t remember the exact file.
Your guess about global ESLint being in the way could be going the right way, but I’ve tested switching between global & local (in Atom’s linter-eslint settings menu), and it gave same results.
I did previously have an issue with it using global(without me realising), and the global eslint was outdated, causing random rule not defined etc. Now that seems to be solved.
I could just replace all the ~ to @‘s, but don’t understand what’s causing the behaviour.
This also happens both in Atom & VScode, so not editor/linter specific.
On previous versions of the package(e.g. non-dev branch) adding:
"settings": {
        "import/resolver": {
            "webpack": {
                "config"<EMAIL_ADDRESS>            }
        }
    }

Was enough to fix this. Doesn’t work now however, and also I’ve tried through adding to vue.config.js:
configureWebpack: {
    resolve: {
      alias: {
        '~': path.resolve(__dirname, 'src/'),
      },
    },
  },

Ah man, can’t wait to have no issues on tooling.. running behind schedule with all these getting in the way 😬
I’ll pull your latest commit in the morning and give it a spin, thanks for looking into this!

Ok, so it gave the error straight after install in clean project. Log in the gist:
https://gist.github.com/vpiskunov/10b24561ae7947289c8216ab4d76df21
The env is first populated / normal in vue cli - flags - , but empty / undefined at
tns cli - flags -  []
env -  {}
platform -  undefined

diff on full project gave only node_modules/.cache changed.
So... the cache files are to blame. When running a clean project, the cache directory is only containing eslint-loader which is empty.
This is the state both after installing the plugin, as well as after running serve:web from UI and it erroring out on provide a target platform.
I then ran the project from command line - it ran successfully, at which point a diff of that project & it's cloned directory pre-successful-run, gave the following diff:
diff --recursive test-plugin-diff test-plugin-diff-pre-run/
Only in test-plugin-diff/node_modules/.cache: babel-loader
Only in test-plugin-diff/node_modules/.cache/eslint-loader: 189519d40df8d8b562f6a62e691e5087f18b1e52.json.gz
Only in test-plugin-diff/node_modules/.cache/eslint-loader: 43b99531851d67662fd0f64ab192114d6cb51f2e.json.gz
Only in test-plugin-diff/node_modules/.cache/eslint-loader: 49916036c69b6b22fd1801222d3a04c0f606e9aa.json.gz
Only in test-plugin-diff/node_modules/.cache/eslint-loader: 4cd258c825f2d13a6dc06df50dc792a4f3bcfb37.json.gz
Only in test-plugin-diff/node_modules/.cache/eslint-loader: dee39e11e5227e8f8355697947c90aaf5553cf8a.json.gz
Only in test-plugin-diff/node_modules/.cache/eslint-loader: e017093038ad96ea1b0d6447fd9f6c0e9418f252.json.gz
Only in test-plugin-diff/node_modules/.cache/eslint-loader: ea082e9f0a7b79a4575d7603c127b630f2bfe343.json.gz
Only in test-plugin-diff/node_modules/.cache: vue-loader

I had then verified, that deleting those cache files, has made the UI-run produce the error again.

Well...I just have not been able to reproduce this. I've tried on almost a dozen different test projects while using different versions of node, npm, nativescript, etc.  I've tried deleting the folders in .cache as you mention and it runs from the UI everytime, first time without a problem.
i don't know why it's doing what it's doing for you.  However, because you do have a workaround where you can run it from the cli first, i'm going to let this issue sit open and we'll see if others end up having the same sort of issues as you.
I'm going to take the additional logging back out of the dev branch and then move it to production as version 0.0.16.

Sure, lets do that.
Food for thought: https://github.com/vuejs/vue-cli/issues/1128#issuecomment-438123411 seems related, though no fix

I did fix an env issue that I pushed in 0.1.2 yesterday where for native projects it wasn't reading all the environmental variables correctly when -- --hmr was being added.
I found that my .env.development.android wasn't being included in my build.  Spent 2 hours trying to troubleshoot why all of a sudden I couldn't connect to any of my API's and come to find out it was because the URLs defined in that file were all coming up undefined
Not sure if that will help or not with the initial UI serve or not, but you can try it out and see.

Nope, didn't change anything. I've also just tried by copying .env.development.web file to .env - as that should always be loaded, no matter what environment is set during the run, and then overwritten by specific .env.[mode] from --mode option. Didn't work too.
Also tried adding this to vue.config.js, which is another way to add .env variables (allows for computed values, as per Vue CLI docs here)
process.env.NODE_ENV = 'development';
process.env.VUE_APP_PLATFORM = 'web';
process.env.VUE_APP_MODE = 'web';

module.exports = {
  // config
};

No luck either.

Fixed in #24 - setting platform = 'web' if after all methods of retrieving platform is still not set.
This takes on the assumption that npm run serve:ios & npm run serve:android etc (NS-based) commands always set the .env platform variables correctly - which they do, as otherwise I'd be getting same error on those - but I don't

Fixed in #24 - setting platform = 'web' if after all methods of retrieving platform is still not set.
This takes on the assumption that npm run serve:ios & npm run serve:android etc (NS-based) commands always set the .env platform variables correctly - which they do, as otherwise I'd be getting same error on those - but I don't

@vpiskunov Any word on when this fix will be implemented? Definitely not trying to rush you, but we're looking at using this plugin for a project at work and we're bumping into this issue, so I just want to see if this is something we can use at this time or in the near future.
Again, I'm sure you have other things to do, so if this is still going to take a bit or the solution isn't quite there, absolutely no worries!

I've just released 0.2.0 of the plugin to npm. This includes NS 6.1.0 and NS-Vue 2.4.0.  It also includes PR #24 that addressed the platform setting.
Try it again and let me know if this addresses things.

So...my mistake.  I somehow inadvertently didn't get PR 24 into 0.2.0.  Issue with my local copy of the plugin.  I've added it back and have released 0.2.1

Hey @AlexanderSix
Have you tried the workaround described by running npm run serve:iOS from the terminal instead of using the Vue UI?
If that works, you only have to do it from terminal sometimes, when getting the error, as after that it works from UI too.
Let me know


rgw: admin/README.md shows incorrect usage of co.GetUser(...)

README.md has incorrect usage of co.GetUser(...)
co.GetUser(..) has parameters of type context and User, but the example shows that we need to use a context and a string  like this, co.GetUser(context.Background(), "admin"), which is incorrect.
reference

Thanks. @rakeshgm would you be interested in contributing a doc fix this yourself?  CCing @leseb for awareness.

sure @phlogistonjohn , i can contribute, there is one other issue that is blocking me from testing this. once I get clarity on this. I will send the patch. #619

fix is in this PR  https://github.com/ceph/go-ceph/pull/620


Ace-Support boxes

-can't be recycled.
-ace-advanced medical box is empty.

Fixed and implemented for 0.95


Infer symbol relationship for object literals property in return statement

Previously, scip-typescript didn't infer correct relationships between the object literel property and interface property in return statements like below:
interface Configuration {
  property: number
}

export function returnStatement(): Configuration {
  return {
    property: 42,
  }
}

This commit fixes this specific issue. This commit also adds a test case for a situation where scip-typescript doesn't infer the relationship today but tsserver does. We should fix that in the future.
Test plan
See updated snapshot tests.

Realized the previous logic failed as soon as you didn't have a toplevel return statement. I have a half-baked idea how to clean up the logic so that we pass down the inferred type while traversing the AST avoiding the need to look up parents (which is typically a sign of a broken abstraction IME).


tainted views

Sorry for bothering you ...
I was browsing through your code and I realized, you mark views as tainted on some occasions, but there is nowhere a condition to check if some view is tainted. See search. So you always redraw all border all the time? Or have I overlooked something?
Thank you for your time and have a nice day ... always ;)

Hi there! Maybe I'm a little late but anyway...
Have a look at this:
https://github.com/jroimartin/gocui/blob/c055c87ae801372cd74a0839b972db4f7697ae5f/view.go#L297
When a View is marked as tainted, its ViewBuffer needs to be computed again (this is the viewLines slice).

Ahaaa ... so I trusted GitHub search too much ... it doesn't show all results.
My fault. Sorry.
Consider this not a bug.


[FLINK-17258][tests] Enabling unaligned checkpoint in all tests by default

What is the purpose of the change
To harden unaligned checkpoints as quickly as possible, we want to enable it by default for all tests similarly how we did it for credit-based flow control network stack.
Brief change log

Checking system property "execution.checkpointing.unaligned" if no explicit configuration option has been used.
Setting system property "execution.checkpointing.unaligned"="true" for maven surefire for all unit and IT tests.
Setting the configuration "execution.checkpointing.unaligned"="true" for all e2e tests.

Verifying this change
Affects only tests.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

Based on https://github.com/apache/flink/pull/11814 , so ignore first commit.

Thanks for the feedback @pnowojski . I forked out https://github.com/apache/flink/pull/12739 for API change and handling of inconsistent configuration. This PR is based on it, so that PR must be merged before this.


Formsheet Width is not proper some time

I am using formsheet to present users list which works fine but some time the width of formsheet shrink check the following image.
screen shot
It happens only some time other time the width is fine but i am unable to find why this is happening.

Duplicate of the issue I opened almost a month ago.
https://github.com/rushisangani/RSSelectionMenu/issues/48

@d33pak-s1ngh this is fixed in version 5.3.1


How to actually export?

I installed the *.lua extension in the respective folder. Other plugins work. But I cannot find a way to actually export the "Buchungen". I tried right click on selected "Buchungen", right click on the account in the left panel, searched in all menus, but with no success.
How can I actually export the selected "Buchungen"?

Select the items to be exported
Select Menu "Account -> Export Transactions" ("Konto -> Umsätze exportieren")
Select "Buchungssätze (.csv)" from the "Format" popup meni
Choose a file name to export
Click export

Make sure all transactions have a proper category and metadata assigned

Ah, perfect. That'd be a good addition for the readme, actually.


Easy way to customize the suffix

Feature description
A simple method to customize the suffix of the fold.
You can change the suffix through the fold_virt_text_handler, but it would be nice to have a simpler interface for simple ricing needs.
Describe the solution you'd like
Something like:
require('ufo').setup({
    suffix = "▽"
})

Additional context
No response

https://github.com/kevinhwang91/nvim-ufo/issues/88
h foldtext() , you will find that still need to expose v:foldstart and v:foldend context. fold_virt_text_handler sightly respect to foldtext().

Hmm, I'm not sure what you mean, but couldn't you just add something like this to the default handler:
function Decorator.defaultVirtTextHandler(virtText, lnum, endLnum, width, truncate, ctx)
    local newVirtText = {}
-   local suffix = ' ⋯ '
+   local suffix = config.suffix or ' ⋯ '
    local sufWidth = fn.strdisplaywidth(suffix)
    ...

I don't really mind copying the default handler to my config and changing it manually, but a cleaner config interface would certainly be nice.


Fix generated code for unknown type

Hi @CarterGrimmeisen, this PR fixes #34 I reported earlier.

Ha, I see you just fixed it!


Make next button green, cancel button red

The buttons were the opposite colours to what I expected. This  PR swaps the colours to improve usability.

Nice!


Fix question 145

Hey. It seems even this fix would not help, because correct answer id B.
Check bellow:
$ var person = {
  name: "Lydia Hallie",
  age: 21
}
$ > {name: "Lydia Hallie", age: 21}
$ person[Symbol.iterator]= function *g() { yield Object.values(this) }
$ > ƒ *g() { yield Object.values(this) }
$ [...person]
$ > [Array(2)]
       0: (2) ["Lydia Hallie", 21]
       length: 1
       __proto__: Array(0)

And correct answer B would work like:
$ var person = {
  name: "Lydia Hallie",
  age: 21
}
$ > {name: "Lydia Hallie", age: 21}
$ person[Symbol.iterator]= function *g() { for (let x in this) yield this[x] }
$ > ƒ *g() { for (let x in this) yield this[x] }
$ [...person]
$ > (2) ["Lydia Hallie", 21]
       0: "Lydia Hallie"
       1: 21
       length: 2
       __proto__: Array(0)

Hey. It seems even this fix would not help, because correct answer id B.
Check bellow:
$ var person = {
  name: "Lydia Hallie",
  age: 21
}
$ > {name: "Lydia Hallie", age: 21}
$ person[Symbol.iterator]= function *g() { yield Object.values(this) }
$ > ƒ *g() { yield Object.values(this) }
$ [...person]
$ > [Array(2)]
       0: (2) ["Lydia Hallie", 21]
       length: 1
       __proto__: Array(0)

And correct answer B would work like:
$ var person = {
  name: "Lydia Hallie",
  age: 21
}
$ > {name: "Lydia Hallie", age: 21}
$ person[Symbol.iterator]= function *g() { for (let x in this) yield this[x] }
$ > ƒ *g() { for (let x in this) yield this[x] }
$ [...person]
$ > (2) ["Lydia Hallie", 21]
       0: "Lydia Hallie"
       1: 21
       length: 2
       __proto__: Array(0)

Hey. In your examples you used yield but you should use yield*

Yep, you are right (I miss this nuance), but then no right answer in question.


Fix typo in cache-levels documentation

Oh dang it, good catch! In italian viceversa can be spelled without a space, good catch!
Thanks.

This was totally minor and mostly irrelevant. I just thought I could share it anyway as I noticed it ;)

And I'm glad you did, every contribution is very much appreciate!


⚠ Slack has degraded performance

In 8dd011d, Slack (https://status.slack.com/api/v2.0.0/current) experienced degraded performance:

HTTP code: 200
Response time: 41 ms

Resolved: Slack performance has improved in 5ee82ab after 4 hours, 25 minutes.


HW acceleration

how do i turn on hardware acceleration

Hardware accelerated decoders are already preferred and used (if available) by default (in ExoPlayer).


Run the validate doc update function through couch_eval

Overview
With Couchdb on fdb, we want all javascript and language specific functionality to run through couch_eval.
This moves the validate_doc_update check to run through couch_eval instead of going directly through couch_query_servers.
Testing recommendations
All existing tests should pass.
Related Issues or Pull Requests

Checklist

[x] Code is written and works correctly
[x] Changes are covered by tests
[ ] Any new configurable parameters are documented in rel/overlay/etc/default.ini
[ ] A PR for documentation changes has been made in https://github.com/apache/couchdb-documentation

Could you add reference to https://github.com/cloudant-labs/ateles/pull/29 in Related Issues or Pull Requests section in the PR description?


multisig : Wallet is inactive

I have deployed and run the multisig debot. Then I have answered  0:5d3d540ebeb545be95ad05e22efc0ad3cb2e0172884fba2cedfde445ef16ebf9 to the question 'Which wallet do you want to work with?'. It is a demo wallet mentionned in this section https://github.com/tonlabs/debots#how-to-try-debot. This wallet opens in Surf.
The problem is that the debot answers "Wallet is inactive".

Please check that you deploy debot in net.ton.dev instead default <IP_ADDRESS> in deploy debot script

Thank you!


added condition recommendation task

Hello @san2ds , thanks for your PR. Could I ask the motivation of the task?

Hi,
We have used this task to create dataset using feature keys - Condition
history, Procedure and prescription from past visit history of a patient.
We have used that in our Multilabel Prediction model (Model 1) of diagnosis
code of next visit using Pyhealth.
Please find our github link of final project submission:
https://github.com/jt-alvarez/CS598-DLH-Project/blob/main/DL4H_Team_152_combine.ipynb
We have used that to reproduce result of paper TransformEHR.
https://www.nature.com/articles/s41467-023-43715-z
In addition to that task we have created 4 more tasks also. We have not
created a PR on that yet. Please let me know if you think we should add PR
for those other tasks also.
Task Function 1 - Task Function for diagnosis recommendation of future
visits using past visit's Condition history, Procedure and prescription
history.
Task Function 2 - Task Function for diagnosis recommendation using only
history of diagnosis from past visits.
Task Function 3 - Task Function for diagnosis recommendation related to
Pancreatic Cancer using only history of diagnosis from past visits.
Task Function 4 - Task Function for diagnosis recommendation related to
Pancreatic Cancer using history of Diagnosis, Procedure and Drugs
Prescribed from past visits.
Task Function 5 - Task Function for diagnosis recommendation related to
Pancreatic Cancer using only history of diagnosis from past visits. This
will add data samples with and without Pancreatic Cancer Diagnosis. So that
model performance will be done more accurately.
Thank you!
Santu Banerjee
On Thu, May 9, 2024 at 4:10 PM Chaoqi Yang @.***> wrote:

Hello @san2ds https://github.com/san2ds , thanks for your PR. Could I
ask the motivation of the task?
—
Reply to this email directly, view it on GitHub
https://github.com/sunlabuiuc/PyHealth/pull/292#issuecomment-2103425236,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVIJQHNOCZ2EX37MZ5QVZ3TZBPQ43AVCNFSM6AAAAABHMGXPLGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBTGQZDKMRTGY
.
You are receiving this because you were mentioned.Message ID:
@.***>

Thanks for your comments.


Request: Publish as crate

More a wish than request
Publish erbium at https://crates.io

I thought I had?  https://crates.io/crates/erbium
Is there something else I should be doing?

On Mon, Nov 30, 2020 at 12:24:19PM -0800, Perry Lorier wrote:

I thought I had?  https://crates.io/crates/erbium

Yes, it is there.
I don't known why my previous search at  crates.io didn't show it.

Is there something else I should be doing?

:-)
Allow me to close this issue.
This is an email response.
(github.com login scheduled for later)


Pagination in a collection is not working properly for multilingual asset titles

Example:
I have a collection with 109 files, every file has its title translated to 6 languages. If I switch to the collection in the Sulu Admin it shows me "Items per page: 4". If I change the items per page to 50, the drop down shows "Items per page: 9" and 9 items are shown.
It seems that the query to fetch the asset is missing a limitation on the language.

@sabinebaer we have already fixed that in the newest HOTFIX release https://github.com/sulu-io/sulu-standard/releases/tag/1.1.1 could you please check if it is really fixed? if not reopen this issue


Flushall nodes

Hi,
Is there a neat way to call flushall (and other functions without keys) on all the masters of my cluster?
Thanks

Hello,
No, for now only commands related to particular keys are supported.
I will add this feature to the wish list in my brain ))


Consider using "extensionButton.prominentBackground"

Buttons and badges in extension view has green color that doesn't go together with most of the themes:

It would be nice to use it in themes (not necessarily the same color as badges and input focus, just something that's not stands out in theme context).

I did take a look at this and wasn't sure if keeping the green uniform might be better. Maybe I'll try pushing a build with the button as focus color and see if anyone complains. :) - Will keep this issue as a to do for tonight. Thanks again bud!

Oh hey. Where did the settings santa hat come from? 😂

Insider build is closer to holidays than stable build 🎉

Have added to 1.1.1, thanks mate. :)


[EUWE] - Fix image for orchestration_stack textual summary

Follow-up for euwe backport of https://github.com/ManageIQ/manageiq/pull/12954
Links [Optional]
https://github.com/ManageIQ/manageiq/pull/12954

@miq_bot assign @simaishi

Sorry, my bad backport caused this..  @himdel can you review/approve?

Consider this approved :-) (on mobile now, will mark so when I get home..)

Sorry for the spam, but I'm just tweaking the title to see if the bot fixes it ;)