minIOURandomCrop transorm is possibly buggy

https://github.com/open-mmlab/mmdetection/blob/d88ad8fc32a6cce46c72619a16b85226360a7ba2/mmdet/datasets/pipelines/transforms.py#L584

docstring is wrong.
Seems like such transformation may cause errors because may produce patch of various aspect ratios that will be resized to one on standard formats (VOC/COCO).
Simply: vertical rectangle may become horizontal and vice-versa. Generally it's wrong and it's better to crop patch of same aspect ratio as full image.

I can prepare PR if someone interested

@korabelnikov Thanks for the report and feel free to prepare a PR to fix it! @yhcao6 Please confirm this bug.

Thanks for reporting the bug.

Docstring is wrong.
It is indeed wrong. There is no crop_size in args, it should be min_crop_size.

MinIoURandomCrop will produce patch of various aspect ratios.
This transform is designed for SSD and we just follow the official implementation.

We are appreciate if you can open a pr to fix it.

If the aspect ratio changes after the transformation, I think it is indeed unreasonable. Because the flag is not changed during group sampling

I think there is a problem with this code, especially:
  if len(overlaps) > 0 and overlaps.min() < min_iou:                       continue
If there is a small bbox, then this condition will always be satisfied, this way of writing is wrong
The correct one should be:
     if overlap.max() < min_iou or overlap.min() > max_iou:               continue

I think there is a problem with this code, especially:
 if len(overlaps) > 0 and overlaps.min() < min_iou: continue
If there is a small bbox, then this condition will always be satisfied, this way of writing is wrong
The correct one should be:
 if overlap.max() < min_iou or overlap.min() > max_iou: continue

right!

I think there is a problem with this code, especially:
 if len(overlaps) > 0 and overlaps.min() < min_iou: continue
If there is a small bbox, then this condition will always be satisfied, this way of writing is wrong
The correct one should be:
 if overlap.max() < min_iou or overlap.min() > max_iou: continue

But when len(overlaps)==0, overlaps.max() or overlaps.min() will raise ValueError. So the correct one should be:
if len(overlaps)==0 or overlaps.max() < min_iou or overlaps.min() > max_iou: continue

I think there is a problem with this code, especially:
 if len(overlaps) > 0 and overlaps.min() < min_iou: continue
If there is a small bbox, then this condition will always be satisfied, this way of writing is wrong
The correct one should be:
 if overlap.max() < min_iou or overlap.min() > max_iou: continue

But when len(overlaps)==0, overlaps.max() or overlaps.min() will raise ValueError. So the correct one should be:
if len(overlaps)==0 or overlaps.max() < min_iou or overlaps.min() > max_iou: continue

OK, Thank you. I will check it.

for the code belows, why calculate the iou between the patch and the bbox using 'iou' mode?  as patch could be much larger than the bboxes.
overlaps = bbox_overlaps( patch.reshape(-1, 4), boxes.reshape(-1, 4)).reshape(-1)

would it be better like this:
overlaps = bbox_overlaps( boxes.reshape(-1, 4), patch.reshape(-1, 4),  mode='iof').reshape(-1)

We did some experiments and found that when changing overlaps.min() to overlaps.max() will lead to performance degradation(drop about 0.3~0.5 mAP on SSD and 0.2 on YOLOv3).
Also, we found that the IOU crop operation in the augmentation pipeline is not really where it works. The key is the expand operation before random crop. Combining expand and random crop together is similar to multi-scale training, whether to crop the object with a specific IOU is not so important.


Outdated README

project README is outdated.

#41 created

Looks like this is dead, closing for now.


new_trip usando banner

Please do not send the pull request to dev branch. In main branch New Trip view is up to date.


Fix for BooleanList questions

assemble_questions function can return either an Inquirer question or a list of them.
Alternatively we could have the function always return a list, and always use list.extend instead of list.append.

Tested in venv, this can handle both BooleanList (translated into list of questions) and "normal" questions (translated into a single question).


build with cgo disabled

Signed-off-by: Nino Kodabande<EMAIL_ADDRESS>

I guess the env can also be declared hight up perhaps after on:


add node-addon-api package for linux

I wrote this package for node-addon-api as the project relies on their own build system (node-gyp) that I didn't want to use.
It only supports Linux for now as the .gyp files on their repository seem to indicate that platform specific steps are needed for Windows and Macos.

@waruqi could you merge this PR too if it looks good to you ?

@waruqi is the PR ready to be merged ?


feat: support following shows and fairs

This PR resolves []
Description

Adds follow buttons to show and fair page.

PR Checklist

[ ] I have tested my changes on iOS and Android.
[ ] I hid my changes behind a feature flag, or they don't need one.
[ ] I have included screenshots or videos, or I have not changed the UI.
[ ] I have added tests, or my changes don't require any.
[ ] I added an app state migration, or my changes do not require one.
[ ] I have documented any follow-up work that this PR will require, or it does not require any.
[ ] I have added a changelog entry below, or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

support following shows and fairs - brian

iOS user-facing changes

Android user-facing changes

Dev changes

Need help with something? Have a look at our docs, or get in touch with us.

This PR contains the following changes:

Cross-platform user-facing changes (support following shows and fairs - brian)

  Generated by :no_entry_sign: dangerJS against d43150de395f564537adf486426082ed3ac53ff0

closing for now but can be used as a base if we want to pursue!


Can't change tab text nor underline color

How do you change a tab bar text and underline color?

added to Sass variables in e837e79bdcc46a2ded5d125e2e55d60159ad6c27

It would be great to be able to change the underline color with HTML, like we can with other elements.

Just use  before

Just use
div class="indicator orange" style="z-index:1" /div
before the
/ul

this worked for me:
override in your css file the following rule:
.tabs .indicator {
    color: <ur color>;
}

^ The above worked for me to change the tab's underline color, but I had to use background-color:
.tabs .indicator {
    background-color: <ur color>;
}

Neither of these is working here.

@joaosardinha did you put !important after the color?
.tabs .indicator {     color: <ur color> !important; }

