Updated not_landed to get user nicks in 1 call and removed the duplicate #1101

Checklist

[ ] Type annotations added to new functions
[ ] Docs added to functions touched in main classes
[x] Dry-run produced the expected results
[ ] The to-be-announced tag added if this is worth announcing

Thank you, @Jubintgh! Please see my comments.

Thanks @suhaibmujahid, I applied your suggestions to improve readability. please let me know your thoughts

Thank you! Could you please do another dry-run test?
Also, please link the PR to the issue that will be resolved.1
Footnotes

https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue ↩


Mower faults are changing switches

Describe The Bug:

Whenever the mower faults while mowing the main switch seems to turn off even though the mower would be mowing and is still on. It’s hard to tell it should be mowing like this.
To Reproduce:

Easiest way would be to have the mower out mowing and lift it. The switch will then turn off.
Expected behavior:

When the mower is mowing and faults, the switch should ignore that it’s not mowing and just stay in whatever state it was in previously.

Mower was parked should remain it’s parked
Mower was mowing should remain it’s mowing
The only thing that should change is the sensor indicating it’s faulted

Logs:
[8/17/2024, 11:50:50 AM] [Homebridge Automower Platform] Received event:
 {"id":"REDACTED","type":"status-event","attributes":{"battery":{"batteryPercent":74},"mower":{"mode":"MAIN_AREA","activity":"NOT_APPLICABLE","state":"FATAL_ERROR","inactiveReason":"NONE","errorCode":36,"errorCodeTimestamp":1723894409000},"planner":{"nextStartTimestamp":0,"override":{"action":"NOT_ACTIVE"},"restrictedReason":"NOT_APPLICABLE"},"metadata":{"connected":true,"statusTimestamp":1723909850266}}}
[8/17/2024, 11:50:50 AM] [Homebridge Automower Platform] Changed 'Motion Sensor' for 'Dobby': GENERAL_FAULT
[8/17/2024, 11:50:50 AM] [Homebridge Automower Platform] Changed 'Motion Sensor' for 'Dobby': NO_MOTION
[8/17/2024, 11:50:50 AM] [Homebridge Automower Platform] Changed 'Schedule' for 'Dobby': OFF

Plugin Config:

{
  "name": "Homebridge Automower Platform",
  "device_type": "automower",
  "sensor_mode": "motion_only",
  "logger_type": "imitation",
  "lang": "en",
  "appKey": "REDACTED",
  "authentication_mode": "client_credentials",
  "application_secret": "REDACTED",
  "platform": "Homebridge Automower Platform"
}

Screenshots:

Mower:

Year: 2020
Model: Automower 430XH

Environment:

Plugin Version:
v2.3.0-preview.100+96089d6.0
Homebridge Version:
Node.js Version: 20.15.0
Operating System: Docker

The big concern with this is if the mower is trying to mow and faults, when I check HomeKit it looks like the mower has been parked, and not that it's sitting on the property somewhere in a ditch waiting for help to arrive.


sdk35 part 2

I forgot something.
I will test it again via Jitpack with Files, before we can merge and release it.

Still works ✔


the website requires an openAI API key to work

Sorry for the inconvenience. The demo is online now, re-open if any problems occur.


Deviation from Ably SDK APIs

This issue is a result of review from PR #6
https://github.com/ably/ably-flutter/pull/6#pullrequestreview-418489247
https://github.com/ably/ably-flutter/pull/6#discussion_r430559986

@QuintinWillison I think we can link this Issue to https://github.com/ably/ably-flutter/pull/18 and close?

I agree, @tiholic - thanks. 😁


Changed bad DK translation for RichText Headers

Q
A

Bug fix?
[ X ]

New feature?
[ ]

New sample?
[ ]

Related issues?
fixes #X, partially #Y, mentioned in #Z

What's in this Pull Request?
The translation for Header 1, 2, 3 in the RichText control has been fixed. "Udgiftsområde" changed to "Overskrift" which is the correct danish word for Heading.

Hi @spcph , many thanks for the update. The PR has now been merged and will be available as part of the next release. You can also try the changes by installing the new beta version that will be automatically published in a few minutes.


Starting to verify laws

I see all green, which rules don't hold?

Applicative:
u <*> result y = result ((<|) y) <*> u
Alternative:
(f <|> g) <*> x = (f <*> x) <|> (g <*> x)
empty <*> f = empty

I think FsCheck provides you with a counterexample when it fails, do have it?

I'm having trouble coming up with types that compile for u <*> result y = result ((<|) y) <*> u.
Alternative: (f <|> g) <*> x = (f <*> x) <|> (g <*> x)
(x=AccFailure [""], y=AccFailure [], f=AccFailure [], g=AccFailure [])
Alternative: empty <*> f = empty
f:AccValidation<string list,int->string> = AccFailure [""]

So perhaps it's me being confused?

For applicative you have the operator flipped in the rule, it should be |> :
let u : AccValidation<string list,_> = AccSuccess ( (+) 1)
let y =  10

let x1 =   u <*> result y
let x2 = result ((|>) y) <*> u
x1 = x2

Regarding empty I'm in doubt if it's an Alternative with empty as there are more than a single value for empty. Precisely these days I'm thinking about to add a "halfway concept" which has a method isEmpty instead, to be able to model these types more accurately.

Aaa, thanks!

I see that you translated mempty from Haskell to empty.
That's not exactly the same, mempty is from Haskel's monoid, here it's zero whereas empty is the same in both.
Anyway I'm still in doubt about the Monoid in the error branch. If the error is a semigroup then there is no monoid instance for it. But ok, that's not necessarily wrong, it could be a constrained monoid for the case where the error branch is more than a semigroup.

By the way, I read the Haskell docs and definitely Alt is to Alternative like Semigroup  to Monoid it states clearly <!> is <|> without a required empty.
We should add it in F#+ docs. But we don't need a separated operator, we can keep using <|>.

Where is the <!> defined?

In F#+ <!> has a different meaning. It’s an alias for map, which in Haskell is <$> but that’s an invalid operator in F#.
So <!> belongs to Applicative, and it’s defined directly in operators.fs


SCT-1486 Add GroupsAPI test

Also move token checking code to common class and use it consistently in
GroupsAPI
Also change request sets to lists to maintain ordering from mongo

Build has been done for 15m so I'm guessing GH/Travis/CodeCov are still having problems. Merging.
https://travis-ci.org/kbase/groups/builds/444833317


Simplify code by using copy-on-write for the immutable time zone cache

Simplify code by using copy-on-write for the immutable time zone cache dictionary instead of a slower thread local variant.
This references #12 and runs about 15% faster in my quick test. It's also a lot less code and especially no longer needs an initializer to create the cache.
Another way that might be not as fast but would require even less memory would be to simply use an NSCache object instead of the NSDictionary.

I went with #39. Thanks!


Fix waitctx fds removing the fd from the list

Checklist

[ ] documentation is added or updated
[x] tests are added or updated

Description of change
There are cases where we call ASYNC_WAIT_CTX_set_wait_fd() followed by ASYNC_WAIT_CTX_clear_fd() before pausing the async job.
This happens for example when the submission to the HW accelerator fails and there is no operation in flight (no fd should be added in the epoll set of the application).
In this case, the application will get inconsistent results from ASYNC_WAIT_CTX_get_changed_fds()
Both numdelfds and numaddfds will be set to 1 (they have been increased with the previous call to set_wait_fd and clear_fd)
However in the while loop we explicitly ignore the fds that have been marked as both added and deleted.
This means that the array of fds returned to the application won’t contain any meaningful data, which results in unpredictable behavior.
This pull request changes ASYNC_WAIT_CTX_get_changed_fds() to make sure that the number of file descriptors returned to the application are always correct.
This pull request is based on @mattcaswell 's comment and replaces #2338 . The changes should be applied to both 1.1.0 and master branches.
Since the approach is substantially different, I created a separate review so we can easily compare the two and decide what's best.

The new commit should address all the comments

Needs a second team review.

Thanks @mattcaswell and @richsalz for reviewing the code!
Will the change be included in the upcoming 1.1.0e release?

assuming @mattcaswell merges it :) yes

Thanks. Merged. So, yes, this will be in 1.1.0e.


NameError: name 'test_img_paths' is not defined

Traceback (most recent call last):
File "main.py", line 91, in
callbacks = [ESPCNCallback(), early_stopping_callback, model_checkpoint_callback]
File "/content/drive/MyDrive/Experiment/codes/36_RFDN/RFDNet-ImageSuperResolution/utils.py", line 96, in init
self.test_img = get_lowres_image(load_img(test_img_paths[0]), upscale_factor)
NameError: name 'test_img_paths' is not defined

I also met the problem. I sincerely hope that someone can help me.

I just updated the code. Sorry for making it too long.


Feature/cu 1gpu458 fix fang shooting animation

Shooting animation should look better
Now Fang can dash without keyboard input and with a cool animation

It can be prove directly in lvl1.scene (u may have to delete library)

Task linked: CU-1gpu458 Fang fix shooting animation


enableExperimentalDeepTargets on CURL queries

The documentation totally lack on information about this parameter or at least i was not able to find it out.
is it possible to add this param to a CURL query ?
I'm trying to retireve the resource querying a nested parameter in this way
/resource?where={"field.token":"<somestring>"}
and i get the following
{
    "code": "E_INVALID_CRITERIA",
    "details": "Could not use the provided `where` clause.  Could not filter by `field.token`: Cannot use dot notation in a constraint target without enabling experimental support for \"deep targets\".  Please try again with `.meta({enableExperimentalDeepTargets:true})`.",
    "message": "The server could not fulfill this request (`GET /resource`) due to a problem with the parameters that were sent.  See the `details` for more info."
}

But it gives no information on how to add the parameter inside an external curl query

Hi @cecchigl, I would recommend writing your own custom action.
But what you are trying to do is possible with: https://sailsjs.com/documentation/reference/configuration/sails-config-blueprints#?using-parseblueprintoptions.
Here's the docs for the Find blueprint: https://sailsjs.com/documentation/reference/blueprint-api/find-where

