prefix HTTP automatically to the URL

Originally reported on Google Code with ID 314
What steps will reproduce the problem?
1. paste URL without http:// or https:// in URL input at Request page
2.  What do you see instead?

Existing issue : If I enter URL (in URL input field) like localhost/myproject, it gives
me error as "Status 0 NO RESPONSE"

Expected : Notify user that your URL has no http or https etc..

OR URL should be http://localhost/myproject

On what operating system, browser and browser version?
Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/40.0.2214.111
Chrome/40.0.2214.111 Safari/537.36

Please provide any additional information below.

you can automatically detect and add http to the URL if user has not specified http
or https

Reported by reach.mangeshsathe on 2015-06-25 06:59:40

It will be fixed.
I will add an options in the settings page to choose default protocol (https: or http where default is https) and relative URLs will be resolved adding the protocol.

The app will prefix the URL with https protocol.
I decided not adding an option to choose default prefix because it will unnecessarily complicate the UI and code. HTTPS will be added by default instead of HTTP because the internet is shifting towards the HTTPS network and most of APIs uses https.


Add token/program2

As mentioned at https://github.com/solana-labs/solana-program-library/issues/230#issuecomment-674283283, token/program is now the first version of the token program (previously called "spl-token 1.0") that has already been deployed to mainnet-beta.  token/program/src/processor.rs in particular should now be considered immutable.
token/program2 is the second version of the token program (previously called "spl-token 1.1") where new development occurs and will be deployed to mainnet-beta at some point in the future.
This PR also backs out #210 from token/program, which does not exist in the deployed program.  This will be a feature of program2.
Fixes #230
Fixes #212

@jackcmay - wdyt?


changelogPreset somehow breaks with deps update

Describe the bug
With no configuration changes, changelogPreset just stop working by time while upgrading the deps.
A lot of my repos behave the same, and https://github.com/mdit-plugins/mdit-plugins can be a good example (as it has only a few commits)
While releasing v0.13.1, the changelog still seems working: https://github.com/mdit-plugins/mdit-plugins/commit/a46e5898319b34a9f9558e50cb0094ebf8bf4b22, but when releasing v0.13.2 it breaks, see https://github.com/mdit-plugins/mdit-plugins/commit/d650603fee56f7b9ca0b246b6e913d9d6078b60a
The comparison can be found at https://github.com/mdit-plugins/mdit-plugins/compare/a46e5898319b34a9f9558e50cb0094ebf8bf4b22...d650603fee56f7b9ca0b246b6e913d9d6078b60a
I only bump lerna to 3.9.1 from 3.8.0 and some other deps (no major) besides source code changes
One interesting thing is that I am not finding any related changes in changelog.

Make sure you that you are not using latest version of<EMAIL_ADDRESS>because I don't support it yet since they had huge breaking changes in conventional-changelog and I couldn't migrate to their latest major yet and I mentioned it in
https://github.com/lerna-lite/lerna-lite/tree/main/packages/version#--changelog-preset
on another end, I migrated couple of deps to smaller ones, I didn't hear anyone else complaining about them yet but some of these changes are

from globby to tinyglobby #941

from chalk to picocolors to later tinyrainbow #940 then #942

inquirer to v4 #944

--scope filtering in latest version #948

So, I'm not sure if the migration above have any impacts on your side, it didn't impact anything on my side but I use regular blobs, so if you use complex blobs then maybe that change affects you!?

Thanks, there is not such a warning as I upgrade to v8 at first time and everything was working for me then.
I will try to downgrade to v7 to see if it solves the problem.

