Emoji "disappeared" after 1.31.0 update

Some of the emojis no longer "work" and they appear as empty squares instead.
I'm 100% sure they were showing correctly in the previous versions.

VSCode Version: 1.31.0
OS Version: Windows 10 Professional (latest version)

Steps to Reproduce:

Paste the swan emoji 🦢 in the editor

Does this issue occur when all extensions are disabled?: Yes/No
Yes

@bimbo1989 exact steps what you are doing please

You just need to open any file in VSCode and paste the swan emoji (  🦢 ), that is the one no longer working for me.
You will see that, insted of the swan, an empty square will appear.

Works fine on macOS at least.

Maybe it's Windows related?
I'm using Windows 10. Not a strictly OS  problem though, the emoji is working fine in any other program. Just VSCode seems to suffer this issue. No extensions enabled.

@bimbo1989 I do not even see that emoji appearing on my Windows in IE nor Chrome, so I think this is rather a Windows issue.

@bpasero that's weird: I see the emoji correctly in Chrome, Firefox, even in Microsoft Word 🤔

On Windows 10 Professional also. Opened the emoji menu using Win + Period.

@frobinsonj exactly that 😁

Possible workaround https://github.com/Microsoft/vscode/issues/32840#issuecomment-345923580

@usernamehw it kind of works! Only in the editor though (it doesn't work for example in extensions where it used to work before), but still better than nothing!

@bimbo1989, didn't notice that. Using custom CSS to fallback to emoji where I can (since some emoji didn't work even before this update 🖥 for instance):
.monaco-shell.windows, .monaco-shell.windows .monaco-menu-container .monaco-menu {
    font-family: Segoe WPC,Segoe UI,sans-serif, Segoe UI Emoji;
}

@usernamehw seems nice! Where do I need to put that css? Do I need to create a theme?

Nah, it's an extension (not recommended by vscode team because it modifies the source) Custom CSS.

I suspect this is https://github.com/electron/electron/issues/16530

A workaround for the editor is to use "editor.fontFamily": "Consolas, Segoe UI Emoji". I have updated the issue description to capture this workaround.

Confirmed this is happening on Mac as well.

Can confirm this is also an issue for me on Mac.
VSCode version: 1.33.0
Font Family: IBM Plex Mono

Setting the editor font is one thing. I like to use emojis to keep track of long task lists or launch configurations. Couldn't you just extend the UI font-family list to fix the UI - outside the editor - like so:
.windows {
- font-family: Segoe WPC, Segoe UI, sans-serif;
+ font-family: Segoe WPC, Segoe UI Emoji, Segoe UI, sans-serif;
}

Meanwhile, here is a posh script:
$path = Join-Path (Split-Path (Get-Command "code").Source) "..\resources\app\out\vs\workbench" -Resolve
$stylesheet = Join-Path $path "workbench.main.css"
Copy-Item $stylesheet "$stylesheet.bak"
((Get-Content $stylesheet -Raw) -replace ".windows{font-family:Segoe WPC,Segoe UI,sans-serif}", ".windows{font-family:Segoe WPC,Segoe UI Emoji,Segoe UI,sans-serif}") | Set-Content $stylesheet

We are building exploration builds that use a much newer version of our UI framework (Electron version 6.0.x). I wonder if this issue reproduces with one of these builds, could you try? Download:

macOS: Download
Linux (DEB): Download
Linux (RPM): Download
Windows: Download

Hi @bpasero , the emoji now seems to work, to be fair also on the "regular" release


Get list of EMIT validation products from EMIT team

Need to get a set of or access to the validaiton products that the EMIT team will be using. These will be required for U-DS to populate the data catalog and store in an EMIT venue bucket.
Blocks https://github.com/unity-sds/unity-data-services/issues/354

From Godwins notes:
Figure out how to download EMIT netcdf products from LP-DAAC to Jupyter - bug Mike and Nga

Phil suggested using CMR, which is how we do it as well so this is perfect
CMR query could be done using a REGEX and EMIT time-stamp (this should be unique enough for CMR query to work).  FID in their HPC only has time-stamp
Jay would like to identify 100-200 cases and identify by FID
FID (flightline ID) is the scene unique identifier, Jay would only know the time-stamp
Jay will need to give us the FIDs that he wants
Want L1B RAD and OBS files
Jay can re-construct the orbit number
Have Jay learn to work with CMR and such using our Unity notebook

Still in progress as of 4/24/2024
Ah, so these are the EMIT L1B files you start from?