i.e. I think sticking meta: {enableExperimentalDeepTargets: true} on the query options you return from that function should do the trick.


Test won't work for Puppet 4.0.0

As rspec-puppet breaks with puppet 4.0.0 (see rodjek/rspec-puppet#663),
I propose to drop tests and support for puppet 4.0.0

The module still works, if its just the rspec that fails I think it would make more sense to just pin rpsec-puppet to 2.6.9, or whichever last known good version works for puppet 4.0.0

see #179

Thanks for that @jfroche - thats merged - I'm re-running the other tests and will try and get the remainng PR's (most of them yours! :-)) merged shortly and 3.5.0 relased. Thanks for all the contributions!


Auth Popup

I'm trying to create a plugin for Asana, with Google Auth but I'm having some problems. (OSX here)
When I click the Asana button to open the Google Auth, a new tab opens. It actually showed content once but now it's just blank. I think it's because it's already authenticated and trying to go back to the Asana tab.
I've tried to set the popup config in multiple ways but it's making no difference. Now I'm even trying with .*. It always opens in a tab inside Franz. If I use "popup": [] it opens in Safari.
This is my current config.
  "config": {
    "serviceURL": "https://app.asana.com",
    "serviceName": "asana",
    "message": "",
    "popup": ["^https:\/\/accounts.google.com\/.*"],
    "hasNotificationSound": true,
    "hasIndirectMessages": false,
    "hasTeamID": false,
    "customURL": false,
    "hostedOnly": false,
    "webviewOptions": {
      "disablewebsecurity": ""
    },
    "openDevTools": true
  }

Ideas?
Thanks!

Logging in with username and password works, so I'm probably sticking with that…

3rd party logins are not implemented yet. We have it on our todo list but it's to early to give an ETA.


How to enable response templating?

Hi Rodolphe, thanks for your docker, it's really useful.
One question: when I run wiremock locally (using the jar) I use --global-response-templating. Is there a way to enable that in your image?
Many thanks and regards,
Jim

https://github.com/rodolpheche/wiremock-docker#start-a-wiremock-container-with-wiremock-arguments


Implement TestCafe “availability” tests for DataPage and EditDataPage.

Please do work for this task in a branch called issue-22.
Implement test-cafe for DataPage and EditDataPage as described in E62 .http://courses.ics.hawaii.edu/ics314f20/morea/testing/experience-testing-final-project.html

Implemented the required availability tests for the Data.jsx and the EditData.jsx pages.


Add simulated submit to test the profit calculation on mainnet

bacially just run a loop ad print the logs without submitting to check that the profit calculation works on mainnet. We can't test this on rinkeby as the price cost there is always constant.

No need to add this as can simple set a high profit threshold and in practise it will never submit so can use it to rest the profit calcs


development environment can't be setup due missing bower dependency

>> bower font-source-sans-pro-sass#~2.10.0          ECMDERR Failed to execute "git ls-remote --tags --heads https://github.com/Arelav/font-source-sans-pro.git", exit code of #128 remote: Repository not found. fatal: repository 'https://github.com/Arelav/font-source-sans-pro.git/' not found
>> Additional error details:
>> remote: Repository not found.
>> fatal: repository 'https://github.com/Arelav/font-source-sans-pro.git/' not found
>> Exited with code: 1.

Please have a look at https://github.com/TYPO3-Documentation/t3SphinxThemeRtd/tree/feature/cleanup-frontend-stack and follow https://github.com/TYPO3-Documentation/t3SphinxThemeRtd/tree/feature/cleanup-frontend-stack#set-up-a-development-environment
Note that sphinx is optional, ruby and sass via ruby is required.
Does that help?

It's fixed in the feature branch. So I close this issue


How to run cartographer stand-alone without being a submodule

I have been able to run cartographer without ROS while using it as a submodule by using:
`set(CARTOGRAPHER_CONFIGURATION_FILES_DIRECTORY "${PROJECT_SOURCE_DIR}/cartographer/configuration_files"
CACHE PATH ".lua config file directory")
add_subdirectory(cartographer)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${PROJECT_SOURCE_DIR}/cmake/modules/")
find_package(cartographer REQUIRED)`
in cmake/module, file Findcartographer.cmake contains
`set(CARTOGRAPHER_CMAKE_DIR "${cartographer_SOURCE_DIR}/cmake")
message(STATUS "Cartographer Source Directory = " ${cartographer_SOURCE_DIR})
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(cartographer DEFAULT_MSG cartographer_SOURCE_DIR)`
This method runs without any issue. My system is Ubuntu 18.04. I have received a new requirement that the project run it without it being a sub-module. I have followed the directions from
https://google-cartographer.readthedocs.io/en/latest/
This is followed all the way up to the actual cartographer install step. First I attempt to install abseil-cpp.
git clone https://github.com/abseil/abseil-cpp.git cd abseil-cpp mkdir build cd build cmake -G Ninja \   -DCMAKE_BUILD_TYPE=Release \   -DCMAKE_POSITION_INDEPENDENT_CODE=ON \   -DCMAKE_INSTALL_PREFIX=/usr/local/stow/absl \   .. ninja sudo ninja install cd /usr/local/stow sudo stow absl
I am using the latest master branch of abseil-cpp. Is their any problem with this? I know that cartographer's install script uses a specific commit id at checkout.
Now I install cartographer similar to how it is done in the read the docs link.
git clone https://github.com/cartographer-project/cartographer.git git checkout c5416068dd06ac4ca732ed53db225204b25ec05b cd cartographer mkdir build cd build cmake .. -G Ninja ninja CTEST_OUTPUT_ON_FAILURE=1 ninja test sudo ninja install
I specifically checkout a certain commit just to try and avoid running into library functions getting outdated in my current code. All the install steps above seem to work without issue. Then in my cmakeLists.txt file for my project I have,
`find_package(cartographer REQUIRED)
if(cartographer_FOUND)
message(STATUS "Cartographer Found!!")
endif(cartographer_FOUND)
set(CARTOGRAPHER_CONFIGURATION_FILES_DIRECTORY ${cartographer_DIR}/configuration_files
CACHE PATH ".lua config file directory")
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(cartographer DEFAULT_MSG cartographer_DIR)
message(STATUS "Cartographer CMAKE Directory = " ${CARTOGRAPHER_CMAKE_DIR})
message(STATUS "Cartographer Source Directory = " ${cartographer_DIR})
message(STATUS "Cartographer Config Directory = " ${CARTOGRAPHER_CONFIGURATION_FILES_DIRECTORY})
message(STATUS "Cartographer Module Directory = " ${CMAKE_MODULE_PATH})`
The output from cmake in this section gives
"-- Found installed version of Eigen: /usr/lib/cmake/eigen3
-- Found required Ceres dependency: Eigen version 3.3.4 in /usr/include/eigen3
-- Found required Ceres dependency: glog
-- Found installed version of gflags: /usr/lib/x86_64-linux-gnu/cmake/gflags
-- Detected gflags version: 2.2.1
-- Found required Ceres dependency: gflags
-- Ceres version 1.14.0 detected here: /usr/local was built with C++11. Ceres target will add C++11 flags to compile options for targets using it.
-- Found Ceres version: 1.14.0 installed in: /usr/local with components: [EigenSparse, SparseLinearAlgebraLibrary, LAPACK, SuiteSparse, CXSparse, SchurSpecializations, C++11, OpenMP, Multithreading]
-- Cartographer Found!!
-- Cartographer CMAKE Directory = /usr/local/share/cartographer/cmake
-- Cartographer Source Directory = /usr/local/share/cartographer
-- Cartographer Config Directory = /usr/local/share/cartographer/configuration_files
-- Cartographer Module Directory = /usr/local/share/cartographer/cmake/modules"
Searches for linking abseil brought me to a file called  FindAbseil.cmake. This file looks like it creates the library. I did try to add the file to the cartographer repo under cmake/modules and then rerun cmake, ninja, and ninja install commands. Being a module would it be more appropriate to use find_package(Abseil REQUIRED MODULE)?

The above works without any issue. I just found that as long as the abseil install step is done first, and then cartogrpaher is built, there are not any issues and the FindAbseil.cmake is not necessary.


ZooKeeper 3.4.13 is now archived version

Ok, seems we should have referenced a stable version right from the beginning?

We are referring to version used in Kafka, which is the older one. The original URL does the magic of dowloading from the nearest mirror. That's not supported for older releases when only single location is available.


[ENH][DOC] add instructions to existing users how to migrate their locar repos to main branch

Is your feature request related to a problem? Please describe.
see #1584 - we plan to change the name of master branch to main, if we do, links on GH are updated, but users will have to follow directions to update their local repos
Describe the solution you'd like
Add a temporary section to the docs? announce on google groups
Describe alternatives you've considered
do nothing, just announce on g-group, point users to GH docs
Additional context
IMHO, I have dragged my feet too long on this, just need to do it asap. It will be confusing for a few days, then done

I'm thinking something on this page: https://pvlib-python.readthedocs.io/en/stable/contributing.html

do nothing, just announce on g-group, point users to GH docs

This. The only people that will be effected are those that can deal with it with reasonable effort. No need to reinvent GH docs.

@wholmgren then I suggest just go ahead and do it now. I'll post something on google groups linking to the discussion or the GH help docs

FYI: @pvlib/pvlib-core - I can't make the change, I can't see the settings tab in pvlib

@mikofski simply rename master branch to main?

I believe we can follow the steps here: https://github.com/github/renaming#renaming-existing-branches

and here: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch

then users do what it says here: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch#updating-a-local-clone-after-a-branch-name-changes
$ git branch -m OLD-BRANCH-NAME NEW-BRANCH-NAME
$ git fetch origin
$ git branch -u origin/NEW-BRANCH-NAME NEW-BRANCH-NAME
$ git remote set-head origin -a
$ git remote prune origin

Here is what GH says when renaming master to main:

Will update 36 pull requests targeting this branch across 23 repositories.
Will update 1 branch protection rule that explicitly targets master.

