Make IsSubdomainOf variadic

Pull request checklist:

[x] CHANGELOG.md was updated, if applicable

Description

Make IsSubdomainOf variadic
Add variadic tests


Use jekyll-archives to show all posts (sorted by date)

[x] This is a question about using the theme.
[ ] I believe this to be a bug with the theme --- not Jekyll, GitHub Pages or one of the bundled plugins.
[ ] This is a feature request.
[x] I have updated all gems with bundle update.
[x] I have tested locally with bundle exec jekyll build.

Environment informations

Minimal Mistakes version: 3.2.6
github-pages or jekyll gem version: 3.1.6
Operating system: ubuntu

Expected behavior

/archive should show a list of posts regardless of category, sorted by date (but not limited by year).  At the least I need to know how to create a master page that links to each of the category/date pages.  My layout-fu is very weak.
Steps to reproduce the behavior

Include jekyll-archives
Activate it in _config.yml
Serve the existing pages

https://github.com/synedra/minimal-mistakes

Just a FYI. You don't need Jekyll archives to show all posts. That gem is used to generate individual archive pages for each category or tag. It has nothing to do with building a page that lists all categories or tags.
If you just want a page that lists every post in reverse chron remove archive.html in the root, rename _pages/archive.md to _pages/archive.html and replace the content with this.
---
layout: archive
permalink: /archive/
author_profile: true
---

{% include base_path %}

{% for post in site.posts %}
  {% include archive-single.html %}
{% endfor %}

Which will give you a page at /archive/ that lists every one of your posts.

I noticed quite a few duplicate pages floating around that might cause you trouble down the road. If you have pages in _pages don't place ones with the same name/permalink in the root. They go in one or the other or else they will just overwrite each other.
Also if you hope to use Jekyll Archives you were missing a few configurations. The gem needs to be added to Gemfile with gem "jekyll-archives" and then bundle install. As well as adding it under gems in your _config.yml along with uncommenting the Jekyll Archives settings and replacing liquid with jekyll-archives.
Refer to the docs for the full set of instructions.
For help with installing Jekyll Archives check their docs.

I'm going to assume you got this working. If that's not the case feel free to re-open the issue.


Bump version to 1.3

Getting the latest version out, please let me know if I've misrepresented or forgotten anyone or anything :-)
Thanks a bunch to the pivotal crew!
@stubbornella @gpleiss @pmeskers @bebepeng @a5e @cih @mandest
cc @aflanagan

Also, I just made a super simple PR to address #191. Don't know if you'd be willing to squeeze it in now - it could also wait till the next release.

I merged it in so it should go in 1.3 :+1:

Awesome!!!

--
Geoffrey Pleiss
(408) 338-8247


controllers

Milestone #2 - Implementation of Controllers and updateroutes
In this branch, we work on Controllers, the details of the work are as follows:

Created the Appointments and Roles Controller in the Controller/api/v1 directory

Implement the CRUD actions

Update Routes
Enabling tokens for data manipulation

Security of the API

@skyv26 Thank you for the review


Add working links to homepage (and change some copy)

Getting started with Projects -> https://help.rasterfoundry.com/creating-projects
Help -> Documentation
Raster Foundry guide -> Help Center -> https://help.rasterfoundry.com/
Getting started -> nix
Raster Foundry API Documentation -> API Documentation -> https://docs.rasterfoundry.com/
Getting started with Tools -> https://help.rasterfoundry.com/working-with-tools
Into the API -> Developer Resources -> https://help.rasterfoundry.com/developer-resources

Hi, assign me on this

Hey @fragm3 thanks for offering to do this--not sure we have a process in place yet to accept outside contributions. We need to create a Contributor License Agreement first! Sorry.


expose route settings for showModalBottomSheet

Description
Extends the functionality of the showModalBottomSheet function to allow user to assign the routeSettings: RouteSettings attribute.
To use:
showModalBottomSheet<void>(
      context: scaffoldKey.currentContext,
      routeSettings: RouteSettings(name: 'popup_route_name'),
      builder: (BuildContext context) {
        return Container(
          child: const Text('BottomSheet'),
        );
     },
 );

