Deno.openKv with Subdirectory issue on open

My rust skills are garbage, otherwise i would just submit a pr...  That said, the issue that I am seeing is that when opening a new Deno KV instance in a subdirectory, if the directory does not already exist, it fails to open:
const denokv = await Deno.openKv('./denoKv/deno.db');

I get the following error:
TypeError: unable to open database file: ./denoKv/deno.db: Error code 14: Unable to open the database file
const kv = await Deno.openKv(path);
           ^
    at async Object.openKv (ext:deno_kv/01_db.ts:10:15)
    at async https://deno.land/x/deno_kv_oauth@v0.10.0/lib/_kv.ts:10:12

If the directory already exists for ./denoKv then everything works fine.
Would it be possible to update the code so that it creates any directories if they do not already exist? Before attempting to create the DB files.
The workaround is to create the ./denoKv directory with a .gitkeep file in it, but would be nice if it handles directory creation as well.

Thank you for the suggestion. Though, the idea is outside of the scope of this module. If you'd like to pursue having this functionality, I suggest opening an issue in the main runtime repository (https://github.com/denoland/deno).

Thank you for the suggestion. Though, the idea is outside of the scope of this module. If you'd like to pursue having this functionality, I suggest opening an issue in the main runtime repository (https://github.com/denoland/deno).

@mcgear there is a function in the standard lib to ensure a directory exists... ensureDir
and if you need to determine the directory from the full path... dirname
import { ensureDir } from<EMAIL_ADDRESS>import { dirname } from<EMAIL_ADDRESS>
const DB = './denoKv/deno.db';

await ensureDir(dirname(DB));
const denokv = await Deno.openKv(DB);

Great suggestion, @jollytoad!


[GSoC19] Fetch data from MongoDB

This PR contains commits from all the PRs.
Merge only this PR after reviewing all the PRs.
Any changes required after reviewing any PRs will be updated on this PR.

@kb0304 can you review this file https://github.com/shubhsherl/Ghost/pull/11/files#diff-beac10a5dcf35538fde2f7af2b63f0cd
here I am using mongo client for fetching details from RC


update get-dagNode for buffers

This adds a check for the response from the go/js daemons to see if data is sending a stream or a buffer. This is need for PR
@noffle for CR

Could we just update + push a new version of js-ipfs that returns streams instead of buffers, and avoid this branching & complexity altogether?

I thought about doing that but would need to see if any other modules / tests rely on object/data returning a buffer not a stream.
I agree that it would be nice to have this fix less abstracted away but the error is in a pretty specific use case of the js-ipfs daemon handling requests for add command only.
Would it be more work than it is worth to put the fix in the core just for one use case of one command?

It's a valid stop-gap that maintains backwards compatibility. My primary concern is having core consistently returning the same thing on js-ipfs and go-ipfs (streams, that is).

Thank you @nginnever, good catch. Seems that this is due that go-ipfs sometimes likes to send a stream instead (x-stream) and js-ipfs-api request-api.js module catches that and exposes it as a stream, but sometimes, if the x-stream header is not set, it actually buffers the whole thing.
Getting the data from an object should not come as a stream, that seems like an inconsistency from go-ipfs //cc @whyrusleeping
@nginnever could you make sure this is covered by tests. Can you get the problem reproduced easily? It would help to debug in go-ipfs.

I'm merging this one. It is hard to make a test that easily reproduces the issue, because it depends on how go-ipfs feels. Current tests pass and the change is small enough and solid.
Thank you @nginnever :)


Update for DevExtreme definitions

Tests for 14.2.7 version and definitions for dxResizable widget added.

Sorry, isn't actual now.


Cannot generate an identity on Alpine Linux

Environment

OS: Alpine Linux 3.16.2
age-plugin-yubikey version: 0.3.0

What were you trying to do
Generate an identity to install to my Yubikey 4.
What happened
$ ./age-plugin-yubikey
✨ Let's get your YubiKey set up for age! ✨

This tool can create a new age identity in a free slot of your YubiKey.
It will generate an identity file that you can use with an age client,
along with the corresponding recipient. You can also do this directly
with:
    age-plugin-yubikey --generate

If you are already using a YubiKey with age, you can select an existing
slot to recreate its corresponding identity file and recipient.

When asked below to select an option, use the up/down arrow keys to
make your choice, or press [Esc] or [q] to quit.

thread 'main' panicked at 'range end index 4 out of range for slice of length 0', /home/djmoch/.cargo/registry/src/github.com-1ecc6299db9ec823/yubikey-0.5.0/src/transaction.rs:160:9

Without looking it further, I'm assuming this is an issue in the yubikey crate. I'll leave this here for feedback or until I can confirm.

It turns out this was not an issue with anything in the application, but with the Yubikey device itself. Are Yubikey 4 devices really supported? Here's the info on the non-functioning device.
$ ykman info
Device type: YubiKey 4
Firmware version: 4.3.3
Enabled USB interfaces: OTP, FIDO, CCID

Applications
FIDO2       	Not available
OTP         	Enabled
FIDO U2F    	Enabled
OATH        	Enabled
YubiHSM Auth	Not available
OpenPGP     	Enabled
PIV         	Enabled

Anyway, I ordered a Yubikey 5 and it appears to be working just fine.

@djmoch, there's an Alpine Docker PR in case you want to use it: https://github.com/str4d/age-plugin-yubikey/pull/69.

This indeed looks like a problem with the yubikey crate. Supposedly we support YubiKey 4 there; this must be an edge case we haven't seen before. I'm curious as to whether it is a problem with that specific YubiKey, or with the YubiKey 4.3.3 firmware.

@str4d I see it works with a Yubikey 4C FIPS with firmware 4.4.5. This is conversation is probably better handled over at the yubikey repo, so I'll open an issue there.

This issue was fixed by https://github.com/iqlusioninc/yubikey.rs/pull/466 which we brought into main in https://github.com/str4d/age-plugin-yubikey/commit/9418921dab67f7ba01f6ffce2a10f5e3ca1c4557 (fix confirmed by https://github.com/str4d/age-plugin-yubikey/issues/114#issuecomment-1407330664). The fix will be in version 0.4.0 (as it requires a new version of the yubikey crate).


disable-embedded-helm-controller doesn't seem to be working

Cluster Setup

Kubernetes version: 1.28
Type of Cluster (RKE1, RKE2, k3s, EKS, GKE, AKS, OKE, etc): RKE2
Installation option (Helm Chart / Custom Installation): Helm Chart

If Helm Chart, did you supply any non-default values? If so, what values did you supply:
If Custom Installation, how did you install it (kustomize, k8s manifest, etc.):

Describe the bug
We are installing Prometheus-federator chart and that install helm-project-operator along with it. Since we are using RKE2 cluster, there already exists a CRD Helm chart and project-operator tries to overrides that one. In the documentation we found that adding below will disable HelmChart CRD install and project-operator by enabling argument --disable-embedded-helm-controller:
  helmController:
    # Note: should be disabled for RKE2 clusters since they already run Helm Controller to manage internal Kubernetes components
    enabled: true

But doing so did not help either and we are still getting our RKE2 cluster messed up due to this.
To Reproduce
Try installing prometheus-federator with above setting. It will still install helm-project-operator and override your HelmChart CRD in RKE2.
Result
Expected Result
When HelmController flag is disabled, it should not install helm-project-operator and HelmChart CRD on RKE2 clusters.
Screenshots

Additional context

Hello Team,
Any update on this issue?

Hello Team,
Please see if this can be fixed? We are blocked due to this.
Thanks

@mallardduck @jbiers  Request to please have a look into it..

Hello @mallardduck
Thanks for your response. Yes we are Rancher prime customer and will raise a case to them as well now as you suggested.
Meanwhile, sharing you the requested details below:
Rancher Version: 2.8.5
Federator Version: prometheus-federator-103.0.2+up0.4.0
Also, can you please check, if this really a bug or we are doing something wrong?
Thanks
Sunil Kumar

1. The CRDs are versioned identically yet different
the helm-project-operator ships with
https://github.com/rancher/helm-project-operator/blob/main/crds/crd-helmcharts.yaml
helmcharts.yaml.txt
The CRD shipped by the helm-project-operator (included by prometheus-federator 103.0.2) uses the same group/version (v1) as the RKE2-embedded one, yet they differ.
The RKE2 included one has, amongst others
            repoCAConfigMap:
              nullable: true
              properties:
                name:
                  nullable: true
                  type: string
              type: object

This will break any RKE2 deployment of HelmCharts that use e.g. repoCAConfigMap upon installation of the prometheus-federator>helm-project-operator.
2. CustomResources are always installed thus always overwriting
There is no control in the Helm chart for not installing the CRDs if helmController.enabled=false is set, so they're always installed, overwriting the RKE2 ones

@mallardduck
Do we have any update on this?


tests: Add unit tests for TrustedMetadataSet

Mostly done by #56 but coverage can be improved but is already quite high with around ~90% for that package.

Thanks! 💯


Google map plugin is not working and installing proper giving build error

Hi,
I am using this plugin in my cordova application.
When I try to install the plugin, it is installing google map plugin. previously it was adding the plugin for androidv4 and play service as well.
Due to this I am getting error while building the project. I am using the stable version of google map to install it using below command.
cordova plugin add cordova-plugin-googlemaps --variable API_KEY_FOR_ANDROID="ANDROID_KEY"
ERROR : some resource and image are not found
If  I remove google map plugin then my project is building successfully.
Kindly Provide me the stable link to download the plugin or the version 1.2.5 which was working properly in my project . OR please help if anyone have faced the same problem.

Facing same issue !

Nobody can help without error logs, but I think you are missing Google support and android support sdk. Grab it inside your SDK Manager and recheck the new install progress, as we using framework tags and no support libs anymore

Please find the error log below.