instructions to update local environments:
git branch -m master <BRANCH>
git fetch origin
git branch -u origin/<BRANCH> <BRANCH>
git remote set-head origin -a

OK, it's done. All contributors please update your local environments following GH instructions.

note replace  with "main" so:
git branch -m master main
git fetch origin
git branch -u origin/main main
git remote set-head origin -a
git remote prune origin

@pvlib/pvlib-core  here's a wrinkle, my personal fork is not auto updated, I see this lovely GH message

so that's another step, to rename master branch in my personal fork as well!

git fetch origin

Probably most people will have origin set to their own fork, right?  I have kanderso-nrel/pvlib-python as origin and pvlib/pvlib-python as upstream.  I think people will need to rename the branch in their fork on github before these local commands are applicable.

Here's what the renaming process looked like for me, with my mistakes included 😉 😜

anyway, not too painful and all good now 👍 😺

GH really holding our hands here, saw this on upstream:

@kanderso-nrel  I had one more wrinke, after updating origin and my local environment, I still had this:

So I reran the GH commands with "upstream" as you suggested

now all good


Documentation update

I updated the docs so that the module might be a little more accessible.

Hi Michael, can you update the PR to fix the conflict?
I've put screenshots into a folder screenshot
Once it's updated, I'll merge it! Thanks

I have no possibility to fix it this week. Will fix it next week.
On 12 Nov 2016, at 13:52, JerryShen <notifications<EMAIL_ADDRESS>wrote:
Hi Michael, can you update the PR to fix the conflict?
I've put screenshots into a folder screenshot
Once it's updated, I'll merge it! Thanks

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/awesomejerry/react-native-qrcode-svg/pull/8#issuecomment-260120437, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AERoDXsM972IQwXq-l3wPHg-Kq6UkbF6ks5q9bZsgaJpZM4KwYrp.

Cool! It's no hurry!


Add support for loading Fortran contiguous tensors

This commit introduces the ability to handle Fortran contiguous tensors in the tensor loading process. Previously, the code only supported loading tensors that were contiguous in memory, failing with an error for non-contiguous tensors. With this update, tensors identified as Fortran contiguous (column-major order) are now correctly handled by reversing their dimensions after loading. This enhancement ensures broader compatibility with different tensor layouts, improving the robustness of tensor loading operations.

Check if a tensor is Fortran contiguous using the is_fortran_contiguous flag.
For Fortran contiguous tensors, reverse the dimensions after loading to correctly represent their layout in memory.
Continue to bail out with an error for tensors that are neither C contiguous nor Fortran contiguous, maintaining the previous behavior for non-contiguous tensors without explicit support.

This change addresses the issue of loading Fortran contiguous tensors, which was previously unsupported, thereby extending the functionality of the tensor loading mechanism to accommodate a wider variety of tensor layouts.
I have tested with Whisper's pt files and added a new unit test just to cover this special case.

Thanks!


Feature/3466 add unit tests for order module

Related issues
#3466
Short description and why it's useful
Unit tests for Order module
Which environment this relates to
Check your case. In case of any doubts please read about Release Cycle