Related Issues
#60639
Tests
I added the following tests: Verify that route settings is passed during navigation to verify that the route settings is passed to the route and is consequently retrieved on the page opened as the modal bottom sheet.
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I signed the CLA.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I updated/added relevant documentation (doc comments with ///).
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Did any tests fail when you ran them? Please read Handling breaking changes.

[x] No, no existing tests failed, so this is not a breaking change.
[ ] Yes, this is a breaking change. If not, delete the remainder of this section.

[ ] I wrote a design doc: https://flutter.dev/go/template Replace this with a link to your design doc's short link
[ ] I got input from the developer relations team, specifically from: Replace with the names of who gave advice
[ ] I wrote a migration guide: https://flutter.dev/go/breaking-changes-template Replace this with a link to a pull request that adds the migration guide to https://flutter.dev/docs/release/breaking-changes

@googlebot I fixed it.

I think you need to revert the format changes.

Oh, @AndroidNils, how do I do that?

I think this the easiest way:

Copy your changes
Discard all changes (copy & paste the files from GitHub)
Paste your changes
Commit & Push

Some information about formatting PR: https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#formatting
You can add in your PR description also Closes #60639. With this line the PR will automatically close the ticket.

Thanks @AndroidNils. Will do just that

Fixed the formatting issues. Thanks @AndroidNils

Nit: I meant that you just paste "Closes" in "Related Issue", like Closes #60639 instead of #60639 :D

@chunhtai, I appended the review modifications.

The analyzer suggest there are still extra white space, you can test it locally by running
flutter update-packages
flutter analyze --flutter-repo

The CLA start failing because you includes my email in your commit, you will need to squash all the commit and makes sure only yours is in the commit history

@googlebot I fixed it.

@chunhtai I've updated the CLA. Also, I no longer have analyzer issues locally but the analyze_linux check still fails for some reason relating to url launcher. Found a related but closed issue in #60637

@thedejifab you may need to rebase off the master branch again.

@chunhtai rebasing solved the issue 😃


Allow positioning of IEDs

We should add the IED positioning feature from @openenergytools/scl-editor to this, because two instances of the SLD designer don't play well with one another.

Currently the IED positioning  uses an extension namespace within the IED element which is not well respected by the ICTs.

Siemens DIGSI 5 or IEC 61850 Configurator removes the namespaced information.
It causes difficulty opening files in GE Enervista UR setup because it removes the namespace.

I believe it will work much better with Siemens equipment if it is within a <Private> element and probably won't be scrubbed during a round-trip.

As part of implementing this feature, it would be helpful that when moving a container (bay, voltage level) the IEDs that are enclosed also move.
See https://github.com/OpenEnergyTools/scl-communication-editor/issues/28

Finally, it would be helpful if rather than an entire status bar with each IED as we currently have in the OpenEnergyTools designer prototype (shown below) we had a single item which when clicked displays a menu of IED names perhaps with manufacturer and type in brackets and ideally a search field for larger substations.

The IED button should only be visible once there is a substation element created, unlike the present prototype:

Additionally, most likely on removal of a substation element or a containing element, the coordinates of the IEDs should be deleted.

I'd like to have a go at doing some of these things as some of the above are a blocking issue for the use of the communication-editor.

I've done some more work extending on what Jakob begun on the linked PR (testing welcome)

We have a right-click menu for the IED and have imported scl-lib to allow deleting IEDs from the SLD. It's nice to be able to open a wizard and rename or otherwise change the IED name (although we need and scl-wizarding release to fix a recently resolved issue with the IED wizard).

We can toggle IEDs and have a single menu button which drops down to show a list of IEDs (sorted by what is already placed)

We can move IEDs with bays or voltage levels

However discussing with @ca-d I'd like to discuss our requirements on the positioning of the IED.
At the moment we are doing the following to store coordinates:
<IED xmlns="http://www.iec.ch/61850/2003/SCL" name="Kind_of_an_IED" manufacturer="Dummy" esld:x="24" esld:y="2" esld:lx="25" esld:ly="3" esld:substation="S1">

I've augmented Jakob's original work to add a "substation" attribute to handle multi-substation SCD files.
The downside of this approach is:

Directly namespaced attributes on the IED may be dropped by other tools in compatibility with the standard. DIGSI 5 9.7 does this at the moment. Also this causes issues with GE Enervista UR Setup (to be fair we've previously identified issues with namespacing handling in the version we are using which off the top of my head I think might be 8.51). The up-shot is that opening an SCD file in these tools either means loss of coordinates or a complaint about the namespace.
It is not really in accordance to the standard or the standard's top-down engineering approach to do this (allowed but not really in-line with the engineering approach).

If we were to continue with this approach in a way other tools would respect we would, as a minimum need to wrap the coordinates in at least a Private element:
<IED xmlns="http://www.iec.ch/61850/2003/SCL" name="Kind_of_an_IED" manufacturer="Dummy">
<Private type="OpenSCD-Coordinates" esld:x="24" esld:y="2" esld:lx="25" esld:ly="3" esld:substation="S1"/>

This should mean that the coordinates would be retained in the files sent to the IEDs and preserved in round-trip operations between ICTs and this plugin and was the approach I was intending to follow.
However:

Everything else in the designer follows the hierarchial semantics of the Substation section.
Detecting if IEDs are within Bays or VoltageLevels requires us to iterate over all IEDs to see if they are contained within the VoltageLevel for placing (moving, initial placement, shifting between substations etc.) which may not scale performatively in large files.
It doesn't further the goals of top-down engineering even if it works adequately.

Perhaps a better approach would be to use an LNode in the substation to represent the IED and its coordinates:

We could continue with using namespaced and attributes in the same way we do now, except we wouldn't need the "substation" attribute (as we'd know which substation we were in).
It would follow the VoltageLevel and Bay hierarchy and be more performant.
It would be much less likely to cause issues with ICTs and the round-trip would likely work with all our manufacturers.

The difficult question is, "Which LNode should be used?". Can we have a "sentinel' or "representative" LNode which can be taken to be a proxy for the IED?
I would like to use LPHD for this at first blush. We would then have something like this:
<LNode iedName="Kind_of_an_IED" ldInst="Application" prefix="" lnClass="LPHD" lnInst="0" esld:x="24" esld:y="2" esld:lx="25" esld:ly="3"/>

I note that (at least in our files) the 6MU85 has more than one LPHD, so do SEL devices and so does NR Electric.
SIPROTEC 5 devices

SEL devices

GE and NR Electric devices

In the case of the 6MU85 it makes good sense to me because the additional LPHD represents the physical communications module.
In the other devices it makes considerably less sense to my mind.
However there is not an obvious way to say which of these LPHDs are representative of the whole device.
Obviously once we are virtualising many IEDs in one device this whole strategy wouldn't be great but it might be "good enough" for now.
We do need to have just one identifiable "thing" to represent the IED because for the purposes of placing the IEDs we don't want to see the same IED in multiple places (for multiple LNodes).
Before I can implement this I would like to get some feedback on some questions below.
Questions

Would it be adequate to take the first LPHD in the file? Yes
Would the user need to select the LPHD on placement (which is a little annoying I think)? Probably OK not to for our present use case which is seeing the IED location on the SLD and representing within the communication editor
Is there another LN which we could use instead as a proxy? Perhaps the first LLN0 but probably this is not better
Is there such a thing as a device without an LPHD? I think the standard's answer is there must be at least one from Part 7-1:

These questions do all open up the broader question of showing LNodes on the SLD (and how this might work within IEDs, as well as the broader questions of showing Functions and SubFunctions etc. but I think we need to grow this organically by use case so I'd like to start small).

Wow, a lot has happened here! I'll take some time to look through this great work!

I think I must redo much of it once we agree where/how to store
coordinates, so perhaps in a week or so I'd be very pleased for some
examination.
On Sun, 22 Sep 2024, 14:46 cad, @.***> wrote:

Wow, a lot has happened here! I'll take some time to look through this
great work!
—
Reply to this email directly, view it on GitHub
https://github.com/OMICRONEnergy/oscd-designer/issues/92#issuecomment-2365428989,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFEXX6YMXCZN4KLSFHTNFLZXYVPZAVCNFSM6AAAAABMSZ5WT2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRVGQZDQOJYHE
.
You are receiving this because you commented.Message ID:
@.***>

We do need to have just one identifiable "thing" to represent the IED because for the purposes of placing the IEDs we don't want to see the same IED in multiple places (for multiple LNodes).

The best LN to use would be the LLN0 of the root logical device (one that does not have a LLN0.GrRef DO instantiated) as per IEC 61850-7-1 edition 2.1:

The issue might be that not all IEDs follow this convention, but most of them do these days.
Maybe the first logical device LLN0 where GrRef is not defined is one way of getting the "representative" LN.

On second thought, how about the LPHD LN which is not a proxy (LPHD.Proxy=false) and not LLN0.GrRef? The main issue with this one is that there could be more than one non-proxy LPHD within an IED (there shouldn't if the standard is followed, but some vendors do...). But checking for LLN0.GrRef should take care of that.

Also a few comments here

Thanks @jarradraumati. I quite like the idea of using the LPHD in the root logical device since that is almost exactly what we are trying to represent here.
That's been present since at least Edition 2.0 but I don't find it in IEC 61850-7-1 Ed 1.0. However we could fallback to the first LPHD which is not a proxy in the absence of the root logical device I guess.
However I'm interested in whether this would cause a conflict with some other specification activity.

Whether we use LNodes or not if we want to have Text elements with an IED we will still need to wrap them in a Private so with this in mind I am somewhat less fussy about our three options since this will mean Option 1 and Option 2 can re-use this logic a bit.

Option 1 - Private within IED element
Option 2 - Private within Substation element or children
Option 3 - LNode within Substation element or children

After thinking about this for a bit longer, I like Option 3 the best, especially @jarradraumati 's suggestion of the non-proxy LPHD.
@danyill : Do you still think it may be useful to have one and the same IED appear in several places in the SLD, or do you think this might be more confusing that helpful? If several places could be useful, what do you think about showing individual LNodes in the SLD rather than full IEDs?

So after our discussion, I'm planning to proceed on option 2 as I think it will perform significantly better than option 1 and be more consistent with the treatment of other Substation elements. At least I'll do a bit more prototyping and seek feedback.

https://github.com/OpenEnergyTools/oscd-designer/pull/2 implements this however after some discussion today with @ca-d the downside is that an IEDName element can be invalidated by a change in a tool outside OpenSCD. I'm comfortable with that for now.
I've implemented some logic today to ensure that if a wizard opened from within the designer plugin edits the IED that the IEDName will be correctly updated.


verify_signature might need a network flag

If I am not mistaken we have the same issue with verify_signature than with recover_key.
We should also have a flag in order to specify the network when matching the recovered address from the signature and address extracted from the tx.
    // Compare recovered public key with the public key from the transaction
    if tx_from != from.to_string() {
        return Ok(false);
    }

This is discussible as verification is different from recovery.
In recovery, the caller, given a private key want to retrieve a properly formatted address for network X. So the network parameter is required.
In verify, the situation is different. Given that filecoin does not contain a chainid in the transaction ( this is by design as discussed in this issue https://github.com/filecoin-project/lotus/issues/1138#issuecomment-577735251)
While the json input indicates the network (f or t), this information is not really part of the transaction (when CBOR encoded) but some additional information that is only available the formatting of the address.
We could run a check by looking at the first characted in the address (f or t).. but I am not 100% sure about this.
@eshon any feedback?

Ah yes. My bad I forgot that we were taking a cbor format of the transaction. I just focused on the comparison we were doing.

@jleni - Can you just verify without the network id and just use f or t for now?


Dev

Commits up to this merge are largely just housekeeping.
Now the repo should no longer be marked as 94% makefile.

I can't believe the repo managed by one person has a pr made by that one person and was reviewed by that one person smh my head


fix ArrayHelper::merge

Q
A

Is bugfix?
✔

New feature?
❌

Breaks BC?
❌

Tests pass?
-

Fixed issues
-

Merged. Thanks!


Bug: The Glyphery, Deep Pit: Occasional audio cut-out

Reported by DannySpillerVA. Voice lines in The Glyphery may cut out, as demonstrated in Danny's clip: https://clips.twitch.tv/YummyScrumptiousGoshawkKappaRoss-WL2vy09wsxR-k9Kw
The song in Deep Pit may also cut out, as seen in another of Danny's streams.
This is related to a long-standing bug in GK development where sounds and music would cut out, which was tracked down to a bug in the Unity engine. Since the Unity bug can't be fixed, GK features a workaround in several places which restarts audio which has cut out. This workaround needs to be applied to The Glyphery, which features special logic for playing voices in its soundscape audio, and to Deep Pit's song controller.

Fixed in v1.1.


[SPARK-17850][Core]Add a flag to ignore corrupt files (branch 1.6)

What changes were proposed in this pull request?
This is the patch for 1.6. It only adds Spark conf spark.files.ignoreCorruptFiles because SQL just uses HadoopRDD directly in 1.6. spark.files.ignoreCorruptFiles is true by default.
How was this patch tested?
The added test.

Test build #66853 has started for PR 15454 at commit 3715203.

Test build #66853 has finished for PR 15454 at commit 3715203.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/66853/
Test PASSed.

Since I have not yet heard complaints about this for 1.6, and this one may break some user's job, I'm going to close it now.


Option to override GitHub release name

My mod supports Fabric, Forge, and NeoForge. Each loader is shipped in a different jar, meaning 3 different releases for both Modrinth and CurseForge.
However, on GitHub, the release is only one with all three jars.
My naming standard for Modrinth and CurseForge is "[${loader} - ${minecraft_version}] ${mod_title} v${mod_version}", but on GitHub I'd like the release name to be the same as the tag name.
Is there any way to do this?

So if I understand you correctly, you want the display name of the release, to be the same as the tag name?
So if the tag is 1.3.0, the display name should be 1.3.0 and not "[${loader} - ${minecraft_version}] ${mod_title} v${mod_version}"?

Yeah, but only on GitHub.
For example, running the publishing task correctly generated 3 releases on Modrinth and CurseForge with that naming scheme, but on GitHub it generated a single release (correct), with all 3 jars for the different mod loaders (correct), under the tag v1.3.0 (correct), but named [Forge - 1.20.4] Mod Title 1.3.0 (wrong, I'd like it to be v1.3.0, same as the tag name, here on GitHub).

That makes sense.
Okay we don't currently have a way to do this, but it's something that can be added fairly easily. I'll add it tonight after work

Thank you very much!
Maybe if you add a new github option, you could simply let the user specify a custom name for the release:
github {
  // other options
  tag = "v${project.version}"
  name = "v${project.version}" // I'd say this could already default to the tag name if not specified, but maybe it'd be best to default to the display name to not break it for people relying on the current behavior?
}

Thank you again, for you quick replies too!

Yeah we have a whole new config system planned for 3.0.0
Basically you will be able to either use the "global" configuration, or, a dedicated block to override stuff, like you mentioned above

Great, thanks a lot!

Hey sorry. My night turned out a little different than planned.
Looking over everything, I see Matt already started adding a dedicated GitHub section, so I'm just going to add one there like this:
setGitHubDisplayName()

That should do the job for now until we have a proper implementation

Don't worry, thanks a lot!
I'll wait for the release with this change!

It's been added.
So under github, you can use displayName("Value")
Like:
github {
      displayName("Hello World")
}

It's available in version 2.1.3

Thank you for the quick fix!


DCOS-13710 [preparation]: Fix the code that prettier can't process

Currently prettier can't prettify pieces of code where return statements have comments in it.
return (
  // Comment
  someLogic !== here
);

So I decided to fix those as a separate PR so that these changes could be tested separately.

Can one of the admins verify this patch?

@MatApple fixed!

Ping @orlandohohmeier @jfurrow 🙇

Thanks for the suggestion @jfurrow! Addressed all comments, please give it another shot
@MatApple @orlandohohmeier

I think that we should reduce the complexity of our shouldComponentUpdate methods as there way to many conditions but that is a different issue and not part of this PR. Great job! 💯 🥇

LGMT @nLight! I'll hold off on merging until @MatApple has had a chance to review the changes.

@MatApple can we get an approval?

I rebased this as it's following PR had conflicts and I am resolving those

Run integration tests!

run unit tests


Support gRPC transactions

Not so long ago, Cosmos migrated from Rest API to gRPC, in this regard, the format of transactions for sending through the cosmos.tx.v1beta1.Service/BroadcastTx service has changed.
This kind of transaction cannot currently be signed via the ledger-app.
Do you plan to support gRPC transactions in ledger-app?
Thank you in advance.

Could you provide more information / context ?
REST/gRPC are protocols that are related to completely other layers.
Ledger apps receive a small tx blob and work along USB/Bluetooth. There is no network endpoint in this layer.

@buuni Are you working with https://github.com/cosmos/cosmjs to facilitate signing?

Closing as this it not part of the scope of a Ledger app


Bug in platform generation "platform": "Win32"

Describe the bug
When generating profiles the platform always generates "platform": "Win32" and it does not match the UA
To Reproduce
Simply generate a profile and look at the platform
Expected behavior
The most logical thing would be for it to coincide with the UA or failing that, some more common 64-bit platform these days
System information:

OS: Debian 12
Node.js version 18.13.0

Additional context
This is a profile generated from several, in which you can see: "platform": "Win32"
{
  "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36",
  "webdriver": false,
  "language": "en-US",
  "colorDepth": 24,
  "deviceMemory": "not available",
  "hardwareConcurrency": 4,
  "screenResolution": [
    1920,
    1080
  ],
  "availableScreenResolution": [
    1920,
    1040
  ],
  "timezoneOffset": 0,
  "timezone": "UTC",
  "sessionStorage": true,
  "localStorage": true,
  "indexedDb": true,
  "addBehavior": false,
  "openDatabase": true,
  "cpuClass": "not available",
  "platform": "Win32",
  "plugins": [
    [
      "PDF Viewer",
      "Portable Document Format",
      [
        [
          "application/pdf",
          "pdf"
        ],
        [
          "text/pdf",
          "pdf"
        ]
      ]
    ],
    [
      "Chrome PDF Viewer",
      "Portable Document Format",
      [
        [
          "application/pdf",
          "pdf"
        ],
        [
          "text/pdf",
          "pdf"
        ]
      ]
    ],
    [
      "Chromium PDF Viewer",
      "Portable Document Format",
      [
        [
          "application/pdf",
          "pdf"
        ],
        [
          "text/pdf",
          "pdf"
        ]
      ]
    ],
    [
      "Microsoft Edge PDF Viewer",
      "Portable Document Format",
      [
        [
          "application/pdf",
          "pdf"
        ],
        [
          "text/pdf",
          "pdf"
        ]
      ]
    ],
    [
      "WebKit built-in PDF",
      "Portable Document Format",
      [
        [
          "application/pdf",
          "pdf"
        ],
        [
          "text/pdf",
          "pdf"
        ]
      ]
    ]
  ],
  "webglVendorAndRenderer": "Google Inc. (Intel)~ANGLE (Intel, Intel(R) HD Graphics 4600 Direct3D11 vs_5_0 ps_5_0, D3D11)",
  "hasLiedLanguages": false,
  "hasLiedResolution": false,
  "hasLiedOs": false,
  "hasLiedBrowser": false,
  "touchSupport": [
    0,
    false,
    false
  ],
  "fonts": [
    "Arial",
    "Courier",
    "Courier New",
    "Helvetica",
    "Times",
    "Times New Roman"
  ],
  "audio": "124.04347527516074"
}

Hey @mrfussion,
Win32 is actually the correct platform name for Windows 10/11 x64 systems. If you have a Windows system you can verify this by running navigator.platform in your browser's console. This behavior is mentioned on MDN.

@cIoves Thank you very much for responding, I have some problems passing creepjs and the platform seemed the most suspicious to me. I am taken aback.
My apologies for wasting your time.

Did u modify the library?
Because, i couldn't find "audio" property on library.


Add 'types' in package.json 'exports'

I would like to support the resolvePackageJsonExports option in tsconfig

I applied this change as a patch to my code. Thank you!

@rot1024 can you check this PR please


a "publish" script to force push the "built" react app to the fs-webd…

…ev/fresh-cra-template repo

I'm going to merge this in to see where if any issues are. (I expect github push permissions to be a potential problem)


Voice Over Generator

Writes scripts and makes instant voice overs.
https://chat.openai.com/g/g-R4H9Al3sl-voice-over-generator
Made a pull request. Thanks for the resource 🙏

Closing as the PR is merged.


⚠ PrivateHD has degraded performance

In bb1557d, PrivateHD ($PHD) experienced degraded performance:

HTTP code: 200
Response time: 3996 ms

Resolved: PrivateHD performance has improved in 65644e7.


Webpack + Renderers problem

Hi, thanks again for an awesome plugin! I saw that you guys render the highway files like this..
		this.H = new Highway.Core({
			renderers: {
				'home': () => import('../renderers/home'),
				'page': () => import('../renderers/page'),
				'default': DefaultRenderer
			},
			transitions: {
				default: DefaultTransition
			}
		})

And It's working fine, but when I now run my webpack, I've got some new files in my dist map,  I've got files like this
0.bundle.js
1.bundle.js
2.bundle.js
3.bundle.js
4.bundle.js
My webpack file
'use strict';

const path = require('path')
const webpack = require("webpack")
const MiniCssExtractPlugin = require("mini-css-extract-plugin")
const UglifyJsPlugin = require('uglifyjs-webpack-plugin')
const OptimizeCSSAssetsPlugin = require("optimize-css-assets-webpack-plugin")
const SvgStore = require('webpack-svgstore-plugin')

module.exports = {
  context: path.resolve(__dirname, "src"),
  entry: {
    app: './js/app.js'
  },
  output: {
    filename: '[name].bundle.js',
    chunkFilename: '[name].bundle.js'
  },
  optimization: {
    minimizer: [
      new UglifyJsPlugin({
        sourceMap: true
      }),
      new OptimizeCSSAssetsPlugin({
        cssProcessorPluginOptions: {
          preset: ['default', { discardComments: { removeAll: true } }],
        },
      })
    ],
    splitChunks: {
      cacheGroups: {
        vendor: {
          test: /node_modules/,
          chunks: 'initial',
          name: 'vendor',
          enforce: true
        },
      }
    }
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules\/(?!(dom7|swiper)\/).*/,
        use: [
          {
            loader: 'babel-loader',
            options: {
              cacheDirectory: true,
              presets: [
                [ "@babel/preset-env", {
                  targets: {
                    browsers: [
                      '> 0.25%',
                      'edge >= 14',
                      'not ie <= 10',
                      'not op_mini all'
                    ]
                  },
                  useBuiltIns: 'usage'
                }]
              ],
              plugins: ['@babel/plugin-syntax-dynamic-import']
            },
          }
        ],
      },
      {
        test: /\.scss$/,
        use: [
          MiniCssExtractPlugin.loader,
          {
            loader: 'css-loader',
            options: {
              importLoaders: 1
            }
          },
          {
            loader: 'sass-loader'
          }
        ],
      },
      {
        test: /\.(png|woff|woff2|eot|ttf|svg)$/,
        loader: 'url-loader?limit=1000&name=[name]-[hash].[ext]'
      }
    ],
  },
  externals: {
      'TweenMax': 'TweenMax'
  },
  resolve: {
    alias: {
      'highway': 'build/es5/highway.min.js'
    },
    modules: ['.', 'node_modules'],
    extensions: ['.js']
  },
  plugins: [
    new MiniCssExtractPlugin({
      filename: "app.bundle.css"
    }),
    new SvgStore({
      // svgo options
      svgoOptions: {
        plugins: [
          { removeTitle: true }
        ]
      },
    }),
  ],
};

I'm also got like this
app.bundle.js:147 GET http://test.localhost/women/1.bundle.js net::ERR_ABORTED 404 (Not Found)
./js/app.js @ app.bundle.js:243
__webpack_require__ @ app.bundle.js:84
checkDeferredModules @ app.bundle.js:46
app.bundle.js:135 Uncaught (in promise) Error: Loading chunk 1 failed.
(error: http://test.localhost/women/1.bundle.js)
    at HTMLScriptElement.onScriptComplete (app.bundle.js:135)

It's seems to only happend when I'm trying to import renders like this
			renderers: {
				'home': () => import('../renderers/home'),
				'page': () => import('../renderers/page'),
				'default': () => import('../renderers/default')
			},

Hey @wezzou1,
We don't forget this, I am planning to have a look when I have some spare time to find the reason / a solution to this, but at first glance it may be a webpack configuration issue..
I'll let you know and run some tests :-)

@ThaoD5 Alright! :) Yes, I think too is an webpack configuration issue.. :)

Hi! I have the same issue, any solution found?

@IlaneLopez I'm just running the highway as they say in there documents for now, without chunkfiles/dynamic imports. I don't remember if I solved it for myself or not.. but if you find a solution, let me know =)


Cursor fetch fixes

What?
Why?

CC @hamchapman

          1 Warning

:warning:
Any changes to library code should be reflected in the Changelog. Please consider adding a note there. \nYou can find it at CHANGELOG.md.

SwiftLint found issues
Warnings

File
Line
Reason

ViewController.swift
106
Line should be 120 characters or less: currently 143 characters

ViewController.swift
111
Line should be 120 characters or less: currently 123 characters

ViewController.swift
116
Line should be 120 characters or less: currently 123 characters

ViewController.swift
128
Line should be 120 characters or less: currently 131 characters

ViewController.swift
190
Line should be 120 characters or less: currently 131 characters

ViewController.swift
7
Delegates should be weak to avoid reference cycles.

ViewController.swift
8
Delegates should be weak to avoid reference cycles.

PCCursorSubscription.swift
163
TODOs should be avoided (Should we call the delegate er...).

PCCursorSubscription.swift
65
Function should have complexity 10 or less: currently complexity equals 14

PCCursorSubscription.swift
65
Function body should span 40 lines or less excluding comments and whitespace: currently spans 49 lines

PCCursorSubscription.swift
86
Line should be 120 characters or less: currently 126 characters

ConnectionTests.swift
12
When using trailing closures, empty parentheses should be avoided after the method call.

ConnectionTests.swift
19
When using trailing closures, empty parentheses should be avoided after the method call.

ConnectionTests.swift
48
Variable name should be between 3 and 40 characters long: 'id'

ConnectionTests.swift
64
Variable name should be between 3 and 40 characters long: 'id'

Helpers.swift
404
Limit vertical whitespace to a single empty line. Currently 2.

Helpers.swift
493
Limit vertical whitespace to a single empty line. Currently 2.

Helpers.swift
627
Limit vertical whitespace to a single empty line. Currently 2.

Helpers.swift
18
Variable name should be between 3 and 40 characters long: 'id'

Helpers.swift
100
Variable name should be between 3 and 40 characters long: 'id'

Helpers.swift
406
Variable name should be between 3 and 40 characters long: 'id'

Helpers.swift
464
Variable name should be between 3 and 40 characters long: 'id'

Helpers.swift
691
Variable name should be between 3 and 40 characters long: 'fn'

Helpers.swift
695
Variable name should be between 3 and 40 characters long: 'fn'

Helpers.swift
399
Line should be 120 characters or less: currently 123 characters

Helpers.swift
535
Line should be 120 characters or less: currently 124 characters

Helpers.swift
674
Line should be 120 characters or less: currently 134 characters

Helpers.swift
698
File should contain 400 lines or less: currently contains 698

MessageTests.swift
10
Function body should span 40 lines or less excluding comments and whitespace: currently spans 44 lines

MessageTests.swift
309
Function body should span 40 lines or less excluding comments and whitespace: currently spans 64 lines

MessageTests.swift
409
Function body should span 40 lines or less excluding comments and whitespace: currently spans 44 lines

MessageTests.swift
474
Function body should span 40 lines or less excluding comments and whitespace: currently spans 44 lines

MessageTests.swift
23
When using trailing closures, empty parentheses should be avoided after the method call.

MessageTests.swift
30
When using trailing closures, empty parentheses should be avoided after the method call.

MessageTests.swift
83
Variable name should be between 3 and 40 characters long: 'ex'

MessageTests.swift
111
Variable name should be between 3 and 40 characters long: 'ex'

MessageTests.swift
149
Variable name should be between 3 and 40 characters long: 'ex'

MessageTests.swift
181
Variable name should be between 3 and 40 characters long: 'ex'

MessageTests.swift
540
File should contain 400 lines or less: currently contains 540

PresenceTests.swift
32
When using trailing closures, empty parentheses should be avoided after the method call.

PresenceTests.swift
39
When using trailing closures, empty parentheses should be avoided after the method call.

RoomTests.swift
77
Function body should span 40 lines or less excluding comments and whitespace: currently spans 50 lines

RoomTests.swift
19
When using trailing closures, empty parentheses should be avoided after the method call.

RoomTests.swift
26
When using trailing closures, empty parentheses should be avoided after the method call.

UserSubscriptionTests.swift
15
When using trailing closures, empty parentheses should be avoided after the method call.

UserSubscriptionTests.swift
21
When using trailing closures, empty parentheses should be avoided after the method call.

UserSubscriptionTests.swift
41
Variable name should be between 3 and 40 characters long: 'ex'

Errors

File
Line
Reason

ViewController.swift
31
Force casts should be avoided.

PCCursorSubscription.swift
170
Enum element name should only contain alphanumeric characters: 'initial_state'

PCCursorSubscription.swift
171
Enum element name should only contain alphanumeric characters: 'new_cursor'

ConnectionTests.swift
97
Force casts should be avoided.

ConnectionTests.swift
98
Force casts should be avoided.

ConnectionTests.swift
97
Force tries should be avoided.

Helpers.swift
7
Enum element name should only contain alphanumeric characters: 'generic(_:)'

MessageTests.swift
53
Force casts should be avoided.

MessageTests.swift
54
Force casts should be avoided.

MessageTests.swift
5
Type body should span 200 lines or less excluding comments and whitespace: currently spans 360 lines

MessageTests.swift
349
Variable name should be between 3 and 40 characters long: 'b'

MessageTests.swift
435
Variable name should be between 3 and 40 characters long: 'b'

MessageTests.swift
501
Variable name should be between 3 and 40 characters long: 'b'

MessageTests.swift
53
Force tries should be avoided.

PresenceTests.swift
68
Force casts should be avoided.

PresenceTests.swift
69
Force casts should be avoided.

PresenceTests.swift
112
Variable name should be between 3 and 40 characters long: 'a'

PresenceTests.swift
161
Variable name should be between 3 and 40 characters long: 'b'

PresenceTests.swift
68
Force tries should be avoided.

RoomTests.swift
68
Force casts should be avoided.

RoomTests.swift
69
Force casts should be avoided.

RoomTests.swift
107
Force casts should be avoided.

RoomTests.swift
108
Force casts should be avoided.

RoomTests.swift
126
Force casts should be avoided.

RoomTests.swift
127
Force casts should be avoided.

  Generated by :no_entry_sign: Danger


Create ExtractionProcess class

Creating an issue for creation of ExtractionProcess class to capture volume and concentration of solvents used in the process.

working branch https://github.com/microbiomedata/nmdc-schema/tree/1380-create-extractionprocess-class


Merge with nkatsar’s fork?

Would you please consider merging with the fork done by nkatsar? As far as I can see it has some valuable additions…

Honestly I'm happy to give up this repo. I've not actually done anything with it since 2014.

I see… Then hopefully nkatsar will merge the commits that have happened here since 2015!
Thanks.

I've cleared out my pull request backlog! It's like a git-merge Christmas!


[2.0.0-dev.5] Is it an intentional change that .value access to AsyncError now returns null instead of throwing error?

Describe the bug
Is it an intentional change that .value access to AsyncError now returns null instead of throwing error?
In version 1, an error was returned, but in version 2, null is returned, making it easier to overlook an unintended error.
I agree with https://github.com/rrousselGit/river_pod/issues/270#issuecomment-938522658 and I think this change in version 1 is good.
I know I can check for errors with .hasError, etc., but I would appreciate it if .value access throws an exception as well for reducing programming mistakes.
Or even an alias, I would like a property like .valueXxx that throws an error on error as in version 1.
To Reproduce
import 'package:riverpod/riverpod.dart';
import 'package:test/test.dart';

void main() {
  final errorValue = AsyncError(42);
  // test(
  //   'AsyncValue.value (v1)',
  //   () {
  //     expect(
  //       () => errorValue.value,
  //       throwsA(42),
  //     );
  //   },
  // );
  test(
    'AsyncValue.value (2.0.0-dev.5)',
    () {
      expect(
        () => errorValue.value,
        isNot(throwsA(42)),
      );
      expect(
        errorValue.value,
        isNull,
      );
    },
  );
}

Expected behavior
AsyncError.value throws the errror.

That is because now an AsyncError can have a "value"
If a provider emits a data, then emits loading/error, the data will still be available in "value".
We could still throw though. I'll think about it.

Fixed
Note that if you emit a data then an error. AsyncValue.value will not throw. That is because the previous value is conserved, in which case you'll obtain it.

@rrousselGit
Thank you very much 🙏
The changes are exactly as I imagined 👍

Note that if you emit a data then an error. AsyncValue.value will not throw.

I think it's usually the first time an unexpected error comes in, so I don't think it's a problem 👌


Replace serde_yaml

The maintainer of serde_yaml has announced the demise of that crate:
https://github.com/dtolnay/serde-yaml
We need to replace it.

Considering we never hit any problem of using serde_yaml, let's keep using it till better option shows up.

Hello @cathay4t  do you mind sharing what replacement options are available for serde-yaml ?
i'd like to work on this issue

@cathay4t  can i work this please

Hi @jubril-adeyi @Mabwas, I don't have preference on replacement yet.
Replacing a dependency need to answer these questions with proofs:

Is the new crate API stable enough?
Is the new crate well tested by community?
YAML API is the key API of nmstate, no CI test failure should not caused by this switch.

Personally, unless deprecated serde-yaml proved to be holding unfixed bugs, I would like to keep using it.
So, it might not be a good task for new contributor.
If you like to accept the challenge, PR is always welcome once you have proofs on above questions.

I also think that keeping serde_yaml is the best choice, for the moment. However, this seems a potential good replacement (which is a continuation of serde_yaml): https://crates.io/crates/serde_yaml_ng


Hang on post-reset boot?   (IDFGH-3516)

I first noticed this behavior on Arduino, but it also occurs with the template app.  I almost don't believe this, but I've reproduced it too many times now.
Coming out of flashing the chip, when the reset button is pressed, the ESP32 doesn't seem to boot up right unless it's connected to a serial terminal.
Steps to recreate:

Flash app-template (accepting all default options in menuconfig)
Press reset button
No blinking, no WiFi connection to network.
Run terminal program
Press reset
Connects to network, LED blinks.

Pressing reset many times without connecting a terminal program has no effect.  Powering the chip down and back up, however, makes it work regardless.
Just for fun, because I can't believe this issue, I attached a battery, flashed the firmware, pulled the USB cord, hit reset (nothing), re-attached the USB (nothing), and then opened up a serial terminal and hit reset.  Everything worked as it should.
It seems to be related to the up-from-reset flag and serial.  Though how the chip knows that I'm listening to it is beyond me.  Is there something in the configs that's halting on a test for a serial terminal?  How would it know?
Hardware is a WROOM dev board, esp-idf is all current as of today with a git pull --recurse-submodules.

Some serial programs assert DTR and RTS when you open a serial port. DTR and RTS are wired via two transistors to an auto-reset circuit, which controls EN and GPIO0. My guess is that something is wrong with this circuit and EN/GPIO0 pins are in incorrect state for normal boot to happen. Can you measure voltage at EN and GPIO0 when no terminal is attached? Also, is the board a V1 or V2 board?

Hiya, sorry took so long.
Board is dated 2016-08-31-30.
I think you hit it.  Both EN and GPIO 0 pull down to 0 V when a terminal application is running, but only to 1.415 V separately when it's not.  Pressing them both together pulls EN down to ~550 mV and GPIO 0 to 1.164 V.
That should be enough to explain why it enters programming mode consistently, but only resets (EN low) when whatever DTR/RTS magic is going on.  I wasn't expecting analog problems!  :)
GPIO 0 also seems to float when EN is pulled low.  I accidentally touched it with my finger, and it'll wander around 1.2 - 1.6 V.  On releasing EN, GPIO 0 rises again, following EN by about 180 us.  (So there must be a delay in the test for that pin in the bootloader?)  FWIW.
Anyway, sounds like you've got a handle on the issue?  I almost always have a terminal open anyway, or boot up from power-down in applications, so I've never noticed it until now.  And now that it's clear what's going on, I'm all good.  Thanks.

I noticed the "inverse" too: run the app with a terminal open, close the terminal and the app will stop too.
wroom dev board with esp-idf v0.9

This sounds like it might be the blue Core Board v1, which had a problem with its auto-reset circuit that could lead to symptoms consistent to this.
If anyone is seeing the bug on Core Board v2 (black), please reopen.

Does this behavior have no software solution?

Hi @charcoast,
I think this issue was resolved by a development board hardware update back in 2016. Development boards made by Espressif since late 2016 do not have this issue. It's possible a third party development board has a similar issue, though.
Can you give some details about exactly what you're seeing?

Hi. I'm writing this in 2022. Just in case someone in the future have this weird problem in some cards such as mine (Lolin32_lite, esp32) and their program only works when a serial is connected. @igrr was right. The problem is when you use GPIO0 for some functions (in my case, I use GPIO0 for Touch1 touching input). The solution in this case was just not to use GPIO0 at all, and problem solved. I am sharing this in case it may be useful for someone.


Search doesn't match all used terms, like 10/10, and doesn't match fully with external website terms

For example, search would also give back products that didn't match at all, or couldn't match isolate vs full spectrum.

This is the expected matching.
All red products are not listed products.


Link to CSSON to JSON converter broken

Hi, thanks for sharing an interesting project.
I noticed that the link to the online CSSON to JSON converter is broken. I worked out that it's because CSSON is in caps in the url. Changing this to lowercase fixes the link.

Thanks for spotting this and letting me know @limitlessloop! I'll update it :D


Fix Native S3 PyTorch workflow

Description
Brief description of what this PR is about
Fix Native S3 PyTorch workflow

If this change is a backward incompatible change, why must this change be made?
Interesting edge cases to note here

Codecov Report

Merging #1922 (a341847) into master (bb5073f) will decrease coverage by 2.19%.
The diff coverage is 67.05%.

@@             Coverage Diff              @@
##             master    #1922      +/-   ##
============================================
- Coverage     72.08%   69.89%   -2.20%
- Complexity     5126     5680     +554
============================================
  Files           473      543      +70
  Lines         21970    25072    +3102
  Branches       2351     2713     +362
============================================
+ Hits          15838    17523    +1685
- Misses         4925     6211    +1286
- Partials       1207     1338     +131

Impacted Files
Coverage Δ

api/src/main/java/ai/djl/modality/cv/Image.java
69.23% <ø> (-4.11%)
:arrow_down:

...rc/main/java/ai/djl/modality/cv/MultiBoxPrior.java
76.00% <ø> (ø)

...rc/main/java/ai/djl/modality/cv/output/Joints.java
71.42% <ø> (ø)

.../main/java/ai/djl/modality/cv/output/Landmark.java
100.00% <ø> (ø)

...main/java/ai/djl/modality/cv/output/Rectangle.java
72.41% <0.00%> (ø)

...i/djl/modality/cv/translator/BigGANTranslator.java
21.42% <0.00%> (-5.24%)
:arrow_down:

...odality/cv/translator/BigGANTranslatorFactory.java
33.33% <0.00%> (+8.33%)
:arrow_up:

...nslator/InstanceSegmentationTranslatorFactory.java
14.28% <0.00%> (-3.90%)
:arrow_down:

.../cv/translator/SemanticSegmentationTranslator.java
0.00% <0.00%> (ø)

.../cv/translator/StyleTransferTranslatorFactory.java
40.00% <ø> (ø)

... and 444 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Beautify Automatically Adds Lines Between Comments and Class

**Windows 10 **:
v1.51.0:
v1.5.0:

Beautify Automatically Adds Lines Between Comment and Class:
Before Saving:

After Saving:

Here adding line between classes is ok but between comments and classes is a little problematic.

Try this:
add to Settings.json
"beautify.config": {
    "newline_between_rules": false
},


'generateImageAsync' method does not work in Remote mode

Steps to reproduce:

Create any structure.
Call ketcher.generateImageAsync

Expected result:
Blob is created
Actual result:
Error 'unhandled error' is thrown

Related issue: https://github.com/epam/Indigo/issues/347

Wrong request:
{"struct":"png","options":{"smart-layout":true,"ignore-stereochemistry-errors":true,"mass-skip-error-on-pseudoatoms":false,"gross-formula-add-rsites":true,"outputFormat":"png"}}
outputFormat should be changed to render-output-format.

Indigo/render endpoint should be updated (generation of png does not work - svg is always returned)

Related issue: https://github.com/epam/Indigo/issues/415

The issue is reproducible for the following scenario: https://github.com/epam/ketcher/issues/1007

Everything is fine from our side, waiting for backend changes

Not possible to open svg file - error is shown in browser

fixed tested v.2.4


Repo consistency

CI currently tries to install from requirements.txt and doesn't have steps for formatting/linting.


[Bug]: Maintain context in the UI editor when I switch between pages

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
Currently when I switch between pages: UI, API pane, DB query & back to UI, the state of the UI is lost. It loads the default state of the page. I have to select the particular widget & the specific property I was editing in order to make changes. Not sure how big a change this will be in the code, but it's a small UX change that would improve my dev UX by a lot.
Steps To Reproduce

Open the UI editor
Drag a widget & start editing any property
Navigate to the API pane
Navigate back to the UI editor

See that the cursor doesn't focus on the widget & property any more.
Environment
Production
Version
Cloud

Stats

Stat
Values

Reach
5122

Effort (months)
0.5

Estimating the effort for this as 2 person-weeks. We can update this when we calibrate with the devs.


Reduce the number of warnings

Would you help me remove  this warning?
It is a fake one, I guess we just have to shut down the warning level.

The current version of LibWiser on git is the newest one.

I guess this arises due to lines 896:
NP =   Oversampling * len(P)-1 # degree of the polynomial
and 916:
P_new = np.polyfit(px_new, py_new, NP)
NP is too high for the number of points. Do you think it's fake and just needs to be suppressed or should we change line 896 to something else in order not to be overfitting by numpy standards.

This is something I encountered at day 3 of wiser, and I have never understood.
In principle I am fitting N points with a polynomial of lower degree (Np<N)  so I expected it to be ok.
If you have more advance mathematical skills and want do to a quick check, it's very welcome.
 Results always seemed to be consistent.
Inviato da myMail per Android Giovedì, 02 Settembre 2021, 08:08AM +02:00 da aljosahafner  @.*** :

I guess this arises due to lines 896:
NP =   Oversampling * len(P)-1 # degree of the polynomial
and 916:
P_new = np.polyfit(px_new, py_new, NP)
NP is too high for the number of points. Do you think it's fake and just needs to be suppressed or should we change line 896 to something else in order not to be overfitting by numpy standards.
—
You are receiving this because you authored the thread.
Reply to this email directly,  view it on GitHub , or  unsubscribe .
Triage notifications on the go with GitHub Mobile for  iOS or  Android .

If it works, then I think it's best to just suppress the warning.

Ok, I suppressed the warning, line 885:
warnings.simplefilter('ignore', np.RankWarning)

great! one issue less. We are effective:-)
Inviato da myMail per Android Giovedì, 02 Settembre 2021, 09:20AM +02:00 da aljosahafner  @.*** :