F:\CSM\06.SourceCode\02.Development-PostProd_<IP_ADDRESS>_6Aug14\HDFCERGO.CSMApp\HDF
CERGO.CSMApp\bld\Debug\platforms\android\build\intermediates\exploded-aar\com.go
ogle.android.gms\play-services-base\8.3.0\res\drawable-xhdpi\common_plus_signin_
btn_text_dark_pressed.9.png ERROR: Unable to open PNG file
F:\CSM\06.SourceCode\02.Development-PostProd_<IP_ADDRESS>_6Aug14\HDFCERGO.CSMApp\HDF
CERGO.CSMApp\bld\Debug\platforms\android\build\intermediates\exploded-aar\com.go
ogle.android.gms\play-services-base\8.3.0\res\drawable-xxhdpi\common_google_sign
in_btn_icon_dark_normal.9.png ERROR: Unable to open PNG file
Error: Failed to run command:
C:\Users\rajyagni\AppData\Local\Android\android-sdk\build-tools\23.0.1\a
apt.exe s -i F:\CSM\06.SourceCode\02.Development-PostProd_<IP_ADDRESS>_6Aug14\HDFCER
GO.CSMApp\HDFCERGO.CSMApp\bld\Debug\platforms\android\build\intermediates\explod
ed-aar\com.google.android.gms\play-services-base\8.3.0\res\drawable-mdpi\common_
google_signin_btn_icon_dark_disabled.9.png -o F:\CSM\06.SourceCode\02.Developmen
t-PostProd_<IP_ADDRESS>_6Aug14\HDFCERGO.CSMApp\HDFCERGO.CSMApp\bld\Debug\platforms\a
ndroid\build\intermediates\res\debug\drawable-mdpi-v4\common_google_signin_btn_i
con_dark_disabled.9.png
Error Code:
42
Output:
F:\CSM\06.SourceCode\02.Development-PostProd_<IP_ADDRESS>_6Aug14\HDFCERGO.CS
MApp\HDFCERGO.CSMApp\bld\Debug\platforms\android\build\intermediates\exploded-aa
r\com.google.android.gms\play-services-base\8.3.0\res\drawable-mdpi\common_googl
e_signin_btn_icon_dark_disabled.9.png ERROR: Unable to open PNG file
:mergeDebugResources FAILED
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':mergeDebugResources'.

Error: Failed to run command:
C:\Users\rajyagni\AppData\Local\Android\android-sdk\build-tools\23.0.1\a
apt.exe s -i F:\CSM\06.SourceCode\02.Development-PostProd_<IP_ADDRESS>_6Aug14\HDFCER
GO.CSMApp\HDFCERGO.CSMApp\bld\Debug\platforms\android\build\intermediates\explod
ed-aar\com.google.android.gms\play-services-base\8.3.0\res\drawable-mdpi\common_
google_signin_btn_icon_dark_disabled.9.png -o F:\CSM\06.SourceCode\02.Developmen
t-PostProd_<IP_ADDRESS>_6Aug14\HDFCERGO.CSMApp\HDFCERGO.CSMApp\bld\Debug\platforms\a
ndroid\build\intermediates\res\debug\drawable-mdpi-v4\common_google_signin_btn_i
con_dark_disabled.9.png
Error Code:
42


python310Packages.aesara: 2.8.12 -> 2.9.1, python310Packages.aeppl: 0.1.4 -> 0.1.5

Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

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

4 packages built:

python310Packages.aeppl
python310Packages.aeppl.dist
python310Packages.aesara
python310Packages.aesara.dist


Fixes dependency scope of vendored gson

this saves 240KiB for an unused dep

circleci does parallel tests I think it isn't getting the change to core propagated to collector. since ASF we can't use circleci anyway I'm merging and hoping for the best :P


Handle EGI MFF files with multiple epochs

mne.io.read_raw_egi does not properly process MFF files with multiple epochs. In the worst case, the function returns, but the events are misaligned with respect to the data. In the best case, the function raises an exception as events are created beyond the end of the recording as below. The event start times need to be adjusted to account for any time gaps between the epochs.
 data = mne.io.read_raw_egi('test.mff')
Reading EGI MFF Header from test.mff...
    Reading events ...
---------------------------------------------------------------------------
IndexError                                Traceback (most recent call last)
<ipython-input-2-b23e6b31e949> in <module>()
----> 1 data = mne.io.read_raw_egi('test.mff')

/Users/roh17004/anaconda3/lib/python3.6/site-packages/mne/io/egi/egi.py in read_raw_egi(input_fname, montage, eog, misc, include, exclude, preload, channel_naming, verbose)

/Users/roh17004/anaconda3/lib/python3.6/site-packages/mne/utils.py in verbose(function, *args, **kwargs)
    727         with use_log_level(verbose_level):
    728             return function(*args, **kwargs)
--> 729     return function(*args, **kwargs)
    730
    731

/Users/roh17004/anaconda3/lib/python3.6/site-packages/mne/io/egi/egi.py in read_raw_egi(input_fname, montage, eog, misc, include, exclude, preload, channel_naming, verbose)
    164     if input_fname.endswith('.mff'):
    165         return _read_raw_egi_mff(input_fname, montage, eog, misc, include,
--> 166                                  exclude, preload, channel_naming, verbose)
    167     return RawEGI(input_fname, montage, eog, misc, include, exclude, preload,
    168                   channel_naming, verbose)

/Users/roh17004/anaconda3/lib/python3.6/site-packages/mne/io/egi/egimff.py in _read_raw_egi_mff(input_fname, montage, eog, misc, include, exclude, preload, channel_naming, verbose)

/Users/roh17004/anaconda3/lib/python3.6/site-packages/mne/utils.py in verbose(function, *args, **kwargs)
    727         with use_log_level(verbose_level):
    728             return function(*args, **kwargs)
--> 729     return function(*args, **kwargs)
    730
    731

