Complete rebuild. Version... 4?

The code for this project is a mess, violates just about every principle possible and does so in such a way that any sort of debugging is nigh on impossible. At its core the project should have clear separation between fetching data (request from curse.com, parse) and displaying data. Data that is out of date is better than no data. This project is blindingly simple, it should not be so unreliable.
The project should be rebuilt with reliability at the core, and a full error management layer. The API should be monitored using Runscope.

https://github.com/thephpleague/fractal

API goals:

Run an API with 100% availability
Provide an easy to use system so that anyone can run their own API server
Every request should receive a response, fresh data (<1 hour old) is ideal, stale data (>1 hour old) is okay, "Sorry we don't have data" is bad, no response is terrible end of the world no thank you

A complex high availability system using a data store, load balancer(s) and multiple web servers split across multiple zones with AWS/GCP would be a good option for high availability with a traditional API, but I don't know if it's the right choice for this API. This system does not have any responsibility for any data, it is only responsible for fetching data from a third party and then serving data to consumers, meaning the worst case scenario is... we can't respond to requests: data can't be lost by this system. For high availability it can be as easy as running the self contained system in 2 separate places (eg: 1 in AWS, 1 in GCP) and failing over to the second if the first fails, maybe using Route 53 health checks? Absolute worst case scenario is if both servers disappear from the internet, in which case another can be spun up in a separate data centre in minutes. A system designed like this would meet availability needs and the simple to run goal for third parties.
How the API might work:

A request is made to the API for $project
The system checks if it has any data for $project
If yes the data is served
If $project data is not available then $project is added to a queue to be fetched and a response is given, like "Project data not yet available, try again in 60 seconds".

The queue would work by going through each project in order, fetch the project page from curse.com,
parse the HTML to retrieve the properties, add them to the cache with a "last retrieved at" time. A job would run every 60 seconds that checked the cache for projects that were considered stale (based on "last retrieved time" being greater than a configurable amount (probably 60 minutes)) and add the project back to the queue.
This system is flawed in that when it is first brought online there will be requests to every project seeing responses telling them that data is not available until it is fetched, however because there are a finite number of curse.com hosted projects used by people making requests to the API we could potentially store a list of projects for the app to fetch by default when it starts up. This list could be gathered based on requests already being made to the API, or even by grabbing the popular projects from curse.com.

The remainder of the project would be pretty straight forward. The widget would be a consumer of the API that renders the data in a pretty way, so that too could be a self contained service that anyone could run if they wanted to, built using go. The project homepage could just be a static HTML job, using Javascript for the "create a widget" wizard, which also consumes the API. Simple!
Homepage: curse.mcf.li
Widget: widget.curse.mcf.li
API: api.curse.mcf.li
I'd like to abandon the mcf.li domain, especially given this project is usable for all curse hosted projects (world of warcraft, terraria, I recently discovered that a popular Kerbal Space Program addon manager is planning to use the API...) so a more generic name would be ideal, but I don't want to run into issues with trademarks and whatever, so maybe something like "addon.ninja" or something dumb like that. I don't know. I don't hate mcf.li so we can keep it for now but if a better idea comes up, migrate! hurray!

Something that is worth revisiting is what the current API does. At the moment it just pulls from curse.com, and doesn't include some things, which is suboptimal. mods.curse.com is essentially a consumer frontend to curseforge, which contains more/different information. For example: http://mods.curse.com/customization/minecraft/229041-lucky-block-spiral-1-8-lucky-block-addon and http://minecraft.curseforge.com/projects/lucky-block-spiral-1-8-lucky-block-addon, same project, different information.
The differences between mods.curse.com and curseforge.com:

mods.curse.com only displays "beta" and "release" files, it does not display "alpha" files
both sites have their own separate comments
the changelog listed on curse.com is only for the latest file
each file listed on curseforge has its own changelog
curseforge info is split across multiple pages, curse.com is all on one page