saadq's answer works perfectly. To be clear, however:
.tabs .indicator {     background-color: #99cc00; }
The  needs to be an actual color, without the <> symbols
I needed to do a force refresh before seeing the change.

Building onto @BrenoMazieiro so that his code is readable
Add this right before the

No one has stated how to change the text color?

@Native-Coder
.tabs .tab a.active {
  color: <my-color>;
}

.tabs .tab a:hover {
  color: <my-color>;
}

.tabs .tab a {
  color: <my-color>;
}

notice .active is not a pseudo class, but an actual class name.

combo of things mentioned:

active is indeed a css class here.  my markup is a yellow scheme

.tab a.active {
  color:rgb(252, 234, 37)!important;
  background-color:rgb(3, 169, 244)!important;
}

2.I add the indicator and "color of your choice" classes AFTER the

I battled with this absolutely heinous pink for a few hours.

Thanks benjaminadk! puting the div after ul did the trick!

WIth JQuery
  // TAB Color
   $(".tabs" ).css("background-color", themeColor);

   // TAB Indicator/Underline Color
   $(".tabs>.indicator").css("background-color", '#FFF');

   // TAB Text Color
   $(".tabs>li>a").css("color", '#FFF');

where theme color is the color of your choice

the tab colors can be set with the usual classes red, brown, blue, etc
these were the parts i had to do css to change (thanks to everyone above but nobody had all these put together for me)

.tab a.active {
  color:rgb(252, 234, 37)!important;
  background-color:#448AFF!important;
}
.tabs .tab a:hover {
  background-color: #bcaaa4!important;
  color:#FFFFFF!important;
}
.tabs .tab a {
  color: #efebe9!important;
}
.tabs .indicator{
  background-color:#FFFFFF!important;
}

Here's a full answer of how to change both text and indicator/underline color using only HTML and the materialize color classes (i.e. no changes to CSS).
To change the text color, just add the text-color classes to the  tags, e.g.:
Test 1
To change the indicator/underline color, you can insert this before the  (originally posted by @BrenoMazieiro, updated by @g5codyswartz):

To wrap this up as a complete, 2-tab, example:

          Test 1

          Test 2

Test 1

Test 2

None of these worked well.
Here's how to do it in a way that doesn't involve using jQuery, extra classes, or !important.
It includes all components and is in SCSS format.
// TABS COLORS
.tabs {
  .tab {
    a {
      color: purple;
      &.active {color: purple;}
      &:hover {color: purple;}
      &:focus {
        background-color:lime;
        &.active{background-color:lime}
      }
    }
  }
  .indicator {background-color: purple;}
}

Working demo

I am working with angular 6 I tried all of your solutions but none of them has worked:
This is my actual code:

{{view.name}}

And when I use this css is not working:
.tabs .indicator {
background-color: blue !important;
}
OR
.li .indicator {
background-color: blue !important;
}
I have tried the

And it did not working.
I am using materialize 1.0.0, just updated today.

I am working with angular 6 I tried all of your solutions but none of them has worked:
This is my actual code:

          {{view.name}}

And when I use this css is not working:
.tabs .indicator {
    background-color: blue !important;
}

OR
.li .indicator {
    background-color: blue !important;
}

I have tried the

And it did not working.
I am using materialize 1.0.0, just updated today.

I'm getting the same bug

I am working with angular 6 I tried all of your solutions but none of them has worked:
This is my actual code:

          {{view.name}}

And when I use this css is not working:
.tabs .indicator {
    background-color: blue !important;
}

OR
.li .indicator {
    background-color: blue !important;
}

I have tried the

And it did not working.
I am using materialize 1.0.0, just updated today.

I'm getting the same bug

.tabs .indicator {

background-color: blue !important;

}

attach this lines in styles.css


Droplet updates

Began as an addition of some extra droplet statistics. Then turned into a more extensive edit of the droplet_injection routine based on observed cpu/gpu differences.

With the new commits, the verification result is still slightly worse than the previous PR https://github.com/george-bryan/CM1/pull/134 (Derecho; CPU: ifort, 2 MPI ranks; GPU: nvhpc, 2 MPI ranks + 2 A100 GPUs), using the namelist_ASD.verify with testcase=15:
Metrics
38 stat variables are identical.
40 stat variables show a mean relative difference > 1e-06
8 stat variables show a mean relative difference <= 1e-06
0th-order diagnostics
1 stat variables are identical.
8 stat variables show a mean relative difference > 1e-06
3 stat variables show a mean relative difference <= 1e-06
1st-order diagnostics
254 stat variables are identical.
2 stat variables show a mean relative difference > 1e-06
0 stat variables show a mean relative difference <= 1e-06


Layout problem when using the image ListItem component with is-selectable class

Combining the image ListItem component with the is-selectable class leads to selection checkmark overlap with the image...

Thanks for the issue. We'll look into this.

This should be fixed.

This seems to be fixed as of Fabric 1.2.1. See the repro of this issue.


Node.js: Add v5, v10, v11, v12, patch existent ones.

Close #140

Yes, all of them. They are pretty old manifests.


full version code

Hi, I think your research is very interesting. I see that the paper has been officially published, when will the complete code be open sourced.

Many thanks for your attention. See the `Train' section in the readme file for your answer.

The training codes are released now


Use service-broker-proxy v0.9.4

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Ido Bergerfroind seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Coverage remained the same at 68.214% when pulling fed76ea5eb54817cc9f48aac6eb535bee73c1f74 on use_sb_proxy_v_0.9.4 into 8d1489d5bae6fd3c2007deac81de24ad55985328 on master.


Is adding to groups persistent?

I'm using serverless and adding users to groups via the REST API. Does group membership persist beyond connection closing? IE, do I need to register to the groups every time a user connects or only once? I can't find this information in the docs anywhere.

Yes, when using serverless, we guarantee persistency of "users to group relationship" for 7 days.

Where can I find that guarantee in the documentation? I would love to link to that page from our documentation.

Any updates on this?
I am still looking for some kind of documentation.

We have a swagger describing the usage of adding user to group, inside which we have a description for ttl as Time to live in seconds for the user Id. Optional for live forever. https://github.com/Azure/azure-signalr/blob/dev/docs/swagger/v1.json#L289


Allow Kino to declare its GitHub name and version for assets

This way we can use something like jsDelivr for serving the assets without relying on public routes.
The configuration should be something like:
cdn: {:github, url, version}

Livebook will only attempt to use a CDN if version is not a pre-release.
However, in order for this to work, we need to make sure to tag all releases. My suggestion is to do something like this in the mix.exs:
aliases: ["hex.publish": [&check_tag/1, "hex.publish"]]

check_tag/1 will check if the tag has been created and pushed before publishing. Alternatively we can create and push the tag if none was created yet, something like this:
aliases: ["hex.publish": ["hex.publish", &publish_tag/1]]

On the Livebook side, we can use jsDeliver by default, but perhaps we provide an option for configuration. We can likely also remove the cache system we have, as we will rely less on it.

For git dependencies, there is a Mix.Project.config()[:build_scm] which tells us if a dependency is being build with Git. From there, we can either read the lockfile or issue a git command (probably preferrable), to find out the ref.


[Frontend] Hotfix for error flag on ubuntu machine without clang.

Context: The empty argument in the flags causes the ld failure when invoking gcc via subprocess (and inter-process communication) but not clang
Description of the Change: Only add flag when in macOS.
Benefits: User can avoid install clang.
Related GitHub Issues:

Went looking for this fix and couldn't find it in the changelog 👀


PSoC Build error in main.c

Hi again,
today I want get new images from my bother disks.
Software told me "Error: your FluxEngine firmware is at version 4 but the client is for version 5; please upgrade"
So I downloaded the thing for PSoC Creator, update components, clean and build the project.

main.c: In function 'cmd_set_drive':
main.c:573:44: error: 'struct set_drive_frame' has no member named 'high_density'
current_drive_flags = f->drive | (f->high_density<<1);
^
The command 'arm-none-eabi-gcc.exe' failed with exit code '1'.
--------------- Rebuild Failed: 03/24/2019 16:29:42 ---------------

Did I anything wrong?

After comment out: current_drive_flags = f->drive;// | (f->high_density<<1);
it buids complete. Then program.
But run the software contuing tells me: "firmware version 4, need 5"

In protocol.h in line 6 I set FLUXENGINE_VERSION = 5
Now it works.

That change should never have been checked in on the master branch --- it's experimental; I've backed it out. However, it should have at least built. It sounds like your protocol.h and your FluxEngine.cydsn directory got out of sync. Are you copying the FluxEngine.cydsn directory somewhere before building it with PSoC Creator?

I renamed the "FluxEngine.cydsn" folder to "FluxEngine.cydsn-old".
Then from zip I extract only the FluxEngine.cydsn folder into .\PSoC Creator\fluxengine-master.
But I see newer filedates also in the -old folder...

Could you check an entire clean copy out from github (downloading the zip file is fine) and build from there, rather than copying the FluxEngine.cydsn folder elsewhere, please, and let me know if that works?

Compiling Firmware... success.
Make Software... there are some issues, but it compliles all in result OK.

[62/136] Compiling C++ object<EMAIL_ADDRESS>../lib/ibm/decoder.cc: In Elementfunktion »virtual SectorVector AbstractIbmDecoder::decodeToSectors(const RawRecordVector&, unsigned int)«:
../lib/ibm/decoder.cc:23:26: Warnung: Vergleich zwischen vorzeichenbehafteten und vorzeichenlosen Ganzzahlausdrücken [-Wsign-compare]
if (bytes.size() < (headerSize + 1))
~^~~~~~

But I didn't program the cypress adapter. And so I work with the version "5" before, if there is no critical problem.....


[BUG] Unable to assign environment variables

Description
For the past couple weeks I've had intermittent issues getting environment variables added to my pods. The variables weren't getting added about 20-30% of the time. Now they're not getting added 100% of the time.
Reproduction Code
Create a values.yaml file.
serviceAccounts:
  spark:
    create: true
    name: spark
rbac:
  createClusterRole: true
webhook:
  enable: true
  port: 443
  namespaceSelector: "spark-webhook-enabled=true"
image:
  repository: docker.io/kubeflow/spark-operator
  tag: v1beta2-1.4.6-3.5.0

Install the Helm chart.
helm install my-release spark-operator/spark-operator  \
    -f values.yaml \
    --namespace spark-operator-env \
    --create-namespace \
    --version 1.2.15

Create a ScheduledSparkApplication in spark-py-pi.yaml:
apiVersion: "sparkoperator.k8s.io/v1beta2"
kind: ScheduledSparkApplication
metadata:
  name: pi-scheduled-spark-application
  namespace: "spark-operator-env"
spec:
  schedule: "* * * * *"
  template:
    type: Python
    pythonVersion: "3"
    mode: cluster
    image: "spark:3.5.1-python3"
    mainApplicationFile: local:///opt/spark/examples/src/main/python/pi.py
    sparkVersion: "3.5.0"
    driver:
      env:
        - name: ABC
          value: "123"
      cores: 1
      coreLimit: "1200m"
      memory: "512m"
      labels:
        version: 3.5.0
      serviceAccount: spark
    executor:
      cores: 1
      instances: 1
      memory: "512m"
      labels:
        version: 3.5.0

Apply the scheduled app:
kubectl apply -f spark-py-pi.yaml

Expected behavior
I expect ABC to show up as an environment variable when I run:
kubectl describe pod -n spark-operator-env pi-scheduled-spark-application-1715975950367111977-driver

Actual behavior
Instead, the only environment variables I see when I run kubectl describe are these:
Environment:
      SPARK_USER:                 root
      SPARK_APPLICATION_ID:       spark-fa6befd0696a4d679eb250971b8ff27d
      SPARK_DRIVER_BIND_ADDRESS:   (v1:status.podIP)
      SPARK_LOCAL_DIRS:           /var/data/spark-487682f1-a657-461b-a282-2e724fa3a92b
      SPARK_CONF_DIR:             /opt/spark/conf

Environment & Versions

Spark Operator App version:
Helm Chart Version: 1.2.14, and 1.2.15
Kubernetes Version: 1.28.3
Apache Spark version: 3.5.0

Check if you have enable webhook svc, use this kubectl get svc -n <your-ns> | grep webhook

spec. template. driver.env is set by webhook which listen port 8080, one way to fix this is use default port setting in values.yaml like:
webhook:   enable: true   port: 8080
the other way is to set spark operator param '--webhook-port' to  your port 443

@imtzer I updated the port to point to 8080 like you described, but I'm still not seeing the environment variables added. What's the reason for updating the port?

@imtzer I updated the port to point to 8080 like you described, but I'm still not seeing the environment variables added. What's the reason for updating the port?

spec.template.driver.env is patched in webhook，webhook default port is 8080，or you can remove webhook.port to use default value

@imtzer That was it! The problem was the namespaceSelector. When I took that out the environment variables showed up.  Thank you so much!


Swagger UI show weirdly for labels

"labels": "v1beta3.ObjectMeta.labels",
Not sure what that means...

cc @nikhiljindal

All maps currently show as type "any", which I think was done as a workaround for undefined custom types (#2971).

FYI. In the future, when the spec is upgraded to 2.0, the map can be documented using additionalProperties, e.g. string to model mapping
{
  "type": "object",
  "additionalProperties": {
    "$ref": "#/definitions/ComplexModel"
  }
}

Ref: https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md#model-with-mapdictionary-properties

@thockin @nikhiljindal Before the spec gets upgraded to OpenAPI/Swagger spec 2.0, can we replace "type": "any" with "type": "object" for the time being so as to avoid compilation error related to missing model "Any" ?

Does "type": "object" have any special meaning?
I think we chose "type":"any" arbitrarily to represent custom types.
It should be fine to change it.

"type": "object" means arbitrary JSON.

https://github.com/emicklei/go-restful/pull/270 replaces "any" by "object".
Thanks @wing328

Maps are represented correctly in swagger 2.0/OpenAPI now.


windows autobuilds intermittently failing

I'm seeing a few failures on the appveyor build:
npm install
npm ERR! code ERR_STREAM_WRITE_AFTER_END
npm ERR! write after end
npm ERR!      C:\Users\appveyor\AppData\Roaming\npm-cache\_logs\2018-04-30T07_01_37_522Z-debug.log
Command exited with code 1

It appears to be due to a known bug in npm: https://github.com/npm/npm/issues/19989
There are a few suggestions in that thread. I'll cycle through a few of them to see if they help.

5.8.0 didn't fix it: https://ci.appveyor.com/project/arcs/arcs-3i77k/build/0.0.165

Seems totes fixed mayhaps by last two PRs? Can reopen if we see more. https://ci.appveyor.com/project/arcs/arcs-3i77k/history


 Formatting and formula correction

Corrected "Square" formulas and added formatting for examples

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Thank you @iceicelogan for your contribution!


Use new ctest arguments to set environment variables

Uses https://github.com/girder/girder/pull/1964 to avoid problems with older versions of cmake.

Codecov Report

Merging #322 into master will increase coverage by 0.14%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #322      +/-   ##
==========================================
+ Coverage   45.32%   45.46%   +0.14%
==========================================
  Files         101      101
  Lines        2714     2714
  Branches       98       98
==========================================
+ Hits         1230     1234       +4
+ Misses       1484     1480       -4

Impacted Files
Coverage Δ

web_client/views/body/ImageView.js
67.52% <0%> (+3.41%)
:arrow_up:

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 e901d26...6edf0d7. Read the comment docs.


Bug 1797918 - Enables balancer module

update to rook v1.2.4
enable "balancer" module

/retest

@umangachapagain the back and forth on #401 and this PR confirms my preference to separate updates of dependent components (like rook) and changes that do semantic changes (that possibly depend on the updated component) into separate PRs...

/ok-to-test

(not sure why it didn't have the ok-to-test label)

@umangachapagain the back and forth on #401 and this PR confirms my preference to separate updates of dependent components (like rook) and changes that do semantic changes (that possibly depend on the updated component) into separate PRs...

Agree that it is messy which is why I am working on a separate PR for handling this matter.
(something that will not require us to upgrade version every time we add a feature)
For now, this PR gets the latest from rook and all other PRs can be built on top of this.

@umangachapagain a couple of questions:
* Is the setting of `TargetSizeRatio` independent of the addition of the `balancer` module? If yes, then it should be two commits instead of one.

They are dependent.

* Does the addition of these parameters require rook to be updated to 1.2.4?

Yes. TargetSizeRatio and balancer module support was recently added.

* The setting of `TargetSizeRatio` seems to be hard coded. Can this be made configurable? (This could be a topic of a later PR that might also make other settings like the Size of the ReplicatedSpec configurable, etc).

From what I understand, this seems to be a suitable value for OCS usecase and could be fixed.
@leseb Thoughts?

In general, I think patches bumping versions of dependent components like rook should be in a separate PR.

I'll go ahead and separate the commits then.

@umangachapagain you can leave it in this one PR for now. Just remember next time, please, it makes stuff eaiser.
And with respect to the dependency of changes (ratio depends on balancer module and balancer module depends on the update of rook: please just explain and mention these in the commit messages / pr description and/or code comments. This is important to understand depndencies and will prevent PR review questions and future questions by someone looking at the code / git history.

@umangachapagain regarding the configurability of values - I have just been bitten too many times by hard coded values that were good defaults, but then someone still needed to change them.
This PR is ok to have them hard coded. But we may want to make them configurable in a follow-up commit.

/test ocs-operator-e2e-a

/test ocs-operator-e2e-a

incomplete ;-)
/test ocs-operator-e2e-aws

Is the setting of TargetSizeRatio independent of the addition of the balancer module? If yes, then it should be two commits instead of one.

They are dependent.

It seems that they are actually independent:

The balancer support was added in ceph with https://github.com/rook/rook/pull/4784.
The TargetRatio which is for the pg_autoscaler, not for balancer, was added in https://github.com/rook/rook/pull/4803.

So I would argue that these should be two different patches.  One could even argue that they should be two differnt PRs... At least the PR description needs to mention both.


feat: [M3-8570] - Finish sunsetting Gravatar

Description 📝
This is a follow up from M3-8158 (#10859), which informed users with Gravatars of a sunset date of Sept 30 and transitioned users not currently using Gravatars to our new initial and color avatar icon.
This PR will remove Gravatar support for users who still have it on the communicated date.
Changes  🔄

Deletes a bunch of Gravatar-related components and utils
Uses our Avatar component only
Changes the username for system events or opened support tickets from "Linode" to "Akamai"

📸 Preview

Header
Header

Target release date 🗓
9/30/24
How to test 🧪
Prerequisites
(How to setup test environment)

Log in as an account with a Gravatar

Verification steps
(How to verify changes)

Go to the following locations in the app where we render avatars and confirm that you do not see your Gravatar anywhere:

Top Menu
Notification Center Event
Events Landing > Event Table Row
User Landing > User Table Row
User SSH Key Panel
Profile Display
Support Ticket Details (test this in dev with a dummy support ticket you comment on)

Confirm tests pass

As an Author I have considered 🤔
Check all that apply

[ ] 👀 Doing a self review
[x] ❔ Our contribution guidelines
[x] 🤏 Splitting feature into small PRs
[x] ➕ Adding a changeset
[ ] 🧪 Providing/Improving test coverage
[ ] 🔐 Removing all sensitive information from the code and PR description
[ ] 🚩 Using a feature flag to protect the release
[x] 👣 Providing comprehensive reproduction steps
[ ] 📑 Providing or updating our documentation
[ ] 🕛 Scheduling a pair reviewing session
[ ] 📱 Providing mobile support
[ ] ♿  Providing accessibility support

Made one change (confirmed with UX) to update the username from "Linode" to "Akamai" in the places shown in the PR description. This better matches the Akamai logo and is consistent with our decision to favor "Akamai" branding throughout the app.


Question: can noobaa-core be installed without noobaa-operator?

I'm evaluating noobaa as a drop-in replacement for minio for a specific use case. One of the requirements is to support an installation method via only manifests -- no operators should be used to install or maintain the storage component. Preferably a simple kubectl apply -f install-noobaa.yaml is all that is required to install it.
Is this supported? If so, can you point me to some documentation?

Hey @gregsheremeta !
We do have some new standalone deployment types of NooBaa -

https://github.com/noobaa/noobaa-core/blob/master/docs/dev_guide/standalone_with_db.md
NooBaa NSFS Non containerized - https://github.com/noobaa/noobaa-core/blob/master/docs/non_containerized_NSFS.md (NSFS means buckets are reading and writing plain objects to FS)

These deployments can be installed simply inside a container or directly on a node. Might this help?
Regarding the 1st option, I'm not sure also non FS buckets were tested before.
I'm not familiar with a different way to install containerized NooBaa without also installing NooBaa operator, @guymguym @dannyzaken @nimrod-becker might have other ideas


Add metrics for user lookups

https://github.com/department-of-veterans-affairs/vets-contrib/issues/2393
Add prometheus metrics for MVI and VSO lookups. Using different buckets than the default (.005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10) but let me know if I should adjust from what I currently have.

I think all the changes look good but I think we should add some tests. E.g. I think a unit test to verify that requesWithMetrics actually calls the promiseFunction would be good.


gamma function implementation

SPLIT FROM https://github.com/heltonmc/Bessels.jl/pull/26#issuecomment-1200481143
A small note: I was perusing your gamma implementation and I think there are a couple small improvements that could be made, assuming they don't cost precision somehow. For one, if I change the v = x^(0.5*x - 0.25) to v = exp((0.5*x-0.25)*log(x)) in large_gamma, I see a big speedup. And it doesn't seem like the log would make an issue, because you'll never hit that branch when x is zero.
Second, if there's a reason not to do that, then an intermediate method like this seems to be faster when x > 11.5 but it isn't too too large:
function smallish_gamma(x)
  _x = min(x, x-ceil(x-11.5))
  _g = small_gamma(_x)
  while _x < x # use the fact that gamma(x+1) == x*gamma(x)
    _g *= _x
    _x += one(_x)
  end
  _g
end

You could then branch on x < 30.0 or something instead and at least hit the large_gamma branch less often.
I haven't checked very hard to see if these tricks introduce new issues, but I wouldn't think that they do.
Originally posted by @cgeoga in https://github.com/heltonmc/Bessels.jl/issues/26#issuecomment-1200481143

Thank you for looking at this @cgeoga !!! Let's discuss here to try and keep the other thread focused on bessely.
I'm very happy to take PRs on this in general which we can iron out potentially a better implementation of this. As mentioned https://github.com/heltonmc/Bessels.jl/pull/26#issuecomment-1200514696 we would definitely need to test accuracy for this. The good thing about 1d functions is we can exhaustively test all the ranges. I would say for a function as important as gamma here keeping the max error below 2.5 ULP would be ideal. I need to move the gamma function into its own file as well to keep it separate and add tests as well. But as mentioned hopefully the powers are faster in 1.9, though I just did a quick test on a very old 1.9 branch and found it was much slower than 1.7, so keeping track of this by julia version would also be very helpful.

On a quick first test it looks like the first suggestion increased the mean ULP from 0.26595 to 1.98555 and the maximum ULP from 3 to 571.0 at x=162.81202133604663.

One thing worth noting is that although these techniques won't work for Float64, for Float32, there are a lot of options opened since you can do the internals in Float64 to avoid loosing precision.

Makes sense about moving the issues and apologies for the clutter. Also, wow about the additional error. I assumed it would be a little bit worse, but that is certainly more than I expected.
You've mentioned these back-of-the-envelope errors in terms of ULPs before---is there some easy demo you can point me to so I can figure out how to do that kind of error testing myself?  I should learn how to do this anyway, and then I can sort of pre-screen some of these ideas before posting.

I haven't tried it out but see Oscar's https://github.com/JuliaMath/FunctionAccuracyTests.jl.
Though in this case I just tested against SpecialFunctions.jl
julia> x = rand(10000)*170
julia> mean(1 .- SpecialFunctions.gamma.(BigFloat.(x)) ./ gamma.(x))/ eps(Float64)

If you want more details on my thought process here, my Juliacon talk was on floating point math implementation and testing. https://www.youtube.com/watch?v=-tFS4PUHqT0

Nice, thank you both! Will do some studying.

Can you guys comment a bit more on the current gamma implementation defined in Bessels.jl? Is it ready to use? Why is it not exported? I have a package that depends on both besselk and gamma from SpecialFunctions.jl and would like to replace this dependency by Bessels.jl that is pure Julia with zero dependencies. However, I would like to understand the future plans better before making this migration.

The function is definitely ready to use. We use it in practically every function in this library which is why we rolled our own implementation that is much faster. It has a max ULP around 2.5-3. But it does have some limitations as it only works for real arguments and for single and double precision. So if you need it for complex or higher precision it won't work.
The reason it is not exported is because this is probably not the best package for a native gamma function implementation. There have been some discussion about moving that over to SpecialFunctions.jl but my plan was to actually create a lightweight Gamma.jl package that just has julia implementations of gamma and similar functions. So I'd be hesitant to export it here as it is likely that we will move it out of the package in the future.

+1 for a Gamma.jl package, that would be great.

Awesome @heltonmc , thank you for the prompt reply. I am also +1 for Gamma.jl or maybe a new package that wraps all these special functions in pure Julia, maybe SpecialFuns.jl?

the argument for splitting them up is that a lot of libraries want to use gamma functions without the precompilation time of loading everything.

Thank you @oscardssmith for adding the comment. Is the compilation time a real issue for Bessels.jl or is this another case of premature modularization? I feel that many of these packages splits in Julia are more harmful than helpful, specially when it comes to maintenance. The collateral effect of having many packages is that some of them die after a while without maintainers. Working on the same repo with the same code style, multiple maintainers, etc. pays off in my opinion.

Well using SpecialFunctions is already .35 seconds (and most of the code is just calling C functions).

@juliohm that was my general idea to have a higher level package that wraps all of the mathematical functions outside of Base. I'd like to see more of a canonicalization of the math functions in Julia (particularly the special functions). In my opinion there are many packages that do similar things but the quality is variable and sometimes hard to discern for new users. And they are often put together quickly for a specific application, registered, and then never maintained after…. A python user is immediately going to SciPy or mpmath and they have some sense of quality and stability which I think is a good thing.
Part of the problem with SpecialFunctions.jl is it is actually hard to find maintainers and get things merged where the scope is not so clearly defined (and maybe nobody feels any kind of authority?). One example that I think is concerning is the most recent PR and issue about the fresnel integrals which existed in a different package where a first time contributor to the language submitted a PR to add that functionality that was carefully reviewed by a primary contributor to the language but was decided that it is better in a separate package. So that contributor submitted to the other package but that package is unmaintained….  now we are point people on SpecialFuncitons.jl to an unmaintained package where the existing code base can be improved. So to your point that is definitely an issue with all of these smaller packages. Though, ideally these can be brought under a higher level package under an organization so we can continue to improve them.
So yes… what to do with gamma 🤷♂ ? I’m happy for this package to have special functions but I start to become a bit worried about scope. Which is something I think SpecialFunctions.jl is not so clearly defined. Should we also include loggamma, beta, polygama, digamma, and their incomplete forms here? But I feel like then why not just start making Bessels.jl (or rename it) to just general special functions. I still think the right thing to do is try to improve the scattered special functions already registered in the general repository and improve them and then bring them under some higher organization and repository to standardize in some way. For example, I’ve been spending some time trying to improve Struve.jl so that hopefully we can have several similar quality libraries to piece together.
But I think I agree with your overall sentiment…. Though maybe I was hoping to improve the already existing registered with very defined scope that a higher level package can reexport. So new users can be a little more confident in the quality of the package they are using and having an easy interface with a single package. Though say if you wanted just the gamma function, you can then just depend on that package which has a very defined scope and very lightweight.
Really appreciate your thoughts and definitely welcome to other suggestions!

Thank you all for the very insightful comments. You certainly have better
sense of scope and can decide on a good tradeoff for these projects. I just
commented as an end user who has a very superficial view of the
functionality and would pretty much enjoy a single dependency a la
SpecialFuns.jl in all packages I maintain. If you feel that users will
benefit from tiny packages with just one math function, please go ahead. My
impression is that most people using Bessel will also need Gamma and
related functionality.
Em sáb., 10 de set. de 2022 19:42, Michael Helton @.***>
escreveu:

@juliohm https://github.com/juliohm that was my general idea to have a
higher level package that wraps all of the mathematical functions outside
of Base. I'd like to see more of a canonicalization of the math functions
in Julia (particularly the special functions). In my opinion there are many
packages that do similar things but the quality is variable and sometimes
hard to discern for new users. And they are often put together quickly for
a specific application, registered, and then never maintained after…. A
python user is immediately going to SciPy or mpmath and they have some
sense of quality and stability which I think is a good thing.
Part of the problem with SpecialFunctions.jl is it is actually hard to
find maintainers and get things merged where the scope is not so clearly
defined (and maybe nobody feels any kind of authority?). One example that I
think is concerning is the most recent PR and issue about the fresnel
integrals which existed in a different package where a first time
contributor to the language submitted a PR to add that functionality that
was carefully reviewed by a primary contributor to the language but was
decided that it is better in a separate package. So that contributor
submitted to the other package but that package is unmaintained…. now we
are point people on SpecialFuncitons.jl to an unmaintained package where
the existing code base can be improved. So to your point that is definitely
an issue with all of these smaller packages. Though, ideally these can be
brought under a higher level package under an organization so we can
continue to improve them.
So yes… what to do with gamma 🤷♂ ? I’m happy for this package to have
special functions but I start to become a bit worried about scope. Which is
something I think SpecialFunctions.jl is not so clearly defined. Should we
also include loggamma, beta, polygama, digamma, and their incomplete forms
here? But I feel like then why not just start making Bessels.jl (or rename
it) to just general special functions. I still think the right thing to do
is try to improve the scattered special functions already registered in the
general repository and improve them and then bring them under some higher
organization and repository to standardize in some way. For example, I’ve
been spending some time trying to improve Struve.jl
https://github.com/gwater/Struve.jl so that hopefully we can have
several similar quality libraries to piece together.
But I think I agree with your overall sentiment…. Though maybe I was
hoping to improve the already existing registered with very defined scope
that a higher level package can reexport. So new users can be a little more
confident in the quality of the package they are using and having an easy
interface with a single package. Though say if you wanted just the gamma
function, you can then just depend on that package which has a very defined
scope and very lightweight.
Really appreciate your thoughts and definitely welcome to other
suggestions!
—
Reply to this email directly, view it on GitHub
https://github.com/JuliaMath/Bessels.jl/issues/27#issuecomment-1242815205,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAZQW3PSITQYINPLBQG4MELV5UFGZANCNFSM55FYNCXQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

Yes - and that is definitely the most important thing to consider. We should probably be a bit more mindful on the best thing for users here. It's probably best to only have one dependency in their tree so that it is easier to manage versioning etc.
But I don't think it's wise to have tiny packages like you mentioned. I'd like to have packages that have closely related families of functions. For example, here I plan to give bessel functions, modified bessel functions, spherical bessel functions, airy functions, and hopefully soon kelvin functions. The amount of source code for all of that is getting quite large and the amount of time it takes to test each function is also increasing. Then a gamma package can contain all the gamma and related functions I mentioned earlier. I'm actually trying to do some convincing over at Struve.jl to include related functions as well but we'll see...
But getting back to your original question. The gamma function here is quite good but will probably be moved to a Gamma.jl package. Then can create a top level package that re-exports all of the special functions.
Name suggestions for a top level package are most welcome! As well as anyone who would like to help with that!

As a side comment, VSCode recently released a nice feature for testing
individual test sets, which is wonderful:
https://discourse.julialang.org/t/prerelease-of-new-testing-framework-and-test-run-ui-in-vs-code/86355
So long testing times may not be an issue in the near future.
Em sáb., 10 de set. de 2022 20:18, Michael Helton @.***>
escreveu:

Yes - and that is definitely the most important thing to consider. We
should probably be a bit more mindful on the best thing for users here.
It's probably best to only have one dependency in their tree so that it is
easier to manage versioning etc.
But I don't think it's wise to have tiny packages like you mentioned. I'd
like to have packages that have closely related families of functions. For
example, here I plan to give bessel functions, modified bessel functions,
spherical bessel functions, airy functions, and hopefully soon kelvin
functions. The amount of source code for all of that is getting quite large
and the amount of time it takes to test each function is also increasing.
Then a gamma package can contain all the gamma and related functions I
mentioned earlier. I'm actually trying to do some convincing over at
Struve.jl to include related functions as well but we'll see...
But getting back to your original question. The gamma function here is
quite good but will probably be moved to a Gamma.jl package. Then can
create a top level package that re-exports all of the special functions.
Name suggestions for a top level package are most welcome! As well as
anyone who would like to help with that!
—
Reply to this email directly, view it on GitHub
https://github.com/JuliaMath/Bessels.jl/issues/27#issuecomment-1242818484,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAZQW3JD6MTDG3EBQPTLM6DV5UJLLANCNFSM55FYNCXQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

O wow thank you!! I've been locally commenting out test groups not to run which is definitely a bit of a hack.

@heltonmc any timeline for the Gamma.jl package? I am looking forward to drop SpecialFunctions.jl from my dependencies and favor Bessels.jl + Gamma.jl. In the meantime, can I safely depend on Besses.jl and use Bessels.gamma explicitly even if it is not part of the public API? Are you planning  to release a minor release when it is moved to Gamma.jl?

You can explicitly depend on Bessels.gamma yes. I will definitely follow the guidelines I lay out at https://github.com/JuliaMath/Bessels.jl/blob/master/NEWS.md#changelog on when to increment minor versions and include Bessels.gamma as an unoffical exported function. When we move gamma out of this package we will increment the minor version (e.g., v0.2 -> v0.3) and make very big mention of it in the NEWS.md file. I'll comment here as well.
The timeline is tricky as I want to be as fair as possible giving credit to all the original authors of julia code in SpecialFunctions.jl that worked on gamma like functions (there's a few functions I'd like to move over along with the implementation here). To me the best way to do this is by preserving all of the git history for the necessary files. Of course I am not a maintainer or contributor explicitly at SpecialFunctions.jl so wouldn't want to step on any toes. I'll work to see if I can get this done this week.... but I really don't want to make any promises there.

And just another comment so it's clear for anyone using gamma. If you call gamma with Bessels.gamma even if we move the function to another package that call will still work in your code so you don't really have to worry about any breaking changes (the API for gamma is very stable). Every function in this package relies on gamma so it will also be loaded within the module either by a using Gamma or with the function defined within the package as it is now.
Now is that good practice...... probably not 🤷♂ but this package will always depend heavily on gamma so that functionality will always be there.

I've updated the title of this issue as it has evolved into the scope of this project itself rather than the actual gamma implementation.
I think I've become a bit more persuaded by @juliohm and some others who have reached out to have a more centralized package instead of it being fragmentated. As of now @time_imports using Bessels takes about 10 milliseconds on my computer which I think makes this package even though it has a large amount of code fairly lightweight for users and won't contribute to longer package load times. However, the TTFX will be longer as most of the time is on code generation.
Another thing I'm starting to realize is testing might be better if all related functions with overlapping code were under the same folder that were tested simultaneously by CI. For example, there is sometimes a chain of function calls like gamma->besselk->airy->inhomog. airy. But in some domains, besselk may need to call the airy implementation. So I'm thinking it might make more sense if there is any overlapping code that they share the same project to make sure any changes are rigorously tested within the scope of all dependent special functions. Of course in my case gamma is always independent and could be separate....
Therefore, I might suggest that this package be home to any functions listed in Chapter 9-11 of NIST (https://dlmf.nist.gov/) which is also how mpmath (https://mpmath.org/doc/current/functions/index.html) groups them though they also include Chapter 12 and some of the special cases of hypergeomtric functions.
I think I may make a discourse announcement for this package and maybe some discussion can continue there...
Thanks everyone for the thoughts!

Having a single umbrella for these functions will save you a lot of maintenance headache for sure @heltonmc. Looking forward to seeing it become the next generation special functions in Julia 🚀

@heltonmc I am trying to purge SpecialFunctions.jl from my indirect dependencies...
Do we have the functionality to replace these three functions from this core package already?
https://github.com/JuliaGraphics/ColorVectorSpace.jl/blob/8ec1d3549cab5064be2f09b8bb8de6f502c9c2ba/src/ColorVectorSpace.jl#L26
I can submit a PR to ColorVectorSpace.jl to remove SpecialFunctions.jl and add Bessels.jl instead.

I actually thought SpecialFunctions already had a loggamma implementation but it looks like it’s just for complex values. I am on vacation until next week so can’t tell exactly what is going on.  I think having a good loggamma implementation here is important as it is needed. And I believe logabsgamma can be called from that.
Is ‘lfact’ deprecated? Is that just the logarithm of the factorial? That could also be easily defined from the loggamma algorithm… seems like an important function. I actually had an implementation of loggamma early on that I’ll try to track down again. I’ll try to look into that this week.
But to answer your question only gamma is supported right now and the other ones should really be defined from a dedicated loggamma implementation.


find remote cluster ID for the filesystem

Pull request checklist

Pull request type

Please check the type of change your PR introduces:

[ ] Bugfix
[x] Feature Enhancement
[ ] Test Automation
[ ] Code Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Community Operator listing
[ ] Other (please describe):

What is the current behavior?

User needs to pass clusterID along with the storage class.

What is the new behavior?

User do not need to pass clusterID along with the storage class.

How risky is this change?

[x] Small, isolated change
[ ] Medium, requires regression testing
[ ] Large, requires functional and regression testing

@madhuthorat @deeghuge @amdabhad Please review.

regression test cases are passed.
Command:
kubectl exec -it ibm-spectrum-scale-csi-test-pod -- pytest  remote_test.py -m "regression" --html=/data/regression_driver.html

Output:
12 passed, 337 deselected in 1240.96s (0:20:40)


Extract commons value.

Codecov Report

Merging #226 (c32ccd9) into master (a1ac185) will increase coverage by 0.03%.
The diff coverage is 40.00%.

@@             Coverage Diff              @@
##             master     #226      +/-   ##
============================================
+ Coverage     86.52%   86.55%   +0.03%
- Complexity     9801     9804       +3
============================================
  Files           533      533
  Lines         35579    35564      -15
  Branches       6212     6208       -4
============================================
- Hits          30785    30783       -2
+ Misses         3528     3518      -10
+ Partials       1266     1263       -3

Impacted Files
Coverage Δ

...e/commons/math4/core/jdkmath/AccurateMathCalc.java
0.00% <0.00%> (ø)

...tim/nonlinear/scalar/noderiv/SimplexOptimizer.java
84.24% <50.00%> (+0.57%)
:arrow_up:

...pache/commons/math4/core/jdkmath/AccurateMath.java
96.03% <100.00%> (+0.23%)
:arrow_up:

...gacy/analysis/integration/TrapezoidIntegrator.java
81.39% <100.00%> (ø)

...optim/nonlinear/scalar/noderiv/CMAESOptimizer.java
83.65% <0.00%> (-0.44%)
:arrow_down:

...h4/legacy/analysis/differentiation/DSCompiler.java
99.48% <0.00%> (+0.17%)
:arrow_up:

...acy/optim/BaseMultiStartMultivariateOptimizer.java
74.54% <0.00%> (+3.63%)
:arrow_up:

...criptive/AbstractStorelessUnivariateStatistic.java
88.88% <0.00%> (+3.70%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


implement benchmarks in ci

@geseq add pls:
git checkout --orphan gh-pages
git rm -rf .
git commit --allow-empty -m "Initial commit on gh-pages"
git push origin gh-pages

@geseq add pls:
git checkout --orphan gh-pages
git rm -rf .
git commit --allow-empty -m "Initial commit on gh-pages"
git push origin gh-pages

done

It seems that only repository owners can run benchmarks due to permission restrictions in GitHub Actions, especially when it comes to posting comments on pull requests from forks. Therefore, we’ll need to manually rerun the benchmark jobs as needed.
Thanks for your understanding!


Bulk data dictionaries currently missing type annotations (Transformation) for age

proposed solution:

go back to https://docs.google.com/spreadsheets/d/1_6dnAjl2B2xse3uEB9UgKQziZeduZ9MDAVtUPW5IwIY/edit#gid=927345496&fvid=162673764 and pick the type column for everything annotated as controlled_term is nb:Age
take the script to make new json files: https://github.com/neurobagel/bulk_annotations/blob/a53a17b8df051ef38849cfa47109c496fc2aec64/process_annotation_to_dict.py and add logic to provide Transformations
pull in the updated


Support Drag-and-Drop

We support ElementHandle.uploadFile for <input type=file> but we don't support emulating dragging in files onto an arbitrary element.

@fran0254 we prioritize work based on the demand / effort ratio. Since we don't see much interest in this issue, and the effort is unclear but surely requires upstream contribution to chromium, this issue is a low-pri for us.

For the record: there's a DevTools API proposal on drag-and-drop.

I would love this feature

In my case it had been resolved with direct search input[type="file"] tag, not button

me too

Would really appreciate this feature also.

me too

I have just tested mouse down/move/up with pupeeteer at https://try-puppeteer.appspot.com/
However it did not work with no errors
This is the code that I have tested.
const browser = await puppeteer.launch();

const page = await browser.newPage();
await page.goto('https://html5demos.com/drag');

await page.mouse.move(438,  194, { steps: 1 });
await page.mouse.down();

await  page.mouse.move(208,  301, { steps: 1 });
await  page.mouse.up();

console.log('xxxxxxxxxxxxxxxx');

await page.screenshot({path: 'screenshot.png'});

console.log('yyyyyyyyyyyyy');

I need this as well. Building an automation framework.

Any solution we have on this ?

Any word on this being addressed? It is understandable if it is not a priority but I just want to know for planning purposes.

My team needs this as well, any updates about the timeline are highly appreciated.

Registering my interest in this issue. Drag drop remains the only (and gaping) hole my error reproduction emulator.

Can't test drag-n-drop feature without drag-n-drop in puppeteer:(

I would also like this drag and drop feature since it is a very common functionality and testing drag and drop using puppeteer is quite in demand now.
Using page.mouse.down, mouse.move and mouse.up didn't work for me either. I also tried it in https://try-puppeteer.appspot.com/ and below is my code:
`const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.goto('http://html5demos.com/drag/');
await page.waitFor(2000);
// Move mouse to the item that will be drag and mouse down
const dragItem = await page.$('a[id="one"]');
const  dragItemBox = await dragItem.boundingBox();
const x = dragItemBox.x + (dragItemBox.width/2);
const y = dragItemBox.y + (dragItemBox.height/2);
console.log(x);
console.log(y);
await page.mouse.move(x,  y);
await page.mouse.down();
await page.waitFor(100);
// Move teh drag item to container and release mouse
const container = await page.$('div#bin');
const containerBox = await container.boundingBox();
const x1 = containerBox.x +  (containerBox.width/2);
const y1 = containerBox.y + (containerBox.height/2);
console.log(x1);
console.log(y1);
await page.mouse.move(x1,  y1);
await page.waitFor(100);
await  page.mouse.up();
// Supposely the 'Best VPN' item should be drag into container and it should be disappeared on the right side. However it still remain at the same place since the mouse down, mouse move and mouse up didn't quite work and the real drag and drop
console.log('Finished');
await page.screenshot({path: 'screenshot.png', fullPage: true});
console.log('Screenshot taken');`
It didn't drag the item into the bin as expected.

I think I ran into the issue as well.
Part of my test page has custom drag and drop functionality with jquery.
The mouse down, move, mouse up steps worked correctly with this scenario.
However, another part relies on the browser's native drag and drop behavior.
(For example, the user can drag images by default, view a ghost image, and drop it in a dropzone)
With the native drag in puppeteer, it appears that mouse down it not triggering the drag event, and nothing happens on mouse up (drop). Since the mouse cursor is not provided, I did not expect the ghost image, but that would be a nice to have.

We can now upload our files to dropzone by converting HTMLInputElement.files to DragEvent.dataTransfer.files like this:
const fileInputIdentifier = "some-unique-identifier";
const dropZoneSelector = ".dropzone";
const filePath = "/path/to/file";

await page.evaluate((fileInputIdentifier, dropZoneSelector) => {
    document.body.appendChild(Object.assign(
        document.createElement("input"),
        {
            id: fileInputIdentifier,
            type: "file",
            onchange: e => {
                // Do not use DragEvent instead of Event.
                // DragEvent has native dataTransfer property, which cannot be created by scripts.
                document.querySelector(dropZoneSelector).dispatchEvent(Object.assign(
                    new Event("drop"),
                    { dataTransfer: { files: e.target.files } }
                ));
            }
        }
    ));
}, fileInputIdentifier, dropZoneSelector);

const fileInput = await page.$(`#${fileInputIdentifier}`);
await fileInput.uploadFile(filePath);

...unless dropzone checks Event.isTrusted.
See this article.

Hey if anyone is stuck trying to get this to work and needs an immediate solution check out my post over here: https://github.com/puppeteer/puppeteer/issues/1366#issuecomment-589828387
I hope puppeteer provides a built in solution, in the meantime this above approach worked for me.

Waiting for this feature also.

This would be helpful ! Drag elements over time is more common. Waiting for this to be able to implement my unit test. :)

