Removal of slight RNG bias

I must ask, since I can't see the source.
In C, there is a very, very slight bias toward the low end if you just do a straight modulo to get the result. Not even a 1% variation, but it is there. If it's, say, a d20, since the maximum possible random number (0-4294967295) is not a multiple of 20, there will be a slight bias in favor of rolls 16 and under. Unless you check to see whether the random number is in that final incomplete range, and reroll if it is, it won't be a perfectly random roll (defined as every outcome having an equal chance).
Again, the bias is very, very, very small. But calculable.
Does this bot's programming language have this issue? If so, does it perform this check?

Hi, @NiveusLuna. I did a test spread here: https://github.com/ArtemGr/Sidekick/issues/10#issuecomment-261319378.

Also, here's the source code:
fn real_roll (dice: u32) -> u32 {
  match dice {
    0 => 0,
    1 => 1,
    _ => (dice as f64 * rand::random::<f64>()) as u32 + 1}}

#[cfg(not(test))]
fn roll (dice: u32) -> u32 {real_roll (dice)}

#[cfg(test)]
thread_local! (static MOCK_DICE: RefCell<Vec<u32>> = RefCell::new (Vec::new()));

If you think it can be improved, then by all means, shoot.

Here's also a unit test:
// https://github.com/ArtemGr/Sidekick/issues/10
// RUSTFLAGS=-Zincremental=incremental RUST_BACKTRACE=1 cargo test test_roll_randomness -- --nocapture
#[test] fn test_roll_randomness() {
  assert_eq! (real_roll (0), 0);  // https://github.com/ArtemGr/Sidekick/issues/12.
  assert_eq! (real_roll (1), 1);

  let mut streaks = OrderMap::new();
  for _ in 0..999 {
    let mut longest_streak = 0;
    let mut streak = 0;
    let mut prev = 0;
    for _ in 0..99 {
      let r = real_roll (10);
      if r == prev {streak += 1; if streak > longest_streak {longest_streak = streak}} else {prev = r; streak = 0}}
    *streaks.entry (longest_streak) .or_insert (0) += 1}
  let streak_2_count = *streaks.get (&2) .unwrap();
  let streak_3_plus_count = streaks.iter().filter_map (|(k, v)| if *k > 2 {Some (*v)} else {None}) .sum() :u32;
  //lo! ("Streaks: " [streaks] "; streak_2_count: " (streak_2_count) "; streak_3_plus_count: " (streak_3_plus_count) ".");
  assert! (streak_2_count > streak_3_plus_count);

  let mut map = OrderMap::new();
  for _ in 0..9999 {*map.entry (real_roll (10)) .or_insert (0) += 1}
  let mut min = 0;
  let mut max = 0;
  for (_, v) in map.iter() {
    if min == 0 || *v < min {min = *v}
    if max == 0 || *v > max {max = *v}}
  //lo! ("Spread: " [map] "; min: " (min) "; max: " (max) "; delta: " (max - min) ".");
  assert! (max - min < 200);}

It hasn't failed once since I wrote it, so I almost forgot it's there.

ah. /dev/urandom isn't top tier, but is certainly cryptographically secure. I don't recognize this language (Perl, maybe? ECMAscript?), so I can't suggest something directly. But I can give you some pseudocode. I don't know where the modulo is done in your code, so this is the best I can do.
int die_roll (int max_result)
{
bool correction_needed = true;
int random_number;
int max_random = RAND_MAX - (RAND_MAX % max_result);
while (true)
{
random_number = random();
if (random_number <= max_random)
{
return random_number % max_result;
}
}
}
Do keep in mind that on 1d20, the odds of a 16 being selected over a 20 are insanely low, probably statistically insignificant. The function does return a long int after all. It's just nonzero, which bothers me.

It's Rust and I'm not doing the modulo, I multiply the dice with a 64-bit floating point random.

Then I have absolutely no idea what the bias is, and you're probably going through far more complication than I ever would. A random 64-bit result, floating point or integer, gives an absolutely massive pool. My math was assuming 32-bit integers. I'll content myself with the knowledge that any bias present is statistically insignificant and therefore meaningless.
Thank you for humoring me.

Yeah, I was pretty thorough writing it. You're welcome, and thanks for giving this a second look.

And if you want to play with the underlying RNG, here's a link: http://play.integer32.com/?gist=6f8a6f4e17689bac5e3c6ba62be5ec3a&version=stable.


Image not found error in console throughout site

On some/all of the pages of the site, this error message comes up in the developer console:

GET https://pycon-staging.global.ssl.fastly.net/2016/site_media/static/css/images/ui-bg_flat_35_2871ba_40x100.png 404 (Not Found)
is_wacky_disp @ onloadwff.js:1002chk_form_ask_generate @ onloadwff.js:684checkForSignupForm @ onloadwff.js:716setupIcons @ onloadwff.js:712receiveBG @ onloadwff.js:166target.(anonymous function) @ extensions::SafeBuiltins:19EventImpl.dispatchToListener @ extensions::event_bindings:387target.(anonymous function) @ extensions::SafeBuiltins:19$Array.forEach.publicClass.(anonymous function) @ extensions::utils:94EventImpl.dispatch_ @ extensions::event_bindings:371EventImpl.dispatch @ extensions::event_bindings:393target.(anonymous function) @ extensions::SafeBuiltins:19$Array.forEach.publicClass.(anonymous function) @ extensions::utils:94dispatchOnMessage @ extensions::messaging:316

It looks like it's having trouble finding an image it wants to use.

Fix passes QA.

The issue seems to have reappeared, but only on logged-in user dashboards.

Fixed by https://github.com/PyCon/pycon/commit/f3b4950ec60f9f81bca666e5ac6b9e30ba201119


remotecfg: defer creating remotecfg dir until we decide we need it

PR Description
Which issue(s) this PR fixes

Notes to the Reviewer
PR Checklist

[ ] CHANGELOG.md updated
[ ] Documentation added
[ ] Tests updated
[ ] Config converters updated

The main problem this is trying to solve is that I've seen a number of error messages about remotecfg in unrealted issues, like when the volumes are set up wrong, or read only. That's just because remotecfg is the first thing that tries to create directories in the data dir.
Perhaps a better alternative would be to do a more robust check on alloy startup that we can properly manage the data dir.

The main problem this is trying to solve is that I've seen a number of error messages about remotecfg in unrealted issues, like when the volumes are set up wrong, or read only. That's just because remotecfg is the first thing that tries to create directories in the data dir.
Perhaps a better alternative would be to do a more robust check on alloy startup that we can properly manage the data dir.

I agree with the point at the end about doing a more robust check on alloy startup for the data dir. I would start there and see if there is still an issue for remotecfg.


Slowdown in the case of incorrect hunks values

    let patch = "\
@@ -10,6 +1000000,8 @@
 First:
     Life before death,
     strength before weakness,
     journey before destination.
 Second:
-    I will put the law before all else.
+    I swear to seek justice,
+    to let it guide me,
+    until I find a more perfect Ideal.
";

    let original = "\
First:
    Life before death,
    strength before weakness,
    journey before destination.
Second:
    I will put the law before all else.
";

    let patch = Patch::from_str(patch).unwrap();
    let result = apply(original, &patch);

This code works very slovely because of incorrect value 1000000 of patch

Thanks for the bug report and the repro case! I was able to reproduce the slowdown locally and I believe I was able to fix the issue. On my machine this test case went from 200ms to 30us (in debug mode).


Gateway: add swagger / openapi docs

What is the expected enhancement?
Add swagger and openapi docs for gateway and document everything related to that API.
Epic https://github.com/Qiskit-Extensions/quantum-serverless/issues/1164

hi @IceKhan13 are you on this already?
If still available, I would love to give it a shot to learn more about gateway APIs.

Hey @david-alber ! Sure, take it away! and let us know if you need anything

ref https://drf-yasg.readthedocs.io/en/stable/readme.html#openapi-3-0-note


Add metacall.

Is this a Nim package? (cc @dom96)

Is this a Nim package? (cc @dom96)

It is a nim wrapper to a c library. A port of that library.


Added page describing how to create issues

Replaces the old wiki page with a new page based mostly on the JIRA Triage docs

@jasongin @rakatyal @dblotsky please review

Looks good to me.

Do we need to add the last line as per the old wiki page?
For feature requests, please discuss them on our mailing list or slack channel.

I'm not sure, we do have the "feature" issue type in JIRA

Yeah. Let's skip it.

I've added a page of contributor guidelines as well. It's mostly based off the old issue workflow wiki page but with updated information and fewer git tutorials


Global channel not affecting leds out

After a clean reinstall, global channel isn't affecting led outs.
I couldn't say if this was working before reinstall of the firmware but I suspect it wasn't working.
It works on all inputs tho.
Nico

I don't understand what is the problem.


feat(compile): upgrade to webpack 2