[X] Test version (https://test.storefrontcloud.io) - this is a new feature or improvement for Vue Storefront. I've created branch from develop branch and want to merge it back to develop
[ ] RC version (https://next.storefrontcloud.io) - this is a stabilisation fix for Release Candidate of Vue Storefront. I've created branch from release branch and want to merge it back to release
[ ] Stable version (https://demo.storefrontcloud.io) - this is an important fix for current stable version. I've created branch from hotfix or master branch and want to merge it back to hotfix

Upgrade Notes and Changelog

[x] No upgrade steps required (100% backward compatibility and no breaking changes)
[X] I've updated the Upgrade notes and Changelog on how to port existing VS sites with this new feature

IMPORTANT NOTICE - Remember to update CHANGELOG.md with description of your change
Contribution and currently important rules acceptance

[X] I read and followed contribution rules

@dz3n Hey, thanks for PR, please change base to release/v1.11


Item Deletion

via -deleteItemsAtIndexPaths:withAnimation:

Is this still an issue? I have't played with deletion too much, so I don't know if some aspect of it isn't working yet.

Thanks, @itaiferber. I'd be really happy if someone would take this on; unfortunately, I won't be able to address this in the near future.

I'd love to contribute, but I'm busy too right now. Hopefully soon...

I'll try to set up a sample for you.
On Jan 12, 2012, at 6:58 PM, Kolin Krewinkel wrote:

Okay, sweet. Give me a procedure and I'll test it with breakpoints and slow motion animations.
Sent from my iPhone
On Jan 12, 2012, at 3:56 PM, Itai<EMAIL_ADDRESS>wrote:

If you'd like, I can show you a demo. I deselect all items before moving them. There's definitely some freaky animation going on if you delete items with animation.

Reply to this email directly or view it on GitHub:
https://github.com/kolinkrewinkel/KKGridView/issues/18#issuecomment-3472959

Reply to this email directly or view it on GitHub:
https://github.com/kolinkrewinkel/KKGridView/issues/18#issuecomment-3472989


default password does not work for SDcard image

subj,
please assist with default login/password for aprs-pigate
id does not work for local login nor SSH

Did you resolve this?  It is case sensitive ** raspberry **
If it's not working try a new flash of the image.
Adam

Sure, but ** raspberry ** does not work.
Maybe you can update image and make sure that?

Понедельник, 7 февраля 2022, 11:28 -05:00 от Adam @.***>:

Did you resolve this? It is case sensitive ** raspberry **
If it's not working try a new flash of the image.
Adam
—


Update unmaintained packages

Motivation for this change
This PR updates a bunch of unmaintained packages (as reported by monitor). I test-build all of these PRs (in the order they are committed) using a Debian 8 VM with nix installed. Details below.
I updated them by fetching the packages and running nix-script update-package-def (see my nixos-scripts)with appropriate flags for building etc. in a loop.
Please note that I did not execute them or test them in any way besides the build (nix-build -A <pkg> --cores 8 -j 16).
Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] OS X
[x] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Details on the machine I used to build:
m@banane:~$ uname -a
Linux banane 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux
m@banane:~$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=debian
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
m@banane:~$ nix-env --version
nix-env (Nix) 1.11.2
m@banane:~$

:-1: on the wayland update. .91 is alpha, there is already .93 which is RC1. But I think our policy is not to update to unstable versions if there is no reason.
If this gets merged please also update weston to the same version.

This is not a full PR review, but I noticed that you have a "evince: 3.18.2 -> 3.20.0" in there. I'm pretty sure that update is planned to be done in the (separate) GNOME 3.20 PR: https://github.com/NixOS/nixpkgs/pull/14366.

The postfix update isn't the newest version (3.1.1)
There's a imcompat change according to their 3.1 releasenotes :

[Incompat 20150719] The default Diffie-Hellman non-export prime was updated from 1024 to 2048 bits, because SMTP clients are starting to reject TLS handshakes with primes smaller than 2048 bits.

So this possibly needs review?

@groxxda Will remove the patch for wayland. Not sure on the postfix part, shall I remove this one, too?

@bjornfor I will remove the patch for evince.

I my opinion the postfix update should be fine - but I'd rather update to the newest patchset (3.1.1) :wink:
By the way: You might want to check your git.name setting.

I just made another PR for feh: #15859

@groxxda What is about my git.name setting?
@mbakke Should I remove my feh patch?

 I will rewrite the history once the discussions in here came to a conclusion anyways, I will fix that then.
@joachifm If you feel uncomfortible with that I will take the patches out if you want to.

@matthiasbeyer if you do not intend to test the packages, I suggest at least factoring them out in separate PRs, to allow their maintainers to provide some feedback, instead of making this an all-or-nothing kind of deal.

@mbakke Should I remove my feh patch?

Yes, a newer version is already merged.

@groxxda postfix patch isn't provided by monitor, so I'll remove the patch instead of adding one update by hand.

I've extracted the less update into #15868 as I've been meaning to modify the expression for a while.

varnish, redis, musl, ncurses, openvpn, and asterisk also seem like stuff that should be submitted separately. R can be dropped, as its already out of date. The less patch has been merged.

Removed R and less.

vifm, signing-party, icewm, discount, and diffstat have been merged.

@joachifm removed the updates you named from the PR.

I hope we soon get Hydra to build github PRs. I think that will help a lot with PRs such as this. (If nothing breaks, even NixOS tests, we can safely merge.)

@bjornfor I'll work on that soon.
@matthewbauer did these get merged? In general it's easier to have a PR per minimal mergable branch, most of our big PRs just hang around.

Funny. I just closed this PR because of its age ...

@matthewbauer that's why I said that, it's not that we do not want these changes, it's just hard to get them through.
Once we have a PR testing on Hydra situation will be different, but at the moment our workflow doesn't allow us easy testing :/

Sorry about that, if you find motivation to split these into smaller blocks I'm sure we'll get those merged eventually.

@domenkozar I guess you mean me... no, I guess I will wait until we have hydra working on PRs and then start to file PRs like this one. You are right, before we do not have decent testing, PRs like this do not make a lot of sense.

I certainly agree that that big PRs are hard to get through in general. On most days I personally don't have enough time to finish a big one, so I tend to focus on smaller ones.
If these are changes from nixpkgs monitor, that one also attempts to build the changes (besides the submitter in this case). The PR testing on Hydra would do the same, right? ... perhaps including all reverse dependencies, though.
BTW, I think a couple of these packages have been updated independently already, but that shouldn't matter.

Yeah, I have a script to where I simply paste a monitor patch link and it applies the patch and also test-compiles it.
I really should tweak this script to only apply if compiling works. Then I could use the HPC cluster from my university for something good... :smile:


ci to build scala artifact with tests on pr and merge and release

[ ]  enable scovarage plugin
addSbtPlugin("org.scoverage" % "sbt-scoverage" % "1.9.2")

enablePlugins(ScoveragePlugin)

// Set minimum coverage percentage threshold to 80%
coverageMinimum := 80

// Exclude certain files or packages from coverage analysis
coverageExcludedPackages := "com.example.myapp.api.*" :: Nil
coverageExcludedFiles := "com/example/myapp/Main.scala" :: Nil

// Configure report generation options
coverageReportHTML := true
coverageReportCobertura := true

      - name: Run tests with Scoverage
        run: sbt clean coverage test

      - name: Generate Scoverage reports
        run: sbt coverageReport


Fixes #D1288: Clicking enter when adding custom emoji removes image/gif

Issue #D1288 states that there is a bug with pressing enter key while adding a custom emoji. While adding a custom emoji, pressing enter key does not trigger submitting and it removes the current uploaded file from the modal.
Fixes:  #D1288

Screenshots and screen captures:
At waits I am pressing enter key
Before Implementation:

After Implementation:

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[x] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[x] Responsiveness and internationalization.
[x] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

@enesonus can you explain the changes here? I don't understand the changes -- it seems like removing the form attribute on the button might have other consequences than just addressing this bug.

@timabbott thanks for the review!
I did further debugging on my dev env and saw that the code block I changed is slightly buggy and breaks the working mechanism of other modal forms since it checks for emoji name and emoji file input. So my code works only for add-custom-emoji-modal. Since the bug persists, I did some deeper investigation on add-custom-emoji-modal. I saw that actually conf.form_id is null at the start of the modal since at settings_emoji.js we do not declare any form_id for add-custom-emoji-modal.
// settings_emoji.js
dialog_widget.launch({
        html_heading: $t_html({defaultMessage: "Add a new emoji"}),
        html_body,
        html_submit_button: $t_html({defaultMessage: "Confirm"}),
        id: "add-custom-emoji-modal",
        loading_spinner: true,
        on_click: add_custom_emoji,
        post_render: add_custom_emoji_post_render,
    });

In addition to that I think the problem of vanishing of uploaded image is happening because when there is an uploaded file, "emoji_image_clear_button" gets rendered with the "form" attribute assigned to "add-custom-emoji-form" since the button is inside the form. Assigning a form_id for this modal at launch is not the solution for this problem because enter key triggers the clear image button instead of confirm button. So we can trigger a clicking action for enter keypress by checking if the inputs are valid but i think i would need a bit of help for how to validate the incoming input.
Any help would be appreciated.

Please update this PR description and commit message to point to the new location of this issue (#24972).

If you'd like help with next steps, please post a specific question in the #frontend stream in the Zulip development community. Be sure to follow https://zulip.readthedocs.io/en/latest/contributing/asking-great-questions.html. Thanks!

The original issue was fixed by https://github.com/zulip/zulip/pull/26144. Thanks for contributing @enesonus!


Data folder not found while running the demo

Hi! Im having the following problem while running the demo:
Traceback (most recent call last):
  File "./tools/demo.py", line 84, in <module>
    imdb = get_imdb(args.imdb_name)
  File "/home/fmartinez/ERL/PoseCNN/tools/../lib/datasets/factory.py", line 116, in get_imdb
    return __sets[name]()
  File "/home/fmartinez/ERL/PoseCNN/tools/../lib/datasets/factory.py", line 57, in <lambda>
    datasets.lov(split))
  File "/home/fmartinez/ERL/PoseCNN/tools/../lib/datasets/lov.py", line 55, in __init__
    'Data path does not exist: {}'.format(self._data_path)
AssertionError: Data path does not exist: /home/fmartinez/ERL/PoseCNN/tools/../lib/datasets/../../data/LOV/data

Any idea of what should I do?

Just create the folder


SVGElement.offsetHeight deprecation

Hi,
Just wanted t to remind you guys that SVGElement.offsetHeight is being deprecated and will be removed by April 2016.
warning in chrome console:
'SVGElement.offsetHeight' is deprecated and will be removed in M50, around April 2016. See https://www.chromestatus.com/features/5724912467574784 for more details.

Here’s the console warning:

And the exact place in the minified code:

Looks like this is the corresponding place. (I’m using the outdated library version, so the minified code on a previous screenshot is a bit different.)
ChromeStatus states that offsetHeight for SVG is only implemented in Blink/Webkit and is not supported by any other browser, so I believe we can easily delete this. @davelandry, should I submit a PR?

Great find @iamakulov. I'm a little scared of this breaking stuff, but there's only 1 way to find out. Please do a pull request!


Fix backward compatibility in host triple checks

When setting host triple in Swift SDKs to arm64-apple-macosx13.0 to allow cross-compiling from an older version of macOS, this triple is not recognized as directly matching arm64-apple-macosx14.0 on a newer version of macOS.
We should support backward compatibility with Swift SDKs that were built for older version of macOS.
Resolves rdar://113967401.

@swift-ci smoke test

@swift-ci test windows

@swift-ci smoke test

@swift-ci test windows

@swift-ci test windows

@swift-ci test

@swift-ci test

This looks reasonable to me, though again I would love to see Triple moved to a distinct target shared between driver and pm

@swift-ci test windows

@swift-ci test

@swift-ci test windows

@swift-ci test windows

@swift-ci test

@swift-ci test windows


Random quit when in Downloads folder.

I had just downloaded a video from my whatsapp web, and was about to delete it because it had downloaded twice. I right-clicked to select delete, but then decided to press delete on the keyobard. The app decided to quit, and i got a windows notification asking me to report the problem. I don't have any screenshots.
OS: Windows 10 Pro 10.0.19042 Build 19042(I am in the Windows Beta Insider programme).
App Version: <IP_ADDRESS>
Zip.zip

Also i had downloaded the app from the Windows Store

@RadioActiveEssence Is this still an issue in v0.21.1?

Thanks again for your feedback.
Since we didn't hear from you on this topic for 7+ days, we'll assume everything is worked out and close this feedback item. If you had more feedback to provide, please re-open this and help the owners by describing the current status and any steps taken to troubleshoot this.


Azure CLI Deployment Example For VM Scale Set Has Incorrect Parameter

The VM scale set example uses --vm-name when it should be --vmss-name according to "az vmss extension set --help"

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

ID: a52b0724-6b3b-0daf-7749-d18104d6a40b
Version Independent ID: 56e5c7c4-f456-fc2e-99da-2771eb162947
Content: Azure Key Vault VM Extension for Windows
Content Source: articles/virtual-machines/extensions/key-vault-windows.md
Service: virtual-machines-windows
GitHub Login: @msmbaldwin
Microsoft Alias: mbaldwin

Thanks for the feedback! We are currently investigating and will update you shortly.

There is also a missing quote in the settings string.
"observedCertificates": [\ "]
Should be
"observedCertificates": [" "]

@vanderby fixed :) Once the PR merges the changes will go live after a few hours. Thanks for the find!


New implementation of FileSystemProvider for tekton resources

This PR also add onFileSystem activation event, so now vscode will able load previously opened tekton resource after vscode restart.
Also it change a way how extension refresh file content after save, so now it use event to inform vscode that file was changed and vscode automatically update editor contant.
Fix: #276

Codecov Report

Merging #285 into master will increase coverage by 0.26%.
The diff coverage is 94.73%.

@@            Coverage Diff             @@
##           master     #285      +/-   ##
==========================================
+ Coverage   69.88%   70.14%   +0.26%
==========================================
  Files          42       42
  Lines        3105     3092      -13
  Branches      568      562       -6
==========================================
- Hits         2170     2169       -1
+ Misses        935      923      -12

Impacted Files
Coverage Δ

src/tekton/tektonitem.ts
33.74% <66.66%> (ø)

src/util/tekton-vfs.ts
96.25% <96.25%> (ø)

src/extension.ts
87.15% <100.00%> (ø)

src/pipeline/pipeline-graph.ts
57.57% <100.00%> (ø)

src/tkn.ts
69.27% <100.00%> (ø)

src/yaml-support/tkn-editing.ts
97.18% <100.00%> (ø)

Continue to review full report at Codecov.

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


Gateway validates based on own databaseType

When generating entities on the Gateway with a Microservice's JDL, the validation uses the Gateway's databaseType.  It should just generate the UI as the entity has no server code.  Two examples:

When the Gateway uses Cassandra, the microservice entities are checked for Cassandra fields even if the entity table (in the microservice) uses another database type.  In this case, ZonedDateTime is not an allowed type (works for MySQL though).
Related issue is that the gateway shouldn't validate relationships for microservice entities.  If the Gateway uses MongoDB, the entities are checked for relationships and the error NoSQL entities don't have relationships. is thrown.

This sample JDL has two entities for the microservice testservice which will fail to generate a UI on a Gateway that uses MongoDB or Cassandra.
entity Book {
    dateWritten ZonedDateTime // broken in Cassandra gateway - no ZonedDateTime support
}
entity Author

relationship OneToMany {
  // broken in MongoDB gateway
  Author{book} to Book{writer(name)}
}
microservice * with testservice

Cassandra Gateway .yo-rc.json

{
  "generator-jhipster": {
    "jhipsterVersion": "3.7.1",
    "baseName": "gway",
    "packageName": "com.mycompany.myapp",
    "packageFolder": "com/mycompany/myapp",
    "serverPort": "8080",
    "authenticationType": "jwt",
    "hibernateCache": "no",
    "clusteredHttpSession": false,
    "websocket": false,
    "databaseType": "cassandra",
    "devDatabaseType": "cassandra",
    "prodDatabaseType": "cassandra",
    "searchEngine": false,
    "buildTool": "maven",
    "enableSocialSignIn": false,
    "jwtSecretKey": "d93eaf394dbac702198a0ea3c1c25e17b866dd2d",
    "useSass": false,
    "applicationType": "gateway",
    "testFrameworks": [
      "gatling"
    ],
    "jhiPrefix": "jhi",
    "enableTranslation": true,
    "nativeLanguage": "en",
    "languages": [
      "en"
    ]
  }
}

Mongo Gateway .yo-rc.json
{
  "generator-jhipster": {
    "jhipsterVersion": "3.7.1",
    "baseName": "mongogway",
    "packageName": "com.mycompany.myapp",
    "packageFolder": "com/mycompany/myapp",
    "serverPort": "8080",
    "authenticationType": "jwt",
    "hibernateCache": "no",
    "clusteredHttpSession": false,
    "websocket": false,
    "databaseType": "mongodb",
    "devDatabaseType": "mongodb",
    "prodDatabaseType": "mongodb",
    "searchEngine": false,
    "buildTool": "maven",
    "enableSocialSignIn": false,
    "jwtSecretKey": "26bb5ea6615157ff5cdc9aec596d4b79043e5b7f",
    "useSass": false,
    "applicationType": "gateway",
    "testFrameworks": [
      "gatling"
    ],
    "jhiPrefix": "jhi",
    "enableTranslation": true,
    "nativeLanguage": "en",
    "languages": [
      "en"
    ]
  }
}

Testservice Microservice .yo-rc.json
{
  "generator-jhipster": {
    "jhipsterVersion": "3.7.1",
    "baseName": "testservice",
    "packageName": "com.mycompany.myapp",
    "packageFolder": "com/mycompany/myapp",
    "serverPort": "8081",
    "authenticationType": "jwt",
    "hibernateCache": "hazelcast",
    "clusteredHttpSession": false,
    "websocket": false,
    "databaseType": "sql",
    "devDatabaseType": "h2Disk",
    "prodDatabaseType": "mysql",
    "searchEngine": false,
    "buildTool": "maven",
    "enableSocialSignIn": false,
    "jwtSecretKey": "4c51bb3f31ca75ff5d648c95c391cddb654dd434",
    "enableTranslation": true,
    "applicationType": "microservice",
    "testFrameworks": [
      "gatling"
    ],
    "jhiPrefix": "jhi",
    "skipClient": true,
    "skipUserManagement": true,
    "nativeLanguage": "en",
    "languages": [
      "en"
    ]
  }
}

I think I can fix it pretty easily. I'll see about that tomorrow.

Is this handled correctly in the entity sub generator?
Thanks & regards,
Deepu
On 20 Sep 2016 02:08, "Mathieu ABOU-AICHI"<EMAIL_ADDRESS>wrote:

I think I can fix it pretty easily. I'll see about that tomorrow.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/jhipster-core/issues/60#issuecomment-248118606,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF-F8_CKyBBtKa-NA85dSYBn8m-6wks5qrvK6gaJpZM4KA22I
.

JHipster Core's ReservedKeywords module checks if a class name, a field, or a table name is reserved. To do so, a database type has to be passed (and nothing else except the value to check). Here, JHipster core has no business knowing what is passed as database type, or application type... it just "checks".
After all, it ultimately depends on where you use the subgen. @deepu105 @ruddell I don't think JHipster core is at fault here. It's only a lib. Correct me if I'm wrong but I don't see what's to be done here.

I agree with Mathew. Jh core is agnostic of where we use the parser and for
what. Hence if we are running a microservice JDL we need to pass in the db
type appropriately from the sub generator itself. Its bit tricky but should
be possible to do similar to how we do it on entity sub generator. Let me
take a look at what can be done when I find time.
Thanks & regards,
Deepu
On 7 Oct 2016 01:31, "Mathieu ABOU-AICHI"<EMAIL_ADDRESS>wrote:

JHipster Core's ReservedKeywords module checks if a class name, a field,
or a table name is reserved. To do so, a database type has to be passed
(and nothing else except the value to check). Here, JHipster core has no
business knowing what is passed as database type, or application type... it
just "checks".
After all, it ultimately depends on where you use the subgen. @deepu105
https://github.com/deepu105 @ruddell https://github.com/ruddell I
don't think JHipster core is at fault here. It's only a lib. Correct me if
I'm wrong but I don't see what's to be done here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/jhipster-core/issues/60#issuecomment-252072387,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF2gQNZyWxyV41slrKQUjmpMGQ9NUks5qxVOrgaJpZM4KA22I
.

I took another look at this issue today.  The original issue was slightly off when it mentioned reserved keywords, they are fine (updated the first post).  The problem is dealing with field types in jdl_parser.js and relationships in entity_parser.js.
A databaseType is required for both the JDL Parser and Entity Parser.  This databaseType must be 'sql', 'mysql', 'mariadb', 'postgresql', 'oracle', 'mongodb', or 'cassandra'.  We don't store the path to the microservice or its databaseType in the entity JDL so we can't pass either when importing the JDL in the generator.
Not sure what the fix is.

Yes you are right we would either need the path or the db type in the JDL
to do this.
Mathew how about adding microserviceDbType as an option in JDL?
Thanks & regards,
Deepu
On 30 Oct 2016 02:15, "Jon Ruddell"<EMAIL_ADDRESS>wrote:

I took another look at this issue today. The original issue was slightly
off when it mentioned reserved keywords, they are fine (updated the first
post). The problem is dealing with field types in jdl_parser.js and
relationships in entity_parser.js.
A databaseType is required for both the JDL Parser and Entity Parser. This
databaseType must be 'sql', 'mysql', 'mariadb', 'postgresql', 'oracle',
'mongodb', or 'cassandra'. We don't store the path to the microservice or
its databaseType in the entity JDL so we can't pass either when importing
the JDL in the generator.
Not sure what the fix is.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/jhipster-core/issues/60#issuecomment-257115030,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF9RCdSwa49164bUXplbJm0xkSLpCks5q47BTgaJpZM4KA22I
.

To be honest, I thought about adding it but wasn't sure it would be relevant enough... Let's do it =)

Update: @deepu105 No, not yet anyway. It will be done after I make the JDL create a JHipster app, which is really easy. However, if we make the db type available for the validation, then we win. If you wanna do it, by all means as you've created and updated it.

I wont have much time this week. Btw to generate app from JDL would need
some work on the generator as well
Thanks & regards,
Deepu
On 31 Oct 2016 02:47, "Mathieu ABOU-AICHI"<EMAIL_ADDRESS>wrote:

Update: @deepu105 https://github.com/deepu105 No, not yet anyway. It
will be done after I make the JDL create a JHipster app, which is really
easy. However, if we make the db type available for the validation, then we
win. If you wanna do it, by all means as you've created and updated it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/jhipster-core/issues/60#issuecomment-257179907,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF2febx5ImJlq7t0SrCfEIIcVD_z8ks5q5QldgaJpZM4KA22I
.

Oh? You mean that if I provide a .yo-rc.json, it won't work?
Le 31 octobre 2016 05:05:41 GMT+01:00, Deepu K Sasidharan<EMAIL_ADDRESS>a écrit :

I wont have much time this week. Btw to generate app from JDL would
need
some work on the generator as well
Thanks & regards,
Deepu
On 31 Oct 2016 02:47, "Mathieu ABOU-AICHI"<EMAIL_ADDRESS>wrote:

Update: @deepu105 https://github.com/deepu105 No, not yet anyway.
It
will be done after I make the JDL create a JHipster app, which is
really
easy. However, if we make the db type available for the validation,
then we
win. If you wanna do it, by all means as you've created and updated
it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

https://github.com/jhipster/jhipster-core/issues/60#issuecomment-257179907,

or mute the thread

https://github.com/notifications/unsubscribe-auth/ABDlF2febx5ImJlq7t0SrCfEIIcVD_z8ks5q5QldgaJpZM4KA22I

.

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jhipster/jhipster-core/issues/60#issuecomment-257210048

--
Mathieu ABOU-AICHI

Then you need run the generator again rite so the import jdl sub gen would
need some modifications to generate app from the yo-rc file and then
generate entities
Thanks & regards,
Deepu
On 31 Oct 2016 15:07, "Mathieu ABOU-AICHI"<EMAIL_ADDRESS>wrote:

Oh? You mean that if I provide a .yo-rc.json, it won't work?
Le 31 octobre 2016 05:05:41 GMT+01:00, Deepu K Sasidharan <
<EMAIL_ADDRESS>a écrit :

I wont have much time this week. Btw to generate app from JDL would
need
some work on the generator as well
Thanks & regards,
Deepu
On 31 Oct 2016 02:47, "Mathieu ABOU-AICHI"<EMAIL_ADDRESS>wrote:

Update: @deepu105 https://github.com/deepu105 No, not yet anyway.
It
will be done after I make the JDL create a JHipster app, which is
really
easy. However, if we make the db type available for the validation,
then we
win. If you wanna do it, by all means as you've created and updated
it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

<https://github.com/jhipster/jhipster-core/issues/60#
issuecomment-257179907>,

or mute the thread

<https://github.com/notifications/unsubscribe-auth/
ABDlF2febx5ImJlq7t0SrCfEIIcVD_z8ks5q5QldgaJpZM4KA22I>

.

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jhipster/jhipster-core/issues/60#
issuecomment-257210048

--
Mathieu ABOU-AICHI
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/jhipster-core/issues/60#issuecomment-257250205,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF1v7hkxQIjgBz0nD__d9kzHxkEFaks5q5bbTgaJpZM4KA22I
.

Well, I'll test some things then
Le 31 octobre 2016 10:49:36 GMT+01:00, Deepu K Sasidharan<EMAIL_ADDRESS>a écrit :

Then you need run the generator again rite so the import jdl sub gen
would
need some modifications to generate app from the yo-rc file and then
generate entities
Thanks & regards,
Deepu
On 31 Oct 2016 15:07, "Mathieu ABOU-AICHI"<EMAIL_ADDRESS>wrote:

Oh? You mean that if I provide a .yo-rc.json, it won't work?
Le 31 octobre 2016 05:05:41 GMT+01:00, Deepu K Sasidharan <
<EMAIL_ADDRESS>a écrit :

I wont have much time this week. Btw to generate app from JDL would
need
some work on the generator as well
Thanks & regards,
Deepu
On 31 Oct 2016 02:47, "Mathieu ABOU-AICHI"
<EMAIL_ADDRESS>wrote:

Update: @deepu105 https://github.com/deepu105 No, not yet
anyway.
It
will be done after I make the JDL create a JHipster app, which is
really
easy. However, if we make the db type available for the
validation,
then we
win. If you wanna do it, by all means as you've created and
updated
it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

<https://github.com/jhipster/jhipster-core/issues/60#
issuecomment-257179907>,

or mute the thread

<https://github.com/notifications/unsubscribe-auth/
ABDlF2febx5ImJlq7t0SrCfEIIcVD_z8ks5q5QldgaJpZM4KA22I>

.

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jhipster/jhipster-core/issues/60#
issuecomment-257210048

--
Mathieu ABOU-AICHI
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

https://github.com/jhipster/jhipster-core/issues/60#issuecomment-257250205,

or mute the thread

https://github.com/notifications/unsubscribe-auth/ABDlF1v7hkxQIjgBz0nD__d9kzHxkEFaks5q5bbTgaJpZM4KA22I

.

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jhipster/jhipster-core/issues/60#issuecomment-257252523

--
Mathieu ABOU-AICHI


Large regression on master

In the process of getting our benchmarking pipeline up and running, I noticed there was apparently a large regression (4x-5x performance loss across about half our current benchmarks) introduced on master starting at commit f9016283. asv plots can be examined here.

Nice catch! I confirmed the large runtime regressions locally. Even after the pandas 0.18.0 RangeIndex update (commit here), there is still a large enough performance hit that this needs to be fixed before release. We were prepared to take a small memory hit when merging f9016283 but didn't account for this runtime hit.
The issue is that creating an empty DataFrame (regardless of size) takes ~190 microseconds. This slows down Sequence construction when no metadata is present, so this performance hit propagates to a lot of Sequence methods and things that use Sequence. For a startling example, Sequence kmer methods are now ~26x slower because lots of Sequence objects are being constructed. Even though this performance bug only affects Sequence objects without metadata, it's a relatively common case. For example, when reading a FASTA file without a QUAL file, you get Sequence objects without positional_metadata. Thus, this performance bug is likely to be noticed by users.
Reverting f9016283 is not trivial as other updates have been made to that code, resulting in many merge conflicts. Additionally, that merge commit has other changes we want to keep in the codebase, so it'd be a manual, time-consuming process to revert. Reverting will only exacerbate the original motivation for removing the "empty metadata" optimizations once IntervalMetadata exists on Sequence. The previous optimization simply does not scale because any method on any object that handles metadata needs to carefully use the optimization guards has_metadata/has_positional_metadata, leading to fragile code that requires careful review to prevent hidden performance bugs. Further, each method needs a corresponding unit test that tests private state to make sure these performance bugs don't exist.
After talking with @gregcaporaso and @ebolyen, we have the following plan. Instead of reverting, missing/empty metadata will be stored as None, both internally and at the public API level. This avoids the need for has_metadata/has_positional_metadata optimization guards, private state unit tests, and hidden performance bugs. It reduces cognitive load for scikit-bio devs and reviewers because you can access metadata publicly or privately and get the same object back. It reduces cognitive load on users because checking for metadata simply becomes obj.metadata is None, which is more Pythonic than a special has_metadata method. Further, it removes the ambiguity of what makes metadata "empty" or "not present". We even had conflicting definitions of what makes a DataFrame "empty" (is it lack of index, columns, or index OR columns?) and has_positional_metadata doesn't match DataFrame.empty. Using None as the null/missing value avoids this mess entirely and fixes the performance regression.
This will introduce a backward-incompatible change to stable API. It will affect users who access .metadata or .positional_metadata (the public attribute getter only) where no metadata was previously provided to the object. Previously, they'd receive an empty dict or DataFrame, now they will receive None. In practice this should only affect users who were expecting an "empty" metadata object, likely to mutate further in application code. Now users will receive a NoneType error if trying similar operations on None. Again, this will only affect users who are manipulating empty/missing metadata. To help developers update their code, we will provide methods to obtain "empty" metadata, which can then be manipulated as usual in application code and added back to the object with metadata setters.
An example should make this clearer:
Previous API:
seq = Sequence('ACGT')
seq.metadata # empty dict, {}
seq.metadata['foo'] = 'bar'

New API:
seq = Sequence('ACGT')
seq.metadata # None
seq.metadata = {}
seq.metadata['foo'] = 'bar'

While breaking stable API is highly undesirable, we would rather do this over reverting for the reasons described above. Another option is to have a special scikit-bio import that monkey-patches the metadata getters to use the new API (and the old API raises a warning). While this would avoid breaking stable API, all (or nearly all) application developers would be forced to update their code to use this new import and API, and if they don't do this, they could be impacted by the performance bug. It also isn't guaranteed that application developers will notice the warning telling them to update their code, so it seems better to have this breaking change (for some application devs) over the risk of introducing serious performance bugs.
Since this is a backwards-incompatible stable API change, we plan to put together a concise guide to help devs transition their code to the new API. We'll tweet/gitter about this upcoming change before the release and try our best to notify packages using scikit-bio (e.g. using Depsy to figure that out).
If anyone actually read this far and has questions/comments/concerns, please get in touch!

Thanks for the detailed write-up @jairideout!

After more discussion with @gregcaporaso and @ebolyen, we decided to reinstate the empty/missing metadata optimizations that were removed in #1321. We decided to revert for the following reasons:

avoid breaking stable public API
the current API is convenient for users because they don't have to check whether metadata is None before doing something with it
private-state unit tests will exist only for the metadata mixin classes (where that private state is defined). Instead of writing unit tests that test private state to ensure the performance of a method, users and developers are encouraged to submit ASV benchmarks if a method is determined to have suboptimal performance when handling missing/empty metadata. If the missing metadata guards has_metadata and has_positional_metadata aren't used and this isn't caught during review, the results should still be correct. If performance of the method becomes an issue, it can be addressed and benchmarked with ASV. This separates performance tests from unit (functional) tests and encourages the development of new benchmarks.

PR #1373 implements what I've described here.


Add Unit Testing for development

As the package becomes more and more complex, it is important to adopt unit testing. We can following the example of RMS.jl at https://github.com/ReactionMechanismGenerator/ReactionMechanismSimulator.jl/blob/ac2a3bd88504b86d5bc60dedc09533839a9c9cbb/src/Calculators/TestThermo.jl#L1-L60.
Some thoughts:

[ ] We could put the test files inside the src folder, with a consistent prefix, so that one can easily spot the actual source file.
[ ] We can test the functions against Cantera via PyCall. This should work well for most of the functionality.
[ ] @test Cps ≈ Cpexplist rtol=1e-3 where 1e-3 is a good default value for tolerance.

I had the same problem with the Julia restart, luckily we are not the first to have that issue. You can use the revise package: https://timholy.github.io/Revise.jl/stable/ .
Just call using Revise before using Arrhenius and then revise will check for changes to the source files and will apply those changes in the running session :).


