[FIX] Fix mistake in FASTConvLayer and tf reparameterization

This PR:

Fix mistake in FASTConvLayer (special thanks to @czczup (FAST author) for finding this mistake)
Fix tensorflow reparameterization
Provide new pretrained backbone checkpoints
Add small test to check that reparam works as expected

Any feedback is welcome :hugs:
@odulcy-mindee Please upload the checkpoints before :)

@odulcy-mindee We should check the shrink_ratio with the latest checkpoint before :)

This is really great. Thanks for your time and effort!


Update the metric template

This makes a formal distinction between the formula to create the metric
(in pseudo code) and actual implementations, in code.

Yes. We have a similar approach with the WebIDL spec (browser vendors who are our implementors parse it to programmatically create JavaScript bindings).


[SP-5362] Backport of PDI-17733 - Relabel deprecated internal variables (8.3 Suite)

Attention: This is the outcome of an automated process!
Merge Masters: @ppatricio and @bcostahitachivantara
Cherry-picks:

https://github.com/Pentaho/pentaho-kettle/commit/1f3806b6c136ebcc26dd307e35485dbfba76b0b8

:white_check_mark: Build finished in 20m 35s
Build command:
mvn clean verify -B -e -Daudit -amd -pl core,ui

:ok_hand: All tests passed!
Tests run: 4641, Failures: 0, Skipped: 7    Test Results

:information_source:  This is an automatic message


Admin button to export user data

Coverage decreased (-0.08%) to 63.415% when pulling cad746c7f3ee09f65476eede7033f9648bee3956 on admin-export-data into c2121f437d2a6893951c062079ebc8a86721aba8 on master.

OK
On Jun 22, 2018 2:03 PM, "Nick Winter"<EMAIL_ADDRESS>wrote:
@nwinter commented on this pull request.
In app/templates/admin/administer-user-modal.jade
https://github.com/codecombat/codecombat/pull/4763#discussion_r197555144:

@@ -18,6 +18,7 @@ block modal-header-content
button#deteacher-btn.btn.btn-burgundy Deteacher
p
button#reset-progress-btn.btn.btn-burgundy Reset Progress

a#export-data-btn.btn.btn-primary(target='_blank'
href='/db/user/' + view.user.id + '/export-data') Export GDPR User
Data

Nah, I had it like that but I want this to open in a new page.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/codecombat/codecombat/pull/4763#discussion_r197555144,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AfygPYA_4kLTxxMOXrq04Vu732MIXvKDks5t_U2igaJpZM4UydnN
.

Looks good to me!


feat: allow alternative npm registry url

Adds preliminary support for alternate npm registry
Fixes #148

Hey @danieldelcore! Always happy to help.
I feel like the whole npmrc parsing, as you as well have pointed out, could get quite messy. It also seems to still be an option for the future, if the simple --registry and --registryToken approach turns out to be too limited.

I think your changes will work for public registries, but unsure of the best way to approach private registries and if that should change our overall strategy here thinking I'd love to get your advice if it's something you're familiar with.

For our current setup, we have a internal registry deployed which has no authentication read protection other than physical network access. But an approach without any authentication will obviously not work for private access registries on npm or anywhere else.
We have never had the idea of actually using the CLI in an CI environment. In our cases, we have always had a developer running an update on packages.

I'd love to add the --registryToken flag authentication to this PR as well and add some tests as well.

I'd love to add the --registryToken flag authentication to this PR and some tests as well.
That would be wonderful – thanks!

I agree, this approach seems like the best way forward and if we really need to go down the npmrc route and take on all of that complexity we can cross that bridge when we get there!
Thanks again! LMK when you're ready for a review!

@danieldelcore I have pushed a fixup with the following changes:

Added the registryToken flag as well to the CLI
Added registry and registryToken to the docs/website as well
Added some tests. For those I'm not sure how thorough I should go, as the majority of the logic is side loaded to the PluginManager anyways.

Let me know what you think.


wireframe for "Replaced backend_prefix regex with apiBasePathLooseRegEx"

pull requests: https://github.com/apinf/platform/pull/1964#issuecomment-265425561

added wireframes to the associated pull request

new wireframe has been added to the pull request.


Terraform support for Kafka Source

Is there any prevision for the implementation of a resource to track Kafka Source objects with the Terraform module?

I would also like to know if there are any plans for kafka source. This is a critical issue for my company.

I'm also in need of help with this. Do you have any plans to implement this one?


NLA Server Side Improvements

Fix sending of proper TLS alert code on authentication failure. Without this alert code, the Microsoft clients do not properly understand the reason for the disconnection, and do not present the authentication prompt to try authenticating again.

Make NTLM SAM file configurable through settings->NtlmSamFile, instead of using the hardcoded /etc/winpr/SAM file path. One can now call freerdp_set_param_string(settings, FreeRDP_NtlmSamFile, "/path/to/my/sam/file"); to set a custom path to an NTLM SAM file in the server.

@freerdp-bot test.

@awakecoding : I know it's in the title but I just want to be 100% sure: this PR doesn't affect at all the client implementations (xfreerdp, wfrerdp, ...), right?
thanks

@HenryJacques no worries, this really doesn't affect client-side NLA, only server-side.

@mfleisz @MartinHaimberger I made modifications according to the comments you made on this PR in my last commit.


Checks are not ignoring databases listed in parameter -ExcludeDatabase

-ExcludeDatabase ReportServer, ReportServerTempDB is not skipping the databases for all the tests.
Example of failed test.

I can confirm that this is not working in the current release 1.0.5 as expected.

-ExcludeDatabase does not seem to be functioning at all anywhere.

Executed Invoke-DbcCheck -SqlInstance localhost -AllChecks -ExcludeDatabase ReportServer and it still shows up on all of the tests

Yes, there are some checks that I have noticed that are missing the capability to exclude


Azure is quiet

Hi,
I have my JennyNeural voice, audio as here:

and importing as wav:

No errors, but still no sound from the voice when running the project.
Any suggestions?
Thank you.
Inese

Any advice please :)
If Azure would not work properly, then it should return an error, but there is no such...just quieteness.
Regards, Inese

Hi,
I have my JennyNeural voice, audio as here:
and importing as wav:
No errors, but still no sound from the voice when running the project.
Any suggestions?
Thank you. Inese

Are you play the audio data with your code or another plugin or save to disk? My plugin just get the audio data.

Hi,
On Success, I am conecting to Audio like this:

@inesevira
Hi, failed my blueprint logic.
I can't find the cause of the problem.
Maybe voice name is the problem?  i tried too javascript naming rule(en-US-JennyNeural).
I don't know this plugin's voice tag naming rule?


Match the dht api

Added the following:

this.destroyed
destroy({force})
server.dht, to listen on the this.dht.defaultKeyPair
server.closed

Things I couldn't add:

createServer() firewall feature.
Catching the error on node.ready() when the relay URL is invalid

API not yet tested from the dht README.md:

https://github.com/hyperswarm/dht#additional-peer-discovery
https://github.com/hyperswarm/dht#mutableimmutable-records
Anything API in the dht-rpc but not in the dht README.md

I'll see if I can get this included in #5 which will likely conflict with this PR anyway.

Firewalling is being added to #5 as well.


"Failed to parse bmc-info" when the system does not provide "System Firmware Version"

On my Supermicro servers, I'm getting the following error with the bmc collector enabled:
ERRO[0004] Failed to parse bmc-info data from [local]: Could not find value in output: Device ID             : 32
Device Revision       : 1
Device SDRs           : unsupported
Firmware Revision     : 1.52
Device Available      : yes (normal operation)
IPMI Version          : 2.0
Sensor Device         : supported
SDR Repository Device : supported
SEL Device            : supported
FRU Inventory Device  : supported
IPMB Event Receiver   : supported
IPMB Event Generator  : supported
Bridge                : unsupported
Chassis Device        : supported
Manufacturer ID       : Super Micro Computer Inc. (10876)
Product ID            : 6937
Auxiliary Firmware Revision Information : 00000000h

Device GUID : 00000000-0000-0000-0000-000000000000

System GUID : 00000000-d43a-46ef-ec3c-534d31303136
…

As you can see the BMC on SMCI doesn't always provide a System Firmware Version - can we make this optional?

I also noticed this a few days ago when trying out v1.3.0 for the first time. I initially thought it was just one extremely old SMC board, but it seems to occur on a wider range of systems than expected.

Thanks for the report! This is certainly a bit problematic, I had not thought of this scenario. I will try to release a fixed version ASAP

@dswarbrick FWIW, the boards for which bmc-info is not reporting a System Firmware Version are brand new.

Just because we love IPMI so much... I have an old SMC host that does not seem to like running bmc-info without the --get-device-id param, which was removed in https://github.com/soundcloud/ipmi_exporter/commit/2c6a73b1510cb1b6095feb5f18ed5d1da9823616#diff-f1c80b360812fd52bef43d56f3c4ef40853f02711810857332ccedfd9f463f79L291
$ bmc-info -l user -u MONITOR -p $password -h tank-ipmi
Device ID             : 32
Device Revision       : 1
Device SDRs           : unsupported
Firmware Revision     : 3.29
Device Available      : yes (normal operation)
IPMI Version          : 2.0
Sensor Device         : supported
SDR Repository Device : supported
SEL Device            : supported
FRU Inventory Device  : supported
IPMB Event Receiver   : supported
IPMB Event Generator  : supported
Bridge                : unsupported
Chassis Device        : supported
Manufacturer ID       : Nedam ENG. Co., ltd. (47488)
Product ID            : 43025

Device GUID : 00000000-0000-0000-0000-000000000000

System GUID : 00000000-dfad-2990-2500-534d31303037

ipmi_cmd_get_system_info_parameters_system_firmware_version_first_set: privilege level insufficient

The fact that bmc-info exits with status code 1 means that the collector is treating it as a failed command, which is fair enough. But it results in the ipmi_bmc_info metric disappearing for that host. We don't really want to use a higher privilege level for monitoring.

I discovered about another 40 more systems which now fail the bmc-info command. I did not previously see them because the ipmi_exporter was running with --log.level=fatal.
In addition to the privilege level error in my previous comment, I've seen some fail with:
ipmi_cmd_get_system_info_parameters_system_firmware_version_first_set: command invalid or unsupported