We used these same files on our SISTER work- for example one set of inputs comes from [https://cmr.earthdata.nasa.gov/search/granules.stac?collection_concept_id=C2408009906-LPCLOUD&temporal[]=2023-08-10T03:41:03.000Z,2023-08-10T03:41:03.000Z](https://cmr.earthdata.nasa.gov/search/granules.stac?collection_concept_id=C2408009906-LPCLOUD&temporal%5b%5d=2023-08-10T03:41:03.000Z,2023-08-10T03:41:03.000Z)

Which gives us:
EMIT_L1B_RAD_001_20230810T034101_2322203_002.nc
EMIT_L1B_OBS_001_20230810T034101_2322203_002.nc

We can either pull these and have them ready locally, or we can pull them at run-time. IF you want to run against all of them, we’d probably create a wrapper to make these calls/executions anyway.

-Mike

Response:
Yes, that’s right. There’s several that are needed, not just the two you list here.

I’m asking around about a list of cases. If no one has a preferred list, I’m just going to select 200 plume cases.

@ngachung - The list of files needed for the plume detection is attached.
For each entry, there is a column (line_name) that looks like this: emit20230620t084426.
To find the corresponding file in CMR, we search on the collection (C2408009906-LPCLOUD) for that pattern in the granule_readbale_name:
https://cmr.earthdata.nasa.gov/search/granules.json?echo_collection_id=C2408009906-LPCLOUD&options[readable_granule_name][pattern]=true&page_num=1&page_size=20&readable_granule_name[]=*20230620T084426*&sort_key=-start_date

Closing as we have the list of items. We should probably bring them into the system and then ensure things like bbox and searches are working.
We might also want to see if there is "custom" metadata that would be helpful (e.g. the plume lat/lon locations?)


Runtime numbers are unreliable

GradBench currently evaluates each function only once on each workload.  This makes the runtime measurements highly sensitive to noise, and also unrealistically pessimistic, as caches will be cold. This becomes even more significant once you want to measure performance on GPUs and the like. Accurately benchmarking computer programs is a complicated problem, but I don't think GradBench needs to go to a lot of effort to get numbers that are reasonably reliable. E.g. ADBench just does ten runs per workload and takes the average, and this is fine.
But how should this be implemented? Should the eval do ten (or whatever) evaluate messages? Should the intermediary automatically duplicate these messages? Should the tools internally do multiple runs and report the average? Or multiple runs and report all of the runtimes, to enable statistical analysis?
I have a mild preference for letting the tool do multiple runs internally, because it cuts down on the potentially costly communication of large datasets. It also makes it easier to "keep the cache warm" for tools where that matters (e.g., GPUs, where you might normally deallocate all data after evaluation). If we provide a bit of reusable Python and C++ glue code, then it is not so difficult to accomplish this in a consistent way across all tools. I would suggest that the tool then reports the runtimes of all the evaluations, in order to maximise the information available for further analysis.

The functions in the eval can be defined however the eval wants. Since we're trusting the tools to be a bit honest, can't we just change the evals to add an additional integer parameter in the "input" of each function, specifying how many times that function should be evaluated by the tool before returning the outputs from just one of those evaluations?

I think another issue here is that we don't have control over what runner GitHub uses for each individual job in the run matrix, so it seems quite possible that different kinds of runners will happen to be used for different tools. There are a couple ways I can think of to try to address this:

Replace the matrix in the run job with just a single job, that iterates over all the eval/tool pairs and runs them all in sequence. This would be slower, but at least we guarantee they all run in the same VM.
Use self-hosted runners to guarantee the exact machine configuration for every run job. This is more expensive and complex, but allows us to maintain consistency across workflow runs rather than just within a single workflow run. I think @avibryant mentioned something about this in the past.

The functions in the eval can be defined however the eval wants. Since we're trusting the tools to be a bit honest, can't we just change the evals to add an additional integer parameter in the "input" of each function, specifying how many times that function should be evaluated by the tool before returning the outputs from just one of those evaluations? Then the eval could make this parameter configurable via https://github.com/gradbench/gradbench/pull/127.

Yes, this would be a good way to do it, as it still puts the multiple-runs logic inside each tool, thus enabling cache warmup etc. It is fine to just return one output for validation (say, the last one), but I think it is best to return multiple runtimes.

I think another issue here is that we don't have control over what runner GitHub uses for each individual job in the run matrix, so it seems quite possible that different kinds of runners will happen to be used for different tools.

Any runtime numbers coming out of GA will always be suspect since they are run on shared virtual machines. It's a very noisy environment. It's fine to put the numbers on the website as a rough measurement, but any real results, reported in papers or whatnot, should be done in a controlled environment. To me, the main purpose of the GA setup is to ensure that things work, not to produce fully reliable numbers.
I have experience using self-hosted runners, and they work very well. The main problem is actually having that hardware somewhere. I suggest dealing with that once GradBench is a wealthy and powerful project.

I also have a machine in a cabinet here that can operate as a self-hosted runner. They really aren't very difficult to set up.
If someone has a spare M1 Mac Mini that you can put on a shelf at CMU, then that could also solve the cross compilation woes.

Yeah; I guess currently I'm leaning toward first making it easy for people to run all the benchmarks locally on their own machine, unless we have a good reason to work on self-hosted runners at the moment. I'm sure you're right that they're not too bad to set up, but it's the ongoing maintenance that I'm a bit wary of.
Regarding an M1 Mac: just one wouldn't really help since we already get 5 concurrent macOS jobs for free via GitHub Actions, as I wrote in https://github.com/gradbench/gradbench/pull/153#issuecomment-2532655870.

Does GA run macOS jobs on real ARM hardware? Then why do we cross compile at all?

Yep! And the reason we cross-compile is that I don't know how to build separate parts of a cross-platform Docker image on different machines and then combine them. So if I understand correctly, unless there's a way to do that, we need to cross-compile using either QEMU or Rosetta, and currently we just happen to be using QEMU because GitHub has a higher concurrency limit for Linux jobs.

The DiffSharp failures are due to qemu limitations, based on my brief investigation.


ISPN-14976 fix protostream serializer

Fixes https://issues.redhat.com/browse/ISPN-14976

Merged, thanks


Info.plist does not contain CFBundleVersion

Command
flutter run

Logs
ProcessException: ProcessException: Process exited abnormally:
An error was encountered processing the command (domain=NSPOSIXErrorDomain, code=22):
Failed to install the requested application
The application's Info.plist does not contain CFBundleVersion.
Ensure your bundle contains a CFBundleVersion.
  Command: /usr/bin/xcrun simctl install 9A403314-88E2-495A-9182-AB09C2B85719 /Users/qiaobo/Workspace/hangtian/rfid_app/build/ios/iphonesimulator/Runner.app

#0      RunResult.throwException (package:flutter_tools/src/base/process.dart:172:5)
#1      _DefaultProcessUtils.run (package:flutter_tools/src/base/process.dart:322:19)
<asynchronous suspension>
#2      SimControl.install (package:flutter_tools/src/ios/simulators.dart:145:29)
#3      IOSSimulator._setupUpdatedApplicationBundle (package:flutter_tools/src/ios/simulators.dart:451:31)
<asynchronous suspension>
#4      IOSSimulator.startApp (package:flutter_tools/src/ios/simulators.dart:351:15)
#5      FlutterDevice.runHot (package:flutter_tools/src/resident_runner.dart:434:54)
#6      _asyncThenWrapperHelper.<anonymous closure> (dart:async-patch/async_patch.dart:75:64)
#7      _rootRunUnary (dart:async/zone.dart:1134:38)
#8      _CustomZone.runUnary (dart:a

problem seems  quite obvious :"Failed to install the requested applicationThe application's Info.plist does not contain CFBundleVersion."

Hi @zzljob
there are issues that might contain a possible solution for your case
https://github.com/flutter/flutter/issues/40623
https://github.com/flutter/flutter/issues/42383
https://github.com/flutter/flutter/issues/48895
https://github.com/flutter/flutter/issues/53539
https://github.com/flutter/flutter/issues/54427
if those don't fix the problem
can you please provide your flutter doctor -v ,
your flutter run --verbose
and your pubspec.yaml
Thank you

Hi @zzljob
Without additional information, we are unfortunately not sure how to resolve this issue. We are
therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the
bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution


Image Sizes

A couple of months ago we implemented basic image resizing and compression support with Sharp, the second half of the work that needed doing was supporting multiple image sizes in Ghost.
For example: You upload a 5,000px wide feature_image to a post.

Step 1: Resize to max 2,000px and enable basic compression to load image on post.hbs ✅
Step 2: Generate smaller thumbnails to be used elsewhere on the size, eg. index.hbs

There's already been a lot of discussion about this which has gone undocumented, so I'm going to summarise all the approaches and decisions I can remember.

We want to generate resized images on-request. So an image request takes place with a "width=300" setting, and if the image doesn't already exist then we generate it on the fly.
We want to limit the allowed-requests to an explicit set of sizes to prevent DDoS/abuse
To start with those sizes will be defined by theme package.json

In short, this will look like a very basic implementation of cloudinary fetch with a couple of transformation options.

Implementation Details
The theme determines the sizes it wants/needs to use based on its own layout design, and specifies those in its package.json. For example, in Casper we smaller thumbnails on the index page, eg demo.ghost.io
"image_sizes" {
  "small": {
    "width": 320,
    "height": 200,
    "crop": "fill"
  },
  "medium": {
    "width": 500,
    "height": 200,
    "crop": "fill"
  },
  "large": {
    "width": 700,
    "height": 400,
    "crop": "fill"
  }
}

For image sizes to be valid they must specify both width and height. Crop mode is optional and defaults to fill. Have no particular desire to replicate every cropping mode which sharp provides, nor any of the entropy based cropping.

Our fill => sharp cover
Our fit => sharp contain

Once sizes are specified, they can be passed as paramaters to the img_url helper in Ghost themes, eg:
<img src="{{img_url feature_image size="small"}}" alt="{{title}} />

Once a request is made for an image, as long as a valid size is provided, then Ghost returns the image at the requested size and stores it for re-use in future. There is no spec for what this looks like, but I would guess that we would generate image files based on size names and store them alongside the master images. Eg.

file.jpg

file-small.jpg
file-medium.jpg
file-large.jpg

Questions
Unknown: How will this work with a headless front-end eg. Gatsby?
Tasks

[ ] Add size attribute to img_url helper
[ ] Add automatic image thumbnail generation
[ ] Validate image sizes in gscan
[ ] Update Casper

This issues should close https://github.com/TryGhost/Ghost/issues/4453

Initial go at the img_url helper - it uses . to delimit the filename and the size e.g. img.jpg and img.small.jpg

@JohnONolan I worked this weekend on the same feature. #10183
Maybe it could be useful

@notanengineercom Thanks! We'll definitely take a look. Image handling is sort of the third-rail of Ghost at the moment, so there's a lot of nuance to implementing this in a way which is broadly compatible for all users. Appreciate the PR either way though!

Yes I'm aware and I agree that it has to be more compatible/flexible. I just made the change to process the images on upload, and without changing the image ratio. I also changed some of the image processing in the image manipulator in lib/images/ (enabled cache for unix, changed the processing kernel and added imagemin which helps alot with the compression problem that sharp sometimes gives #10144).

Maybe Ghost Content API also needs size parameters.

@allouis Can we close this issue?

@kirrg001 Looks like " Validate image sizes in gscan" hasn't been completed - should we leave it open until that's done?

I'd suggest to track this task in GScan as a separate issue, leave a comment here and close this one.
If we track this in GScan separately, maybe we get some help/attraction from the community.

Closing - the gscan issue can be tracked here https://github.com/TryGhost/gscan/issues/173


Wall improvements (rebased)

This should just be the changes from https://github.com/yunity/karrot-frontend/pull/630 but rebased ontop of latest quasar branch, but I got a bit confused/tired, and wasn't sure whether I have undone some work somewhere, so I stuck it in this branch.

I also wanted to see how the new netlify branch deploys work! If you click the Show all checks then for the line _ deploy/netlify — Deploy preview ready! _ click the Details button, you can see it deployed!

Merged in #630


audit: disallow devel specs in core

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[ ] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew tests with your changes locally?

See discussion in https://github.com/Homebrew/brew/pull/5060#issuecomment-428149176

Devel specs have been removed or have open PRs to be removed, merging.

All devel specs have been removed.


Hi, file socket support ? *un

good idea support network/file socket for input and output, or/and fifo file..

Could you please elaborate a bit on this issue?
It seems stdin/stdout should suffice, in any case – you may redirect them to/from anywhere as you like (POSIX sockets, files, etc.). If you know what a Unix philosophy is, the best way to achieve this is by concatenating tools together, not by creating a single tool to handle everything (immaturely).

I agree, maybe sockets are not the best idea. Now I look in the direction of D-Bus for accessing transditertsii no apparent relation to translation API.
It would be desirable to have a user-friendly interface to access the compiler from C/C++ code.

Not sure what you are trying to achieve, but this tool was not designed to be a library (nor it is a "free API wrapper" to Google Translate), not to mention C/C++. You may fork it like a normal process which gives you stdin/stdout access, and that's all we should have.
Hint: If you want a user-friendly interface that much, you may consider Google's official API (and according to Google's TOS, that's the only legit way of using it).


General Improvement

Changed

If RuntimeError raised while reading custom attributes in avalon.maya.lib.read(), parse source node name if has input connection. Useful for message type connection.

Use creator plugin's name value as default, if avalon.pipeline.create()'s arg name receive "" or None.

Remove unnecessary value remap in cbsceneinventory app, which causing wrong container data name passed to loader.update.

Remove hard-coded container id "pyblish.avalon.container" in each host.

Move collect_container_metadata from cbsceneinventory app to each host.ls, thought putting this logic to each host would making more sense.

Hoping these changes are making sense to you, please let me know what you think :)

Looks like some nice fixes. I need to double check coming week whether it doesn't break anything on our end, but it looks good. :)

If RuntimeError raised while reading custom attributes in avalon.maya.lib.read(), parse source node name if has input connection. Useful for message type connection.

Where/how are you using this? Are you using this on instances?

Move collect_container_metadata from cbsceneinventory app to each host.ls, thought putting this logic to each host would making more sense.

The reason we ended up doing that is that I felt the data was purely intended for the UI - as such I felt only exposing the functionality there made sense. Also to ensure the ls() kept a high speed as a query, but that was probably a micro-optimization.
Both is fine with me.

The only minor red flag is where AVALON_CONTAINER_ID is coming from. On top of that, it's hard-coded in pipeline.py

Is it configurable? If it is, shouldn't that invalidate the current schema? I thought it was supposed to be a fixed value in Avalon.

Good question. There's no reason to change this value, so maybe hard-coding it isn't a problem.

@BigRoy

Where/how are you using this? Are you using this on instances?

I have another objectSet which functions alike container, but instead having all referenced/imported nodes as member, it only contain the root assembly node and other important nodes, like an interface for artists. And I connect the container to the correspond interface node with message type connection.
@mottosso