A job would run every 60 seconds that checked the cache for projects that were considered stale (based on "last retrieved time" [...]
The issue I can forsee is it being costly to list out all (internally) registered projects before calculating whether they are stale. The other idea I had was after each project is requested, you create a go routine for that request. This routine then sleeps until it needs to re-queue the project (say, a 60 minute sleep) before exiting.

I'm not sure how many unique projects you would be tracking and if that many go routines would be inefficient. The same considerations would have to be given to iterating though that much data every minute ;)
There is an example in the imgd project. We don't use that in production though as we share a Redis backend between the nodes (I did used to run it without issue though).
https://github.com/minotar/imgd/blob/master/cache_memory.go#L95-97

AfterFunc waits for the duration to elapse and then calls f in its own goroutine. It returns a Timer that can be used to cancel the call using its Stop method.

The complication would then be rescheduling the re-requests at server start. It would likely need a one time (costly) run through of all projects to initialize the sleep processes. It would know how long it needed to set each to sleep for so there shouldn't be a bust I'm queued requests.
Thoughts?


Create_CustomSentinel2Tiler.ipynb notebook is broken

in the first section "Create the CustomTiler" instead of from titiler.models.dataset import Info, Metadata should be from rio_tiler.models import Info, Metadata
optquery variable is not defined

Thanks @vincentsarago, great job! We are planing to start using Titiler here so in order to be more familiar with code I'm going to pick something else to fix from the backlog.

thanks @drnextgis

so in order to be more familiar with code I'm going to pick something else to fix from the backlog.

Right now the highest priority is to find a solution for https://github.com/developmentseed/titiler/issues/186 but I think the fix is on rasterio side.

https://github.com/developmentseed/titiler/issues/153 also needs more discussion.

https://github.com/developmentseed/titiler/issues/193 I've started something on my side, but I'm not 💯 sure we have to do this

We are always looking for contribution on the DOC side. Like I really want to add docstring (google style) to all the methods/function so we can add API documentation in the online doc. Other documentation update would be really appreciated.


Update README.md

Just a few corrections.

Thanks for your comment. I replaced the markdown with html in the easing heading. I also replaced the markdown for the options link with html, which for some reason did not convert to a link when parsed.

Thanks!


Support for HarmonyOS 2.0

Description
Huawei lauched its HarmonyOS 2.0 on 10 Sep. Please add support for it. Thanks!

Do the coreutils even work on harmony v2?

You are right. Actually it is probably too early to ask for this.
Right now, Android apps cannot be run on HarmonyOS 2.0. Huawei says that they will release a tool that helps developers to convert Android apps to HarmonyOS apps. Maybe I shall come back when they release this tool.


Add examples (the example notebooks for instance) to the documentation

Obviously I need people to know how to use this module, just telling them about all the functions with autodoc isn't enough.
I should start with the existing example(s?), then start planning and writing more to show off what this module can do, and how easy it is.

Included in this is the task of making sure the current existing example is correct and well formatted, including finally completing issue #56.

Included in this is the task of making sure the current existing example is correct and well formatted, including finally completing issue #56.

I will also need to write more 'under the hood' notebooks explaining in detail how specific techniques work

I will also need to write more 'under the hood' notebooks explaining in detail how specific techniques work


Feature request: basic input test

I have an RG353V whose joysticks might be getting worn out, or there might be some weirdness going on in software.  It'd be very nice if there were a very basic low-level input test screen that could tell me numeric X/Y values for the joysticks, so I could find dead spots in the pots and eliminate layers of software from my list of things to check.
I'm thinking something like you'd see on the switch test features of arcade and pinball games.  Could be useful to anyone trying to fix a partially-working handheld.

Would something like this work for your use case? https://www.youtube.com/watch?v=phKoKU2lYFs
If looking for a graphical solution, not sure one is available for this platform on linux just yet.

Aye that'd do the job just fine.  Long term it'd be nice to have a graph of the joystick x/y so you could slowly move it and watch for dead spots, but this'd do for now no problem.

I've put together a solution for this.  If you could help me test this and provide feedback, it would be helpful.

Take the attached compressed file (arkosbackup.tar.gz) and put it in your roms/backup folder. Do not uncompress the contents! Just place the file as is in your roms/backup folder. If you don't have a backup folder in the roms folder, just create it.

Then go into the Emulationstation Menu, scroll to Options, hit A, then go to Advanced, hit A, then scroll all the way down to Restore Settings, hit A.

Once completed, reboot the device.

Then go into the Emulationstation Menu, scroll to Options, hit A, then go to Advanced, hit A, then select Controller Tester., hit A.

You can then test your inputs.  You can test the rumble motor by pressing L3+R3 together.  Select+Start to exit the tool.
Let me know your results.
Thank you,
arkosbackup.tar.gz


Add Support for Twilio Copilot

Per Twilio Docs add support for alerts using Copilot. Compability with the existing Twilio SMS alerting method is maintained.

Make 'twilio_from_number' optional
Add setting 'twilio_message_service_sid'
Add setting 'twilio_use_copilot', defaults to False

In case 'twilio_use_copilot' is False, 'twilio_from_number' is required. Otherwise, 'twilio_message_service_sid' is required.
I've tested this using an Elasticsearch 7.1.1 cluster, both SMS and Copilot alerting work.

@cdmastercom
Any way you could push this PR to https://github.com/jertel/elastalert ?


⚠ Mobitopup has degraded performance

In 2278caf, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 3062 ms

Resolved: Mobitopup performance has improved in 016e1d1.


No dnd off if manually activated

If a user already has DND activated before a screen share or recording starts, do not turn it off when the session ends.
Note that this trivially conflicts with PR #3.

Hmm, interesting, I actually thought about adding that behavior originally, but I must have forgotten :slightly_smiling_face:


Active account name is missing on the top toolbar of the market page

[Chrome/Win7]
[release 151125]
When you access a market from explorer/markets, the market page is not displaying the active account name.

It's an account selector so it only appears if you have more than one account.

That being said we should rethink the relationship between followed accounts and linked accounts, currently any account you browse to becomes your current account, which shouldn't be the case. Imo current accounts should only be chosen from accounts you control.

Nope, the behavior I described is clearly a bug. When you reload the page the active account name shows up on the top toolbar as it should. It just fails to show up when you access the page from explorer/markets.

So, let's work this one as a bug, but I still kind of like the idea of allowing a user to star accounts and have only the starred accounts show up in the dropdown. It puts the power in the hands of the user.

Ah yea I think I see why this is happening, the current "active route" implementation is a bit hacky. Ideally we'd upgrade to react-router v1 which would simplify things but it breaks a lot of things unfortunately.


Repository description still links to old image

According to the warning

❗  Warning! This image used to be published as jenkinsci/jnlp-slave. That image name is deprecated, use jenkins/jnlp-slave.

jenkinsci/jnlp-slave is deprecated. However, the description of this repository still links to jenkinsci instead of jenkins.

Sorry for missing this issue. It is fixed now, thanks!


Fix name not being updated in cluster servlet and breaking on_this_cluster.

Current dependencies on/for this PR:

main

PR #451   👈

This stack of pull requests is managed by Graphite.


nfc.transceive(data) - NFC Tag write failed. Unexpected flag: 1

I cant transceive some data to a NFC Device.
I can connect with nfc.connect('android.nfc.tech.NfcV')
But after that i try to send a custom Command - nfc.transceive('22 23 B6 33 3B A7 00 26 02 E0 A5 04')
I always get the Error: NFC Tag write failed. Unexpected flag: 1
With other NFC Tools from the Play Store I can send this custom command and get a Result.
What's the meaning of this error?

I have no idea what this means. I'd recommend setting a breakpoint in the Android code and looking up details based on the error.


Students Alcohol Consumption

Pull Request for ML-Crate 💡
Issue Title: Student Alcohol Consumptions

Info about the related issue (Aim of the project): Perform Proprieatory Data Analysis and Predictive analysis on student alcohol consumption dataset and predict the effect on math grades
Name: Piyush Bhujbal
GitHub ID: https://www.github.com/PiyushBL45t
Idenitfy yourself: HSoC Participant

Closes: #145
Describe the add-ons or changes you've made 📃
Give a clear description of what have you added or modifications made
Type of change ☑
What sort of change have you made:

[X] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[X] Code style update (formatting, local variables)
[X] Breaking change (fix or feature that would cause existing functionality not to work as expected)
[X] This change requires a documentation update

How Has This Been Tested? ⚙

I first checked and wrote the general information about the dataset in the Jupyter Notebook.
Then cleaned the dataset and then implemented the necessary data preprocessing techniques.
Grouped the columns and checked the necessary average results.
Separated the training and testing arrays.
Implemented three ML models:
* Linear Regression
* K Nearest Neighbors Regressor
* Decision Tree Regressor
Trained the model with final period grade as a parameter.
Then checked for the training scores of each dataset.
The best results were from Decision Tree Regressor where the Grade G3.
Visualized the results. The results state that G3 shows a uniform distribution when Decision Tree Regressor model is implemented on it.

Checklist: ☑

[x] My code follows the guidelines of this project.
[x] I have performed a self-review of my code.
[x] I have commented on my code, particularly wherever it was hard to understand.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have added things that prove my fix is effective or that my feature works.
[x] Any dependent changes have been merged and published in downstream modules.

Done 👍
On Thu, Jul 21, 2022, 5:44 PM Abhishek Sharma @.***>
wrote:

@.**** requested changes on this pull request.
remove Power Consumption in India/Readme.md file
—
Reply to this email directly, view it on GitHub
https://github.com/abhisheks008/ML-Crate/pull/291#pullrequestreview-1046424692,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASB2BKM4V5D3SQVNS3ZJA23VVE5KTANCNFSM54HIVB2Q
.
You are receiving this because you were mentioned.Message ID:
@.***>


always ask switch network to mainnet

Discussed in https://github.com/family/connectkit/discussions/10

Originally posted by shixin-guo September 29, 2022

When I connect with MetaMask after upgrading to 0.0.2, connectKit asks me to switch to Mainnet, but I want to use Rinkeby TestNet. Do you know what's causing this?
Because 0.0.1 is working properly, I am perplexed.😢
this is my test code
import { ConnectKitProvider } from 'connectkit'
import {
  WagmiConfig,
  createClient,
  allChains,
  configureChains,
  chain,
} from 'wagmi'

import { publicProvider } from 'wagmi/providers/public'

import { CoinbaseWalletConnector } from 'wagmi/connectors/coinbaseWallet'
import { MetaMaskConnector } from 'wagmi/connectors/metaMask'
import { InjectedConnector } from 'wagmi/connectors/injected'
import { WalletConnectConnector } from 'wagmi/connectors/walletConnect'

import { firebaseApp } from '@framework/provider'

const { chains, provider, webSocketProvider } = configureChains(allChains, [
  publicProvider(),
])
const client = createClient({
  autoConnect: true,
  connectors: [
    new MetaMaskConnector(),
    new InjectedConnector({ chains: [chain.hardhat] }),
    new CoinbaseWalletConnector({
      chains,
      options: {
        appName: 'wagmi',
      },
    }),
    new WalletConnectConnector({
      chains,
      options: {
        qrcode: true,
      },
    }),
  ],
  provider,
  webSocketProvider,
})
```</div>

same issue https://github.com/family/connectkit/issues/16

Just to answer the secondary question in this issue, in 0.0.2 we introduced the change that causes this automatic targeting.

The requested chain during connection now automatically targets the first chain in the developer’s client configuration.

An update is available in version 1.0.0 that allows some customisation for the above @shixin-guo

what if I want to have default chain that is currently selected in metamask (or other wallet) in case it is in the list of supported chains?


REL-880

@pvinh-spike
Upon Deeper examination we may have done the previous build(s) incorrect...
I suspect we need to update respective to the Spark version, in this case lines 26 & 27:
  && wget -qO- "https://archive.apache.org/dist/spark/spark-3.4.0/spark-3.4.0-bin-hadoop3-scala2.13.tgz" | tar -xvz \
  && ln -s spark-3.1.2-bin-hadoop3.2 spark-dir-link \

My best guess is the values should probably be:
  && wget -qO- "https://archive.apache.org/dist/spark/spark-3.1.2/spark-3.1.2-bin-hadoop3.2.tgz" | tar -xvz \
  && ln -s spark-3.4.0-bin-hadoop3-scala2.13 spark-dir-link \

@rahul-aerospike thoughts?

wget -qO- "https://archive.apache.org/dist/spark/spark-3.4.0/spark-3.4.0-bin-hadoop3-scala2.13.tgz" | tar -xvz \
  && ln -s spark-3.4.0-bin-hadoop3-scala2.13 spark-dir-link \

right. i.e download 3.40 spark and link corresponding tared directory as "spark-dir-link".


visionOS should not show compatibility with the plugin

We only support macOS and Linux for running the build plugin, but SPI is also now showing visionOS. We should expand our #if guards.

We should double check when the visionOS platform name was added to SwiftPM, as this might require the 5.9 tools version - possibly blocked.

I think we're fine.
We make the following check^1, which should definitely fail on visionOS.
#if !(os(macOS) || os(Linux))
#error(
    "_OpenAPIGeneratorCore is only to be used by swift-openapi-generator itself—your target should not link this library or the command line tool directly."
)
#endif


10 final igor0806

https://igor0806.github.io/fe-course-basic-2023/

Hey @igor0806 thank you for the good project! I have a couple improvements for you


Question on visualizing the data

Hello and thanks for your work. I was wondering if you could tell me how you were able to animate the joint values from the XML-files, although some coordinates are sometimes missing? Take for example the joint LKx_joint, which only has the x-coordinate. How would you use a 3d matplotlib plot to visualize these joints? I tried examing your code, but I can't find the place where you simply read the XML-file, parse the joint values, and visualize them.
I would be grateful for any tips.

Hi,
The XML files contain joint angles for each joint, but some of these joints only have 2 or 1 degree of motion such as LK (or Left Knee I think). So, here the assumption is that the other joint angles do not change. You can find the skeleton structure here.
The preprocessing class which converts these joint angles to quaternions and then to joint positions (in Euler space) is available here
The script to preprocess is available in the Readme here
Once the joint positions are extracted it is straightforward to render these animations in matplotlib. The render function is available here
Hope you find these useful!

Thank you :)

Another question though...why are the arms of the skeleton hanging behind the its back in most of your animations? Is it the dataset or how it was preprocessed? Thanks again for your time

For some reason, there was a constant bias in the shoulder joints of the skeleton provided in the dataset.  I was not able to rectify it completely, hence the artefacts.


feature: add the possibility to set a Security annotation over a whole class

In order to secure a whole controller, to be able to add a     @Security("user.hasRight('MY_SUPER_RIGHT')") above a Controller class could be a game changer ;-)

Related to #196.  We should look into expanding the auth and authz service interfaces to add global support.  While requiring this annotation at the class level would be a step in the right direction, I'd argue that it still opens up the option for mistakes/forgetting to add it properly, etc.  Therefore, a globally registered service would be ideal.  How this is implemented will need to be looked into and possibly discussed.


;) I’ll have to pass on the patch though; adding braces to single expressions doesn’t seem helpful to me.


using spaudiopy to generate spherical harmonics for resonanceaudio for another hrtf dataset

hello,
I would like to use another hrtf dataset in resonanceaudio other than its default one.
can you guide me on how would I use spaudiopy to read and create spherical harmonics for resonanceaudio?
it has some matlab scripts, but its just for its default dataset.
for example for mit kemar, data, how can I process it into spherical harmonic wavs?
thanks.

Hey, this sounds like something I'm familiar with.
Resonance Audio HRIRs are embedded into the source code (see hrtf_assets.h).
The source code can be generated using generate_hrtf_assets.py. It takes SH-decomposed HRIRs saved as multichannel .wav files. The filters need to be ACN/SN3D compliant. Only 1st, 2nd and 3rd order filters are supported. Resonance Audio assumes head symmetry, therefore only left ear data should be provided.
So to replace the original filters.... load a .sofa file, calculate MagLS filters (probably the most reasonable choice), sort out normalisation, save left ear data into a multichannel .wav file. Proceed with the Python workflow, replace the source files and recompile the project.


fnm: 1.26.0 -> 1.27.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/Schniz/fnm/releases.
meta.description for fnm is: "Fast and simple Node.js version manager"
meta.homepage for fnm is: "https://github.com/Schniz/fnm"
meta.changelog for fnm is: ""
Updates performed

Rust version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

/nix/store/zzcz3j22biq520ahdwwpmi5p8xpz42xn-fnm-1.27.0/bin/fnm passed the binary check.

1 of 1 passed binary check by having a zero exit code.

1 of 1 passed binary check by having the new version present in output.

found 1.27.0 with grep in /nix/store/zzcz3j22biq520ahdwwpmi5p8xpz42xn-fnm-1.27.0

found 1.27.0 in filename of file in /nix/store/zzcz3j22biq520ahdwwpmi5p8xpz42xn-fnm-1.27.0

directory tree listing: https://gist.github.com/515a905d1c5c59af8bd352b74e832dc7

du listing: https://gist.github.com/1268663b66b8e74b71909942adacc2a1

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
fnm

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/zzcz3j22biq520ahdwwpmi5p8xpz42xn-fnm-1.27.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A fnm https://github.com/r-ryantm/nixpkgs/archive/c474fb2ba311a3042224637c0271183b4f761114.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/zzcz3j22biq520ahdwwpmi5p8xpz42xn-fnm-1.27.0
ls -la /nix/store/zzcz3j22biq520ahdwwpmi5p8xpz42xn-fnm-1.27.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

fnm

Maintainer pings
cc @kidonng for testing.

Result of nixpkgs-review pr 138229 run on x86_64-linux 1

1 package built:

fnm


Restore method for CodeIgniter Model.

I think the CodeIgniter\Model needs restore method to restore the trashed item.
$user = new UserModel;

$user
	->where('id', $id)
	->set([
		'deleted_at' => null,
	])
	->update()
;

Because there are withDeleted(), OnlyDeleted(), purgeDeleted() methods.
I want to create my custom CRUDR library, but I'm lazy to extends CodeIgniter\Model to add restore() and restoreAll().
Just an idea. Thanks!

Please feel free to open a PR.

Nice idea


Removed JQuery dependency

I wanted to use this on a website I'm building that doesn't have JQuery, so I rewrote the plugin to use vanilla JS.
It's seems to be working fine, and I'm implementing it into my own project right now, however I wondered if you'd like to include my changes in the base repo? There's practically no reason to use JQuery as it takes 100ms to load (on my computer) and nearly everything is achievable without it.
If you do want to use my code, please tell me as I will have to make some changes.

First off, I use tabs instead of spaces, but I can revert that.
Secondly, I put my { on a new line, however I can revert that too.
Thirdly, I couldn't get the animations to be the same when animating it with vanilla JS. I'm not too sure why this is, however there will be a difference both in speed and interpolation when using the new code (however I've gotta say I prefer this version's).
Fourth, I'm not using NodeJS so I haven't debugged it for that, however I suspect it won't be working for that.

This is an amazing contribution, thank you.
I will review your PR and try it out on the example pages. If it's all good, I'll certainly want to merge this in.

One thing to note, as you're using modern JavaScript, we'll need to introduce Babel to transpile this for older browser support.

to

Ah, ok, hadn't been thinking about that. Would that involve a development file and a production file? I guess that would also mean that we could compress the production file which would be beneficial.

I believe line 917 (if(panel.originalEvent)) is checking if panel is an event? I'm not too sure why that is however, as if I'm not mistaken panel is meant to be either the index or name of a panel. Do you know what that's meant to be for?

Regarding  (if(panel.originalEvent)) I think the intention here was to enable something like this:
$('a').click($.scrollify.move)
But I don' think I ever documented this so it's probably not used like that by anyone.
Happy for you to remove this.

Wow. Incredible to see something so small from something so big.

I've compressed the file and run it through babel. I've fixed a lot of things, but I've added a Known Issues section to the readme. I'm currently in the process of debugging them.

I'm having some trouble currently, could you help me?
When offset is called on page load, it returns incorrect values, which is why the page snaps. If you check the array heights, its been populated with these incorrect heights. For some reason though, it seems that running the function again makes it work - I'm guessing if this is a problem with the page not fully loading yet?

@cyruscook I'll take a look into that


Retrieve the total number of filtered instances by SqlOrchestrationQuery

Hello,
The GetManyOrchestrationsAsync returns a list of orchestration states. We can set the paging parameters (pageNumber and pageSize) with the SqlOrchestrationQuery object.
My problem is that this method cannot tell us how many instances match the defined query filter.
Can we add a GetOrchestrationsCountAsync method that accepts the same SqlOrchestrationQuery object as input (without paging information) and returns that total number of matching instances.
Thank you

@hsnsalhi
As I understand it, GetManyOrchestrationsAsync is not a part of a contract for implementing a persistence provider for DurableTask - it's more like a backdoor for DurableTask.SqlServer.AzureFunctions.SqlDurabilityProvider.
Could you please explain in more details why would you need such a change, so we can better understand a use case here?
Thank you.

Hello and thank you for answering my question,
In relation to this issue in durabletask, the filtering feature using related interfaces was not yet available for mssql provider (now it is implemented, but the nuget package is not yet released).
Now that it's implemented, I still don't know how to get the total number of instances that match my filter.
In Azure Durable Functions, I see that we use infinite scroll to get more results (using continuation-token), so the full count is not needed in this case. Is this the end goal even for DTF ?


Remove property from assert message

Assert macros in prim_assert.sv report the asserted property as part of
the error message if the assertion fails. Doing that requires us to
stringify the property. If the property is multi-line in the source
code, this produces a multi-line string. According to the
SystemVerilog standard, a multi-line string requires a backslash (\)
at the end of a line. Adding this backslash through a macro is not
possible (at least to my knowledge), giving us no way to produce a
standards-compliant implementation of the ASSERT macros that report
the property as string.
This commit therefore removes the property from the error message if an
assertion fails. It makes these messages less useful, but the
information can still be recovered in a less convenient way through the
name of the assertion, and the file and line numbers. File and line
number were missing from the non-UVM code path before, this commit adds
them there as well.
This aligns the prim_assert.sv macro with what has been done in Ibex,
where all the discussion around this change happened as well. Please
have a look at https://github.com/lowRISC/ibex/issues/669 and
https://github.com/lowRISC/ibex/pull/699 for the bigger picture.

LGTM. OK with this solution.


Implement relative and absolute methods for Lighten/Darken, Saturate

Add lighten_fixed and darken_fixed methods to the Shade trait. The
_fixed functions inherit the old behavior. lighten/darken are
implemented in terms of the corresponding _fixed versions when
possible. The new implementation uses an amount relative to the color's
current lightness and the scale of possible lightnesses for the color
space. This should be more intuitive to adjust as a small amount can
have drastically different results based on the color space. The same
change is made for saturate/desaturate with corresponding _fixed
methods.
closes #215

Yes, my thoughts were that this seemed like a nice addition to try getting in for the new release.
Good catch on the Saturate impls. I saw the T::one nearby in the saturate_fixed methods so I think my mind stuck on using that instead of using T::max_intensity.
There's some shuffling in the Saturate docs because I had a formatting error due to duplicating the code originally. I removed "fraction" from the Saturate and Shade docs because it doesn't seem necessary to include and I felt it made the description a bit harder to read. I can re-add it if you think that or "fractional" if you think it should be there to describe the amount. I think amount makes more sense to normalize toward. Mix still uses factor but I think that is the correct use of factor because it's a mixing factor between 0.0 and 1.0.
Luma already had the max(T::zero()) on the original implementation. I added it to the others, that seems like the best thing to do for now.

This seems like the least weird option for handling "out-of-bounds" values without complicating it. Let's go with it for now.
I just know I/we have been using different terminology (sometimes interchangeably) for factors and amounts, so it would be nice to set a proper standard or pattern that makes sense for what they are. I don't have anything against using different names if they match the different semantics, so if "factor" is correct for relative changes, we could use it for the relative methods and use "amount" for the fixed/absolute methods. I mean since they are also part of the documentation. Does that sound good?
And I would also like to encourage having a couple of small examples in the documentation to really show how things are intended to work. Something simple like showing that Hsl::new(0.0, 1.0, 0.5).lighten(0.5).lightness == 0.75 (with nice formatting), while Hsl::new(0.0, 1.0, 0.5).lighten_fixed(0.5).lightness == 1.0 could help with demonstrating the difference.
Aside from those details, there seem to be a test that need to be changed. It's probably based on an incorrect assumption, so it can either be changed tor removed and replaced with the above mentioned examples.

I just know I/we have been using different terminology (sometimes interchangeably) for factors and amounts, so it would be nice to set a proper standard or pattern that makes sense for what they are. I don't have anything against using different names if they match the different semantics, so if "factor" is correct for relative changes, we could use it for the relative methods and use "amount" for the fixed/absolute methods. I mean since they are also part of the documentation. Does that sound good?

That makes the most sense and clarifies a lot semantically. I've made it so the _fixed versions use amount and the relative versions use factor.
I've modified the doc tests for Shade and Saturate to show the fixed and relative differences. I removed the old examples but can add them back in. I'm not sure if you want more text in the description for the trait description to detail the relative/fixed types or if the examples are good enough.
The tests for Saturate threw me off because the implementation is actually relative for both and might be surprising. I'm not sure what's more expected.
// Shade
(self.value + amount).max(T::zero())
// Saturate
self.saturation * (T::one() + amount).max(T::zero())

let a = Hsv::new(0.0, 0.5, 1.0);
assert_relative_eq!(a.saturate(0.5).saturation, 0.625);
assert_relative_eq!(a.desaturate_fixed(0.5).saturation, 0.25);

Ohhh, wait, no, that's not what I had in mind. I must have blinked while reading that earlier, sorry. 😬 Or I may need to sleep. An example of what I'm going for is the color module for the SASS CSS pre-processor: https://sass-lang.com/documentation/modules/color. I don't know how familiar you are with it, but it has some functions for manipulating colors, including the ones from these traits. The darken/lighten/saturate/desaturate (ex. https://sass-lang.com/documentation/modules/color#darken) functions are basically legacy and are using fixed amounts. The scale function is what I had in mind for the new defaults in Palette. So I would say that it should mimic the SASS counterparts. That is, fixed amount is basically just current_value + max * amount.
For the docs, I'm usually not requiring people to write a lot because I know not everyone is too keen on doing it and I don't want to drag things out. And I know there can be a feeling of "being done" once someone has submitted a PR. But if I get to go into full wish list mode, I would say that it's good if both the text and the examples can demonstrate the functions fully. It should be clear from the text, but it should be fine to also only look at the examples. So feel free to make them completely exhaustive if you want to (while not drowning the reader in text 😅). It's going to be helpful as a guide for both using and implementing the traits. But I think that level of complexity (or simplicity) is good for the examples. They could perhaps just be a bit more verbose and explicit with the variables, like let saturated = original.saturate(0.5);.

I wasn't familiar but I understand the intention a lot better now. I re-read the original issue and see where I went off track keeping the old calculation methods. I think this should be closer to the goal.
I added documentation and examples for Shade and Saturate which was challenging to phrase. I removed the examples from the main trait description since they seemed redundant with each function getting its own example.

That makes sense in accounting for negative factors, the difference is self.lightness - T::zero() when the factor is negative. And I caught an error in Lab/Lch where I used max_intensity instead of from_f64(100.0) due to you mentioning it in your 4th paragraph.
I've changed the lighten and saturate methods to that algorithm. Are the *_fixed variants okay in their current implementations?
I've been wondering throughout this: should we clamp the components to the min and max before returning the color, or is max(T::zero()) enough? I'm fuzzy on what the guarantees or expectations are for library operations on colors being valid/clamped. I wouldn't want to add more overhead than necessary.

Great! Good catch with Lab and Lch. I sort of skimmed through them after realizing it had to be made a bit more complicated than it was.

Are the *_fixed variants okay in their current implementations?

Yes, I think they will be good as they are. 👍 They are just normalized addition and subtraction.

I've been wondering throughout this: should we clamp the components to the min and max before returning the color, or is max(T::zero()) enough? I'm fuzzy on what the guarantees or expectations are for library operations on colors being valid/clamped. I wouldn't want to add more overhead than necessary.

I have actually been wondering the same, so that's why I haven't maybe been so clear about my standpoint. Prepare for a brain dump!
I like to keep things open for "out-of-range" values because they could be useful as deltas (like my_color += delta;, where delta and my_color have the same type), and there's also the whole HDR thing and other cases where there is no specific limit. That's why I generally leave it to the user to clamp their values or offer escape hatches such as from_color_unclamped. But I can't say I have it 100% figured out yet.
For these operations, I see the output as more of a display value than a delta value, so I think some minimal clamping is fine. Values that correspond to some kind of brightness should probably just not be negative (what does that even represent? 😄), while values above 100% has their uses. Saturation could perhaps be fully clamped in some of the cases, but I think the conservative option is to only keep them positive as well.
The relative methods (lighten, saturate, etc.) have the extra tricky aspect of moving the value to one of two specified extremes. They are basically undefined for out-of-range input. I see a number of options there but all seem very weird and I still don't know if I picked the best one. Here are some:

Never move backwards (the current option). The good thing is that it stays somewhat true to the semantics. Lighten doesn't darken for positive input, etc. The downside is that out-of-range values may seem to be stuck when they don't change and it doesn't work for HDR in SDR scale.
Find some way to continue scaling them. This is complicated because we no longer have a reference point. Does it just use the current value, i.e. self.lightness += self.lightness * factor? What about negative values?
Ignore the out-of-range case. Definitely not suitable for HDR in SDR scale, so may be surprising, but is at least cheap and simple.

I don't think any of them stand out as a clear winner, just that the current option doesn't do anything too weird without trying to be particularly clever. But the last option could be perfectly valid, with the disclaimer that in-range values are assumed and clamping is recommended. I expect the "pickier" users to roll their own algorithms when they need full control and this is more for "casual" users, for lack of better terms.
What's your view on it all? Am I lost in my own thoughts?

The brain dump on this is welcome. There's a lot going on below the surface that isn't obvious at first glance, so it's good to talk about it especially when taking into account the future.

I like to keep things open for "out-of-range" values because they could be useful as deltas (like my_color += delta;, where delta and my_color have the same type), and there's also the whole HDR thing and other cases where there is no specific limit. That's why I generally leave it to the user to clamp their values or offer escape hatches such as from_color_unclamped. But I can't say I have it 100% figured out yet.
For these operations, I see the output as more of a display value than a delta value, so I think some minimal clamping is fine. Values that correspond to some kind of brightness should probably just not be negative (what does that even represent? ), while values above 100% has their uses. Saturation could perhaps be fully clamped in some of the cases, but I think the conservative option is to only keep them positive as well.

I agree with all of this. I think there's only a problem if there's a disconnect between user expectations and what the library does or expects of colors. That can be solved by the library stating its goals for the operations. If there's enough friction from use cases then the behavior can be improved or new methods added.
Unclamped-max values have uses for arithmetic and other cases, the upper clamp can be left to the user instead of adding more machinery and technical debt to churn through at a later date. Unclamped-min values for lightness, value, saturation, chroma, etc. don't make much sense to me.

I don't think any of them stand out as a clear winner, just that the current option doesn't do anything too weird without trying to be particularly clever. But the last option could be perfectly valid, with the disclaimer that in-range values are assumed and clamping is recommended. I expect the "pickier" users to roll their own algorithms when they need full control and this is more for "casual" users, for lack of better terms.

Agreed, I think for now this is the best default for the casual/average user. More advanced users can roll their own or contribute their methods back to the library if it's clearly better or general purpose enough. I can imagine some type of scaling maximum limits supplied as a parameter or generic parameter, but other problems like how HDR is handled should probably be solved first then solutions for relative operations will follow. When there are so many options on the table and with no clear-cut best, choosing what seems to be the least surprising option and not over-complicating the API surface seems reasonable until proven otherwise.

The brain dump on this is welcome. There's a lot going on below the surface that isn't obvious at first glance, so it's good to talk about it especially when taking into account the future.

I'll try to do it more often. Don't be afraid to remind me in the future!

I agree with all of this. I think there's only a problem if there's a disconnect between user expectations and what the library does or expects of colors. That can be solved by the library stating its goals for the operations. If there's enough friction from use cases then the behavior can be improved or new methods added.

Absolutely, that's simply a trade-off that need to be communicated in a good place. I suspect it's not so up-front at the moment. We'll have to try and see how it's received.

I can imagine some type of scaling maximum limits supplied as a parameter or generic parameter, but other problems like how HDR is handled should probably be solved first then solutions for relative operations will follow.

It's always possible to scale down to a 0.0-1.0 range while working with the color, and that may even be what they do with proper HDR if I'm not mistaken. My impression is that that's part of why there's a need to differ between HDR and SDR values on a type level. But yes, as you say, it's better to keep it simple. That way it will be easier to reason about and compose with other operations.
But I think this PR is pretty much done, unless you have anything to add. 🙂 I'm happy with the result and especially to have something more consistent that should be familiar when comparing to other software. Something you could do, by the way, is to run the saturate and shade examples and see how the output looks. I would expect them to be a bit different now, so probably good to make sure they look ok.

I have nothing else to add so I'll squash the commits.
Yes, the results are a bit different now. Current behavior is on the left, this PR on the right. The Lch example for saturate on the right is a bit extreme at 0.8.

That should be good from my end now :slightly_smiling_face:

Oh, wow, it's surely saturated! They both need to be changed a bit, but I'll do in my housekeeping PR instead, while messing around with the other examples. I might edit them a bit more than just restoring them to the old results, so I think it's better to do it all together and look over the rest of them too.
Thank you for the help here and for sharing your thoughts! It's always appreciated!
bors r+


Beta feature : Vision : PDF/TIFF/GIF document feature detection

Added new beta feature for Vision - PDF document feature detection. Have used the new approved format for the files. Please let me know if you would like me to switch it back.

@nnegrey Please review. Have used the new format here.

@nnegrey Thanks for reviewing . I have fixed all the comments, please let me know if there is anything else.

Please let me know if there is anything else.


Revert "refactor(resources): migrate WidgetList to TypeScript"

Reverts quisquous/cactbot#2532
@Trim21 I'm sorry to revert this, but this patch was causing all of my overlays to run with extreme lag.  Normally I wouldn't revert and would just fix, but I think this is a pretty bad bug.  My jobs overlay would print BrowserConsole: Element with id child20 is missing? (Source: http://localhost:8080/dist/jobs.bundle.js, Line: 10214) many times a second.  When I reverted this patch locally it stopped happening, so I feel pretty confident that this is the issue.

Looks like there is some bug in removeElement， I'll try to fix it

look like I'll get a notification every this commit is pushed to a fork...

Click unsubscribe button?

Click unsubscribe button?

Then I just unsubscribed from this commit in this forked repo.


Use RealStdlib for method method in gem generator

Motivation
We ran into an issue where a class was overriding the method method with one that took no arguments causing the generation of gem RBIs to fail. This just creates a RealStdlib version of method and uses that.
Test plan
See included automated tests.

Could you update the hidden method tests in gems/sorbet/test/hidden-method-finder? They seem to be failing with this change.

@elliottt how can I replicate this locally? I tried bazel test //... --config=dbg and test/snapshot/driver.sh but neither of these seem to run the test that was failing.

You should be able to reproduce them by running this command:
bazel test //gems/sorbet/test/hidden-method-finder

@elliottt I think I've fixed the test errors. Please take another look when you have the time!


Add a direct dependency on jsoup and upgrade to Quarkus 2.10.0.Final

jsoup was removed in the current main branch of Quarkus, which causes the platform CI to fail.
This PR introduces a direct dependency on jsoup and upgrades the Quarkus version to latest final release which is 2.10.0.Final.

We'll want a new release too though. Can we do that ASAP? Thanks!

@radcortez ^

In case @radcortez is too busy to do this, @gsmet will you be able to look into this? It'd be good to fix the platform CI.

In case @radcortez is too busy to do this, @gsmet will you be able to look into this? It'd be good to fix the platform CI.

I'll have a look today.


[Suggestion] Only search on spawn points?

That would increase the search speed a lot

agree

Yeah it would, especially for larger search areas.

Yeah, put this feature. Auto scan only spawn points


Load balancer extensibility

Load balancers seems to be a natural first class extension point in Envoy, but we don't support this today. As load balancer behaviors become more complicated, e.g. witness issues such as https://github.com/envoyproxy/envoy/issues/4685, and the need for custom locality handling in Istio (CC @rshriram @costinm), it would be great to allow for LB extensions and even CDS delivery of LB behaviors via Lua/WASM.
Complications that make this challenging include the tight integration between LB and various ClusterManager data structures such as host, priority and locality data structures. We would neat a tighter, more stable and better defined API here. Also, allowing reuse of existing LBs and just minor customization, without having to reimplement the entire LB, would be useful.
I'm opening this issue for discussion and long-term evolution of the LB implementation, help wanted.
CC @mattklein123 @snowp @cpakulski @rshriram @costinm

@htuch heads up that I was discussing this with @HenryYYang today and I don't think we are going to end up needing this for the redis cluster work so Lyft won't be implementing.

Ack; it's still on our backlog but not a super high priority.

@markdroth I see you landed https://github.com/envoyproxy/envoy/pull/7744 a while ago that seems to tie nicely into this issue. I was gonna spend some time thinking of how to do this over the next few months, and the config approach in your PR is very similar to what I was thinking. Is this something you're actively working on?

@snowp My impetus for #7744 was for gRPC clients being configured via xDS, not for Envoy, so I am not personally working on the Envoy-side changes to support this.  But I do agree that this should be implemented in Envoy, and we had discussed the possibility of @htuch taking this on at some point.  But if this is something that you need sooner, I suspect he would not mind if you take this on.
No matter who does the Envoy-side work, I would be happy to consult on functionality and semantics, to make sure that things stay consistent between Envoy and gRPC.

@markdroth yeah, @snowp and I chatted at EnvoyCon. He is the Envoy-side domain expert in this area, so it would be awesome if he can own this for us.

One thing I’m thinking about is whether it would make sense to move the generic lb configuration to the ClusterLoadAssignment proto, which would make it possible to reconfigure arbitrary lb details through EDS (or CDS since the proto is inlined). If we were to decouple endpoint details from the lb configuration (e.g. by using the named_endpoints) and provide a way to cross reference the structure and the endpoints it seems like we’d be able to provide a very flexible API for statically compiling in custom load balancers.
If this general approach seems reasonable I’d be happy to put together a doc.

@snowp I don't quite understand what you mean about cross-referencing the structure and the endpoints.  Can you give a concrete example of how this might work?
In general, it seems like EDS is mainly dynamic data (i.e., it changes to shift load around), whereas CDS is more configuration data (i.e., it changes only when humans modify it), and I would think that the LB policy configuration fits more into the latter category.  But if there are good reasons to do it in EDS, I'm not necessarily opposed.
I have actually considered putting the LB config in EDS at least twice, and both times we didn't wind up going with that approach.  Let me provide some context to explain when I considered that and why I didn't go with that approach.
gRPC has the ability to independently select the policy for each level of the routing hierarchy -- i.e., we can choose the policy for picking the locality and then separately choose the policy for picking the endpoint within the locality.  We do this by having the locality-picking policy create a child policy for each locality.  For each request, the parent policy picks the locality and delegates to the child policy for the chosen locality to pick the endpoint within that locality.  In effect, we have a tree of LB policies whose structure matches that of the organizational hierarchy of the endpoints.
I specifically wanted to be able to support that structure when I added the new fields in #7744.  The approach that I went with was essentially the same one that we use in gRPC: we have the config for the parent policy include a field that tells it what child policy to use and what config to pass to the child policy.  So, for example, if we had a locality-picking policy called "closest_locality", its config might be expressed using the following proto message:
message ClosestLocalityLbConfig {
  envoy.api.v2.LoadBalancingPolicy child_policy = 1;
}

We could use this to configure the "closest_locality" LB policy for locality picking and then independently choose a "weighted_round_robin" policy for endpoint picking.  Here's how it would look in CDS:
load_balancing_policy: {
  policies: {
    name: "io.grpc.builtin.closest_locality"
    typed_config: {
      type_url: "type.googleapis.com/io.grpc.ClosestLocalityLbConfig"
      value: {
        child_policy: {
          policies: {
            name: "io.grpc.builtin.weighted_round_robin"
          }
        }
      }
    }
  }
}

While working on #7744, I had originally considered saying that we would configure the locality-picking policy in CDS and then the endpoint-picking scheme in the Locality message in EDS, so that the latter could potentially even be overridden on a per-locality basis.  That approach would have worked fine for hierarchical policies, but it would not have provided an intuitive way to represent the existing Envoy LB policies that are non-hierarchical.  For example, I understand that Envoy's current ROUND_ROBIN policy handles weighting for both localities and endpoints in a single mechanism.  Because it's non-hierarchical, it's not clear how it would be represented in a config that wants to configure each level separately.  There are ways we could have made this work.  One way would have been to just configure the locality-picking policy and then leave the endpoint-picking policy unset.  Another way would have been to configure the same policy in both places, and have the two pieces work together to do the right thing.  But neither of these seemed as flexible as the approach we wound up using: because the hierarchical structure is encoded only in the per-policy config for policies that support it, the top-level config can deal only with the top-level LB policy, and any delegation to child policies that may happen inside of the top-level policy is hidden from the rest of the system.
The other time that I considered making this configurable in EDS was for the case I described in #7454.  We have a use-case where we have endpoints in two different priorities and we need to use a different endpoint-picking LB policy for each one.  We had originally thought about addressing that by allowing per-priority endpoint-picking policy overrides in EDS, but @htuch suggested that we use the aggregate cluster design instead.
Stepping back a bit, I have to say that it does seem a little strange that we have two different prioritization mechanisms that both basically do the same thing, one in the aggregate cluster design and another in the priority field for localities.  In the long run as part of UDPA, I wonder if it would make sense to try to restructure this such that a cluster defines priorities as a top-level concept, and then sets localities and endpoints for each priority.  In other words, instead of this:
Aggregate Cluster -> Prioritized Cluster -> Prioritized Locality -> Endpoint
we would have this:
Cluster -> Priority -> Locality -> Endpoint
Then we could set defaults at the Cluster level but also override them as needed at the priority level.
Anyway, this may be more detail than you are actually interested in, but I hope the context is useful.  Please let me know what you think.

@snowp didn't the last discussion around EDS-overriding-CDS end up with the aggregate cluster compromise? Was that missing some use case or does custom LB introduce new options that might need overriding in EDS?

@markdroth isn't "Cluster -> Priority -> Locality -> Endpoint" what we had before aggregate cluster? :)

@htuch No, before aggregate cluster, we had "Cluster -> Prioritized Locality -> Endpoint".  That structure couldn't handle overriding various things on a per-priority basis, which is why we had to add aggregate cluster.  What I'm proposing is combining the two places that we're doing prioritization into a single one.

Yeah, that makes sense. I think this is going to be on of the more complex aspects of UDPA; right now I'm getting a feel that there are some pretty non-controversial wins we can make in UDPA, for example transport protocol, routing and the moral equivalent of EGDS (i.e. discovering endpoints groups without any of this implied priority and policy). We're going to have to look at a few other proxies and see what they might need in terms of expressability etc here.

There seems to be a fundamental question we should probably figure out: how much of the existing load balancing logic should be core vs extensions? In my mind I was imagining a world where everything was just extensions, which is why I was thinking about having an arbitrary config stanza as part of the CLA proto. Imagine something like this on the CLA proto:
named_endpoints:
  foo: ...
  bar: ...
lb_config:
  name: envoy.load_balancers.priority
  config:
    priorities:
    - endpoints: [foo] # priority 0
        inner_lb:
          name: envoy.load_balancers.random
    - endpoints: [bar] # priority 1
        inner_lb:
          name: envoy.load_balancers.least_request

When I said cross-reference in the previous comment, I was referring to the fact that we're naming endpoints and then referring to them by name to define the LB structure in the config. Naming them vs defining inline means that we can refer to them multiple times:
lb_config:
  name: envoy.load_balancers.priority
  config:
    priorities:
    - endpoints: [foo, baz] # priority 0
        inner_lb:
          name: envoy.load_balancers.locality
          config:
            - weight: 10
               endpoints: [foo]
               inner_lb:
                 name: envoy.load_balancers.random
            - weight: 20
               endpoints: [baz]
               inner_lb:
                 name: envoy.load_balancers.random

With this, the configuration stored on the CLA is not just the LB policy, but the entire LB hierarchy. This is a pretty substantial change in how load balancing works in Envoy (the LB impls track the LB structure instead of the cluster), but it would make it possible to split up the LB code substantially and make it easier to pick and choose what LB features you want. It also substantially changes how host changes would be propagated in code, due to its current reliance on the PrioritySet which would no longer be a core part of the Cluster.
The composable API structure would also make it a lot easier for custom LB algorithms to be used for intermediate steps:
lb_config:
  name: envoy.load_balancers.priority
  config:
    priorities:
    - endpoints: [foo] # priority 0
        inner_lb:
          name: envoy.load_balancers.random
    - endpoints: [bar, baz, bax] # priority 1
        inner_lb:
          name: my.custom.lb
          config:
            inner_lb: envoy.load_balancers.least_request

where the high level idea is that my.custom.lb is used to select which subset of priorirty 1 should be targeted, and delegates the selection from that subset to the least_request LB.
This is all going down the path of trying to make everything extensible. It might be that we want to make certain things supported directly instead, which would probably warrant a different API.

@snowp In general, I agree that making everything extensible is the right approach.  I think that the built-in LB policies can simply be provided as plugins that are shipped with Envoy and available by default.  This is what we do in gRPC for the few LB policies that we provide out of the box.
I think there's also another benefit to what you're proposing here, which is that it actually removes the restriction that exists today where endpoints must be grouped into localities with associated priorities.  Instead, the hierarchy would be completely customizable by the user: it could be a single, flat list of endpoints, or it could be a multi-level hierarchy of priority, region, locality, and endpoint.  In effect, xDS would no longer be enforcing its own notion of the hierarchy in which endpoints are organized.  I think this would add a lot of flexibility.
One thing that may be fairly complex here is to figure out how to handle the priority failover logic that is used in choosing priority levels and in locality weighted load balancing.  I don't think that's an insurmountable issue; it's just something that we need to carefully consider when we design the LB policy API.  When we get further into the details, I'd be happy to show you how our API in gRPC handles this sort of thing.
The one noteworthy difference I see between what you're proposing and what we do in gRPC is that you would be explicitly setting the targets along with the config for each level of LB policy, whereas in gRPC, we usually wind up specifying those two things separately.  However, the design you propose does actually seem a bit more flexible, since it allows more easily overriding the behavior for each individual child of a given node in the LB policy tree.  And gRPC can certainly adapt to this approach when we start using this part of UDPA.

I think the endpoint cross-refs is basically what we are thinking about in EGDS (see mentions of this in https://github.com/envoyproxy/envoy/issues/8400), I think there is a lot of alignment around this idea.

I think there's also another benefit to what you're proposing here, which is that it actually removes the restriction that exists today where endpoints must be grouped into localities with associated priorities. Instead, the hierarchy would be completely customizable by the user: it could be a single, flat list of endpoints, or it could be a multi-level hierarchy of priority, region, locality, and endpoint. In effect, xDS would no longer be enforcing its own notion of the hierarchy in which endpoints are organized. I think this would add a lot of flexibility.

I think this is pretty key in providing a truly extensible LB experience: having the API (and by extension the implementations) be opinionated about the hierarchy makes it hard for custom LBs to efficiently store endpoints in a different format: in Envoy, this would most likely result in these LB extensions managing their LB state in addition to the PrioritySet, resulting in a lot of wasted space and time spent processing host changes.
Another approach I had in mind for splitting LB config and endpoints was to make use of endpoint metadata to provide per LB extension information in the endpoint metadata, something like:
named_endpoints:
  foo:
    address: ...
    metadata:
       envoy.lb.priorities:
         priority: 1
       envoy.lb.endpoint_weighting:
         weight: 2
       envoy.lb.locality:
         locality:
           zone: ...

This moves the endpoints out of the dynamic LB config, which would make it very easy to provide partial EDS updates as talked about in #8400: the LB config remains relatively fixed, and endpoints can be added/removed from the endpoint map without having to worry about modifying the arbitrary tree formed by the LB config.
This sacrifices some wire overhead (ie potentially lots of config per endpoint) and possibly harder to optimize update code (you have to keep scanning the endpoints for which ones match a priority, locality, etc., vs knowing the names from the LB config) for the reduction in coupling between the endpoints and the LB config.

I think the most flexible way of approaching this might be to simply have each LB policy control how it identifies its children.  There are some cases where it will be useful to directly configure a policy's children in its LB config, but there are other cases where the policy will need to dynamically determine its children at run-time.  That might be done based on a request header, or it might be controlled by some external control plane.
One very flexible way of doing this would be to allow each policy to create its own xDS resource type, which it could query via ADS.  For example, let's say that we want a simple hierarchy of the following form:
Cluster -> Locality -> Endpoint
There are no priorities.  We want to use simple weighted round-robin picking of the locality and then use the least_request policy for picking the endpoint within the locality.  To do this, we can define a new xDS resource type that defines the set of localities in the cluster, which would look something like this:
message ClusterLocalities {
  message Locality {
    // Name of locality.
    string name = 1;
    // Weight.
    uint64 weight = 2;
    // List of EGDS resources for this locality.
    messge Egds {
      ConfigSource source = 1;
      string name = 2;
    }
    repeated Egds egds = 3;
  }
  repeated Locality locality = 1;
}

The config message for the top-level LB policy can look something like this:
message LocalityLbConfig {
  // How to fetch the cluster locality info.
  ConfigSource cluster_locality_source = 1;
  string cluster_locality_name = 2;
  // The child policy to create for each locality.
  envoy.api.v2.LoadBalancingPolicy child_policy = 3;
}

The top-level LB policy will fetch the ClusterLocality resource as specified in the config and create the specified child policy for each config.
The child policy might have a config message that looks like this:
message EndpointLeastRequest {
  // List of EGDS resources for this locality.
  messge Egds {
    ConfigSource source = 1;
    string name = 2;
  }
  repeated Egds egds = 1;
}

The child policy will fetch the EGDS resources and perform the least_request algorithm across the resulting endpoints to pick the endpoint for each request.
An actual configuration might look like this:
lb_config:
  name: envoy.load_balancers.locality_round_robin
  config:
    locality_group_source:
      ads:
    locality_group_name: "my_locality_group"
    child_policy:
      name: envoy.load_balancers.least_request

Note that in this case, the config for the top-level LB policy is fully specified in the LB config; it specifies which locality group to use directly in the config.  However, the child policy specifies the name only, not the corresponding config, because the top-level policy will construct the config for the child policy based on the Locality data it obtains from the management server.  (There are obviously other ways we could have structured this if we wanted, but this is just an example.)
This approach provides flexible decoupling of endpoint data from the LB config, but it would avoid the overhead of tagging everything as metadata on the endpoints, which both avoids the wire overhead and provides more flexibility for non-leaf policies that don't know or care about endpoints.
As a side note, this also makes me think that as part of UDPA, we should consider splitting up some parts of what's currently in RDS and moving it to this new LB policy mechanism instead.  For example, it would be trivial to express things like cluster_header or weighted_clusters as an LB policy.

@markdroth it looks like you have a lot of great ideas for where to take the API. Do you and @snowp  want to put together a strawman (similar to what we did for routing) for UDPA-WG? That way we can explore this in a doc rather than GH threads, which are hard to follow and then feed that next year into some concrete protos.
I would aim for the v3 API (which is where this present issue is likely to intercept) to be a bit more constrained. EGDS makes sense and we need that sooner rather than later, but we should probably descope as much as possible to ensure we can deliver in that time frame.

/cc @yxue

/cc @jmarantz

I was looking at how to implement custom load-balancing algorithms in envoy, and based on this thread, this needs to be a cluster based extension? (similar to what was done for Redis)? The EDGS and other ideas here are not merged, right? Is there any reference on what we can use/restrictions for custom algorithm today?

@markdroth @htuch @snowp
By my understanding, It is possible to use hierarchical load balancing.
But I have been trying to set that up, but there is no sample documentation for the same.
How do I go about setting a hierarchical policy, for eg:

First to check the closest endpoints (by zone)
And then to select which endpoint to route to, within that zone.

Can you share a sample doc/code snippet for the same?

We don't have any "parent" LB policies today, but we do now have the structure in place such that it should not be too hard for you to write such a policy.
What is the exact behavior you want here for selecting the zone?  If you always want the closest zone for any given client, why not just have the control plane send only the endpoints in that zone to the client, so that no matter what it picks, it gets the right thing?


Add comments attribute to the study

Being able to add comments to the study can be useful for the user to keep track of different things that the tried about the study.

@josenavas, I know is not the same but perhaps the tags are useful here?

I think the idea of this was to add more verbose comments. I do not recall exactly the examples that we had, but I think it was a free text in which the study owner could add some more background to the study and/or notes on the current status.


[KFNBC]: UI: Support tolerations for Jupyter notebooks

Feature description
See following jira for details: https://issues.redhat.com/browse/RHODS-3624
Note: The above jira is more involved.  P0 is the focus.
Describe alternatives you've considered
No response
Anything else?
No response

I think we should allow an admin to designate tolerations at the global scope for all notebooks AND/OR specific sizes.  Also this should allow for tolerations that only applied to be applied when a Special Resource (GPU) is requested by the user

Mockup: https://marvelapp.com/prototype/djj8abd


Naming suggestion of tags

In the Deployment (CI/CD) considerations section after the part where the build has succeeded in point 3 the current tag is myrepo.azurecr.io/delivery:v1.0.2 and the production tag is reponame.azurecr.io/prod/delivery:v1.0.2. I would be cleaner to use the same repo names: myrepo or reponame.

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

ID: c5e2e444-d6b9-962e-56d4-8d1f3508ba9e
Version Independent ID: 061ea6aa-353b-a98d-cbf6-639209a5fd1b
Content: Microservices architecture on Azure Kubernetes Service (AKS)
Content Source: docs/reference-architectures/microservices/aks.md
Service: architecture-center
GitHub Login: @MikeWasson
Microsoft Alias: pnp

@sujithq Thank you posting your question. we will review this and provide an update as appropriate.

@sujithq  Yes, thanks - that was the intent. I'll fix this.


[BUG] test.step failures dont fail the test , appears as passed on the html report

please execute the following test and then view the report ... the test case passes on the report instead of failing.. i think when you use test.step and if the failure occurs inside the test.step it does not fail the test
const { test, expect } = require("@playwright/test");
const config = require("../../config/environment_manager");
//run command
//ENV=dev npx playwright test tests/training/test.spec.js
var number_one = 3;
var number_two = 4;
var total = "";
test("most basic test: add two numbers", async () => {
test.step("add two numbers", async () => {

    //adding two numbers

    total= number_one + number_two;

    console.log( "the total is: ",total);

    });

test.step("verify total", async () => {

//Assertion

expect(total).toBe(6);

});

});

Try using soft assertions in step:
https://playwright.dev/docs/test-assertions#soft-assertions
expect.soft(total).toBe(6);

I don't know why but works. and this should not be a bug of the report, but the logic of Playwright itself.


Adding GCM

@mar-v-in Are there any plans to include GCM support in this library?

Yes. I already started development but had no time to get it to a usable state. I will try to provide a somewhat useful state the next days (which should be enough to get basic push notifications running).

If you already have written some code, could you push it to a dev branch?

I don't know what exactly is in the code I wrote (it's some time ago already I worked on that), so I first have to look through it, but I'll for sure push something the next days.

A first working (but likely incomplete) version is in git as of 3bb89224dc28fddce7049e3e693c320e79514318

@mar-v-in did push ever start working? Can't get it to work atm :-/


collect-info binary missing

The README.md mentions collect-info should be (as binary) present in the download.
For me (downloading the 2.0.2 zip release) it is not. Is something going wrong here?
I ran into some other issues as well for which I'll try to create PRs later. Thanks.

The download zip is only the source code. As described in the top-level readme, you need to generate a diagnostic bundle first. Part of that generation process is the multi-arch compilation of the rust code into the collect-info binary.


Add public key support

Description

re-factored "crypto.ts" to handle PEM files in more general way.
Added unit tests for new functions.
Re-factored internally implementation to use "key info" (or similar) terminology instead of talking only about certificates. Certificate term is ok, if we known that we are handling certificate.

These changes are not making any changes into used interface, only internal re-factoring.
I will make changes to README.md before merge, because it is not currently talking about public key support. Public key support comes through cert property, if PEM file is well formatted then it is accepted.

Resolves https://github.com/node-saml/node-saml/issues/206

Thank you for this, but all these code scanning alerts will have to be addressed. If you need help figuring out how to make the regex less catastrophic, please post here and we'll see what help we can provide.
It looks like the new code you added isn't 100% covered by tests. Please have a look and see what can be done about that.
I look forward to seeing your README updates; our README definitely needs a little TLC.
Also, if it is easy to add a test to add coverage to another part of the code that is currently untested, perhaps a branch, please consider that; sometimes I find that when I'm writing a test trying to get complete coverage for my new code, I see that I can make one tweak to a new test and cover a previously untested branch in some other code.

@cjbarth

..but all these code scanning alerts will have to be addressed. ofc. I'll check what is the best way to test potential fix before pushing changes. (I have not used Github code scanning tools before)
It looks like the new code you added isn't 100% covered by tests. , I'll check what improvements there can be made. Those PEM handling functions should be covered as much as possible. My guess is that assertions should be tested better.
README.md updates
Add at least one unit test for saml.ts where well formatted PEM public key is given into library.
Check that is there need to add tests for saml.ts getKeyInfosAsPem() function. (most likely yes)

..but all these code scanning alerts will have to be addressed. ofc. I'll check what is the best way to test potential fix before pushing changes. (I have not used Github code scanning tools before)

One of the best ways is to just look at the manual: https://codeql.github.com/codeql-query-help/javascript/js-polynomial-redos/. As suggested, anchoring the string or using some lookbehind helps a lot.

@cjbarth I have now;

Added more tests for crypto.ts
Fixed regex issues
Added test for public key
Added tests for resolveAndParseKeyInfosToPem()
Updated readme to contain mention about public key support

Thanks for all your hard work and the clarity of your code. I see that this patch is almost at 100%, good job! Keep at it!

@cjbarth is there something that should be done to get this PR into master?

DeepScan finding is false-positive
codecov finding is minor

@cjbarth Hi, is there something that you are expecting me to work with this PR? Or do you have time allocation issues with this PR? I would like to work to get this PR finished.

It seems that my previous PR comments are unresolved. Why not start there? I'm also interested in addressing those regex warnings, but I need more time to review what can be done there.

DeepScan stuff fixed, I'll check if I can get coverage a bit better.

@cjbarth Hi, I resolved most of the conversations on couple of weeks ago, but there are still those two open conversations. For now I need more feedback from you in order to get things moving.
If there are some issues which needs to be addressed in specific way other than those two open conversations, I wish you point out those explicitly where the issue is and how you want it to be fixed so that I can make those fixes.

I'm sorry for the delay; I was unavailable for a while. I'm back to giving this project more attention. I've read over the changes you've made and they look good. I'll take time to take a second look at my comments that are still open and see if they are still valid or if I need to add more details.

@RopoMen , I've pushed up a lot of changes to improve this code. We don't want to export code just for testing, so many tests were changed, or even removed, for that reason. Many tests were redundant.
I see the point about the codecov tool. I'll merge if you agree with the changes I've made. I look forward to your feedback.

@RopoMen , I've pushed up a lot of changes to improve this code. We don't want to export code just for testing, so many tests were changed, or even removed, for that reason. Many tests were redundant.
I see the point about the codecov tool. I'll merge if you agree with the changes I've made. I look forward to your feedback.

Hi @cjbarth
You can merge this if you are done. I don't mind about the changes, main point is more important.
Thank you to be active again 😁


subj_areas migration handle EMPTY -> NULL

Pull Request Checklist:

[x] Positive Test Case Written by Dev

[ ] Automated Testing

[ ] Sufficient User and Developer Documentation

[ ] Passing Jenkins Build

[ ] Peer Code review and approval

Positive Test Case

git checkout 2.5 && ./hsctl loaddb
git checkout develop && ./hsctl managepy migrate <-- should give an error like:

django.db.utils.DataError: malformed array literal: ""
DETAIL:  Array value must start with "{" or dimension information.

git checkout subject_area_migration_fix && ./hsctl managepy migrate <-- should succeed without the error

METRIC
VALUE

https://sonarqube.cuahsi-workstation.com:9000/dashboard?id=hydroshare-5051


anchor links not working

these anchor links aren't working:

source

It seems to have something to do w/ the versioning feature 🤷♂.
See how the anchor link changes slightly w/ the -3 vs -1 based upon w/ version of ASP.NET core is selected:
https://learn.microsoft.com/en-us/aspnet/core/web-api/?view=aspnetcore-2.1#attribute-routing-requirement-3
https://learn.microsoft.com/en-us/aspnet/core/web-api/?view=aspnetcore-7.0#attribute-routing-requirement-1
but the doc page doesn't have -N in them.  This is the link on the page:
https://learn.microsoft.com/en-us/aspnet/core/web-api/?view=aspnetcore-2.1#attribute-routing-requirement

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

ID: b391017f-25e1-d5e1-c4f7-020408ade7b5
Version Independent ID: 263a7b64-2e42-bbfc-c1d3-61680438e1e4
Content: Create web APIs with ASP.NET Core
Content Source: aspnetcore/web-api/index.md
Product: aspnet-core
Technology: aspnetcore-webapi
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

That's correct, @spottedmahn. This is a known limitation of the current versioning. Duplicate section headings are enumerated by the build system, so the links in earlier versions of the doc break. There's some background work going on to try and address this, but there's no ETA at this time on a new versioning implementation.


DOCS-#3803: update "building modin from source" docs

Signed-off-by: Anatoly Myachev<EMAIL_ADDRESS>
What do these changes do?

[x] first commit message and PR title follow format outlined here

NOTE:  If you edit the PR title to match this format, you need to add another commit (even if it's empty) or amend your last commit for the CI job that checks the PR title to pick up the new PR title.

[x] passes flake8 modin/ asv_bench/benchmarks scripts/doc_checker.py
[x] passes black --check modin/ asv_bench/benchmarks scripts/doc_checker.py
[x] signed commit with git commit -s
[x] Resolves #3803
[x] tests added and passing
[x] module layout described at docs/development/architecture.rst is up-to-date

@vnlitvinov changes in docs folder don't result in build-docs: job being executed. Is this expected? https://github.com/modin-project/modin/blob/5ebbac683321d23c975d059a995eb7cc1b6353e9/.github/workflows/ci.yml#L50

@anmyachev, you should rebase on current master to make docs build passed.


Update fs2-kafka to 3.3.1

About this PR
📦 Updates com.github.fd4s:fs2-kafka from 3.1.0 to 3.3.1
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

🔍 Files still referring to the old version number
The following files still refer to the old version number (3.1.0).
You might want to review and update them manually.
modules/ws-client/yarn.lock
modules/ws-client/yarn.nix

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.github.fd4s", artifactId = "fs2-kafka" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.github.fd4s", artifactId = "fs2-kafka" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, version-scheme:early-semver, old-version-remains, commit-count:1

Superseded by #337.


Regular Expressions: Specify Only the Lower Number of Matches

Describe your problem and how to reproduce it:
On the challenge entitled "Regular Expressions: Specify Only the Lower Number of Matches" the instructions say to "Change the regex haRegex to match the word "Hazzah" only when it has four or more letter z's."
I provide the code to match 4 or more z's -->
let haStr = "Hazzzzah";
let haRegex = /Haz{4,}zah/;
let result = haRegex.test(haStr);
All tests except 'Your regex should match "Hazzzzah"' pass.
I change code to -->
let haStr = "Hazzzzah";
let haRegex = /Haz{3,}zah/;
let result = haRegex.test(haStr);
And all tests pass.  This shouldn't happen as the instructions say 4 or more
Add a Link to the page with the problem:
https://learn.freecodecamp.org/javascript-algorithms-and-data-structures/regular-expressions/specify-only-the-lower-number-of-matches
Tell us about your browser and operating system:

Browser Name: FireFox Quantum
Browser Version: 63.0.3 (64-bit)
Operating System: Windows10 (64-bit)

If possible, add a screenshot here (you can drag and drop, png, jpg, gif, etc. in this box):

Hi @JS-goose,
Thank you for opening this issue.
The regex /Haz{3,}zah/ is also correct because it'll only match 4 z's or more. Note that z{3,} will match atleast 3 z's and the "z" after that would be another match. The only difference between z{4,} and z{3,}z is that in the latter one the last "z" is matched explicitly.
Hope this cleared it up.
Closing this issue, feel free to reopen if you think issue isnt fixed.
Happy contributing!

This makes sense to me know.  The wording on the challenge led me to believe that only 4 (explicitly) would be matched.  Thank you for clearing that up!

@ezioda004
Sorry, i was looking for this issue
here is my regex
`/Haz{4,}ah/g
it doesn't match 5 z

but when i test it on online regex tester, it should be a match
i think this is a bug, or did i miss something?

@rickvian You should really check the forum first with these kinds of issues and if those helping you on the forum believe it is a bug, you would report it over here.  The problem is your use of the g flag when using test.  When using the g flag with test multiple times (as our behind-the-scenes tests are doing), the lastIndex property of the regex does not get reset each time automatically.  See https://stackoverflow.com/questions/1520800/why-does-a-regexp-with-global-flag-give-wrong-results for more information.  Just remove the g flag.

let haStr = "Hazzzzah";
let haRegex = /Haz{4,}ah/gi; // Change this line
let result = haRegex.test(haStr);
console.log(result);


deployment demo webstore to kubernetes

helm chart

[ ] demo-webstore
[ ] otelcol
[ ] jaeger
[ ] Prometheus
[ ] document
[ ] Multi-node (load balancing, replica etc.)
[ ] documents
[ ] test

Kubernetes quick setup (local setup)

[ ] Kubernetes YAML file
[ ] documents

The demo store currently only supports docker-compose deployments.
We should support the deployment of the demo store to Kubernetes.
There are two ways to deploy to Kubernetes.

Kubernetes YAML
Excellent for beginners, with a quick start. simply run a command line

kubectl apply -f https://raw.githubusercontent.com/....../demo-store.yaml

helm chart
You can flexibly choose the configuration of the demo store you want to deploy.
For example, helm/value.yaml

feature:
    log_collect: true
    epbf: true
    database: false
loadgenerator:
    speed: 10

This issue is part of #41

I agree with this issue. With kubernetes, we can also involve opentelemetry operator into this demo which is more close to the way of using otel-collector for users who are also using kubernetes.

The helm chart should be probably added to https://github.com/open-telemetry/opentelemetry-helm-charts

I would like to help the helm chart :)

