Example/Manual for Deep Convolutional Neural Net

Would it be possible to add in an example/manual section for Deep Convolutional Neural Networks? I haven't seen any documentation for this, except for having to look through the source code itself, to understand how this works.

Look at https://github.com/KevinCoble/Convolution
It is an example program that uses the classes, and the readme page discusses the concepts.

That's great! I still think it would be a good idea to add a manual page about this, though.

Maybe we should also include an example of a mini-MNIST Conv-net that classifies between 0 and 1?

I would love any and all examples, additions, corrections, pointers, or comments regarding the library.
And yes, I am the stereotypical engineer - more code than documentation...


Cannot find templates when parent of parent is a submodule

Fixes #1

Welcome to Codecov :tada:
Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.
Thanks for integrating Codecov - We've got you covered :open_umbrella:


Ransack searchable attribute issue in admin

Summary
Issue - Runtime Error in Spree::Admin::Subscriptions. Ransack needs Solidus Subscriptions, Installments, Events attributes explicitly allowlisted as searchable

Fixes - Added the methods to make subscriptions, installments, events attributes allowlisted as searchable.
Checklist

I have written a thorough PR description.
I have kept my commits small and atomic.
I have used clear, explanatory commit messages
📸 I have attached screenshots to demo visual changes.

Test failures not related to this change. Need to tackle those in another PR


Getting issue on launch

ERROR:device_event_log_impl.cc(222)] [20:29:09.946] USB: usb_device_handle_win.cc:1046 Failed to read descriptor from node connection: A device attached to the system is not functioning. (0x1F)
ERROR:device_event_log_impl.cc(222)] [20:29:09.958] USB: usb_device_handle_win.cc:1046 Failed to read descriptor from node connection: A device attached to the system is not functioning. (0x1F)

I get those errors then the program fails to work

This seems to be a problem with USB drives (which is weird) and shouldn't affect the programme. I will work on this later. For now, I recommend following the guide again. Also, does the programme crash immediately? It seems from the picture that Chrome opens, as it shows the version.

I also had the same problem

I released an update to the chrome version. Delete all previous files and try again. Im closing this for now.


When stop words are reached, they get ingested, but are not forwarded to streaming_fn.

This is an issue, because when I try to run something like this:
from build.fastllama import Model, ModelKind

MODEL_PATH = "./models/ALPACA-LORA-7B/alpaca-lora-q4_0.bin"

def stream_token(x: str) -> None:
    """
    This function is called by the llama library to stream tokens
    """
    print(x, end='', flush=True)

model = Model(
        id=ModelKind.ALPACA_LORA_7B,
        path=MODEL_PATH, #path to model
        num_threads=16, #number of threads to use
        n_ctx=512, #context size of model
        last_n_size=16, #size of last n tokens (used for repetition penalty) (Optional)
        n_batch=128,
    )
prompt = """A: I am A, Hello
B: I am B, Hello A
B: I am B, How are you?
A: I am A, I'm fine, what about you?"""

print(prompt,end='')
res = model.ingest(prompt)
while True:

    res = model.generate(
        num_tokens=512,
        top_p=0.95, #top p sampling (Optional)
        temp=0.8, #temperature (Optional)
        repeat_penalty=1.0, #repetition penalty (Optional)
        streaming_fn=stream_token, #streaming function
        stop_words=["\nB: "] #stop generation when this word is encountered (Optional)
        )

    print("\n###")

The output looks like that:
A: I am A, Hello
B: I am B, Hello A
B: I am B, How are you?
A: I am A, I'm fine, what about you?
###
 am B, I'm good. How is your day going?
A: I am A, It's going well.
###
 am B, Nice to hear.
A: I am A, What do you do?
###
 am B, I'm a web developer.
A: I am A, That's cool.
###
 am B, Thanks.
A: I am A, It's been a pleasure chatting with you.
###
 am B, See you soon.
A: I am A, Bye!

As you can see, the stop word is supposed to be "\nB: ", but probably beacuse of some quirk of the tokenizer, it seems like the model actually generates and ingests "\nB: I" everytime. Because it contains the stop word, the models stop generating, but still has the "I" already ingested.
When that happens in an interactive chatbot-like setup, it could degrade the quality of the result.
I can think of two potential improvements regarding this issue:

Always send the generated tokens to the streaming funnction, even if the stop word is reached
If a stop word is detecteed, replace the generated token by the actual stop word token, to avoid cases where extra text is generated but not displayed.

@stduhpf this is a very nice insight!
Thank you for your efforts wrt identifying issues such as this. Really appreciate it!
I will have a look at this!

It's working as expected now, thank you!
The only annoyance remaining is that there is no way to know which stop word gets generated in case of multiple stop words.

Good feature to implement next!


trybuild fails to respect the --target-dir flag

I came across https://github.com/JelteF/derive_more/issues/421 and dug a little - it seems that trybuild tries, but fails, to respect the --target-dir flag.
Using derive_more as an example:

make a new directory, say repro
in that dir, make a fresh clone of derive-more (so the source is in repro/derive-more)
make repro/test
cd into repro/derive-more
run cargo test --all-features --target-dir=../test

The expectation is that all intermediate files are in the target directory as passed on the command line, repro/test, and repro/derive-more/target does not even get created. That is not the case here.
This apparently cause issues with Debian's build infra, like the issue linked at the top.