There's no reason to change this value, so maybe hard-coding it isn't a problem.

Then I shall ignore the change request ? :P
The reason I made that change was because I was implementing a custom lookup for containers, but I wouldn't wont to hard-coding that id string in my config, so I thought making it as an attribute in the core  would be nice.
Thanks !

Then I shall ignore the change request ? :P

Haha, yes. Sorry. :)

Merging this, thanks !


attach-detach-timing tests are flaky

attach-detach-timing.html mostly succeeds, but once in awhile fails. All three tests in that file show this behavior. I had this on travis builds as well as locally. PTAL @azakus

E.g. https://travis-ci.org/Polymer/polymer/builds/123298983

Yeah, they've only started to become flaky in Chrome 50. We'll need to investigate that.

We haven't observed the flakiness in a while, therefore I am closing this issue.


Requirement of bcrypt library for ARM

Is it possible to cross -compile bcrypt library for ARM?
I have tried compiling but in bcrypt/crypt_blowfish/Makefile i see we are including x86.o?

Update: I tried removing x86.o from makefile and could obtain cross-compiled bcrypt.a . But what was the significance of x86.o?

The crypt_blowfish subdirectory is a verbatim copy of the crypt_blowfish bcrypt implementation as can be found here:
http://www.openwall.com/crypt/
Which is what my library wraps. I've never tried to compile this code under non-x86 platforms, but crypt_blowfish/README makes a small mention that the project should compile on non-x86 platforms producing no code from x86.S.
I suggest you try to compile crypt_blowfish as a standalone project first and, if you find trouble building it from the Makefile, contact Solar Designer directly.


Buffered state diff bug fix

This is on top of my PR #832.
I think, the root issue is that in WidgetModel the attribute _buffered_state_diff is not set correctly on initialization. So when the first sync from javascript happens, the change handlers of all the attributes are notified. Also, if any of the other attributes changed, they are being overwritten by the old values which came back in the comm message.

@SylvainCorlay I think this change might cause an issue with loading widgets just from the javascript side. I do not know the exact code, but I believe that it relies on _buffered_state_diff being set on initialization.
If you can point me to how we can recognize if a widget is initialized from javascript side how I can identify, I'll make changes to ensure that the _buffered_state_diff is set correctly.

@ssunkara1 I will dig into this logic when I am back from Milan. In the meantime, you can test with widgets created from the js side:

the panzoom widget in bqplot is created by the toolbar on the js side.
controller axes and buttons are created from the js side.

Looking at this...

Submitted a PR to your PR.

Thanks @jasongrout Tested this. Seems to be good. Have a look.

This looks good to me. Thanks for working on this!


Kindly Resolve this issue please :  componentWillReceiveProps has been renamed, and is not recommended for use. See https://fb.me/react-async-component-lifecycle-hooks for details.

componentWillReceiveProps has been renamed, and is not recommended for use. See https://fb.me/react-async-component-lifecycle-hooks for details.

Move data fetching code or side effects to componentDidUpdate.
If you're updating state whenever props change, refactor your code to use memoization techniques or move it to static getDerivedStateFromProps. Learn more at: https://fb.me/react-derived-state
Rename componentWillReceiveProps to UNSAFE_componentWillReceiveProps to suppress this warning in non-strict mode. In React 17.x, only the UNSAFE_ name will work. To rename all deprecated lifecycles to their new names, you can run npx react-codemod rename-unsafe-lifecycles in your project source folder.

Please update the following components: CCInput, CreditCardInput

getting the same warning:
Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See https://fb.me/react-unsafe-component-lifecycles for details.

Move data fetching code or side effects to componentDidUpdate.
If you're updating state whenever props change, refactor your code
to use memoization techniques or move it to static getDerivedStateFromProps. Learn more at: https://fb.me/react-derived-state
Rename componentWillReceiveProps to UNSAFEcomponentWillReceiveProps to suppress this warning in non-strict mode. In React 17.x, only the UNSAFE name will work. To rename all deprecated lifecycles to their new names, you can run npx react-codemod rename-unsafe-lifecycles in your project source folder.

Please update the following components: %s, CCInput, LiteCreditCardInput

Facing the same warning

is anyone solve this issue please I face the same warning


[IOTDB-6178] Add fsync for schemaregion, CQInfo, ModelInfo

more details can be seen in https://issues.apache.org/jira/browse/IOTDB-6178.
the solutions can be found in https://apache-iotdb.feishu.cn/docx/L6XNd0HBbo57xFx1DQ0cjkNenhg
In this pr, I add fsync for schemaregion, CQInfo, ModelInfo.

Codecov Report

Merging #11300 (4ff5078) into master (e929cee) will increase coverage by 0.00%.
Report is 21 commits behind head on master.
The diff coverage is 85.71%.

@@            Coverage Diff             @@
##             master   #11300    +/-   ##
==========================================
  Coverage     48.55%   48.55%
- Complexity    24142    24166    +24
==========================================
  Files          2792     2799     +7
  Lines        171025   171195   +170
  Branches      20423    20443    +20
==========================================
+ Hits          83038    83123    +85
- Misses        87987    88072    +85

Files
Coverage Δ

...apache/iotdb/confignode/persistence/cq/CQInfo.java
52.50% <100.00%> (+0.23%)
:arrow_up:

.../mtree/impl/mem/snapshot/MemMTreeSnapshotUtil.java
60.00% <100.00%> (+0.83%)
:arrow_up:

...apache/iotdb/confignode/persistence/ModelInfo.java
0.00% <0.00%> (ø)

... and 70 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Tolga - app that has a dcc and a choropleth map

dash core component tied to a choropleth graph

[ ] Layout- 1row:1col;  1row:2col;  2row:1col;  3row:1col;  multiple row and col
[ ] Callback- 1input:1output;  2input:1output;  1input:2output;  Multiple output input
[ ] Components - dropdown, checklist, DataTable, RadioItem,
[ ] Data set - sports, geology, manufacturing, finance, general
[ ] Graph- Bar, Line, Histogram, Scatter, Pie, Candle, etc

Added the population density application with a choropleth, and created a pull request.

wow @tolgahancepel  congrats you wrote the first app :)

Done. population-density.py


Version Packages

Try out this version of the Stacks Wallet - download extension builds.

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
Releases
<EMAIL_ADDRESS>Minor Changes

#1326 f1382d1b Thanks @aulneau! - This update replaces our use of recoil for state management to jotai. This gives us tighter integrations with tools such as react-query and rxjs.

Patch Changes

#1222 08fe3e99 Thanks @kyranjamie! - Removes unused old code once used in the authenticator

let's wait to merge this until we've done a full QA on this and we feel confident in it

It seems perfect to me !!! Let's wait and see what you think ... thank you
!!!! *
El mar., 22 jun. 2021 5:33, Thomas Osmonson @.***>
escribió:

let's wait to merge this until we've done a full QA on this and we feel
confident in it
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/blockstack/stacks-wallet-web/pull/1330#issuecomment-865501542,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUQMRSPT7XUR7THN5DEPUC3TUAABHANCNFSM47BHKHPA
.

@aulneau Can I get some content to the what are use cases needed for be tested from QA?

@aulneau Can I get some content to the what are use cases needed for be tested from QA?

Yes, of course
I think what makes sense for this PR is to do a similar test for the previous state refactor. I'd suggest loading up https://stacks-wallet-web.vercel.app/ and testing all the functionality that the app provides, so:

log in
Try to do any of the actions with an account that has 0 STX (should see an error in the tx signing window)
in the extension, log out and sign in with a different seed phrase and try to do any of the actions in the test app with the previous session
sign in with correct session
do these actions:
contract call button (tx will fail)
STX transfer (tx should not fail)
NFT with postconditions (tx will fail)
contract deploy (tx should not fail)
Get SteLLa tokens (tx should not fail)
Send stella tokens (tx should not fail)
get Rocket tokens (tx should not fail)
Send rocket tokens
send Stella tokens from within the extension (not via the test app)
switch accounts
switch networks

Most of the use cases above passed with the exception of the known issue that was created and enhancements along with it.


Added CODEOWNERS file to enforce reviewers.

should we use a github team, instead of individual users?
that ensures that the ownership is done via groups


Customize run command

Feature Request
Hi! I've discovered this project and I love it, thank you for making it!
I was wondering if it's possible to specify a command to execute, or to make it work with vue-cli
I'm using the command vue-cli-service test:unit, and my tests are passing, but with the GUI I suppose it runs Jest directly so it fails with:
import Vue from 'vue';
^^^

SyntaxError: Unexpected identifier

Thanks!

Hey 👋 ,
I'm glad that you like the project.
Could you please add the following configuration to package.json and check?
"majestic": {
    "jestScriptPath"<EMAIL_ADDRESS>test:unit"
}

Thanks for your quick reply!
(I've had to replace \\ with /)
It's using vu-cli-service now, but it seems it's without the config for jest (defined in the package.json)
If I run<EMAIL_ADDRESS>test:unit in the terminal the tests passes
But in the GUI it says Jest encountered an unexpected token
(also I'm using TypeScript)

I created a new project via the Vue CLI with Jest (Config in package.json) + typescript and I can run the project. So I'm not sure why your one is not working. If you could share a small repo with the issue, I can take a look into it.

You're right I've tried with another similar project and it worked like a charm!
I'll try to see what's causing the error in the first project

I haven't touched anything, but now it works!
Thank you :smile:

Hey again 👋 ,
From Majestic 1.3 (Which I released just now) onwards the config needs to be as follows.
  "majestic": {
    "jestScriptPath"<EMAIL_ADDRESS>    "args": [
      "test:unit"
    ]
  }

Cheers!

Hi!
Thank you that's very kind of you!
 To run things up with my setup I have to run ng test or yarn test, which will then compile the relevant jest config and run up jest, but I'm not sure how to configure majestic to work with that.

 To run things up with my setup I have to run ng test or yarn test, which will then compile the relevant jest config and run up jest, but I'm not sure how to configure majestic to work with that.

It could be any binary but the binary that you provide should forward the args correctly to Jest at the end otherwise things won't work.
Would you be able to share whats in your yarn test script has so I could see how we can make it work?
There are no stupid questions :)

Thanks @Raathigesh, any thoughts you have would be appreciated :)
My yarn test script actually doesn't do much, it just calls ng test.
I'm using @angular-builders/jest. My understanding is that it:

integrates Jest into Angular CLI's workflow
merges together a default config (defined in the lib) with any overrides that you provide (to avoid needing a lot of setup / boilerplate in your app's codebase)
makes use of jest-preset-angular internally
allows you to pass through any jest cli options (either from the config file or by adding them to the end of ng test ...jest-args-can-go-here at the command line)

If I run this command in the terminal (from the project root folder), I see the test results all ok in the terminal:
ng test myproject
I tried adding the following to my package.json and then running majestic:
"majestic": {     "jestScriptPath": "ng test myproject"   }
but when it starts up I see this error in the (web browser) console:
ui.bundle.js:42 TypeError: Cannot read property 'projectRoot' of undefined

hey 👋 ,
I created a sample project and I was able to start majestic with the following config.
"majestic": {
    "jestScriptPath": ".\\node_modules\\@angular\\cli\\bin\\ng",
    "args": [
      "test"
    ]
  }

You can add more arguments to the args array like the project name.
Let me know if you run into issues.

Hey @Raathigesh, thanks for the amazing work!
I'm trying to make it work with vue-cli as well but it looks like it's just ignoring my jest.config.js file.
I use the following config:
{
  "majestic": {
    "jestScriptPath"<EMAIL_ADDRESS>    "env": {
      "TEST_MODE": "unit"
    },
    "args": [
      "test:unit",
      "--config=./jest.config.js",
      "--testPathPattern=/unit/",
      "--runInBand"
    ]
  }
}

And when I run majestic --debug I'm getting:
⚡  Majestic v1.4.1 is running at http://localhost:4000
ℹ Majestic configuration from Package.json:  {                                                                                Config Resolver 16:22:54
  jestScriptPath<EMAIL_ADDRESS>  env: {
    TEST_MODE: 'unit'
  },
  args: [
    'test:unit',
    '--config=./jest.config.js',
    '--testPathPattern=/unit/',
    '--runInBand'
  ]
}
ℹ Resolved Majestic config : {                                                                                Config Resolver 16:22:54
  jestScriptPath<EMAIL_ADDRESS>  args: [
    'test:unit',
    '--config=./jest.config.js',
    '--testPathPattern=/unit/',
    '--runInBand'
  ],
  env: {
    TEST_MODE: 'unit'
  }
}
ℹ Error occured while obtaining Jest cofiguration for coverage report

Any clue?

Hey @pirhoo,
It seems like there is something going on when obtaining coverage report path. Unfortunately, the error is not printed to the output but it should have been. I'll do a release with enhanced error logging so we could see what's going on and also fixed a few things around this area so thing might work as well.
I'll ping here after releasing the next version in a couple of days so you could check again.

Copy that, thanks @Raathigesh !

Hi again @pirhoo 👋 ,
Released 1.5.0. Could you please try again.

Thanks for the doing this so quickly @Raathigesh!
The error is a little bit more explicit now:
ℹ Error occured while obtaining Jest cofiguration for coverage report SyntaxError: Unexpected token d in JSON at position 1

The Jest config is here and works well when executed with jest (thought vue-cli-service). The package.json is also valid.

I checked out the repo and it looks like when I provide the --app flag, I see the error but without the --app flag, it works. Are you seeing the same behavior?

You're right, Majestic works well without the --app flag :dizzy_face:

That doesn't add up. I'll have a look at it.

(in the meantime I'm using the --noOpen flag - it's great)

hey y'all, what if you have more than one test script, for example
{
  "scripts": {
    "test": "jest -c jest.config.unit.js",
    "itest": "jest -c jest.config.integration.js",
  }
}


netstats does not work

i run  sudo netstat -anp, but get no information, just below content:
(No info could be read for "-p": geteuid()=1000 but you should be root.)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node   PID/Program name     Path

cat /etc/network/interfaces ?
https://wiki.debian.org/NetworkConfiguration

ifupdown has been replaced by netplan(5) on this system.  See
/etc/netplan for current configuration.
To re-enable ifupdown on this system, you can run:
sudo apt install ifupdown
i  install ifupdown , work as before ,   can you run netstats correctly?

#2249 (message). On a quick look, the "No info could be read for "-p"" error is a side effect of there being no entries at all.


Use IO.binread instead of IO.read

Problem
Looks like there are multiple problems related to this code.

Fix for Windows
https://github.com/twitter/twurl/issues/89
https://github.com/twitter/twurl/issues/68
https://github.com/twitter/twurl/issues/58

Fix for Ruby 2.6.0+(?)
https://github.com/twitter/twurl/issues/109

IO.read doesn't handle binary file well due to encoding.
https://techblog.leosoto.com/reading-binary-file-on-ruby/
And for #109 , I can reproduce the same error with Ruby 2.6.0 + latest Mac OS X version and confirmed this PR fix the issue.
Solution
Use IO.binread instead. This was introduced since Ruby 1.9.2, so it should be okay as twurl only supports 1.9.3+ as far as I know.
Things to consider
As this PR will force binread for all files, I'm not sure if we want to keep existing implementation and then create a new option for binary file (e.g., --file-binary, which is similar to what curl offers)

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


Lab 2

Had to redo the code as I lost my usb with original code.
-Little buggy and crashes after first run.

????!
On Mon, Nov 12, 2018 at 4:13 PM hbhinder2<EMAIL_ADDRESS>wrote:

Had to redo the code as I lost my usb with original code.
-Little buggy and crashes after first run.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/NAIT-CNT/CMPE1700.Public/issues/2, or mute the thread
https://github.com/notifications/unsubscribe-auth/AeTcG8yh6OJVNTPuvdVdqG6tVDUSmhnGks5uufd1gaJpZM4Yajni
.


No-unused-expression wrongly lints a comma-separated expression.

Bug Report

TSLint version: 4.3.1
TypeScript version: 2.1.5
Running TSLint via: Visual Studio Code

TypeScript code being linted
let x: number, y: number;
x = 1, y = 2;

with tslint.json configuration:
{
    "rules": {
		"no-unused-expression": true
	}
}

Actual behavior
Line 2 lints with expected an assignment or function call
Expected behavior
Line 2  contains two assignments, so it should not be linted.

Why not just use x = 1; y = 2;?

Doesn't work on one line if statements.


Make the language switch more intuitive

Make it clearer that it's not another field, but has impact on all that follows.

While implementing this, we need to check if the app is able to send several languages, and otherwise, add a warning that the current modifications or any un-uploaded images in the current language will be lost.

I think we should consider removing the language field in the app completely, and only display/edit in the language of the interface of the app. That will make things much simpler.

only display/edit in the language of the interface of the app.

Lots of reasons why people would use an interface language different than what they're scanning. I think a separate setting would be preferable.


Implement selenium service v4

Clone of https://github.com/tebeka/selenium/pull/275

@ChristianSch, since https://github.com/tebeka/selenium is dead, please consider using https://github.com/go-auxiliaries/selenium instead

@ChristianSch, since https://github.com/tebeka/selenium is dead, please consider using https://github.com/go-auxiliaries/selenium instead

Thank you so much


fix: Ensure test account has default draft MIME type

We should validate this behavior in Bridge first before accepting this MR.


Docker apt repository only having one version

With the old repository we had package "lxc-docker" pointing to latest greatest version and "lxc-docker-1.6.0" etc for specific version.
With the new repo there is only one package "docker-engine" in the "Packages" file, pointing to 1.8.1 although more versions do exist ( http://apt.dockerproject.org/repo/pool/main/d/docker-engine/ )
For automatic use of this repo, like with Chef/Puppet, it is quite handy if you can pin a certain version and later raise that version for automatic upgrades

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

Closing as a dup of #13191

No worries, GH search is awful.
Btw, what should actually happen here is you specify the version like so: docker-engine=x.y.z-0~trusty.


fix(vue-query): ensure built-in types are not being unwrapped

Resolve the following error
This error was mentioned in PR  https://github.com/TanStack/query/pull/5935#issuecomment-1705020256
import { useQuery, UseQueryOptions } from https://github.com/TanStack/query/tree/master/packages/vue-query;
import { Ref, toRef } from https://github.com/vuejs/core;

type MaybeRef<T> = T | Ref<T>;
type MaybeRefOrGetter<T> = MaybeRef<T> | (() => T);

const fetchUser = (userId: Date) =>
  fetch(`/api/user/${userId.toISOString()}`).then(res => res.json());

type User = any;
export function useUser(
  userId: MaybeRefOrGetter<Date>,
  options?: UseQueryOptions<User, any, User, readonly [string, Ref<Date>]>
) {
  return useQuery({
    queryKey: ['user', toRef(userId)],
    queryFn({ queryKey }) {
      return fetchUser(queryKey[1]);
    },
    ...options,
  } satisfies typeof options);
}

example.ts:185:24 - error TS2345: Argument of type '{ toString: {}; toDateString: {}; toTimeString: {}; toLocaleString: {}; toLocaleDateString: {}; toLocaleTimeString: {}; valueOf: {}; getTime: {}; getFullYear: {}; getUTCFullYear: {}; getMonth: {}; ... 32 more ...; [Symbol.toPrimitive]: {}; }' is not assignable to parameter of type 'Date'.
  Types of property 'toString' are incompatible.
    Type '{}' is not assignable to type '() => string'.
      Type '{}' provides no match for the signature '(): string'.

In that PR, not avoiding unwrapping built-in types resulted in errors, such as Ref, occurring.
Before

After

Codecov Report
Patch has no changes to coverable lines.
:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the GitHub App Integration for your organization. Read more.

Files Changed
Coverage

packages/vue-query/src/useBaseQuery.ts
ø

packages/vue-query/src/useInfiniteQuery.ts
ø

packages/vue-query/src/useQuery.ts
ø

:loudspeaker: Thoughts on this report? Let us know!.

what about user-defined classes?

When dealing with user-defined classes, we can draw inspiration from Vue's handling method, as demonstrated here:
https://github.com/vuejs/core/blob/0e8bbe873e579f3d3a74c44af28f7df9e7a06978/packages/reactivity/src/ref.ts#L459-L472
A possible implementation might resemble the following:
declare module '@tanstack/vue-query' {
   export interface RefUnwrapBailTypes {
     UserDefinedClass: UserDefinedClass;
   }
}

However, it's important to note that @tanstack/query-core will convert the queryKey into a string using JSON.stringify to use it as a key for cache access. This approach might encounter issues with types like Map, Set, or user-defined classes that cannot be stringified.
Given this consideration, I'm not sure if queryKey should support such a wide range of types.


cocomac: Watch 021582

cocomac requests the watch of the watch_keyword 021582. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

021582 has been seen in 2 true positives, 0 false positives, and 0 NAAs.

Approved by Ryan M in Charcoal HQ


List all the projects that are willing to change and use this format

Here's a working list of tracing systems and constraints related to this specification

System
Trace ID
Span Id
Flags
Notes

Google instrumentation/Stackdriver Trace
128bit
64bit
?

Jaeger
128bit
64bit
sampled, deferred, debug
• we set the debug flag when user code does span.SetTag(SAMPLING_PRIORITY, v) v > 0.• it always sets sampled: 1 (in our case sampled bit is authoritative, not a suggestion - suggestion would have deferred: 1)• the backend will not down-sample the data any further (which it can do for normal sampled traces to shed the load)

Tracelytics
160bit
64bit
?

Zipkin
128bit
64bit
sampled, debug
• In B3, sampling is implied as authoritative downstream, and can be null• incompatible w/ B3 approach of single-span/RPC, so needs work both server side and all tracers.

Please note your project if not already on the list, so we can keep requirements.

Jaeger | 128-bits trace_id | 64-bits span_id | 3 bits used in flags (sampled, deferred, debug)

@yurishkuro I know what deferred means (you explained in the doc) but can you explain the debug field as well?

we set the debug flag when user code does span.SetTag(SAMPLING_PRIORITY, v) v > 0.
it always sets sampled: 1 (in our case sampled bit is authoritative, not a suggestion - suggestion would have deferred: 1)
the backend will not down-sample the data any further (which it can do for normal sampled traces to shed the load)

Tracelytics | 160-bit trace_id | 64-bit span_id

I reformatted comments into a table above. Note from another issue is that in Zipkin, support for this format wouldn't happen until users ask for it, especially as it implies a significant amount of work to tracers and the server side, due to single-host-span model. For example, this spec is incompatible with span-per-rpc defined in b3, as there's not enough room to store the whole context (trace,parent,span id).
I'd expect demand to source from at least google-related sites, just that whatever demand needs to be enough to motivate tracer maintainers to support two propagation formats simultaneously (B3 and this). This labor aspect is a constraint that may not apply to others.

sky-walking project has interested in this, although, in order to improve the performance(less backend memory requirements) of Topological graph of application clusters, we set more info in propagation than others.
Our format is traceSegmentId|spanId|applicationCode|peerHost|distributedTraceIds|sampled. traceSegmentId is only id in current JVM. distributedTraceIds are real trace_ids, more than one values are for batch requirements.
I have a propose, can we design this format as a extendable format. e.g. the first four fields are necessary, but the tracer implementation can use more fields?

We are planning to make the move to distributed tracing from a single process tracer, the format is not yet defined, so we could definately see us moving to Trace-Context header.
In addition to trace id, span id and flags we could make use of additional optional key value pairs, but i see no problem solving this with an additional vendor specific header. We will also sign the trace-context with a hash-hmac key, since we have different customers calling each other we need to define the boundary, but this is a specific header as well.
One thing i see a bit problematic with "flags" is that they have to be defined up front in the spec, or they might cause incompatibilities between vendors.

Hello all. We are looking at using OpenTracing and my searching for the on-wire/protocol for SpanContext led me here.  I was surprised to not find this part solidly defined as it seems critical to the broad adoption of OpenTracing.   Some observations - hopefully of use:

seems like the minimal abstract span context should be {traceid, spanid} and a is high priority to define. Other things such as sampling could be other headers or optional fields defined later.
having just fought int64 issues between gRPC & Swagger/REST and prog langs (Javascript 52 bit integers anyone?), using 'string' as the type for traceid and spanid is less bug prone, future safe, and size tuning can be done depending on installation. DB index optimization could handled by local configuration convention (e.g. traceid strings are b64'd 128 bit little endian ints)
Given that HTTP2 will likely become a dominant transport (gRPC, etc), bit packing the header values becomes less important thanks to HPACK compression.
Someone mentioned HMAC - if there is need for signatures and even encryption, there is already a good format for this - JWT (lots of debugged libraries, fairly compact).  The overhead for 'Unsecured JWTs' (no signature, not encrypted) is pretty low.  It's also easy to add other fields if needed.

An unsecured JWT with 'tid' and 'sid' strings might be a decent format - the spec is short, libraries abound, id size is tuneable, and it's relatively future safe (id sizes & adding fields).

@msample see http://stackoverflow.com/questions/43619434/does-opentracing-specify-any-on-wire-protocol-format/43619435#43619435

@yurishkuro thanks, I would have posted to stackoverflow if I had wanted to.  I infer that you don't want this discussion here so I'll leave it at this.
your answer: "The reason for this is that such standardization is not necessary as long as the target architecture is using the OpenTracing libraries from the same tracing system"
Unfortunately, that  requirement is often a challenge in larger, polyglot microservices deployments that use many different libraries. Pardon my confusion - I thought a standardized wire format was the purpose of this project.

I infer that you don't want this discussion here so I'll leave it at this.

@msample - this was a FAQ for OpenTracing, that's why I posted to SO. The standardized wire format is the purpose of this project, TraceContext, but not of OpenTracing.

Unfortunately, that requirement is often a challenge in larger, polyglot microservices deployments that use many different libraries

Our (Uber's) ecosystem is 2000+ microservices in 4+ languages and dozens of frameworks. But we consistently use Jaeger as the tracing backend, and Jaeger libs guarantee wire interop. Because all services and libs are instrumented with OpenTracing, we can (theoretically) switch the tracing backend & libraries. It's just rather hard in practice since we can't upgrade 2000+ microservices in lock-step. If we did try to switch, then the wire interop would become very useful indeed.

@yurishkuro  I actually kind of agree with @msample.
We here at Trustpilot have a few thousand microservices and we are consistently using logstash for all services.
Our scenario is that we are looking to implement opentracing but can't afford to implement vendor specific code in clients since updating them (if we made the wrong choice of OT backend)  would be too costly ( /impossible if libs for chosen backend did not exist).
My point is:
We allready have the infrastructure to transmit logs and dispatch them using an OT client towards a chosen backend so :-)WHY:-) would we need to introduce vendor specific code in our client libs for other reasons than it simply not being part of the standard.
[btw. enjoyed your talk (and donuts) at osCon]

@sloev to clarify, I believe the approach has been to get as many OpenTracing-enabled Tracers to agree on a wire-protocol, then "bless" that wire-protocol in OpenTracing (though I doubt OT will ever require support for a particular protocol, as it's orthogonal to the instrumentation API). Trying to dictate a wireprotocol to a number of disparate tracing systems which could nonetheless support a common instrumentation API was deemed a non-starter for getting that first tier of agreement.

I'm not sure the connection between log dispatch and this cross-process propagation format, except facilitating that the ids log messages are indexed against are coherent within a trace.
It is certainly the case that propagation format inside a library is easier to change than the library itself. In OpenZipkin ecosystem, for example, the binding of headers to tracing happens more often at an abstraction higher than the tracer was defined at. Worst case, middleware can translate things provided the actual trace context values are compatible. More on that..
The values in the trace context (shape of the ID, how many etc), are what will ultimately decide what's compatible within this spec. There are other initiatives for example, that accept arbitrary strings. These won't fit. Also, there's things like X-Ray which include a temporal part of an ID, which might not fit well. So long story short, I agree with @tedsuo that this will be a subset of all propagation formats, hopefully collecting a stronger union there than exists today.

B3 format includes a debug flag, which is persisted such that it passes through all the way to collection tier. This lets operators request a trace be retained even in a scenario where a traffic spike or otherwise leads to traffic being dropped. This functionality isn't widely understood or supported consistently. From tracing workshop discussion, it seems this sortof flag could be accomplished in other ways, and in doing so could reduce the scope of what propagated context must include. Ex. replace this with advice.
One way would be to have a vendor-specific way to ask the collection tier for a force-sampled trace ID. An operator could use this trace ID and the tier would allow it to pass. Another way is that in a scenario like overload, just keep retrying until a request passes collection-tier sampling. Ex if collector is dropping 10%, unlikely 10 tries will fail.

Just a note that LightStep is also interested in supporting this format. Our caveats are that we would like to see a Baggage concept, and are concerned about a couple things being specified too narrowly, but it is very very close.

Just a note that LightStep is also interested in supporting this format.
Good news. Can you describe or link to the format info we have for others?
I can put it in.
Our caveats are that we would like to see a Baggage concept, and are
concerned about a couple things being specified too narrowly, but it is
very very close.
Baggage, tags or other stuff that rides as a sidecar and tied to a span ID
sounds like a reasonable feature to explore. I will open an issue on it.
Maybe add a column that this is mandatory for you and jaeger.
Scope (no pun intended) can surely increase over time, as long as we are
careful to not create tech debt along the way.
This project needs to be trustworthy and rock solid as otherwise it will
repeat the maintenance burden and confusion of other works that precede it
(the cost to reverse define B3 was very high and especially so for
volunteers). We dont want an effort that only highly staffed groups can
participate in.

I would rather list all project that have passed the tests. This is the best way to define support.


Connect to a Windows 2016 or Windows 10 remote host outside your domain, or with no domain

I was trying to connect from a domain-joined windows 10 client to a workgroup windows 2016 hyper-v server and followed the directions in the section "Connect to a Windows 2016 or Windows 10 remote host outside your domain, or with no domain", but it did not work. I had to do the following to get it to work.
Step 1: add fqdn to workgroup server (https://blogs.msdn.microsoft.com/virtual_pc_guy/2017/03/10/giving-a-workgroup-server-an-fqdn/)
Step 2: add registry keys for AllowFreshCredentials and AllowFreshCredentialsWhenNTLMOnly (https://powertoe.wordpress.com/2011/04/29/enable-credssp-from-a-windows-7-home-client/)
Afterwards, I was finally able to use hyper-v manager on my domain-joined client to manage my dev workgroup hyper-v server.

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

ID: 5c4bb2d4-9b81-b153-6936-3ca0f95bf631
Version Independent ID: 968f574d-3be8-2af6-7470-d4e1f65b4a48
Content: Remotely manage Hyper-V hosts
Content Source: WindowsServerDocs/virtualization/hyper-v/manage/Remotely-manage-Hyper-V-hosts.md
Service: na
GitHub Login: @KBDAzure
Microsoft Alias: kathydav

I was trying to use HyperV Manager on a Client in Domain1 and connect to a hyperV Server to Domain2. This Documentation helped me alot and I can sucessfully connect my HyperV-Manager Console. BUT I cannot use the "Connect" function to view the "VM Console". The VM-Console tries to connect a few times and ultimately fails with an Error Message: "Cannot connect to the virtual machine."

Please use a real support instance like Microsoft Support or Microsoft Forums. This repository is intended for documentation improvement only.
Wish I could help, but this repository is not intended for regular support issues, support requests or support questions.
You may want to look elsewhere for answers, unless you have suggestions for improving one or more specific pages in the MS Docs repository.
Disclaimer: I am not affiliated with Microsoft or the Microsoft Docs teams here on GitHub.
The intention of this repository is to improve on the existing documentation by providing the users a way to report factual errors, improvement suggestions and request updates for new versions.
The MS Docs team members might not have time to answer your question, both due to the small size of the team and the big workload.
Try the following resources to get in touch with users who may be able to help you:

TechNet forums: https://social.technet.microsoft.com/Forums/en-US/home
MSDN: https://social.msdn.microsoft.com/Forums/en-US/home
Microsoft Community: https://answers.microsoft.com/

#please-close


maestral pauses sync when a dropbox server error is encountered

Describe the bug
While a sync is in progress, this stack trace is generated:
...
2021-10-04 17:04:09 sync INFO: Indexing 957324...
...
2021-10-04 17:05:58 sync INFO: Syncing â 461/500
2021-10-04 17:06:18 manager ERROR: Dropbox server error
Traceback (most recent call last):
File "/home/anaconda3/lib/python3.8/site-packages/maestral/client.py", line 126, in convert_api_errors
yield
File "/home/anaconda3/lib/python3.8/site-packages/maestral/client.py", line 1155, in list_remote_changes_iterator
result = self.dbx.files_list_folder_continue(result.cursor)
File "/home/anaconda3/lib/python3.8/site-packages/dropbox/base.py", line 1976, in files_list_folder_continue
r = self.request(
File "/home/anaconda3/lib/python3.8/site-packages/dropbox/dropbox_client.py", line 323, in request
res = self.request_json_string_with_retry(host,
File "/home/anaconda3/lib/python3.8/site-packages/dropbox/dropbox_client.py", line 479, in request_json_string_with_retry
return self.request_json_string(host,
File "/home/anaconda3/lib/python3.8/site-packages/dropbox/dropbox_client.py", line 602, in request_json_string
raise InternalServerError(request_id, r.status_code, r.text)
dropbox.exceptions.InternalServerError: InternalServerError('593a9ccaf0c94894a0d057c39ae9d615', 500, '')
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/anaconda3/lib/python3.8/site-packages/maestral/manager.py", line 791, in _handle_sync_thread_errors
yield
File "/home/anaconda3/lib/python3.8/site-packages/maestral/manager.py", line 769, in startup_worker
self.sync.download_sync_cycle(client)
File "/home/anaconda3/lib/python3.8/site-packages/maestral/sync.py", line 2829, in download_sync_cycle
for changes, cursor in changes_iter:
File "/home/anaconda3/lib/python3.8/site-packages/maestral/sync.py", line 2888, in list_remote_changes_iterator
for changes in changes_iter:
File "/home/anaconda3/lib/python3.8/site-packages/maestral/client.py", line 1156, in list_remote_changes_iterator
yield result
File "/home/anaconda3/lib/python3.8/contextlib.py", line 131, in exit
self.gen.throw(type, value, traceback)
File "/home/anaconda3/lib/python3.8/site-packages/maestral/client.py", line 128, in convert_api_errors
raise dropbox_to_maestral_error(exc, dbx_path, local_path)
maestral.errors.DropboxServerError: Dropbox server error. Something went wrong on Dropboxâs end. Please check on status.dropbox.com if their services are up and running and try again later.
2021-10-04 17:06:18 manager INFO: Shutting down threads...
2021-10-04 17:06:18 sync INFO: Sync aborted
2021-10-04 17:06:18 manager INFO: Paused
2021-10-05 04:58:31 manager INFO: Connecting...
2021-10-05 04:58:41 manager INFO: Connected
To Reproduce
I don't know for sure, but I suspect the root cause of this is the absurdly large number of files I'm trying to sync. Dropbox's native sync daemon handles this level of volume well, it just doesn't run on Centos 7 like I need. So I don't think this is necessarily a limitation in Dropbox's API.
Expected behaviour
Maestral should wait a random amount of time and attempt to continue the sync from where it left off.
System:

Maestral version: 1.5.0
Python version: 3.8.3
OS: Centos 7
Desktop environment: none, running headless
PyQt version (for Linux GUI): none

Additional context
none

I suppose at this point this bug report should become a feature request. should I open a new one and close this one for that?

Leaving this as a bug report is fine. I'll discuss the issue with Dropbox support as well but some retry logic on our side makes sense to me.


[SW-475] Add duke dependency to --packages

We need to put this dependency here manually since spark is not able to resolve it if it's defined as transitive dependency. Fixes this https://stackoverflow.com/questions/44641158/h2o-error-when-calling-as-factor-on-h2o-data-frame

Just finished testing, it solves the issue.

LGTM. Thanks!


bugs for regexp.ReplaceAllString?

Go version
1.22.2
Output of go env in your module/workspace:
set GO111MODULE=on
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Administrator\AppData\Local\go-build
set GOENV=C:\Users\Administrator\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\Administrator\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\Administrator\go
set GOPRIVATE=
set GOPROXY=http://<IP_ADDRESS>:8081/repository/go-local/
set GOROOT=D:/Program Files/Go1.22.2
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=D:\Work\Git\system-watcher-api\go.mod
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\ADMINI~1\AppData\Local\Temp\go-build2208406462=/tmp/go-build -gno-record-gcc-switches

What did you do?
when i rename uploaded filenames, codes below
`
package main
import (
"fmt"
"regexp"
)
func main () {
var filename = "abc.123.txt"
var pattern = regexp.MustCompile("^(.+?)\.([^\.]+)$")
fmt.Println(pattern.ReplaceAllString(filename, "$1_.$2"))
}
What did you see happen?
`
output result: .txt

even when the codes like this
fmt.Println(pattern.ReplaceAllString(filename, "$1000.$2"))
the result unchanged
What did you expect to see?
it seems that golang can't get group no and strings
when i try this replace in javascript and c#, the out is "abc.123000.txt", which is my expected result

Related Issues and Documentation

regex: ReplaceAllString and ReplaceAll broken group replacement #65000 (closed)
Regex: Underscore (_) makes replace group not found #32885 (closed)
regexp: issue parse string #68940 (closed)
regexp: confusing ReplaceAllString result when using patterns like `$1_$2` #68712 (closed)
regexp: Expand rules are confusing #40329
regular expression sub-match not used in replace #42291 (closed)
regexp: ReplaceAllString unexpected behavior with $ in src #69399 (closed)
golang regex replace problem #29936 (closed)
regexp: backreference to capturing group breaks if followed by underscore #39594
strings: incorrect output #63596 (closed)

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

https://go.dev/play/p/hIgPEsAiel1
Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.
For questions please refer to https://github.com/golang/go/wiki/Questions


Bug: Unable to get 11.0.1 working - TypeError is logged and homebridge keeps restarting

Describe The Bug
Unable to get 11.0.1 working - TypeError is logged and homebridge keeps restarting (must remove plugin to restore homebridge)
To Reproduce
Fresh install of 11.0.1, go through login/auth, restart homebridge
Expected behavior
I expect after checking my 2 thermostats in the Honeywell Web UI config is linked.  It worked in previous versions for me no problem.
Relevant log output
After I authorize a new App, then auth with the plugin, I select my 2 thermostats in the Honeywell Web UI, then save, and there is HomeBridge UI to close window and restart Homebridge.  After restarting, homebridge just goes in a continuous loop...

[10/23/2021, 7:41:28 PM] TypeError: Cannot read property 'debug' of undefined
    at HoneywellHomePlatform.debug (/usr/local/lib/node_modules/homebridge-honeywell-home/src/platform.ts:840:30)
    at new HoneywellHomePlatform (/usr/local/lib/node_modules/homebridge-honeywell-home/src/platform.ts:53:10)
    at /usr/local/lib/node_modules/homebridge/src/server.ts:440:40
    at Array.forEach (<anonymous>)
    at Server.loadPlatforms (/usr/local/lib/node_modules/homebridge/src/server.ts:372:27)
    at Server.start (/usr/local/lib/node_modules/homebridge/src/server.ts:159:29)
[10/23/2021, 7:41:28 PM] Got SIGTERM, shutting down Homebridge...
[10/23/2021, 7:41:29 PM] [LitterRobotPlatform] Shutdown
[10/23/2021, 7:41:29 PM] [Harmony Hub] INFO - shutdown
[10/23/2021, 7:41:29 PM] [Rachio] Loading Rachio device: Jordan Redner  - aa2ddfdf-9cc0-4a1f-85a6-daf24ec1307c
[10/23/2021, 7:41:29 PM] [Rachio] Add Device: Jordan Redner
[10/23/2021, 7:41:30 PM] [Rachio] Adding Zone: Front Drip
[10/23/2021, 7:41:30 PM] [Rachio] Adding Zone: Front Lawn

other log lines...

[10/23/2021, 7:41:14 PM] [HB Supervisor] Homebridge Process Ended. Code: 143, Signal: null

.... repeats previous after restarting

To get my homebridge system back I remove the plugin.

Config for homebridge-honeywell-home
{
            "name": "HoneywellHome",
            "credentials": {
                "consumerKey": "xxxxxxxxx",
                "consumerSecret": "xxxxxxxxxx",
                "accessToken": "xxxxxxxxx",
                "refreshToken": "xxxxxxxxx"
            },
            "platform": "HoneywellHome"
        }

Screenshots
No screen images
Device & Model
Honeywell Home RCHT8610WF2006/W, T5 Smart Thermostat, Black
Node.js Version
v14.18.1
NPM Version
v6.14.15
Homebridge Version
v1.3.5
Homebridge Honeywell Home Plugin Version
v11.0.1
Homebridge Config UI X Plugin Version
v4.41.2
Operating System
Raspbian

Fixed in Version 11.1.0


better way to maintain the producer and renderer modules

Thanks for adding support for this! Now that we have some depth, do you see a better way to maintain the producer and renderer modules?
Originally posted by @jaredjj3 in https://github.com/stringsync/vexml/pull/25#pullrequestreview-943352839

The message types are the contract that binds the producer and renderer together. If we can make those types more stable, then we can independently work on the producer and renderer. Do you have any idea of how many more message types we need to cover let's say 80% of use cases? I'm looking for an order of magnitude and a level of uncertainty.

I would say around 50 messages. I have come to this number marking the VexFlow files that I believe might end up being a message,
You also suggested the past to make a class for each message.

I have come to this number marking the VexFlow files that I believe might end up being a message

Would you show me an example?

You also suggested the past to make a class for each message.

I like what we've landed on so far. The messages should be "dumb". Any message-related behavior should be encapsulated in a MessageReceiver.

messages.txt
43 and I decided to round up. It is just a quick exercise.

Ah, now I understand what you mean. Here's what I think we need to do:

Map each Vexflow file to a list of MusicXML elements
Determine what data we need from each MusicXML element to satisfy Vexflow, and those become our messages

Thoughts?

Sounds good. There are some one to one obvious elements that we should implement and that map pretty good. I would say that we should do as a minimum the sunset that allows to play the score:

stave keys
stave bars
tuplets

I am looking into how to resolve the chords in a sensible way. I want to go for scores with several parts then. I believe that both changes may have a big impact.

I'm continuing the maintainability discussion here. Please don't feel obligated to respond to my thoughts. I'm dumping them to possibly revisit later, and they're not particularly well organized.

I have two ideas that I'd like to experiment with:

Use state machines to update context, decide what next node to deeply dissect (Cursor is only top-level nodes),  and emit messages when the context and the state machine event warrant it.
Fragment message production so that it's easier to work on when there are multiple authors.

For example, this code is what happens when a <note> element is encountered:
https://github.com/stringsync/vexml/blob/1b5719625bddb0506bbb67b04a21b18fcc4b8077/src/producer.ts#L77-L170
The main state machine could invoke a child state machine (xstate docs). In our example, we could have rest and audible child state machines. The context object that would get updated would be slices of the variables currently available in the Producer.getMessages closure. Perhaps we don't even need Cursor anymore.
The same principle applies for the Renderer. The difference is that our events are vexml Message objects instead of element nodes.

Going to start working on this.

@rvilarl, I'd like to reflect on https://github.com/stringsync/musicxml/issues/1#issuecomment-1058066180 and our general approach. Please don't change anything you're doing now. The work you're doing will continue to shape the evolution of this library.
No pressure to continue the discussion, but I'm always happy to hear your thoughts.
Problem
The message pattern was heavily influenced by SAX parsing (example). This approach is conducive to state machines, as a SAX event can trigger transitions and side effects.
However, after studying Renderer, I don't see the rendering state machine approach scaling very well. The main drawback is that there is a lot of state you have to track, which can be difficult to maintain.
I think this is a consequence of MusicXML elements having a lot of forks in them. For example, see the possible contents of <note>. The message approach also means you have to store state while you wait until you know which fork you land on.
It's not all bad. In summary, here's what we got with the current approach:
Pros

Message receivers don't have to navigate deeply nested XML structures.
MusicXML interpretation is decoupled from consumption, allowing each side to be developed independently.
Messages are trivially serializable. I envisioned that this would enable things like shared document editing.

Cons

Domain complexity is offloaded to the message receiver. Message receivers don't have to worry about XML, but they still have to do something meaningful with the messages.
Message abstractions can only fully cover the MusicXML spec if they contain as much or more information as the MusicXML spec. However, it's worth noting that we don't need 100% MusicXML coverage for rendering.
Abstracting messages is hard. Flattening the MusicXML spec means we have to continuously decide what level of granularity to abstract to. Right now, decisions are driven by how EasyScore works, but this may not work well for all use cases.

Proposal
The state that we need for rendering is already in the MusicXML document. I propose replacing message production and handling with a view layer that wraps the MusicXML document. The view layer has the following traits:

It is stateless. All non-computed data needed for rendering should be queried from the MusicXML document as needed. Think of the get* methods in the NodeHandler subclasses today (example).
It provides convenient typesafe handles for navigating musical notation structures that are encoded in MusicXML. Callers (renderer, in our case) don't need to know anything about MusicXML, but they do need to understand how vexml organizes music.
It exclusively performs readonly operations. I think the key to #66 is to make the renderer responsible for marrying VexFlow objects with MusicXML. Therefore, the proposed view layer will need to expose a list of "authoritative nodes" or something similar to make the connections possible by consumers.

The ultimate goal is to reduce the amount of state juggling that has to be done in Renderer, hopefully making it easier to maintain and test.
I'll be testing this idea in experiment/view branch. Again, for now, you don't need to change your trajectory. I'll abandon this idea if it doesn't really make the codebase more maintainable.

Sounds great, I hope that it maskes our lib simpler.

@rvilarl, I've been using your rendering work to navigate this new approach. Now that I've made progress on https://github.com/stringsync/vexml/issues/28#issuecomment-1430020367, I'm pretty confident that is a much more maintainable approach.
When you get a chance, would you take a look at the experiment/view branch so far and let me know the concerns you have?

@jaredjj3 the files look simple and good commented. The structure is more flat and this once again makes think simpler. I am not a TS expert and some declarations scare me, I will learn.
The app is not working though, I gues that this is WIP and expected.
No concerns once it works :)

Hey @rvilarl, I'm currently trying to get 01a-Pitches-Pitches.xml to look reasonable on the experiment/view branch. I ran into a formatting issue that I need help with. I see that you've contributed a lot to VexFlow, so I'm leaning on your expertise here.
I found out that we're getting "free" padding as a side effect of unconditionally adding a voice for direction notes. In renderer.ts, if you comment out adding direction notes in L245 and adding vexflow.TextNotes in L339, you will see that the notes will not have any padding.
I know I can fix this by setting the measure width, but I'd like to get this to work using the auto width feature of vexflow.System. I tried adding padding by preformatting tickables using vexflow.Formatter.SimpleFormat, but it doesn't seem to have an effect on the rendering. I suspect that the vexflow.System.format call is overriding the vexflow.Formatter.SimpleFormat changes, but I haven't been able to pinpoint it yet.
How do I add padding to each note?

Hi @jaredjj3, I thought that adding the direction notes with no text would have no effect. Padding should be added to the system. You can use Formatter.preCalculateMinTotalWidth to get the minimal, decide how much you want to add and set the width.

@rvilarl, I tried what you suggested, but it still doesn't look right. Would you show me what you mean, please?
https://jsfiddle.net/81uen7hm/44/

Thanks, @rvilarl! I was able to come up with a reasonably fast way to render responsively. There's still a lot I need to do, but this approach is showing more promise.
https://user-images.githubusercontent.com/19232300/221427955-368d69f2-cf68-4e8b-97c9-066105f40ad8.mov

Wow this is quick!

@rvilarl, just giving you a pulse check, I got busy with some other things. I want to try to finish this refactor this weekend. Don't let this block you on trying other things on the main branch!

@jaredjj3 I am still there! I am tryin to get a new vexflow release through

After wrestling with the vexflow.Factory API for a while now, I've come to the conclusion that it doesn't offer the flexibility we need for vexml. Particularly, it's been difficult calculating how much width a vexflow.System takes, and figuring out the (x, y) coordinates based on that (if there's not enough width on the current line, you need to create a new line). preCalculateMinTotalWidth gets me part of the way, but it's missing how much space a clef and a timesignature may take.
I'm going to switch to using the Native API, and see if that makes things easier. I'm aware that I'll be reimplementing a lot of the vexflow.Factory functionality, but I think I need the flexibility.

@rvilarl, take a look at this fiddle. Why does formatter.preCalculateMinTotalWidth() return 62.69704? Using that width would cause all the notes to stack on top of each other.

Ah, I see, thank you. Is there a standard way to calculate the width of all the stave modifiers?

What are you missing with the factory interface?

The problem I'm trying to solve early on is being able to responsively render measure lines based on the renderer width. This is particularly important since this is a library that targets the web.
The biggest issue is being able to "prototype" a system. For example, I want to be able to instantiate a system, calculate its width with autoFormat: true, then maybe re-render the system somewhere else based on whether or not I have enough width budget on the current line. However, when I format a system, there seems to have a lot of side effects that lock me into a system, preventing me from changing its spatial attributes. I only have an experimental understanding of this, so please correct me if I'm misunderstanding something.
I've tried extending vexflow.Factory within vexml, but this ultimately felt like I was reaching into the internals too much. I think it'd be better if we keep vexml less coupled so that changes to vexflow.Factory don't break vexml.

Ah, I see, thank you. Is there a standard way to calculate the width of all the stave modifiers?

You have to add stave.getNoteStartX() plus padding

What are you missing with the factory interface?

The problem I'm trying to solve early on is being able to responsively render measure lines based on the renderer width. This is particularly important since this is a library that targets the web.
The biggest issue is being able to "prototype" a system. For example, I want to be able to instantiate a system, calculate its width with autoFormat: true, then maybe re-render the system somewhere else based on whether or not I have enough width budget on the current line. However, when I format a system, there seems to have a lot of side effects that lock me into a system, preventing me from changing its spatial attributes. I only have an experimental understanding of this, so please correct me if I'm misunderstanding something.
I've tried extending vexflow.Factory within vexml, but this ultimately felt like I was reaching into the internals too much. I think it'd be better if we keep vexml less coupled so that changes to vexflow.Factory don't break vexml.

Right, I think that would accomplish what I need to do.

OK I will look into that :)

OK I will look into that :)

Thinking about it for a bit, really what I need is a way to pre-calculate the width of a system without committing it to the Factory store. This is a more pointed approach, and I imagine it's less cumbersome than juggling all the state that format() touches.
Maybe the ability to make a virtual/calculation-only Factory could work here? Right now, there's a hard requirement to have a DOM element to use Factory.

Could you provide a piece of code to show hoe you would use System?

I ended up coming up with an example of the caller, but I think this illustrates the point. transform() would contain a method that may need to format() a System more than once.
const MAX_WIDTH = 480;

let remainingWidth = MAX_WIDTH;
for (let ndx = 0; ndx < systems.length; ndx++) {
  const currentSystem = systems[ndx];
  const previousSystem: System | null = systems[ndx - 1] ?? null;

  const requiredWidth = getRequiredWidth(currentSystem);
  const hasEnoughRemainingWidth = remainingWidth >= requiredWidth;
  if (hasEnoughRemainingWidth) {
    // transform wraps the system to add useful transformation methods to vexflow.System
    // it would be the thing that uses `format()`
    transform(currentSystem).moveToEndOf(previousSystem);
  } else {
    if (previousSystem) {
      console.warn(`not enough container space for system: ${currentSystem}`);
      transform(currentSystem).setWidth(MAX_WIDTH);
    } else {
      transform(currentSystem).moveToNextLine();
      transform(previousSystem).stretchSystemToFillLine();
      let remainingWidth = MAX_WIDTH;
    }
    remainingWidth -= requiredWidth;
  }
}

@jaredjj3 could you modify the jsfiddle to show want you want to do and get it to fail
https://jsfiddle.net/ronyeh/xure9svb/

@rvilarl, I was able to figure out resizing! The difference between this version and the video in https://github.com/stringsync/vexml/issues/28#issuecomment-1445421867 is that I'm able to account for beginning modifiers for each line as well as resize the lines to fit the renderer width. These are also the fastest rendering times, which is a good sign.
The difficulty stemmed from formatting side effects on the setters for different vexflow objects, so I created data containers that have side effects I could manage. I made it so that I can create vexflow objects not tied to anything whenever I want.
There was also the other problem when I wanted to format things multiple times, but vexflow objects don't support this well. For example, when stretching the width of each system to make a line fit, I may need to change the width of some vexflow.Staves or even move their position (overflow to next line), then reformat. Ultimately, the data containers could be changed freely, so I lost the need to reformat.
The next steps are

Distribute the formatting logic across the data container classes (instead of everything in the Vexml class).
Reach feature parity with master.
Improve unit test coverage.

When you get a chance, would you please take a look at the experiment/view branch and let me know if you have any concerns so far? I'm hoping that this imperative approach is much easier to maintain than the "event"-based approach we have been doing before. I'm hoping to submit for review in a week or two.
https://github.com/stringsync/vexml/assets/19232300/83f3c910-24c1-4d93-adbe-e9a779d3b48e

Thanks


cannot verify login

Request Id: d046c1eb-916c-43c9-8745-ae2a47db2e01
Correlation Id: 9a854afb-2c2c-4cf8-8eca-ccd3f3116671
Timestamp: 2018-11-27T15:06:03.010Z
Advanced diagnostics: Disable
If you plan on getting support for an issue, turn this on and try to reproduce the error. This will collect additional information that will help troubleshoot the issue.
i have no way of reporting this to MS as i can't login anywhere.
Every login attempt tries to verify me by 2FA and that is not working right now.
Where should i post this?
Azure documentation issue guidance
Thanks for opening an issue in the Azure technical documentation repository.
We use GitHub issues as the primary channel for customer and community feedback about the Azure documentation.
Creating an issue
We prefer that you create documentation feedback issues using the Feedback link on the published article - the feedback control on the doc page creates an issue that contains all the article details so you can focus on the feedback part.
You can also create a feedback issue here in the repo. If you do this, please make sure your issue lists:

[ ] The relevant Azure service or technology.
[ ] A link to the published documentation article that you have feedback about.
[ ] Clear, specific feedback that the author can act on.

Pull requests and article contributions
If you know the change that is needed in an article, we encourage you to submit the changes directly using a pull request. If the change is large, or if you want to contribute an entire article, follow these guidelines:

[ ] Don't surprise us with a big pull request or a pull request with a new article! Submit an issue that describes the details of the proposed large change or new article.
[ ] Include the service or technology area.

We'll route the issue to the appropriate content team for review and discussion.
Tech support and product feedback
If you would like to contact Microsoft about other things, such as product feedback or tech support, please review these guidelines:

If you need technical support using Azure, the paid and free support options are described here: https://azure.microsoft.com/support/options/.

Each article in the Azure technical documentation contains a product feedback button - it's best to submit product feedback directly from a relevant article. Otherwise, you can submit product feedback for most Azure products in the following product feedback forum: https://feedback.azure.com/forums/34192--general-feedback.

@zoomessence please leave the link to the document to which you are referring so that we can respond.

closing issue as i resolved this issue by loggin in as another admin and changing my user to not require multi-factor auth.


Overlay not observed when capturing D3D12 games

Here're the logs when capturing D3D12 games(The_Divison, Sniper_Elite_4) which the overlay aren't been observed. I can't tell whether it's a bug in RenderDoc or unsupported features. Can you help to take a look?
RenderDoc_2019.05.17_18.07.36(The_Divison).log
RenderDoc_2019.05.17_14.37.29(Sniper_Elite_4).log
Environment

RenderDoc build: v1.4 - 29 Apr, 2019
Operating System: Windows 10
API: D3D12

I do not condone or support capturing commercial copyrighted games that you are not the owner and creator of.
RenderDoc is intended only for debugging your own code.


[stable/sematext-agent] Updates to auto discovery configuration file in sematext agent

The PR updates the variable names in the autodiscovery configuration file of sematext agent chart, based on recent changes in App Agent repo
@komljen

What this PR does / why we need it:
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ ] DCO signed
[x] Chart Version bumped
[ ] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/chart])

/assign @megastef

Closing this PR since https://github.com/helm/charts/pull/15310/ has latest changes


Added setting of some Semantic Module properties

Added 3 vital properties when creating a Semantic module: custom nodeids or not, and a couple for variable generation

@sleiban Merge and publish :-)


minor doc update for running on YARN

Include info on SPARK_YARN_JAR can be HDFS

@jongyoul @swkimme Could you please review?

LGTM. Thanks for fix my typo.

Looks great!

@swkimme It is ok to merge this PR? I've heard Zeppelin repos moved to apache/incubator-zeppelin. I think @felixcheung should make this PR with same patch under apache/incubator-zeppelin. How do you think of it?

@jongyoul
Oh, you're right.
I guess we need to create this PR again for apache/incubator-zeppelin repo.
@felixcheung can you do that?

Absolutely! Created https://github.com/apache/incubator-zeppelin/pull/2


GFX: Relegate some logs to LOG_LEVEL_DEBUG

Related to: #2939
Backport to: v0.10
Per-frame logs are too much.

Agreed.

Oops it should be LOG_LEVEL_TRACE.