Ok, I suppressed the warning, line 885:
warnings.simplefilter('ignore', np.RankWarning)
—
You are receiving this because you authored the thread.
Reply to this email directly,  view it on GitHub , or  unsubscribe .
Triage notifications on the go with GitHub Mobile for  iOS or  Android .


gradle 5.0 have a problem with Android Studio 3.2.1

Expected Behavior

Expected -> Build project
Current Behavior

Curent -> Not Build! Generate ERROR
Context

Caused by: java.lang.AbstractMethodError: org.jetbrains.plugins.gradle.tooling.util.ModuleComponentIdentifierImpl.getModuleIdentifier()Lorg/gradle/api/artifacts/ModuleIdentifier;
Steps to Reproduce (for bugs)

Android studio 3.2.1. with Gradle ver 5.0
I go back to Gradle ver 4.10.3 and I do not have any problem!
Your Environment

PC , OS Windows 10 x64, Intel core i5-8600k, Coffe Lake, Java 11.0

Build scan URL:

Caused by: java.lang.AbstractMethodError: org.jetbrains.plugins.gradle.tooling.util.ModuleComponentIdentifierImpl.getModuleIdentifier()Lorg/gradle/api/artifacts/ModuleIdentifier;
Android studio 3.2.1. with Gradle ver 5.0
I go back to Gradle ver 4.10.3 and I do not have any problem!
PC , OS Windows 10 x64, Intel core i5-8600k, Coffe Lake, Java 11.0