Maybe this #74 pull request works for this issue?

Having the same wish for that request.

What's the conclusion ? I'm having the same issue right now

Also me. Would be great to have this feature.


Add a "About Page" in the settings applications

Currently the small About page that is attached to the application gives very little information. We need to make it better.
A good idea would be try out this as a nice starting point.

I think it would also be a good idea to put the GitHub-link into the app, to give users a quick way to check out the repository.

Maybe in "About", you could add something like this to the end:
"8Vim is an open-source application. For feedback, you can visit the GitHub-repository: https://github.com/flide/8VIM"

The only problem is: this also sounds a little bit like it belongs in the "Help & Feedback" -category. Not sure though.
The "Help & Feedback" -category seems a little unnecessary anyways, at least when it contains that few options.

In the "About" -Popup, some words seem to be randomly capitalized. For example, why is "Developed" capitalized? Should "Application" be capitalized?
There should be a space between "Designed and Developed by Filde" and "iteration 5". Currently it looks like, this is one sentence. "Designed and Developed by Filde iteration 5"
Maybe make it "Version: iteration 5"


Feature request: over the air updates (MEGH-1904)

Could you implement OTA to the examples?

This is already supported, please see details here: https://rainmaker.espressif.com/docs/ota.html

O thanks! Didn't see that


