Problems with version 1.0.16

Hi @phillwiggins ,
I am not able to use version 1.0.16.
I update pubspec.yaml and get get packages. The following error appears:
dependencies:
  flutter:
    sdk: flutter
  parse_server_sdk: ^1.0.16

Error:
Running "flutter packages get" in parse_test ...
Because parse_tes depends on parse_server_sdk ^ 1.0.16 which does not match any versions, version solving failed.

On the page https://pub.dartlang.org/packages/parse_server_sdk appears version 1.0.15.

Hey Rodrigo
It is not released just yet. I had multiple PR's going straight to master,
hence the merge.
The date query still doesn't work even though the JSON request looks
correct. Will release once that has been fixed.
On Mon, Mar 18, 2019, 11:48 Rodrigo de Souza Marques <
<EMAIL_ADDRESS>wrote:

Hi @phillwiggins https://github.com/phillwiggins ,
I am not able to use version 1.0.16.
I update pubspec.yaml and get get packages. The following error appears:
dependencies:
flutter:
sdk: flutter
parse_server_sdk: ^1.0.16
Error:
Running "flutter packages get" in parse_test ...
Because parse_tes depends on parse_server_sdk ^ 1.0.16 which does not match any versions, version solving failed.
On the page https://pub.dartlang.org/packages/parse_server_sdk appears
version 1.0.15.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/phillwiggins/flutter_parse_sdk/issues/127, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AHgn3uXbHTB1V9Ur2pGU5fwP9Y6kxw1Lks5vX30KgaJpZM4b5lnn
.

@rodrigosmarques you can test it using:
  # parse_server_sdk: ^1.0.15
  parse_server_sdk:
    git: https://github.com/phillwiggins/flutter_parse_sdk.git
    ref: release/v1.0.16 # some-branch-name

I'm not in front of my computer to test at the moment but can push the
update remotely.
On Mon, Mar 18, 2019, 12:08 Daniel Bjørnbakk<EMAIL_ADDRESS>wrote:

@rodrigosmarques https://github.com/rodrigosmarques you can test it
using:
parse_server_sdk: ^1.0.15
parse_server_sdk:
git: https://github.com/phillwiggins/flutter_parse_sdk.git
ref: release/v1.0.16 # some-branch-name
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/phillwiggins/flutter_parse_sdk/issues/127#issuecomment-473883787,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHgn3ieM37iNE4HuefNHHQxm-Lm3I5dSks5vX4GxgaJpZM4b5lnn
.

On Mon, Mar 18, 2019, 12:08 Daniel Bjørnbakk<EMAIL_ADDRESS>wrote:

@rodrigosmarques https://github.com/rodrigosmarques you can test it
using:
parse_server_sdk: ^1.0.15
parse_server_sdk:
git: https://github.com/phillwiggins/flutter_parse_sdk.git
ref: release/v1.0.16 # some-branch-name
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/phillwiggins/flutter_parse_sdk/issues/127#issuecomment-473883787,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHgn3ieM37iNE4HuefNHHQxm-Lm3I5dSks5vX4GxgaJpZM4b5lnn
.

@phillwiggins
I made correction of the datetime query in my PR 123.
Tested and working on my project.
Functions changed:
_buildQueryWithColumnValueAndOperator
convertValueToCorrectType
_checkForMultipleColumnInstances
A DateTime value should be converted to a Map. The convertValueToCorrectType function was not converting.
The _checkForMultipleColumnInstances function after conversion to Map removed all the "" left and this caused error in the query.

parse_server_sdk:
git: https://github.com/phillwiggins/flutter_parse_sdk.git
ref: release/v1.0.16 # some-branch-name

Not work:
[parse_test] flutter packages get
Running "flutter packages get" in parse_test...
Error on line 20, column 5 of pubspec.yaml: A dependency may only have one source.

   ╷
20 │ ┌     git: https://github.com/phillwiggins/flutter_parse_sdk.git

21 │ │     ref: release/v1.0.16 # some-branch-name  path_provider: ^0.4.1

22 │ │   http: any

   │ └──^

@rodrigosmarques
my bad - wrong syntax from the top of my head. This is tested:
  # parse_server_sdk: ^1.0.15
  parse_server_sdk:
    git:
      url: https://github.com/phillwiggins/flutter_parse_sdk.git
      ref: release/v1.0.16

@danibjor
Thank you. It worked.
Let's go the tests.

Are you able to do a Flutter get/Flutter upgrade?
There was merge conflicts earlier that might have caused a bug.
Thanks in advance.
On Mon, Mar 18, 2019, 12:14 Daniel Bjørnbakk<EMAIL_ADDRESS>wrote:

@rodrigosmarques https://github.com/rodrigosmarques
my bad - wrong syntax from the top of my head. This is tested:
parse_server_sdk: ^1.0.15
parse_server_sdk:
git:
url: https://github.com/phillwiggins/flutter_parse_sdk.git
ref: release/v1.0.16
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/phillwiggins/flutter_parse_sdk/issues/127#issuecomment-473885666,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHgn3gzFWRlRCJeZudv_twepGxymwoBbks5vX4M8gaJpZM4b5lnn
.

Hi @phillwiggins
It worked, but when doing tests I'm finding errors.
The _buildQueryWithColumnValueAndOperator function in parse_query.dart has been changed and is causing errors with DateTime that I had fixed in my PR.
Had changes to use parseEncode and jsonEncode but the previous code was fading. There was only one adjustment in the convertValueToCorrectType function.
I'm going to make a new Pull Request.

ParseQuery not Working with Parse types: Pointer, Geopoint, DateTime.
It was all working.

Upload ParseFile stoped too

@rodrigosmarques Seems related to #128 - just posted

Hey @rodrigosmarques
Your commit was too far behind master. If you do find the issues and correct them, please make sure that you pull from the latest version first. There's been a lot of changes from 1.0.15 > 1.0.16

Resolved in branch v.1.0.16