/Users/roh17004/anaconda3/lib/python3.6/site-packages/mne/io/egi/egimff.py in _read_raw_egi_mff(input_fname, montage, eog, misc, include, exclude, preload, channel_naming, verbose)
    258     """
    259     return RawMff(input_fname, montage, eog, misc, include, exclude,
--> 260                   preload, channel_naming, verbose)
    261
    262

/Users/roh17004/anaconda3/lib/python3.6/site-packages/mne/io/egi/egimff.py in __init__(self, input_fname, montage, eog, misc, include, exclude, preload, channel_naming, verbose)

/Users/roh17004/anaconda3/lib/python3.6/site-packages/mne/utils.py in verbose(function, *args, **kwargs)
    727         with use_log_level(verbose_level):
    728             return function(*args, **kwargs)
--> 729     return function(*args, **kwargs)
    730
    731

/Users/roh17004/anaconda3/lib/python3.6/site-packages/mne/io/egi/egimff.py in __init__(self, input_fname, montage, eog, misc, include, exclude, preload, channel_naming, verbose)
    278
    279         logger.info('    Reading events ...')
--> 280         egi_events, egi_info = _read_events(input_fname, egi_info)
    281         gains = _get_gains(op.join(input_fname, egi_info['info_fname']))
    282         if egi_info['value_range'] != 0 and egi_info['bits'] != 0:

/Users/roh17004/anaconda3/lib/python3.6/site-packages/mne/io/egi/events.py in _read_events(input_fname, info)
     30     for n, event in enumerate(event_codes):
     31         for i in mff_events[event]:
---> 32             events[n][i] = n + 1
     33     return events, info
     34

IndexError: index 413166 is out of bounds for axis 0 with size 413096

duplicate of https://github.com/mne-tools/mne-python/issues/5027 ?

Actually a duplicate of #4759 but not fixed by 261a678.

@rhancockn will you be able to get back to this?

@larsoner Yes, I have a first pass at a fix, but it fails some preload=False test cases. I will take another look at getting this integrated and passing.

In the worst case, the function returns, but the events are misaligned with respect to the data.

Oops, I was not aware of this, I will have to check all my preprocessed files for presence of pauses. I never had an error reading mff files, although I am sure some of them had pauses. My attention was drawn to these issues only because I found that in some recordings I lost a lot of events and noticed that these files had pauses in epochs.xml.

This issue is likely to affect your data if you are using E-prime with ECI events.

On Mar 31, 2019, at 11:08 AM, Mikolaj Magnuski<EMAIL_ADDRESS>wrote:
In the worst case, the function returns, but the events are misaligned with respect to the data.
Oops, I was not aware of this, I will have to check all my preprocessed files for presence of pauses. I never had an error reading mff files, although I am sure some of them had pauses. My attention was drawn to these issues only because I found that in some recordings I lost a lot of events and noticed that these files had pauses in epochs.xml.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I have checked and the issue does affects my data - the events are clearly misaligned with the signal in subjects with pauses (no ERP for example). I was using Psychopy with LPT triggers.

So @mmagnuski should we review+merge this as is, then you (or someone else) make another PR to fix the multiple epoch support?

Yes, I'll just push a cosmetic change to this PR (I have it locally, but I have traumatic memories of pushing to a PR so left it for the evening). Then I would merge as soon as possible and add/fix stuff in subsequent prs. Merging this PR even without a test is much better than having mff reading as it works in master now - small pause at the beginning of the recording removes all time-locked activity without error or warning.

Pushing to a PR turned out to be too much hassle again, I just commented in the PR. I will have to preprocess again one of the files I had problems with and then I would be able to confirm.

@rhancockn are you able to produce a small file (as small as possible that shows the issue) for testing ?

There is a ~4MB file with events in multiple epochs at https://github.com/mne-tools/mne-testing-data/pull/37. I'm not able to generate a smaller file until my University reopens.

Ahh right forgot about that, thanks @rhancockn . That should be good enough for at least developing a solution for people to test in the meantime.


ClearContactTracking() doesn't clear a pooled Hashset before calling Recycle()

https://github.com/leapmotion/UnityModules/blob/ff63f37fd07b4361cb91752b7e2e0bdbae4dee52/Assets/LeapMotion/Modules/InteractionEngine/Scripts/InteractionController.cs#L1498-L1500
The pool class mentions to clean up objects yourself when using types that dont implement IPoolable.
Not calling tempObjs.Clear() here seems to be a mistake?
I'm investigating, because we've been having issues with hands getting stuck in soft contact, but I'm not sure this has anything to do with it.

Yes, if tempObjs is filled with anything, it should be cleared before the recycle.
Generally I Clear before AND after using an object from the Pool so that an error like this minimizes the resulting bugs.

This is under review.

@julienkay The suggested change has been included in the code. Thanks for taking the time to point out the need for this change.


Pagers on help pages are broken.

Added unique query string token to pager to support multiple pagers on a single page.


Reduce impact of channel refreshing

When a channel shuts down and reconnect, the service will throw an UNAVAILABLE or something like it with a "Go Away" message. That happens on a scheduled bases for all long running Channels.
When the shutdown happens and UNAVAILBLE is returned, an RPC retry is triggered.  Since we have a ChannelPool, the RPC will likely be tried on a different channel.  In a low QPS system or large machines (that have a lot of CPUs, and therefore a proportionally larger channel pool), that new channel is likely to also be shut down, and the cycle will start again.  This can happen a few times, which would mean that the total operation time could become large.
Towards that end, add stats and spans that could be sent via OpenCensus's tracing and statistics around the refreshing.  Also, consider a policy other than round-robin for channel selection in these cases.

Couple of thoughts/suggestions:

I think with the current bigtable_client + grpc instrumentation you should see the first RPC client span that fails and then immediately a new RPC client span that succeed. Is that the case?
Do you think an attribute on the RPC client span that tells if the RPC started a new channel connection when executed would help?
Do you have other suggestions?

As far as telemetry is concerned:

We do have traces across RPCs if there was a retry, assuming that we're lucky enough to get traces for those RPCs.
We probably need an annotation for shutdown and reconnects, and stats around connection retries.

This is probably something that grpc-gcp should do, and not something actionable for this repository.


future things to do

overall interface
class interface instead of functional interface
.get_data
.get_model
.get_loss
.get_optimizer
.train --> .train_loop
.train_from_params
default order of calls and some glue
---> issue of how logging is done?
---> or there's the "callable" method

multi-gpu stuff
distribute over nodes
rationalize and simplify the way multi-gpu (within node) of a single model is handled in the base functions
validation w/o creating a new copy of the model?
on a different thread or not?
training multiple models on different GPUs with a common data input setup
--> relieves network congestion

loading
mapping the names for partial loading
combining multiple sources for loading?   (low priority)

misc
actually get the per-variable learning rates and store them
allow the restarting with specifiable/controllable per-variable learning rates
modify the standard optimizer to return a summary of the gradients and log them
make the seed in the standard data provider chooser depend on the saved global batch if you want.
put a less terrible version of the graph abstraction into the standard saver for saving the beginning of training.
convenience loader for stuff saved to GFS
the interface should be nice
it should handle the too-big-to-load in a standard problem
make sure that threads that fail to write to the DB kill the thread by emitting coordinator stop
in general, deal with threads not throwing coordinator stop signals when appropriate
don't allow specifying the cache directory manually
create subfolders in the cache directory every time a new model is run
cache directory loading issues in test_from_prarams (ask Chengxu)

fix bugs
problem with the untar'ing
if cache directory is on the NAS

For bookkeeping purposes and anyone interested in the status of this issue, I am just posting a brief summary of the current plans to address the overall interface and multi-gpu stuff.
Description of requested improvements
For a given tfutils experiment running on a single node, optimize the behavior of get_data, get_model, get_loss, get_learning_rate, get_optimizer, and train with respect to:

evaluating the model in a particular 'phase'/'mode' (e.g. train vs. test/validation)
deploying multiple (potentially different) single-gpu models and/or one multi-gpu model
distributing potentially common dataproviders to all models running on a node
simplifying access to arbitrary graph 'Ops' during an experiment
providing greater control over the innermost training loop

Summary of potential solutions:
First suggested change: To address requests (1) and (4), it was suggested that lines 989 - 1003 in master/tfutils/base.py containing calls to get_model, get_loss, get_learning_rate and get_optimizer should be replaced with a single, user-specified (optional) function (potentially called get_targets) that accepts train_inputs (during training) or vinputs (during validation)provided by a call to get_data and returns the final train_targets dictionary, which, in this case, could be any desired set of valid graph Ops. Users needn't explicitly specify this function since it should default to its current behavior, and if they do, it needn't contain calls to loss or optimizer ops (if users just want to make a simple forward pass, for example).
An additional suggestion was to pass this get_targets function some sort of flag that indicates the experiment's 'phase' or 'mode' (e.g. whether you are in training or testing) that alters the contents of the target dict it returns.
Analysis of first suggested change:
This change is more subtle than it appears.
Initially, it seemed appropriate given the requests it aimed to address. Users would certainly have tight control over which Ops are to be evaluated (since they would have to be manually specified); however, after looking through master/tfutils/tests/test.py, it seemed like this was already a feature of the current tfutils. Both train_params['targets'] and validation_params['targets'] accept a function func whose purpose is to extract and return particular Ops from the model to be evaluated. Thus, this change seemed to only address request (1), and if the underlying motivation for request (1) is to eliminate redundancies between the training and validation routines, then there may be other changes that are better suited for that (e.g. consolidating base.train() and base.test` into one since they have almost identical structure).
It turns out constructing the entire graph from input data to train/val target Ops all at once may help to facilitate requests (2) and (3). It is much easier to share dataproviders and distribute model ops across GPUs in a node when it's done together. Currently, you cannot retrieve the final target ops without accessing both the model_params and train_params/validation_params because the full model definition is stored in the former and the target ops are specified in the latter. In the single-gpu, single-model, single-dataprovider case, calling get_data -> get_model -> get_loss etc. sequentially is doable because get_data instantiates a single provider, which produces a single set of inputs to be fed into a single model for which there is a single function that extracts the appropriate target ops etc.
To call these functions sequentially and independently in the distributed case requires that global information about the configuration of the entire node be passed from one function to the next... This just seems cumbersome and slightly annoying.
Second suggested change:
To address request (5), replace the call to sess.run(train_targets) on line 795 with train_results = train_loop(sess, train_targets), where train_loop is some user-defined callable that describes a custom training loop.
Analysis of second suggested change:
This appears to be a very worthy change and appears in the 'Proposed plan of attack' section below.
Proposed plan of attack:
Package and repurpose get_data get_model, get_loss, and get_optimizer, etc.
The functionality offered by these routines obviously needs to stay, and packaging all of them into a single function call seems to be the most convenient way to also address requests (2) and (3) (i.e., incorporate the distribution of a model or collection of models over the GPUs into tfutils.base.py and appropriately distribute dataproviders to individual models or GPUs to maximize data sharing and reduce network congestion).
Here is an example that demonstrates how this might work:
Step 1:
For each model you are interested in running, write a function that describes the single-gpu graph. This step is the same as before. Note: You needn't specify how this model is distributed across the GPUs in the model function. Instead, specify how they are distributed in the model_params dictionary.
For example, suppose you you would like to train two identical models, say model.mnist_tfutils and model.alexnet_tfutils, each distributed across 2 GPUs. You might specify this configuration like so:
params['model_params'] = {'gpu0': {'func': model.mnist_tfutils},
                          'gpu1': {'func': model.mnist_tfutils},
                          'gpu2': {'func': model.alexnet_tfutils},
                          'gpu3': {'func': model.alexnet_tfutils},
                          }

Or, perhaps like this:
params['model_params'] = {'mnist': {'func': model.mnist_tfutils,
                                    'devices': [0, 1]},
                          'alexnet': {'func': model.alexnet_tfutils,
                                      'devices': [2, 3]},
                          }

Step 2:
Next, specify how data is distributed to each model and each node. TBD: This can be done in many different ways. You can distribute by:

phase (train vs. validation):  all models will share this same dataprovider.
distinct model: all instances of a particular model will share the same dataprovider.
device (gpu): all devices will have separate dataproviders
Some combination of the above

For the sake of the example, imagine you specify by model:
params['train_params'] = {'data_params': {'mnist': {'func': data.MNIST,
                                                    'batch_size': 100,
                                                    'group': 'train',
                                                    'n_threads': 4,
                                                    'devices': [0, 1]},  # Devices 0 and 1 share the MNist provider
                                          'alexnet': {'func': data.ImageNet,
                                                      'batch_size': 100,
                                                      'group': 'train',
                                                      'n_threads': 4,
                                                      'devices': [2, 3]}},  # Devices 2 and 3 share the ImageNet provider
                              'queue_params': {'queue_type': 'fifo',
                                               'batch_size': 100},
                              'num_steps': 500
                              }

The pseudo-code for a private function that distributes models and dataproviders depends heavily on the structure of the dicts above, but it might look something like this:
def _distribute(**params):

    for model in distinct_models:                #  For each distinct model (e.g. model.mnist_tfutils and model.alexnet_tfutils)
        dataprovider = generate_provider(model)  #  Generate a single provider for each model type
        for gpu in model.devices():
            gpu.deploy(model)                    #  Deploy an instance of the model type on this gpu
            dataprovider.assign(gpu)             #  assign the current provider to feed data to the model housed on this gpu

The output of this pipeline should be a final targets_dict (e.g. train_targets) that can be passed to the user-specified, train_loop callable. Since the user is involved in specifying the final targets, he/she can request any Op needed to execute the custom training loop.
Lastly, the custom training loop would be called like so:
        if train_loop is not None:
            train_results = train_loop(sess, train_targets)
        else:
            train_results = sess.run(train_targets)

defaulting to its old behavior if train_loop is left as None.
Concrete example where proposed solution alleviates issues.
 base.get_params()
    sess, queues, dbinterface, valid_targets_dict = base.test_from_params(**params)
    # start queue runners
    coord = tf.train.Coordinator()
    threads = tf.train.start_queue_runners(coord=coord, sess=sess)
    """
    FIRST ISSUE: Getting handles to network parts
        Above, base.test_from_params() is called to retrieve handles on the sess,
        queues, dbinterface and valid_dict_targets, which are then restarted
        for the second time (since they are called once already in base.test_from_params()).

        Below, specific ops and placeholders are extracted from the valid_targets_dict().

    REQUEST:
        "I would prefer not to have to use valid_targets_dict to get handles to
        arbitrary nodes in the graph but specify a separate test function
        for testing (or train function for training) that outputs me a
        dict of the handles I want…"
    SOLUTION:
        By implementing the packaged `get_targets` function, you should be
        able to retrieve all of the ops and placeholders during the innermost
        training loop!
    """
    # Ops
    get_images = valid_targets_dict['valid0']['targets']['img']
    encode = valid_targets_dict['valid0']['targets']['encode']
    run_lstm = valid_targets_dict['valid0']['targets']['run_lstm']
    decode = valid_targets_dict['valid0']['targets']['decode']

    # placeholders
    ph_enc_inp = valid_targets_dict['valid0']['targets']['ph_enc_inp']
    ph_lstm_inp = valid_targets_dict['valid0']['targets']['ph_lstm_inp']
    ph_dec_inp = valid_targets_dict['valid0']['targets']['ph_dec_inp']
    ph_dec_cond = valid_targets_dict['valid0']['targets']['ph_dec_cond']
    # unroll across time
    n_context = 2
    """
    SECOND ISSUE:
        For a single input, sess.run must be called separately multiple times.
        (see below).
    SOLUTION:
        You will be able to implement the routine below in
        train_loop(sess, targets),
        where you can repeatedly call sess.run on the target ops you have
