File rename not handled correctly in 2.0.3

TypeScript Version:  2.0.3
See Screen cast: noteworthy is that the project has no tsconfig.json. As you can see app.ts is not showing an error. When clicking onto the './bar' the tsserver even response with the old file ....../bar.ts

Closing issue for now. Looks like a problem with us not sending close events.

Was again a problem with realpath :-).

Actually, the real path fixed it in Windows, but not for Mac. Renaming in the example bar.ts -> boo.ts produces correctly an error. However renaming it back doesn't remove the error. Server tracing shows that the error is still reported from the server. See also https://github.com/Microsoft/vscode/issues/12798 which shows a screen recording and the below trace.
[Info - 10:32:20 AM] Using tsserver from location: /Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/extensions/typescript/server/typescript/lib/tsserver.js
[Trace - 10:32:20 AM] Sending request: open (0). Response expected: no. Current queue length: 0
Arguments: {
"file": "/Users/chrmarti/Development/repos/ts203/app.ts",
"fileContent": "import * as bar from './bar';\n\nbar.boo();\n"
}
[Trace - 10:32:20 AM] Sending request: open (1). Response expected: no. Current queue length: 0
Arguments: {
"file": "/Users/chrmarti/Development/repos/ts203/bar.ts",
"fileContent": "export function boo() {\n console.log('boo');\n}\n"
}
[Trace - 10:32:20 AM] Sending request: geterr (2). Response expected: no. Current queue length: 0
Arguments: {
"delay": 0,
"files": [
"/Users/chrmarti/Development/repos/ts203/app.ts",
"/Users/chrmarti/Development/repos/ts203/bar.ts"
]
}
[Trace - 10:32:21 AM] Event received: syntaxDiag (0).
Data: {
"file": "/Users/chrmarti/Development/repos/ts203/app.ts",
"diagnostics": []
}
[Trace - 10:32:21 AM] Event received: semanticDiag (0).
Data: {
"file": "/Users/chrmarti/Development/repos/ts203/app.ts",
"diagnostics": []
}
[Trace - 10:32:21 AM] Event received: syntaxDiag (0).
Data: {
"file": "/Users/chrmarti/Development/repos/ts203/bar.ts",
"diagnostics": []
}
[Trace - 10:32:21 AM] Event received: semanticDiag (0).
Data: {
"file": "/Users/chrmarti/Development/repos/ts203/bar.ts",
"diagnostics": []
}
[Trace - 10:33:42 AM] Sending request: open (3). Response expected: no. Current queue length: 0
Arguments: {
"file": "/Users/chrmarti/Development/repos/ts203/boo.ts",
"fileContent": "export function boo() {\n console.log('boo');\n}\n"
}
[Trace - 10:33:42 AM] Sending request: close (4). Response expected: no. Current queue length: 0
Arguments: {
"file": "/Users/chrmarti/Development/repos/ts203/bar.ts"
}
[Trace - 10:33:42 AM] Sending request: geterr (5). Response expected: no. Current queue length: 0
Arguments: {
"delay": 0,
"files": [
"/Users/chrmarti/Development/repos/ts203/boo.ts",
"/Users/chrmarti/Development/repos/ts203/app.ts"
]
}
[Trace - 10:33:42 AM] Event received: syntaxDiag (0).
Data: {
"file": "/Users/chrmarti/Development/repos/ts203/boo.ts",
"diagnostics": []
}
[Trace - 10:33:42 AM] Event received: semanticDiag (0).
Data: {
"file": "/Users/chrmarti/Development/repos/ts203/boo.ts",
"diagnostics": []
}
[Trace - 10:33:42 AM] Event received: syntaxDiag (0).
Data: {
"file": "/Users/chrmarti/Development/repos/ts203/app.ts",
"diagnostics": []
}
[Trace - 10:33:42 AM] Event received: semanticDiag (0).
Data: {
"file": "/Users/chrmarti/Development/repos/ts203/app.ts",
"diagnostics": [
{
"start": {
"line": 1,
"offset": 22
},
"end": {
"line": 1,
"offset": 29
},
"text": "File '/Users/chrmarti/Development/repos/ts203/bar.ts' is not a module."
}
]
}
[Trace - 10:33:43 AM] Event received: syntaxDiag (0).
Data: {
"file": "/Users/chrmarti/Development/repos/ts203/boo.ts",
"diagnostics": []
}
[Trace - 10:33:43 AM] Event received: semanticDiag (0).
Data: {
"file": "/Users/chrmarti/Development/repos/ts203/boo.ts",
"diagnostics": []
}
[Trace - 10:33:48 AM] Sending request: open (6). Response expected: no. Current queue length: 0
Arguments: {
"file": "/Users/chrmarti/Development/repos/ts203/bar.ts",
"fileContent": "export function boo() {\n console.log('boo');\n}\n"
}
[Trace - 10:33:48 AM] Sending request: close (7). Response expected: no. Current queue length: 0
Arguments: {
"file": "/Users/chrmarti/Development/repos/ts203/boo.ts"
}
[Trace - 10:33:48 AM] Sending request: geterr (8). Response expected: no. Current queue length: 0
Arguments: {
"delay": 0,
"files": [
"/Users/chrmarti/Development/repos/ts203/bar.ts",
"/Users/chrmarti/Development/repos/ts203/app.ts"
]
}
[Trace - 10:33:48 AM] Event received: syntaxDiag (0).
Data: {
"file": "/Users/chrmarti/Development/repos/ts203/bar.ts",
"diagnostics": []
}
[Trace - 10:33:48 AM] Event received: semanticDiag (0).
Data: {
"file": "/Users/chrmarti/Development/repos/ts203/bar.ts",
"diagnostics": []
}
[Trace - 10:33:48 AM] Event received: syntaxDiag (0).
Data: {
"file": "/Users/chrmarti/Development/repos/ts203/app.ts",
"diagnostics": []
}
[Trace - 10:33:48 AM] Event received: semanticDiag (0).
Data: {
"file": "/Users/chrmarti/Development/repos/ts203/app.ts",
"diagnostics": [
{
"start": {
"line": 1,
"offset": 22
},
"end": {
"line": 1,
"offset": 29
},
"text": "Cannot find module './bar'."
}
]
}

