A11y_VSCode_SidebarBarOptions_AccessingTheExplorersidebaroptionsandCreatinga newfile_ScreenReader: Inappropriate name is announced for the “Open Editors”, “PRE.REQ” and “Outline” toolbar.

Environment Details:
VSCode Version : 1.35.6 (user setup)
OS Version : Win10
Additional Details:
MAS Violated : MAS 1.3.1, MAS 4.1.2
ScreenReader Versions : NVDA2019.1.1, JAWS 2019
Repro Steps:

Pre-req: Create an empty folder on desktop
Open Visual studio code editor.
Using "Ctrl+Shift+E" key navigate to the Explorer side view bar option.
Using "Tab" key navigate to explorer side bar options.
Arrive at the "Open Folder" button and hit "Enter".
Select the folder created under "Pre-req".
Using "Tab" key navigate to and select "New File" option using "Enter" key.
Start screen reader
Using "Tab" key navigate to extension side bar options.

Actual:
When screen reader users navigate through the “Open Editors”, “PRE.REQ” and “Outline” toolbar inappropriate name is announced to the users which is incorrect.
Expected:
The “Open Editors”, “PRE.REQ” and “Outline” toolbar should be announced with the specific name and their state of either expand/collapsed accordingly.
Recommendations:
Refer below link which is repository of bug fixes code snippets:
https://microsoft.sharepoint.com/teams/msenable/mas/pages/browse-fixes.aspx
User Impact:
If the name of the controls is not announced properly to the screen reader user then they will get confused.
MAS Reference:
MAS 4.1.2 - https://microsoft.sharepoint.com/:w:/r/teams/msenable/_layouts/15/WopiFrame.aspx?sourcedoc={248054a6-5e68-4771-9e1e-242fb5025730}
Attachment for Reference:

This works for me and also works for you (check your screen shot it nicely says Open Editors Section tool bar expanded).
We properly set the aria-expanded attribute. Thus closing as invalid


TK228 OBD device

I am trying to use traccar server connecting to OBD device TK228. I am providing the device identification number and its showing offline (even when the device is attached to the car and car is moving).
Please help.

Are you using port 5009? which is the correct one for TK228.
Try to activate logging and see if you receive data on that port.

O!! Thanks for the quick reply. Do you mean to say that I have to change 8082 to 5009!!
Relating logging it didn't log anything just saying the server started.

Port 8082 is ONLY for web interface. For devices you should use port 5xxx. Check official website for more information. Please do some research before asking questions here.

leave the 8082 which is for web interface as @tananaev said.
configure your device to send to your IP server, port 5009.
Regards

Thank you Slachtar and Anton Tananaev. I was able to communicate the server with obd device. Your views were of great help. The last statement given by Slachtar helped me drive to my destination.
Regards.


feat: add exclude patterns support

Description
This PR enhances the leptosfmt command to support excluding files or directories.
Usage
In my case, I need to exclude just one directory out of 5 directories, so instead of including specific directories, I simply use the exclude feature :
leptosfmt src/ -x src/first -x src/secundo/mod.rs

Changes

added --exclude (-x) argument
updated get_file_paths function.

I hope this feature is useful to everyone.

thanks!


up-android: Add uDiscovery uService

UDiscovery initial commit
-Integrated new uprotocol-java SDK
-Refactored unit tests
-Remove synchronization with Central Discovery Service
-factory reset initialization
-intersection logic
-remote RPC calls
-Remove uRegistry Database, hardcoded URI strings, Authenticator class,
Tag class, Key class, Log class, ultifi key name and unwanted permission.
-UDiscovery Unit Test update
-Refactor variable names
-Android entry for entity name and version
-Unit Test coverage in total approx 100%
-Change artifactory name org.eclipse.uprotocol.core.udiscovery.
-UDiscovery code cleanup.
-Changed gradle dependency to reflect new names of repos.
-Contribution doc updated.
-Class rename to ResourceLoader.
-Change invokeMethod() to return UMessage

close #5

Initial UDiscovery commit
Integrated new uprotocol-java SDK
Refactored unit tests
Remove synchronization with Central Discovery Service
-factory reset initialization
-intersection logic
-remote RPC calls
-Remove uRegistry Database, hardcoded URI strings, Authenticator class,
Tag class, Key class, Log class, ultifi key name and unwanted permission.
-UDiscovery Unit Test update
-Refactor variable names
-Android entry for entity name and version
-Unit Test coverage in total approx 100%
-Change artifactory name org.eclipse.uprotocol.core.udiscovery.
-UDiscovery code cleanup.
-Changed gradle dependency to reflect new names of repos.
-Contribution doc updated.
-Class rename to ResourceLoader.
-Change invokeMethod() to return UMessage
#5


handleUri(uri: vscode.Uri) function can't get access to the 'fragment' part of the URI

I am creating a Vs Code web extension with OAuth2 based authentication (similar to Github Authentication in VS Code), upon successful authentication, redirects to a specific URI like the one shown below. This URI, unfortunately, contains the auth credentials in the fragment part (i.e. starts with the "#" character). This "#" character and the credentials are added by the OAuth server.
Redirect URI from OAuth server:
https://vscode.dev/callback?vscode-reqid=1&vscode-scheme=vscode&vscode-authority=myPublisher.foo-web-extension&vscode-path=%2Fdid-authenticate#&access_token=XXXX&expires_in=XXXX&location=XXXX&api_domain=XXXX
I'm accessing this URI inside the extension's source using the below code:
context.subscriptions.push(vscode.window.registerUriHandler({
    handleUri(uri: vscode.Uri): vscode.ProviderResult<void> {
        console.log(uri);
    }
}));
// output: { "$mid": 1, "path": "/did-authenticate", "scheme": "vscode", "authority": "myPublisher.foo-web-extension" }

Note here that the 'fragment' part of the vscode.Uri instance is not present in the output
The URI object doesn't contain the fragment part (i.e. #&access_token=XXXX&expires_in=XXXX&location=XXXX&api_domain=XXXX) which is required to log the user in the extension.
Questions:

I can't log the user in until I can access the OAuth credentials from this URI. Is there any way the handler function can get access to the fragment part of the URI? Any workaround?

I'm using vscode.env.openExternal to initiate the login process, which opens a new tab. Is there another option to open the same process in a popup window using VS Code's Extension API? Github Authentication uses a popup window for the same. I wasn't able to find the particular VS Code's Extension API.

What I've tried?

Removing the '#' part from the URI solves the issue as all the credential information gets included in the uri.query object. So, I've reached out to the OAuth provider for removing the "#" character and providing credentials in queryString only, but haven't got a solution from them as of now.

Steps to Reproduce:
Reproducing error during VS Code web extension development

Create a URI for the VS Code's extension to listen for using the below code.

const redirectURI = (await vscode.env.asExternalUri(vscode.Uri.parse(vscode.env.uriScheme + '://myPublisher.foo-web-extension/did-authenticate'))).toString()

Attach this redirectURI to OAuth2 login URI for your provider and open the resultant loginURI using the vscode.env.openExternal method and perform authentication. The OAuth2 authentication provider I'm using redirects to a link containing credential details appended as fragment part.
i.e. https://vscode.dev/callback?vscode-reqid=1&vscode-scheme=vscode&vscode-authority=myPublisher.foo-web-extension&vscode-path=%2Fdid-authenticate#&access_token=XXXX&expires_in=XXXX&location=XXXX&api_domain=XXXX

const loginUri = await getLoginUri(redirectURI);
await vscode.env.openExternal(loginUri);

Listen for the URI event and register a URI handler method to get and save auth credentials.

context.subscriptions.push(vscode.window.registerUriHandler({
    handleUri(uri: vscode.Uri): vscode.ProviderResult<void> {
        console.log(uri);
    }
}));
// output: { "$mid": 1, "path": "/did-authenticate", "scheme": "vscode", "authority": "myPublisher.foo-web-extension" }

As the credential details are present in the fragment part of the redirect URI, the resultant 'uri' I'm getting is having no credential details. We can get access to the credentials details only if we can get access to the fragment part of this 'uri'.

Version: 1.63.2
Commit: 899d46d82c4c95423fb7e10e68eba52050e30ba3
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36
Embedder: vscode.dev

This URI, unfortunately, contains the auth credentials in the fragment part

That's essentially the problem here, unfortunately.
We actually merge in query params and ignore external fragments. The reason for that is that we might accidentally overwrite the initial fragment you might've put in the original URI. This works out usually pretty OK, since most OAuth implementations simply add additional query params. Your specific OAuth server decided to instead use the fragment portion of the URL.
If they would use the query params, the URL would look like this instead: https://vscode.dev/callback?vscode-reqid=1&vscode-scheme=vscode&vscode-authority=myPublisher.foo-web-extension&vscode-path=%2Fdid-authenticate&access_token=XXXX&expires_in=XXXX&location=XXXX&api_domain=XXXX, and we'd correctly translate it to vscode://myPublisher.foo-web-extension/did-authenticate?access_token=XXXX&expires_in=XXXX&location=XXXX&api_domain=XXXX.
Is there any chance you have control over the OAuth server and can change that implementation to not use the fragment part of the URI?>

Is there any chance you have control over the OAuth server and can change that implementation to not use the fragment part of the URI?

I don't have any control over the OAuth server or it's implementation. I was hoping if we can get an optional API to get fragments from the URI or any workaround for this issue.
Google OAuth also uses fragment part to attach auth details in the redirect URI. So there will be a demand for such a solution soon (if not already). learn more here

2. I'm using vscode.env.openExternal to initiate the login process, which opens a new tab. Is there another option to open the same process in a popup window using VS Code's Extension API? Github Authentication uses a popup window for the same. I wasn't able to find the particular VS Code's Extension API.

I was also hoping to get a solution for this case as the popup window option is better for our use case while asking the user to authenticate instead of switching to a new tab.

I was also hoping to get a solution for this case as the popup window option is better for our use case while asking the user to authenticate instead of switching to a new tab.

Do you mind filling this a new separate issue, so we mark it a feature request?

2. I'm using vscode.env.openExternal to initiate the login process, which opens a new tab. Is there another option to open the same process in a popup window using VS Code's Extension API? Github Authentication uses a popup window for the same. I wasn't able to find the particular VS Code's Extension API.

For sure! Will create a new issue for Question 2

I was hoping if we can get an optional API to get fragments from the URI or any workaround for this issue.

Can we do anything regards to this line?

Yeah. I think the best behavior would be to overwrite the fragment, if the OAuth gives us one and the original URI also had one.

Any timeline on this fix?

Just fixed this in our vscode-dev sources. By tomorrow, insiders.vscode.dev should have the fix.

Thanks, @joaomoreno, and every developer who worked on this feature update. I really needed this fix and your efforts mean a lot to my team and me. We are grateful.