"Birthday" Overlaps the Date Picker

Summary

the label overlaps the date picker
Expected Behavior

Both are readable
Environment

firefox, macos

いくつか同じ内容にissueが立っていたような気がする


SSO functionality (SAML / SCIM)

Summary
Support SAML 2.0 and JIT so that its easier to manage users.
SCIM would also be great.
Describe the solution you'd like
Let us configure the SAML settings in the TwillCMS interface so we can use a external identity provider for it. (e.g. okta, jumpcloud,...)
Additional context
In enterprises its good practice to centrally manage all users and this is done via SAML or SCIM nowadays.

Hello @LANopop,
I will close this issue as this is out of the scope of Twill.
Kind regards,


/en-US/docs/Web/HTTP/Cookies

Request type

[ ] Please close this issue, I accidentally submitted it without adding any details
[ ] New documentation
[x] Correction or update

Details

Under Cookie prefixes, the description of __Host says:

If a cookie name has this prefix, it will only be accepted in a Set-Cookie directive if it is marked Secure, does not include a Domain attribute and was sent from a secure origin. In this way, these cookies can be seen as "domain-locked".

It is missing that the cookie should also have the "Path" attribute set to "/".

Added; let me know if you think the wording looks OK.

I suggest the following to emphasize that the Path attribute is one of the conditions:
If a cookie name has this prefix, it will only be accepted in a Set-Cookie
directive if it is marked Secure, was sent from a secure origin, does not
include a Domain attribute, and has the Path attribute set to /. In
this way, these cookies can be seen as "domain-locked".