https://gist.github.com/sokra/27b24881210b56bbaff7 may be useful to check out
Having done this a few times, I thought it would be good to upgrade this popular starter kit to webpack 2 (#1057). Several things are going on here to upgrade:

postcss and sass loader configs have moved into the webpack.LoaderOptionsPlugin (see https://github.com/postcss/postcss-loader/issues/99 for an example)
module.preLoaders does not exist and has been replaced with the enforce: 'pre' option on a regular loader.
devtool: null is no longer valid and has been replaced with devtool: false
karma-webpack-with-fast-sourcemaps is very outdated (~60 commits behind) and does not seem to support webpack 2 so I've removed it in favor of the official karma-webpack
upgrading of the ExtractTextPlugin is also required for webpack 2. It is only slight changes in config syntax
resolve.root no longer exist and both the diff below and the gist above show the differences

I confirmed that the npm scripts still function as expected.

note that I will be editing the travis.yml to debug the travis build.

Current coverage is 72.58% (diff: 100%)

Merging #1063 into master will not change coverage

@@             master      #1063   diff @@
==========================================
  Files            12         12
  Lines            62         62
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits             45         45
  Misses           17         17
  Partials          0          0

Powered by Codecov. Last update c3abb24...e555f7f

it appears that this does not work with cached node_modules. I will dig into what dependency is cached and causing the issues

It seems like the build is failing with an issue related to loader-utils
https://github.com/s-panferov/awesome-typescript-loader/issues/241
Removing the cache should solve the problem.

The following error keeps showing up in travis:
Module build failed: Error: parseQuery should get a string as first argument
    at Object.parseQuery (/home/travis/build/davezuko/react-redux-starter-kit/node_modules/loader-utils/index.js:68:9)
    at Object.module.exports (/home/travis/build/davezuko/react-redux-starter-kit/node_modules/babel-loader/index.js:80:35)

It seems to be an issue with loader-utils that is solved by re-installing your node_modules which resetting the cache will fix

Any reason why you've put dev_tool to null?

Thank you for the PR, this is definitely on my radar.
Referencing https://github.com/davezuko/react-redux-starter-kit/issues/1057 for transparency.

@jonaswindey, I changed the dev_tool from null to false due to the addition of config validation. Null is invalid. https://github.com/webpack/webpack/blob/996fdc5eebcd5a109b67efb2d53e6639d93fb264/schemas/webpackOptionsSchema.json#L632-L644

@mgmcdermott ok, just wondering since the starter kit currently uses compiler_devtool from /config and not null

Thank you for your PR, and apologies for my inattention. I'll be continuing this off of https://github.com/davezuko/react-redux-starter-kit/pull/1091 which builds on your work. Thanks!


Creator Features 2022-09-01-preview

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[x] Other, please clarify - This is technically a new service onboarding. However, I wanted to clarify that this service is the successor of an existing service, WFS. We opted to create a whole new service instead of version as we wanted to rename the service to Features (as WFS is now a legacy service per Open Geospatial Consortium standards), as well as make a number of small changes to existing APIs that would sum up to breaking changes. Features keeps the same functionality as the read APIs in WFS while also adding a set of new APIs for write operations.

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.

February 2023

When do you expect to publish the swagger?

February 2023

If updating an existing version, please select the specific language SDKs and CLIs that must be refreshed after the swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[x] No refresh required for updates in this PR

Contribution checklist:

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following appy to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you are using OpenAPIHub to initialize the PR for adding a new version. More details, refer to the wiki.

[ ] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.
fix https://github.com/Azure/azure-rest-api-specs/issues/22058

/azp run

@ismael-ms if possible, can you please avoid rebasing and force-pushing. It makes it very difficult to simply view the changes since last we reviewed, thus having to review the entire PR again and taking longer.

@ismael-ms if possible, can you please avoid rebasing and force-pushing. It makes it very difficult to simply view the changes since last we reviewed, thus having to review the entire PR again and taking longer.
Understood. Just wanted to fix a mistake in the previous commit, but I'll refrain from cleaning up history. Apologies for the trouble.

@mikekistler, @JeffreyRichter, @heaths Thank you all for your assistance and guidance in developing a new API version. I have addressed the versioning concerns in this PR now and it is ready for review again.
For reference, here's a quick summary of things that have been changed since the last review:

I merged release-maps-Creator-2023-03-01-preview-feature-branch into this branch to have the latest 2023-03-01-preview changes. (https://github.com/Azure/azure-rest-api-specs/pull/19539/commits/66ffa06dd5040e4907d438d4e4229c076d2b4f9a)
I updated the API version for Features to 2023-03-01-preview (https://github.com/Azure/azure-rest-api-specs/pull/19539/commits/41693437b3ef5e1e64a2d4e2550f1795bfcc1609 and https://github.com/Azure/azure-rest-api-specs/pull/19539/commits/ec3fb5434a4f8e0c73e34aa3c80cfd6e2c2dbb89)
I removed the "id" field in the POST (create feature) and PUT (update feature) request body. This is still conforming with the Open Geospatial Consortium specification, and it is not a breaking change since it is a new API. (https://github.com/Azure/azure-rest-api-specs/pull/19539/commits/ec3fb5434a4f8e0c73e34aa3c80cfd6e2c2dbb89)
Removed the default api-version since it is a required field. (https://github.com/Azure/azure-rest-api-specs/pull/19539/commits/284d62c7a6e19ca10ed41e9c8ae4327bdf78cc58)

Please let me know if there are any questions. I'll be happy to answer 😃

@jhendrixMSFT This PR is ready to merge.


Release 3.0.20

Welcome to Clear Containers release 3.0.20!.
The runtime now checks to do not  exceed the number of physical cores per VM, this fixes issues with KVM and some architectures. The clear containers configuration file now allows to disable block device being used directly by the hypervisor.
The agent and kernel versions were updated to allow support for SCSI and allow use the maximum number of CPUs.
Changes

config: don't exceed the number of physical cores
fedora-installation-guide: update Fedora versions supported
Logging fixes
versions: Update agent version to pull in SCSI support
logging: Add CLI command to logs
config: Add comments for the DisableBlockDeviceUse flag

Shortlog
f6da537 config: don't exceed the number of physical cores
e703f15 fedora-installation-guide: update Fedora versions supported
b03c4a5 logging: Add name to all log calls
055c688 logging: Add PID field to logs
cc84544 versions: Update agent version to pull in SCSI support
54f87f5 logging: Add CLI command to logs
befbdb1 config: Add comments for the DisableBlockDeviceUse flag
Compatibility with Docker
Clear Containers 3.0.20 is compatible with Docker v17.12-ce
OCI Runtime Specification
Clear Containers 3.0.20 support the OCI Runtime Specification v1.0.0-rc5
Clear Linux Containers image
Clear Containers 3.0.20 requires at least Clear Linux containers image 20640
Clear Linux Containers Kernel
Clear Containers 3.0.20 requires at least Clear Linux Containers  kernel v4.9.60-85.container
Installation

BC-Linux

Centos

Clear Linux

Fedora

SLES

Ubuntu

Developers

Issues & limitations
Docker swarm support
See issue #771 for more
Networking
Adding networks dynamically
Resource management
docker run --cpus=
See issue #341 for more information.
docker run --kernel-memory=
See issue #388 for more information.
shm
cgroup constraints
Capabilities
See issue #51 for more information.
sysctl
tmpfs
Other
checkpoint and restore
docker stats
See issue #200 for more information.
runtime commands
ps command
See issue #95 for more information.
events command
See issue #379 for more information.
update command
See issue #380 for more information.


Ctrl+c / Ctrl+a don't work in command mode

Open command mode Ctrl+E
Type anything
Try to select all using Ctrl+A
Select with the mouse and then try to copy using Ctrl+C

Specifications

Commit hash:

Version: 2.0.11
Commit hash: 225927b9
Compiled on August 01, 2022

OS:

Windows 10.0.19045

Terminal:

Windows Terminal Preview
Version: 1.16.3463.0

Same problem on a Linux terminal emulator.

Hi
You can define key bindings for the command mode in your bindings.json. Mine are below, I use a small keyboard with no End Home keys, hence CtrlB and CtrlE :
{
<buffer bindings>
 "command": {
        "CtrlA": "SelectAll",
        "CtrlB": "StartOfLine",
        "CtrlC": "Copy",
        "CtrlE": "EndOfLine",
        "CtrlK": "SelectToEndOfLine,Delete",
        "CtrlShiftK": "SelectToStartOfLine,Delete",
        "Down": "HistoryDown",
        "Up": "HistoryUp",
        "MouseLeft": "MousePress"
    }

See Help Keybindings, at section Pane type bindings
Kind Regards Gavin Holt


Invalid XML on the output

Hello,
I am trying to use Grobid batch mode to extract structured full text from PDFs (-exe processFullText). Unfortunately, the latest code version gives me invalid XML files on the output. I am not sure whether this is caused by problems with my installation or the source code.
Here is an fragment of the output XML I obtained processing the example file "Metab_Brain_Dis_2011_Mar_9_26(1)_1-8/11011_2011_Article_9233.pdf" from PMC_sample_1943 dataset:
<text xml:lang="en">

the nature of the deficient enzyme, eleven types and subtypes of MPS are already recognized. Partially degraded GAGs accumulate in cells of MPS patients, causing dysfunction of tissues and organs, including the heart, respiratory system, bones, joints and central nervous system (CNS). In MPS types characterized by the storage of heparan sulfate (HS), one of the GAGs, neurological symptoms are among the most severe ones (Neufeld and Muenzer 2001). Although enzyme replacement therapy (ERT) has been developed for various types of MPS, and registered to date for three of them (types I, II and VI), such a treatment is ineffective for neurological symptoms as the enzyme cannot cross the blood-brainbarrier (for reviews, see Beck 2007a, b). The second therapy used in a relatively large fraction of MPS patients, A. Kloska : J. Jakóbkiewicz-Banecka : G. Węgrzyn (*)

Department
e-mail<EMAIL_ADDRESS>
bone marrow transplantation, has been shown to be efficient to some extent in MPS type I, but not in MPS III (Sanfilippo disease) (Beck 2007a, b), an MPS type characterized by the most severe CNS dysfunctions among mucopolysaccharidoses (for recent discussion, see Węgrzyn et al. 2010).

It seems to lack the opening  tag (there is a closing one at the end of the document), as well as a few closing
 tags. I have similar problems with other PDF files as well. Only the full text part is corrupted, the headers and references seem to be correct.

Hello Dominika,
Thanks you for reporting the problem! It appears that I cannot reproduce it. The TEI file that I obtain for this PDF file of the PMC_sample_1943 is well-formed and different:
https://grobid.s3.amazonaws.com/11011_2011_Article_9233.tei.xml
Which version of GROBID are you using?
Normally all the TEI are well-formed since some changes in March which made the full text TEI much more robust. Since 2 weeks there is a small validity error when the coordinates are outputted in the TEI file, because it does not follow a TEI scheme for the moment (I am a bit slow for recreating the RNG schema). Otherwise, the TEI are normally also valid when not outputing the coordinates in the original PDF.

Hi Patrice,
Thank you for the answer.
I checked out the latest version today: 0.3.9-SNAPSHOT. I am using CRF++ library compiled for Linux 32-bit, but this does not seem relevant to the problem.
Here is the exact file I obtained: http://pastebin.com/ReH7snh7
If you think of anything that might cause this, please let me know. I will try to debug it deeper anyway.

I think the problem is the CRF++ library for linux 32 bits. I removed it from the GROBID distribution since one or two years because I can't compile and update it anymore (I don't have access to a 32 bit linux set-up and CRF++ is really hard to build with JNI).
In addition, the models for CRF++ might not have been updated for the full text model (I always forget!). I plan to remove the support of CRF++ from GROBID as soon we can have Wapiti working on Windows.
At this point of time, I can only guarantee Mac OS and Linux 64 bit versions!

Thanks for the information, until now I thought the choice of CRF library affects only the time performance.
Would it be ok to use Wapiti on Linux 32-bit? Or I should also move everything to 64-bit?

I think Wapiti on Linux 32-bit should work well! But you have to build with this fork -> Wapiti which includes JNI and important bug fixes for GROBID.
If it works well, I could add Wapiti 32 bits to GROBID!

Everything worked fine, and miraculously the output XMLs seem valid now. Thanks a lot for your help!
Would you like me to provide the resulting .so files?

Very good !!
Yes many thanks in advance for the .so, I will add it so that people on Linux-32 can have a ""out--of-the-box" solution. :+1:


Strange scrolling behaviour when dragging from tableviews

Hi everybody,
I see a strange behaviour when you scroll up.
To replicate this problem you have, in the example app, to:

Scroll down a bit, but not enough to pin the segmented view to the top
Scroll up again, tapping on the tableview, NOT on the header NOR on the segmented view

If you scroll with the "inertia" you can observe that the scrollingview doesn't acquire the normal "velocity", but it stops instantaneously.
This effect makes the navigation in the section a little weird, you can sense that something is wrong, but it's difficult to figure it out what!!

Hi @nemwiper,
We are not able to reproduce this scenario. Could you please provide a video for this scenario?

Hi @subinspathilettu, thanks for the quick response!!!
This is a video of the issue, as you can see, when scrolling up dragging from the tableview (when it reaches the top element), the movement of the scrollview stops as you release the mouse, instead of continue to move upward.

Ohh.. got it.. Thanks @nemwiper
After reaches the top element, we are using UIScrollView scroll changes to update the view. The deceleration rate for UITableView and UIScrollView is different. So that it suddenly stops after releasing the touch/mouse. I will look into this issue and provide an update.

@subinspathilettu, thankyou very much! ;)

Hi @subinspathilettu,
another small issue:
when one drags up starting from the table view it's all fine, but when the dragging starts from the header or from the segment view, the scroll view stops scrolling once the fragment view reaches the top, and the "movement" will not propagate to the tableview! ;)
With this two issues resolved I think that this library will be perfect! :)

Why this issue has been closed? It's still present in the last version! :(


E2E performance regression for timm_models

Fox example timm_models bfloat16 inference (https://github.com/intel/intel-xpu-backend-for-triton/actions/runs/9770466839/job/26971711342).
This case took more than 8h, usually it takes ~8 minutes for the job to complete.
Others took more than 12h and timed out:
https://github.com/intel/intel-xpu-backend-for-triton/actions/runs/9770466839/job/26971711342.
The logs contain errors like this:
python: /runner/_work/intel-xpu-backend-for-triton/intel-xpu-backend-for-triton/third_party/intel/lib/TritonIntelGPUToLLVM/Utility.h:113: mlir::Value mlir::LLVM::intel::getSharedMemoryBase(mlir::Location, mlir::ConversionPatternRewriter&, mlir::Operation*): Assertion `op->hasAttr("allocation.offset")' failed.

Looks like this caused by #1559: running all e2e models instead of a subset.


fix inet serverurl path

inet_hostname variable is not defined in the module at all, so I have replaced it with correct one.
There are multiple errors with FUTURE_PARSER=yes during CI, but they are not related to current fix.
https://travis-ci.org/kam1kaze/puppet-supervisord/builds/53780764

Thanks @kam1kaze


Crowd audio clips when transitioning to match starting

"I shortened the interlude duration to 3.5s from 5 because 5s feels like forever."
This may be the root of the problem


Aurelia-binding typings build issue after latest commit

HI Team,
The recent change is throwing error in type definition during compile.
typings/modules/aurelia-binding/index.d.ts
Could you resolve it ASAP>
export interface CollectionObserver {
/**

Subscribe to collection mutation events.
*/
subscribe(callback: (changeRecords: Array | Array | Array) => void): Disposable;
}

OK, there is an issue template for, reasons.

Which version of aurelia-binding is giving you the issue?
What is your tooling? Basically now I'm guessing that you are referencing the master branch in git somehow, and not a specific tag or preferably a npm package. The merged PR you commented first has not been released yet.
Please provide the related compiler errors. I can't seem to find callback: (changeRecords: Array | Array | Array in the code.

Hi,
Please find the below screen shot of the gulp build issue we are facing with Aurelia typings file.

And regarding the version, our build server will take the latest Aurelia binding version.
Regards,
Dhanapal Chandran

From the look of the error report, I think you have typescript version less than 2.3 as the new typings use Default generic type.
@EisenbergEffect @jdanyow @StrahilKazlachev What should we do about this ?

Also notice that the distribution typings doesn't match typings in src, could be an issue.

@bigopon about the typings in the dist, isn't is normal, since there has not been a release?

@dhanapalschandran have you resolved your issue?

async triageQuestion(id) =>{
 respondSameDay()
 let response = await getResponseFromOP( { timeout : longEnough} )
 if(!response) {
    closeQuestion(id,randomReason())
 }
}

can be closed

Closing because:

This is likely an issue with the OPs TS version.
No response from OP in 10 days.


Converting quantised (QAT static) PyTorch model to ONNX

https://colab.research.google.com/drive/1It97gzQTTWUxZGCsK3BwimO6RBICzPWL?usp=sharing

Approaches attempted - 1:

Save the weights alone for QAT torch model and load it to a torch model


Enable gateway-mode namespaces

In a chain with #876

Codecov Report

Merging #878 (245dbe2) into main (cf843bc) will decrease coverage by 0.18%.
The diff coverage is 88.42%.

@@            Coverage Diff             @@
##             main     #878      +/-   ##
==========================================
- Coverage   99.95%   99.76%   -0.19%
==========================================
  Files         300      301       +1
  Lines       19479    19555      +76
==========================================
+ Hits        19470    19509      +39
- Misses          7       26      +19
- Partials        2       20      +18

Impacted Files
Coverage Δ

internal/assets/token_transfer.go
97.35% <0.00%> (-2.65%)
:arrow_down:

internal/broadcast/message.go
100.00% <ø> (ø)

internal/coreconfig/coreconfig.go
100.00% <ø> (ø)

internal/data/blobstore.go
95.55% <0.00%> (-4.45%)
:arrow_down:

internal/events/batch_pin_complete.go
95.52% <0.00%> (-4.48%)
:arrow_down:

internal/events/dx_callbacks.go
97.84% <0.00%> (-2.16%)
:arrow_down:

internal/events/event_dispatcher.go
100.00% <ø> (ø)

internal/events/ss_callbacks.go
92.10% <0.00%> (-7.90%)
:arrow_down:

internal/networkmap/register_node.go
90.47% <0.00%> (-9.53%)
:arrow_down:

internal/orchestrator/bound_callbacks.go
100.00% <ø> (ø)

... and 51 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 cf843bc...245dbe2. Read the comment docs.


Changed fosdem image in navigation header to fossasia

@mananwason Hi, thank you for your changes! They seem to be ok. I have one suggestion - can you remove old FOSDEM logo? We do not need having all unused assets.

@tt221 I thought I removed it, anyways I'll do it by tomorrow.

@mananwason Ok, I will merge your PR after you will remove this old logo. Thanks for your edits and involvment in creating our app!

Sure tymon :D

@ty221 It's done, you may proceed with the merging. Thanks.

@mananwason Thanks. Merged.


Add support for setting CLI arguments using environment variables

Enable users to set all optional CLI arguments as environment variables instead of (or in additional to) directly passing them as CLI arguments. For example running export CFV_REPORTER="json would produce JSON output. If both a CLI argument and environment variable are provided the CLI argument should win over the environment var or any type of merging of the options.

Hello. Could I work on this one ?

@nikonhub assigned it to you!


Move Socket.ip? to Socket::IPAddress.ip?

The method is specific to IPAddress, so it shouldn't be defined in the parent namespace.
It could also be Socket::Address.ip?, but it fits more closely in IPAddress.

if Socket.ip?(address)
  # ...
end

I think that was the point, it's almost readable English.
This new way is longer and redundant.

Darn I agree with both of you here^^
In this case there could be a Socket.ip? that simply redirects to Socket::Address.ip? as a fancy-english-method?

@bew That would be an alias. I don't think anyone would want that.

Oh right ^^ didn't even see it coming

Maybe Socket::IPAddress.parse? which returns the Socket::IPAddress if it's valid, nil otherwise? Then it'd fit.

That sounds good. ip? and parse (or rather new(host, port)) already do pretty much the same, so it looks like a nice solution. Will need some refactoring in the implementation, but I could give it a try.

Or, well. The only issue is port. Socket.ip? is about checking if a string is an IP address. IPAddress.parse creates an instance of IPAddress and expects the argument to be a URI including an IP and port.

Oh, yeah. I keep forgetting IPAddress isn't an IP address. Really bad naming, if it has a port then it probably shouldn't be on IPAddress at all.

would it make more sense to have Socket::Address.ip? be Socket::Address.valid??

@wontruefree A path could also be a valid (UNIX) address.

I just thought it might a little redundant to have IPAddress.ip?

Asterite said it all: the proposed change doesn't improve anything. Further proposed alternatives bring more confusion. What's there to discuss further here? Socket.ip?(address) reads better and is simpler. Let's keep it.


Refactor the backend typing system

This PR is a refactor of the typing system within the library. Previously, typing was handled individually by fields, arguments, and types with a hodgepodge of functions to tie it together. This branch creates a unified typing system that the object, fields, and arguments each hook into.
It's not quite done yet, but I opened the PR so that progress can be monitored.
To Do

[ ] Tests involving StrawberryType.__eq__
[ ] Think longer about how to implement StrawberryType.__hash__. Currently breaking the hash contract
[ ] New unit tests for the StrawberryType types

Types of Changes

[x] Core
[ ] Bugfix
[ ] New feature
[x] Enhancement/optimization
[ ] Documentation

Issues Fixed or Closed by This PR

Checklist

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] I have tested the changes and verified that they work and don't break anything (as well as I can manage).

Hi, thanks for contributing to Strawberry 🍓!
We noticed that this PR is missing a RELEASE.md file. We use that to automatically do releases here on GitHub and, most importantly, to PyPI!
So as soon as this PR is merged, a release will be made 🚀.
Here's an example of RELEASE.md:
Release type: patch

Description of the changes, ideally with some examples, if adding a new feature.

Release type can be one of patch, minor or major. We use semver, so make sure to pick the appropriate type. If in doubt feel free to ask :)


Error: matches multiple boards

When I run this command:
$ cargo pio new -b sipeed-longan-nano my_blink2
I got this error:
Error: Configured board 'sipeed-longan-nano' matches multiple boards in PIO: [sipeed-longan-nano, sipeed-longan-nano]
How can I correct this?
I asked PlatformIO community if it is normal to have multiple boards with the same ID and they answer that is normal: "A board is only unique per platform." https://community.platformio.org/t/multiple-board-id-sipeed-longan-nano/22827
So I added the platform:
$ cargo pio new -b sipeed-longan-nano -p GD32V my_blink2
But I got the same error.
I there something I missed and need to add?
I use the PlatformIO extension for VSCode in WSL2 Debian. Also, the cargo pio command is executed in WSL2 Debian.

Nothing missing really, it is just that the current resolution algorithm assumes that the board name is unique across platforms. Let me try to fix it. Once/if fixed, your command cargo pio new -b sipeed-longan-nano -p GD32V my_blink2 should be working.

OK, so I've published a new version of cargo-pio so you can try it out by re-issuing:

cargo install cargo-pio

The following command line now works:

cargo pio new -b sipeed-longan-nano -p gd32v my_blink2 (please note the lowercase name of the platform; matching is case sensitive)

... however, I cannot test the build of the resulting crate, because of this issue in PlatformIO.
Hope that helps.

By the way... this board looks like a pretty simple thing - no WiFi, BLE or anything like that. And only 32KB RAM / 128KB flash.
So if you really want to code in Rust for it, I don't see the need to go the Cargo->PIO route. Why not just using this crate, and forget about PlatformIO?

Great! Thank you.
Now it works flawlessly. Yes, Longan Nano is super cute and it has a Risc-V processor. I am a "fan" of rust and Risc-V and wanted to play with this combination.
Thank you for the tip for seedstudio-gd32v. I will give it a try.
I wrote some instructions how to setup a development environment for Longan Nano in Win10 + WSL2 Debian for the rust language:
https://github.com/LucianoBestia/longan_nano_rust_wsl2_platformio_setup
I needed to solve some workarounds, but now it works.
I read lately that the ESP32-C will have a Risc-V processor with Wi-Fi and Bluetooth 5. Sounds like a good future.

Great! Thank you.
Now it works flawlessly. Yes, Longan Nano is super cute and it has a Risc-V processor. I am a "fan" of rust and Risc-V and wanted to play with this combination.
Thank you for the tip for seedstudio-gd32v. I will give it a try.

The longan-nano crate actually looks like even more appropriate for your board, so I guess you should keep using that.

I wrote some instructions how to setup a development environment for Longan Nano in Win10 + WSL2 Debian for the rust language:
https://github.com/LucianoBestia/longan_nano_rust_wsl2_platformio_setup

That's great and I'll put edition = "2018" by default in the autogenerated lib.rs by cargo-pio. However my point is: you don't need cargo-pio actually?
Your project relies on a pure-Rust crate (longan-nano) and it is not interfacing with any Vendor SDK and/or C APIs. So why bother with PlatformIO and cargo-pio at all?
Just turn your demo crate from "static lib" to a binary crate one, say !#[cfg(no_main)] and you should be good to go. The build will generate a regular .elf file instead of the .hex one you need for flashing, but I'm sure there are pure-Rust utilities, which can do .elf to .hex and then do the flashing for your board.

I read lately that the ESP32-C will have a Risc-V processor with Wi-Fi and Bluetooth 5. Sounds like a good future.

Yes. That's the ESP32-C3 chip which is on my desk as we speak. Now, the ESP32-C3 is a whole different beast compared to your board - 10x more RAM, 40x more flash, and very difficult to write the WiFi & BLE layer from scratch in Rust, so you have to interface with the ESP-IDF SDK APIs. That's a chip where cargo-pio (either in its cargо-first variant or PIO-first) is really useful.


Compute and report dictionary size

This pull request fixes #339 and integrates the result in the reporting on the command line.

My local branch had some old merges still going on. Sorry for the mess. The new parts are just my commits. This also removes ByteSize from nemo-physical and nemo, as discussed.


High level docs about the hardware

Request from the community:

What is the hardware, and what can it do? (or what could it do, assuming appropriate software was written)

What abstractions have TT chosen to make/expose in TT-Metal and why? e.g. Native matmul on WH is 8x16, but TT-Metal exposes 32x32, and there are good reasons for this, and you should state them. Native RISC-V has 5 cores, but only 3 kernels get written - again, there are good reasons for this, and you should state them. Interleaved/sharded buffers make obvious sense, but only when put in the context of 12 DRAM channels and trying to balance requests to them. Tilized tensor layouts are encouraged because the NoC read/write APIs can only do 1D fetches, and tilized layout packs a small 2D block into a 1D range. And so on and so forth.

@bbeggsTT please look into this ask.

creating high level document here: https://github.com/tenstorrent/tt-metal/pull/15350


add pagination article

Please check my English, structure and links  :)

@metalwarrior665 this is super thorough and clear! I did some pedantic changes and added a couple of images but really only cosmetic stuff.
The only structural change is I put the 'using filter ranges' section before the other two that don't work, just so people can get straight to the good stuff :)
I also updated this heading, pls check if I understood correctly.
It should be available on staging now: https://docs.apify.com/tutorials/scrape-websites-with-limited-pagination?version=add-article/scrape-websites-with-limited-pagination
Feel free to merge when you're happy with it - looks good on my end

Also, is this an article from knowledge base or a new one?
If it's from KB, would you mind replacing the original with a bullet-point version linking to here?

Great! But to be honest, I would keep the original order of "How to overcome the limit" as it builds up the understanding. If we would put the correct one first, the other two are meaningless then.
Other than that it looks great, thanks for the images!
This an original article.

Yeah, that makes sense. I'll change it back


Unable to set output inside a devcontainer

When using the new non-deprecated way of setting outputs in GitHub Actions ( https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ ), it is not working. I assume it is because $GITHUB_OUTPUT refers to some file or pipe which is not set in the devcontainer.
    - name: Execute DevContainer commands
      uses<EMAIL_ADDRESS>      with:
        runCmd: |
          echo "foo=bar" >> $GITHUB_OUTPUT

Now, I would expect the output foo to be available and usable in other steps or jobs, but it is not.

@gauravsaini04 / @prathameshzarkar9 Can either of you help with investigating this? Thanks!

Hello @ffMathy ,
Kindly check if the below sample workflow works for your scenario in reading the variable set in the GITHUB_OUTPUT in different steps under the same job or in a different job altogether. Please let us know if this doesn’t  work out for you and provide further details of your specific scenario.
https://github.com/Kaniska244/checkactionfur/blob/main/.github/workflows/testoutput.yml
Thanks and Regards,
Kaniska

Hi @ffMathy ,
I am closing this issue as I received no further response from your end. Kindly create another issue if the issue still persists for the same.
Thanks and Regards,
Kaniska Sengupta


E2503 Attributes ElasticLoadBalancingV2::LoadBalancer

cfn-lint version: v0.20.0 (used with VsCode)
Description of issue:
I'm setting attribute for AWS::ElasticLoadBalancingV2::LoadBalancer that it's an application load balancer but i receive this error:
[cfn-lint] E2503: Attribute "routing.http.xff_client_port.enabled" not allowed for load balancers with type "application\
But as per aws documentation this settings can be enabled only on application load balancer
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-elasticloadbalancingv2-loadbalancer-loadbalancerattributes.html
Ignoring this error and deploy to cloudformation ALB got created successfully with that oprions enabled
Thanks

Tracking in https://github.com/aws-cloudformation/cfn-lint/issues/2100


Missing instructions for Mac

Xamarin can be installed on Macs. Would you mind adding instructions showing how to uninstall Xamarin on Mac OSX? Thank you.

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

ID: a77068e2-5802-f169-f068-6a2bf41491c2
Version Independent ID: 073d6c2f-b652-e427-f0e6-fb1ce0012485
Content: Uninstall Xamarin - Xamarin
Content Source: docs/get-started/installation/uninstalling-xamarin.md
Product: xamarin
Technology: xamarin-crossplatform
GitHub Login: @conceptdev
Microsoft Alias: crdun

Microsoft support for Xamarin will end on May 1, 2024 for all Xamarin SDKs including Xamarin.Forms. In preparation for this, all issues and PRs in this repository are being closed.
.NET MAUI is the replacement for Xamarin.Forms, and it's documentation can be found here.


Question: How would I make import statements?

First off, I just wanted to say that this tutorial is AMAZING!!!! I only have one "issue"/question, which is: how would I go about making an import statement in this language? All of the other stuff I wanted to do could be based off something, but import is kinda different. My apologies if this shouldn't be an issue, I didn't really know how to ask.

Well, you could use RUN(<filename>) and define functions in said file, then call them from your code.


bump plural-certmanager-webhook and k8s kind version

Summary
bump plural-certmanager-webhook and k8s kind version
This PR fixes the problem: E0228 13:53:48.071853      11 controller.go:116] loading OpenAPI spec for "v1alpha1.acme.plural.sh" failed with: OpenAPI spec does not exist
Test Plan

Checklist

[ ]  No images hosted from dockerhub
[ ]  Are dashboards present to understand the health of the application.  There must be at least 1 of these

[ ]  all databases should have dashboards
[ ]  ideally also have at least cpu/mem utilization dashboards for webserver tier of the app
[ ]  you can use plural from-grafana to convert a grafana dashboard found via google to our CRD

[ ]  Are scaling runbooks present

[ ]  all databases must have scaling runbooks
[ ]  you can use the charts in pluralsh/module-library to accelerate this

[ ]  do you need to add config overlays?

[ ]  inputing secrets
[ ]  configuring autoscaling

[ ]  If there’s a web-facing component to the app, we need to support OIDC authentication and setting up private networks if no authentication option is viable
[ ]  All major clouds must be supported

[ ]  Azure
[ ]  AWS
[ ]  GCP

I have tested it with the new webhook image. Waiting for the new image 0.1.4 https://github.com/pluralsh/plural-certmanager-webhook/pkgs/container/plural-certmanager-webhook


how to set first and last link?

page.url - current link
paginate.href(true) - prev link
paginate.href() - next link
How to add the first and last link, if I, for example, on page 50?
And the second question - how to disable the parameter limit in the URL?

It looks like paginate.href returns a query string with whatever params you throw at it.
So link for first page is:
href=paginate.href({ page: 1})
And link for last page is
paginate.href({ page: pageCount })
but you need to set pageCount yourself as shown in the example in the readme.

And, if someone bump into this issue again, I'll just leave it here:
// req is express request object
// pageCount is total number of pages, you need to calculate it on your own
paginate.href(req)(false, {page: 1}),
paginate.href(req)(false, {page: pageCount}),
Solution provided above has cause errors on:
express: 4.17.1
express-paginate: 1.0.2


[bug] Embeddable objects can't have @Serialized properties

@Embeddable
interface MyEmbeddable {
    @Serialized
    val someValue: Map<String, String>
}

MyEmbeddable.kt:10: Illegal property "MyEmbeddable.someValue", it cannot be decorated by @org.babyfish.jimmer.sql.Serialized because the declaring type "MyEmbeddable" is not decorated by [org.babyfish.jimmer.sql.Entity, org.babyfish.jimmer.sql.MappedSuperclass]

Try 0.8.110


Introduce yourself to the project and community, and tell us your skills/interests

Welcome! Say hi, and tell us who you are, and what your skills/interests are.

Hi..I'm a second year undergraduate from Rajarata University of Sri Lanka. Currently participating in the Mozilla Global Sprint 2018.

I'm a 2nd year student from Informatics Institute of Technology Sri Lanka.
#MozillaGlobalSprint2018


Update DFPRollingWindowStage to emit correct window

DFPRollingWindowStage was only emitting last batch once min_history was met. This PR updates the stage to emit all accumulated rows meeting configured window history requirements.
Fixes #674

/merge


Variables relativeFile and relativeFileDirname use backslashes in WSL when used in keyboard shortcuts

Does this issue occur when all extensions are disabled?: Not really, I can't access WSL without the ms-vscode-remote.remote-wsl extension.

VS Code Version: 1.74.3
OS Version: Windows_NT x64 10.0.19045

Steps to Reproduce:
I have this keyboard shortcut, which comes in handy whenever I want to run a command in the terminal against the current file:
{
  "key": "ctrl+shift+p",
  "command": "workbench.action.terminal.sendSequence",
  "args": { "text": "${relativeFile}" },
  "when": "terminalFocus"
}

When triggering this shortcut in a WSL workspace, it sends the file path with backslashes instead of forward slashes, which negates its usefulness. This happens for both relativeFile and relativeFileDirname, but not for file or fileDirname.
Here's output for each variable when used with the workbench.action.terminal.sendSequence in a keyboard shortcut:

file: /home/jamin/projects/environment/config/code/settings/settings.json
fileDirname: /home/jamin/projects/environment/config/code/settings
relativeFile: config\code\settings\settings.json
relativeFileDirname: config\code\settings

When using relativeFile or relativeFileDirname within a task like this:
{
  "label": "print relativeFile",
  "type": "shell",
  "command": "echo ${relativeFile}"
}

The path is printed with forward slashes as expected:

I think I'm running into this over in https://github.com/microsoft/vscode-flake8/issues/331 as well

Code pointer:
https://github.com/microsoft/vscode/blob/4b91caa59bcdca34de48d3e41e5f3a0102410bc6/src/vs/workbench/services/configurationResolver/common/variableResolver.ts#L317-L342

@Tyriar as far as I can tell, terminal isn't resolving variables in the extension host, which what tasks and debug does to get proper paths. The fix would be for terminal to resolve the variables in the extension host, similar to this:
https://github.com/microsoft/vscode/blob/092158edd9ef8e334e79b7ea368581eac25faecd/src/vs/workbench/api/node/extHostTask.ts#L153-L154


Code Javascript

You have a real problem?

No, i'm just studying. Seeking to find the best way to work with github in the future.

[ ] ``

Awesome, congratulations!
this place is better to get tech content and to study code with open sources projects.
The documentation is complete and you can explore more functionalitys.


Provide better feedback if timing parameters need to be customized

The default timing parameters in benchmark_driver work very well if you're performing a fast micro benchmark. However, if the code being benchmarked runs a bit slower, the default parameters for the warmup phase result in __bmdv_ip100ms being 0 due to the .floor call. And subsequently the __bmdv_loops value ends up being 0. This will eventually lead to the following cryptic backtrace:
/home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/benchmark_driver-0.10.15/lib/benchmark_driver/output/compare.rb:108:in `humanize': Non positive value: 0.0 (ArgumentError)
	from /home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/benchmark_driver-0.10.15/lib/benchmark_driver/output/compare.rb:75:in `report'
	from /home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/benchmark_driver-0.10.15/lib/benchmark_driver/runner/ips.rb:38:in `block (3 levels) in run'
	from /home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/benchmark_driver-0.10.15/lib/benchmark_driver/output/compare.rb:55:in `with_job'
	from /home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/benchmark_driver-0.10.15/lib/benchmark_driver/runner/ips.rb:34:in `block (2 levels) in run'
	from /home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/benchmark_driver-0.10.15/lib/benchmark_driver/runner/ips.rb:31:in `map'
	from /home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/benchmark_driver-0.10.15/lib/benchmark_driver/runner/ips.rb:31:in `block in run'
	from /home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/benchmark_driver-0.10.15/lib/benchmark_driver/output/compare.rb:19:in `block in with_warmup'
	from /home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/benchmark_driver-0.10.15/lib/benchmark_driver/output/compare.rb:101:in `without_stdout_buffering'
	from /home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/benchmark_driver-0.10.15/lib/benchmark_driver/output/compare.rb:16:in `with_warmup'
	from /home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/benchmark_driver-0.10.15/lib/benchmark_driver/runner/ips.rb:30:in `run'
	from /home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/benchmark_driver-0.10.15/lib/benchmark_driver/runner.rb:36:in `block (2 levels) in run'
	from /home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/benchmark_driver-0.10.15/lib/benchmark_driver/runner.rb:56:in `block in with_clean_env'
	from /home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/bundler-1.16.1/lib/bundler.rb:297:in `block in with_clean_env'
	from /home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/bundler-1.16.1/lib/bundler.rb:540:in `with_env'
	from /home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/bundler-1.16.1/lib/bundler.rb:297:in `with_clean_env'
	from /home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/benchmark_driver-0.10.15/lib/benchmark_driver/runner.rb:55:in `with_clean_env'
	from /home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/benchmark_driver-0.10.15/lib/benchmark_driver/runner.rb:35:in `block in run'
	from /home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/benchmark_driver-0.10.15/lib/benchmark_driver/runner.rb:29:in `each'
	from /home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/benchmark_driver-0.10.15/lib/benchmark_driver/runner.rb:29:in `run'
	from /home/kjmenard/.rbenv/versions/2.4.4/lib/ruby/gems/2.4.0/gems/benchmark_driver-0.10.15/exe/benchmark-driver:104:in `<top (required)>'
	from /home/kjmenard/.rbenv/versions/2.4.4/bin/benchmark-driver:23:in `load'
	from /home/kjmenard/.rbenv/versions/2.4.4/bin/benchmark-driver:23:in `<main>'

I think the error should be handled with hints on how to tune the process to get better results. Note, however, that even for seemingly simple benchmarks I had to increase the run duration to many minutes just to get the parameter values to work. This seemed to be far in excess of what was needed to actually warm up. I think it may be worth revisiting when to determine warm up has completed.

Yeah, I want to improve the situation. Could you give me some example benchmark definitions to be fixed?


Fixed cls attribute being ignored

It seems like the class attribute for supplying custom css classes to the field is being overwritten and hence ignored entirely.

I can see that my account was flagged (shadow banned), hence why my pull request wasn't public - so once more I'll ping you just in case you haven't actually received any pings yet @mdelobelle

Hi sorry I totally missed this PR.... the repo has evolved quite a lot since then but I see your point and made the change in the code based on your proposal, will be available in a future release. Hence closing this PR. Sorry again about that


[Backport 2.x] Bump org.apache.maven:maven-model from 3.6.2 to 3.9.1

Description
Backport of https://github.com/opensearch-project/OpenSearch/pull/6753
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed per the DCO using --signoff
[ ] Commit changes are listed out in CHANGELOG.md file (See: Changelog)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Gradle Check (Jenkins) Run Completed with:
* **RESULT:** FAILURE ❌

* **URL:** https://build.ci.opensearch.org/job/gradle-check/12721/

* **CommitID:** [a3b954e](https://github.com/opensearch-project/OpenSearch/commit/a3b954ea91284854b2711e090107069d9aca39e1)
  Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
  Is the failure [a flaky test](https://github.com/opensearch-project/OpenSearch/blob/main/DEVELOPER_GUIDE.md#flaky-tests) unrelated to your change?

https://github.com/opensearch-project/OpenSearch/issues/5958

Gradle Check (Jenkins) Run Completed with:
* **RESULT:** FAILURE ❌

* **URL:** https://build.ci.opensearch.org/job/gradle-check/12726/

* **CommitID:** [494f2ce](https://github.com/opensearch-project/OpenSearch/commit/494f2ce373efc4e36e4527d140fbf5e22b8da38d)
  Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
  Is the failure [a flaky test](https://github.com/opensearch-project/OpenSearch/blob/main/DEVELOPER_GUIDE.md#flaky-tests) unrelated to your change?

https://github.com/opensearch-project/OpenSearch/issues/6738

Codecov Report

Merging #6769 (714b9f7) into 2.x (3c9eeb4) will increase coverage by 0.04%.
The diff coverage is 57.77%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff              @@
##                2.x    #6769      +/-   ##
============================================
+ Coverage     70.46%   70.51%   +0.04%
- Complexity    59440    59519      +79
============================================
  Files          4806     4806
  Lines        285284   285283       -1
  Branches      41470    41470
============================================
+ Hits         201034   201175     +141
+ Misses        67451    67340     -111
+ Partials      16799    16768      -31

Impacted Files
Coverage Δ

...e/internal/InternalDistributionBwcSetupPlugin.java
0.00% <0.00%> (ø)

...a/org/opensearch/gradle/test/DistroTestPlugin.java
0.00% <0.00%> (ø)

...eighted/put/TransportAddWeightedRoutingAction.java
25.00% <0.00%> (ø)

...ster/metadata/MetadataCreateDataStreamService.java
60.75% <0.00%> (-0.78%)
:arrow_down:

...rch/extensions/rest/RestSendToExtensionAction.java
26.92% <0.00%> (+0.34%)
:arrow_up:

...rc/main/java/org/opensearch/index/IndexModule.java
81.92% <0.00%> (ø)

...rc/main/java/org/opensearch/index/IndexWarmer.java
47.14% <0.00%> (ø)

...rg/opensearch/index/analysis/AnalysisRegistry.java
84.58% <0.00%> (ø)

...n/java/org/opensearch/index/translog/Translog.java
81.25% <0.00%> (-0.83%)
:arrow_down:

...regations/bucket/composite/DoubleValuesSource.java
83.82% <0.00%> (+1.21%)
:arrow_up:

... and 24 more

... and 494 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


[Bug Report] - Civic Profile: Housing Info

Describe the bug:
Console warning of unstyled content in console log in 4 input fields and State input accepts any string.
Expected behavior:
Unsure if the console error is worth looking into.
I'd want the state input to be a dropdown of set values instead of typing my state.
Actual Behavior:

When typing input for street, city, state & zip, a console error appears: Layout was forced before the page was fully loaded. If stylesheets are not yet loaded this may cause a flash of unstyled content. (menu.html)

State input: should be a set dropdown of states (name or abbreviation) instead of a basic text input to reduce errors. I can currently enter random strings and it is submitted without an error

Screenshots:

To Reproduce:
Steps to reproduce the behavior:

Go to 'Civic Profile > Housing Information'
Fill out the form
Submit
See error in console log

Desktop (please complete the following information):

OS: Mac
Browser Firefox
Version 129.0.1

Possible Fix:
Update form for State input to be a dropdown instead of a basic text input.

The console error is only for Firefox. It shows up on the Log In page too.


Please provide crnn training example

Hi Keunwoo!
Thank you for this repo!
But can you please provide a code chunks for model training?
Number of epochs, batch size and number of samples, etc...
I would like to train my own model with this dataset:
https://github.com/mdeff/fma
For now I have created a custom generator but maybe you can point out few hints.
Thank you.
def MelGenerator(features, labels, batch_size):
 # Create empty arrays to contain batch of features and labels#
    batch_features = np.zeros((batch_size, 96, 1366, 1))
    batch_labels = np.zeros((batch_size,1))
    while True:
        for i in range(batch_size):
        # choose random index in features
            index = randint(0, np.size(batch_features,0))
            batch_features[i] = features[index]
            batch_labels[i] = labels[index]
        yield batch_features, batch_labels

Hi, training part would more depend on the dataset, or rather be general regardless of the task. I don't think there' a particular problem in your generator. Batch size was approx 16-32. Other details are in my paper which is linked in the README. FMA is good and large enough, I think you'd get some nice results with it.

ok, thank you for information!


Remove static muts from logging package

Upcoming clippy versions have more aggressive warnings about static mut, so I'm removing them from the logging package. The defmt frontend uses a custom static with interior mutability. The implementation is otherwise the same.
I refactored the rest of the package to use &'static muts produced by the static_cell package. This lets us remove the explicit uninitialized memory and the mutable statics. The details are unchanged.
Tested the rtic_logging example on an 1170EVK: logging frontend with both backends, and the defmt frontend with just the LPUART frontend.

It could be a compile-time decision, and most examples in this repo demonstrate backend selection based on a constant. But by representing a Poller with runtime dispatch, we enable a use-case where programs can select a logging backend during start-up (read a config from storage, check a GPIO, etc). These users don't need to propagate a backend type state around their interfaces.


Speedseq submitted via SGE Scheduler

Hello,
I want to run speedseq on my server, which is running the SGE scheduler.  When I just SH the example script "run_speedseq.sh" I can get the program to run fine, and the outputs are all correct.  But when I run via the server, it seems the commands are being written to the standard out file.
My outfile:
Sourcing executables from /opt/tools/speedseq/bin/speedseq.config ...
Aligning...
    mkdir -p example.ndIsseRdarl9/full example.ndIsseRdarl9/spl example.ndIsseRdarl9/disc
    mkfifo example.ndIsseRdarl9/spl_pipe example.ndIsseRdarl9/disc_pipe

    /opt/tools/speedseq//bin/bwa mem -t 1 -p  -R '@RG   ID:NA12878  SM:NA12878  LB:lib1' /opt/tools/speedseq/example/data/human_g1k_v37_20_42220611-42542245.fast

a /opt/tools/speedseq/example/data/NA12878.20slice.30X.fastq.gz |
/opt/tools/speedseq//bin/samblaster --excludeDups --addMateTags --maxSplitCount 2 --minNonOverlap 20 --splitterFile example.ndIsseRdarl9/spl_pipe --discordantFile ex
ample.ndIsseRdarl9/disc_pipe |
/opt/tools/speedseq//bin/sambamba view -S -f bam -l 0 /dev/stdin |
/opt/tools/speedseq//bin/sambamba sort -t 1 -m 1G --tmpdir=example.ndIsseRdarl9/full -o example.bam /dev/stdin
    gawk '{ if ($0~"^@") { print; next } else { $10="*"; $11="*"; print } }' OFS="  " example.ndIsseRdarl9/spl_pipe | \
        /opt/tools/speedseq//bin/sambamba view -S -f bam -l 0 /dev/stdin | \
        /opt/tools/speedseq//bin/sambamba sort -t 4 -m 1G --tmpdir=example.ndIsseRdarl9/spl -o example.splitters.bam /dev/stdin
    gawk '{ if ($0~"^@") { print; next } else { $10="*"; $11="*"; print } }' OFS="  " example.ndIsseRdarl9/disc_pipe | \
        /opt/tools/speedseq//bin/sambamba view -S -f bam /dev/stdin | \
        /opt/tools/speedseq//bin/sambamba sort -t 4 -m 1G --tmpdir=example.ndIsseRdarl9/disc -o example.discordants.bam /dev/stdin

    /opt/tools/speedseq//bin/sambamba index example.bam
        /opt/tools/speedseq//bin/sambamba index example.discordants.bam
        /opt/tools/speedseq//bin/sambamba index example.splitters.bam

Done
If I run these commands (the ones printed to the screen and captured in my out file) then the pipeline will work.  Any help here?
Thanks,
Phil

@Phillip-a-richmond
Phillip -- I'm running into a similar issue. Interactively the commands are successfully, but submitted through SGE they fail. Did you find a solution?
James


[YUNIKORN-956] remove old REST handlers: objects and code

What is this PR for?
Remove old REST API and its handlers.
What type of PR is it?

[ ] - Bug Fix
[x] - Improvement
[ ] - Feature
[ ] - Documentation
[ ] - Hot Fix
[ ] - Refactoring

Todos

[ ] - Documents might need to update

What is the Jira issue?
https://issues.apache.org/jira/browse/YUNIKORN-956
How should this be tested?
make test
Screenshots (if appropriate)
Questions:

[ ] - The licenses files need update.
[ ] - There is breaking changes for older versions.
[ ] - It needs documentation.

Hi @yangwwei
Thanks for the prompt reply and comments.

Hi @cchung100m, we are finally to the point where we are ready to remove the old v1 REST API. Are you able to update this PR and resolve the conflicts?

Closed in favor of #403 as this one has gone stale.


writeBits design is extremely inefficient for practical use

Describe the feature you'd like
Currently the signature of writeBits is:
-- | Given a 'BuiltinByteString', a list of indexes to change, and a list of values to change those
-- indexes to, set the /bit/ at each of the specified index as follows:
--
-- * If the corresponding entry in the list of values is 'True', set that bit;
-- * Otherwise, clear that bit.
writeBits ::
  BuiltinByteString ->
  BuiltinList BuiltinInteger ->
  BuiltinList BuiltinBool ->
  BuiltinByteString

Instead it should be:
-- | Given a 'BuiltinByteString', a list of indexes to change, and a boolean set/clear flag, set the /bit/ at each of the specified indices
-- if the boolean is true or clear the /bit/ at each of the specified indices if the boolean is false.
writeBits ::
  BuiltinByteString ->
  BuiltinList BuiltinInteger ->
  BuiltinBool ->
  BuiltinByteString

The issue with the current implementation is that any non-trivial use requires a huge amount of wasted work in constructing the BuiltinList BuiltinBool argument. If the caller wants to set and unset bits, they can simply call writeBits twice once with the indices they want to set and the flag set to true, and the second time with the indices they want to clear and the flag set to false.
Consider the current practical use-case:
-- | Return true iff the first 256 integers in the list are all unique.
isUniqueSet :: BuiltinList BuiltinInteger -> Bool
isUniqueSet xs =
  let byteArray = replicateByte 32 0
       flagUniqueBytes = writeBits byteArray xs
   in (countSetBits flagUniqueBytes) == builtinListLength xs

 replicateBuiltinTrue :: Integer -> BuiltinList BuiltinBool
 replicateBuiltinTrue n = go
   where
     go n =
       if (n == 0)
       then BI.mkNilData BI.unitval
       else BI.mkCons (toOpaque True) $ go (n - 1)

 builtinListLength :: BuiltinList a -> Integer
 builtinListLength xs = go 0 xs
   where
     go acc l = matchList l (\_ -> acc) (\_ ys -> go (acc + 1) ys)

Notice replicateBuiltinTrue blows up the script budget? Each recursive call invokes 4 builtin functions, a builtin ifThenElse, a builtin equalsInteger, a builtin subtractInteger, and a builtin mkCons.
Here is what the implementation would look like with the suggested interface for writeBits, notice that repliaceBuiltinTrue is not required. There is an absolutely massive difference in efficiency.
-- | Return true iff the first 256 integers in the list are all unique.
isUniqueSet :: BuiltinList BuiltinInteger -> Bool
isUniqueSet xs =
  let byteArray = replicateByte 32 0
       flagUniqueBytes = writeBits byteArray xs (toOpaque True)
   in (countSetBits flagUniqueBytes) == builtinListLength xs

 builtinListLength :: BuiltinList a -> Integer
 builtinListLength xs = go 0 xs
   where
     go acc l = matchList l (\_ -> acc) (\_ ys -> go (acc + 1) ys)

Describe alternatives you've considered
No response

The important thing to note is that even in the non-sensical case where the BuiltinList BuiltinBool list is provided already and does not need to be constructed / checked onchain, then this suggested change would only introduce 1 additional builtin call, ie. instead of calling writeBits once, we have to call it twice, once for the bits we want to set and once for the bits we want to clear. I'd imagine even in this scenario with the additional call it might still even be cheaper because the cost of writeBits would decrease as it no longer needs to fmap on the boolean flag list. But even if it isn't cheaper, the additional cost is completely negligible, where-as in any other scenario (where you either need to construct the BuiltinBool list onchain, or traverse it and apply validation to its contents) the cost is reduced by at-least n (where n is min length of both lists) builtin calls (required to construct the list) and often more (4 * n builtins each recursive call + lots of function applications to recurse) ie in the above example.

This is great reasoning and I fully agree with it.
We can't change that much the signature of a builtin once it was released in a hard fork, but we can when the builtin isn't used by anything on the chain yet. Or we can introduce a new builtin.
@kwxm writeBits isn't used on the chain yes, right? Should we change before it's too late?

I

This is great reasoning and I fully agree with it.
We can't change that much the signature of a builtin once it was released in a hard fork, but we can when the builtin isn't used by anything on the chain yet. Or we can introduce a new builtin.
@kwxm writeBits isn't used on the chain yet, right? Should we change before it's too late?

For what it's worth I am strongly in favor of changing it now given that it has not been used onchain yet. This means we have a limited opportunity window to correct this now without needing to permanently introduce a new builtin or replace the old one (and thus break backwards compatibility between V1-3 scripts and >=V4 scripts). I will get confirmation from all the ecosystem dApps that they are either not currently working on a PlutusV3 upgrade, or if they are that it isn't using this builtin. I'll post the feedback here.

It can't possibly have been used on the chain, since it won't be enabled until Chang+1.
If this problem is a serious concern, we should postpone enabling this particular builtin until Chang+2, since delaying Chang+1 is unlikely going to be an acceptable option.

If this problem is a serious concern, we should postpone enabling this particular builtin until Chang+2

I'd vote for that.

That makes sense to me.

@kozross @kwxm what's your opinion?

@zliu41 - I find the reasoning persuasive, and the current implementation wasn't anyone's intent, but was forced by circumstances. Originally, it was meant to be a list of pairs of index-value, but that turned out to not be workable.
If we want to change writeBits, I support @colll78's proposed signature. This also nicely avoids some weirdness with the current implementation (such as 'what happens when the two lists don't match in length').

I think this is a good idea and we should do it.  It'll simplify the implementation and the specification signficantly as well.

Originally, it was meant to be a list of pairs of index-value, but that turned out to not be workable.

It would probably be better w.r.t. what's discussed in this issue for some use cases, but

not for the one provided as an example, as instead of creating a new list you'd have to annotate elements of an existing one, which is no better
it's still a linear amount of additional builtin calls

Making writeBits receive a single Bool and calling the builtin twice is just a better approach overall.

This suggestion has been implemented in #6547. We'll have to update the CIP and the Plutus Core specification, but everything else is done.

@kwxm

This suggestion has been implemented in https://github.com/IntersectMBO/plutus/pull/6547. We'll have to update the CIP and the Plutus Core specification, but everything else is done.

Who is responsible for updating the CIP-122 specification to match this change?

@kwxm

This suggestion has been implemented in #6547. We'll have to update the CIP and the Plutus Core specification, but everything else is done.

Who is responsible for updating the CIP-122 specification to match this change?

I'm not sure, and I'm also not sure if there's any official policy about changing CIPs after they've been approved.  I imagine that in theory what should happen is that if a change to an exsiting CIP is proposed then the change should be approved by the community and no action should be taken until that's done.  In this case we just went ahead and did it because we were in a hurry.  In fact the description of writeBits in the CIP even differs from the implementation that we had before this issue arose (the CIP says it takes a list of pairs but in the  implementation we replaced that with a pair of lists to improve efficiency and make implementation easier, and now we've replaced the second list with a single value).

Those are good questions @kwxm :smile:
For now, note that CIP-122 still has the status of proposed and not active. So I think that changing the CIP is still okay (and even necessary as the specification does not match anymore).
Can you make a PR that corrects the CIP to match the finalized implementation? I think that you, as an implementor of the CIP, have a good overview of how it should change? Furthermore, do not forget to add yourself as an author if you make this PR  :+1:

I hope I am not a bit too late (pun intended), but should the signature of readBit also not change from
readBit :: BuiltinByteString → Integer → Bool

to something like
readBits :: BuiltinByteString → [Integer] → [Bool]

As this way you can save on CEK machine cost if you have to call readBit on multiple bits?

I wonder if it'd really make things cheaper.  With readBit, if you want to read multiple bits then you have to call it multiple times.  If we made it into readBits then you'd only have to call it once, but presumably you'd usually have to iterate over the list of booleans that you get back.  Maybe that'd be cheaper but we'd have to try it and see.  Also it'd probably increase  the cost of just reading a snigle bit. I think we should leave it as it is and we could think about adding a readBits version later if that turns out to be a feature that people really need.

I agree with @kwxm here. Certainly the idea of paralellizing lookups makes sense on paper, but the result you get back is a linked list, which means 'unpacking' these results has linear (if not quadratic) cost. Thus, just doing the lookups one by one actually ends up costing the same.


Dev: Enhancement add support for dbGroup in is_unique and is_not_unique validation rules

I recently posted a feature request on the CodeIgniter forum regarding the is_unique and is_not_unique validation rules. The current implementation lacks support for specifying a dbGroup, which can cause issues when working with multiple database connections.
Here is the forum post for additional context: https://forum.codeigniter.com/showthread.php?tid=91760
Request: I propose enhancing the is_unique and is_not_unique validation rules to optionally accept a dbGroup as a parameter. This would allow users to specify the database connection they want the rule to apply to, providing more flexibility in multi-database environments.
I am planning to submit a pull request (PR) with these changes soon. If there are any suggestions, please let me know.
Thank you for considering this enhancement!

To be fixed in 4.6


[Minor] Added disabled prop in tag component

What's the difference between the Storybook's examples "with icon" and "with large icon"?

What's the difference between the Storybook's examples "with icon" and "with large icon"?

Large icon is an icon bigger than the icon size from the specs. It is added to check it is escalating well (from 48px to 24px):

More things to add to my review:

Disabled Tag with linkHref, which displays as an anchor, works when it is clicked.
Focus now doesn't work as usual, it displays the default HTML focus instead of our custom one. Also, the focus works with the disabled state:

As expected:

Does the disabled state make sense when the component is not clickable (anchor or link) and doesn't have hover or focus? What do you think about this @aweell?

If there's no interaction doesn't make much sense to have a disabled state.


Criteria::lockForUpdate documentation is missing?

I struggle to use a newer way of locks. Who can help?
https://github.com/propelorm/Propel2/blob/master/src/Propel/Runtime/ActiveQuery/Criteria.php#L1400
If there's a better place to ask for this, happy to do so - just guide me!
Thanks!

Yes, this function lacks documentation.
It was introduced together with other lock functions in PR https://github.com/propelorm/Propel2/pull/1658.
There is a little documentation on the intent in this PR and links to the underlying DB logic but also a call for proper documentation from https://github.com/propelorm/propelorm.github.com/issues/417 in the documentation repo.
What I really don't really understand is why this function you mention is not covered at all in the official website and documentation https://propelorm.org/documentation/ within the source code repo https://github.com/propelorm/propelorm.github.com
Instead, along with a lot of other crucial documentation, this file is documented only under https://api.propelorm.org using a different source code repo: https://github.com/propelorm/api.propelorm.org
Your documention should be in this file: https://api.propelorm.org/2.0-master/Propel/Runtime/ActiveQuery/Criteria.html
Unfortunately, the API repo has last been updated almost 11 years ago. As I understand it, it once was generated automatically also 11 years ago with https://github.com/FriendsOfPHP/Sami and then received only a few commits afterwards. Although the Sami repo is also grandfathered since 2019 maybe it is still possible to get this running again to update the API docs for all the changes in the API within the last 11 years.
Besides a proper update for the API docs (be it automatic or manual) - what I actually find really important is to integrate the API documentation into the main documentation and if possible, even merge the repos.
Today, there is only one tiny link in https://propelorm.org/documentation/ pointing to the API docs. I always overlooked this link until today because I was often times looking for functions or constants concerning Criteria or ModelCriteria and finally had to google up the relevant pages when I had a question as most of this stuff is not really covered in the 2.x main docs. Some stuff is even better explained in the old 1.x docs 😱.  Also the proper TableMap documentation I could only find via googling the relevant API doc page. And these API doc pages are most often not under the top results if you google for something specific. Granted - I now should finally bookmark this stuff 😁.
Saying this, I would love to have the documentation as a whole unified, streamlined and updated.
If anyone is reading this comment who has a say on this, please prodive your opinion if/how this can be accomplished.
All the best,
Kaspar.


Fix an issue where edited message could be saved without the content and attachments when rich text editor is enabled

What

fixed the issue
added tests
renamed variables

Why

How Tested

Process & policy checklist

[ ] I have updated the project documentation to reflect my changes if necessary.
[ ] I have read the CONTRIBUTING documentation.

Is this a breaking change?

[ ] This change causes current functionality to break.

Thanks for adding all of these tests!


Istio proxy should advertise capabilities

At present istio proxy has build versions like the following
node.build_version: a7b2578494d79fe098f0e99282e0236946562fa0/1.12.0/Clean/RELEASE/BoringSSL
node.metadata.ISTIO_VERSION: 1.4.2
When https://github.com/envoyproxy/envoy/pull/9301/files merges we should advertise capabilities.

One problem with this that looking at the version doesn't have is we may not know we should be advertising until later. So I may support field "foobar" but not realize I should be advertising it, then months later we decide we need to set foobar in pilot but proxies that support it didn't advertise it. The version works though since we can backtrack and realize we supported foobar since 1.x.y


cleanup qtserial and qtlocation

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin please rerender

Are you happy to merge this @SrNetoChan ?

Yes sure!! If it builds, it should mean that all dependecies are satisfied,
right? Go ahead and merge.
A quarta, 8/06/2022, 23:51, Sam Gillingham @.***>
escreveu:

Are you happy to merge this @SrNetoChan https://github.com/SrNetoChan ?
—
Reply to this email directly, view it on GitHub
https://github.com/conda-forge/qgis-feedstock/pull/241#issuecomment-1150490822,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA3QU6KZYUXGAPFQBMBP2UTVOEPWXANCNFSM5YAMCLJA
.
You are receiving this because you were mentioned.Message ID:
@.***>

I guess so - couldn't see any messages saying things weren't found. Merging.


[1.15.x] KOGITO-6362 Update Maven calls to be more reliable

https://issues.redhat.com/browse/KOGITO-6362
cherry-pick: https://github.com/kiegroup/kogito-operator/pull/1096
Many thanks for submitting your Pull Request :heart:!
Please make sure your PR meets the following requirements:

[ ] You have read the contributors' guide
[ ] Pull Request title is properly formatted: [KOGITO-XYZ] Subject
[ ] Pull Request contains a link to the JIRA issue
[ ] Pull Request contains a description of the issue
[ ] Pull Request does not include fixes for issues other than the main ticket
[ ] Your feature/bug fix has a unit test that verifies it
[ ] You've ran make before-pr and everything is working accordingly
[ ] You've tested the new feature/bug fix in an actual OpenShift cluster
[ ] You've added a RELEASE_NOTES.md entry regarding this change

How to retest this PR or trigger a specific build:

Run operator BDD testing
Please add comment: /jenkins test

Run RHPAM operator BDD testing
Please add comment: /jenkins RHPAM test

/jenkins test


update fortio to 1.4.1

Update to current fortio (includes fix for #21289 )
<EMAIL_ADDRESS>[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[X] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[X] Test and Release
[ ] User Experience
[X] Developer Infrastructure

@googlebot I signed it!