There's huge breaking changes in their implementation and they don't provide any migration guide or anything, it's really difficult to upgrade to their latest version and I don't have time to spend on this at the moment (I spent couple of hours before and couldn't upgrade). But yes the biggest changes is related to changelog presets, if you use any (it looks like you are), then you will most probably face problems.

Hi, things are still not working when I trying to downgrade to v7, see https://github.com/mdit-plugins/mdit-plugins/tree/bug-report
I ran pnpm exec conventional-changelog --preset conventionalcommits --release-count 0 --outfile ./CHANGELOG.md --verbose, but the generated result is obviously broken.

It looks like you're installing conventional-changelog-conventionalcommits but you're not using it in your lerna.json config since you use "name": "conventionalcommits",. However I never tried that one myself, whenever I use a preset, I typically go with the conventional-changelog-conventionalcommits not the conventionalcommits. I also don't know all these configs, the only reason I use conventional-changelog-conventionalcommits is because it supports Breaking Major with the ! symbol while not supported in the default angular preset... so config wise, you should probably check on google or in the Lerna GitHub for configuration

I am still debuging things. At least I can tell that everything was fine when I try to hard reset to v0.13.1 tag in my repo, and it brokens with just a pnpm up -r. :(

It looks like you're installing conventional-changelog-conventionalcommits but you're not using it in your lerna.json config since you use "name": "conventionalcommits",. However I never tried that one myself, whenever I use a preset, I typically go with the conventional-changelog-conventionalcommits not the conventionalcommits. I also don't know all these configs, the only reason I use conventional-changelog-conventionalcommits is because it supports Breaking Major with the ! symbol while not supported in the default angular preset... so config wise, you should probably check on google or in the Lerna GitHub for configuration for the correct setup/config

Thanks for the advice, I will give a try.

Hi, I finally succeeded in regenerating the existing changelog and make the dry run works after downgrade to v7, (details https://github.com/mdit-plugins/mdit-plugins/commit/7b80c385c7a873702c99152fa0c3f587e3157455), thanks for the help.

Make sure you that you are not using latest version of<EMAIL_ADDRESS>because I don't support it yet since they had huge breaking changes in conventional-changelog and I couldn't migrate to their latest major yet and I mentioned it in
https://github.com/lerna-lite/lerna-lite/tree/main/packages/version#--changelog-preset

@ghiscoding Thanks for pointing that out.
I get that migrating to a major version with breaking changes can be a tough nut to crack. Just curious—has any progress been made on adding support for<EMAIL_ADDRESS>or is it still on the back burner?

@izikl  no progress made, I don't have time to spend on this and again this latest changelog major is hard to understand. If you want some progress made then I suggest you contribute to the project 😉


Issues Generating Client After go mod tidy

Disclaimer: I am not sure how to fix this or if this is a issue with go mod.
Describe the bug

Installed the genqlient: go get github.com/Khan/genqlient
go.mod contains several indirect dependencies required by go generate . (see below)
I can run go generate . successfully
Then I run go mod tidy, which removes all the required indirect dependencies of genqlient (see below).
Now I can't run go generate . anymore, because dependencies are missing (see error below)

Error:
../../go/pkg/mod/github.com/vektah/gqlparser/v2@v2.1.0/validator/suggestionList.go:7:2: missing go.sum entry for module providing package github.com/agnivade/levenshtein (imported by github.com/vektah/gqlparser/v2/validator); to add:
        go get<EMAIL_ADDRESS>../../go/pkg/mod/github.com/!khan/genqlient@v0.3.0/generate/main.go:13:2: missing go.sum entry for module providing package github.com/alexflint/go-arg (imported by github.com/Khan/genqlient/generate); to add:
        go get<EMAIL_ADDRESS>../../go/pkg/mod/github.com/!khan/genqlient@v0.3.0/generate/generate.go:19:2: missing go.sum entry for module providing package golang.org/x/tools/imports (imported by github.com/Khan/genqlient/generate); to add:
        go get<EMAIL_ADDRESS>../../go/pkg/mod/github.com/!khan/genqlient@v0.3.0/generate/config.go:10:2: missing go.sum entry for module providing package gopkg.in/yaml.v2 (imported by github.com/Khan/genqlient/generate); to add:
        go get<EMAIL_ADDRESS>main.go:25: running "go": exit status 1

To Reproduce

Download attached zip: go-mod-tidy-issue.zip
Extract archive
Run go generate .
A new file generated.go should be created (you can also run go run . to verify that the generated client works)
Run go mod tidy
Check go.mod, most indirect dependencies have been removed
Run go generate . again
Error should appear

Expected behavior
When running go mod tidy required dependencies are not removed.
genqlient version
v0.3.0
Additional context
go.mod after go get github.com/Khan/genqlient:
module genqclientbug

go 1.17

require github.com/Khan/genqlient v0.3.0

require (
	github.com/agnivade/levenshtein v1.0.3 // indirect
	github.com/alexflint/go-arg v1.4.2 // indirect
	github.com/alexflint/go-scalar v1.0.0 // indirect
	github.com/vektah/gqlparser/v2 v2.1.0 // indirect
	golang.org/x/mod v0.4.2 // indirect
	golang.org/x/sys v0.0.0-20210510120138-977fb7262007 // indirect
	golang.org/x/tools v0.1.5 // indirect
	golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 // indirect
	gopkg.in/yaml.v2 v2.4.0 // indirect
)

go.mod after running go mod tidy:
module genqclientbug

go 1.17

require github.com/Khan/genqlient v0.3.0

require github.com/vektah/gqlparser/v2 v2.1.0 // indirect

go-mod-tidy-issue.zip

Thanks for the report!  This looks to be golang/go#45552; see in particular this comment.  In short, if you want to be able to go run on newer Go you'll need to have a (blank) import of genqlient's entrypoint in a special tools.go file somewhere in your module so go mod tidy doesn't prune it.  (This only matters on newer Go which is more aggressive about its pruning, such that the import of github.com/Khan/genqlient/graphql no longer suffices as it doesn't import all the third-party deps.)
This is ultimately a Go modules problem so we can't fix it, but I'll leave this issue since we should probably mention it in genqlient docs.

@benjaminjkraft Thank you for the help. Very much appreciated. I will check if the provided workaround int he comment works 👍

Just came back here and can report that the workaround did in fact worked.
I use a tools.go with the following code:
//go:build tools
// +build tools

package client

import (
	_ "github.com/Khan/genqlient"
)

This fixed the issue.


Instance crashes here and there.

npm-debug.log.txt
Admits having this deployed a created its own query login.
I have another bot accessing the querry. Via its own query login also.
I have no idea if this is relational but steam bot crashes after a day or so.
`/home/ubuntu/steam-ts/node_modules/async/dist/async.js:837
if (fn === null) throw new Error("Callback was already called.");
^
Error: Callback was already called.
at /home/ubuntu/steam-ts/node_modules/async/dist/async.js:837:34
at Object.cb (/home/ubuntu/steam-ts/lib/queryusers.js:43:29)
at LineInputStream. (/home/ubuntu/steam-ts/node_modules/node-teamspeak/index.js:170:35)
at emitOne (events.js:96:13)
at LineInputStream.emit (events.js:188:7)
at LineInputStream.line (/home/ubuntu/steam-ts/node_modules/node-teamspeak/node_modules/line-input-stream/lib/line-input-stream.js:8:8)
at Array.forEach (native)
at Socket. (/home/ubuntu/steam-ts/node_modules/node-teamspeak/node_modules/line-input-stream/lib/line-input-stream.js:36:9)
at emitOne (events.js:96:13)
at Socket.emit (events.js:188:7)
npm ERR! Linux 3.13.0-92-generic
npm ERR! argv "/usr/bin/nodejs" "/usr/bin/npm" "start"
npm ERR! node v6.10.2
npm ERR! npm  v3.10.10
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>start: node lib/launch.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script 'node lib/launch.js'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the steam-ts package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node lib/launch.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs steam-ts
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls steam-ts
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /home/ubuntu/steam-ts/npm-debug.log`

I will attempt to resolve this issue in a couple of days, I will come back to this in around a week.

Would a perl script interfere with npm scripts.

This is a bug in my code, has nothing to do with your scripts. I am currently a bit busy but I will fix this as soon as I can.

I'm getting this issue to Only from today tho

Fixed as of 9b3a358f30364bd7e111a32e12c921e73daebf43

Sorry for bringing this back up. Having to use PM2 to keep the bot alive. Its crashing 'randomly'.
Seeing the same error as above, even after the fix #9b3a358
at Socket.<anonymous> (/home/ts3bot/steam-ts/node_modules/line-input-stream/lib/line-input-stream.js:36:9)
at Socket.emit (events.js:182:13)
at addChunk (_stream_readable.js:283:12)
at readableAddChunk (_stream_readable.js:264:11)
Error: Callback was already called.
at /home/ts3bot/steam-ts/node_modules/async/dist/async.js:837:34
at Object.cb (/home/ts3bot/steam-ts/lib/queryusers.js:49:29)
 at LineInputStream.<anonymous> (/home/ts3bot/steam-ts/node_modules/node-teamspeak/index.js:170:35)
at LineInputStream.emit (events.js:182:13)
at LineInputStream.line (/home/ts3bot/steam-ts/node_modules/line-input-stream/lib/line-input-stream.js:8:8)
at Array.forEach (<anonymous>)
at Socket.<anonymous> (/home/ts3bot/steam-ts/node_modules/line-input-stream/lib/line-input-stream.js:36:9)
at Socket.emit (events.js:182:13)
at addChunk (_stream_readable.js:283:12)
at readableAddChunk (_stream_readable.js:264:11)

PM2 lists this error 7 times, and also shows it's restarted the steam-ts bot 7 times, so concluding that this error is causing it to crash.


Docker-Compose send-command

I'm trying to use the send-command to set gamerules, for example pvp = false
I am using docker-compose:
version: '3.4'

services:
  bds:
    image: itzg/minecraft-bedrock-server
    container_name: "MC_123"
    privileged: true
    restart: always
    ports:
      - 11111:19132/udp
    environment:
      SERVER_NAME: "Test server"
      EULA: "TRUE"
      GAMEMODE: "survival"
      DIFFICULTY: "easy"
      VIEW_DISTANCE: "16"
      ALLOW_CHEATS: "true"
      WHITE_LIST_USERS: "me"
    volumes:
      - ./data:/data
    stdin_open: true
    tty: true

then sending:
docker exec MC_123 send-command gamerule pvp

but I'm getting:
OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "send-command": executable file not found in $PATH: unknown

Any ideas?

I had performed a pull, but just to make sure I changed to yml to specify ":latest" and now its all working!
Thanks for all your great work!


Admins can administer all tenants, not just their own

Currently permissioning doesn't take tenants into account - that needs to change! Verify that admins can only admin grants / users / etc within their own tenant.

See previous product discussions here: https://docs.google.com/document/d/1DG6YO0eiAiu9sFAsGjBQaCb1tGucmHkDsoB2i8OqCDU/edit#bookmark=id.60cjr2f8enx7

Closing this issue as a duplicate of #72.


Where can I find release notes for v2.2.0, 1, 2, 3 and v2.3.0?

I've searched for them every where and can't find them.

I've found this changelog https://github.com/quartz-scheduler/quartz/blob/master/docs/changelog.adoc but it looks more like the set of jira issues moved to done than an upgrade guide.
About the v2.3.2, there's no mention in the doc of the official website.


Walk-off leaving method

Is your feature request related to a problem? Please describe.
No, more of an annoyance where you need to press LSHIFT and walk out the doors to get off the train
Describe the solution you'd like
When you walk out the doors, you get off the train without pressing LSHIFT
Additional Information
Add any other context or screenshots about the feature request here.

It has already implemented in the new Beta-5 unofficial releases

Where can I download those?

Where can I download those?

Join our Discord server for preview versions:
https://discord.gg/qPHTFvs3Kj

This is added in beta-5. Please let me know if you encounter issues, thanks!


Please write in readme which dependancies (libs) do you use.

the dependencies can be checked here build.gradle, so i won't add it until finish other features, actually working on the persistence layer, when compleded i will add dependencies into README, please be patient and check build.gradle file until that

test study


Add completion support for annotations within the same module

Purpose

WIth this, add the following improvements

Completion within the default function arguments
Completion and suggestions for the annotations defined in the same module

Check List

[x] Read the Contributing Guide
[ ] Required Balo version update
[ ] Updated Change Log
[x] Checked Tooling Support
[x] Added necessary tests

[x] Unit Tests
[ ] Spec Conformance Tests
[x] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

Merging #16273 into jballerina will increase coverage by 0.09%.
The diff coverage is 76.41%.

@@               Coverage Diff                @@
##             jballerina   #16273      +/-   ##
================================================
+ Coverage         15.44%   15.53%   +0.09%
- Complexity         3564     3600      +36
================================================
  Files              1468     1468
  Lines             71518    71573      +55
  Branches           8584     8603      +19
================================================
+ Hits              11049    11122      +73
+ Misses            59466    59448      -18
  Partials           1003     1003

Impacted Files
Coverage Δ
Complexity Δ

...erinalang/langserver/completions/util/Snippet.java
94.79% <100%> (+0.05%)
3 <0> (ø)
:arrow_down:

...g/ballerinalang/langserver/AnnotationNodeKind.java
100% <100%> (ø)
1 <0> (ø)
:arrow_down:

...providers/scopeproviders/ServiceScopeProvider.java
90% <100%> (+0.81%)
9 <0> (+1)
:arrow_up:

...org/ballerinalang/langserver/SnippetGenerator.java
99.23% <100%> (+0.01%)
87 <6> (+1)
:arrow_up:

...rs/scopeproviders/ObjectTypeNodeScopeProvider.java
22.58% <100%> (+0.47%)
6 <0> (ø)
:arrow_down:

...ngserver/completions/spi/LSCompletionProvider.java
86.03% <59.09%> (-0.13%)
96 <0> (+1)

...lerinalang/langserver/completions/TreeVisitor.java
75.69% <60%> (-0.38%)
114 <1> (+3)

...letions/util/sorters/ServiceContextItemSorter.java
70.58% <61.53%> (+66.24%)
6 <4> (+5)
:arrow_up:

...providers/AnnotationAttachmentContextProvider.java
81.53% <81.81%> (+0.28%)
26 <16> (+16)
:arrow_up:

...lerinalang/langserver/common/utils/CommonUtil.java
75.39% <85.71%> (+0.44%)
154 <1> (+5)
:arrow_up:

... and 4 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9537fa6...bdca7a1. Read the comment docs.


openrazer: 2.7.0 -> 2.8.0

Motivation for this change
v2.8.0 Changelog
Support for several new devices added
Unsure if related to #92959 but figured it can/should be updated, anyway.
Things done
Bumped from 2.7.0 -> 2.8.0

cc @algram

I would like to check if this changes fixes my problem. How would I best test this locally before the merge?
Thanks!

I would like to check if this changes fixes my problem. How would I best test this locally before the merge?
Thanks!

I'm lazy and typically use gh for checking out PRs
e.g. nix run nixos.gitAndTools.gh --command gh pr checkout 93275 from a local nixpkgs repo
That aside, from the root of a local nixpkgs repository (with the PR checked out), one way is to run nixos-rebuild switch -I nixpkgs=.
This should rebuild your system with the main channel referencing the local nixpkgs repo instead.
There are probably better ways to do it, but this is how I currently test module updates.

Thanks! I tested it and it works on my end. The mouse gets recognized and I can communicate with it via DBUS.

Curious, any other Razer users with merge/write permissions?
Not sure what else I can do (or who would be best to ping) aside from e.g.
@GrahamcOfBorg build openrazer-daemon
or etc


Update min version of net-http-persistent to 3.1.0

Proposed changes
Bump min version of net-http-persistent to avoid issue when running on windows. See https://github.com/drbrain/net-http-persistent/pull/90 and https://github.com/splunk/fluent-plugin-splunk-hec/pull/64
Types of changes
What types of changes does your code introduce?
Put an x in the boxes that apply

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist
Put an x in the boxes that apply.

[x] I have read the CONTRIBUTING doc
[x] I have read the CLA
[ ] I have added tests that prove my fix is effective or that my feature works
[x] I have added necessary documentation (if appropriate)
[x] Any dependent changes have been merged and published in downstream modules

this was updated at https://github.com/splunk/fluent-plugin-splunk-hec/commit/0766b05188126d2e753aa106cbbbc1996a7dec43#diff-e79a60dc6b85309ae70a6ea8261eaf95

right. thank you for pointing this out. closing


"Unable to cast" error when using a luis intention

Describe the bug
Every time a message is evaluated by a LUIS trigger, the following error is returned:
Unable to cast object of type ‘System.Int64’ to type ‘System.Int32’.
This project was created in version 1.4.1 and converted to version 2.0. In the previous version the project works without any problems.
Version
Version:  2.0.0
Electron: 8.2.4
Chrome: 80.0.3987.165
NodeJS: 12.13.0
V8: 8.0.426.27-electron.0
OS

[ ] macOS
[X] Windows
[ ] Ubuntu

Screenshots
This error happens in all intent triggers registered in my bot.
Below are images with an example of this happening in an intention.
Error message

Dialog structure

Intent settings

Thank you for the report, @gabrielguarisa. I would like to help and I have a few questions.

Are you able to reproduce the problem when creating a new bot in Composer 2.0?
If not, can you copy your project and then modify it to create a minimal example of the problem?
Can you help us reproduce the problem by providing a sample project with repro steps?

We've seen this kind of issue before, though not in Composer: https://github.com/microsoft/botbuilder-dotnet/issues/1859

@v-kydela thanks for the reply.
I followed your suggestion and tried to create a new bot in composer 2.0. And I accidentally found out why this problem was happening . It has no connection with LUIS (should I change the title of this issue?).
I am using the delay activity before the text messages, in a similar way to what is suggested here. But the casting error happens when setting the delay time on a variable.
The project created with the reproduction of the error: bot.zip

@gabrielguarisa - Thank you for the sample. I can reproduce the problem now, and I believe it is related to the problem I linked to before. It looks like the new cloud adapter reintroduced the problem with this line:

var delayMs = (int)activity.Value;

I'll work on a PR to fix this. I see two possible workarounds for now:

Bypass the variable, replacing ${user.typingSpeed} with ${1000}
Get your exported runtime to use a Bot Framework adapter instead of a cloud adapter

Thank you for your help. I will test the suggested approaches.


Multi-tenancy

Resolves: https://github.com/dimagi/open-chat-studio/issues/24
Best reviewed by commit

Add team to all necessary models
All existing data owned by Team(1)
All users added to Team(1)
View queries updated to filter by team

Safety Story
I have tested this locally using a dump of the 'dimagi' instance DB and confirming that the migrations run as expected.
After running the migration I inspected all pages and tested a lot of features to ensure that they still work.
TODO

remove remaining redirects to admin UI

main experiment page
prompt builder save

From a quick glance it looks like the ExperimentChannel is missing a team? (I'm grabbing coffee now for a more in-depht review)

Awsome stuff! From a quick glance it looks like the ExperimentChannel is missing a team?

That's correct but it is always associated with an Experiment. The same for ChatMessage which is always associated with a Chat.
We could add team to them but it doesn't seem necessary at this point.

Awsome stuff! From a quick glance it looks like the ExperimentChannel is missing a team?

That's correct but it is always associated with an Experiment. The same for ChatMessage which is always associated with a Chat.
We could add team to them but it doesn't seem necessary at this point.

Yeah that's fair

An administrator of a team is not able to add/edit experiments (only the superuser can do this).

I kept this as it is now since most users won't be administrators. Improving permissions is a whole other set of changes.

when creating a new experiment in say, team 2, I can (as a superuser) see and link a prompt from team 1 to this experiment.

ah - this is an issue which I'll fix in this PR

when creating a new experiment in say, team 2, I can (as a superuser) see and link a prompt from team 1 to this experiment.

ah - this is an issue which I'll fix in this PR

Resolved in 263be36be53e10ee2ecc109325246782a794c7ff

@SmittieC I found an issue with Participants which already had a team before. I've added a new migration to handle it:
https://github.com/dimagi/open-chat-studio/pull/50/commits/4484351e4f82b20aa4ebc4502a25a5c601ebd7e3

I'm going to wait till Monday to roll this out

Do you think there is a better way to handle team-based filtering (and setting on create?) that uses something like middleware + threadlocals to always ensure the proper filters get put in place? I'm not sure exactly what that would look like, but it just struck me that it would be nice to not have to handle it explicitly everywhere if there was a way to do that.

That approach does appear nice but there are a lot of edge cases. If we did want to do that we could try out this project rather than implement it ourselves: https://github.com/citusdata/django-multitenant

Related - tn terms of testing, I think the largest potential remaining risk is that some functionality accidentally "leaks" across teams. In your manual testing did you also create a new team and confirm that none of the existing Dimagi stuff showed up in all the common flows? Note: this is a lower-risk issue if we don't expose multi-tenancy to anyone outside Dimagi until we do further testing in production.

I did create a new team and verified most of the views. I do think this is relatively low risk from that point of view. The higher risk right now is whether there are any links out there which point to a team other than the 'default team' but I've confirmed with our users that there aren't.


Update setup.py for v2.0 release

Status
READY
Description
Update setup.py for v1.6 release.
Related PRs
List related PRs against other branches:

branch
PR

other_pr_production
link

other_pr_master
link

Todos

[ ] Tests
[ ] Documentation

Deploy Notes
Notes regarding deployment the contained body of work.  These should note any
db migrations, etc.
Steps to Test or Reproduce
Outline the steps to test or reproduce the PR here.
git pull --prune
git checkout <feature-branch>

Impacted Areas in Application
List general components of the application that this PR will affect:

setup.py

We can include the setup.py restructure in this PR. @abhisharma404

@rejahrehim Hi there, can we discuss about the updates in the IRC channel. There are few problems that need to be cleared. :)

Can we include the Installation updates in setup.py?

Done :)


time

Hi
we are testing LRSIM for to generate 10X reads for an organism with genome size about 1.5Gbp. As I was noticed, you had mentioned that the normal time for a genome like human genome will take a time less than 10 hours. But it is 283 hours we are running the LRSIM on 16 threads and about 160 GB memory.
is it abnormal? do you recommend to stop it?

Please stop. It's because LRSIM was running out of available barcodes (about 4M available in total) for your setting combination.

@aquaskyline thanks. So what should we do?

Could you please show me your setting and the size of your genome input?

@aquaskyline thanks.
I have run LRSIM using this command :
../../Apps/LRSIM/simulateLinkedReads.pl -r /mnt/hdd2/mostafa/Bio-Mostafa/data/Dj_genome_v1.fasta -p SimulatedReads -z 16

we are trying to have an assembly using 10X technology for a genome which its estimated genome size is about 1.5Gbp and it is repetitive regions which makes assembly process hard.

my other question is about the outputs of LRSIM. Does LRSIM do some analysis about our genome including the ideal coverage we should have in genome assembly or even some other statistics?
or it only makes a 10X library for us to do an assembly process using an assembler?

No, LRSIM won't analyze the characteristic of your input. It outputs exactly as you set in the parameters.
Do you know which step LRSIM was stuck at? You could run "ls -lrt" at the folder your ran LRSIM, and paste the outputs in your reply. That helps to narrow the problem.

@aquaskyline
drwxrwxrwx 1 root root          0 ﻑﻭﺭیﻩ  6 17:38 _Inline
-rwxrwxrwx 1 root root        647 ﻑﻭﺭیﻩ  6 17:38 SimulatedReads.hap.parameter
-rwxrwxrwx 2 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:26 SimulatedReads.hapA.fasta
-rwxrwxrwx 2 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:26 SimulatedReads.hap.0.fasta
-rwxrwxrwx 2 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:26 SimulatedReads.hapB.fasta
-rwxrwxrwx 2 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:26 SimulatedReads.hap.1.fasta
-rwxrwxrwx 1 root root      12809 ﻑﻭﺭیﻩ  6 18:26 SimulatedReads.hap.hetA.insertions.fa
-rwxrwxrwx 1 root root   18563387 ﻑﻭﺭیﻩ  6 18:26 SimulatedReads.hap.hetA.bed
-rwxrwxrwx 1 root root      12546 ﻑﻭﺭیﻩ  6 18:26 SimulatedReads.hap.hetB.insertions.fa
-rwxrwxrwx 1 root root   18574133 ﻑﻭﺭیﻩ  6 18:26 SimulatedReads.hap.hetB.bed
-rwxrwxrwx 1 root root      11316 ﻑﻭﺭیﻩ  6 18:26 SimulatedReads.hap.homAB.insertions.fa
-rwxrwxrwx 1 root root   18545140 ﻑﻭﺭیﻩ  6 18:26 SimulatedReads.hap.homAB.bed
-rwxrwxrwx 1 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:27 SimulatedReads.hap.0.clean.fasta
-rwxrwxrwx 1 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:27 SimulatedReads.hap.1.clean.fasta
-rwxrwxrwx 1 root root    1455863 ﻑﻭﺭیﻩ  6 18:27 SimulatedReads.hap.0.clean.fasta.fai
-rwxrwxrwx 1 root root    1455867 ﻑﻭﺭیﻩ  6 18:27 SimulatedReads.hap.1.clean.fasta.fai
-rwxrwxrwx 1 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:34 SimulatedReads.dwgsim.0.0.12.fastq
-rwxrwxrwx 1 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:34 SimulatedReads.dwgsim.0.2.12.fastq
-rwxrwxrwx 1 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:34 SimulatedReads.dwgsim.0.3.12.fastq
-rwxrwxrwx 1 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:34 SimulatedReads.dwgsim.0.5.12.fastq
-rwxrwxrwx 1 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:34 SimulatedReads.dwgsim.0.4.12.fastq
-rwxrwxrwx 1 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:34 SimulatedReads.dwgsim.0.6.12.fastq
-rwxrwxrwx 1 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:34 SimulatedReads.dwgsim.1.0.12.fastq
-rwxrwxrwx 1 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:34 SimulatedReads.dwgsim.0.1.12.fastq
-rwxrwxrwx 1 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:34 SimulatedReads.dwgsim.1.2.12.fastq
-rwxrwxrwx 1 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:34 SimulatedReads.dwgsim.1.1.12.fastq
-rwxrwxrwx 1 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:34 SimulatedReads.dwgsim.1.3.12.fastq
-rwxrwxrwx 1 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:34 SimulatedReads.dwgsim.0.7.12.fastq
-rwxrwxrwx 1 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:34 SimulatedReads.dwgsim.1.6.12.fastq
-rwxrwxrwx 1 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:34 SimulatedReads.dwgsim.1.4.12.fastq
-rwxrwxrwx 1 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:34 SimulatedReads.dwgsim.1.5.12.fastq
-rwxrwxrwx 1 root root<PHONE_NUMBER> ﻑﻭﺭیﻩ  6 18:34 SimulatedReads.dwgsim.1.7.12.fastq
-rwxrwxrwx 1 root root       6367 ﻑﻭﺭیﻩ 20 00:50 SimulatedReads.status
-rwxrwxrwx 1 root root          0 ﻑﻭﺭیﻩ 22 09:17 command.txt

should we specify another parameter for running the process?

Were you running out of disk space?
By this way, please use "-t 750 and -z 4"

@aquaskyline  no there is much free space. Ok

@aquaskyline
Hi
we have launched the LSRIM using a command as you said.
it is running for 28 hours till now and I think it should take this much time.
do you suggest to keep it running?

@aquaskyline the last log I have observerd is:
DjScaffold99999 length: 12205
38203 sequences, total length:<PHONE_NUMBER>
Currently On: 7057813

and is stuck here!

That's weird, could you please attach the full log?

@aquaskyline Sorry, Since I had no idea how to copy logs from a running a process, here are the screenshots available from this process.

Th log file is in the output folder with ".status" extension.

@mossishahi The full log is in this file "SimulatedReads.status".

it seems to me that your genome input is an assembly and it's too fragmented, with most of the scaffolds at 10s of kilobases. 10x Genomics uses an average of 100kbp fragment size, which is longer than most of the scaffolds. LRSIM requires scaffolds longer than the fragment size for reads simulation. LRSIM will soon run out of usable scaffolds if most of the scaffolds are shorter than the fragment size. You might have to improve your assembly contiguity first.


Automatic content links

It should be possible to just write /u/ernest, /m/kbinmeta or /c/kbin and have it autocomplete to [/c/kbin](https://kbin.social/c/kbin) on submitting a comment or post.

/u/ernest should instead autocomplete to @ernest

The easy-emoticon mod contains a naive implementation of text autocompletion that may be a jumping-off point.


Link to Spin kit not working

Probably a copy/paste mistake ;)

Thanks for letting me know. I've fixed that. :)


conform to swift 2.3

@torkale  I created new branch  conforming to Swift 2.3 syntax. If you're still using Swift 2.3, please update this branch in your Podfile:
pod 'BTNavigationDropdownMenu', :git => 'https://github.com/PhamBaTho/BTNavigationDropdownMenu.git', :branch => 'swift-2.3'

Thanks so much 👍


Docker for beta delivery

Dockerfile for beta delivery
[] Change the link to the source code to the official beta release
specfile updated
setup.py fixed

Closing this PR to avoid confusion with the same PR on the fork here


JWT is stored as Session

I expect that gateway would act as stateless. But it stores JWT in session and return sessionId associated with JWT as SESSION cookie to client. So JWT is not returned to client directly. Is it bug or design decision?
Note: I'm using Oauth2Login
Sample: https://stackoverflow.com/q/60669768/10550738

@spencergibb hey, can you provide an information about this? i have the same issue. is it my implementation issue or is it right behavior for gateway? thanks

Closing in favor of stack overflow


Migrate feature flag ANDROID_FACEBOOK_LOGIN_REMOVE

📲 What
In the viewModel/viewModelTests level change the calls:
optimizely.isFeatureEnabled(OptimizelyFeature.Key.ANDROID_FACEBOOK_LOGIN_REMOVE)
to
featureFlagClient.getBoolean(FlagKey.ANDROID_FACEBOOK_LOGIN_REMOVE)
🤔 Why
This is one feature flag migration as part of overall migration from optimizely to firebase remote config MBL-661
👀 See
No visible changes.
📋 QA
In firebase console, change the value of ANDROID_FACEBOOK_LOGIN_REMOVE in the three build variants. Verify that the facebook login is shown or not shown in the login screen.
Story 📖
https://kickstarter.atlassian.net/browse/MBL-681

@ycheng-kickstarter small format PR comment, we usually add the ticket number to the title of the PR:
[TEAM-TICKETNUMBER]: [JIRA TITLE] -> MBL-684: Migrate feature flag ANDROID_CAPI_INTEGRATION


Add C3 and R3 to BOM

I think these were missing (should have ordered extras! 😢 )

C3 and R3 are only needed if you want to add extra gain to the preamp. With the specified mic capsule and the preamp configured for unity gain, the AOP of the mic should be close to 0dBFS with most mic interfaces.
I moved C3 and R3 to a new optional components section in the BOM and updated the pull request branch. This is my first pull request, so I hope that is the right way to handle it. Thank you for contributing!


Revert "Automatic deletion of bitwig.bitwig <IP_ADDRESS>435"

Reverts microsoft/winget-pkgs#51316
Microsoft Reviewers: Open in CodeFlow

/azp run

@wingetbot run


Print out the workflow to be registered during deployment

Currently, the huge JSON printout is not readable which makes the debugging almost impossible.  Here is an example: https://flyte.lyft.net/api/v1/workflows/setl/production/workflows.setl.backfill_pt_ganeshp__fact_rider/6c71ee619209f58698f06d80f2e6ba57a5e2d60a
Motivation: Why do you think this is important?
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] OR why this would be a cool addition OR which usecases could this unblock.
Goal: What should the final outcome look like, ideally?
A clear and concise description of what you want to happen or achieve.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Flyte component

[ ] Overall
[ ] Flyte Setup and Installation scripts
[ ] Flyte Documentation
[ ] Flyte communication (slack/email etc)
[ ] FlytePropeller
[ ] FlyteIDL (Flyte specification language)
[ ] Flytekit (Python SDK)
[ ] FlyteAdmin (Control Plane service)
[ ] FlytePlugins
[ ] DataCatalog
[ ] FlyteStdlib (common libraries)
[ ] FlyteConsole (UI)
[ ] Other

[Optional] Propose: Link/Inline
If you have ideas about the implementation please propose the change. If inline keep it short, if larger then you link to an external document.
Additional context
Add any other context or screenshots about the feature request here.
Is this a blocker for you to adopt Flyte
Please let us know if this makes it impossible to adopt Flyte

Actually... I'm going to update some of the items in the description.  The huge printout is exactly as it should be.  This is the API endpoint provided by Admin.  It's doing exactly what it's supposed to do.  What this issue should be for is to print out another long spec of the thing to be registered in case of a conflict error, so that a user may go through both long json outputs to detect what the difference is.


bkImage It doesn't seem to work properly

No cross domain issues reported
bkColor can render normally

required:   topology-core  >  0.2.1-beta

@Alsmile
Bkimage cannot be clear
 //render bkimage success
   this.canvas.data.bkImage = 'http://localhost:9800/workstorge/personal/images/A600E431-A9EF-4139-BED1-617564300970timg.jpg';
   this.canvas.updateProps(node);

   // clear bkimage,Bkimage cannot be cleared
     this.canvas.data.bkImage=null;
     this.canvas.updateProps(node);

Clear bkimage:
this.canvas.clearBkImg();
this.canvas.render();


error with GETRF with MLS

Hi,
I'm a relatively new DTK user, but have used it successfully on one project and am now using it on other. I am using DTK 2.0 (2.0.0-5-g63d2fc8) and I am interpolating from one point cloud to another using the following parameters:
 m_parameters = rcp(new ParameterList("DataTransferKit"));
  m_parameters->set("Map Type",
                   "Point Cloud");

  ParameterList& pc_params = m_parameters->sublist("Point Cloud", false);
  pc_params.set("Map Type",
                "Moving Least Square Reconstruction");
  pc_params.set("Basis Type",
                "Wendland");
  pc_params.set("Basis Order",
                0);
   pc_params.set("Spatial Dimension",
                3);
   pc_params.set("Type of Search",
                 "Nearest Neighbor");
  pc_params.set("Num Neighbors",
                8);

This worked well with one data set, but now it is crashing with the following error:
terminate called after throwing an instance of 'DataTransferKit::DataTransferKitException'
  what():  DataTransferKit DataTransferKitException: 0 == info, failed in /home/burg137/build/Trilinos/DataTransferKit/packages/Operators/src/PointCloud/DTK_LocalMLSProblem_impl.hpp, line 168.

I have attached a commented gdb log. I understand that this is caused by an LU factorization returning with a zero on the diagonal of U. I printed out the coordinates of the target and the eight source points, and everything looks okay to me. I also did this for points with a successful LU factorization and didn't see anything obviously different. Any help would be appreciated.
Thanks,
Jeff
gdb_log_commented.txt

I read this paper
https://www.casl.gov/sites/default/files/docs/CASL-U-2015-0177-000.pdf
and now understand (I think) that it is related to the linear dependence of the position vectors of the source points. Right? I increased the number of nearest neighbours from 8 to 10 and it seems to have fixed the problem. Is there a more robust set of parameters/algorithms that I could be using? I'm interpolating from the centroids of a structured finite difference grid to the centroids of an unstructured tetrahedral finite element mesh.

@jeff788 thanks your feedback and digging up that paper! Yes - these point cloud methods, particularly the moving least square operator require special attention for certain configurations to avoid singular least square problems hence the work I did in that paper. These originally came from the aerospace community where smooth, curved manifolds typically yielded well-behaved point configurations.
With regards to the settings you've found the most significant aspect of robustness of these algorithms that we are working on. They are incredibly simple and accurate but require a good selection of the neighborhood (i.e. the radius or the number of neighbors). Too few neighbors in a bad configuration means that you may filter out a lot of redundant points and therefore may fail on the LU decomposition in GETRF. If you're grids are fairly uniform, often the radius is a better choice of neighborhood selection. I would then start with a radius between 1 and 2 cell widths and see how that works. If they are not uniform the number of nearest neighbors is a better choice for performance reasons.
As far as your choice of algorithm I think you have a good start. If you actually want nodal data on the finite element grid then I would try interpolating on to the nodes of the tetrahedral mesh rather than the cell centers. The same goes for the structured finite difference grid. If the data is node-centered rather than cell-centered you could pass the node coordinates and nodal field values to the map as well.

@jeff788 Do you mind if I ask which institution you are with and what kind of problems you are working on? We are currently developing version 3 of the code which will have OpenMP/CUDA support for advanced architectures and we are always looking for feedback from users to make improvements. Thanks!

Yes, I'm at Pacific Northwest National Lab. I used DTK for a project where I coupled a subsurface reservoir simulator (PNNL's STOMP code) to a finite-element mechanics code (LLNL's GEOS). I wrote a conference paper about it and cited DTK (https://www.onepetro.org/conference-paper/ARMA-2017-0478). Now I'm trying to use it to transfer data from the same reservoir simulator, but this time to a geophysical forward modeling code with the goal of determining which geophysical monitoring techniques would be sensitive to various subsurface processes. For this application it is cell-centered data (bulk properties) that I'm transferring, which is why I'm using cell centroids as point clouds.
DTK is great, thanks for all of your work!


Expand EXT_feature_metadata support

Resolves: #513
Addresses: #389
Partially implements #771
Expands EXT_feature_metadata support:

Adds Blueprint-based "picking" to query metadata:

[x] Support querying Feature Id Textures.
[x] Support querying Feature Textures.
Note that vertex attributes picking has already previously been implemented.

Adds material graph based GPU "styling" where the metadata values can be used to drive material/shader effects:

[x] Support Feature Id Textures styling.
[x] Support Feature Textures styling.
[x] Support vertex attributes styling.

Adds the UCesiumEncodedMetadataComponent, which can be added to tilesets to describe exactly what metadata to encode for availability for material styling. Specific properties out of specific feature tables can be picked out for gpu encoding, while others that aren't needed can be left out.

Adds button on the CesiumEncodedMetadataComponent to auto-generate an incomplete material layer based on the currently selected metadata to encode. This generated material will take care of all the boiler plate code responsible for parsing feature id textures / attributes and performing the per-pixel / per-vertex feature id lookup. The requested property values will be available as the output pins of a custom shader node as plain floats or vectors.

Some Remaining TODOs:

[x] Fix example materials, make them compatible for UE 4.26.
[x] Fix picking blueprint in sample level + implement backward compatibility for blueprint api changes.
[x] Easier view of available metadata on the UCesiumEncodedMetadataComponent, currently it is painful to manually open the tree.
[x] Add an "Auto Fill" button to the encoded metadata component, that can automatically punch in all unique feature tables and properties (from the currently visible tiles). Users can do this to quickly get the superset of encodable properties and delete the ones they don't need. This might be particularly useful when users don't have convenient access to the glTF jsons or may have forgotten the exact names of the feature tables and properties in the metadata.
[ ] Check that picking and styling of metadata works on UE5 preview 1. May need to write Chaos-specific code to enable UV-based picking.
[x] FIXED NOW (I think). There seems to be a strange issue with deletion of auto-generated materials causing crashes in some cases.
[x] Add auto-generated materials for feature textures.
[ ] Occasional issues regarding using vertex interpolators in materials with multiple layers underneath. E.g., vertex interpolator in the metadata layer causes the material to not compile, if there is a base glTF layer.

Feature ID Textures queried in Blueprint using a line-trace.

Feature ID Textures used to color the model based on age of components.

Per-Vertex Feature ID Attributes, in this case building height information, used to color the buildings of NYC

Blueprint-based metadata picking, used to spawn billboards indicating terrain-type.

Example of how to use this:
After using "Auto Fill" the CesiumEncodedMetadataComponent should look something like this, listing the existing metadata in the tileset.

After picking the required metadata properties and pressing "Generate Material", a material layer accessing the required metadata is created.

The output pins of the feature table lookup node can be used to access the metadata property values. They can be used to drive any shading effect. Here we highlight buildings built in 1931. Note that for vertex attributes, this needs to be run on the vertex shader, which means the output has to be run through a vertex interpolator. The auto-generated template material creates an unattached vertex interpolator next to feature tables using per-vertex feature id attributes, as a reminder.

Add the material layer to to a material instance, as usual.

The final output: the NYC buildings tileset, with all buildings from 1931 highlighted yellow.

Thanks for the pull request @nithinp7!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

Reviewers, don't forget to make sure that:

[ ] Cesium for Unreal Samples works.

@nithinp7 this looks really exciting! Seems like you took it much farther than I realized. I think it would be helpful if you could walk me through it next week. And can you share the blueprint for the custom materials you've demonstrated in the screenshots above?

Just added an example material that can be added to the "New York City 3D Buildings" tileset to color based on height. The material and the material layer should be under "Cesium for Unreal Content -> Materials -> Experimental".

@kring Officially marking this as ready to review! I just added the UCesiumEncodedMetadataComponent which can be added to a tileset. The list of feature table properties and feature textures to encode can be described in the details panel of the component. Later, only matching properties will be encoded and usable in the material. I still need to make the tileset automatically pick up changes in the component.

The two new uassets were created in UE 4.27, so they can't be loaded in UE 4.26.

This is amazing! I think there are a few things we can tweak to improve the usability though:

Add doc comments for FPropertyDescription etc (you already have a TODO). Also the Auto Fill button.
Designate a TitleProperty for the array of properties. Probably the property name. That way users can which property is which without expanding them. See the CesiumSubLevels property in CesiumGeoreference.h for an example.
I think the way Auto Fill works is a little painful, where it adds all the properties and those have a cost even if you don't use them. And avoiding that cost requires deleting the properties, which could be super tedious, especially with a tileset with lots of properties (Cesium OSM Buildings, for example, could easily have a hundred or more properties just from the tiles visible on screen). I think it would be a drastic improvement - and hopefully not too hard - to make Auto Fill more of an "Add" button that opens a dialog to select the properties to add.
Especially with the above, I wonder if a flat structure where "feature table name" is one of the fields might be easier to work with than the tree structure. So basically CesiumEncodedMetadata would have a simple list of properties with these attributes:

Feature Table Name
Property Name
Component Type
Type
Normalized
(Maybe!)

Not really usability, but... Should the texture sampler type used for the feature material be "Data" instead of "Color"? I'm admittedly not real clear on the difference, but I think the Color sampler might do sRGB correction or somesuch, which seems bad. Or maybe that doesn't happen because of the PropertyArray.Load?
Would love to be able to create these kinds of materials without writing HLSL. I guess your other branch is the ultimate answer there?

I'm probably doing something dumb, but I can't seem to get this to work. I get strange compiler errors from my material instance:

My metadata extension looks like this:

Material Layer (ML_Material) looks like this:

And material instance looks like this:

Any idea what I'm missing? This is with the NYC Buildings tileset.
Also I noticed that the picking blueprint in 06_CesiumMetadata doesn't work any more, presumably because changes in the API mean it doesn't compile anymore. In the short term, do you have an updated version of the blueprint? But before we ship this, we should make sure we preserve backward compatibility if possible.

@kring I have been running into that issue with per-vertex feature id attributes only. I think it is due to the vertex interpolator, the vertex interpolator forces the input graph to compile on the vertex shader which is needed here. The only work-around I've found so far has been to remove all layers below the metadata layer (so this is only usable if none of the original glTF shading is needed in the metadata styling, e.g. metadata styled tints wouldn't be possible). I replaced the background layer with the "Empty" material.