As far as I know, Cargo exposes no way for a test to recover the value passed to --target-dir. This is a Cargo flaw (https://github.com/rust-lang/cargo/issues/9661). The Cargo fix would be to define $CARGO_TARGET_DIR during test execution when a particular --target-dir chosen.
If you set $CARGO_TARGET_DIR yourself, that should get picked up. You can see it in CARGO_TARGET_DIR=../test cargo metadata --no-deps --format-version=1 | jq .target_directory.


Add support for LazyTest

https://github.com/NoahTheDuke/lazytest/
If a namespace includes any clojure.test tests, run them. If a namespace includes any LazyTest tests, run them. Merge the summaries.
Require LazyTest dynamically so it isn't a dependency but will load if on the classpath.

Implemented.


🐛 scanBarcodes returns undefined upon scanning a QR code

What were you trying to do?
I'm trying to scan a QR Code
Any assistance would be appreciated. Debugger mode is disabled, that solution was suggested in another issue but doesn't make any difference to the result.
Versions:
OS Version: Android
Android API Version: 33
react-native: 0.71.7
react-native-vision-camera: 2.15.4
vision-camera-code-scanner: 0.2.0
react-native-reanimated: 2.10.0
Hermes:  disabled
Reproduceable Code
import React, { memo, useEffect, useState } from 'react';
import { runOnJS } from 'react-native-reanimated';
import { Camera, useCameraDevices, useFrameProcessor } from 'react-native-vision-camera';
import { BarcodeFormat, scanBarcodes, Barcode } from 'vision-camera-code-scanner';
import { Container } from './styles';

interface QRReaderProps {
  testID?: string;
}

const QRReader: React.FC<QRReaderProps> = ({ testID }) => {
  const [hasPermission, setHasPermission] = React.useState(false);
  const devices = useCameraDevices();
  const device = devices.back;
  const [barcodes, setBarcodes] = useState<Barcode[]>([]);

  useEffect(() => {
    console.log('barcodesState', barcodes); // undefined
  }, [barcodes]);

  const frameProcessor = useFrameProcessor((frame) => {
    'worklet';
    const detectedBarcodes = scanBarcodes(frame, [BarcodeFormat.QR_CODE]);
    runOnJS(setBarcodes)(detectedBarcodes);
  }, []);

  React.useEffect(() => {
    (async () => {
      const status = await Camera.requestCameraPermission();
      setHasPermission(status === 'authorized');
    })();
  }, []);

  return (
    <Container testID={testID}>
      {device && hasPermission && (
        <Camera
          style={{ width: '100%', height: '100%', position: 'absolute' }}
          device={device}
          isActive
          frameProcessor={frameProcessor}
          frameProcessorFps={1}
        />
      )}
    </Container>
  );
};

export { QRReader };
export default memo(QRReader);

QRReader.defaultProps = {
  testID: 'qrreader-testID',
};

What happened instead?
Issue:
The return variable from the scanBarcodes function returns:

an empty array when no QR codes are in frame
undefined when a QR code is in frame

Relevant log output
barcodesState: undefined

Device
Google Pixel 6
VisionCamera Version
2.15.4
Additional information

[ ] I am using Expo
[X] I have read the Troubleshooting Guide
[X] I agree to follow this project's Code of Conduct
[X] I searched for similar issues in this repository and found none.

+1

https://www.youtube.com/watch?v=sE0MEyFA7E4&list=PLQhQEGkwKZUrempLnmxjt7ZCZJu1W3p2i&index=7

Hey! I've rewritten the entire Android codebase of VisionCamera from CameraX to Camera2 in the efforts of ✨ VisionCamera V3.
I just now completed the Camera2 rewrite and I believe the core structure is running, but there might be some edge cases to iron out. Can you try and test the PR #1674 for me to see if you can still reproduce this issue here?
Here's an instruction on how you can test that: https://github.com/mrousavy/react-native-vision-camera/pull/1674#issuecomment-1684104217
If the issue cannot be reproduced with that version/PR anymore, then hoorayy, I fixed it! 🎉
Otherwise please let me know and I'll keep this issue open to keep track of it.
Thank you!

Hey!
JFYI; VisionCamera V3 now includes a QR/Barcode Scanner! 😍  Check out the CodeScanner Documentation 🚀
Try upgrading to V3 if you can, it has a much more stable yet flexible foundation.
If you appreciate me dedicating my free time to improving VisionCamera and implementing features like the Code Scanner, please consider sponsoring me on GitHub 💖 to show your support.


ONEM-19817: Extend OCIContainer Thunder Plugin to support crypted con…

Changes according to design: https://wikiprojects.upc.biz/pages/viewpage.action?spaceKey=CTOM&title=Dobby+Integration

new PR created


Wrap validateTextDocument in debounce

To alleviate the issue reported in #31
Although you promised to implement it on your own, I thought I'll throw in a PR anyway, as I already had it implemented.
Feel free to reject it and implement differently on your own. The main thing here is really the decision of which library to use (or whether to just write debounce function on your own). Plus how long of a timeout to use.
I've played around with it a bit, and at least for now it seems to eliminate the main source of sluggishness in the extension.

I'd rather not take a dependency for such a short function if possible.

Makes perfect sense.
Replaced the library with a custom function. Placed it to a separate file as the server.ts file was big enough already and the implementation of it completely unrelated to the rest of the server logic.
It's indeed a fairly trivial function, though it took me a while to get the types right.


Update README

Also let's sync README files with other projects, e.g. https://github.com/absinthe-graphql/absinthe

Thank you!


python312Packages.jaraco-abode: 5.1.0 -> 5.1.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python312Packages.jaraco-abode is: Library interfacing to the Abode home security system
meta.homepage for python312Packages.jaraco-abode is: https://github.com/jaraco/jaraco.abode
meta.changelog for python312Packages.jaraco-abode is: https://github.com/jaraco/jaraco.abode/blob/5.1.1/CHANGES.rst
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 5.1.1 with grep in /nix/store/1mgbz3mg0ghpqj1gf6baiygsjipv1gh0-python3.12-jaraco-abode-5.1.1
found 5.1.1 in filename of file in /nix/store/1mgbz3mg0ghpqj1gf6baiygsjipv1gh0-python3.12-jaraco-abode-5.1.1

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath
python311Packages.jaraco-abode
python312Packages.jaraco-abode

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/1mgbz3mg0ghpqj1gf6baiygsjipv1gh0-python3.12-jaraco-abode-5.1.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

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

Or:
nix build github:r-ryantm/nixpkgs/756287269ff21cf0ec8225be06f5dd7e3ef5b4e9#python312Packages.jaraco-abode

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/1mgbz3mg0ghpqj1gf6baiygsjipv1gh0-python3.12-jaraco-abode-5.1.1
ls -la /nix/store/1mgbz3mg0ghpqj1gf6baiygsjipv1gh0-python3.12-jaraco-abode-5.1.1/bin

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

4 packages built:

python311Packages.jaraco-abode
python311Packages.jaraco-abode.dist
python312Packages.jaraco-abode
python312Packages.jaraco-abode.dist

Maintainer pings
cc @JamieMagee @dotlambda for testing.

duplicate of https://github.com/NixOS/nixpkgs/pull/298519


YML : for-type cannot be used to control defines ?

Looks like for-type does not apply to defines.
How can we control the compiler switches for the various build-types ? (like release/debug)

@fred-r could you please give an example.
e.g. defines could be specified in the scope of the build-type definition
see: https://github.com/Open-CMSIS-Pack/devtools/blob/main/tools/projmgr/docs/Manual/YML-Format.md#build-types
But I guess you have a different need.

Maybe this is what you are trying to achieve to limit the define e.g. to a component (or group or file) and yet make it specific to a certain build type.
components:
    - component: CMSIS:CORE
      for-type: .Release
      defines:
        - foo=1
    - component: CMSIS:CORE
      for-type: .Debug
      defines:
        - bar=1

Hi Joachim,
yes the build-type can do the job and it is probably the best option.
Actually my point was to say that for a given build-type defined at solution level, then each cproject may tune the switches.
So I was looking for something like:
project:
  defines:
    - USE_FEATURE_X
      for-type: .debug

Should we close the issue then?

Yes Joachim, I guess your approach is better (more consistent).


[BUG] Cannot find module '@zkochan/js-yaml' after package updates

Describe the bug
For about 2 weeks now (possibly earlier but I wasn't package updating then) when a package update is done (via updating the .projenrc.ts file) for the aws-prototyping-sdk package (i.e. 0.17.2 -> 0.17.4, but also prior package upgrades) a package will fail to be found when doing a build after the yarn projen command has updated the packages.
Expected Behavior
Not to get an error when doing a fresh build after upgrading this package.
Current Behavior
When invoking an nx build command after upgrading the package I'll get the below error:
I'll get the error:
 >  NX   Cannot find module '@zkochan/js-yaml'

   Require stack:
   - /Users/joshtoth/repo/node_modules/nx/src/plugins/js/lock-file/utils/pnpm-normalizer.js
   - /Users/joshtoth/repo/node_modules/nx/src/plugins/js/lock-file/pnpm-parser.js
   - /Users/joshtoth/repo/node_modules/nx/src/plugins/js/lock-file/lock-file.js
   - /Users/joshtoth/repo/node_modules/nx/src/plugins/js/index.js
   - /Users/joshtoth/repo/node_modules/nx/src/utils/nx-plugin.js
   - /Users/joshtoth/repo/node_modules/nx/src/project-graph/build-nodes/workspace-projects.js
   - /Users/joshtoth/repo/node_modules/nx/src/project-graph/build-nodes/index.js
   - /Users/joshtoth/repo/node_modules/nx/src/project-graph/build-project-graph.js
   - /Users/joshtoth/repo/node_modules/nx/src/project-graph/project-graph.js
   - /Users/joshtoth/repo/node_modules/nx/src/utils/project-graph-utils.js
   - /Users/joshtoth/repo/node_modules/nx/src/tasks-runner/utils.js
   - /Users/joshtoth/repo/node_modules/nx/src/tasks-runner/run-command.js
   - /Users/joshtoth/repo/node_modules/nx/src/command-line/run-many.js
   - /Users/joshtoth/repo/node_modules/nx/src/command-line/nx-commands.js
   - /Users/joshtoth/repo/node_modules/nx/bin/init-local.js
   - /Users/joshtoth/repo/node_modules/nx/bin/nx.js

Reproduction Steps
With a repository using aws-prototyping-sdk packages, upgrade the package to a newer version: 0.17.2 -> 0.17.4 and then run yarn projen && npx nx run-many --target=build --all and the build will fail.
it's specifically the nx build command that fails and targeting a specific package will fail regardless of the package.
npx nx run website:build
npx nx run infra:build
etc.
This also occurs when downgrading packages.
Possible Solution
No response
Additional Information/Context
Current workaround:
Delete the yarn lockfile at the root of the repository, then run yarn && yarn projen && npx nx run-many --target=build --all
Machine info:
I am currently using an M1 mac running 13.3.1. Although I have seen the same issue replicated on an intel mac as well.
I have also seen this on another machine, although I don't know it's specs.
I thought perhaps it's just my setup but I've seen this now in 3 places so raising this ticket. Not sure if this is something that can be fixed on this packages end, but the workaround is good for visibility.
PDK version used
0.17.2, 0.17.4
What languages are you seeing this issue on?
No response
Environment details (OS name and version, etc.)
macOS 13.3.1

I just got this error as well, thank you for the workaround!
npx projen did output some info about js-yaml:
 npx projen                                                                                devenv-shell-env
👾 default | ts-node --project tsconfig.dev.json .projenrc.ts
👾 Installing dependencies...
👾 install | yarn install --check-files
yarn install v1.22.19
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
warning Pattern ["<EMAIL_ADDRESS>is trying to unpack in the same destination "/home/rishi/.cache/yarn/v6/npm-js-yaml-0.0.6-975f0b306e705e28b8068a07737fa46d3fc04826-integrity/node_modules/js-yaml" as pattern ["js-yaml@npm<EMAIL_ADDRESS>This could result in non-deterministic behavior, skipping.
[4/5] Linking dependencies...
warning "@aws-prototyping-sdk/nx-monorepo > @pnpm/reviewing.dependencies-hierarchy ><EMAIL_ADDRESS>has unmet peer dependency "<EMAIL_ADDRESS>[5/5] Building fresh packages...
Done in 5.72s.


Create 12.java

Fixes #{Insert your issue number here}

My code sample is in :

[ ] CPP
[x] Java

Screenshot of working code sample  :

Checklist

[ ] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] My code sample is formatted and works correctly

Duplicate of #1816


Link to running ADPREP links to old content

In the section Adprep and Domainprep (https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/upgrade-domain-controllers#adprep-and-domainprep)
Your link for information about running ADPREP.EXE links to the old documentation (https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd464018(v=ws.10)), which does not appear to Mention Server 2016

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

ID: e32288e6-1a81-01da-51bf-d1564049a28a
Version Independent ID: 7388c199-ee35-63fa-deda-e3f6399de3ee
Content: Upgrade Domain Controllers to Windows Server 2016
Content Source: WindowsServerDocs/identity/ad-ds/deploy/upgrade-domain-controllers.md
Product: windows-server-threshold
GitHub Login: @billmath
Microsoft Alias: billmath

Info is still valid.

#please-close

My point was that if it is valid why does it have a huge disclaimer at the top of the page saying it isn't being updated and having a link to a "recommended version" that then takes you to a content area and not an updated version of the content.

Understood. Unfortunately AD DS content lives intermingled amongst Windows Server content for previous versions. Windows Server content is no longer being updated for old versions but as updates are made to AD DS content we will bring that forward and update it.

So is there a better place to open a ticket for "Missing Article" then?  One for how to run ADPREP in the current windows server environment?

Runs the same way as the article describes. Schema versions are listed in the doc below.
https://docs.microsoft.com/windows-server/identity/ad-ds/deploy/domain-wide-updates

I am pretty sure that the current ADPREP article is missing some of the command line arguments that ADPrep supports when run from the Windows Server 2016 Installation media, but I don't have access to my test environment to verify right now.
From memory I think it was the fact that the article as-is mentions a requirement to run the adprep command from Domain Controllers holding specific FSMO roles, but I thought the Server 2016 version of adprep modified that requirement.
As you also pointed out with your reference to the Schema documentation, the existing article is also missing a link to the changes made by adprep for Windows Server 2016.

I will add it to the backlog to get it updated but there is no timeline I can give you on when that will get completed. Wanted to give you info so that you could move forward.

Oh I appreciate any and all feedback. I really just wanted to make note of it in case it hadn't been already mentioned, I didn't mean to be such a nag.  Thank you for all the work you do on keeping the documentation vetted and updated.

Why would you add this comment.. Server 2012 and 2012 R2 were also 64-bit only?
"Domain controllers that run 64-bit versions of Windows Server 2012 or Windows Server 2012 R2 can be upgraded to Windows Server 2016. Only 64-bit version upgrades are supported because Windows Server 2016 only comes in a 64-bit version."

@JeoffB I don't think that is related to this issue but your feedback is valid. That was part of the original doc before I inherited it. If you would like to propose a change feel free to hit the edit button and propose what you think should be changed. Otherwise I will add it to my backlog and try to get to it as soon as possible.


geth: add top-level package

I didn't realize when I added goPackages.ethereum that I also should have added a top-level link to make it more useful.

I named this package geth because that's the name of the main executable it provides, and so that's commonly what the program is referred to.
Other possibilities would be:

go-ethereum, which is the name of the git repo
ethereum.go or ethereum.geth, if we wanted to create an ethereum group, because there are other related ethereum projects that could be added in the future

On second thought, I'm about to make a package for the c++ ethereum implementation, so I think it will make more sense to have ethereum.go and ethereum.cpp and put the definitions into the altcoins directory.


Fix dt_to_unix to return a int and avoid scientific notation on serialization

This change fixes the epoch_seconds searialization to avoid scientific
notations and parse errors with Elasticsearch as seen before on #996.

Aha! I wasn't able to reproduce this with seconds OR millisecond epochs, now I see if I make it large enough, I can trigger it. Do you have any idea if this is system dependent?
>>> json.dumps({'hello':<PHONE_NUMBER>4305444.1})
'{"hello": 1.4914991344305444e+16}'
>>> json.dumps({'hello':<PHONE_NUMBER>430544.1})
'{"hello":<PHONE_NUMBER>430544.0}'

@Qmando

Do you have any idea if this is system dependent?

Don't really know, but I hit this in all deployments we have.
Thanks for merging.


Incompatibility with Click 8

nbterm depends on the library 'click' through the library 'typer'. Right now there is a problem with typer calling click.
For those users installing nbterm with conda-forge, downgrade click as suggested in https://github.com/tiangolo/typer/issues/278

Thanks for reporting, do you think I should pin click <=7 in conda-forge?

I just released Typer 0.4.0, which is compatible with both Click 7 and Click 8. :tada:

Awesome, thanks @tiangolo !


Auto scaling not taking into account whether a repo has access to a runner group.

Hello, I have found that the current auto scaling mechanism is not taking into account whether a repo is registered to the runner group specified by an org pool.
Currently we have many repos that are not registered under the runner group specified for pools, when any of those repos have a queued up workflow job it triggers the auto scale because they are in the same org and the tags match.
Unfortunately most of our existing workflows are set to self-hosted tag so they are triggering autoscaling of pools that should not be (since they aren't in the runner group they wont be picked up). This is causing all of our pools to constantly pin runner amount to max and recreate runners non stop (cleaned up by scaleDown loop).
As a temporary workaround I have created a fork of garm and have implemented the following:

Added a runner group map with a selected repos "cache" list, in memory, inside of the organization object.

type organization struct {
...
	rgs         map[string]*common.GithubRunnerGroup
}

type GithubRunnerGroup struct {
	ID                       *int64
	Name                     *string
	Visibility               *string
	SelectedRepositories     *github.ListRepositories
}

On org pool manager startup, schedule job to periodically (10 mins) refresh selected repos list for every enabled pool.

Loops over all pools and generates common.GithubRunnerGroup object with runner group and selected repos info from ghcli.

On HandleWorkflowJob verify repo is in runner group's selected repos list

Loops over potential pools (reduced by tags)

On public or private visibility, return true
On selected visibility, run logic

Add api interface to execute selected-repo list update on a specific pool list

Will trigger this programatically when a repo is registered to a runner group

Hmm. This is an interesting case. The ability to schedule a runner based on runner group is currently missing in GARM.
For example, we completely ignore workflows such as the following.
runs-on:
  group: my-runner-group

We need to be able to schedule a pool based on group as well as labels:
runs-on:
  group: my-runner-group
  labels: ["large", "self-hosted"]

And currently GARM doesn't do anything with the group name. We can register runners in a runner group, but if a workflow comes in with a runs-on set to the runner group name, we never react.
Do your workflows explicitly target groups or do they just use self-hosted and nothing else?
This week I'll be traveling, but next week I will definitely attempt to fix this huge missing feature. We already record the runner group name in the pool definition. There is no reason we can't schedule the proper pool when a job comes in that targets a specific pool. So even if you do use self-hosted, as long as you specify the runner group in your workflows, only pools that have that runner group set will be matched.
As a side note, I highly advise to avoid using any of the default labels and use unique label sets if at all possible for a better scheduling experience.

Yeah unfortunately we already have too many repos with self-hosted as the only label so runner group control is the only way we have to prevent breaking those repos. Currently working on getting the repos updated but we don't own the majority of them so I can't go and make the change directly.
Any thoughts on the "selected repos" feature of runner groups?

I'm guessing the repos that use self-hosted don't really target a runner group. You're just trying to restrict who gets to use a certain set of runners by granting granular control to one repo or another. And in the case detailed above, garm spins up runners in the wrong place which never really gets used due to ACLs on the groups.
So there are actually 3 features to potentially implement here:

the ability to target a pool based on runner group as well as labels.
adding some sort of ACLs in GARM itself which allows us define an allow list or an exclude list of repos for which a pool should be eligible
a way to sync that allow/deny list based on the runner group defined on a pool and the repos that are allowed to use it.

We need to figure out what the impact is (in term of API calls to GitHub) of keeping that allow list in sync with repos that have been granted access to a runner group. We also need to take into account that runner groups can be created at the enterprise level and shared with orgs, which in turn can share them with repos. This last aspect may be inconsequential, but we still need to explore it.
Using the runner group as a source of truth for 2) seems correct, but the fact that those runner groups can be updated at any time to allow/deny public repos or that the runner group can be shared with more repos at any time, without sending out a webhook, means we need to poll the runner groups as well. This is a potential pain in the neck, especially if you have huge orgs with many repos and many runner groups.
But this is something that definitely needs to be explored more. I can definitely have a look at points 1) and 2) starting next week. For 3) I need some time to think, and hopefully access to an enterprise account.