Oh my. Thanks for the detailed report. Give me a moment to figure out how to solve this mess somewhat gracefully...

Any chance this could be resolved before debian bullseye freeze? I'd quite like to update the package there (which I co-maintain), but am hesitant to use 1.3.x versions, as they will require a bit of patching to work around some of the rough edges.

Any chance this could be resolved before debian bullseye freeze? I'd quite like to update the package there (which I co-maintain), but am hesitant to use 1.3.x versions, as they will require a bit of patching to work around some of the rough edges.

Just wanted to provide a quick update: I had to take a break from maintenance for a while for private matters, sorry for letting this sit for so long. I am tackling this now, is before the hard freeze still sufficient, or is it already too late?

@bitfehler So long as the diff isn't too huge, we can probably still get it into bullseye, since it's not a new package - it will just take a bit longer to transition. Give me a shout if you need any additional testing on a zoo of old(er) IPMI beasts.

@dswarbrick could you let me know if #65 seems like a reasonable solution that does not involve refactoring the heck out of the exporter?
If you think it would help I would merge that and the (small) fix for #62 and then do another release, before doing a larger refactoring to account for the all the things i have learned about the dark sides of IPMI from maintaining this exporter for a while :innocent:

@bitfehler As I mentioned above, running bmc-info without --get-device-id results in a non-zero exit status for some devices, which makes the collector treat it as a failed command, despite the partially good output.
My hack that that I ended up applying to our inhouse packages was to explicitly run bmc-info <target> --get-device-id, which should generally be fine, and additionally run bmc-info <target> --get-system-info, which can potentially return non-zero - and in such cases, set the systemFirmwareVersion var to "N/A".

The idea was that if you run into this issue, you just use the bmc-device-id collector for these machines, which will only do --get-device-id and set the system firmware version to "N/A". I would like to avoid doing two roundtrips for a single collector, as each one is pretty costly with IPMI.

I agree that two IPMI roundtrips is not ideal, however it's not always feasible to know which devices are going to fail without the --get-device-id. And it means that we would need to group the scrape targets or somehow label them with the ipmi_exporter module that they should refer to in the scrape.

And it means that we would need to group the scrape targets or somehow label them with the ipmi_exporter module that they should refer to in the scrape

Hrm, that is a good point indeed, seems quite impractical.

Maybe if it didn't treat that as a completely failed command, it could parse the useful output of that command

I was hoping to avoid something like that, but it might actually be worth a try...

@dswarbrick how do you feel about https://github.com/soundcloud/ipmi_exporter/tree/bitfehler/bmc-info-recover ?

@bitfehler That looks pretty okay to me.

Cool. Could I get you to give that a spin? I don't have any such hosts available that would trigger this path...

Looks mostly fine, however it's going to be a bit noisy at log.level=error.
Feb 16 21:03:42 ber-prom1 prometheus-ipmi-exporter[31853]: time="2021-02-16T21:03:42Z" level=error msg="Error while calling bmc-info for tank-ipmi: Device ID             : 32\nDevice Revision       : 1\nDevice SDRs           : unsupported\nFirmware Revision     : 3.29\nDevice Available      : yes (normal operation)\nIPMI Version          : 2.0\nSensor Device         : supported\nSDR Repository Device : supported\nSEL Device            : supported\nFRU Inventory Device  : supported\nIPMB Event Receiver   : supported\nIPMB Event Generator  : supported\nBridge                : unsupported\nChassis Device        : supported\nManufacturer ID       : Nedam ENG. Co., ltd. (47488)\nProduct ID            : 43025\n\nDevice GUID : 00000000-0000-0000-0000-000000000000\n\nSystem GUID : 00000000-dfad-2990-2500-534d31303037\n\nipmi_cmd_get_system_info_parameters_system_firmware_version_first_set: privilege level insufficient\n" source="collector.go:278"

We're running most instances at log.level=fatal already however.

Thanks for the feedback, I demoted the severity of that log to warning. It was misguided to log an error at that point anyways. Current master should work ok for you now. I'll push one more fix and then make another release, the changes will be rather small compared to the next release, so I hope that works for you to get it into Bullseye.

Super, thanks for your perseverance on this one!


Put a filter in that prevents self-connection

With the multicast working the node is constantly trying to connect to itself because of hearing the advertisments, it should be ignoring its own advertisments and not even considering connecting to its' own IP/port combination.

several bits that seem to have fixed this problem, not sure exactly, somewhere in the last day of work.


Unsafe Vec::from_raw_parts

https://doc.rust-lang.org/std/vec/struct.Vec.html#method.from_raw_parts
Safety
This is highly unsafe, due to the number of invariants that aren't checked:

ptr needs to have been previously allocated via String / Vec  (at least, it's highly likely to be incorrect if it wasn't).

https://github.com/Kogia-sima/sailfish/blob/880cf9db5af79d8e74292d56bdf57089dacd8035/sailfish/src/runtime/buffer.rs#L102

There is no such a guarentee for String.
https://doc.rust-lang.org/std/string/struct.String.html#method.from_raw_parts


Detect mobile

How do you best want to handle the mobile vs desktop logic in the code? In previous projects, I have used a function to detect mobile and then set a variable isMobile, which can be used as a conditional in other parts of the code, such as SVG resizing. Do you have another approach you would recommend?

I researched this a few days ago and found this to look like a nice simple solution:
function detectmob() {
   if(window.innerWidth <= 800 && window.innerHeight <= 600) {
     return true;
   } else {
     return false;
   }
}

From https://stackoverflow.com/questions/11381673/detecting-a-mobile-browser

Looks good to me.


Implement quorum limit for search endpoints

Summary
Many endpoints respond only when a quorum of replicas have responded with what the actual response should be, however not all endpoints behave this way. As @rnewson said in Slack:

the _view, _find and _search endpoints read one copy of each shard range to form the response, there is no option to consult multiple copies, the code simply hasn't been written.

This can cause bugs in applications that make successive queries where these may be ultimately handled by different nodes.
Desired Behaviour
All endpoints to behave consistently using the default quorum which can be overridden (eg: with r and w query parameters). This makes the behaviour of endpoints consistent and therefore easier to develop against, but also means subsequent queries can be guaranteed to work given appropriate values for the quorum.
Possible Solution
Have these endpoints read all copies of the shard and respond when a quorum is achieved.
Additional context
We're upgrading from supporting single node to clustered operation and certain tests in our integration suite are failing too often.
Some workarounds we have considered include, using w=<replica count> everywhere, setting replicas to 1, and now investigating using sticky sessions so subsequent requests from the same client are handled by the same node. These have obvious drawbacks and none have been found (yet) to be 100% reliable.

This is non-trivial. The N copies of the database are not in the same order, and the indexes are in the order of the corresponding data shard. It is not just a case of reading multiple indexes to form a quorum.
The only plausible fix is to ensure that all the N replicas of a database are in the same order, which involves adding strong consensus.

as for "Many endpoints respond only when a quorum of replicas have responded" I think it's actually a minority. Specifically only those that read or write documents. Even that quorum is not guaranteed, couchdb will lower the quorum threshold all the way down to one if it believes the other nodes are unavailable (e.g, during a network partition that isolated a single node, that node would continue to serve read and write requests for the documents it hosts).


[Typo/Mistranslation] 04-create-dax-calculations-in-power-bi-desktop

On Practice 1, Task 2, step 2 and 6, columns and table names need to stay in English to prevent confusion.
Current:
영업 직원(성과)
영업 직원
판매
To be:
Salesperson (Performance)
Salesperson
Sales

Hello contributor,
Thank you for your contribution! We are processing your suggestions and we will update you shortly.
Kind regards,
Microsoft Worldwide Learning Team

Locfile InLoc at present - need it to be at HB to make the fix.

Blocked

Updated last handedback locfile


render of "term" failed: execute of template failed

Hi, trying to run this theme and getting the below error when executing "hugo serve" using Hugo 0.74.2:
Building sites … ERROR 2020/07/19 18:47:14 render of "term" failed: execute of template failed: template: _default/list.html:26:74: executing "bottom-menu" at <partial "bottom_menu.html" (dict "Page" . "show_back_menu_item" false)>: error calling partial: "/Users/folder/themes/sam/layouts/partials/bottom_menu.html:1:10": execute of template failed: template: partials/bottom_menu.html:1:10: executing "partials/bottom_menu.html" at <(.Page.Site.Params.mainMenu) (.show_back_menu_item)>: can't give argument to non-function .Page.Site.Params.mainMenu
ERROR 2020/07/19 18:47:14 render of "term" failed: execute of template failed: template: _default/list.html:26:74: executing "bottom-menu" at <partial "bottom_menu.html" (dict "Page" . "show_back_menu_item" false)>: error calling partial: "/Users/folder/themes/sam/layouts/partials/bottom_menu.html:1:10": execute of template failed: template: partials/bottom_menu.html:1:10: executing "partials/bottom_menu.html" at <(.Page.Site.Params.mainMenu) (.show_back_menu_item)>: can't give argument to non-function .Page.Site.Params.mainMenu
ERROR 2020/07/19 18:47:14 render of "term" failed: execute of template failed: template: _default/list.html:26:74: executing "bottom-menu" at <partial "bottom_menu.html" (dict "Page" . "show_back_menu_item" false)>: error calling partial: "/Users/folder/themes/sam/layouts/partials/bottom_menu.html:1:10": execute of template failed: template: partials/bottom_menu.html:1:10: executing "partials/bottom_menu.html" at <(.Page.Site.Params.mainMenu) (.show_back_menu_item)>: can't give argument to non-function .Page.Site.Params.mainMenu
ERROR 2020/07/19 18:47:14 render of "term" failed: execute of template failed: template: _default/list.html:26:74: executing "bottom-menu" at <partial "bottom_menu.html" (dict "Page" . "show_back_menu_item" false)>: error calling partial: "/Users/folder/themes/sam/layouts/partials/bottom_menu.html:1:10": execute of template failed: template: partials/bottom_menu.html:1:10: executing "partials/bottom_menu.html" at <(.Page.Site.Params.mainMenu) (.show_back_menu_item)>: can't give argument to non-function .Page.Site.Params.mainMenu
Built in 14 ms
Error: Error building site: failed to render pages: render of "term" failed: execute of template failed: template: _default/list.html:26:74: executing "bottom-menu" at <partial "bottom_menu.html" (dict "Page" . "show_back_menu_item" false)>: error calling partial: "/Users/folder/themes/sam/layouts/partials/bottom_menu.html:1:10": execute of template failed: template: partials/bottom_menu.html:1:10: executing "partials/bottom_menu.html" at <(.Page.Site.Params.mainMenu) (.show_back_menu_item)>: can't give argument to non-function .Page.Site.Params.mainMenu
Running Hugo Static Site Generator v0.74.2/extended darwin/amd64 BuildDate: unknown on osx.
Cheers!