This bug has been fixed in to the latest release of VS Code Insiders for the Web!
@aadarshp31, you can help us out by confirming things are working as expected in the latest Insiders release. If things look good, please leave a comment with the text /verified to let us know.
Happy Coding!

Hi, @joaomoreno I tested things out with my project and everything works as expected. /verified
Thanks again!


Implement data browser screen

https://projects.invisionapp.com/d/main#/console/13746874/308252302/preview

Closing as duplicate of #352


Generic Error

After installing the integration from HACS and attempting to add the integration, I get to the final step when I link it to my home assistant url I select the link and then I get a popup that says "Error". Any help would be greatly appreciated as I am really excited to get this integration working!

Here is the only log I am finding;
This error originated from a custom integration.
Logger: aiohttp.server
Source: custom_components/google_photos/config_flow.py:87
Integration: Google Photos (documentation, issues)
First occurred: 1:00:08 PM (2 occurrences)
Last logged: 1:04:42 PM
Error handling request
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/aiohttp/web_protocol.py", line 433, in _handle_request
resp = await request_handler(request)
File "/usr/local/lib/python3.10/site-packages/aiohttp/web_app.py", line 504, in _handle
resp = await handler(request)
File "/usr/local/lib/python3.10/site-packages/aiohttp/web_middlewares.py", line 117, in impl
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 67, in security_filter_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 227, in forwarded_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 28, in request_context_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 80, in ban_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 234, in auth_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 146, in handle
result = await result
File "/usr/src/homeassistant/homeassistant/components/config/config_entries.py", line 171, in get
return await super().get(request, flow_id)
File "/usr/src/homeassistant/homeassistant/helpers/data_entry_flow.py", line 96, in get
result = await self._flow_mgr.async_configure(flow_id)
File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 271, in async_configure
result = await self._async_handle_step(
File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 367, in _async_handle_step
result: FlowResult = await getattr(flow, method)(user_input)
File "/usr/src/homeassistant/homeassistant/helpers/config_entry_oauth2_flow.py", line 332, in async_step_creation
return await self.async_oauth_create_entry(
File "/config/custom_components/google_photos/config_flow.py", line 99, in async_oauth_create_entry
(await self.hass.async_add_executor_job(_check_photoslibrary_access))
File "/usr/local/lib/python3.10/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/google_photos/config_flow.py", line 87, in _check_photoslibrary_access
lib = build(
File "/usr/local/lib/python3.10/site-packages/oauth2client/_helpers.py", line 133, in positional_wrapper
return wrapped(*args, **kwargs)
TypeError: build() got an unexpected keyword argument 'static_discovery'

Home assistant information:
Home Assistant 2023.3.6
Supervisor 2023.03.2
Operating System 9.5
Frontend 20230110.0 - latest
I'm using the following Google integrations:
Google Nest
Google Mail (gmail)
Google Keep HACS
I'm not sure how to see the version unless there is a pending update, but all my integrations including HACS are all up to date and working

I don't really know what I did but I finally got the integration to work.
I was also having problems with Google Fit HACS integration so I removed the config from my configuration.yaml for google fit. remove both integrations from HACS, rebooted, then installed Google Photos integration and it worked!! I'm so excited to start playing around with this!

The Google Fit integration is very likely the problem. I couldn't find one in the HACS store directly, but assuming it's vmanuel/hacs-google-fit, it's using a pre 2.x version of the google api package.
It's actually surprising that the other Google integrations kept working, the Gmail integration for example also uses a 2.x version of the Google Api package, but apparently only uses functionality that was also available before 2.x was released.


模块引入报错

WARNING in ./~/ng-zorro-antd/src/components/root/nz-root.component.ts
43:22-30 "export 'DOCUMENT' was not found in '@angular/common'
WARNING in ./~/ng-zorro-antd/src/components/core/floater/floater.service.ts
56:22-30 "export 'DOCUMENT' was not found in '@angular/common'
WARNING in ./~/ng-zorro-antd/src/components/core/floater/floater.service.ts
66:20-28 "export 'DOCUMENT' was not found in '@angular/common'

please provide more info

I have this problem, too，i'll Introduce “NgZorroAntdModule.forRoot()” into the rootModule  and introduce  in rootComponent.html

Make sure you're using Angular version higher than 4.3.0.

aha, forRoot(). deprecated


Update README.md

Verbiage changed on about:support from folder to directory

Interesting, I'm on v123 and it shows 'folder'. Anyway I believe users will be able to understand it :p


Off-by-one error

When you equip a fresh Ring of Forging, the counter correctly shows 140 charges remaining. Use one charge, ring contains 139 charges left, this plugin's counter shows 140. Use another, 138 true, 139 on the counter. Ring melts after smelting 1 bar while this plugin's counter shows 2 charges. Somewhat frustrating for ironman users who are trying to be careful with their inventory management.

Seems to be synced correctly when you first log in, but the moment the user smelts their first bar of the session, the counters desync from one another. Random thought, but perhaps the plugin is reading that counter too fast after seeing the chat log message, and the plugin is reading RuneLite's internal RoF charge counter before RuneLite has actually updated it? I don't know how to tweak/test installed RuneLite plugins, but maybe inserting a short delay in between the Chat Alert and reading RuneLite's counter could resolve the issue?


Duplicate emit when using amd-dependency and es6 ambient import

Hi,
I think that the ///<amd-dependency /> functionality exhibits odd behavior when combined with an ES6 import.
For example, this TypeScript code:
/// <amd-dependency name="jquery" path="/jquery/jquery.min.js" />
import 'jquery';

$('#myDiv').html('Hello');

emits as this JS when using AMD module mode:
define(["require", "exports", "/jquery/jquery.min.js", 'jquery'], function (require, exports, jquery) {
    $('#myDiv').html('Hello');
});

In the emitted JS, the string 'jquery' is included in the requirements for the module (causing an HTTP 404 error at runtime).  My expectation would be that 'jquery' here would be considered the same as the 'jquery' inside the amd-dependency comment, so it would be de-duplicated and that only "/jquery/jquery.min.js" would be passed along to the emitted JS.
I can simply remove the ES6-style import and the emit works as expected.
Am I crazy on this?
I know this will probably be m00t once #2338 hits.
Possibly related: #4004.

this looks right to me. you have two imports one to jquery and one to /jquert/jquery.min.js. i would say remove the amd-dependency and just make the import:
import "/jquery/jquery.min.js";

Interesting.
I wasn't aware of that minimalist import syntax, and it does work in this case.  However, I think maybe jQuery was a bad example because it's actually implemented as a UMD module and $ and jQuery are in-scope in all files merely by including the jquery.d.ts file in the TypeScript compilation context.
Even if you don't think it's a bug that they are both emitted, do you believe that "jquery" in both the amd-dependency comment and the import statement in my example refer tot he same ambient external module declaration (as described in 12.2 of the spec)?
Is there a way to alias external modules in AMD compilation mode using the ES6 syntax only? For example what if I wanted an emit like this ($ is aliased as jq, but somehow tied to the "jquery" ambient external module declaration  so the types work)?
define(["require", "exports", "/jquery/jquery.min.js"], function (require, exports, jq) {
    jq('#myDiv').html('Hello');
});

If not, will this be supported in the future with #2338?  I know people were talking about syntax like import * as foo: IFoo from "foo"; in #2709, but I think this would almost call for something like import {$} as jq: typeof "jquery" from "/jquery/jquery.min.js";, no?
Thanks so much, Mohamed.

Thanks for the reply, Mohamed.  I wrote a response before, but I deleted it because I think this one is better.
I wasn't aware of the minimalist import syntax that you suggested, and it does work in this case.  However, I think maybe jQuery was a bad example because it's actually implemented as a UMD module so $ and jQuery are in-scope in all files merely by including the jquery.d.ts file in the TypeScript compilation context.
Perhaps I'm just hitting up against #2338 again.  This new example may better-illustrate what I was expecting.  Let's say I want to rename $ to jq inside my module, but still fetch jQuery from /jquery/jquery.min.js.  I wrote the following TypeScript code:
///<amd-dependency name="jq" path="/jquery/jquery.min.js" />

import * as jq from 'jquery';

jq('#myDiv').html('Hello');

I was expecting this emit:
define(["require", "exports", "/jquery/jquery.min.js"], function (require, exports, jq) {
    jq('#myDiv').html('Hello');
});

But I got this emit:
define(["require", "exports", "/jquery/jquery.min.js", 'jquery'], function (require, exports, jq, jq) {
    jq('#myDiv').html('Hello');
});

Notice - two jq parameters, and both "/jquery/jquery.min.js" and 'jquery' are included.  I can't see a benefit to doing this emit versus the one I was expecting.
Am I just stuck until the mapping functionality is added to tsconfig.json as part of AMD support in #2338?
Thank you so much, as always!!!

What you describe was never the intended behavior of the 'amd-dependencey' tags, these were mainly Kent for importing non-code resources, and should not be used with imports.

OK.  Thanks for your responses.  It's been very helpful.
As far as aliasing dependencies as a .js script name (instead of as an external module ambient declaration name) when using ES6-style imports and AMD compilation mode - is that impossible still without a post-processor until #2338 is complete for AMD?
Thanks.

For posterity's sake, I've figured out a good technique to permit the TypeScript type system to be happy and to have an arbitrary path be emitted in the define() call when using ES6 import syntax that works today.  This technique assumes that the types for the module are available globally.  It involves using a supplementary ambient external module definition.  This technique eliminates the need to define paths in a call to require.config when using RequireJS in simple projects.
If I want to require jQuery as a variable jq using the ES6 module syntax and have this resolve to /scripts/jquery/jquery.js at runtime for loading by RequireJS, I can do the following.

Create a new definitions file called amdMappings.d.ts, or something similar.
This file will duplicate the ambient external module declaration for jquery - however it will do so with a different ambient module name:

declare module "/scripts/jquery/jquery" {
    var $: JQueryStatic;
    export = $;
}

Now, jQuery can be imported into another module as so:

import * as jq from '/scripts/jquery/jquery';
jq('#myDiv').html('hello');

The AMD emit from this code is:
define(["require", "exports", '/scripts/jquery/jquery'], function (require, exports, jq) {
    jq('#myDiv').html('hello');
});
``


Move ZoneId to config-provisioning

Moves ZoneId, UpgradePolicy, ZoneFilter, and ZoneList to a non-public exported config-provisioning package.

FYI @jonmv


Add support for icesat2 validation plotting

Start simple: Pull in ICESat and plot:

mapview
dh
histogram
profiles? select profiles based on tri-error variance or based on high vs. low dh areas (maybe use percentiles so as to avoid extremes?)


Update SiteConfig.js

Description of the change:
Fixed code style. Break long strings into multi line.

 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.

Please check out our open issues for changes that we’re looking for in this repo! We’re adding new ones from easy to difficult every day.


Capitalization on Query Params

Hey Nick,
I was messing around with some of the API methods, and I noticed some behavior where the parameters had to be lower case for them to override the defaults.
Here's an example in express, using the correct key, 'Season':
router.get('/', function(req, res) {
  nba.ready(function() {
    nba.api.playersInfo({ Season: "2010-11"}, function(err, data) {
      res.send(data);
    });
  });
});

This would result in the request:
{ LeagueID: '00', Season: '2014-15', IsOnlyCurrentSeason: '1', season: '2010-11' }

However, if I changed the key to 'season', the request would work properly, and I would get the players for the 2010-11 season:
{ LeagueID: '00', Season: '2010-11', IsOnlyCurrentSeason: '1' }

I know this has something to do with the twoWayMap function and it should work regardless of capitalization. I'm not sure yet how all of the utility functions work and how they transform the parameters, but when I get some time to dig in I'll hopefully be able to figure it out and make a PR.

Yeah you're on the right track. I'm not sure exactly what the issue is, but the main problem is that all the utility functions and stuff are completely untested. If I get some time this week I'm going to try to write tests to specify how they should work and see where it goes wonky.

Gotcha, now that I looked a little more, it seems that it just translates upper camel case to lower (and vice-versa). I just assumed upper would work because of the defaults you were using in endpoints.js.
I'll take a stab at writing some tests for utils.js and other parts of the library, partially because I need to get better at writing tests, and partially because I did get some other types of weird errors on the endpoints I added.

Sounds good! Let me know if you run into any roadblocks

For anyone who sees this in the future:
For all options passed to methods in this module, I've tried to ensure they are in camel case as is usual for JavaScript projects. This helps avoid having to constantly refer to the inconsistent capitalization scheme that the NBA uses. The translation table is in https://github.com/nickb1080/nba/blob/master/src/dicts.js


Merge Develop branch with Prefect updates

Leaving this PR as record of branch update, but we will be deprecating the "master" branch to use "main" so will technically just clone the develop branch into "main" to do so.


Removed pointless docs/source dir.

Why was it there in the first place?  Is this some kind of sphinx best practice?  Or is it actually completely unnecessary and un-sphinx-idiomatic?

I'm not sure why it ended up in there --- @shajoezhu, I think you set this up initially?.

Hi Danny and Jerome,
I believe this was because how I usually set up my files, where I have my source code in one folder, and images under another folder, and both are under the folder docs.
Best
Joe

+1


Added logging to proxy example.

Per the TODO comment in the main.rs file of the proxy example this PR adds simple logging.

Errors are upstream from my changes, so this PR is not the source of the failing Travis build.


Remove Import a MP, Submit and Evaluate from Global View

Remove the following options from the Global/Non-logged-in View in ECMPS:

Import a Monitoring Plan
Evaluate
Submit
Revert to Official Record
Status Fields for Evaluation and Submission

Test Passed


Adds cancer stats stratification data, filtering options

This PR introduces two separate, but related improvements:

updates the CancerStats model to include "RE" (race/ethnicity) and "Sex" fields that are now included in CancerInFocus dataset; the newest database dump, as of Feb 22nd 2024, includes these new columns
adds support for "factors", additional categorical-valued columns in the dataset on which we can subset the data

Addresses #30, but we probably want to include the frontend part before we consider it closed. Feel free to use this PR for the frontend changes, or open a new one that references this one if you prefer.
Terminology: "Factors"
First: I'm of course open to debating the terminology, so if the terms don't make sense to you, please tell me!
The name "factors" comes from R's "factor" datatype; in R, factors are used as an efficient way to represent values that take on a discrete set of categorical values. For example, a "Color" column that only takes on the values "Red", "Green", and "Blue" would be a candidate for a factor, and in R's case, each of these possible values would be called a "level". I've chosen to call them "values" of the factor rather than "levels" just to keep things simpler for us.
The Data
Tables in CancerInFocus are organized first by geometry (county or tract), then by category, then by measure; each measure has an associated FIPS ID (i.e., identifying a county or tract) and a value for that FIPS. With the introduction of these additional "RE" and "Sex" columns (aka factors), each cancer-related table now has a row for the combination of the possible values for all the factors for each FIPS. For example, in the cancer mortality data, Denver County previously had a single row for "All Sites". Now, there is a row for (RE=All, Sex=All), a row for (RE="White NH", Sex=All), a row for RE="White NH", Sex=Male, etc.
A consequence of this design is that one must always filter the dataset by its factors to get a correct response. For example, to get back the old non-stratified dataset you must query the tables with RE=All and Sex=All. The API generally handles that for you; if you don't specify specific values for factors, they're assumed to be the factors' default.
Currently, the "RE" field takes on the values "All" (the default), "White NH", "Black NH", and "Hispanic". The "Sex" field currently takes on the values "All" (the default), "Female", and "Male". Despite these being the current values, this PR's implementation only hardcodes the default value and human-readable labels for the currently-observed values (e.g., "White NH" is labeled "White, Non-Hispanic" in the metadata). The idea behind all this is that the existing factors will continue to work even if new versions of the data introduce new factors or new values for existing factors. We can catch up to extending the factors and adding human-readable labels as we notice issues without things breaking completely.
Accessing Factor Metadata
This PR changes the /stats/measures/ endpoint to also return information about factors for each table, if available. Under each category, in addition to the measures field, there is now a factors field which is {} for most tables, but contains factor information for tables that have factors (e.g., the cancer incidence and mortality county-level tables).  The new response for, e.g., cancer mortality, looks like this (with measures left out for brevity):
{
    "county": {
        "label": "County",
        "categories": {
            "cancermortality": {
                "label": "Cancer Mortality (age-adj per 100k)",
                "measures": { },
                "factors": {
                    "RE": {
                        "label": "Race/Ethnicity",
                        "default": "All",
                        "values": {
                            "All": "All",
                            "Black NH": "Black (non-Hispanic)",
                            "Hispanic": "Hispanic",
                            "White NH": "White (Non-Hispanic)"
                        }
                    },
                    "Sex": {
                        "label": "Sex",
                        "default": "All",
                        "values": {
                            "All": "All",
                            "Female": "Female",
                            "Male": "Male"
                        }
                    }
                }
            }
        }
    },
    "tract": { }
}

The keys in factors are the identifiers you should use when interacting with the API. Under each entry in factors, you'll find:

label: the human-readable version of the factor, for display in the web UI
default: a value representing "no selection" in the data; should be the default selection in the web UI. (It's also used in the API when querying a table that has factors but when no specific value for a factor is given.)
values: a dictionary of value-label pairs for the column.

The values are computed from the table, and like the factor keys should be used when interacting with the API.
The labels come from the backend.app.models.cif.FACTOR_DESCRIPTIONS dictionary; if no match is found there, the value is used as-is as the label. These labels are intended to be used as the labels for the factors' dropdown in the web UI.

Using Factors to Subset
The /stats/<type>/<model>/fips-value endpoint now takes an optional querystring argument, filters, which can be used for subsetting a table based on its factors. The argument takes a semicolon-delimited list of comma-delimited <factor>:<value> pairs. For example, the string "RE:White NH;Sex:Female" would filter the dataset to only return rows where the "RE" column is "White NH" and the "Sex" column is "Female". If a factor is left out, it takes on its default value as specified by the "default" field in the metadata for that factor.
Other notes:

White space is trimmed at each level of parsing, so the string "  RE : White NH  ; Sex :   Female   " is equivalent to "RE:White NH;Sex:Female". (White space is retained within a key or value).
As of now there are no values that include one of our separators (":", or ";"), but if that should occur we might move toward encoding the filter string as, say, JSON.

Just getting to this now. Read through your description. The terminology and approach all make sense to me.

As of now there are no values that include one of our separators (":", or ";"), but if that should occur we might move toward encoding the filter string as, say, JSON.

If this becomes the case we might want to just enforce some url/filepath-safe identifier, because we'd maybe want a non-obfustracted human-readable way to put selected factors in the UI urls for users to share.
I'll probably start doing the frontend changes in this PR and that will be my review of testing to make sure everything works. That'll probably be better than me looking over your code, though I'll still glance through it.

If this becomes the case we might want to just enforce some url/filepath-safe identifier, because we'd maybe want a non-obfustracted human-readable way to put selected factors in the UI urls for users to share.

That's a good point about readability; I doubt being unable to use semicolons and colons in the factor IDs or values is really going to impact readability, but switching to a different format would, so just let's stick with our current format. It's not hard to strip out the colons and semicolons during both data ingest and querying.

I'll probably start doing the frontend changes in this PR and that will be my review of testing to make sure everything works. That'll probably be better than me looking over your code, though I'll still glance through it.

Sounds good. I'd give running the stack locally a try while you develop the frontend, assuming you're not already doing that.  If you'd like me to deploy it to prod I can do that, too; there shouldn't be any changes that would break the older frontend.


Recommended workaround for GroupOperation willFinishOperation...

I had been relying on GroupOperation's willFinishOperation being called even when there were errors in child operations. I liked how I could monitor every child operation and dynamically call addOperation as I progressed through my state machine - at least this was my particular use-case for the class.
I'm not sure when or if the behavior changed but I believe it may have in one of the more recent revisions.
What is the best reason for not having willFinishOperation called even if errors is not empty in the code below and is the proper work-around to just override willAttemptRecoveryFromErrors?
public func operationQueue(queue: OperationQueue, willFinishOperation operation: NSOperation, withErrors errors: [ErrorType]) {
        guard queue === self.queue else { return }
        if !errors.isEmpty {
            if willAttemptRecoveryFromErrors(errors, inOperation: operation) {
                child(operation, didAttemptRecoveryFromErrors: errors)
            }
            else {
                child(operation, didEncounterFatalErrors: errors)
            }
        }
        else if operation !== finishingOperation {
            willFinishOperation(operation)
        }
    }

Hi @StephenDaedalus - I think this change happened ~ v3.1 or v3.2 and the goal is mostly to allow GroupOperation to be able to recover from errors. Previously, if there was a child which failed, the error would be collected, and even if the subclass, re-added a new operation which "fixed" the error, there was no way to essentially remove the error from the previous failure.
To remedy this, GroupOperation (and GroupProcedure) has some APIs which can be overridden to indicate to the group that the failing child will be re-tried. This can be done in willAttemptRecoveryFromErrors(_, inOperation: Operation) -> Bool.
If you don't want to handle any errors, no need to override it. If you do want to handle errors, then framework consumers must explicitly indicate how they are going to handle errors.
I think this actually makes subclasses much more readable and testable - as the happy path is all just in willFinishOperation() and the unhappy path is clear.
In terms of how to implement an override to handle errors.

Check what the failing operation is
Check what the error is.
If it is recoverable by doing something differently, use addOperation to add additional operations to the group - and then return true.
If the error is not recoverable - return false.

This is basically how RetryOperation works, and see CloudKitOperation for hints about how to write a RetryOperation subclass.

Dan, apologies for the delayed response. After looking more closely at the code I can see that this is definitely the better approach. I suggest that adding a few of the sentences from your notes above to the documentation will help clarify things just a bit more.


Test against Python 3.12 once dbt-core supports it

Waiting for https://github.com/dbt-labs/dbt-core/issues/9007.
Can then git revert 7a8c9ff1a64a7e91304d46bec4a88e7d157887de

@binste Support for Python 3.12 was just recently released in dbt-core 1.7.9.

Thank you very much for letting me know! :)


refactor: remove task_registry.py

psycop/common/sequence_models/tasks/task_registry.py
@Registry.tasks.register("behrt")
def create_behrt(
    embedding_module: BEHRTEmbedder,
    encoder_module: nn.Module,
    optimizer: OptimizerFn,
    lr_scheduler: LRSchedulerFn,
) -> BEHRTForMaskedLM:
    return BEHRTForMaskedLM(
        embedding_module=embedding_module,
        encoder_module=encoder_module,
        optimizer_fn=optimizer,
        lr_scheduler_fn=lr_scheduler,
    )

@Registry.tasks.register("clf_encoder")
def clf_encoder(
    embedding_module: BEHRTEmbedder,
    encoder_module: nn.Module,
    aggregation_module: Aggregator,
    optimizer: OptimizerFn,
    lr_scheduler: LRSchedulerFn,
    num_classes: int = 2,
) -> EncoderForClassification:
    return EncoderForClassification(
        embedding_module=embedding_module,
        encoder_module=encoder_module,
        aggregation_module=aggregation_module,
        optimizer_fn=optimizer,
        lr_scheduler_fn=lr_scheduler,
        num_classes=num_classes,
    )

Couldn't we decorate BEHRTForMaskedLM and BEHRTEmbedder instead? This would eliminate duplication of the interfaces. What do you think @KennethEnevoldsen?

We could, but e.g. a "clf_from_pretrained" would still use this interface. This way we keep a clear distinction between registry and object.

Ah yeah, it's the classical decoupling by adding an intermediate vs. duplication of interfaces.

but e.g. a "clf_from_pretrained" would still use this type of interface to the registry

Not sure I understand this. Let's have a chat about it when you're back 👍


Use generic for Object.seal(), freeze() and preventExtensions()

To me, seal(), freeze() and preventExtensions() should be declared like:
    seal<T>(o: T): T;
Adding it to ObjectConstructor does not help, the 'any' version is taken first.
The only solution I've found is to patch lib.d.ts...
Is there a better way?
Or could you update lib.d.ts?

I think the main reason is we had these in lib.d.ts before generics were introduced. I think it would be safe to change it, if it breaks exiting code, it most probably did not work in the first place.
A PR would be appreciated. the change should be in src\lib\code.d.ts


add(vscode config): use local typescript library, and make file list …

…view clean

@zixia I don't think that specific editor config files should be in the repo, can it be achieved with common configuration, for example with tsconfig.json?

@JIoJIaJIu This file contains setting for vscode, its functionality can not be achieved by tsconfig.json or other config files.
For example:

files.exclude entry is to control which file/directory should be hidden in the Sidebar Explorer in vscode IDE.
typescript.tsdk will be used by vscode by static type checking service, and IntelliSense.
etc.

So my suggestion is to include it, to make the vscode IDE behavior consistent across the developer/computer.

Sorry, but I dont think that specific editor configuration should exist in the repo, better to store it locally

No problem.
However, as we are using TypeScript, I'll strongly suggest you switch your IDE to vscode because it has the best support for TypeScript/JavaScript. :P

@zixia I installed it today - really awesome tool, will look it slowly


⚠ Empornium has degraded performance

In f5ac145, Empornium ($EMP) experienced degraded performance:

HTTP code: 200
Response time: 1148 ms

Resolved: Empornium performance has improved in 2421c18 after 14 minutes.


HTTP/1.1 sent to h2 connection with native-tls-alpn

Code:
let _r = reqwest::get("https://www.google.com/").await.unwrap();

Cargo.toml:
reqwest = { version = "0.12.1", default-features = false, features = ["native-tls-alpn", "http2"] }

Result:
called `Result::unwrap()` on an `Err` value: reqwest::Error { kind: Request, url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("www.google.com")), port: None, path: "/", query: None, fragment: None }, source: Error { kind: SendRequest, source: Some(hyper::Error(Parse(Version))) } }

ALPN has negotiated to use h2 and then an HTTP/1.1 request is sent. The server terminates the connection by a GO_AWAY frame.
With http2_prior_knowledge it works fine.

Oops, it's fixed by #2165.


Documentation link

Hello, could you provide the link to the documentation? Looks like the one in ReadMe is outdated.

Thank you knmcguire :)