@mhegazy could you please investigate.

Now I see this under Windows as well. There is an interesting difference. After renaming bar.ts -> boo.ts the error message produced is:
"File 'p:/mseng/VSCode/Playgrounds/bugs/12798/bar.ts' is not a module."

After renaming boo.ts back to bar.ts the error message is:
"Cannot find module './bar'."

In addition it makes a big difference whether there is a tsconfig.json or not. If so it seems to work correctly.

It also makes a difference if boo.ts is open in the editor. If not, there are only FS events no editor open/close events. In this setup VS Code doesn't request error computation for app.ts. The interesting question here is whether VS Code should do this or whether we should wait for the builder work in 2.0.5 which should handle this (no client error requests). Opinions ?

Maybe we could kill 2 birds with one stone https://github.com/Microsoft/TypeScript/issues/10218 ;)


llvmPackages_14.openmp: unbreak

Description of changes
Fixup old patches causing OpenMP to be marked broken,
one of which can be removed in favor of pointing the build
at the required tools directly.
Mostly get tests working, but few failures I haven't tracked down
caused me to ultimately disable them for now.
Help testing or pointing to something that should work on Linux with
this is appreciated :).
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Looks like others need fixing too, see #162423 .  Especially libunwind and libcxxabi.  libunwind is trickier re:patch.
 And don't suppose you have patches for these already or would be willing to take a look? Thanks!

(force-push'ing after rebasing onto master, and -rc updates before that)

@dtzWill https://github.com/NixOS/nixpkgs/pull/154465 updated the patches somewhat, a tiny bit more was perhaps upstreamed since. I am not sure at what point the branch-offs occured upstream.

github.com/Ericson2314/llvm-project has the commits I made by patches from, but I would rebase them so it is unclear whether we have enough to stuff for prior releases from there :(.

@dtzWill Did you just remove parts of the patch that already were applied, or what?

Patch change question

@dtzWill Did you just remove parts of the patch that already were applied, or what?

Actually it looks like for this one... yes! Looking at how this compares to the patch before (or in git/, thanks for the pointer) that's all it took.  IIRC I applied it to the llvm-project tree and went from there, grep'd for the changed patterns a bit.  And dropped the tools patch in favor of using the cmake vars to control those paths.  Almost got tests working, I'll check but if you don't hear they're still failing on the final release :smile:.
vs openmp13
Comparing this to llvmPackages_13.openmp, this has multiple outputs now (which were already present before this PR)! So that might impact users, but hopefully works as folks expect without much trouble.  Might be good to ensure that users of the .dev output's cmake files can properly find the libraries in .out.  But since this patch is basically what we had before, modulo what you upstreamed (hooray!), maybe I'm worrying too much about this :smile:.
Comparing the header trees, looks like it's almost entirely the same, small enough I can include the diff:
diff -r ./openmp13/include/omp.h ./openmp14-dev/include/omp.h
434c434,439
<     extern void *__KAI_KMPC_CONVENTION omp_calloc(size_t nmemb, size_t size, omp_allocator_handle_t a = omp_null_allocator);
---
>     extern void *__KAI_KMPC_CONVENTION omp_aligned_alloc(size_t align, size_t size,
>                                                          omp_allocator_handle_t a = omp_null_allocator);
>     extern void *__KAI_KMPC_CONVENTION omp_calloc(size_t nmemb, size_t size,
>                                                   omp_allocator_handle_t a = omp_null_allocator);
>     extern void *__KAI_KMPC_CONVENTION omp_aligned_calloc(size_t align, size_t nmemb, size_t size,
>                                                           omp_allocator_handle_t a = omp_null_allocator);
440a446,447
>     extern void *__KAI_KMPC_CONVENTION omp_aligned_alloc(size_t align, size_t size,
>                                                          omp_allocator_handle_t a);
441a449,450
>     extern void *__KAI_KMPC_CONVENTION omp_aligned_calloc(size_t align, size_t nmemb, size_t size,
>                                                           omp_allocator_handle_t a);

Seems like on that front things are very unlikely to break :).
I re-enabled the bitcode building as it builds and installs it fine AFAICT.
Testing
If someone is in a position to test this at all, that'd be swell.  I admit I don't remember right now how to use this for ad-hoc testing, and of course checking our in-tree users (or future in-tree users when they move to 14) would be good.

in-tree users: Darwin, clang-based stdenv's.  Maybe can at least kick the tires a bit by modifying a package to use an appropriate stdenv on Linux for that.  Might take fair bit of compute to test more exhaustively on Linux (via pkgsLLVM or something).
Checking build on Darwin:  Darwin ofborg builders timed out building LLVM, checking this at least /builds/ on that platform is probably a good idea before proudly marking it no longer broken :innocent: .

All that said, I think if this looks good to folks we should move ahead (maybe after build-testing on Darwin?).  I think things like libcxxabi are likely more important, for example.  Not sure how tricky that'll be yet!

@dtzWill Did you just remove parts of the patch that already were applied, or what?

That's what it ended up being, yes, I think.  Not how I went about it but yes, applied and seemed safe to drop bits that were already applied (since seemed you were upstreaming things).  The rest still seem useful, and seem to be needed (and doing what they seem intended to).
Bummer about the patches rebase'd and maybe lost from around the branch-off.  These things happen, but ugh sorry.  How do you want to handle this, then? (don't suppose you have a super high git reflog limit and they're still sticking around in there? hopeful face)
What we have here (openmp) doesn't seem super broken (bits all end up in expected places, compared to openmp13 -- includes are almost entirely the same, etc.), but I haven't checked the produced cmake bits all work (esp across multiple outputs).  Haven't sorted what a good test might be, since our in-tree users are Darwin or a clangStdenv (so can't just point nixpkgs-review at it or something :)).
The other bits (the other subprojects) I/we might need (or really appreciate at the least) some help with.  Can you take a look?  Or is there a way to check things work as expected?