Thanks @agouny! I can't seem to replicate this error, so I'm opening this issue for help. If you have more information to share, or you're willing to open source your site, that might help the diagnostic process.

hugo version：
│╰─ hugo version
│Hugo Static Site Generator v0.74.2-48565DE6 linux/amd64 BuildDate: 2020-07-17T17:25:56Z
Replicate the problem.
### Solution:
Change file layouts/partials/bottom_menu.html line 1
Origin:
{{ if or ((.Page.Site.Params.mainMenu) (.show_back_menu_item)) }}
To:
{{ if or (.Page.Site.Params.mainMenu) (.show_back_menu_item) }}
It seems the go template upgrades, the most outer square make a function call.

Thank you @oopschen!
@agouny This was changed in https://github.com/victoriadrake/hugo-theme-sam/commit/e3f815d908963d5b901fd793e1641a83f6d6af29#diff-fed0815ec9f8e8bfb810282b95e0f43b. Can you confirm you're running the most current version of the theme?


Clarify Ion MIME type

Hi all – I see application/ion listed as a provisional MIME type at IANA. Question: Is this MIME type for our Ion, or a different Ion?
Note that there's another Ion, featured here. I'm not sure what the status of that project is, but this article says that its MIME type is application/ion+json.
If application/ion is indeed meant to be the MIME type for our Ion, this should probably be noted in the docs.

That is the MIME type for Amazon Ion. You can find more details here: https://github.com/amzn/ion-java/issues/82.
I will leave this issue open until we make progress on that process and add a note about the MIME type to the docs.


Make package Capacitor 6 compatible

To test:
npm install github:piotr-cz/capacitor-android-dark-mode-support#feature/capacitor-6

This repository is deprecated as this plugin should no longer be needed, see this comment. For this reason, I am closing this PR.

This repository is deprecated as this plugin should no longer be needed, see this comment. For this reason, I am closing this PR.

That comment applies to WebView versions >= 100, but Capacitor requires  >= 60.
There is an edge case when user installs a capacitor app, but doesn't update WebView or is not able to update it (on older Android version).
See https://stackoverflow.com/a/61643614/1012616

Okay, I will publish a Capacitor 6 compatible version in https://github.com/capawesome-team/capacitor-plugins.

See https://github.com/capawesome-team/capacitor-plugins/pull/308


无法删除聊天

好像API无法删除聊天，返回如下错误：
claude-to-chatgpt-api-1  | delete err: delete chat conversations errInternal Server Error xxxxxxxxx
claude-to-chatgpt-api-1  | [GIN] 2023/08/27 - 12:58:17 | 200 | 17.896308744s |   <IP_ADDRESS> | POST     "/v1/chat/completions"
claude-to-chatgpt-api-1  | delete err: delete chat conversations errInternal Server Error xxxxx
claude-to-chatgpt-api-1  | [GIN] 2023/08/27 - 12:59:24 | 200 |  5.202486228s |   <IP_ADDRESS> | POST     "/v1/chat/completions"
查看网站上有很多标题为“Untitled”的“chat”

Same issue but its still working, no problem

I am only a novice so likely wrong, but given this is uses the OpenAI-API Interface as a reference, I don't believe clearing chats would be possible.  Secondly, I thought Anthropic, keeps the chat history on the browser, not the server end.
What are you using on the front-end?

The chat history is saved on the server, because after replacing the browser, the chat history still exists.
I think this is unrelated to the frontend, I get the same results using different frontends, for example ChatGPT-Next-Web, OpenAI Translator


Edit: using cursor keys off end of edited text loses focus

On the edit tutorial with no cellNav: http://ui-grid.info/docs/#/tutorial/201_editable, if you start editing a cell then use the arrow keys to go to the end of the data, it will navigate off the end of the cell and lose focus (OSX and Chrome, in case this is OS/Browser dependent).
I think this is a duplicate, and will later look for the matching item.

@PaulL1 after several iterations, my solution was to turn off grid scrolling while in edit mode. You can't ignore scroll events and Chrome is firing a scroll event for the parent container when you are at the end of the text.  I think this is bad behavior from Chrome, but we probably have to live with it.
What I did was change the rendercontainer overflow style to hidden when editing.  This has the effect of turning off scroll bars when in edit mode.  What do you think?
You can see the fix here: https://github.com/angular-ui/ng-grid/tree/Fix-3128

It sounds reasonable to me, if perhaps prone to giving us some sort of artefacts when the scrollbars come and go.  I'm on a Mac so I don't see scrollbars anyway, so for me it works fine.  When I turn scrollbars on it also works fine.  I'd go ahead and merge it, one more defect off our list.

Scrollbars are removed from viewport if in deep edit to prevent any browser trigger scrolling


OCBBlockCipher license prevents from using bcprov artifact in some legal contexts

Eclipse ecosystem does use the bcprov jar extensively for some actions (download PGP signatures check, Git commit signatures...). Some Eclipse IP rules are checked to verify the library that are used do not introduce some legal risk upon the Eclipse project and its adopters. Those rules have determined (for a long time) that OCBBlockCipher is such a legal risk; and there has been a habit of using a and delivering a re-packaged bcprov to exclude this particular class in most Eclipse distributions. However this situation is a bit cumbersome as the Eclpse ecosystem is getting closer from Maven one and would like to avoid having parallel artifacts.
The particular concern is expressed at https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/3286#note_1020671 ( @waynebeaton can probably tell more if you ask him).
What we'd love to see is a solution that would make bcprov "safe" to use as-it from IP perspective at Eclipse. One proposal can be for example that the OCBBlockCipher get moved to another artifact, either an existing one with other IP-challenging stuff, or into its dedicated bcocb artifact, to clean the central bcprov from this particular concern.
Are there other approaches one can recommend? If not, is the former proposal acceptable? We could most likely take care of implementing the refactoring if the proposal is acceptable.

In view of:
https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/
Would you clarify what the risk is?

@dghgit thanks, I was not aware of that. I'm not the one who actually evaluate whether there is a legal risk or not (this service is provided by Eclipse Foundation, @waynebeaton would be the representative here). I'll make sure they are aware of this matter and can decide to re-evaluate that. In the meantime, I think that the OCBBlockCipher.java file should then present an updated header, clarifying that the underlying algorithm is public domain and dropping everything that mentions patent.

I'm pretty sure that this is good news. I'll need go through our notes to confirm, but this is helpful. Thanks @dghgit.

Good point, I'll get the JavaDoc updated as well.

JavaDoc now updated to properly reflect the current standing, having including the owner's original text as well.

Thank you very much @dghgit , your insights here have drastically improved things on Eclipse end!


RFC: Marking events using @eventClass and/or @eventProperty

We have two different API Extractor consumers who define class "events".  In C# this is formalized via an event keyword.  Although the TypeScript language doesn't model events, it's fairly easy to simulate.
You define an "event class" (e.g. SPEvent) that allows adding/removing handlers:
class FrameworkEvent<TEventArgs extends FrameworkEventArgs> {
  public add(eventHandler: (eventArgs: TEventArgs) => void): void {
     // ...
  }
  public remove(eventHandler: (eventArgs: TEventArgs) => void): void {
     // ...
  }
}

And then you expose readonly-properties (e.g. ApplicationAccessor.navigatedEvent) returning this object:
class MyClass {
  public readonly navigatedEvent: FrameworkEvent<NavigatedEventArgs>;
}

And then users can attach an event handler like this:
const myClass = new MyClass();
myClass.navigatedEvent.add((eventArgs: NavigatedEventArgs) => {
  console.log('Navigated to:' + eventArgs.destinationUrl);
});

The feature request is for the documentation tool to group members like navigatedEvent under an "Events" heading, instead of the usual "Properties" headings.
Proposed Solutions
We're proposing three approaches to support this:
1.  Mark up the class:  Define a TSDoc tag @eventClass  for the class:
/**
 * This is the class used to represent API events.
 * @eventClass
 */
class FrameworkEvent<TEventArgs extends FrameworkEventArgs> {
  public add(eventHandler: (eventArgs: TEventArgs) => void): void {
     // ...
  }
  public remove(eventHandler: (eventArgs: TEventArgs) => void): void {
     // ...
  }
}

Based on this, ideally a tool like API Extractor would recognize any readonly property that returns FrameworkEvent, and automatically classify that as an “event” in the documentation.
2. Mark up each event property: Define a TSDoc tag @eventProperty which needs to be applied to each individual property.  This more work for API owners, but it has the benefit of being more obvious to API users who will see these comments in the *.d.ts files.  Also it can handle edge cases where something has a signature that looks like an event, but wasn't intended to be.  Example:
class MyClass {
  /**
    * This event is fired whenever the application navigates to a new page.
    * @eventProperty
    */
  public readonly navigatedEvent: FrameworkEvent<NavigatedEventArgs>;
}

3. Both:  If we supported both tags, then you would manually mark individual properties as in #2, but a tool like API Extractor can use the information from #1 to find places where @eventProperty is missing or improperly added, and issue appropriate warnings in "strict mode".
NOTE: JSDoc already defines an @event tag with different meaning, so the proposed tags were chosen to avoid conflicts/confusion.

@mpasarin @dend @AlexJerabek FYI

I'm down for option 2, since it mirrors reality the closest.

I'd say also consider the eventbus ala pub / sub angle too. Here is a recent random Microsoft doc on it...

I have a slight preference for #2, but I'm fine with #1 too.

