Panel as an iframe

Proposal
I don't want to use Grafana and the basic Prometheus graphs are fine to me. But I need to include the graph into a dashboard. The Grafana has such a feature and it looks for me like a simple thing to implement for the Prometheus.
Even now I can include the /graph page but I just want to hide a header. Is it something that can be done in Prometheus or it's UI is not a subject for a serious use and we should use the Grafana instead?

Technically, I don't think this would be too difficult. All the configuration information for a graph is already serialized in the URL anyway so all we would need to do is make a page that only has the graph component. The question of is it in scope is a little more tricky. I personally think the iframe functionality is on the border of what our simple UI should be doing. I wouldn't necessarily be opposed to it, but I'm not familiar enough the decisions made in the UI to make a determination.
cc @juliusv

I'm also on the fence about that in Prometheus itself... btw., one way you can already do it is by using the console templates in Prometheus (https://prometheus.io/docs/visualization/consoles/#console-templates) that already come with an example graphing library as well. You could use that to serve an HTML page straight from Prometheus that only shows a graph.
On a totally different front (but at the moment still only in a separate project), the Perses project (https://github.com/perses/perses) had embeddability of Prometheus graphs as one of its main goals. @Nexucis is this already usable by others?

I feel stupid because didn't figured out what is consoles and how to use them when first read the docs. Nice feature. It would be great to add a menu item for them.
The consoles themselves needs for some attention.
Their index page http://localhost:9090/consoles/index.html.example has a list of console files but it's not clickable and not generated automatically. Some consoles seems not working our of the box.
The consoles aren't not the same as the React UI built-in to Prometheus binary. So I'm not sure if I can get the same functionality like query autocompletion. Ideally the main UI must be also implemented as a default console. Then users may play and hack it.
Anyway, this is basically not related directly to the feature request. The iframe would be very useful at least for my case but I don't know how many of others would need it. Given that I was a first who asked about it I assume that this is not needed.
Right now for my app I took chart.js library and making a CORS request to the Prometheus with Base Authorization and credentials are just written in the client JS. This is a bad solution from security perspective but I don't have other options for now. And even with the CORS I have a trouble and had to put nginx behind.
I still wish to have the iframe just because I can use autocompletion.
Also I need to figure out how to get rid off the basic auth creds and the only reasonable way would be to use JWT based auth. This again needs for a proxy behind the Prometheus.
P.S. You see, this is all basically talk more about direction of the Prometheus itself. When I created the issue I was pissed off. And next hour I just started looking how to get rid off the Prometheus and use plain PostgreSQL instead. I spent too much time on the Prom and not a single of my needs wasn't solved without a headache:

Installation: the Ubuntu's prom package is very outdated. And there is no any PPA or just a DEB package. So I had to download manually and configure the systemd unit.
By default there is no any password and I had to spend time to find how to add a basic auth.
TLS was a separate pain because the Prometheus has it's own user that doesn't have an access to /etc/letsencrypt. As a workaround I added the prometheus user to ssl-cert group and copied certs to /etc/ssl/private.
Alerts should be installed separately and this also was a big challenge. The Ubuntu's package is old and doesn't support Telegram. I don't know why TG wasn't supported from beginning given that it has a simple API and widely used. I still didn't configured alerts rules because this seems complicated and no any UI for this. Instead I just wrote a shell scrip that does everything I need in a plain manner.
The service discovery turned out to be just an integration with a SD of a k18s. So basically Prom doesn't have an SD and I have to write my own.

And many of other small problems like removing a metric series that consumed too mush of a disk space. I spending about 30% of time to fight with it and this is just insane.
So many optimizations of TSDB while basic needs aren't covered and the overall system is not usable.

@stokito It seems to me that you came with the expectations of a commercial product to an open-source project built and maintained in large parts by volunteers, often in their free time (although some companies also pay some people for specific things). Still, it is good feedback, and definitely we could do a better job in many of these things. When it comes to Debian / Ubuntu packages, they are indeed often out of date or not feature-complete, as Debian's own packaging guidelines make it quite tough to ship Prometheus packages with all features and in a timely way. That's currently done by a volunteer outside of the official project. It would be nice if the project itself could ship its own .debs and other packages with less packaging restrictions, but currently nobody is doing that unfortunately (again, it would need a volunteer).
With point 5, I'm not sure what you mean... Prometheus supports integrating with a lot of common types of service discovery, where k8s is just one (see https://prometheus.io/docs/prometheus/latest/configuration/configuration/#configuration). It also allows custom integrations over HTTP or local files. What other way were you expecting Prometheus to discover services?
Anyway, it seems like Prometheus wasn't a match for what you were expecting, which is fine.

On a totally different front (but at the moment still only in a separate project), the Perses project (https://github.com/perses/perses) had embeddability of Prometheus graphs as one of its main goals. @Nexucis is this already usable by others?

Well on the paper, it should be usable by others, but for the moment there is no guideline or explanation on how to do it.
On my personal side, I will try it in Prometheus. Probably when I will start to do that, I will write or help to write such documentation.
Even if I can't wait to see it happen, well this moment will take time :(. Also because there is some steps before with more urgent matter, like integrating PromLens in Prometheus.


feat(lidar_centerpoint): output the covariance of pose and twist

Description
This PR enables the centerpoint node to update the covariance of covariance of pose and twist.
The variance comes from the model trained with sigma loss(https://github.com/tier4/AWMLdetection3D/pull/133), which predicts the variance of the boundingbox's size, position, and velocity.
Related links
Please download the centerpoint_sigma model from https://drive.google.com/drive/folders/1Thr_M1Jo1-ByP23qjLmXiFh-abdStD2J?usp=drive_link
Tests performed
ros2 launch lidar_centerpoint lidar_centerpoint.launch.xml model_name:=centerpoint_sigma input/pointcloud:=/sensing/lidar/concatenated/pointcloud
output:
`ros2 topic echo ~/objects

existence_probability: 0.47262266278266907
classification:

label: 2
probability: 1.0
kinematics:
pose_with_covariance:
pose:
position:
x: 14.863276481628418
y: -30.522504806518555
z: 0.982421875
orientation:
x: 0.0
y: -0.0
z: -0.8441231237133663
w: -0.5361493747197593
covariance:

0.2047557532787323
0.0
0.0
0.0
0.0
0.0
0.0
0.23383840918540955
0.0
0.0
0.0
0.0
0.0
0.0
0.1902950257062912
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.025285644456744194
has_position_covariance: true
orientation_availability: 1
twist_with_covariance:
twist:
linear:
x: 6.219586886509506e-05
y: 0.0
z: 0.0
angular:
x: 0.0
y: 0.0
z: 7.58850622177124
covariance:
0.06898762285709381
0.0
0.0
0.0
0.0
0.0
0.0
0.09374400973320007
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
has_twist: true
has_twist_covariance: true
shape:
type: 0
footprint:
points: []
dimensions:
x: 5.908353805541992
y: 2.103604555130005
z: 2.882314920425415
---`

Notes for reviewers
Interface changes

Effects on system behavior

Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[ ] I've confirmed the contribution guidelines.
[ ] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.
[ ] The PR has been properly tested.
[ ] The PR has been reviewed by the code owners.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.
[ ] The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

@YoshiRi The conflict is fixed.

I found that the compile is failing in image_projection_based_fusion package.
The point painting is using the centerpoint and the configuration may need to be updated.
https://github.com/autowarefoundation/autoware.universe/blob/f97cdc03ba8aa5d30fa3ebc9edd5f75f15adc4d7/perception/image_projection_based_fusion/src/pointpainting_fusion/node.cpp#L189C1-L192C26

Config of pointpainting is updated.

I am testing the centerpoint_sigma model with lsim
### copy onnx models
# $HOME/autoware_data/lidar_centerpoint/pts_backbone_neck_head_centerpoint_sigma.onnx
# $HOME/autoware_data/lidar_centerpoint/pts_voxel_encoder_centerpoint_sigma.onnx

### launch once for tensorRT cuda engine generation: convert onnx to engine
ros2 launch lidar_centerpoint lidar_centerpoint.launch.xml model_name:=centerpoint_sigma input/pointcloud:=/sensing/lidar/concatenated/pointcloud

### copy parameter to autoware_launch
# autoware/launcher/autoware_launch/config/perception/object_recognition/detection/lidar_model/centerpoint_sigma.param.yaml

### launch lsim
ros2 launch autoware_launch logging_simulator.launch.xml  ........ lidar_detection_model:=centerpoint centerpoint_model_name:=centerpoint_sigma

Compatibility check
I checked this PR would not brake conventional detection process with sample-rosbag in autoware tutorial.

config
model: conventional one
autoware_launch is not changed
result
Not broken. Covariance and twist is not published.

Twist check

Since current model already has twist output, we can get twist by changing paramter in autoware_launch.
https://github.com/autowarefoundation/autoware.universe/pull/6602

Pose covariance check
Current model seems not able to measure covariance, but the process still works.

config

add variance=true in conventional model param

PR to autoware_launch: https://github.com/autowarefoundation/autoware_launch/pull/945


Chart Tango results

Build the capability for a user to take
tango results + chart config files + transformation code from tango result format to a specific charting format
And display a nivo chart of the tango results. varnish nivo
This is a hard task if we want to support many many charting options and formats, and a trivial task to support a single non configurable chart.  So what we do really depends on need and time.

Like we said on the call, the best way to do this might be to provide a library that can take numbers and visualize them in a static HTML page, and then use that library to write a Tango step that does this to visualize results. We'll provide 2-3 example steps that do this, but in general we leave the precise mapping from data to graphs up to the user, defined in Python.
I think it will be very hard to come up with a generic step that can do all this just with Jsonnet.


"_x" is being stripped out of emails

We have encountered an issue where customers who have an "_x" in their Email address are not receiving their esignlive Emails.
Upon investigating the code it seems the EsignLiveJSONHelper.remove_x(String jsonString) method removes all instances of "_x" due to the naming convention of some objects defined in the EsignLiveAPIObjects class (ex: Package is Package_x in the SDK). We believe this code is also removing the value from email addresses as well.
We were able to reproduce the issue by including an "_x" in an Email address, only to have it removed after we make the rest call to esignlive using the APEX SDK.

Hi Christian - yes, we included that functionality to handle reserved words.  We're looking into a fix for this and will update this issue shortly.

@robmtz I assume the issue is in the replace_x() method? Since you are searching a JSON string could you use this instead to only replace the '_x' or '_X' when it's at the end of a JSON keys.
 jsonString = jsonString.replaceAll('_[xX]":', '":');

Example of the regex: https://regex101.com/r/pTZdGX/1

@doublesharp - yeah, that's a good idea.  I'm leaning towards specifying the full reserved word, though, as that will be even more targeted.
@ChristianAubut  - we're starting development of the fix now and should have this fixed and released in a couple weeks.


slog_term could benefit from an option to print out filename and line number ...

Necessary in case of massive systems where the same error can repeat in many places possibly ... Ideally per level so e.g. ERROR/WARN/CRIT are showing it ...
Yes, it can be put manually on every error! but we already have line/file in record

It's possible already via normal means.
Every key-value pair when being emitted takes a Record: https://docs.rs/slog/2.0.0-3.1/slog/trait.KV.html
Record gives it line, file and everything if needed. https://docs.rs/slog/2.0.0-3.1/slog/struct.Record.html#method.file
Typically this is used with closures. Eg. here slog-bunyan: https://github.com/slog-rs/bunyan/blob/00b495dd171ee1f673aea8872f6dea0a08e0af5e/lib.rs#L67
In your system you could add a key-value object that emits "location" => file:line or whatever you prefer, and possibly even skip emitting anything on some record.level() etc.
I'm talking slog v2 here, but IIRC slog v1 can do it quite similarly.
Now, if you'd want some "special treatment" for source location during formatting, that's another story. Probably could be added to a builder, however I'm not sure if it's really worth it. Please let me know if the general approach works for you.

I don't think I expressed myself clearly. I'm kind of looking for a drain (option?) with sterm that automatically prints line/file just like it puts timestamps on everything ...

So for full format this would work already. When creating root logger just do something like:
let log = log.new(o!("location" => PushFnValue(|r : &'c Record<'d>, ser : PushFnSerializer<'c>| {
                ser.serialize(format_args!("{}"{}", r.file(), r.line());
})));

and just is the new log. I haven't actually tried that code, just typing from memory.
It would however defeat the compact format as the first value would keep changing, forcing printing out all information over and over.
I think it makes sense to add list of KVs to terminal output, in a way similiar to what slog-bunyan is implementing, that it would be output along the timestamp and message for cases like that.

I think I know what you mean. You'd like this to be printed as the "header" part, not a KV-part. It could be added, as an optional closure or something like that in the builder.

Yupp, I'd like it like a timestamp on the header. Huge systems have thousands of logs and sometimes it's not easy to find out WHERE the log comes from, especially if the same text/log can occur in many places ...

Yes, I would like this as well.
I just tried @dpc approach (btw, this version compiles:
        let log = log.new(o!("location" => PushFnValue(|r: &Record, ser: PushFnValueSerializer| {
            ser.serialize(format_args!("{}:{}", r.file(), r.line()))
        })))

with
slog-term = "2.3.0"
slog-async = "2.1.0"

)
and it works, but it also ruins CompactFormat output - the whole hierarchy is printed every time, because the location keeps changing...
Being able to easily customize the header (probably custom slog_term::print_msg_header ?)  would be nice))

Agree. I think this is a useful feature. Please submit a PR!


feat(analysis): Allow uploading shapefile grids using multiple select.

@evansiroky can you take a look at the tests here?

Current coverage is 53.98% (diff: 84.61%)

Merging #208 into dev will increase coverage by 0.56%

@@                dev       #208   diff @@
==========================================
  Files           160        160
  Lines          3403       3412     +9
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           1818       1842    +24
+ Misses         1585       1570    -15
  Partials          0          0

Powered by Codecov. Last update 6580418...2aab812

Don't forget to fix the linting issue tho.

Good call. I think lonlat is too specific (trying to only handle the names we encounter on the web in e.g. leaflet), I think we want to be more flexible and handle more possible names, but the idea is well taken. It's a little tricky as we'll have to use a FileReader to parse the first line of a (potentially very large) file. Certainly not impossible but it's a post-1.0 feature given the tight timeline there. https://app.asana.com/0/150048889193026/232402333785327

@mattwigway agree with @evansiroky tho. If we can add one or two more parsing checks to get 99% of the use cases then that would be a great way to do it. As it is I imagine it would currently get us > 80% of the way there.

@evansiroky / @trevorgerhardt should be better now.


[Feature] Add a strict parser for YAMLs in CI

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

Description

#2174
#2239

Use case
No response
Related issues
No response
Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

Hi @kevin85421 , Can I take on this issue?


Simplify using middleware request handlers

We now support middleware request handlers by default and no longer require an explicit call to MiddlewareRunner. Accordingly, the MiddlewareRunner is now internal only.
Builds on top of #215

Test failing after merging to master. Not sure why now and not in the PR build. Opened #279 with a fix.


Feature writemode

Added writemode with update mode.
It works nicely but I'm really new to Ruby and I can't sure my code is clean.
Please review my codes.

Any comments?

Yes, so many that I copied your code to my branch and started working on it myself. Then I had to stop because life kicked in, but I hope I'll figure this out this week.

The param needs to be called write_mode and not writemode.
The UI message outputting the write mode to the console is unnecessary.
The wording for parameters documentation is poor (Revision no. to update doesn't say too much).
Ideally, the write_mode parameter should be optional, defaulting to :add, but when update_rev is present then write_mode has to be equal to :update (or not present too, but defaulting to :update). I can't make it work with Fastlane parameters optionality yet.
I was getting some weird errors from Dropbox when trying to test write modes, can't remember those now, might have been unrelated though.
You forgot tests.

Okay, thanks for you kindness.
Since I am new to Ruby and just ended my first year of programmer, I can learn so many things from your comments.
I'll keep going for this project for good.

@jooneyp I added write mode and made 0.2.0 release. Please verify if it works for you. Thanks for the patch!

Works like a charm.
Thanks for your help!🙌


cob_android: 0.1.11-1 in 'noetic/distribution.yaml' [bloom]

Increasing version of package(s) in repository cob_android to 0.1.11-1:

upstream repository: https://github.com/ipa320/cob_android.git
release repository: https://github.com/ipa320/cob_android-release.git
distro file: noetic/distribution.yaml
bloom version: 0.11.2
previous version for package: 0.1.10-1

cob_android

No changes

cob_android_msgs

No changes

cob_android_resource_server

No changes

cob_android_script_server

No changes

cob_android_settings

No changes

this is a rather organizational release


Add Typings using JsDoc

Since migrating to typescript is not an option, in the future, typings would be added to provided intellisense while using Node User Settings

I wan't to help on this project, can you describe it.

what exactly you want to document
what should be the format of it
what to skip/ give more importance on it
basic conventions to follow

Thank you for wanting to contribute.
For now, I am trying to improve the project, there are a lot of things to be done. But I also want to provide typing, as in providing Typescript IntelliSense features but without using Typescript and having to re-write the project completely in Typescript.
If you could help generate the typings using JsDocs and JsDocs comments that would be very much appreciated

If I get it right?
You wan't me to write JSDoc Comments for this Project.
I assume it is just the ./src directory.
Are you willing to convert it into a static docs website?

Do you use Typescript? If yes, then you know the significant difference between JS and Ts, the Intellisense and Auto-completion it brings to the IDE, unfortunately, Ts isn't used in this project, and JsDocs was used, but you could get that TYPING, which TS provides using JsDoc if you don't still know what it means check this website out How to get type-checking and generate TypeScript Typing declaration (types.d.ts) from JSDoc annotations.
And No, the project does not require to generate a website

Check this file,
is this what you need?
Forked Changes
The thing is,
it shows,
/**
 * Initialize the preference API with configuration options.
 */
declare namespace __exports {
    /**

maybe you want something else instead of __exports?

No, don't change or rename anything, leave them the way they are. Just add the typing. Please also move the typedefs out of the src folder into a types.js file, all typedefs should go there.
Ensure that you document these types appropriately with JSDoc comments to provide clear documentation for users and enable better tooling support for TypeScript or editors with TypeScript-aware features.
/**
 * @typedef {Object} PreferenceConfig
 * @property {string} preferenceFileDir - The directory where preference files are stored.
 * @property {string} preferenceFileName - The name of the preference file.
 * @property {string} fileName - The name of the file.
 * @property {string} fileExt - The file extension.
 */

PreferenceConfig doesn't seem to provide documentation as to what it actually is.
Also, if you noticed, there are places where JSON was used as a type of parameters (which is vague), also generate typedefs (that is well documented), to provide info as of what this object would be

Also moving forward, don't capitalize your commit messages, start with a lowercase (I will update the Contributing.md file soon with that info). This is the actual guideline:
Writing good Git commit messages is important for the maintainability and collaboration of your codebase. Clear and informative commit messages help you and your team understand the history of changes in the project. Here are some guidelines for writing good Git commit messages:

Keep It Short and Descriptive:

Limit the first line of your commit message to 50 characters or less.
Write a concise but descriptive summary of the change. Imagine it as the subject of an email.

Use Proper Grammar and Punctuation:

Start the summary with a capital letter.
Use imperative mood (e.g., "Add feature," "Fix bug," "Update Documentation") for the first word of the summary.

Provide Additional Details in the Body:

After the summary, add a blank line and write a more detailed explanation of the change.
Describe why the change is necessary and what it accomplishes.
Include any relevant context, references, or issues.
Use bullet points or paragraphs for readability.

Reference Issue Numbers:

If your commit is related to a specific issue or task, reference it in the commit message.
Most platforms (e.g., GitHub, GitLab) automatically link issues when you use a keyword followed by the issue number (e.g., "Fixes #123").

Separate the Summary and Body:

Use a blank line to separate the summary from the body for better readability.

Use Present Tense:

Write commit messages in the present tense. Instead of "Fixed bug," use "Fix bug."

Be Consistent:

Maintain a consistent style and tone for your commit messages throughout the project.

Here's an example of a well-formatted Git commit message:
Add validation for user input

This commit adds input validation to the user registration form to prevent
SQL injection attacks and improve security. It validates user inputs
including username, email, and password against a set of rules defined
in the validation module.

Fixes #123

Also, note that the dev branch was what I was working on to create a new release, so I have created a new branch called Staging and opened a pull request against that staging branch (and not Master!). I will also restructure the guide on how to make a pull request later.


Need to run tika server manualy but previously it works without tika

I had used this couple of months ago where I didn't have to configur anyhting on windows but now i need to run
this java -jar tika-server-x.x.jar -h <IP_ADDRESS>  in background to run python-tika. Am i doing anything wrong?

Can you provide more detail about what is no longer working? What are the error messages on Windows (if any?) What is present in the temporary director and the tika.log file? Can't really answer much with what you have provided @mahmudtopu3


spring native support for @circuitbreaker by resilience4j

This is a continuation of
https://github.com/spring-projects-experimental/spring-native/issues/960
While Resilience4j mostly works fine with native and Spring Boot3,
At least when using the programatic "circuitbreaker factory.
However leveraging the @CircuitBreaker Annotation does not work in native mode.
The adherent CircuitBreakerAspects seemingly never gets invoked.
I've attached a sample project below.
Starting the application in non native, will trip the circuitbreaker.
In Native mode it will do nothing
example.zip

also see https://github.com/spring-projects/spring-framework/issues/29519
because there might be a correlation

The @CircuitBreaker annotation is provided by Resilience4J itself, it is not part of this project.  It is something Resilience4J would need to fix.

https://github.com/spring-projects/spring-framework/issues/29519 will be fixed with boot 3.0.2
now we just need the following
" hints.reflection().registerType(io.github.resilience4j.spring6.circuitbreaker.configure.CircuitBreakerAspect.class, builder -> builder.withMembers(MemberCategory.INVOKE_DECLARED_METHODS));"
would be nice if spring-cloud will ship with this out of the box

Again this annotation is part of Resilience4J, that project should have the hint


Reference URL fix

Title
On the title describe
what you've fixed (or created) with this Pull Request (PR).
Summary
Insert a short (one or two sentence) summary here.
Fixes #Issue_Number

Note: The "Fixes #nnn" syntax in the PR description causes
GitHub to automatically close the issue when this PR is merged.
Remove that line if you don't have issues associated with this
PR. Click on the Guidelines for Contributing link above for details.

Details
Explain your changes, and why you made them. If that
information is already available in the issue referenced
above, just referencing the issue is preferred to copying
the text.
This may not be necessary depending on the scope of the PR
changes. For example, "fix typo in introduction.md" is
sufficient to describe that PR.
Suggested Reviewers
If you know who should review this, use '@' to request a review.

We're having build issues with our CI system. Given the nature of thix, we'll merge the PR without validation. Thanks again @AlQuraian. Your fix should go live in the next day or so.


msi_pc\Python3.9.10\Lib\site-packages\finrl\applications\stock_trading.py To fix the issue of overlapping dates on the x-axis

overlapping dates on the x-axixs are not readble Can you help me how can i fix it?

At the moment, you can rotate the xticks by setting the parameter “xrotation=20” of the plot function (FinRL/finrl/plot/plot_result), although this may still not achieve the effect you want. Further improvements may require modifying the source code.

pls try functions of finrl.plot, or write your own functions as reference.


Set border-color to currentColor by default; resolves #638.

Based on @mrmrs comment in #483, I believe we have been counting on the browser to set the border color to currentColor for all elements by default. However, this appears to be the case only for certain elements. This change will restore currentColor as the default border color for all elements that include a border base class.

You can use inherit to override buttons.


Update to Ghost 5.0 route versioning

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


fix(fonts): update fonts dependencies

Update base image to Ubuntu 20.04
Use precompiled ttfautohint (1.8.3)

Remove build-related tools: wget, man-db, pkg-config

Use Python 3
Update fonttools to 4.21.1

There are subpixel changes to the screenshots: diff.zip.

Codecov Report

Merging #2866 (8ea1585) into master (fe21971) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 8ea1585 differs from pull request most recent head 45648ab. Consider uploading reports for the commit 45648ab to get more accurate results

@@           Coverage Diff           @@
##           master    #2866   +/-   ##
=======================================
  Coverage   93.92%   93.92%
=======================================
  Files          87       87
  Lines        6326     6326
  Branches     1308     1308
=======================================
  Hits         5942     5942
  Misses        354      354
  Partials       30       30

Continue to review full report at Codecov.

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

This PR is ready for review.

@ylemkimon I'm happy to take a look at this now. Could you resolve the conflict / update the screenshots?

@ylemkimon It would be nice to get font building working again. Do you have some time to look at this, or should I try to fix it myself?

Codecov Report

Merging #2866 (45648ab) into master (0371a1c) will decrease coverage by 0.01%.
The diff coverage is n/a.

:exclamation: Current head 45648ab differs from pull request most recent head a9cbcf0. Consider uploading reports for the commit a9cbcf0 to get more accurate results

@@            Coverage Diff             @@
##           master    #2866      +/-   ##
==========================================
- Coverage   93.94%   93.92%   -0.02%
==========================================
  Files          87       87
  Lines        6344     6326      -18
  Branches     1314     1308       -6
==========================================
- Hits         5960     5942      -18
  Misses        354      354
  Partials       30       30

Impacted Files
Coverage Δ

src/functions/utils/assembleSupSub.js
95.00% <0.00%> (-1.16%)
:arrow_down:

src/environments/cd.js
98.31% <0.00%> (-0.85%)
:arrow_down:

src/functions/operatorname.js
96.72% <0.00%> (-0.06%)
:arrow_down:

src/functions/genfrac.js
94.39% <0.00%> (-0.06%)
:arrow_down:

src/MacroExpander.js
97.82% <0.00%> (-0.05%)
:arrow_down:

src/Parser.js
96.24% <0.00%> (-0.02%)
:arrow_down:

src/environments/array.js
98.31% <0.00%> (-0.01%)
:arrow_down:

src/macros.js
97.28% <0.00%> (-0.01%)
:arrow_down:

src/Lexer.js
100.00% <0.00%> (ø)

src/symbols.js
100.00% <0.00%> (ø)

... and 2 more

Continue to review full report at Codecov.

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

@edemaine Sorry for the delay. This PR is ready for review.

It seems that buildFonts.sh doesn't run buildMetrics.sh.  Do we not have a Dockerized buildMetrics.sh?  It would be nice to include, perhaps in a future PR.

Another update: Should we add scripts for build:fonts and build:metrics or something along those lines?  Having them in the scripts list makes it more obvious that they exist.

@edemaine Thank you very much!

Oops, maybe this should have been chore instead of fix, but not a big deal. 🙂 We'll have a bunch more releases with actual font-based features soon.

@edemaine Since fonts are updated, a patch release makes sense.


Change way types are stored and represented + allow for more than u16::MAX types

Currently all types are currently held under a single Vec<Type>, and TypeId is pointer into this vector. TypeId is a wrapped for a u16. To support larger files/codebases this needs to increase

Currently the sequential ids require the whole program to be checked (from a starting point). Adding more incremental parts will create problems if an intermediate file is changed. TypeId has to be split between libraries/files somehow.

Also from #103: Adding versioning or something to the binary format that can be checked on deserialization. This is because new versions of the compiler might have a different representation in byte form (new fields, removed enum members, etc) that isn't compatible to be parsed with binary files generated by older compilers

Quick thoughts:
Considering struct TypeId { block: u16, offset: u16 }. Where BlockId points to a collection of Vec<Type> that can span multiple files / packages. But each block only contains types per module so that invalidations have a limited effect or something.

I think the first thing is to split types apart.
TypeId should be InterfaceTypeId | ConstantId | FunctionId | ... with each of them having their own Vec
Could try splitting types that an expression can represent from conventional types again at some point. Although makes subtyping less simple

Worth considering whether Type::And and Type::Or should be Vec rather than binary tree

Additionally for Type::Object(AnonomousObjectLiteral) it would be great if the properties could be inline rather than on through environment (they are fixed for this type, can't be modified or merged)


Add support for compare-and-set option while creating k/v secret

Hi,
According to the VaultKeyValue2Template implementation whole body argument of the put operation is treated as data section of  create payload, while my use-case require to pass options.cas parameter, because I need strong consistency while using K/V secret storage.
Could put operation accepts optional parameter for options part, which would be included in creating payload for the Vault ?
Current workaround
Manually call Vault API with payload, which includes options section:
vaultTemplate.doWithSession((restOperations) -> {
            return restOperations.exchange("secret/data/my-secret-with-cas", HttpMethod.POST,
                            new HttpEntity<>(Map.of(
                                                         "options", Map.of("cas", 0),
                                                         "data", Map.of("value", "secret-value"))),
                            VaultResponse.class)
                    .getBody();
        });

Please let me know what you think.
More
Vault API reference: https://www.vaultproject.io/api-docs/secret/kv/kv-v2#create-update-secret

Thanks @mp911de for the hint - that obviosuly addressed my requirements.


Make SyncResultRoom's srrJoin optional

The spec doesn't specify it as required and synapse apparently omits
it, if no events in joined rooms are returned.

Thanks!


Web - Task - Apostrophe character doesn't display correctly on chat history

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: v9.0.57-7
Reproducible in staging?: Y
Reproducible in production?: Y
Email or phone of affected tester (no customers<EMAIL_ADDRESS>Issue reported by: Applause Internal Team
Action Performed:

Go to https://staging.new.expensify.com/
Go to any existing chat group
Click on the "plus" button on the chat
Click on "Assign Task"
Create a Task with a Title containing an apostrophe

Expected Result:
The apostrophe character is correctly displayed on the chat history
Actual Result:
On the chat history the apostrophe character is not displayed correctly, instead there is a placeholder text "'" replacing it.
Note: when going inside the task report, the apostrophe character is correctly displayed.
Workaround:
Unknown
Platforms:

[ ] Android: Standalone
[ ] Android: HybridApp
[ ] Android: mWeb Chrome
[ ] iOS: Standalone
[ ] iOS: HybridApp
[ ] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
https://github.com/user-attachments/assets/d841b394-4a6e-460e-8ee5-46a109fad878

View all open jobs on GitHub

Proposal
Please re-state the problem that we are trying to solve in this issue.
if task title has ' in it, it will &apos instead of '
What is the root cause of that problem?
we are encoding but later not decoding the task title here:
https://github.com/Expensify/App/blob/4dc7fd7f4beee25510405f2a50c8d7e10b33b7fe/src/components/ReportActionItem/TaskPreview.tsx#L77
What changes do you think we should make in order to solve the problem?
change this: https://github.com/Expensify/App/blob/4dc7fd7f4beee25510405f2a50c8d7e10b33b7fe/src/components/ReportActionItem/TaskPreview.tsx#L133
to :
                   <Text style={titleStyle}>{Str.htmlDecode(taskTitle)}</Text>

We aren't prioritising any Task bugs @IuliiaHerets - closing.


Add support for Python remote debugging

In order to support Python remote debugging, we need to generate a different debug configuration so that the appropriate debugger is launched.
See microsoft/vscode-azureappservice#1148 and microsoft/vscode-azurefunctions#1488 to see how this is used.

Actually this would be a breaking change to the signature of startRemoteDebug. Please update the minor version in package.json and package-lock.json (we use minor for breaking changes until we're ready for 1.0.0)

Sorry for the delay. The minor version is now updated.


Not able to get the org.springframework.sbm eclipse plugin

Firstly, many thanks for spring-boot migrator
Am trying to integrate the spring boot migrator in either IntelliJ and STS from the steps provided in ide-integrations/eclipse/com.vmware.bootifier and trying to expose SBM as a REST service.
However, being unable to find the 'org.springframework.sbm' eclipse plugin, could you please help me.
Your help is greatly appreciated.
Thanks,
Mahi

Hi @bsmahi,
thanks for trying SBM.
Looking at the README I think com.vmware.bootifier needs to be renamed to com.vmware.sbm and then it's the plugin mentioned to be under <SBM Root Folder>/ide-integrations/eclipse/org.springframework.sbm. The REST Service was changed too. Nevertheless, I think you could get this working again...
Besides these there were other efforts targeting IDE integration:

There's a spike for WebSocket communication so that the backend can publish messages to the client.
@BoykoAlex is actively working on an OpenRewrite integration behind a Spring Language Server for STS where I could see SBM fit into one day.

If you’re serious about looking into an IDE integration for SBM we’d be glad to take contributions.
I’d see the WebSocket integration as a natural first step as WebSocket can also be used with LS protocol.
The important advantage over REST is the ability for simple notifications sent from the backend to the client which is important for things such as status updates for long-running recipes or recipes that require user input.
Feel free to reopen the issue in case you need further assistance or want to discuss IDE integration.

Hi @fabapp2,
Sure thanks for your reply :). I will explore further.
Sure, am happy to contribute in IDE integration and will work with @BoykoAlex.
By the way, have given one Pull Request for code improvement have done for Spring Spell module (https://github.com/spring-projects-experimental/spring-boot-migrator/pull/713)
@BoykoAlex could you please let me know how to pick up this task, am happy to connect with you as well.
Thanks,
Mahi


ODBC Doc

Hey all,
I updated the ODBC documentation. It was spited off into separate files for Linux and Windows setup.

I just had a read through it and it looks good! There are one or two small typos (I saw a DuckBD in there... ;-) ), but I can make those edits after this gets merged if that's the easiest way.
I had a couple of small thoughts. Do you think you could add a sentence or two about where ODBC can be used in the introduction section? That will help folks understand when they should use ODBC vs. another method like JDBC.
Maybe it would belong in a blog post, but a few screenshots to get DuckDB up and running in a business intelligence tool (Excel, Power BI, Tableau, etc.) would be really helpful to folks that are just getting started!

Thanks for all the changes! This seems ready to merge now.


Release new version of Intercity-Docker

This has been prepared in: https://github.com/intercity/intercity-docker/pull/18

We released version 0.4.0 of Intercity Docker


Please invite me to the Recode-Hive GitHub Community Organization

Name
Sundaram Agnihotri
Discord Username (if applicable)
No response
Additional Context
No response

Invitation sent to join the GitHub Organisation. Welcome to the community 🎉
Don't forget after accepting to make it public so it appears on your GitHub profile for everyone else to see. You can do this by finding your name in the GitHub organisation list and change the dropdown to public https://github.com/orgs/recodehive/people


AWS: Automated deployment

As a developer
I want to develop my AWS application
without a high risk of production issues in case of a bug.

We may introduce an AWS test stage in order to be able to test changes to the AWS application efficiently.
We may introduce a CI stage that is triggered only on changes within the AWS path and that automatically deploys the aws application to the test stage.
We may run our e2e tests against the AWS test stage.
We may automatically production deploy on a merge to main.

Limitations:

Multiple PR modifying the AWS application may interfere with each other.

Local testing is not supported for WebSocket APIs

Based on our findings in #218, this issue became obsolete and won't be tackled (in the current form). Therefore, I am closing it for now.


Loan request: Add different states to loan request page

When requesting a loan for a document, the user should see different states depending on the circumstances. Currently there are 2 states:

User is not logged in, (s)he has to sign in to be able to request a loan.
User is logged in and has no requests on the document, (s)he should be able to request a loan.

The goal is to add 2 new states:

User is logged in and already has a request for that document, (s)he should have a link to redirect him to the Your loans page and not have the request button available.
User is logged in and has a current loan active on the document, (s)he should be able to apply for an extension.

Potential enhancements:

If the user already requested a loan of the document in the past, display You requested a loan of this book 1 year ago

Tasks

[ ] Modify the component to display different states depending on the circumstances.
[ ] Display message if user requested a loan in the past.

Backend task: https://github.com/inveniosoftware/invenio-app-ils/issues/482

A sketch of the different states (correct me if anything is wrong):

We shall also include all the relevant informations in the two new states (dates, etc.).

https://github.com/FlorianCassayre/react-invenio-app-ils/tree/loan-request


[Question] [iOS] Image shared does not have the right permission in the app?

After trying for several hours, I finally get this module working. I have a React Native app that is powered by Expo bare workflow. I cannot figure out how to install Expo pods into the share extension, thus I will need my app to handle all the logic instead of the share extension.
So far when sharing both text and image, the share extension can evoke my app without problem. I have patched manually with this PR https://github.com/meedan/react-native-share-menu/pull/158 to support multiple images. So far when the app is launched, the data field is empty, but extraData field can be used. I then pass image data through extraData field, but when in the app, it seems the path of the image cannot be loaded. How can I debug permission issue? Thanks!

@xmflsct Can you run in real device?. When I run in Release mode, I can't show share view.  It only shows me a blank screen

Turns out that it is indeed a permission issue. I need to copy the file to a cache place that is shared among app within the App Groups, then React Native can assess it properly. See https://github.com/itinance/react-native-fs/issues/640.

@mircogrosch yes I just test it through TestFlight and it works on real device. Though it currently only gets data when the app is fully closed. Need to figure out why the app does not receive data when it is running in the background.


ERROR in ./node_modules/react-big-calendar/dist/react-big-calendar.esm.js 6:0-62

Check that this is really a bug

[X] I confirm

Reproduction link
n/a
Bug description
On a fresh install of react-big-calendar and rendering with the most basic example, I am immediately getting this error and it won't render. Please assist.
Module not found: Error: Package path ./helpers/esm/callSuper is not exported from package ../node_modules/@babel/runtime
Expected Behavior
Renders the calendar
Actual Behavior
Fails
react-big-calendar version
1.11.2
React version
18.2.0
Platform/Target and Browser Versions
macOS
Validations

[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
[X] Make sure this is a react-big-calendar issue and not an implementation issue

Would you like to open a PR for this bug?

[ ] I'm willing to open a PR

Having the same issue on a next.js 14.0.3 typescript app with node 18.17.0

Having the same issue on a react typescript 18.2.0 app with node 18.13.0

Same here.

same here react ^17.0.2

npm i @babel/runtime
Running this has fixed this issue. But the style (CSS) is not loading

@peterzanetti  do you find any alternative? I have to submit the calendar event today. feked up :(

@Jobin-S You can lower the version to 1.8.7 to temporarily solve this problem  :)

I had the same problem. Update to the latest version of @babel/runtime, then update Big Calendar. Check if another @babel directory exists inside your react-big-calendar directory and delete it.

Looks like this was introduced in v1.10.1 with the updates to yarn.lock

same problem here, did you find any solution?

Please see @marcocinus91 comment above for the solution to this issue.

I solved it by adding "@babel/runtime": "^7.24.6" to the resolutions. When running yarn install, it removed duplicate (stale) entries. After that I removed the "resolution" and it still works.
"resolutions": {
  "@babel/runtime": "^7.24.6"
},

npm i @babel/runtime
Running this has fixed this issue. But the style (CSS) is not loading

importing the styles as stated here fixed this


Move utils and components into this repo

SUITCSS could be developed as a monorepo to easy versioning and toolchain setup. This wouldn't stop us being able to publish to the individual npm packages.

Are you thinking releasing SUIT as an entire package each time a change is made, instead of per component/util? Would definitely ease issue reporting and PRs I expect

Yeah. And should make development easier in general. It's a suggestion, as I won't be able to put time into it myself. Just to say that I'm not militant about the multi-repo approach.

Sounds like a sensible idea to me. I feel it could even remove the need for separate npm packages, just encourage users to npm install suit and then import the components/utils needed from within. If any of them change then publish a new version of whole thing.

I feel it could even remove the need for separate npm packages, just encourage users to npm install suit and then import the components/utils needed from within.

@simonsmith My only concern there is always having to upgrade all changes. E.g. if you wanted the latest compontents-grid but didn't want to mess with anything else.
In reality, probably not a huge deal, but if the amount and/or complexity of components grow in the future, maybe something to consider.

If we had all the components within suit how would we publish separate releases of each? I know you can use dist-tags in npm but don't you still need to point it at a single git tag? If it was all under one repo then it could get messy.

One thing I find refreshing about the individual repositories is that it's easy to get up to speed fast, since there is less information to cover.  If you want to get up to speed by reading through issues in order to understand the design, it's less intimidating than having one monolithic project.  There are also less files to wade through when understanding the build, tests, etc..  More here:
https://github.com/substack/browserify-handbook#module-philosophy
Having one to one correspondences between the NPM package and the corresponding github repository is what most of us are used to.  The README for the NPM package corresponds to the README at the root of the github repository, etc.

I could go either way on multi-repo vs. one, but I think the npm packages should definitely stay separate.

So as @necolas says in this PR, managing a PostCSS build system across so many different repos is going to be a real hassle. For example, to work on SUIT I had to run a script to checkout the entire org, which is just working round not having everything in one repository.
Based on that I'd be keen to move this issue along. Some points to clarify:

All the packages remain on npm as separate. I think this makes a lot of sense.
Should we do away with per-package build scripts? Might make sense as usually if you want just a couple of packages you have a build step already in place. For those wanting to build the whole SUIT library then cloning this repo and running npm run build will do the job.
How do git tags work within this repository once it's all under one roof? Should we just push a new version any time one of the packages changes, as well as maintaining the npm tags of each package?

I started a local branch already to fix this issue.
I am organizing the folders as follow:
.
├── doc
├── base
|   └── index.css
├── component
|   ├── arrange
|   |   └── index.css
|   ├── grid
|   └── ...
├── util
|   ├── text
|   ├── size
|   └── ...
├── theme
...
└── ...

Should everything go under a lib/ folder?
What do you think about using the singular form for the folders names?
@import 'component/arrange';
@import 'util/text';

Do we still need the shortcut packages components and utils in this setup?
Maybe, TBD.
All the packages remain on npm as separate. I think this makes a lot of sense.
Yes.
Should we do away with per-package build scripts? Might make sense as usually if you want just a couple of packages you have a build step already in place. For those wanting to build the whole SUIT library then cloning this repo and running npm run build will do the job.
Yes, it makes sense since they are published on npm as separate.
How do git tags work within this repository once it's all under one roof? Should we just push a new version any time one of the packages changes, as well as maintaining the npm tags of each package?
We'd tag suit as a whole (versions are free : ) and maintain the npm tags of each package.

Looks good @giuseppeg

What do you think about using the singular form for the folders names?

I'd vote to keep it components just to align with npm, which is hopefully where most people will install from anyway

Should everything go under a lib/ folder?

I don't think this is necessary.
Are you adding the PostCSS build steps in this branch?

Are you adding the PostCSS build steps in this branch?
To each single package? I could or maybe it is better to just make the monorepo and refactor the build in a followup.

Ah yeah, sorry I didn't mean to each package. That would be quite a chore. Yeah, let's do the PostCSS switch as a separate task.

I'd vote to keep it components just to align with npm
Would you repeat strip it from the pkg name?
`components/component-arrange/` vs `components/arrange/`

I think your idea of components/grid, components/arrange etc is good +:1

Should the parent packages suit, components and utils depend on the local ones
"dependencies": {
    "suitcss-components-grid": "file:./components/grid"
}

for example — or the ones published on npm?
If so how do we publish them to npm?

Hmm, good question.
I suppose one route is to bring back lib:
components
├── README.md
├── index.css
├── lib
│   ├── arrange
│   ├── button
│   └── grid
└── package.json

That would enable lib to be ignored by git which npm would also respect, then components could still be published and so could the individual component directories.

Do we still need the shortcut packages components and utils in this setup?

Since we're moving to a PostCSS ecosystem, that leads itself to using postcss-import, in which a user could do:
@import 'suitcss/components/**/*.css'
@import 'suitcss/utils/**/*.css'

So I vote to drop the shortcuts ('utils', 'components') Plus maintaining them could be a chore.

Hmmmm...it sounds like publishing multiple npm packages from a single repo is not as easy as I thought it might be: https://github.com/npm/npm/issues/2974

This wouldn't stop us being able to publish to the individual npm packages.

@necolas I'm pretty sure I've seen other repos do this, but I think it requires some build script magic. Do you have any examples?

@timkelty

I'm pretty sure I've seen other repos do this, but I think it requires some build script magic. Do you have any examples?

Lodash does it, also, it's worth to take a look to the amp project.

I think @timkelty's idea could work there. postcss-import supports globbing and looks in node_modules by default.
It's also probably good practice to encourage users to install what they need

@timkelty @giuseppeg Added postcss as the build task in the wip branch. It raises a couple questions:

Should the top level index.css include custom media properties to stop the media queries for the size utils being stripped from the output?
What happens to the test pages if we take away per package build tools and the gh-pages branches? Do we consolidate this under a single page on the SUIT site?

@simonsmith awesome looks good, thank you!
From now on I suggest that we branch off suitcss/suit/tree/monorepo when we want to try new things and merge or patch it when it makes sense i.e. use the wip branch as "master" and the experiments as feature/patch branches.
stop the media queries for the size utils being stripped from the output
This is not a new issue right? If so I wouldn't try to solve it here.
What happens to the test pages if we take away per package build tools and the gh-pages branches? Do we consolidate this under a single page on the SUIT site?
Each package should still have a `build` script and tests in my opinion (like you did in suitcss/components-button#19)
Now that I think about this maybe we shouldn't use local paths in package.json and revert my change.
We could add a test.css file at the root of the project and import the local files.
Before releasing a new version we would preprocess test.css to make sure that nothing breaks.

Nice work, @simonsmith.
My first thought is we might want base, components, utils, theme nested under a folder. Could be lib (following other suit repos), or css or whatever. Just to keep the actual guts of the project separate from say, doc.
What do you all think?

I thought the build and test tooling was going to be handle at the top level in the mono-repo, not per-package.
If we don't do that, I'm not sure what we're gaining by going with the mono-repo approach? (feel free to remind me :))

@timkelty with the mono-repo you can make a change to all the README.md for example and make just one commit instead of having to clone n repos and do it one by one.
Considering that we are going to publish the single packages on npm, each pkg still needs a build script and tests because it is standalone.

From now on I suggest that we branch off suitcss/suit/tree/monorepo when we want to try new things and merge or patch it when it makes sense i.e. use the wip branch as "master" and the experiments as feature/patch branches

I'm not really fond of the develop branch style if it doesn't add much. Pushing a feature branch whenever needed seems to work okay.

This is not a new issue right? If so I wouldn't try to solve it here.

You're correct, but I always wondered if it was a bug and it's even been reported before. It does start to step on the toes of theme but it does seem odd for a load of console warnings to be normal.
With regard to the per package build scripts, I did also raise about per package build scripts earlier in this issue and it sounded like the idea would be to ditch them. @necolas also pointed out that it will be a chore to maintain the pipeline across so many repositories. I think one of the big wins of a single repo was to keep the build script in one place, and if people want to use individual packages then it's very likely they'll just import them into an existing postcss pipeline. If not, we can certainly encourage this.
It may not be feasible with the need for testing the components though, so not sure how to proceed on this. Losing the gh-pages branches kind of destroys this too, even with per package build scripts in place

I'm not really fond of the develop branch style if it doesn't add much.
It keeps the git history clean, no need to revert if we reconsider some choices. Not a big deal though ;)
and if people want to use individual packages then it's very likely they'll just import them into an existing postcss pipeline.
Agreed!
I'll try to think of a way to keep the tests on the repo.

It keeps the git history clean, no need to revert if we reconsider some choices

I am equally OCD about a good history :)
Won't we be all good if we keep stuff in branches, tested and agreed before bringing it into master?
In terms of the tests, I guess ultimately they are no more than just static pages. We could just generate them for each repo with a build step and then they can be viewed locally. They won't be public pages on gh-pages but maybe we could instead create a more user-friendly page on the SUIT website that had examples of each component and utility.

Build them as static files sounds good, although that may not necessarily reflect their actual state when the user uses customizes em (eg. defines custom mq, gutters etc.) <- maybe a non-problem though.

What do you all think?

Yeah, sounds like a good idea @timkelty. I'm down with lib.

Done in latest commit. I figure this might make it easier to use things like glob as well.

Just to update on this, I think we're heading along the route of keeping the repositories as is, and re-factoring the preprocessor to use postcss. This was off the back of a spike @giuseppeg has spent some time on.
More info on this in this issue - https://github.com/suitcss/preprocessor/issues/11#issuecomment-157006922
Here is the PR for reference too - https://github.com/suitcss/preprocessor/pull/12

Just ran across this, which was interesting: https://github.com/babel/babel/blob/master/doc/design/monorepo.md

Oh nice find. Yeah, I think it's a smart way to go from the start.

Yeah - I still think it is an attainable migration for SUIT, but right now I'd rather just plow away with the packages/repos as is.

On gitter there was talk about dropping support for bower being a factor.

I don't really think this should be a concern. IMO bower being "dead" is more or less true, and it is always still possible to install any arbitrary repo with bower. Furthermore, our other npm packages, while deprecated, wouldn't be going anywhere.
With the PostCSS migration, we're expecting/encouraging users to have thier own postcss toolchain in place anyhow, so there's really no need for bower (no need to have the suit source css in a public web root).

In superfly-css I've implemented a standard directory layout superfly-css-pli, along with self contained gulp tasks (Example superfly-css-task-build ), that I think reduce the weight of, if not eliminate, most of the arguments cited by babel for maintaining a monorepo.  Simple focused repositories are easier to manage and get up to speed on from a dependency, core concern / boundary, and information volume standpoint.

I personally think giving up the issue and git commit history is too big a sacrifice just on its own, basically destroys git blame and the tags too.
I can 100% see the value in it from the start of a project though.

Should we close this issue?
cc @simonsmith @timkelty

Yep

Yep!


⚠ Bofrost.at has degraded performance

In 96499ca, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1442 ms

Resolved: Bofrost.at performance has improved in cdd5d46 after 27 minutes.


feat(observability): OpenTelemetry logs

Description
docs for https://github.com/Kong/kong/pull/13291
Testing instructions
Preview link:
Checklist

[x] Review label added
[x] Conditional version tags added, if applicable.

ready for review @Kong/docs-maintainers along with: https://github.com/Kong/docs-plugin-toolkit/pull/38 - thanks


[integration tests] skip whole module if not all env. variables set

also, how the F did you push into Honza's branch? Are you a magician?

@TomasTomecek read the line below the latest comment - slowly & carefully :-)


Update microkit dep & enable debug server

Added debug server exposes net/http/pprof interface in
http://<IP_ADDRESS>:6060/debug.
This helps with profiling running service e.g. when it's OOMing.
Towards https://github.com/giantswarm/giantswarm/issues/4088

Can we merge this?

Hello.

I already gave approval, who are you asking?

The PR is approved since 12 days so I just want to have a communication and want to know why this is still not merged and if we can do it.


HADOOP-17534. Update Jackson to 2.10.5 and Jackson databind to <IP_ADDRESS>

JIRA: https://issues.apache.org/jira/browse/HADOOP-17534

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
1m  9s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m 26s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
23m 11s

trunk passed

+1 :green_heart:
compile
25m 14s

trunk passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
compile
21m 18s

trunk passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
checkstyle
4m 10s

trunk passed

+1 :green_heart:
mvnsite
2m  2s

trunk passed

+1 :green_heart:
shadedclient
22m 23s

branch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
1m 25s

trunk passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
2m  5s

trunk passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+0 :ok:
spotbugs
2m 37s

Used deprecated FindBugs config; considering switching to SpotBugs.

+0 :ok:
findbugs
0m 29s

branch/hadoop-project no findbugs output file (findbugsXml.xml)

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 40s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m 13s

the patch passed

+1 :green_heart:
compile
24m 58s

the patch passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javac
24m 58s

the patch passed

+1 :green_heart:
compile
19m 53s

the patch passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+1 :green_heart:
javac
19m 53s

the patch passed

+1 :green_heart:
checkstyle
3m 59s

the patch passed

+1 :green_heart:
mvnsite
2m  3s

the patch passed

+1 :green_heart:
whitespace
0m  0s

The patch has no whitespace issues.

+1 :green_heart:
xml
0m  1s

The patch has no ill-formed XML file.

+1 :green_heart:
shadedclient
15m 34s

patch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
1m 26s

the patch passed with JDK Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
1m 58s

the patch passed with JDK Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

+0 :ok:
findbugs
0m 26s

hadoop-project has no data from findbugs

_ Other Tests _

+1 :green_heart:
unit
0m 25s

hadoop-project in the patch passed.

-1 :x:
unit
17m 25s
/patch-unit-hadoop-common-project_hadoop-common.txt
hadoop-common in the patch passed.

+1 :green_heart:
asflicense
0m 47s

The patch does not generate ASF License warnings.

212m 59s

Reason
Tests

Failed junit tests
hadoop.ha.TestZKFailoverController

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2708/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/2708

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml

uname
Linux 14fcb903c7e8 4.15.0-126-generic #129-Ubuntu SMP Mon Nov 23 18:53:38 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 25af8901a97

Default Java
Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.10+9-Ubuntu-0ubuntu1.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_282-8u282-b08-0ubuntu1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2708/1/testReport/

Max. process+thread count
1252 (vs. ulimit of 5500)

modules
C: hadoop-project hadoop-common-project/hadoop-common U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2708/1/console

versions
git=2.25.1 maven=3.6.3 findbugs=4.0.6

Powered by
Apache Yetus 0.13.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

Merged. Thank you @jojochuang

I ran TestZKFailoverController locally and it passed.


Verify/update BIDS Derivatives compliance

Need to add a dataset_description.json and a .bidsignore. Currently I believe all derivatives will be in .bidsignore.

Need to add a dataset_description.json and a .bidsignore. Currently I believe all derivatives will be in .bidsignore.


Make JsonPostProcessor (and perhaps others) public

Hi,
I've been using your work for interfacing with the mess that is Patreon's API, and it's been a lifesaver. Thanks !
I'm currently investigating Patreon's Webhooks. I'll gladly share my work with you later on (the small piece of code to verify a webhook's signature is especially valuable, despite being simple - it's the least I can do), and I was going to try and deserialize the body using your data structure and your deserialization algorithm.
Yet, as JsonPostProcessor is declared "internal", I can't do so, sadly :( I'll copy the class in my own project for now, but making that class public would allow us to parse data obtained from patreon in ways not yet supported by your project.
What is your opinion on this ?
Again, thanks for all this :)

As this stuff is very much explicit to the Patreon API, I dont see the use cases for it to be publicly available.
What exactly is the use case you are implementing, which requires this stuff? Maybe it makes more sense to just implement those features as part of the Patreon.NET lib, as it might be needed by multiple people and is hardly patreon related anyway?

Well, i'm subscribing to Webhooks, and the body of the webhooks are really models you have already implemented and parsed. The pledge create webhook is sending you a serialized Member in its body.
By copying your JsonPostProcessor class into my solution, it enabled me to do this, for instance :
            // Verifying webhook signature and all before processing, ommitted for clarity purposes here
            var jsonSerializer = new JsonSerializer()
            {
                NullValueHandling = NullValueHandling.Ignore,
                MissingMemberHandling = MissingMemberHandling.Ignore
            };

            if (!JsonPostProcessor.Process(JObject.Parse(body), out JToken dataToken))
                throw new Exception("Unexpected or unparsable data");

            var member = dataToken.ToObject<Member>(jsonSerializer);

All in all, this changes enables us consumers to support raw data obtained from Patreon through any means that isn't implemented yet in the library. Webhooks being the one i'm thinking of right now (I have no idea how to generalize webhook support in your library - you need the raw body and all to check the signature).

As this webhook subscribing stuff is part of the Patreon API, I think it should be directly implemented and supported in this lib.
I also think in case Patreon changes or adds something, developers should better implement the new stuff or changes directly in the lib for everyone instead of doing their own thing using the internal stuff of the lib.
Just my 2 cents on the topic :D

Oh, I agree fully with you. But submitting your work to a public API in a lib like this tends to be scary (at least for me). Will my code be up to the standard this lib wants to stick to ? I submitted two small changes on public projects personally ( oxyplot and next-auth, the latter being adding an Oauth2 provider for Patreon actually ), and that was quite an emotional ride !
I was just suggesting a change that enhanced functionality at no cost for the lib, without resorting to what is, ultimately, a code smell (like me copying the class into my project).
I've got the signature validation nailed down, and subscribed to the one webhook event I need for my project. Once that's launched (as I need to prioritize this for... obvious reasons ;) ), i'll see if I can't generalize my work and submit it as a PR. Nervously !

I can completely relate to your feelings. Thats what the complete Pull Request system exists for, the maintainer / contributors can review your code and suggest changes in case it doent fit the repositories coding styles or contains any bugs.
In my opinion changing those parts to be publicly available just breaks the overall design and purpose this lib exists for, its meant as a lib for consumers of the Patreon API and not people that want to use it as a base to basically implement patreon API stuff themselves.
I guess it should never really be the case that people would want / need to implement anything from the Patreon API on their own because the lib doesnt contain it. This lib needs to be either feature complete or the devs that miss something need to open PRs to allow the changes to be implemented in the lib for everyone to use - as every dev that would use those very internal code parts would ultimatively just enhance the lib anyway in some way that others would profit from.
Basically that small change would just suggest wrong usage and behaviour (in terms of giving back to this public lib 😁)

Sorry for taking so long to see this! Yeah, ideally this library should handle everything in the Patreon V2 API. I initially wrote this because I needed it for a separate project and I unfortunately have more urgent things to do than to implement the rest of the endpoints like webhooks at the moment. I'm not heavily experienced with public collaboration as well so don't hesitate to throw your changes in here. Being worried of your own work not being up to snuff means you're at least intending to write good code so don't stress about it too much!

Will close this since it's been over a year without any discussion


Backport "PHP: avoid destroy channel more than once" to v1.31.x

Backport #23567 to the v1.31.x branch.

The errors are unrelated to this PHP change.


Long-polling pins constitute a data race

While pins == 0, any intercedent updates won't be received by any connected ratchet.
This is starting to sound a lot like consensus, and any efforts should be carefully weighed against simply transitioning to an architecture that supports consensus.

Possibly the best solution would be to discount multiple ratchet associations to ratchet-pawl then poll-directed updates could be lockstepped to user-induced changes. Then config/policy consensus across the cluster could be entirely the responsibility of pawl.


Can we declare this dead?

I see plenty of PRs and Issues open. It seems like the maintainer hasn't updated this in 3y.
I love this theme.
Can we branch it and revive it?

Can we branch it and revive it?

If you have required knowledge and time to make "zzo great again", it would be great.


registerValidator to use array of entries

Update registerValidator to accept an array of entries (in line with the beacon-API: https://github.com/ethereum/beacon-APIs/blob/master/apis/validator/register_validator.yaml)
Using an array would be particularly useful if there's a lot of validators using the same CL/mev-boost instance. Since mev-boost regularly resends the validator registration to the relays/builders, it would only need one call per relay instead of potentially thousands (one per validator).

I'm not sure I see the value in the array implementation here.
In the event that some builder endpoints end up being gossiped, I have a hard time seeing that an array is the proper choice. Both from a privacy (simply tying these together as one) as well as load and other complexities.
E.g. you'll need anti-dos mechanisms for such a gossip path and putting N of these messages together means you have to say things like "none of the  validators in the list of registrations has submit a registration in the past T seconds".

I don't think the array here is a must-have, just thought it would be more elegant in case of thousands of validators, where all those requests could be combined into a single API call to the relay.
If this negatively impacts a future p2p design then let's not do it, I didn't think the REST API semantics would have an effect on that.

An additional benefit is that the BN can just proxy the request from the validator (which already comes as an array), instead of needing to split it up into multiple individual calls.

I'm fine with his as long as this design does not creep into future gossip designs (if/when gossip replaces some relay functionality).
Additionally, I would encourage relays to not blindly forward this request but instead to allow for queries that do not explicitly tie validators togthr as they wre sent to the relay

Yeah I think we can move ahead with this PR and possibly add a note that it is highly encouraged for relays to turn a batch of N into N batches of 1 to help w/ validator privacy

Yeah I think we can move ahead with this PR and possibly add a note that it is highly encouraged for relays to turn a batch of N into N batches of 1 to help w/ validator privacy

Makes sense. If a validator cares very much about this privacy, it could also already send the registrations as single items to the beacon node? 🤔

The privacy concern here is a relay/builder learning about IPs of validating nodes. For the purposes of the security risk, the beacon node and validator client are essentially one entity as the beacon node will be the entrypoint for the validator client onto the p2p network.
If I use the builder network from the same IP I send proposals from, then any agent (under the current model, the relays) can make a mapping of validator identity to this IP (c.f. registrations have the pubkey in them). With this mapping, I learn which nodes I need to DoS to add a liveness failure to the chain. Moreover, I can be incentivized to pull off an attack of this sort given a block with very high MEV (where my cost to execute a re-org is subsidized by the MEV profit in the block).
Leaking this information to relays is bad not only because the relays could be malicious (I think we can assume they won't be), but they themselves could accidentally leak the information ("honeypot" scenario) or become a target for attack. Mercenary relays could also simply sell the data to the highest bidder.
The immediate stop-gap solution is to run your beacon node behind a VPN or similar setup where you can periodically rotate your IP. But even this solution has higher complexity than just "staking out of the box" so harms decentralization. Ideally we can evolve the builder specs in a direction where it is much harder to gather this information in the first place.

Thanks for the explanation. Definitely something important to think about and plan for.
Do you see an impact on this whether the registerValidator call sends single items vs an array?

Do you see an impact on this whether the registerValidator call sends single items vs an array?

I think we are fine for now as far as the API goes, if we hit a blocker we can always update it


pull request for e2e test at 01/22/2017 20:15:13

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Document how to write tests unit tests with nested function calls

Most unit tests in Mbed TLS are simple functions that run library code, test assertions, repeat. The basics are well-explained in the knowledge base. You call TEST_ASSERT and it reports failures.
However, there are a number of more advanced things that are not so well documented, if at all.

There are a number of wrapper macros for TEST_ASSERT. They are well-documented, but you need to know where to look.
It is not at all obvious how to report an error from a nested function. Calling TEST_ASSERT twice is wrong because it hides the original location of the error.
It is even less obvious how to report errors from a callback.

The goal of this task is to document the existing facilities. We may well want to improve those facilities, but that's out of scope for this task.

Rather than document the workaround for test_fail overwriting failure information, let's fix that: https://github.com/ARMmbed/mbedtls/pull/3625
Then the naive way of writing tests with auxiliary functions works. A bit of documentation is still required, at least to say that the auxiliary function needs an exit: label.

Since https://github.com/ARMmbed/mbedtls/pull/3625 was merged, the naive way works: call TEST_ASSERT (or anything else that ends up calling test_fail from the auxiliary function, return an error status of some kind from the auxiliary function, and have another TEST_ASSERT or similar in the main function to abort the test. The error will be reported at the first call to test_fail.
Since the naive way works, we don't particularly need documentation. We can add a knowledge base article to the new documentation site when it's up, but there's no particular urgency of importance, so I'm closing this task as done in spirit if not in letter.


Resample bug, see #137

See #137 137

Guess the only thing blocking merging this PR is checking other werkzeug versions!


Make kubefed docs similar to rest of the docs in docs/admin

The title in kubefed autogenerated docs appears twice for some reason (Probably the way, kubernetes.github.io processes the md files).
Example (https://kubernetes.io/docs/admin/kubefed/).
Align these file with other docs/admin files.
Also, update-imported-docs.sh puts only below lines at the top of all auto generated files like below:
---
---

I am assuming, there is some other post process script/tool which actually puts the two lines, for title, for example:
---
title: kubefed options
notitle: true
---

Or it is done manually.
@chenopis, please let me know if this change is ok, or something better option is there.
Actually I did ask the clarification here earlier. It appears to me, that its done manually post importing the docs. If that is indeed the case, We can update the script to update the title lines also.

This change is

/assign @chenopis

@chenopis 👋  LGTM but would appreciate your review on the script changes.

@zacharysarah The script changes look okay.

@irfanurrehman :wave: It looks like Travis/CI is failing, possibly from the issue this PR addresses:
$ ./verify-docs-format.sh
Error: docs/admin/kubefed_init.md doesn't have a proper title defined!
Found 1 files without titles.

Thoughts?
/cc @chenopis

@zacharysarah @chenopis Apologies! I raised this one and then forgot about it. Somehow I did not get a mail notification about the failure too (which I do get for my kubernetes core PRs), else I would have looked at it much earlier.
Updated now!

rebased on latest!


SW-2884 Report list page

I didn't add any report to test this, so probably this will need testing after create flow is finished.
Also, the listReports api doesn't support a query, so I didn't add the search bar. Should we use the search api for that??
Should we support filters too?

shiny ✨

this will need testing after create flow is finished.

So reports are kinda odd in this respect. There isn't a create flow. Rather, reports are created automatically by the backend on a schedule. They can be manually created through the admin page, however, if you are a super-admin


Adding an AI Message Bot #214

So, I have used Gemini AI to create a messaging bot where you have to enter your prompt either it be a text prompt or an image prompt.
You will receive the output given by Gemini.
Issue number - #214

Hi Maintainers,
I've submitted a pull request (PR) and would appreciate it if you could take a look and provide feedback. If there are any issues or changes needed, please let me know so I can address them.
Thanks!


Index Error in dialogs.py ! next ! method

    async def next(self, manager: DialogManager):
        if not manager.current_context():
            raise ValueError("No intent")
        print(self.states)
        print(self.states.index(manager.current_context().state))
        print(self.states.index(manager.current_context().state) + 1)
        new_state = self.states[self.states.index(manager.current_context().state) + 1]
        await self.switch_to(new_state, manager)

When I'm moving states the next method is throwing an index error.
Here is the output with the additional print statements
[<State 'Link[0.0.1:1'>, <State 'Link[0.0.1:2'>]
1
2
Task exception was never retrieved
future: <Task finished name='Task-28' coro=<Dispatcher._process_polling_updates() done, defined at /Users/mac/Library/Caches/pypoetry/virtualenvs/custombot-VvSOzSsp-py3.9/lib/python3.9/site-packages/aiogram/dispatcher/dispatcher.py:409> exception=IndexError('list index out of range')>
Traceback (most recent call last):
  File "/Users/mac/Library/Caches/pypoetry/virtualenvs/custombot-VvSOzSsp-py3.9/lib/python3.9/site-packages/aiogram/dispatcher/dispatcher.py", line 417, in _process_polling_updates
    for responses in itertools.chain.from_iterable(await self.process_updates(updates, fast)):
  File "/Users/mac/Library/Caches/pypoetry/virtualenvs/custombot-VvSOzSsp-py3.9/lib/python3.9/site-packages/aiogram/dispatcher/dispatcher.py", line 238, in process_updates
    return await asyncio.gather(*tasks)
  File "/Users/mac/Library/Caches/pypoetry/virtualenvs/custombot-VvSOzSsp-py3.9/lib/python3.9/site-packages/aiogram/dispatcher/handler.py", line 116, in notify
    response = await handler_obj.handler(*args, **partial_data)
  File "/Users/mac/Library/Caches/pypoetry/virtualenvs/custombot-VvSOzSsp-py3.9/lib/python3.9/site-packages/aiogram/dispatcher/dispatcher.py", line 286, in process_update
    return await self.callback_query_handlers.notify(update.callback_query)
  File "/Users/mac/Library/Caches/pypoetry/virtualenvs/custombot-VvSOzSsp-py3.9/lib/python3.9/site-packages/aiogram/dispatcher/handler.py", line 116, in notify
    response = await handler_obj.handler(*args, **partial_data)
  File "/Users/mac/Documents/PycharmProjects/CustomBot/main.py", line 321, in callback
    await dialog_manager.dialog().next(dialog_manager)
  File "/Users/mac/Library/Caches/pypoetry/virtualenvs/custombot-VvSOzSsp-py3.9/lib/python3.9/site-packages/aiogram_dialog/dialog.py", line 78, in next
    new_state = self.states[self.states.index(manager.current_context().state) + 1]
IndexError: list index out of range

The list should account for the 0th index

Found the issue in my own code.

Task exception was never retrieved
future: <Task finished name='Task-30' coro=<Dispatcher._process_polling_updates() done, defined at /Users/mac/Library/Caches/pypoetry/virtualenvs/custombot-VvSOzSsp-py3.9/lib/python3.9/site-packages/aiogram/dispatcher/dispatcher.py:409> exception=IndexError('list index out of range')>
Traceback (most recent call last):
  File "/Users/mac/Library/Caches/pypoetry/virtualenvs/custombot-VvSOzSsp-py3.9/lib/python3.9/site-packages/aiogram/dispatcher/dispatcher.py", line 417, in _process_polling_updates
    for responses in itertools.chain.from_iterable(await self.process_updates(updates, fast)):
  File "/Users/mac/Library/Caches/pypoetry/virtualenvs/custombot-VvSOzSsp-py3.9/lib/python3.9/site-packages/aiogram/dispatcher/dispatcher.py", line 238, in process_updates
    return await asyncio.gather(*tasks)
  File "/Users/mac/Library/Caches/pypoetry/virtualenvs/custombot-VvSOzSsp-py3.9/lib/python3.9/site-packages/aiogram/dispatcher/handler.py", line 116, in notify
    response = await handler_obj.handler(*args, **partial_data)
  File "/Users/mac/Library/Caches/pypoetry/virtualenvs/custombot-VvSOzSsp-py3.9/lib/python3.9/site-packages/aiogram/dispatcher/dispatcher.py", line 286, in process_update
    return await self.callback_query_handlers.notify(update.callback_query)
  File "/Users/mac/Library/Caches/pypoetry/virtualenvs/custombot-VvSOzSsp-py3.9/lib/python3.9/site-packages/aiogram/dispatcher/handler.py", line 116, in notify
    response = await handler_obj.handler(*args, **partial_data)
  File "/Users/mac/Documents/PycharmProjects/CustomBot/main.py", line 323, in callback
    await dialog_manager.dialog().next(dialog_manager)
  File "/Users/mac/Library/Caches/pypoetry/virtualenvs/custombot-VvSOzSsp-py3.9/lib/python3.9/site-packages/aiogram_dialog/dialog.py", line 78, in next
    new_state = self.states[self.states.index(manager.current_context().state) + 1]
IndexError: list index out of range
[<State 'Link[0.0.1:1'>, <State 'Link[0.0.1:2'>]
1
2

I have a scrolling group. And this is what I get from pressing the arrow to scroll further (From page 1)

What should I execute to scroll further?

It tries to move states when it should just scroll and not create any callback

async def callback(callback_query: types.CallbackQuery, dialog_manager: DialogManager):
    await bot.answer_callback_query(callback_query.id)
    userID = callback_query.from_user.id
    logger.info(f"{callback=}")
    # await go_next(callback_query, None, manager=dialog_manager)
    logger.debug(f"{dialog_manager.current_context().state=}")
    if callback_query.data.startswith("scroll"):
        ...
    # await dialog_manager.start(TmpState.st, mode=StartMode.RESET_STACK)
    await dialog_manager.dialog().next(dialog_manager)

What can I do to scroll and not move states?

It looks that you are calling on next the last window in dialog. Where do expect it to switch?
Please, share you dialog definition

The code is very sophisticated, I will try to comment on some parts
async def register_dialogs(dp):

    states_registry = []
    registry = DialogRegistry(dp)
    for i in MESSAGE:
        if all([i.startswith("Link["), i.endswith("]")]):
            windows = []

            link_length = len(i)
            states = generate_states_of_a_unique_group(
                group_prefix=i.lstrip("[").rstrip("]"), amount_of_states=link_length
            )
            for ii, item in enumerate(MESSAGE[i]):
                order_id_of_list = item.removeprefix("List[").rstrip("]")
                state_ = states[ii]
                states_registry.append(
                    {"key": f"CommandState[{order_id_of_list}]", "value": state_}
                )
                buttons = await buttons_creator(
                    MESSAGE[item],
                    _class=MESSAGE[f"Command[{order_id_of_list}]"],
                    randomness=MESSAGE[f"{item}Randomness"],
                )
                try:
                    if ii == 0:
                        windows.append(
                            Window(
                                Const(MESSAGE[f"Response[{order_id_of_list}]"]),
                                ScrollingGroup(
                                    *buttons,
                                    width=2,
                                    height=3,
                                    id=f"scroll_{order_id_of_list}",
                                ),
                                state=state_,
                            )
                        )
                    else:
                        windows.append(
                            Window(
                                Const(MESSAGE[f"Response[{order_id_of_list}]"]),
                                Back(Const("❌Back"), on_click=go_back),
                                ScrollingGroup(
                                    *buttons,
                                    width=2,
                                    height=3,
                                    id=f"scroll_{order_id_of_list}",
                                ),
                                state=state_,
                            )
                        )
                        logger.info(f"{state_=}")
                except KeyError as e:
                    logger.warning(f"Please, create a {e.args[0]} key")
            logger.debug(f"{windows=}")
            registry.register(Dialog(*windows))
            logger.info(f"Registered Dialog of {i}")

    for ii in states_registry:
        MESSAGE[ii["key"]] = ii["value"]

    states_tmp = {}

    for iii in MESSAGE:
        if all([iii.startswith("Command["), iii.endswith("]")]):
            command = MESSAGE.get(iii, False)
            if not command:
                break
            else:
                index = iii.removeprefix("Command[").rstrip("]")
                number = int(iii.split(".")[1])
                if 8 <= number:
                    state_ = MESSAGE.get(f"CommandState[{index}]", False)
                    states_tmp[command] = state_
                    if state_:

                        # this is done because if we register the same function more than once,
                        # the function will be overwritten.

                        # Here we access predefined functions from "abstraction_costyl.py" to avoid
                        # Overwriting. Another (general) solution is highly desirable.
                        import importlib
                        module = importlib.import_module("abstraction_costyl")
                        function_ = getattr(module, f"command{number}_")
                        dp.register_message_handler(
                            function_(state=state_),
                            commands=[command],
                            regexp=None,
                            content_types=None,
                            state="*",
                            run_task=None,
                        )

                        logger.debug(f"Registered command {command}")

It looks that you are calling on next the last window in dialog. Where do expect it to switch?
Please, share you dialog definition

It tries to switch states when I press the Scroll arrows

what the hell is this? please stop generating windows and dialogs.
you can use single window and change data inside it on clicks. Another variant is to use subdialogs.
what is the purpose of all this code?

what the hell is this? please stop generating windows and dialogs.
you can use single window and change data inside it on clicks. Another variant is to use subdialogs.
what is the purpose of all this code?

I hope you are not irritated or confused by it.
the purpose is to generate any amount of dialogs, who follow the same structure.
Creating something like a small wiki, where we generate a page, which is linked by many others.
Btw, do you know russian? Maybe I'll explain it better

Let's continue diacussion in telegram: https://t.me/aiogram_dialog


Parametrization of nested objects generation

The behaviour regarding nested objects was described in details in https://github.com/j-easy/easy-random/issues/384. While I do not have doubts that it works as designed, I see the benefits of having the possibility to force it to work differently. I see here two scenarios:

Assume there is a nested object that guards its collections (fields) against null values by initializing them (e.g. in the constructor) with empty collections. As a consequence, it is not possible to have there null field unless reflection is used. However, EasyRandom uses reflection, and when reaching 'randomizationDepth' lefts the fields uninitialized. When using such objects in tests, we face NullPointerException in places where production code will never have them.
Solution: it would be convenient to have the possibility to chose to no to use objects with uninitialized fields and instead on the 'randomizationDepth' -1 level have empty collections.

When the 'objectPoolSize' is close to the number of nested objects, there is a considerable possibility of having infinity recursion, e.g. object A can have list containing among others the object A itself. This is something the production code may prevent by executing some logic, but since EasyRandom uses reflection, can easily overcome such invariants. When using such objects in tests, we may face the infinity recursion.
Solution:  it would be convenient to have the possibility to avoid reusing objects that are already used on the path leading to the root object, at least as long as there are in the pool objects that fulfil the condition.

While I do not have doubts that it works as designed, I see the benefits of having the possibility to force it to work differently

Easy Random cannot cover all cases. If you want to make it work differently, you can use custom randomizers for such recursive types or provide a custom ObjectFactory implementation that is smart enough to covers those cases.
I'm closing this issue as explained in #412 . Thank you.


Add support for DLQ to Consumers

This doesn't really make sense in NiFi. If the consumer processor can't handle the messages, then it is a failure.


confusing type mismatch involving Tuple and List

In the following example:
accumulate : (a -> b -> b) -> b -> List a -> List b
accumulate fn init values =
    values
    |> List.foldl (\v (next,rest) -> (fn v next)::rest) (init,[init])
    |> snd

The errors produced, while pointing to the correct place, do not describe the error in a helpful way:
-- TYPE MISMATCH --------------------------------------------------------------

This argument is causing a type mismatch.

3|
4|        List.foldl (\v (next,rest) -> (fn v next)::rest) (init,[init])
5|                                                          ^^^^^^^^^^^

To be more specific, as I infer all the types, I am seeing a conflict between
this type:

    List

and this type:

    (a)

-- TYPE MISMATCH --------------------------------------------------------------

This argument is causing a type mismatch.

3|
4|        List.foldl (\v (next,rest) -> (fn v next)::rest)
5|                                       ^^^^^^^^^^^^^^^^

To be more specific, as I infer all the types, I am seeing a conflict between
this type:

    (a)

and this type:

    List

Both the type (a) and the type List (without a parameter) are confusing--I'm not really sure what either refers to.  More helpful in this case would be to say there is a conflict between types (b, List b) and List b.

Context is added in 0.16


New package: CBS.Rainbow version 5.4.68+5468

Microsoft Reviewers: Open in CodeFlow

Verify:

I couldn't find how to have the application display the version number.


segmentation fault (core dumped)

I am using AWS EC2 Ubuntu 18.04. I was able to install everything successfully. While I was trying to load Detectron2LayoutModel, I get following error
python3: Relink `/lib/x86_64-linux-gnu/libsystemd.so.0' with `/lib/x86_64-linux-gnu/librt.so.1' for IFUNC symbol `clock_gettime'
python3: Relink `/lib/x86_64-linux-gnu/libudev.so.1' with `/lib/x86_64-linux-gnu/librt.so.1' for IFUNC symbol `clock_gettime'
Segmentation fault (core dumped)

To Reproduce
Steps to reproduce the behavior:
I launched a t2.large AWS Ubuntu 18.04 and ran following command

sudo apt-get update
sudo apt install python3-pip -y
python3 -m pip install --upgrade pip
pip3 install scikit-build
pip3 install layoutparser torchvision && pip3 install "detectron2<EMAIL_ADDRESS>
and then ran the following script.
import layoutparser as lp
model = lp.Detectron2LayoutModel('lp://PubLayNet/mask_rcnn_X_101_32x8d_FPN_3x/config',extra_config=["MODEL.ROI_HEADS.SCORE_THRESH_TEST", 0.65],
                                 label_map={0: "Text", 1: "Title", 2: "List", 3:"Table", 4:"Figure"})

Output -
python3: Relink `/lib/x86_64-linux-gnu/libsystemd.so.0' with `/lib/x86_64-linux-gnu/librt.so.1' for IFUNC symbol `clock_gettime'
python3: Relink `/lib/x86_64-linux-gnu/libudev.so.1' with `/lib/x86_64-linux-gnu/librt.so.1' for IFUNC symbol `clock_gettime'
Segmentation fault (core dumped)

Environment

Ubuntu 18.04 - AWS t2.large Instance
layout parser version = 0.3.2
Python 3.6.9

Any one else facing this issue?

This should help
pip3 install opencv-python-headless==<IP_ADDRESS>

This should help
pip3 install opencv-python-headless==<IP_ADDRESS>

Thanks. It worked!