TypeIdentifierPrefix not working as expected

I could well be doing something wrong here. Despite reading the annotations docs a couple of times, it's not entirely clear to me.
I'm trying to ensure the type names and identifiers in my entity model are good. I thought I'd just need to specify TypeIdentifierPrefix at the assembly level and all my entities would just inherit that setting. However, this isn't working:
[assembly: TypeIdentifierPrefix("http://www.example.com/")]

[Entity("Foo")]
public interface IEntity
{
    string Id
    {
        get;
    }
}

using (var context = new MyEntityContext(connectionString))
{
    var entity = context.Entities.Create();
    context.SaveChanges();
}

If I set a breakpoint at context.SaveChanges() and examine the Identity property of the entity (I don't know of any other way to check the ID - please let me know if there's a better way) I see:

If I manually specify on the Id property:
[Identifier("http://www.example.com/Entity/")]
string Id
{
    get;
}

Then it works:

So, questions:

am I doing something wrong with respect to TypeIdentifierPrefix? Should my entity's identifier be prefixed with the value in my TypeIdentifierPrefix?
how can I similarly check that my type identifiers are correct?
is there an easy way to see IDs in general? Some B* tooling for opening and browsing the store?

The TypeIdentifierPrefix attribute sets the prefix for the URI that is generated to identify the type rather than to identify an instance of the type. So if you just the [TypePrefixIdentifier] and the [Entity("Foo")] decorator on your IEntity interface and then created an instance of IEntity, in the store you would see a triple like:
http://www.brightstardb.com/.well-known/genid/{guid}  http://www.w3.org/1999/02/22-rdf-syntax-ns#type  http://www.example.com/Entity .

The [Identifier] attribute on the Id property is the one that you need to set to specify the identifier prefix for instances of the entity.
If you want to look into the store then the tool to use is Polaris. You can either build this yourself from source (src/tools/Polaris/polaris.sln); or install from the setup.exe over on our codeplex page. WARNING: This will require a bit of SPARQL knowledge to use effectively, but basic SPARQL isn't too hard to get to grips with. There is a tutorial on the Apache Jena site that would get you started.

Thanks. Downloading Polaris now.
So I guess the trick is to specify both TypeIdentifierPrefix and manually specify an Identifier for every entity? Example:
// AssemblyInfo.cs
[assembly: TypeIdentifierPrefix("http://www.example.com/types/")]
[assembly: NamespaceDeclaration("e", "http://www.example.com/")]

[Entity]
public interface ICustomer
{
    [Identifier("e:customers/")]
    public string Id { get; }
}

There's no way to avoid having to manually provide the identifier right (unless one is happy with the default namespace)?

