Fix dependencies and build on the romcal-es6branch

Update node dependencies.
The @std/esm package has been deprecated in favour of esm. Also esm have limited the .mjs files to basic functionality without support for esm options, to align with the current experimental support in Node. More details here. According to that all .mjs files in the romcal project have been renamed back to .js.

The front-end build still need some works, including uglify/minify and configure source-map.
This also might fix #49.

@pejulian, I also notice that you didn't transpose the cache for dates, on the new es6 codebase. Is it intentional, or something that you didn't have time to include again?

Anyway, do you know why this PR is checked by Travis? I cannot find it at Travis too.

@pejulian, I also notice that you didn't transpose the cache feature for dates, on the new es6 codebase. Is it intentional, or something that you didn't have time to include again?

As @pejulian is currently AWOL, do what you think is the best. :smiley:

1 - install / building/ running steps
Generally Node.js projects (like that one) on Github don't specify that you have first to install node.js (which include npm). Because people on Github are mostly developpers.
But I'm aware that romcal isn't a "mainstream" project, and might interest people not all developpers or familiar with JavaScript / Node.js development.
However I dont' think it's a good idea to give all the detailed instructions on how install Node.js, or npm, or Yarn... Because there is various ways in different OS. For exemple I've installed node.js via nvm so I can easily switch between different node.js versions on my mac.
Instead I'll suggest to complete a little bit the "Usage" section in the readme.md, and maybe rename it to Installation instead of Usage (more clear).
The beginning could looks like:
⏳ Installation
Install Romcal with this Quickstart command :

Use NPM (with node installed)

$ npm install romcal

Use yarn (install yarn with these docs)

$ yarn add romcal