Gradle 5.0 is not compatible with Android 3.2.
This is indicated in the upgrade guide.
Note that combine effort from the Gradle and Android team may end up making Android 3.3 compatible, so you may not have to wait until 3.4 is out.

Same problem with intelliJ

I am migrate to ver android studio 3.3R and to this moment I do not have problem with gradle 5.0q but I recomende you to build you project with gradle ver 4.10.
How m-r Jacomet write Gradle NOT compatible with Android Studio 3.2.
To IntelleJ IDEq I see that they have a big problem with visual component preview, must write every time for new name on Theme listing (Base) or change name  AppCompat...to alpha1

Yeah rollback to Gradle 4.8 works okay


Theme Support

Summary
This PR adds some initial/basic support for user-configurable themes. I didn't want to turn too many things inside out, which is why
there's a "shim" function that translates the user's color choices into the currently-used format; the idea being that the default theme ships a combined light + dark mode, but once a user writes their own theme, the complexity of that is unnecessary, as they're writing it for their own terminal, which is either light or dark.
On top of that, it's possible to set a useShellTheme bool in the config file, which skips custom themes altogether and instead uses the user's shell theme. I'm not sure if it looks good for everyone, perhaps that needs some testing/adjustment and maybe also the same light+dark logic of the default theme.
In summary, the config file generated on the first run now includes this (these are the colors for a dark terminal, for a light one it'd dump a different set of colors - I "transcribed" the default color scheme):
theme:
  colors:
    text:
      main: '#E2E1ED'
      secondary: '#666CA6'
      bright: '#E2E1ED'
      subtle: '#242347'
      faint: '#3E4057'
      warning: '#F23D5C'
      success: '#3DF294'
    background:
      selected: '#39386B'
    border:
      main: '#383B5B'
      secondary: '#39386B'
      faint: '#2B2B40'

I've deliberately put everything under a theme.colors sub-key, because looking at the open issues, there's a few things that'd probably fit well into a theme.layout (#107) or theme.options (#111) tree.
How did you test this change?
Barely, and I'm new to Go. Opening this as a draft to facilitate discussion about the implementation. When/if everything is agreed on code wise, I'd update the docs in a separate commit. Also looking at base16 to generate a set of themes, license wise gh-dash is compatible with it, but again, don't want to do too much at once.
Images/Videos

<making the robots happy>
Fixes #102
</making the robots happy>
If there's anything unclear, ask away, I have trouble articulating myself sometimes! :)

Hey! Amazing stuff, thanks so much for contributing this! I'll go over it in the next couple of days 💖

I made a whole mess with the colors :D
I think some are unused, and some are just badly named.
I need to go over them and consolidate a bit.
theme:
  colors:
    text:
      main: '#E2E1ED' # should probably be renamed to "primary"`
      secondary: '#666CA6'
      bright: '#E2E1ED' # I actually searched the code and I don't think this is used
      subtle: '#242347' # This one is badly named. It's used for the pills which have a light background color and so need a dark text. Maybe it should be named "inverted"?
      faint: '#3E4057'
      warning: '#F23D5C'
      success: '#3DF294'
    background:
      selected: '#39386B'
    border:
      main: '#383B5B' # "primary"
      secondary: '#39386B'
      faint: '#2B2B40'

I made a whole mess with the colors :D I think some are unused, and some are just badly named. I left comments I think should make things more clear.
theme:
  colors:
    text:
      main: '#E2E1ED' # should probably be renamed to "primary"
      secondary: '#666CA6'
      bright: '#E2E1ED' # I actually searched the code and I don't think this is used
      subtle: '#242347' # This one is badly named. It's used for the pills which have a light background color and so need a dark text. Maybe it should be named "inverted"?
      faint: '#3E4057'
      warning: '#F23D5C'
      success: '#3DF294'
    background:
      selected: '#39386B'
    border:
      main: '#383B5B' # "primary"
      secondary: '#39386B'
      faint: '#2B2B40'

https://github.com/dlvhdr/gh-dash/pull/146/commits/8beba2a978f2fd4cea64f3dc4093d2bcc58a6c3c

Overall looks great!

You can push whenever you're ready.

I'm not sure what you mean..? :D

Ah push = merge

I can't, it's set up so only you can :P

Whoops ok then :)