Add split from another dataset

Thanks for the great project and support !
I currently have two datasets in the datumaro format, my_ds and my_test_ds. What would be the best way for me to merge them such that I have one dataset with two different splits ?
As an extra question, if my_ds already have train and val splits, is there a way for me to add the test split from the second dataset ?

Hi @CourchesneA, thank you for your steady interests to Datumaro!
Let me start how I reproduced your problem.
Here is the code for creating two datasets with different subset names from Pascal VOC dataset.
from datumaro.components.dataset import Dataset

data_path = "/home/wonju/ssd_ext/datumaro/VOCdevkit/"
dataset = Dataset.import_from(data_path, 'voc')

trainval_dataset = dataset.clone().filter('/item[subset="train" or subset="val"]')
print(trainval_dataset)

test_dataset = dataset.clone().filter('/item[subset="trainval"]')
test_dataset = test_dataset.transform("map_subsets", mapping={"trainval": "test"})
print(test_dataset)

This results

After that, we can merge them with "union" merge policy as below.
from datumaro.components.hl_ops import HLOps
merged = HLOps.merge(trainval_dataset, test_dataset, merge_policy="union")
print(merged)

This makes

For more complex merge situation such as merging two datasets with different categories, please refer to our notebook for merging heterogeneous datasets here https://github.com/openvinotoolkit/datumaro/blob/develop/notebooks/02_merge_heterogeneous_datasets_for_detection.ipynb.

Oh that is much simpler than what I expected, that is awesome. Thanks a lot !


Contributor Console Individual CLA flow when there is no signed CLA but company is there. Step 3.2

Here is the link to wireframe for the contributor console of EasyCLA.

Step 3.2 in Table 3 in the PRD below
https://confluence.linuxfoundation.org/display/PROD/Contributor+Console+for+EasyCLA+V2
##Acceptance Criteria

[ ] Design Changes Required ?--> Not Applicable (N/A)
[ ] Unit Testing Complete

[ ] Unit Testing complete for backend API
[ ] Unit Testing complete for UI

[ ] Functional Testing Complete

[ ] Functional Testing complete for backend API
[ ] Functional Testing complete for UI

[ ] Integration Testing Complete

[ ] Integration Testing complete for backend API and UI
[ ] Integration Testing complete end to end dev deployment

[ ] Documentation Updated
[ ] Any Open Sev. 1, Sev 2 bug(s)

@prasannamahajan and @wanyaland For above screen we required new endpoint without session for Contact Company Admin. (As per wireframe it is not implemented yet but please confirm the same)

@amolsontakke3576 . This is same case as #1135 .

Testing In Progress and logged below bugs
#1373

Testing In Progress with new changes to the flow and so far observed below issues
#1373, #1374, #1377, #1578, #1577, #1576, #1575 , #1574, #1573, #1572, #1571, #1569

Testing is completed and there are no blocking issues for this feature


XML version supported?

Hi! Thanks for the crate!
I just wanted to know better what version of XML is supported (1.0 or 1.1).
Could we document this?
If version 1.0 is supported, would you consider moving to 1.1?

This crate relies on the xmlparser crate, which supports XML 1.0.
I am open to considering XML 1.1 but at least parsing relies on that crate, so it would need to gain support.

Thanks!
Then,

Could we add that we work only on XML 1.0 in the README?
Do you know that xmlparser is archived in GitHub? (Not that it will stop working, but just to be aware)

Yes, I need to update the README.
I didn't know xmlparser got archived, thanks for pointing that out. I think it got folded into the source code of roxmltree.
That may make it worthwhile to explore other parsers, or even take a copy and put it  Xot itself.


cmd/cue: consider a fmt mode to format all CUE files recursively

Splitting off from https://github.com/cue-lang/cue/issues/1731, which was quite broad and got solved by @NoamTD implementing --check and --diff as well as a bunch of other improvements.
gofmt from upstream Go is separate from go fmt - the former works on files and directories, and the latter on packages. So, for example, gofmt -l -w . is pretty similar to go fmt ./..., with the exception that the latter will only format the packages matching the ./... pattern. So if I'm in a monorepo with many Go modules, then the file-based first command can be more powerful. Similar situations happen if I want to keep all files formatted, even those behind "hidden" directories like testdata.
CUE only has cue fmt, which is package-based. It has flags like --check and --diff now, so it's pretty flexible, but I think it's still missing a mode where it simply walks directory trees and formats all CUE files it finds, regardless of package patterns and boundaries.
I can think of multiple ways to go about this:

Add a flag like cue fmt --files or perhaps --recurse, which would make the tool interpret any arguments as file or directory paths to recurse into rather than package patterns.
Overload the argument syntax much like cue help filetypes, e.g. cue fmt files: ., as a different form of 1. This one is cute, but probably too confusing for end users, and might just make the filetypes logic even more hard to grasp.
Interpret arguments as directories to recurse into if they have a trailing slash or filepath.Separator, which is something that some other tools already do, e.g. search for "trailing slash" in https://linux.die.net/man/1/rsync. This is likely the shortest solution, but perhaps the most surprising, as today cue export ./internal/ci/github and cue export ./internal/ci/github/ mean exactly the same.

I personally lean towards option 1, as options 2 and 3 are likely to cause confusing among users.

I should clarify that one option is to change cue fmt in a breaking way where it always interprets arguments as file paths rather than package patterns. However, this is likely to break lots of users, particularly given that arguments like ./... or ./foo/... would stop working, and cue fmt . would now start working recursively when before it wasn't.

First off, I'll admit that even as a relatively advanced cue user, before delving into the cue fmt implementation I ran cue fmt ./... assuming that it was running in the "file" mode you described - I think in an ideal world there would only be a file mode, but as you said this is a breaking change.
So I agree that best/least surprising option would be 1 - it's explicit and doesn't require the user to have any fancy knowledge.
One thing that I think should be considered is the topic of files like .gitignore - we probably would want to ignore files excluded by vcs.