[1.x] Allow configurable trim length

If the pulse:work command fails the Ingest will continue to build up in size.
With Redis this is problematic as it is keeping itself in memory. When the pulse:work command fails we already trim the ingest on a lottery whenever we put data into the ingest, but it will always retain 7 days worth of data.
That could be problematic for some application depending on their traffic size.
This PR allows the maximum retention for the ingest to be configured.
This value is respected whenever the ingest is trimmed, so it is not guaranteed that the ingest will only contain the configured value until trimming occurs, which again, may happen on a lottery basis.
You may specifiy either a time period or a number of entries to retain.
    // ...

    'ingest' => [
        'trim' => [
            // Keep an interval...
            'keep' => '7 days',
            'keep' => '3 days',
            'keep' => '1 day',
            'keep' => '1 hour',

            // Keep a count of entries...
            'keep' => 500_000,
            'lottery' => [1, 1_000],
        ],
    ],

    // ...

Leaving as a draft, as the upgrade guide will conflict with another PR I have open.

@timacdonald some conflicts here


Conflicting info in Create new VHD section for Dev Drive

Type of issue
Other (describe below)
Feedback
There are 2 pieces of conflicting information in the "Create new VHD" section for Dev Drives.

The VHDX option says "supports virtual disks up to 64 TB". However, the screenshot below says "supports virtual disk up to 2040 GB" for the same option.
Under "Disk Type", the text says "Recommended" for the "Dynamically expanding" option, while the screenshot shows the "Fixed size" option to be the recommended one.