@eventProperty supports one style of events, and while the type of event it describes is common in the C# land, it does not capture all common patterns in JS/TS.
Node provides the EventEmitter class. This class lets users emit events by a string (or potentially symbol) name. This can be made more strongly typed (example), but TSDoc doesn't provide any standard way to document these events.

JSDoc uses the @event tag to describe what is emitted under a certain name
TypeDoc uses the @event tag to group properties together under an "events" group, but doesn't provide any nice way to specify the type of the object(s) emitted.

How should we document this code?
class Foo extends EventEmitter {
  static readonly START = 'start' // doc comment here?
  static readonly END = 'end'

  doSomething(arg: number) {
    this.emit(Foo.START, 'doSomething', arg)
    // do work
    this.emit(Foo.END, 'doSomething', arg)
    return work
  }
}

🤔 Is there maybe a clever way to use the TypeScript type system to describe the events that can be fired?
Do you have an example of a real API documentation website (generated by JSDoc or TypeDoc) that shows how the @event tag is processed?

Sorry for the delay here, TypeDoc uses @event to place members tagged with it under a separate heading.

https://typedoc.org/api/classes/converter.html

Yes, there's a clever way to describe the events that can be fired, linked under example in my previous reply. The trick is to make the class generic on an event map.

In the apps I'm working on we use some sort of publisher pattern (not really a pubsub but kind of : @qphi/publisher-subscriber) so declaring the events on the classes themself doesn't work. Instead we use enums (or plain const: Record<string, string>) being able to mark an enum member as an event of a given class (or the whole enum maybe) would be handy

In our product code we dispatch custom custom DOM events from our custom DOM elements. And of course standard DOM elements also dispatch standard DOM events in the same way which are currently not yet documented by the lib.dom.d.ts documentation.
This could potentially also be very useful for supporting more advanced linting to check whether the type of an event listener is correct for the related element(s). All TypeScript currently supports there now AFAIK is the GlobalEventHandlersEventMap and I understand that events can bubble so that makes some sense. But in many cases events don't bubble and it would be great if we could enable strict type checking there. I guess I could also override the types of addEventListener() and removeEventListener(), but that would be cumbersome and still not reliable cover all uses.
I currently declare custom events like so, p.e. in LiveryErrorEvent.ts:
declare global {
  interface GlobalEventHandlersEventMap {
    'livery-error': LiveryErrorEvent;
  }
}

/**
 * Dispatched when an error occurs.
 *
 * @group Events
 */
export class LiveryErrorEvent extends Event {
  /**
   * Event type.
   */
  static type = 'livery-error' as const;

  constructor(
    /**
     * Error that occurred.
     */
    readonly error: Error,
    init?: EventInit,
  ) {
    super(LiveryErrorEvent.type, init);
  }
}

Then I document our class LiveryPlayer extends LitElement (from Lit which in turn extends HTMLElement) with a list of:
/**
 * This can dispatch the following events:
 * - {@link LiveryErrorEvent | livery-error} - Dispatched when an error occurred
 */

As that looks better at tsdocs.dev then using the old JSDoc @fires syntax.
E.g. see<EMAIL_ADDRESS>But what I'd really like to have standard support for is something specifically suitable for DOM events, let's call it: @dispatches, p.e:
/**
 * @dispatches {LiveryErrorEvent} livery-error - Dispatched when an error occurred
 */

So similar in syntax to @param but linking to the related event class and specifying the event type value that it is dispatched with and can be listened to and a description.
This would not only facilitate writing such documentation, but theoretically also enable checking it for correctness and refactoring etc. It could be used by standard and custom elements to declare which events they can dispatch in general. But also by element methods to point to events that could be dispatched as a result of calling that method. And perhaps also by element properties to point to the events that are dispatched when the property value is changed.


Abstract away explicit context passing

Currently, the type checker explicitly takes and returns the bidirectional typing context. As OCaml is not a purely functional language, there's no real need to explicitly thread through state like this, as mutable state is free game.
Another approach that helps keep purity is through a monad. Unfortunately unlike Haskell, composing and unwrapping monad stacks isn't as easy.

I've looked into using functor modules to inject state for tracking the bidirectional typing context and I've come to the conclusion that ergonomically, it's no different than simply just doing the context passing.
At the very least, passing something like an environment would be much more suitable in this scenario, and I'm much more open to that being introduced through a functor module instead of explicitly tracking the context as well.

Closing in favor of a better approach.


[WIP] Fix failed to load sdk dll in unit tests