also, perhaps from a UX perspective, it would make sense to warn/fail in case the user mistakenly runs something like cue fmt --files ./...

I think in an ideal world there would only be a file mode, but as you said this is a breaking change.

I wouldn't go that far to be honest - formatting packages only can still be useful, for example if your testdata directories have files badly formatted on purpose, or have tons of files and you're simply not interested in formatting them. But I agree that by default I almost always want "file mode".

One thing that I think should be considered is the topic of files like .gitignore - we probably would want to ignore files excluded by vcs.

cue mod publish does support that sort of thing to decide what files to publish as part of a module (https://github.com/cue-lang/cue/issues/2992), but otherwise none of our other commands (nor gofmt) care about gitignore-like logic. That said, I kinda agree that we shouldn't blindly recurse into every single directory and file. For example, gofmt does and I found it to be wasteful, so I taught my fork to stop at testdata and vendor dirs.
I would just follow the logic of cue help inputs to be honest - note that we don't have testdata or vendor dirs in CUE at this point:

Directory and file names that begin with "." or "_" are ignored, unless explicitly listed as inputs.

it would make sense to warn/fail in case the user mistakenly runs something like cue fmt --files ./...

Yes, we could and should make cue fmt --files fail if any argument contains ..., because that's most definitely a mistake.

I have an initial implementation based on our above discussion, looks like it's working well.
but it made me think: how would we want to handle cue.mod?
running cue fmt --files --check ./... displayed files in cue.mod/gen, I'm assuming that isn't ideal

Right, we should probably make it ignore cue.mod directories entirely. cue.mod/module.cue is formatted/canonicalized by cue mod tidy. The pkg and gen directories aren't written by humans, so we shouldn't touch them. usr perhaps we should format, but it would be odd to just do that one.


Changing timeout value for VGPlayer

Hi
We are using VGPlayer in our application but some of our users constantly report they cannot see the video.
When we investigate their log files it seems that VGPlayer says "request timed out"
We also encountered the same problem, while we have poor internet connection.
But we couldnt find where to change the timeout parameter.
Can you point us to the right direction?
Thanks

@tolgatanriverdi Will you use the version after v0.1.5? Previous versions of some video URL resolution will appear this problem.

Thanks @VeinGuo  I'll give it a try

@VeinGuo I've updated the vgplayer to 0.2.0 version(was 0.1.5 before), but this time it updated snapkit to 4.0.0 and there was compiler errors while building it , related with snapkit.
So I needed to revert back to 0.1.5 (which is using 3.2.0 version of snapkit) and then I can succesfully build and run my app. But this doesnt solve my original timeout problem.
What do you suggest for us?

@tolgatanriverdi  Can you provide a test video link?

Here is a link that you can test. (But it has 5 minutes time limit)
<EMAIL_ADDRESS>

@tolgatanriverdi  Sorry, I can't debug the problem. I play this link very smoothly.


Now user won't be able to copy the quote and paste into the usetInput.

Hey, @mohitkrsuman Welcome to the community.
kindly create a issue that you worked on. This will prevent spam to the repo.


[Bug] [branch-3.0] The test SimpleProducerConsumerTest.testAccessAvroSchemaMetadata always fails

Search before asking

[X] I searched in the issues and found nothing similar.

Read release policy

[X] I understand that unsupported versions don't get bug fixes. I will attempt to reproduce the issue on a supported version of Pulsar client and Pulsar broker.

Version
Branch-3.0
Minimal reproduce step
Run the test SimpleProducerConsumerTest.testAccessAvroSchemaMetadata
What did you expect to see?
It should pass.
What did you see instead?
It always fails.
Anything else?
No response
Are you willing to submit a PR?

[ ] I'm willing to submit a PR!

@poorbarcode @Technoboy-  PTAL!

The issue was related to the unit testing framework's handling of schema changes. Previously, tests would fail whenever there was a schema change due to lack of proper error handling.
The solution was to restart the server for every test case.
In the latest branch (3.3), the issue has been resolved by introducing try-catch and finally blocks for better error handling within the unit tests.
While the fix in branch 3.3 addresses the immediate issue, consider implementing the following improvements: Use separate topics for each test case to avoid interference due to schema changes.
If two different schemas (e.g., JSON and Avro) were uploaded on different topics, the tests would have passed.


Status colors

 Issue by beefoo
Fri Dec 16 20:29:20 2016
Originally opened as https://github.com/NYPL/design/issues/9

I'm not exactly sure how to generalize this, but for our use-case, we're using colors to reinforce the availability status of an item and the ready-status of a hold request (e.g. green = available or ready).  Note that there can also be a recommendation to "not use colors to indicate/reinforce meaning"

 Comment by mgiraldo
Mon Dec 19 20:15:21 2016

do you have an example link for this?
in general we are avoiding relying on color in favor of text (eg: “available”, “not available”). availability can also be reinforced with the presence or absence of buttons.
as we design the request/hold process we can decide if color is required.

Here's one example for availability status of a patron's holds:
https://nypl-discovery.github.io/discovery-designs/holds/v1a.html
And another example for availability status in a search result:
http://dev-discovery.nypl.org/search?q=war
To your point, it makes sense that the "request hold" button should be absent if it is not available.  So in the "War" example, should we remove the green/orange colors?

first pass at this in 894638cc77189c1cd1c2ac45bc1c1a5f0ecb718f


Does chalk.js support squiggly lines?

Does it support these features? https://github.com/microsoft/vscode/issues/158827

No. It's not widely supported in terminals. Not even the plain underline style (which Chalk does support) is widely supported in terminals. We'll consider adding it, but I'd like to see some more terminal adoption first.


Options object not supported for Firestore snapshot listener

Operating System version: MacOS Mojave (v10.14.2)
Firebase SDK version: v7.0.0
Firebase Product: firestore

Describe the problem
Firebase reference documentation states that you can have an options object as the first argument for the DocumentReference.onShapshot() method. This works for the firebase JavaScript client SDK, but not for this Node.js SDK.
Specifying an options object for this package produces the following error:
node_modules/@google-cloud/firestore/build/src/validate.js:93
                    throw new Error(message);
                    ^

Error: Argument "onNext" is not a valid function.
    at Validator.(anonymous function).values [as isFunction] (node_modules/@google-cloud/firestore/build/src/validate.js:93:27)
    at Query.onSnapshot (node_modules/@google-cloud/firestore/build/src/reference.js:1485:25)
    at Object.subscribeRaw (flamelink-js-sdk/packages/schemas/dist/cjs/cf/index.js:1864:29)
    at Object.subscribe (flamelink-js-sdk/packages/schemas/dist/cjs/cf/index.js:1871:24)
    at flamelink-js-sdk/packages/schemas/dist/cjs/cf/index.js:2004:21
    at Array.forEach (<anonymous>)
    at subscribeAndCacheSchemas (flamelink-js-sdk/packages/schemas/dist/cjs/cf/index.js:2003:24)
    at factory (flamelink-js-sdk/packages/schemas/dist/cjs/cf/index.js:2023:5)
    at schemas (flamelink-js-sdk/packages/schemas/dist/cjs/index.js:13:62)
    at flamelink-js-sdk/packages/app/dist/index.node.cjs.js:1249:24

Based on what I could tell, the problem is that this method is only expecting the first argument to be the onNext function:

This code is actually in the @google-cloud/firestore/build/src/reference.js package, but that does not seem to be publicly available apart from via this repo.
Steps to reproduce:

Initialize Firebase admin app
Setup listener for a Firestore collection with the first argument an options object

Relevant Code:
const admin = require('firebase-admin')

const adminApp = admin.initializeApp({
  credential: <setup-credentials>
  ),
  databaseURL: 'https://something.firebaseio.com'
})