[BUG] ImportError: cannot import name 'ChromaDB'

Describe the bug
ImportError: cannot import name 'ChromaDB' from 'swarms' (/home/ermia/anaconda3/envs/deep-shap/lib/python3.10/site-packages/swarms/__init__.py)

To Reproduce
Steps to reproduce the behavior:
Here's the code I'm running:
from swarms import Agent, ChromaDB, OpenAIChat

# Making an instance of the ChromaDB class
memory = ChromaDB(
    metric="cosine",
    n_results=3,
    output_dir="results",
    docs_folder="docs",
)

# Initializing the agent with the Gemini instance and other parameters
agent = Agent(
    agent_name="Covid-19-Chat",
    agent_description=(
        "This agent provides information about COVID-19 symptoms."
    ),
    llm=OpenAIChat(),
    max_loops="auto",
    autosave=True,
    verbose=True,
    long_term_memory=memory,
    stopping_condition="finish",
)

# Defining the task and image path
task = ("What are the symptoms of COVID-19?",)

# Running the agent with the specified task and image
out = agent.run(task)
print(out)

Expected behavior
It should run without any errors as it is an example in the readme.md of the repository.
Screenshots

Additional context

Upvote & Fund

We're using Polar.sh so you can upvote and help fund this issue.
We receive the funding once the issue is completed & confirmed by you.
Thank you in advance for helping prioritize & fund our backlog.