:white_check_mark: Build AElf <IP_ADDRESS>64 completed (commit https://github.com/AElfProject/AElf/commit/54e6609fca by @jason-hoopox)


Not working with "auth-user-pass"

Hi the application is not working useing auth-user-pass authentication .
It asks for username and password but nothing happens and simply disconnect. If you specify username and paswword directly on the code it does not work either.
Do you have any advice ?
Thank you

The auth code has been removed, because it was buggy.

Hello, if it can be useful, if you sepecify
vp.mAuthenticationType = VpnProfile.TYPE_USERPASS;
vp.mUsername = "yourusername";
vp.mPassword = "yourpassword";
it work, so I thinh it is just the "switch" which identify the authentication type which is buggy

First it worked well, but sometimes the UI does not show up and show an error
@Pecana you can contribute to this repository with your suggestions


Checked the window of AmongKey during game and it looks like it isn't noticing you're in the chat, but it still thinks you're playing the game. Right here it says ingame, but it is in chat:


Draft: MD workflows

Summary of Changes
Before going further a little consultation:
MD users use workflows all the time, just for the NVE example in this commit there is pretty much a thousand ways you can run that; doing a first NVT to relax to the desired temperature, or a first NPT to relax to the desired density, etc...

For example, should we have one NVT workflow with a parameter "thermostat", or one workflow per thermostat?
If you want things to be in recipe.common, atoms will have to be sent in with a calculator already attached, is that what you want?
From what I understand you want to keep things simple (not something like the code here), users then build their workflows to get what they want.
In any case, for now doing these kinds of workflows is difficult, because it is generally hard to transfer results between ASE calculators, which will always happen between runs, this is critical since MD needs momenta and forces to ensure proper continuation. (This is a problem I would like fixed above since it also causes problems when restarting optimization etc)

Checklist

[ ] I have read the "Guidelines" section of the contributing guide. Don't lie! 😉
[ ] My PR is on a custom branch and is not named main.
[ ] I have used black, isort, and ruff as described in the style guide.
[ ] I have added relevant, comprehensive unit tests.

Can one of the admins verify this patch?

Happy to respond but before I do, I just wanted to check that this is the full commit you wanted to share --- just the args/kwargs, right?

@tomdemeyere: Happy to respond to each question but before I do, I just wanted to check that this is the full commit you wanted to share --- just the args/kwargs, right?
(In short, I really would love to have MD flows and am willing to work together to figure out how to get this done the best way possible)

Yes, before doing more I wanted to make sure we are on the same page.
I guess my main question here is: how to make these flows common to all codes? Should they call code specific MD jobs? Or, should a calculator be attached to the Atoms object being sent to the MD flow?
Once I know this we can work on details

I guess my main question here is: how to make these flows common to all codes? Should they call code specific MD jobs? Or, should a calculator be attached to the Atoms object being sent to the MD flow?

Good question.
Personally, I think what would likely make the most sense is to make a run_md function in quacc.runners.ase that would take an Atoms object with an attached calculator just like the other methods in there. You likely were aware of that already.
From there, we get to the recipes, and my answer is: "it depends." If it is just a simple @job (i.e. not a @flow), then this is no different than a relaxation job --- one would just be calling run_md instead of run_calc or run_ase_opt. Since there wouldn't be much logic beyond the simple function call, this is fine. In fact, I don't really intend most users to call the common recipes directly. They are there to reduce code duplication, but most users aren't comfortable using them directly. I would treat the individual MD jobs in the same way as a relaxation --- we have a runner, which is called in the various recipes where it is appropriate. For instance, we would make an qucc.recipes.emt.md.py and such. It does mean that there would be multiple MD modules, but we would need that anyway because every code will have different parameters (defaults) that are needed to properly run an MD calculation. There are other nuances for why this suggested approach is ideal related to (de)serialization that I won't bore you with (namely, the outermost @job/@flow, i.e. the one directly called by the user, must have arguments that are all pickle-able, and keyword arguments must be JSON serializable for the various workflow engines to function properly --- and the current code layout permits this).
If we are talking about a @flow where there are multiple Jobs being stitched together, and we anticipate this pattern (i.e. the workflow DAG) to be calculator-agnostic, then we'll put that in common. This is the philosophy behind the existing common recipes.
To get started, I would suggest making quacc.runners.ase.run_md and then a simple demo for a cheap-to-run calculator, like EMT or LJ. That will likely be illustrative and help guide the design further.

For example, should we have one NVT workflow with a parameter "thermostat", or one workflow per thermostat?

If the workflow logic is staying the same regardless of thermostat, then I would suggest one job/workflow where thermostat would be a keyword argument with a sensible default.

If you want things to be in recipe.common, atoms will have to be sent in with a calculator already attached, is that what you want?

See comment above. If we are talking about a @job, then that would call run_md and be specific for the code since we need to set some sensible default parameters. If it's a @flow pattern, that can go in common but would not require passing in Atoms objects with attached calculators --- it would require passing in one or more Jobs.

From what I understand you want to keep things simple (not something like the code here), users then build their workflows to get what they want.

Hard for me to tell from the commit you shared here, but I am not opposed to complexity. In fact, we should not rely on the users to build something complex. If the @flow pattern is "trivial", like a relax then an MD run, it is debatable if we should make that its own @flow or not (honestly, it can go either way). But if it's more complex, for sure we should.

In any case, for now doing these kinds of workflows is difficult, because it is generally hard to transfer results between ASE calculators, which will always happen between runs, this is critical since MD needs momenta and forces to ensure proper continuation. (This is a problem I would like fixed above since it also causes problems when restarting optimization etc)

This is a good point. However, I think it is solvable. Let's circle back to this when the time is right.

@Andrew-S-Rosen Thanks for all these details. I will come back to it at some point

@Andrew-S-Rosen I think this is now a good point to have your input

Thank you for kicking this off, @tomdemeyere! Really appreciate the contribution!
This is looking good. I have some comments that are mostly related to some minor restructuring.
Starting with this isolated EMT example is very helpful for me in understanding the process and figuring out what should be refactored, so I thank you for doing that.

I see that your comment is different than the one I received by email from git. But yes, originally my plan was to have these "_base" functions. Either per calculator or in common like you previously said.
After discussing that along with other details I was then planning to introduce recipes for the other ensembles (NVT, NPT).

I see that your comment is different than the one I received by email from git. But yes, originally my plan was to have these "_base" functions. Either per calculator or in common like you previously said.

Apologies about the edits! I was trying to sort out where to place them and was going back-and-forth so decided to just save it for a future discussion to avoid confusion. But you got the right idea anyway.

After discussing that along with other details I was then planning to introduce recipes for the other ensembles (NVT, NPT).

That would be great!

Didn't see your comments originally (github mobile) will work on it at some point

Thank you!

Few comments:

Without run_kwargs there is no way to pass things to dyn.run()
There is still a check_convergence, although it does not make much sense for MD. By definition you reached the max number of steps, but there is a case where it makes sense:

We are currently working on a error-free quacc as part of another project. We make sure that quacc always reaches the point of writing to the database: it writes the errors that occurred, along with the available results, if any (the errors might happen at some point during the MD, previous results should be returned, actually in some cases, errors might even be part of your journey (although this might not be what Quacc was originally made for)). Currently if one is running a bunch of simulations, if errors occur, there will be a bunch of directories with no really easy way to figure things out.
Because you said you might be interested in error handling I am leaving that there.

I change how temperature/time etc... is handled, feel free to tell me what you think

Without run_kwargs there is no way to pass things to dyn.run()

The fmax and steps are already passed in quacc.runners.ase.run_opt, and .run() doesn't take any other keyword arguments, so that should be fine.

There is still a check_convergence, although it does not make much sense for MD. By definition you reached the max number of steps, but there is a case where it makes sense:

I agree that a check_convergence doesn't make much sense for this job type. We should remove that logic entirely.

We are currently working on a error-free quacc as part of another project. We make sure that quacc always reaches the point of writing to the database: it writes the errors that occurred, along with the available results,

There is a global setting CHECK_CONVERGENCE. One could catch the typical RuntimeError errors when ASE is called and try to give the user some flexibility via the global settings about how to handle things with the CHECK_CONVERGENCE or some other global parameter. But of course, feel free to continue doing what you're doing!

Currently if one is running a bunch of simulations, if errors occur, there will be a bunch of directories with no easy way to figure things out.

Indeed. This is a limitation of Parsl, which is really best thought of a task manager. Other true workflow tools like Prefect or Covalent have a separate database for the task metadata and would highlight when/where the job fails. But since Parsl does not have a task database, there is no mechanism to easily store that info. The recommended approach would be to launch your calculations in a for loop and log any errors from the Parsl AppFuture. But of course, your mechanism is fine as well.

I changed how temperature/time etc... is written to results, feel free to tell me what you think

I like that a lot more!

@tomdemeyere Thank you for addressing my comments! This looks good to me. How are you feeling about the state of this PR?
I will likely go ahead and refactor summarize_md_run and run_md afterwards since there is some copy/paste between methods that we can likely reduce. But that's something I'm happy to sort out.

I just changed the whole microcanonical thing to "md_job" because there will not be any major differences between these jobs except from Quacc point of view.
ASE has a lot of deprecated keywords, such as "temperature" or "pressure" which should be written as "temperature_K" or "pressure_au". Except... for some MD classes where they are perfectly fine 👌. Anyway, what I do here is: I change everything to what is normally expected, In Quacc if the user input "temperature" or "temperature_K" they will both work in Kelvin (A message will be printed in the first case). Feel free to change this behaviour if you want.

Momenta (results in general) has to be carried from job to job, this is a hard requirement, without this, flows do not make sense for MD jobs. For now, when setting a new calculator in the next job previous results will be erased.

fixcm and fixrot have been changed to fix_com and fix_rot, which I prefer as well, but fixcm and fixrot from ASE are still a thing in some ASE MD classes and might confuse people.

Note to self: there are some interesting ideas in https://github.com/materialsproject/atomate2/pull/722/files#diff-ae55fbbe68bef6a3e4bd052ea86c473adb44a91b440d2abb63a89ff1be198fe7 by Materials Project colleagues.

Note to self: there are some interesting ideas in https://github.com/materialsproject/atomate2/pull/722/files#diff-ae55fbbe68bef6a3e4bd052ea86c473adb44a91b440d2abb63a89ff1be198fe7 by Materials Project colleagues.

FYI: I didn't give up on this P:, I have some other things to finish first. Also, in the meantime I want to think about what would be the best way to proceed with this

All good! I also have this on the backburner to think about some more.

Some progress! I think I would like to take advantage of this merge request to fix a few things on ASE's side. Currently there are multiple problems:

Some Molecular Dynamics classes simply can't restart correctly (NPT)
During a restart, one configuration will always be calculated, twice.
No units convention.

This makes ASE simulations not (or hardly) reproducible, which is a big deal, in my opinion. Something that would greatly increase the reproducibility of ASE simulation's, and fix the problems above is to allow a verbose mode, where the state of each object involved is written to the disk in a json format (Calculator, Profile, Template, Dynamics) if applicable.
This json format would allow to instantly recreate the objects as well. What do you think?

Thanks for the update! I think improvements on the ASE side are always welcome. I will give this (and your other PRs, e.g. in ASE and here) a more detailed look later this week. Just got back from travel so am a bit behind.

This should be close to go, there is still something essential before being able to run MD correctly: restarts. They are still difficult to do (impossible in some cases), but that's an ASE problem. I suspect this will take ages to fix; for now I deleted everything related to restart while we wait to see what solutions will get accepted upstream (if any).
I looked at automate2, there are indeed some interesting things, like the possibility to specify a temperature/pressure gradient. I will charge back with my idea of "patches" to accomplish that, this would look like:

steps = np.arange(1000, 10000, 1)
temperatures = function_of_steps(steps)

my_temp_gradient = TemperatureGradient(steps, temperatures)
my_file_copier = FileCopier(interval = 10)
my_press_gradient = PressureGradient(...)

md_job(... patches = [my_temp_gradient, my_file_copier, my_pressure_gradient])

This is achievable by tuning the generator as you did previously (although it might get packed), for some reason I love this "patching" concept 😅. People could fine-tune their MD, picking what triggers when, Quacc could even have a section in the documentation explaining how to do complex things as we already discussed. Anyway, daydreaming here 🙃

Thanks for your persistence with this! I will try to look at this within the next few days (please ping me if I forget). I'm definitely interested to chat more about the patches idea here; perhaps within the context of MD, it could be an interesting proof-of-concept to think about. I'll revisit this when I have the time to give this a proper review!

Some news on this? Just to know if it is waiting on https://gitlab.com/ase/ase/-/merge_requests/3310

@tomdemeyere: Thank you for your enormous amount of patience with this PR. I didn't see your comment from 3 weeks ago, so my apologies about not responding and for keeping you in the dark about this.
The reason I had been reluctant to merge this was that there was a fair bit of refactoring I wanted to do to remove code duplication in the run_md method and also in the schema. This was dependent on some other PRs I had in the pipeline. I was finally able to devote time to do so properly, and now it is much cleaner. 👍 I didn't change any functionality (to the best of my knowledge).
At this point, I am quite pleased with this. Whenever you have a moment, however, I have a few remaining questions outlined below. I am happy to take over of any (small) changes that result from my questions --- but I wanted to get your professional input before attempting to proceed since I am not an MD expert. Finally, before I merge, if you have a moment to look at a similar attempt recently implemented in matcalc, it'd be nice to know if we are missing anything particularly useful that's in there. For instance, there is something about upper triangular cells that is entirely foreign to me.

I had a look at the code you sent me and I am afraid I have never had issues with the upper vs lower triangular matrix (mainly because I don't often run NPT) but from what I understand this is taken care by a PR in ASE (https://gitlab.com/ase/ase/-/merge_requests/3277) by just modifying the NPT class without the need of modifying the atoms object like in matcalc.
For more context: left is my slab before, right is the slab after being passed in matcalc.

To refresh the current challenges in this PR:

The lack of proper restart, which breaks the purpose of "MD workflows"
Choose a convention for the units being used and make sure that it is clear and user-friendly

For the first point, I am afraid this is not for today :/. For the later I tried to make things as clean as I could but of course feel free to discard these suggestions and do as you like.

Thanks for the reply, @tomdemeyere! Regarding the triangular stuff, thanks for linking me to the MR. If this is just an ASE bug/inconvenience, we will take care of that upstream. I'll keep tabs on the MR.
As for this PR, not to worry about restarts. I don't think it is a dealbreaker, and I disagree that it defeats the purpose of a workflow. After all, one might want to do a non-MD job afterwards (e.g. a DFT relaxation) which would be fully supported. It's just that MD-->MD might be tricky. I wouldn't let that hold up this PR. Let me know if/when your upstream ASE MR though needs any attention from me.
The second point is really the only one I feel is necessary to make sure we get right. I trust your opinion on this and am content with leaving it as-is.
So, I think the plan (unless you disagree) should be:

I'll monitor the conversation at https://gitlab.com/ase/ase/-/merge_requests/3391 to see if there's anything productive that might turn up in the short term.
Assuming the above answer is no, I'll go ahead and merge this PR pretty much as-is sometime next week.

Thoughts?

Oh, but also I still had the question about fixcm and fixrot. Did we need to rename them for some reason?

Oh, but also I still had the question about fixcm and fixrot. Did we need to rename them for some reason? Was that also an internal consistency thing?

Most of the time you will find fixcm but occasionally you might find fix_com (mostly internally) I prefer fix_com so I used that (it is less obscure in my opinion) but I don't feel strongly about it, change it as you want.

FYI: I have seen all your comments, but I am moving right now. I will make sure to come back to it ASAP 😀 !

No worries, @tomdemeyere! I have been kind of going back and forth on a bunch of things, so I'm sorry about all the spam here. 😅 I should be done for now. Hopefully sometime later you can take a look and tell me what's a good or bad idea from here. Thanks for understanding.
I'm also moving next week!! Good luck with your move!

When you have a moment, could you please re-review the changed files and see if this is to your liking?

I think it's nice (I skipped the part where the runners have been changed to a class!) you changed fix_rot and fix_com to set_zero_rotation and set_stationary my only concern here is that it is not immediately clear what set_stationary is, but with a little bit research this should be ok on the user side (zero_com_momentum, zero_angular_momentum might be better? I don't know)

In the quacc.recipes.emt.md.md_job recipe, I thought it would be nice to have temperature, pressure, and timestep as dedicated keyword arguments like what is done here. This is because the parameters are so critical to running MD and because it will potentially help clarify that users should be playing by "our rules" in terms of units. I have made that change accordingly. What do you think?

When I initially tackled the problem I had a few points in mind:

Convention/units choice has to be uniform and well-thought: Kelvin for temperature, femtosecond for time, GPa for pressure... All these units are widely used, and they are all powers of SI units, so Quacc somehow follow international conventions.
Users must be able to understand quickly what's going on, despite ASE being a mess on this side, this is especially challenging since some ASE's MD use different units with similar keywords.

With that in mind I was planning to add Quacc specific keywords such as "temperature_K", "pressure_gpa", and "timestep_fs", so that it would be clear that Quacc follow a different convention than ASE. ASE base keywords would still be allowed inside the kwargs. The problem with this approach is that it is not uniform; additional keywords (compressiblity, taut, etc) which are class specific are not integrated and will not follow the same convention, except if Quacc keeps track of every keywords, but that's a lot of burden on the dev side.
Instead, I went all-in by forcing every ASE keywords (deprecated or not...) to follow Quacc's new convention.

I have made that change accordingly. What do you think

Pressure might be a little bit tricky, because NPTBerendsen expects a scalar while NPT (Nose-Hoover) can take both an array and scalar (externalstress keyword), and is represented as stress (so minus the pressure), if you are fine with the keyword pressure being used for multiple meaning, then it is fine.

Why do we have logs and handling for deprecated keyword arguments like pressure and temperature? Would it not be better to simply not accept them? Then there won't be any confusion about units. That was more-or-less my question from earlier. Instead of trying to be "smart", we could simply just not accept those old keywords at all.

Yes, but again, you have to be careful because these keywords are not deprecated in some classes, for example temperature and temperature_K both seem to work for NVTBerendsen.
Not sure if I am very helpful here, I think the current approach including your suggestions and changes is good. Although I must say I am still thinking about Quacc specific keywords, as mentioned above, as it would make it independent from what ASE is doing, at least for now.

@tomdemeyere: Thank you for your review of this! Apologies this has dragged on for so long. I recognize your time is valuable and so appreciate your comments here. I will address your comments below later this week. I think they are all logical. I will ping you (one last time? 😅) when that's done to keep you updated.

I think it's nice (I skipped the part where the runners have been changed to a class!) you changed fix_rot and fix_com to set_zero_rotation and set_stationary my only concern here is that it is not immediately clear what set_stationary is, but with a little bit research this should be ok on the user side (zero_com_momentum, zero_angular_momentum might be better? I don't know)