BTW I've done a hopefully-not-too-rough attempt at packaging up MLIR and flang over here: https://github.com/NixOS/nixpkgs/pull/163878 .  I noticed your github has a gnu installdirs for MLIR (5ad96992ef909e6b99d8c693a285f06c9fc645fe), is any of that needed? To fix libraries being installed in the wrong location, I addressed it same as in another patch (but I don't see that in your commit).  Well anyway, this can be discussed over in that PR if you have time/are interested :smile:.  Also, I'm packaging up a few more projects, hopefully that'll be posted soon (maybe as a flake).

 If just tthe former I might have reflog, but honestly I would just start with what's in Nixpkgs as more of a known-good state.

Also note I did save the original backports in split-prefix-*. I should probably put 13's in there for safe keeping, and 14's once it is fixed it.


Creating an Empty animation

This is created as a discussion for PR #14 .
I thought that adding Animation.empty would make it easier to match either no animation or some animation depending on the model.
My thinking is
animatedEl
    ( if shouldAnimate then
          expandFade
      else
          Animation.empty
    )

@andrewMacmurray mentioned that he usually makes conditional animations like:
if shouldAnimate then
   Animated.div expandFade [] [ element ]
else
   element

(For understanding both use the expandFade animation from the docs.)
In my opinion both work just fine (Andrew's might be slightly more performant, but I haven't tested it, but I can't imagine it is but much ). I just like the flexibility of being able to drop in an empty animation because both "Do I want this element to animate or not" and "Do I want an animated element or not" now have direct answers.
I'm interested what others think?
Thanks!
Also I am curious, should the name be Animation.empty because that is what the code is doing, or should it be Animation.none because that is what the intent is?

I've also found Animation.empty to be a great placeholder when using animated Els to allow for the project to compile so I can see layout before I begin to animate.

My thoughts on this are that I'd rather not include it unless it's requested by a number of people - I'd like to keep the api deliberately minimal and not add helpers that could be specific to people's use cases (this is a general philosophy followed by many of the core Elm libraries).
One thing I often do in these situations is define a module in a project for extras - e.g.:
module Utils.Animation exposing (empty)

empty : Animation
empty =
    Animation.fromTo
        { duration = 0
        , options = []
        }
        []
        []

And then use the same alias name in other modules so it "looks like" the same api:
import Simple.Animation as Animation
import Utils.Animation as Animation

myAnimation : Bool -> Animation
myAnimation shouldAnimate =
    if shouldAnimate then
        Animation.fromTo
            { duration = 500
            , options = []
            }
            [ P.x 0 ]
            [ P.x 100 ]

    else
        Animation.empty

Ya I totally understand where you are coming from. It makes sense that elm-simple-animation's API should be simple. I just don't think that having a "none" type is a specific use case, even Elm-UI has a none. I think that including it just helps reduce boilerplate, and from what I can tell they are doing the same thing.
Thank you for the code examples, I had never thought of using two imports with the same name like that before. I'm sure I will find places where that comes up again!

My plan is to use an API I've developed that will have knowledge, during view of items that may be transitioning OR in a completed transition state. Specifically, when it's time to render an animation it will look like this:


Azure deployment

Hey,
Just wondering if anyone is able to help attempting to deploy an Adonis 4.1 app to Azure and running into some issues.
I've configured Adonis to use ENV_SLIENT mode and setup all my environment variables as app settings. (Believe I had to do this in order for Azure to correctly find the iisnode port) But no matter what I do, when I visit the URL I'm hit with "The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.".
Nothing much in the logs either, adonis appears to be running OK, but doesn't output any errors.
2018-12-18T17:59:55.343Z - info: serving app on http://xxxxx.azurewebsites.net:\.\pipe\63a04c49-a26c-4ebc-9de5-699f18a32389
Other than:
(node:25408) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
But think this is just a deprecation warning and nothing important.
Any insight would be appreciated.
Cheers,
Mark.

Actually...managed to fix this . The web.config provided in the default node js app service on Azure, was seriously messed up had some rewrite options, that were causing issues. All good now.

Oh...if anyone needs that web.config feel free to drop me a message. I can supply it :)


Export as SVG or other Graphics

From<EMAIL_ADDRESS>on April 07, 2011 10:24:27
What is the expected output?
It would be nice to have the possibility to export the created design as SVG (or in other graphic formats). SVG could be further processed by GIMP or Inkscape to include it into documentations. What version of the product are you using? On what operating system? wwwsqldesigner-2.5 on Debian Squeeze
PS: Keep up that good work!
Original issue: http://code.google.com/p/wwwsqldesigner/issues/detail?id=124

From ondrej.zara on April 07, 2011 04:05:13
Very similar to issue #70 . Exporting as SVG, PDF or anything else basically means duplicating the whole codebase in order to render in non-HTML format. I have no time nor courage to do such major refactoring; instead, I strongly suggest using PhantomJS ( http://www.phantomjs.org/).. .

I would be happy with an export to something printable to a large format printer.  How about a PDF output via one of the many HTML to PDF php libraries?

The PDF writer would have to understand the full CSS styling and SVG connector code as well. Rendering using PhantomJS (one can easily do this already by feeding it with a permalink to a saved design) is more straightforward.

This is a duplicate of #132.
Still, if there was a button to hide the UI (and the background grid), we could use the browser built-in tool to take a full-page screenshot.

Still, if there was a button to hide the UI (and the background grid), we could use the browser built-in tool to take a full-page screenshot.

The main toolbar can be closed by the triangle button located at the very top of it. The minimap and grid remains, though.


Softplus with parameters

Should I go on implementing the parametric version of Softplus?
Current implementation: softplus_impl.py#L35
Reference to parametric version: PyTorch docs

@ jvdillon could you please comment on this.

Sorry for just noticing this issue.  Im happy to make this change ASAP.

So we do have the hinge_softness parameter. Do you need the threshold parameter as well? (I question if threshold is useful since the function is anyway almost linear...)

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


Project

New files added to ide_profiles for instructions about configuring Eclipse project.
Project TODO lines have been completed and preliminary results for the first data
file are printed and tested with the kalman_tracker_linux simulator.
Changes to be committed:
new file:   ide_profiles/Eclipse/README.md
new file:   ide_profiles/Eclipse/images/Capture-EclipseMenuFileImport.jpg
new file:   ide_profiles/Eclipse/images/Capture-EclipseProjectsIntoWorkspace.jpg
new file:   ide_profiles/Eclipse/images/Capture-Final.png
new file:   ide_profiles/Eclipse/images/Capture-Import-2.png
renamed:    CMakeLists.txt -> src/CMakeLists.txt
modified:   src/FusionEKF.cpp
modified:   src/FusionEKF.h
modified:   src/kalman_filter.cpp
modified:   src/kalman_filter.h
modified:   src/main.cpp
modified:   src/tools.cpp
modified:   src/tools.h