@behroozazarkhalili this code was taken out of the main swarms package to reduce redundancy, you can import it from here:
https://github.com/kyegomez/swarms/blob/master/playground/memory/chroma_db.py

@behroozazarkhalili this code was taken out of the main swarms package to reduce redundancy, you can import it from here:
https://github.com/kyegomez/swarms/blob/master/playground/memory/chroma_db.py
It is not the correct way to remove the bug. I think we should update the readme file to effectively handle this bug.

@behroozazarkhalili the code example has been removed! Let me know if you have any other questions!

@behroozazarkhalili try
from swarms_memory import ChromaDB

@behroozazarkhalili @www lmk will be closing soon


Create terrainManager

The terrainManager will create terrainElements. Allowing to create large terrains made out of smaller chunks.
This will result in lesser triangles to be rendered since the renderer only needs to render some smaller chunks instead of the full terrain.
The basic heightfield generation happens in the terrainManager. The terrainElements only control the mesh generation.

Calculation of pivot/ origin of the terrainElement happens with the following function
int origin = index_x * width + index_z * width  * (tWidth+1);


feat(Partner Management APIs): add new service to project

PR summary

Adding new partner API to fetch resource usage reports.
TRI: https://github.ibm.com/BSS/architecture/blob/master/design-docs/cosell/partner.md
Issue: https://github.ibm.com/BSS/metering-deliverables/issues/2063
PR Checklist
Please make sure that your PR fulfills the following requirements:

[x] The commit message follows the Angular Commit Message Guidelines.
[x] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

Current vs new behavior

Does this PR introduce a breaking change?

[ ] Yes
[ ] No

Other information

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Integration test results

Example results

:tada: This PR is included in version 0.58.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[BUG] First call to CREATE OR REPLACE TABLE shows confusing INFO

If the first table a user creates is created with CREATE OR REPLACE syntax, they get a confusing INFO:
CREATE OR REPLACE TABLE stations WITH (
    location = '/raid/weather_meta/stations.parquet',
    gpu=True
)

# in Jupyter, red INFO line:
No tables are registered.

The table is successfully created, but the INFO message makes it seem like it might not have been.
Is there a reason to emit this message at all?

No, I'm not sure why we choose to log that message at the warning level, as there are various cases where one might perform SQL queries without actually registering any tables - I can start off a PR switching this to a debug level log, and also look through the code to see if there's any other places where it might be more fitting to switch the log level.


ESM and types missing issue with 2.0.0 release

We are having trouble including the 2.0.0 version you recently released.
We were able to fix the issue by adding the following line to the exports in the package.json:
  "exports": {
    ...
    "types": "./types/index.esm.d.ts"
  }

Thanks for the suggestion, added that line: https://github.com/timohausmann/quadtree-ts/commit/53c6a894494adf67464ae99b4a77da1141ce2615#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519
and published: https://www.npmjs.com/package/@timohausmann/quadtree-ts?activeTab=versions

Thank you very much. That is highly appreciated!

You're welcome, let me know if the issue persists.


Add package mariadb-server-galera on image photon/mariadb

This commit add the binaries needed by mariadb cluster.

Coverage decreased (-0.006%) to 64.526% when pulling 14c7a15f0e88eb99da947cca941ca47fae6a19a4 on vasartori:add_galeradb_bin into 981743ada955b6f1225e3a275ffc7f74815181cd on vmware:master.

Sorry we are moving from MariaDB to postgresql

OK! No problem!


[Snyk] Upgrade sharp from 0.33.3 to 0.33.4