adminApp
  .firestore()
  .collection('someCollection')
  .onSnapshot(
    {
      includeMetadataChanges: true
    },
    onNextCallback,
    onErrorCallback
  )

Here is how the client SDK handles it: https://github.com/firebase/firebase-js-sdk/blob/6a0154aee104a163d6d3b1a28d80fcbb9bace908/packages/firestore/src/api/database.ts#L971

You're comparing JS SDK's API reference docs against the Firestore Node.js SDK. They have slightly different API surfaces. The server-side Node.js SDK does not support an options argument: https://cloud.google.com/nodejs/docs/reference/firestore/0.20.x/DocumentReference#onSnapshot

Assigning to the Firestore SDK team to comment on if this option should be added to the server-side SDK.

@hiranya911 is correct. There are no snapshot listener options in the server-side node SDK.
In particular, the includeMetadataChanges option doesn't exist there because those kinds of transitions only happen when there's a local cache involved. The server-side SDKs have no cache.

Thanks, @hiranya911 and @wilhuff
It makes sense what you say about the includeMetadataChanges option specifically.
The thing that confused me was reading the Firebase reference docs and clicking the links under the Node.js (client) section, it actually takes you back to the standard JS docs.

This is my mistake. Thanks for your time.


Use remote node cache in CI workflow

Definition of Done

The hardhat-core GitHub CI workflow is retaining Rethnet's remote node cache for the "test-fork" job across CI runs.
As this is still in a testing phase, it should be set up as a separate job in the workflow

BEWARE: currently the cache does not properly handle requests for "latest". Caching of these should be avoided as latest is continuously changing. See #88

Fixed in https://github.com/NomicFoundation/hardhat/pull/4376


Update mocha dependencies and replace deprecated mocha.opts

Replaces deprecated mocha.opts with package.json entry. Updates mocha dependencies 2 major versions.
Fixes firebase/quickstart-nodejs#117

sputnik:typescript-quickstart katowulf$ firebase emulators:exec --only firestore 'npm test'
i  emulators: Starting emulators: firestore
i  firestore: Serving ALL traffic (including WebChannel) on http://localhost:8080
⚠  firestore: Support for WebChannel on a separate port (8081) is DEPRECATED and will go away soon. Please use port above instead.
i  firestore: firestore emulator logging to firestore-debug.log
✔  firestore: firestore emulator started at http://localhost:8080
i  firestore: For testing set FIRESTORE_EMULATOR_HOST=localhost:8080
i  Running script: npm test

><EMAIL_ADDRESS>pretest /Users/katowulf/projects/quickstart-nodejs/firestore-emulator/typescript-quickstart
> tsc

><EMAIL_ADDRESS>test /Users/katowulf/projects/quickstart-nodejs/firestore-emulator/typescript-quickstart
> mocha --timeout=10000

  MyApp
    ✓ require users to log in before creating a profile (302ms)
    ✓ should enforce the createdAt date in user profiles (150ms)
    ✓ should only let users create their own profile (54ms)
    ✓ should let anyone read any profile (66ms)
    ✓ should let anyone create a room
    ✓ should force people to name themselves as room owner when creating a room (39ms)
    ✓ should not let one user steal a room from another user (113ms)

View rule coverage information at http://localhost:8080/emulator/v1/projects/firestore-emulator-example:ruleCoverage.html

  7 passing (2s)

✔  Script exited successfully (code 0)
i  emulators: Shutting down emulators.
i  firestore: Stopping firestore emulator

Thanks Kato!


Sync downstream devel with upstream devel

Sync downstream devel with upstream devel branch
This includes the fix for BZ https://bugzilla.redhat.com/show_bug.cgi?id=2132359

/lgtm


[SVE] Check for SVE target in func_attr from VectorizeLoop

Check that we are compiling for an SVE enabled target when the extent of a loop marked for vectorizing is a vscale dependent expression.

Add call to BindTarget in Graph Executor pipeline (to enable running tvmc flow)