Long mode page incorrectly identifies VGA character size

The "Some Tests" section states that a screen character consists of an 8-byte color code and 8-byte character. This should read as 8-bit for both.

Thanks!


QuickFix generate method should not add using directive

editor.action.quickFix currently adds a using System directive to the containing file when generating methods.
This is not always convenient and often means that the using has to be removed once the method has been fully implemented.
A lighter approach would be to change the generated method's body to throw new System.NotImplementedException(); instead.

This issue was moved to OmniSharp/omnisharp-roslyn#393


Catch panic caused by race condition when handling a buggy stream

If the data passed has a faulty chunk or the stream is closed from the other side then there is a race condition that can mean that zedUpload/datastore.go:postResponse can panic from trying to write to a closed response stream. Things seem to get cleaned up, but this can still cause applications using this library to crash.

@dionb is there a reason to handle panic in postResponse and not in higher level like handleRequest or ListenAndServe?

@dionb could you please point out what exact channel close call for this respChan do you mean? Or do you have a backtrace of the crash? It is worth to specify it in the commit message. Also please sign your commit and keep the commit message ~80 characters wide (not a single line, otherwise looks ugly). Thanks.

@uncleDecart mostly to try to minimise potential impact on eve, in what is a bugfix needed for zedcloud. I tried a bunch of workarounds at the handleRequest level, and in the code in zedcloud that calls this library to try to prevent the error with no luck. But I admit this is not a good solution. If you have a better approach that you would like me to try, and are happy to walk me through how I should test the change in eve then I would be happy to do so.