... and so on.
You don't have to clone romcal, except if you want to contribute to this project (so theses instructions should be elsewhere in the doc).
In the contribution section, we should suggest first to fork romcal in our own github account, and then clone (to install locally) this forked repo. So you have your own working space (it's a best practice). But I'm pretty sure that this kind of documentation already exists somewhere on Github, so we don't have to reinvent the wheel.
Also it's no necessary to install webpack, webpack-cli or mocha globally. That should be fixed in this PR.
And I don't recommend to do npm audit fix. Since it could update/modify dependencies of dependencies that could break things. It's best to keep dependencies up to date as far as we can, and if there is critical vulnerabilities, we should report them instead, in the issue tracker of this dependencies.
2
I don't have this issue one Firefox, Safari or Chrome on my mac. But there is still some fine tuning on the build steps for the web package of Romcal. Probably in another PR.
3
Here it's just to give a very basic exemple, that we can easily hack directly in the browsers. So I don't think it's a problem if it don't follow good practices in web development here.
4
I already created a new version 1.3.1. The major refactor from @pejulian correspond to 1.3.0 (also not published yet on NPM).
To stay in the scope of this PR, the following points you are mentioning (as well as the installation documentation) should be handled in separated PRs.
Travis: I have not looked at it yet. I know it was working and checking automatically all new PR for this project, a few months (years) ago. But I don't know what's going on today. Yes we should took a look into it as well...

I've removed the fr localisation in the index.html, and squashed together all the commits concerning the dependencies and build work. All other suggestions will be addressed in future separated PRs.
If everything looks good I think we can merge this PR. Thanks!

1 - install / building/ running steps

I have no problem with your suggestions as long as the instructions will be accessible in more detail. I am a node.js/npm beginner (I have never dealt with any node.js/npm project before romcal). And I really think that romcal could have only a specialised community, i.e. especially those who are Roman Catholics. Therefore I think we should (or need) to be as open (or welcoming) to any of them as we could be to any of these potential contributors. I regard this as a priority for now as we don’t have enough contributors (there are 6 member of romcal organisation, but currently only you and me work on romcal).

Generally Node.js projects (like that one) on Github don't specify that you have first to install node.js (which include npm). Because people on Github are mostly developpers.
But I'm aware that romcal isn't a "mainstream" project, and might interest people not all developpers or familiar with JavaScript / Node.js development.
Mostly does not mean that there are only devs. Do you regard reporters as devs? I personally not. And although I mostly use Git (any Git server, mostly GitLab) for code versioning, some of my repos contain other, non-code related stuff. Git is for (text) file versioning, not only for code versioning.

Therefore I think we should have detailed build instructions. We don’t need to have the build instructions where the regular (npm) installation is, but even there should be a link to them. I think we could use GitHub Wiki pages for the documention or have the docs in docs/ folder within the romcal repo. I have made this proposal/suggestion in #57 and #61 is also related to this issue.

However I dont' think it's a good idea to give all the detailed instructions on how install Node.js, or npm, or Yarn... Because there is various ways in different OS. For exemple I've installed node.js via nvm so I can easily switch between different node.js versions on my mac.
I don’t say we must have a guide how to install npm on any and every Linux distribution. A link to a npm installation instructions (something like this, where the LTS or latest version npm can be downloaded, which is recommended way to install, or even using package managers. You could even mention the nvm which I use too.

Instead I'll suggest to complete a little bit the "Usage" section in the readme.md, and maybe rename it to Installation instead of Usage (more clear).

I don’t think that the Usage is the proper place to include the build instructions—those should be in Installation or Build instructions. Some projects/programs have an Install.md file in the repo root. I think we should have a single place where there we would place all the docs—and I this the best place for them is either docs/ folder in the repo root or the GitHub Wiki. What do you think?

You don't have to clone romcal, except if you want to contribute to this project (so theses instructions should be elsewhere in the doc).

You don’t have to clone it unless you want to build the dev version (i.e. one not yet published on npm). Some (like me) like to be on the edge for some software to test it and report the issues back. So for testing purposes and when a feature a user wants to use is not yet in the npm version yet, the use has to build a program by himself. But the user does not necessarily needs to be a(n npm) dev.

In the contribution section, we should suggest first to fork romcal in our own github account, and then clone (to install locally) this forked repo. So you have your own working space (it's a best practice). But I'm pretty sure that this kind of documentation already exists somewhere on Github, so we don't have to reinvent the wheel.

Yes, the fork → fix → PR → (squash) merge should be mentioned in the Contributing.md file. Although it might be on GitHub (or elsewhere on the Internet), I’d suggest to place a comprehensive, foolproof guide in Contributing.md, because many projects have different requirements. Of course, we need to agree upon one first (we already agreed on the fork → fix → PR → (squash) merge process). Again: the Contributing.md does not need to have all the instructions in itself; there can be links to useful sights that have the instructions we need. If there are no such sites (or the instructions are not such as we want), we should place the instructions into the file.

Also it's no necessary to install webpack, webpack-cli or mocha globally. That should be fixed in this PR.

Good to know. The former instructions (made by @pejulian) included them, so I have kept them.

And I don't recommend to do npm audit fix. Since it could update/modify dependencies of dependencies that could break things. It's best to keep dependencies up to date as far as we can, and if there is critical vulnerabilities, we should report them instead, in the issue tracker of this dependencies.

Agreed on regular patching of the dependencies. The reason I have provided that in the instructions is that I have always had problems with romcal installation (although I have never tried to do so on vanilla OS). Other users might get the same errors, so I think there should be at least a remark how to solve this potential error.

2
I don't have this issue one Firefox, Safari or Chrome on my mac. But there is still some fine tuning on the build steps for the web package of Romcal. Probably in another PR.

I use Firefox Nightly (current version 72.0a1) on CentOS 7 x86_64. But it looks like romcal is buildable, so we might postpone it to a later PR.

3
Here it's just to give a very basic exemple, that we can easily hack directly in the browsers. So I don't think it's a problem if it don't follow good practices in web development here.

I don’t say it is a problem, but I think it might be regarded as enhancement. We might push the improvement of the example to a later PR. (I think the example might show all/most features romcal offers.)

4
I already created a new version 1.3.1. The major refactor from @pejulian correspond to 1.3.0 (also not published yet on NPM).

I think that by releasing we talk about different things. I think a proper release (and all release in general, be it major, minor or patch) should have the following (let’s say) attributes after they are merge to master:

a tag (like v1.2.0 has);
a GitHub release (like v1.2.0 has);
an npm release (like v1.2.3 has).

I regard this as proper versioning system. And I think we should never skip a version publishing to npm, therefore only release (i.e. merge to master) a new romcal version when everything has be double-checked. :smiley:
I agree that this is only a patch to v1.3.0, so no need to increment the major version number. And it is also true that @pejulian did not had time to make proper releases at the end of his maintainership (before he went AWOL).
And I would like to note that we should include proper release notes what has changed since the last release. Currently, you merge directly to master (sort of) any single commit. I think it would be better to have a dev branch were we would check and test if everything is working and then do a squash merge of all commits with release notes in the merge description. The git log would be usable and pretty again. :smiley:

To stay in the scope of this PR, the following points you are mentioning (as well as the installation documentation) should be handled in separated PRs.

Agreed.

Travis: I have not looked at it yet. I know it was working and checking automatically all new PR for this project, a few months (years) ago. But I don't know what's going on today. Yes we should took a look into it as well...

I have no idea too. But it might related to my previous findings (#66 and #67) that the OS used at Travis is outdated. But we might need some authorisation from @pejulian, as if I recall correctly, I could not change the config (because I don’t have @pejulian’s credentials). But I have no experience with Travis. :smiley:

Today I have found another issue (I regard it as major bug): when I change the locale in the example to sk (Slovak), most strings are not localised (although they are localised in skSk.js). For example:
300: Object { type: "FEAST", name: "Saints Simon and Jude, Apostles", key: "saintsSimonAndJudeApostles", … }
301: Object { type: "WEEKDAY", name: "utorok of the 30. week of Ordinary Time", key: "utorokOfThe30WeekOfOrdinaryTime", … }

I agreed with you 👍
For the release, I still thing working directly on master is enough for small things. People will don't get automatically the update until we tag and publish to npm, and we can always take care of the release # and history before publish it. This is the way a lot other projects are doing, and in my experience point of view, I thing it's also reasonable for romcal.
If people include romcal in their projects, targeting the last commit change instead, instead a last/specific release (which is a bad practice unless you know what they are doing), it's at their own risk.
But let's try to keep the discussion on the scope of this PR, and use the issue tracker for all other things.

For the release, I still thing working directly on master is enough for small things.

Okay, but we should not increment a version when we don’t publish one. But this seems to me not the proper way to do releases.

Still, I don’t know if you have read this (I think this is very related to this PR):

Today I have found another issue (I regard it as major bug): when I change the locale in the example to sk (Slovak), most strings are not localised (although they are localised in skSk.js). For example:
300: Object { type: "FEAST", name: "Saints Simon and Jude, Apostles", key: "saintsSimonAndJudeApostles", … }
301: Object { type: "WEEKDAY", name: "utorok of the 30. week of Ordinary Time", key: "utorokOfThe30WeekOfOrdinaryTime", … }

We are not yet on master, so not the time yet to do a release. And we don't bump the version each time we do a commit. The purpose of this PR was to make the romcal-es6 branch working again so then we can test and fix what need to be fixed.
For the bug you mentionned, please create a new issue (if it doesn't exist) so we can check that separately. I'm actually rebasing this branch from master and I'm getting some headaches with locale keys since we got updates in both master and romcal-es6. It have too much stuffs not related of the main purpose of this branch: revamp the code to the es6 syntax with the help babel, esm and webpack.

I believe that the version bumping should be done after all changes are made and were checked, not before. That is, the version bumping should be the last thing made before version release (merging to master, GitHub tag and release creation and npm release).
I see that too many things needs to be fixed at once. Still I am glad you’ve taken up that burden. ;)
I have already created/updated some issues based upon our conversation in this PR. :smiley:


Second order stuff

[ ] Second order backend
[ ] Hessian and hessian-vector products
[ ] Second derivative
[ ] Test more combinations

Mostly done


Can't generate rails task after installing es-rails

Hi.
I installed es-rails into my application running docker.
After installing, I executed the following command. However, I couldn't.
$ docker-compose run web rails g task elasticsearch
Starting research_app_db_1 ... done
The git source https://github.com/elastic/elasticsearch-rails.git is not yet checked out. Please run `bundleinstall` before trying to start your application

I tried docker-compose run web bundle install again but I can't do it yet.
Please tell me the way to resolve this problem.

@hiracky16 What are you trying to accomplish with the command?

@estolfo Thank you reply Emily.
I hope to make a Rake task to index into ElasticSearch.
When I try to generate task, this problem is happened.

@hiracky16 Are you trying to import your models as outlined here ?

@estolfo
Thank you for telling me the way to resolve this problem!
I can generate task 👍

Great, I'm glad you've resolved it!


A Google Compute Engine setup guide

Hi, i've been trying to set this up on a GCE f1-micro vm, but i'm not quite sure how to go about that (I did try a few things in the dashboard thing, and i have been able to get it to start and bind to a port, but now i have issues configuring it, exposing the ssh server etc.), and I haven't been able to find any tutorials that use GCE, i'll probably be able to figure it out after staring at the documentation for a bit longer but a easy straight forward guide specifically with sish in mind would be nice :)
Thanks!

Hello!
I like this idea and I have been thinking of creating either simple guides to get an instance up and running with sish, or images that are prebuilt with sish use in mind. Not sure when I'll have time to work on this though.
Best,

Deploying to heroku isn't currently possible sadly! Mainly because sish listens on a TCP service and last I checked you can't do that with heroku.

I spent more than an hour to try with gcloud and couldn't get it working either... So it would be really great if we have this 😆

Hi there! Could you describe the issues you're having a little bit? I plan on spending some time on this in the coming weeks!

Many in fact, I first tried using it's image feature to try to run it directly when creating a new vm instance, which didn't work... And then I tried to do it manually (with my own ssh keys but without specifying the ssh private key) and it refuses my ssh connections. I then went to firewall and realized the default firewall rule only allows port 22, so I added my own rule allowing 2222, but still no luck yet...

So would be great to have a guide to work with the image directly when creating a vm 😆
Also am wondering if it's possible to use a root domain rather than a subdomain for this...
Thank you a lot!!

Yep, GCP has a bunch of different features so it definitely is difficult to make sure everything is setup properly so I'll take a look! sish does support routing to a domain root instead of a subdomain, just take a look at the CLI flags!

I thought so, and I did go through the flags; but maybe it wasn't obvious enough to me which one is the flag I want...
Anyway, I might be able to figure it out myself if I have gcp set up to begin with 😂 so I think the guide would be what we need.
Many thanks!

Hi! Just trying to resurface this in a friendly and gentle manner 😁

I am working on setting up sish in a Google Compute Engine f1 micro instance (debian) right now. If I manage to get things setup properly, I'll return here and provide any tips or answers I can.

Hey everyone, I've put together something here. Sorry about the delay, I've been dealing with a loss in the family and have been quite busy lately. I'm going to close this issue, but any comments or recommendations to update the tutorial would be helpful if you could leave them in this issue.


Bump dependencies

✄ -----------------------------------------------------------------------------

Could you please do this next time just in one pr? There is no reason to open 2 prs for this.

Could you please do this next time just in one pr? There is no reason to open 2 prs for this.

@bkchr Sorry about that.  I use the hub command-line tool to create PRs, and I didn’t realize the first one had already been merged.

interesting to use in the future
https://blog.rust-lang.org/inside-rust/2019/10/03/Keeping-secure-with-cargo-audit-0.9.html


Using var electron = require('electron'); in index.html

i'm trying to use Electron with angular-cli, however, when i build the .exe the variable  has set to undefined. On development environment its work normaly.
i've tryed to import manually electron on .exe directory, but it's fail to send SendSync.
In my Index:

in typings.d.ts:
declare var electron: any;
In component:
const {ipcRenderer} = electron;
console.log(ipcRenderer.sendSync('synchronous-message', 'ping'));
In package.json dependencies:
"@angular/common": "~2.1.0",
"@angular/compiler": "~2.1.0",
"@angular/core": "~2.1.0",
"@angular/forms": "~2.1.0",
"@angular/http": "~2.1.0",
"@angular/platform-browser": "~2.1.0",
"@angular/platform-browser-dynamic": "~2.1.0",
"@angular/router": "~3.1.0",
"ag-grid": "^6.2.1",
"ag-grid-ng2": "^6.2.0",
"bootstrap": "^3.3.7",
"core-js": "^2.4.1",
"jquery": "^3.1.1",
"rxjs": "5.0.0-beta.12",
"ts-helpers": "^1.1.1",
"zone.js": "^0.6.23",
"electron": "^1.4.5"

This is a little bit of a shot in the dark, but if angular-cli is bundling with webpack, you may need to add this to your webpack config: https://github.com/chentsulin/webpack-target-electron-renderer. Basically webpack rewrites all your requires to it's own internal version of require. Because webpack isn't bundling (nor could it) electron's modules, ipcRenderer is undefined. I think that package above makes it so that things like require('electron') aren't resolved by webpack's require function, it's left to node/Electron.

put node Integration = false and worked! Thanks!


[TFL] Remove (log-)softmax before arg-minmax as (log-)softmax is monotonic

It's a common pattern for classification task. Most models in tf.keras.applications set classifier_activation="softmax" by default. This PR optimizes out that softmax op when users want to get prediction ids only instead of probabilities.

@WindQAQ Could you sync it to head again? There are merge conflicts, which block the submission.

Updated!


Fix Counter Example missing link

Shouldn't the counter example points to this https://github.com/ReSwift/CounterExample-Navigation-TimeTravel?

Current coverage is 100.00%

Merging #53 into master will not affect coverage as of be2b0b9

@@            master     #53   diff @@
======================================
  Files            6       6
  Stmts          100     100
  Branches         0       0
  Methods
======================================
  Hit            100     100
  Partial          0       0
  Missed           0       0

Review entire Coverage Diff as of be2b0b9

Powered by Codecov. Updated on successful CI builds.

It should! Thanks a lot for the fix!

You're welcome :+1:


Created Pull Request Template

Fixes #577
Before:

After:

@anuragverma108 Please review my PR and merge it if it is good to go


Gunnery Skill translation and others

Gunnery Skill translation and others

Thanks for reopening this

You're welcome !
I was in a rush when I did it the first time ^^
Le mer. 1 févr. 2023, 14:19, LebombJames @.***> a
écrit :

Merged #952
https://github.com/foundryvtt-starfinder/foundryvtt-starfinder/pull/952
into development.
—
Reply to this email directly, view it on GitHub
https://github.com/foundryvtt-starfinder/foundryvtt-starfinder/pull/952#event-8410326548,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQMGTQ2JT5AAPI227FA4MUTWVJPGLANCNFSM6AAAAAAUNRERQ4
.
You are receiving this because you authored the thread.Message ID:
<foundryvtt-starfinder/foundryvtt-starfinder/pull/952/issue_event/8410326548
@github.com>


Fix warning duration for whm spells when they never use them

Make 2 lines of change after over an hour of work, proving that people in charge need to reevaluate my skills as a dev
Modify said file to modify the time held duration based on casts – if 0 casts, then it's the fight duration; otherwise the regular logic should hold

Looks good to me, maybe some Typescript magic to validate held exists could help, I'm not 100% sure tho.

It looks like the interface CooldownTrack has held set as a not-nullable field, and the method that creates it always initializes it with a 0 as the default.
This took me a bit longer than I liked, but I'm not 100% familiar with this module.


fix 1760/1758 baiji group 264-3

Signed-off-by: YTTmiao<EMAIL_ADDRESS>
Ⅰ. Describe what this PR did
add test in image_proxy_util_test.go and config_test.go
Ⅱ. Does this pull request fix one issue?
fix 1760 and 1758
Ⅲ. Describe how you did it
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

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

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@afc7a21). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #1828   +/-   ##
=========================================
  Coverage          ?   56.58%
=========================================
  Files             ?      200
  Lines             ?    15659
  Branches          ?        0
=========================================
  Hits              ?     8861
  Misses            ?     5700
  Partials          ?     1098

Flag
Coverage Δ

#critest
33.5% <ø> (?)

#integrationtest
37.67% <ø> (?)

#unittest
20.6% <ø> (?)


Metamask don't working fine

Description
Environment

Browser: Firefox, Chrome, Brave
Wallet: MetaMask, Gnosis, Ledger
Safe: All mainnet network
Environment:

production mainnet

Steps to reproduce

Update all browser
Open Ledger Live
Open browser
Unlock metamask
Login Gnosis (don't working 20% of case, 1rst screen)
Make a transfert
Gas failed, upgrade gas max to bypass them
Metamask pop up don't appear

Expected result
Working
Obtained result

Screenshots

We are supporting only FF and Chrome. There is no issue with connection Ledger via MM in FF
@Sigri44 , the issue will be closed as duplication of #2644 .


Add a primary content (branch patch/content/primar)

Add a primary content (e.g. avatar, name, job, contacts, intro, etc.) here. Commit small steps, add meaningful messages

Primary content template
Contact info items example (should be place inside the contact-info__block)
Intro block (should be put below the previous container)

https://github.com/SkyKeyUA/homepage


fix duplicated feed

For feed, Collabrative option is no need. Just remove it and fix #2366

LGTM

LGTM

make L-G-T-M work


fix: assert failed in example uart_async_rxtxtasks

In esp-idf/components/freertos/FreeRTOS-Kernel/tasks.c:1127, verify uxPriority must be less than configMAX_PRIORITIES.
    /* This is used as an array index so must ensure it's not too large. */
    configASSERT( uxPriority < configMAX_PRIORITIES );

In the example, uxPriority equals configMAX_PRIORITIES, resulting in a failed assert.
xTaskCreate(rx_task, "uart_rx_task", 1024 * 2, NULL, configMAX_PRIORITIES, NULL);

 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.

@DYFeng Thanks for the fix. Changes LGTM.

sha=b8a3141ef96d655271f9b4634c559b61a2bef2be


Rust Regex experts: Codeblocks and inline code in regex

Problem
Hello StyleX community I'm working on a PR #87 for adding reserved words (with correct capitalization) for the spellchecker typos that the StyleX team uses to eliminate unnecessary PRs.
I have forgotten that there are code blocks in markdown files that we would most likely want to ignore. The issue is the way that we can ignore such patterns is through regex and it does not support backreferences and lookaround Rust Regex.
I have gotten this far:
extend-ignore-re = [
    "(`{3,}|~{3,})(\\w+)?\\s*", # Pattern for code blocks
    "([\\s\\S]*?)",
    "`[^`]+`", # Pattern for inline code snippets
]

This regex pattern detects all code blocks with either ~~~ or ```, but it seems to only capture the first instance of inline code snippets. Wanted to see if there was anyone with experience to help make this PR into a reality.
Steps to reproduce
Clone the PR, install typos (using link above) run typos in root directory. Additional rules are as follows:
[type.md]
extend-glob = ["*.md", ".mdx"]
extend-ignore-re = [
    "(`{3,}|~{3,})(\\w+)?\\s*", # Pattern for code blocks
    "([\\s\\S]*?)",
    "`[^`]+`", # Pattern for inline code snippets
]
[type.md.extend-words]
stylex = "StyleX"
typescript = "TypeScript

Any chance we could instead add words we use within the API, CSS and JS, so the typos in code are checked as well?

Ah so instead of ignoring code blocks, for us to define API, CSS and JS typos 🧐 I'll make a push to PR with a possible fix with that method!

I think this was completed. So I'm closing this issue. Let me know if there's more discussion to be had @kevintyj


Breaking Bad API is down

https://breakingbadapi.com/ is for sale.
It should be removed, right?

It should be removed due to copy right content. My application didn't fetch the api it told me this is unauthorized request even website didn't exist

This repo isn't maintained anymore, I think. :/

#122

@nsde yes it is.


Async lifecycle hooks?

Hello!
I've noticed that when using async with my lifecycle hooks, the data is stored in Vuex incorrectly as a promise.
async beforeCreate(context, record) {
  console.log(record);
}

My use case is that I want to persist these records asynchronously (to my backend) after they're created on the client side. Is there a preferred and/or different way of doing so?
Thanks for creating/supporting this awesome library!

Hi! Thank you for the feedback! Yes, unfortunately, Promise (async) is not supported by the lifecycle at the moment.

My use case is that I want to persist these records asynchronously (to my backend) after they're created on the client side. Is there a preferred and/or different way of doing so?

If you need to process the record after they are created, could you try using afterCreate instead of beforeCreate. Then I think it should work fine.

Mmm.. The beforeCreate Lifecycle hook should really support async, because you HAVE TO (no other way around) use it to insert pivot records that have composite primary keys..
And the problem is that the insertOrUpdate is in itself async.. So if you don't wait for the data to be inserted you run into race conditions...


[WIP] Install iTMSTransporter on Circle/Ubuntu

This is not really a PR, I am more looking for feedback.
The relevant part is this:
     - run:
          name: Install additional dependency iTMSTransporter
          command: |
            cd /tmp
            wget https://github.com/janpio/fastlane-ubuntu-foo/raw/master/iTMSTransporter_installer_linux_1.9.7.sh
            sudo sh iTMSTransporter_installer_linux_1.9.7.sh --target itms --noexec
            cd itms
            sudo sed -e '15,43d' -i install_script.sh
            sudo ./install_script.sh

This is a step on Circle CI that is run on Ubuntu, more or less a Shell script.
Problem with this are:

I downloaded the iTMSTransporter_installer_linux_1.9.7.sh from the developer portal of Apple and put it on Github as a login is required to download.
sudo sed -e '15,43d' -i install_script.sh deletes parts of the install script that requires paging though some Terms of Services and typing "yes" twice.

Is there a better way to get this dependency fulfilled on a CI server that I am not seeing?

          1 Warning

:warning:
Pull Request is Work in Progress

  Generated by :no_entry_sign: Danger

Looks like the official URL for linux is https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa/ra/resources/download/Transporter__linux/bin/ (I had a hard time finding it...) We could download it automatically using fastlane as we already support itunesconnect

not sure modifying the script is the proper way to accept the user agreement. Are there CLI options to answer yes? If not does it show a GUI or is in text based? Otherwise you could try with the expect tool to script the answers.

I believe one would want a docker setup file to avoid having to do this like that as part of the build

Re 1: Yes, problem is that this only works when logged in on https://developer.apple.com/account/
Re 2: No CLI options that would skip the licence and prompts. This is what is available:
foo@foo-VirtualBox:~/Downloads$ sudo sh iTMSTransporter_installer_linux_1.9.7.sh --yes
[sudo] password for foo:
Unrecognized flag : --yes
Makeself version 2.1.4
 1) Getting help or info about iTMSTransporter_installer_linux_1.9.7.sh :
  iTMSTransporter_installer_linux_1.9.7.sh --help   Print this message
  iTMSTransporter_installer_linux_1.9.7.sh --info   Print embedded info : title, default target directory, embedded script ...
  iTMSTransporter_installer_linux_1.9.7.sh --lsm    Print embedded lsm entry (or no LSM)
  iTMSTransporter_installer_linux_1.9.7.sh --list   Print the list of files in the archive
  iTMSTransporter_installer_linux_1.9.7.sh --check  Checks integrity of the archive

 2) Running iTMSTransporter_installer_linux_1.9.7.sh :
  iTMSTransporter_installer_linux_1.9.7.sh [options] [--] [additional arguments to embedded script]
  with following options (in that order)
  --confirm             Ask before running embedded script
  --noexec              Do not run embedded script
  --keep                Do not erase target directory after running
			the embedded script
  --nox11               Do not spawn an xterm
  --nochown             Do not give the extracted files to the current user
  --target NewDirectory Extract in NewDirectory
  --tar arg1 [arg2 ...] Access the contents of the archive through the tar command
  --                    Following arguments will be passed to the embedded script