Check in LoopVectorize that the extent is either a positive integer or an vscale dependent expression, in which case we'd expect an SVE enabled target to be present in func_attr

@Lunderberg @lhutton1
This is a follow up from https://github.com/apache/tvm/pull/16782, it makes sure that scalable vectors are created only for SVE target. In this implementation we check for target in function attributes, so we'd rely on BindTarget having run before. Alternatively we could access the "global" target via Target::Current(), which would be simpler, but would make it harder to mix SVE and non-SVE targets. I'm happy to go with either option :)

I moved the implementation to use the current target since changing the graph executor's pipeline is breaking lots of CUDA tests.

Thanks @ekalda!


How to Use DISM to optimize your image and reduce your VM's first boot time.

This page suggests using DISM to optimize the image and reduce the VM's first boot time by mounting the VHD in Windows explorer, but it's not clear how to get the VHD from the VM that has just been generalized.
The "Disk Export" section in the os disk says "Exporting disks is allowed only when the VM is deallocated or the disk is unattached, or when the disk is not in ReadyToUpload or ActiveUpload state".
Please provide clarification on how to run DSIM on a disk from a Windows VM where sysprep has just been executed.

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

ID: 83917921-2dc0-42a9-1b99-cce2fca9961a
Version Independent ID: 3812c21e-a5f6-af8d-17b5-05a2635d8b1d
Content: Generalize a VM before creating an image - Azure Virtual Machines
Content Source: articles/virtual-machines/generalize.md
Service: virtual-machines
Sub-service: imaging
GitHub Login: @cynthn
Microsoft Alias: cynthn

@dg-eparizzi
Thanks for your feedback! We will investigate and update as appropriate.

Please refer to this document for Downloading a Windows VHD from Azure after generalizing the VM :
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/download-vhd?tabs=azure-portal
Post that, you can run DISM on the VHD.
You may also find these docs helpful for the next steps:
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/prepare-for-upload-vhd-image#generalize-a-vhd
Upload a generalized VHD and use it to create a new VM in Azure.
Let me know if you have further questions. Thanks.

Thanks for bringing this to our attention. We will now close this issue. If there are further questions regarding this matter, please tag me in a comment. I will reopen it and we will gladly continue the discussion.


New Artifact windows-ConfigurationManagerTechnicalPreview

New Artifact for System Center Configuration Manager (Technical-Review).
Cleanup of the existing Artifact windows-ConfigurationManagerCurrentBranch(EVAL) to remove .exe Files from Artifact.

Hi @rzander, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
We will now validate the agreement and then real humans will evaluate your PR.
TTYL, AZPRBOT;

... I'm still waiting for Feedback ....

... is there a Moderator on this Project ?... still waiting for Feedback...


Fix result propagation in RenderSliverEdgeInsetsPadding.hitTestChildren

Fixes https://github.com/flutter/flutter/issues/149824
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] I followed the breaking change policy and added Data Driven Fixes where supported.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Google testing had an internal error. I restarted it.

@goderbauer, thanks for the heads-up.

The internal test has been updated. I am going to rebase this to trigger the checks again.

Internal tests have been updated again, let's see if they pass now...


2 word clouds show same data

Hi,
I really like the word cloud so far and would like to thank you for making such an extension.
But as soon I do changes on the word cloud I have to refresh the Qlik Sense app to see the changes (which is not a big issue).
The bigger issue I have is that I use two word clouds to display some Facebook and twitter posts. The word clouds are on different sheets but show the same posts. The data in the background is in different tables but linked through a master key. The dimension and measures in the word cloud on the other side are different. Still it shows the same posts until I refresh the app. After refreshing it shows me the correct data on the current sheet I am, if I go to the other sheet with the other word cloud it shows me the wrong data till I refresh.
Really appreciate your help.
Thanks!

Hello,
Good to read that you liked my work.
This extension has been deprecated.
Please search for new one by Ralf Becher
Em 07/07/2016 22:22, "FelixKi"<EMAIL_ADDRESS>escreveu:
Hi,
I really like the word cloud so far and would like to thank you for making
such an extension.
But as soon I do changes on the word cloud I have to refresh the Qlik Sense
app to see the changes (which is not a big issue).
The bigger issue I have is that I use two word clouds to display some
Facebook and twitter posts. The word clouds are on different sheets but
show the same posts. The data in the background is in different tables but
linked through a master key. The dimension and measures in the word cloud
on the other side are different. Still it shows the same posts until I
refresh the app. After refreshing it shows me the correct data on the
current sheet I am, if I go to the other sheet with the other word cloud it
shows me the wrong data till I refresh.
Really appreciate your help.
Thanks!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cleveranjos/br.com.clever.wordcloud/issues/7, or mute
the thread
https://github.com/notifications/unsubscribe/AInxtncx_WYm4UcI3xTZjNrVOIvpu1qjks5qTaZhgaJpZM4JHpXM
.


Zwave Climate Operation Mode not working

Make sure you are running the latest version of Home Assistant before reporting an issue.
You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:
Home Assistant release (hass --version):
0.43
Python release (python3 --version):
python 3.5.3
Component/platform:
Zwave climate
Description of problem:
17-04-23 23:35:45 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "uvloop/future.pyx", line 374, in uvloop.loop.BaseTask._fast_step (uvloop/loop.c:112704)
  File "/usr/src/app/homeassistant/core.py", line 1015, in _event_to_service_call
    yield from service_handler.func(service_call)
  File "/usr/src/app/homeassistant/components/climate/__init__.py", line 362, in async_operation_set_service
    yield from climate.async_set_operation_mode(operation_mode)
  File "uvloop/future.pyx", line 230, in __iter__ (uvloop/loop.c:110600)
  File "uvloop/future.pyx", line 432, in uvloop.loop.BaseTask._fast_wakeup (uvloop/loop.c:113980)
  File "uvloop/future.pyx", line 101, in uvloop.loop.BaseFuture._result_impl (uvloop/loop.c:108900)
  File "/usr/local/lib/python3.5/concurrent/futures/thread.py", line 55, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/src/app/homeassistant/components/climate/zwave.py", line 197, in set_operation_mode
    self.values.mode.data = bytes(operation_mode, 'utf-8')
  File "/usr/local/lib/python3.5/site-packages/openzwave-0.3.3-py3.5.egg/openzwave/value.py", line 292, in data
    self._network.manager.setValue(self.value_id, value)
  File "src-lib/libopenzwave/libopenzwave.pyx", line 2840, in libopenzwave.PyManager.setValue (src-lib/libopenzwave/libopenzwave.cpp:21991)