Ok if I delete the extra material layers and use ML_CesiumNothing as the base, the compile errors go away. It still doesn't work the way I expect, though. I'm testing with NYC Buildings, asset ID 75343. The problem is that, even though I've tried to arrange for every building with a height to be red, most of the buildings are black. I can see by exploring this tileset in CesiumJS that they all (or at least most) have a valid Height property.

My material layer, ML_Material, looks like this:

The encoded metadata extension is straightforward:

And the material instance looks like this:

I noticed that you used the Empire State Building in your example above, and that happens to be one of the "working" buildings. Is there perhaps some problem where most of the buildings are missing their metadata?

I haven't reviewed the code in great detail, but here are the things I think need to happen from a user-facing perspective before we can ship this:

[ ] Assets need to target UE 4.26, not 4.27.
[ ] 06_Metadata level blueprint has a bunch of errors. We need a backward compatibility path. Should be possible with some Core Redirects.
[ ] Generated materials should have a better name, probably involving tileset name and the names of the properties included in the material.
[ ] Can we open the content browser and auto-select the newly-generated material? Otherwise it's easy to miss that the "Generate Material" button did anything.
[ ] Is it possible to only rewrite the generated portion of an existing material? Like the set of textures and the custom expression node, but not anything attached to it?
[ ] If not, we should at least warn before overwriting an existing generated material.
[ ] Those compiler errors when the material is too complicated (?): We at least need to understand what's going on there well enough to explain it to users. Ideally we'd fix it somehow, if possible.