Text based interface, here are screenshots:

...

Here is the actual script that is executed in the background:
#!/bin/sh
#PATH=/usr/bin:/bin
#umask 022
#NODOT_VERSION=142_12
#javahome=j2sdk1.4.2_12
#PACKED_JARS="lib/tools.jar jre/lib/rt.jar jre/lib/jsse.jar jre/lib/charsets.jar jre/lib/ext/localedata.jar jre
#/lib/plugin.jar jre/javaws/javaws.jar"
#LINUX_RPM=
#JAVAWS_BIN=jre/javaws/javaws
#libthread_path=
#localinstall=$1
#diskSpaceRequired=104668
#MIME_TYPE=application/x-java-jnlp-file

more License.txt
agreed=
while [ x$agreed = x ]; do
    echo
    echo "Do you agree to the above license terms? [yes or no] "
    read reply leftover
    case $reply in
        y* | Y*)
            agreed=1;;
        n* | N*)
    echo "You must agree to the license agreement to install this software!";
    exit 1;;
    esac
done

cat Welcome.txt
agreed=
while [ x$agreed = x ]; do
    echo
    echo "Continue? [yes or no] "
    read reply leftover
    case $reply in
        y* | Y*)
            agreed=1;;
        n* | N*)
    echo "Installation aborted by user";
    exit 1;;
    esac
