Scenario Test Runner not working with autoware

Describe the bug
Using pilot-auto, commit id: c92557c9698cd040da57b53c7cdde533128d9054 I'am unable to make autoware and scenario test runner works
To Reproduce
Steps to reproduce the behavior:

Clone https://github.com/tier4/pilot-auto
Build
run example by ros2 launch scenario_test_runner scenario_test_runner.launch.py scenario:='$(find-pkg-share scenario_test_runner)/scenario/sample.yaml' launch_rviz:=true record:=false vehicle_model:=lexus sensor_model:=aip_xx1
See an error

Expected behavior
Ego driving
Desktop:

OS: Ubuntu
Version 20.04
ROS2 Galactic
Cyclone DDS

Error log
Autoware is initialized but in  [simulation.concealer::waitForAutowareStateToBeWaitingForRoute] Simulator waiting for Autoware state to be WaitingForRoute (3). state. In this state, it hung till timeout causing exit.
NOTE:
Interesting logs
Info: [planning.mission_planning.mission_planner::publishRoute] Route successfully planned. Publishing...
Info: [planning.scenario_planning.lane_driving.behavior_planning.behavior_path_planner::waitForData] waiting for scenario topic
Error : [planning.scenario_planning.lane_driving.motion_planning.motion_planning_container::OnLoadNode] Failed to find class with the requested plugin name 'surround_obstacle_checker::SurroundObstacleCheckerNode' in the loaded library

Info:  [planning.scenario_planning.lane_driving.motion_planning.obstacle_avoidance_planner::waitForFirstPose] waiting for self pose...
Warning:  [planning.scenario_planning.lane_driving.motion_planning.obstacle_avoidance_planner::resetPlanning] [ObstacleAvoidancePlanner] Reset planning
Warning:  [planning.scenario_planning.lane_driving.motion_planning.obstacle_avoidance_planner::getLatestTransform] failed to get transform from map to base_link: "map" passed to lookupTransform argument target_frame does not exist.

Full log:
log.txt
I can also provide a rosbag if needed.
The initial pose seems to be set as you can see on the screen-shot

I wonder if there might be a problem with openscenario <-> t4s2.yaml since there is a log
[openscenario_interpreter_node-3] [path_distance_calculator_node-61] [WARN] [1652696567.467424226] [autoware_api.utils.path_distance_calculator]: no path

@adamkrawczyk
Will this behavior be reproduced no matter how many times I rerun the simulator?
In the sample scenario, Autoware's initial location is slightly randomized, which can cause Autoware to fail in route planning.

@yamacir-kit
Yes, this is no matter how many times I try, also extending initialization time does not work (tested 60s).
Also does not work with other scenarios I have been using before.

@adamkrawczyk
Looking at the logs you provided, it seems that rosbridge_server failed to start. Did you refresh your terminal after the build and then source install/setup.bash?

@yamacir-kit
Thank you!! It turned out that it was not installed - I have done rosdep step but supposedly rosbridge_server is not a part of any package.xml. I have also a problem building with quaternion_operation and added this to the package.
Anyway thank you for your super fast support. It is working now.
Should I rise an issue on for example autoware repo or will you manage this issue?

There it is. Sorry I have missed this.  In the future I will start by looking for PackageNotFoundError
[openscenario_interpreter_node-3] future: <Task finished name='Task-2' coro=<LaunchService._process_one_event() done, defined at /opt/ros/galactic/lib/python3.8/site-packages/launch/launch_service.py:226> ```
exception=PackageNotFoundError("package 'rosbridge_server' not found, searching: [blablabla]")>
[openscenario_interpreter_node-3] Traceback (most recent call last):
[openscenario_interpreter_node-3]   File "/opt/ros/galactic/lib/python3.8/site-packages/ament_index_python/packages.py", line 50, in get_package_prefix
[openscenario_interpreter_node-3]     content, package_prefix = get_resource('packages', package_name)
[openscenario_interpreter_node-3]   File "/opt/ros/galactic/lib/python3.8/site-packages/ament_index_python/resources.py", line 48, in get_resource
[openscenario_interpreter_node-3]     raise LookupError(
[openscenario_interpreter_node-3] LookupError: Could not find the resource 'rosbridge_server' of type 'packages'
[openscenario_interpreter_node-3] ```

@adamkrawczyk
https://github.com/tier4/pilot-auto/commit/95c47a2b59090e89fe4af0c0f3acd0e8e4168c88
Apparently, the previous commit of the pilot-auto version you used (currently tier4/universe HEAD) intentionally removed the dependency on rosbride.
I don't know why it was removed, but I recommend raising the issue in the pilot-auto repository as it would prevent pilot-auto from working with scenario_simulator_v2 without rosbridge_server.

Closed due to opening https://github.com/tier4/pilot-auto/issues/471


Back arrows for subviews of burger menu

See Dining>any Menu

Migrated to https://github.com/pennlabs/penn-mobile-ios/issues/97


upgraded gocloak to v13.9.0

As per the issue mentioned in Gocloak gocloak is broken for Keycloak v17.0 : need to remove /auth from the gocloak endpoint path, have updated Gocloak to its latest version (v13.9.0) to bring that fix in group-sync-operator.
Verified by creating GroupSync CR for Provider type keycloak
apiVersion: redhatcop.redhat.io/v1alpha1
kind: GroupSync
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"redhatcop.redhat.io/v1alpha1","kind":"GroupSync","metadata":{"annotations":{},"name":"keycloak-groupsync","namespace":"group-sync-operator"},"spec":{"providers":[{"keycloak":{"credentialsSecret":{"name":"keycloak-group-sync","namespace":"group-sync-operator"},"insecure":true,"loginRealm":"master","realm":"master","scope":"sub","url":"https://keycloak.lab.kubeapp.cloud"},"name":"keycloak"}]}}
  creationTimestamp: "2024-02-16T21:23:05Z"
  generation: 1
  name: keycloak-groupsync
  namespace: group-sync-operator
  resourceVersion: "9074428"
  uid: 7ae9fc86-f09c-46bd-8fe1-b7379fbe8480
spec:
  providers:
  - keycloak:
      credentialsSecret:
        kind: Secret
        name: keycloak-group-sync
        namespace: group-sync-operator
      insecure: true
      loginRealm: master
      realm: master
      scope: sub
      url: https://keycloak.lab.kubeapp.cloud
    name: keycloak
status:
  conditions:
  - lastTransitionTime: "2024-02-16T21:23:30Z"
    message: ""
    observedGeneration: 1
    reason: LastReconcileCycleSucceded
    status: "True"
    type: ReconcileSuccess
  lastSyncSuccessTime: "2024-02-16T21:23:30Z"

Observed logs:
1.708118585902769e+09	INFO	controllers.GroupSync	Beginning Sync	{"groupsync": "group-sync-operator/keycloak-groupsync", "Provider": "keycloak"}
1.7081185872111435e+09	INFO	syncer_keycloak	Successfully Authenticated with Keycloak Provider
1.7081186109454274e+09	INFO	controllers.GroupSync	Sync Completed Successfully	{"groupsync": "group-sync-operator/keycloak-groupsync", "Provider": "keycloak", "Groups Created or Updated": 9, "Groups Pruned": 0}

@tanalam2411 thanks for the contribution. Will look into review the PR soon.
In the meantime, the operator supports versions before and after v17.0. The Operator documentation for Keycloak highlights how to manage the configuration with both versions

@tanalam2411 thanks for the contribution. Will look into review the PR soon.
In the meantime, the operator supports versions before and after v17.0. The Operator documentation for Keycloak highlights how to manage the configuration with both versions

As per the README Older versions (<17.0.0) including Red Hat SSO should include the context path /auth appended to the hostname and for new version (>17.0.0) of Keycloak or RHSSO we don't need to append /auth to the hostname but the gocloak (version v11.2.0) is itself appending /auth internally which is causing this error  "Unable to find matching target resource method" as a responce from keycloak server.
And this has been fixed in current latest version of gocloak - https://github.com/Nerzal/gocloak/blob/v13.9.0/client.go#L183

@tanalam2411 I just testing the current released Group Sync Operator with the latest versions of Red Hat Single Sing On and upstream keycloak successfully
apiVersion: redhatcop.redhat.io/v1alpha1
kind: GroupSync
metadata:
  name: keycloak-groupsync
  namespace: group-sync-operator
spec:
  providers:
    - keycloak:
        credentialsSecret:
          kind: Secret
          name: keycloak-group-sync
          namespace: group-sync-operator
        prune: false
        realm: master
        scope: sub
        url: 'https://keycloak.<apps_domain>'
      name: keycloak
    - keycloak:
        credentialsSecret:
          kind: Secret
          name: rhsso-group-sync
          namespace: group-sync-operator
        loginRealm: master
        prune: false
        realm: master
        scope: sub
        url: 'https://keycloak-rhsso.<apps_domain>/auth'
      name: keycloak

@tanalam2411 I just testing the current released Group Sync Operator with the latest versions of Red Hat Single Sing On and upstream keycloak successfully
apiVersion: redhatcop.redhat.io/v1alpha1
kind: GroupSync
metadata:
  name: keycloak-groupsync
  namespace: group-sync-operator
spec:
  providers:
    - keycloak:
        credentialsSecret:
          kind: Secret
          name: keycloak-group-sync
          namespace: group-sync-operator
        prune: false
        realm: master
        scope: sub
        url: 'https://keycloak.<apps_domain>'
      name: keycloak
    - keycloak:
        credentialsSecret:
          kind: Secret
          name: rhsso-group-sync
          namespace: group-sync-operator
        loginRealm: master
        prune: false
        realm: master
        scope: sub
        url: 'https://keycloak-rhsso.<apps_domain>/auth'
      name: keycloak

Yes its working, tested on different cluster and it worked for upstream keycloak.
@sabre1041 should we keep this PR as its updating goloack's version and doesn't have any major impacting change.


[ODS-4237]  Ed-Fi-Alliance repo paths in nuspec files

Fixed Formatting issue . Ready for code review .


feat(sdf, dal, web): Add ability to understand who has taken what action in a changeset

We now show history actor details at an action and change level:

and we also work out the full list of actors involved in the Applied Changeset and list them alongside the person who merged the changeset

LGTM! Ship it!

bors merge


Fix Generate repo logged download logs instructions