@kring Concerning two of those points, maybe it would be a good idea to enumerate the saved material layers to avoid a name clash and overwrite. I'll look for a way to scan the directory for existing materials of that name and tack on a number to deconflict.

I'll look for a way to scan the directory for existing materials of that name and tack on a number to deconflict.

Yeah that'd definitely be an improvement! Not quite as good as only regenerating the generated portion, of course.

You might already be aware, but MLB_CesiumAlphaBlendBaseColor.uasset has been upgraded to 4.27. It needs to go back to 4.26.

@kring That was quite painful to sort out, but the blueprint api changes are now backwards compatible with deprecation warnings as necessary! I will open a follow-up PR to remove the deprecated mess.
Remaining tasks:

Make the example materials 4.26-compatible and undo the accidental change to the material blend.
Investigate vertex-interpolator issue.
Add button on the EncodedMetadataComponent to update the tileset to use the metadata selection (essentially a more convenient way to just refresh the tileset). I was going to have the tileset automatically pick up changes, but this might be extremely costly the way Auto-Fill currently works. All of the metadata would be loaded to the GPU if we refresh the tileset before the user deletes unneeded metadata.
Regenerate the generated portion of materials (I'm going to time-box this and bail if it takes too long).

@kring Alright another somewhat painful task, but I think the regenerating nodes idea is implemented reasonably now! There is a new "Target Material Layer" field on the encoded metadata component, that indicates what material layer file was just generated / what file to regenerate. This makes the regeneration robust to moving the material layer into a different directory and also allows users to pick which specific file they want to regenerate.
A few more quality-of-life features came out of this:

The material editor automatically opens to a newly generated / regenerated material.
Any existing editor window of the material layer with unsaved changes is prompted to save before a material regeneration actually happens.
Generated / regenerated materials are now automatically saved.
If the "Target Material Layer" is empty, a new material layer is generated in the /Game/ folder and the "Target Material Layer" is automatically set to the newly created layer so that it is the immediate target of future regenerations.

This unfortunately introduces a new plugin dependency to be able to save the resulting material (although I was hoping this is a built-in plugin like Water, SunSky, etc). I think the saving was necessary to properly refresh what the material editor showed when opening up regenerated materials. Previously it was showing the out-of-date version in the material editor until the material was saved and the material editor was re-opened. This new dependency is causing CI to fail I believe, maybe we need to add the plugin to the version of Unreal we have on s3?

Added two example metadata styling materials for NYC buildings in the CesiumforUnrealContent/MetadataStyling folder, one visualizing height and the other visualizing year-of-construction.

🤩 this is looking awesome! I'll do a more thorough review tomorrow, but I tried it out and I think it's really close. Do you think we should try to get it into the April release? My inclination is not to rush it, given that it's a very large new feature. Giving everyone some time to play with it before we ship it is probably worthwhile. What do you think?

This looks great, I think the only thing stopping me from hitting merge is that change we talked about to use square-ish textures for metadata so that our feature count isn't limited to 4096 or 8192 or whatever the max texture size is.

@kring Should be good to go now, changed the feature table encoding and material generation code to create and use square textures. Also made slight changes so the material editor for new / edited materials always gets focused when it is opened. Lastly, found a way to mark the material compilation as dirty in the editor, so the green "Apply" button shows up after regeneration. I never noticed until today that the "Apply" was greyed out after regeneration (maybe it was a regression from the last volley of commits), but it was making it difficult to recompile without making an extraneous change to get the editor's attention.
Anyways, it should be simple to apply the square-texture fix to any previously-generated material layers,: Just select it as the target material, check that the same properties are selected, and regenerate.

@kring As an aside, I'm super glad you suggested and pushed me to implement the regeneration, it makes the workflow very flexible!

I spent some time trying to understand those shader compilation errors when using ML_CesiumGltf as the background (bottom) layer. Here's what I understand to be happening...
Unreal Engine and/or the hardware have a limit of 8 "custom UV" interpolators, each of which is two floats. Older shader models have less, but SM5, Vulkan, and Metal (which are the only ones we care about, really) all seem to allow at least 8. These 16 floats are the only way to get information from the vertex to the pixel shader. So regular UV texture coordinates coordinates start out as vertex attributes, and if you want to use them from the pixel shader side of the house, then congrats, you just used 2 of your 16 available interpolator slots.
Unreal Engine materials aren't super obvious about which parts of a material are vertex shader and which are pixel shader. From what I understand, it comes down to the material output pins. Pretty much all of the material output pins imply pixel shader. So if you connect nodes to "Base Color" for example, everything feeding into that runs at pixel shader time. The exception is special "Customized UVn" pins. Nodes connected to those run in the vertex shader. A common trick in older versions of UE was to do some per-vertex work, connect the output to Customized UVn pins as necessary, and then have separate nodes that read TexCoord[n], do some further computations in the pixel shader, and send the output to normal pins like Base Color. In more recent versions of UE, we can use "Vertex Interpolator" nodes instead. A Vertex Interpolator node has a "VS" input and a "PS" output. Nodes attached to the VS side run in the vertex shader, the value(s) attached to the VS input are stored in Customized UV channels as necessary, and nodes attached to the PS side use those values to do further computation in the pixel shader. The release notes for UE4.16 have a better explanation of this than mine: https://docs.unrealengine.com/4.26/en-US/WhatsNew/Builds/ReleaseNotes/4_16/#new:vertexinterpolatormaterialexpressionnode
So Vertex Interpolators are really handy for passing values between the vertex and pixel shader, because we don't have to manually allocate Customized UVn slots to them. But it's important to realize that UE is still allocating them behind the scenes. In order to do this, it looks at which TexCoord[n] values are used from the pixel shader. Those need to be assigned directly to equivalent Customized UVn pins, otherwise the pixel shader wouldn't be able to use them. Then values passed through vertex interpolators are assigned to further Customized UVn pins, automatically and transparently.
But here is where we run into trouble. Because glTF has lots of options, and we need an uber-shader that can handle all of them, our ML_CesiumGltf uses every single one of the Customzied UVn slots. It doesn't really, of course. Even if you use every single glTF feature, and separate texture coordinates for each, you'll only use 5 sets of texture coordinates (base color, metallic/roughness, emissive, normal, occlusion). That should leave 3 available. But we actually use all of them because we don't know which ones we're going to use. Every texture sample pulls its coordinates through our CesiumSelectTexCoords function, which is basically a giant switch that turns a texture coordinate index into texture coordinates. Because the switch includes all 8 texture coordinates, our M_CesiumGltf pixel shader effectively uses all 8 Customzied UVn pins. That leaves zero available for the Vertex Interpolator, and so we get (strange, not very helpful) compiler errors.
One improvement we can make right away is to use vertex interpolators in the ML_CesiumGltf layer right after each CesiumSelectTexCoords. This way each use of CesiumSelectTexCoords (of which there are 5) will use up a Customized UV_n slot, instead of each possible set of texture coordinates (of which there are 8) using up a slot. So that'll free up 3 UVs / 6 scalars for use with material styling. I think it might give us a tiny performance improvement too, so I'll go ahead and make that change.
But this is going to be really difficult to fix more generally. Ultimately maybe we need a way to generate the glTF base material from representative tiles, so every texture can just use the right glTF materials and texture coordinates and be done with it.

One thing I'm still not completely clear on is why we have to use a vertex interpolator for metadata styling. As long as the feature IDs are the same for all three vertices in every triangle, it seems like it shouldn't make any difference. Yet there are crazy artifacts without the vertex interpolator.

Why is it so terrible to sample metadata in the pixel shader?

One improvement we can make right away is to use vertex interpolators in the ML_CesiumGltf layer right after each CesiumSelectTexCoords.

ehhh... the problem with this is that we should do the same for the CesiumSelectTexCoords in MF_CesiumSampleRasterOverlay. But if we do that, our standard MI_CesiumThreeOverlaysAndClippingAndWater doesn't compile anymore. 5 glTF vertex interpolators, plus three overlay vertex interpolators, plus one clipping vertex interpolator is 9 vertex interpolators, one more than we're allowed.

Ok I figured out the cause of those crazy artifacts: Draco encoding. The feature ID attributes are Draco-compressed, so they're quantized, so they're not exactly integers. So the truncation to integer would sometimes be off by one, and when we sampled per pixel this could cause very different feature values even within a single triangle. The solution is to round the sampled feature ID before truncating them to integers. We had the exact same bug in the original picking implementation, so I'm embarassed I didn't think of it sooner.
Anyway, with that, metadata styling now works well without a Vertex Interpolator. Actually it works better, because you don't have to remember to swap out the ML_CesiumGltf for ML_Nothing. It might be a little slower, but IMO that all falls into the category of "to go faster, make a custom material for your tileset, rather than using the uber-materials we provide." So I removed the vertex interpolator from the material generator.
Before I figured out that Draco was the issue, I thought it might be sRGB colorspace conversion. So I also added a bit of code to only treat the glTF base color and emissive textures as sRGB, and the others as not sRGB (as the glTF spec says we should). It didn't help with the metadata problem at all, but I think it's a good change so I didn't revert it.
So with that I'm really happy with this PR and ready to merge it. But because I made some non-trivial changes at the last minute here, @nithinp7, you should take a look and make sure it all still looks ok to you. If you're happy, go ahead and merge it!

Thanks for looking into this @kring! I have no objections with any of the changes you made, looks good to me. My only remaining concern, as discussed offline, is to make sure I understand what the draco issue is and why rounding in the shader fixes it. My alternate theory for the artifacts was that all three feature ids on the vertices of the triangle are the same even after the quantized -> integer -> float conversions, but the automatic barycentric interpolation of the three same floats in the pixel shader is still subject to some ever-so-slight floating point error. Just enough, to make the truncation back to uint propertyIndex cause an incorrect feature id.

Self-merging this now with approval from @kring! 🤞


Create a String algebraic datatype in bitcoin-s

Create a type for the Strings we are passing around in bitcoin-s
Example:

Hex
Bech32
Raw (java.lang.String)

This makes it easier to reason about what types of strings are being passed around where.

Base58 string as well


fix: dfdaemon exit when load properties failed

Signed-off-by: lowzj<EMAIL_ADDRESS>Ⅰ. Describe what this PR did
Dfdaemon exit directly when load config file failed.
Ⅱ. Does this pull request fix one issue?

Ⅲ. Why don't you add test cases (unit test/integration test)? (你真的觉得不需要加测试吗？)
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Codecov Report

Merging #426 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #426   +/-   ##
=======================================
  Coverage   67.79%   67.79%
=======================================
  Files          51       51
  Lines        2304     2304
=======================================
  Hits         1562     1562
  Misses        671      671
  Partials       71       71

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f7d5ffb...d0c69b7. Read the comment docs.

LGTM.


Pan/zoom not working

Sorry, I should be clearly doing something wrong but I'm can't figure what it's.
I'm building a simple map with a line layer from the getting started docs, however different from the online examples pan and zoom are not working.
I've added controller={true} to DeckGL component and also tried to customize the controller params:
<DeckGL viewState={initialViewState}
        controller={{type: MapController, scrollZoom: true, doubleClickZoom: true}}
        layers={layers}>
        <StaticMap mapboxApiAccessToken="token"/>
</DeckGL>

I thought it could something related to StaticMap vs InteractiveMap from react-map-gl. However all examples use StaticMap.
I also tried to add maxZoom and minZoom props. No error or warning shows up in the console.
Any help would be appreciated. Thanks!
Code available here: https://gist.github.com/ricardoekm/bfe098f3b94951b20c828bfbb8120f93

I think you want initialViewState={initialViewState}.

Exactly! Thank you very much!!


Jumpy scrolling with touchpad (vertical/horizontal double finger scroll).

When using a touchpad with double-finger scroll enabled for both vertical and horizontal directions, the scroll becomes jumpy in some cases.
This happens when the user moves his fingers not following a straight vertical line, but a bit in horizontal direction. For example, left and bottom cause opposite scrolling, so left-bottom movement becomes jumpy.
This could be solved simply by ignoring horizontal mouse scroll events (like google maps do).

Hey, can you check if https://github.com/Leaflet/Leaflet/pull/3653 works?

Sorry, missed this somehow.
I can confirm that this is fixed in the recent 1.0 beta.

@ChALkeR beta2 was released 2015-oct-14, and the commit fixing horizontal scroll was merged 2015-oct-20. Please use master instead of beta2 for this.

Huh? I was under an impression that I was checking beta2. Will recheck later today.

@ChALkeR Exactly my point: the bug is present in beta2 but fixed in master.

@IvanSanchez What do you mean? I stated above that I didn't observe this bug anymore.

Ah, yes. I was actually checking master, not beta2.


set the mutated value

Hi ,How can I set a mutated dictionary for the specified field, when I run this project？

Hello @higher75,
If I understand your question correctly, say you have a specific field in the body named "location".  You can tell RESTler to replace all occurences of that field with a list of values using restler_custom_payload in the dictionary, either via just a string value or the full json pointer.  See Fuzzing Dictionary documentation for further details.
Is this what you were looking for?
Thanks,
Marina

Thanks you
I know that I can set some values in the restler_fuzzable_string field in dict.json, such as:
"restler_fuzzable_string": [
"//////////////",
"################",
"*************",
")))))))))))))",
"___________________"
],
But according to the data packet sent out, I found that the field values are some example values, such as "fuzzstring". If I have many apis, and then I want to use a unified api payload, how should I set it up?

@higher75

Can you please share the command line you are using?  If you have the above 'restler_fuzzable_string' in the dictionary, RESTler should not be sending fuzzstring, we need to investigate further.

Regarding your request - do you want all the parameter values to be fuzzed with the above values, regardless of data type?  Right now it needs to be set per type, so 'restler_fuzzable_string', 'restler_fuzzable_int', 'restler_fuzzable_bool' etc.  you would have to copy the above list into all those properties, RESTler doesn't have a global list you can specify.

1.This is the cmd
$  /Restler   fuzz   --grammar_file   Compile/grammar.py   --dictionary_file   Compile/dict.json   --settings Compile/engine_settings.json   --time_budget 0.05   --target_ip <IP_ADDRESS>   --target_port 8080

I probably know what you mean, similar to restler_fuzzable_string, restler_fuzzable_int is for all apis and has different type values, and restler_custom_payload can be fuzzed for the specified api, is that what it means? In other words, I can specify dict.json every time I run, right?


WIP: java: move CredentialsProvider up to ClientSettings

redo of #1251.
WIP pending more tests, but all generated code's
unit tests run OK against updated gax.
Adding Neo since a similar change broke his code earlier.

Codecov Report

Merging #1319 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master    #1319      +/-   ##
============================================
+ Coverage     86.47%   86.48%   +<.01%
  Complexity     3836     3836
============================================
  Files           378      378
  Lines         15323    15326       +3
  Branches       1694     1694
============================================
+ Hits          13251    13254       +3
  Misses         1622     1622
  Partials        450      450

Impacted Files
Coverage Δ
Complexity Δ

.../transformer/java/JavaGapicSurfaceTransformer.java
98.13% <100%> (+0.01%)
43 <0> (ø)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7d00fbf...6f52cb0. Read the comment docs.

LGTM - this will work as an intermediate state until my refactoring is done.

This seems good to go, is there anything left to do?

I forgot to update the baseline. Will do that and merge.


Note down who created tmp saltfs clone and when

This change is

r? @jdm

@bors-servo r+
Nice solution :)