done

if [ -d /usr/local/itms/ ]
 then
  rm -r /usr/local/itms
fi
if [ -d ~/.itmstransporter ]; then rm -rf ~/.itmstransporter; fi
sudo cp -r itms /usr/local/
sudo chmod 555 /usr/local/itms/bin/iTMSTransporter

#use awk to keep finding the parent pid until the user is
#is not root or we reach the top process
FILE_OWNER=`ps -e -o "user ppid pid" | awk -v proc=$$ '{
	user_a[row] = $1
	parent_a[row] = $2
	child_a[row] = $3
#print $1,$2,$3
#print row
	row++
}

END {
	p=proc
        # building one list of users.
        # the user of the current process is the
        # first item.  the user of its parent process
        # is the second item. the user of its grandparent
        # process is the third item.  etc..
        # "pi++<50" is there as a safety to avoid
        # infinite loops
	while (p!=0 && pi++<50){
		user=userForChild(p)
#print user, p
#print "::",user,":",p,":",pi,":"
		p=parentForChild(p)
		userList[pi]=user

	}
        # go through the list of users until we find
        # the first non-root user.  this is the user
        # that su-ed to root.
	i=0
	do {
                i++
 		user=userList[i]
#print "user=:",user,":"
#print i, pi
#print "pi=",pi
#print "i=",i
	}
	while (i<pi && user=="root")
	print userList[i]
}

function userForChild(l_proc) {
	rval=""
	for(i=0;rval=="" && i<row;i++) {
		if (child_a[i]==l_proc) {
			rval=user_a[i]
		}
	}
	return rval
}

function parentForChild(l_proc) {
	rval=""
	for(i=0;rval=="" && i<row;i++) {
		if (child_a[i]==l_proc) {
			rval=parent_a[i]
		}
	}
	return rval
}'`

#chown $SUDO_USER /usr/local/itms/share/iTMSTransporter.woa/Contents/Resources/id_dsa
#echo "FILE_OWNER: "$FILE_OWNER

Re 3: Ah, so just taking the current image and adding iTMSTransporter would be an option. Interesting.

See #11331


Travis CI integration

You can see the output of the Travis CI build(s) here: https://travis-ci.org/kleisauke/php-vips/builds/178825558
It's failing on PHP 7.1 because of this:
1) VipsConvenienceTest::testVipsMaxpos
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
 Array (
-    0 => null
-    1 => null
-    2 => null
+    0 => 6
+    1 => 2
+    2 => 1
 )

/home/travis/build/kleisauke/php-vips/tests/convenience.php:123

I'm not sure why that test is failing. At first look I could not find any fault in that test case.

Hey fantastic! Well done @kleisauke.
I'm sure it was passing with 7.1. I'll build the latest and try here.

Found it, there was a missing deref for optional output arguments which 7.1rc6 can trigger:
https://github.com/jcupitt/php-vips-ext/commit/6d3b9f00e191e2ef5f870b98b100b2f6cb9f6c18#diff-b1cc89f7ef630413232cfad4ba9bdbf2R898
ouch. I bump the ext to 1.0.1 as well, does that fix it for you?

@jcupitt if you can link this repository to travis, and configure it to only build when a config file is present, then we can track this PR's progress over here: https://travis-ci.org/jcupitt/php-vips/

I turned it on (I think) but it looks like travis will only build PRs opened after you enable PR builds.

@jcupitt I think a new commit to an existing branch should trigger a build on travis.

@jcupitt Nice work! I can try to test it on my server by installing PHP 7.1 or we can test it with Travis CI by triggering a rebuild (although that requires an update to the PECL package).

I noticed you're building libvips from github. This will need a lot of packages: things like gtkdoc need to be there for autogen to function.
If you build from the tarballs on the vips website instead, you can skip autogen and go straight for configure. This will work with many fewer packages required.
Building libvips from git master would still require autogen, of course.

@jcupitt I've pushed a new commit that build libvips from the tarball. However the support for git master is now dropped. Is support for the git master needed? If so, I can try to make a if condition to also support the git master.

I'm OK not testing against libvips master. This travis run is focussed on testing php-vips, not libvips.

Hey, looks good! Could you test php-vips-ext on your machine? It would be nice to get confirmation from someone else before pushing a release out.

@jcupitt Just tested on a freshly installed system with Centos 7.2 and PHP 7.1.0RC6. All test passes!
Test results
php-vips-ext:
=====================================================================
PHP         : /usr/bin/php
PHP_SAPI    : cli
PHP_VERSION : 7.1.0RC6
ZEND_VERSION: 3.1.0-dev
PHP_OS      : Linux - Linux centos-1gb-ams2-01 3.10.0-327.36.3.el7.x86_64 #1 SMP Mon Oct 24 16:09:20 UTC 2016 x86_64
INI actual  : /root/php-vips-ext/tmp-php.ini
More .INIs  :
CWD         : /root/php-vips-ext
Extra dirs  :
VALGRIND    : Not used
=====================================================================
TIME START 2016-11-25 16:35:10
=====================================================================
PASS check for vips presence [tests/001.phpt]
PASS vips can load a file [tests/002.phpt]
PASS vips can save a file [tests/003.phpt]
PASS vips can get image header fields [tests/004.phpt]
PASS we can call any vips operation [tests/005.phpt]
PASS vips_call supports optional input and output args [tests/006.phpt]
PASS new_from_file supports optional args [tests/007.phpt]
PASS input array double args work [tests/008.phpt]
PASS input array image args work [tests/009.phpt]
PASS output int arrays work [tests/010.phpt]
PASS typeof works [tests/011.phpt]
PASS new_from_buffer works [tests/012.phpt]
PASS write_to_buffer works [tests/013.phpt]
PASS new_from_array works [tests/014.phpt]
PASS new_from_array sets values correctly [tests/015.phpt]
PASS new_from_array has optional scale and offset [tests/016.phpt]
PASS can set enum from int [tests/017.phpt]
PASS can use 2D array as image [tests/026.phpt]
PASS can use 1D array as constant image [tests/027.phpt]
PASS can call draw operations [tests/028.phpt]
PASS can get error messages [tests/029.phpt]
PASS enum fields are returned as strings [tests/030.phpt]
=====================================================================
TIME END 2016-11-25 16:35:12

=====================================================================
TEST RESULT SUMMARY
---------------------------------------------------------------------
Exts skipped    :    0
Exts tested     :   15
---------------------------------------------------------------------

Number of tests :   22                22
Tests skipped   :    0 (  0.0%) --------
Tests warned    :    0 (  0.0%) (  0.0%)
Tests failed    :    0 (  0.0%) (  0.0%)
Expected fail   :    0 (  0.0%) (  0.0%)
Tests passed    :   22 (100.0%) (100.0%)
---------------------------------------------------------------------
Time taken      :    2 seconds
=====================================================================

php-vips:
> parallel-lint . --exclude vendor
PHP 7.1.0 | 10 parallel jobs
......................................................       54/54 (100 %)

Checked 54 files in 0.9 seconds
No syntax error found
> phpunit
PHPUnit 5.6.5 by Sebastian Bergmann and contributors.

................................................                  48 / 48 (100%)

Time: 947 ms, Memory: 6.00MB

OK (48 tests, 90 assertions)

Great! OK, I've pushed 1.0.1 of php-vips-ext to PECL.

Woo hoo!

I've added a build badge, and it's green! Good job @kleisauke, time for a beer.

@jcupitt No problem! 🍻


Verbose logging for TUI

Is your feature request related to a problem? Please describe.
Printing to stdout is not possible while running TUI since the output is locked by the terminal backend (termion). This causes verbose logging to be suppressed.
Describe the solution you'd like
Add a new command-line flag named --verbose and somehow enable verbose logging while running the TUI.
Describe alternatives you've considered
-
Additional context
This will be useful when some of the parameters cannot be retrieved due to insufficient permissions and error logs are printed. Right now there is no way of telling when the parameter list is fetched without errors when the TUI is launched.

Logging to the terminal when a TUI is rendered might cause rendering issues. Have you considered the following alternatives:

Logging to a log file.
Logging to the syslog.
Tearing down the TUI right before printing to stderr.

Thank you for the ideas @koutheir!
Another alternative would be using tui-logger.

Logging inside TUI would make the logs unavailable for further analysis at a later date, which is a very common use case for logs.

What do you suggest here? @koutheir

I suggest saving the log entries to a log file that can be analyzed after the fact.

tui-logger supports saving the logs to a file and also provides a smart widget for analyzing them. I implemented a draft at #83


HDDS-1391 : Add ability in OM to serve delta updates through an API.

Added an RPC end point to serve the set of updates in OM RocksDB from a given sequence number.
This will be used by Recon (HDDS-1105) to push the data to all the tasks that will keep their aggregate data up to date.

/label ozone

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
52
Docker mode activated.

_ Prechecks _

+1
dupname
1
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

0
mvndep
28
Maven dependency ordering for branch

+1
mvninstall
500
trunk passed

+1
compile
257
trunk passed

+1
checkstyle
74
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
869
branch has no errors when building and testing our client artifacts.

+1
javadoc
164
trunk passed

0
spotbugs
311
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
498
trunk passed

_ Patch Compile Tests _

0
mvndep
37
Maven dependency ordering for patch

+1
mvninstall
453
the patch passed

+1
compile
269
the patch passed

+1
cc
269
the patch passed

+1
javac
269
the patch passed

-0
checkstyle
41
hadoop-ozone: The patch generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
687
patch has no errors when building and testing our client artifacts.