We need to have a discussion/vote on whether our helm chart should be called opentelemetry-demo or opentelemetry-demo-webstore (to be consistent with the repo name)
@austinlparker @cartersocha @open-telemetry/demo-webstore-approvers  @open-telemetry/demo-webstore-maintainers

helm chart: opentelemetry-demo

helm chart: opentelemetry-demo-webstore

Vote: I'd like the chart called the same name as the repo

I'd say we should keep it consistent with other charts which are called the same as repos. What's the benefit of dropping -webstore?

We are investigating changing the repo name, and dropping the -webstore suffix.  See #222

Yall should be unblocked now. Please proceed

There’s a helm chart you can start with already available @xoscar. Check the main readme

Added support


Limit the size of the image cache

Fixed #1009

@eseidelGoogle @Hixie
I think the biggest controversy here is whether to take a production dependency on Quiver.

That's not controversial. We already depend on quiver (via vector_math).

lgtm

That's not controversial. We already depend on quiver (via vector_math).

pub deps in packages/flutter says that vector_math doesn't have any dependencies.

I see:
|
'-- vector_math 1.4.4
    '-- quiver 0.21.4
        '-- matcher...

Might be a dev dependency?

https://github.com/google/vector_math.dart/blob/master/pubspec.yaml says it's a regular dependency