TypeError: Expected str, got bytes

Expected:
Setting operation mode to not throw a type error.

Same here

#7266 fixes it for me

@jordemort are you using the dev branch? How did you apply the fix in #7266?

@rudolfrck I'm using Docker, I docker execed into a shell in my container and patched  homeassistant/components/climate/zwave.py by hand and then restarted the container.

Yeah, same as I did then. I'm not using docker though. Thanks!

So for us that are kinda new to patching things up, can you explain your process. This breakage actually made me start looking for another automation source since I depend on controlling my thermostats alot and would love to stick with Homeassistant. Thanks gang.

#7266 has been merged. Closing.


feat: optionally apply unique() to results

Description
Allows for an optional configuration to call unique() results.
This is useful when you need to use contains_eager on a one-to-many relationship.

Closes
Closes #160

Welcome to Codecov :tada:
Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.
Thanks for integrating Codecov - We've got you covered :open_umbrella:


Refresh to 0.3.26

Checklist before submitting

[ ] Did you read the contributor guide?
[ ] Did you update any affected documentation?
[ ] Did you write any tests to validate this change?

Description
Fixes # (issue).
Review process to land

All tests and other checks must succeed.
At least one maintainer must review and approve.
If any  maintainer requests changes, they must be addressed.

Refreshed to v0.3.26 with ref: https://github.com/open-ce/openblas-feedstock/pull/17


Move cmaes_test.py to baselines_test from core_test

Related issues: #201
Move cmaes_test.py to baselines_test from core_test
Checks

[x] a clear description of the PR has been added
[ ] sufficient tests have been written
[ ] relevant section added to the documentation
[ ] example notebook added to the repo
[ ] clean docstrings and comments have been written
[ ] if any issue/observation has been discovered, a new issue has been opened

Future improvements
[List here potential observations made and/or improvements that could be made in the future. If relevant, open issues for those.]

Thanks @LisaCoiffard 😃


Move to a fully hand-written parser to improve compile / iteration times

This is part of https://rust-lang.zulipchat.com/#narrow/stream/186049-t-compiler.2Fwg-polonius/topic/Polonius.20Hackathon.202021-07-30.
Preliminary results:
---- ALL ----	   ---- OLD ----	---- NEW ----
build --all: 		   28.874		     8.38
build --all --release: 38.162			14.15
test: 				   42.74		    16.569
test --release:		   53.709			23.505

---- PARSER ONLY ----
build: 				   26.367		     1.427
build --release: 	   31.56			 2.84
test: 				   28.244			 2.1
test --release: 	   34.41			 2.945

@lqd I've made some changes addressing your comments.
During the sprint, I was very much focused on getting this off the ground and compile times as far down as possible, largely flying by the existing tests. Now with more time I've done some minor refactorings to clean up the implementation, add documentation to a lot of places and give the polonius_parser crate its own README. The latter contains some general description and instructions, plus the example you asked about.
I would have liked to put some doc tests on the actual parsing methods as well, but doc testing with internal items doesn't really work out that well.
Let me know in case you have further questions on this.

Thanks a ton!


Fix exception happening in unit tests. Resolves #817

This can be merged @steiza

I accidentally added some more commits, but this can still be merged.  The additional changes fix a bug and then resolves #816.


chore(esm): change imports to esm compatible