-1
javadoc
70
hadoop-hdds generated 1 new + 14 unchanged - 0 fixed = 15 total (was 14)

+1
findbugs
518
the patch passed

_ Other Tests _

-1
unit
108
hadoop-hdds in the patch failed.

-1
unit
209
hadoop-ozone in the patch failed.

+1
asflicense
43
The patch does not generate ASF License warnings.

5173

Reason
Tests

Failed junit tests
hadoop.utils.db.TestRDBStore

hadoop.ozone.om.ratis.TestOzoneManagerRatisServer

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/1/artifact/out/Dockerfile

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

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

uname
Linux 6169ac17e161 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 29465bf

Default Java
1.8.0_212

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/1/artifact/out/diff-checkstyle-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/1/artifact/out/diff-javadoc-javadoc-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/1/artifact/out/patch-unit-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/1/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/1/testReport/

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

modules
C: hadoop-hdds/common hadoop-ozone/common hadoop-ozone/integration-test hadoop-ozone/ozone-manager U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/1/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
44
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

0
mvndep
22
Maven dependency ordering for branch

+1
mvninstall
547
trunk passed

+1
compile
256
trunk passed

+1
checkstyle
59
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
780
branch has no errors when building and testing our client artifacts.

+1
javadoc
150
trunk passed

0
spotbugs
307
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
598
trunk passed

-0
patch
344
Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

0
mvndep
28
Maven dependency ordering for patch

+1
mvninstall
423
the patch passed

+1
compile
268
the patch passed

+1
cc
268
the patch passed

+1
javac
268
the patch passed

+1
checkstyle
81
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
648
patch has no errors when building and testing our client artifacts.

-1
javadoc
70
hadoop-hdds generated 1 new + 14 unchanged - 0 fixed = 15 total (was 14)

+1
findbugs
522
the patch passed

_ Other Tests _

-1
unit
300
hadoop-hdds in the patch failed.

-1
unit
153
hadoop-ozone in the patch failed.

+1
asflicense
43
The patch does not generate ASF License warnings.

5251

Reason
Tests

Failed junit tests
hadoop.hdds.scm.container.placement.algorithms.TestContainerPlacementFactory

hadoop.ozone.om.ratis.TestOzoneManagerRatisServer

Subsystem
Report/Notes

Docker
Client=18.09.8 Server=18.09.8 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/3/artifact/out/Dockerfile

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

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

uname
Linux 5640f7cf3c34 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 303a7f8

Default Java
1.8.0_212

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/3/artifact/out/diff-javadoc-javadoc-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/3/artifact/out/patch-unit-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/3/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/3/testReport/

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

modules
C: hadoop-hdds/common hadoop-ozone/common hadoop-ozone/integration-test hadoop-ozone/ozone-manager U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/3/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
0
Docker mode activated.

-1
patch
14
https://github.com/apache/hadoop/pull/1033 does not apply to trunk. Rebase required? Wrong Branch? See https://wiki.apache.org/hadoop/HowToContribute for help.

Subsystem
Report/Notes

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

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/4/console

versions
git=2.7.4

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
85
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

0
mvndep
23
Maven dependency ordering for branch

+1
mvninstall
509
trunk passed

+1
compile
265
trunk passed

+1
checkstyle
75
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
926
branch has no errors when building and testing our client artifacts.

+1
javadoc
167
trunk passed

0
spotbugs
357
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
572
trunk passed

-0
patch
403
Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

0
mvndep
31
Maven dependency ordering for patch

+1
mvninstall
448
the patch passed

+1
compile
268
the patch passed

+1
cc
268
the patch passed

+1
javac
268
the patch passed

-0
checkstyle
37
hadoop-hdds: The patch generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

-0
checkstyle
41
hadoop-ozone: The patch generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
763
patch has no errors when building and testing our client artifacts.

-1
javadoc
76
hadoop-hdds generated 1 new + 14 unchanged - 0 fixed = 15 total (was 14)

+1
findbugs
559
the patch passed

_ Other Tests _

+1
unit
372
hadoop-hdds in the patch passed.

-1
unit
313
hadoop-ozone in the patch failed.

+1
asflicense
43
The patch does not generate ASF License warnings.

5834

Reason
Tests

Failed junit tests
hadoop.ozone.om.ratis.TestOzoneManagerRatisServer

Subsystem
Report/Notes

Docker
Client=18.09.8 Server=18.09.8 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/5/artifact/out/Dockerfile

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

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

uname
Linux 42daf491a8cd 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 7f1b76c

Default Java
1.8.0_212

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/5/artifact/out/diff-checkstyle-hadoop-hdds.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/5/artifact/out/diff-checkstyle-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/5/artifact/out/diff-javadoc-javadoc-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/5/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/5/testReport/

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

modules
C: hadoop-hdds/common hadoop-ozone/common hadoop-ozone/integration-test hadoop-ozone/ozone-manager U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/5/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

+1 LGTM, needs rebase.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
39
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

0
mvndep
72
Maven dependency ordering for branch

+1
mvninstall
576
trunk passed

+1
compile
352
trunk passed

+1
checkstyle
63
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
789
branch has no errors when building and testing our client artifacts.

+1
javadoc
143
trunk passed

0
spotbugs
412
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
605
trunk passed

-0
patch
451
Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

0
mvndep
31
Maven dependency ordering for patch

+1
mvninstall
533
the patch passed

+1
compile
367
the patch passed

+1
cc
367
the patch passed

+1
javac
367
the patch passed

-0
checkstyle
32
hadoop-hdds: The patch generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

-0
checkstyle
36
hadoop-ozone: The patch generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
628
patch has no errors when building and testing our client artifacts.

-1
javadoc
63
hadoop-hdds generated 1 new + 15 unchanged - 0 fixed = 16 total (was 15)

+1
findbugs
621
the patch passed

_ Other Tests _

+1
unit
280
hadoop-hdds in the patch passed.

-1
unit
176
hadoop-ozone in the patch failed.

+1
asflicense
35
The patch does not generate ASF License warnings.

5691

Reason
Tests

Failed junit tests
hadoop.ozone.om.ratis.TestOzoneManagerRatisServer

Subsystem
Report/Notes

Docker
Client=19.03.0 Server=19.03.0 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/6/artifact/out/Dockerfile

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

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

uname
Linux f57c9f61d1b8 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / cb69700

Default Java
1.8.0_212

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/6/artifact/out/diff-checkstyle-hadoop-hdds.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/6/artifact/out/diff-checkstyle-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/6/artifact/out/diff-javadoc-javadoc-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/6/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/6/testReport/

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

modules
C: hadoop-hdds/common hadoop-ozone/common hadoop-ozone/integration-test hadoop-ozone/ozone-manager U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/6/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
39
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

0
mvndep
69
Maven dependency ordering for branch

+1
mvninstall
609
trunk passed

+1
compile
359
trunk passed

+1
checkstyle
75
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
861
branch has no errors when building and testing our client artifacts.

+1
javadoc
158
trunk passed

0
spotbugs
427
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
617
trunk passed

-0
patch
460
Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

0
mvndep
30
Maven dependency ordering for patch

+1
mvninstall
566
the patch passed

+1
compile
371
the patch passed

+1
cc
371
the patch passed

+1
javac
371
the patch passed

+1
checkstyle
72
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
654
patch has no errors when building and testing our client artifacts.

-1
javadoc
69
hadoop-hdds generated 1 new + 15 unchanged - 0 fixed = 16 total (was 15)

+1
findbugs
633
the patch passed

_ Other Tests _

+1
unit
277
hadoop-hdds in the patch passed.

-1
unit
2023
hadoop-ozone in the patch failed.

+1
asflicense
44
The patch does not generate ASF License warnings.

7765

Reason
Tests

Failed junit tests
hadoop.ozone.om.TestOzoneManagerHA

hadoop.ozone.client.rpc.TestOzoneRpcClient

hadoop.ozone.client.rpc.Test2WayCommitInRatis

hadoop.ozone.TestStorageContainerManager

hadoop.ozone.client.rpc.TestOzoneRpcClientWithRatis

hadoop.ozone.client.rpc.TestSecureOzoneRpcClient

hadoop.ozone.client.rpc.TestBCSID

hadoop.ozone.om.TestScmSafeMode

hadoop.ozone.client.rpc.TestOzoneAtRestEncryption

hadoop.ozone.client.rpc.TestHybridPipelineOnDatanode

Subsystem
Report/Notes

Docker
Client=19.03.0 Server=19.03.0 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/7/artifact/out/Dockerfile

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

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

uname
Linux f5771a69a0a5 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 9b8b3ac

Default Java
1.8.0_212

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/7/artifact/out/diff-javadoc-javadoc-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/7/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/7/testReport/

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

modules
C: hadoop-hdds/common hadoop-ozone/common hadoop-ozone/integration-test hadoop-ozone/ozone-manager U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/7/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

@arp7 Can you please review/commit this PR?

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
42
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ trunk Compile Tests _

0
mvndep
22
Maven dependency ordering for branch

-1
mvninstall
32
hadoop-ozone in trunk failed.

+1
compile
380
trunk passed

+1
checkstyle
71
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
805
branch has no errors when building and testing our client artifacts.

+1
javadoc
145
trunk passed

0
spotbugs
437
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
626
trunk passed

-0
patch
472
Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

0
mvndep
29
Maven dependency ordering for patch

+1
mvninstall
531
the patch passed

+1
compile
368
the patch passed

+1
cc
368
the patch passed

+1
javac
368
the patch passed

+1
checkstyle
72
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
666
patch has no errors when building and testing our client artifacts.

-1
javadoc
66
hadoop-hdds generated 1 new + 15 unchanged - 0 fixed = 16 total (was 15)