@dionb thanks for the tweaks made.

the close calls were all coming from outside of this library, when the channel that is passed into NewRequest were being closed before zedUpload was finished with them

I see. Frankly, this is clearly a caller issue. Don't close the channel, don't shoot into the leg.

@dionb can the channel be explicitly closed by the writer side? Reader gets EOF.
Something like:
diff --git a/libs/zedUpload/datastore.go b/libs/zedUpload/datastore.go
index 5602ec9b4495..141b2449a544 100644
--- a/libs/zedUpload/datastore.go
+++ b/libs/zedUpload/datastore.go
@@ -174,7 +174,7 @@ func (ctx *DronaCtx) handleRequest(req *DronaRequest) error {

                // No matter what post response
                ctx.postResponse(req, err)
-
+               close(req.result)
        }()

        return err

But isn't this pointer to channel coming from somewhere else @rouming? So closing should be not on handleRequest, but on the side which passes channel to handleRequest

But isn't this pointer to channel coming from somewhere else @rouming? So closing should be not on handleRequest, but on the side which passes channel to handleRequest

@uncleDecart I'm reasoning how that can be improved in order to solve the problem (if the problem exists, because I still do not understand why it is impossible to "teach" the caller good manners not to close the channel before operation completes). So one of the possible ways is to allocate the channel in the NewRequest and assign it to the req.reply and then close once no replies. The main question is: can the request be used several times, like "req.Post(), wait for responses, req.Post() twice, etc". This I do not know, thus the question.

@rouming I agree with you and what I'm saying is closing channel on receiver side won't fix the problem, it's better to "teach" sender some good manners. But since PR is closed let's stop discussing it :D

I found a solution in using a buffered channel so that for the event that this library signals an error and then writes another response anyway it doesn't hold the thread goroutine open, and they will then get garbage collected. I don't think this is an elegant solution, but it's better than just catching the panic


Members API will deprecate

Need to change the members api to users api in the task section of dashboard site.

Please test it before making a PR
Involves pagination and debounce

closing in lieu of: https://github.com/Real-Dev-Squad/website-members/issues/547


Enabling fullscreen via code shows window border at screen edges (DisplayServer regression)

Godot version
4.0.dev (835da447)
System information
Windows 10, Vulkan Clustered, 3 monitor setup
Issue description
When changing fullscreen mode via code, the window's border is visible at the edges of the screen. This does not happen when enabling the fullscreen project setting instead.
Launching the MRP with a high contrast theme (where window borders are white) with x10 zoom on the top left corner of my screen:

When using the default Windows 10 theme:

This confirms that you see the window's borders.
Steps to reproduce
Create a fresh project. Then either in _ready, or when pressing a key, run:
get_tree().root.mode = Window.MODE_FULLSCREEN
# This does not help:
#get_tree().root.borderless = true

Minimal reproduction project
win_fullscreen_border.zip

I just tested the example and for me on Win10 the Taskbar is also visible (window seems to be behind the Taskbar)

I've noticed this on my system w/ Windows 11, Vulkan, RTX3070 and GD4a14. Dual monitor set up (1920x1200, 1920x1080). It exists on all games, including the editor. It's not just via code. It is the window mode set by DisplayServer.
The title of this ticket should be changed to something like Border on Full Screen.
DisplayServer.WINDOW_MODE_FULLSCREEN results in a 1px wide border in games and the editor.
DisplayServer.WINDOW_MODE_EXCLUSIVE_FULLSCREEN removes the border.
I can fix it for my game, but I don't see an option to change the editor to exclusive mode. Its hard to see in a screenshot, so I added black borders around so you can see the white border.

And the border cannot trigger mouse click event

Incidentally, you can actually get around this and achieve "true" borderless fullscreen by setting the window mode to a standard window (i.e. not maximized or minimized, not borderless, not unresizable), changing its size to your screen resolution, and setting its position to the monitor position (which is going to be 0,0 if you have only one monitor). It'll take up the full screen without triggering exclusive mode. Sometimes it leaves behind the taskbar and you have to alt tab a couple of times, but I find that's an issue with windows on multiple games anyway.
I have a hunch that's just how windows handles borderless fullscreen - if a window has a position and size equal to a monitor, it'll just fullscreen on that monitor. Enabling settings such as windowless or non-resizable actually stops this fix from working, though I don't know how much of that is windows getting confused and how much of it is Godot trying to be clever with your settings and doing the wrong thing by mistake.
Incidentally, exclusive fullscreen introduces a delay on mouse movements, which is quite frustrating if you've got an object tracking the mouse.

The border is added deliberately, since it's the only reliable way to ensure non-exclusive mode on all hardware, and Godot editor (or any other Godot app that is using multiple windows) require non-exclusive mode to work.

For what it's worth, you can actually get around this and achieve "true" borderless fullscreen by setting the window mode to a standard window (i.e. not maximized or minimized, not borderless, not unresizable), changing its size to your screen resolution, and setting its position to the monitor position (which is going to be 0,0 if you have only one monitor). It'll take up the full screen without triggering exclusive mode.

No it won't, at least no on all GPUs (it is controlled by the driver), only the window client area size/position matter, so window with the border outside the screen will still trigger exclusive fullscreen.
There's MODE_FULLSCREEN_EXCLUSIVE which is equivalent to 3.x fullscreen (or creating borderless window and change it to match screen size), which will not have a border (but won't work with multiple windows).

Incidentally, exclusive fullscreen introduces a delay on mouse movements, which is quite frustrating if you've got an object tracking the mouse.

It should be the opposite – borderless fullscreen has more input lag, except on Windows 11 with Direct3D 11/12 apps.

No it won't, at least no on all GPUs
Works On My Machine:tm:, but I'll take your word on that
Is there any reliable way to achieve borderless windowed mode on multiple platforms, then? I never see these thin borders on other games.

It should be the opposite – borderless fullscreen has more input lag, except on Windows 11 with Direct3D 11/12 apps after enabling windowed gaming optimizations.
After testing it just now, it actually seems to introduce a delay on all input, not just a mouse. I agree it shouldn't be that way, but I have no idea if it's a bug in Godot or an anomaly of my setup (running a second monitor connected to a laptop).

I have analyzed borderless full-screen in some games, and might find a combination of window style flags that is working, but it needs testing on various GPUs to make sure it is https://github.com/godotengine/godot/pull/72787

Even a borderless mode that only has partial compatibility would be a great step up, honestly
Actually, thinking back on it, I think SFML and SDL had borderless fullscreen modes that worked fairly gracefully? Although it's been a while, so I might be misremembering

https://github.com/godotengine/godot/issues/81553 was closed as a duplicate of this issue so just to recap some info from the other ticket -- 4.1.1 and onward do not support borderless fullscreen when set from project settings, versus this ticket which at least originally specifies the issue is when changing the mode through code. This was the result of https://github.com/godotengine/godot/pull/79016. This change references issues predating 4.1.stable but was cherry-picked for 4.1.1, and at least on my system borderless fullscreen worked with 4.1.stable.

I use DisplayServer.WINDOW_MODE_EXCLUSIVE_FULLSCREEN and have no border.
I connect this to F11 to switch between windowed and full screen:

That border makes this mode is useless for many developers, if this is not going to change I would vote for removal of this mode entirely, leaving only exclusive full-screen mode (Of course, I may be wrong and that mode is useful on other OS/platforms, so it just my thoughts).

if this is not going to change I would vote for removal of this mode entirely, leaving only exclusive full-screen mode (Of course, I may be wrong and that mode is useful on other OS/platforms, so it just my thoughts).

Borderless window behaves better with screen recording apps and overlays that draw their own window. We shouldn't remove it entirely.

@Calinou Ok, then, for example, some games have that mode without a border (Age Of Wonders 3 for example) - why Godot may not have it without border?

I've heard rumor that, on windows, tagging the window as a "popup window" lets it go borderless fullscreen gracefully without hijacking into exclusive fullscreen mode, but I've had only limited success myself.
This really is one of those problems that a bunch of professional developers seem to have solved but for the life of me I have no idea how.

Obviously releasing a game with a white border is not an option. But neither is releasing a game with input lag.
This white border appears no matter if you set "fullscreen" from the project settings or in code.  You can verify this by using PresentMon.
Please take a look at this page:
https://learn.microsoft.com/en-us/windows/win32/direct3ddxgi/for-best-performance--use-dxgi-flip-model
Exclusive fullscreen on Windows should not even be an option as it is a deprecated function that doesn't have any of advancements of borderless fullscreen. By using PresentMon you can see that using Godot with exclusive fullscreen adds over 30 ms of presentation delay (at 120 fps) which gives an awful feel for all kinds of games, especially first person games. By using what Godot calls "fullscreen" with the white border, it uses GDI copy presentation which is not optimal, and an ancient feature, but it slightly reduces the latency [1]. This white border is obviously by all intentions not something that any user or developers wants. A user doesn't care about some technical detail why it is visible, and will instead blame the game developer about something they cannot control.
Exclusive fullscreen is also the culprit that may lock your computer since no window is able to get shown in front of it in case of a crash or hitting a breakpoint when debugging. It also adds flickering when the window becomes focused or unfocused, not to mention alt tabbing feels terrible.
Also sorry but trying to shape the Linux way of doing things on to Windows is the wrong approach. These are separate operating systems and the DirectX team at Microsoft has gone to great lengths to make these optimizations on Windows 10 and later, and Godot is not using any of them. The state of the Windows "display server" in Godot 4 is not in a production state for game developers as it is now: you either have a white border or you have severe input lag. No serious game studio would ever release a product with either of those issues present.
For DirectX applications the only thing you have to do to engage DirectFlip (which is a low latency zero copy direct-to-dwm presentation) is to create any window that matches the monitor size and with the WS_POPUP window style, and using either flip swap effects. It appears that Godot 4 is using Vulkan on WIndows now so is that what is holding all Windows developers back? Will https://github.com/godotengine/godot/pull/70315 resolve this by actually making use of the features that Microsoft give us? There is no secret to this or driver specific (unless you use MPO but you don't need to) since presentation to DWM is managed by Windows.
[1] I should point out that this white border alone doesn't make the latency much better, you have to really fiddle with the VSync values and engine variables to reduce it to something not-super-bad. But that is a large other topic not related to this issue.