Page URL
https://learn.microsoft.com/en-us/windows/dev-drive/
Content source URL
https://github.com/MicrosoftDocs/windows-dev-docs/blob/docs/hub/dev-drive/index.md
Author
@mattwojo
Document Id
bfda7965-bc34-ab88-fdc9-efef4a5d8a9e

Thanks @vinod-unny-eit. #2 was resolved here: https://github.com/MicrosoftDocs/windows-dev-docs/commit/d1e11a591ffa5e44d5a7242b5ecd9a246ff1569f
I'm working on getting some clarification regarding #1 and will add an update as soon as I have a clear answers.

The Dev Drive creation user interface has been updated to fix these issues and is rolling out over the various build updates. The fixed user interface will look like the screenshot below. The VHDX format supports a max of 64 TB and the VHD format supports up to 2040 GB. The recommended disk format is Dynamically expanding.

Fix is on it's way in to the docs.


[core] Implove SchemaChange class

fix https://github.com/apache/incubator-paimon/issues/985
Purpose
Add updateColumnComment and updateColumnNullability overloaded methods to the SchemaChange class
Tests
CatalogTestBase
API and Format
no
Documentation
no

We should support ROW type for hive catalog first.

See tast failure.


Exporting cables dosn´t include termination points

Environment
NetBox version:  2.5.5
Steps to Reproduce
1: Click export within devices/cables
Expected Behavior
All fields presented within the list to be exported in csv format.
So its in a usable format similar to exporting other things within netbox such as devices.
id,Lable,Termination A (device and port), Termination B (device and port),, Status, Type, Color, Lenght
Observed Behavior
dcim.interface,XXXX,dcim.interface,XXXX,,STATUS,,,,

More generally: the CSV export format currently does not match the CSV import format for cables.  For example, the export says dcim.interface whereas the import requires interface.
People use the export as a guide to the format for importing, and are surprised when it doesn't work (and have to grok the source to find out the actual format for import).

Here is a concrete example.  A cable which I imported using the following CSV:
side_a_device,side_a_type,side_a_name,side_b_device,side_b_type,side_b_name,type
mk938-rtr1,interface,1/1/10a,mk938-r5-odf1,frontport,E1,Singlemode Fiber

Exports as:
termination_a_type,termination_a_id,termination_b_type,termination_b_id,type,status,label,color,length,length_unit
dcim.interface,875,dcim.frontport,11617,Singlemode Fiber,Connected,,,,

Those are the termination IDs not the device IDs; they map to /dcim/interfaces/857/ and /dcim/front-ports/11617/  respectively.  So the XXXX does define the termination point, just not in a useful form.  At least the Type is the same :-)
In other CSV import/export areas in Netbox, the interface ID doesn't normally appear.  You can't directly import or export interfaces, and there is no top-level /dcim/interfaces/ view.  But in other areas, the CSV export gives the device name and interface name.
For example, if I attach an IP address to the interface, and then export IP addresses, I get:
address,vrf,tenant,status,role,device,virtual_machine,interface_name,is_primary,description
<IP_ADDRESS>/24,,,Active,,mk938-rtr1,,1/1/10a,,

Instead of interface ID there's the device or VM name plus interface name - no need for termination type here, since IP addresses can only be attached to "interface".

See #2563


Port for communication with Mesos

I can not seem to find a way to specify the port Marathon will bind to for Mesos to communicate with it.
7 master.cpp:6517] Sending 1 offers to framework bee1c0bb-5c53-4d25-8d12-40da87a5481f-0003 (marathon) at scheduler-9388e17e-bfdc-463f-aa41-d8e9be729b79@<IP_ADDRESS>:46515

This log from Mesos shows that it is trying to contact Marathon framework on port 46515, which is generated at each restart.
Is that a behaviour we can control ? Using Chronos v3, I am able to configure HTTP port for Web UI and this Mesos communication port. I would expect to be able to also do it with Marathon.

You can define the port by specifying the environment variable: LIBPROCESS_PORT.


What to do when you rename or change a doctype?

This one was sparked off by re-reading Janaes post about switching DocTypes. When a developer changes a doctype the API would be broken for anyone external using it. Lets say we rename a Hotel doctype to Accommodation to make it more generic (a villa is not a hotel for instance). Now no one can have a query that references Hotel, they will all break (well return null anyway).
To be fair having it break might be ok but ideally we want some backwards compat. I pondered keeping a list of renames around or possibly a list of Aliases that we could set (in an xml file for example) and when we build our schema up on start up we can create a bunch of Types that just inherit from the new Type. So a Hotel(id:123) would work just like Accommodation(id:123) under the hood. Ideally we would return an Error in our response too so that users know that they shouldn't be using it. This would work but fields that have changed on the doctype would blow up too and theres no way around that that I can think of?
Ideally don't change doctypes if they are out in the wild!
Again this is here more so we know we've thought about it than somethign we should "fix" but something to think over.
Chat I had with Joe about this is here: https://gitter.im/graphql-dotnet/graphql-dotnet?at=5b881948f5402f32aab353f5