:pushpin: Commit ddbb426 has been approved by jdm

:hourglass: Testing commit ddbb426655b95094d86d419c6051ae026b5543d9 with merge 331c94dfcaba5d9f294f9c4ea73b74729b631714...

:sunny: Test successful - status-travis
Approved by: jdm
Pushing 331c94dfcaba5d9f294f9c4ea73b74729b631714 to master...


Running examples on CI

Now that #202 has been introduced it seems like a good time to bring this up.
I was wondering if you could describe a roadmap towards introducing automatic support for CI. Executing the examples on CI should probably mean rendering to a texture, writing it to a file/PNG maybe.
It would probably also be nice to lean on this behavior when building an example gallery for the docs.

Propose a phased approach.
Step 1:

[ ] Adjust auto gui mechanism to switch to CI mode based on environment variable CI=true condition
[ ] If so, use an OffscreenCanvas and adjust run() to render a single frame
[ ] Ensure CI build fails on error running examples

Step 2:

[ ] Adjust run() to grab a screenshot and output it as build artifacts so it can be checked/verified
[ ] Compare screenshot against "known good screenshot" on CI as additional acceptance criteria

Step 3:

[ ] Gallery generation mechanism


Filter branch

Codecov Report
Base: 70.50% // Head: 69.74% // Decreases project coverage by -0.76% :warning:

Coverage data is based on head (bad2527) compared to base (729c02e).
Patch coverage: 0.00% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff              @@
##             master      #39      +/-   ##
============================================
- Coverage     70.50%   69.74%   -0.77%
  Complexity      428      428
============================================
  Files            73       75       +2
  Lines          1373     1388      +15
  Branches        140      141       +1
============================================
  Hits            968      968
- Misses          367      382      +15
  Partials         38       38

Impacted Files
Coverage Δ

...va/seedu/address/logic/commands/FilterCommand.java
0.00% <0.00%> (ø)

.../seedu/address/logic/parser/AddressBookParser.java
84.21% <0.00%> (-4.68%)
:arrow_down:

...eedu/address/logic/parser/FilterCommandParser.java
0.00% <0.00%> (ø)

src/main/java/seedu/address/model/Model.java
100.00% <ø> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

FilterCommand which currently filters via names. Will implement it to filter via tags in the future increments.


Change developer settings to account settings

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


[WIP] Add base parameter class

Description
Adds a base class for parameters and groups them into other groups aligned with BPX
Related: #3909
Type of change

[x] New feature (non-breaking change which adds functionality)

Key checklist:

[x] No style issues: $ pre-commit run (or $ nox -s pre-commit) (see CONTRIBUTING.md for how to set this up to run automatically when committing locally, in just two lines of code)
[x] All tests pass: $ python run-tests.py --all (or $ nox -s tests)
[x] The documentation builds: $ python run-tests.py --doctest (or $ nox -s doctests)