I meant to pull this to my fork... mistakenly pulled here


⚠ Samsung has degraded performance

In 1ef7fce, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2452 ms

Resolved: Samsung performance has improved in b27497d.


Issue with Spice

First - Thanks for a great program!  Now on to the issue :)
I have  Proxmox running remotely in a Lab at school and as a server here at the house. When connecting through the web interface and launching a Spice session  Remote-Viewer connects and launches a window automatically with no issues.  I am able to connect to either server with the test account and see a list of VMs the user is authorized to use.  The issue that happens is that Virt Viewer pops up a window saying it is "unable to connect to the graphic server"
Some things I have tried -  Turning off all Windows Firewall and Anti Virus Settings - Same Error
- Setting the spice port in the vdiclient.ini file                     - same error
I am running Windows 11, so I'm not sure if that is part of the issue.  I plan on testing on Windows 10 when I return to work Monday.
Just wondering if you had any other ideas since both servers work with the web browser downloading the .vv file, but both fail with the same error in the app.
Look forward to seeing where this program goes.
Greg

Ok found something that may be causing the issue:
the file downloaded from  the website has  this line:   proxy=http://prox.ctisandbox.cfcc.edu:3128
In the INI debug  it has this line:  proxy = http://pve2.ctisandbox.cfcc.edu:3128
It is using the node (host) name instead of the domain name.  Otherwise, the two files appear to be identical.
I tried overriding it by using prox2.ctisandbox.cfcc.edu:3128 =<IP_ADDRESS>:3128 in the ini file.
But it still shows the  proxy = http://pve2.ctisandbox.cfcc.edu:3128  instead of the IP address
I know this would not work long-term.  but was hoping it would give us proof that this was the issue...
Greg

would it not need to be pve2.ctisandbox.cfcc.edu:3128=<IP_ADDRESS>:3128 in the ini file instead?
Here is the logic that looks for the exact value you're receiving in the spice configuration:

It strips off http:// (first 7 characters) off the front of the proxy value and if the string matches an entry in your config file it will replace it.

You are 100% correct.   Sometimes I can't see the forest for the trees :)    Works great now!
Thank you again for a great program.  This will make it much easier to have the students working remotely on labs.
Greg

Quick easy fix that was my mistake


Fixed #9050

Fixes #9050 3 bugs (NullPointerException, messed coords and regularization overwriting/loss). All changes require some manual check

Bugged commits


Turning task into an importable module

Terraform providers modules are named in such a way that prevents importing them. Now that we're going to use the task package from several repositories, we'll need to perform some modifications so it can be imported.
Option A
Rename terraform-provider-iterative to github.com/iterative/terraform-provider-iterative here and on every imaginable import:
https://github.com/iterative/terraform-provider-iterative/blob/85645f465d82dc849dc51fcbd54a395ac185b6b6/go.mod#L1
Option B
Create a new github.com/iterative/leo repository/module and move the task package (also cmd) and children there.

(I prefer the second option)

To be clear - the way terraform provider modules are named has no technical reason behind it. It's just a means of not having to maintain a stable API. Nothing will break if we change the module name of terraform-provider-iterative.


Bug in HP_model ECON_IHX variante A

The name of the python file is different from the Heat pump class code. So when we do simulation, it picks correct topology image but wrong heat pump class.
For example, python file name is HeatPumpEconIHX.py, but the Heat pump class code in it is for the HeatPumpIHXEcon.

I fixed the issue with the mixup between topology schema and heat pump class of the series economizers. Additionaly, I changed the naming convention of variant "A" and "B" according to how we named these topologies in other work. What needs to be done still is the complete renaming of the parallel compression economizer variants according to this naming convention.
The implementation of variant "B" of the parallel compression econmizer with ihx right after the econ is out of the scope of this issue I think.

I finished the enforcement of the ihx naming convention for the parallel compression economizers. For the pc heat pumps with two ihx's, I went with e.g. ihx_pc_econ_closed_ihx to align it with the naming of heat pumps with one ihx. If you have any objections to that, I will reopen the issue. Otherwise I think this is done for now.

HeatPumpIHXPC - this naming means, the IHX is immediate after the condenser and not after economizer, right? if so the naming for this model is wrong. Because the connection inside this model in a such a way that the IHX is after economizer.

Yeah, you're right. So the real problem with the HeatPumpPCIHX is, that it's topology schemas are wrong...
I'll reopen the issue, undo my changes of renaming it and then we'll fix the schemas.

I copied the parallel compression ihx heat pump class and remodelled it to fit its name. Now both variants exist and the old one (now named back to HeatPumpPCIHX) only needs the topology schemas. @maltefritz will create them and then the issue should be done.

I created topology schemas for HeatPumpPCIHX. Now everything should be correct.
Thank you for your work.


Implemented Question Model, Storing and Fetching Question by ID for Question Service

Finish Issue #24 , #26
Task Done:

Implement Question. QuestionCategory Schema and Collection
Implement CRUD functions
Implement endpoints

lgtm


Add constants for magic numbers

There are a few instances of numbers used in our code where it is not obvious how these numbers have been determined.  For example
forecast_dao.py includes the number 41:
class CamsRequestDetails:
def __init__(
    self, base_forecast_datetime: datetime, no_of_forecast_times: int = 41
):
    self.base_forecast_datetime = base_forecast_datetime
    self.no_of_forecast_times = no_of_forecast_times

This ticket is for reviewing the codebase for numbers like these and adding constants for them to improve the readability / maintainability of the code, with additional comments if needed.
Acceptance Criteria

Any "magic" numbers are defined as constants
This only covers the UI and backend code, doesn't cover tests
Regression should have been run (no functional change in this ticket)

Test Checklist:

[x] Test Analysis & discussion with developer
[ ] Write Test Cases / Charters
[ ] Test Cases & Charters Reviewed
[ ] Test Cases Executed
[ ] Test Charters Executed
[x] Regression tests executed
[ ] Automation Tests added to project