+1
findbugs
636
the patch passed

_ Other Tests _

-1
unit
294
hadoop-hdds in the patch failed.

-1
unit
1555
hadoop-ozone in the patch failed.

+1
asflicense
47
The patch does not generate ASF License warnings.

6721

Reason
Tests

Failed junit tests
hadoop.ozone.om.TestScmSafeMode

hadoop.ozone.client.rpc.TestOzoneRpcClient

hadoop.ozone.client.rpc.TestSecureOzoneRpcClient

hadoop.hdds.scm.pipeline.TestRatisPipelineCreateAndDestory

hadoop.ozone.client.rpc.TestOzoneAtRestEncryption

hadoop.ozone.client.rpc.TestBlockOutputStreamWithFailures

hadoop.ozone.client.rpc.TestOzoneRpcClientWithRatis

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/9/artifact/out/Dockerfile

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

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

uname
Linux 1f78d6aeaca6 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / c0a0c35

Default Java
1.8.0_212

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/9/artifact/out/branch-mvninstall-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/9/artifact/out/diff-javadoc-javadoc-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/9/artifact/out/patch-unit-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/9/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/9/testReport/

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

modules
C: hadoop-hdds/common hadoop-ozone/common hadoop-ozone/integration-test hadoop-ozone/ozone-manager U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1033/9/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

The test failures seem unrelated to the patch.

+1 The failures look unrelated.


Fixes #5930

This requires a few small logic changes to allow single-atom list queries to be written.

@d-b-w : you may also want to look at this


Classes should inherit from Function

I'm trying use code that can be simplified to this:
var foo = Array.apply(null, [1,2]);

// And I'm receiving the following error:
index.js:3
  3: var foo = Array.prototype.apply(null, [1,2]);
                               ^^^^^ property `apply`. Property not found in
144: declare class Array<T> {
     ^ Array. See: /private/tmp/flow/flowlib_62cf125/core.js:144

Summary of the problem: Array is both callable and constructable -- so the static Array global is a function with a proto chain that points to Function.prototype.
To fix this we should make sure that all class objects statically inherit from "Function"

Agreed. I editorialized the title to reflect the actual incompleteness here.

given class Foo { constructor() {} }, Foo() throws a TypeError (per ES6 § <IP_ADDRESS>), so I'm not sure all classes should inherit from Function. Seems like only class-like functions like Array, String, Date, etc. should allow this.

Yeah, Foo isn't callable (callable constructors is a proposal), so Foo.bind, etc., all work but when they are eventually invoked it is a runtime error. Foo instanceof Function is true, however. Whether we want to model that is questionable.

Even in that case, "property apply is not found in ..." is technically incorrect, and may confuse developers.  Technically correct error messages would be "class constructor functions are not callable" and "Flow rejects bind on constructor functions because they aren't callable".

The original example no longer errors, and Function is now an alias of any so the proposal no longer makes sense.


Support deny class

fix #28

Pull Request Test Coverage Report for Build 104

27 of 72 (37.5%) changed or added relevant lines in 7 files are covered.
3 unchanged lines in 3 files lost coverage.
Overall coverage increased (+0.6%) to 30.178%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

sofa-ark-parent/core-impl/container/src/main/java/com/alipay/sofa/ark/container/model/BizModel.java
8
9
88.89%

sofa-ark-parent/support/ark-maven-plugin/src/main/java/com/alipay/sofa/ark/boot/mojo/RepackageMojo.java
0
3
0.0%

sofa-ark-parent/support/ark-support-starter/src/main/java/com/alipay/sofa/ark/support/common/DelegateArkContainer.java
0
8
0.0%

sofa-ark-parent/core-impl/container/src/main/java/com/alipay/sofa/ark/container/service/classloader/BizClassLoader.java
2
10
20.0%

sofa-ark-parent/support/ark-tools/src/main/java/com/alipay/sofa/ark/tools/Repackager.java
0
10
0.0%

sofa-ark-parent/core-impl/container/src/main/java/com/alipay/sofa/ark/container/service/classloader/ClassloaderServiceImpl.java
5
20
25.0%

Files with Coverage Reduction
New Missed Lines
%

sofa-ark-parent/core-impl/container/src/main/java/com/alipay/sofa/ark/container/service/classloader/BizClassLoader.java
1
56.58%

sofa-ark-parent/support/ark-maven-plugin/src/main/java/com/alipay/sofa/ark/boot/mojo/RepackageMojo.java
1
0.0%

sofa-ark-parent/support/ark-support-starter/src/main/java/com/alipay/sofa/ark/support/common/DelegateArkContainer.java
1
0.0%

Totals

Change from base Build 102:
0.6%

Covered Lines:
985

Relevant Lines:
3264

💛  - Coveralls

@QilongZhang You can add on test case in BizClassloaderTest to make sure deny import work

@straybirdzls  fix as your suggestion.


Jobs in career

Aside from the usual money that comes in after a race, In career we will have the option to also complete jobs. These jobs will become gradually more difficult. (E.g. complete a race, be in the top 50%, be in the top 10%, win. Win a team victory, win in points, win a sprint, ...)

Since Career is to be reworked, money might not be relevant anymore. For now, this won't be implemented


Generalize the precompressed content serving from DefaultServlet

Replaces all gzip specific handling with more generic precompressed content handling.
More specifically, if the new precompressed parameter of DefaultServlet is set to true also brotli compressed (.br) files will be served in addition to gzipped files.
The old gzip parameter functionality is preserved for backwards compatibility, but removed from documentation.
The defining of new precompression file formats as parameter to the DefaultServlet can be added at later time.

Generally I like this patch. I do have a couple of comments:

I think it makes sense to make the change to a generic approach immediately. One way of doing this would be for the precompressed init param to take a comma separated list like ".gz,gzip,.br,br". It would need suitable sanity checking.
The preference for different encodings is set by the client, not the server. See RFC7231, section 5.3.4. Look at o.a.catalina.Request.parseLocales() for a way of handling q values.

Thank you for the review comments.
Modified pull request to accept and pare "gzip=.gz,br=.br" syntax in the precompressed init parameter.
Honors the full client preference settings from client as per RFC7231, including * and identity types.


Cannot add IPv6 loopback address as redirect URI due to field validation

Trying to add the IPv6 loopback address 'http://[::1]' (with or without brackets) results in the field validation calling it an invalid URI despite it being valid. The same error occurs with 0:0:0:0:0:0:0:1 in colon-hexadecimal notation.
This results in OAuth2 authorization failing if the user is using IPv6.

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

ID: 006699d8-d208-ec2e-9b14-ec6c5d4bd71f
Version Independent ID: b9ad346f-2140-8d7b-c5aa-b5e4d7bae866
Content: Configure an application to access web APIs - Microsoft identity platform
Content Source: articles/active-directory/develop/quickstart-configure-app-access-web-apis.md
Service: active-directory
Sub-service: develop
GitHub Login: @rwike77
Microsoft Alias: ryanwi

@mol Thanks for your feedback! We will investigate and update as appropriate.

Closing out this issue as this seems to be a duplicate of the SO post here and we've received an answer from our product group :
https://stackoverflow.com/questions/56798300/how-to-add-ipv6-loopback-address-as-redirect-uri-in-azure-for-oauth2/56843915#56843915
Unfortunately as of 7-1, currently Azure Active Directory does not support IPV6 yet.
If you're interested in this feature please post it under the feedback section for Azure here : https://feedback.azure.com/forums/34192--general-feedback
And Microsoft's product group will look into it.


Does the final model needs Normalization?

I read the code and saw that the final embedding did not normalize.
Does it a good idea to normalize the final embedding vector?

Thank you for trying out InternVideo!
We normalize the embedding in the loss when training. Please refer to the demo for use case.


Nominal bit rate overwrites bit rate even with ParseSpeed=1

Big_Buck_Bunny_1080_10s_1MB.zip
Hi all, in the attached video as well as in a lot of similar files, the video bit rate is wrong:
Bit rate                                 : 828 kb/s

This is because BitRate is replaced with BitRate_Nominal: https://github.com/MediaArea/MediaInfoLib/blob/c978f3c601e49b43c68dd3a06d0539fff5ced6ac/Source/MediaInfo/File__Analyze_Streams.cpp#L655-L660
I do not understand why that code is here, why should we ignore the bit rate when it is close to the nominal bit rate? Having both seems very interesting. 5% can also be a big difference.
If I comment that block, I get this correct info:
Bit rate                                 : 812 kb/s
Nominal bit rate                         : 828 kb/s

There are two problems with the current way bit rates are calculated:

with --ParseSpeed=1, I get 828 kbps too. In this case, the nominal bit rate should never overwrite the bit rate. There is no reason for the stream size to be wrong in that case.
when the file is MKV (can be reproduced by remuxing the example file to MKV with mkvtoolnix), the track statistics tag should be used for nominal bit rate instead of the x264 bitrate parameter. Track statics set by mkvtoolnix are always accurate and I think the majority of MKV files are made this way. Maybe in that case the track statistic tag can even be used for bit rate and the x264 bit rate can be left as nominal bit rate.

I do not understand why that code is here, why should we ignore the bit rate when it is close to the nominal bit rate? Having both seems very interesting. 5% can also be a big difference.

different points of view. There was a request years ago for that.
But true that it may be not good for full parsing and/or when the bitrate is precisely calculated (from MP4 or MKV), but the nominal bitrate is better when e.g. the bitrate was estimated.

the track statistics tag should be used for nominal bit rate instead of the x264 bitrate parameter.

The nominal bitrate is the one from the x264 bitrate parameter, the track statistic tag would be for real bitrate.

There is definitely a lot to do here, but it is complex to have more people happy. Here I need to flag when the bitrate is estimated and when it is precise. I try to have a quick and dirty patch for at least flagging MKV with statistical metadata and MP4 as exceptions for this merge.

Thank you, can you also add a quick exception for when ParseSpeed is 1? Or can there be a problem there too?
May I ask why MP4 is an exception? Is it easy to get the real stream size from it?

Thank you, can you also add a quick exception for when ParseSpeed is 1?

Yes.

Or can there be a problem there too?

There is a small risk of showing up a bug somewhere else, I let you test :).