vector_math 1.4.3
Maybe a recent change.

Ok, will land.

Ah, yeah, John release 1.4.4 a couple of weeks ago. The dependency comes from a chance last summer, but it only just got released.


FIXME: correct error return in _load_settings_text

This is interesting. Do we know for sure that FileAccess::open() won't return ERR_FILE_CANT_OPEN in case the file doesn't exist? There's a point in the code that checks against that specific error code. Additionally, _load_settings_binary is not doing any mapping of return codes, so I'm a bit puzzled about the text counterpart needing it. Either binary load should be doing the mapping (fishy) or, as this PR suggest, text load shouldn't.
Can you please clarify?


Feedback Files: Ensure submission association if it exists

Motivation and Context

the API feedback_files.index method currently does not return any feedback files, because it calls submission.feedback_files but feedback files are not currently associated with submissions directly. This PR adds that association, if a submission exists for the test run.
Your Changes

Description:
Modified test_run.update_results! to add submission association if one exists.
Type of change (select all that apply):

[x] Bug fix (non-breaking change which fixes an issue)

Testing

Tested via the markusapi package, as well as adding tests.
Questions and Comments (if applicable)

If a submission exists when test results are processed, marks are created due to a call to set_autotest_marks in update_results!, even if the tests have failed. I don't think this is a problem, but there may be cases I'm not considering.
Checklist