Test Analysis

No functional change, just need to run regression tests and ensure they pass

Backend tests - PASSED ✅

Frontend tests - 33 Failed, all to do with snapshots

AQI graph snapshot is failing because the line has changed

Pollutant graphs are failing as expecting dimensions 600 x 400 but getting 601 x 400

No2 is correct dimensions but 192 pixels (ratio 0.01 of all image pixels) are different.

note: webkit tests are expecting and getting a different size: Expected an image 1200px by 800px, received 1202px by 800px

Regression Tests Passed ✅

Backend system tests

Frontend system tests


regional failover to work with failover priority

Please provide a description of this PR:
Related to https://github.com/istio/istio/issues/47068
Failover and FailoverPriority can't be used together at the moment. There is no validation as such to prevent this but FailoverPriority takes precedence in case it is defined. There could be a requirement such that failoverPriority should be considered for calculating priorities of endpoint and at the same time of failover is defined it can be taken into account for determining priorities of the endpoints remaining.
The example is given in the issue attached.
This PR needs a document change if merged

Hi @tanujd11. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@hzxuzhonghu

/ok-to-test

@tanujd11: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
1203524f2af0af12416a06d3e597ba790382b6e8
link
true
/test release-notes

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Not sure we need this, see https://github.com/istio/istio/issues/47068#issuecomment-1734614560? I may be misunderstanding though

@tanujd11: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

lint_istio
59f2418da71dbb644c6a09cf8eb69ca574f5a15e
link
true
/test lint

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@tanujd11: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

lint_istio
59f2418da71dbb644c6a09cf8eb69ca574f5a15e
link
true
/test lint

gencheck_istio
59f2418da71dbb644c6a09cf8eb69ca574f5a15e
link
true
/test gencheck

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Hey @hzxuzhonghu can this PR be backported to 1.19?

I would suggest not, let it run in master to have a test


Test: provide more clear message on GetScope.

Signed-off-by: Eloy Coto<EMAIL_ADDRESS>

This change is

test-me-please


Full name in fieldset labels

Issue
When you send or receive a mail/message/whisper/warning, the fieldset tag only includes the first name of the sender/receiver, or no name at all. Instead, we should show the full name in all cases.
See this Wolfery Forum discussion:
https://forum.wolfery.com/t/suggestion-redesign-the-message-just-a-bit/1768

Resolved in PR #77


Potential DoS attack when reading large containers

I've setup the server over a directory with 309.978 very small N-Quads files (~10 triples per file).
The server seems to be unable to reply to requests to this container (files within it work fine).
The server also doesn't appear to give an error, or result in a timeout.
I've done some profiling in FileDataAccessor, and these are my findings:

fsPromises.readdir takes 541 ms. Given the number of files, this is a reasonable duration.
The for loop for generating metadata takes 28.045 s. This can probably be optimized. Maybe some parallelization can be done even using Promise.all.
Quad generation takes 1.187 s. Relatively fast, but maybe also optimizable if done in a streaming manner.
After this, I see warn: This writer can only write errors appearing in the console, and nothing happens anymore after that. Possibly something crashes silently, as I'm unable to see any further output (and my request is still hanging).

One could argue that this container is simply too large, so perhaps the server should have a default max limit when listing containers. Alternatively, container listing can be done in a streaming manner, which would probably require refactoring a bunch of components.

* **After this, I see `warn: This writer can only write errors` appearing in the console, and nothing happens anymore after that. Possibly something crashes silently, as I'm unable to see any further output (and my request is still hanging).**

That probably means the BasicResponseWriter is crashing (that warning is from the canHandle function of the other response writer).

First of all, the logging:

That probably means the BasicResponseWriter is crashing

And if it does, we can no longer write the error to the HTTP stream.
So any error at this point MUST be logged as an error, since there is no other way to see it.
We do have an issue abut this: #6, so it needs to take that into consideration.

One could argue that this container is simply too large, so perhaps the server should have a default max limit when listing containers.

Agreed, we could bail on > 10,000 for now; later, it could be multi-paged.

fsPromises.readdir takes 541 ms. Given the number of files, this is a reasonable duration.

Fair enough.

The for loop for generating metadata takes 28.045 s. This can probably be optimized. Maybe some parallelization can be done even using Promise.all.

Quad generation takes 1.187 s. Relatively fast, but maybe also optimizable if done in a streaming manner.

The combination of the above is the problem: there should be no such thing as a generation phase.
Rather, we should:

before (or in parallel with) readdir:

write :c a ldp:BasicContainer, ldp:Container; etc.
the rest of the container metadata as it arrives

immediately after readdir

for each file, write :c contains :f

asynchronously after readdir

for each file, get and write quad metadata

That way, the response will be streaming. We should also listen for response stream close to stop generation.
So yes, might still take 28s, but we will be streaming the response during all of that time, and the client can back out at any point.
I would not parallelize, that could be an even bigger DDOS; with a linear loop, at least only the one request will be blocked.

First of all, the logging:

Since the last update there should be loggin though if the stream crashes. The fact that this doesn't happen means something unexpected is breaking
https://github.com/solid/community-server/blob/82f3aa0cd849417b25d56dc288999a4acc914036/src/ldp/http/BasicResponseWriter.ts#L37-L40

That way, the response will be streaming. We should also listen for response stream close to stop generation.

That will require some architectural rethinking since everything that is metadata is currently not stream and put in a RepresentationMetadata object. Some other functions also depend on this (e.g., the delete function using that metadata to check if a container is empty before deleting).

In fact, the response stream should likely be lazy here, such that we only read from disk when asked to write data.
So container metadata and containment triples can be non-lazy (they are 2 calls for us), but reading the other files' metadata should be on demand.
So we after we have piped our "header" (container metadata + containment triples), we should only write until false and wait for drain events on the response before continuing: https://nodejs.org/api/stream.html#stream_event_drain

Since the last update there should be loggin though if the stream crashes. The fact that this doesn't happen means something unexpected is breaking

FYI, I am in sync with master, so something unexpected must indeed be breaking.

That will require some architectural rethinking since everything that is metadata is currently not stream and put in a RepresentationMetadata object.