May I ask why MP4 is an exception? Is it easy to get the real stream size from it?

The way MP4 are built mandates to know the real stream size from the header (it has the list of the byte size and location of each frame, used for demuxing)

By the way, if adding exceptions is too complex, I would be happy with an option like --DisableBitrateFromNominal or something that makes it skip the part where the Bitrate is replaced with the Nominal Bit rate.

Here I prefer to handle now the "right" way than adding (yet another) option.
But I am late, I know...


Add "array-like" to _validate_type()

Since we typically require arguments to be "array-like", I think it is convenient to add such a type union to _validate_type(). I've used this new addition to now accept baseline to be array-like (instead of just tuple).
Let me know if this already exists and I just missed it.

If this gets accepted, let me know where it goes in our changelog (Enhancement or API?).

Qt/PyVistaQt-related tests failing left and right, but I think my changes are unrelated.

Re-running failed jobs, maybe they come back green this time. I cannot restart the Cirrus M1 job though.

I believe the errors are unrelated, @agramfort or @larsoner could you merge this PR please? 🙏


Vyper

We can add a repo for Vyper smart contracts and projects using Vyper.

Good idea.
First, we add the definition to the glossary.
Then, we can add a sample lesson in markdown that describes building a basic storage contract similar to:
https://github.com/trufflesuite/webinar-episode-01/blob/master/steps.md
Basically, translate this lesson into Vyper.
This will link to the Vyper section.
Then link that to the repo with the code and the markdown as the README.md.


Using artisan:serve as webserver not multithreaded

Hello everybody,
it would be great if Sail would support another Webserver (NGINX + FPM) as the missing ability to run multi-threaded crashes my application when I try to do something like this:
echo Browsershot::html($body_html)->format('A4')
                ->margins(0, 0, 0, 0)->showBackground()
                ->addChromiumArguments([
                    'font-render-hinting' => 'none',
                ])->waitUntilNetworkIdle()->noSandbox()->pdf();

If $body_html contains assets that are pointing to the very same application like <link href="{{ asset(('/css/app.css')) }}" rel="stylesheet"> those requests run into timeout.

We have no plans for this sorry.

I know this is closed, but I would also like this.

I have to agree with @ahoiroman and @tkoop
Sail is almost useless for big projects. The software I'm currently working with runs 5-8 requests simultaneously. UI waiting for artisan serve to respond makes using Sail a total nightmare as loading one page takes a lot of time.


CI improvement

Could you add functionality from https://github.com/106-inc/sim2022/issues/16 to this patch?

Could you add functionality from https://github.com/106-inc/sim2022/issues/16 to this patch?

Ok

Closes #16

huita

huita

I think it is offensive....


Need guidelines for creating out-of-tree mixer adapters

Describe the feature request
Currently, it's possible to have out-of-process adapters via gRPC. It'd be great to have these adapters out of Istio tree. Good documentation around this would be really helpful.

+1. And I could potentially help around this... once I get mine working.

I've created a Wiki page to address this. You can find it at https://github.com/istio/istio/wiki/[Preliminary]-Mixer-Out-of-Tree-Adapter-Walkthrough.


Configurable Contour and Envoy Network Endpoint Publishing

Please describe the problem you have
Make Contour and Envoy network endpoints configurable. For example, I may not want to use a LB service to expose Envoy (default). I may want to only use a ClusterIP or a range of other possibilities for Contour and Envoy.
/cc @jpeach @Miciah

xref: https://kubernetes.slack.com/archives/C8XRH2R4J/p1603393745340600

Right now, the examples on projectcontour/contour use host ports.  Host ports are not well documented.  Using host networking (which is better documented) solves the same problem for bare metal, and using node ports is preferable on cloud platforms (and on bare metal when an external load-balancer is used).
I believe we should change the projectcontour/contour examples (a) to use host networking instead of host ports to satisfy the bare-metal use-case and (b) define a LoadBalancer-type service (which doesn't necessarily need host ports or host networking, but should be compatible with either) to satisfy the cloud use-case.  We should propose this as a change to the projectcontour/contour examples first, and then update projectcontour/contour-operator once we have made the change in projectcontour/contour.
We'd need to verify that changing host ports to host networking does not break kind.  We'd also need to sort out any implications for SCCs (there may not be an issue for vanilla Kubernetes).
As a follow-up, we can change contour-operator (a) to turn host networking on and omit the LB service on bare-metal platforms and (b) to turn host networking off and create the LB service on cloud platforms.

xref https://github.com/projectcontour/contour-operator/issues/105 to make ports configurable. containerPorts should be configurable. nodePort of the envoy service should be configurable when using a NodePort service.


onMessage not working on Android

When using onMessage to gather events being sent in real time from the WebView the data is received with no issues on iOS but doesn't work on Android, in fact is prevents the webview from progressing (the webview is actually an animation with objects moving at 30FPS, with the data being fed to the view every second).

Android webview is still.

The webview should play the animation and feed the required data to the onMessage function so we can render out that data provided.

IOS: https://d.pr/v/gJLVjV (video)
ANDROID: https://d.pr/i/Jyjjbc (capture)

Environment:

OS: Android
OS version: Pie
react-native version: 0.61.5
react-native-webview version: 8.1.0

I cannot capture the value I sent from the web on android. Ios is working


ci: remove Saxon 9.7

This pull request removes Saxon 9.7 from the CI test matrix and retreats Saxon 9.8 to the lowest priority.
Further work
Update Wiki

Further work
Update Wiki

Done


Fixed: Allow physDesc on Source

Also removed a reference to a 'manifestation' since this module is independent of the FRBR module.
Built locally and looks like it works OK.
Fixes #1078

What I would like to see here, in addition to the change in the specs, is some more documentation, maybe along the lines of https://music-encoding.org/guidelines/dev/content/metadata.html#headerRelatedItemVsFRBR. We should ideally give example(s) on how <source> and <manifestation> / <item> should be combined, and what the purpose of both is. https://music-encoding.org/guidelines/dev/content/metadata.html#msdesc is just a stub, and work on that is underway, but it seems necessary to have that clarification somewhere already if we want to merge this now (which makes perfect sense – it should be possible to give details about a source without having to use full FRBR…)

@kepper In addition to the "Related Item vs FRBR" section, the introduction to the FRBR module contains the following:
"MEI header information may refer to different levels of description of the encoded work: Some information may apply the work in all its various forms and realizations, e.g., the name of its composer. Other information may describe a certain version of the work, or a source such as the printed first edition, or only a single copy of that source. Core MEI limits the header information to two such levels of description: work and source, respectively.
However, when the FRBR module is available more detailed descriptions are possible. ..."
So I didn't add anything more since it seems we already cover this. Personally, I would like to stay away from any prescriptive descriptions of how these things can be combined, since I prefer to see it as an either / or (use FRBR, or don't) rather than trying to mix them in the same encoding. For keeping them separate, sections 3.3 and 3.4 seem to already cover most of the ground (particularly §<IP_ADDRESS>.)

I'm not ok with this change. Not allowing physDesc in source came with a good reason, changing this back causes more confusion. I still don't see why this should be important now.

Not allowing physDesc in source came with a good reason

Do you remember what the reason was? As far as we can tell it was dropped with the addition of the FRBR module, but not sure if that was done intentionally. As a result it means we cannot do non-FRBR source description, which seems like a bug.

It was possible, for example, in MEI 3, but was removed from MEI 4. https://music-encoding.org/guidelines/v3/elements/source.html

Yes, the idea was to have full FRBR support and not to confuse manifestation with source.
I'm a bit confused now that @riedde approved this, because I think we came in the metadata IG to another conclusion before.

There is still full FRBR support. However, there is no longer non-FRBR support. That is the issue. Sometimes we need to do source description without performing a full analysis of whether something is describing it at the manifestation or the item level -- we just want to describe the source that we transcribed it from.
If you want FRBR support, it still exists and this does not change it.

Who is we and why want you do it this way? I still think it's a feature, not a bug. FRBR was implemented this way to not allow non-FRBR.

The issue is described in #1078.
The background is that we wanted to encode incipits in MEI, with some minimal RISM data in the MEI header, so that we could support basic metadata input in Verovio. (https://github.com/rism-digital/verovio/pull/3278)

Perfect reason for a customization. The rest is silence.

Maybe it could help to add some explanations/remarks to source to clarify the intended (non-FRBR) usage and point to manifestation for FRBR usage (and maybe even vice versa)? To make sure "not to confuse manifestation with source" as @rettinghaus pointed out.

Not sure it helps, but here's another personal take on this. From my perspective, FRBR can be very helpful to describe the available sources / dissemination / known situation of a work. However, whenever this concept of a work is challenged for any reason (be it practical cataloguing issues as in Andrew's situation, be it for a very detailed look at small chunks of sketch material as in my case), the strong assumptions that FRBR makes start to stand in the way – they're just not as helpful anymore as they promise to be at first sight. However, this doesn't mean they cannot be used to describe available sources anymore. This requires a level of investigation that may exceed the available resources, though. According to my understanding (which seems to be covered by the docs), <sourceDesc> is meant to capture the material that was considered in the preparation of the encoding at hand. That material may or may not be a manifestation singleton / item encoded elsewhere. In our project, we encode such material in both places, as those seem to be different statements. Obviously, we're not providing two <physDesc>s in that case, but have a very light encoding on one end, which is then linked to the other. I believe it is perfectly sensible to not take away the possibility to specify what your encoding is based on, even when you don't find the time to deal with all the intricacies of FRBR – which can be really painful in some situations. I therefore think this is a really good and necessary improvement, which will lead to better encodings.