[x] I have performed a self-review of my own code.
[x] I have verified that the pre-commit.ci checks have passed.
[ ] I have verified that the CI tests have passed.
[ ] I have reviewed the test coverage changes reported on Coveralls.
[x] I have added tests for my changes.
[ ] I have updated the Changelog.md file.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

17 of 17 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.003%) to 91.565%

Totals

Change from base Build<PHONE_NUMBER>:
0.003%

Covered Lines:
38550

Relevant Lines:
41480

💛  - Coveralls


Add getCollectionReactively()

This PR implements getCollectionReactively(). I tried to do it in as clean a manner as possible, but let me know if you have any suggestions for improving anything, and I will be happy to make those adjustments.
Fixes #1088

@canac thank you so much!
I'm adding this, but I will also want you to think about the next version - 1.4.x
Please have a look at the branch and let me know what you think about that API.
You can also contact me directly.


docs: add close old prs workflow

Closes #271

to close prs that have been inactive for more than 30 days.

Working

The workflow is triggered on a schedule using a cron expression. In this case, it is set to run every day at midnight (0 0 * * *).

The workflow job named close-old-prs runs on the latest version of the Ubuntu environment.

The steps within the job are as follows:

"Checkout Repository" step: This step checks out the repository's code, allowing subsequent actions to access its contents.
"Close Old PRs" step: This step contains the main logic to close old PRs. Here's what it does:

It makes a GET request to the GitHub API to retrieve a list of open PRs in the repository.
For each open PR, it retrieves the last updated timestamp using another API request.
It calculates the number of days that have passed since the last update of the PR.

If the number of days since the last update is greater than 30, it makes a PATCH request to the GitHub API to close the PR by updating its state to closed.

The workflow utilizes the secrets.GITHUB_TOKEN secret, which is a token provided by GitHub to authenticate and authorize API requests made by the workflow.

Overall, this workflow helps automate the process of closing old PRs in a GitHub repository by checking their last update timestamp and closing them if they have been inactive for more than 30 days.

We can also insert a workflow that closes PRs without linked issues if it is relevant to the contributing guidelines. Feel free to share your thoughts regarding this workflow.

@Vikash-8090-Yadav
Could you please review this pull request :)

Nope, closing Pr does not seem to be legit this time. Thanks!

@Vikash-8090-Yadav
As an experienced contributor, I prefer to work on assigned tasks and avoid having closed pull requests on my profile without being merged. This can create a negative impression. Therefore, I kindly request that you refrain from assigning an issue if you do not intend to accept the corresponding pull request.
In addition, I have provided an image as a reference to further clarify my point:

Image

As a mentor, and contributor, I want to emphasize the following statement:
This time, I will not create a ticket, but I do ask for your understanding and cooperation to avoid this situation in the future. Thank you for your attention, and please consider my request.