Sounds better to me; I've updated it as suggested.


ARROW-4025: [Python] Avoid pthread_once in ThreadPool

This seems to fix the TensorFlow/PyTorch crash for me.
Some disassembling (thanks for the hint @pitrou) brought up that pthread_once is called by the C++11 future library. Replacing it with boost seems to fix it (but unfortunately pulls in a number of other boost dependencies like atomic, chrono and date_time; I wonder if that is avoidable).

To test this, the manylinux1 base image needs to be rerun (in arrow/python/manylinux1) with
docker build -t arrow_manylinux1_x86_64_base -f Dockerfile-x86_64_base .

and then wheels can be generated with
docker run --shm-size=2g --rm -t -i -v $PWD:/io -v $PWD/../../:/arrow arrow_manylinux1_x86_64_base:latest /io/build_arrow.sh

Yuck. We don't want to bring in boost just to workaround Tensoflow's standard violations.
If you think this should be solved, I encourage you to find another way.

I'm also -0/-1 on eschewing C++11 future/thread -- that seems hardly sustainable. I think we need to engage the TF / PyTorch communities on this. It feels like they swiped the credit card, but sent the bill to our house.

It might mean that we have to create some kind of a pip wheel to hoist a modern C++ standard library into the environment (for PyTorch / TF to depend on) so they can avoid all this static linking insanity, similar to what's being done in conda now

Concerning 2) I have a sketch in this PR now. It's not ready yet and there are probably bugs at the moment but it may give you an idea on how this would look like.

I just took a look... Do you realize the thread pool can be called from several threads? If you wait for the thread pool to be idle, you may be waiting much longer than necessary.

At least now that we know that the problem comes from std::call_once and the futures, we have a way of attacking it :)

What if some other problem comes up? What if loading Gandiva (which is gonna bundle LLVM) side-to-side with Tensorflow also causes crashes?

See if the problem will be fixed with manylinux2010. If it uses a more modern libstdc++, the problem might be fixed there

It may indeed. Though I'm afraid that depends on the exact libstdc++ version Tensorflow builds against?