These are good suggestions. I found the original keywords a bit confusing because they are not actually "fixing" it per se rather they are setting it. But I agree my change is not clearer for other reasons. I will change to the syntax to something clearer based on your suggestion.

Instead, I went all-in by forcing every ASE keywords (deprecated or not...) to follow Quacc's new convention.

This is more-or-less my concern --- that an ASE expert will come in and expect that if they are requesting an ASE keyword that it will behave as one would expect from ASE.
I like your suggestion of quacc-specific keywords. The suggestions you have are particularly nice because there is no way that somebody is going to misinterpret the units on something like time_fs unless they are really clueless. It is true that something like pressure_gpa is lengthier, but I don't think a few characters will bother people. I am inclined to make this change and thank you for the suggestion.
If we go ahead with the custom keyword arguments, then we really aren't doing anything unusual with the units here. We don't need to have the behind-the-scenes transformations and logging. If the user passes in a custom ASE keyword argument, then that's on them to deal with. Additional keyword arguments like those related to compressibility would be missing (and require the user to supply an ASE keyword with ASE units), but there is also nothing stopping us from adding in one or more keyword arguments to the recipe if it is convenient for the end-user.

Pressure might be a little bit tricky, because NPTBerendsen expects a scalar while NPT (Nose-Hoover) can take both an array and scalar (externalstress keyword), and is represented as stress (so minus the pressure), if you are fine with the keyword pressure being used for multiple meaning, then it is fine.

It looks like you may have meant NPT? If so and I'm understanding the documentation correctly, it does not look like this should be a major problem because NPT accepts externalstress but has no pressure keyword argument. So, this is a scenario where pressure_gpa (or whatever we name it) would not apply. NVTBerendesen looks to have just a pressure_au but not externalstress, unless I am missing something.

EDIT: Also, the problem is that now you have pressure_au that takes a pressure in GPa 🙃

Thanks! Will fix!

Hey @tomdemeyere, while reviewing your PR, I'd suggest the following code changes:
👉 Code Suggestion for #1672

https://github.com/Quantum-Accelerators/quacc/pull/1672

You can also review and apply these suggestions locally on your machine.
Learn more about GitKraken Code Suggest

Code Suggest liberates your code reviews from GitHub's restrictive, comment-only feedback style. As simple as suggesting changes in a Google-doc, provide real code suggestions from where you code, e.g. your IDE, and on anything in your project — not just on the lines of code changed in the PR.

Join your team on GitKraken to speed up PR review.

@tomdemeyere: How does the proposal in https://github.com/Quantum-Accelerators/quacc/pull/2308 sound?

Thanks again, @tomdemeyere for your help and patience! I'm going to go ahead and merge this in. Certainly, there remain areas for improvement, but I think this is a good place to be at. I will mark it as for "beta testing" in the changelog just for the time being.


Indicate in ProcessError if the command timed out

It can be helpful if the fact that a command timed out is indicated also in error messages.

Straightforward, so merging. (Travis failure is due to conda timeouts.)


Make withRouter HOC stateful to allow refs

Right now when you use withRouter on a component with ref it suddenly breaks because withRouter is a stateless component which doesn't allow refs.
There is wrappedComponentRef property but it forces container to know which child components use withRouter and which don't.
Components refs are mostly used to get a DOM node via ReactDOM.findDOMNode so usually it doesn't matter if ref points to withRouter HOC instead of wrapped component.

using ref as string is not the best way. better to pass a callback,
and lift this ref to the parent component in componentDidMount
class ChildComponent extends Component {
  static propTypes = {
    liftNode: PropTypes.func.isRequired
  }

  componentDidMount = () => {
    this.props.liftNode(this.node)
  }

  getNode = node => { this.node = node }

  render () {
    return (
      <div
        ref={this.getNode}
      />
    )
  }
}

class HOC extends Component {
  liftNode = node => { this.div = node }

  render () {
    < ChildComponent
      liftNode={this.liftNode}
    />
  }
}

you can even use React context API to lift node up the component tree.
2017-07-28 18:28 GMT+08:00 Nikita Lobachev<EMAIL_ADDRESS>
Right now when you use withRouter on a component with ref it suddenly
breaks because withRouter is a stateless component which doesn't allow refs.
There is wrappedComponentRef property but it forces container to know
which child components use withRouter and which don't.
Components refs are mostly used to get a DOM node via ReactDOM.findDOMNode
so usually it doesn't matter if ref points to withRouter HOC instead of
wrapped component.
You can view, comment on, or merge this pull request online at:
https://github.com/ReactTraining/react-router/pull/5382
Commit Summary

Make withRouter HOC stateful to allow refs

File Changes

M packages/react-router/modules/tests/withRouter-test.js
https://github.com/ReactTraining/react-router/pull/5382/files#diff-0
(20)
M packages/react-router/modules/withRouter.js
https://github.com/ReactTraining/react-router/pull/5382/files#diff-1
(28)

Patch Links:

https://github.com/ReactTraining/react-router/pull/5382.patch
https://github.com/ReactTraining/react-router/pull/5382.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ReactTraining/react-router/pull/5382, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ACJsecSOKZxfKLoWF09KT0WrpTSsHzAkks5sSbfggaJpZM4OmcA9
.

The main point, is that ReactDOM.findDOMNode is very old API, which
definitely adds up the complexity to the bundle.
2017-07-28 18:46 GMT+08:00 Alexey Lyahov<EMAIL_ADDRESS>
using ref as string is not the best way. better to pass a callback,
and lift this ref to the parent component in componentDidMount
class ChildComponent extends Component {
  static propTypes = {
    liftNode: PropTypes.func.isRequired
  }

  componentDidMount = () => {
    this.props.liftNode(this.node)
  }

  getNode = node => { this.node = node }

  render () {
    return (
      <div
        ref={this.getNode}
      />
    )
  }
}

class HOC extends Component {
  liftNode = node => { this.div = node }

  render () {
    < ChildComponent
      liftNode={this.liftNode}
    />
  }
}

you can even use React context API to lift node up the component tree.
2017-07-28 18:28 GMT+08:00 Nikita Lobachev<EMAIL_ADDRESS>
Right now when you use withRouter on a component with ref it suddenly
breaks because withRouter is a stateless component which doesn't allow refs.
There is wrappedComponentRef property but it forces container to know
which child components use withRouter and which don't.
Components refs are mostly used to get a DOM node via
ReactDOM.findDOMNode so usually it doesn't matter if ref points to
withRouter HOC instead of wrapped component.
You can view, comment on, or merge this pull request online at:
https://github.com/ReactTraining/react-router/pull/5382
Commit Summary

Make withRouter HOC stateful to allow refs

File Changes

M packages/react-router/modules/tests/withRouter-test.js
https://github.com/ReactTraining/react-router/pull/5382/files#diff-0
(20)
M packages/react-router/modules/withRouter.js
https://github.com/ReactTraining/react-router/pull/5382/files#diff-1
(28)

Patch Links:

https://github.com/ReactTraining/react-router/pull/5382.patch
https://github.com/ReactTraining/react-router/pull/5382.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ReactTraining/react-router/pull/5382, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ACJsecSOKZxfKLoWF09KT0WrpTSsHzAkks5sSbfggaJpZM4OmcA9
.