Change all relative path imports to have .js suffix required by the ESM standard.
Use full import path instead of directory default import.
I've created a tool for doing this automatically (existing tools were failing on some edge cases). The sources are available here: https://github.com/outSH/to-esm-imports.
The tool is executed after codegen (because openapi generators doesn't support creating ESM-compatible imports yet).
Changed jest and webpack configs to work with fully qualified ESM imports.

Pull Request Requirements

[ ] Rebased onto upstream/main branch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.
[ ] Have git sign off at the end of commit message to avoid being marked red. You can add -s flag when using git commit command. You may refer to this link for more information.
[ ] Follow the Commit Linting specification. You may refer to this link for more information.

Character Limit

[ ] Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
[ ] Commit Message per line must not exceed 80 characters (including spaces and special characters).

A Must Read for Beginners
For rebasing and squashing, here's a must read guide for beginners.

@petermetz

The tool is executed after codegen (because openapi generators doesn't support creating ESM-compatible imports yet).

There are two problems with this at the moment:

Users can see their CI codegen job fail because they use old import statements and not because of actual change in openapi.
Bugs in my tool may change / break unrelevant code (may be annoying in the future).

The solution I see is to move codegen logic to separate script (including warmaps) and run my tool only for files changed (right now it runs for entire repo). I'm open for opinions and any suggestions :)
BTW how come so many tests were skipped if I'm literally changing every ts file on the project :D

@outSH OK, a slightly different place in the code but with the same technical decision by the maintainer to not include renames: https://github.com/dorny/paths-filter/blob/master/src/main.ts#L185-L187
My own take:
I disagree with renames not making sense to include as changes because if I move files around and forget to update the imports then I had just broken the build which the CI should definitely catch.
I explained as much here as well hoping that the maintainers of that repo agree.
https://github.com/dorny/paths-filter/issues/152#issuecomment-1957351279
Later on if I have enough time I could send a PR myself to that repo to extend it with this functionality but in the meantime I propose that we move ahead as-is.

@petermetz This occurred when build was working, it's still WIP. Also, there are no file renames here so how does it apply here? I'm still thinkinking this is caused by picomatch limitations,  here's sample code:
const pm = require("picomatch");

const isMatch = pm(
  "./packages/cactus-plugin-keychain-vault/**!(*.md|*.css|*.html|*.jpg|*.jpeg|*.png)"
);
console.log(
  "packages/cactus-plugin-keychain-vault/foo",
  isMatch("packages/cactus-plugin-keychain-vault/foo")
);
console.log(
  "packages/cactus-plugin-keychain-vault/foo.md",
  isMatch("packages/cactus-plugin-keychain-vault/foo.md")
);
console.log(
  "packages/cactus-plugin-keychain-vault/foo.html",
  isMatch("packages/cactus-plugin-keychain-vault/foo.html")
);
console.log(
  "packages/cactus-plugin-keychain-vault/foo.jpg",
  isMatch("packages/cactus-plugin-keychain-vault/foo.jpg")
);
console.log(
  "packages/cactus-plugin-keychain-vault/foo.ts",
  isMatch("packages/cactus-plugin-keychain-vault/foo.ts")
);
console.log(
  "packages/cactus-plugin-keychain-vault/foo.asd",
  isMatch("packages/cactus-plugin-keychain-vault/foo.asd")
);

console.log(
  "packages/cactus-plugin-keychain-vault/src/main/typescript/plugin-keychain-vault.ts",
  isMatch(
    "packages/cactus-plugin-keychain-vault/src/main/typescript/plugin-keychain-vault.ts"
  )
);
console.log(
  "packages/cactus-plugin-keychain-vault/src/main/typescript/foo.ts",
  isMatch("packages/cactus-plugin-keychain-vault/src/main/typescript/foo.ts")
);
console.log(
  "packages/cactus-plugin-keychain-vault/src/main/typescript/foo.js",
  isMatch("packages/cactus-plugin-keychain-vault/src/main/typescript/foo.js")
);
console.log(
  "packages/cactus-plugin-keychain-vault/src/main/typescript/foo.png",
  isMatch("packages/cactus-plugin-keychain-vault/src/main/typescript/foo.png")
);
console.log(
  "packages/cactus-plugin-keychain-vault/src/main/typescript/foo.jpg",
  isMatch("packages/cactus-plugin-keychain-vault/src/main/typescript/foo.jpg")
);
console.log(
  "packages/cactus-plugin-keychain-vault/src/main/typescript/foo.md",
  isMatch("packages/cactus-plugin-keychain-vault/src/main/typescript/foo.md")
);

and output:
packages/cactus-plugin-keychain-vault/foo true
packages/cactus-plugin-keychain-vault/foo.md true
packages/cactus-plugin-keychain-vault/foo.html true
packages/cactus-plugin-keychain-vault/foo.jpg true
packages/cactus-plugin-keychain-vault/foo.ts true
packages/cactus-plugin-keychain-vault/foo.asd true
packages/cactus-plugin-keychain-vault/src/main/typescript/plugin-keychain-vault.ts false
packages/cactus-plugin-keychain-vault/src/main/typescript/foo.ts false
packages/cactus-plugin-keychain-vault/src/main/typescript/foo.js false
packages/cactus-plugin-keychain-vault/src/main/typescript/foo.png false
packages/cactus-plugin-keychain-vault/src/main/typescript/foo.jpg false
packages/cactus-plugin-keychain-vault/src/main/typescript/foo.md false

@outSH You are a 100% right, sorry for the complications from my investigation. When I did the full deep-dive I narrowed it down to a single line in the code of the paths-filter action that we could update to make our use-case work with slightly differently formatted globs where the exclusion globs are on their own line and we specify that all of the patterns have to match instead of "at least one".
I've submitted a patch to the paths-filter action directly and hoping that the idea will get some traction there and then it will be merged and released so we can use it.
If not, then plan B is to just use the fork as long as the original author(s) are OK with that.
My pull request:
https://github.com/dorny/paths-filter/pull/224

@outSH My pull request to add the feature to the paths-filter action is still pending unfortunately.
In the meantime, I wanted to check in and ask: Are you still working on this PR or should we close it for now? (I'm trying to declutter the PR queue)

@outSH My first PR to the paths-filter library was accepted and merged but there was a bug in it so I had to submit a second one which hasn't been looked at by the maintainer of that package for months now unfortunately. I thought about publishing a friendly fork of the path-filter action but in the meantime Jennifer made some headway in the dynamic diff analysis so we might not need path filtering at all in the near future.
On another note though: In general, are you still working on this PR or should we just put it to rest for now? It's been open for a while and I'm trying real hard to bring the number of pending PRs down.

On another note though: In general, are you still working on this PR or should we just put it to rest for now? It's been open for a while and I'm trying real hard to bring the number of pending PRs down.

@petermetz I'm not working at this ATM, but this is just a PR draft. Is it displayed on your "to review" list? I wanted to keep to find it quicker once I get some time / energy to sit down to it again :)

On another note though: In general, are you still working on this PR or should we just put it to rest for now? It's been open for a while and I'm trying real hard to bring the number of pending PRs down.

@petermetz I'm not working at this ATM, but this is just a PR draft. Is it displayed on your "to review" list? I wanted to keep it open to find it quicker once I get some time / energy to sit down to it again :)

@outSH It's not in my review list (so it's totally OK on that front) but the other (kinda) list (of the many) that I have is this one about the project health in terms of the velocity of PR throughput and reviews where we have pretty  bad numbers due to PRs being left open on the upstream repo as drafts.
If you are not actively working on it but would still prefer a reminder, maybe I could recommend to open a PR against the main of your own fork? I'm also open to any other idea that would reduce the skew in the statistics linked below (I think we are doing much better in terms of PR velocity this year than last year, BUT a few of these long-running PRs are probably making it look worse than it is).
Source: https://insights.lfx.linuxfoundation.org/foundation/hyp/velocity?project=cacti&routedFrom=Github&bestPractice=false
Screenshot:

@outSH Thank you!


pm2-server-monit TypeError.

This is part of the email reporting an error regarding pm2-server-monit agent.
Application: pm2-server-monit
Message:
TypeError: Cannot read property 'replace' of undefined
at /root/.pm2/node_modules/pm2-server-monit/lib/drive.js:22:35
at ChildProcess.exithandler (child_process.js:742:7)
at ChildProcess.emit (events.js:110:17)
at maybeClose (child_process.js:1015:16)
at Socket. (child_process.js:1183:11)
at Socket.emit (events.js:107:17)
at Pipe.close (net.js:485:12)
Import from https://github.com/Unitech/pm2/issues/2284

Moreover, I'm encountering serious memory leak issue.
How pm2-server-monit can consume almost 250Mb (24%) on a 1Gb Raspberry Pi?

Used shelljs + added new check in v2. Please reopen if the error appears again.
About the memory leak: pm2-server-monit usually consumes 25-35 Mo, and I could not observe a memory leak over time. It also has a hard limit set at 150Mo and pm2 will restart it if it goes over this level. If you still have a leak with the new pm2 version, please open a new issue
Cheers


sk.js: Fix l10n issues (czechisms)

Describe the bug
The preposition za in the sense of in in in a minute is a czechism (a word or usage borrowed from the Czech language), therefore the moment’s za pár sekúnd is correct in Czech, and incorrect in Slovak. In Slovak, the correct preposition is o in the phrase.
Expected behavior
For example: use o pár second instead of za pár sekúnd (meaning: in a few seconds).

Update: Another issue is the pred 3 dny which should be pred 3 dňami. Not an issue of moment, but of dayjs, my bad.

@k2s thoughts?

the statement in this ticket is not true, it is valid slovak language construct
all was discussed here https://github.com/moment/moment/pull/5409#issuecomment-618482801
solution is .replace('za', 'o'), better solution in moment would be to provide context parameter to the translation

@k2s, although my statement in the OP is not entirely correct, it is partially correct. As the current implementation of the issue in Moment. And as the implementation is not entirely corrent, I think it should be fixed. I have no idea how, but IMHO the output should be always correct.
Your proposed solution (.replace('za', 'o')) is not even a workaround as it leaves the output partially correct, although reversed.
Based on the sources from your comment in #5409 (which are indeed valid) I have wrote the following in a comment:

za is used when we talk about a period during which something is done (like He cooked it in an hour.);
o is used when we talk about a point in time (like She’s back in a minute.).

Therefore, the current output not corrent for o (but correct for za) and if one chooses to use to 'solution', they would get correct output for o, but not for za.

@tukusejssirs thank you that you try to implement and improve support for slovak language in libraries. in relation to moment library, you need to keep in mind that it is established library, used by many projects and to change something has most of all not break existing code.
name of this ticket says that the returned za value is grammatically wrong which would mean it is bug, it would need fix. that is not true.
to correctly return za or o additional context is required which is not needed for english and that,  what I am aware of, is not supported by related moment functions
I understand your desire to have it perfect and the way to achieve it is to create moment plugin which will provide methods with context support.

Well, I tried to pass the same: #5206, which was reverted afterwards :-(
I don't believe there are so many Slovak users who would even notice za / o change anyway, so why they keep the incorrect version, I don't understand. Both are valid, though I'd guess that most users need the "in time in future" form, for which o preposition should be used. The form "it took time / it was done in", for which preposition za is used in Slovak, is a much less frequent case.

@dakujem, thanks for your comment. It makes me feel I’m not alone in this. 😄
When I created this PR, I thought we should always use o instead of za, but @k2s proved me wrong (see this comment of mine) that both are correct, but not interchangable.
Therefore from my current point of view,  if we use either za only or o only, both are equally wrong as both are not always true. I wish I could propose an algorithm (a function) that would deal with the cases when which preposition is to be used, but I am not that good at programming … maybe you can do it. :smiley:

Indeed, both are used. I would bet that o is more frequent though. But...
Unfortunatelly, I'm not a JS guy 🤷, my JS plugin would be bad 😆

@dakujem, currently we don’t need the code, but the algorithm—how to check what preposition Moment should output?

I don't know how we can distinguish between points in time and periods of time.
I guess I will not make any changes here.
The locales can always be overridden by individual users.
https://momentjs.com/docs/#/customization/

That’s a great pity.

Hm... Perhaps we can distinguish usage between durations and moments.  I will leave it open for a little while longer.

It sounds good me.
Is there any way we could get this ‘metadata’ now? Or is it something you need to implement into Moment?

I don't know what you mean.
for now:
If you are using durations, you can update the locale for o.
If you are using moments, it will already use za.

I don't know what you mean.
for now:
If you are using durations, you can update the locale for o.
If you are using moments, it will already use za.

On a second thought, this won’t solve this issue, because in an hour means both o hodinu (like in I’ll be back in an hour., which uses o point in time, i.e now + 1 hour) and za hodinu (like in He cooked it in an hour., which talks about a duration of time).
If you still think it’ll solve this issue, please share with me some code snippets how I could distinguish between the two. Thanks.

I read through this discussion again.
It sounds like the difference between za and o depends on the specific context of the sentence. Probably, there are some linguistic texts discussing this, but it sounds more specific than can be implemented in this library. For example, Moment.js cannot distinguish between "He cooked it in an hour" and "I'll be back in an hour".
It seems like the best strategy is to use one, and replace it  outside of Moment.js when you need.
If you have other ideas, feel free to re-open. Best of luck!

Moment.js cannot distinguish between "He cooked it in an hour" and "I'll be back in an hour".

@marwahaha, that was my impression, too. It is a pity, but it is true. It’s shame that most l10n tools are so English-concerned that they can’t be modified to fully support other locales. I wish Moment would be like Fluent.
Until then, I think that this is a dead end.