@crashfort You seem to have a better understanding of the issues than most. I'm wondering if you could shed some light on what the hell is actually causing these issues.
I made an issue a while back (#77596) trying to figure out exactly why Godot was introducing input lag. I got very confused when I started running into the same issue with other engines. I also eventually discovered that manually limiting the FPS and setting the vsync mode to mailbox achieved the best of both worlds, sometimes, occasionally, except sometimes things would fall out of sync and you'd get weird stuttering with skipped frames or some such.
In addition, the method I posted earlier in the thread - the sort of pseudo fullscreen - has a weird issue where the window is still resizable on multi-monitor setups, and trying to fiddle with the window flags ends up either triggering exclusive fullscreen or doesn't go fullscreen at all. And setting mailbox vsync seems to sometimes prevent it from going exclusive fullscreen and it just works mainly as I'd expect?
I'm not a contributor, but I'm still genuinely confused about what the hell is going on. Is this a problem with Vulkan/OpenGL? Is Godot just handling the windows API in a really janky way? Is there even a solution to this that doesn't involve switching to DirectX? Because you're absolutely right, having to choose between two frames of input delay or a borderless windowed mode which, hilariously, has a border, isn't exactly a fantastic set of choices.

Note that PresentMon is known to sometimes give unrealistic latency readouts. Special K may be more reliably, but ideally, I recommend testing with a high-speed camera or LDAT testing device (if you have access to one).

This should be addressed by https://github.com/godotengine/godot/pull/80566.

That would be wonderful. This issue is currently in my top three. Thanks for pointing it out.
Anecdotally, 30ms feels about right for the delays I was experiencing in that other issue, so at a glance I'd trust those numbers.

I was looking into adding D3D11 + DXGI presentation to the Vulkan renderer myself since this issue has not seen any progress at all, but I have given up simply because Vulkan is miserable, and the unbelievably slow build system that Godot uses. Nobody should put themselves through build times this slow. How this issue isn't considered more important since it affects every Windows user is beyond me. Anyway, I tried.

I was looking into adding D3D11 + DXGI presentation to the Vulkan renderer myself

Wouldn't D3D12 + DXGI make more sense, as every GPU that supports Vulkan also supports Direct3D 12?

It doesn't matter if you'd use D3D11 or D3D12 since you only have to create a single DXGI texture that you'd write to through Vulkan and then present in a DXGI swapchain. Doing that is way simpler in D3D11 (I also have experience with D3D11) so I would above all else recommend doing that. That is not the problem. The problem is that Vulkan is Vulkan, and there is nothing simple without friction for a lifetime.

I have analyzed borderless full-screen in some games, and might find a combination of window style flags that is working, but it needs testing on various GPUs to make sure it is https://github.com/godotengine/godot/pull/72787

Some update:

It works on NVIDIA, but unfortunately AMD drivers force exclusive mode based only on the client area rectangle, style flags seems to be entirely ignored. So I do not see any way to ensure multi-window support in the full-screen mode other than adding a border.
Border color is handled by https://github.com/godotengine/godot/pull/82031 (uses clear color from project settings).

That border makes this mode is useless for many developers, if this is not going to change I would vote for removal of this mode entirely, leaving only exclusive full-screen mode (Of course, I may be wrong and that mode is useful on other OS/platforms, so it just my thoughts).

This mode exists specifically for the Godot editor (and similar non-game applications), with the intention to ensure support for multiple windows in all cases. It's not intended for games and should not be used in most cases.
Also note: "exclusive" mode is just a WS_POPUP window with the size of the screen, it's not true exclusive with video mode change. How it's actually handled is up to Vulkan driver implementation.

That border makes this mode is useless for many developers, if this is not going to change I would vote for removal of this mode entirely, leaving only exclusive full-screen mode (Of course, I may be wrong and that mode is useful on other OS/platforms, so it just my thoughts).

I guess we can add a third mode instead (WS_OVERLAPPED + screen size), which will work as "borderless full-screen" on NVIDIA and Intel GPUs, and not guarantee multi-window support, like this:

MODE_MULTIWINDOW_FULLSCREEN - (WS_OVERLAPPED | WS_BORDER + screen size), with border, multi-window, used by editor.
MODE_FULLSCREEN - (WS_OVERLAPPED + screen size), w/o border, might be "borderless" or "exclusive" depending on GPU.
WINDOW_MODE_EXCLUSIVE_FULLSCREEN - (WS_POPUP + screen size), always "exclusive".

I made an issue a while back (https://github.com/godotengine/godot/issues/77596) trying to figure out exactly why Godot was introducing input lag. I got very confused when I started running into the same issue with other engines. I also eventually discovered that manually limiting the FPS and setting the vsync mode to mailbox achieved the best of both worlds, sometimes, occasionally, except sometimes things would fall out of sync and you'd get weird stuttering with skipped frames or some such.

@vpellen The cause will vary based on the implementation but ultimately the problem is frames being queued. Sometimes they are queued intentionally to guard against frame rate fluctuation, and sometimes they are queued unintentionally because of an inefficient implementation. But generally speaking, the input is being processed when you expect it to; you just need to wait for all the queued frames to pass before you can actually see it.
I've created a project you can use to visualise this delay: https://github.com/TempoLabGames/UnityRenderingLatencyDemo
The grey bands indicate where the mouse ought to sit if the renderer implementation is achieving optimal latency for the given settings. When you see tearing, you can move the mouse up and down the screen to get a better understanding of how the tear lines impact latency. Unity's Direct3D12 implementation achieves these optimal values on my machine (tested with 2021.3.x).

I'm here from the issue that was just linked to this one (sorry for the duplicate, searched but didn't see this) and a bit confused on how the new integer scaling feature is supposed to be used with this issue.  Exclusive full screen was suggested, but that is Windows OS only according to the documentation.
So, if you make your game viewport resolution divisible by a common resolution like 1080p, there wouldn't really be a way to use integer scaling with full screen on any OS other than Windows, right?  Because the window would always be 2 pixels smaller in both dimensions.
It also would mean regardless of integer scaling, if you want any kind of full screen on a non-Windows platform it would have a border like this which hurts the visuals of the game.

This mode exists specifically for the Godot editor (and similar non-game applications), with the intention to ensure support for multiple windows in all cases. It's not intended for games and should not be used in most cases.

Doesn't that mean there is no intended way to have a full screen game on Linux for example? If the only full screen option isn't intended to be used for games. That's quite surprising.

Doesn't that mean there is no intended way to have a full screen game on Linux for example?

Exclusive Fullscreen works on all desktop platforms and is the intended mode.

Docs are a bit out of sync (https://github.com/godotengine/godot/pull/82179), DisplayServer has more up-to-date description than Window.

As someone totally new to Windows' window management, I wonder if other projects approaches could be of help?
An open source project that performs similar window management (minus the multi-window aspect, focusing on the gaming experience) that I use frequently on Windows is RetroArch. They allow windowed or exclusive fullscreen, and at least on my setup (Windows 11 + NVIDIA + Vulkan) the windowed variant doesn't result in the anoying mode switching discussed earlier (OpenGL is a different story though). They seem to achieve both fullscreen modes with WS_POPUP, so maybe worth checking if they're doing something that could be of use in this context?

I think this has been fixed with 4.2 beta
I just tested a small (private) 2D project of mine and an empty 2D project in both 4.1.1 and 4.2 beta versions and can confirm the white border only appears in 4.1.1

I think this has been fixed with 4.2 beta

Nope, nothing changed for me in my project.

I also am still experiencing the issue in 4.2.beta1, and similarly saw the issue in each of the 4.2 dev releases (the latest version not affected afaik was 4.1.stable).  In both cases with "borderless" toggled on I see the 1px gray border in Fullscreen mode but not Windowed or Exclusive Fullscreen. This is on Windows 10 with Nvidia. I could believe that Windows 10 vs 11 affects this issue but it looks like others have also run into it with W11.
borderless_test.zip

After testing the project a-johnston sent in 4.2 (beta 1) I have some notes:

If you change the clear color and make the window fullscreen at runtime, then the border color will be the set clear color
RenderingServer.set_default_clear_color(Color.PURPLE) DisplayServer.window_set_mode(DisplayServer.WINDOW_MODE_FULLSCREEN)
If you first go fullscreen, then change the clear color, it doesn't change the border color, but if you set the mode to WINDOW_MODE_FULLSCREEN again then the border color is changed

It is not fixed in 4.2 and is still an issue. The border being present also breaks the canvas items scale mode, since the border reduces the size of the window and the UI will become a blurry mess.
All that was changed in 4.2 was that the color of the border changes according to the clear mode. Sorry, but seriously? Again, this is entirely a flaw in the Godot code, and yet again not any driver specific thing. The way to present graphics on Windows is to use DXGI. Stating that users can override the presentation behavior in the Nvidia control panel is not useful. Are you going to prompt in your game to tell all your users to go dig in the control panel to change a specific setting to play the game?

Hi everyone.
I think @bruvzg's  idea of WINDOW_BORDERLESS_FULLSCREEN could be useful! Removes the need to actually do that from scrip. I have tried it borderless + fullscreen and does remove the 1pixel border and doesn't affect fps.
The exclusive fullscreen caps the fps at 60 which makes me think Windows is taking over and forcing vsync on it.  I'm on the lasted update Windows 10.

I was getting this white border in 4.1.1-stable-mono but then I built PR #80566 [v4.2.dev.mono.custom_build [e4a4a40c8]] from source for mono and now I don't see it anymore.

Can confirm this still exists in 4.2, in fact in my case it didn't exist until I upgraded from 4.1 to 4.2. Thin grey border that I cannot change or get rid of.

Can confirm this still exists in 4.2, in fact in my case it didn't exist until I upgraded from 4.1 to 4.2. Thin grey border that I cannot change or get rid of.

The only possible fix is maximize_window + borderless creating a "fake fullscreen". Works perfectly!

The only possible fix is maximize_window + borderless creating a "fake fullscreen". Works perfectly!

This worked for me as well. Seems like a good enough workaround for now. Thanks, @filipworksdev!

I created a new MRP to track down the best way to get around this and what I discovered is that borderless windows might be more busted than I thought. I got WEIRD behavior but if you're here for the solution the TL;DR is that this works (yes, you need to set the window mode TWICE):
get_window().mode = Window.MODE_MAXIMIZED
get_window().borderless = true
get_window().mode = Window.MODE_MAXIMIZED

Okay, so here's my findings... I made a MRP where you can change the window mode with hotkeys. Windowed and exclusive windowed work as expected. Exclusive fullscreen has a size of (1920, 1080). Borderless fullscreen has a size of (1918, 1078) due to the 1px border around it.
Maximizing the window without a border makes NO sense however and it might be where everything breaks. My first thought was to do this:
get_window().borderless = true
get_window().mode = Window.MODE_MAXIMIZED

What this code actually does is just turn on borderless fullscreen mode. As in, get_window().mode is literally Window.MODE_FULLSCREEN and not maximized, so this might be what borderless fullscreen literally does under the hood. The window size is (1918, 1078) again. What about maximizing first, then setting borderless?
get_window().mode = Window.MODE_MAXIMIZED
get_window().borderless = true

The first time you run this it works as expected. It maximizes then turns borderless, not going over the taskbar.  There is no visible border but it might be getting rendered around the window, hence the extra two pixels on each axis.
Running that code a third time just turns it back into borderless fullscreen.
What's interesting is that the first code snippet I posted (maximize->borderless->maximize) actually works as expected, giving us a window size of (1920, 1080) with no borders. Only if you add another get_window().borderless = true after that does it add 2px to each axis. I have no idea why that is and maybe someone familiar with Godot source code can pick this up from here and figure out a solution.
Tested with Godot 4.2.1, Windows 11 23H2. I went insane writing this. Make it make sense.
borderless_test.zip

I still have this issue in Godot 4.3 beta1 using Windows 10 Pro version 22H2

Out of curiosity I set the rect of my game window through WinExplorer after setting borderless to true and it seems to work as intended (1920x1080, no pixel border, no exclusive fullscreen.) The only difference seems to be WS_POPUP being unset (false) when I use WinExplorer which prevents the unwanted behaviour.
Unfortunately Godot (probably with good reason) does not allow me to set WS_POPUP off and won't let me disable the flag anyway despite handling WinExplorer forcing that flag off just fine.
This may not work for every video driver or version of Windows, but it does work for me and Godot won't let me utilize this fix assuming it would work. My project doesn't need multi window support, so any borderless non-exclusive fullscreen option that is actually the intended window size would be appreciated.
This is mostly relevant from a game recording perspective. Right now if I someone wants to record or stream the game in fullscreen these are the available options:
Option 1) Make the game window a very slightly different size using Windowed + Set Size. Now OBS game capture will capture a 1920x1081 source leading to either blurred capture (stretch), fit to screen capture (black bar on the right), off screen capture (missing pixel at the bottom) or the streamer has to notice and crop the window by 1 pixel vertically to get the correct aspect ratio (missing pixel at the bottom.)
Option 2) Use Fullscreen (not Exclusive) mode. OBS game capture is now 1918x1078 leading to blurriness because the aspect ratio is off. Due to a bug using Fullscreen with display capture leaves a 1 pixel transparent border around my game which is very unsightly. Streamers also aren't fans of using display capture in the first place for privacy reasons.
Option 3) Use Exclusive Fullscreen. For people who choose to play this way this is an acceptable workaround, but in my experience it's common for streamers to prefer borderless windowed to prevent issues with alt tabbing during streams.
Images of the blur as captured through OBS at 1920x1080 (Open in new tab to compare at full size)
1920x1081 Borderless Blur