specified in `targets`. train_loop will be called from within
        base.test_from_params, instead of outside like you have here.
    """
    for ex in xrange(valid_targets_dict['valid0']['num_steps']):
        # get input images
        images = sess.run(get_images)[0].astype(np.float32) / 255.0
        context_images = np.zeros(list(images.shape[:-1]) + list([256]))
        # encode context images
        print('Encoding context:')
        for im in trange(n_context, desc='timestep'):
            context_image = np.expand_dims(images[:,im,:,:,:], 1)
            context_images[:,im,:,:,:] = np.squeeze(sess.run(encode,
                    feed_dict={ph_enc_inp: context_image})[0])
        # predict images pixel by pixel, one after another
        print('Generating images pixel by pixel:')
        predicted_images = []
        for im in trange(n_context, images.shape[1], desc='timestep'):
            encoded_images = sess.run(run_lstm,
                    feed_dict={ph_lstm_inp: context_images})[0]
            image = np.zeros(images[:,im,:,:,:].shape)
            image = np.expand_dims(image, 1)
            context = encoded_images[:,im-1,:,:,:]
            context = np.expand_dims(context, 1)
            for i in trange(images.shape[-3], desc='height', leave=False):
                for j in trange(images.shape[-2], desc='width'):
                    #for k in xrange(images.shape[-1]): # predict all channels at once
                        image[:,0,i,j,:] = sess.run(decode,
                                feed_dict={ph_dec_inp: image,
                                    ph_dec_cond: context})[0][:,0,i,j,:]
            context_images[:,im,:,:,:] = np.squeeze(sess.run(encode,
                feed_dict={ph_enc_inp: image})[0])
            predicted_images.append(np.squeeze(image))
        predicted_images = np.stack(predicted_images, axis=1)
        np.save('predicted_images.npy', predicted_images)
        np.save('gt_images.npy', images)

General observations:
In order to better understand how tfutils operates, I generated the 'skeleton' for its primary functions:
def test_from_params():                 def train_from_params():
    tf.Session()                                get_data()
    DBInterface()                               get_model()
    get_valid_targets_dict()                    get_learning_rate()
        get_data()                              get_optimizer()
        get_model()                             get_valid_target_dicts()
        check_model_equivalence()                   get_data()
        get_validation_target()                     get_model()
    DBInterface()                                   check_model_equivalence()
    test()                                          get_validation_targets()
                                                tf.Session()
                                                DBInterface()
                                                train()

def test():                                     def train():
    start_queues()                                  start_queues()
    dbinterface.start_time_step = time.time()       dbinterface.start_time_step = time.time()
    run_target_dict()                               run_target_dict()
        run_targets()                                   run_targets()
            sess.run()                                      sess.run()
            dbinterface.save()                              dbinterface.save()
            online_agg_func()                               online_agg_func()
            agg_func()                                      agg_func()
            dbinterface.sync_with_host()                    dbinterface.sync_with_host()
    stop_queues(sess, queues, coord, threads)       dbinterface.start_time_step = time.time()
    dbinterface.sync_with_host()                    sess.run()
                                                    global_step_eval()
                                                    run_targets_dict()
                                                    dbinterface.save()stop_queues(sess, queues, coord, threads)
                                                    dbinterface.sync_with_host()

My overall impression here is that the change to base.get_targets may be a good opportunity to bundle a lot of base.train and base.test into a single function.


Pull referendum title from referendum title field

The header bar for the referendum should display the referendum title field. Please see below -- this address can be tested using the staging tool.
I believe the tool was configured differently due to how states were providing data in a haphazard way prior to the general election. We are now committed to getting the data properly formatted, so it would be useful to have the tool align with the spec. Thanks!

Updated on staging.

LGTM. Thanks!
Also -- let me know if you'd prefer to close them once you've push these changes to production, or if you'd like me to closed once I review.


cleanup, refactoring, splitted validators, tweaks

hey justin,
i refactored the whole library so its done in a cleaner way.
the main refactoring was the split of validators into separate smaller classes
they all use a common interface
all tests are still passing

It's a bit confusing to have JsonSchema\Validator and JsonSchema\Validator\Validator (I'm surprised this doesn't cause conflicts). I think it would make more sense to rename the latter to Constraint everywhere.

yeah i didnt found a better name, what about BaseValidator?

Thanks @digitalkaoz - these changes look great

You guys are fast! Great stuff! :)
Now we can add JSON-schema validation to composer!


Entity recognition for location

Rasa NLU version:
Name: rasa-nlu
Version: 0.12.3
RASA CORE version:
Name: rasa-core
Version: 0.9.7
Operating system (windows, osx, ...):
RHEL 7.4
Content of model configuration file:
language: "en"
pipeline:

name: "nlp_spacy"
name: "ner_spacy"
name: "tokenizer_spacy"
name: "intent_entity_featurizer_regex"
name: "intent_featurizer_spacy"
name: "ner_crf"
name: "ner_synonyms"
name: "intent_classifier_sklearn"
name: "intent_featurizer_count_vectors"
name: "intent_classifier_tensorflow_embedding"
intent_tokenization_flag: true
intent_split_symbol: "+"

First of all, I have searched for this issue prior and through gitter also. Am raising as an issue here since I couldnt figure it out any where.

I have taken the weather bot demo & trying to get weather for a specified location. It works absolutely fine when I give the location upfront: "Get me the weather in Sydney".

However, when I say "Get me the weather" & the bot asks "Enter the location". The location I entered is not recognized without preposition..... entity is recognized only when I give location as "in Sydney".

Please let me know whether this is issue with RASA Core config.

Hi
This is something we are working on improving for future releases.   Right now the model has no way of knowing that 'Sydney' alone is a city name unless it is defined in the training set as such.
Therefore, it's likely that from the training data, the has model learned that locations often come after prepositions like 'in _' or 'going to _' and may be overfitting to this.
In future releases we will include internal or user-specified lookup tables so that the model will be much better at picking out city names, like 'Sydney', and label them as location entities.  For now I'd assume it's nothing you did wrong.  You could try adding a single Sydney training example labelled as a location entity and see if it works.
Hope it helps

@twhughes ... Thanks for the reply..... here, Sydney is infact present in the training data but once again when data is trained, I give it as "get me weather in sydney" right? so even if I had trained it, while training the story or conversing with the bot through DMM, in the conversation we dont always mention the location and has to be captured separately.
Now having said this, I went through this example of Weatherbot: https://github.com/JustinaPetr/Weatherbot_Tutorial.git where there is also a video tutorial...! In this video, the scenarios is carried out to find the weather in a specific place. The bot had accepted the location without any preposition identifier....
This caused the confusion if there is anything in the Pipeline I need to alter....
Pls let me know...

Just to be clear, did you add a few examples of one-word inputs with city as an entity?  Like:
{
    "text": "Canada",
    "intent": "inform",
    "entities": [
      {
        "start": 0,
        "end": 6,
        "value": "Canada",
        "entity": "location"
      }
    ]
}

for example?   @JustinaPetr said that she included some like this when she did the demo.  Since this is a demo one can expect less ideal performance.   In general usage you should supply your own training data to cover what use cases you expect and the more examples the merrier.

Hey @Sramperu.
Regarding the entities, I agree with Tyler - it's actually quite complicated to train the model so that it would know that 'Sydney' alone is a city name. The only thing that might be different about the weatherbot tutorial and the data you have is that in weatherbot tutorial dataset I actually have a few examples of those one-word city inputs and that's why sometimes (but unfortunately not all the time) it extracts the city without a preposition. So just like Tyler suggested, try adding some examples like this as well.

Hi @twhughes , any update on this please?

@vivekanon No update, sorry.


Add to the "Kitchen Sink" of the Matrix Spec', the ability to "Whisper" in group chat rooms.

This seems to be in debate at the current time, in #matrix:matrix.org .
XMPP even has this.
@matthew:matrix.org a.k.a. @ara4n mentioned that "whispering should be through per-msg ACLs when we get there."

These are my concerns with whispering and what has happened at XMPP and I hope they will be considered in potential specification in order to make Matrix not become less secure considering harassment.

Mikaela hopes whispers won't come or if they do, with clear method for blocking them

people do whisper thing like "what a beautiful woman we have here"...

either do it in public so mods can handle it or give me the ability to prevent receiving the message so it's not word of one person versus word of another person

I proposed this in the aforementioned discussion because it can be useful to send a quick/offtopic message to a subset of users in a channel about something small or only affecting them, especially in high-traffic rooms, without necessarily starting a new discussion. That means it should discourage being easy to have entire whispered/secret conversations in a channel, but still be much easier than creating a new room and inviting users to it (possibly to facilitate the decision of whether a discussion is worth continuing in a new room).
I see two possibilities which came out of the discussion:

Best is probably to make the entire whisper visible to everyone, but hidden by default.
Less ideal is using e2e encryption so that the event is visible but contents are not.

When people send messages that are against the Code of Conduct | Matrix.org, and which is "harmful to the community", or members thereof, it is probably better that they do so privately.  And, with the present state of Matrix; no Moderator who is not also in some encrypted, invite-only room, not in the directory, will be able to do anything about that.  So, it's actually better if it's kept off the communities' "radar", or out of sight.
A bit of logic: Cars (Motorized Vehicles) have been used as weapons.  Should everyone who wants to own a car only be a police or military person?
@thekyriarchy makes good use-case points.  The abuse happens despite the technology.  And in this case, it is better if offensive things are kept out of public rooms.  Regardless, it is a great tool.  Focus on the positive.

I actually disagree with that logic entirely. That logic basically says that harassment and abuse should be swept back under the rug so that only those likely to be harassed will have to deal with them or leave, which ToS, CoC, or other community standards docs exist in part to protect but would now be out of purview.
I should hope a solution where this does not enable harassment to go out of sight at all. If anything, possibly providing a false sense of security for harassers to be weeded out by moderators, but hopefully not that either.

Well, the logic is being used against your suggestion.
Really, it seems like a separate issue, "best practices"/Code of Conduct, et cetera, aside from the usefulness of a feature.
Yes, invite-only rooms can be used to spread messages that are unflattering to certain users.  That doesn't mean invite-only rooms should be eradicated.  Just as cars are very useful, despite the way they can be abused.  The misdeeds do not warrant the eradication of cars, as they serve a greater good.  Electric versus petroleum cars is a separate matter, entirely.
And, it seems the co-founder of Matrix leans towards the concept, if I interpret his comment correctly. "whispering should be through per-msg ACLs when we get there."  It's just a matter of time, with other issues at the front of the queue.

Good, my suggestion should be vetted against that logic.
Technology is never neutral nor separable from the context from which it emerges, the literal functions of its design, the places and ways it is implemented, and the people who use and interact with it.

"Software’s fringe existence seems to corroborate the commonsense notion that it is “intangible” rather than physical, that it is something more like a social convention or rule than machine-thing. The characteristics of software as a material object, as a means of production, as a human-technical hybrid, as a medium of communication, as terrain of political-economic contestation—in short as sociality—seem hard to represent. Software as a material with specificities, singularities, traits, and modes of existence has been displaced by software as mundane application, as infrastructural element in a wider social or technological change (the information revolution, “digital culture,” “new media,” “network society” or “convergence”)."

and

"code can be seen both as a discursive practice — in that is an expressive medium that can shape personal conceptions of the world, […] and a productive apparatus that contributes to the regulation of a biopolitical paradigm (that is, code directly affects the productive capacities of an individual via software programs)"

but academic-speak aside, its nonsensical to assert that the way something works is divorced from how its used. your "cars as weapons" analogy is so reductive and simplistic. there is nobody here who hasn't thought far past that idea. we're talking about the nuances of how different mechanisms and implementations may enable/disable encourage/discourage different types of interaction. so let's stop treating this like yes vs no argument over implementing anything that might be useful vs dangerous and discuss the many different considerations on how it might or might not be done, used, needed, etc.

Yeah, anyway...
FTR, I have reported the two MXIDs' content, in the few messages, starting here.
Others should do the same.

I don't have to vet that call against any "Social Justice Warrior" handbook, either.  The behavior was clearly unacceptable to any observing responsible adult in the room; even "simplistic" me.
I would have filed a report sooner, but my knuckles were dragging on the floor, on my way to begin typing the above, in THIS content stream, which should be focused on the issue at hand.
Now, the link to the first post of the offensive content referenced herein is in the above post.  It is not all that difficult to use Riot-'droid, et cetera, to report content, as that is the proper outlet for such valid complaint.
I can now direct my "simplistic" attention elsewhere!

why would you report @Mikaela in the channel for bringing the issue up and why are you talking about that here? you'd strayed us far enough off topic before, and now you're barely intelligible.

You should NOT pick on  @Mikaela for having brought up that she was offended by those two.  It is not at all noble.  And just "not cool".
It is part of the discussion of this "Whisper" concept, as it happened in #matrix:matrix.org while this was brought up.  Not cool!

That sort of steerage towards Ad Hominem ploys might gain more traction, but for the fact that the above post, absolutely unedited points to the offensive content with an embedded link, here:  https://riot.im/app/#/room/!cURbafjkfsMDVwdRDQ:matrix.org/$14883978042mKsFe:gruenhage.xyz  and both the HomeServer gruenhage.xyz and the HomeServer kolm.io  are NOT the HomeServer of the MXID @Mikaela used there.  What I *reported  was the content that offender her So, for lack of a better cliché, a most disingenuous "Nice try."

NOW  Back to the topic.  Regardless, this is a reference for when a PR might happen.  But, hopefully, from here on, posts/comments will be on topic.  We can only hope.

You should NOT pick on @Mikaela

I realized, hence the quick edit. Why bring that up long after it was corrected?...why link to logical fallacies?...or restate all of that?...and bold all those words/letters?...or—you know what I'll just take the L on this

This thread did not make happy reading this morning.
I am closing, and locking, this issue, and opening https://github.com/vector-im/riot-web/issues/3345 in its place, in which I have attempted to summarise the relevant points from this discussion. Although it might well require support in the matrix protocol, we find it easier to triage feature requests by driving them from the product side; hence the move to riot-web.
A few points, if I may:

Given the huge number of feature requests and issues projects like Matrix/Riot have to deal with, triaging them is made much easier if such requests are short and to the point. Discussions about the definition of a kitchen sink are likely to get your feature ignored in favour of those that don't require us to read a wall of text with erratic formatting.
Those following github issues by email (or matrix notifications) will see the first submission of a github comment. It is at best confusing to discover that a post has since been significantly edited. The edit feature should therefore be used sparingly, if at all. Instead please consider what you have to say carefully before posting.
Please remember that what you write in github issues remains, effectively forever, as a publicly-visible statement of your own attitude. You are also, to some level, representing the project; a new user will not be encouraged to see this sort of conversation. Please also remember that we also seek to be inclusive as a project, and you may find yourself in discussion with people with different backgrounds and opinions. If you find yourself offended, you will do better to ignore or report the offence than to engage with the offender. In short: be respectful of others and seek to de-escalate conflict.


Fix NullReferenceException in GetBytesAsync

fixes #1903
When calling GetBytesAsyns with no timeout no cancellation token source is created. The source value is captured by the async context and is being unconditionally disposed in DisposeCore(). This fix adds a null check before disposal.
Covering test is added.
/cc @NickKerensky

@Wraith2 thanks. Failure is not regarding the changes made in this PR. The intermittent failure that happens is regarding named pipes. Any idea on PR #1880? There are couple of things in that draft, but mainly what is your idea on passing a flag to distinguish between sync and async calls?


Add support for NaniScript

NaniScript is a scenario scripting language used by Naninovel visual novel extension for Unity: https://naninovel.com

Sorry for the ongoing commits; it's ready now.

Thank you for the review! @vladdancer is actually the main contributor here, hopefully he'll be able to provide some feedback on the suggestions. A PR to the fork would be great, thanks!

Quick question: How does escaping in strings work? The doc gives this example:
"Saying \\"Stop the car\\" was a mistake."

But I guess that this isn't how it is supposed to be tokenized:

(Screenshot of the DOM of the website)
So how does it work? It's not mentioned anywhere and the double escaping seems weird to me.

That's a special case here. The value of if operators is treated as expression by default (to save the user from typing curly braces every time) and expressions are evaluated with their own parser after being parsed by the main one, hence the need for double escape: \\" is replaced with \" on the initial parse and then the expression evaluator receive a properly escaped quote.

I see. Since doing this correctly will be quite difficult, let's just leave it as is.

@RunDevelopment thank you for a such great review!
I fixed remain issues and a couple of small improvements, added PR in Elringus repo.

Thank you for contributing @Elringus and @vladdancer!

Thank you for the help and patience with us!

@RunDevelopment Thanks one more time for such great review, it gives me more details about regular expressions!


What about limits

Hi,
I wonder if there is a limit for frontends and backends for a single installation.
My goal is to organize something around 400 backend containers and more than 100'000 frontend domain names (may be more).
Can I do such thing with Traefik ?
Do I need specific hardware (memory / cpu) to do the job ?
I can't find any limit page in the documentation
Many thanks

Thanks for your interest in Traefik !
Every question in the issues means features less 😉.
The issue tracker is for reporting bugs and feature requests only.
For end-user related support questions, refer to one of the following:

Stack Overflow using the "traefik" tag
the Traefik community Slack channel

It is very difficult to define limits:

the project changes very quickly
it depends on qps and the size of queries
it depends on middlewares (auth, redirect, retry, ...)
it depends on the providers (Docker, k8s, Mesos, ...) and the number of providers that you use
it depends on the number of backends and frontends
it depends on the hardware
benchmarks rarely give realistic data and are very difficult to maintain

I hope you better understand the absence of a page on limitations.
FYI: The previous answer and labels were set by a bot using one of my GH tokens. (now the bot has this own GH token)

@smalot  I'm in a similiar situation as you: I'll have maybe 1 000 or 10 000 frontend hostnames (only one or maybe a few backends though).
How did things work out for you? Did you run into any limits? How many frontend hostnames do you have currently? (if I may ask)  Did you re-post this question elsewhere? (then I'd like to go there and have a look :-)  )
@ldez  I'm interpreting what you wrote as that there aren't any known restrictions (say, a hardcoded list that can grow to at most 1 000 items). Instead, if the server load caused by each separate frontend / hostname, is low (in comparison to the server's hardware), then, I can have really many frontends and hostnames.

(I had posted a question at SO already before I found this topic here in GitHub:  https://stackoverflow.com/questions/53994690/any-number-of-hostnames-limit-for-traefiks-rule-hosthostname1-name2  )

Did you find something to workaround traefik's limits?  It's very easy to test and prove that traefik has a very hard-set max limit on frontends/backends.  Simply start traefik configured to dynamically add frontends and backends based on container labels, then start spinning up containers behind it.  The first 115 or so will work perfectly, you'll see both frontends and backends created and listed in the dashboard.  But you'll soon hit a magic limit where all containers added will 404 (just using the basic nginx container), no frontend gets created and no backend either.  The services are all present and running in the swarm, but traefik is overwhelmed and can't create any more entries.
If you then restart traefik, you find it's completely unable to start.  It will hang forever, swarm will show its desired state as "running" but its current state is stuck at "New", where it will remain for 15+ minutes until you give up and kill the whole stack.  You can get it to start by pruning your nginx containers, but it will die again when you re-add them.
TLDR: A very easy test proves that traefik definitely has hard and fast limits of around 115-120 frontend/backend pairs and going beyond that kills it entirely.
So, what did you commenters above end up using?  We're needing to reevaluate load balancer choices since traefik definitely can't handle nearly 1,200 frontends each with a distinct backend.

@marker Thank you for your comment 😃
I don't know where to start...
Of course, there is no limitation hard-coded nor configured intp Traefik on the maximum frontends/backends it can handle. I don't see any good reason why we would have done this. The code can easily be reviewed by anyone to check this, as it is open sourced. And yes, it is reviewed by many people all the time.
We did some benchmark tests and we have been able to route to more than 100k frontends.
Hitting limitations does not imply that things are hard coded somewhere. For example, you can reach limits because you deployed more containers on your server it can handle. Or maybe your issue is due to a real bug with our Swarm provider implementation! One thing is sure, it is obviously too early to draw any conclusions on your issue. I invite you to contact us on Slack and give more details on your configuration.


Circular interpolation

This one is not ready for merge, but I would like some inputs.
The idea: we can do linear or elliptic interpolation in cartesian space, so that the trajectory of the end effector is known, unlike with goto_joints or goto_from_matrix (interpolations are in joint space for both).
We can call reachy.r_arm.send_cartesian_interpolation(target_pose, duration) to do so, with by default a linear interpolation.
Using reachy.r_arm.send_cartesian_interpolation(target_pose, duration, circular_interpolation=True, arc_direction='below') makes a circular interpolation and chooses the arc in -z direction normal to the vector current/target pose. arc_direction can be : below, above, right, left, front or back. (if the arc has no solution, does linear interpolation instead)
Last option is the secondary_radius, which makes possible elliptic interpolation, deciding how far the end effector is going from the linear interpolation. Can be customized with: reachy.r_arm.send_cartesian_interpolation(target_pose, duration, circular_interpolation, arc_direction='below', secondary_radius=0.05)
Also tests are quite difficult to read and write ....

@apirrone send_cartesian_interpolation() is already blocking, as it doesn't work like gotos


GH-40577: [C++] Ensure pkg-config flags include -ldl for static builds

Rationale for this change
When linking statically, pkg-config doesn't pick up the new dependency on libdl introduced by https://github.com/apache/arrow/pull/39067
This produces unresolved symbol errors

What changes are included in this PR?
Addition of -ldl to ARROW_PC_LIBS_PRIVATE to ensure linkage to the necessary library

Are these changes tested?
yes

Are there any user-facing changes?
no

GitHub Issue: #40577

@github-actions crossbow submit example-cpp-minimal-build-static*


conv_bias_relu fusion slows down inception_v3 batch size of 2

inception v3 batch size of 2 has about 2X slow -down with fusion.  I discovered this while I was working on stream-scheduling task and had to temporarily disable fusion.
To get the .onnx file, use Mev's instructions:
https://github.com/mvermeulen/migraphx_onnx
In specific, I used the following script to create .onnx file.
import torch
import torchvision.models as models
batch_size = 2
inception = models.inception_v3(pretrained=True)
inception.eval()
torch.onnx.export(inception, torch.randn(batch_size,3,299,299), "inception.onnx")

Not sure on the causes, but using HCC_PROFILE=2 and then rpt on perf_onnx (minus the compile step and minus the individual instruction timing); suggests that there might also be a "mis-tuned" situation for batch size 2 relative to batch size 4.
I've attached files but item that stands out is the kernel "gcnAsmConv1x1U" which takes 12x longer in batch size 2 than in batch size 4 - and hence dominates 60% of the batch size 2 time and is only 10% of the batch size 4 time.
inceptionv3i4.txt
inceptionv3i2.txt
Running a MIOPEN_FIND_ENFORCE=3 tuning on the batch size 2 to see if this speeds up this case.

After tuning, with MIOPEN_FIND_ENFORCE, the speed for inceptionv3 batch size goes from 55 images/sec to 177 images/sec.
This now fits between batch size 1 (164 images/sec) and batch size 4 (222 images/sec), but will also try tuning inceptionv3 to see if that also speeds up.
The tuning added the following entries on my Vega64 system
'''
48-35-35-5x5-64-35-35-2-2x2-1x1-1x1-0-NCHW-FP32-F=ConvOclDirectFwd:16,16,16,32,1,2,4,4,2;ConvOclDirectFwdFused:8,32,16,32,2,1,4,4,2
192-35-35-1x1-32-35-35-2-0x0-1x1-1x1-0-NCHW-FP32-F=ConvActivAsm1x1U:1,16,1,16,1,4;ConvAsm1x1U:1,8,1,16,1,4,2,1;ConvOclDirectFwd1x1:1,
64,1,1,1,1,16,2048,0
256-35-35-1x1-64-35-35-2-0x0-1x1-1x1-0-NCHW-FP32-F=ConvActivAsm1x1U:1,16,1,32,1,4;ConvAsm1x1U:1,8,1,32,1,4,2,1;ConvOclDirectFwd1x1:1,
64,1,1,1,1,16,2048,0
256-35-35-1x1-48-35-35-2-0x0-1x1-1x1-0-NCHW-FP32-F=ConvActivAsm1x1U:1,16,1,32,1,4;ConvAsm1x1U:1,8,1,32,1,4,2,1;ConvOclDirectFwd1x1:1,
64,1,1,1,0,32,64,0
288-35-35-1x1-64-35-35-2-0x0-1x1-1x1-0-NCHW-FP32-F=ConvActivAsm1x1U:1,16,1,32,1,4;ConvAsm1x1U:1,8,1,32,1,4,2,1;ConvOclDirectFwd1x1:1,
64,1,1,1,1,16,64,0
288-35-35-1x1-48-35-35-2-0x0-1x1-1x1-0-NCHW-FP32-F=ConvActivAsm1x1U:1,16,1,32,1,4;ConvAsm1x1U:1,8,1,64,1,4,2,1;ConvOclDirectFwd1x1:1,
64,1,1,1,1,32,64,0
288-35-35-3x3-384-17-17-2-0x0-2x2-1x1-0-NCHW-FP32-F=ConvOclDirectFwd:32,8,32,32,1,4,4,1,1
96-35-35-3x3-96-17-17-2-0x0-2x2-1x1-0-NCHW-FP32-F=ConvOclDirectFwd:32,8,32,32,1,4,2,1,2
768-17-17-1x1-192-17-17-2-0x0-1x1-1x1-0-NCHW-FP32-F=ConvAsm1x1U:2,8,2,32,1,4,4,2;ConvOclDirectFwd1x1:1,64,1,1,1,4,16,128,0
768-17-17-1x1-128-17-17-2-0x0-1x1-1x1-0-NCHW-FP32-F=ConvAsm1x1U:2,8,2,32,1,4,4,1;ConvOclDirectFwd1x1:1,64,1,1,1,0,16,128,0
768-17-17-1x1-160-17-17-2-0x0-1x1-1x1-0-NCHW-FP32-F=ConvAsm1x1U:2,8,2,32,1,4,4,2;ConvOclDirectFwd1x1:1,64,1,1,1,4,16,128,0
192-17-17-3x3-320-8-8-2-0x0-2x2-1x1-0-NCHW-FP32-F=ConvOclDirectFwd:8,8,8,8,1,1,1,4,2
192-17-17-3x3-192-8-8-2-0x0-2x2-1x1-0-NCHW-FP32-F=ConvOclDirectFwd:8,8,8,8,1,1,1,4,2
1280-8-8-1x1-320-8-8-2-0x0-1x1-1x1-0-NCHW-FP32-F=ConvAsm1x1U:1,8,1,64,1,4,4,1;ConvOclDirectFwd1x1:1,64,1,1,1,4,16,128,0
1280-8-8-1x1-384-8-8-2-0x0-1x1-1x1-0-NCHW-FP32-F=ConvAsm1x1U:1,8,1,64,1,4,4,1;ConvOclDirectFwd1x1:1,64,1,1,1,4,16,128,0
1280-8-8-1x1-448-8-8-2-0x0-1x1-1x1-0-NCHW-FP32-F=ConvAsm1x1U:1,8,1,64,1,4,4,1;ConvOclDirectFwd1x1:1,64,1,1,1,0,16,128,0
1280-8-8-1x1-192-8-8-2-0x0-1x1-1x1-0-NCHW-FP32-F=ConvAsm1x1U:1,8,1,64,1,2,4,1;ConvOclDirectFwd1x1:1,64,1,1,1,1,16,128,0
2048-8-8-1x1-320-8-8-2-0x0-1x1-1x1-0-NCHW-FP32-F=ConvAsm1x1U:1,8,1,32,1,4,4,2;ConvOclDirectFwd1x1:1,64,1,1,1,4,16,128,0
2048-8-8-1x1-384-8-8-2-0x0-1x1-1x1-0-NCHW-FP32-F=ConvAsm1x1U:1,8,2,16,1,2,4,1;ConvOclDirectFwd1x1:1,64,1,1,1,4,16,128,0
2048-8-8-1x1-448-8-8-2-0x0-1x1-1x1-0-NCHW-FP32-F=ConvAsm1x1U:1,8,2,16,1,4,4,1;ConvOclDirectFwd1x1:1,64,1,1,1,1,16,128,0
2048-8-8-1x1-192-8-8-2-0x0-1x1-1x1-0-NCHW-FP32-F=ConvAsm1x1U:1,8,1,16,1,4,4,1;ConvOclDirectFwd1x1:1,64,1,1,1,1,16,128,0
'''

Further investigation shows that batch size 2 was missing for both inceptionv3 and inceptionv4 and that MIOpen is tuned for other batch sizes.  The increase in performance when fusion is disabled, may likely be an artifact of untuned kernels.

Tuning, closing.


Shutters don't close fully

I have venetian blinds (Hella) connected to HASS. When I use the down button on your card, the blind closes fully. When I pull it down on the graphic part of the card, it closes fully and then it opens slightly and goes to 3%. Why doesn't it stay at 0%?

Feature added with Pull Request #69


Use Prettier to Auto-Format the Code

This is a very opinionated PR; while it includes the changes from #14, its main contribution is the set-up and initial run of the opinionated code formatter Prettier. While this is an arbitrary choice — as is Prettier's default configuration — I would highly suggest you offer some configuration with a corresponding tool in order to have consistent PRs and reduce merge-conflicts from people with different auto-formatters in their IDE. This here would be my suggestion on how this could be.
One more little thing that it includes: in index.html, there seems to be an unclosed <div> and in turn a closing </article> without the corresponding opening tag — this would be fixed with this PR, too.
Thanks anyway!

@GenieTim Thanks for this. Code standards are good! I appreciate the contribution.
Please don't take my lack of reply as me not being interested. I've just not used Prettier before and want to figure out what this is doing before I merge it.

@rosswintle I am sorry, it seems that checkbox does not exist as I accidentally seemed to have forked the repo as an organisation.
See https://github.com/isaacs/github/issues/1681 and https://github.community/t/how-can-we-enable-allow-edits-from-maintainers-by-default/2847/8 and https://github.com/whatwg/html/pull/3881#issuecomment-668467097 as to why I think this is the case.
Would it help if I gave you maintainer access to my fork? Or shall I push and PR again from a private fork?

This will be fixed by #18 which has had the main branch merged in.


Clinicjs profiler docker

I add clinic.js for profiler, i verify in docker-compose if need some modification but just add in dockerfile and will be install in container,
after need configuration in helm chart why because we need when we have some problems all the tools of clinic.js launch to retrieve all metric and information need to know where the problem is coming  and we gains the time to fix error

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.2 out of 3 committers have signed the CLA.:white_check_mark: ClaudeROSSI:white_check_mark: Ramzay:x: AdilMektoubYou have signed the CLA already but the status is still pending? Let us recheck it.


'Go To Repository' links just to Artemis Homepage in Update Manual Result

Describe the bug

When you want to update the assesment of a programming exercise you have already assesed, the 'Go To Repository' Link just links to the Artemis Homepage but not to the repository any more.
To Reproduce

Evalute a programming exercise for the first time (go to repository works)
Finish it and open it again to reevalute (go to repository link is broken)

Expected behavior

Link should link to repository
Screenshots

Environment

 - OS: [e.g. iOS]
 - Browser [e.g. chrome, safari]
 - Version [e.g. 22]

Additional context

Output in Web Console

  [REPLACE THIS WITH YOUR INFORMATION]

I just found out that it sometimes loads the url and sometimes does not. I have to reload the whole page and try again and then sometimes the link works to the repository. Maybe some issue with asynchronous loading?

we have re-implemented this feature and it should work now.
@fde312 if this is still an issue, please fix it


Error (1):[Errno 2] No such file or directory: 'esformatter'

I receive the following error upon formatting: "Error (1):[Errno 2] No such file or directory: 'esformatter'. "

EsFormatter is installed here: "~/.npm-packages/lib/node_modules."
I am using the default ruleset: https://github.com/millermedeiros/esformatter/blob/master/lib/preset/default.json.
Sublime build 3114.

is that path in your PATH? can you run esformatter --version from the terminal? Which OS are you using?

is that path in your PATH?

Yes.

can you run esformatter --version from the terminal?

esformatter v0.9.5

Which OS are you using?

OS X 10.11.5

Are you using nvm? I had problems with it, I didn't really need it so I removed it.

No, Node is at /usr/local/bin,

Could you paste here your EsFormatter.sublime-settings ?

EsFormatter.sublime-settings
{
"format_on_save": false,
 "esformatter_path": "/Users/cbloodworth/.npm-packages/lib/node_modules/esformatter/bin/esformatter",
    "esformatter_config_file": ["/Users/cbloodworth/.esformatter"]
}
If I change esformatter_path to null, I get "It looks like esformatter is not installed...".
$PATH
/Users/cbloodworth/.npm-packages/bin:/opt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/opt/fzf/bin:/Users/cbloodworth/n/bin
Node version is 6.2.1. I've also tried 6.0.0.

I think you need to keep it to null as you have esformatter installed globally.
I'm on ubuntu but maybe the plugin works differently on OS X? The version 2.0.0 of this plugin doesn't handle unix paths (with /). Piuccio merged my PR to fix this.
Maybe you could try to update the package to the version 2.0.1? I don't know if npm is already up-to-date so you might have to do it manually.

I just updated. 2.0.1 fixed this :)

I'm afraid this issue has returned. I can't think of anything that has changed, apart from restarting Sublime.

That's strange, can you double check the version of the plug-in installed? Maybe restarting sublime did something to the config...
Did you try to restart sublime or maybe delete the cache?

It is strange. I checked and I'm on 2.0.1. I also cleared Sublime's Packages directory and reinstalled everything, as well as restarted Sublime a few times, but the issue persists.

I think there is a few other places in the plugin that need to be changed to support UNIX paths.
Maybe you could fix them and submit a PR? This way https://github.com/piuccio/sublime-esformatter/commit/e094749aff59850787029047bca588d31f2a318d
This could fix your problem... I can't reproduce the problem on Linux so I don't know what else you could try apart from this.


Passthrough all subtitles present, no main audio reencode.

Hopefully this is the direction you were headed. I know these are based off my personal preferences and may not completely match. The added audio track, and subtitles were important sticking points to me. With these changed I feel I can actually start doing my whole collection without having to go back and redo them later. This branch will also merge and work with #3, which is how I have been testing it. I moved it to its own branch in order to keep the pulls separate.
Added --single to stop reencoding the main AC3 as AAC. I do not feel that it is necessary to recreate the 5.1 audio as stereo within the transcode, media players can handle it on the fly. This seems to shave almost 1GB from the about 100MB file size, as well as some time. Not a huge deal, but it does help.
Changed code to passthrough all subtitles which are present in the mkv. This means there is no need to intelligently decide what subtitles are wanted in the program. Whichever subtitles are ripped will end up in the final mkv exactly as they show up in the original. The regex does allow for some language filtering later if that is a direction that is interesting. It would require more configuration and be slightly less turnkey though. I am leaning towards allow the user to decide while ripping it.
Added --no-auto-burn because I think it is better to leave the subtitles as text. They are now passed through so they still have the 'forced' tag for whatever media player you use to display them. This may still need more testing, my two test movies have not had any forced.

I'd move the --single and --no-auto-burn options to the TRANSCODE_OPTIONS variable where all the constant options are. Other than that, this patch seems find from a technical side.
I'd like to get @notthatwillsmith to provide feedback on the subtitle changes. He knows more about it than I do.

Yeah, would make sense to move those to TRANSCODE_OPTIONS now that I see it. I was concentrating on that section and did not reread what that was for.
Looking in those options, I would consider removing the --find-forced add if the decision to go with passing all subtitles through is made. Not sure if it will cause a conflict, but would seem unnecessary.

Was out of town, and let it transcode a bunch of discs while I was gone. Did a great job with the video and stayed up the whole time.
Seems I like all of the subtitle tracks make it through, but contain no text, so I will need to investigate this tomorrow and see what is going wrong with this method.

Thanks for following up on this.

It actually appears to be something specific to the transcode and Media Player Classic. DirectVobSub seems to be doing something weird with them. The subtitles work on original mkv, but do not after the transcode. They do however work in VLC and Plex after the transcode, which is really weird. It seems to be more of an issue with settings in MPC than the transcoder.
Will still keep investigating, as I would prefer they work in everything, but not sure where the bug lies. I may actually try and transcode one in handbake manually to see what settings it take there, and then translate it back to the script.

Not sure the best route forward on this. The subtitles work in MPC before transcoding, but even running default handbreak on them makes them stop working. That makes me thing it is some sort of incompatibility between the two. The subtitles work just fine with this method in VLC and Plex, so I think it is an acceptable solution. If that is the case then it is just a question of if passing through all the subtitles is the way the project wants to go. Definitely interested in hearing other people's opinions on it.

I like the idea of having all the subtitles passed through and not burned (or at least as an option). I'm ripping anime DVDs right now and would like to be able to have subtitles optional since it will depend on the language track I use.

I have been using my branch for a while now about 60 movies or so, and have had no additional issues. Works great with Plex at least. There is just the confusion with MPC.
I have been doing the same thing with a few dual language animes as well. Seems to work. If you try it out let me know if you find any issues. I also just feel the subtitles look crisper / cleaner not being burned in.
I am contemplating ideas for options that get passed through to the transcoder, but have to be careful with settings, and newlines and things. That is for another discussion though.

I almost exclusively play videos through Plex these days so that's not a problem.
That's good to hear. I'm having some issues getting the VM to mount my folder/create the transcoder folders but that's better suited for the Tested forum if I can't get it to work later.
Agreed, I feel that subtitles look better when not burned in, though with movies that have the forced subtitles for certain scenes I could see the burn-in being useful.


Any plans to support ASP.NET Web Api 2.2?

The dependency constraint of >= 5.1.2 && < 5.2 on these NuGet packages prevents use of WebApi.Hal from being added to projects setup with Web Api 2.2 package already added.
Thanks

closing stale issue


Propose transitioning KServe project from LFAI to CNCF

KServe is a community driven open source project, aiming to deliver a cloud-native, scalable, extensible serverless ML inference platform. It provides an open standard control and data plane for serving production ML models including Scikit-learn, Tensorflow, PyTorch and large language models(LLMs).
Since its inception in 2019, previously known as KFServing under Kubeflow, the KServe project has gained significant traction with support from leading industry players such as Bloomberg, IBM, RedHat, Intuit, SAP, AliCloud. It has fostered a diverse and inclusive community including both end users and cloud vendors. Embracing an open governance model, KServe has established a clear process for promoting reviewers and approvers, ensuring transparency and fairness in decision-making.
KServe plays a vital role for deploying the trained models to production to realize the business values in enabling the end to end ML lifecycle, including model development, training and pipeline. With the rise of LLMs, the need for scalable and cost-effective serving solutions like KServe has become increasingly evident.
Given the recent incubation of Kubeflow within CNCF,  the collaborative efforts with CNCF Cloud Native AI working group as well as the community asks, the KServe community propose transitioning the KServe project from LFAI to CNCF.  We are using issue to initiate the voting process.
Dan Sun on behalf of the KServe community

/vote

In favor

What does transitioning to CNCF mean in practice, ie., how does it impact governance, adopters and potential adopters? Whatever be the case, looking forward to keep participating and engaging with the awesome KServe community!

/check-vote

/check-vote

In favor 👍

/check-vote

/check-vote

/check-vote

The proposal for moving KServe to CNCF was submitted to CNCF TOC: https://github.com/cncf/toc/pull/1353

Here's the new link to the proposal to follow the new template from CNCF TOC: https://github.com/cncf/toc/issues/1367


Bar location incorrect when chat is collapsed

When the chat is collapsed, the bar is on top of the text. Would be nice if it was a bit higher

Okay interesting, thanks for pointing this out - this occurs when "Transparent chatbox" is checked in the Resizable category of the Interfaces panel in Settings. As a temporary workaround, you can uncheck this box if the bar is more important than the transparency, but I will work on a fix for this!

Thank you for the workaround. Will use that in the meantime!


Dark theme download page does not exists

Describe the problem and steps to reproduce it:
(Please include as many details as possible.)
Dark theme download page does not exists.
What happened?
Download not works from the "add to thunderbird" button in "https://addons.thunderbird.net/en-US/thunderbird/addon/macos-sierra-dark/" responding "We're sorry, but we can't find what you're looking for."
What did you expect to happen?
Theme download
Anything else we should know?
(Please include a link to the page, screenshots and any relevant files.)

Most themes(lightweight themes) cannot be downloaded, they must be installed from within Thunderbird. This currently requires Thunderbird 60.
See: https://github.com/thundernest/addons-server/issues/19#issuecomment-411897770


Clarification Needed on max_tokens Value

Hello,
Firstly, I noticed a discrepancy in the max_tokens value—15 in the source code versus 175 in the documentation examples. Could you advise on how this value is derived?
Thank you for your support.

Hi,
The max tokens parameter does not affect the functionality of the package, it is used to calculate the number of the tokens of the prompt, this algorithm was taken from a notebook that was published earlier by OpenAI.
It depends on how much you expect the output to be.
Please note that I didn't update the package for months, and it may be that OpenAI changed the way how this is calculated but the package can still be helpful to limit the request but not precisely.
So I suggest you test if the package is behaving like you are expecting first :)

Hi,
The max tokens parameter does not affect the functionality of the package, it is used to calculate the number of the tokens of the request, this algorithm was taken from a notebook that was published earlier by OpenAI. It depends on how much you expect the output to be.
Please note that I didn't update the package for months, and it may be that OpenAI changed the way how this is calculated but the package can still be helpful to limit the request but not precisely.
So I suggest you test if the package is behaving like you are expecting first :)

I see, so from what I understand max_tokens is basically "guess how many output tokens the model will generate and this will count towards the token limit".
So for example, if OpenAI is limited to 200 output tokens, then setting max_tokens to 200 would account for the worst possible case.
If the generation is non-streaming, then ideally that value (200) would be replaced in the limiter with the actual output token count, I suppose
Either way, thanks for the library, provides a quick way to get started 👍 🚀

I see that the code implements a cooldown mechanism. If the rate limit is exceeded, it enforces a pause (cooldown) for the entire duration of the fixed window before attempting to process further requests.
I see that you're using Redis incrby

This means that without even changing the code, this should theoretically work

Reserve some amount of tokens (e.g. average output consumption, or 99th percentile of usual responses etc., if max_tokens is not specifically set)
Get completion and calculate actual consumption
Reserve actual - reserved amount of tokens. If the value is positive then additional tokens are taken into account. If the value is negative, then unused tokens are freed.

E.g. (a very rough hacky example)
reserved_tokens = 300
with limiter.limit(messages=..., max_tokens=reserved_tokens)
    response = ... # make request

# Adjust reserved tokens based on actual consumption
actual_output_tokens = calc_output_tokens(response)
adjustment = actual_output_tokens-reserved_tokens
with limiter.limit(messages=[""], max_tokens=adjustment)
    pass

A cleaner solution would potentially use aexit to adjust limiter based on actual consumption
--
just a few raw thoughts regarding the limiter 👍

I will add this for future reference. The following code seems to work great so far, it only adjusts the actual consumption value if it didn't expire yet (as a transaction to avoid race conditions).
reserved_tokens = 300

...

with limiter.limit(messages=..., max_tokens=reserved_tokens)
    response = ... # make request
result = response.choices[0].message.content

actual_tokens = len(tiktoken.get_encoding("cl100k_base").encode(result))
adjustment = actual_tokens - RESERVED_OUTPUT_TOKEN_COUNT
used_tokens = await self.incr_if_exists(adjustment)

  async def incr_if_exists(self, adjustment: int) -> str:
      lua_script = """
      if redis.call('exists', KEYS[1]) == 1 then
          return redis.call('incrby', KEYS[1], ARGV[1])
      else
          return nil
      end
      """
      key = f"{limiter.model_name}_api_tokens"
      adjustment_value = adjustment
      return await self._limiter.redis.eval(
          lua_script, 1, key, str(adjustment_value)
      )  # type: ignore


Responsive Pagination

Pagination component is not responsive. Pages get cut in mobile devices.

You can check in live demo.

@tarzanking @jsinhSolanki
I had the same problem but I solved it by adding a div  container to vs-pagination .
For example,
from
<vs-pagination v-model="page" :length="reviews.last_page" class="mt-8 mb-4"/>

to
<div class="flex flex-col items-center">
     <vs-pagination v-model="page" :length="reviews.last_page" class="mt-8 mb-4"/>
</div>

The reason of this could solve the problem is because the active page button uses absolute position.
Hope this helps.


Improve plugin description

The description that shows in the client when you search for dink or webhook or notification is:
A notifier for sending webhooks to Discord or other custom destinations
Since the description can only fit very few words, I think we can come up with something better that more accurately describes what the plugin does.

Universal discord webhook/API notifications with additional JSON?
I think it's important to include key words like Discord, notifications, webhook and API, at least from a developer stand point webhook and API are what I would search for.
Hopefully this increases exposure as originally I didn't come across your plug-in until referred by iProdigy from another notifier plugin.

Universal discord webhook/API notifications with additional JSON?
I think it's important to include key words like Discord, notifications, webhook and API, at least from a developer stand point webhook and API are what I would search for.
Hopefully this increases exposure as originally I didn't come across your plug-in until referred by iProdigy from another notifier plugin.

I disagree partly with this, I feel like plugin hub tags could serve this purpose, as the majority of people using this plugin are not developers. People already don't look at plugin descriptions, if they see stuff like API and JSON in the description, they just don't know what you are on about.
The name already puts the plugin in a disadvantage way down the list, among the dozens of abandoned discord notifier plugins, the next visible part when you search something is the description, so it should be clear as day what the plugin does to the average user.

how about: Discord-compatible webhooks for Loot, Death, Levels, CLog, KC, Pets, Diary, Quests, etc.


Accessing current vue instance in validators object

Is there a way so we can access the vue instance inside a validator?

Validator is call in the context of current vue instance, so you can use this to access it.

I used the normal function instead of ES6's arrow function and it worked. Thanks for the lead.


Filter properties are not respected

Part of my filter is set like this
      EC2InternetGatewayAttachment:
      - property: "vpc:OwnerID"
        value: "123456789"
      EC2RouteTable:
      - property: "OwnerID"
        value: "123456789"
      EC2DHCPOption:
      - property: "OwnerID"
        type: "regex"
        value: "(123456789|987654321)"

The account has resources with Owner ID that match the filter. The original nuke had those filtered out. The fork still goes

us-west-2 - EC2InternetGatewayAttachment - igw-03be1339519e46fa9 -> vpc-0debf6fec89321668 - [DefaultVPC: "false"] - would remove
us-west-2 - EC2DHCPOption - dopt-0c578847d991d4df5 - [DefaultVPC: "false"] - would remove
us-west-2 - EC2RouteTable - rtb-0d7b4aa83ad8d4a37 - [DefaultVPC: "false", vpcID: "vpc-0debf6fec89321668"] - would remove

Would it be possible to have those filtered out? Not sure if there're other resources with the same issue, but these 3 definetely have it.

I don't see property vpc:OwnerID or OwnerID on any of the output there.

I found the issue, looks like the original nuke was patched at some point and I missed it to add OwnerID, let me see if I can snag that.

I'll have to spend some time comparing properties between the two and see what's different, not sure how I missed that. I'll fix it this evening, I can't do it right now. You'll get a notice here when it's fixed.

I really appreciate the effort you're putting into this. Thanks!

Absolutely, I want the tool to be useful and easier to maintain and build, that's why I broke away.

:tada: This issue has been resolved in version 3.0.0-beta.34 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 3.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


AQCU-1248: parameters passed into gsplot v 8 changed for error_bar

And we didn't update uvhydro to reflect that. Changed now, and now error bars appear again.

Need some tests updated too, so this may error. Working on those. FYI @dpattermann-usgs

When the tests pass, it looks good to me.

Coverage remained the same at 98.922% when pulling ed2d38c607a0424045d7b08f2d8fb31f4d8a1c8e on mhines-usgs:AQCU-1248 into 4c1fadb76b46ce74fbc5fcadc7d94b9adda8e924 on USGS-R:master.


typo cleanup

Ran cSpell across the code base. I lumped this into one PR, but it could be split into individual ones if prefferred.
I also avoided anything that had public access so it shouldn't include breaking changes. There were a few of those, that'll I'll submit separately if this lands.

Really appreciate the fix.  Mind rebase to one commit to keep it clean.   We can rebase ourselves as well if you prefer.

@suwatch I think it's better that you squash/merge if that's your process. I'd like to keep it separate to make it easier to split up or remove particular changes if requested during the review

Oh, I think you pulled this in through 787c893a9336beb498252bb2f90a06a95763f9e9 so I'll close this


[Discussion] Azure Functions Runtime 2.0.12134

Discussion for https://github.com/Azure/app-service-announcements/issues/141

This runtime version is relying on Webjobs 3.0.1 based on relase notes but it seems to not be available on NuGet yet.
Can you publish it so everyone can benefit the fixes it contains?

@ggirard07 those will be published by the end of the week.

Is there a way to roll back to a prior runtime?  Otherwise I can’t do anything until next week.

@Jeremywhiteley there are no breaking changes or behavior differences with that update. This is fully backwards compatible and should not cause any issues with existing apps.
You can roll back to the previous version by setting the FUNCTIONS_EXTENSION_VERSION to 2.0.12115, but if you can share your function app name (or the information requested when you create an issue here, we can take a look at your app to investigate what is going on there. Again, a package update is not required and this a fully backwards compatible release, so we definitely want to  understand what is happening there.

@fabiocav In the process of putting together the code to share,  I found the error.
If you go to this page, https://github.com/Azure/azure-functions-host/wiki/host.json-(v2)#sample-hostjson
The CosmosDB code is missing a  :  after "cosmosDB" and before the {
So it should be:
"cosmosDB": {             "connectionMode": "Gateway",             "protocol": "Https",             "leaseOptions": {                 "leasePrefix": "prefix1"             }         },
Once I fixed this, It worked.  I can't believe I didn't catch it!  Can you please update the page?
Thank you for your help!

Glad to hear this is working, though!

The deployment is complete.


[NFC] Remove dead code from type attribute parsing

Noticed by inspection.

@swift-ci please smoke test and merge

Hm, not so dead after all.


Add final annotations & remove inaccurate throws

Use linter to automatically apply final annotation to fields. I removed the ones that didn't make sense to mark as final.
Also removed occurrences of throws SomeCheckedExceptionThatIsNeverThrown

@phillipm Has conflicts


Actually process fallbacks properly by asset path instead of making assumptions

Includes minor code style changes

Closing this because Kohana is dead, so no reason for it to show up on my dashboard anymore.


Anagram in Python

Aim

To contribute to LGM-SoC'21.

Details

Code for finding Anagram.

Assign this to me.

Assign this to me in C programming.

Assign this to me.

@pranita736 you are participant in LGM SOC 21

Assign this to me in C programming.

@Sumanth2905 and you are also participant In LGM-SOC 21

I can't assign me this under LGM-SOC 21 Because current the program was not start when program was started then I assigned to you under LGM-SOC'21

@Ayush7614 yes, I'm participant in LGM SOC 21

@Ayush7614 Yes, I'm a participant in LGM-SoC'21.

@Ayush7614 yes, I'm participant in LGM SOC 21

When program was started then I assign to you thus under LGM-SOC 21

Okay, I'll wait.

@Ayush7614 yes, I'm participant in LGM SOC 21

When program was started then I assign to you thus under LGM-SOC 21

Okay, I'll wait.

@Ayush7614  Assign this to me.  I'm participant in LGM SOC 21.

@Ayush7614 Assign this to me. I'm participant in LGM SOC 21.

First you can check the timeline of LGM-SOC 21 program was start from 10 June so from 10 june i will assigned you this will not count towards your contribution in program if you work without program then i will assign you and if you work under program then i will assign from 10 June

Go Ahead @pranita736 @Sumanth2905

@Ayush7614 Assign this to me. I'm participant in LGM SOC 21.

@Jagannath8 bro you can work on different issues because firstly pranita and Sumanth was asked to me if you working in any other language then i will assign you

I can use python for solving

I can use python for solving

@Jagannath8 sorry brother i can`t assign you because in python @pranita736 was solved so you can work on diffenret issue and if you wish you can also opened issues from your sides then i will assign you

okay


Transform ::slotted() to ::content

Provides forward compatibility with Polymer 2.x and ShadowDOM v1
Fixes #3976

LGTM


Version stability on website is stale

https://http4s.org/versions indicates that 0.23 and 0.22 are stable and 0.21 is EOL.
However the dropdowns under "Documentation" (top bar) and "get started with http4s" (center of page) on https://http4s.org indicate that 0.21 is stable and 0.23 and 0.22 are under development.

Thanks for the report, and thanks to @armanbilge for jumping on it.


Add ability for site-level measurement scale method to report fugitive emissions based on known venting

Add the ability to allow for site-level measurement scale method to report a site-level fugitive emissions measurement by subtracting expected venting rates from the measured site level emissions. This will reflect some real-world work practices, where screening methods are provided with planned/expected site venting rates before the screening so that they can account for venting when reporting/analyzing results.

No longer relevant with v4 update.