When a repo is migrated the logs contain instructions how to download the logs, but the parameters names were incorrect.
Only gei  since download-logs parameters are not consistent between gei, bbs2gh´ and ado2gh(onlygei` is different than the other two)
closes #1179

[x] Did you write/update appropriate tests
[x] Release notes updated (if appropriate)
[x] Appropriate logging output
[x] Issue linked
[x] Docs updated (or issue created)
[x] New package licenses are added to ThirdPartyNotices.txt (if applicable)

Can you add this to RELEASENOTES.md too, actually? Maybe something like:

Fix suggested command for downloading logs in gh gei migrate-repo log output

Added in e64dd63a59395cd896d03beb6d3d608a9be1a1c1


Feature request: Show a warning if IPFS port is closed

I use ipfs-desktop <IP_ADDRESS> (and go-ipfs 0.4.21) on Windows 10.
IPFS ports are open on my Windows Firewall and my router by default. If I run IPFS normally I can connect to 250+ peers and my shared files can be accessed without too much extra delay.
I use a VPN service frequently. This service doesn't support port forwarding, so if I'm on VPN my ports appear to be closed. In this case I can connect to fewer peers (~40) and the access to my files are significantly slower.
I think it would be beneficial to have a small indication somewhere (maybe on the peers page) if the ports on the computer seem to be closed.
A brief explanation of the drawbacks of this would be motivating, and we could even offer some helpful links to configure the firewall and/or the router.

Thanks for the suggestion @andrasfuchs. I need to see if there's an easy way in Node.js to detect if ports are open on the firewall on all OSes. Do you happen to know if such tool exists?

I don't know Node.js that much, but I'll look into it. Since the checking must be initiated from outside the network of the node in question, it's very likely that we would need to use an external service to do the check. I suppose we would need both ipv4 and ipv6.
As a long term solution it would be great if any node could ask any other node to check its port, and report it back if it found it open or closed ;)

Yes, it should go into the implementation go-ipfs and js-ipfs. Perhaps you should open an issue there 😃

Just leaving a ref to #1001.

From @andrasfuchs on https://github.com/ipfs/go-ipfs/issues/6593

I see, alright, thank you @Stebalien for the explanation!
So, if we wanted to show a warning message to ipfs-desktop users when they are in passive mode (their port looks closed from the outside), we should:
1, check if AutoReplay is enabled in their config file (because it's needed for the port checking)
2, check if ipfs id returns any addresses with the "p2p-circuit" substring (because this means that our port looks closed)
Is my understanding correct?

@lidel @rafaelramalho19 This sounds like it could be a pretty valid unboarding unblocker - thinking specifically about new users who assume their relevant ports are open, but they're actually not. Is it worth prioritizing?

Hm.. dial check would improve onboarding of  new users, but we should avoid using centralized services for the check.
AFAIK go-ipfs ships with AutoNAT enabled to determine if node should be DHT server or only a DHT client:

an ambient NAT autodiscovery service. It allows peers to figure out their NAT dialability situation by using test dial backs through peers providing the AutoNAT service.

In simpler words, go-ipfs asks publicly dialable peers to check if it is publicly dialable too.
So in theory, decentralized solution is in place already, but it is internal to go-ipfs and ipfs-desktop can't leverage it to warn user they are not publicly dialabe, because AutoNAT service is not exposed via HTTP API.
@jacobheun  @aschmahmann are you familiar with AutoNAT implementation?
Got some questions, and would appreciate sanity check on the idea of using it in IPFS Desktop:

How reliable it is? Is AutoNAT test happening only once, periodically, or on listening address change?

Main use case here would be user moving their laptop between different networks: some having UPnP, some blocking IPFS.

thoughts on exposing the result of AutoNAT test via HTTP API somehow?

for MVP it does not need to be part of official /api/v0, it could be under /debug like http://<IP_ADDRESS>:5001/debug/metrics/prometheus


Minor CL4 bug: Userlists don't get updated when clients disconnect

^
Can be tested at wss://cl4-test.meower.org/

Fixed.


Bug/visible to images

there's something wrong with this

will close #80

It does but Django should treat visibleTo in the post data as a list
On Tue., Mar. 26, 2019, 8:56 p.m. Nicholas<EMAIL_ADDRESS>wrote:

@npwhite commented on this pull request.
In posts/static/makepost/posts.js
https://github.com/dispersal/CMPUT404-project-socialdistribution/pull/85#discussion_r269389683
:

     let csrf = document.getElementsByName('csrfmiddlewaretoken')[0].value;

   formData.append('title', 'Image"');

   formData.append('content', fileContent);

   formData.append('description', 'Image');

   formData.append('unlisted', 'true');

   formData.append('contentType', fileType);

   formData.append('visbility', visbility);

   formData.append('csrfmiddlewaretoken', csrf);

   let title = 'Image';

I thought the name would need a [] suffix in order to append to the same
name multiple times
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dispersal/CMPUT404-project-socialdistribution/pull/85#discussion_r269389683,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQgGQu9IjeDFEgdy5kxHR7eiTedLDKtwks5vat3ngaJpZM4cMt-C
.


error with python enviornment setup process

Trying to setup python environment with anaconda and following the instructions outlined on the repository:
Error 1: installing saber with "pip install ." inside the saber folder

Error 2: installing en_coref_md, tried running twice but the same errors come up

Weird, looks like issues are related to gcc. I suspect this is an issue with your Command Line Tools.
First, try this (as per this SO post):
# activate your environment
source activate saber
# install gcc compiler into this environment
conda install gcc
# reinstall saber
git clone https://github.com/BaderLab/saber.git
cd saber
pip install .
pip install git+https://www.github.com/keras-team/keras-contrib.git
pip install https://github.com/huggingface/neuralcoref-models/releases/download/en_coref_md-3.0.0/en_coref_md-3.0.0.tar.gz

If that doesn't work, try reinstalling the Xcode Command Line Tools. Here are some good instructions, but they require that you have brew installed (which is a good idea anyway). After updating the CLTs, re-install saber as per above.
Let me know if either solution fixes the problem!

Turns out I had to update my OS…I have everything working again


Mutable arrow function variable that returns void can be assigned different return types without erroring.

Bug Report

🔎 Search Terms
mutable function void
mutable arrow function void
arrow function void

🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about functions and function-related things in Type System Behavior.

⏯ Playground Link

Playground link with relevant code
💻 Code

let foo = () => {}

foo = () => [1]

console.log(foo().map(x => ++x))

🙁 Actual behavior

It did not error on line 2; and instead, it changed the variable. It errored on line 5 because the function "map" did not exist on type void.
🙂 Expected behavior

I expected it to error on line 2 because it was assigning a different return type to the arrow function.

https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-functions-returning-non-void-assignable-to-function-returning-void


Added support to flag components Red/Green when required properties a…

I think we can use some better UI elements to Flag Proper setup. @mgubaidullin  you can decide if the current Icons are good or not.

@mrinalsharma I disagree.

Small round elements on route diagram are buttons (grey to delete or blue to add smth)
If Element is properly configured it has normal dark grey color label
Additional round elements confuses.
If component/kamelet/dsl is not properly configured the label is red.
User should not be notified that everything is OK (green icon), It is enough to notify user that something is wrong.

Thanks for the update,  it seams you have already made changes.

Closing this pullrequest as Issue 494 is already resolved


chore: align structs to reduce space usage

Some of the structs were not aligned and therefore using some more bytes and also using more cachelines that were actually needed.
Closes #2457

/test

/test


easyeffects: 6.0.3 -> 6.1.2

Motivation for this change
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 139464 run on x86_64-linux 1

1 package built:

easyeffects

See also https://github.com/NixOS/nixpkgs/pull/136477, the comments need to be updated as per the changes.


Hm207v2 add create and edit to its own route

Overview
moves create and edit into its own routes
Includes:
please see files changed for changes
Developer Checklist:

[x] The code follows the Quality Policy file on Google Drive
[] My code has been developer-tested and includes unit tests
[x] I have considered proper use of exceptions
[x] I have eliminated IDE warnings

Notes:

Needs a better progress bar

Refs:

US 207

Right now, in addition to what Trent has mentioned, this is kind of a confusing UI. For example when creating a new model:

It shows the "Save" and "Close" at the top right under the "Home" and "About" menus. Also the bottom of the screen is cut off. If it is meant to feel like a new window that is coming up, then it should likely not include the top bar, rather the top bar should be replaced by a back arrow to the top left and the "Home" and "About" should probably be gone. Also the "Save" and "Close" might be better served at the bottom in this case so as to not confuse the user, because the "Home" and "About" used to be there a second ago.

Right now, in addition to what Trent has mentioned, this is kind of a confusing UI. For example when creating a new model:

It shows the "Save" and "Close" at the top right under the "Home" and "About" menus. Also the bottom of the screen is cut off. If it is meant to feel like a new window that is coming up, then it should likely not include the top bar, rather the top bar should be replaced by a back arrow to the top left and the "Home" and "About" should probably be gone. Also the "Save" and "Close" might be better served at the bottom in this case so as to not confuse the user, because the "Home" and "About" used to be there a second ago.

I think we have a tendency to just dump all the logic into this one view when the couldbase would be cleaner if we split some things up. It would be great if there were separate views for Edit / Create so we could abstract the route & store related logic into those and keep the forms independent of all of that stuff. Would separate concerns a little bit & make things easier to test down the road.
The basic idea:
* Make the current Create.vue a FormsComposite.vue and put it in components.

* Create two new files Create.vue & Edit.vue in views and use them as simple wrappers for FormsComposite.vue.

* Pass initial state (either from INITIAL_STATE or $store) to FormsComposite via props & initialize data there from that.

* Pass model state up from FormsComposite to Create and Edit via v-model (whenever something changes).

* Keep buttons & their corresponding handlers in the wrappers so they can have unique functions for updating vs creating and maybe unique labels, too (create in Create & Save or Update in Edit).

Is that something that makes sense to the rest of you?

The differences in create and edit functions can be in done in store, otherwise: prepopulating user created data = prepopulating default data. I dont see why we need an extra wrapper.

I think we have a tendency to just dump all the logic into this one view when the couldbase would be cleaner if we split some things up. It would be great if there were separate views for Edit / Create so we could abstract the route & store related logic into those and keep the forms independent of all of that stuff. Would separate concerns a little bit & make things easier to test down the road.
The basic idea:
* Make the current Create.vue a FormsComposite.vue and put it in components.

* Create two new files Create.vue & Edit.vue in views and use them as simple wrappers for FormsComposite.vue.

* Pass initial state (either from INITIAL_STATE or $store) to FormsComposite via props & initialize data there from that.

* Pass model state up from FormsComposite to Create and Edit via v-model (whenever something changes).

* Keep buttons & their corresponding handlers in the wrappers so they can have unique functions for updating vs creating and maybe unique labels, too (create in Create & Save or Update in Edit).

Is that something that makes sense to the rest of you?

The differences in create and edit functions can be in done in store, otherwise: prepopulating user created data = prepopulating default data. I dont see why we need an extra wrapper.

Right now, in addition to what Trent has mentioned, this is kind of a confusing UI. For example when creating a new model:

It shows the "Save" and "Close" at the top right under the "Home" and "About" menus. Also the bottom of the screen is cut off. If it is meant to feel like a new window that is coming up, then it should likely not include the top bar, rather the top bar should be replaced by a back arrow to the top left and the "Home" and "About" should probably be gone. Also the "Save" and "Close" might be better served at the bottom in this case so as to not confuse the user, because the "Home" and "About" used to be there a second ago.

fixed the bottom styling. I cannot find a better compoent than md-app-toolbar for md-app right now. We can fix the styling later in another location. Maybe change the stuff on the navbar?

Right now, in addition to what Trent has mentioned, this is kind of a confusing UI. For example when creating a new model:

It shows the "Save" and "Close" at the top right under the "Home" and "About" menus. Also the bottom of the screen is cut off. If it is meant to feel like a new window that is coming up, then it should likely not include the top bar, rather the top bar should be replaced by a back arrow to the top left and the "Home" and "About" should probably be gone. Also the "Save" and "Close" might be better served at the bottom in this case so as to not confuse the user, because the "Home" and "About" used to be there a second ago.

fixed the bottom styling. I cannot find a better compoent than md-app-toolbar for md-app right now. We can fix the styling later in another location. Maybe change the stuff on the navbar?

Right now, in addition to what Trent has mentioned, this is kind of a confusing UI. For example when creating a new model:

It shows the "Save" and "Close" at the top right under the "Home" and "About" menus. Also the bottom of the screen is cut off. If it is meant to feel like a new window that is coming up, then it should likely not include the top bar, rather the top bar should be replaced by a back arrow to the top left and the "Home" and "About" should probably be gone. Also the "Save" and "Close" might be better served at the bottom in this case so as to not confuse the user, because the "Home" and "About" used to be there a second ago.

fixed the bottom styling. I cannot find a better compoent than md-app-toolbar for md-app right now. We can fix the styling later in another location. Maybe change the stuff on the navbar?

Floating buttons that are semi-transparent normally & solid on hover would work well I think. On the styling front I think we'd also benefit from some more whitespace on the left and right of the forms themselves. Don't think they need to take the entire screen, ya?

Right now, in addition to what Trent has mentioned, this is kind of a confusing UI. For example when creating a new model:

It shows the "Save" and "Close" at the top right under the "Home" and "About" menus. Also the bottom of the screen is cut off. If it is meant to feel like a new window that is coming up, then it should likely not include the top bar, rather the top bar should be replaced by a back arrow to the top left and the "Home" and "About" should probably be gone. Also the "Save" and "Close" might be better served at the bottom in this case so as to not confuse the user, because the "Home" and "About" used to be there a second ago.

fixed the bottom styling. I cannot find a better compoent than md-app-toolbar for md-app right now. We can fix the styling later in another location. Maybe change the stuff on the navbar?

Floating buttons that are semi-transparent normally & solid on hover would work well I think. On the styling front I think we'd also benefit from some more whitespace on the left and right of the forms themselves. Don't think they need to take the entire screen, ya?

Right now, in addition to what Trent has mentioned, this is kind of a confusing UI. For example when creating a new model:

It shows the "Save" and "Close" at the top right under the "Home" and "About" menus. Also the bottom of the screen is cut off. If it is meant to feel like a new window that is coming up, then it should likely not include the top bar, rather the top bar should be replaced by a back arrow to the top left and the "Home" and "About" should probably be gone. Also the "Save" and "Close" might be better served at the bottom in this case so as to not confuse the user, because the "Home" and "About" used to be there a second ago.

fixed the bottom styling. I cannot find a better compoent than md-app-toolbar for md-app right now. We can fix the styling later in another location. Maybe change the stuff on the navbar?

Floating buttons that are semi-transparent normally & solid on hover would work well I think. On the styling front I think we'd also benefit from some more whitespace on the left and right of the forms themselves. Don't think they need to take the entire screen, ya?

Yeah I agree with all that. We can definately use better styling. Let's do that on a different US.  It can still be in a modal (which supports routing) too if Steven insists on it (which would make sense to keep the toolbar).
I don't think making it look good is within the scope of this US though. Let's get the routing to work and we can work on a better style in a separate US.

Right now, in addition to what Trent has mentioned, this is kind of a confusing UI. For example when creating a new model:

It shows the "Save" and "Close" at the top right under the "Home" and "About" menus. Also the bottom of the screen is cut off. If it is meant to feel like a new window that is coming up, then it should likely not include the top bar, rather the top bar should be replaced by a back arrow to the top left and the "Home" and "About" should probably be gone. Also the "Save" and "Close" might be better served at the bottom in this case so as to not confuse the user, because the "Home" and "About" used to be there a second ago.

fixed the bottom styling. I cannot find a better compoent than md-app-toolbar for md-app right now. We can fix the styling later in another location. Maybe change the stuff on the navbar?

Floating buttons that are semi-transparent normally & solid on hover would work well I think. On the styling front I think we'd also benefit from some more whitespace on the left and right of the forms themselves. Don't think they need to take the entire screen, ya?

Yeah I agree with all that. We can definately use better styling. Let's do that on a different US.  It can still be in a modal (which supports routing) too if Steven insists on it (which would make sense to keep the toolbar).
I don't think making it look good is within the scope of this US though. Let's get the routing to work and we can work on a better style in a separate US.

I think we have a tendency to just dump all the logic into this one view when the couldbase would be cleaner if we split some things up. It would be great if there were separate views for Edit / Create so we could abstract the route & store related logic into those and keep the forms independent of all of that stuff. Would separate concerns a little bit & make things easier to test down the road.
The basic idea:
* Make the current Create.vue a FormsComposite.vue and put it in components.

* Create two new files Create.vue & Edit.vue in views and use them as simple wrappers for FormsComposite.vue.

* Pass initial state (either from INITIAL_STATE or $store) to FormsComposite via props & initialize data there from that.

* Pass model state up from FormsComposite to Create and Edit via v-model (whenever something changes).

* Keep buttons & their corresponding handlers in the wrappers so they can have unique functions for updating vs creating and maybe unique labels, too (create in Create & Save or Update in Edit).

Is that something that makes sense to the rest of you?

The differences in create and edit functions can be in done in store, otherwise: prepopulating user created data = prepopulating default data. I dont see why we need an extra wrapper.

Because it separates form logic from routing / store interaction logic, which makes both ends easier to test & lets us customize the behavior of certain routes more easily. Generally nice to have core side effects separate from presentational stuff. I'm up for making this change if you just don't want to do the legwork haha

I think we have a tendency to just dump all the logic into this one view when the couldbase would be cleaner if we split some things up. It would be great if there were separate views for Edit / Create so we could abstract the route & store related logic into those and keep the forms independent of all of that stuff. Would separate concerns a little bit & make things easier to test down the road.
The basic idea:
* Make the current Create.vue a FormsComposite.vue and put it in components.

* Create two new files Create.vue & Edit.vue in views and use them as simple wrappers for FormsComposite.vue.

* Pass initial state (either from INITIAL_STATE or $store) to FormsComposite via props & initialize data there from that.

* Pass model state up from FormsComposite to Create and Edit via v-model (whenever something changes).

* Keep buttons & their corresponding handlers in the wrappers so they can have unique functions for updating vs creating and maybe unique labels, too (create in Create & Save or Update in Edit).

Is that something that makes sense to the rest of you?

The differences in create and edit functions can be in done in store, otherwise: prepopulating user created data = prepopulating default data. I dont see why we need an extra wrapper.

Because it separates form logic from routing / store interaction logic, which makes both ends easier to test & lets us customize the behavior of certain routes more easily. Generally nice to have core side effects separate from presentational stuff. I'm up for making this change if you just don't want to do the legwork haha

Right now, in addition to what Trent has mentioned, this is kind of a confusing UI. For example when creating a new model:

It shows the "Save" and "Close" at the top right under the "Home" and "About" menus. Also the bottom of the screen is cut off. If it is meant to feel like a new window that is coming up, then it should likely not include the top bar, rather the top bar should be replaced by a back arrow to the top left and the "Home" and "About" should probably be gone. Also the "Save" and "Close" might be better served at the bottom in this case so as to not confuse the user, because the "Home" and "About" used to be there a second ago.

fixed the bottom styling. I cannot find a better compoent than md-app-toolbar for md-app right now. We can fix the styling later in another location. Maybe change the stuff on the navbar?

Floating buttons that are semi-transparent normally & solid on hover would work well I think. On the styling front I think we'd also benefit from some more whitespace on the left and right of the forms themselves. Don't think they need to take the entire screen, ya?

Yeah I agree with all that. We can definately use better styling. Let's do that on a different US. It can still be in a modal (which supports routing) too if Steven insists on it (which would make sense to keep the toolbar).
I don't think making it look good is within the scope of this US though. Let's get the routing to work and we can work on a better style in a separate US.

Just concerned that if we present it as is to Steven it will feel like a regression to him. Some route switches are slow and rerender the whole page for me (Home -> Create) and in general it looks worse than the last thing we demoed to him. Would rather spend a little time making everything nice so we can actually sell it to him as an alternative to the 'single page' he was asking for.
I think the style changes you made did something to Home btw.

Right now, in addition to what Trent has mentioned, this is kind of a confusing UI. For example when creating a new model:

It shows the "Save" and "Close" at the top right under the "Home" and "About" menus. Also the bottom of the screen is cut off. If it is meant to feel like a new window that is coming up, then it should likely not include the top bar, rather the top bar should be replaced by a back arrow to the top left and the "Home" and "About" should probably be gone. Also the "Save" and "Close" might be better served at the bottom in this case so as to not confuse the user, because the "Home" and "About" used to be there a second ago.

fixed the bottom styling. I cannot find a better compoent than md-app-toolbar for md-app right now. We can fix the styling later in another location. Maybe change the stuff on the navbar?

Floating buttons that are semi-transparent normally & solid on hover would work well I think. On the styling front I think we'd also benefit from some more whitespace on the left and right of the forms themselves. Don't think they need to take the entire screen, ya?

Yeah I agree with all that. We can definately use better styling. Let's do that on a different US. It can still be in a modal (which supports routing) too if Steven insists on it (which would make sense to keep the toolbar).
I don't think making it look good is within the scope of this US though. Let's get the routing to work and we can work on a better style in a separate US.

Just concerned that if we present it as is to Steven it will feel like a regression to him. Some route switches are slow and rerender the whole page for me (Home -> Create) and in general it looks worse than the last thing we demoed to him. Would rather spend a little time making everything nice so we can actually sell it to him as an alternative to the 'single page' he was asking for.
I think the style changes you made did something to Home btw.

Right now, in addition to what Trent has mentioned, this is kind of a confusing UI. For example when creating a new model:

It shows the "Save" and "Close" at the top right under the "Home" and "About" menus. Also the bottom of the screen is cut off. If it is meant to feel like a new window that is coming up, then it should likely not include the top bar, rather the top bar should be replaced by a back arrow to the top left and the "Home" and "About" should probably be gone. Also the "Save" and "Close" might be better served at the bottom in this case so as to not confuse the user, because the "Home" and "About" used to be there a second ago.

fixed the bottom styling. I cannot find a better compoent than md-app-toolbar for md-app right now. We can fix the styling later in another location. Maybe change the stuff on the navbar?

Floating buttons that are semi-transparent normally & solid on hover would work well I think. On the styling front I think we'd also benefit from some more whitespace on the left and right of the forms themselves. Don't think they need to take the entire screen, ya?

Yeah I agree with all that. We can definately use better styling. Let's do that on a different US. It can still be in a modal (which supports routing) too if Steven insists on it (which would make sense to keep the toolbar).
I don't think making it look good is within the scope of this US though. Let's get the routing to work and we can work on a better style in a separate US.

Just concerned that if we present it as is to Steven it will feel like a regression to him. Some route switches are slow and rerender the whole page for me (Home -> Create) and in general it looks worse than the last thing we demoed to him. Would rather spend a little time making everything nice so we can actually sell it to him as an alternative to the 'single page' he was asking for.
I think the style changes you made did something to Home btw.

fixed home.
as for Steven's concern, we'll get something better afterwards. There are huge changes needed for create/ anyway. All the forms needs to be refactored and modified to support user generated values.

Right now, in addition to what Trent has mentioned, this is kind of a confusing UI. For example when creating a new model:

It shows the "Save" and "Close" at the top right under the "Home" and "About" menus. Also the bottom of the screen is cut off. If it is meant to feel like a new window that is coming up, then it should likely not include the top bar, rather the top bar should be replaced by a back arrow to the top left and the "Home" and "About" should probably be gone. Also the "Save" and "Close" might be better served at the bottom in this case so as to not confuse the user, because the "Home" and "About" used to be there a second ago.

fixed the bottom styling. I cannot find a better compoent than md-app-toolbar for md-app right now. We can fix the styling later in another location. Maybe change the stuff on the navbar?

Floating buttons that are semi-transparent normally & solid on hover would work well I think. On the styling front I think we'd also benefit from some more whitespace on the left and right of the forms themselves. Don't think they need to take the entire screen, ya?

Yeah I agree with all that. We can definately use better styling. Let's do that on a different US. It can still be in a modal (which supports routing) too if Steven insists on it (which would make sense to keep the toolbar).
I don't think making it look good is within the scope of this US though. Let's get the routing to work and we can work on a better style in a separate US.

Just concerned that if we present it as is to Steven it will feel like a regression to him. Some route switches are slow and rerender the whole page for me (Home -> Create) and in general it looks worse than the last thing we demoed to him. Would rather spend a little time making everything nice so we can actually sell it to him as an alternative to the 'single page' he was asking for.
I think the style changes you made did something to Home btw.

fixed home.
as for Steven's concern, we'll get something better afterwards. There are huge changes needed for create/ anyway. All the forms needs to be refactored and modified to support user generated values.

@aschnapp in the description for this PR, what does "Needs a better progress ba" mean?

@aschnapp in the description for this PR, what does "Needs a better progress ba" mean?

Also, the design seems to be getting further off:

The font for the "New Model" part looks to be different than everything else on the page and the spacing is different than the top bar. Also the white space around "Model Metadata" in the left menu is different than every other menu item.

Also, the design seems to be getting further off:

The font for the "New Model" part looks to be different than everything else on the page and the spacing is different than the top bar. Also the white space around "Model Metadata" in the left menu is different than every other menu item.

One more thing: Spacing at the top, under the main menu bar on the home screen looked better before than it does in this branch. Dev spacing currently:

The spacing in this branch at the moment:

One more thing: Spacing at the top, under the main menu bar on the home screen looked better before than it does in this branch. Dev spacing currently:

The spacing in this branch at the moment:

@Tengelma @aneuhold /home is left as is right now, except navbar is now edited on a per component basis (you can have custom buttons)
I wanted to keep the nav in its own component, but seems like it isn't possible with md-app... @Tengelma if you have any ideas on how you keep nav inside navbar, lmk.
all styling issues have been fixed. /home is as it currently is.

@Tengelma @aneuhold /home is left as is right now, except navbar is now edited on a per component basis (you can have custom buttons)
I wanted to keep the nav in its own component, but seems like it isn't possible with md-app... @Tengelma if you have any ideas on how you keep nav inside navbar, lmk.
all styling issues have been fixed. /home is as it currently is.

@aschnapp the UI looks quite a bit better now.
Just still having a hard time seeing why we need routes in this situation. It seems to be quite slow at the moment, and we still don't have a lot of other functionality included yet, which means it might get slower. Testing routes sounds more complicated than testing components. It could be easier, but it definitely makes the code harder to read and understand. So what are the upsides to routes again? Other people on the team can approve this PR without this question being answered. But until I have a better understanding of the benefits, I don't feel comfortable approving.

@aschnapp the UI looks quite a bit better now.
Just still having a hard time seeing why we need routes in this situation. It seems to be quite slow at the moment, and we still don't have a lot of other functionality included yet, which means it might get slower. Testing routes sounds more complicated than testing components. It could be easier, but it definitely makes the code harder to read and understand. So what are the upsides to routes again? Other people on the team can approve this PR without this question being answered. But until I have a better understanding of the benefits, I don't feel comfortable approving.

@aschnapp the UI looks quite a bit better now.
Just still having a hard time seeing why we need routes in this situation. It seems to be quite slow at the moment, and we still don't have a lot of other functionality included yet, which means it might get slower. Testing routes sounds more complicated than testing components. It could be easier, but it definitely makes the code harder to read and understand. So what are the upsides to routes again? Other people on the team can approve this PR without this question being answered of course. But until I have a better understanding of the benefits, I don't feel comfortable approving.

@aneuhold  try to navigate to localhost:8080/create and see what happens in dev branch

@aschnapp the UI looks quite a bit better now.
Just still having a hard time seeing why we need routes in this situation. It seems to be quite slow at the moment, and we still don't have a lot of other functionality included yet, which means it might get slower. Testing routes sounds more complicated than testing components. It could be easier, but it definitely makes the code harder to read and understand. So what are the upsides to routes again? Other people on the team can approve this PR without this question being answered of course. But until I have a better understanding of the benefits, I don't feel comfortable approving.

@aneuhold  try to navigate to localhost:8080/create and see what happens in dev branch

I'm on board with routes but I don't think this is ready for dev:

Auto plot updates on Plot Type change is broken.
Navbars are meant to be navbars. Save/Cancel != Navigation
Scroll tracking (and menu snapping) isn't working again because intersection line has changed
Transition to/from Create is super slow when it should be very very fast (like switching between Home & About).
Transition to/from Create causes entire page to rerender instead of preserving navbar between routes.
Style still has a lot of room for improvement

Let's just slow down a bit & make it into something that can be stable, functional & look better than the current format. This is going to take some time to get right & there's no reason to rush it through when routes are just dynamic components and this isn't really blocking anything or affecting future development.

I'm on board with routes but I don't think this is ready for dev:

Auto plot updates on Plot Type change is broken.
Navbars are meant to be navbars. Save/Cancel != Navigation
Scroll tracking (and menu snapping) isn't working again because intersection line has changed
Transition to/from Create is super slow when it should be very very fast (like switching between Home & About).
Transition to/from Create causes entire page to rerender instead of preserving navbar between routes.
Style still has a lot of room for improvement

Let's just slow down a bit & make it into something that can be stable, functional & look better than the current format. This is going to take some time to get right & there's no reason to rush it through when routes are just dynamic components and this isn't really blocking anything or affecting future development.

@aschnapp the UI looks quite a bit better now.
Just still having a hard time seeing why we need routes in this situation. It seems to be quite slow at the moment, and we still don't have a lot of other functionality included yet, which means it might get slower. Testing routes sounds more complicated than testing components. It could be easier, but it definitely makes the code harder to read and understand. So what are the upsides to routes again? Other people on the team can approve this PR without this question being answered of course. But until I have a better understanding of the benefits, I don't feel comfortable approving.

@aneuhold try to navigate to localhost:8080/create and see what happens in dev branch
the /create#hash goes nowhere, and if you take "create" out the #hash will still go nowhere. Now when you refresh the page it goes back to where you are.
I dont notice any difference in speed on my machine though. It's probably just the animation in the dev branch making it feel like it's faster.

The question was more about why we need routes at all, not the difference between this implementation of routes and the one on dev.

@aschnapp the UI looks quite a bit better now.
Just still having a hard time seeing why we need routes in this situation. It seems to be quite slow at the moment, and we still don't have a lot of other functionality included yet, which means it might get slower. Testing routes sounds more complicated than testing components. It could be easier, but it definitely makes the code harder to read and understand. So what are the upsides to routes again? Other people on the team can approve this PR without this question being answered of course. But until I have a better understanding of the benefits, I don't feel comfortable approving.

@aneuhold try to navigate to localhost:8080/create and see what happens in dev branch
the /create#hash goes nowhere, and if you take "create" out the #hash will still go nowhere. Now when you refresh the page it goes back to where you are.
I dont notice any difference in speed on my machine though. It's probably just the animation in the dev branch making it feel like it's faster.

The question was more about why we need routes at all, not the difference between this implementation of routes and the one on dev.

@aschnapp the UI looks quite a bit better now.
Just still having a hard time seeing why we need routes in this situation. It seems to be quite slow at the moment, and we still don't have a lot of other functionality included yet, which means it might get slower. Testing routes sounds more complicated than testing components. It could be easier, but it definitely makes the code harder to read and understand. So what are the upsides to routes again? Other people on the team can approve this PR without this question being answered of course. But until I have a better understanding of the benefits, I don't feel comfortable approving.

@aneuhold try to navigate to localhost:8080/create and see what happens in dev branch
the /create#hash goes nowhere, and if you take "create" out the #hash will still go nowhere. Now when you refresh the page it goes back to where you are.
I dont notice any difference in speed on my machine though. It's probably just the animation in the dev branch making it feel like it's faster.

The question was more about why we need routes at all (for model manipulation and viewing, not the about page. That makes sense as a route), not the difference between this implementation of routes and the one on dev.

I think what @aschnapp was getting at is that some pretty standard behavior (like being able to refresh while the modal is open) just breaks things instead of taking you to where you left off. We could opt out of changing the visible route in the browser at all when we open / navigate the modal but, generally, that's pretty standard and meaningful feedback for the user (and the devs) to confirm that the correct things are happening as they progress through the site. There's other little things, too, like not being able to scroll through the modal with pageup/pagedown or arrow keys.
It's also feedback that 'should' come at no cost. Like right now, if you transition between Home & About the route switch is instantaneous and you're where you want to be without any visual sign that stuff had to load. That's something we should be able to achieve with routes and something I'm sure we can figure out with a little more time.
More generally, though, this is a massive modal & it contains a lot of interactivity (basically 90% of the functionality of the front end) when it's generally supposed to be a very critical / quick / lightweight piece of information that interrupts whatever you're doing to inform you of something important or get confirmation of something. As an example, lets say the user spent a bunch of time filling out a form and accidentally clicks cancel. With routes we can just have a modal that pops up if changes were made asking users to confirm that they want to discard them. With a modal, what do we do? Snackbars don't block page interaction so people could still interact with the form with them up. We can't really have a modal in a modal either because that doesn't even make sense. There's no clean or idiomatic solution to the problem.

@aschnapp the UI looks quite a bit better now.
Just still having a hard time seeing why we need routes in this situation. It seems to be quite slow at the moment, and we still don't have a lot of other functionality included yet, which means it might get slower. Testing routes sounds more complicated than testing components. It could be easier, but it definitely makes the code harder to read and understand. So what are the upsides to routes again? Other people on the team can approve this PR without this question being answered of course. But until I have a better understanding of the benefits, I don't feel comfortable approving.

@aneuhold try to navigate to localhost:8080/create and see what happens in dev branch
the /create#hash goes nowhere, and if you take "create" out the #hash will still go nowhere. Now when you refresh the page it goes back to where you are.
I dont notice any difference in speed on my machine though. It's probably just the animation in the dev branch making it feel like it's faster.

The question was more about why we need routes at all (for model manipulation and viewing, not the about page. That makes sense as a route), not the difference between this implementation of routes and the one on dev.

I think what @aschnapp was getting at is that some pretty standard behavior (like being able to refresh while the modal is open) just breaks things instead of taking you to where you left off. We could opt out of changing the visible route in the browser at all when we open / navigate the modal but, generally, that's pretty standard and meaningful feedback for the user (and the devs) to confirm that the correct things are happening as they progress through the site. There's other little things, too, like not being able to scroll through the modal with pageup/pagedown or arrow keys.
It's also feedback that 'should' come at no cost. Like right now, if you transition between Home & About the route switch is instantaneous and you're where you want to be without any visual sign that stuff had to load. That's something we should be able to achieve with routes and something I'm sure we can figure out with a little more time.
More generally, though, this is a massive modal & it contains a lot of interactivity (basically 90% of the functionality of the front end) when it's generally supposed to be a very critical / quick / lightweight piece of information that interrupts whatever you're doing to inform you of something important or get confirmation of something. As an example, lets say the user spent a bunch of time filling out a form and accidentally clicks cancel. With routes we can just have a modal that pops up if changes were made asking users to confirm that they want to discard them. With a modal, what do we do? Snackbars don't block page interaction so people could still interact with the form with them up. We can't really have a modal in a modal either because that doesn't even make sense. There's no clean or idiomatic solution to the problem.

@Tengelma ah okay. That makes more sense. The modal within modal confirmation dialog justifies it personally. And when a new page is used for the form entry, then the routes seem like a great next step to give some logical feedback to the user where they are.
UI should definitely be worked on to get there, but the concept as a whole makes more sense now. Thanks for that.

@Tengelma ah okay. That makes more sense. The modal within modal confirmation dialog justifies it personally. And when a new page is used for the form entry, then the routes seem like a great next step to give some logical feedback to the user where they are.
UI should definitely be worked on to get there, but the concept as a whole makes more sense now. Thanks for that.

Closing this in favor of #58


[doc] Documentation for touch-mode option added

/cc @DevExpress/testcafe-docs
this PR waits for https://github.com/DevExpress/testcafe/pull/1052

See https://github.com/DevExpress/testcafe/issues/984#issuecomment-267297010


captions for image_preview?

Is there a way to specify a caption for image_preview (for © purposes)?

I would assume a copyright notice on the full article page satisfies that purpose. The thumbnails on the homepage may appear too small on some devices to include copyright text as well, especially if we decide to change the thumbnail size in the future.

@kortschak Two other options are to use embedded metadata or to watermark the copyright statement onto the image.

Yeah. Either of those are probably OK. Thanks.


Fixed bug on patch, change token to key as 'key' is referenced in main

old patch run was throwing document does not exist because of duplicated /api//api/ in the URL
https://github.com/duckduckgrayduck/documentcloud-ocrspace-addon/actions/runs/4431432379/jobs/7774386270

Fixes #1


(gobby) Fix updater for gobby

Description
This pull request updates the updater to make use of the new script to grab the latest release.
Additonally, I have also changed to include the actual release notes in the package.
Motivation and Context
To have the updater fixed.
How Has this Been Tested?

Run .\update_all.ps1 gobby -ForcedPackages gobby

Screenshot (if appropriate, usually isn't needed):
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Migrated package (a package has been migrated from another repository)

Checklist:

[x] My code follows the code style of this repository.
[ ] My change requires a change to documentation (this usually means the notes in the description of a package).
[ ] I have updated the documentation accordingly (this usually means the notes in the description of a package).
[ ] I have updated the package description and it is less than 4000 characters.
[x] All files are up to date with the latest Contributing Guidelines
[ ] The added/modified package passed install/uninstall in the chocolatey test environment.
[x] The changes only affect a single package (not including meta package).

:white_check_mark: Package verification completed without issues. PR is now pending human review


Nestjs v9.1.1

Hello,
just upgraded to nestjs v9.1.1, and I'm getting this error:
[Nest] 670118  - 09/20/2022, 11:38:27 AM   ERROR [ExceptionHandler] Nest can't resolve dependencies of the SwaggerProtectHost (HttpAdapterHost, ?, SWAGGER_GUARD). Please make sure that the argument SWAGGER_PROTECT_OPTIONS at index [1] is available in the SwaggerProtectHost context.

Potential solutions:
- If SWAGGER_PROTECT_OPTIONS is a provider, is it part of the current SwaggerProtectHost?
- If SWAGGER_PROTECT_OPTIONS is exported from a separate @Module, is that module imported within SwaggerProtectHost?
  @Module({
    imports: [ /* the Module containing SWAGGER_PROTECT_OPTIONS */ ]
  })

I'm using fastify and latest swagger protect.
Any ideas?
NOTE: I've boiled it down to the fact that it happens when I use forRootAsync instead of forRoot when instantiating SwaggerProtect module

@femike After some debugging. I can confirm that this bug related to forRootAsync is caused by the SWAGGER_PROTECT_OPTIONS missing from providers.
https://github.com/femike/swagger-protect/blob/39884c84201ed93429ff47aa97d279375debb5ae/dist/host-async.module.js#L48-L55
Currently providers initialized with the HttpAdapterHost.
https://github.com/femike/swagger-protect/blob/39884c84201ed93429ff47aa97d279375debb5ae/dist/host-async.module.js#L15
Depending on use of useFactory it gets the SWAGGER_GUARD and SWAGGER_LOGIN added to it.
https://github.com/femike/swagger-protect/blob/39884c84201ed93429ff47aa97d279375debb5ae/dist/host-async.module.js#L18-L31
Replacing [core_1.HttpAdapterHost] with [$options], which contains the SWAGGER_PROTECT_OPTIONS from createAsyncOptionsProvider, solves this issue.
https://github.com/femike/swagger-protect/blob/39884c84201ed93429ff47aa97d279375debb5ae/dist/host-async.module.js#L11-L70

@xtrinch Could you update the title? because it's not really a Nest v9.1.1 issue.
forRootAsync providers should have the same providers as forRoot


⚠ Bofrost.lu has degraded performance

In 69408c3, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 2619 ms

Resolved: Bofrost.lu performance has improved in 27861a9 after 6 minutes.


feat(kit): TUI_AVATAR_OPTIONS default options configuration for Avatar

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows Conventional Commits
[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Refactoring
[ ] Code style update
[ ] Build or CI related changes
[ ] Documentation content changes

What is the current behavior?
Partially implements https://github.com/Tinkoff/taiga-ui/issues/133
What is the new behavior?
Default avatar options can be set via a provider. This is a partial implementation of https://github.com/Tinkoff/taiga-ui/issues/133
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Hello, please, rebase with main branch before


tf.data.experimental.snapshot() hangs when using GCS paths

Please make sure that this is a bug. As per our
GitHub Policy,
we only address code/doc bugs, performance issues, feature requests and
build/installation issues on GitHub. tag:bug_template
System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Debian 9.12 stretch
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:
TensorFlow installed from (source or binary): binary
TensorFlow version (use command below): 2.3
Python version: 3.5.7
Bazel version (if compiling from source): NA
GCC/Compiler version (if compiling from source): NA
CUDA/cuDNN version: CUDA 10.1
GPU model and memory: Nvidia Tesla T4

You can collect some of this information using our environment capture
script
You can also obtain the TensorFlow version with:

TF 1.0: python -c "import tensorflow as tf; print(tf.GIT_VERSION, tf.VERSION)"
TF 2.0: python -c "import tensorflow as tf; print(tf.version.GIT_VERSION, tf.version.VERSION)"

Describe the current behavior
tf.data.experimental.snapshot() hangs when using a Google Storage path.
Describe the expected behavior
tf.data.experimental.snapshot() works.
Standalone code to reproduce the issue
Provide a reproducible test case that is the bare minimum necessary to generate
the problem. If possible, please share a link to Colab/Jupyter/any notebook.
import tensorflow as tf
for _ in tf.data.Dataset.range(10).apply(tf.data.experimental.snapshot('gs://my-bucket/my-path')): break

hangs. Using a local path
for _ in tf.data.Dataset.range(10).apply(tf.data.experimental.snapshot('gs://my-bucket/deleteme')): break

works as expected.
Other info / logs Include any logs or source code that would be helpful to
diagnose the problem. If including tracebacks, please include the full
traceback. Large logs and files should be attached.

ping @piwell @carlthome

Confirming that I was able to repro this in Colab and with a GCP deep learning vm instance. Although it was hanging, the files actually did get written to the bucket. Did you see the same?

Thanks for reporting this issue! I've investigated and the underlying cause is gcs_file_system.cc not handling NewAppendableFile() correctly when the file does not yet exist.
The deadlock happens due to the following sequence of events:
The error is propagated all the way back to AsyncWriter::WriterThread, which then returns with the error code.
However, by this time, the entire writing process has finished and the main iterator thread calls SignalEOF from GetNextInternal. SignalEOF acquires the WriterThread's mu_ lock and then tries to clear() writers_ vector, containing all the AsyncWriters.
To clear the vector, C++ needs to call AsyncWriter's default destructor, which then blocks on the thread_ within AsyncWriter finishing.
Now, the AsyncWriter thread is still trying to call the done() function that was passed in, which tries to acquire the same mu_ lock that SignalEOF was already holding.
This results in a deadlock where the main thread calling writers_.clear() cannot proceed because the AsyncWriter thread has not terminated, but the AsyncWriter thread is blocked trying to acquire the mu_ lock held by the main thread.
Will fix the underlying problem and the deadlock in an upcoming commit.


[Feature Request]: Searching multiple chromadb together

Describe the problem
I produce some data every day and store them in a new chromadb, persisting them on the disk.  I want to directly query the data from the past 30 days instead of merging them and then querying.
Describe the proposed solution
I'm sorry, I'm not sure exactly how to implement it.
Alternatives considered
No response
Importance
would make my life easier
Additional Information
No response

Can you talk a little bit more about your use case? Can you not just add to the existing db, instead of creating a new one every 30 days?

The data volume is quite large, and storing 30 days of data in a ChromaDB for searching is causing memory issues.


[question] less tab?

On oadp/bookbag/deploy-template.yaml line 61, should it be? (one less tab in name)
    metadata:
      labels:
        app: ${NAME}
      name: ${NAME}

There both are labels.


INFRA: Initialize Acceptance Test Project

Closes Task #39590603 - INFRA: Initialize Acceptance Test Project

@AndrewMcClelland to add additional initialization folders/files to acceptance test project

@AndrewMcClelland please address conflicts

@AndrewMcClelland please address conflicts

Looking


[github] Goodbye dependabot, you served us well

Coverage remained the same at 93.333% when pulling 466c10ab44e34e1417695c8c06eadc3c8a5a868a on hazendaz:master into 680de07cfd15b282d38247b49cc6ecc41769c329 on mybatis:master.


Templating Dream = we want jinja2 with a django, smarty style, with handlers

For all u template designer out there......
What we all want as template designers....
is we gone through all the templaiting "techniques"

eg
smarty devs
django devs
jinga1devs, and jango2
pinocide oand this and that

We Need to clean up templates..
BIGTIME..
If we can help by making it simple to read a previous template but no same template is another platform..
Come on all u smarty, jinga2, django, et all template users ..
chime in..

{% extend "SomeLAYOUT" %}
{% set page = "hello" %}
Thankx, here is replay vid below

:+1:
Pongo2 -> https://github.com/flosch/pongo2
I'm looking Pongo2, very interesting for those from the Python world
We can add a feature in the next roadmap to add Pongo2?
Cool !!!
:100:

Yes please..
Am migrating jinga2 n smarty

@jniltinho already in the current target version pluggable template engine

Closing this as duplicate of #99 and #123

@brendensoares  I’m sorry.
Thanks,
New features in 0.13, please do not remove HTTPS, I'm using in my project

Can we keep this open,, for feedback please..

Wheres the pongo version ??
Can we have a

revel/thirdparty
and a a sub modules ??
eg pongo ? gorm, gorp ?

@pedromorgan no, they have their own repos. I don't see a need to keep their code in our own mirrored repo, do you?
Also, I put this in the backlog, but it may not get much attention if it's there and not in the roadmap.

@brendensoares , @pedromorgan It is on the road map "Pluggable template engine"

@notzippy indeed it is :confounded:


Fix api route

As title.

Codecov Report

Merging #7346 into master will decrease coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #7346      +/-   ##
==========================================
- Coverage   41.25%   41.25%   -0.01%
==========================================
  Files         467      467
  Lines       63291    63291
==========================================
- Hits        26112    26108       -4
- Misses      33762    33767       +5
+ Partials     3417     3416       -1

Impacted Files
Coverage Δ

routers/api/v1/api.go
71.36% <100%> (ø)
:arrow_up:

models/unit.go
62.16% <0%> (-5.41%)
:arrow_down:

modules/log/event.go
64.61% <0%> (-1.03%)
:arrow_down:

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 68ec7b8...06f696b. Read the comment docs.

Please send backport

i don't know why, but since merging this drone build seems broken

@Cherrg fail is due to an upstream dependency not related to this PR

ok, only looked what was merged before it was broken :)
unfortunately i cant reproduce this on my local machine to track down the error


chore: update validation type to match model

Issue #, if available:
Description of changes:
Update form validation types
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Codecov Report

Merging #545 (69f437a) into tagged-release/forms-and-views (6dafab1) will increase coverage by 0.64%.
The diff coverage is 71.42%.

@@                        Coverage Diff                         @@
##           tagged-release/forms-and-views     #545      +/-   ##
==================================================================
+ Coverage                           89.02%   89.66%   +0.64%
==================================================================
  Files                                  74       74
  Lines                                2796     2805       +9
  Branches                              777      779       +2
==================================================================
+ Hits                                 2489     2515      +26
+ Misses                                294      277      -17
  Partials                               13       13

Impacted Files
Coverage Δ

...ges/codegen-ui-react/lib/utils/forms/validation.ts
97.64% <ø> (+1.44%)
:arrow_up:

...kages/codegen-ui/lib/types/form/form-validation.ts
100.00% <ø> (+100.00%)
:arrow_up:

...es/codegen-ui/lib/utils/form-component-metadata.ts
16.66% <ø> (ø)

.../codegen-ui-react/lib/forms/react-form-renderer.ts
74.52% <50.00%> (-0.48%)
:arrow_down:

...codegen-ui-react/lib/forms/form-renderer-helper.ts
100.00% <100.00%> (ø)

packages/codegen-ui/lib/types/form/index.ts
100.00% <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 6dafab1...69f437a. Read the comment docs.


alpine-consul-nginx does not build

 ---> Running in 00612f21dd21
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/community/x86_64/APKINDEX.tar.gz
fetch http://dl-4.alpinelinux.org/alpine/v3.2/main/x86_64/APKINDEX.tar.gz
ERROR: unsatisfiable constraints:
  nginx-1.10.1-r1:
    breaks: world[nginx=1.8.1-r0]

Problem seems to be with mixture of 3.4 and 3.2. The old repository should be dropped and main should be used instead I think.
A side note and a question: Nginx has stream_module that needs to be built-in for it to be supported. Reason why this matters is if you use Nginx for routing (i.e. database TCP connection from dc1 to dc2). I have custom image where I use Nginx from aports to build it in. Would there be interest to change alpine-nginx and alpine-consul-nginx to this custom build to support Nginx stream?

I've just resolved this. I kept it as v1.8.1 but I'll start releasing some upgrades to catch up to the most current Nginx version.
Could you tell me port about this aports thingo, and how it would impact this image? I did stumble across the stream_module the other day and it piqued my interest so I'm keen to here your thoughts on this.

Well nothing special in it. I create a user to build nginx under as abuild
does not allow build as root, then I clone aports, modify the makefile so
that includes the stream module in and then I simply execute abuild which
creates packages installable with apk and then do cleanup. It behaves
exactly like a build from repo. I'll send the dockerfile over tomorrow.
On Jul 21, 2016 7:24 PM, "Scott Mebberson"<EMAIL_ADDRESS>wrote:

I've just resolved this. I kept it as v1.8.1 but I'll start releasing some
upgrades to catch up to the most current Nginx version.
Could you tell me port about this aports thingo, and how it would impact
this image? I did stumble across the stream_module the other day and it
piqued my interest so I'm keen to here your thoughts on this.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/smebberson/docker-alpine/issues/57#issuecomment-234438392,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA_GtSPLJ7gDW55Njgwy3q9ZnY9Q6V66ks5qYCncgaJpZM4JMqH1
.

 So with that this custom building of stream is no longer necessary. In Alpine Linux edge we already have the stream module available, check it out https://pkgs.alpinelinux.org/package/edge/main/x86_64/nginx and package nginx-mod-stream.
Closing this ticket as the original issue was resolved.


switch to latest avd for instrumentation test

Looks like google has some bug with the latest avd.

Reported https://issuetracker.google.com/issues/76200998.


Revert "fix: prevent open context menu on money request"

Reverts Expensify/App#48375 as it causes failures https://github.com/Expensify/App/issues/49640 and https://github.com/Expensify/App/issues/49639
EDIT: actually, this isn't the case. https://expensify.slack.com/archives/C01GTK53T8Q/p1727174165508219?thread_ts=1727173924.473629&cid=C01GTK53T8Q
Closing the PR.

A


Disable camera movement when clicking a marker

Hello, currently when I click on a marker, the camera is automatically animated to go to that marker.
I wanna disable that the camera moves automatically and move it myself since I wanna add an offset to the movement.
Is this possible?
Thanks.

https://github.com/mapsplugin/cordova-plugin-googlemaps-doc/blob/master/v2.3.0/class/Marker/README.md#disable-auto-pan


Wrap everything in a closure

The 'u2f' in window check was returning true because the var u2f was being hoisted. This PR addresses this by wrapping everything in a closure and explicitly setting window.u2f.
/cc @dgraham @josh

Looks good.


Don't check the API for non configured instances

I've been seeing alot of calls to "/v1/pack/Default" through the API and ask to see if you would be so kind as to not make an API call unless the user has set it up.
I'm not sure where users are getting non configured versions of the mods from, but a simple setting in the config for enabling the checker which is false by default or even having the pack name to check be blank by default and don't check for updates when it's a blank string.
This would be very much appreciated.
Thanks

Patch has been created for this. Modpacks with the default config should no longer call the API.

Cheers. Was just seeing invalid api calls every 3 seconds nearly from this
:/


Tag/Release v2.18.2

According to GitHub this repo is still at version 2.17.1, but the latest published ruby gem is 2.18.2.

Since v2.18.2 has been published it probably makes sense to also designate this commit as a release.

Tagged master as v2.18.2 and published as latest release


Linking issue: undefined reference to symbol 'omp_get_max_threads@@OMP_1.0'

Hi there,
ipopt: 0.5.4
ipopt-sys: 0.5.5

Judging by the compiler output, its installing ipopt from source. ipopt and ipopt-sys compiled fine, but there was an issue with the linking step for my executable:
  = note: /usr/bin/ld: /my_lib/target/release/deps/libipopt_sys-cfc42e238256c47f.rlib(daxpy.o): undefined reference to symbol 'omp_get_max_threads@@OMP_1.0'
          /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/libgomp.so: error adding symbols: DSO missing from command line
          collect2: error: ld returned 1 exit status

  = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

error: could not compile `my_lib` (lib test) due to previous error

I tried adding:
println!("cargo:rustc-link-lib=gomp");
println!("cargo:rustc-link-lib=omp");

to build.rs but it didn't help (same error)
Any ideas? Thanks!

Ok I solved by adding println!("cargo:rustc-link-arg=-fopenmp"); to build.rs

Thanks for the issue, and the solution! Which platform did you compile on?

Hi it was Ubuntu 20.04.5 LTS
Note I had to add the command to the build.rs of the final crate, it was not enough to add it to the internal dependency where I wrote my optimization code ..


Lesson Builder Tool Issue

Hi All,
with this connector we have an issue,
When we create multiple lessons in a site using lesson builder tool,  we are unable to get the multiple lessons content in the portlet.
Steps To Reproduce Issue:
1.Login into sakai
2.Choose a site
3.Go to site info and choose mange tools
4.Check the Lessons checkbox and click on continue
5.Give a title like, Week-1 and click on continue and finish.
6.From Tools List Select Week-1 and add some content(ex: Week-1 Content) by clicking on Add Content later Add Text.
7.Now again go to site info - manage tools - Check Lessons check box - continue
8.Give a title like Week-2 and click on continue and finish
9.From Tools List Select Week-2 and add some content(ex: Week-2 Content) by clicking on Add Content later Add Text.
Now from the sakai connector portlet try to access this site week-1 and week-2 lessons.
Thanks,
Thirumal

Hi, I don't think the portlet supports multiple placements of a tool within a single Sakai site.

Hi @steveswinsburg ,
Thanks for your reply.
Any one is working on it to fix this issue? and are we going to get it in near future.?
If yes, let me know.
If not, do we need to start customizing this portlet.?
Thanks,
Thirumal.

I don't know of anyone working on it so feel free to submit a PR. cheers.


Adding YOLOS to HuggingFace Transformers

Hi YOLOS team :)
I've implemented YOLOS as a fork of 🤗 HuggingFace Transformers, and I'm going to add it soon to the library (see https://github.com/huggingface/transformers/pull/16848). Here's a notebook that illustrates inference with it: https://colab.research.google.com/drive/18ti9HrRoVE6d0vGBtnaeq93Tau3EYqOK?usp=sharing
The reason I'm adding YOLOS is because I really like the simplicity of it, compared to very complex frameworks such as Faster R-CNN and Mask R-CNN. I've added DETR previously also because it simplifies the task of object detection a lot.
As you may or may not know, any model on the HuggingFace hub has its own Github repository. E.g. the YOLOS-small checkpoint can be found here: https://huggingface.co/nielsr/yolos-s. If you check the "files and versions" tab, it includes the weights. The model hub uses git-LFS (large file storage) to use Git with large files such as model weights. This means that any model has its own Git commit history!
A model card can also be added to the repo, which is just a README.
Are you interested in creating an organization on the hub, such that we can store all model checkpoints there (rather than under my user name)?
Let me know!
Kind regards,
Niels
ML Engineer @ HuggingFace

Hi @NielsRogge, thanks for your and your team's interest in our work!
We are very glad to create an organization on the hub.

huggingface/transformers#16848

Hey Niels,
Thank you so much for implementing YOLOS in HuggingFace Transformer.
I am the university professor/supervisor of github/hustvl. As you can see, in our group, we have many many awesome transformer-based computer vision methods, such as YOLOS, MIMDet, TeViT, and TopFormer. Besides, we have other SoTA vision methods, such as QueryInst, ByteTrack, SparseInst, and FairMOT.
We would like to create an organization on HuggingFace. The name of the organization could be "hustvl". Definitely, HuggingFace and hustvl will have a win-win cooperation.
Thanks a lot!
Xinggang

Awesome :) feel free to create an organization on hf.co. I can then put all YOLOS checkpoints there, such that people will be able to do (for instance):
from transformers import YolosForObjectDetection

model = YolosForObjectDetection.from_pretrained("hustvl/yolos-s")

It seems that you have many exciting models! We can definitely add more in the future.

Awesome :) feel free to create an organization on hf.co. I can then put all YOLOS checkpoints there, such that people will be able to do (for instance):
from transformers import YolosForObjectDetection

model = YolosForObjectDetection.from_pretrained("hustvl/yolos-s")

It seems that you have many exciting models! We can definitely add more in the future.

@NielsRogge Done. The org URL is https://huggingface.co/hustvl. Thanks a lot.

🥳  YOLOS is now available in HuggingFace Transformers: https://huggingface.co/docs/transformers/main/en/model_doc/yolos
All checkpoints can be found on the hub: https://huggingface.co/models?other=yolos. They come with inference widgets, meaning you can directly try out all YOLOS checkpoints in the browser on images that you upload (or click one of the "examples")

🥳 YOLOS is now available in HuggingFace Transformers: https://huggingface.co/docs/transformers/main/en/model_doc/yolos
All checkpoints can be found on the hub: https://huggingface.co/models?other=yolos. They come with inference widgets, meaning you can directly try out all YOLOS checkpoints in the browser on images that you upload (or click one of the "examples")

thank you for your great efforts! @NielsRogge


Night CI 2023-12-12: Failed

action url: https://github.com/spidernet-io/egressgateway/actions/runs/7175598245

for test, close


Save As option needed

Since each script file has it's own GUID in it, there should be an option to Save As that changes the GUID after saving the script as a new script. Kind of a pain to duplicate scripts at the moment.

@EmilySamantha80 sorry for the late reply. I assume, you're manually copy/pasting the script file right now? If you duplicate a script through NetPad (by right clicking a script tab and selecting Duplicate) and then save it, it should work just fine. But yes a Save As is needed and will get it added.

Thanks for the reply! Just wanted to also say I love this app.


getPerformanceTiming logic

Please can you explain the logic of getPerformanceTiming logic which you have mentioned in the example below:-
.
Function NextRow() As Range
Static i As Integer
i = IIf(i = 0, 1, i + 1)    'Increments the row index
Set NextRow = Range("A:I").Rows(i)  'Returns the next row
End Function
Public Sub GetPerformanceTiming()
Dim driver As New SeleniumWrapper.WebDriver
driver.Start "firefox", "http://uk.news.yahoo.com"  'Starts firefox
'Writes the titles on the first row
NextRow() = Array("Page Url", "Page load", "Redirect", "DNS", "Connecting", "Waiting", "Receiving", "DOM", "Events")

'Opens each page and copies the metrics in the WorkSheet ( 1 row for each page opened)
driver.Open "tech"
  NextRow() = driver.getPerformanceTiming()
driver.Open "world"
  NextRow() = driver.getPerformanceTiming()
driver.Open "opinion"
  NextRow() = driver.getPerformanceTiming()
driver.Open "business"
  NextRow() = driver.getPerformanceTiming()

driver.stop 'Closes Firefox

End Sub

The "getPerformanceTiming" method was not ported to this project. It was using the Javascript "performance.timing" API to create the metrics:
https://developer.mozilla.org/en/docs/Web/API/Navigation_timing_API
http://www.html5rocks.com/en/tutorials/webperformance/basics
http://www.w3.org/TR/navigation-timing
You can still craft your own one with a Javascript call:
Const script = "var t=performance.timing;return [t.responseEnd-t.navigationStart,t.loadEventEnd-t.responseEnd];"

Dim driver As New FirefoxDriver
driver.Get "https://en.wikipedia.org/wiki/Main_Page"
times = driver.ExecuteScript(script).Values

Hi Florentbr,
I have prepared a macro to pull the performance of my project page.
its working fine but with Errors.
Also its generating a lot of Log & Junk files in my system.
Is it due to i'm making Variable i as Static?
Here is the error:-

Allthough when i click on "Debug" and again Run the script it works fine.
But it storing a lot of Junk files. Can you say what may be the possible reason?
its slowing down my system.
May be because i'm making variable i as Static? i'm not sure.?
Any method to release the memory space which the variable is reserving?
How can we implement this?
Here is my Complete code which i'm using. Any improvement suggested will be very much Welcome.
Private Sub CommandButton21_Click()
Dim driver As New SeleniumWrapper.WebDriver
Set pdf = CreateObject("SeleniumWrapper.PdfFile")
Dim By As New By, Assert As New Assert, Verify As New Verify, Waiter As New Waiter
Dim path, url
Dim wndhand
Dim perf
Dim m As Integer, n As Integer
'Writes the titles on the first row
' NextRow() = Array("Page Url", "Page load", "Redirect", "DNS", "Connecting", "Waiting", "Receiving", "DOM", "Events")
Worksheets("Input").Activate
Sheets("Input").Select
path = Range("B3").Value
url = Range("B2").Value
browser = Range("B4").Value
MsgBox path
MsgBox url
MsgBox browser
Shell (path + "\PRM Login1.exe")
Set selenium = CreateObject("SeleniumWrapper.WebDriver")
Set pdf = CreateObject("SeleniumWrapper.PdfFile")
'pdf.addImage selenium.getScreenshot()
driver.Start browser, url
driver.setImplicitWait 5000
driver.maximizeWindow
driver.get "/"
pdf.addImage selenium.getScreenshot()
'driver.setImplicitWait 5000
'  NextRow() = driver.getPerformanceTiming()
driver.setImplicitWait 50000
pdf.addImage selenium.getScreenshot()
windowhandle
'wndhand = driver.getAllWindowTitles
'MsgBox wndhand(0)
'MsgBox wndhand(1)
'driver.Focus (wndhand(1))
'driver.switchToWindow (1)
'driver.switchToDefaultContent
driver.setImplicitWait 50000
driver.findElementById("butBegin").Click
' pdf.addImage selenium.getScreenshot()
driver.switchToWindow (0)
driver.setImplicitWait 5000
pdf.addImage selenium.getScreenshot()
' Worksheets("Page Performance").Activate
'Sheets("Page Performance").Select
' Sheets("Page Performance").Activate
'Sheets("Sheet2").Activate
' For m = 1 To 9
' For n = 1 To 9
'driver.setImplicitWait 5000
NextRow() = driver.getPerformanceTiming
' driver.setImplicitWait 5000
' perf(10, 10) = driver.getPerformanceTiming
' Next n
' Next m
' MsgBox perf(1, 1)
'MsgBox perf(1, 2)
' MsgBox perf(1, 3)
' MsgBox perf(1, 4)
'NextRow() = perf
' NextRow() = driver.getPerformanceTiming()
'MsgBox NextRow(0)
'Writes the titles on the first row
'NextRow() = Array("Page Url", "Page load", "Redirect", "DNS", "Connecting", "Waiting", "Receiving", "DOM", "Events")
'driver.setImplicitWait 5000
driver.waitForAlertNotPresent
' ERROR: Caught exception [ERROR: Unsupported command [waitForPopUp | _self | 30000]]
'driver.findElementByCssSelector("nobr.ms-crm-NavBar-Area-Title").Click
'driver.findElementByCssSelector("#nav_accts > nobr.ms-crm-NavBar-Subarea-Title").Click
pdf.SaveAs "C:\Users\407484\Desktop\Performance Tool\Screenshots\sscapture.pdf"
driver.stop
End Sub
Function NextRow() As Range
Static i As Integer
'i = 1
' MsgBox i
' Worksheets("Sheet2").Activate
'Sheets("Sheet2").Activate
'Sheets("Page Performance").Activate
Worksheets("Page Performance").Activate
If i = 0 Then
i = 2
Else
i = i + 1
End If
'i = IIf(i = 0, 1, i + 1)    'Increments the row index
 MsgBox i
Set NextRow = Worksheets("Page Performance").Range("A:I").Rows(i)  'Returns the next row
'Range("K(i)").Value = Now
Worksheets("Page Performance").Cells(i, "K").Value = Now
'NextRow.Cells(i, "K").Value = Now

Worksheets("Page Performance").Rows(i).Select
' Exit Function
'MsgBox NextRow(0)

End Function
Function windowhandle() As Windows
Dim driver As New SeleniumWrapper.WebDriver
Dim By As New By, Assert As New Assert, Verify As New Verify, Waiter As New Waiter
Dim wndhand, cnt
wndhand = driver.getAllWindowTitles
'pdf.addImage selenium.getScreenshot()
'MsgBox wndhand(0)
'MsgBox wndhand(1)
'driver.Focus (wndhand(1))
driver.switchToWindow (1)
End Function
Thanks in Advance

Your exemple is from the SeleniumWrapper project which is no longer supported.
You should consider switching to SeleniumBasic:
https://github.com/florentbr/SeleniumBasic/releases

ok. Thanks,
i have downloaded the Selenium Basics and working on that. I am facing a lot of issues:-

How to Maximize & Minimize the window?
2.How i will implement getperformanceTiming() logic here, do we have any function like this here or API?
3.Putting Screenshots in a .pdf file

Thanks in advance.

How to Maximize & Minimize the window?

To maximize a window:
driver.Window.Maximize

Minimizing the window is not supported by Selenium. If your purpose is to hide it, then you can position it off-screen:
driver.Window.SetPosition -2000, 0

2.How i will implement getperformanceTiming() logic here, do we have any function like this here or API?

This was already answered in comment 2.

3.Putting Screenshots in a .pdf file

https://github.com/florentbr/SeleniumBasic/blob/master/Examples/VBScript/CaptureToPdf(Firefox).vbs


Use zsh as the default command prompt on Mac

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version:
OS Version:

Steps to Reproduce:

Update Mac book Pro to MacOS Monterey version 12.1.
Open Visual Studio Code and start writing PHP. Errors will show everywhere but the code still run and works.
Open terminal.
Open terminal settings.
Click Generally.
Click Open command interpreters.
Click command (full path) and write in /bin/zsh and close settings.
Relaunch VS Code.
Error still there.

/needsMoreInfo
Could you please specify how errors that coming from PHP Intelephense are related to setting up default terminal in OS? And how both of the, are related to VS Code editor itself?
For errors that are provided by extension please see extension docs for proper configuration or raise issue in extension's repo.
For configuring VS Code integrated terminal to use different profile - check docs on this topic https://code.visualstudio.com/docs/editor/integrated-terminal#_terminal-profiles

I cant add more information to this issue for i dont know what to write about it. But I try to find the php executable to fix the issue. See image to understand my problem.

This is a better image showing the settings.

The information I can give is that I have my php with Mamp and now I have installed zsh to read the shell.

the source of the error is the PHP Language Features Extension. Please create an issue in that repo.


mpv not recognized

Hello,
I can not get command prompt or powershell to recognize mpv. When typing in
"C:\Users\me>mpv --version"
This is what happens.
"
C:\Users\me>"
I just get a blank and new command line. The exe file is in the bin folder with the other exe files that work.
Any help is appreciated.

Sorry that this happened to you. The mpv.exe executable also requires that the mpv.com file be in the same directory to work. Just make sure both are in your bin directory.

That worked!! Thank you so much!


Document app favoriting from dashboard

This PR adds documentation for app favoriting from dashboard on Streamlit Cloud.

Merging as this feature was released last week for GA on 6/1/21.


Modification in implementation

This PR will solve the following:

#126

Only 8 digit phone numbers will be accepted.

#123

A contact will only be considered as a duplicate if they have the same 8 digit number.
This exploits the fact that phone numbers are unique.

LGTM 😃


Add styling for cursor on search suggestions

Prior to this commit, search suggestions triggered the text cursor. This
commit adds the cursor property to search suggestions, so as to trigger
the hand/pointer cursor when hovering over a search suggestion.

Found the site via HN and noticed the above tiny issue, thought it might be too small to make a PR for but every little helps I guess :)
Thanks for the hard work guys, really useful project!

Thanks for this fix @leakypixel :smile:


Finish e2e GPU memory fix

The prototypical GPU memory fix has been tested and solves the problem that the GPU runs out of memory for large action sets in e2e scenarios.
Implementation issue for #8734
To make it production ready, the following things need to be addressed / Definition of done:

[ ] code quality (comments, minor refactorings / renaming)
[ ] tests are added for not running into memory problems again
[ ] label_batch_size should be turned into a boolean variable balanced_sampling_negative_labels to remove unnecessary complexity in the interplay between label_batch_size and number_of_negative_examples
[ ] Sampling inside DotProductLossLayer should be unique as well using uniform_candidate_sampler

closing as stale


Add route to test JSON contributions

Maybe we could consider adding a route that allows contributors to paste in their JSON and run it against our tests, that way they can verify it passes before submitting a PR. I think it's possible to run mocha tests on the client side.

Great idea!

Ok, I'll start on this later this week


Pass arguments to Docker run command

I need to add a --log-level debug.
I have tried with args: ["/run.sh,"--log-level","debug"] but the container crash.
I just need to know if it's the appropriate way.

You should use the container.docker.parameters field.


Eclipse IDE - Problem to "Open Call Hierarchy" on class field

It seems to be unpossible to call hierarchy (Ctrl+Alt+H) in Eclipse IDE on a class field independent on views ("Java-Editor" or "Outline"). The result of this call returns empty list always.
The call hierarchy on a class method from "Outline"-view works fine as expected.
Lombok Version: 1.16.16
Eclipse Version: Neon Release 4.6.0

To clarify, the issue is that the call hierarchy does not show lombok generated methods that call the selected field.
For example, if I Open Call Hierarchy for a field foo that has a @Getter it does not show the getFoo() method in the Call Hierarchy view because it is generated by lombok.
The Outline view does show the getFoo() method though, and opening the call hierarchy on that from the Outline view works and is the next best thing, but this is a clunky alternative.


Random upload of all files upon save

What happened
I don't know if this issue was reported but since a few versions backwards while I work on a random file and try to save it will start uploading all the files in my directory "assets", "snippets", "config", "sections" etc..
Because of this it usually overwrites my settings_data.json file and I have now the habit of deleting the file so it doesn't overwrite my settings.
Steps to reproduce
I can't provide a steps to reproduce this issue, since this happens randomly for me.
The issue is not present only for me but for other developers as well working on the same version of themekit and same environment as me.
This is using only the theme watch command.
My Environment
OS (including version): Windows 10
Themekit version: 0.8.0
Editor (including version): Sublime Text 3
Ignore Files(if any): settings_data.json

Has anyone experienced this issue and knows if the new prerelease fix it?

duplicate of #519 please add your information there. Since you are also on the windows 10 OS, it seems likely that this problem is specific to windows 10. I am still under the suspicion that it may be because of a virus scanner.


Static functions redeclared as extern are static

Expected behavior
The second extern int f(); should have no effect.
Actual Behavior
rcc gives a type error.
Code

static int f();
extern int f();
<stdin>:2:13 error: invalid program: redeclaration of 'f' with different type or qualifiers (originally static int f(), now extern int f())

http://port70.net/~nsz/c/c11/n1570.html#6.2.2p4:

4 For an identifier declared with the storage-class specifier extern in a scope in which a prior declaration of that identifier is visible,31) if the prior declaration specifies internal or external linkage, the linkage of the identifier at the later declaration is the same as the linkage specified at the prior declaration. If no prior declaration is visible, or if the prior declaration specifies no linkage, then the identifier has external linkage.

Instructions:

In declare(), check if decl.storage_class is Extern and existing.storage_class is Static. If so, don't give an error.

Because the C standard is truly incomprehensible, the opposite is still an error.
$ run_clang
extern int f();
static int f();
<stdin>:2:12: error: static declaration of 'f' follows non-static declaration