Hi
Just wanted to let you know that the project is moving to the Umbraco Community GitHub organisation, so we are closing all existing issues.
If you think your issue is still relevant, please feel free to reopen it.
/Rasmus

Hi
Just wanted to let you know that the project is moving to the Umbraco Community GitHub organisation, so we are closing all existing issues.
If you think your issue is still relevant, please feel free to reopen it.
/Rasmus


seg fault training tf.nn.conv3d with minibatch size >2

Please go to Stack Overflow for help and support:
https://stackoverflow.com/questions/tagged/tensorflow
If you open a GitHub issue, here is our policy:

It must be a bug or a feature request.
The form below must be filled out.
It shouldn't be a TensorBoard issue. Those go here.

Here's why we have that policy: TensorFlow developers respond to issues. We want to focus on work that benefits the whole community, e.g., fixing bugs and adding features. Support only helps individuals. GitHub also notifies thousands of people when issues are filed. We want them to see you communicating an interesting problem, rather than being redirected to Stack Overflow.

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Custom code! You can find it here: https://github.com/NERSC/CosmoFlow/tree/master/SegFault
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): SUSE Linux 12.2
TensorFlow installed from (source or binary): Source
TensorFlow version (use command below): ('v1.3.0-rc1-3112-g65b6a75', '1.4.0-rc0') Note this is NOT compiled with the Intel MKL options.
Python version: 2.7.13
Bazel version (if compiling from source): 0.6.0
GCC/Compiler version (if compiling from source): 4.8.5
CUDA/cuDNN version: N/A
GPU model and memory: N/A, Running on x86_64 Intel Haswell node
Exact command to reproduce: See README in https://github.com/NERSC/CosmoFlow/tree/master/SegFault

Describe the problem
A seg fault when training a tf.nn.conv3d with minibatch size more than 2 on a single Intel Haswell. The seg fault occurs at line 187.
Source code / logs
GDB log: https://github.com/NERSC/CosmoFlow/blob/master/SegFault/gdbTrace.log
It looks like some kind of cyclic dependency in Eigen::TensorEvaluator.

It could be more helpful if you could create a mini reproducable example. Thanks.

I agree - but I haven't had time to make a mini example (this is someone else's code). I will try to find time to do so, but in the meantime the github repo I linked to will reproduce the error shown in the gdb log.

@djbard Thanks for filing the issue!  As @facaiy mentioned, a minimum repro would be appreciated.  But I agree that this looks like a cycle in Eigen that ends up exhausting the stack.
@benoitsteiner @rmlarsen Can you take a look, or suggest someone who can?
Here's a simplified form of the bottom of the stack trace from the gdbTrace.log link above.  I dunno if this is simply a bug that causes an infinite loop, or if there's some static unrolling that's managing to blow our stack, but having the same repeated pattern of calls for >7000 frames definitely looks suspicious:
... pattern repeats until frame #0 which segfaults ...
#7671 Eigen::TensorEvaluator::Context::kernel(long, long, long) ()

#7672 Eigen::TensorEvaluator::Context::signal_kernel(long, long, long, bool) ()
#7673 Eigen::TensorEvaluator::Context::pack_rhs(long, long) ()
#7674 Eigen::TensorEvaluator::Context::enqueue_packing_helper(long, long, long, bool) ()
#7675 Eigen::TensorEvaluator::Context::pack_lhs(long, long) ()
#7676 Eigen::TensorEvaluator::Context::enqueue_packing_helper(long, long, long, bool) ()
#7677 Eigen::TensorEvaluator::Context::kernel(long, long, long) ()

#7678 Eigen::TensorEvaluator::Context::signal_kernel(long, long, long, bool) ()
#7679 Eigen::TensorEvaluator::Context::pack_rhs(long, long) ()
#7680 Eigen::TensorEvaluator::Context::enqueue_packing_helper(long, long, long, bool) ()
#7681 Eigen::TensorEvaluator::Context::pack_lhs(long, long) ()
#7682 Eigen::TensorEvaluator::Context::enqueue_packing_helper(long, long, long, bool) ()
#7683 Eigen::TensorEvaluator::Context::kernel(long, long, long) ()

For readability, I simplified Eigen::TensorEvaluator::Context above from the full form, in all its templatized glory:
Eigen::TensorEvaluator<Eigen::TensorContractionOp<Eigen::array<Eigen::IndexPair<long>, 1ul> const, Eigen::TensorReshapingOp<Eigen::DSizes<long, 2> const, Eigen::TensorVolumePatchOp<-1l, -1l, -1l, Eigen::TensorMap<Eigen::Tensor<float const, 5, 1, long>, 16, Eigen::MakePointer> const> const> const, Eigen::TensorReshapingOp<Eigen::DSizes<long, 2> const, Eigen::TensorMap<Eigen::Tensor<float const, 5, 1, long>, 16, Eigen::MakePointer> const> const> const, Eigen::ThreadPoolDevice>::Context<Eigen::internal::gemm_pack_lhs<float, long, Eigen::internal::TensorContractionSubMapper<float, long, 1, Eigen::TensorEvaluator<Eigen::TensorReshapingOp<Eigen::DSizes<long, 2> const, Eigen::TensorMap<Eigen::Tensor<float const, 5, 1, long>, 16, Eigen::MakePointer> const> const, Eigen::ThreadPoolDevice>, Eigen::array<long, 1ul>, Eigen::array<long, 1ul>, 4, true, false, 0, Eigen::MakePointer>, 8, 4, 0, false, false>, Eigen::internal::gemm_pack_rhs<float, long, Eigen::internal::TensorContractionSubMapper<float, long, 0, Eigen::TensorEvaluator<Eigen::TensorReshapingOp<Eigen::DSizes<long, 2> const, Eigen::TensorVolumePatchOp<-1l, -1l, -1l, Eigen::TensorMap<Eigen::Tensor<float const, 5, 1, long>, 16, Eigen::MakePointer> const> const> const, Eigen::ThreadPoolDevice>, Eigen::array<long, 1ul>, Eigen::array<long, 1ul>, 4, true, false, 0, Eigen::MakePointer>, 4, 0, false, false>, Eigen::internal::gebp_kernel<float, float, long, Eigen::internal::blas_data_mapper<float, long, 0, 0>, 8, 4, false, false>, Eigen::internal::TensorContractionInputMapper<float, long, 1, Eigen::TensorEvaluator<Eigen::TensorReshapingOp<Eigen::DSizes<long, 2> const, Eigen::TensorMap<Eigen::Tensor<float const, 5, 1, long>, 16, Eigen::MakePointer> const> const, Eigen::ThreadPoolDevice>, Eigen::array<long, 1ul>, Eigen::array<long, 1ul>, 4, true, false, 0, Eigen::MakePointer>, Eigen::internal::TensorContractionInputMapper<float, long, 0, Eigen::TensorEvaluator<Eigen::TensorReshapingOp<Eigen::DSizes<long, 2> const, Eigen::TensorVolumePatchOp<-1l, -1l, -1l, Eigen::TensorMap<Eigen::Tensor<float const, 5, 1, long>, 16, Eigen::MakePointer> const> const> const, Eigen::ThreadPoolDevice>, Eigen::array<long, 1ul>, Eigen::array<long, 1ul>, 4, true, false, 0, Eigen::MakePointer>, Eigen::internal::blas_data_mapper<float, long, 0, 0> >

It has been 14 days with no activity and the awaiting tensorflower label was assigned. Please update the label and/or status accordingly.


proton-latest | Error! App '2278520' state is 0x202 after update job.

Hi there,
I'm encountering an issue while setting up Docker for an Enshrouded server on a Proxmox VM. I'm working with a limited-core, older PC server, and have decided to use Proton based on discussions I've seen on GitHub.
Here's what I've done so far:

Forwarded both UDP ports on my router.
Pulled the latest Docker image as of February 3rd at 17:30.
 Here's the log output:
2024-02-03T16:52:53.946513385Z [  0%] Checking for available updates...
2024-02-03T16:52:53.946516752Z [----] Download complete.
2024-02-03T16:52:53.946520075Z [----] Extracting package...
2024-02-03T16:52:53.946523376Z [----] Extracting package...
2024-02-03T16:52:53.946526664Z [----] Extracting package...
2024-02-03T16:52:53.946529946Z [----] Extracting package...
2024-02-03T16:52:53.946534451Z [----] Installing update...
2024-02-03T16:52:53.946540824Z [----] Installing update...
2024-02-03T16:52:53.946547077Z [----] Installing update...
2024-02-03T16:52:53.946552356Z [----] Installing update...
2024-02-03T16:52:53.946557432Z [----] Installing update...
2024-02-03T16:52:53.946560909Z [----] Installing update...
2024-02-03T16:52:53.946564168Z [----] Installing update...
2024-02-03T16:52:53.946567462Z [----] Installing update...
2024-02-03T16:52:53.946570991Z [----] Cleaning up...
2024-02-03T16:52:53.946574312Z [----] Update complete, launching Steamcmd...
2024-02-03T16:52:54.734250350Z tid(25) burning pthread_key_t == 0 so we never use it
2024-02-03T16:52:54.734308316Z Redirecting stderr to '/home/steam/Steam/logs/stderr.txt'
2024-02-03T16:52:54.734315033Z Logging directory: '/home/steam/Steam/logs'
2024-02-03T16:52:54.734318610Z [  0%] Checking for available updates...
2024-02-03T16:52:54.734321971Z [----] Verifying installation...
2024-02-03T16:52:54.734325560Z Steam Console Client (c) Valve Corporation - version<PHONE_NUMBER>
2024-02-03T16:52:54.734328924Z -- type 'quit' to exit --
2024-02-03T16:52:54.841975026Z Loading Steam API...OK
2024-02-03T16:52:54.841997570Z "@sSteamCmdForcePlatformType" = "windows"
2024-02-03T16:52:54.842333004Z
2024-02-03T16:52:57.587659030Z Connecting anonymously to Steam Public...OK
2024-02-03T16:52:57.587706596Z Waiting for client config...OK
2024-02-03T16:53:06.674478187Z Waiting for user info...OK
2024-02-03T16:53:06.674497995Z  Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)
2024-02-03T16:53:06.674502207Z  Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)
2024-02-03T16:53:06.674513761Z  Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)
2024-02-03T16:53:06.674517693Z Error! App '2278520' state is 0x202 after update job.
2024-02-03T16:53:06.805179393Z 2024-02-03 16:53:06,804 ERROR: steamcmd was unable to successfully initialize and update Enshrouded

It appears the steamcmd is unable to successfully initialize and update Enshrouded. Does anyone have insights or suggestions on how to resolve this issue?
Thank you for your assistance!