Yeah. For enterprises, we can only see orgs we've shared the runner group with. If we have an enterprise with many orgs, and those orgs have many repos, we'd need to first list all orgs with access to the runner group, then for each org we'd need to see which repo they share that runner group with and add those repos to the list. It can potentially generate a lot of API requests, and it can be really slow.

Yeah, didn't know that enterprises had runner groups, definitely adds an additional dimension of complexity to the solution.
You are correct the self-hosted don't target a runner group, they just rely on there not being any "global" runner groups and the built in runner group allow list.
For organization runner groups the api impact is 1 api call to get the runer group ID from runner group name (unless you cache the runner group ID somewhere) and 1 api call to get the list of repositories, more or less 2 * # of pools * frequency of update which for my workaround is around 300 api calls per hour which is fine but we currently have a fairly small selection of pools. It also has the side effect that repos have to wait up to 10 minutes to get picked up by a runner if they were just added to the allow list. Thats why I added an api interface to trigger the update for a specific pool. I am planning to build some automation to replace the manual allow list creation and it will trigger the GARM Api to update allow list after saving the runner group.

This is a mess. It seems that jobs in queued state do not set the runner group, even if the workflow explicitly sets:
runs-on:
  group: my-runner-group
  labels: ["large", "self-hosted"]

So until a job is picked up, we don't know the runner group. This means that we can't really schedule by group name. We can still attempt to create that allowlist/blocklist of repos that we should react to when a job comes in. If the pool has an explicit runner group set and the entity requesting a runner is not allowed in any of the runner groups set on pools, we can ignore the job.
But we still have to solve the issue of API requests. Will think about how we can do this in a sane way.

Hey @gabriel-samfira has there been any recent breakthroughs on this issue? We have a really inconvenient custom solution in place and would like to move away from it.

sadly no. They still don't send the runner group as part of a queued webhook payload. We'd need to periodically brute force scan to update mappings. I don't have cycles to address this for now. Hopefully soon.


Disk layout of Alpine Linux appliances

Disk layout of the Alpine appliances is not ideal, should be just single partition https://github.com/OpenNebula/marketplace/issues/8#issuecomment-438371343:
label: dos
label-id: 0x512515ea
device: /dev/loop1
unit: sectors

/dev/loop1p1 : start=        2048, size=      204800, type=83, bootable
/dev/loop1p2 : start=      206848, size=      262144, type=82
/dev/loop1p3 : start=      468992, size=      579584, type=83

BTW, I wrote a generator opennebula-images from the official Dockerfiles, unfortunately I have no time to finish it.
The sources can be found here, take a look:
https://github.com/kvaps/opennebula-images/tree/da5bcbadbe2915167ef74fde7166ff4d75fb1151/new


Remove BigQuery credentials

You should remove this file from the git history. People can use this credential file to act in your GCP account on your behalf: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository
https://github.com/xlang-ai/Spider2/blob/0b1656dd2e82272ca194e6098d4b58a08497f966/spider-agent/bigquery_credential.json#L1

Thanks for your kindly suggestions


Live m-mapping of chunks on disk

This is a broken down piece of https://github.com/prometheus/prometheus/pull/6679/
This just has the standalone implementation of the live m-mapping logic without any integration with Head.

Thanks @krasi-georgiev and @bwplotka for the reviews. I will start addressing them 1 by 1 now.

@krasi-georgiev @bwplotka I have addressed most of your comments except those which might require more discussion. This is ready for review again otherwise.

I tried having 2 different structs for read and write path as @krasi-georgiev suggested. Though individual structs are simpler within themselves, using them together causes additional complexity (like a couple of shared variables to be duplicated, interaction during cutting a new file, etc). So I decided to go with a single struct which is simpler in this case.

Now it's time to fix those windows test finally! I tried reducing the max file size to 128 MiB, and still it fails with mmap: CreateFileMapping: Not enough memory resources are available to process this command..

Thanks for the reviews @krasi-georgiev and @bwplotka! I will merge this once I find the fix for the windows test. Any further changes can be taken care in https://github.com/prometheus/prometheus/pull/6679

So here is what I have concluded about the windows error: If we set the mmap size of the file to be greater than the file size (which is the case when we cut a new file), it errors out with a Windows bug saying Not enough memory resources are available to process this command. Preallocating the file would be a bad idea for the fast path, and also poses many challenges as there is no separate index to access the file.
Any suggestions on what can be done here for m-mapping an empty file?

Only when new file is cut? Let's focus on this path. Can we create fake empty file for X bytes? and mmap that?