Maybe the problem is that we have put it in metadata in the first place. Maybe this should have been data with internal/quads (or internal/dir+quads) to begin with.

We are also returning metadata of every resource in the container because that's what NSS does. Question is if we really need to do this or if the containment triples are sufficient? Or maybe we could have this as a setting?

Let's check the LDP spec on this indeed. I do know cases where all metadata is used (file browsers).

Ah, even better: https://nodejs.org/api/fs.html#fs_dir_symbol_asynciterator

FYI, I just ran into this again, and it looks like the BasicResponseWriter is not crashing anymore, so that's a good thing :-)
Things also seem a bit faster, but still quite slow (and non-streaming).

FYI, I just ran into this again, and it looks like the BasicResponseWriter is not crashing anymore, so that's a good thing :-)
Things also seem a bit faster, but still quite slow (and non-streaming).


When you are going build with rust on Linux

You must install this first.
sudo apt-get install curl git-all cmake gcc libssl-dev pkg-config libclang-dev libpq-dev build-essential
User version wants to run node

Thank you for the suggestions. One will want to run the snarkOS binary as node, that repo has build instructions noted in the README for ubuntu - PR is open for debian https://github.com/AleoNet/snarkOS/pull/3041

Are you saying you want to have a .deb package for snarkOS?  Not sure what this issue is describing/asking for.

Compiler time with Rust. People who use Rust generally don't need to install much, but when building a Blockchain project aleo or sui, aptos, rooch,... Must be installed because it is very necessary. If not installed as mentioned, it may not work.

Compiler time with Rust. People who use Rust generally don't need to install much, but when building a Blockchain project aleo or sui, aptos, rooch,... Must be installed because it is very necessary. If not installed as mentioned, it may not work.

@jamesatomc are you suggesting we should have a build_ubuntu.sh script like the one we have in snarkOS, telling people the required libraries to build?

I saw it last week. At first I thought it wasn't there.


#version is hidden from GLSL in Rust string literals

In Rust code blocks, mdBook hides lines starting with #, which causes the string literals used by vulkano-shaders in Rust code blocks to not render the #version 460 line. This is of course not the desired outcome. This supposedly works the same as in rustdoc, so I'm assuming using double hashtag ## will escape the symbol.

## does escape the the symbol! I'll have a pull request with the fix soon.


"docker app upgrade" doesn't seem to actually perform any upgrades

Description
I don't understand what docker app upgrade actually does. With docker-app 0.6.0, I'm able to make changes like a service's image or environment variables, run docker-app deploy …, and see that change take place. With docker-app 0.8.0, making the same types of changes and running docker app upgrade … doesn't actually update anything.
Steps to reproduce the issue:
Install the following application. This is a single-file app named demo.dockerapp.
name: demo
version: 0.1.0

---
version: "3.7"
services:
  nginx:
    image: nginx:1.16.0
    environment:
      ABC: 123

---

$ docker app install demo
Creating network demo_default
Creating service demo_nginx
Application "demo" installed on context "default"
$ docker service ls
NAME                IMAGE               REPLICAS            MODE                PORTS
demo_nginx          nginx:1.16.0        1/1                 replicated

Change the image to nginx:1.17.0 and the value of ABC to 456. Upgrade the app.
name: demo
version: 0.1.0

---
version: "3.7"
services:
  nginx:
    image: nginx:1.17.0
    environment:
      ABC: 456

---

$ docker app upgrade demo
Updating service demo_nginx (id: 5iagc6bvplgkagik3dnykut7m)
Application "demo" upgraded on context "default"

Describe the results you received:
Neither the image nor the environment variable has changed.
$ docker service ls
NAME                IMAGE               REPLICAS            MODE                PORTS
demo_nginx          nginx:1.16.0        1/1                 replicated
$ docker service inspect demo_nginx --format '{{ .Spec.TaskTemplate.ContainerSpec.Env }}'
[ABC=123]

The service does show an update, but the (current) Spec and PreviousSpec both have the same image and environment variables. The changes in the app aren't in the update. (Output below is truncated).
$ docker service inspect demo_nginx
[
    {
        "ID": "5iagc6bvplgkagik3dnykut7m",
        "Version": {
            "Index": 16568
        },
        "CreatedAt": "2019-06-18T15:24:28.6371129Z",
        "UpdatedAt": "2019-06-18T15:24:46.8050215Z",
        "Spec": {
            "Name": "demo_nginx",
            "Labels": {
                "com.docker.stack.image": "nginx:1.16.0",
                "com.docker.stack.namespace": "demo"
            },
            "TaskTemplate": {
                "ContainerSpec": {
                    "Image": "nginx:1.16.0@sha256:cbbfea92cde1d5dffc5a354a366f2bdd48ce59031183c165498e578e73bd06bd",
                    "Labels": {
                        "com.docker.stack.namespace": "demo"
                    },
                    "Env": [
                        "ABC=123"
                    ]
                }
            }
        },
        "PreviousSpec": {
            "Name": "demo_nginx",
            "Labels": {
                "com.docker.stack.image": "nginx:1.16.0",
                "com.docker.stack.namespace": "demo"
            },
            "TaskTemplate": {
                "ContainerSpec": {
                    "Image": "nginx:1.16.0@sha256:cbbfea92cde1d5dffc5a354a366f2bdd48ce59031183c165498e578e73bd06bd",
                    "Labels": {
                        "com.docker.stack.namespace": "demo"
                    },
                    "Env": [
                        "ABC=123"
                    ]
                },
            }
        }
    }
]

Describe the results you expected:
After the upgrade, the service's spec should be updated with the nginx:1.17.0 image and ABC=456 environment variable.
Additional information you deem important (e.g. issue happens only occasionally):
Changes to other properties like published ports and configs also don't seem to get applied on upgrade. I haven't been able to find changes to anything after running upgrade in docker-app 0.8.0.
Output of docker version:
Client: Docker Engine - Community
 Version:           19.03.0-rc2
 API version:       1.40
 Go version:        go1.12.5
 Git commit:        f97efcc
 Built:             Wed Jun  5 01:37:53 2019
 OS/Arch:           darwin/amd64
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          19.03.0-rc2
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.5
  Git commit:       f97efcc
  Built:            Wed Jun  5 01:42:10 2019
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          v1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Output of docker-app version:
Version:               v0.8.0-rc1
Git commit:            73d86744
Built:                 Wed Jun  5 01:45:27 2019
OS/Arch:               darwin/amd64
Experimental:          off
Renderers:             none
Invocation Base Image: docker/cnab-app-base:v0.8.0-rc1)