Added a re-implementation of RIBES

RIBES is a popular MT evaluation metric, especially for Asian language pairs. The official scripts can be found at http://www.kecl.ntt.co.jp/icl/lirg/ribes/
This re-implementation provides an educational documentation of the various parts of the algorithm described in the paper.
Since the licenses differs for NLTK and RIBES, having RIBES code in verbatim would be technically wrong. Users are still encouraged to use the official script when evaluating their MT system.
Note that the emulation code was removed at https://github.com/alvations/nltk/commit/520a6760b3012aa0fd245264741ad4d9563645da at the suggestion of the original RIBES maintainers.

@hoontw – would you mind reviewing this contribution please?

I will review this over the next few days.

@hoontw thanks for looking through the code! Please continue to review if you have yet finished but I've got to go offline for a while. And I'll get back to the edits tomorrow.

@hoontw Thanks again for the reviews. I think I've fixed most of the suggested edits, I hope I didn't miss anything. Sorry that it took a while to revise because I was busy.


add inventory options

Added possibility to set dynamic inventory parameters compose, groups and keyed_groups. Details: https://docs.ansible.com/ansible/latest/dev_guide/developing_inventory.html#constructed-features
Additionally added option to enable or disable automatic creation of groups by the tag.

Thanks!
I'll take a look at this over the next day or so.