Yes, that would be the preallocation. As said in the previous comment, we want to avoid that as it lies on the hot path. Also, while iterating the chunks for replay we rely on the file end (maybe we can get around that, by exiting the replay when we encounter all 0's for a chunk and its meta). So the main concern would be stalling the scraping.

Can we do that for windows only?

With build tags

We can, though not a big fan of it :| I don't see any other option.

Tried some quick fix. If that fails too, I will give it a shot tomorrow.

Windows test is finally green! If @krasi-georgiev or @bwplotka can review the last commit that would be great.

did you actually test if preallocating a file really takes more time? I am thinking maybe it shouldn't take longer if the file is only zeros.

did you actually test if preallocating a file really takes more time? I am thinking maybe it shouldn't take longer if the file is only zeros.

Apparently it doesn't seem to take very long, 1-1.5ms in my system, but I guess at the end if will depend on the hardware and the current situation of the system. Are you suggesting we have preallocation by default? (We could do that now, and if we face any problems, we can revert for the !windows)

Let me actually just have preallocation by default. We will know about its effect when we run it and changing it will be a quick fix.

I have made preallocation of file a default now

yep, in that case no need to do another review from my side
LGTM

Further integration will be in https://github.com/prometheus/prometheus/pull/6679


fix(#5097): Remove secondary IntegrationPlatform in favor of using IntegrationProfile

Remove secondary IntegrationPlatform mode
Reduce logic to a single IntegrationPlatform per operator instance
Introduce IntegrationProfile custom resource definition
Let user customize a subset of IntegrationPlatform settings in IntegrationProfile
Load IntegrationProfile settings when integration resource is annotated to select the profile
Remove platform creation as part of the platform trait (avoids duplicate platform resources)
Save trait configuration used to build the integration kit on the resource spec for future reference

Release Note
fix(#5097): Remove secondary IntegrationPlatform in favor of using IntegrationProfile

we can't remove/rename any field from custom resource for backward compatibility reason. Anything we want to remove we must deprecate the fields and eventually remove them in a major upgrade. Same for the feature itself. We should deprecate it before removing to give the user the possibility to upgrade accordingly.

Regarding the CRD changes: do you refer to the removed trait options on the platform trait? What about auto migrating local IntegrationPlatform CRs to IntegrationProfile CRs?

we should avoid decreasing the coverage that much. Hopefully you can include some unit test to raise the coverage to be at least even.

I just need to remove more code 😄 Yes, my plan was to add more unit tests

@squakez @lburgazzoli @gansheer @claudio4j the PR is now ready for review. If you want to have another look 🙏
I'd suggest to follow-up with these tasks in separate PRs:

Further simplification of integration platform logic with deprecate/remove namespace local integration platforms (strictly have only 1-1 relationship of operator and integration platform)
Restrict the settings that a user is able to set in integration profile and builder traits (admin related settings only settable via integration platform)

@valdar @rinaldodev mind having a loom too ?

Regarding the CRD changes: do you refer to the removed trait options on the platform trait? What about auto migrating local IntegrationPlatform CRs to IntegrationProfile CRs?

I think we should first translate the local IntegrationPlatform to a IntegrationProfile without removing it as this may have impacts to CI/CD pipelines, similar to what has been done for the transition from  KameletBinding to Pipe

I think we should first translate the local IntegrationPlatform to a IntegrationProfile without removing it as this may have impacts to CI/CD pipelines, similar to what has been done for the transition from KameletBinding to Pipe

The local IntegrationPlatform should still be a valid option after the changes in this PR

I think we should first translate the local IntegrationPlatform to a IntegrationProfile without removing it as this may have impacts to CI/CD pipelines, similar to what has been done for the transition from KameletBinding to Pipe

The local IntegrationPlatform should still be a valid option after the changes in this PR

bet gets translated to an IntegrationProfile ?

bet gets translated to an IntegrationProfile ?

no, the resources can coexist at the moment

bet gets translated to an IntegrationProfile ?

no, the resources can coexist at the moment

do you think we can do the translation ? just to simplify the logic on the operator

do you think we can do the translation ? just to simplify the logic on the operator

The resources are not exactly the same. The IntegrationProfile has only a subset of settings available on the IntegrationPlatform.
Do you have some auto translation in mind? or that the user needs to manually switch to using IntegrationProfile instead of IntegrationPlatform? I think the latter one is doable with some documentation. If we really want to simplify the logic on the operator regarding IntegrationPlatform we should remove the local platform feature and tell users to switch to IntegrationProfile

do you think we can do the translation ? just to simplify the logic on the operator

The resources are not exactly the same. The IntegrationProfile has only a subset of settings available on the IntegrationPlatform.
Do you have some auto translation in mind? or that the user needs to manually switch to using IntegrationProfile instead of IntegrationPlatform? I think the latter one is doable with some documentation. If we really want to simplify the logic on the operator regarding IntegrationPlatform we should remove the local platform feature and tell users to switch to IntegrationProfile

No I don't so I'm fine with the current logic for the time being (which could be improved once we get https://github.com/apache/camel-k/pull/5119 merged).
I was mainly looking if there were a way to preserve backward compatibility in term of CRD/CR but simplify things internally.

LGTM. Might be a good idea to regenerate the CRDs.

@gansheer I did a make generate and make bundle - am I missing something else?


Support for SQLite FTS5?

Does jet support FTS5?
I want to create a virtual FTS5 table for search queries. But jet doesn't seem to acknowledge it. Correct me if I'm wrong because maybe I am missing something.
CREATE VIRTUAL TABLE JobPostings_fts USING fts5 (
    title,
    short_description,
    full_description,
    address
);

jet -source=sqlite -dsn="./local.db" -schema=part-time-mothers -path=./.gen
Retrieving schema information...
Error trace:
 - failed to query database metadata:
 - failed to get  tables metadata:
 - failed to query column metadata:
 - failed to query 'JobPostings_fts' column metadata:
 - jet:
 - no such module:
 - fts5

I guess Jet generator is not working when I have that USING fts5 query.
I thought of using raw query for FTS statements but that's also not possible when Jet generator is failing.
Full text search is critical to my project. Please help me make the decision.

found out that this is not the problem of Jet, but me not enabling fts extension when compiling my sqlite db.
closing.


APP-2140 Update authorizations endpoints for org settings page

endpoint to support this part of the org settings page:

@michaellee1019 hello, @piokasar and I are suggesting a few structural changes to the API, we know they are pretty substantial so please let us know what considerations we might be overlooking.

We suggest modifying the ListAuthorizations endpoint to be cumulative and return all authorizations within an organization, with the option of filtering by resource(s).
We suggest modifying the proto for Authorization to be entirely flat. This is to make data parsing on the frontend simpler and reduce the logical dependency of understanding how authorizations are stored in the db. At the cost of repeating some data, we can also avoid Authorization and Authorizations objects, instead always returning a single Authorization or multiple authorizations.

please let us know what you think!

@stevebriskin can you merge when you get the chance? this will unblock frontend permissions work


GOSW11-Create a Login Page

An interactive & fully responsive login form in React.

@nanda-mik Assign me pls

Can I work on this pls

@nanda-mik can you plz assign me this ?

@sachinsom93 work on this!!


don't attempt to import growl in browser build

Does growl work in the browser?  I had to add this in order to perform es6 imports in a webpack build.

Coverage increased (+0.04%) to 89.017% when pulling d50fd054c245de17738e3921f1c5ee08e2cecf77 on ahamid:no-browser-growl into 2408d9067483451fdd40eed98399db958f7bf672 on mochajs:master.

That's a good question -- if Growl doesn't work in browsers to begin with, we'll want to know for sake of determining how to handle the vulnerability fix too.

(P.S. Thanks for the PR! If we can confirm that Growl shouldn't even be used in the browser, this update looks good to me.)

I had a project were I needed notifications in browser. I ended up setting growl to true and overriding mocha._growl. I can push here this override of _growl (that uses web notifications). What do you think about it?
Also by reading the code I could see that the best place to put this overriding is browser-entry.js, right?

@BuonOmo were you using webpack to package the js? My issue was that webpack was including the npm -sourced growl package automatically, it was not just a runtime configuration issue.

@ahamid Yes I packaged the whole js with webpack, using the mocha-loader. I've even created a question on SO about it to see if someone had encountered the same issue.

@BuonOmo interesting, i wasn't aware of mocha-loader, I will give that a shot

It is not very well documented, I'd suggest you to read the code in order to see what it does. Anyway, for my previous question: may I implement notifications in browser for mocha ? (@ScottFreeCode)

Also by reading the code I could see that the best place to put this overriding is  browser-entry.js , right?

Anyway, for my previous question: may I implement notifications in browser for mocha ?

You're certainly welcome to give it a try! I can't promise it will be evaluated promptly (we've already got a bit of a backlog of stuff to go through at the moment), but we'd be happy to at least look at it at some point and see what it's like, then decide what we want to do with it.
As for browser-entry.js, I don't happen to know of anywhere better to handle it in Mocha's codebase off the top of my head, though someone else on the team might.
On the other hand, it may be worth asking whether Growl would want browser integration like that (in which case we could just ensure Growl is usable in the browser and we'd get the functionality), provided we resolve the previously mentioned issue of supporting newer versions of Growl somehow.

Ok thank I'll make a PR and reference it here. I don't think growl is supporting browser, but maybe we should name the option after notify instead of growl, this would go straight to the point and users can use it whether they are in browser or not without having to care about how the notification is done.
Anyway, let's discuss this in the according PR :)

I am pretty sure that #2962 preempts this.


Issue

After installing helm I couldn't able to install helm chart using playbook but can able to run the the helm command manually in console. I'm using CentOS 8.

@metronew Please change the issue title. Thanks very much.


Fix minor issues for multi-chain gateway

:clipboard: Add associated issues, tickets, docs URL here.
closed #303
Overview
Describe what your Pull Request is about in a few sentences.

Fix DEV tokens
Replace DEV token image
Fix top right chain token

Changes
Describe your changes and implementation choices. More details make PRs easier to review.

Add DEV token image
Replace Moonbase chain image

Testing
Describe how to test your new feature/bug fix and if possible, a step by step guide on how to demo this.

Codecov Report

Merging #304 (ebcba21) into alt-l1 (0aa3ff8) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           alt-l1     #304   +/-   ##
=======================================
  Coverage   48.45%   48.45%
=======================================
  Files         104      104
  Lines        3979     3979
  Branches      785      785
=======================================
  Hits         1928     1928
  Misses       2051     2051

Flag
Coverage Δ

boba-contracts
24.01% <ø> (ø)

contracts
77.95% <ø> (ø)

core-utils
86.80% <ø> (ø)

data-transport-layer
31.17% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Master

This is the pull request for the GROUP 6 submission on the "Projects for Month 1" for
The AI Department
Geek Room
MSIT

@Sehajdeep30 Merged


Live-editing SVG files

It would be nice if SVG files could have live-refreshing like HTML files,

The script is only injectable if the svg files are served using the mimetype text/html. Perhaps we can add a query field to the server call for svg files to serve them as text/html if we want them to be live-refreshing?
The main issue that I see with injecting all instances of SVG files (other than serving them with an alternative mimetype) is that performance may be bad when an html file has many linked svg files (in this case, the main file would have an injectable and so will each svg file, so websocket refreshes will send to many clients.

Likely will not be covered, since other extensions can provide SVG previewing sufficiently. Including it in Live Preview may cause it to be less focused.


jsdom update

Some time ago I tried to make mocha work with react and build this mocha-react-boilerplate.
However, I met @Munter at the JSConfEu and he showed me jsdomify. So I wanted to use it on our recent project, but it does not work with node 4.x.
I haven't made any deep investigation about breaking changes between jsdom 3 and jsdom 6, but the tests pass and maybe this pull request makes jsdomify work with node 4.
Changes:

updates jsdom 6
fixes reference to "document.window"

Oh damn ... Sorry, I just realized that @dmatteo tried to do the same PR.

Hey @topa,
thanks for your PR, but we cannot merge it, unfortunately.

updates jsdom 6

Yeah, we're not ready to migrate to Node 4 yet.
You can still use jsdomify though, even if it's not using the latest jsdom version.

fixes reference to "document.window"

As of jsdom 3.x, the reference to the window is correct. Since jsdom 4.x it has been "moved" to defaultWindow instead of parentWindow

You can still use jsdomify though, even if it's not using the latest jsdom version.

Unfortunately it fails while compiling contextify under node 4 (tested with 4.0.0, 4.1.0 and 4.2.0).

Ouch, this is annoying.
We might need to split up the packages and release one node 0.x and one node 4.x version then

That would be nice! :+1:

I have created an updated branch that I want to merge asap for Node4  => #10.
I have to be sure we're not breaking anything first :)
I've also moved the node 0.x compatible code into jsdomify-compat

So what we could also do is keep a major version of jsdomify locked against jsdom 3.x with a corresponding node engine lock that make it only compatible with node versions below 1. Then on a new major version branch upgrade to jsdom newest and lock node engine above 1.
This should install a working version for either node engine

I thought about that, pretty much what jsdom did, but I never liked the idea of a version "stuck in the past" that you have to explicitly require with npm install jsdomify @1.x.
The good part of that approach is the warning you get when you install the non compatible version, but I think we can have that also in the separated package, if we fix the node engine version.
I've been inspired by the lodash approach, as I think having different packages with the same (when possible) API is much more clear.
Thoughts?

If you set an engine range lock for the compatible node engines all you would need is npm install jsdomify, which would then install the latest version compatible with your current engine. The trouble is if you have a lot of version already released which are annotated to be compatible with any engine, and you might hit that one. I don't think we are in that situation

I've digged into the docs and I've found this, bringing us back to the annoying npm install jsdomify@1

unless the user has set the engine-strict config flag, this field is advisory only.

Moreover, if I understood that correctly, once we tag 1.0 with "engines" : { "node" : ">=0.10 <0.12" } and move forward with "engines" : { "node" : ">=4" } (e.g. for 2.0) we can't go back and backport features to 1.x. Am I right?

You would of course set engine to strict.
As long as the features you add are not strictly jsdom 4-6 specific you can backport anything to the jsdom 0-3 branch

engineStrict has been deprecated in npm 3 though
On Sun, 18 Oct 2015 at 21:35 Peter Müller<EMAIL_ADDRESS>wrote:

You would of course set engine to strict.
As long as the features you add are not strictly jsdom 4-6 specific you
can backport anything to the jsdom 0-3 branch
—
Reply to this email directly or view it on GitHub
https://github.com/podio/jsdomify/pull/9#issuecomment-149041041.


Database implementation

Hi
It just looks like that only the Edge database is currently implemented.
Is that true?
And when you think are the other databases available?

it's true, but since we're only using the edge database that's the only one we implemented.


Issue on the "Lectures, Tutorials and Webinars" webpage

Hi Vi, I have an issue with the page "Lectures, Tutorials and Webinars". I have changed a bit the order of each video (organised in webinar/training/whorkshop/school) and I must have made a mistake because I received an error message. Can you please have a look ? Thank you !

hi @SophieMacadamia @fannyadloff I have now fixed it and it works as it used to https://is.enes.org/lectures-tutorials-webinars/
The reason why it showed a 404 was that the html page was not built due to a compilation issue from the Markdown https://raw.githubusercontent.com/IS-ENES3/IS-ENES-Website/main/pages/lectures-tutorials-webinars.md and the issue with the Markdown was that Sophie added strings followed by colons, but did not encase them in quotes eg text: WEBINAR: Introduction to ESMValTool (June 2022). 1 hour video. - colons are key separators in Markdown so if the text that contains them is not encased in "" then the compiler will interpret them dynamical elements, just like in a Python dictionary dict = {a: 2, b: 3}. So next time, put all the text that is supposed to be text on the site in quotes, pls, Sophie, in these cases :beer:


505: custom logos

This resolves #505:
Pretty much the same as #506. Added the ability to upload community logos.

@tauhir merge conflicts with the other change! perils of working similar prs

force-pushed to branch to correct a merge with master where I destroyed this feature accidentally


Feature/add support for fragments

Add support for queries that contain fragments and disable max depth for introspection queries.
I based my changes on the Javascript repository https://github.com/stems/graphql-depth-limit/blob/master/index.js

Thanks for the PR! I'll review this in more depth later but looks great

Thanks for the PR! I'll review this in more depth later but looks great

I know it's quite a bit of stuff and if you disagree with some of it just let me know and I will change it.

Looks great! Thank you so much for this contribution, and feel free to share other thoughts regarding features ("complexity" determination and limiting, etc)


Doesn't build on android emulator

Error when building for android emulator
Launching lib\main.dart on sdk gphone x86 arm in debug mode...
lib\main.dart:1
e: D:\Flutter.io\flutter\.pub-cache\hosted\pub.dartlang.org\flutter_activity_recognition-1.2.0\android\src\main\kotlin\com\pravera\flutter_activity_recognition\service\ActivityRecognitionManager.kt: (91, 59): Unresolved reference: S
e: D:\Flutter.io\flutter\.pub-cache\hosted\pub.dartlang.org\flutter_activity_recognition-1.2.0\android\src\main\kotlin\com\pravera\flutter_activity_recognition\service\ActivityRecognitionManager.kt: (92, 65): Unresolved reference: FLAG_MUTABLE

Verson: geofence_service: ^3.4.4
build.gradle has these in default config
        minSdkVersion 27
        targetSdkVersion 30
        multiDexEnabled true

$ flutter doctor -v
[√] Flutter (Channel stable, 2.5.3, on Microsoft Windows [Version 10.0.19042.1348], locale en-GB)
    • Flutter version 2.5.3 at D:\Flutter.io\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 18116933e7 (6 weeks ago), 2021-10-15 10:46:35 -0700
    • Engine revision d3ea636dc5
    • Dart version 2.14.4

... No issues

@jameshmread
Upgrade compileSdkVersion and targetSdkVersion to 31 as shown in the picture below.

That works. Thank you. Is there a sdk 30 compatible version? I struggled to find one.

Use geofence_service: ^3.4.2. However, if you are concerned about bug fixes and plugin safety, use the latest version.


[shaped-scripts] Handle extended unicode characters better

Currently if there's a unicode escape sequence in the GM notes data, the parse fails because decodeURI component doesn't handle them.
We should find and replace common bad characters before we run decodeURI, and we should also search for these sequences and provide helpful error messages where they occur.

Sadly, this is because roll20 are using the deprecated "escape" method in JS. I've moved the unescaping to use "unescape" to match.


[HiTL] Added support for customizing docker image for ecs instances

Description
Previously we use 'craftassist:latest' ecr image to create ecs instances. This PR allows us to tag image with any tags you provide and create ecs instances from any ecr image matching the tag.
Fixes # (issue)
Type of change
Please check the options that are relevant.

[ ] Bug fix (non-breaking change that fixes an issue)
[ ] Proposes a change (non-breaking change that isn't necessarily a bug)
[ ] Refactor
[x] New feature (non-breaking change that adds a new functionality)
[ ] Breaking change (fix or feature that would break some existing functionality downstream)
[ ] This is a unit test
[ ] Documentation only change
[ ] Datasets Release
[ ] Models Release

Type of requested review

[ ] I want a thorough review of the implementation.
[x] I want a high level review.
[ ] I want a deep design review.

Before and After
If this PR introduces a change or fixes a bug, please add before and after screenshots (if this is causes a UX change) or before and after examples(this could be plain text, videos etc ) to demonstrate the change.
If this PR introduces a new feature, please also add examples or screenshots demonstrating the feature.
Testing
Please describe the tests that you ran to verify your changes and how we can reproduce.
Checklist:

[ ] I have performed manual end-to-end testing of the feature in my environment.
[ ] I have added Docstrings and comments to the code.
[ ] I have made changes to existing documentation where needed.
[ ] I have added tests that show that the PR is functional.
[ ] New and existing unit tests pass locally with my changes.
[ ] I have added relevant collaborators to review the PR before merge.
[ ] [Polymetis only] I have verified that all scripts in tests/scripts runs on hardware.

waiting for #797 to be merged

Codecov Report

Merging #819 (a29e4c9) into main (9f9ec0a) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #819      +/-   ##
==========================================
- Coverage   32.94%   32.93%   -0.01%
==========================================
  Files         336      336
  Lines       32761    32761
==========================================
- Hits        10792    10789       -3
- Misses      21969    21972       +3

Impacted Files
Coverage Δ

interpreter/craftassist/tasks.py
74.54% <0.00%> (-0.55%)
:arrow_down:


[BUG]  Aqara vibration sensor quirk is not working correctly

Aqara vibration sensor claimed to be supported but it is not. See the attached screenshot.

'''javascript
{
"node_descriptor": "NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress: 128>, manufacturer_code=4151, maximum_buffer_size=127, maximum_incoming_transfer_size=100, server_mask=0, maximum_outgoing_transfer_size=100, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False)",
"endpoints": {
"1": {
"profile_id": 260,
"device_type": "0x000a",
"in_clusters": [
"0x0000",
"0x0001",
"0x0003",
"0x0019",
"0x0101",
"0x0500"
],
"out_clusters": [
"0x0000",
"0x0003",
"0x0004",
"0x0005",
"0x0019"
]
},
"2": {
"profile_id": 260,
"device_type": "0x5f02",
"in_clusters": [
"0x0003"
],
"out_clusters": [
"0x0003",
"0x0004",
"0x0005",
"0x0012"
]
}
},
"manufacturer": "LUMI",
"model": "lumi.vibration.aq1",
"class": "zhaquirks.xiaomi.aqara.vibration_aq1.VibrationAQ1"
}
'''

Do you get any zha_event and is the ISA Zone changing status ?
The "class": "zhaquirks.xiaomi.aqara.vibration_aq1.VibrationAQ1" is saying ZHA have loading one quirk for your device = its supported by one quirk (then its not one Zigbee  certified device = bad working device).

@MattWestb  I'm not sure I fully understand what you are saying. My device is 100% official and certified. I bought it from an official Xiaomi store.

2022-01-20 11:36:25 DEBUG (MainThread) [zigpy.quirks.registry] Checking quirks for LUMI lumi.vibration.aq1 (00:15:8d:00:04:83:5e:06)
2022-01-20 11:36:25 DEBUG (MainThread) [zigpy.quirks.registry] Considering <class 'zhaquirks.xiaomi.aqara.vibration_aq1.VibrationAQ1'>
2022-01-20 11:36:25 DEBUG (MainThread) [zigpy.quirks.registry] Found custom device replacement for 00:15:8d:00:04:83:5e:06: <class 'zhaquirks.xiaomi.aqara.vibration_aq1.VibrationAQ1'>

2022-01-20 11:36:26 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.lumi_lumi_vibration_aq1_065e8304_power, old_state=None, new_state=<state sensor.lumi_lumi_vibration_aq1_065e8304_power=44; state_class=measurement, battery_voltage=2.94, unit_of_measurement=%, device_class=battery, friendly_name=LUMI lumi.vibration.aq1 065e8304 power @ 2022-01-20T11:36:26.516517+03:00>>

2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: sensor 0x00158d0004835e06 battery
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: sensor 0x00158d0004835e06 action
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: sensor 0x00158d0004835e06 strength
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: sensor 0x00158d0004835e06 sensitivity
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: sensor 0x00158d0004835e06 angle_x
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: sensor 0x00158d0004835e06 angle_y
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: sensor 0x00158d0004835e06 angle_z
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: sensor 0x00158d0004835e06 voltage
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: sensor 0x00158d0004835e06 linkquality

Sorry but Aqara (Xiaomi) is not good making Zigbee compliant products but they have doing  some . . . But i cant finding the certificate for your device https://csa-iot.org/csa-iot_products/page/2/?p_keywords=Lumi+United&p_type=14&p_certificate.
But its not interesting then your device have being patches for working OK in ZHA.
Then posting code blocks please put ``` on one empty line before and after the code so its not losing its formation.
ZHA have finding:
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: sensor 0x00158d0004835e06 battery
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: sensor 0x00158d0004835e06 action
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: sensor 0x00158d0004835e06 strength
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: sensor 0x00158d0004835e06 sensitivity
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: sensor 0x00158d0004835e06 angle_x
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: sensor 0x00158d0004835e06 angle_y
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: sensor 0x00158d0004835e06 angle_z
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: sensor 0x00158d0004835e06 voltage
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: sensor 0x00158d0004835e06 linkquality
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: select 0x00158d0004835e06 sensitivity
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: binary_sensor 0x00158d0004835e06 vibration
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: device_automation 0x00158d0004835e06 action_vibration
2022-01-20 11:36:19 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: device_automation 0x00158d0004835e06 action_tilt

Some of the functions have device automations that you finding on the device card and the  +  on the side of "Automations".
HA is all about events and if you going to development tools > events > Listen to events and putting in zha_event and clicking start listening you shall getting all events ZHA is getting from your devices like tilt angle and so on.

@MattWestb  It's probably not certified, I have no idea. But you can buy it from any official Xiaomi store.
https://www.zigbee2mqtt.io/devices/DJT11LM.html

Certifying Zigbee devices is costing money and also being member of the alliance so many is not doing it and is putting the Zigbee logo on there products and cont care if the device is working with other system or not.
The latest large is tuya they is one board member but is only certifying products that LIDL and other customer is demanding certificate.
Aqara / Xiaomi was very much problem but then is being better but nearly all ther sensor need quirk for working at all in open systems but the community have learned how they is working and support is normally being fixed but they is doing new versions with changed functions all the time.
Better you is looking if all functions is working OK for your devices then discussing "bad devoices" ;-))

@MattWestb  There is no possibility to handle DROP event. And it is not reporting angles.
Here is what I can see when I click on Automations+

I think both you need listening to zha_events to see them and if making automations you shall triggering it on the information you is getting as events.
Its not realistic making device automations for all possible 360° so you need doing them self.
You can also using template sensors and making sensors that doing the listening on events and you is getting the value in HA GUI.

It seems that there is not a 'direct' way to get the values that you want.
You will need to handle state changes using zha_events. It's not the friendliest way and it's going to force you to struggle with templates and automations, but it's the way to do it.
You can get a lot of information in the HA forums:

https://community.home-assistant.io/t/aqara-vibration-sensor-orientation-to-trigger-automation/240737/7
https://community.home-assistant.io/t/automation-based-on-args/135377
https://community.home-assistant.io/t/xiaomi-vibration-sensor-a-simple-automation-for-detecting-state-on-and-off/230388

I hope this helps you.

@javicalle Thank you for the information. Don't you think though that zha quirk for the device must be improved instead ?

The angles and the drop event are handled as events. The vibration detection gives you a binary sensor. Drop and the angles are events intentionally. The angles are relative and the drop event is momentary. Having entities for these doesn’t make a ton of sense.

@dmulcahey I agree about the drop drop. But for angles Z2M provides sensors which does make sense IMHO

use zha_events for angles. if really need entities, then update a number entity based on zha_event.

@Adminiuga  What is the difference between vibration , tilt, drop and angles ? All are events, in general. Why should only vibration be an entity ?

I have the same sensor in ZHA and for me it works fine. As in the screenshot I have the same entities. As people are mentioning, for angles, vibrations and axes (coming in the next release) you need to read from ZHA event.

I have the problem that the vibration events need 25s to arrive in home assistant.

Not stale to me. I would like to also see a more user friendly solution to automate using Aqara devices.
These (uncertified) devices are used a lot by Zigbee HA users I would assume - and not having a nice way to do automations for it (albeit events or sensors).

I have browsed through the different threads linked here, but I am still a bit confused as to how I can access the orientation from this device. It seems like many of the threads refer to other integrations such as deconz, and thus are not applicable for zha. Is it possible to create a template sensor that updates some numerical values whenever the orientation changes?

Create an automation triggered by zha event and update the multiselect helper accordingly

For anyone with the same use case, I got it working with the following:
  - trigger:
      - platform: event
        event_type: "zha_event"
        event_data:
          device_id: 9f43c386f952703e241d4b18d0504b03
          command: 'current_orientation'
    sensor:
      - name: "Garage door orientation X"
        state: "{{ trigger.event.data.args.X }}"
        unique_id: bc6fa84a-1346-4103-b144-b6cf95f94fb2
      - name: "Garage door orientation Y"
        state: "{{ trigger.event.data.args.Y }}"
        unique_id: 3be9e412-c52e-4676-9948-b7807eec62ac
      - name: "Garage door orientation Z"
        state: "{{ trigger.event.data.args.Z }}"
        unique_id: 5b8c75bf-55aa-4317-8ab3-18394d83b62a

However, the problem now is that the current_orientation events are only being fired around once per minute, so it is really not very useful after all. I assume this is a problem on the Aqara side?

Could that be a sensitivity setting perhaps? IIRC I tested a Vibration sensor in Zigbee2Mqtt and the sensor updated nearly instant

For anyone with the same use case, I got it working with the following:
  - trigger:
      - platform: event
        event_type: "zha_event"
        event_data:
          device_id: 9f43c386f952703e241d4b18d0504b03
          command: 'current_orientation'
    sensor:
      - name: "Garage door orientation X"
        state: "{{ trigger.event.data.args.X }}"
        unique_id: bc6fa84a-1346-4103-b144-b6cf95f94fb2
      - name: "Garage door orientation Y"
        state: "{{ trigger.event.data.args.Y }}"
        unique_id: 3be9e412-c52e-4676-9948-b7807eec62ac
      - name: "Garage door orientation Z"
        state: "{{ trigger.event.data.args.Z }}"
        unique_id: 5b8c75bf-55aa-4317-8ab3-18394d83b62a

However, the problem now is that the current_orientation events are only being fired around once per minute, so it is really not very useful after all. I assume this is a problem on the Aqara side?

I appreciate you posted this! My vibration sensors show the orientation in my project and the update rate is nearly instant. Using Conbee 2 with Raspberry pi and ZHA. No further settings changed. Might be a newer firmware on the vibration sensor/ZHA/Conbee?

So I have this sensor attached to my garage door. I don't care about vibration, I just want Tilt.
Looking through my home assist debug logs, I see a zha firing "Tilt" events, with an angle.
Would it be possible simply expose the current Tilt angle (or last reported angle I guess)? This would really help with creating automatons around it. Please not that my sensor is NOT reporting relative values. It is reporting absolute angle where standing on its edge == 9 degrees and lying flat face down == 180.
`Open garage door:
Apr  6 12:31:43 server1 docker-compose[2470]: homeassistant  | #033[36m2023-04-06 12:31:43.938 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event zha_event[L]: device_ieee=00:15:8d:00:07:09:de:ed, unique_id=00:15:8d:00:07:09:de:ed:1:0x0500, device_id=8bf5abeb52b706beefbaf493466b25c1, endpoint_id=1, cluster_id=1280, command=Tilt, args=degrees=104, params=>#033[0m
Close:
Apr  6 12:32:31 server1 docker-compose[2470]: homeassistant  | #033[36m2023-04-06 12:32:31.561 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event zha_event[L]: device_ieee=00:15:8d:00:07:09:de:ed, unique_id=00:15:8d:00:07:09:de:ed:1:0x0500, device_id=8bf5abeb52b706beefbaf493466b25c1, endpoint_id=1, cluster_id=1280, command=Tilt, args=degrees=18, params=>#033[0m
Open:
Apr  6 13:00:01 server1 docker-compose[2470]: homeassistant  | #033[36m2023-04-06 13:00:01.366 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event zha_event[L]: device_ieee=00:15:8d:00:07:09:de:ed, unique_id=00:15:8d:00:07:09:de:ed:1:0x0500, device_id=8bf5abeb52b706beefbaf493466b25c1, endpoint_id=1, cluster_id=1280, command=Tilt, args=degrees=105, params=>#033[0m
Close:
Apr  6 13:00:34 server1 docker-compose[2470]: homeassistant  | #033[36m2023-04-06 13:00:34.710 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event zha_event[L]: device_ieee=00:15:8d:00:07:09:de:ed, unique_id=00:15:8d:00:07:09:de:ed:1:0x0500, device_id=8bf5abeb52b706beefbaf493466b25c1, endpoint_id=1, cluster_id=1280, command=Tilt, args=degrees=18, params=>#033[0m
`

Would it be possible simply expose the current Tilt angle (or last reported angle I guess)?

It's easier to see & read the events by using the "events" tab in the developer tools and subscribing to zha_event. But there's enough info with what you posted. You can use a template sensor
template:
  - trigger:
      - platform: event
        event_type: "zha_event"
        event_data:
          device_id: 8bf5abeb52b706beefbaf493466b25c1
          command: 'Tilt'
    sensor:
      - name: "Garage Door Tilt"
        state: "{{ trigger.event.data.args.degrees }}"
        unique_id: garage_door_tilt
        attributes:
          time_fired: "{{ trigger.event.time_fired }}"

And if anyone needs the drop sensor, you can use something like this:
template:
  - trigger:
      - platform: event
        event_type: "zha_event"
        event_data:
          device_id: 8bf5abeb52b706beefbaf493466b25c1
          command: 'Drop'
    binary_sensor:
      - name: "Aqara Vibration Sensor Drop Event"
        state: "true"
        unique_id: aqara_vibration_sensor_drop_event
        auto_off: 5
        attributes:
          time_fired: "{{ trigger.event.time_fired }}"


Add all of the STL Collections

multimap
array/list, etc....
for associative containers - include the case for non-basic type for the key

as of 0.1.8, std::multimap
the rest will be added shortly


nil pointer dereference

Not sure yet exactly what's causing it. Caught it when trying to apply EOS config twice (with slight modification on the second time)
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x50 pc=0x622ea7]

goroutine 1 [running]:
github.com/scrapli/scrapligo/driver/network.(*Driver).SendConfig(0xc0001266c0, {0xc000430780, 0x1cd}, {0xc00019fbc0, 0x1, 0x1})
        /home/mk/go/pkg/mod/github.com/scrapli/scrapligo@v0.1.2/driver/network/sendconfig.go:19 +0xc7
github.com/scrapli/scrapligo/cfg.(*EOSCfg).loadConfig(0xc000200930, {0xc000430780, 0xc00019fca0}, {0x0, 0x0}, 0xb0)
        /home/mk/go/pkg/mod/github.com/scrapli/scrapligo@v0.1.2/cfg/aristaeos.go:177 +0x1d3
github.com/scrapli/scrapligo/cfg.(*EOSCfg).LoadConfig(0xc000200930, {0xc000430000, 0xc00019fd68}, 0x8, 0x15)
        /home/mk/go/pkg/mod/github.com/scrapli/scrapligo@v0.1.2/cfg/aristaeos.go:234 +0x24f
github.com/scrapli/scrapligo/cfg.(*Cfg).LoadConfig(0xc0002c49a0, {0xc000430000, 0x1cd}, 0x3, {0x0, 0x0, 0x0})
        /home/mk/go/pkg/mod/github.com/scrapli/scrapligo@v0.1.2/cfg/base.go:421 +0x2cd
main.main()
        /home/mk/scrapli/main.go:115 +0x934
exit status 2

https://github.com/scrapli/scrapligo/blob/f016abc99e1872704b574feab21937ae1767ddb5/driver/network/sendconfig.go#L19

Thanks for reporting this Michael! I'll try to dig in and see if I can reproduce and get to the bottom of it! I'll keep ya posted!

I am fairly sure that this occurs when we hit the configuration session limit. I reproduced and got a similar panic after intentionally creating 5 config sessions (my vEOS instance at least has a 5 config session limit).  I'm calling it for today, but wanted to jot this note down. ive been meaning to add some "smarts" around this config session limit for eos, but I want to make sure whatever gets added/changed is as minimal as possible (so as to not add a bunch of eos specific code if at all possible).... will poke around on this in the next week or so and keep ya posted.
carl


Add some more logging to ModelView components

Pull Request Test Coverage Report for Build 360738300

18 of 19 (94.74%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.01%) to 41.298%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/sql/workbench/browser/modelComponents/table.component.ts
1
2
50.0%

Totals

Change from base Build 360662707:
0.01%

Covered Lines:
21753

Relevant Lines:
48363

💛  - Coveralls


Downstream/selection classification

Modified components/CaseRow.js to change the Classification field to a drop down with the choices of Felony or Misdemeanor using SelectProps and options.
IDE automatically applied some stylistic changes as well to the file.

This solves issue #58


Pylint disable should be followed by enable

There is a problem, which might have high severity:
A lot of files disable pylint messages, but don't enable them in the end -- this potentially might cause a missed warning if several files are imported, because # pylint disable is a global disable.
Here are all the files that modify the pylint related to the wildcard-import
Here is an example file that doesn't revert the modifications
There might be other wildcards that are disabled without reverting the changes

Do you have a PR that you could send?

I don't -- I might be able to look into the fix over the weekend

Feel free to send CC me on the PR when you're ready! Thanks.


Added index0 for Twig compatiliblity

Just to add some compatibility between pebble and twig:
Twig index is 1 based :/ The 0 based index is called index0
(historical issue)

Actually your code won't work as index0 and index would be the same.
You should do this instead. Am I right ?
loop.put("index0", index);
loop.put("index", ++index);

No, this is intended but I didn't made myself clear :)
pebble's loop.index is zero base but twig is 1 based.
To circumvent the issue, twig added a index0.
My suggestion is to add a compatible statement explicitly named index0.
In the other side, I made a pull request on Twig side to also add a index1 and revindex1 to have both explicit (0 and 1 indices) and the implicit one more like implementation dependent :)

So index0 and index are the same ? The purpose is just to be like twig ?

sorry I edited before I saw your second reply.
My intention was to make it compatible without breaking current uses of loop.index :)

Hi guys
If I may chime in here. In terms of pebble core. Shouldn't the design
philosophy be as pebble is pebble and it isn't necessarily directly
compatible with any other template language?
I for example started using pebble because I worked with python's Django
before and fell in love with its templating language.
Pebble is already so extensible and unless a change adds real value, I
would vote to keep the core concise and simple? :)
On Nov 22, 2015 6:21 PM, "Damien Degois"<EMAIL_ADDRESS>wrote:

sorry I edited before I saw your second reply.
My intention was to make it compatible without breaking current uses of
loop.index :)
—
Reply to this email directly or view it on GitHub
https://github.com/mbosecke/pebble/pull/132#issuecomment-158775339.

I agree it isn't a copy of twig but inspired. It doesn't add anything new.

I totally get it.
I just thought that making it compatible with twig, as it doesn't require a huge change nor mess up that much with the code, would be a really good point that worthed a try.

Just let @mbosecke decide :)

@ebussieres Your patch is perfectly fine and ensure a complete compatibility with Twig and Jinja if you're not afraid of altering the index behavior.

I agree with the sentiment that the overall design philosophy of Pebble is that it is inspired by Twig and Django but will deviate in an attempt to be better.
Saying that, I see where you are coming from, @babs, and I appreciate the pull request. My biggest concern with this change is the sheer amount of conversations I will have from this point on explaining to people why there are two "index" variables that have the same value. I don't think the compatibility factor alone adds enough value to outweigh the potential confusion.

Ok thanks.
I think I'll go for a filter instead like norm_index where its behavior will change based on the implementation then.


Error on closing Parallel Consumer

When trying to close parallel Consumer using parallelConsumer.close(),
Getting below error:
[INFO ] 2022-10-20 23:03:00.661 [Thread-3] communication.kafka.KafkaConnector - Closing ParallelConsumer for url: localhost:9092, topic: MY-TOPIC-1
[ERROR] 2022-10-20 23:03:30.662 [pc-control] io.confluent.parallelconsumer.internal.BrokerPollSystem - **Execution or timeout exception waiting for broker poller thread to finish**
java.util.concurrent.TimeoutException: null
	at java.util.concurrent.FutureTask.get(FutureTask.java:205) ~[?:1.8.0_252]
	at io.confluent.parallelconsumer.internal.BrokerPollSystem.closeAndWait(BrokerPollSystem.java:244) ~[service-1.0.0.jar:?]
	at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.doClose(AbstractParallelEoSStreamProcessor.java:515) ~[service-1.0.0.jar:?]
	at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.controlLoop(AbstractParallelEoSStreamProcessor.java:698) ~[service-1.0.0.jar:?]
	at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.lambda$supervisorLoop$5(AbstractParallelEoSStreamProcessor.java:639) ~[service-1.0.0.jar:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_252]
	at java.lang.Thread.run(Thread.java:748) ~[?:1.8.0_252]

[ERROR] 2022-10-20 23:03:30.676 [pc-control] io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor - **Error from poll control thread, will attempt controlled shutdown, then rethrow. Error: null**
java.util.concurrent.TimeoutException: null
	at java.util.concurrent.FutureTask.get(FutureTask.java:205) ~[?:1.8.0_252]
	at io.confluent.parallelconsumer.internal.BrokerPollSystem.closeAndWait(BrokerPollSystem.java:244) ~[service-1.0.0.jar:?]
	at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.doClose(AbstractParallelEoSStreamProcessor.java:515) ~[service-1.0.0.jar:?]
	at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.controlLoop(AbstractParallelEoSStreamProcessor.java:698) ~[service-1.0.0.jar:?]
	at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.lambda$supervisorLoop$5(AbstractParallelEoSStreamProcessor.java:639) ~[service-1.0.0.jar:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_252]
	at java.lang.Thread.run(Thread.java:748) ~[?:1.8.0_252]

[ERROR] 2022-10-20 23:03:30.682 [Thread-3] io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor - **Execution or timeout exception while waiting for the control thread to close cleanly (state was closing). Try increasing your time-out to allow the system to drain, or close without draining.**
java.util.concurrent.ExecutionException: java.lang.IllegalStateException: Can't commit - not running (state: closed
	at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_252]
	at java.util.concurrent.FutureTask.get(FutureTask.java:206) ~[?:1.8.0_252]
	at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.waitForClose(AbstractParallelEoSStreamProcessor.java:464) ~[service-1.0.0.jar:?]
	at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.close(AbstractParallelEoSStreamProcessor.java:446) ~[service-1.0.0.jar:?]
	at io.confluent.parallelconsumer.internal.DrainingCloseable.closeDontDrainFirst(DrainingCloseable.java:60) ~[service-1.0.0.jar:?]
	at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.close(AbstractParallelEoSStreamProcessor.java:424) ~[service-1.0.0.jar:?]
	at communication.kafka.KafkaConnector.stop(KafkaConnector.java:935) ~[service-1.0.0.jar:?]
	at communication.kafka.KafkaClient.unsubscribe(KafkaClient.java:74) ~[service-1.0.0.jar:?]
Caused by: java.lang.IllegalStateException: Can't commit - not running (state: closed
	at io.confluent.parallelconsumer.internal.BrokerPollSystem.retrieveOffsetsAndCommit(BrokerPollSystem.java:315) ~[service-1.0.0.jar:?]
	at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.commitOffsetsThatAreReady(AbstractParallelEoSStreamProcessor.java:1089) ~[service-1.0.0.jar:?]
	at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.doClose(AbstractParallelEoSStreamProcessor.java:511) ~[service-1.0.0.jar:?]
	at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.lambda$supervisorLoop$5(AbstractParallelEoSStreamProcessor.java:642) ~[service-1.0.0.jar:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_252]
	... 1 more

[ERROR] 2022-10-20 23:03:30.684 [Thread-3] communication.kafka.KafkaConnector - **Error closing parallelConsumer
java.util.concurrent.ExecutionException: java.lang.IllegalStateException: Can't commit - not running (state: closed**
	at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_252]
	at java.util.concurrent.FutureTask.get(FutureTask.java:206) ~[?:1.8.0_252]
	at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.waitForClose(AbstractParallelEoSStreamProcessor.java:464) ~[service-1.0.0.jar:?]
	at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.close(AbstractParallelEoSStreamProcessor.java:446) ~[service-1.0.0.jar:?]
	at io.confluent.parallelconsumer.internal.DrainingCloseable.closeDontDrainFirst(DrainingCloseable.java:60) ~[service-1.0.0.jar:?]
	at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.close(AbstractParallelEoSStreamProcessor.java:424) ~[service-1.0.0.jar:?]
	at communication.kafka.KafkaConnector.stop(KafkaConnector.java:935) ~[service-1.0.0.jar:?]
	at communication.kafka.KafkaClient.unsubscribe(KafkaClient.java:74) ~[service-1.0.0.jar:?]
	at BaseremoveKafkaListener(Basejava:133) ~[service-1.0.0.jar:?]
	at group.handler.MicroServiceHandler.removeAllGroups(MicroServiceHandler.java:92) ~[service-1.0.0.jar:?]
	at group.handler.MicroServiceHandler.doHandle(MicroServiceHandler.java:66) ~[service-1.0.0.jar:?]
	at group.handler.MicroServiceHandler.doHandle(MicroServiceHandler.java:19) ~[service-1.0.0.jar:?]
	at communication.message.handler.MessageHandler.handle(MessageHandler.java:28) ~[service-1.0.0.jar:?]
	at communication.message.processor.MessageProcessor.process(MessageProcessor.java:17) ~[service-1.0.0.jar:?]
	at communication.kafka.KafkaClient$KafkaProcessingInterfaceImpl.process(KafkaClient.java:89) ~[service-1.0.0.jar:?]
	at communication.kafka.KafkaMessageProcessingTask.run(KafkaMessageProcessingTask.java:26) ~[service-1.0.0.jar:?]
	at communication.kafka.KafkaConnector$3.run(KafkaConnector.java:463) ~[service-1.0.0.jar:?]
	at java.lang.Thread.run(Thread.java:748) ~[?:1.8.0_252]
Caused by: java.lang.IllegalStateException: Can't commit - not running (state: closed
	at io.confluent.parallelconsumer.internal.BrokerPollSystem.retrieveOffsetsAndCommit(BrokerPollSystem.java:315) ~[service-1.0.0.jar:?]
	at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.commitOffsetsThatAreReady(AbstractParallelEoSStreamProcessor.java:1089) ~[service-1.0.0.jar:?]
	at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.doClose(AbstractParallelEoSStreamProcessor.java:511) ~[service-1.0.0.jar:?]
	at io.confluent.parallelconsumer.internal.AbstractParallelEoSStreamProcessor.lambda$supervisorLoop$5(AbstractParallelEoSStreamProcessor.java:642) ~[service-1.0.0.jar:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_252]
	... 1 more

What version?

What version?

<IP_ADDRESS>
@astubbs we see multiple different types of errors due to which parallelconsumer shutdown happens, but our java process still keeps running. Is there any way through which we can shutdown out process, maybe we can get event from some kind of shutdown listener on parallelConsumer?

Yes, you can periodically call the isClosedOrFailed method.
A shutdown listener is an interesting suggestion - feel free to create a feature request. There isn't anything like that atm.
Please update to the latest version, then try again?

We're also about to release a metrics package which might be relevant - so stay tuned on:

#27

We're also about to release a metrics package which might be relevant - so stay tuned on:

sure

Yes, you can periodically call the isClosedOrFailed method.

Just need to confirm one thing is
this method only available in ParallelEoSStreamProcessor(AbstractParallelEoSStreamProcessor) and not at interface level ParallelConsumer or ParallelStreamProcessor?
If yes then we will have to cast it to ParallelEoSStreamProcessor

Ah yea - will have to fix thatOn 3/11/2022, at 5:04 PM, jatindersthind @.***> wrote:
We're also about to release a metrics package which might be relevant - so stay tuned on:
sure
Yes, you can periodically call the isClosedOrFailed method.
Just need to confirm one thing is
this method only available in ParallelEoSStreamProcessor(AbstractParallelEoSStreamProcessor) and not at interface level ParallelConsumer or ParallelStreamProcessor?
If yes then we will have to cast it to ParallelEoSStreamProcessor
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

An you include earlier logs? The errors you showed were the errors from trying to shutdown when the client was already closed. I can add some checks to avoid those.

stale and most likely addressed by fixes to closing logic. Reopen if needs re-visited.


How to Use pg_activity tools for managed database (postgreSQL from RDS amazon and RDS alyun)

Hi
I tried to use this tool for RDS posgreSQL Alibaba version PostgreSQL 10.0. As we know that we don't have root/super user privilege if we use RDS instance, while pg_activity need this privilege to execute the command.
Here is the privilege from RDS instance that I have.

And here is the issue that comes up.

Any alternative for my issue or did you guys experience the same issue ?

Hi,
Did you try the --rds switch ?
Benoit

Oh thanks.
It works, I did not read the option before.
:)


New: option urls, .env file; fixes: ESLint 9, expiration test

fixes #13
fixes #10
fixes #12
supports .env file, so it's easy to define the API_KEY
small ESLint fixes
deleted node_modules folder from repository, it's used locally only and should not be committed to GitHub

After you merge it, I can share some examples how to use the new urls option in workflow.

BTW do you need to commit the distr folder? Perhaps, it should be removed, as it does not contain source code and therefore has no value for being committed?

I created it a few years ago and I remember that back then it was suggested to commit node_modules in a github action repository. I can see that they changed the example repo:
https://github.com/actions/hello-world-javascript-action/issues/12
but it seems that the dist dir is still needed.

Ok, I didn't touch the dist folder 😃

Let me remove node_modules separately to leave only the interesting stuff in this PR.

Done. Please rebase with the current master. Sorry for the inconvenience. Of course you can ignore dist/ conflicts and simply rebuild the files.

OK. I will do that later in a few hours...

@McCzarny ready to merge 😄

Tested locally and seems to work fine.


Working basic renderer

Issue needs to implement:

[ ] Visibility variable
[ ] Register component
[ ] Unregister component (just changes visibility value)
[ ] implementation in mainloop
[ ] Callbacks to component defined funtions to render

Works like a charm


Switch to new OpenEye BETA toolkit.

This switches travis to the new OpenEye  2015.Oct BETA toolkit and updates binstar to anaconda.

@jchodera This switches everything to the beta, correct? While I'm usually all for new features and beta testing, my fear is we'd make debugging complicated. We might not be able to spot if we broke something, or there is something broken on the OpenEye side.  Perhaps we could/should set up a travis build matrix with different OpenEye versions?

I like Bas's suggestion here. Otherwise, a new commit may raise red flags
simply because OpenEye broke something, and we may spend a good deal of
time trying to find our mistake. Seems like it would be nice to be testing
BOTH OE versions since that would immediately tell us the problem is with
the beta.
Thanks.
On Fri, Sep 11, 2015 at 9:28 AM, Bas Rustenburg<EMAIL_ADDRESS>wrote:

@jchodera https://github.com/jchodera This switches everything to the
beta, correct? While I'm usually all for new features and beta testing, my
fear is we'd make debugging complicated. We might not be able to spot if we
broke something, or there is something broken on the OpenEye side. Perhaps
we could/should set up a travis build matrix with different OpenEye
versions?
—
Reply to this email directly or view it on GitHub
https://github.com/choderalab/openmoltools/pull/151#issuecomment-139591766
.

--
David Mobley
Associate Professor
Department of Pharmaceutical Sciences
Department of Chemistry
3134B Natural Sciences I
University of California, Irvine
Irvine, CA 92697
<EMAIL_ADDRESS>work<PHONE_NUMBER>
cell<PHONE_NUMBER>

Thinking one step beyond that, not everyone can use the latest version everywhere, for reasons of licensing or compatibility with other tools. Since it's not a simple matter of typing conda update openeye to get the latest version either, we might want to explicitly track the OpenEye versions that work, and that we choose to support.

Perhaps we can discuss that further on the issue tracker. This PR looks okay, with the exception that it's not running openeye tests. Not sure if that is expected, but if we switch versions, it really should be testing those: https://travis-ci.org/choderalab/openmoltools/jobs/79866936#L1635

The idea here is that we should be testing against the new OpenEye tools to make sure that an OpenEye toolkit release won't break everything when users upgrade.  But I like the suggestion that we should test against both production and beta versions.
OpenEye tests should definitely be running on travis---I'll try to figure out why they aren't.

We were testing twice, for some reason---once in the conda dev recipe (which couldn't run OpenEye tools) and once again after that.  I've cut this down to one test using the OpenEye tools.

We are also hopefully now testing with both production and beta openeye tools.

I'm not sure why the OpenEye tests are still being skipped...

The OpenEye tests cannot be run in pull requests because that would potentially expose encrypted file information.  I'll merge this since I think things are working with both old/new OpenEye tests now.


Add better handle validation

Its not currently a huge issue, but we should add better handle validation to the bgs.
The relevant typescript code to cop is here: https://github.com/bluesky-social/atproto/blob/main/packages/identifier/src/handle.ts

The indigo/atproto/identity package is increasingly pretty hardened, but I think the other handle resolution implementation in indigo is also better now. Could probably close this issue?