So the steamcmd error is an error that I built. Basically steamcmd had a non zero exit so I capture that and kill the container. The instances that I have seen the 0x202 error is generally related to steams inability to use the storage. Make sure there is enough storage and the permissions are correct and this will resolve.

I'm still a rookie with everything that has to do with Linux/Unix. So not entirely sure if that was the case, but in proxmox I'm using my own steam-dedicated template to start a quick VM with openSSH and docker preinstalled on a Ubuntu... with a preset user named "steam" which has an uid of 1000. When I recreated my Vm with another username, everything worked.

I had this same issue.
steam:steam user:group setup (10000:10000) with 0755 permissions on /home/steam/ and all subfolders (including enshrouded/savegame/). /home/steam/ still has 260g of available space (and /tmp/ for /tmp/dumps/ has 16g).
So everything had enough space, or so I thought. Then I wondered where Docker is storing the persistent data. When I inspect the Docker volumes, I see this:
[
    {
        "CreatedAt": "2024-04-12T13:20:47-07:00",
        "Driver": "local",
        "Labels": {
            "com.docker.compose.project": "steam",
            "com.docker.compose.version": "1.29.2",
            "com.docker.compose.volume": "enshrouded-persistent-data"
        },
        "Mountpoint": "/var/lib/docker/volumes/steam_enshrouded-persistent-data/_data",
        "Name": "steam_enshrouded-persistent-data",
        "Options": null,
        "Scope": "local"
    }
]

That "Mountpoint" path ( "/var/lib/docker/volumes/steam_enshrouded-persistent-data/_data" ) has only 3.8g of free space! Adding more space to that volume (at least the necessary ~14g for the game, I gave it an additional 26g for patching and other files) fixed the error for me. Hope this helps the next person to run across this.


Abandoned?

Getting access denied error from AWS when trying to play the MP3.

A workaround is to comment out the AWS S3 line in IVRController i.e.
            var gather = new Gather(action: Url.Action("Show", "Menu"), numDigits: 1);
            gather.Say("Press a digit.");
            // gather.Play("http://howtodocs.s3.amazonaws.com/et-phone.mp3", loop: 3);
            response.Gather(gather);

            return TwiML(response);


game crash

game crashes on 1.18.2 with this mod. please figure out a way to fix this

Hi Grizz, thanks for reporting. When does the crash happen? And can you share a crash log?

As for the crash, it happens every time I load a world, I even tried a fresh world and same result. This is the crash log
crash-2022-03-22_14.34.14-client.txt

Thanks for the log — looks like you actually have the 1.18.1 version of the mod installed. For some reason, CurseForge lists that above the 1.18.2 version, so it’s easy to mix them up. 1.18.2 is at https://www.curseforge.com/minecraft/mc-mods/treechop/files/3706945


Add note about port to Mesh GEP

What type of PR is this?
/kind gep
What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes https://github.com/kubernetes-sigs/gateway-api/issues/1487
Does this PR introduce a user-facing change?:

NONE

/assign @mikemorris

Thanks!
/lgtm
/approve


Add x-description URNs to fields to group related properties

In order to help visual tools to render kamelets, it would be nice if we include metadata information to the properties a kamelet expose, as example we could use some dedicated urn to group authentication related properties:
spec:
  definition:
    title: AWS SNS Sink
    type: object
    properties:
      accessKey:
        title: Access Key
        description: The access key obtained from AWS
        type: string
        format: password
        x-descriptors:
        - urn:alm:descriptor:com.tectonic.ui:password
        - urn:camel:group:credentials
      secretKey:
        title: Secret Key
        description: The secret key obtained from AWS
        type: string
        format: password
        x-descriptors:
        - urn:alm:descriptor:com.tectonic.ui:password
        - urn:camel:group:credentials

@nicolaferraro @oscerd what do you think ?

Makes sense, +1


missing tag so cluster-autoscaler can pick up ASG

You set the tag for the cluster name but you need to enable autoscaling for the ASG.
At this line
https://github.com/kubernetes-incubator/kube-aws/blob/master/core/nodepool/config/templates/stack-template.json#L135
Add:
           {
             "Key": "k8s.io/cluster-autoscaler/enabled",
             "PropagateAtLaunch": "false",
             "Value": ""
           },

@jasonrichardsmith Thanks for the report 👍
But no worry - that's it!

Thanks for trying kube-aws, and the info 👍
Honestly, I believe that I correctly understand that, because I am the original author of the auto-discovery feature.
So, I guess you might be missing worker.nodePools[].autoscaling.clusterAutoscaler.enabled set to true?
Also, would you mind sharing your cluster.yaml if the above guess didn't help?

@jasonrichardsmith No worry. Glad it worked for you 👍
Please feel free to submit another GitHub issues regarding U/X if any. I always welcome more inputs to improve kube-aws.


Call from a PMC not connected

Got a call from PMC<PHONE_NUMBER>, the call did not connect, and they did not call back nor leave a voicemail. Area code seems to be a Michigan PMC.

Michigan PMC says they don't have the PlantMap3D app on their tablet. 111 extension.

Attempted to install PM3D app on MI tablet.


Shifter:  Joint tagging to track guide locators relation