This PR was automatically created by Snyk using the credentials of a real user.![snyk-top-banner](https://github.com/andygongea/OWASP-Benchmark/assets/818805/c518c423-16fe-447e-b67f-ad5a49b5d123)
Snyk has created this PR to upgrade sharp from 0.33.3 to 0.33.4.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 2 versions ahead of your current version.

The recommended version was released on 21 days ago.

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:

🧐 View latest project report
📜 Customise PR templates
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Check out a preview of your pull request here: https://app-servicecanadalabs-dev-pr-preview-3.azurewebsites.net


Numpy integration and comphys integration

In task 3, there is a task:

Compare the numpy integration functions to the ones found in compphys

So what really are we comparing? Can you elaborate?

So in this case, we have to compare results of various functions in numpy that can be used for integrations to the ones that are mentioned in Comphys( Simpson, Trapezoid and Adaptive trapezoid).


Adding workflow/integration-test.yml

Describe what this PR does / why we need it
Adding workflow/integration-test.yml
Does this pull request fix one issue?

Describe how you did it
Describe how to verify it
Special notes for reviews

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Please sign the Contributor License Agreement.

Please sign the Contributor License Agreement.

ok！


Can't compile the project with i18n

Hello there,
I was trying to apply i18n in my angular app and met this error...
Unexpected value 'NgXCreditCardsModule in /path/to/project/node_modules/ngx-credit-cards/index.d.ts' imported by the module 'AppModule in /path/to/project/src/app/app.module.ts'. Please add a @NgModule annotation.
Project config:

Angular: 4.0.3
Typescript: 2.3.4
Node: 7.7.1
NPM: 4.1.2

Could you please help me with this?
Thanks.

Hey @abhilashrathod have you found a way around this?

@nwrman I used your directive files and created my own @NgModule and added them as a part of my project and it worked..!

Merged a PR from a user so should be good now

@abhilashrathod We are getting same issue. can you share example ?

@aditdeveloper Nothing much I did there, I took all the src files from this repo and created my own custom angular module. Imported and exported all modules. Imported that module in my main app.module and everything worked fine as expected.


fix: make compatible with Angular 1.5 and non-cached templates

Same change introduced in 0e85670ed377148ac3a7d5ef6ff5ed7c46446858
Closes #1609

Derp, seems so obvious now. Thank you. :+1:


Watch ambassadorinstallations.getambassador.io

This commit makes Ambassador watch for
ambassadorinstallations.getambassador.io CRD if it exists in the
cluster.

@concaf Why is this needed? Why should Ambassador watch the AmbassadorOperator CRD? Is this just so that it will show the data in the debug page? If so, then I don't think it's needed because Ambassador doesn't need to update the Envoy configuration when the AmbassadorInstallation CRD changes: only the operator needs to know about that CRD, correct...?

Re

Why is this needed?
See Slack conversation https://datawire.slack.com/archives/CT0TVAL0M/p1581949417006300 for the answer.


Operator request: Leaky Relu (Unsupported TFLite OP: 98 LEAKY_RELU!)

Note: Currently, we only accept TensorFlow Lite builtin operators request.
What is the TensorFlow Lite operator you need
(Please attach a tiny TFLite model *.tflite, which contains the operator you need ONLY.)
LeakyRelu
What kind of service you are trying to deploy your model?
.tflite to .onnx
Would you like to contribute the operator?
Additional context
Add any other context about the problem here.

using command for yolo tflite model: tflite2onnx.convert(tflite_path, onnx_path)
Error message:
if opcode in tflite.BUILTIN_OPCODE2NAME:
name = tflite.opcode2name(opcode)
raise NotImplementedError("Unsupported TFLite OP: {} {}!".format(opcode, name))
else:
raise ValueError("Opcode {} is not a TFLite builtin operator!".format(opcode))
NotImplementedError: Unsupported TFLite OP: 98 LEAKY_RELU!

alpha typically 0.2

@shilpan97 thanks for reporting this issue. Are you interested in contributing this operator? We have documents to help with the implementation, check https://github.com/jackwish/tflite2onnx/blob/master/docs/how-to-enable-new-operator.md


Assignment of xt::zeros needs major speed-up

I benchmarked resetting an xarray to zero and found that array = xt::zeros<float>(shape) is 27x slower than std::fill(), whereas I expected to see no difference. Here are the numbers for gcc-7:
(Edit: I added results for dynamic view, which are even worse - 54x slower.)
(Edit2: in releases 0.10 to 0.14, array = xt::zeros<float>(shape) was "only" 16x slower.)
----------------------------------------------------------------------
Benchmark                               Time           CPU Iterations
----------------------------------------------------------------------
init_memset<float>                  70685 ns      70658 ns       9878
xarray_init_std_fill<float>         67681 ns      67683 ns      10334
xarray_init_zeros<float>          1868781 ns    1866331 ns        372
dynamic_view_init_zeros<float>    3712534 ns    3712598 ns        188

Code:
(BTW, why is straightforward array = 0 not supported?)
    constexpr int SIZE = 1 << 20;

    template <class V>
    void init_memset(benchmark::State& state)
    {
        std::vector<V> array(SIZE);

        for (auto _ : state)
        {
            std::memset(array.data(), 0, SIZE*sizeof(V));
            benchmark::DoNotOptimize(array.data());
        }
    }
    BENCHMARK_TEMPLATE(init_memset, float);

    template <class V>
    void xarray_init_std_fill(benchmark::State& state)
    {
        auto array = xt::xarray<V>::from_shape({SIZE});

        for (auto _ : state)
        {
            std::fill(array.begin(), array.end(), V());
            benchmark::DoNotOptimize(array.raw_data());
        }
    }
    BENCHMARK_TEMPLATE(xarray_init_std_fill, float);

    template <class V>
    void xarray_init_zeros(benchmark::State& state)
    {
        auto array = xt::xarray<V>::from_shape({SIZE});

        for (auto _ : state)
        {
            array = xt::zeros<V>({SIZE});
            benchmark::DoNotOptimize(array.raw_data());
        }
    }
    BENCHMARK_TEMPLATE(xarray_init_zeros, float);

    template <class V>
    void dynamic_view_init_zeros(benchmark::State& state)
    {
        auto array = xt::xarray<V>::from_shape({SIZE});
        auto view  = xt::dynamic_view(data, xt::slice_vector{xt::all()});

        for (auto _ : state)
        {
            view = xt::zeros<V>({SIZE});
            benchmark::DoNotOptimize(array.raw_data());
        }
    }
    BENCHMARK_TEMPLATE(dynamic_view_init_zeros, float);

Hi,
Assigning to a container or a view after it has been initialized involves a temporary to avoid aliasing. Could you test with the noalias proxy:
    template <class V>
    void xarray_init_zeros(benchmark::State& state)
    {
        auto array = xt::xarray<V>::from_shape({SIZE});

        for (auto _ : state)
        {
            xt::noalias(array) = xt::zeros<V>({SIZE});
            benchmark::DoNotOptimize(array.raw_data());
        }
    }
    BENCHMARK_TEMPLATE(xarray_init_zeros, float);

    template <class V>
    void dynamic_view_init_zeros(benchmark::State& state)
    {
        auto array = xt::xarray<V>::from_shape({SIZE});
        auto view  = xt::dynamic_view(data, xt::slice_vector{xt::all()});

        for (auto _ : state)
        {
            xt::noalias(view) = xt::zeros<V>({SIZE});
            benchmark::DoNotOptimize(array.raw_data());
        }
    }
    BENCHMARK_TEMPLATE(dynamic_view_init_zeros, float);

Regarding the assignment  xarray = 0, scalar and 0-d expressions are considered as equivalent and handled the same way in xtensor. Thus, to be consistent, array = 0 should resize the array to a 0-d array an then assign it the value 0, which would be confusing.

noalias() indeed helps the dynamic view, so that it is only 27x slower. However, this is unsatisfactory for three reasons:

It is still too slow.
Since xt::zeros<V>({SIZE}) can never share data with any array, aliasing is impossible, and the library should be able to detect this without external help.
Even if aliasing is possible (as in the assignment view1 = view2), it can be easily ruled out in 80% of the cases by a simple check for overlapping address ranges in the LHS and RHS. I have used this technique in vigra for a long time and never encountered any problems. You really ought to improve this!

Thus, to be consistent, array = 0 should resize the array to a 0-d array an then assign it the value 0, which would be confusing.

To the contrary, I was shocked when I first learned that assignment of an xscalar resizes the LHS to 0-d. This behavior is counter-intuitive and useless in practice. As the Zen of Python puts it: "practicality beats purity".

Even if aliasing is possible (as in the assignment view1 = view2), it can be easily ruled out in 80% of the cases by a simple check for overlapping address ranges in the LHS and RHS. I have used this technique in vigra for a long time and never encountered any problems. You really ought to improve this!

In fact, the rhs can be a complicated expression involving views, concatenations, computations, views on combinations of those. The current mechanism is very general, and there is no systematic way of ruling out aliasing.
Even the lhs can have a "view semantics", which complicates the picture.
There are cases where we can probably rule out aliasing like when the rhs is a generator like zeros or linspace. (Although, when we move to strided random generators, it might be a more complicated question.)

To the contrary, I was shocked when I first learned that assignment of an xscalar resizes the LHS to 0-d. This behavior is counter-intuitive and useless in practice.

In extensor, xscalars are expressions of dimension zero, and assignment proceeds like for any expressions, and we are not making it a special case. Since you quote the Zen of Python:
Special cases aren't special enough to break the rules.
Now, the assignment behavior depends on what the lhs is. In the case where the lhs has a view semantics, the rhs is broadcasted to fill the content (including the case of the rhs being e.g. 1-D). In the case where the lhs has a container semantics, it is an assignment, just like for a numpy array.

You really ought to improve this!

The fact that assignment from a generator goes through the whole broadcasting logic (compared to a simple std::fill) still comes at a cost, but we can certainly improve this.

Thanks for the quick answer, I really appreciate this. I understand the logic behind your assignment semantics, but I'm sorry to say that I'm not convinced of the premises.
Vigra fundamentally rests on the assumption that algorithms cannot know (and should not care) if they are called with arrays or views. This is important because views are very common (for example, many algorithms are applied to each channel individually). This premise has two implications:

Arrays and views must have the same API (but arrays may offer additional functionality).
Operations on arrays and views should be equally fast.

In vigra, these requirements are fulfilled by construction, because arrays are implemented as subclasses of views. In contrast, xtensor fulfills neither, and this is a big problem for me. Do you have any suggestion how to resolve this dilemma?

There are cases where we can probably rule out aliasing like when the rhs is a generator like zeros or linspace.

Here is how I do it in vigra: all arrays, views, and expressions provide a function check_memory_overlap(void * begin, void * end) (expressions forward this call to their parts). This function is called at the beginning of an assignment with the memory bounds of the LHS. If the call returns false, no aliasing can occur and no temporary is needed. This is really easy to implement and covers 80% of the cases (after all, aliasing is rare). Why does this technique not work in xtensor?

Even if aliasing is possible (as in the assignment view1 = view2), it can be easily ruled out in 80% of the cases by a simple check for overlapping address ranges in the LHS and RHS. I have used this technique in vigra for a long time and never encountered any problems

The problem is the remaining 20%. You end up with a scheme where the user does not have a simple rule to determine whether he has to use noalias. When writing generic code that could work with any kind of expression, one would use noalias anyway to guarantee that no copy is made when the dynamic check is not able to determine whether overlap happens.

To the contrary, I was shocked when I first learned that assignment of an xscalar resizes the LHS to 0-d.

If assigning a 0d array / scalar to an array was broadcasting to the array instead of resizing it to a 0d array, the copy constructor and assignment operators would have different behaviors:
double s = 1.;
xt::xarray<double> a(s);
// a is a 0d array
xt::xarray<double> b = {{0., 1., 2.}, {3., 4., 5.}};
b = s;
// b is still a 2d array

And that is a really bug-prone behavior.

If assigning a 0d array / scalar to an array was broadcasting to the array instead of resizing it to a 0d array, the copy constructor and assignment operators would have different behaviors:

For that reason, vigra doesn't provide a constructor taking a scalar. The constructor's first argument is always the shape, or an array expression that provides a method shape(). Therefore
array_t<double> a(2.0);

is an error, whereas
array_t<double> a{2.0};

would invoke an initializer_list that creates an array of size 1 -- but this syntax cannot be confused with assignment.
For the record: anyone I asked wants the assignment a = 0; to zero out the array.

Like in numpy when lhs is a view, rhs is broadcasted to match the shape if possible

numpy:
>>> import numpy as np
>>> x = np.array([[[1, 2], [3, 4]], [[10, 20], [30, 40]]])
>>> x [:, :, 1] = [-1, -2]
>>> x

array([[[ 1, -1],
        [ 3, -2]],

       [[10, -1],
        [30, -2]]])

xtensor:
>>> auto x = xt::xarray<double> ({{{1, 2},{3, 4}},{{10, 20}, {30, 40}}});
>>> auto v = xt::view(x, xt::all(), xt::all(), 1);
>>> xt::xtensor<double, 1> t = {-1, -2};
>>> v = t;
>>> std::cout << x << std::endl;

{{{  1.,  -1.},
  {  3.,  -2.}},
 {{ 10.,  -1.},
  { 30.,  -2.}}}

When lhs is a container, assigning the an expression to the container will change the dimension of the container.

In all of xtensor, scalar are treated as 0-D expressions, and assignment is treated accordingly.

It would basically break xtensor's consistency to treat scalars differently for assignment, so I don't think that this can change.

For that reason, vigra doesn't provide a constructor taking a scalar.

With that solution, the inconsistency is now between scalars and 0-d expression:
xarray<double> a = {{0., 1., 2.}, {3., 4., 5.}};
xarray<double> b = a;
b = sum(a);
// => b is a 0d array
b = a;
double s = sum(a);
b = s;
// => b is still a 2d array

This is still bug-prone. This decision (i.e. broadcasting scalars as 0d expressions) has not been taken lightly, we want to ensure consistency between different ways of writing the "same" code and avoid vicious bugs when refactoring (i.e I want to cache the result of a 0d expression in a scalar because now it is used many times while before lazy computing was ok).
So this is something that we won't change. I'll add a paragraph explaining all of this in the documentation of xtensor.
However, we can think of a way to simplify the filling of an N-dimensional expression without resizing it:

provide a full function like numpy
see if user-defined literals can help, so we can have a syntax like:

xarray<double> a = {{0., 1., 2. }, {3., 4., 5.}};
a = 1_br;
// => a is a 2d array containing 1 everywhere

I implemented @JohanMabille's use case and printed the shapes:
xarray<double> a = {{0., 1., 2.}, {3., 4., 5.}};
xarray<double> b = a;
std::cerr << "shape before: (" << b.shape()[0] << ", " << b.shape()[1] <<
             ")\ncontents:\n" << b << "\n";
b = sum(a);
std::cerr << "shape after: (" << b.shape()[0] << ", " << b.shape()[1] <<
             ")\ncontents:\n" << b << "\n";

The output is
shape before: (2, 3)
contents:
{{ 0.,  1.,  2.},
 { 3.,  4.,  5.}}
shape after: (2, 3)
contents:
 15.

This looks like a bug to me.

Continuing on @JohanMabille's use case, when I use a view instead of an array
xarray<double> a = {{0., 1., 2.}, {3., 4., 5.}};
xarray<double> b = a;
auto c = view(b, all(), all());
std::cerr << "shape before: (" << c.shape()[0] << ", " << c.shape()[1] <<
             ")\ncontents:\n" << c << "\n";
c = sum(a);
std::cerr << "shape after: (" << c.shape()[0] << ", " << c.shape()[1] <<
             ")\ncontents:\n" << c << "\n";

I get (as expected)
shape before: (2, 3)
contents:
{{ 0.,  1.,  2.},
 { 3.,  4.,  5.}}
shape after: (2, 3)
contents:
{{ 15.,  15.,  15.},
 { 15.,  15.,  15.}}

but the behavior differs between arrays and views. I can absolutely not live with this inconsistency, because vigra's generic algorithms must work identically, regardless of their arguments being arrays or views.
I see only one (admittedly radical) solution: arrays adopt the assignment semantics of views, i.e. assignments cannot resize the LHS (with one exception: when the LHS does not yet contain data, e.g. after default construction).

but the behavior differs between arrays and views. I can absolutely not live with this inconsistency, because vigra's generic algorithms must work identically, regardless of their arguments being arrays or views.

Don't hold your breath though 😄 . Thanks for catching the bug on sum.
Regarding the different behavior on views and containers, we don't consider this as an inconsistency, and from the very start we have separated the two semantics (just like numpy).
One things you can probably do if you want a view semantics is take a view on an array with no slice. Soon(ish), strided views should have exactly the same performances as arrays.

One things you can probably do if you want a view semantics is take a view on an array with no slice.

That means, every algorithm must begin with
auto in_view = make_view(in);

etc. -- not a pretty design, and easy to forget.

This looks like a bug to me.
Edit: Presumably, it is not a bug, because b.shape() has size 0 after the assignment. Sorry for the mistake, but this is a trap many users will fall into.

Yeah, we were posting an answer and that. So no bug, phew.

we have separated the two semantics (just like numpy)

It is technically impossible in Python to assign a scalar to an array, because the expression array = 0 doesn't touch the array at all, but only changes the reference behind the identifier array. I therefore don't buy the analogy to numpy as a justification for your design decision allowing assignments to resize the LHS.
From the top of my head, I can't come up with other semantic differences between numpy's arrays and views. What differences are you referring to?

Containers should behave like std::vector. Assigning or moving a vector to another should result in a resized container.
Assigning or moving any expression to an array should behave like assigning an array to an array: it should resize. Otherwise it would be inconsistent.

I therefore don't buy the analogy to numpy as a justification for your design decision

That's because you're reading the arguments one by one instead of taking them as a whole thing. So to be clear:

in numpy, when assigning an array / numpy expression to a view, the right hand side is broadcasted to the shape of the view
=> The same happens in xtensor, so we're consistent with numpy behavior

in numpy, when assigning an array / numpy expression to an array, from a user point of view, it is as if the LHS had been resized to match the RHS shape (even if the technical details are quite different because it is python and yes I know that you get a new array under the hood, the reference points to this new array and the original array is not really resized but that does not matter here)
=> The same happens in xtensor, so we're consistent with numpy behavior. Besides we're consistent with STL's containers behavior.

in numpy, you cannot assign a scalar to a numpy array or to a numpy view
=> That's because it is python, however in C++ it it technically possible.

Then you have 3 means to handle that last point:

you forbid scalar assignment; that is too restrictive from our point of view
assigning a scalar broadcasts it to the lhs => this leads to inconsistency with 0-D expression assignment, I have given a example in one of my post above (and this will be soon in xtensor documentation)
assigning a scalar is handled like assigning a 0-D expression, and the system is consistent.

So the analogy with numpy justifies the broadcasting when assigning to a view while resizing when assigning to an array, consistency between scalars and 0-D expression justifies the way we handle scalar assignment.
Thus, as already said before, we won't change this behavior.
That being said, we can consider ways of simplifying the filling of a N-dimensional expression without resizing it:

fill free function
user-defined litteral
shift-equal operator, as suggested by @wolfv in #614

Then you have 3 means to handle that last point:

You forgot to mention the fourth possibility: Change arrays to adopt view semantics (i.e. scalars and 0-D expressions are always broadcast to the LHS), and the system is consistent.

Then you have 3 means to handle that last point:

You forgot to mention the fourth possibility: Change arrays to adopt view semantics (i.e. scalars and 0-D expressions are always broadcast to the LHS), and the system is consistent.

No, it breaks consistence with STL containers, as explained two comments above.

You want to be able to assign or move a container to another (like an STL vector), which should resize, even when the RHS is 0-D.

You want the behavior to be the same for any expression on the RHS.

When you work on speeding-up expressions on views, also include view creation itself, i.e. functions xt::view() and xt::dynamic_view(). I need view creation to be cheap as well (and looking at the code of xt::dynamic_view(), this might prove quite challenging).

You want to be able to assign or move a container to another

No, I don't want to do this:

I have no use case -- arrays don't change shape halfway through the algorithm.
One doesn't want memory management to happen inside loops. Thus, allocation is done before the loop with constructor calls.
I can't rely on the resizing capability, because the LHS could also be a view.
Consistency with STL containers is not important, because we are in an entirely different domain.
Should I be wrong, and resizing assignment is needed, it can still be achieved by the standard idiom xarray<double>(rhs).swap(lhs).

You want the behavior to be the same for any expression on the RHS.

I think this is not violated when arrays have view semantics.

You want to be able to assign or move a container to anotherNo, I don't want to do this:

No, I don't want to do this:

This was a generic "you". There are other users. If you want something like an array that has a view semantics, you can make one that is a valid expression for xtensor by inheriting from xview_semantics and xstrided_container. There are only a couple of constructor to implement.

Consistency with STL containers is not important, because we are in an entirely different domain.

We strongly disagree. This was a deliberate conscious choice.

This was a generic "you".

I repeatedly asked for uses cases from your side, but got none.

I think that we are in the land of sea-lioning here.

If you want something like an array that has a view semantics, you can make one that is a valid expression for xtensor by inheriting from xview_semantics and xstrided_container.

This looks like what I'll try next.

Another note on this issue: for #666 I was planning to overload assign for the special case of a RHS of a single reducer, and then reroute the reducer to use the faster, strided-loop reducers instead of the lazy ones.
Also, when we have implemented the strided loop variant of assign, broadcasts (and probably also broadcasts of scalars) should speed up quite a bit.

So I've added a benchmark for xt::zeros and assignment to a container is now as fast as using std::fill directly:
----------------------------------------------------------
Benchmark                   Time           CPU Iterations
----------------------------------------------------------
benchmark_arange        52827 ns      52004 ns      12112
benchmark_std_iota      10540 ns      10519 ns      50931
benchmark_ones          14028 ns      14005 ns      38908
benchmark_std_fill      14309 ns      14280 ns      38371

as you can see, on arange there is still some work outstanding. We'll spend some cycles to add assign_to to other expressions.


  You'd be better getting rid of it so nobody stumbles into it and gets the wrong idea.
There is no gitter and nobody from Piston ever hangs out on the #rust-gamedev IRC channel on Mozilla's network, so no newbies ever have a place to get first-hand help.  This is somewhat shameful for a major Rust project, given how many people have gone into various Rust IRC channel's and gotten fantastic help; that trains people to have high expectations.  The results of this is that newbies always wander into #rust-gamedev and ask for help and get told "don't use Piston because nobody there cares".
The Twitter is not terrible, I confess.

The forum is used by people for mostly offtopic discussion since the issue tracker is used for tracking stuff on projects. We will work on improving the help for new people, but the best way of getting it now is to open issues.
I don't usually hang out on #rust-gamedev because I already use too many forums and need to prioritize my attention on the right tasks. Please open issues.

Okay I'll just tell everyone with a Piston problem in #rust-gamedev to open an issue.

...though if the forum is off topic, then it shouldn't be listed as a place to start discussions. As it is, a new user (ie me, a year ago) will go to the forum, see nothing at all about Piston, Rust, or gamedev at all, and say "well I guess this project is irrelevant" and "this is the best the rust gamedev scene has to offer?"
It looks very unprofessional when a project's official forum has the last post about that project over a year ago.

It's a good idea to post more official posts on the forum. At the moment we are using the blog for this http://blog.piston.rs/.
I think we can open up individual issues for the relevant topics. So I will close this.


How to avoid MySQL "ER_LOCK_WAIT_TIMEOUT"

Hi iam trying update 10 rows and I get "ER_LOCK_WAIT_TIMEOUT". Please explain to me what is wrong with this piece of code
var promises = [];
// 2
for (var i=0; i < result.length; i++) {
            var a = cols.findWhere({ pa_allegro_uid : parseInt(result[i]) });
              if (a){
                  // 3
                  promises.push(a.query().update({ pa_is_photo: 0 }));
              }
};
// 3
return Promise.all(promises).then(function(){
                return thumbs;
});

Please format your code using the correct GitHub Flavored Markdown syntax in the future so we can read it.
Seems like this is a MySQL specific issue and so I can't really speak to what exactly might be causing it in your specific case. If you truly believe this is a universal issue, you'd have to create a repo that can reproduce the issue that we could git clone, npm install, and then npm test to cause the failure.
In this case you should be changing the logic here entirely so I don't think it matters all that much. Instead of writing 10 queries, and running them roughly in parallel, you should be building up 1 update + where in query using an array of the matched object ids.

Closing this for lack of activity. If you have any new data in regards to this issue you can leave a comment and we may reopen it.


Migrate SOFO Toolbox functionality

This is no longer directly feasible within a webpage as SOFO requests are multi-step forms