Output of docker info:
Client:
 Debug Mode: false
 Plugins:
  app: Docker Application (Docker Inc., v0.8.0-rc1)
  buildx: Build with BuildKit (Docker Inc., v0.2.2-tp-docker)

Server:
 Containers: 1
  Running: 1
  Paused: 0
  Stopped: 0
 Images: 302
 Server Version: 19.03.0-rc2
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: active
  NodeID: ilntgb4sbycucyl3iiva1wk3p
  Is Manager: true
  ClusterID: wsz99afbhy169obu69h1eq7z0
  Managers: 1
  Nodes: 1
  Default Address Pool: <IP_ADDRESS>/8
  SubnetSize: 24
  Data Path Port: 4789
  Orchestration:
   Task History Retention Limit: 5
  Raft:
   Snapshot Interval: 10000
   Number of Old Snapshots to Retain: 0
   Heartbeat Tick: 1
   Election Tick: 10
  Dispatcher:
   Heartbeat Period: 5 seconds
  CA Configuration:
   Expiry Duration: 3 months
   Force Rotate: 0
  Autolock Managers: false
  Root Rotation In Progress: false
  Node Address: <IP_ADDRESS>
  Manager Addresses:
   <IP_ADDRESS>:2377
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc version: 425e105d5a03fabd737a126ad93d62a9eeede87f
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 4.9.125-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 6
 Total Memory: 11.71GiB
 Name: docker-desktop
 ID: b5307ed3-4dc8-4eb4-b931-138544ef581f
 Docker Root Dir: /var/lib/docker
 Debug Mode: true
  File Descriptors: 57
  Goroutines: 172
  System Time: 2019-06-18T15:35:34.150281Z
  EventsListeners: 3
 HTTP Proxy: gateway.docker.internal:3128
 HTTPS Proxy: gateway.docker.internal:3129
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: true
 Insecure Registries:
  <IP_ADDRESS>/8
 Live Restore Enabled: false
 Product License: Community Engine

Additional environment details (AWS, VirtualBox, physical, etc.):

Thank you @kinghuang for filling this issue, the upgrade needs definitely some documentation  👍
docker app upgrade refers to an installation, not an application package.
docker app upgrade --help

Usage:	docker app upgrade INSTALLATION_NAME [--target-context TARGET_CONTEXT] [OPTIONS]

Upgrade an installed application

Examples:
$ docker app upgrade myinstallation --target-context=mycontext --set key=value

Options:
      --app-name string               Override the installation with another Application Package
      --credential stringArray        Add a single credential, additive ontop of any --credential-set used
      --credential-set stringArray    Use a YAML file containing a credential set or a credential set present in the credential store
      --insecure-registries strings   Use HTTP instead of HTTPS when pulling from/pushing to those registries
      --parameters-file stringArray   Override parameters file
      --pull                          Pull the bundle
  -s, --set stringArray               Override parameter value
      --target-context string         Context on which the application is installed (default: <current-context>)
      --with-registry-auth            Sends registry auth

During the installation, docker app stores the application definition, and refers to it with the upgrade. So like this all you can do is modify the parameters (ex: ports or replicas).
That said, we added a flag for your use case: --app-name to point to a new application definition (the one upgraded with your new services). It will then upgrade the stack with the new specification, and update the installation in the store with this new definition.
Does that make sense to you and fix your issue?

Ah, thanks for the explanation. I definitely did not get that understanding from the help text. I'll try this out tomorrow!

I tried it on one app where I added a new parameter. I am unable to upgrade the app. Here's what I did, using the demo app from the opening post.
Steps:

Install the demo app from the opening post.
Add a new environment variable whose value is a parameter named def.
Create a params.yml file with def: 456.
Upgrade the app.

$ docker app install demo
Creating network demo_default
Creating service demo_nginx
Application "demo" installed on context "default"
$ cat <<EOF > demo.dockerapp
name: demo
version: 0.1.0

---
version: "3.7"
services:
  nginx:
    image: nginx:1.16.0
    environment:
      ABC: 123
      DEF: ${def}

---
EOF
$ cat <<EOF > params.yml
def: 456
EOF
$ docker app upgrade demo --app-name demo.dockerapp --parameters-file params.yml
parameter "def" is not defined in the bundle

Describe the results you received:
The new parameter is not recognized.
Describe the results you expected:
The nginx service should be updated with a new environment variable DEF=456.

Hello @kinghuang , thank you for finding this issue 👍 .
I'm tracking the bug right now. It seems the parameters files are not applied/ignored during the upgrade. If you put the parameter in the "new" demo.dockerapp it should be fine, can you try it?
I will work on a fix once I find the culprit.