bug: build will fail from the serialized guide.
"guide_relative": self.guide.guide_locators[0], should just point to the str name of the guide locator like ```"guide_relative": "root",


fix: expose babel presets for upstream libraries

It would be nice to be able to do this:
{
  "presets": ["next/babel"]
}

currently you need to do this:
{
  "presets": ["next/dist/server/build/babel/preset"]
}

Coverage increased (+2.4%) to 61.169% when pulling 868c88b00a1d8112807f3e0721d6e38f8c77e904 on bcoe:babel-presets into 2a29bf624294a26fac240d080057ffd7a97ca74d on zeit:master.

:D :D :D

Thank you!


Support for Retrofit

Does this agent support auto-instrumentation of retrofit http client library?

Hey @scheler ,
We don't have a dedicated instrumentation for retrofit; but we do instrument OkHttp, which is used internally by retrofit. You should be able to instrument your retrofit-based clients by setting a custom OkHttp Call.Factory:
new Retrofit.Builder()
  .callFactory(splunkRum.createRumOkHttpCallFactory(new OkHttpClient())
  .build();

Do you automatically log network exceptions or only response codes?

We capture all exceptions thrown by the OkHTTP client -- if it throws SSLHandshakeException then yes, the telemetry produced by this library will reflect that.

there is a space for network exceptions on the SignalFX UI but nothing gets populated there, so only error codes like HTTP 500 are logged... I think something must be broken that drops cached exceptions in unhealthy network conditions

basically, we need a manual SplunkRum.getInstance().addRumException(t) for any exception (we have configured .crashReportingEnabled(false) because we use Crashlytics to track crashes but that should not disable logging of non-fatal exceptions).

I just don't see network exceptions captured in practice, so it may be a broken feature

Can you share a reproduction scenario for your use case? It can be a small example app, or a unit test, anything executable. If you're not able to do that, or do not want to share your code publicly, I suggest talking to your Splunk sales rep about your issues - we'll handle this in an internal ticket.

I do see "Network Errors" populated now, thanks for the help


Online Version

The link for Online Version loops back to this page. The Cmdlet Add-AttachmentFilterEntry does not work for the online version.

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

ID: 2f877953-84fa-9ec8-d458-76a04c1b7c33
Version Independent ID: c6b18203-781a-dea0-3e81-66cf8ca32e80
Content: Add-AttachmentFilterEntry (exchange)
Content Source: exchange/exchange-ps/exchange/antispam-antimalware/Add-AttachmentFilterEntry.md
Service: exchange-powershell
GitHub Login: @chrisda
Microsoft Alias: chrisda

This is by design. The 'Online Version' link in the RELATED LINKS section for all Exchange cmdlet reference topics links back to the topic itself. Why? That link is used when you run the command Get-Help <Cmdlet> -Online to take you to the topic page. That 'Online Version' link serves no other purpose, and is useless if you try to use it on the web.
Does that make sense?

I understand, now.

@chrisda  Thank you very much for the contribution and sharing this explanation. @Polymathink
Hope this comment is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.

BTW, I found yesterday that while the Add-AttachmentFilterEntry does not work for Exchange Online, the following method did work to add .vhd and .vhdx extensions: $FileTypesAdd = Get-MalwareFilterPolicy -Identity Default | select -Expand FileTypes; $FileTypesAdd += "vhd","vhdx"; Set-MalwareFilterPolicy -Identity Default -EnableFileFilter $true -FileTypes $FileTypesAdd

@chrisda kindly give your input, do you think documentation update is needed here?

Unless it's better placed somewhere else, it might be of benefit to those looking for an EOP solution. I would modify it to make it more generalised: $FileTypesAdd = Get-MalwareFilterPolicy -Identity Default | select -Expand FileTypes; $FileTypesAdd += <"filenameextension1">,<"filenameextension2">; Set-MalwareFilterPolicy -Identity Default -EnableFileFilter $true -FileTypes $FileTypesAdd

Add-AttachmentFilterEntry is a venerable old cmdlet from as far back as the Exchange 2010 days. The first two sentences of the topic say:

This cmdlet is available or effective only on Edge Transport servers in on-premises Exchange.
Use the Add-AttachmentFilterEntry cmdlet to add an entry to the attachment filter list that's used by the Attachment Filtering agent on Edge Transport servers.

And, the topic is peppered with "Applicable" tags that don't mention Exchange Online or Exchange Online Protection.
I don't think any updates are required to the topic.

@chrisda  Thank you very much for the contribution and sharing this explanation. @Polymathink
Hope this comment is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


Question about pdb-addr2line and end_rva

Hi, I made pdb-addr2line and saw the following comment in your code:
https://github.com/mandiant/STrace/blame/27e57cd6f990b824063a1c27a7612e3226af5340/Rust/PDBReSym/src/main.rs#L307
// if a line has no end rva, the start of the next block defines it's end. Lots of symbols are like this.

How up-to-date is that comment? Do you still get lots of symbols with a missing end_rva? I tried to mostly fix this issue in pdb-addr2line 0.7.2, with these commits:
https://github.com/mstange/pdb-addr2line/commit/8787f38644c7b0b22f1ce192c08f45ff8676bd9f
https://github.com/mstange/pdb-addr2line/commit/0bdb486bf498b027cbac977de733d102211faa5f
So I'd expect basically all symbols to have an end_rva now. If this is true, it might simplify your code.

I haven't checked in a while, I originally wrote this over a year ago. I'll do some testing sometime!


plutarch-extra: export a merged Plutarch Prelude that reexports the base Prelude (or something like Relude?) and the Plutarch.Prelude

This increases usability a lot as you can just set this as a Prelude in your cabal file and don't have to import Plutarch.Prelude in every file.

What happens if the user prefers to work with PlutusTx.Prelude?

If there is a need for that, we can just export another merged Prelude, say PPreludeTx which reexports that.
I think it's quite handy as the use with cabal mixins is really a boost in usability.


⚠ SceneTime has degraded performance

In 5f888ed, SceneTime ($ST) experienced degraded performance:

HTTP code: 200
Response time: 1445 ms

Resolved: SceneTime performance has improved in c194cfd after 6 minutes.


Check parameter executor in api.Context; fix tests

Give a meaningful error message if a bad value is passed as an executor.
Refs #918
Drive-by change: Fix tests to not lock up when I run them on moellenstedt with remote VSCode. Not sure if the lock-ups occur under other circumstances as well.
Contributor Checklist:

[x] I have added or updated my entry in the creators.json file
[ ] I have added a changelog entry for my contribution
[ ] I have added/updated documentation for all user-facing changes
[x] I have added/updated test cases

Reviewer Checklist:

[x] /azp run libertem.libertem-data passed

/azp run libertem.libertem-data

Drive-by change: Fix tests to not lock up when I run them on moellenstedt with remote VSCode. Not sure if the lock-ups occur under other circumstances as well.

Can you describe further how to reproduce this? I'm running tests directly via pytest in the vscode terminal, Python 3.7 environment via conda, and couldn't reproduce the problem with the current master. distributed version 2.21, all requirements seem to be up to date. How often does it occur, how often do I have to repeat to have a good change of seeing the problem?

How often does it occur, how often do I have to repeat to have a good change of seeing the problem?

In my tests, about every second run didn't work. I was running it in VSCode terminal (host Windows, target Moellenstedt), running pytest directly. It seems that running libertem-server in parallel on the same target system might contribute to the issue.
 I'll update here shortly :-)

/azp run libertem.libertem-data

Thanks, merged!

FYI just to keep a record, merged into master, this now also triggered the problem on Python 3.6 / Windows - this time not with a blind hang, but with a timeout error.


Makefile(238) : fatal error U1001: syntax error : illegal character '{' in macro

Facing issue while running nmake to build openssl

What openssl version, or if you're building from a git clone, what's your branch and top commit?

Hello,
Yes, downloaded from: (https://github.com/openssl/openssl.git) clone.
Branch is Master
yes it is top commit.
Kindly revert if you need further details.
Thanks & Regards,
Tejas
On Sun, Sep 10, 2017 at 1:10 AM, Richard Levitte<EMAIL_ADDRESS>wrote:

What openssl version, or if you're building from a git clone, what's your
branch and top commit?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/openssl/openssl/issues/4352#issuecomment-328299209,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMv0WihViOJV97rK34aOzd2LmOMLrySmks5sgumSgaJpZM4PSEF9
.

Ok good.  Next thing, can you tell me what the configuration command was?  You know, the command starting with perl Configure...  I'm interested in the exact command line you used.

Hi,
Yes,
first command was: perl Configure
second command was: nmake
And I got error mentioned in subject.
Thanks & Regards,
Tejas
On Sun, Sep 10, 2017 at 2:41 PM, Richard Levitte<EMAIL_ADDRESS>wrote:

Ok good. Next thing, can you tell me what the configuration command was?
You know, the command starting with perl Configure... I'm interested in
the exact command line you used.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/openssl/openssl/issues/4352#issuecomment-328329891,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMv0Wv38TLHwqLxU-fIOw0d2KGNLD37iks5sg6fEgaJpZM4PSEF9
.

Surely, there were some arguments after perl Configure?  I need the full command

Hi Richard,
I wanted to build it for win32 platform only.
So first time I used perl Configure {VC-WIN32 } but I got message on
command line : "target already defined - { (offending arg: VC-WIN32)"
So I simply fired "perl Configure" command. And it was successful.
Issue in "nmake" command.
Regards,
Tejas
On Sun, Sep 10, 2017 at 2:55 PM, Richard Levitte<EMAIL_ADDRESS>wrote:

Surely, there were some arguments after perl Configure? I need the full
command
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/openssl/openssl/issues/4352#issuecomment-328330598,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMv0WhcSCNndLg80z1B3EumkgTnKuF9uks5sg6sMgaJpZM4PSEF9
.

I certainly doubt that running perl Configure was successful without any argument at all.  However, the first command was slightly wrong as well, so try this instead:
perl Configure VC-WIN32

(i.e. no braces)
... and then nmake.

Hi Richard,
PFA.
Regards,
Tejas
On Sun, Sep 10, 2017 at 3:07 PM, Richard Levitte<EMAIL_ADDRESS>wrote:

I certainly doubt that running perl Configure was successful without any
argument at all. However, the first command was slightly wrong as well, so
try this instead:
perl Configure VC-WIN32
(i.e. no braces)
... and then nmake.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/openssl/openssl/issues/4352#issuecomment-328331219,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMv0Wt7LeRYvyotDneiXgB5LEYBFYLsjks5sg63lgaJpZM4PSEF9
.

I assume that means Pretty F*ng Awesome, and that we can close this case?
(PFA can also mean Please Find Attached)

Hi Richard,
No, still issue is there when I do "nmake". You can see error at the bottom
of screenshot.
-Tejas
On Sun, Sep 10, 2017 at 3:28 PM, Richard Levitte<EMAIL_ADDRESS>wrote:

I assume that means Pretty F*ng Awesome, and that we can close this case?
(PFA can also mean Please Find Attached)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/openssl/openssl/issues/4352#issuecomment-328332149,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMv0WtZeQicVoPXgLSkaARiQxCUHcBriks5sg7K9gaJpZM4PSEF9
.

Ah...  in that case, you forgot to attach the screenshot.

Hi Richard,
Please refer previous screen shot. See at the bottom.
Tejas
On Sun, Sep 10, 2017 at 3:56 PM, Richard Levitte<EMAIL_ADDRESS>wrote:

Ah... in that case, you forgot to attach the screenshot.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/openssl/openssl/issues/4352#issuecomment-328333550,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMv0WhQej5rs7L0ZLYhcT9fVJSMypjZbks5sg7lVgaJpZM4PSEF9
.

I misunderstand.  Please resend the screenshot

Sorry Richard for misunderstanding. :-(
PFA.
see fatal error at the bottom of screen shot.
-Tejas
On Sun, Sep 10, 2017 at 4:04 PM, Richard Levitte<EMAIL_ADDRESS>wrote:

I misunderstand. Please resend the screenshot
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/openssl/openssl/issues/4352#issuecomment-328333939,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMv0WgYFN-_OiEjgnRYxquSbGzZPaCakks5sg7shgaJpZM4PSEF9
.

Ok...  it seems that your attachment gets lost over mail, because I'm still not getting a screenshot.
Please log in on github and use the web interface instead.

Thanks!  And I think you've made a mistake, because that seems to be OpenSSL 1.0.1c, and that version builds in a distinctly different way.  I think you'll find a document called INSTALL.W32 there, and you should do as it says...
... but most of all, version 1.0.1c is oooold and unsupported, please download something current (currently supported versions are 1.0.2, 1.1.0 and the master branch).
Since this is an unsupported version, I'm closing this issue.

Thanks alot. :-)

i am seeing this issue as well. i am using 1.0.2

i am seeing this issue as well. i am using 1.0.2

Hello Jalal,
Did you find the method to fix this issue? I am building GmSSL, and find the same error as yours.
Thanks.
Tim

I have had the same error and it seems that it was my fault. Try:
nmake -f ms\ntdll.mak
instead of just nmake

I have had the same error and it seems that it was my fault. Try: nmake -f ms\ntdll.mak instead of just nmake

Hi, I got this error after calling nmake -f ms\ntdll.mak. Did you get it as well? Thanks


new account  - address record is created three times and myhQ contact blows up

Expected behavior
When creating an account on Big C, only one record should be created in TS Data tables.
Actual behavior
When creating an account from checkout area and placing an order, three records are created for the address.
email address =<EMAIL_ADDRESS>
Steps to reproduce behavior
Went to big c and selected a consultant, CID#28, then added items to my cart and went to checkout.
Step 1 of checkout user is required to enter an email address and checkout as guest or can click 'Sign in now'

If they click sign in now, they then have the option to create an account, I clicked this and created my account:

I then navigated back to the checkout and placed the order.
The new account is created in TSProfiles.dbo.userobject.

in dbo.address  - three records were created. I would expect only one to be created, correct?

Email address  =<EMAIL_ADDRESS>Big C ID#5354
inmyHQ address book when I try to view this contact I get an error:

THIS IS A DIFFERENT EXAMPLE THAT I DID EARLIER TODAY BELOW:
On this example, I checked out with the order and then on the confirmation page created my account.

on this one there is only two records in dbo.address

but in myHQ address book, CID #28 it displays 3 times:

We believe this is a database integration issue.

@suehamre is this fixed?

Corrected contact address logic in orders.uspU_BatchDetailStatusByOrderNumber so it would handle null business names and find the existing address. Added logic to bcom.uspI_BigCommerceOrderLine to only create one address record for a user that functions as both billing and shipping.


logger incorrectly prints rehydrated to undefined

newState is not a plain js object, it's an immutable.Map. Previously it would print undefined when in fact it was correctly rehydrated to part of the state.
I also removed new from the immutable Map creation. This isn't required as it's a factory.

thanks!


Generators now use same logic as Sequence

Summary
Update the GeneratorEnqueuer logic to follow the Ordered Enqueuer (We could merge them later on)

Remove the Lock and adds a new error message when use_multiprocessing=False.
The exceptions raised are now similar between a Generator and a Sequence. (StopIteration)
wait_time is now deprecated.

Related Issues
https://github.com/keras-team/keras/pull/8662#discussion_r210682836
PR Overview

[x] This PR requires new unit tests [y/n] (make sure tests are included)
[x] This PR requires to update the documentation [y/n] (make sure the docs are up-to-date)
[x] This PR is backwards compatible [y/n]
[x] This PR changes the current API [y/n] (all API changes need to be approved by fchollet)

cc @datumbox @de-vri-es

Thanks for the PR. Goals and code look good to me.
We seem to be having test flakiness issues with TF currently. Possibly related to the recent TF 1.9 upgrade on CI.

There are still issues with this PR on Python3, working on it.

Some time ago I modified GeneratorEnquer to re-throw the original exception from a generator in the main thread/process (https://github.com/keras-team/keras/pull/8485). It looks like this PR reverts the behaviour to always throwing StopIteration in the main thread.
I'd really like if the behaviour from my PR can be preserved.

First of all, your patch makes the Generator lightning fast. Good job!
Here are some benchmarks of GPU utilization before an after your patch (check IO and gpu-util on the last column). Removing the lock gives you a 5x speed improvement.
Before - Keras 2.2.2 (gpu starvation is observed):
https://ibb.co/mL7TyK
After - your branch:
https://ibb.co/i7rkCe
As for why the tests are stalling, I believe this has to do with your Queue. In our patch, we had to remove not only the lock but also the max-size of the queue. This is because a thread might get blocked while adding stuff in the queue (if it's full). When you call stop, these threads wait infinitely and that's why probably your tests are stalling.
Here is a modified version of my test snippet I posted on the other PR that can help you see it:
import time
from keras.preprocessing import image
from keras.utils.data_utils import GeneratorEnqueuer

it = image.ImageDataGenerator().flow_from_directory('/path/to/data', target_size=(224, 224), batch_size=512)

reader = GeneratorEnqueuer(it, use_multiprocessing=False)
reader.start(workers=16, max_queue_size=16)
g = reader.get()

start = time.time()
n = 100
for i in range(n):
        x=g.next()

total_time = time.time()-start
print('Total time %f sec; Average time: %f sec' % (total_time, total_time/n))

print('Stopping Queue')
reader.stop()

print('Finished')

Output:
Total time 31.848560 sec; Average time: 0.318486 sec
Stopping Queue^C

What I would do instead is use non-blocking Queue with not defined max-size. You can then use qsize() to get an approximate size of the queue and sleep if it exceeds the maximum. The queue can exceed the maximum defined value in this implementation but it's size can't get more than MAX-QUEUE_SIZE+WORKERS-1. I would also recommend adding some debug messages when the queue consistently gets empty and warn users for possible GPU starvation. This has been a huge pain for us in the past and due to the lack of messages, it's very hard to debug without modifying the keras code.
Try out the queue size and if that does not work let me know. I can debug the code for you on Monday as now I don't have the necessary tools to do it.

Sorry I need to provide a clarification on my previous comment. When I talked about stalling tests, I was referring to the travis output for the penultimate commit:
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received
The build has been terminated

The tests of your subsequent commit did not stall but I think this was just a happy coincidence of threads not falling into blocking state. I believe that in the penultimate commit the execution of the test_generator_enqueuer_threads test got stack on enqueuer.stop() because it's the last test running on gw0. I think my comment on the queue size is still valid and the above snippet can help you reproduce the problem.
As for the reason why the last commit fails on test_stateful_metrics with the tolerance error, I have no clue. Might be related to TF as @fchollet said. On my machine the specific tests pass on your branch.

@de-vri-es Now the behavior is similar to the Sequence behaviour, I wrap the exception in a StopIteration, we could rethrow as before. In any case, we should try to have a uniform behaviour.
@datumbox  in stop, we clear the queue so that the enqueuing threads get the final put.  I have a strong feeling that it's just the usual OOM from tensorflow since 1.9. I'll investigate the stateful metric test.
When we call stop, the enqueuer shouldn't be used and the data shouldn't be trusted.

@Dref360 I have not checked your modifications on an IDE so I just noticed that you clear the queue on stop. I'll check it more thoroughly next week. Does the example that I posted above hangs for you whenstop is called? For me it did and I saw similar behaviour on earlier commits of your PR on Travis. I also see that the last commit passed the tests once your rerun it on travis. Sounds good on investigating the OOM, let us know your findings. If you don't spot anything there, we should look on the order of the data that I describe above.
Don't get me wrong, I like your changes; the Enqueuer was heavily patched by multiple PRs (myself included) and it was long due for someone to rationalize it. Just checking because multi-threading problems are hard to debug/reproduce.

Your example works on my branch. I appreciate your help :P

test_stateful_metrics is just flaky. Maybe having a "deterministic" model is something we should look for.
Nonetheless, I fixed a potential bug for the "generator" part. Even with workers=1 the order is never guaranteed. Setting it to workers=0 guarantees the order.

@Dref360 you are right. I have another unrelated PR and it randomly failed on test_stateful_metrics. This is not related.

@de-vri-es Now the behavior is similar to the Sequence behaviour, I wrap the exception in a StopIteration, we could rethrow as before. In any case, we should try to have a uniform behaviour.

Makes sense. I do think it's better to throw the original exception rather than a StopIteration. It significantly increased the quality of bug reports we got on our custom generators. Think that is possible here, or do you think a separate PR will be better?

I agree with you, I'll make the changes in this PR this week.

LGTM, good work.

Tests looking stuck; restarting.

Please resolve remaining merge conflicts.


Quit scrape if no items in the feed

Sometimes a filter will result in a feed with no items. The casper scrape should not try to scroll/load items if this is the case.

resolved in 0e5dc6a


Algorithms: Design and Analysis Vs. Algorithm Specialization on Coursera

Hello,
The curriculum previously used Coursera's Algorithm Specialization (https://www.coursera.org/specializations/algorithms) but now it uses from the Stanford website here (https://lagunita.stanford.edu/courses/course-v1:Engineering+Algorithms1+SelfPaced/about).
I know this has been mentioned about the difference but forgot and can't find it now. So my question is what is the difference between the two? They're essentially the same thing correct? Why might one take one over the other?
Thank you.

If I understand correctly, only part 1 used to be available on the Lagunita site, which was basically courses 1 and 2 of the Coursera specialization, but recently they've added part 2 as well which is the equivalent of courses 3 and 4. So now you can do the whole thing on Lagunita without Coursera nagging you to pay.

Nixerrr is correct; nothing has changed except the platform hosting the course.


Update reference to UI elements by their current names

@normesta
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

merged


Typo (“folter” -> “folder”)

https://github.com/krzysztofzablocki/Sourcery/blob/85bdf335133a5594abf57cc4fa3d92d733534798/Sourcery/Sourcery.swift#L418

@mdznr mind submitting a PR?

This looks to be fixed. Close this issue?


WIP: Check for sufficient channel buffer size for signals being trapped

I'm concerned about the actual implementation itself, I'm not certain whether this is the most optimal.
The check currently ensures the buffer size == number of signals caught, however, in discussions with @judwhite and re-reading docs, I also believe just a check the channel is buffered is enough. As the buffer size above 1 depends on the signal rate, not the number of signals.
A test still fails until we can agree whether the check should only check for a buffered channel, or whether it should check the buffer size is at least number of signals being trapped.
Fixes #30

If we're only checking channels are buffered, then we could also just check calls to make with an os.Signal have a buffer regardless where they're used.
This could open it up for false positives though, if someone is creating the channels for some other purpose, but simplifies the test, improves speed and reduces false negatives when a unbuffered channel is passed into a function calling signal.Notify (this check doesn't handle that).

Please don't simplify the logic. In fact, I would recommend putting the PR on hold for now. By the time I am done with implementing VRP, checking a channel's length will be trivial.

Sounds good to me.

Closing for the moment as an alt implementation will be better.


Specify image resolution for vector formats

Close #15

Hi @kjcole, this PR may fix the SVG crop bug, can you please have a try? Use
pip install --user git+https://github.com/sphinx-notes/lilypond.git@bugfix/trim-svg

to install.

Since ImageMagick doesn't output real SVG, this is a hotfix, we need a better way to crop SVG.


Controllable (Fabric)

CurseForge link
https://www.curseforge.com/minecraft/mc-mods/controllable-fabric
CurseForge Mod Distribution
None
Modrinth link
No response
Source/other link
https://github.com/MrCrayfish/Controllable
Mod file size
15.81 MB
License
GNU General Public License version 3 (GPLv3)
What it does
Let's you play with a controller.
Why should it be in the modpack
It is, in my opinion, much nicer than controlify and offers a smoother experience.
Why shouldn't it be in the modpack
It's not available on Modrinth. It can be slow to update. It requires the FRAMEWORK library. It needs special hooks to interact with other mods.
Additional details
No response

No plan to add this at the moment, as indeed, it is:

not on Modrinth
requires another library
requires special hooks for mod interaction
is a lot bigger

Feel free to swap the mods on your instance or suggest any missing features to Controlify.


Extraction of Prices

Doesn't the api provide to extract opening prices, closing prices?

Hello! No, I haven't seen such an option to obtain opening and closing prices. It seems to provide only one price, the open price.
Best


Custom shaders

This PR adds custom shaders to bevy_ecs_tilemap in the form of a MaterialTilemap trait. Users can create their own materials like:
#[derive(AsBindGroup, TypeUuid, Debug, Clone, Default)]
#[uuid = "31575692-a956-4762-98e2-5d457f552d0a"]
pub struct MyMaterial {}

impl MaterialTilemap for MyMaterial {
    fn fragment_shader() -> bevy::render::render_resource::ShaderRef {
        "custom_shader.wgsl".into()
    }
}

This works fundamentally in the same way as bevy's Material2d or Material3d traits.
Migration Guide:
TilemapBundle should be replaced with StandardTilemapBundle.
TilemapBundle<T: MaterialTilemap> is now used for custom materials.

This is pretty neat.
Seeing a couple issues:

Seems like the chunking example is misbehaving when moving away from the origin.
The docs for TilemapBundle and StandardTilemapBundle are identical. Would be nice for those to explain how they differ and perhaps link to each other.

And just an opinion:

I think TilemapBundle is a better name for StandardTilemapBundle. It seems like users not doing fancy stuff shouldn't need to think about / migrate anything.

Closes: #443


refactor(scale_degree): rename degree → ordinal

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

13 of 13 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
712

Relevant Lines:
712

💛  - Coveralls


Write examples and user documentation

Again, I think it's a good idea to write examples and documentation progressively, with every PR, as you go along.
However, you can keep this issue for giving the docs a final overhaul once the service is fully functional.
Also check out the API docs issue on the TESK project board, which also covers some doc hosting options.


Add from_raw_fd methods for TcpStream and TcpListener

I use fd passing between processes and need to be able to "rebuild" the stream.

This looks good to me, but can you provide this functionality through extension traits rather than inherent methods?

At the start, I wanted to add it through the FromRaw trait but the Handle was needed. How would want me to call the trait?

You'd create a new trait, like TcpStreamExt

Strange name choice but let's go for TcpStreamExt! Also, don't you want to add #![deny(warnings]) as well to tokio?

Would it be better to not have a conversion directly from RawFd (especially since it requires a new trait) and instead go Fd -> std::Tcp* -> tokio::Tcp*.
I don't currently see a TcpStream::from_stream fn, is there a reason that it doesn't exist? Anyway, I would rather see this strategy unless there is a good reason why it doesn't work.

@carllerche: To create a tokio stream, you need a Handle and so creating a function (through a trait or not) anyway. So why not doing it at once?

@alexcrichton: Updated.

@carllerche that's a very good point yeah, and may sway me to preferring we add from_stream (no reason it doesn't currently exist) instead.

Note that another reason to not go the platform-specific extension route is that means the platform-specific extensions don't have to be duplicated in all the various crates. It may be more convenient ergonomically, but that's not really what we're optimizing for at this point.

So... Do I need to update something?

I agree with @carllerche that this isn't the right strategy, so I'm going to close.
If you'd like to continue along this though then a PR which adds TcpStream::from_stream should do the trick.