Currently the only way is to specify the [Identifier] property for each entity. Perhaps a future version could support other assembly level attributes for defining a global identifier prefix or a type-based identifier prefix. e.g.
// All entities get identifiers of the form http://www.example.com/{type}/{id}
[assembly: EntityIdentifierPrefix("http://www.example.com/{type}/"]

Should also consider adding parameters to the assembly attribute for specifying one or more type name conversion functions (e.g. pluralization, case conversion etc.)


Face Recognition not installing on raspberry pi 3

face_recognition version: 1.2.3, 1.3.0
Python version: 3.11
Operating System: Raspbian os, Debian based

Description
I am trying to install face-recognition on raspberry pi 3 for my project.
Error
ERROR: THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE. If you have updated the package
versions, please update the hashes. Otherwise, examine the package contents carefully; someone may have tampered with
them.
face-recognition-models>=0.3.0 from https://www.piwheels.org/simple/face-recognition-
models/face_recognition_models-0.3.0-py2.py3-none-
any.whl#sha256=8d6b0af2e37a17120c3f13107974bc252142a4ffcb4e58eabdfcf26608e52c24 (from face-recognition):
Expected sha256 8d6b0af2e37a17120c3f13107974bc252142a4ffcb4e58eabdfcf26608e52c24
Got        219620d8f433b279fc659fc8509d1a8ef919a6a8ca5f64766da035a2813ffeff
What I Did
I run the following commands
pip install --no-cache-dir face-recognition
pip install --upgrade pip setuptools
pip install cmake dlib
pip install face-recognition
git clone https://github.com/ageitgey/face_recognition.git
cd face_recognition
pip install .
$ git clone https://github.com/ageitgey/face_recognition.git --depth 1
$ cd face_recognition
$ git fetch --unshallow
$ git clone git@github.com:ageitgey/face_recognition.git
but none of them worked, library didn;t installed.

You are doomed


BUGGGGGGGGGGGGGGGGGGGG[BUG]

Acknowledgement of preliminary instructions

[X] I have read the preliminary instructions, and I am certain that my problem has not already been addressed.
[X] My answer given in the checkbox above is a lie.

What problem did you encounter?
System.UnauthorizedAccessException: Access to the path 'C:\Users\Lenovo\AppData\Local\Bloxstrap\Bloxstrap.exe' is denied.

Fix this please :(

https://github.com/pizzaboxer/bloxstrap/wiki/"Access-to-the-path-is-denied"-error-when-trying-to-reinstall-Bloxstrap


Compile to native code?

I appologize if this is a dumb question and i don't suppose it is in your agenda for kuroko's future but  is compiling kuroko to native code on your agenda cuz that will be hella freakin cool.also a seperate question: do you plan on registering kuroko on github linguists as a seperate programming language.usually registering a language requires it to have 200 or so seperate repos written in that language by seperate users.i know it hasn't garner  much attention but just wanted to know  if you had any such plans.

Kuroko is intended to be used as an embedded scripting language: it was designed to write extensions and config files for my text editor, and later as a general scripting language for my OS project. With those goals in mind, I built Kuroko to have a small footprint - it requires only a handful of libc functions, has no external dependencies, and can be built for virtually any platform. I consider these to be core aspects of the language.
Native compilation requires a code gen backend. Some languages go about this by having a "transpiler" that converts source code to another language and then uses that language's compiler to build a binary - this obviously introduces a dependency on another compiler. More mature languages would use a compiler backend like LLVM - which, again, is a large external dependency. The "do it myself" hobbyist approach is to write your own code gen, but that is a dreadfully difficult task, especially if you want any of the performance benefits that are expected from "compiling to native code".
Kuroko is a dialect of Python, and with that design comes a lot of things that are ill suited to static, native compilation. Most of that isn't so much in the syntax, but in the expectations of the runtime. Building a natively-compiled language with all the same semantics is doable (see Cython, which achieves this by compiling "pure Python" to equivalent C code that uses the CPython APIs to do what the bytecode eval loop would do anyway), but it has limited benefits on its own and it takes a lot of restrictions on the language to see real performance gains.

Would I like to see a Cython equivalent for Kuroko? I think it would be neat. Do I have the time to pursue something like that myself? Not at the moment. And, besides, if and when I do have the opportunity to work on a natively-compiled language, I would make very different design decisions than trying to emulate Python as I have with Kuroko.

Ah thanks for letting me know.i know about cython but i thought it used some bulky dlls .there is also another project called nuitka which compiles all python constructs to c and uses libpython.well anyway sorry for the silly question and thanks.


CORS issue

I'm using replicate js package in my Vue app. During prototyping I'm getting the following error message.
Access to fetch at 'https://api.replicate.com/v1/predictions' from origin 'http://localhost:8080' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

This is the code I have in my method
            const replicate = new Replicate({
                auth: process.env.VUE_APP_REPLICATE_API_TOKEN,
            });

            try {
                const output = await replicate.run(
                    "lucataco/faceswap:9a4298548422074c3f57258c5d544497314ae4112df80d116f0d2109e843d20d",
                    {
                        input: {
                            target_image: this.inputImage,
                            swap_image: this.faceImage,
                        }
                    }
                );
                console.log(output);
                this.outputImage = output

            } catch (error) {
                console.error("Error calling Replicate API:", error);
                alert("An error occurred while processing the images.");
            }

What am I missing?

Hi @mhviraf. Replicate's API doesn't support CORS, so you'll need to proxy requests from the server.

This library can't interact with Replicate's API directly from a browser. For more information about how to build a web application check out our "Build a website with Next.js" guide.


feat: add validate handler to object syntax

🔗 Linked issue

❓ Type of change

[ ] 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
[ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
[x] 👌 Enhancement (improving an existing functionality like performance)
[ ] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description
This allows inferring type of event by passing a validate function which needs to return the event (as validated). It's simple and allows any kind of validation, throwing an error if invalid input is provided.
📝 Checklist

[ ] I have linked an issue or discussion.
[ ] I have updated the documentation accordingly.

I am wondering if we can alternatively support before:[validate()] to allow multiple validate functions and avoid adding new hook.

The issue is the typing. It might be possible but will be a lot more complex, to create chainable validators. (So output of one becomes input of another.)

It makes sense for type complexity
I am thinking it could give some overhead for when we want to do body normalization, we actually read the body (and an external library can apply schema normalization). Only returning a boolean + typed Event will cause to loose this information (unless the utils support a context caching mechanism for when we later call useValidatedBody).
Also, it would be nice if we expose a generic utility async validateEvent to extract this functionality and also make it available for non object syntax usages.

Update: Both me and @danielroe need to rethink about whole typing and validation and how it works with downstream (Nitro and Nuxt) types and best type/runtime safely+perf balance which is tricky at the moment. Making it draft until after 1.8 to iterate.


Exception in thread Thread

WAF or security plugin likely in use
Exception in thread Thread-4:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 763, in run
self.__target(*self.__args, **self.__kwargs)
File "wpforce.py", line 63, in worker
PasswordAttempt(user,password,url,thread_no,verbose,debug,agent)
File "wpforce.py", line 155, in PasswordAttempt
total = len(passlist)
NameError: global name 'passlist' is not defined
Traceback (most recent call last):
File "wpforce.py", line 213, in
main()
File "wpforce.py", line 203, in main
time.sleep(0.1)

Can you post the command you ran as well?  Thanks.

Since those variables are readonly, try making their scope global.


Bundles ignored with recent jspm versions

It seems there might have been some breaking changes between jspm 0.16.19 and 0.16.20 that makes the bundler not work.
When I upgraded to jspm 0.16.20 and did a jspm update all packages where re-installed and when I rebuild my bundles after that they still seem to look the same. At least they have the same size and the config.js looks the same, which maybe isn't strange since aurelia-bundler 0.2.1 still seem to use systemjs-builder 0.14.6. But when I run my application the bundles seem to be completely ignored and it loads all files from the jspm_packages rather than the bundles.
I've since also tried to update to jspm 0.16.21 and 0.16.22, but not until I roll back to 0.16.19 the bundles start working again.
I suspect there might have been breaking changes between the SystemJS Builder 0.14.15 shipped with jspm 0.16.19 and SystemJS Builder 0.15.x shipped with more recent versions of jspm?

I can confirm that fixing JSPM to version 0.16.19 will solve the issue.

We have a new release for bundler v0.3.0. We now need to add [*.js] explicitly in the bundle config. Please install this version and let us know.

yes, with 0.3.0 after adding brackets around the .js paths in my bundle.js it seems to work fine with jspm 0.16.23 :-)


Explore hwloc for better hardware support

See this discussion for context. Basically, in it's current state, the library is limiting itself to 1 processor group with a max of 64 logical cores.

https://www.open-mpi.org/projects/hwloc/doc/v2.9.2/a00359.php#cli_examples

I think this is beyond the scope of the thread pool at this time.


MINOR: Change ForeachProcessor as Java doc deprecated not a comment

see: https://github.com/apache/kafka/pull/17129#discussion_r1752406123
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Thanks for the follow up! Merged to trunk.


curve-finance ethereum (PENDING): Protocol Error totalValueLockedUSD

Field: totalValueLockedUSD
Value: $1,481,768,160,826,862.50
Description: This field on dexAmmProtocol entity has a value below $0 or above $100,000,000,000.

https://github.com/messari/subgraphs/issues/1927


[Maps] Correct the file path for type declaration in @azure-rest/maps-search

Packages impacted by this PR

@azure-rest/maps-search

Issues associated with this PR
Describe the problem that is addressed by this PR

The type declaration file path is incorrect in the files prop in package.json, thus causing the user cannot access the file.

What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
Are there test cases added in this PR? (If not, why?)
Provide a list of related PRs (if any)
Command used to generate this PR:**(Applicable only to SDK release request PRs)
Checklists

[ ] Added impacted package name to the issue description
[ ] Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
[ ] Added a changelog (if necessary)

API change check
API changes are not detected in this pull request.


USB with web version

Hi,
has anyone got a connection between MacroDeck and server via USB with the web versión ? I have a device with IOS

It would be a good idea, since macrodeck 1 had that function and it was fast

This is technically not possible.


chore(PointerLockControls): Remove browser prefixes for "MouseEvent.movement" props

About
The browser support for these properties is stabilized for years (since 2015).
https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/movementX
https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/movementY
Checklist

[x] N/A ~Documentation updated~
[x] N/A ~Storybook entry added~
[x] Ready to be merged

Same change for the original Three.js implementation of PointerLockControls: https://github.com/mrdoob/three.js/pull/29802


luci-app-privoxy: fix description for socks5

Privoxy supports login password for socks5 proxy forwarding. It allows use proxy in format [user:pass@]socks_proxy[:port] http_parent[:port] as noted in the official documentations.

[x] This PR is not from my main or master branch :poop:, but a separate branch :white_check_mark:
[x] Each commit has a valid :black_nib: Signed-off-by<EMAIL_ADDRESS>row (via git commit --signoff)
[x] Each commit and PR title has a valid :memo: <package name>: title first line subject for packages
[ ] Incremented :up: any PKG_VERSION in the Makefile
[x] Tested on: (architecture, openwrt version, browser) :white_check_mark:
[ ] ( Preferred ) Mention: @ the original code author for feedback
[ ] ( Preferred ) Screenshot or mp4 of changes:
[ ] ( Optional ) Closes: e.g. openwrt/luci#issue-number
[ ] ( Optional ) Depends on: e.g. openwrt/packages#pr-number in sister repo
[ ] Description: (describe the changes proposed in this PR)

Screenshots

Fix #7251.


Change 8b3db5b for #13 broke semantic versioning of module

Change 8b3db5b introduced a change that broke existing code. By changing the signature of checkPassword to callback, rather than return values, ALL existing implementations using this library would have broken (including mine!)
The library should have been updated to 0.4.0, not 0.3.5!
To maintain backwards compatibility, the implementation should have returned the checked password response if the callback was not provided.

Yes, i know that. I've missed it and corrected version too late. Should i unpublish 0.3.5 from the registry? or just deprecate it?

Cool. Didn't notice you'd published 0.4. Agree that deprecating 0.3.5 seems like the correct option, although not sure what that does if anybody has non snapshotted it?
Cheers for the library btw, appreciate the effort!

non = npm (autocorrect!)

Done. Thank you for your feedback


Fission Product Model with Explicit Fission Products for all Depletable Components

Description

Update the fission product model to fix a bug where all nuclides were not being initialized in non-fuel depletable components when using the explicitFissionProducts model. Add testing for the updated implementation.

Checklist

[x] This PR has only one purpose or idea.
[x] Tests have been added/updated to verify that the new/changed code works.

[x] The code style follows good practices.
[x] The commit message(s) follow good practices.

[x] The release notes (location doc/release/0.X.rst) are up-to-date with any bug fixes or new features.
[x] The documentation is still up-to-date in the doc folder.
[x] The dependencies are still up-to-date in setup.py.

This PR had an issue on Linux, where file paths are case sensitive. I edited the files / expected paths to be upper case, as is currently defined as the default. But now there are a mix of upper and lower case file path extensions in the test files. So as not to force this PR to solve even more problems, I made an issue about it: https://github.com/terrapower/armi/issues/1078


curio capability slot order is sometimes different between client and (integrated) server

when reading curios using the curio capability (I didn't try other methods, so I don't know if it behaves the same there), in about half of the launches, the order in which the first two slots (slot 0 and slot 1) appear is different between (logical) client and (logical) server.
this causes a problem with ae2 / ae2wtlib, which uses the slot number to tell the client where to find an item to open a GUI. (https://github.com/Mari023/AE2WirelessTerminalLibrary/issues/312)
I could reproduce that issue by putting an ae2 wireless terminal in  HostileNeuralNetworks curio slot, and then using the keybinding to open the terminal.
debug crash report from the instance I used to reproduce this: https://gist.github.com/Mari023/b236e4efbc0dee4031392f64381091d6

Sorry for not getting back to you on this issue but I am quite confused about the issues as it seems the slots for a given slot type are in different order i.e. 0 -> 1 and then after relaunch, it can be 1 -> 0 which makes no sense based on how any of the Accessory API works. Frankly having a hard time reproducing any issue in production using AE2 and Accessories Slots specifically

Also, the debug report dose not seem that helpful besides giving a mod list so idk if such is intentionally the only info that can be given here.

Also, the debug report dose not seem that helpful besides giving a mod list so idk if such is intentionally the only info that can be given here.

it's use is mostly the modlist, sometimes also other system information.
lots of issue trackers require them, so I just included it by default.
I also have this log from when I triggered the bug again now, tho I don't think it is any more useful since it just shows ae2 complaining it can't find the item in the slot it expected to find it.

I am quite confused about the issues as it seems the slots for a given slot type are in different order i.e. 0 -> 1 and then after relaunch, it can be 1 -> 0 which makes no sense based on how any of the Accessory API works

It doesn't make sense to me either, but that was what I observed.
To me it makes even less sense that there is a discrepancy between the client and the integrated server at all.
It also appears normally in the UI.

I tried it a few times without Hostile Neural Networks, and couldn't reproduce it, so it seems like they are doing something weird

Might be related to this issue which the code is based on meaning this may be the actual issue: https://github.com/TheIllusiveC4/Curios/issues/363

Ill try using the update version to see if it fixes the issue

Sadly did not fix the issue as I thought it might ):


Where to specify "train text encoder"?

Noticed in original Diffusers colab there's a section saying "training text encoder has a much better result." Just wondering where should I enable text encoder training with current implementation? Thanks

+1 , does not exists in current version


Allow several tags sets

Hi !
Currently we have three dataset cards : snli, cnn_dailymail and allocine.
For each one of those datasets a set of tag is defined. The set of tags contains fields like multilinguality, task_ids, licenses etc.
For certain datasets like glue for example, there exist several configurations: sst2, mnli etc. Therefore we should define one set of tags per configuration. However the current format used for tags only supports one set of tags per dataset.
In this PR I propose a simple change in the yaml format used for tags to allow for several sets of tags.
Let me know what you think, especially @julien-c let me know if it's good for you since it's going to be parsed by moon-landing

Closing since we don't need to update the tags of those three datasets (for each one of them there is only one tag set)


REST API response status codes?

Per discussion on #2353:

... I need to comment on the 200 response codes. In the REST protocol it is only possible to return a response object if the status code is 200. If we returned, say 500 then it would not be possible to return the error message.

Is this a limitation on our side, or a difference in a standard that defines how REST API status codes differ from the HTTP protocol itself?  I can't see anything in the HTTP standard restricting message bodies (response objects?) to status code 200.  The overview of status codes (https://tools.ietf.org/html/rfc7231#section-6) explains:

"HTTP clients are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable.  However, a client MUST understand the class of any status code, as indicated by the first digit...  For example, if an unrecognized status code of 471 is received by a client, the client can assume that there was something wrong with its request and treat the response as if it had received a 400 (Bad Request) status code.  The response message will usually contain a representation that explains the status."

(Per the last sentence, a non-200 code of 471 has a response message that provides further explanation.)  Regarding a 500 response, specitically (https://tools.ietf.org/html/rfc7231#section-6.6):

"Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition.  A user agent SHOULD display any included representation to the user."

Using 200 is not breaking the protocol because it does not mean "success" as many people think - it mean there is further information in the response object.

Again, is this something specific to REST APIs vs the HTTP protocol itself?  From the standard (https://tools.ietf.org/html/rfc7231#section-6.3), it feels pretty strongly worded to me that 200 is defined as success:

"Successful 2xx: The 2xx (Successful) class of status code indicates that the client's request was successfully received, understood, and accepted.  The 200 (OK) status code indicates that the request has succeeded."

It's confusing to me that we would specify different HTTP status codes (like 500, 404, etc) on the definition of errors, but not actually use them as the response status code -- which per the standard references above seems like it should be possible? -- and I suspect will be confusing to users as well (who upon seeing a 200 response status may well simply ignore any body of the response itself)?
Suggestion:

if we can, we change our approach to make use of the HTTP status codes and record a message body in the response
if not, that we clearly document somewhere quite clearly that the 200 codes we use in responses do not necessarily mean success.

On the call we questioned whether these response bodies could also apply to DELETEs, it looks like they can (https://tools.ietf.org/html/rfc7231#section-4.3.5):

"If a DELETE method is successfully applied, the origin server SHOULD send a 202 (Accepted) status code if the action will likely succeed but has not yet been enacted, a 204 (No Content) status code if the action has been enacted and no further information is to be supplied, or a 200 (OK) status code if the action has been enacted and the response message includes a representation describing the status."

(Implying that there are response messages available in addition to the status code, even on deletes.)

(I've linked to the latest HTTP/1.1 spec above, but even going back to the very first HTTP/1.0 spec from 1992 there were response bodies possible against non-200 status codes: https://www.w3.org/Protocols/HTTP/HTRESP.html)

Happy to look into rolling this out; on the call someone mentioned that in the past we were sending non-200 responses -- any quick pointers on where / how to we were doing that?  Just looking for where to start with the response status codes (ie. where they're set / returned by the rest API itself), and in particular in a non-Spring-specific manner to remain portable (?)

It appears that the way to handle these non-200 responses in Spring is via exceptions themselves...  However, we of course don't want to make our exceptions (or exception-handling) Spring-specific, so I'm thinking of the following approach:

create a new common-services module specifically for Spring (common-services/spring-services)
inside the new module I'll define a new Spring-specific exception and exception handler (using Spring's @ControllerAdvice -- which is how I can control the HTTP status returned for any errors)
I'll also add a simple utility class & method to check any generic response objects we have for an error, and if found raise this new exception (to be handled by the exception handler) with the HTTP status code as set in the response itself

This just means the following changes to existing modules where spring resources are defined:

include this new common service module as a pom dependency
instead of directly returning the response for each resource, pass the response to the utility method that will check for any error and raise a Spring-specific exception if any is found

... and our existing exception handling and recording (outside of Spring) should remain entirely untouched.

To my mind there are 3 options:

stay as we are - i.e. continue to use 200 to convey both success or an error with a response in the body
change to only using 200 for success - and not worry about breaking compatibility - although I would generally not approve of this, I think it is a valid option given the current set of adopters
change to only using 200 for success - and worry about breaking compatibility - I think this would a) be tons of work, b) complicate the APIs and c) is not necessary given the current set of adopters

So I think it comes down to a choice between 1 and 2 - meaning that in my opinion it would be OK to change and break compatibility if we want to; and the decision is about how we want the API to look.
In defence of option 1:

Egeria is not alone - e.g. Facebook use 200 for everything (i.e. including error responses)
The status code can be considered to form part of the API or considered not to. Either is valid (see the answer from "Larry K" (located just below all the flowchart pictures) in the second ref below
The use of 200 can be considered to mean that the transport layer was successful, the error response is conveying the status of the higher layer(s) that is nothing to do with HTTP
This is known to work, even with outdated gateways that may not tolerate response bodies on responses with error codes

In defence of option 2:

This is probably more intuitive for today's programmers and API users
It is now more likely (with modern frameworks) that the client can get access to the status code (this was not always the case)

The one thing that is critical with EITHER approach is that the content of the response body needs to accurately and adequately convey the outcome of the operation including the suggested user-action in a human-intelligible form.
My current preference would be to initially talk to people in industry sectors where there may be old gateways, to assess the risk of option 2, then if the risk is deemed low, adopt option 2.
Some useful references:
On use of status codes relative to success/failure of the operation:
https://blog.restcase.com/rest-api-error-codes-101/
(Note that Facebook use 200 whatever the outcome; but the author's recommendation is counter to what Facebook do.)
Useful thread on use of HTTP status codes with regard to success/failure:
https://stackoverflow.com/questions/942951/rest-api-error-return-good-practices
(See in particular the answer from "Larry K" (located just below all the flowchart pictures)
On standardisation of error responses:
https://dzone.com/articles/rest-api-error-handling-problem-details-response
Quite interesting: RFC7807
On documentation of REST APIs:
https://www.openapis.org
Linux Foundation OAS

Hmmm...  I thought we'd discussed this on the call and agreed that we should move ahead with option (2) unless there was a standard that dictated otherwise, but maybe I over-interpreted...  As best I can tell the references linked are all opinion-based rather than a standard?
The only exception being the last one for OAS, which to me clearly advocates option 2 (http://spec.openapis.org/oas/v3.0.2#http-status-codes -- itself referring to the IETF / IANA standard):

"The HTTP Status Codes are used to indicate the status of the executed operation. The available status codes are defined by [RFC7231] and registered status codes are listed in the IANA Status Code Registry."

As mentioned earlier, response bodies have been allowed on non-200 responses since the early '90s, so we're talking ~30 years now...  So I'm certainly keen that we address your point on industry sector input where there may be old gateways, but we'd presumably be talking about gateways that are > 30 years old (?)

Actually I'm not sure I understand this point about old gateways in general -- my understanding is that for them to not support response bodies they'd need to not support (predate?) the ~30-year old HTTP/1.0 spec, so I'm not sure I follow how they'd interpret / handle HTTP at all (status codes or response bodies) (?)

All options are valid by the spec, so we are just discussing style.
I was leaning towards option 2 but given the discussions above, I have changed my mind and think option 1 is better for us.
Option 1 retains backward compatibility for our APIs,  ensures our errors will always get through and allows us to distinguish between requests that fail in the transport layer rather than in our server.  This could be really useful in complex multi-cloud environments.
The more minor point is that it is the least amount of work and we are desparately overloaded.

I was just reading through the earlier comments and completely agree we need to document our REST API style - not just the use of the status codes - but also the way we format complex request/response bodies, the handling of exceptions, structure of the URL.
Our initial decision was that the REST APIs were private to Egeria and that technology is plugged in through the connectors - or by calling the client interfaces.
However, having the REST APIs as external APIs has advantages in supporting multi-programming environments - we see this advantage in the Python Notebooks - so it is reasonable to revisit this decision.

I can appreciate that option 1 has some advantages, but I also believe some potentially significant disadvantages.
In support of option 2:

REST API Standards: while the HTTP spec itself would support either approach, I have not been able to identify any REST API standard (which admittedly are all emerging rather than as well-established as HTTP itself) that advocates option 1.  Both fellow LF project OAS (http://spec.openapis.org/oas/v3.0.2#http-status-codes) and JSON:API (https://jsonapi.org/format/#crud-updating-responses) advocate for option 2.  I am hesitant not to adopt the approach advocated by such standards that specialise in this domain more than ourselves.
Consumability: we seem to be implying that if we adopt option (2) we won't be able to distinguish between transport layer failures and internal Egeria failures, but I don't believe that's accurate.  Under option 2, since we would still place a response body against any non-200 response statuses as well, that response body can be used to determine whether the failure was at the transport-layer (response body not present) or Egeria-internal (response body present).  For me it's rather a question of priority: is it more important to a consumer to know whether the request was successful or not, or what caused a failure if there was one?  (Both options can answer both questions, but there is more work involved to answer one question vs the other depending on the option chosen.)  In other words, I wonder if those adopting APIs do not have an initial hierarchy of concerns when receiving a response along the following lines: a) did it succeed or fail, and then b) only if it failed, why did it fail?  By adopting option 1 we are forcing the API consumer to parse into every response to determine true success or failure, as that is only identified within the body of the response itself with option 1.  (This also requires consumers to understand this response format to be able to check for errors.)  I'm seeing the two options from a consumption perspective as:

Did I have a transport failure?  No, I got a 200 with a response body.  Now let me check the response body to see whether my request worked or had an error.  (Or Yes, now I fix the transport error and go back to seeing whether there is another transport failure or a response whose body I need to introspect for actual success / failure status.)  Getting to "success" always requires 2 hops: status code check, then response body parsing.  Understanding failure could require either 1 hop (status code alone, which could be transport or framework (Spring itself could return such codes still in certain conditions)), or 2 hops (status code is OK, but response body has an error inside it).
Did my request work?  Yes, I got a 2xx response.  (Or No, I got a non-2xx response: now let me look into the response body to see why it failed.)  Getting to "success" always requires only 1 hop: the status code.  Understanding failure always requires 2 hops: non-2xx response, parse the response body (if any).

Ease-of-interpretation: Popular libraries seem to adopt the overall success vs failure check of (ii), so in the multi-programming environments we want to support it may be the simpler / quicker option for consumers?  For example Python's requests library (3rd most-downloaded library in PyPI with 13M downloads / week) provides a raise_for_status() method that automatically raises errors for unsuccessful responses based on the response code (https://2.python-requests.org/en/master/user/quickstart/#response-status-codes).  Furthermore, it automatically interprets the success of a response as a boolean based on the response code (between 200 and 400 as success, and anything else as a failure (https://realpython.com/python-requests/#status-codes)).  That is, they can programmatically check this without needing to first understand our response body format (find our documentation, read it, understand it, etc) to parse it for a potential error.
Adoption: I've also quickly surveyed different metadata APIs for their own approaches.  I think it would be helpful to follow a similar pattern as the rest of the community with which we want to integrate.  I have not been able to identify any that follow option 1.  All of the following take the approach of option 2:

WKC (uses 4xx and 5xx responses, as do the Watson Data APIs in general)
IGC (uses 201 as well as 200 for success, and 4xx responses to indicate improper request bodies)
Apache Atlas (uses 4xx responses to indicate improper request bodies)
CKAN (uses 4xx and 5xx responses)
Lyft's Amundsen (uses 5xx responses)
WeWork's Marquez (uses 201 as well as 200 for success, and appears that it would use 4xx and 5xx responses as while not formally documented the code uses javax.ws.rs, extends its built-in exceptions (that do generate such codes) and throws them from the API resources under certain conditions)

I can appreciate that some codes (like 404) may seem particularly confusing in this server-internal vs transport-layer error debate between option 1 and option 2.  However, I also see that even for a 404 response, given that our REST resource URLs for things like getEntity actually have the GUID in the URL itself, that it's debatable whether this is a valid URL or not in the same way that mis-spelling some other portion of the URL would be invalid (and validly result in a 404) -- from the perspective of a URL that does not exist, both seem equally relevant to me.
However, IMHO it would be better to take such debatable codes as an exception we explicitly handle rather than as a reason to entirely discard option 2: eg. perhaps under option 2 we instead opt not to use 404's at all, so for endpoints like getEntity we simply return a 200 status with a null or empty response object (rather than any error body).  (For me it's debatable whether it's even an error that someone has requested an entity instance that we have not stored in our repository, for example, or whether we should simply report that the request succeeded but we have no such entity in our repository.)
Equally, I feel that other codes are quite clear-cut: a 500 Internal Server Error to me is a clear indication that something unexpected has gone wrong in our processing, within the server (and not at the transport level).  And per my book above (😉), would be a very clear communication that does not require me to understand the response body format to understand that the server did not succeed in processing my request.

My thoughts

I think in practical terms our REST APIs are public - I don't think we've been clear enough to say they are private for consumers... as per references to notebook
I am inclined to consider the proposal is good, as it does make the API a little clearer IMO - @cmgrote your last post & research is superb.
However it does break backward compatibility, and we've made efforts to stress we would aim not to do this. We perhaps are in the stage where we could still just about make this change if managed carefully

One option (though it could be deemed procrastination?) is to post a proposal to make this change very clearly on our public list/chat & gather feedback over a release cycle. Perhaps linking in this with clarification over the status ( -> public? ) of the rest api

Good discussion and I agree with pretty much everything that has been said, including the point that this is about more than just implementation of a rigid specification - it depends on how one applies the specifications in terms of mapping to architectural concepts (e.g. layers) and both specs/standards and precedent/opinion are important.
On both fronts I am still of the opinion that our APIs would be better if we were to implement option 2.
Reading Nigel's comment above I realise I should clarify my earlier definition of "option 2" in which I said "not worry about breaking compatibility". What I meant is that we should not attempt to preserve backward compatibility - e.g. by API versioning or introducing a dual API - those would be the activities of option 3 (which I am not in favour of). If we were to adopt option 2 I think we need to be very public about the proposed change and provide [at least] a release of warning. My thoughts were that we might propose the change with 1.4 and implement it in 1.5 (subject to approval by the wider community) - together with comprehensive documentation.

Yes, I think we’d have to have this release-long request for review on option 2 as per the 1.1 release notes I would consider (at least some of) the APIs to be “released functionality”: https://github.com/odpi/egeria/blob/master/release-notes/release-notes-1-1.md

Closing as I believe this is now decided for OMRS, and permitted for OMASes.


Fix magic number check

This PR fixes a number of issues in the MagicNumber check:

flagging non-numeric constant expressions (e.g., true, null)
inability to ignore floating point values correctly (due to casting to long)
incorrect hex number parsing in some cases
silently ignores invalid ignoredNumbers configuration parameters
ignores negative values when the corresponding positive number is
ignored (e.g., -2 is ignored when 2 is in ignoredNumbers)
floating point numbers are not correctly parsed in some cases
numeric literals that contain underscores are not correctly parsed

I noticed these issues because I got false positives all over the place in my codebase as soon as I updated. Unfortunately the tests for the rule in this case were omitting any false positive and any edge case, so that the rule seemed formally valid but was actually severely bugged. I would recommend double checking the test suite for new rules before shipping them in the future.
To be fair, the test suite is still not optimal, but at least captures all the bugs I identified so far. There can/will be more bugs, possibly, but this seems a good starting point. It's not Checkstyle's omonimous check, and the tests are not nearly as exhaustive, but better than it was.
On top of that there are a couple of minor tweaks to make the testing of the class easier (not that Spek ever worked for me in the IDE... but at least from the command line it does), removes an unused Gradle property, adds missing spaces in the MagicNumber check description, and renames the ignoreNumbers config setting to ignoredNumbers.
The rule still doesn't parse binary numbers because it was originally not, but that could be a separate PR if required.

Thank you for your work! I've also found a false positive: int and double etc properties shouldn't be flagged as magic number as they have a meaningful name.
And yes your right we need to double check new rules. As a bunch of new rules get contributed every month I can't check them all out locally, I do not have the time for it. My proposal is to let new rules PR open for at least 2 days so others can also have a look at them and let new rules be deactivate for two version.

That sounds like a reasonable policy. I know you already run Detekt against itself when cutting releases, but I think doing it against a couple more projects when adding new rules,  and quickly glance at the results, could be useful. I noticed the issues immediately after upgrading when running against my side project, and I generally keep up to date with Detekt reasonably closely because this sort of issues is sort of expected in such a young static analysis tool, and I hope for fixes :)


Warning: Suppressed stale connector activation [object Object]

I get this warning in the console when trying to connect to metamask in my react (next.js) app using activateBrowserWallet indirectly. The way I'm doing this is via a custom hook I made which provides me with a function which calls activateBrowserWallet in the background but which also keeps track of the current state of the connection. While this is only a warning the account prop returned by the useEthers hook doesn't seem to be updated without directly refreshing the page despite metamask being connected to the page.
My current work-around is directly using await window.ethereum.request({ method: 'eth_requestAccounts' }) and then immediately after calling activateBrowserWallet(). Let me know if you have any ideas on fixes or additional information you'd like me to provide.

I've got the same issue, while the warning doesn't bother me, it's a bit annoying having to refresh the webpage in order for account to be non-null after calling activateBrowserWallet.

I'm also encountering this.

I have tried to reproduce on current version of useDApp - 1.1.5.
I tried to do something like:
<DAppProvider config={config}>
    <IndirectActivator />
    <App />
</DAppProvider>,

function App () {
  // Main page, that displays the `account` from `useEthers`
}

function IndirectActivator () {
  const { activateBrowserWallet } = useEthers()

  // Activate browser wallet indirectly in a different component than the main one.
  useEffect(() => {
    setTimeout(() => {
      activateBrowserWallet()
    }, 2000)
  }, [])
}

It seems like account is non-null without refreshing the page.
@Philogy @georgeroman @josh-richardson Do you have any more pointers on reproducing this? Or maybe the issue is resolved in a recent version?


It dosen't support RTL

@MAAlsaleh0 Fixed in this PR https://github.com/aheze/SwipeActions/pull/27


Web interface doesn't show button background images

v4.12.5 (possibly all?) - On linux and MacOs. Button background images are not show in web interface of virtual console. Looking through web page html, there is no sign of background-image tag. Is this by design or is there a problem?
If it is not been implemented, please point me towards the supporting code and I'll be happy to look into implementation.
There is no info in web api to address background-image.

Closing, as reported here:
https://www.qlcplus.org/forum/viewtopic.php?f=34&t=15789

@mcallegari I'm happy to work on this. I'm just jumping in and will have to work back to some end which will take a long time. I've had a look through the code and I imagine webaccess and ui are the places to look but not sure where xmlProject is loaded as it points to res->body which I don't quite follow as it seems self referencing to me not knowing the code.
If this is something you have already resolved in a later developer release, I'd be interested in it. Otherwise, again, I'm happy to work on a resolution.

See if this is what you expect:
https://github.com/mcallegari/qlcplus/commit/a97abd449f3e3a9d22973640f394743323108740


Child component validation breaks in transition group

Versions:

VueJs: latest
Vee-Validate: latest

Description:
Using the inject: ['$validator'] method in the child component, validation fails when the child is part of a transition group.
Steps To Reproduce:
Whenever I include child components like this:
            <transition-group name="list-complete" tag="ul">
                <li v-for="item in items" :key="item.id" class="list-complete-item">
                    <date-input></date-input>
                </li>
            </transition-group>

Validation does not occur. Removing the transition group tag works as expected.

Take a look at #891 which has a workaround

Thanks, I'll be sure to actually check the closed issues next time.

Its fine, I will try to implement an enhancement for it though.


 This only happens when UNIQUE_LOGS is active.
Sorry for my bad english, i learning by myself ;)

UNIQUE_LOGS doesn't have any restriction. If the message doesn't appear in the Gameserver N°2, it's because it's not receiving any message about it, as simple as that.


omnibus: Gemfile: use 'ref' instead of 'branch'

'ref' supports a branch name, but also accepts a commit sha1, which will improve our ability to pin a specific version at a specific point in time

What does this PR do?

Motivation

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

Reviewer's Checklist

[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] Changed code has automated tests for its functionality.
[ ] Adequate QA/testing plan information is provided if the qa/skip-qa label is not applied.
[ ] At least one team/.. label has been applied, indicating the team(s) that should QA this change.
[ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
[ ] If applicable, the need-change/operator and need-change/helm labels have been applied.
[ ] If applicable, the k8s/<min-version> label, indicating the lowest Kubernetes version compatible with this feature.
[ ] If applicable, the config template has been updated.

/merge


Update from Adam/Igor about CF UI-less

@alison-mk we should check that this is only for desktop and not available online as well

Docs Build status updates of commit b9e1542:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/excel/custom-functions-debugging.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

@mscharlock Can this PR be merged?

Docs Build status updates of commit cb7e0b4:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/excel/custom-functions-debugging.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Enhancement: Grunt command added for fetching logs.

Fixes issue: https://github.com/odk-x/tool-suite-X/issues/186
What changes have been made?

An additional grunt command has been added for pulling logs from the device.
The output logs directory has been set to 'output/logging'.
It follows the same implementation as 'adbpull-csv'.

@linl33
Kindly review this..


[FEATURES] Fluid support non-host network mode

What feature you'd like to add:
Why is this feature needed:

How about adding this feature in 0.7.0?


extension is not installing

Issue Type: Bug
I'm trying to install various extensions from the visual studio code but the screen always get stuck on the "installing" and not moving ahead from this steps
VS Code version: Code 1.35.1 (c7d83e57cd18f18026a8162d042843bda1bcf21f, 2019-06-12T14:30:02.622Z)
OS version: Windows_NT x64 10.0.17134

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz (4 x 2712)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: enabledsurface_synchronization: enabled_onvideo_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
7.88GB (4.30GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (1)

Extension
Author (truncated)
Version

python
ms-
2019.6.22090

Can you please provide us the logs from following
F1 -> View: Open View -> Log (Shared)
You can see the extension installation activity here. Please provide us this log to know what's happening


Add support for detecting block overshooting the offset

Hi there,
thanks for this project, really helps,
I was in need to detect when the target overshoots the offset
so I added the proposed change
it also adds the ability to have the scrollactive-items in any order which was not the case before I believe
let me know what you think and if you can have a look
I tried to build your examples but got an error relating to sass-loader
ERROR in ./examples/src/main.scss
Module parse failed: /Users/thomasmery/Documents/WebDev/Clients/C&I/cominst.com/v2/application/web/app/themes/cominst/node_modules/vue-scrollactive/examples/src/main.scss Unexpected character '@' (1:0)
You may need an appropriate loader to handle this file type.
| @import "normalize";
|
| .nav.is-fixed {
 @ multi ./examples/src/main.js ./examples/src/main.scss

maybe you know how to fix this so I can test with your examples

I'm closing this since it's been quite a while it's been opened and now I have time to maintain my libraries. I'm not sure if this is still an issue as many changes have happened since then, if so feel free to open an issue and I'll be happy to help :)
Thanks for the support!


Documenting the fact that overrideAttr doesn't work on recursive sets

This was not documented and caused me to waste hours on it.
Also, giving an alternative solution, like this PR does, doesn't hurt.

I'd say +1 for this note, but I have another example, which doesn't invoke creating custom attributes.
If you do .overrideAttrs (old: { version = "x.x.x"; }) it won't trigger an error, but also won't change package version, name and sources. You have to override both name and src to make it work (in most cases, but not all).
So, it's not something specific to "recursive sets", even let-binded variables used in mkDerivation will behave same.

What is the status of this pull request?

Closing due to lack of activity, feel free to reopen this if needed.


Access to remote Jupyter Tree

Feature: Notebook Editor, Interactive Window, Python Editor cells

Description
Hi,
I recently tried Microsoft's new Jupyter Notebook support, particularly using it to access a remote Jupyter server. What bothers me is that there is no ability to access or modify the remote tree. If I go to the remote Jupyter url, I can access the entire tree and make edits to it. I am wondering if it is possible to integrate VScode with the remote tree such that one can edit the remote tree through Vscode?
Thanks

This is supported in VS code with the remote-ssh work. You essentially open the remote server in VS code:
https://code.visualstudio.com/docs/remote/ssh

Yes, but once I open a remote directory through the remote-ssh extension, I no longer get the new Jupyter support for my notebooks. I can use this to edit regular remote python files, but not edit remote .ipynb and their cells.

Is the python extension installed on the remote server? I thought it did it automatically but you might need to install it.

As long as the extension is there, it should open the notebook files the same way it does locally

Okay, I figured out what the problem was. It turns out that a remote server is using the configs in ~/.vscode-server but not ~/.vscode, so although I installed the python extension on my local Linux vscode in ~/.vscode, it didn't exist in ~/.vscode-server. Maybe the remote configuration should detect if local extensions exist and symlink to them?

Maybe the remote configuration should detect if local extensions exist and symlink to them?

Feel free to log a suggestion on VS code here:
https://github.com/microsoft/vscode-remote-release/issues

Logged a suggestion at https://github.com/microsoft/vscode-remote-release/issues/1652. Thanks a ton for the help with remote Jupyter and SSH.


GTK: Clear amount field on click

It is annoying to have to clear the Amount field everytime I add a new expense/income.
When editing text input fields, it is common in Gtk to select the whole input on click and use a placeholder in the new transaction case.
Also, could you remove the currency name from the input field? I think it makes more sense to put somewhere else

👍

Also, could you remove the currency name from the input field? I think it makes more sense to put somewhere else

Any suggestions on where else to put it?

Hey, good to know you agree :)
WRT the currency name, I think you can make so it is there, but it is not editable/selectable. I think there are widgets in Adw that do this, but if not, I found this stackoverflow answer to be very insightful: link

I think you can make so it is there, but it is not editable/selectable.

But it's not editable in the latest stable. Don't you use 2022.11.x by chance?

But it's not editable in the latest stable. Don't you use 2022.11.x by chance?

@Diegovsky ^
This is what it looks like in the current stable:

Oh yeah, I am most likely in an older version. I apologize for that, please ignore what I said about the currency name :)

The new 2023.1.0 stable should be available in flathub
OR
If you are using arch/manjaro there is a new AUR package: denaro please remove the old nickvision-money package

just got the new version from flathub, although I'm on arch :)

Adw.EntryRow does not have placeholder text but I will make it so that anytime you active the entry, it will select all of the text

Looks like it's not a good design to implement this feature :/

It's not a Gtk.Entry, but an Adw.EntryRow which doesn't have a placeholder

That is a bummer, hopefully future versions of libadwaita will have this


Use a vector instead of an array for holding cost types

Both cost_tracker and cost_models have their lengths set to the size of the xdr enum at compile time because they're arrays. but the actual number of cost types depend on the protocol. Because of this, core needs to resize the array when we're on v20 but using a v21 supported build. This is not ideal. The host should just expect the right number of cost types for the protocol instead.

This is the section in core that is affected by this issue.


Backend part of working sets

I see that you have a support for working sets in the roadmap on the next year.
This proposal creates a "backend" part for the working sets:

It creates workingSets.json file in .vscode folders in roots of mounted folder
It allows defining included folders in these files
It allows to switch active working set using a setting in workspace

Design decisions:

The working sets have overlapping scopes, i.e. you can activate the working set with the same name, and it will work in several mounted folders. This is done by design, since often, working sets span several repositories.
I didn't use anything complicated as include patterns, since I want to have a simple UI, ideally, checkbox tree to choose what's available.

Next steps:

If it gets accepted, I will create a UI for it. It can be implemented as an extension, or as a part of the main process (which is preferable, since there're more UI features there).

Please, let me know what you think about this.

@kieferrm What do you think in general about this approach? I see that you have this item on the roadmap. Did you have any discussions about it? Can you delegate this parts of it to external contributors? What about other items?

Thank you very much for this PR. However I would first like to understand how this would look in the UI, before we actually look at any implementations.
As far as I see this is the only issue that we have open which resembles working sets https://github.com/microsoft/vscode/issues/9498
Please let me know if you are aware of other feature requests which would be solved with this.
So I would first bring this up in our weekly UX meeting, and after that we can continue the discussion. I will also see how Eclipse did this, please let me know if there are other solutions which you think are good.
Hope that makes sense.
fyi @bpasero

@isidorn The approach I have taken is inspired by Nuclide working sets. You can take a look at how they look like here: https://nuclide.io/docs/features/working-sets/
There're two ways to implement them:

In vscode core. The good thing is that it will be much easier to have a checkbox tree.
In extension. There're no checkbox trees, but it's possible to more or less emulate one with change in the checkbox icon.

@isidorn  Concerning the roadmap:
https://github.com/microsoft/vscode/wiki/Roadmap
Improve VS Code performance in large workspaces
- Investigate 'working sets' of files and folders in the file explorer
- Provide guidance to users how to configure VS Code
- Improve Open File / Quick Pick performance

@solomatov Thanks again for this PR and thank you for the Nuclide working sets pointer.
I have presented this in our weekly UX meeting and we concluded this is best done by an extension by:

Contributing a new Working Sets view to the explorer. This Working Sets view would have all the functionality for managing Working Sets - renaming, seting which one is active, delating etc..
Contributing a "Add to Working Set" action in the Explorer - which can be multi selection aware so it is easier for the users to create Working Sets from the Explorer

Changes needed on the vscode Explorer side:

Explorer would need to have a new configuration from which files in the explorer would get filtered. Something like a duplication of files.exclude. This is what you have already done in this PR. However I would prefer if Explorer has no notion of Working Sets, so I would call this setting differenetly
Explorer needs to show opened editor even if it is hidden via some setting. This makes sense overall and we can tackle it as a seperate PR

Also the extension would depending on the active working set make sure that the value of this new setting is correct.
Some other related feature requests https://github.com/microsoft/vscode/issues/41274 https://github.com/microsoft/vscode/issues/10962 https://github.com/microsoft/vscode/issues/41860
Even though #9498 is similar to this, it is not exactly the same and that one could also be done by extensions if we tackled this https://github.com/microsoft/vscode/issues/15178
@solomatov let me know what you think and we can discuss in more details if needed.

Some additional insights after discussing with @bpasero

This new setting should not be exclusive but inclusive (specifying what is shown). Similar request https://github.com/Microsoft/vscode/issues/869 So it could be called files.includesas this comment points out
The downside of the extension always writing the setting based on the active set - the setting would always get dirty. We can think about this problem a bit later - idealy we would need to have workspace settings outside of a workspace https://github.com/Microsoft/vscode/issues/40233 This we plan to tackle in the future, however it is not on the current plan as @sandy081 points out

As @bpasero suggest we could introduce a new service that would be aware of what files are visible and what not - respecting the files.include and files.exclude and the open editor.
So that seems like a great first step for this. Introducing the setting files.include and introducing the service for this. After we have this we can think more about how the extension would change this setting dynamically based on the active working set.

To add on top: currently files.exclude is being used and respected in these locations:

Explorer
Search results
Breadcrumbs picker
Quick open
Problems

I think I would expect working sets to have an influence in the same areas as well. Thus I was suggesting a new service that anyone can ask if a resource should be included or not.
Having both files.exclude and files.include will result in potential conflicts if both patterns match. We probably need to define some rules which pattern wins (e.g. by looking at the pattern length).

@bpasero  @isidorn thanks for all the pointers!
I'm working with @solomatov on this area. Please let me know if the below covers your comments:

Adding the new service to see what is included or not.
Make it respect/read files.include and files.exclude.
Replace all files.exclude usage with this new service.
Decide what happens in case of conflicts (both patterns match), who would win?

My thoughts here, people use include to define what they want to see in the file tree, and exclude to exclude patterns that don't matter here (within that tree), so our logic should follow the same (includes.match(path) && !excludes.match(path)). Please let me know if you think otherwise.

Have the setting be updated by an external "working sets" extension. The extension would keep its knowledge of sets private, along with functionality to update/delete/create them.

for now, the plan is to use vscode.WorkspaceConfiguration.update(_, _, true) to update that setting (globally).

@isidorn
So, to confirm some parts of the plan:

Do not create a working-set.json file, and use files.include, and files.exclude instead via a dedicated service
The extension will read its settings, generate derived settings with includes and excludes, and use these settings to guide the service, controlling what's visible and what's not. Do we need a new API for these or can we store it just in some of the configuration files? I have seen some proposal to expose internal memory only settings, will we need this to do this work? Will you be open to a PR to expose them in the API?

@bpasero

Concerning search results, it's a bit tricky. User might want to find references everywhere, but show the ones from the working set, and the rest in a different way. I agree that in the rest of the items, files should be excluded.

cc @OmarTawfik

Decide what happens in case of conflicts (both patterns match), who would win?

I think going by (includes.match(path) && !excludes.match(path)) is probably a good start and we can see if there are any issues.

Concerning search results, it's a bit tricky.

Yeah we may have go decide this on a case by case basis. One option would be to still show the search results from outside the working set in a different bucket, collapsed by default.

@OmarTawfik @solomatov great recap, that was exactly our thinking.

Search already has a checkbox if it should respect the files.exclude setting (picture attached). That way a user can easily switch if he wants to search the whole workspace or not. @bpasero showing results collapsed would still make some searches very slow on large workspaces.  By default this checkbox is turned on, which I think makes sense to avoid long running searches.
Changing the logic of how include and exclude align should be easy once we have the service. (includes.match(path) && !excludes.match(path)) is the only thing that makes sense to me atm
@solomatov as @OmarTawfik pointed out you can use vscode.WorkspaceConfiguration.update to update the setting. The downside is that you will always make the settings file dirty. As for the PR to tackle https://github.com/microsoft/vscode/issues/40233 @sandy081 would be best to answer if he would be willing to accept a PR

Thanks a lot and let me know if you have more questions.

@bpasero @isidorn thanks for all the suggestions! it certainly makes things more straightforward, but would present the following issues with using files.include:

different windows to the same workspace: in that case, they would all read/edit the same setting, thus updating in one window would override the other.
user is allowed to edit that setting: in that case, this will invalidate their active working sets, without having the mental connection between both, which will be a negative UX.

Any thoughts on that?

different windows to the same workspace

I think we would need to support a way to configure this setting for the workspace from outside the workspace. Since we do not allow the same workspace to be opened in multiple windows, a user could make changes to both windows without impacting each other.

user is allowed to edit that setting

That is probably OK as long as the extension is storing the working set definition somewhere. E.g. couldn't the extension store an array of all working sets and switching between them is simply replacing the files.include value? If the user makes changes to files.include it would not impact those working set definitions?

Re PR to tackle #40233, I am happy to accept it. Since it touches API and UX this needs to be discussed in respective calls which can be worked out together.

@OmarTawfik regarding point 2) just to add on top of what @bpasero said. The working set extension should also remember the initial value of the files.include so when there is no longer a working set active the intial files.include value is restored (which the user manualy set). If the user manually changed the files.include while a working set is active yes that would lead to incosistent UI, but I think we can live with that as that sounds like a corner case imho.

@isidorn I have concerns about storing files.include in the settings.json:
a) It's often committed and we don't want it to be put into settings.json
b) A user can change it, and close settings.json. In this case, it will be hard to bring it back, and that's what we want to avoid
One solution to a) is to have #40233. Another one which I like the most is exposing in-memory settings. If we will workspace folder specific in memory settings, it will solve the problem, i.e. we will just load the settings from there. There's a usability problem of what to do while the extension is being activated, but we can cache the old value in the local storage or in other temporary storage available to the VS Code.
What do you think?
cc @OmarTawfik

@sandy081 So what are our next steps for this? I think, the simplest way to add these settings is to set an attribute on a setting scheme whether it's user specific or project specific. In this way, we can keep the same UX for settings as we have now.
cc @OmarTawfik

@solomatov I agree that storing it in settings.json is not a good long term solution. However we can still start with other things and temporarliy put it in storage.json before we look into this issue.
As for #40233 we do want this in VSCode and should be doable.
As for next steps, @sandy081 would be best to answer this, however I do know that this milestone he is focued on other tasks and he planned to add that item to his plan next milestone. And yes having another ConfigurationTarget is something we also thought makes sense.

Just for reference as an example: an Explorer Exclude extension found by @egamma
There is a bit of common ground between this extension and what the Working Sets extension would do
https://marketplace.visualstudio.com/items?itemName=RedVanWorkshop.explorer-exclude-vscode-extension

I think the in-memory solution mentioned here would work well for our case. Without it:

User changes to that setting would corrupt our view of the world.
This would corrupt the case where the user has multiple windows, where changing the active working set would update the other window.

There is an internal support for storing in memory configuration. But this is not supported in the API. But your scenario is a good use case to expose this.

cc @sandy081 I want to take a stab at this, maybe exposing ConfigurationTarget.InMemory? would you be open at accepting a PR? any pointers would be appreciated.

Next steps are to discuss the design and implementation for #40233 or #43226. I would suggest to discuss them in the corresponding issue and open a PR. I cannot assure that I can look at this in this milestone as we have other plans already. But we can discuss the design and implementation.

@sandy081  I'll follow up on #43226, since it aligns to our goals! thanks for the pointer.
The current milestone is not an issue, since I can work on my fork, and we can review/make sure it aligns with your project plans, and merge it whenever needed.
What I want to avoid is to design a solution that is not going to get merged into master at some point, and would require us to revert/conflict with any future updates.

@OmarTawfik after discussion with @sandy081 please note that https://github.com/microsoft/vscode/issues/43226 is not requested by that many users and that it has more open questions than #40233
We always try to find the solution that would work for multiple scenarios and to me it seems like https://github.com/microsoft/vscode/issues/40233 is the way to go here since it is more general.
Thanks for offering to do a PR however to avoid designing a solution that will not get merged I would advise that you wait some time until we internally decide on the best way to tackle this.
As for your concerns for #40233:

User changing would corrupt your view: your extension can react on configuration changes
VS Code does not support opening multiple windows on the same workspace, or did I misunderstand something here? Can you explain this multi window scenario better? Thanks

@isidorn thanks for taking a look.
Problem with #40233

User changing would corrupt your view: your extension can react on configuration changes

Yes, but that would still corrupt the view of the world. If the user has chosen to display (for example) two working sets, each covering two folders (total of 4), and then they go and modify that setting locally to remove one (now only three remain). What would the extension do in that case?
The best it can do currently is to just warn the user along the lines of (settings manually edited, overwrite needed) and then error out. With #43226, this problem goes away

VS Code does not support opening multiple windows on the same workspace, or did I misunderstand something here? Can you explain this multi window scenario better? Thanks

Not the same workspace, but two folders in the same repo. The main use case is a large repo with hundreds of projects. Since settings would be updated for both when one is updated, #40233 would not work for us here.
Current progress with this issue
I almost implemented the files.include setting, but ran into a blocker (possibly related to #85193). When checking the globs in that setting in the explorer to see if we should view it or not, we cannot use TreeVisibility.Recurse to check children of a folder.
For example, consider structure:
File1.txt
src/
   File2.txt

And with the setting:
{
  "files.include": {
    "src/**": true,
  }
}

In the following filter, if we get src folder, we cannot determine if we should show it or not based on the glob alone, since it might contain files that should get matched:
https://github.com/microsoft/vscode/blob/980d8ef1371b14e80162d88e88f45e15f8632070/src/vs/workbench/contrib/files/browser/views/explorerViewer.ts#L507-L521
So, returning TreeVisibility.Recurse is not supported for async trees:
https://github.com/microsoft/vscode/blob/980d8ef1371b14e80162d88e88f45e15f8632070/src/vs/base/browser/ui/tree/asyncDataTree.ts#L1231
Thinking about it, it would be expensive to enumerate every child recursively to see if anything matches or not. One possible solution to this is to not use globs, but use explicit folder names only, like folderA, folderA/folderB, or folderA/folderB/file1.txt, but no *.

PROs: let us perform this efficiently, but just splitting paths and checking explicitly for names. No glob parsing/regex execution would be necessary.
CONs: this deviates from files.exclude and might cause minor user confusion.

Any thoughts on this?

@OmarTawfik Are you assuming that in memory settings are not editable by user? I do not see the reason to restrict this to user from settings perspective. Also how are you expecting user see these in memory settings values?

Great idea, will be following this closely. I have made an image of what I think working sets could look like when implemented:

Working sets could be accessible via an icon on the activity bar

Sorry for not commenting here sooner, I was busy with other feature areas - mostly accessibility.
I will definetely have time for reviewing and testing files.include PR in the March / April milestone.
And for Local Workspace Settings I just discussed with @sandy081 and he has this feature on the plan for the next couple of milestones.
So let us know what you think would be the best next steps for you.
Thank you
isidor


Weight (cannot read)

 Issue by AndyFrnk
Thursday Mar 14, 2019 at 09:48 GMT
Originally opened as https://github.com/googlesamples/android-fit/pull/47

Tried to implement weight, but cannot get information on the weight

AndyFrnk included the following code: https://github.com/googlesamples/android-fit/pull/47/commits

 Comment by googlebot
Thursday Mar 14, 2019 at 09:48 GMT

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
:memo: Please visit https://cla.developers.google.com/ to sign.
Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

What to do if you already signed the CLA
Individual signers

It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ Googlers: Go here for more info.


Flash the start bar icon in IE9 when you have unread messages

I want to know when there are unread messages more clearly than just the count in the title bar. IE9 has an API to support flashing the start bar icon from JS, and in other browsers you could possibly even "shake" the window my moving it around via JS (crazy I know :).

Pull request?

Do the new notification options make this obsolete? Also, this API requires the site to be pinned: http://msdn.microsoft.com/en-us/library/gg131029(v=vs.85).aspx#causing-taskbar-button-to-flash


Selecting a dropdown choice in a profile should select that profile

In

if I interact with the dropdown 'image' under the second profile, it should automatically select the profile. Currently, it doesn't and i have to manually select it as well

Haa, this is a bit of a tricky UI one, and makes me wonder if using Radio buttons is actually the correct UI for this.
Currently, on the kubespawner interface, we do something a bit ugly to get the desired behaviour -- i.e. that if a user clicks on a profile option "anywhere", including selecting a drop-down, it also selects that profile option. We wrap the entire element in the label for the input type=radio: https://github.com/jupyterhub/kubespawner/blob/main/kubespawner/templates/form.html#L5
I think I would definitely like to not do that here. This will likely be something like an onClick handler on the entire profile option to select it if it is unselected, or something like that.
Longer term, I think we should consider the UI around this and see if there's something better than these radio buttons.
@oliverroick I think if we can discuss this and if it doesn't seem too complicated, I'd be happy to take it on.


Add Python library dependencies for VK and Tumblr

Use requirements.txt to specify dependencies.

pip install vk
pip intstall pytumblr
looks like it

Seems right. Though requirements.txt should be added using pull request.

Looks fine enough but it should be merged into the whole requirements.txt file. This can be achieved by installing all your requirements (vk and pytumblr) into your virtualenv through pip install and then calling pip freeze > requirements.txt.


Update License

I am pretty sure the outright copyright for @hexorx might violate the data we pull from various sources.   We might want to look a revising this.

Didn't look at the license file, only looked at the readme. OOOPS


Namadillo: MASP fully rescanned after a Shielding Transfer

After doing a Shielding Transfer (transparent -> shielded), if you go to the MASP page shielded-sync starts over from block 0. That currently takes about 2 minutes and makes the browser slow. Namadillo should just sync from the last known block instead.

This should be resolved by https://github.com/anoma/namada-interface/pull/1433


Archiving files linked to cloud service or network drives in emails

Is your feature request related to a problem? Please describe.
Providing links to files is increasingly becoming a common practice, partly due to the size restrictions on attachments imposed by email clients. However, the current version of Mailbagit does not archive these linked files, leading to archived emails that are incomplete as archival records.
Describe the solution you'd like
Files linked from cloud services or network storage ought to be archived and stored locally. Additionally, there should be a reference to link these files back to their corresponding email messages.
Describe alternatives you've considered
Archive-IT asserts that there are no known problems with archiving Google Docs and Sheets. Yet, there have been cases where archived Google spreadsheets show error messages along with their content. Currently, there's no solution to this Wayback replay issue, but the content of these crawls can still be collected and preserved as improvements are underway. Browsertrix Crawler/Cloud, on the other hand, has not been successful in archiving Google Docs. Moreover, neither AIT nor Browsertrix Crawler offers email archiving integration. This is where Mailbagit stands out, providing the exclusive capability to archive both emails and web content, thus offering a solution without compare.
Additional context
Add any other context or screenshots about the feature request here.

Add archive SharePoint files.


How to parse filter applied to a layer?

I applied a specific filter and effect to a layer, attached test image below.

I could parse effect information, for example, Stroke effect but not sure how to get filter information.
What apis are for parsing filters?

Filter info is likely in low-level tagged_blocks structure. Check tagged_blocks attr.

@kyamagu Thanks for your kind answer.
I checked the tagged_blocks but look like there are not filter information in tagged_blocks.
I think that filter information are not stored in the PSD file.
Let's say we apply a filter to layer, save it, and close Photoshop.
If we reopen that file, we cannot revert it to the original image.
That is just my idea and what do you think about this?

Filter info is likely in low-level tagged_blocks structure. Check tagged_blocks attr.

Filter info is likely in low-level tagged_blocks structure. Check tagged_blocks attr.

@kyamagu Thanks for your kind answer.
I checked the tagged_blocks but look like there are not filter information in tagged_blocks.
I think that filter information is not stored in the PSD file.
Let's say we apply a filter to layer, save it, and close Photoshop.
If we reopen that file, we cannot revert it to the original image.
This is just my idea and what do you think about this?

@proactive-developer That is probably true, only irreversible filtered pixels are stored in each layer. To get irreversible filter effects, you should use smart filters. That info should be stored in layer's tagged blocks.


npm support please

I see that you have included support for bower but as many developers are moving away from using it (as it's unnecessary and basically redundant) including this within the npm registry would be beneficial.
See this old post: https://gofore.com/stop-using-bower/
Even if you just include a compatible package.json without submitting to npm we could install via git url.

Agreed, we need package.json as well.  Feel free to submit a pull request if you'd like.

Thanks again @theDustRoom for the package.json update.. and for the article on bower.


AjaxFileUpload MaxFileSize Accessibility

The AJAX Control Toolkit \20.1.0>
The installation method

[ ] Installer
[x] NuGet package
[ ] A custom build from the source code

A site deployment method

[ ] VS development web-server,
[x] IIS

I do not see any way to access the client property of MaxFileSize of the AjaxFileUpload.
https://github.com/DevExpress/AjaxControlToolkit/wiki/AjaxFileUpload
As result the file upload can appear to succeed, but not report back a failed upload (due to excessive size) to the user.

Hello
Refer to the maxFileSize wiki section.

An attempt to upload a file of an excessive size should display a message box:

See also:

https://ajaxcontroltoolkit.devexpress.com/AjaxFileUpload/AjaxFileUpload.aspx
https://github.com/DevExpress/AjaxControlToolkit/tree/master/AjaxControlToolkit.SampleSite/AjaxFileUpload

Thank you very much. What could be a reason for this property not being accessible? From my nuget install I don't see it in visual studio, nor is it accessible in the devtools console, while it clearly is seen in your example.

If you can share a sample project that illustrates the lack of this API, I can look into it and hopefully find what's wrong.


oreilly.com learning path

Checklist

[x ] I'm reporting a site feature request
[x ] I've verified that I'm running youtube-dl version 2019.09.01
[x ] I've searched the bugtracker for similar site feature requests including closed ones

Description

please add this url in oreilly site script
https://www.oreilly.com/learning-paths/
this is the course url
https://www.oreilly.com/learning-paths/learning-path-sql/9781492058090/9781492058212-video326308
and what i check i think rest video lecture setting is same with other script setting
Remember filename saved in youtubedl folder is Safari.py
thanks

@remitamine  will you refer me duplicate of this topic ?

look for Safari(Safari Books Online) issues.


⚠ Bofrost.at has degraded performance

In d13227f, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1350 ms

Resolved: Bofrost.at performance has improved in 5ff02f6.


Add temporary files to gitignore

Description
Changes proposed in this pull request:

add generated files to gitignore

Related issue(s)

/unhold


How I can remove the default style attributes of the element video?

The element video has by default style width: 100% , height: 100% and display: block and I want to remove the width because that is overriding the style defined by me.
I searched but I think that is not configurable or it is? If not, there is a clean way (or not) of removing that?

The video element has a width of 100% in order to fill the wrapper element, the size of which is defined by the height and width props.
Manually overriding the video element width should not be necessary if you just use ReactPlayer's width prop and let video fill the wrapper.
If you really want to override the video style attribute, you could do this:
<ReactPlayer
  url='file.mp4'
  fileConfig={{ style: { height: '100%', width: '720px' } }}
/>

I really need because the video gonna be fullscreen and the style only work applied to the video element and that was overriding. But yeah for a "normal" use it is ok and i understand why it is on that way.
Thanks a lot and good job with this lib.

And by the way I was trying now and I founded you miss to involving the style object with attributes.
{ attributes: { style: { height: '100%', width: '720px' } } }

And by the way I was trying now and I founded you miss to involving the style object with attributes.

My bad! Example updated.


Add BlobId class to identify a storage object

This PR follows from the discussion in #62 and adds a BlobId class used to identify a storage object (by bucket and name). This PR also changes other classes accordingly, most notably:

add storage.get(BlobId blob, BlobSourceOption... options)
add storage.get(BlobId blob)
add storage.delete(BlobId blob, BlobSourceOption... options)
add storage.readAllBytes(BlobId blob, BlobSourceOption... options)
add storage.reader(BlobId blob, BlobSourceOption... options)
refactor CopyRequest to take BlobId as source
refactor BatchRequest to take BlobId for get/delete
change batch get to get(BlobId... blobIds)
change batch delete to delete(BlobId... blobIds)

I would also consider (and want your opinion on) adding the following methods:

create(BlobId blobId, InputStream content)
create(BlobId blobId, byte[] content)
create(BlobId blobId)
writer(BlobId blobId)
signUrl(BlobId blobId, ...)

Fixed all comments and opened itssues for the ones that need to be fixed elsewhere.


Site Update for 2024

AWS Community site update for year 2024

fix code Conflict to i can marge pull request


how to make a new theme ?

I want to know how to define a new theme through API.
I saw a definetheme API that defines the theme, but I don't know the definition rules.
monaco-editor version: 0.13.1

Here are the built-in themes
https://github.com/Microsoft/vscode/blob/master/src/vs/editor/standalone/common/themes.ts#L13

@alexandrudima thank's

@mengdu You can use https://bitwiser.in/monaco-themes/ to generate theme for monaco from tmTheme files.

that's so good. @brijeshb42


Upgrade Issues to 2.4 Thread

Hi all,
I've noticed some upgrade issues there are similar caching issues as with the 2.2 upgrade
UI library was updated and seems this requires clearing the browser cache. If that does not solve your issue a reinstall of the addon should do the trick.
Sorry for the inconvenience.

That's actually a good idea. I Will add this in a future version to save the settings in OneDrive so that they can be fetched on re install

After the update, I'm not connecting to onedrive. It's just showing as initialising. It reconnected with the code ok (eventually). Is this related or something else?

Store the backup settings locally would be nice I wouldn't like to upload the password for the backups to the cloud storage

If the addon is removed where would the local copy be stored ?
It's a valid point about the password but it's probably still useful to backup the settings to the cloud omitting the password, which can be entered again post settings restore.


repo marked as unmaintained

Hi,
I am wondering why this project is currently marked as unmaintained? I have found this very useful and it would be a shame to see it go and have to use NgRx for redux boiler plaiting for future releases of angular,
Best wishes,
This is a...

[ ] feature request
[ ] bug report
[ x] usage question

What toolchain are you using for transpilation/bundling?

[ ] @angular/cli
[ ] Custom @ngTools/webpack
[ ] Raw ngc
[ ] SystemJS
[ ] Rollup
[ ] Other

Environment
NodeJS Version:
Typescript Version:
Angular Version:
@angular-redux/store version:
@angular/cli version: (if applicable)
OS:
Link to repo showing the issus
(optional, but helps a lot)
Expected Behaviour:
Actual Behaviour:
Stack Trace/Error Message:
Additional Notes:
(optional)

https://github.com/angular-redux/platform/issues/114#issuecomment-612922598


transformer: differentiate import {} from "a"; and import from "a";

Our AST differentiates import {} from "a"; and import from "a";
Failing babel test cases like imports/elide-no-import-specifiers/input.ts
Added failing test cases: https://github.com/oxc-project/oxc/pull/3735/files#diff-0a1b8e143f74590ed69ad0ad7abfcf2add6d7e6a9c3daff2bbb132b71e0f3f14

I tried this for 30 minutes but couldn't figure out 🙃

Do we want to distinguish them? Is there any semantic difference?
TypeScript seems to treat them differently: TS Playground

Do we want to distinguish them?

yes

Is there any semantic difference?

no


[patch] update dependency versions

update NGT version to 1.7.2
Signed-off-by: kpango<EMAIL_ADDRESS>

Codecov Report

Merging #12 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #12   +/-   ##
=======================================
  Coverage   68.31%   68.31%
=======================================
  Files           1        1
  Lines         385      385
=======================================
  Hits          263      263
  Misses         89       89
  Partials       33       33

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2f725a1...362d69c. Read the comment docs.


fix(symbolwinbar): Extra space on non-icon buffer

Also, the current winbar behavior is not very good
If vim.wo.winbar = nil then it will not remove the extra one line. However vim.wo.winbar = "" does... Upstream bug?
https://user-images.githubusercontent.com/56817415/177960834-8f1efa04-cb42-4dc7-b179-5fff209687ec.mp4
in_custom manage to overcome this because I pattern matching every buffer
https://user-images.githubusercontent.com/56817415/177961447-5c8a2106-57df-4712-b3b6-4facdac0c218.mp4

:h winbar you can't set it to nil. default is empty

hmm works fine with me ?

@glepnir https://github.com/neovim/neovim/issues/18660 upstream issue

I think it should be work like statusline/tabline.

Sure, I think it's a preference
Either way, I provided a way to disable it if they want in this pull request. Please review

Thanks @glepnir
I saw you joined the neovim core, wish you luck for the foreseeable :)
Taking a break from the internet for a while, thanks for merging these silly pull requests!

oh I had joined for a while . now i public my organizations team information. so you saw it :)
There are some code not very readable in example . I had edit it . a reusable table should not be defined inside a function. Memory allocation is unscientific

@nullchilly  hi did you found symbol winbar very slow in lua file today?

@glepnir It's faster actually lol


⚠ Bofrost.de has degraded performance

In 6e51106, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 770 ms

Resolved: Bofrost.de performance has improved in 834df6b after 6 minutes.


Unable to activate both CF Actuators and Endpoints together

Describe the bug
Package steeltoe.management.endpointweb.2.4.0-rc1
Trying to enable actuators for an ASP.NET full framework application using ActuatorConfigurator as below. The problem is that when I set the context to ActuatorContext.Actuator I am able to hit the endpoints, say /actuator/health, but since I need the Cf Actuators to be enabled for AppsMan, I set the context to ActuatorContext.ActuatorAndCloudFoundry where I can see the actuators enabled in AppsMan, but I am getting 401 UnAuthorized when trying to access the endpoints say /actuator/health or /actuator/info
ActuatorConfigurator.UseCloudFoundryActuators(configuration,
                                                            dynamicLoggerProvider,
                                                            MediaTypeVersion.V1,
                                                            ActuatorContext.ActuatorAndCloudFoundry,
                                                            GetHealthContributors(),
                                                            GlobalConfiguration.Configuration.Services.GetApiExplorer(),
                                                            loggerFactory);

Expected behavior
When context is set to ActuatorContext.ActuatorAndCloudFoundry, we should be able to hit the endpoints, together with AppsMan actuators.
Environment (please complete the following information):

Platform: PCF
OS: Windows
.NET Framework 4.6.2
Steeltoe Version 2.4.0-rc1

@hananiel At this point, do we need to enable /info and /health endpoints explicitly via configuration or they exposed by default. Any samples are welcome. Thanks!

@alfusinigoj  health and info should be exposed by default. Here is a sample:  https://github.com/SteeltoeOSS/Samples/blob/master/Management/src/AspDotNetCore/CloudFoundry/Startup.cs

@hananiel the sample still uses steeltoe 2.4.0-rc1 which has this issue, i will test and let you know. thanks!

@alfusinigoj , can you please provide me a sample where you have got the actuator work. I'm still not able to get it working

@VenkateshSrini here is a working sample https://github.com/alfusinigoj/pivotal_aspnet_bootstrap_cloudfoundry_extensions/tree/master/samples/Actuators/ActuatorSample

Thanks alfus it  worked


Make it easy to edit class definitions programmatically

https://user-images.githubusercontent.com/249595/227705372-52a1413a-dd6b-4d6e-a617-19333411d2bc.mp4