[BUG] Unable to have List of Pydantic Model as route 'responses' model

Describe the bug
When using responses={...: {"model": List[PydanticModel]}} in a route function there is an exception returned AssertionError: A response model must be a Pydantic model when attempting to run the application.
To Reproduce
from fastapi import FastAPI
from pydantic import BaseModel

class T(BaseModel):
    a: int

app = FastAPI()

@app.get("/", responses={200: {"model": List[T]}})
def index():
    ... # This is never entered due to error when adding the route

Expected behavior
This behaves the same as response_model= since it is allowed and works as intended there.
Environment:

OS: macOS
FastAPI Version [e.g. 0.3.0], get it with: fastapi==0.42.0
Python 3.7.0

Additional Context
I was going to return my response directly but would like the schema to be automatically done based on the pydantic model. I was following the steps in https://fastapi.tiangolo.com/tutorial/additional-responses/

Hi @nwalsh1995
On your code:

you should include response_model=T
you should not be using List as it's not a Pydantic model

@app.get("/", responses={200: {"model": List[T]}})
def index():
    ... # This is never entered due to error when adding the route

By reviewing documentation code (https://fastapi.tiangolo.com/tutorial/additional-responses/) I see that response_model attribute is used prior to every response model.
Instead, could you could try out:
@app.get("/", response_model=T, responses={200: {"model": T}})
def index():
    ... # This is never entered due to error when adding the route

Also from the documentation we can clearly see that each response shall include a Pydantic model.

Each of those response dicts can have a key model, containing a Pydantic model, just like response_model.

@nwalsh1995  I've updated my suggestion, please take another look if you've already read it. Thanks

@iamaldi But isn't that the wrong response? Why would you want to document it as returning a T instead of a List[T]?
If I understand correctly, this seems like a bug, but I think it shouldn't be too hard to fix.

Well, by writing response_model=List[T] you're basically saying that the response should be a list of T then inside the responses, each model is going to be of model T.
Could you ellaborate a bit more on why this seems like a bug? I read all the available documentation and saw response_model=List[T] as the only available option to do this.
Thanks

The "model" for the response should be the actual type returned for the response. response_model is basically a shorthand for what to use in the case where everything goes as planned, but, for example, if you wanted to return a list of errors in the case of a 400, you'd want to have responses={400: {"model": List[ErrorModel]}}.
It seems to me like you are concerned with the schema making sense as a human, but the point is for it to be correct if interpreted by a machine (e.g., for client generation).
I don't see any reason why this version:
@app.get("/", responses={200: {"model": List[T]}})
def index():
    ... # This is never entered due to error when adding the route

shouldn't result in the same openapi schema as this version:
@app.get("/", response_model=List[T])
def index():
    ... # This is never entered due to error when adding the route

My suspicion is that this is only broken right now because most people don't frequently use this capability. I don't see any reason an arbitrary pydantic field couldn't be supported here.

@dmontagu Now I can see what the issue was in the first place. I was initially confused and thought this was a implementation-specific issue @nwalsh1995 had.
Thanks for the clarification.

Yep. Response models in the extra responses should receive any type valid for a Pydantic field, not only Pydantic models. That's a valid bug/feature request.

This was fixed by @patrickmckenna in https://github.com/tiangolo/fastapi/pull/1017.
It will be available in the next release. :rocket: :tada:


Added scale w.r.t origin property

Added scale(issue #2693 ) with respect to origin property, similarly to how it was done in rotate. The set_scale method coresponds to compute method in rotate.

two files changed in one commit because if I did it in two there would have been a state in between where the code would be broken.

two files changed in one commit because if I did it in two there would have been a state in between where the code would be broken.

Looks good to me, thanks! I've also added a new example demonstrating this feature.

Sorry for  #3070, should have closed that one myself.


I see this error in dev tools

Welcome! Please use this template for reporting bugs or requesting features. For questions about using Workbox, the best place to ask is Stack Overflow, tagged with [workbox]: https://stackoverflow.com/questions/ask?tags=workbox
Library Affected:
workbox-sw
Browser & Platform:
Google Canary Version 88.0.4324.2 (Official Build) canary (64-bit)
Issue or Feature Request Description:
I see this error in dev tools

Uncaught (in promise) TypeError: Failed to execute 'put' on 'Cache': Request method 'POST' is unsupported
at Object.put (cacheWrapper.js:223)

When reporting bugs, please include relevant JavaScript Console logs and links to public URLs at which the issue could be reproduced.
Not sure, I'm currently using Workbox v5.1.4 via cdn.
Code line: https://storage.googleapis.com/workbox-cdn/releases/_private/cacheWrapper.js:223
Just thought I'd report it to let the admins know.

Here's answer from similar issue I found:

The underling Cache Storage API doesn't support using POST requests as the key when storing a response. This is not a limitation specific to Workbox.
In general, since POST requests are meant to mutate server-side state, caching them locally and replaying the response tends not to be a great idea.
You can either write something by hand to process the incoming POST request and convert it into a GET prior to storing it, or, better yet, work with the API you're using to ensure that they also support GET requests.

Originally posted by @jeffposnick in https://github.com/GoogleChrome/workbox/issues/1547#issuecomment-399507780
It appears that the Cache Storage API doesn't support any other request than get and this is explicitly said in specification:

If innerRequest’s url's scheme is not one of "http" and "https", or innerRequest’s method is not GET, return a promise rejected with a TypeError.

So this is not possible, unless you use @jeffposnick tips from the quoted reply to other issue.

Yes—this is expected if you're attempting to handle a POST request using a runtime strategy that involves writing to the cache.
It was unfortunately easy to inadvertently get into this situation when using setDefaultHandler(), because that handler would also be applied to POST requests. In Workbox v6, setDefaultHandler() will only apply to GET requests by default, and you have to explicitly opt-in to having it apply to other HTTP methods.

Thank you for your answers, look forward to upgrading to v6 in the near future.


9068 DEV Add migration to set isDeprecated to true for artifactory

https://github.com/Shippable/pm/issues/9068

This is complete and verified in rc.


Tyreid App for Bangle.js 2

Hello,
This is a Bluetooth war-driving app for the Bangle.js 2.
It passively logs bluetooth packets with the current time and GPS location.
Hopefully some people might find it useful/fun!
Regards,
Tom

Looks great - thanks! The pre-merge check is failing though because:

There's no ChangeLog - just copy one from the example app and make sure the last version listed is 0.02
There's no icon file - not sure if you still have the original, but it needs to be a png file (as well as the JS) and that needs referencing from the metadata's 'icon' field (not the .img)

If you wanted to be able to get the file off a bit more easily you can add an 'interface' file to the app loader. The tutorial here basically does exactly what you want - just copy/paste and change the filename: https://www.espruino.com/Bangle.js+Storage#reading-with-the-app-loader

Any chance of fixing what we'd asked, or shall I close this PR?

Hi,
Sorry Gordon, I haven't had a lot of time to work on this recently - but hopefully the required changes are there now.
In the future I would like to spend some time working on an interface file, and possibly some code to perform some analysis.
Also, thank you Rob for your suggestion; unfortunately I haven't had time to change and fully test your suggestion, but if I get some time in the future I will give it a go.
Thanks both,
Tom

No problem, thanks for those final changes! I tweaked metadata.json to bring it into line with your changelog :)


Min pokemon to trigger evolve

Add the config to set the minimum no. of pokemon to trigger evolve so that it can maximum the experience earned when using lucky egg.

👍


Issue about surface contact setting during double foot support periods

Hello, Dr. Gergondet (@gergondet),
I apologize for bothering you, but I am experiencing some issues with the controller on my robot. During double foot support periods, the robot loses contact with the floor, and its feet cross the ground. However, during the walking process, this problem disappears. The process unfolds as follows:
1.Initially, the robot is set at the proper height.

2.Upon clicking "Start" to enter the BWC::Main_ state, the ControlRobotModel moves down slowly due to gravity, causing its feet to cross the ground.

3.I set the walking parameters and click "walk," after which the ControlRobotModel quickly returns to its original height and walks normally.

4.Once the walking is finished, the robot's feet cross the ground again.

It seems that there is an issue with the contact setting during the double foot support periods. Could you please provide me with some advice on how to address this problem?
Thank you for your time and assistance.
Best regards,
Ethan

Hi @EthanZengg

Could you attach a video of the scene with the problem?
Could you tell us which command you ran to launch the controller (specifically choreonoid or mc_rtc_ticker)?

Could you try increasing the following parameters by 10 times?
https://github.com/isri-aist/BaselineWalkingController/blob/52da546486e528b79475c2f7bb364fb3a65b1a9c/etc/BaselineWalkingController.in.yaml#L190
I suspect that there is a large difference in the robot's total mass between the VRML model loaded in Chorenoid and the URDF model referenced in the controller.

it didn't solve the issue. Based on your description, it seems that your guess is correct. The simulation runs very slowly with the VRML.
A new video is as follow, the all-black model represents the RealRobot, while the translucent model represents the ControlRobot. Please note that the observation may be slightly challenging due to the absence of mesh files.
https://github.com/isri-aist/BaselineWalkingController/assets/73087353/84140f47-1461-4491-9b73-2ed955ce6745

Hello @EthanZengg
Are the force sensors of your robot connected to mc_openrtm?

Hello  Dr. Gergondet (@gergondet),
I have only attached the rfsensor and lfsensor to the robot, as it seems that the problem is not related to other sensors ( that's my guess). The attached pictures depict the robot's RTsystem configuration.

This configuration appears to be the cause of the problem. Could you please provide me with some advice on how to address it?

Indeed, the video looks like the robot's behavior when the force sensor value is zero all the time. Could you share the mc_rtc log (*.bin file in /tmp) to confirm this?
However, I do not know why the force sensor value is zero all the time. The RTC port connections above appear to be correct. Can you confirm that the force sensor values are correct on Choreonoid according to the following document?
https://choreonoid.org/en/documents/1.5/simulation/sensor-visualization.html

Thank you for your notification. I discovered that the orientation of the force sensor was incorrect, and I promptly corrected it. The subsequent images depict the body state view on Choreonoid and the mc_rtc log related to the RightFootForceSensor. It seems that the data is correct now after the correction. Nevertheless, the issue persists.

Thank you for your patient response. Could you please provide me with a few more hints?

Since the same sensor values are described in the Choreonoid and the mc_rtc log, the data port of the RTC is correctly connected. Would you be able to share the mc_rtc log in some way so that we can examine it more closely?

Thanks for the reply. The following two files are respectively  the latest mc_rtc log (*.bin file) and the corresponding video after correcting the orientation of the force sensor  . I hope this will be helpful
mc-control-BaselineWalkingController-2023-07-19-10-53-11.zip
https://github.com/isri-aist/BaselineWalkingController/assets/73087353/67f159ef-c972-4c19-9c0a-5a32473a3ea6

Large forces are recorded in FootTask_Left_measuredWrench_fx in the log, which means that the X-axis of the foot surface is in the vertical direction. BaselineWalkingController (and many other mc_rtc contrllers) assume that the normal direction of the surface is the Z axis. It is necessary to modify the RSDF file, etc. accordingly.

Dear mmurooka,
Thank you for your patient and helpful responses, which enabled me to successfully fix the bug! !
Best regards,
EthanZengg

@EthanZengg  Good! I would appreciate it if you could post a video of the robot walking.

Dear mmurooka,
It's my honor. However, The robot is currently facing challenges in keeping steady while walking due to other issues (I guess), such as format conversion problem about VRML by https://github.com/fkanehiro/simtrans   ) , Other Sensors addition(gsensor, gyrometer, etc.), The proper configuration of mc_rtc tasks, ect. I will resolve these issues one by one diligently.
Once again, sincerely  grateful for your generous sharing of numerous controllers, which greatly aided me when I first started working with biped robots.
Best regards,
EthanZengg

Hello,@mmurooka and @gergondet
I apologize for reaching out again, but I am encountering some new issues.
When I import my STL file into Blender, I notice that the coordinate system of the STL file does not align with the world coordinate system. This misalignment is illustrated in the attached figure. If I create the surface as shown in figure 2(Z-axis of surface ligns with Z-axis of stl) , it leads to the same issues I mentioned earlier. In this situation, The direction of the normal in RViz appears to be correct, but there are significant forces recorded in FootTask_Left_measuredWrench_fx.

When I modify the coordinate system of surface as shown in the following figure , I observe large forces recorded in fz in the log(This is what I expected). However, the surface shape and normal direction in RViz appear to be incorrect.

Could you please assist me in creating the correct RSDF file in this situation?

Force sensor measurements do not depend on mesh coordinates or RSDF, but only on the sensor coordinates defined in the robot module class.
example: https://github.com/jrl-umi3218/mc_rtc/blob/69397dc8f1494c49af9be0a2051e9dc20d74844d/src/mc_robots/jvrc1.cpp#L98
In the first case of your comment above, how about changing the orientation of the force sensor coordinates, e.g. sva::PTransformd(sva::RotX(0.5 * mc_rtc::constants::PI)) or sva::PTransformd(sva::RotY(0.5 * mc_rtc::constants::PI )) ?

Force sensor measurements do not depend on mesh coordinates or RSDF, but only on the sensor coordinates defined in the robot module class.

That's not exactly correct. The wrench in the graph is coming from a foot task so this is obtained via robot().frame().wrench() which is different from robot().forceSensor().wrench() in two ways.

robot().forceSensor().wrench() only depends on the information provided by the interface
robot().frame().wrench() depends on the transformation between the frame and the sensor (which is generally defined by the transformation between the sensor and its parent body and by the transformation between the frame and its parent body
Furthermore, if the sensor is calibrated there's another transformation involved (force sensor to "true" force sensor)

When we define a surface in an rsdf file, we specify a frame relative to its parent body so changing the rsdf will change the wrench you observe in the task.
Note: it is however correct that mesh coordinates have no effect at all.

In the first case of your comment above, how about changing the orientation of the force sensor coordinate

Given that it was working before, I'm guessing there was a recent change in the simulation model that was not reflected on mc_rtc side. Possibly the force sensor was rotate in the model used by Choreonoid but not by mc_rtc

Thank you for all your suggestions; they have proven to be immensely helpful to me.
1.In the first case ,  I adjusted the sensor orientation along the y-axis by -90 degrees:
 _forceSensors.push_back(mc_rbdyn::ForceSensor("RightFootForceSensor", "right_leg_l6",sva::PTransformd(sva::RotY(-0.5 * mc_rtc::constants::PI))));,While the data ( /real/force/FootForceSensor published in the ros and FootTask_Left_measuredWrench in the log ) appears to be correct, the lingering issue persists. During the double support period, the controlled robot's feet still intersect with the ground, resulting in pronounced instability and shaking.

https://github.com/isri-aist/BaselineWalkingController/assets/73087353/1686ae08-2320-43f5-aa2a-7644cc949652
2.The  latest series of experiments was actually conducted using Webots, with communication established between Webots and mc_rtc through the ROS environment. I manually incorporated input data from the IMU and force sensors into the mc_rtc_ros_control package, drawing inspiration from the approach utilized in mc_openrtm. I apologize for any confusion caused by my earlier lack of clarity.

@gergondet, thanks for the correction, that's right!


decoder: Try to provide more explicit error context on invalid data

Please see details in the commit itself.

Thanks for applying.

Thanks. I filed #30 to track the crashers you reported. I think I fixed the one in loadString already but it seems the others are a bit more tricky and I need to go to bed :)


options.hash still adds hash to images

options.production.hash still adds hash to images
so specify in doc that it removes the hash only for js and css
or fix it so it remove the hash in images too
(talking about the loader for: ico|jpg|png|gif|eot|otf|webp|svg|ttf|woff|woff2 )

fixed, now it removes hash for images too.


torch.compile parameters are missing in Accelerator.prepare_model

System Info
- `Accelerate` version: 0.22.0.dev0
- Platform: Linux-3.10.0-957.el7.x86_64-x86_64-with-glibc2.17
- Python version: 3.9.17
- Numpy version: 1.25.1
- PyTorch version (GPU?): 2.0.1+cu117 (True)
- PyTorch XPU available: False
- PyTorch NPU available: False
- System RAM: 376.40 GB
- GPU type: Tesla V100-SXM2-32GB
- `Accelerate` default config:
        Not found

Information

[ ] The official example scripts
[X] My own modified scripts

Tasks

[ ] One of the scripts in the examples/ folder of Accelerate or an officially supported no_trainer script in the examples folder of the transformers repo (such as run_no_trainer_glue.py)
[X] My own task or dataset (give details below)

Reproduction
It happens when I want set torch_compile_backend='nvfuser' in transformers code link
To simplify this problem, I use the following scripts:
import os
from accelerate.utils import TorchDynamoPlugin

prefix = "ACCELERATE_DYNAMO_"
os.environ[prefix + "BACKEND"] = "nvfuser"
os.environ[prefix + "MODE"] = "reduce-overhead"

dynamo_plugin_kwargs = TorchDynamoPlugin().to_kwargs()
print(f"dynamo_plugin_kwargs: {dynamo_plugin_kwargs}")

Expected behavior
I expect console to prints:
dynamo_plugin_kwargs: {'backend': 'nvfuser', 'mode': 'reduce-overhead'}

instead, it prints
dynamo_plugin_kwargs: {}

I submit a PR to fix it:  #1738

Close this issue as #1738 is merged into main.


Update README.md

Add CryptoHeroes (Hero Tavern), a Simulation game

@Hero-Tavern  Thanks for the update. All the best with Hero Tavern (CryptoHeroes). Cheers.


[USM] tests https prefetch lib.so

What does this PR do?
Fix bug prefetch bug introduce by a previous PR
As we relay only by checking the pid (we don't scan ourself)
Motivation

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

Reviewer's Checklist

[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] Changed code has automated tests for its functionality.
[ ] Adequate QA/testing plan information is provided if the qa/skip-qa label is not applied.
[ ] At least one team/.. label has been applied, indicating the team(s) that should QA this change.
[ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
[ ] If applicable, the need-change/operator and need-change/helm labels have been applied.
[ ] If applicable, the k8s/<min-version> label, indicating the lowest Kubernetes version compatible with this feature.
[ ] If applicable, the config template has been updated.

Addressed @hmahmood comments as this PR is urgent


PR adding our API docs in the OpenAPI spec to our docs

Before this can get merged:

[x] Merge https://github.com/stellar/stellar-docs/pull/9 into main
[ ] Complete new API docs
[ ] Switch all the ops mumbo jumbo over to a singular deploy for both /docs and /api again
[ ] Update nginx stuff for a root / domain

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com/docs

Something went wrong with PR preview build please check

Something went wrong with PR preview build please check

Something went wrong with PR preview build please check

Something went wrong with PR preview build please check

Something went wrong with PR preview build please check

Something went wrong with PR preview build please check

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com/docs

Something went wrong with PR preview build please check

Something went wrong with PR preview build please check

Something went wrong with PR preview build please check

Something went wrong with PR preview build please check

Something went wrong with PR preview build please check

Something went wrong with PR preview build please check

Something went wrong with PR preview build please check

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com/docs

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com/docs

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com/docs

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com/docs

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com/docs

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com/docs

Something went wrong with PR preview build please check

Something went wrong with PR preview build please check

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com/docs

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com/docs

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com/docs

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com/docs

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com/docs

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com/docs

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com/docs

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com/docs

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com/docs

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com/docs

Something went wrong with PR preview build please check

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com

Something went wrong with PR preview build please check

Something went wrong with PR preview build please check

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com

Preview is available here:http://developers-pr23.previews.kube001.services.stellar-ops.com


🐼 Drop pandas table margin to get consistent with default zero margin thebe-output block

Currently, table element margin is decided by typography.css:
https://github.com/executablebooks/myst-theme/blob/6404d386efb39b7f8024813f2000a816974f1f7a/styles/typography.css#L46
Since apply on prose, it will have mt-5 style:
https://github.com/executablebooks/myst-theme/blob/6404d386efb39b7f8024813f2000a816974f1f7a/styles/typography.css#L20
However, since DataFrame, which appear in the thebe-output, is also a table element, the margin is inconsistent with default thebe-output block, having zero margin, like the numpy output in the following example:

It would be better if we align the m-0 behavior:

Thank you! 🚀 🐼


Clarify where code lives for certain branches

Since things have moved around a lot between Juno and Kilo, it's worth
documenting where stuff lives, so we're not all having to remember it.
Fixes: #206

Backport, LGTM.

:+1: from me, this is a backport of my change.


[Java] ListViewVector Implementation

Describe the enhancement requested
Arrow Format includes ListViewVector and this has been implemented in other language bindings, and Java also needs this specification.
Component(s)
Java

Issue resolved by pull request 41285
https://github.com/apache/arrow/pull/41285


firefox (current=86) is not vulnerable anymore

both with/without privacy mode, should be fixed on Firefox already.
https://blog.mozilla.org/security/2021/01/26/supercookie-protections/

Latest version of FF (86.0) is still vulnerable.

In the case of Firefox’s image cache, a tracker can create a supercookie by "encoding" an identifier for the user in a cached image on one website, and then “retrieving” that identifier on a different website by embedding the same image. To prevent this possibility, Firefox 85 uses a different image cache for every website a user visits.

This fix just prevents cross-site-tracking between websites but "supercookie" on the same site is still a thing!


return bundle for external reference

Why added this feature?
No description is given.

I am using let neobundle = neobundle#config#external_bundle(name) to get the actual neobundle.path. So far, the only use for me is that in some cases, the ftplugin folder is not sourced while using on-demand plugin activation. I need the path to do it manually.

OK. I pulled it.


refactor(batch): Use futures-async-stream to implement GenericExchange executor

What's changed and what's your intention?
Implement GenericExchange using the Executor2 trait.
Please explain IN DETAIL what the changes are in this PR and why they are needed:

Summarize your change (mandatory)
How does this PR work? Need a brief introduction for the changed logic (optional)
Describe clearly one logical change and avoid lazy messages (optional)
Describe any limitations of the current code (optional)

Checklist

[x] I have written necessary docs and comments
[x] I have added necessary unit tests and integration tests

Refer to a related PR or issue link (optional)
close https://github.com/singularity-data/risingwave/issues/1935

Thanks for your contribution. Forked in #2134


More shapes update

Modified the Babble app and the config file to work with the new shapes. Also moved all of the datagen stuff into a separate branch.

SHAAAPPPPEEESSSS


How to load encoder

Hi, I am getting the following traceback. Can you please help me with what went wrong here?

  File "/betterapp.ai/clustering/trainer/quaterion/serving.py", line 4, in get_model
    model = SimilarityModel.load(path)
  File "/usr/local/lib/python3.10/dist-packages/quaterion_models/model.py", line 232, in load
    encoder_class = restore_class(encoder_params)
  File "/usr/local/lib/python3.10/dist-packages/quaterion_models/utils/classes.py", line 28, in restore_class
    module = importlib.import_module(module)
  File "/usr/lib/python3.10/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1004, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'encoders'

Hi @nizamsp thanks for reaching out!
How are encoders.py and serving.py files located in your project? Is the former importable during the inference?

I had it initially with a full path in import like the following
from clustering.trainer.quaterion.encoders import BetterAppEncoder
I changed it to current path based import like the following and it worked!
from .encoders import BetterAppEncoder
Thank you so much for the quick reply! I hope my fix is correct.

Glad to hear that your problem is solved. It's always advisable to have a proper module structure. We're considering a CLI utility that can also create a project template, among other things. Then it'll be easier to manage Quaterion projects.


⚠ SolarOscp has degraded performance

In 5271075, SolarOscp ($SOLAROSCP_URL) experienced degraded performance:

HTTP code: 200
Response time: 177 ms

Resolved: SolarOscp performance has improved in 6b3b458.


Update relative representation

👷 Deploy Preview for gladia processing.

Name
Link

🔨 Latest commit
6dd85a5cad84c38883d13dbe967c0e188ebe4025

🔍 Latest deploy log
https://app.netlify.com/sites/gladia/deploys/63e4b47128eb7b000868526d


Added quantization to LCM notebook

Add post-training optimization support by NNCF for UNet model from 263-latent-consistency-models-image-generation.ipynb
Pipeline performance speed up: 1.307

@MaximProshin, @eaidova, @nikita-savelyevv please take a look

I use 10 samples. 128 data files relates to internal dataset files.

View entire conversation on ReviewNB

Added

View entire conversation on ReviewNB

I use default nncf version from https://github.com/openvinotoolkit/openvino_notebooks/blob/main/requirements.txt#L4

View entire conversation on ReviewNB

I use default nncf version from https://github.com/openvinotoolkit/openvino_notebooks/blob/main/requirements.txt#L4
View entire conversation on ReviewNB

Please see https://github.com/openvinotoolkit/openvino_notebooks/pull/1363#discussion_r1356490623

Added

View entire conversation on ReviewNB

Added comparison

View entire conversation on ReviewNB

the size argument is never used.

View entire conversation on ReviewNB

Added

View entire conversation on ReviewNB

thanks! Removed size

View entire conversation on ReviewNB


User Profile , Sign in page

we can add user profile
We can add login / sign in page so that we can track all user data regarding labs , courses and other activity
that he/she do in our webpage.

@prvn-kumar01 this issue was created before and worked already on it., so i am closing this issue.


Multiple filter test in elephant

We want to have port the Multiple FIlter Test for rate change-point detection in Elephant

Done: https://github.com/NeuralEnsemble/elephant/pull/142


Add TLS 1.3 support

There are no open-source Java library that supports TLS-1.3 at the moment. It would a cool thing if you could update this wrapper to back tls-1.3 version as it is supported by openssl now.

@nimatrueway, that is not true anymore. There is https://github.com/openjsse/openjsse.


default keymaps not working correctly

I have an issue where default keymaps don't (all) work.
For example, gd to jump to definition does not work. On the other hand, K to open diagnostic hover window works.
If I add an extra keymap for gd which does exactly what the default keymap would do, it also works.
 I use a bunch of different plugins, but none overrides gd in particular (which-key also doesn't show that gd is a viable option).
return {
	'VonHeikemen/lsp-zero.nvim', bracnh = 'v3.x',
	dependencies = {
		-- mason for installation of LSPs from within nvim
		{'williamboman/mason.nvim'},
		{'williamboman/mason-lspconfig.nvim'},
		-- actual dependencies
		{'neovim/nvim-lspconfig'},
		{'hrsh7th/cmp-nvim-lsp'},
		-- nvim-cmp as the auto-completeion feature
		{'hrsh7th/nvim-cmp'},
		{'L3MON4D3/LuaSnip'},
	},

	-- do some default setup
	config = function()
		-- setup lsp for files for which you have an LSP
		require('lsp-zero').setup()
		local lsp_zero = require('lsp-zero')
		-- lsp-zero and whichkey don't play nice together,
		-- see https://github.com/VonHeikemen/lsp-zero.nvim/issues/155#issuecomment-1428964266
		-- the following line should fix the keymap
		lsp_zero.preset({
			name = 'recommended',
			set_lsp_keymaps = {preserve_mappings = false}
		})
		require('lspconfig').intelephense.setup({})
		lsp_zero.setup()

		lsp_zero.on_attach(function(client, bufnr)
		-- see :help lsp-zero-keybindings
		-- to learn the available actions
			lsp_zero.default_keymaps({buffer = bufnr})
		end)

		-- default keymap for opening float is K.
		-- default keymap for going to definition (gd)
		-- or going to declaration (gD) don't work :(
		-- go to next / previous diagnostic. important especially,
		-- if multiple diagnostics appear on one line
		vim.keymap.set('n', '<leader>.',
			function()
				vim.diagnostic.goto_next()
			end, { desc = "Go to next diagnostic"})
		vim.keymap.set('n', '<leader>,',
			function()
				vim.diagnostic.goto_prev()
			end, { desc = "Go toprevious diagnostic"})

		-- setup mason for lsp installation from within nvim
		require('mason').setup({})
		require('mason-lspconfig').setup({
			ensure_installed = {
				"clangd", "cmake",
				"lua_ls",
				"pylsp",
				"rust_analyzer",
			},
			handlers = {
				lsp_zero.default_setup,
			},
		})

		-- 'vim' is global, but LSP doesn't know about it yet.
		require('lspconfig').lua_ls.setup({
			settings = {
				Lua = {
					diagnostics = {
						globals = {
							'vim',
						}
					}
				}
			}
		})

		-- additionally setup the "ensure_installed" languages
		require('lspconfig').clangd.setup({})
		require('lspconfig').cmake.setup({})
		require('lspconfig').pylsp.setup({})
		require('lspconfig').rust_analyzer.setup({})
	end,
}

I assume that there's something wrong with my config function here, but for the life of me I cannot figure it out.
Just in case, here is the entire config: https://github.com/lobneroO/nvim_conf

Okay, I just saw the forcing of the keymappings with preserve_mappings = false int he default_keymapssection. That works. I assume that means something overrides the keymaps, but since there is no keymap for gd, I don't see how/where...

which-key overrides the keymaps that start with g and z. That's how it provides the description for Neovim built-in keybindings.

I see, thank you. I thought I read in the docs that the preset thing was meant to mitigate that, but that seems to be wrong then.


Linking issue

I am now running a site called ezsh.xyz
When I run hugo everything that needs to be in my public folder is there, but some of the links are incorrect.
links such as /post/gettingstarted/ end up in the html as /ezsh.xyz/post/gettingstarted/.
Any idea why this might be ?

Could you produce a source code example? The .md file in post dir and generated html.
The URL generation was followed by https://gohugo.io/content-management/urls/#permalinks.

+++
title = "Getting Started with Hugo Part 2"
description = ""
tags = [
    "go",
    "golang",
    "hugo",
    "development",
]
date = "2014-04-02"
categories = [
    "Development",
    "golang",
]
menu = "main"
+++

## Step 1. Install Hugo

Goto [hugo releases](https://github.com/spf13/hugo/releases) and download the
appropriate version for your os and architecture.

Save it somewhere specific as we will be using it in the next step.

More complete instructions are available at [installing hugo](/overview/installing/)

## Step 2. Build the Docs

Hugo has its own example site which happens to also be the documentation site
you are reading right now.

Follow the following steps:

 1. Clone the [hugo repository](http://github.com/spf13/hugo)
 2. Go into the repo
 3. Run hugo in server mode and build the docs
 4. Open your browser to http://localhost:1313

Corresponding pseudo commands:

    git clone https://github.com/spf13/hugo
    cd hugo
    /path/to/where/you/installed/hugo server --source=./docs
    > 29 pages created
    > 0 tags index created
    > in 27 ms
    > Web Server is available at http://localhost:1313
    > Press ctrl+c to stop

Once you've gotten here, follow along the rest of this page on your local build.

## Step 3. Change the docs site

Stop the Hugo process by hitting ctrl+c.

Now we are going to run hugo again, but this time with hugo in watch mode.

    /path/to/hugo/from/step/1/hugo server --source=./docs --watch
    > 29 pages created
    > 0 tags index created
    > in 27 ms
    > Web Server is available at http://localhost:1313
    > Watching for changes in /Users/spf13/Code/hugo/docs/content
    > Press ctrl+c to stop

Open your [favorite editor](http://vim.spf13.com) and change one of the source
content pages. How about changing this very file to *fix the typo*. How about changing this very file to *fix the typo*.

Content files are found in `docs/content/`. Unless otherwise specified, files
are located at the same relative location as the url, in our case
`docs/content/overview/quickstart.md`.

Change and save this file.. Notice what happened in your terminal.

    > Change detected, rebuilding site

    > 29 pages created
    > 0 tags index created
    > in 26 ms

Refresh the browser and observe that the typo is now fixed.

Notice how quick that was. Try to refresh the site before it's finished building.. I double dare you.
Having nearly instant feedback enables you to have your creativity flow without waiting for long builds.

## Step 4. Have fun

The best way to learn something is to play with it.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354

<!DOCTYPE html>

  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta http-equiv="X-UA-Compatible" content="ie=edge">
  <title>ezsh Project Blog</title>

  <meta name="author" content="ezsh" />
  <meta name="description" content="Step 1. Install Hugo Goto hugo releases and download the appropriate version for your os and architecture.
Save it somewhere specific as we will be using it in the next step.
More complete instructions are available at installing hugo
Step 2. Build the Docs Hugo has its own example site which happens to also be the documentation site you are reading right now.
Follow the following steps:
 Clone the hugo repository Go into the repo Run hugo in server mode and build the docs Open your browser to http://localhost:1313  Corresponding pseudo commands:" />

<meta name="generator" content="Hugo 0.50" />

<link rel="canonical" href="ezsh.xyz/post/gettingstarted/" />
<link rel="alternative" href="/ezsh.xyz/index.xml" title="ezsh Project Blog" type="application/atom+xml" />

<link href="https://cdn.bootcss.com/semantic-ui/2.2.14/semantic.min.css" rel="stylesheet" />
<link rel="stylesheet" href="/css/site.css" />

          Getting Started with Hugo Part 2

@ ezsh · Apr 2, 2014 · 2 min read · Update at Apr 2, 2014

Step 1. Install Hugo

Goto hugo releases and download the
appropriate version for your os and architecture.

Save it somewhere specific as we will be using it in the next step.

More complete instructions are available at installing hugo

Step 2. Build the Docs

Hugo has its own example site which happens to also be the documentation site
you are reading right now.

Follow the following steps:

Clone the hugo repository

Go into the repo

Run hugo in server mode and build the docs

Open your browser to http://localhost:1313

Corresponding pseudo commands:

git clone https://github.com/spf13/hugo
cd hugo
/path/to/where/you/installed/hugo server --source=./docs
> 29 pages created
> 0 tags index created
> in 27 ms
> Web Server is available at http://localhost:1313
> Press ctrl+c to stop

Once you’ve gotten here, follow along the rest of this page on your local build.

Step 3. Change the docs site

Stop the Hugo process by hitting ctrl+c.

Now we are going to run hugo again, but this time with hugo in watch mode.

/path/to/hugo/from/step/1/hugo server --source=./docs --watch
> 29 pages created
> 0 tags index created
> in 27 ms
> Web Server is available at http://localhost:1313
> Watching for changes in /Users/spf13/Code/hugo/docs/content
> Press ctrl+c to stop

Open your favorite editor and change one of the source
content pages. How about changing this very file to fix the typo. How about changing this very file to fix the typo.

Content files are found in docs/content/. Unless otherwise specified, files
are located at the same relative location as the url, in our case
docs/content/overview/quickstart.md.

Change and save this file.. Notice what happened in your terminal.

> Change detected, rebuilding site

> 29 pages created
> 0 tags index created
> in 26 ms

Refresh the browser and observe that the typo is now fixed.

Notice how quick that was. Try to refresh the site before it’s finished building.. I double dare you.
Having nearly instant feedback enables you to have your creativity flow without waiting for long builds.

Step 4. Have fun

The best way to learn something is to play with it.

      go

      golang

      hugo

      development

ezsh's blog
Making the command line a friendlier place.

  development

  go

  golang

  hugo

      development

          Getting Started with Hugo

          Getting Started with Hugo Part 2

      golang

          Getting Started with Hugo

          Getting Started with Hugo Part 2

© 2018 ezsh Project Blog

Powered by Hugo with theme Dream.

    <a<EMAIL_ADDRESS>

          About ezsh

Welcome to ezsh!

ezsh (pronounced EasyShell) is to be user-friendly, and interactive shell designed to concretise a beginner’s view of the terminal and usage of the command line.

The inspiration for this project comes from extracurricular activities both of us have taken on outside of our academic studies.

Over the years, both of us have been involved in tutoring secondary school students of all ages, from 12 right up to 18 when they come to university. This happened through our involvement in both CoderDojo in our local areas & ComputeTY. Pretty much anything you lay down for them, be it Python or Java for example, they would pick it up and run with it.

I think this problem is baseUrl in your config file, like named config.toml.
Change it to baseURL = "http://ezsh.xyz" and see what's next.

adding http:// to the baseURL seems to have helped! Closing now, thanks a million.


Test

Type: Incorrect
Summary:
Test
Details:
Test
Resolution:
Test
Affected definitions:

mocha 5.0.1

You can review the change introduced to the full definition at ClearlyDefined.


Unreal Engine 4 platform support

Describe the solution you'd like
All AppCenter features available for Unreal Engine 4 games.
Describe alternatives you've considered
Currently there is no cloud build & test services for UE4 applications, but SDK features like analytics, crashes, etc. are widely provided by alternatives like Google Firebase (Crashlytics). For CI it's easy to use Bamboo/Teamcity/Jenkins, but its not "all in one" solution which AppCenter could be.
Additional context
I'm experienced UE4 developer with love to open source solutions and I'll be happy to collaborate on integration features like this. Also, I've created UE4 integration SDK for IOS/Android platforms, here it is: https://github.com/PushkinStudio/AppCenter-SDK-UE4 (MIT license). It has Analytics and Crashes modules implemented for now (we're using them in own projects, so it's a first priority), and Distribute and Push modules are on the way.

Hi @ufna,
Unreal support is on my radar, something I hope we can get to at some point. All a matter of customer interest and priorities. This would likely get grouped with general C++ support.
Could you drop me an email? It would be great to learn more about what you are doing now with App Center.

Hi @jwhiteDev ,
Sure, sent you one :)

Hey there, The appcenter support folks directed me here - I'd like to throw my hat in for this one too.

I was directed here as well. Very much looking for an "Unreal Engine" plugin to facilitate rapid integration for testing.

Definitely interested in Unreal Engine 4 support. We currently use HockeyApp to capture crashes on Windows game clients and even our Linux game servers, both using Unreal Engine 4. We will unfortunately not be able to stay with App Center without this support.

This worked ( once I figured it out a bit )
https://github.com/PushkinStudio/AppCenter-SDK-UE4

@DJLennon could you share a bit more how you are using HockeyApp to capture crashes on windows and Linux games with UE4? I am interested to learn your setup and how you are accomplishing this today.
I am also looking into possibilities of leveraging our NDK support with regards to Unreal on Android right now as well.

@jwhiteDev ,
What's the issue with NDK on Android? The most annoying part for me was breakpad compilation, but after that all works as it should.

No issues, it was more the thought that because of our existing NDK support there may already be some built in support for Unreal with C++, or at least some preliminary support. Just needs to vetting & exploration

Oh, got it. Great to hear that.

@DJLennon could you share a bit more how you are using HockeyApp to capture crashes on windows and Linux games with UE4? I am interested to learn your setup and how you are accomplishing this today.

We currently use HockeyApp as mostly a way to store and manage the custom crashes we have. We built a crash processor server that receives new minidumps, and symbolicates them by grabbing the right pdb/exes if needed, and calling cdb to get the right stack trace, in case this is a Windows crash; For Linux crashes, we use objdump's output to find the correct unmangled symbols, from Unreal's builtin stack walker.
We then upload the crash to HockeyApp using the custom crash API. So if AppCenter supports a custom crash API like HockeyApp does, we should be able to use it just fine!

It would be great to have official HockeyApp support for UE4 as a plugin. I haven't tried fred-king's plugin ( https://github.com/microsoft/appcenter/issues/294#issuecomment-498359687 ) but that sounds promising.

@ecosky , we're using it in few mobile projects and it works) Not all features yet, cause I've implemented only what is necessary for us. F.e. this plugin used in AW: Assault

@ufna Sounds promising! I'm actually interested in Windows support however. After posting this I discovered App Center is replacing Hockey App pretty soon. Hoping they add Windows+Unreal support to it (they appear to support Unity right now which is encouraging).

@ufna I see your plugin has Analytics (basic integration and events tracking)
Can this be used to track performance metrics. Would this scale ? Something similar to firebase performance monitoring. https://firebase.google.com/docs/perf-mon. Looking to see if we can add traces.

1++ Yes please, this would be amazing.

1++, UE4 should be supported.
Just merge in the great work by @ufna

@maestersid had commented nearly a year ago that UE4 support is on his radar. One year is more than enough time and UE4 is popular enough platform to warrant that.
So, why there is no support for UE4 in AppCenter still? Are we all just going to use @ufna plugin? Which is a great product, considering the alternatives especially!

Being candid, this is still something I would love to see done, but there are a lot of things we would like to do with App Center. Right now adding any native C++ support, let alone Unreal Engine, is unfortunately not something on the roadmap at this time. Unfa's work is a great avenue for the time being, but please keep making your interest known!

Being candid, this is still something I would love to see done, but there are a lot of things we would like to do with App Center. Right now adding any native C++ support, let alone Unreal Engine, is unfortunately not something on the roadmap at this time. Unfa's work is a great avenue for the time being, but please keep making your interest known!

So, there is no way to have Unreal app on AppCenter then? Even for a distribution, not for full service?

You can use Distribution with Unreal, I would look at creating an app with a "custom" OS version.


Support for package-private jsonAdapter method

auto-value-moshi requires a method like this:
public static JsonAdapter<MyAutoValueClass> jsonAdapter(Moshi moshi) { ... }

Are you open to a PR which would allow this?
static JsonAdapter<MyAutoValueClass> jsonAdapter(Moshi moshi) { ... }

With Java 9 modularity coming, I'd like the option to use Moshi as an implementation detail which is invisible to client code.

That would require all your model objects be in the same package. Is that
ok? Compilation would fail otherwise, which seems like reasonable behavior.
On Sat, Mar 11, 2017, 3:03 AM Ned Twigg<EMAIL_ADDRESS>wrote:

auto-value-moshi requires a method like this:
public static JsonAdapter jsonAdapter(Moshi moshi) { ... }
Are you open to a PR which would allow this?
static JsonAdapter jsonAdapter(Moshi moshi) { ... }
With Java 9 modularity coming, I'd like the option to use Moshi as an
implementation detail which is invisible to client code.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rharter/auto-value-moshi/issues/87, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AAEEEVEDY6C-hZIvAg7pEG5YZGz-Cv6Xks5rklVugaJpZM4MaI1N
.

That's only the case if you're using the MoshiAdapterFactory, right?  If
accessing the adapters manually or another way then they could be in
different packages.
On Sat, Mar 11, 2017, 6:06 AM Jake Wharton<EMAIL_ADDRESS>wrote:

That would require all your model objects be in the same package. Is that
ok? Compilation would fail otherwise, which seems like reasonable behavior.
On Sat, Mar 11, 2017, 3:03 AM Ned Twigg<EMAIL_ADDRESS>wrote:

auto-value-moshi requires a method like this:
public static JsonAdapter jsonAdapter(Moshi moshi) {
... }
Are you open to a PR which would allow this?
static JsonAdapter jsonAdapter(Moshi moshi) { ... }
With Java 9 modularity coming, I'd like the option to use Moshi as an
implementation detail which is invisible to client code.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rharter/auto-value-moshi/issues/87, or mute the
thread
<
https://github.com/notifications/unsubscribe-auth/AAEEEVEDY6C-hZIvAg7pEG5YZGz-Cv6Xks5rklVugaJpZM4MaI1N
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rharter/auto-value-moshi/issues/87#issuecomment-285862721,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPJbi1rqZSVmpFaHp3EQYeNa2y2rnNFks5rko5AgaJpZM4MaI1N
.

Yeah. I was thinking about models that referenced other models in other
packages specifically.
I still think it's reasonable to allow.
On Sat, Mar 11, 2017, 8:13 AM Ryan Harter<EMAIL_ADDRESS>wrote:

That's only the case if you're using the MoshiAdapterFactory, right? If
accessing the adapters manually or another way then they could be in
different packages.
On Sat, Mar 11, 2017, 6:06 AM Jake Wharton<EMAIL_ADDRESS>wrote:

That would require all your model objects be in the same package. Is that
ok? Compilation would fail otherwise, which seems like reasonable
behavior.
On Sat, Mar 11, 2017, 3:03 AM Ned Twigg<EMAIL_ADDRESS>wrote:

auto-value-moshi requires a method like this:
public static JsonAdapter jsonAdapter(Moshi moshi) {
... }
Are you open to a PR which would allow this?
static JsonAdapter jsonAdapter(Moshi moshi) { ... }
With Java 9 modularity coming, I'd like the option to use Moshi as an
implementation detail which is invisible to client code.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rharter/auto-value-moshi/issues/87, or mute the
thread
<

https://github.com/notifications/unsubscribe-auth/AAEEEVEDY6C-hZIvAg7pEG5YZGz-Cv6Xks5rklVugaJpZM4MaI1N

.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<
https://github.com/rharter/auto-value-moshi/issues/87#issuecomment-285862721
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ABPJbi1rqZSVmpFaHp3EQYeNa2y2rnNFks5rko5AgaJpZM4MaI1N
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/rharter/auto-value-moshi/issues/87#issuecomment-285865892,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEEZsd3MI6WUgbeHGMo5KvWMldZqsyks5rkp4OgaJpZM4MaI1N
.

I agree, seems like a simple enough option that doesn't hinder any current
functionality.
On Sat, Mar 11, 2017 at 7:44 AM Jake Wharton<EMAIL_ADDRESS>wrote:

Yeah. I was thinking about models that referenced other models in other
packages specifically.
I still think it's reasonable to allow.
On Sat, Mar 11, 2017, 8:13 AM Ryan Harter<EMAIL_ADDRESS>wrote:

That's only the case if you're using the MoshiAdapterFactory, right? If
accessing the adapters manually or another way then they could be in
different packages.
On Sat, Mar 11, 2017, 6:06 AM Jake Wharton<EMAIL_ADDRESS>wrote:

That would require all your model objects be in the same package. Is
that
ok? Compilation would fail otherwise, which seems like reasonable
behavior.
On Sat, Mar 11, 2017, 3:03 AM Ned Twigg<EMAIL_ADDRESS>wrote:

auto-value-moshi requires a method like this:
public static JsonAdapter jsonAdapter(Moshi moshi)
{
... }
Are you open to a PR which would allow this?
static JsonAdapter jsonAdapter(Moshi moshi) { ... }
With Java 9 modularity coming, I'd like the option to use Moshi as an
implementation detail which is invisible to client code.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rharter/auto-value-moshi/issues/87, or mute the
thread
<

https://github.com/notifications/unsubscribe-auth/AAEEEVEDY6C-hZIvAg7pEG5YZGz-Cv6Xks5rklVugaJpZM4MaI1N

.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<

https://github.com/rharter/auto-value-moshi/issues/87#issuecomment-285862721

,
or mute the thread
<

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

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/rharter/auto-value-moshi/issues/87#issuecomment-285865892
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAEEEZsd3MI6WUgbeHGMo5KvWMldZqsyks5rkp4OgaJpZM4MaI1N
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/rharter/auto-value-moshi/issues/87#issuecomment-285867540,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPJblDg-hLDQgDL_zKF6zPhqgFeIw4eks5rkqVDgaJpZM4MaI1N
.

Looks like there's been quite a bit of really useful stuff since 0.4.5: https://github.com/rharter/auto-value-moshi/compare/0.4.5...master
In addition to this issue, upgrading to AutoValue 1.6 and implementing net.ltgt.gradle.incap.IncrementalAnnotationProcessorType.AGGREGATING would be big wins.  I know there's always more I try to stuff into my releases, but it would be really cool to get an 0.4.6 as-is out on MavenCentral.  It's 0.x stuff, no warranty expected :)

WAAAHOOOO!!!  Thanks so much for 0.4.6!  This is such a useful library, great to see it shipping again :)


chore: lock version of grumpkin package

Description
Problem*
Resolves
Summary*
@kevaundray was very irresponsible and didn't specify a version for the noir-grumpkin dependency. The reviewer in the PR in which he made this mistake is entirely blameless.
Additional Context
Documentation*
Check one:

[x] No documentation needed.
[ ] Documentation included in this PR.
[ ] [Exceptional Case] Documentation to be submitted in a separate PR.

PR Checklist*

[x] I have tested the changes locally.
[x] I have formatted the changes with Prettier and/or cargo fmt on default settings.

checks Reviewer  ... :side-eye:


Fix typo in documentation for selectDevice

Description
Fixes a typo in the docs for selectDevice
Breakdown
No new changes
Validation
Additional Notes
Submission Checklist

[x] The source has been evaluated for semantic versioning changes and are reflected in gradle.properties
[x] The CHANGELOG.md reflects any feature, bug fixes, or known issues made in the source code

Thank you for your contribution @umarniz !


reset the received memory stream before SerializationException

Just found out that the received memory stream has to be reset before throwing the SerializationException when the message deserializing went wrong. Otherwise no new messages can be received.
Thanks

OK, thanks.


Support client invalidation on deletion

Description
Support invalidating a client when deleting it via the API, disallowing further client keepalives and check results until the client is either successfully removed from the client registry or for a specified duration of time.
Examples:
Invalidate a client until it is removed from the registry:
API DELETE /clients/:name?invalidate=true
Invalidate a client for an hour:
API DELETE /clients/:name?invalidate=true&invalidate_expire=3600
Related Issue
https://github.com/sensu/sensu/issues/1541
Motivation and Context
Some infrastructure system/vm/container life cycle workflows do not allow for Sensu client decommissioning or users do not care for the keepalive event handler method of client registry cleanup.
How Has This Been Tested?
Added RSpec API tests.
Manual testing with running services:
{"timestamp":"2017-03-22T11:33:11.219089-0700","level":"debug","message":"updating client registry","client":{"name":"i-424242","address":"<IP_ADDRESS>","signature":"foobar","subscriptions":["test","roundrobin:test","all","client:i-424242"],"keepalive":{"th
resholds":{"warning":10}},"deregister":true,"deregistration":{"handler":"DEREGISTER_HANDLER"},"version":"0.28.4","nested":{"attribute":true},"service":{"password":"REDACTED"},"empty":{},"localhost":"fail","http_socket":{"user":"foo","password":"REDACTED"
,"bind":"<IP_ADDRESS>","port":3031},"timestamp":1490207591}}
{"timestamp":"2017-03-22T11:33:11.219551-0700","level":"warn","message":"invalid client signature","client":{"name":"i-424242","address":"<IP_ADDRESS>","signature":"foobar","subscriptions":["test","roundrobin:test","all","client:i-424242"],"keepalive":{"thr
esholds":{"warning":10}},"deregister":true,"deregistration":{"handler":"DEREGISTER_HANDLER"},"version":"0.28.4","nested":{"attribute":true},"service":{"password":"REDACTED"},"empty":{},"localhost":"fail","http_socket":{"user":"foo","password":"REDACTED",
"bind":"<IP_ADDRESS>","port":3031},"timestamp":1490207591},"signature":"invalidated"}
{"timestamp":"2017-03-22T11:33:11.219614-0700","level":"warn","message":"not updating client in the registry","client":{"name":"i-424242","address":"<IP_ADDRESS>","signature":"foobar","subscriptions":["test","roundrobin:test","all","client:i-424242"],"keepa
live":{"thresholds":{"warning":10}},"deregister":true,"deregistration":{"handler":"DEREGISTER_HANDLER"},"version":"0.28.4","nested":{"attribute":true},"service":{"password":"REDACTED"},"empty":{},"localhost":"fail","http_socket":{"user":"foo","password":
"REDACTED","bind":"<IP_ADDRESS>","port":3031},"timestamp":1490207591}}

{"timestamp":"2017-03-22T11:34:01.297743-0700","level":"warn","message":"invalid check result signature","result":{"client":"i-424242","check":{"source":"switch-y","command":"/bin/true","name":"source","issued":1490207641,"subscribers":["test"],"interval
":1,"executed":1490207641,"duration":0.006,"output":"","status":0},"signature":"foobar"},"signature":"invalidated"}

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

Awesome! That should take care of most of the issues. This only seems to be an issue for within 5-10m of initial deletion, so that should easily cover the bases.
Thanks for your work on that.


Feature suggestion: Open new tab in same directory as current tab

Hi, awesome project! This has quickly become my primary terminal.
I have a suggestion regarding opening new tabs, essentially mirroring a feature from at least Linux Mint's native terminal: It would be really cool if, when a new tab is opened, the new tab could start in the previous active tab's working directory.
More clearly:

Currently, all tabs start in the home directory, regardless of the wd of the active tab prior to opening a new one.
If I open extraterm and cd code/myproject, then do Ctrl+Shift+T (or Ctrl+Shift+P "New tab"), I'd love for the new tab to open with the pwd set to ~/code/myproject

I hope I'm explaining it well enough.
Thanks again for your hard work!

Yes, I know what you mean and think that I would also like to have that feature too. It might be possible to make this work across SSH too.
Also, can I ask you how you discovered this project? and features do you like the most? (I'm curious of course)

I think I found this project on awesome-electron, but I feel like I also saw it referenced somewhere else (can't remember where right now) that further encouraged me to look into it.
I think my favorite feature is the cursor mode -- that just makes things so much more efficient. I also like that there are relatively high-contrast dark themes by default. I know that sounds like a little thing, but it's a pretty big accessibility deal; white/bright interfaces give me a headache, but dark ones that are too low-contrast are very hard to read.

I use the dark theme with a Linux style dark console theme. I had to tweak some of the colours to be brighter and readable. (Blue text on black is often unreadable for example That blue colour is brighter than the theme I originally borrow it from.)
I'm glad you like the cursor mode!

i'd love to see this feature as well. my workflow consists of opening new tabs within a directory and interacting with the files within, once the feature is there i'll feel much more at home 😄
also thanks for making such a beautiful terminal emulator, and for free!

I would really love to see this feature too, as i almost always need my terminals opened in the same directory. I've implemented this in a fork of your project some time ago, see https://github.com/nanobot248/extraterm/commit/4b473511e450d7508e97241a7d7fbcf8f0be5c5a
Maybe it helps, although there are probably easier ways to implement this.

@nanobot248 I’d also love to see this (not just for new tabs but, since I use the auto-tiling feature in Pop!_OS, also in new windows). Is there any chance you could implement your version as an extension?

The extension API doesn't support this kind of thing at the moment.
Right now I'm working on what I think of as a "tapas" release.  I'll be digging into this small feature shortly.

This feature will be in the next release. It is done.

Released in version 0.55.0.


Use the same version for all commands

Use the same version for all the components.
Moved the version file to the root.

Improved a bit more the version handling. I added a version.go file in the root directory which each package can access to read the version.
Maybe the string "master" could be manually changed to the correct version when a tag is created.

recheck

recheck

recheck

recheck

recheck

recheck

recheck

recheck


Third-party crate warnings exposed in my crate

Problem
When I build my project foo it gives warnings from a third-party crate's test directory
Steps

Add this dependency (confirmed at this commit https://github.com/offscale/cargo-make/tree/6cf59426a6e33ebaf5a769f88f5dda51a7e4cc1f )

[dependencies]
cargo-make = { git = "https://github.com/offscale/cargo-make", branch = "publicise" }

$ cargo build
warning: skipping duplicate package `member1` found at `.cargo/git/checkouts/cargo-make-1147f9fdbe23da7e/6cf5942/src/lib/test/workspace-inherit/member1`
warning: skipping duplicate package `member1` found at `.cargo/git/checkouts/cargo-make-1147f9fdbe23da7e/6cf5942/src/lib/test/workspace1/member1`
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.50s

Possible Solution(s)
No response
Notes
Official Rust discord told me that the warning shouldn't be exposed to me
Version
cargo 1.81.0-nightly (154fdac39 2024-07-07)
release: 1.81.0-nightly
commit-hash: 154fdac39ae9629954e19e9986fd2cf2cdd8d964
commit-date: 2024-07-07
host: x86_64-unknown-linux-gnu
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.8.0-DEV (sys:0.4.73+curl-8.8.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Ubuntu 24.4.0 (noble) [64-bit]

This appears to be a duplicate of #10752 and closing in favor of that.  If there is a reason we should keep this open, let us know!


Linuxbrew support?

Any chance you could pre-install http://linuxbrew.sh/ in the PHP containers?

@tracyfloyd can be added.
Can you please direct the request here:
https://github.com/devilbox/docker-php-fpm-7.3
This is going to be the base for all PHP container. Once this one has been finalized, I will copy it to the other versions.

Done - thanks!
https://github.com/devilbox/docker-php-fpm-7.3/issues/6


[Documentation] Update links on the documentation

We need to update the links on the documentation to reflect all the changes as well as the newest publication details. We should be able to get this done quite easily.

This has already been addressed. Closing it.


Bomb Specialist  Sabotuer Ascendancy Class

WIth the Sabotuer class, when you get the node bomb specialist. It is supposed to  increase mine laying speed and provide a 40% increased damage if you have detonated mines recently. When I go into configuration, and change the # of mines detonated recently from 0 to X amount, the mine laying time under the main skill and the damage does not change.

Bomb Specialist still seems to not be adding the increased damage if you've detonated mines recently even when # of mines is changed in Configuration.


Monorepo?

I think @HanSolo's discoclient should also be under the foojay2020 org so everything is in one place.
But... since I just tweaked my plugin because the client is during heavy development and the API is not stable I wonder if it wouldn't help for everything to use the same source repository. Then a class rename would easily propagate everywhere instead of me manually discovering what changed.

I see discoclient is under foojay2020. Not a monorepo but good enough.


About StarNet-150, StarNet-100, StarNet-050 pretrained model

Hi, thank you for your great work! Could you please provide StarNet-150, StarNet-100, StarNet-50 pretrained model? My adress is<EMAIL_ADDRESS>Thank you very much again!

@puyiwen Thanks. We mainly focus on s1,s2,s3,and s4 variants, and the smaller models / checkpoints are not relseased. I really need, we can retrain later and update.

@puyiwen Thanks. We mainly focus on s1,s2,s3,and s4 variants, and the smaller models / checkpoints are not relseased. I really need, we can retrain later and update.

ok, thank you for your reply. I want to constract the downstream task performace of mobilenetv2-0.75 and  starnet-150, so I need pretrained model. If you can update, I would be grateful.

@puyiwen Thanks. We mainly focus on s1,s2,s3,and s4 variants, and the smaller models / checkpoints are not relseased. I really need, we can retrain later and update.

Sorry to bother you again. If I have only 4 GPU, how can I train the starnet? Should I need to change some parameters, like lr, batch-size?

Hi @ma-xu, I also have the request about the checkpoint of starnet050, as we want to evaluate it on resource-constraint devices. Thank you!

@KokyoK @puyiwen Hi, thanks for your message.
Let me train these models on this weekend since there are some GPUs available, and probably will update the link to checkpoints by Wednesday. If not, please feel free to directly send me an email. Thank you!

Hi, @ma-xu, much thanks to your work.
However, i have the same request about the starnet_s050 pretrained model for a fair comparision. Are there any update about the pretrained weight? Hope to get youre reply.


Showing source code in the sampler breaks the transition animation

Select some different panes from the left hand. The content crossfades pleasingly.
View some source code.
Select some different panes. Now the source appears briefly during the fade.

Thanks! That's UI misbehaviour.

Fixed with https://github.com/mkpaz/atlantafx/commit/259ee6da61e8252cddcc32f3102bf19a82e53340


Fix bug about feature_transformation error

Description: This pull request addresses a bug related to feature transformation configuration errors in the configuration files for neural network models.

@microsoft-github-policy-service agree

Hi @chakkritte, I'm grateful for your contributions, and I found this bug, and fixed it in batteryml/utils/configs.py. No need to modify all yaml files。


Always show the last closed report action

Details

Usually there is only one closed report action in a report, however, in case of merging two accounts, when the old account has some archive policy expense chats, there is another closed report action added to the report. The old once (in this scenario - user removed from policy) stays in the report so we need to make sure the reportAction we show in the report footer is the closed report action with the latest created field.
In this PR have added a new method which will filter the report actions for only those which are closed, sorts them and shows the latest one meaning we will always display the most up-to-date archive reason.
Fixed Issues

$ https://github.com/Expensify/App/issues/14292
Tests

[x] Verify that no errors appear in the JS console

Create the first account and create a workspace
Invite a second and third account as members to the workspace
Send a message in the workspace chat for the second account and the third
accout
Remove the second account from the workspace
Validate the second account on OldDot
Sign in as the third account on OldDot and merge the second account
Sign-in to newDot as the third account
Verify the archived reason in the archived workspace chat is due to account being merged (and not due to user being removed from the policy)

Offline tests

N/A
QA Steps

Same as test. Will be queued internally by @trjExpensify

[ ] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

@parasharrajat @neil-marcellini One of you needs to copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

👀

Yeah I have the same questions.
I think we need to merge the second account into the third so that the old
account (second account) has archived policy expense chats due to being removed
from a workspace. I think these steps might be better.

Create the first account and create a workspace
Invite a second and third account as members to the workspace
Send a message in the workspace chat for the second account and the third
accout
Remove the second account from the workspace
Validate the second account on OldDot
Sign in as the third account on OldDot and merge the second account
Sign-in to newDot as the second account
Verify the archived reason in the archived workspace chat is due to account being merged (and not due to user being removed from the policy)

Hmm now when I go to merge accounts I get an error. I'll look into that.

Oh I see, the accounts can't be on the wallet beta as shown in the backend here. I'll comment out that line to proceed.

Sorry for the it not being more clear, i havent counted the admin account as first or second, so first was the first non-admin member.
Will updat

@parasharrajat Sorry, I am also not fully aware if anything special is required to test this. I hoped not, given @neil-marcellini has tested this and it worked well I think we can proceed with merging once I fix the lint issue.
Thank you both!

@neil-marcellini @parasharrajat Ready to fill out the reviewer checklist and merge, thanks!

Do I need a domain-based email account or Gmail one will work for it?
Sorry, I am also not fully aware if anything special is required to test this.

The account needs to be on the policyExpenseChat beta to access workspace chats.

@parasharrajat I think we can skip this testing on all platforms, Neil has confirmed this works fine locally and we will test this thoroughly in Staging with Tom so we will catch any issue there nonetheless.
Can you just fill in the checklist and note Neil tested web and we will test the entire flow in staging?

Thanks @parasharrajat

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

This is merely updating the ReportFooter logic on how to get the closer report action and does not touch Search page logic. I think we are fine here and it was a one off, removing the Deploy blocker label.
Let me know if you think otherwise.

This is building right now but should be ready to test in an hour and tomorrow @trjExpensify

🚀 Deployed to staging by https://github.com/mountiny in version: 1.2.78-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

Okay, going to jump into this PR review now.

Is this related? Created a workspace and my own policyExpenseChat shows with this OpenReport auth error:

And then here from the account I'm setting up to be the old employee when trying to access their workspace chat:

So the common denominator is that we're running into this bug trying to access your own workspace chat just fine. For example, this is the admin looking at emp17's report:

It's traced back to this PR I think: https://github.com/Expensify/Auth/pull/7576
CC: @jasperhuangg @aldo-expensify

Okay, that's as much as I can do here to test this PR given that blocker.

🚀 Deployed to production by https://github.com/mountiny in version: 1.2.78-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Removes empty parent association sections from associations drawer

I find the empty parent association sections in the redesigned associations drawer quite noisy since the 2.7.0-release (see screenshots). As far as I can tell, they also provide no real value, so I propose to remove them entirely. Not sure if this is something that should be changed in a patch release or better be cherry-picked for the 3.0.x-branch, but I’m working with the 2.7.0-code at the moment, therefore submitting this to the 2.7.x-branch.

Looks like sections without actual associations weren't listed in the "linked to"-part of the association drawer before 2.7.0 and I guess this change more or less "happened" while refactoring the drawer and wasn't really introduced by purpose.
So I'm all for Jens' proposal and remove these links in the next patch-release again.

@twiro Thanks for the detailed feedback, much appreciated.

The goal was to add information about the possible links. Without it, you loose information about all the possible associations. It is also weird to have empty sections in one way, but not the other way around.
I do not know if that fact comes from our data modelling. But I sure do know that Symphony should not care about one's data modelling, so I am tempted to add "Yet Another Configuration Setting"TM.
I'll think about it, but with 4 votes against 1 right now, you guys might expect me to merge it in the next days ;)

It is also weird to have empty sections in one way, but not the other way around.

The difference is that having it for the other direction offers additional functionality because of the “new” button.

The difference is that having it for the other direction offers additional functionality because of the “new” button.

Yeah I understand that ;) Still feels weird to me!

Well, even @alexnantel88 is for it, so I guess democracy wins. This time ;)


Add -r, --reverse option to reverse dependency tree

--reverse
I've added -r to the command line and tried to merge it as well as I can into the existing structure. The output style is slightly different for readability, but fully compatible with the -f, -w, -a and -l flags.
Comments on style/string format/code welcome!
So far I've only manually tested this in 2.7 and 3.5; I haven't used tox before and have failed to get it running successfully (under Win7/MinGW), so apologies for that.
Closes #25
Examples:
$ pipdeptree -w

django-guardian==1.3.1
  - Django [installed: 1.8.5]
  - six [installed: 1.10.0]
djrill==1.4.0
  - requests [required: >=1.0.0, installed: 2.8.1]
  - Django [required: >=1.3, installed: 1.8.5]
pip-autoremove==0.9.0
virtualenv==13.1.2
WhatColorIsX==1.0.0
  - colour [installed: 0.1.2]
  - simplejson [installed: 3.8.1]
  - Pillow [installed: 3.0.0]

$ pipdeptree -w -r

virtualenv==13.1.2
Pillow==3.0.0
  - WhatColorIsX==1.0.0 [requires Pillow]
requests==2.8.1
  - djrill==1.4.0 [requires requests>=1.0.0]
six==1.10.0
  - django-guardian==1.3.1 [requires six]
simplejson==3.8.1
  - WhatColorIsX==1.0.0 [requires simplejson]
Django==1.8.5
  - djrill==1.4.0 [requires django>=1.3]
  - django-guardian==1.3.1 [requires Django]
colour==0.1.2
  - WhatColorIsX==1.0.0 [requires colour]
pip-autoremove==0.9.0

$ pipdeptree -w -r -f

Django==1.8.5
    django-guardian==1.3.1
    djrill==1.4.0
pip-autoremove==0.9.0
requests==2.8.1
    djrill==1.4.0
six==1.10.0
    django-guardian==1.3.1
Pillow==3.0.0
    WhatColorIsX==1.0.0
virtualenv==13.1.2
colour==0.1.2
    WhatColorIsX==1.0.0
simplejson==3.8.1
    WhatColorIsX==1.0.0

Issue seems to be render_tree() doesn't have some default arguments it should (e.g. top_pkg_str), so I'm going to look at changing that, and also adding some _reverse tests to test_pipdeptree.py

render_tree() now has sane default arguments (i.e. it will default to a non-frozen style output), which makes calling it during testing much more readable.
I've added some tests for --reverse as well, although obviously these may need changing if people don't like the current reversed output format.

Hi, thanks for this. I think I'll only get time to go though it over the weekend.
Testing with python 2.7 and 3.5 is fine. I'll run tox on it and do a final verification before merging the PR. Even I haven't tested under Win7/MinGW so that should be fine for now :-)
Also, when I was thinking of implementing this, my idea was to try revering the `req_map

Sorry, I should have written a bit of description. My approach was:
Parsing req_map after passing it to render_tree(reverse=True) to generate a new, parents tree structure. This basically contains the original tree structure in reverse, and can be called like parents[pkg.key] instead of pkg_index[pkg.key].requires().
After that, aux(reverse=True) is called, to indicate the string_generator used should be non_bottom_pkg_str instead of non_top_pkg_str, which accepts a slightly different format (documented in the doctring), and returns a differently formatted string.
In my opinion this is better than trying to manipulate req_map beforehand, as:

It keeps render_tree() very simple to call and use
The same kind of reversal you suggest is pretty much what I've implemented, and it happens quietly inside render_tree() only if it is given the reverse=True parameter, so there is no potential slowdown for non-reversed trees
I think the formatting of the output will need to be changed anyway for reverse trees to be intuitive

Modified the output slightly to cohere to the original style, and only show requires: if a version is specified. requires: will show both the name and version of dependency required, to avoid confusion.
pip-autoremove==0.9.0
colour==0.1.2
  - WhatColorIsX [installed: 1.0.0]
Werkzeug==0.10.4
  - Flask [installed: 0.10.1, requires: Werkzeug>=0.7]
    - Flask-Script [installed: 2.0.5]
Pillow==3.0.0
  - WhatColorIsX [installed: 1.0.0]
virtualenv==13.1.2
itsdangerous==0.24
  - Flask [installed: 0.10.1, requires: itsdangerous>=0.21]
    - Flask-Script [installed: 2.0.5]
simplejson==3.8.1
  - WhatColorIsX [installed: 1.0.0]
MarkupSafe==0.23
  - Mako [installed: 1.0.3, requires: MarkupSafe>=0.9.2]
  - Jinja2 [installed: 2.8]
    - Flask [installed: 0.10.1, requires: Jinja2>=2.4]
      - Flask-Script [installed: 2.0.5]

I can see the dict reversal you have implemented inside render_tree but I don't think it needs to be inside the function. If all you are doing is reversing the input, it could be done before calling the function eg.
    tree = render_tree(reverse_dict(pkgs), ...)

I agree that the output formatting will probably be different for --reverse. But may be that can be solved by passing different formatting functions as args? In that case, it should be possible to define two high level functions eg. render_tree_down and render_tree_up that will take care of reversing the input dict and passing the correct args to render_tree.
IMO, multiple if reverse then .. else .. blocks inside render_tree severely affects readability of the code. I would rather have just one conditional check outside that will decide which function to delegate the job to, eg,
    tree = render_tree_down(...) if not reverse else render_tree_up(...)

Fair enough, in that case I'll try and write something along those lines (unless you want to do it yourself)

Sure, please go ahead. I think you have already added lot of code that just needs to be moved around. Thanks.

Was trying to write as you suggested, found it quite hard without daisy-chaining pkg_index absolutely everywhere. I realised this could be easily solved with an OOP approach, and as far as I can tell it works well.
I moved everything under a pipdeptree.pipdeptree() object and found everything much easier to manage. I've removed the multiple if reverse: ... else: statements, and implemented string formatting by passing object methods through a variable, as you suggested. I also realised that you had actually already implemented a reverse_dict in the confusing_deps function :) I just hadn't realised previously.
So, if you're interested, my last commit (e2a269e) is an OOP conversion of your original code that works on Python 2.6, 2.7, 3.3, 3.4 and 3.5. For some reason 3.2 throws an error, haven't quite worked out why yet.
Obviously this is quite a large (huge!) change in your project, so totally understand if you don't want it. I do think the OOP structure works much better though, as it allows global access to the pkgs, pkg_index, req_map, etc data structures. It also forces testing without faking some sort of pkgs input, which I've implemented (currently running with nosetests).
Summary:

Code is now in OOP structure, under a pipdeptree object
Sphinx/sphinx-rtd-theme is a natural cyclic dependency, for future testing
The output tree is now sorted alphabetically
Backwards-compatible for command-line use

Example:
from pipdeptree import pipdeptree

# Main
ptd = pipdeptree(local_only=False)
tree = ptd.render_tree(list_all=True, bullets=True, reverse=False)

# Warnings
cyclic_generator = pdt.cyclic_deps()
confusing = pdt.confusing_deps()

# Helpers
nice_string = pdt.non_top_pkg_name('markupsafe', 'mako')

Hi, I finally got some time to take a look at your code. To be frank, I didn't quite like the OO approach for various reasons mainly that everything is now tied together to the python environment. I can't for eg. test the functions (now methods of the class) by passing them a dict/list of packages that are not in the active python environment. The same reason why you had to modify tests that loaded pickled pkgs. Daisy chaining arguments is better IMO.
Having said that, I think both your solutions have helped me understand a key problem in my original code which is, the render_tree function is not abstract enough. I have a few ideas in mind for refactoring the existing code and implementing the --reverse flag. I am going to push my changes to a different branch so that we can compare both PRs and decide.
Thanks

Sounds good. I agree that at the moment it is less flexible, but equally you could give the init method an optional pickle file to use for tests, and if it is present it extracts from your test file instead of from pip; something like that? I dont think it is the OOP structure exactly that makes it inflexible.
The reason I preferred not using such a file for tests is that it feels like cheating the system a bit. If you can run and pass tests in an environment without it, what is your reason for doing so? I'm guessing reliability, in which case you could have two sets of tests, one using pickle amd the other using a real environment.

Agreed, the __init__ method could be modified to take optional args for "seeding" the object.
Also you are right about the reason for using two kinds of tests. The very first version used pickled data stored in files. However this tool is basically a hack! It uses internal functions from the pip codebase that may change depending upon the version of pip. Pickled files gives the flexibility of simulating fake test scenarios such circular deps.

pipdeptree() now accepts a pkgs argument, from which all the other arguments are generated automatically. This allows for pickle-type testing. I have generated new pickle files for this testing which contain only pkgs as a list.
pkg_resources is generating a warning during testing stating that it is dropping support for Python 3.2 (which this build fails on), so I've removed it from the testing suite.
All other versions pass both pickled tests, and virtualenv-type tests. These are run in parallel and expect the same results.

I have added my solution in PR https://github.com/naiquevin/pipdeptree/pull/34. It took a lot of refactoring! Basically I have defined wrapper classes for the Distribution and Requirements instances with methods such as render_as_root and render_as_branch (equivalent to top_pkg_name and non_top_pkg_name etc.) so each type of object knows how to render itself as a root node or branch node of the tree. Rest of the code is more or less the same.


How to bundle several smart contract invocations into a single tx?

I would love to be able to bundle several smart contract invocations into a single transaction.
If anyone wants to take a stab at this, that would be great! If not, perhaps at some later date I'll find enough time to try taking a look. I think this feature will become an increasingly important thing to do for more complex SC interactions.
Adding this ticket mainly to keep track of any development and references.

I am successful in chaining vm scripts together. At least for minor stuff like retrieving names, symbol, etc. It works in invokescript RPC call so I don't see why not with a real transaction.
You can take a look at https://github.com/CityOfZion/neon-js/blob/081bc4c42422f1eb9f51bf955e93ac28111888c1/src/nep5.js#L14 . Each emitAppCall is basically one invocation.

Resolved in https://github.com/CityOfZion/neo-python/pull/137