This problem really needs to be fixed. If we don't fix it, doing deep learning with arrow via TensorFlow or PyTorch will be severely hindered

I understand the sentiment, but it seems the only sane way to fix this on our side is to ask people to use conda packages, not wheels. If wheels are broken, just say it to users instead of piling up fragile workarounds in the Arrow codebase.
Actually, I would even go as far as asking distutils-sig if the non-conformant wheels can be removed from PyPI. PyPI has no policy for this currently, but it is an obvious detriment to the whole ecosystem that people are allowed to upload rogue wheels and other packages have to deal with the fallout.

By the way, it seems manylinux2010 is almost there now: https://github.com/pypa/manylinux/issues/179
(i.e. it's in pip master, but not any pip releases yet, AFAICT)

Thanks again for the further feedback! It seems to me changing the threadpool API is also suboptimal.
I'd suggest the following solution:

Keep the API as is, but instead of std::future expose arrow::Future
Introduce a flag that redirects the implementation of arrow::Future to either std::future or boost::future.

Then we can leave it to the user which option they prefer. One sane default might be that if boost is vendored (like in our wheels), boost::future will be used. This will fix the problem not only for Ray but also vanilla pyarrow wheels.
In the future (if manylinux2010 and/or TensorFlow and pytorch solve the issue), we can remove the flag and just default to std::future.

Actually, I would even go as far as asking distutils-sig if the non-conformant wheels can be removed from PyPI.

Somehow we need to create some catalyst to cause the TF and PyTorch developers to take more responsibility for the toolchain problem they have created; this might be one way. Either way we need to escalate the issue and make a lot more people aware of what is going on

Aside: pyarrow is being installed more frequently than PyTorch and about 1/4 as often as TF on PyPI.

I don't think it's worth investing any more effort in this until we open a dialogue about the toolchain issues with the relevant developer communitise

Thanks for all the views! I'll send a post to the TensorFlow and PyTorch lists and to make sure this issue is raised prominently. Hopefully the community can agree on a way forward that works for everyone. At least we should make sure that there will be compatibility with manylinux2010 in the future.
I'll also prepare a patch for Ray 0.6.1 to make sure this works in the short term for our users.

Relevant thread https://groups.google.com/a/tensorflow.org/forum/#!topic/developers/TMqRaT-H2bI.

@wesm thanks a lot for pushing to start a discussion and dialogue around these issues. PyTorch certainly isn't immutable and we dont expect to be treated that way.
I've responded on the email thread that @pcmoritz started to get the discussion going and try finding a solution.

It might mean that we have to create some kind of a pip wheel to hoist a modern C++ standard library into the environment (for PyTorch / TF to depend on) so they can avoid all this static linking insanity, similar to what's being done in conda now

Just FYI, PyTorch hasn't statically linked with the std C++ since Jan this year -- we've been trying our best to work with the necessary constraints we have (in terms of CUDA, C++11) and covering as old a linux distro we can possibly go to.

Closing this pending some guidance about how to proceed on creating compatible wheels


Does Azkaban support cron scheduling in the next release?

Does Azkaban support cron scheduling in the next release?

It's supported. see
https://github.com/azkaban/azkaban/wiki/New-Azkaban-Schedule-Introduction

When to release the new version?


Added a note about activation variables

Azure Batch Rendering uses Software Entitlement Service for Azure Batch that uses two special environment variables AZ_BATCH_ACCOUNT_URL and AZ_BATCH_SOFTWARE_ENTITLEMENT_TOKEN to check if application was started in Azure Batch managed environment. If they are modified, the user is likely to be hit by "Software is not activated"-like message.

@evgri243 : Thanks for your contribution! The author, @dlepow, has been notified to review your proposed change.

@evgri243 - Thanks for adding this note. I think it's a very useful hint to add to this article. Minor style suggestion: Can you please change "...any of application above" to "any of the applications above"? Then we can merge this in. Thank you!

@evgri243 - I have a doc work item in progress to update other content in this article, and will include your revision in that update. I expect that to publish in approximately 1 week. Accordingly, I am closing your PR.
#please-close


Disable Hikari Debug Logging.

I'm finding it increasingly frustrating for my log file to be filled with statements like:
[19:51:52] [Hikari housekeeper (pool HikariPool-0)/DEBUG] [com.zaxxer.hikari.pool.HikariPool]: Before cleanup	pool HikariPool-0 stats (total=25, active=0, idle=25, waiting=0) [19:51:52] [Hikari housekeeper (pool HikariPool-0)/DEBUG] [com.zaxxer.hikari.pool.HikariPool]: After cleanup	pool HikariPool-0 stats (total=25, active=0, idle=25, waiting=0) [19:51:53] [Hikari housekeeper (pool HikariPool-1)/DEBUG] [com.zaxxer.hikari.pool.HikariPool]: Before cleanup	pool HikariPool-1 stats (total=25, active=0, idle=25, waiting=0) [19:51:53] [Hikari housekeeper (pool HikariPool-1)/DEBUG] [com.zaxxer.hikari.pool.HikariPool]: After cleanup	pool HikariPool-1 stats (total=25, active=0, idle=25, waiting=0) [19:51:53] [Hikari housekeeper (pool HikariPool-2)/DEBUG] [com.zaxxer.hikari.pool.HikariPool]: Before cleanup	pool HikariPool-2 stats (total=25, active=0, idle=25, waiting=0) [19:51:53] [Hikari housekeeper (pool HikariPool-2)/DEBUG] [com.zaxxer.hikari.pool.HikariPool]: After cleanup	pool HikariPool-2 stats (total=25, active=0, idle=25, waiting=0) [19:51:53] [Hikari housekeeper (pool HikariPool-3)/DEBUG] [com.zaxxer.hikari.pool.HikariPool]: Before cleanup	pool HikariPool-3 stats (total=25, active=0, idle=25, waiting=0) [19:51:53] [Hikari housekeeper (pool HikariPool-3)/DEBUG] [com.zaxxer.hikari.pool.HikariPool]: After cleanup	pool HikariPool-3 stats (total=25, active=0, idle=25, waiting=0) [19:51:53] [Hikari housekeeper (pool HikariPool-4)/DEBUG] [com.zaxxer.hikari.pool.HikariPool]: Before cleanup	pool HikariPool-4 stats (total=25, active=0, idle=25, waiting=0) [19:51:53] [Hikari housekeeper (pool HikariPool-4)/DEBUG] [com.zaxxer.hikari.pool.HikariPool]: After cleanup	pool HikariPool-4 stats (total=25, active=0, idle=25, waiting=0) [19:51:53] [Hikari housekeeper (pool HikariPool-5)/DEBUG] [com.zaxxer.hikari.pool.HikariPool]: Before cleanup	pool HikariPool-5 stats (total=25, active=0, idle=25, waiting=0) [19:51:53] [Hikari housekeeper (pool HikariPool-5)/DEBUG] [com.zaxxer.hikari.pool.HikariPool]: After cleanup	pool HikariPool-5 stats (total=25, active=0, idle=25, waiting=0) [19:51:53] [Hikari housekeeper (pool HikariPool-6)/DEBUG] [com.zaxxer.hikari.pool.HikariPool]: Before cleanup	pool HikariPool-6 stats (total=25, active=0, idle=25, waiting=0) [19:51:53] [Hikari housekeeper (pool HikariPool-6)/DEBUG] [com.zaxxer.hikari.pool.HikariPool]: After cleanup	pool HikariPool-6 stats (total=25, active=0, idle=25, waiting=0) [19:51:55] [Hikari housekeeper (pool HikariPool-7)/DEBUG] [com.zaxxer.hikari.pool.HikariPool]: Before cleanup	pool HikariPool-7 stats (total=25, active=0, idle=25, waiting=0) [19:51:55] [Hikari housekeeper (pool HikariPool-7)/DEBUG] [com.zaxxer.hikari.pool.HikariPool]: After cleanup	pool HikariPool-7 stats (total=25, active=0, idle=25, waiting=0)
every few seconds.
It would be nice for there to be a config option to enable and disable it. (Ideally disabled by default)
I'm starting to get really sick and tired of seeing those statements. They also make log files unnecessarily huge.

IMO this can and should be configured using Log4J2.xml config. However I agree that it should be disabled by default or at least a sicriplet with the necessary changes in the config should be exposed somewhere.

We don't really have control about the log4j configuration from SpongeForge (only using a lot of hacks). The design of the logging framework Minecraft is using makes it difficult to change certain options like this at runtime (e.g. by a config option) so the recommended way (right now) to fix this issue is to take the Forge log4j2 config and customize it for your needs.

Would it be possible to import a log4j file externally in spongeforge?

You can use the log4j.configurationFile system property when starting the server, e.g. `-Dlog4j.configurationFile=mycustomconfig.xml’

I do this in my plugin to prevent hikari spam:
((Logger)LogManager.getLogger(HikariPool.class)).setLevel(Level.INFO);
((Logger)LogManager.getLogger(PoolElf.class)).setLevel(Level.INFO);
((Logger)LogManager.getLogger(HikariConfig.class)).setLevel(Level.INFO);

Not working for me. Compile Errors. Can you explain how you're using that?

You need to reference log4j2 classes there, not slf4j/jul.

@gravityfox Can you move this issue to SpongeForge? We will need some awesome log4j2 hacks here in order to fix this in SpongeForge, I'll need to take a look at that soon. Not an issue on SV anymore.

Hacks? I fixed this by literally adding a few lines the the xml file...
Also i'm not sure how to move issues...

Close issue
Open new issue

As for the fix: On SpongeForge the log4j configuration is controlled by Forge, it will be loaded before Sponge is actually loaded, we can't simply replace it somehow. We will need to ship a custom configuration and add ugly log4j hacks to make it reconfigure all loggers based on the configuration in our custom XML files.


limit number of accumulated factors in running product to at most T

Introduce register ramp and instructions set_ramp & get_ramp.
Explicitly treat clock jump differences of magnitude 1.
Also, make running evaluation reu absorb first (not last) cell of every contiguous region. I believe relying on the existence of the padding region, which is by no means guaranteed, can lead to hard-to-catch bugs, both in the code and in soundness of the presented argument.

Instruction get_ramp is not strictly needed for TIP 0003 but I believe it can be very useful for stack management. Happy to discuss.

Introduce register ramp and instructions set_ramp & get_ramp.

Before having read the changes in detail, I wonder if we need to add the two instructions. The alternative would be to update the ramp register in the background, whenever read_mem or write_mem are executed.

Makes perfect sense. Since neither read_mem nor write_mem changes the size of the stack, only one memory pointer is changed, namely, ramp. I seem to have gotten lost in the design possibilities and mixed things together.


issue : Report generation in future date

Expected behavior:
Reports can be generated from the past to current date.
Actual behavior:
Validation not done in report generation date field which allowing future date for report generation
Steps to reproduce:

under Report generation section, select the future date in the date field.

Screenshots (if applicable):
Attached. Please find the attachment.
OS and Browser:
N/A

Seems to be an easy fix, I'll take a look at it in a second.

Hi there! I’m a first-time contributor and was hoping to help out with this issue. I noticed nobody was assigned to it, but if there’s already a solution in progress I’m happy to try helping out elsewhere. Thanks!

@EvanSays sorry to steal your thunder EvanSays, I've already submitted a pull request that addresses this issue in the post above yours.
Please join the slack channel https://hospitalrun-slackin.herokuapp.com/ if you haven't already if you have any other  questions :)


Add custom routes for pub/sub

This PR allows users to specify custom routes for Pub/Sub topics.
Closes #1518
The PR does the following:

Changes the response expected from the app subscribe endpoint to the agreed definition
Refactors the subscription handling to different package
Updates tests for topics with the same route names and adds a test for a topic with different route name

And linter is not happy.

On a path to dynamic subscriptions

On a path to dynamic subscriptions I hope 😄

Indeed.

@amanbha I added a test that validates the correctness of subscription filtering.

Note this change breaks samples/docs/sdks/aspnet attributes

@yaron2 LGTM,  could you open issues in other repos for this "mother-of-breaking-changes" :)

@yaron2 LGTM, could you open issues in other repos for this "mother-of-breaking-changes" :)

I will, once we merge.

Now we'll wait for the scheduled e2e tests to run..


Filter chips from multi value array

Filter chips from multi value array in MUI datatables
Hello, World!
Expected Behavior
I would like to be able to display the filter chips for every value from filterList[index] if there are more than one.
Current Behavior
If there is just one value - I can use
customFilterListOptions: {
             render: (v) => `VAT: ${v}%`,

but if there are more than one  - the values are displayed all together in one chip.

OR if I map the values - in console.log I can see the good result, but there is no render for text in the chips:
 customFilterListOptions: {
          render: (value) =>
            value.map((v) => {
              console.log(v);
             `VAT: ${v}%`;

Steps to Reproduce (for bugs)

Your Environment

Tech
Version

Material-UI
0.20.2

MUI-datatables
3.7.1

React
16.13.1

browser
Chrome 88.0.4324.150 / Firefox 85.0.2

etc

sorry - just return was missing


fix: change count condition

Description
https://github.com/terraform-ibm-modules/terraform-ibm-icd-elasticsearch/issues/359
Release required?

[ ] No release
[ ] Patch release (x.x.X)
[ ] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content
Change count condition to no longer use resources that are only created after apply.
Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

For mergers

Use a conventional commit message to set the release level. Follow the guidelines.
Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
Use the Squash and merge option.

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

Reason for skipping upgrade tests:
TestRunStandardUpgradeSolution 2024-12-06T01:46:33Z logger.go:66: │ Error: Invalid count argument
TestRunStandardUpgradeSolution 2024-12-06T01:46:33Z logger.go:66: │
TestRunStandardUpgradeSolution 2024-12-06T01:46:33Z logger.go:66: │   on ../../main.tf line 89, in resource "ibm_iam_authorization_policy" "backup_kms_policy":
TestRunStandardUpgradeSolution 2024-12-06T01:46:33Z logger.go:66: │   89:   count                    = local.create_backup_kms_policy ? 1 : 0
TestRunStandardUpgradeSolution 2024-12-06T01:46:33Z logger.go:66: │
TestRunStandardUpgradeSolution 2024-12-06T01:46:33Z logger.go:66: │ The "count" value depends on resource attributes that cannot be determined
TestRunStandardUpgradeSolution 2024-12-06T01:46:33Z logger.go:66: │ until apply, so Terraform cannot predict how many instances will be
TestRunStandardUpgradeSolution 2024-12-06T01:46:33Z logger.go:66: │ created. To work around this, use the -target argument to first apply only
TestRunStandardUpgradeSolution 2024-12-06T01:46:33Z logger.go:66: │ the resources that the count depends on.
TestRunStandardUpgradeSolution 2024-12-06T01:46:33Z logger.go:66: ╵
TestRunStandardUpgradeSolution 2024-12-06T01:46:33Z retry.go:99: Returning due to fatal error: FatalError{Underlying: error while running command: exit status 1; ╷

/run pipeline

@arya-girish-k, refer this PR updates to for your issue in the PR- https://github.com/terraform-ibm-modules/terraform-ibm-icd-postgresql/pull/530

@Ak-sky This PR has nothing to do with scoping the KMS policy to the exact key. Its related to how we are handling the use case when users pass a different KMS key for backup encryption

@Ak-sky This PR has nothing to do with scoping the KMS policy to the exact key. Its related to how we are handling the use case when users pass a different KMS key for backup encryption

right @ocofaigh, but @arya-girish-k is refering the same changes from here in postgresql to create 2 auth-policies and running into the same issue Invalid count argument. So the same usecase would be need to be handled in https://github.com/terraform-ibm-modules/terraform-ibm-icd-postgresql/pull/530.

Superseeded by https://github.com/terraform-ibm-modules/terraform-ibm-icd-elasticsearch/pull/363


Run evaluation in parallel to training in ULTRA

Based off of #624.

Produces these errors at the end of the training session. This can be fixed by upgrading the grpcio==1.30.0 dependency of SMARTS to something like grpcio==1.36.1 (see this issue from the GRPC repository).

/usr/lib/python3.7/subprocess.py:883: ResourceWarning: subprocess 7946 is still running
  ResourceWarning, source=self)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Exception ignored in: <function _ChannelCallState.__del__ at 0x7f094c7bc5f0>
Traceback (most recent call last):
  File "/SMARTS/ultra/.venv/lib/python3.7/site-packages/grpc/_channel.py", line 1126, in __del__
AttributeError: 'NoneType' object has no attribute 'cancelled'
Exception ignored in: <function _ChannelCallState.__del__ at 0x7f094c7bc5f0>
Traceback (most recent call last):
  File "/SMARTS/ultra/.venv/lib/python3.7/site-packages/grpc/_channel.py", line 1126, in __del__
AttributeError: 'NoneType' object has no attribute 'cancelled'
Exception ignored in: <function _ChannelCallState.__del__ at 0x7f094c7bc5f0>
Traceback (most recent call last):
  File "/SMARTS/ultra/.venv/lib/python3.7/site-packages/grpc/_channel.py", line 1126, in __del__
AttributeError: 'NoneType' object has no attribute 'cancelled'
Exception ignored in: <function _ChannelCallState.__del__ at 0x7f094c7bc5f0>
Traceback (most recent call last):
  File "/SMARTS/ultra/.venv/lib/python3.7/site-packages/grpc/_channel.py", line 1126, in __del__
AttributeError: 'NoneType' object has no attribute 'cancelled'
Exception ignored in: <function _ChannelCallState.__del__ at 0x7f094c7bc5f0>
Traceback (most recent call last):
  File "/SMARTS/ultra/.venv/lib/python3.7/site-packages/grpc/_channel.py", line 1126, in __del__
AttributeError: 'NoneType' object has no attribute 'cancelled'
Exception ignored in: <function _ChannelCallState.__del__ at 0x7f094c7bc5f0>
Traceback (most recent call last):
  File "/SMARTS/ultra/.venv/lib/python3.7/site-packages/grpc/_channel.py", line 1126, in __del__
AttributeError: 'NoneType' object has no attribute 'cancelled'
Exception ignored in: <function _ChannelCallState.__del__ at 0x7f094c7bc5f0>
Traceback (most recent call last):
  File "/SMARTS/ultra/.venv/lib/python3.7/site-packages/grpc/_channel.py", line 1126, in __del__
AttributeError: 'NoneType' object has no attribute 'cancelled'

Will potentially record data out of order if the --eval-rate flag value is too low: https://github.com/huawei-noah/SMARTS/blob/a65215660f2b54d02d971dedf10ff56c7f3993cb/ultra/ultra/utils/episode.py#L253-L263
This should not be a problem if --eval-rate is kept reasonable, i.e. not evaluating every episode (--eval-rate > 1).

This might be reason enough to log information to some format other than tensorboard.

This might be reason enough to log information to some format other than tensorboard.

True @AlexLewandowski. I believe the all_data attribute of episodes should contain all the data that has been gathered during training and testing for each agent: https://github.com/huawei-noah/SMARTS/blob/6cb8ffda74e235c25d63b74313623b2e03e402f7/ultra/ultra/utils/episode.py#L131 https://github.com/huawei-noah/SMARTS/blob/6cb8ffda74e235c25d63b74313623b2e03e402f7/ultra/ultra/utils/episode.py#L257-L275 Maybe this could help? I will investigate as well.

Looks good, we should work on merging this with the changes in the ultra-eval-per-episode branch sometime tomorrow.

Definitely! Sounds good.

Whoops, I did this merge from the CLI which I did not know was possible. I think it's all set though, I was able to integrate the episode based evaluation and most of the generalization stuff. The one hiccup is gap_mode. I think this could be done by running the evaluation for eval_mode = True and eval_mode = False inside the for loop instead of two separate for loops. Then the task_ids can be bundled together, like:
 evaluation_task_ids[(evaluation_task_id,evaluation_train_task_id)] = ...

I don't know if that would pose a problem though

Oh okay no worries, we can maybe talk about it in today's meeting.