You can run integration tests, unit tests, and doctests together at once, using $ python run-tests.py --quick (or $ nox -s quick).
Further checks:

[x] Code is commented, particularly in hard-to-understand areas
[x] Tests added that prove fix is effective or that feature works

@BradyPlanden Can you take a look at this?

@brosaplanella What did you think of my groupings of parameters? Are the close enough or do they still need work?

To be totally honest I don't like this change. I like the split to different components, but by making it a class it feels like it moves us further away from serialization, with everything having to be defined in a class, rather than closer to it. Ideally an entire parameter set should be able to be defined in a single json file.

The way I was looking at it was that this class could be used as the interface between BPX files and the pybamm functionality. It lets us group and test if features are available. So we could easily add BPX reading/writing to the class plus sanity checking

@brosaplanella What did you think of my groupings of parameters? Are the close enough or do they still need work?

I think they are in the right direction but work is needed. However, I believe this goes beyond parameters themselves and also covers models. For example, we have the mechanical properties, which currently are under the electrodes, but they could also fall under a new mechanics category. LAM is also another one that it is not clear. However, unless we need to set them in stone now, I am happy going ahead as things are and improving in the future.
I also agree with Valentin that serialisation and being able to define parameters as a single script should be the priority. I don't have a strong opinion regarding classes, but I think we should try to do whatever is easier for users (e.g. can we achieve similar testing results by just having some functions that read the .py or .json file and process it?).

I think the class is good, but parameter sets should be stored in as-close-to-json-as-possible format, not embedded into child classes and split across different methods. Right now as-close-to-json-as-possible format is python functions + dicts like we have now, since there is no good way to include the python functions in a json file.


[Bug] Error on Startup after Updating

I'm getting this error when trying to start up langflow locally.
2023-10-31 16:18:41 - ERROR    - utils utils.py:216
- Error migrating flows:
(sqlite3.OperationalError) no such
column: flow.user_id
[SQL: SELECT flow.data AS flow_data,
flow.name AS flow_name,
flow.description AS flow_description,
flow.id AS flow_id, flow.user_id AS
flow_user_id
FROM flow
WHERE flow.user_id IS NULL]
(Background on this error at:
https://sqlalche.me/e/14/e3q8)

Deleting your cached langflow files fixed this for me.


cri registry e2e test

Signed-off-by: qinyer<EMAIL_ADDRESS>Signed-off-by: qinyer<EMAIL_ADDRESS>
What type of PR is this?

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #431
Special notes for reviewers:

Does this PR introduced a user-facing change?

Additional documentation, usage docs, etc.:

Codecov Report

Merging #433 (21caf1c) into release-1.3 (6bcaf82) will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff              @@
##           release-1.3     #433   +/-   ##
============================================
  Coverage        12.85%   12.85%
============================================
  Files              103      103
  Lines            15843    15843
============================================
  Hits              2036     2036
  Misses           13562    13562
  Partials           245      245

/lgtm
/approve


Parallelize BB processing script

This patch parallelizes the BB processing script. This significantly speeds up the processing of BBs. Eventually diminishing returns are reached, especially on systems with a large number of threads, most likely due to blocking on IO.

I'm seeing near linear speedup up to about 16 threads and then I start to hit diminishing returns.

Converting to a draft as it needs some more work. Currently not handling the case where a batch is left with some items at the end.

Closing this for now. I think I want to restructure this to do something different rather than just parallelizing in process. Adding Python bindings and using something like Apache Beam I think would enable more scalability for dataset processing.


(DRAFT) Handle "EULA not accepted" cases the same way for all routes

We need to handle all the user flows that check routes / actions to see if the user has accepted the EULA before proceeding, consistently.
For this, we can use a "middleware" approach to protect routes with 1 central logic for this use cases.

This repository is no longer maintained. It has been superseded by IBM Quantum Learning.


Return the StyleID for delegation

What is it?

[x] Feature / enhancement
[ ] Bug
[ ] Docs / tests

Description
Simply reveals the StyleID when using either useStylesScoped$ or useStyles$.
There is no reactivity for styles at the moment aside from adding or removing classes. Being able to render an additional <style scoped> before each element would help override some styles (or css variables) defined with useStylesScoped$ depending on props or state, making styles reactive.
As of now, while rendering an additional <style scoped> is possible (although it weirdly gets its own class=...), the styles in there do not override the ones from useStylesScoped$ as the latter are prefixed with a unique StyleID.
Returning this StyleID allows the user to inject it in the content of the additional aforementioned <style scoped>, allowing its styles to be applied to the element and properly override the default ones.
Use cases and why
This future enables delegation of the styleID to per-element styles for overriding the per-component styles.
const Room = component$(function Room ({very}) {

    // Cannot override here
    // useStylesScoped$ does not accept local identifiers
    const styleID = useStylesScoped$(
        `.chilly {
            background-color: lightblue;
        }`
    )

    return (
        <>
            <style scoped>
                {
                    // Can override here
                    // "very" is a local identifier
                    `.chilly.⭐${styleID} {
                        ${very ? 'background-color: lightcyan;'  : ''}
                    }`
                }
            </style>
            <div class='chilly'>
                BRRR!
            </div>
        </>
    )
})

This example demonstrates swapping a discreet style, which could be done by simply adding or removing classes. But the same cannot be said for discreet styles such as numbers, percentages, etc...
Take trying to set width or a color's alpha to a number passed through props for instance.
Checklist:

[X] My code follows the developer guidelines of this project
[X] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] Added new tests to cover the fix / functionality