After second thoughts, I think this error is "normal" (even if not really explicit). If you try to install (not upgrade) this modified app, it would raise the same error.
Thing is that this app is no more valid (try to validate it and it will say ${def} is missing in the parameters section.
The fix here is to add a default value in you app definition, then you can override it with your params.yml file or via a --set.
Does that make sense?

It seems the "level" of the parameter matters. In the actual apps where I ran into this problem, the parameters were a sub-key of something else. Here's a reproduction for install, where both config.sasl_username and sasl_password have empty default values, but only sasl_password results in an error.
$ docker app install demo
Creating network demo_default
Creating service demo_nginx
Application "demo" installed on context "default"
$ cat <<EOF > demo.dockerapp
name: demo
version: 0.1.0

---
version: "3.7"
services:
  nginx:
    image: nginx:1.16.0
    environment:
      SASL_USERNAME: ${config.sasl_username}
      SASL_PASSWORD: ${sasl_password}

---
config:
  sasl_username:
sasl_password:
EOF
$ cat <<EOF > params.yml
config:
  sasl_username: some_username
sasl_password: some_password
EOF
$ docker app install demo --parameters-file params.yml
parameter "sasl_password" is not defined in the bundle

If I put sasl_password under config, it works.
$ docker app install demo
Creating network demo_default
Creating service demo_nginx
Application "demo" installed on context "default"
$ cat <<EOF > demo.dockerapp
name: demo
version: 0.1.0

---
version: "3.7"
services:
  nginx:
    image: nginx:1.16.0
    environment:
      SASL_USERNAME: ${config.sasl_username}
      SASL_PASSWORD: ${config.sasl_password}

---
config:
  sasl_username:
  sasl_password:
EOF
$ cat <<EOF > params.yml
config:
  sasl_username: some_username
  sasl_password: some_password
EOF
$ docker app install demo --parameters-file params.yml
Creating network demo_default
Creating service demo_nginx
Application "demo" installed on context "default"

Oh, that's interesting 😅 I'll take a look at that, thank you very much @kinghuang 👍

@kinghuang it looks like #554 fixed the issue you spotted. Can you try with master ? I'll close this issue, but feel free to re-open it if it's not fixed 👍


Avoid pushing image in pull_request event

Signed-off-by: Raul Sevilla<EMAIL_ADDRESS>Description
We shouldn't push container images in pull_request events. These kind of events does not have access to GHA secrets. In addition, we should test building images only, pushing them is not a hard requirement for this kind of CI.
Also adding some newlines.
Fixes

Duplicate of #344.
Additionally the logic in the if statement that you have for update_manifest won't work properly. You need to add the always() somewhere in there, otherwise the update_manifest task will only run if all of the images build successfully. In my testing, here is how I found that it needed to be done: https://github.com/cloud-bulldozer/benchmark-wrapper/pull/344/files#diff-d0777657fa3fd81d23aaf7273e58aee453b04e67882517900c56daeef9b3e4c1R165-R169


Add 'parser' instead of deprecated 'format'

Fixes #5456
update line chart demo to replace deprecated 'format' property with the 'parser' property under the 'scales' option of chart.js configuration(as per moment.js documentation). This update removes the below warning while running the example -
options.time.format is deprecated and replaced by options.time.parser.
jsfiddle sample after using 'parser' :  Demo

@benmccann Hi , Thanks for the approval , is there anything required from my end regarding this PR merge?

Thanks @Niladri24dutta


Error in rebuild

Goof evening
When I did "rebuild" to "ALL BUILD" file, I got this error "Error LNK1104 cannot open file 'Debug\warpctc.lib",  and I searched for solutions but it's not worked.
What can I do?
Thank you.

I guess, you got stuck at the following step?
Open the warp-ctc/build/ctc_release.sln with vs2017, and build the project ALL_BUILD (Release x64).
If so, the error may be caused by the build configuration, Try change it to Release x64 before the building.
Please feel free to contact me if there are any problems.

Thank you so much, it's work.
Sorry but I got a new error after doing this step.
When I did this step: python setup.py install
I got this error: LINK : fatal error LNK1181: cannot open input file 'warpctc.lib'
Do you know what should I do?
Thank you.

Check the files under the path warp-ctc/build/Release, to ensure the warpctc.lib has been generated after you build the project. If not, try to rebuild the project.
According to my experience, after the successfully build the project, there should be four files under the path, including test_cpu.exe, warpctc.dll, warpctc.exp and warpctc.lib.


GoogleAdsService.Search() failure in upgrade from Library V11 / Ads V10 to V14 / Ads V11

Hello - I have been communicating with the Google Ads API support team and they have asked me to contact you.
We have been using the API since 2014 with the same developer token and oAuth credentials / refresh token without problem. However, we have recently upgraded from the .NET client library V11 using Ads API V10 to .NET client library V14 with Ads API V11 and the call to GoogleAdsService.Search() is failing but without returning an error or logging information - configuration below:

.NET client library 14.0
VB.NET with .NET framework 4.8
Google Ads API v11
One method call to GoogleAdsService.Search()
Development token and Oath details used since 2014

I have attached an image of our code

As you can see, logging is enabled but the log DETAILED_REQUEST_LOGS_SOURCE is empty
However, the logging for GRPC does produce a file with data
The sample code performs a very simple campaign query
Line 57 calls GoogleAdsService.Search() successfully but...
When line 58 executes to read / fetch a result, the code runs but does not progress - it just sits there, waiting for something
And no exception is thrown, no logging is made
Please note that if a call is made to GoogleAdsService.SearchStream(), then the code executes correctly!

We are at a loss to work out what is happening as we cannot get any information from exceptions or logging. Could there be a problem with our OAuth desktop credentials or refresh token? Our "app" in Google Cloud Console is marked as "unverified", could this be a problem? (Although this has always been this way - we have one user of the app which is the MCC of the AdWords accounts we are accessing - which means we fit the "personal" user exception we think?)
Any help appreciated.

Many thanks.

Hi Tom,
The Search call is heavy, and WinForm UI threads are not designed to handle heavy calls because the Message pump blocks or deadlocks with the awaiting tasks, You need to use the async methods, or do something like this:
Private Async Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
  TraceUtilities.Configure(TraceUtilities.SUMMARY_REQUEST_LOGS_SOURCE,
      "c:\\Logs\\summary.log", System.Diagnostics.SourceLevels.All)

  TraceUtilities.Configure(TraceUtilities.DETAILED_REQUEST_LOGS_SOURCE,
      "c:\\Logs\\details.log", System.Diagnostics.SourceLevels.All)

  Dim client As New GoogleAdsClient
  Dim config As GoogleAdsConfig = client.Config

  config.DeveloperToken = "****"
  config.OAuth2Mode = OAuth2Flow.APPLICATION
  config.OAuth2ClientId = "****"
  config.OAuth2ClientSecret = "****"
  config.OAuth2RefreshToken = "****"
  config.LoginCustomerId = "****"

  Dim service = client.GetService(Services.V11.GoogleAdsService)
  Dim request As New SearchGoogleAdsRequest
  request.CustomerId = *****
  request.Query = "Select campaign.id, campaign.name from campaign"
  Await Task.Run(Sub() RunSearchQuery(service, request))
End Sub
Private Sub RunSearchQuery(service As GoogleAdsServiceClient, request As SearchGoogleAdsRequest)
  Dim results = service.Search(request)
  MsgBox("HERE " & results(0).Campaign.Name)
End Sub