@rettinghaus yes, we discussed this in the @music-encoding/ig-metadata meeting and it was a very contrasting discussion. As far as I remember we arrived at a stalemate situation because we didn't find reasons to do that change (from our perspective). For me these reasons are given in the discussion above.
Yes I'm also not absolutely happy with a <physDesc> in <source>, but there is a documentation what <source> and <manifestation> and <item> are for. Further those are different use-cases and the MEI.header is independent from MEI.frbr.
The only thing that is a bit weird to me is that <source> is defined as A bibliographic description of a source used in the creation of the electronic file. And <physDesc> would allow to make a physical description inside of a bibliographic description. Therefore I wouldn't use it this way, but it might be helpful in a customization that does not contain MEI.frbr module.
Conclution: For me, the arguments outweigh the counterarguments

Personally I'm +1 with @rettinghaus here. My biggest concern is that this change leads the way to use source as a direct substitute for manifestation. My understanding of the source element is, however, that it fulfils a different task than the manifestation element. I base this interpretation partially on the element definition of a similar element in EAD. However, my impression is that any counterargument or concern is not perceived as having the same weight as the pro arguments. Hence, the approval on this PR.

And  would allow to make a physical description inside of a bibliographic description

Physical descriptions are part of bibliographic descriptions. Size and extent are very common features of bibliographic description; colour and other features less so, but are certainly not unheard of. A good chunk of the 3XX tag range in MARC21 deals with physical description.

@ahankinson thanks! I didn't know that.

Developer meeting, 25.05.2023: After a fairly extensive conversation, we decided that <source> and <sourceDesc> need a major rework.
The general consensus and motivation is that encoders should be able to describe a source without using FRBR structures (manifestation / item, specifically). However, after doing the example it was discovered that <physLoc> was also not available on <source> anymore.
Looking back through earlier versions of MEI, it seems that most of the source description capabilities were removed in 4.0. The content models for MEI 1.8, MEI 2, and MEI 3 were consulted. In these previous versions it seems that there was confusion with FRBR elements being allowed within <source>, which seems strange.
Further investigations covered an investigation of <bibl> and <biblStruct>, but these have very weird content models as well. (e.g., <pubStmt> and <imprint> being two different ways of expressing a publication.)
It was agreed that a re-work of the <source> and <sourceDesc> elements was needed, and so we should convert this PR to a WIP draft while we consult more broadly with the community, particularly @music-encoding/ig-metadata, about this issue.

Issues andiscussions related to this: #579 and #546

I think it's important to recognize the difference between bibliographic citation and bibliographic description.  The <bibl> and <biblStruct> elements address bibliographic citation; that is, a bibliographic reference.  In-depth description of the thing referred to is not generally accommodated in a reference, e.g., references in a paper don't contain the dimensions of the referenced item.  By allowing <bibl> and <biblStruct>, <source> is permitting citation. On the other hand, the FRBR elements, <work>, <expression>, <manifestation>, and <item>, allow for description.
That being said, the issue suggests a need for description where currently only citation is allowed.  Allowing additional descriptive elements within <bibl> and <biblStruct> would permit <source> to keep its current model, but would create additional problems elsewhere, since it would make it possible to put bibliographic description virtually everywhere.
I think the better path is to insert a variant of the content model of <manifestation> into the current model of <source>:
<content>
  <rng:zeroOrMore>
    <rng:ref name="model.headLike"/>
  </rng:zeroOrMore>
  <rng:zeroOrMore>
    <rng:choice>
      <rng:ref name="locus"/>
      <rng:ref name="locusGrp"/>
    </rng:choice>
  </rng:zeroOrMore>
  <rng:choice>
    <rng:zeroOrMore>
      <rng:choice>
        <rng:ref name="model.biblLike"/>
      </rng:choice>
    </rng:zeroOrMore>
    <rng:group>
      <rng:optional>
        <rng:ref name="model.identifierLike"/>
      </rng:optional>
      <rng:ref name="titleStmt"/>
      <rng:optional>
        <rng:ref name="model.workIdent"/>
      </rng:optional>
      <rng:ref name="macro.bibldescPart"/>
      <rng:optional>
        <rng:ref name="creation"/>
      </rng:optional>
      <rng:optional>
        <rng:ref name="history"/>
      </rng:optional>
      <rng:optional>
        <rng:ref name="langUsage"/>
      </rng:optional>
      <rng:optional>
        <rng:ref name="contents"/>
      </rng:optional>
      <rng:optional>
        <rng:ref name="notesStmt"/>
      </rng:optional>
      <rng:optional>
        <rng:ref name="classification"/>
      </rng:optional>
      <rng:zeroOrMore>
        <rng:ref name="relatedItem"/>
      </rng:zeroOrMore>
      <rng:zeroOrMore>
        <rng:ref name="extMeta"/>
      </rng:zeroOrMore>
    </rng:group>
  </rng:choice>
</content>

Then the encoder has a choice of using a bibliographic citation (i.e., <bibl> or <biblStruct>), or a more extensive bibliographic description.

@ahankinson & @lpugin is could you provide some samples of the

incipits in MEI, with some minimal RISM data in the MEI header

for clarification. Thanks

just a link or a plaintext with the metadata that should go into the MEI would be sufficient ;-)


(feature) Being able to configure a different port for Metrics / Health Check

Requirements
We must be able to configure a different port for Metrics and Health Check
The new port can be configurable and in the case when the configuration is absent, we should fall back to the current configuration.
In a nutshell:

Business endpoint + metrics on the same port (should be the default)
Business on 1 port + metrics on another one via configuration.

That configuration is usually the standard used by many companies.

/assign me

/assign-me


Difference between Model and Server Configs?

Thanks for a great project!
I might be misunderstanding or missing some limitation that doesn't allow for certain fields to be specified in a standalone config file, but there seem to be many server params which aren't supported on a per model basis?
Prerequisites
Please answer the following questions for yourself before submitting an issue.

[X] I am running the latest code. Development is very rapid so there are no tagged versions as of now.
[X] I carefully followed the README.md.
[X] I searched using keywords relevant to my issue to make sure that I am creating a new issue that is not already open (or closed).
[X] I reviewed the Discussions, and have a new bug or useful enhancement to share.

Expected Behavior
To be able to set all of the constants found in the Server Types in ConfigFileSettings
Current Behavior
Only a subset of config params are available in the Model Configuration
Environment and Context
Running in Docker with CONFIG_FILE=/config/config.json python3 -m llama_cpp.server , with config file mounted to /config/config.json
Failure Information (for bugs)
This is an explicit type error
Steps to Reproduce
Create model config JSON, and attempt to set any of the unsupported parameters:
{
  "models": [{
       "model": "/models/gemma-1.1-2b-it-Q5_K_M.gguf",
        "model_alias": "gemma-2b-it-q5",
        "chat_format": "gemma",
        "penalize_newline": false,
       "repeat_penalty": 1
  }]
}

Failure Logs
As expected, the config file validation fails on startup:
models.2.penalize_newline
  Extra inputs are not permitted [type=extra_forbidden, input_value=False, input_type=bool]
    For further information visit https://errors.pydantic.dev/2.6/v/extra_forbidden
models.2.repeat_penalty
  Extra inputs are not permitted [type=extra_forbidden, input_value=1, input_type=int]
    For further information visit https://errors.pydantic.dev/2.6/v/extra_forbidden

@Gordonei that's not a difference between the server and model configs, repeat_penalty is specified on a per request basis and penalize_newline is not a supported option. That being said I do see the value of being able to override default parameters in cases where you don't have control of the client.

Probably the most relevant case I can think of is the stop parameters, which are different on a per model basis. It's nice to be able to hide those sorts of implementation details from clients of the API.
Would it just be a matter of adding the relevant fields to the ConfigFileSettings, or would there need to be additional plumbing needed? The reason I ask is that would point me in the right direction for putting together a PR.


Fix early stopping on_training_epoch end with structured results

What does this PR do?
First, adds a test which tries to set early_stop_on in a TrainResult in training_epoch_end and tests if early stopping is triggered.
The test fails.
Second, fixes the issue by storing the callback_metrics for structured results in logger_connecter.py.
Third, fixes a bug in a test model, which returns a tensor with more than one element for checkpoint_on.
This bug was hidden before, since checkpoint_on was also discarded alongside early_stop_on.
Fixes  #3413
Before submitting

[ ] Was this discussed/approved via a Github issue? (no need for typos and docs improvements)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure your PR does only one thing, instead of bundling different changes together? Otherwise, we ask you to create a separate PR for every change.
[x] Did you make sure to update the documentation with your changes? --> Will be done in #3193
[x] Did you write any new necessary tests?
[x] Did you verify new and existing tests pass locally with your changes?
[x] If you made a notable change (that affects users), did you update the CHANGELOG?

PR review
Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.
Did you have fun?
Make sure you had fun coding 🙃

mind waiting till next week until we are done with refactors?
anything results related is likely to change by then, so i don't want you to waste time if we overwrite these changes

mind waiting till next week until we are done with refactors?

no problem. I'm not really depending on the feature anyway.

@williamFalcon i think most refactors are done and this can be synced, right?

We changed our API from structured results to a simpler API, please look at the latest docs. We now pass early stoping as a callback. please try to update to master, see if issue remains!

I'm closing this PR since this should no longer supported, please reopen if needed!