Sorry it took so long to merge this. Thanks for your contribution!

This is released as version v0.3.0. Thanks Again!


missing: "love.textedited" callback

Wiki Page: https://love2d.org/wiki/love.textedited
I believe this callback is missed and not included in loveCallbacks .

Thanks for pointing out. It was a typo actually, textedit instead of textedited. Fixed it.


Made Notify me button worked

Previously Notify Me button on index.html was not redirecting to contact me page. Changed the code to make it work.

#72


Integration Test - Release - 2019/09/10 15:38:25

Auto create for integration test. IssueCommandFlow

@PRMergerTest3 : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Benchmark, consider over-fitting optimization

By my curiosity, I just benchmarked is() function with only one instance.
The result was 200,000x times faster and I just assume that over-fitting optimization had happend by v8 engine. Category of the overfitting optimization may cashingcaching validation result and just checking whethet pre-validated instance or not.
Therefore, I need to research my benchmark program again and it would better to make benchmark data size larger.
However, it is a dilema for me that increasing data size by using Array. Iterating the Array also have its own cost and it can damage on objective benchmark measurement. Such extra cost would be bad for faster libraries and good for slower libraries.

Tested a lot to avoid over-fitting optimization by caching.
Except ObjectSimple structure for is() function, 3 repeated function call avoid the cashing. Also, is<ObjectSimple>() function can avoid such caching by 4 repeated function call. Although such repeated function call damages on perfective benchmark measurement, but it is better then using Array iteration.

Add a question article on google v8 engine users group:
https://groups.google.com/g/v8-users/c/tJ-LgXyv1zM