not sure i like the idea of returning a scopeID as string, i think we should return an object, like {scopeId} so we can extend the API in the future in case we need to return more things without breaking changes


Trouble with fmriprep_ciftify_BIDS-app

I am running the following command:
docker run -ti --rm
-v /Users/neurolab/Desktop/Test_sub_002_fcmriprep_ciftify:/data:ro
-v /Users/neurolab/Desktop/Test_sub_002_fcmriprep_ciftify:/out
tigrlab/fmriprep_ciftify:1.1.8-2.1.1
/data /out/out participant
And receive the following message:
/usr/local/miniconda/lib/python3.6/site-packages/bids/grabbids/init.py:6: FutureWarning: grabbids has been renamed to layout in version 0.6.5, and will be removed in version 0.8
warnings.warn("grabbids has been renamed to layout in version 0.6.5, and will be removed in version 0.8", FutureWarning)
cmd: bids-validator /data
Failed with returncode 1
But it continues to run. The Data is BIDS valid.
What does that mean?
And can I run fmriprep_ciftify and tell it where to find the already executed recon-all folder?
Best

It looks like you might be mounting /Users/neurolab/Desktop/Test_sub_002_fcmriprep_ciftify to both /data and /out? This might be causing issues? Try mounting two different folders to /data and /out?
The /data folder needs to contain the bids validated inputs. (i.e. /data/sub-...)
Also, if the recon-all outputs are in the output folder (i.e. /out/freesurfer/sub-/..) ciftify should find work from them.
One way to check is to run the command with the "--debug --dry-run" flags. These will cause the bids-app to print all the steps fmriprep-ciftify would run to the terminal instead of running them. You can use this to get a better idea of what is happening.

I am doing now fmriprep and ciftify separately and that works fine. So thats okay.
But it seems to register my BOLD signal far up too cranial

That is the BOLD-Signal after ciftify_recon_all and ciftify_subject_fmri

And here the one after fmriprep:

Yes, something definitely went wrong there.
One question - is your T1w higher resolution (i.e. voxel size less than 1x1x1mm)?  I have noticed one bug where the header from the higher-res freesurfer pipeline outputs is not read properly - which causes big problems with the registration steps inside ciftify (like this one).
A way to check is to run fmriprep with the --no-submm-recon option and see if that fixes the problem.

Thanks a lot for the reply.
It is 1.2x1.2x1.2mm (GSP-Dataset)
I ran the pipeline with your suggested command and thats the result:

It still does not look correct.

I tried now do to ciftify_subject_fmri with --FLIRT-to-T1w and these are the results:
It see

![Uploading fmri_LM.png…](

)

The last version --FLIRT-to-T1w does look a lot better..  The good news is that the versions of ciftify above 2.2.0 use boundary-based registration (BBR) when running --FLIRT-to-T1w  using a white matter mask derived from the freesurfer outputs - which actually tends to work as well the BBR registration in fmriprep. So you might be good from here?
Are you taking the space-T1w outputs from fmriprep? Those would be the only one's that are registered to the T1w image (that ciftify would pull from) you may need to run rerun fmriprep with the --output-spaces T1w flag to get those.

Ok, I will have a look for them.
For some projects I am interested in analysis in the volume space not surface.
This would be that output: <task_label>.nii.gz  # the MNI transformed func.nii.gz ?
Is the method ciftify_vol_result helpful for preprocessing the volume data to cifti volume space?


Drop deprecated (Anko, kotlin-android-extension, android.preference) and Update

TODO:

[x] update sentry (from #52)
[x] update flipper
[x] update libpretixui → https://github.com/pretix/libpretixui-android/pull/12

On Android 9 (emulated) I get a NPE crash in EventSelectActivity.onCreate when accessing the binding.eventSelectList!!.eventsList for some reason. Not quite sure yet why. On Android 12 (emulated) this works.


Move scrapeHTML into its own package

I'd like to use your package from a React Native app, where the Node.js core modules are not available. scrape-it indirectly depends on tinyreq, which in turn uses Node's url module. I'm only using scrapeHTML, so all the networking stuff is not required. Could you move scrapeHTML into its own package, say "scrape-it-core", so people can use the offline functionalily independently? Thanks!

I was thinking of this too. Perhaps will wokr on this next days. Thanks for the idea! :sparkles:

I was thinking of this too. Perhaps will wokr on this next days. Thanks for the idea! :sparkles:


[consul] Wrong nodes count when filtering over service tags

Currently it's not possible to get the exact nodes count for a specific consul service tag. For example there could be obviously just one active and two standby vault servers, but the agent reports three.

Output from agent check consul
 {
   "metric": "consul.catalog.nodes_up",
   "points": [
     [
<PHONE_NUMBER>,
       3
     ]
   ],
   "tags": [
     "consul_datacenter:gc-europe-west1",
     "consul_service_id:vault",
     "consul_vault_service_tag:active",
     "consul_vault_service_tag:standby"
   ],
   "host": "master-b1-staging.c.nextjournal-com.internal",
   "type": "gauge",
   "interval": 0,
   "source_type_name": "System"
 },

This issue was addressed on https://github.com/DataDog/integrations-core/pull/5992


tauri_plugin_log::RotationStrategy::KeepAll does not work as expected on macOS

Description:
tauri_plugin_log::RotationStrategy::KeepAll seems to only keep the last 2 logs, instead of all logs as promised.
Repro steps:

Set up a project using tauri_plugin_log, and the following logger config:

tauri_plugin_log::Builder::default()
        .level(log::LevelFilter::Debug)
        .targets([
            Target::new(TargetKind::Stdout),
            Target::new(TargetKind::LogDir { file_name: None }),
            Target::new(TargetKind::Dispatch(make_sentry_logger())),
        ])
        .rotation_strategy(tauri_plugin_log::RotationStrategy::KeepAll)
        .build(),

Visit the logging directory (~/Library/Logs/<AppName>)
See the log file(s)
Close the app
Artificially inflate the size of the current log file to force rotation
Relaunch the app

Expected behavior:

Whenever a log gets rotated, it should be preserved, along with all previous logs

Actual behavior:

Only at most 2 .log files exist at a given time - the most recent log file, and the previous log file. All other older log files are lost.

Tauri info:
[✔] Environment
- OS: Mac OS 14.4.1 X64
✔ Xcode Command Line Tools: installed
✔ rustc: 1.76.0 (07dca489a 2024-02-04)
✔ cargo: 1.76.0 (c84b36747 2024-01-18)
✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
✔ Rust toolchain: stable-aarch64-apple-darwin (default)
- node: 20.10.0
- pnpm: 8.11.0
- yarn: 1.22.19
- npm: 8.1.2
[-] Packages
- tauri [RUST]: 2.0.0-beta.12
- tauri-build [RUST]: 2.0.0-beta.10
- wry [RUST]: 0.37.0
- tao [RUST]: 0.26.0
- tauri-cli [RUST]: 2.0.0-beta.12
- @tauri-apps/api [NPM]: 2.0.0-beta.0
- @tauri-apps/cli [NPM]: 2.0.0-beta.3
[-] App
- build-type: bundle
- CSP: unset
- frontendDist: http://localhost:5173/
- devUrl: http://localhost:5173/
- framework: React
- bundler: Vite

With the latest versions, it works as expected for me.

macOS: 14.5 (23F79)
tauri: 2.0.0-beta.24
tauri-plugin-log: 2.0.0-beta.8

tauri_plugin_log::Builder::new()
    .level(LevelFilter::Debug)
    .rotation_strategy(RotationStrategy::KeepAll)
    .max_file_size(10) // artificially low file size to exemplify
    .targets([
        Target::new(TargetKind::LogDir { file_name: None }),
    ])
    .build()

Result:


Proposal: Move this repo to metamath

@tirix said in issue https://github.com/david-a-wheeler/metamath-knife/issues/64 that:

I support moving this repository to the metamath organization.

That also makes sense to me.
However, I want to make sure that others accept this move before we do it. I believe we can just move this whole repo under https://github.com/metamath and keep everything (issues, history, etc.).
All those in favor please add a "+1". If you have other thoughts, please indicate that too.
Thank you!

@digama0 - thoughts?

Sounds good to me. I think we can just have it owned by the metamath org for maintenance purposes as well, similar to metamath-exe.

Very good. I'll leave this proposal up for a bit, to give people a little to object and/or warn of some issue.

All: The metamath-knife repository has now been moved to:

https://github.com/metamath/metamath-knife/

All issues and pull requests moved with it. Requests to the old URL will generally be forwarded.
If you have an existing copy of the repo, go to it and type:
git remote -v

That will show you the names of the remotes (often "origin" or "upstream"). You can use get remote set-url to change things (and then use "git remote -v" to see the result), e.g.:
git remote set-url origin https://github.com/metamath/metamath-knife

I'm going to close this as I think it's done.


Readme: added "new" to Hover constructors

Fixes #23

Coverage remained the same at 100.0% when pulling d1e4eb2024252f0bb0438f4d66bd4294e03a5baf on bfred-it:master into d07e7f2624d2442686305c5539a3ebf6962eecc0 on jesseskinner:master.

Coverage remained the same at 100.0% when pulling 23b49f85dff0f41ce96b995e4da5defb4b6deec6 on bfred-it:master into d07e7f2624d2442686305c5539a3ebf6962eecc0 on jesseskinner:master.

Thanks!


docs: add e2e tests README

#391  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @davidlj95 and the rest of your teammates on  Graphite


[WIP] Add policy based routing test

Issue: https://github.com/networkservicemesh/api/issues/119
Signed-off-by: Artem Glazychev<EMAIL_ADDRESS>

@edwarnicke @zolug @tedlean
Could you please take a look at this example? It is related to Policy Based Routing issue.
Is this what we want to see?

OK, I see that protocol numbers are known https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers
So merging.
@edwarnicke Let us know if you will have any questions or comments on this example.