1918x1078 fullscreen Fullscreen Blur

1920x1080 Exclusive Fullscreen No Blur (WinExplorer no WS_POPUP is the same result)


It wont start

So recently i wanted to install MSIRGB. I already had it working on another machine withe the same Mainboard (MSIM-Pro-VDH), but now i cant open it. As soon as I try opening it, it asks for admin rights but then it dissapears immediately. Also it doesn´t show up in Task Manager. I have no Idea why it wont work since it already worked on the same mainboard and ive VCRedist installed.
Thx for help.

I'm sorry for the delayed response. Did you get it fixed?

Yup finally got it. There were some corrupted files in my operating system that after reinstalling windows were finally fixed. I think it was some kind of driver issue that caused the problem. Am 19.08.2020 18:56 schrieb Pedro Fanha<EMAIL_ADDRESS>I'm sorry for the delayed response. Did you get it fixed?
—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.


TF Batch 256 ResNet50 Takes ~4 mins to compile for CUDA

What happened?
ResNet50 compile time scales linearly with batch size. This is not the case for other models. For Bert-Large and T5-Large below, compile time is similar regardless of batch size.

Steps to reproduce your issue

Download SavedModel: https://storage.googleapis.com/iree-model-artifacts/tensorflow/tf_models_2.12.0_1680491395/RESNET50/batch_256/tf-model.tar.gz

Import:

iree-import-tf --output-format=mlir-bytecode --tf-import-type=savedmodel_v2 --tf-savedmodel-exported-names=forward <saved_model> -o </path/to/model.mlirbc>

Compile:

iree-compile --iree-hal-target-backends=cuda --iree-input-type=mhlo --iree-hal-cuda-llvm-target-arch=sm_80 </path/to/model.mlirbc> -o </path/to/model.vmfb>

What component(s) does this issue relate to?
Compiler
Version information
Commit 35bdd9d
Additional context
No response

Thanks Marie. We must be missing to tile some batch dimension. @KoolJBlack can you take a first look?

We're unrolling endlessly during LLVMGPUVectorLoweringPass. This happens with dispatches that contain convolutions in Resnet, thought the unrolling does not affect the arithmetic of the convolution. I haven't dug into T5 but i suspect like BERT models , it does not contain convolutions which is why their unaffected.
The unrolling issue is caused by populateVectorBroadcastLoweringPatterns() and  vectorToSCFOptions.enableFullUnroll() during vectorization.
The first unrolling issue is caused by populateVectorBroadcastLoweringPatterns(). It turns this:
  %22 = vector.transfer_read %4[%21], %cst {in_bounds = [true]} : memref<64xf32>, vector<4xf32>
  %23 = vector.broadcast %22 : vector<4xf32> to vector<256x1x4x4xf32>

into an endless stream of:
    %1814 = vector.load %4[%21] : memref<64xf32>, vector<4xf32>
    %1815 = vector.insert %1814, %cst_0 [0] : vector<4xf32> into vector<4x4xf32>
    %1816 = vector.insert %1814, %1815 [1] : vector<4xf32> into vector<4x4xf32>
    %1817 = vector.insert %1814, %1816 [2] : vector<4xf32> into vector<4x4xf32>
    %1818 = vector.insert %1814, %1817 [3] : vector<4xf32> into vector<4x4xf32>

The second issue is vectorToSCFOptions.enableFullUnroll() which turns this:
  vector.transfer_write %cst_0, %7[%c0, %15, %20, %21] {in_bounds = [true, true, true, true]} : vector<256x1x4x4xf32>, memref<256x112x112x64xf32>

into and endless stream of:
    %22 = vector.extract %cst[0, 0, 0] : vector<256x1x4x4xf32>
    vector.store %22, %7[%c0, %15, %20, %21] : memref<256x112x112x64xf32>, vector<4xf32>
    %23 = affine.apply #map()[%20]
    %24 = vector.extract %cst[0, 0, 1] : vector<256x1x4x4xf32>
    vector.store %24, %7[%c0, %15, %23, %21] : memref<256x112x112x64xf32>, vector<4xf32>
    %25 = affine.apply #map1()[%20]
    %26 = vector.extract %cst[0, 0, 2] : vector<256x1x4x4xf32>
    vector.store %26, %7[%c0, %15, %25, %21] : memref<256x112x112x64xf32>, vector<4xf32>

Full gist https://gist.github.com/KoolJBlack/9e3c451ea20344f1810498af3d95cc31
Trying to determine why this only affects convolutions.


DOC: Mention that a string without root element doesn't raise an error

See #8.

Thanks for merging!


Are the peer cache ports all TCP?

For those discussions with the network team :)
Port for the initial network broadcast to find a peer cache source. By default, this is port 8004.

Is this UDP?

Port for content downloading from a peer cache source (HTTP and HTTPS). By default, this port is 8003.

I'm assuming this is TCP but some folks might not be aware.

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

ID: bd7a196d-4829-4b01-0bc0-8c14fd52dc1a
Version Independent ID: db302fc5-0610-b270-0202-16fb4606a588
Content: Prepare Windows PE peer cache to reduce WAN traffic - Configuration Manager
Content Source: sccm/osd/get-started/prepare-windows-pe-peer-cache-to-reduce-wan-traffic.md
Product: configuration-manager
Technology: configmgr-osd
GitHub Login: @aczechowski
Microsoft Alias: aaroncz

Thanks @SLeuthold for the feedback. Here you go:

8004: UDP
8003: TCP

Should also note that here: https://docs.microsoft.com/en-us/sccm/core/clients/deploy/about-client-settings#client-cache-settings
And perhaps the best solution in both instances is to just link to the ports article which already has this information. 😄

Thanks to @jpcast88 for submitting some changes for this issue, which is why it's now closed. The changes should publish live tomorrow (Thursday, 20 June) around 11am Pacific time.


Add SPDM 1.3 new feature get_MEL for spdm_emu

This PR will pass the CI after the lisbspdm PR(https://github.com/DMTF/libspdm/pull/2635) merge.


#1832 Displaying locustfile and tasks ratio information on index.html

As discribed on #1832 , here is the suggested changes to allow displaying a bit more information about the current locustfile / tasks that will be executed in the Web UI.
About the look n feel any suggestions to make it looks nicer would be welcome.
Note this is a new PR as I had to rework my commits and so did hard push on my existing fork.
Tests are updated to match the new html title and other html output expected.
Can you please verify this one @cyberw  ?

Screenshot mentioning currently used script filename in the title of the browser tab:

Screenshot showing the tasks description , and script filename used.

Screenshot showing the tasks description , and script filename used in the report html.

LGTM! Would you mind moving the Tasks tab two steps to the right, between Exceptions and Download?

@cyberw just did in commit 8833ddb , let me know if that works for you.

Thx!


List drag and scroll does weird things when the first visible item moves

Not sure what the cause is, but I'm guessing it might actually be an issue with LinearLayoutManager

to comment those lines worked for me.
//    recyclerView.post(new Runnable() {
//                      @Override public void run() {
adapter.notifyItemMoved(fromPosition, toPosition);
//                     }
//                    });

Should this already have been fixed?
There's a comment in the code like  // fix for weird scrolling when animating first item... But the current version does not work correctly. If flaquir4's solution works, maybe there should be an else in the code to run the runnable only if fromPosition != 0 and  toPosition != 0?

MFlisar's fix works for me.


Jesse: Watch checkbill.pk

Jesse requests the watch of the watch_keyword checkbill\.pk. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

Approved by Mast in Charcoal HQ