@JustFly1984 It affects both string and functional refs. Also findDOMNode isn't deprecated and useful for some edge cases or quick prototyping.

It was explained in #4838 that we do this because it follows the recommendation from the React docs. The ref you would get back from this component wouldn't be the correct one, as it points at the wrapper instead of the wrapped component.

I ended up writing this utility function:
import {withRouter as withRouterOrig} from 'react-router-dom';

export function withRouter(Component) {
  Component = withRouterOrig(Component);
  return class WithRouterWrapper extends React.Component {
    render() {
      return (
        <Component
          wrappedComponentRef={ref => this.ref = ref}
          {...this.props} />
      );
    }
    getWrappedInstance = () => this.ref;
  };
};

Use like you would use the original getRouter(), but you can assign it a ref, and later call getWrappedInstance() on that ref, like you already do with other HOCs such as injectIntl(), connect(), etc.
I understand the future is forwardRef() (#6056), but until it is supported by react-redux
(see react-redux issue #914) and others, this will do me for now.


How to precompile asset

How can I precompile assets for release packaging and debug development?
You can pub get the packages, but there are no command for post-processing (compiling) got packages.
Also it would be great to expose some sort of config that will allow to map some particular Natives to precompiled dynamic libraries.

Hi @Zekfad,

You can pub get the packages, but there are no command for post-processing (compiling) got packages.

With build.dart you can do whatever you want in the script. You can compile your packages (and RELEASE or DEBUG is defined).
Alternatively, if you want to precompile your packages, you can precompile your dynamic libraries both in release and debug mode, host them somewhere on the web and download them in build.dart.

Also it would be great to expose some sort of config that will allow to map some particular Natives to precompiled dynamic libraries.

This is exactly what build.dart outputs: a mapping from asset id (the asset: in @Native) to the path of the dynamic library (per os_arch).
You can give support for build.dart a spin in Dart by passing the experimental flag --enable-experiment=native-assets. In Flutter support hasn't landed yet https://github.com/flutter/flutter/issues/129757.

Hi @dcharkes , thank you for your answer!
What if I have multiple native dependencies, should I manually call build for each of them from pub cache?
Apart from this I understand meaning behind build.dart to have precise control over build phase, but isn't yaml config easier for simple solutions (e.g. just compile c-code) than having to copy-paste build script and keep it updated for API changes?

What if I have multiple native dependencies, should I manually call build for each of them from pub cache?

If you have dart package that have native assets, they should be automatically built by their build.dart. The Dart SDK will automatically invoke the build.dart for all your dependencies.
If your package has multiple dynamic libraries, you should build/download all of these in your build.dart. The Dart SDK will automatically invoke your build.dart when running dart run / dart test when passing --enable-experiment=native-assets on the dev branch.
You should not be manually calling any build.dart scripts, the Dart SDK should do this for you. Maybe I misunderstood the question, was this what you were asking?

but isn't yaml config easier for simple solutions

We considered this. However, you'll need a different line in your config for every _, and Dart and Flutter support 21 combinations, so you'll likely want to script that. (And then default the OS to the relevant file extensions etc. .so for Linux, .dylib for MacOS...) Moreover, it means you have to push your dynamic libraries to pub.dev with dart pub publish, and this only works up to a certain size as pub has a size restriction for package versions.

keep it updated for API changes?

The API changes in the Dart API of the helper package are versioned by the package, so you're not forced to update.
The API changes in the communication between Dart SDK and the packages with native assets would always have issues if we ever want to change that protocol. Having a package actually allows you to just update the package in your dependencies instead of having to manually fix up some yaml file.
(In general, we'd like to minimize breaking API changes! However, currently this package is experimental, so no promises.)

Thanks for clarifying the config part.
Regarding automatic build.dart call: I was talking about scenario where I don't want to run tests or program itself. That's what I meant by precompilation.
One solution I see to have empty test, to force Dart SDK into calling related builds?

Ah, that's what you meant with precompiling. I thought you were talking about having the C code compiled when shipping a package as a package author rather than on a build.dart invocation as a package user.
You are correct, there is currently no way to force pre-compilation. In the Dart SDK it could make sense to precompile, because we almost always are running in JIT mode (meaning we need dynamic libraries, not static libraries) and Dart does not have a concept of debug/release mode (so the build mode is always the same). However, in Flutter, we have multiple target OSes/architectures, and debug and release build modes. So it's hard to know for what to pre-compile in that case.
The workaround, having an empty test in your package, works.
cc @mit-mit Our first user asking for being able to run the native builds before doing a dart run or dart test invocation. Maybe it would be good to introduce something similar to dart pub get to be able to build the native assets. Possibly dart build native-assets.

So the use case here is targeted at the developer creating the package containing native assets who wants to adhoc test that the build works?

That (1), and (2) the "airplane mode" approach as a user, where you get all your dependencies with dart pub get and your native dependencies (which are possibly downloaded as well) with dart build native-assets. And then you enter the airplane and hack on your own Dart code that uses some downloaded native assets as a dependency.

Got it. How about dart prebuild as a hidden subcommand (i.e. hidden in dart help, only shown in dart help -v)? That is aligned with flutter precache.


Added  Dice class

The Dice class represents a dice with an arbitrary amount of sides, defined in the constructor.
This class contains methods to access the number of sides, as well as rolling the dice to generate a random number.
Included javadoc and unit tests.

Will be leaving this PR open, will likely incorporate these in a future release, with some minor adjustments of course.

This has been added to the next release, thank you all for your contributions!


[WIP] Merge develop into master

Overview
Merge develop branch into master. It includes the following commits.
Refactors:

#3 Refactor Word2Vec
#4 Refactor Similarity

Parallelizing Word2Vec with gorgonia, lingo:

#6 Multiple works done

Adding tests:

#5 Improve code coverage

Replacing vector to gorgonia in cosine similarity:

[WIP] #13 Use tensor.Dense in similarity

Coverage decreased (-13.8%) to 12.195% when pulling 552f479c61ed42d2e2d932adcb49bbb0884cfae8 on develop into ddd3aa27363b159b09e175b3394e756b64b237a3 on master.

Coverage decreased (-16.004%) to 9.989% when pulling ae99ba43b7fef45466b43aa48486110bc75101fd on develop into ddd3aa27363b159b09e175b3394e756b64b237a3 on master.

Coverage increased (+30.6%) to 56.572% when pulling ea8240d117a7e199882f539e827d54ea2473beb3 on develop into ddd3aa27363b159b09e175b3394e756b64b237a3 on master.

Coverage increased (+30.4%) to 56.362% when pulling c8280e49dab84832540edd8c798cc5d4aed11215 on develop into ddd3aa27363b159b09e175b3394e756b64b237a3 on master.

Coverage increased (+30.5%) to 56.476% when pulling 89355aad104023743a7d0b3bac339220931ecde0 on develop into ddd3aa27363b159b09e175b3394e756b64b237a3 on master.

Coverage increased (+30.7%) to 56.688% when pulling 3cc0352136b4a75264d3d3160eeeed0858a45f70 on develop into ddd3aa27363b159b09e175b3394e756b64b237a3 on master.

Coverage increased (+29.2%) to 55.202% when pulling 5f5720da2918a5f360b57b850fdfa8471723a958 on develop into ddd3aa27363b159b09e175b3394e756b64b237a3 on master.

Coverage increased (+29.2%) to 55.202% when pulling 5f5720da2918a5f360b57b850fdfa8471723a958 on develop into ddd3aa27363b159b09e175b3394e756b64b237a3 on master.

Coverage increased (+29.0%) to 54.989% when pulling fe45ffc19e4d1f74574e4db8a45f2d282cfc8621 on develop into ddd3aa27363b159b09e175b3394e756b64b237a3 on master.

Coverage increased (+25.2%) to 51.188% when pulling 14db84a0c7573d9f1d0f8911afdf7cd1575aef16 on develop into ddd3aa27363b159b09e175b3394e756b64b237a3 on master.

Coverage increased (+25.2%) to 51.188% when pulling 14db84a0c7573d9f1d0f8911afdf7cd1575aef16 on develop into ddd3aa27363b159b09e175b3394e756b64b237a3 on master.

Coverage increased (+25.2%) to 51.188% when pulling f336f926b39ad7b11b44627afb523acd788b74b1 on develop into ddd3aa27363b159b09e175b3394e756b64b237a3 on master.


Sample schema for creating AI plugin using copilot studio

Hi,
I was trying to create a AI plugin from Copilot Studio by manually providing a manifest file and open AI file. Is there any sample schema available for manifest and Open AI file? or any other sources where I can get this info?
Thanks,
Kalyan

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

ID: 2a941c97-4437-9556-c0a1-d7eccdbc7a66
Version Independent ID: 2a941c97-4437-9556-c0a1-d7eccdbc7a66
Content: Create AI plugins for Microsoft Copilot (preview) - Microsoft Copilot Studio
Content Source: power-virtual-agents/copilot-ai-plugins.md
Service: copilot-studio
GitHub Login: @iaanw
Microsoft Alias: iawilt

Thanks for your comment, @Kalyan492. This issue has been assigned to the doc author for review.


Support differentiating networks by ID

Hardhat deploy supports having different networks with the same network id. For example, you can have rinkeby and rinkeby-testing. Both are rinkeby, but contract addresses and ABIs can be different.
It may be beneficial to support this in ethcontract-rs.

Also, in general, its probably safer to differentiate on chain ID instead of network ID.
Do you know if it uses the chain ID as the differentiating factor, or something else?

Oh yeah, it uses chain id. Sorry, my bad. I'll update the issue.


fixed sorting by title

Sorting product by title doesn't work with Elasticsearch backend, because Elasticearch doesn't sort ngram fields correctly.
This request adds unanalyzed title CharField that is sorted correctly by all backends.
p.s. partially addresses #1872

Current coverage is 83.36% (diff: 100%)

Merging #2142 into master will increase coverage by <.01%

@@             master      #2142   diff @@
==========================================
  Files           302        302
  Lines         15047      15048     +1
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits          12544      12545     +1
  Misses         2503       2503
  Partials          0          0

Diff Coverage
File Path

•••••••••• 100%
src/oscar/apps/search/search_indexes.py

•••••••••• 100%
src/oscar/apps/search/forms.py

Powered by Codecov. Last update 6ce56cc...7536664

Thanks for the contribution.


Should a community's Colu asset be divisable?

Doesn't seem to put asset amounts together when receiving multiple bounties.

@dukedorje The reason is that even the same type of asset can have different metadata on different "coins", so the question on how to merge the assets is the UI developer choice.
What UI (application) are you using to view the asset?

One more thing, the divisibility feature is mainly a UI thing.
Think about Bitcoin for example, the bitcoind (original) clients actually counts in Satoshis and treat Bitcoin as a non divisible asset while we as humans and high level wallets like to think of it as Bitcoins with 8 points of divisibility.
So in reality it's a matter of enforcing a certain UI rule on people who build the clients, it doesn't really makes an "economic" difference.
Hope it helps :)

Hey, thanks for the comments.  Some things to think about in there.  So, 'divisible' is essentially a metadata attribute that indicates whether the currency represents something that can be separated & combined, or whether it represents assets that are unique and not combinable?

copay

Not exactly.
Divisible and non divisible are both able to be "combined". It's only a matter of wallet implementation and how it decides to show the data.


Feature - Include Journey Updates

This branch contains all the updates that were marked for Aug 31 on Jira, these include:
IJ-192: Feature - Affirmations
IJ-193: Feature - User Extra Fields
IJ-196: Feature - Update Delete Functionality
IJ-200: Bugfix - Mailer Error
IJ-185: Feature - Surveys
IJ-195: Feature - Reminder Notifications
IJ-183: Feature - Achievements

This is a big PR, is there anything specific you would like me to look at?

This is a big PR, is there anything specific you would like me to look at?

@phil-6 there isn't, every part of the PR has been individually peer reviewed so should be good to go. I should've just raised them to go into main and then we could cut a new version of the demo branch, this step is wholly redundant in all honesty.


Problem with MythicLib

The output of command /version on my server is: git-Purpur-1777 (MC: 1.19.2)
The output of command /version citizens on my server is: Citizens version 2.0.30-SNAPSHOT (build 2765)
The output of command /version sentinel on my server is: Sentinel version 2.7.1-SNAPSHOT (build 499)
A pastebin.com link to my (full!) Sentinel/config.yml file is: https://pastebin.com/fkpDKPU9
This error will appear when sentinel attack by monsters or players etc.
https://pastebin.com/0UFYGiMN
Should I send this issue to MythicLib?

Yes, that's a mythiclib error


run marked tests

As you can see lots of tests fail (as they should) because the extension changes the output html. In this case it would almost be better to just copy the tests that should pass instead of trying to run them from marked-repo.


feat: Add nomerge option to ignore merge commit msg

It seems to me that this option is no longer exist in the v1.0.x so I would like to add this feature back.

@domrongpon-tanpaibul Unless I've misunderstood you, there is an .changelogrc that dictates what gets parsed. Last time I checked the default one seems to have "merge commits" as an option. Your .changelogrc could remove it.

@seivan Um. Do you have a sample of .changelogrc? I also check from README and git-changelog -h, there is no mention about no merge option.

@domrongpon-tanpaibul Again, I might not understand correctly, but I would suspect this is something related to "omitting" stuff from the changelog.
https://github.com/rafinskipg/git-changelog/blob/master/.changelogrc#L40-L42
If you don't want merge commit messages, you could have a changelog that omits them.

@seivan Right, that'd work. I will check it out more. One more question if you don't mind, is it possible to group the change log by tag version? Searching in issues and it seems that this feature is not implemented yet.
Would you please advise?

@domrongpon-tanpaibul You should create a separate issue for that. Right of the bat, I'd say it's not currently possible, but I could be wrong.

@seivan Thanks a lot. I'll close this PR as we don't need it.


Scrollbar Enhancement

Is your feature request related to a problem? Please describe.
I want to create a customized nav bar for the new revamped website. It is currently a bland and default gray scrollbar
Describe the solution you'd like
I want to create a scrollbar with a colour and a feel similar to that of the theme of thw website
Describe alternatives you've considered
No response
Additional context
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Go Ahead

Keep it blue , because out site theme gonna blue and white


Fix for TZ in Western hemisphere

In timezones in the Western hemisphere (UTC-1 etc.), the local year at UNIX epoch is 1969, not 1970. Therefore, instead of checking getFullYear()==1970, we should be checking getFullYear()<=1970 (I did < 2000 consistent with the existing code below on line 24).

Great - thanks!


INSERT fails with non-null constraint violation

System information:

Operating system (distribution) and version: Fedora 31 - os.arch=amd64 os.name=Linux os.version=5.5.9-200.fc31.x86_64
DBeaver version <IP_ADDRESS>105300349
org.jkiss.dbeaver.ce.feature (<IP_ADDRESS>105300349) "DBeaver Standalone"
org.jkiss.dbeaver.runtime.feature (<IP_ADDRESS>105300349) "DBeaver Model"
org.jkiss.dbeaver.standalone.feature (<IP_ADDRESS>105300349) "DBeaver Standalone"

Connection specification:

Database name and version: PostgreSQL 13.2 (Debian 13.2-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
Driver name PostgreSQL JDBC Driver (org.postgresql:postgresql:RELEASE version 42.2.5)
Do you use tunnels or proxies (SSH, SOCKS, etc)?  No
org.jkiss.dbeaver.ext.postgresql (<IP_ADDRESS>105300349) "DBeaver PostgreSQL Support" [Active]
org.jkiss.dbeaver.ext.postgresql.ui (<IP_ADDRESS>105300349) "DBeaver PostgreSQL Support UI" [Active]

Describe the problem you're observing:
Using the Editor UI Add Row feature to insert a row in the database, fails when not providing any column with a value.
All columns are defined to have default values, so the operation should insert a row even when no value is explicitly set by the user.
Expected result: DBeaver should use statement INSERT INTO accouting.invoices DEFAULT VALUES;
Actual result: DBeaver uses statement INSERT INTO accounting.invoices (id, created_at, updated_at, deleted_at) VALUES (null, null, null, null)
Steps to reproduce, if exist:

Create table with all columns having default values
In table Editor UI, use Add Row button, to insert a row (Alt+Insert)
Do not set/modify any of the column values of the row to be inserted.
Click on Save button (Ctrl+S)
Error is generated by PostgreSQL Database

Working alternative, but this is counter intuitive:

Create table with all columns having default values
In table Editor UI, use Add Row button, to insert a row (Alt+Insert)
Set the value for at least one column in the row to be inserted.
Click on Save button (Ctrl+S)
SQL Insert is ok

Include any warning/errors/backtraces from the logs

Table DDL:
CREATE TABLE accounting.invoices (
	id uuid NOT NULL DEFAULT uuid_generate_v4(),
	created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
	updated_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
	deleted_at timestamp NULL,
	CONSTRAINT invoices_pkey PRIMARY KEY (id)
);

Error on inserting row with all defaults:
[92] ERROR:  null value in column "id" of relation "invoices" violates not-null constraint
[92] DETAIL:  Failing row contains (null, null, null, null).
[92] STATEMENT:  INSERT INTO accounting.invoices (id,created_at,updated_at,deleted_at)
VALUES ($1,$2,$3,$4)

Looks like a good enhancement, thanks @mpotra!

Implemented in DBeaver 21.1.4
Now we are using "INSERT INTO tableName DEFAULT VALUES" for an empty row with all default value cells.

verified. Related issue is created.


Susan/hotfixesonsamplepage

Show number of samples found during search in real time
Swop qc and compression ratio values on the table
Refactor header styling

Could you make it so that the values in the "Total Reads | Final Reads | Percentage Reads | QC | Compression Ratio | Pipeline run status" columns move around correctly when User searches for a sample and the list of displayed samples changes? Right now, they do not change, i.e. they display the wrong values


Non-standard config for Feather M0

Line 88 of adafruit_feather_m0_lora.h has dio1 on pin 5. However the common pin used on all examples I've seen uses pin 6.
Additionally, and I'm not sure if it makes a difference, but the examples also has .rssi_cal = 8, instead of 10.

Thanks for your feedback.
I must have forgotten to change it in the actual code (after changing it from 5 to 6 in the documentation).
Not having the hardware to test makes this easier to slip through.

Additionally, and I'm not sure if it makes a difference, but the examples also has .rssi_cal = 8, instead of 10.

Ah, I see, the 'feather-us915' examples use 8, while file hal/getpinmap_featherm0lora.cpp uses 10.
The 8 is possibly more correct. I'm not sure where you would see the actual difference. I suspect in reported RSSI value of downlink messages.

DIO1 mapping has been fixed.
Will have a look at rssi_cal later.

rssi_cal has been changed to 8.

Awesome thank you!
My initial testing with these settings got the device working with the expected serial monitor output. Tho I haven't been able to test on TTN as there are no active gateways near enough to me.


Change "save attachment" icon

Before and after:

But paper clips are still a thing?
Actually I enjoyed the floppy icon. But, well, things change, the new icon is abstract as well.


Could you share the meta files for training?

thanks ; )

Hi,
Thanks for your question. The content of meta file depends on the path of your training images. You need to generate it by yourself.

Hi,
Thank you for sharing your nice work.
I also want to know the training data, i.e., which 5000 images are chosen for each training set.
And how to train the teacher model.
Could you share more details about the data used so I can reproduce the experiment more smoothly?
Thanks

Hi, Thanks for your question. The content of meta file depends on the path of your training images. You need to generate it by yourself.
Hi,
Thank you for sharing your nice work.
I also want to know the training data, i.e., which 5000 images are chosen for each training set.
Could you share the meta files for training?
Thanks


Check positive dilation in F.deconvolution_2d

Rel. #7304.
This PR make F.deconvolution_2d check if the supplied dilation is positive integer.

CIs, test this please.

Jenkins CI test (for commit 6d64061777f983e09401935800c95b43d8f755f4, target branch master) failed with status FAILURE.


License confusion

Hi fastai folk,
I noticed the LICENSE file for the project is Apache-2.0, but the setup.py lists 5 different licenses. Is the setup.py in error? It feels like maybe it's a template and still needs work?

setup.py is generic. It reads the actual license name from setup.ini