Tracking integrations with other technologies

I've recently opened a few issues for integration with other technologies:
Azure Service Operator: https://github.com/Azure/azure-service-operator/issues/1377
Crossplane:

ALibaba Cloud: https://github.com/crossplane/provider-alibaba/issues/57
Rook: https://github.com/crossplane/provider-rook/issues/94
GCP: https://github.com/crossplane/provider-gcp/issues/304
AWS: https://github.com/crossplane/provider-aws/issues/537
Azure: https://github.com/crossplane/provider-azure/issues/221

I was thinking, would it make sense to document in a page what the tools are that we integrate with and they can use KEDA with?
This could be in our docs, in this repo or in something like kedacore/integrations.

WDYT @zroubalik @jeffhollan @anirudhgarg @ahmelsayed ?

I'm not very familiar with crossplane, but I'm assuming it's a way to standardize operators across clouds for those cloud's services, but just managed through Kubernetes, right? Based on the issues you have above though, they don't yet support the /scale subresource, right?

Yes indeed, but Crossplane is just an example of one integration - But it's just an idea though.

This could also be part of keda.sh, which might be a better place under /integrations or so.

We've agreed to add this to keda.sh, tracking in https://github.com/kedacore/keda-docs/issues/387


Exo Chestpiece + Jetpack = No longer enchantable

Issue description
The Exo Chestpiece is, well, a chestpiece, and can be enchanted with chestpiece and armor enchantments.
The Jetpack is not a chestpiece and thus can't be enchanted with those stuff.
Perfectly reasonable so far.
Then you combine the Jetpack with the Exo Chestpiece into a single piece, and you'd think that would be a jetpack chestpiece.
Buuuut, no. It can't be enchanted at all. Not a single enchantment is available on the merged item. So for those enchantments that only goes on the chestplate, well to bad they can't be applied anymore.
I think, that since it IS a chestpiece that you're adding a jetpack ontop of, it should still be enchantable with everything that usually goes onto chestpieces.
The same thought goes when you combine it with the Elytra, which in some mods also have elytra specific enchantments. They should work when you combine the chest (or the chestjetpack) with the Elytra.
It makes no sense that the piece suddenly can't be enchanted with anything at all.
Steps to reproduce
1: Combine Exo Chestpiece with Jetpack
2: Try to enchant with Armor or Chest enchantments, or just the Enchantment table.
3: Nope, can't do that.
Minecraft version
1.21.1 (Latest)
Fabric loader version
0.16.7
Fabric API version
The latest
Oritech version
oritech-0.10.3
Other relevant versions
1.21 and 1.21.1
If a (crash)log is relevant for this issue, link it here: (It's almost always relevant)
No response

Good catch, thanks. The variants not being enchantable is something I missed when implementing them. I'll fix it in the next update.


fix: Use source "response.text" for any mime-type starting with text/

Responses with Content-Type: text/csv or Content-Type: text/xml ought to be treated the same as text/html

Awesome, thanks! I don't think we have any e2e tests for text-based responses yet. Could you add something to end_to_end_tests/openapi.json for some common ones (maybe text/html, text/csv, text/plain)? More details in CONTRIBUTING.md

Will resolve #797 and #821 once completed

Replaced with #897 since I can't edit this PR.


[ECharts] Color / style of time shift line is confusing

A clear and concise description of what the bug is.
In current time series chart, the time shift is in dashed line of same color.
In e-charts the time shift line is different color, making it appear as a completely different data line. This is confusing to users (and will be especially confusing when there are multiple lines on the chart).
How to reproduce the bug
Create time shift for time series chart in echarts.
Expected results
Lines should be same color, one dashed one full line, OR this can be left up to user to configure. Currently it looks like two completely different data point lines.
Actual results
Lines have different colors.
Screenshots
First image = nvd3 charts
Second image = e-charts

Environment
lastest master
Checklist
Make sure to follow these steps before submitting your issue - thank you!

[x] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[x] I have reproduced the issue with at least the latest released version of superset.
[x] I have checked the issue tracker for the same issue and I haven't found one similar.

If there are multiple time shifts for a certain series, should we cycle through different dashing options or even revert back to changing colors at some point?

The nvd3 charts handle it by cycling through multiple dashing options.

I haven't seen users using more than 2 time shifts in a single chart, but it could certainly happen - the setup allows that.
This would be the best solutions in order:

User can chose whether to use dashed line or different color (even if they can't chose what color / what type of dash)
Current experience - dashed line
(not preferred) Current e-chart solution - lines are different colors

cc @graceguo-supercat

I think this issue is still relevant for when we evaluate feature parity with echarts before deprecating nvd3; Maybe it's a feature as opposed to bug, so I will move it to dicsussions.


fix symbols in sensu_agent config, closes #51

cc @cwjohnston ✌

Thanks @scalp42 !
I’m cool with this, tests pass.


Optional warning when closing Hourglass

To avoid accidentally closing hourglass and missing an upcoming alert, add an option that makes the window's close button minimize the app instead of exiting. Alternately make the window close button prompt whether to exit or minimize.

Fantastic! No more accidentally dismissed timers :-)


Add support for streamed messages split in multiple frames

Hi,
As I mentioned in tony612/protobuf-elixir#11 I'm working on a Google Cloud Bigtable client and I'm running into problems working with googles developer emulator.
It turns out that the server might split the protobuf payload into multiple data frames that are less than the size of the payload even though the window size can contain the full payload. This results in an exception in stub.ex L166 when the non-complete payload is unmarshalled. The exception is similar to the to the problem mentioned in #27 that was fixed in parse_unary_response.
This PR fixes this problem for streamed responses by buffering incomplete data frames until they are complete and can be treated as complete grpc messages.
One question:
The unfold accumulator keep a list of all the received data frames but doesn't use it for anything, what's the reason for this?

@ssboisen ping

I AFK this week, will get back to you monday :-)
tir. 17. okt. 2017 kl. 16.12 skrev Bing Han<EMAIL_ADDRESS>
@ssboisen https://github.com/ssboisen ping
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tony612/grpc-elixir/pull/35#issuecomment-337244503,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjC7b5KjmDCF3xKQk6uw_voB0GSZSV7ks5stLXKgaJpZM4P4jAX
.


Merge dev into master

This is mainly to get Jainam's changes into master that didn't make it in earlier. Also bumping connector-packager version to 1.0 because we haven't changed it since the first release.

Hi, @pvanderknyff! Thanks for opening this PR!

In the file connector-packager/connector_packager/package.py:

Line 30:121: E501 line too long (186 > 120 characters)

In the file connector-packager/connector_packager/xml_parser.py:

Line 167:91: W291 trailing whitespace

For reference: Error Code Reference, PEP8, Python code style


Linux: Build process fails

Description
Build process fails on Arch Linux.
Steps To Reproduce
Arch Linux (flutter: 3.24.2 / dart: 3.5.2)
git clone https://github.com/tsinis/colors_ai.git
cd colors_ai
flutter build linux -v --release

Additional Context
build.log

Hey @lapicidae, thanks for the report, but this repository is being archived due to a lack of time and the presence of significant technical debt. Thank you for your understanding in advance!


Transfer then evolve

Calculate first the number of pokemon to transfer and then the updated number of pokemon to evolve.
Also the math is know taking consideration of the bonus candy after each evolution

"Only for 12 candies pokemon" Would be a must in my opinion

Do you mean showing this column and updated number of evolution just for 12 candies Pokemons and not for the other ones ?

Yes. The only pokemon you want to evolve in batch are pidgey, caterpie and weedles... which are the one providing easy exp

That's true, but having the information does not hurt right ?
While being more candy-expensive Rattata and Zubats are pretty common as well.
A screenshot of my zubats below,

Note than technically there is enough candy just for 3 evolutions but by transferring and because of the evolution bonus candy, I can grind for a fourth evolution.
I could not transfer the Zubats and still be able to do 4 evolutions but I personally like to keep my pokemon count as low as possible.

Same for me.
For when is the batch evolution coming ?
Félix Provost-Poulin
Software Engeneer Bacc. and MBA Candidate
Cellulaire :<PHONE_NUMBER>
2016-08-09 22:19 GMT-04:00 Periphanos Alexandre<EMAIL_ADDRESS>
That's true, but having the information does not hurt right ?
While being more candy-expensive Rattata and Zubats are pretty common as
well.
A screenshot of my zubats below,
[image: image]
https://cloud.githubusercontent.com/assets/5519146/17539669/58ff5cf2-5ef3-11e6-8e15-d0a52515e185.png
Note than technically there is enough candy just for 3 evolutions but by
transferring and because of the evolution bonus candy, I can grind for a
fourth evolution.
I could not transfer the Zubats and still be able to do 4 evolutions but I
personally like to keep my pokemon count as low as possible.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/cglatot/PokeManager/pull/52#issuecomment-238748151,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARHK3zmBICzYNVvhGSwcE6mkWdcKCOfbks5qeTUvgaJpZM4Jgr0r
.

I realized the title of the pull-request was misleading, this code modification does not automatically transfer and evolve it just shows the number for you to manually do it.
The actual batch evolution, hmmm, I am going to have a look !

To many changes - closing


Book: Understanding ECMAScript 6

Book by Nicholas C. Zakas (principal architect at Box) about all the heavy changes in ES6.
Was proposed a few times on resourses slack channel and on forum.
I would like to recommend it because I found it much easier to understand comparing to MDN

@kshpikat Thank you for your commit. Unfortunately i have some remarks before we can merge your PR:

Briefly write a description and why it should be added to the list

Please make sure you read the contribution guidelines before submitting a PR next time.

Hi @jvaes! Thank you for feedback! I never contributed before into open-source projects so was not aware of contribution guidelines. I apologize for inconvenience.
I updated the description and also fixed the link to free available book online.
Please let me know if there is something more I need to do.
Thank you!

LGTM 👍

Thanks for your contribution @kshpikat


Renaming method causes behavior change

Does this issue occur when all extensions are disabled?: Yes/No

-VS Code Version: 1.88.1
-OS Version: Windows11
-Language：java
Steps to Reproduce:
1.select "m()"
2.click “Rename”
3. new name "hashCode()"
// rename m() to hashCode()
interface I{
String m();
}

/extJava

It looks like this is caused by the Java extension. Please file the issue to the Java extension repository. Make sure to check their troubleshooting instructions and provide relevant information such as the extension version you're using. See also our issue reporting guidelines for more information.
Happy Coding!


AFC <IP_ADDRESS> New Bug

X17 R1 11980HK, 3080, 21H2 patched
First off, kudos for addressing AFC several issues with this build that I had been having but didn't have the drive to report to you (sorry).
STEPS TO CAUSE

Used zip file o overwrite all AFX files in my folder. Ancillary issue: this caused the loss of my existing Manual curves. Many past builds seem to do that too. I almost exclusively use pretty simple fan curves, with identical ones for CPU fan tied to CPU temp and GPU fan tied to GPU temp.

Created CPU fan curve. Fan and GUI did as expected.

Created GPU fan curve.

BUG
As soon as the GPU curve was completed (perhaps after I clicked back to the CPU fan option, uncertain of exact timing of the start), the fan curves disappeared and both fans started ramping up. They continued ramping up all the way to my overspeed max values - which is well past what you can actually get with Manual curves, as we have discussed before.
I have not yet attempted to reproduce this, but will do so now and report back.

Upon restarting AFC the following was noted:
A) The 3rd and 4th fans, which were previously labeled SSD 1 and SSD 2, changed names to be CPU 3 and GPU 4. I may have noticed this in the past, uncertain.
i) These two fans SHOULD be labeled CPU 2 and GPU 2, as the X17 does have 4 fans on each side. I currently cannot remember which heat pipe sections they are "associated" with, but I can get that from the X17 Service Manual.
i) Very briefly, the 4th tmp fan speed went to 900 rpm for a few seconds, then returned and remained at 0.
B) Both CPU and GPU fan curves were gone.
i) CPU fan curve was default linear line, and that fan responded as expected (red dot and fan speed prepresentative of where the temp/speed line was at)
ii) GPU fan curve was blank, and GPU fan ramped up to max. While writing this up, the GPU fan speed actually reduced to a reasonable value, then went back to max after some time with no change in computer usage.
I apologize, but I have a family commitment and cannot get you screenshots. I know that I have posted my simple fan curves in the past on prior issues though if you get a chance to work this before I can update this ticket with new ones.

POSSIBLY NEW BUG:
I just noticed that I have TWO alienfan-gui.exe copies running currently. That should not be allowed.
The second of the two shut down as expected when I X'd out. The 2nd did NOT close when I X'd out.
Using the Exit button DID close the initially-opened app.

It's impossible. Configuration does not impact by update, it's into Registry. But - new user have cleaned one, it's user-based.
and so. Please use alienfx-config backup console command and share afx-fans.reg here -i'll check what you have into configuration.

Yes, after some update, fans now have names by it's function. Number is a fan number into the system, as reported by BIOS, so 3-4 is NOT a bug, but hint.
Please keep in mind, fan control is INDIRECT for this hardware, so real RPM controlled by BIOS, i just add some hints and flexibility for it. I can only increase RPM, not decrease it.
2 copies is OK, it's useful sometimes. They do not interfere to each other, just consume a bit more CPU.
Yes. MANY people ask me to make this reaction to "x" - this apps intended to run all the time, so it's the protection against accidentally closing it. Quit only possible via "Exit" button, application top or tray menu. Even ALT-F4 will minimize it.

Wonkiness continues with this build.
A) While adjusting CPU undervolt and benchmarking, I set AFC to Level 4 to keep fans high. I experienced several crashes of various benchmarking apps during this cycle, including a number of BSOD's.
It came to be that no matter whether AFC was running or not, my fans would go to super-max speed (well above Level 4's numbers). When Win started, fans went to max - and I do not have AFC set to start on boot. If I started AFC and changed the level numbers, it seemed to behave as expected. When I changed to Manual, it ignored that and blasted to max speed again. This was repeatable over reboot cycle too.
Digging though the Doc files (very helpful, btw!!), I found there was an "Unlock" command, which would enable manual fan control. I tried that, and sure enough I was able to regain the use of Manual mode. YAAAAYYY! :-D
Oh, one further thing. During one of the periods when I was on Manual, the fan speeds for fans 3 and 4 went thousands of RPM above their max boost levels!! Over 6K for one and about 5500 for the other.
B) Before starting my undervolting exercise, AFC yet again lost my fan curves. This has been a recurring theme for me for probably every build I have tried.
C) While doing research, I compared the current reg export with one from earlier this year (both attached). I noticed two new entries:
"DPTF"=dword:00000000
"KeepSystemMode"=dword:00000001
I am curious what those are for. Actually, I am curious about all of the reg values. Could you add that info to the Doc files?
D) Does the fact that the Power Levels are not in the same numerical order as their names? I would guess not, but ask because I have noticed some inconsistency between the level and the fan speeds.
AFC_Reg_Exports.zip

I'll start from the last.
DPTF - this flag force DPTF (ESIF) name check. It's long operation, so i do it once only - if driver present and can be run, until read.
KeepMode - it's about your point "A". Normally (if it set), app store power mode at start and restore it back at quit. In case it is not checked (0) - app will keep last mode selected into it after quit. So you can use it to switch default system mode (as well as CLI). It's in Settings, in fact.
Level order - yes, it is. First level order created based on BIOS report order, but later registry sort it, so it will be different. In fact, it's intended to be renamed, so it's important to keep the same order all the time.
Curves... This just CAN NOT be like this. Source is other, most probably unchecked sensors. I see you have it in Registry.
BTW, some systems can report incorrect RPMs for a second, so it's OK. It is not used anyway, just shown. ^_^

Thanks for the responses!
I may have found a reason why fans 3 and 4 run up to super-max speeds: those two have NO "curve" for either temperature (CPU or GPU). Always in the past I would have a default curve which was a straight line from lower-left corner to upper-right corner. That is missing for fans 3 and 4 for both temperatures. Could this be the cause of my behavior? In any case, is there a way I can get the default curve to show so I can adjust it? Or perhaps just copy the curve I use for one of the other fan/temp pairs to these two?

When you say "Source is other, most probably unchecked sensors.", what, exactly, do you mean there?

Curve deletion now is a 2-stage process. In case you just uncheck sensor, curve still in memory, but not shown/used in calculations. But it will be removed completely at application quit (not saved in config, in fact). So do not do it except for experiments, or you lost it.

those two have no "curve" for either temperature (CPU or GPU).

In this case, fan fully controlled by BIOS and not touched by app. BIOS decide what sensors and values it uses (fan name give a hint about it).

Always in the past I would have a default curve which was a straight green line from lower-left corner to upper-right corner.

It's different case. Boost will be controlled by app, and have some boost value all the time.

In any case, is there a way I can get the default curve to show so I can adjust it?

In the first case - no, it's 100% BIOS-defined, and i have no data about it.
Into the second case - yes, it's a common control case. But, anyway, you can't set it below BIOS value.
Better set common S-shaped curve for it with 60-70C border.


ImageManip: rotated/arbitrary cropping, add camera controls

Extend ImageManipConfig with Warp related functionality:void setCropRotatedRect(RotatedRect rr, bool normalizedCoords = true);
void setWarpTransformFourPoints(std::vector<Point2f> pt, bool normalizedCoords);
void setWarpTransformMatrix3x3(std::vector<float> mat);
void setWarpBorderReplicatePixels();
void setWarpBorderFillColor(int red, int green, int blue);
void setRotationDegrees(float deg);
void setRotationRadians(float rad);

Add ImageManipConfig API allowing to skip or reuse a frame (useful when ImageManip inputImage is connected directly to the camera, and it has to process a series of bounding-boxes, or none). Usable only with setWaitForConfigInput(true)void setReusePreviousImage(bool reuse);
void setSkipCurrentImage(bool skip);

Extended CameraControl with ISP / 3A commands:
https://github.com/luxonis/depthai-core/blob/58033d6/include/depthai/pipeline/datatype/CameraControl.hpp
https://github.com/luxonis/depthai-shared/blob/7fd5976/include/depthai-shared/datatype/RawCameraControl.hpp
ColorCamera / MonoCamera nodes: added inputControl input, that can take control commands during runtime. Applying a set of initial commands on the Mono/ColorCamera->initialControl is also possible, but only these are implemented for now (will be extended in future):void setAutoFocusMode(AutoFocusMode mode);
void setManualFocus(uint8_t lensPosition);

Deprecated ImageManip API that was common to ImageManipConfig, in favor of applying on imageManip->initialConfig (shared with runtime messages passed via inputConfig):
imageManip->setCenterCrop(0.7f) -> imageManip->initialConfig.setCenterCrop(0.7f)
NeuralNetwork: added void setNumInferenceThreads(int numThreads); - could set more than 1, but usually not recommended more than 2. Was used to improve the performance on OCR demo (two networks: text detection and bounding-box text recognition -- the latter was configured with two threads).
Added auto/manual exposure/focus controls to color_camera_control_example.cpp
Added new example: image_manip_warp_example.cpp

Related PR: https://github.com/luxonis/depthai-shared/pull/16

Updated PR description with a list of changes. Merging.


ELSA workflow designer not supporting in angular 9 application

Hi, I want to integrate the ELSA workflow designer in an angular 9 application. To implement that I followed all steps mentioned in this URL(https://github.com/elsa-workflows/elsa-designer) but the UI is not showing.

Maybe this thread provides some hints: https://github.com/elsa-workflows/elsa-designer/issues/18


package the maintainer vim and lua updaters

Description of changes
Fixes https://github.com/NixOS/nixpkgs/issues/249783
The nixpkgs documentation mentions how to update out of tree plugins but one problem is that it requires a nixpkgs clone.
I've had the need to generate vim plugins and lua overlays for other  projects unrelated to nix and this PR makes this workflow easier (aka just run nix run nixpkgs#vimPluginsUpdater ....
I added an optional "nixpkgs" argument to command line parser, which is the path  towards a nixpkgs checkout. By default the current folder.
I have checked that the kakoune updater works. Same for lua updater (issues are unrelated).
I also wonder if this requires a documentation entry. I can do this afterwards: I first would like to run a luarocks update since I've already diagnosed the existing issues.

Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

this is ready for review. I updated the doc and plans to do the same with the luarocks updater this week.


data: ralphsulit

Fixes Issue

Changes proposed

Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[ ] My change requires changes to the documentation.
[ ] I have updated the documentation accordingly.
[x] All new and existing tests passed.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

Screenshots

Note to reviewers

removed avatar and trailing comma. thank you.


migrate diff for auth schema on Supabase creates invalid SQL

Bug description
When introspecting and baselining a Supabase auth schema with prisma db pull and prisma migrate diff, the generated migration file contains some invalid SQL. This causes prisma migrate dev to fail:
Error: P3006

Migration `0_init` failed to apply cleanly to the shadow database.
Error:
db error: ERROR: cannot use column reference in DEFAULT expression
   0: migration_core::state::DevDiagnostic
             at migration-engine/core/src/state.rs:264

How to reproduce
This repo contains instructions to reproduce the issue: https://github.com/sbking/prisma-supabase-diff-issue
Expected behavior
prisma migrate diff creates two column DEFAULTs which contain column references and should use GENERATED DEFAULT AS. Compare with pg_dump output:
pg_dump generates:
CREATE TABLE auth.identities (
    ...
    email text GENERATED ALWAYS AS (lower((identity_data ->> 'email'::text))) STORED
);

CREATE TABLE auth.users (
    ...
    confirmed_at timestamp with time zone GENERATED ALWAYS AS (LEAST(email_confirmed_at, phone_confirmed_at)) STORED,
    ...
);

prisma migrate diff generates:
CREATE TABLE "auth"."identities" (
    ...
    "email" TEXT DEFAULT lower((identity_data ->> 'email'::text)),
    ...
);

CREATE TABLE "auth"."users" (
    ...
    "confirmed_at" TIMESTAMPTZ(6) DEFAULT LEAST(email_confirmed_at, phone_confirmed_at),
    ...
);

Prisma information
See https://github.com/sbking/prisma-supabase-diff-issue/blob/main/prisma/schema.prisma
Environment & setup

OS: macOS
Database: PostgreSQL
Node.js version: 18.12.1

Prisma Version
prisma                  : 4.8.1
@prisma/client          : 4.8.1
Current platform        : darwin-arm64
Query Engine (Node-API) : libquery-engine d6e67a83f971b175a593ccc12e15c4a757f93ffe (at<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli d6e67a83f971b175a593ccc12e15c4a757f93ffe (at node_modules/@prisma/engines/migration-engine-darwin-arm64)
Introspection Engine    : introspection-core d6e67a83f971b175a593ccc12e15c4a757f93ffe (at node_modules/@prisma/engines/introspection-engine-darwin-arm64)
Format Binary           : prisma-fmt d6e67a83f971b175a593ccc12e15c4a757f93ffe (at node_modules/@prisma/engines/prisma-fmt-darwin-arm64)
Format Wasm             : @prisma/prisma-fmt-wasm 4.8.0-61.d6e67a83f971b175a593ccc12e15c4a757f93ffe
Default Engines Hash    : d6e67a83f971b175a593ccc12e15c4a757f93ffe
Studio                  : 0.479.0
Preview Features        : multiSchema

The SQL could point to this being a side effects of https://github.com/prisma/prisma/issues/6336

Is this still being looked at? Seems like it's still an issue especially with Supabase schemas.

Ran into exactly the same thing. @sbking did you end up figuring it out?

+1

I found a solution.
https://github.com/prisma/prisma/issues/1122#issuecomment-1510359508

Guys this is a solution for those trying to use prisma and supabase auth
https://tobicode.hashnode.dev/integrating-supabase-with-prisma-and-trpc-a-comprehensive-guide


Error with multiple comparisons correction

I am trying to replicate some of my previous results that I have found with NPM using the lesymap toolbox, but I am getting strange outputs depending on what I set for the multiple comparisons option.
When I ask for BM tests or t-tests using FDR, Bonferroni or holm (I haven't tried all the options), lesymmap produces z-maps with uniform zeros. Like below:

Lesymap Summary:
Subjects            : 27
Method              : ttest
Voxels in mask      : 107372
Method              : ttest
Multiple comparison : fdr
P-threshold         : 0.05
Statistic range     : 0 0
Significant voxels  : 0
Runtime             : 8.1 secs

Version             : <IP_ADDRESS>03

If I change the multiple comparisons option to a meaningless string ("hjhjh"), I get non-zero values. Here is an example with t-tests :

Lesymap Summary:
Subjects            : 27
Method              : ttest
Voxels in mask      : 107372
Method              : ttest
Multiple comparison : hjhjh
P-threshold         : 0.05
Statistic range     : -3.6 3.2
Significant voxels  : 107372
Runtime             : 8.1 secs
Version             : <IP_ADDRESS>03

With this meaningless string, the t-test values look reasonable to me, but the BM Z-scores are on an unreasonably wide range:

Lesymap Summary:
Subjects            : 27
Method              : BM
Voxels in mask      : 107372
Method              : BM
Multiple comparison : hjhjh
P-threshold         : 0.05
Statistic range     : -50.9 14
Significant voxels  : 105444
Runtime             : 14 secs
Version             : <IP_ADDRESS>03

Not sure what I might be doing wrong here?
Thanks again,
Avi

T scores look pretty low. I'm not surprised the correction kills them all.
They also look ranging equally both negative and positive which is a bit
unusual.
Two questions:

Are behavioral scores decreasing or increasing for lesioned voxels?
Lesymap expects lesions to produce lower scores.
Have you checked stats.img itself instead of zmap.img for BM? Does it
give a reasonable output?

On Fri, Oct 20, 2017, 01:00 avrvaidya<EMAIL_ADDRESS>wrote:

I am trying to replicate some of my previous results that I have found
with NPM using the lesymap toolbox, but I am getting strange outputs
depending on what I set for the multiple comparisons option.
When I ask for BM tests or t-tests using FDR, Bonferroni or holm (I
haven't tried all the options), lesymmap produces z-maps with uniform
zeros. Like below:
Lesymap Summary:
Subjects : 27
Method : ttest
Voxels in mask : 107372
Method : ttest
Multiple comparison : fdr
P-threshold : 0.05
Statistic range : 0 0
Significant voxels : 0
Runtime : 8.1 secs
Version : <IP_ADDRESS>03
If I change the multiple comparisons option to a meaningless string
("hjhjh"), I get non-zero values. Here is an example with t-tests :
Lesymap Summary:
Subjects : 27
Method : ttest
Voxels in mask : 107372
Method : ttest
Multiple comparison : hjhjh
P-threshold : 0.05
Statistic range : -3.6 3.2
Significant voxels : 107372
Runtime : 8.1 secs
Version : <IP_ADDRESS>03
With this meaningless string, the t-test values look reasonable to me, but
the BM Z-scores are on an unreasonably wide range:
Lesymap Summary:
Subjects : 27
Method : BM
Voxels in mask : 107372
Method : BM
Multiple comparison : hjhjh
P-threshold : 0.05
Statistic range : -50.9 14
Significant voxels : 105444
Runtime : 14 secs
Version : <IP_ADDRESS>03
Not sure what I might be doing wrong here?
Thanks again,
Avi
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dorianps/LESYMAP/issues/4, or mute the thread
https://github.com/notifications/unsubscribe-auth/AIqafVJiCCgr6qhjp42O6FqjIWEBfJKFks5suCjkgaJpZM4QAMFO
.

The behavioral scores are coded so that negative scores = worse performance
in this task.
Stats.img seems to reflect the range of stats in the lesymap summary, which
I assume is meant to be thresholded at pThreshold. However, even when I
have significant results according to some threshold, the z-score map is
blank.
I also think that the thresholding for the stats and z-score images is not
working properly... When I run the same analysis with a pThreshold set to
0.9, I get the exact same results as a threshold of 0.05.
Again, I am also surprised that the stats for the BM test are so different
from NPM. For reference, when I reran this analysis in NPM, the t-stats
range from -2.9-3.2 (where as the range is -3.2-3.6 in lesymap), and the BM
z-scores ranged from -2.96-3.20 (while lesymap gives a range of -50-14).
Thanks again for your fast responses!
Avi
On Fri, Oct 20, 2017 at 2:37 AM, dorianps<EMAIL_ADDRESS>wrote:

T scores look pretty low. I'm not surprised the correction kills them all.
They also look ranging equally both negative and positive which is a bit
unusual.
Two questions:

Are behavioral scores decreasing or increasing for lesioned voxels?
Lesymap expects lesions to produce lower scores.
Have you checked stats.img itself instead of zmap.img for BM? Does it
give a reasonable output?

On Fri, Oct 20, 2017, 01:00 avrvaidya<EMAIL_ADDRESS>wrote:

I am trying to replicate some of my previous results that I have found
with NPM using the lesymap toolbox, but I am getting strange outputs
depending on what I set for the multiple comparisons option.
When I ask for BM tests or t-tests using FDR, Bonferroni or holm (I
haven't tried all the options), lesymmap produces z-maps with uniform
zeros. Like below:
Lesymap Summary:
Subjects : 27
Method : ttest
Voxels in mask : 107372
Method : ttest
Multiple comparison : fdr
P-threshold : 0.05
Statistic range : 0 0
Significant voxels : 0
Runtime : 8.1 secs
Version : <IP_ADDRESS>03
If I change the multiple comparisons option to a meaningless string
("hjhjh"), I get non-zero values. Here is an example with t-tests :
Lesymap Summary:
Subjects : 27
Method : ttest
Voxels in mask : 107372
Method : ttest
Multiple comparison : hjhjh
P-threshold : 0.05
Statistic range : -3.6 3.2
Significant voxels : 107372
Runtime : 8.1 secs
Version : <IP_ADDRESS>03
With this meaningless string, the t-test values look reasonable to me,
but
the BM Z-scores are on an unreasonably wide range:
Lesymap Summary:
Subjects : 27
Method : BM
Voxels in mask : 107372
Method : BM
Multiple comparison : hjhjh
P-threshold : 0.05
Statistic range : -50.9 14
Significant voxels : 105444
Runtime : 14 secs
Version : <IP_ADDRESS>03
Not sure what I might be doing wrong here?
Thanks again,
Avi
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dorianps/LESYMAP/issues/4, or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AIqafVJiCCgr6qhjp42O6FqjIWEBfJKFks5suCjkgaJpZM4QAMFO>
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dorianps/LESYMAP/issues/4#issuecomment-338119063, or mute
the thread
https://github.com/notifications/unsubscribe-auth/Afac64vyCvIvCCLHZb5sUjSsSacBtWFAks5suD-agaJpZM4QAMFO
.

Hi Avi,
There was a small bug that skipped thresholding maps when multipleComparison='none'. I should have fixed it in the last commit a few minutes ago. Update the package to have it take effect.
What you described above might very well come come because you selected an unknown multiple comparison method. That was considered same as no threshold at all. The last commit has a new check, so now you will receive an error if multipleComparison is unkown.
Please check if this fixes the p-value issue. Then check if the maps you get  from stat.img or zmap.img are similar to what you get from MRIcron. If the spatial match is good but values are wrong, I will need to run some troubleshooting with examples with small sample sizes like yours.
Dorian

Great! That seems to have fixed the thresholding problem for t-tests.
It looks to me like the t-tests are providing mostly sensible answers...
The stats map, z-values and spatial pattern match what I find using NPM,
though the values continue to be higher in both directions, as I mentioned
before.
However, with BM tests, I am continuing to get very weird results. The
spatial match is more or less accurate, but is weirdly spotty... Here are
comparisons of results in NPM and with lesymap (both unthresholded):
NPM:
[image: Inline image 1]
Lesymap (patches off):
[image: Inline image 2]
The values are also far off: the lesymap range is still between -50-14.
The spottiness only appears with I have the patch option turned off. With
patches turned on, the spatial pattern looks better, but is still over a
much larger range than in NPM (lesymap: -7.2-14):
Lesymap (patches on):
[image: Inline image 3]
I have also noticed that even when using Bonferroni, or no multiple
comparison correction, Lesymap seems to be running permutations for BM
tests, but not for t-tests.
Thanks again,
Avi
On Fri, Oct 20, 2017 at 1:52 PM, dorianps<EMAIL_ADDRESS>wrote:

Hi Avi,
There was a small bug that skipped thresholding maps when
multipleComparison='none'. I should have fixed it in the last commit a
few minutes ago. Update the package to have it take effect.
What you described above might very well come come because you selected an
unknown multiple comparison method. That was considered same as no
threshold at all. The last commit has a new check, so now you will receive
an error if multipleComparison is unkown.
Please check if this fixes the p-value issue. Then check if the maps you
get from stat.img or zmap.img are similar to what you get from MRIcron. If
the spatial match is good but values are wrong, I will need to run some
troubleshooting with examples with small sample sizes like yours.
Dorian
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dorianps/LESYMAP/issues/4#issuecomment-338278022, or mute
the thread
https://github.com/notifications/unsubscribe-auth/Afac6-_4sJ5BeN74a9RwQc7wpze__1cGks5suN36gaJpZM4QAMFO
.

Images didn't get through. You can post them on the github issue page and they will show:
https://github.com/dorianps/LESYMAP/issues/4

The spottiness only appears with I have the patch option turned off. With
patches turned on, the spatial pattern looks better

I don't think you should switch patches off. MRIcron also runs patch-based analyses. With small sample sizes there are a lot of voxels with identical patches that just increase the number of multiple comparisons if analyzed all.

I have also noticed that even when using Bonferroni, or no multiple
comparison correction, Lesymap seems to be running permutations for BM
tests, but not for t-tests.

This is intentional. BM tests needs permutations at the voxel level if one of the groups has less than 9 subjects (see here. Your sample will have a lot of voxels below that value, so you see permutations being run for those voxels. T-tests are not subject to the problem, so you just see standard voxel-wise tests. Note that permutations for BM are done at each voxel, which is different from permutation-based multiple comparison corrections (multipleComparison='FWERperm'). By the way, if you are comparing lesymap with mricron, try the permutation based multiple comparison on both, that is one of the most robust thresholding mechanisms.

the values are also far off: the lesymap range is still between -50-14.
This is what I am trying to understand. The BM method in lesymap currently relies on the nparcomp package. Will need to check if that package is giving back reasonable values.

Here are the un-thresholded BM stats from my last post:
NPM:

Lesymap (no patches):

Lesymap (patches):

Using FWERperm for multiple corrections and BMfast tests, my results also diverge from NPM. In NPM, the FWE permutation threshold was Z = -3.21 for p = 0.05 (with lower scores = worse performance). In that analysis, I had voxels crossing that threshold at Z = -3.32. In lesymap, nothing comes out significant with FWERperm and patches. If I drop the threshold by a lot (p = 0.5), then I get a few voxels with very high Z values (Z = 14), and a few other small patches (Z=2.67), but these are all in the opposite direction of my NPM results, and in different locations.

Looks like NPM (which uses patches) matches Lesymap's output with patches. The scattered results might come from the stronger correction for multiple comparison, but it also looks like you are using MRIcron to view the data, which has it's own automatic thresholding when overlays are displayed. Either check the automated threshlding in MRIcron, or use ITKsnap. Note that ITK-based software (Snap, ANTsR, Lesymap) use a different part of the header to orient the image from other ones (MRIcron, SPM, FSL). Sometimes this creates problems, so the best way is to visualize the results on a software that reads the data in the same way they were read during analysis.
About FWERperm, there is actually a difference between NPM and LESYMAP, but I that that difference was small. NPM actually computes and stores zscores, while LESYMAP stores the statistical BM t-score. The threshold computed in NPM is actually on the zscore distribution of permuted data, while for LESYMAP is currently on the BM t-score distribution.  This should not create major differences but you never know (zscores depend on the degrees of freedom, which differ at each voxel).
Without knowing the data cannot tell much, but if the range of t-test scores is really -3 to 3, the signal doesn't seem to be strong.
Happy to have a look if you want to share the data. Meanwhile you can try also method='sccan' to see if multivariate is giving you anything.

Sorry about the long delay, but I was out of town for a few days. I tried a few things with SCCAN and compared the output with the BM tests in LESYMAP and NPM.
The stats output of SCCAN at the p < 0.05 threshold ends up giving similar results to NPM+permutation FWER:
NPM BM, FWER (red), LESYMAP SCCAN (blue)

However, I do not see an p-values in the LESYMAP 'pval' file.
If I drop the SCCAN threshold to p = 1, I get a similar stat map with a somewhat larger area and some additional nearby clusters. The p-value map is still blank though.
To me, it looks like SCCAN and NPM+BM with permutation FWER agree better than LESYMAP's BM+FWER tests (where nothing passes the p < 0.05 threshold). I am wondering if this might be due to some of the extreme raw BM values driving the permutation threshold up in SCCAN. As you alluded to, this might be more of a problem in cases like mine with relatively few subjects per voxel.

Interesting, looks like you have a robust enough result. What SCCAN cross-validation you get? You can also use save.lesymap to save the result somewhere, and copy-paste the text file that is produced.
The pval image is always be empty with SCCAN, because there is no "voxel-wise" statistics to compute. There is no null hypothesis at the voxel level. The same is true for FWERperm, which is a global threshold of permutation. I don't know what NPM is producing, but there should not be any voxel level p-values for volume permutation thresholds. Maybe they put in there the values of voxel-wise stats. But I think that might mislead researchers, so the pval map is empty when the chosen analysis cannot produce a pval map.
The p-value that you set for SCCAN is very different from what you might be used to. It is applied to the cross-validated correlation to check whether the correlation is significant to the point that the result can be retained. When you change the threshold you don't get any "more" or "less" significant voxels, because SCCAN converges on its own to the appropriate sparseness (sparseness controls the extent of results). You can manually set a higher sparseness if you want to see more extensive results.
Before we proceed with other checks to see if Lesymap's FWER has a problem, did you remove MRICron's thresholds and clippings? Are you sure there are no values in the outcome maps where there should be?
Thank you for trying things out.
Dorian

The optimized sparseness for that analysis (with the p-threshold set to 0.05) was 0.051. The CV correlation was 0.425, p = 0.03.
In NPM, the FWER permutation analysis will give you thresholds for BM z-scores at the p<0.05, 0.01 etc, levels. My understanding to date was that these permutation tests were carried out at the voxel level, but I will have to check this. Do you have a citation?

Before we proceed with other checks to see if Lesymap's FWER has a problem, did you remove MRICron's thresholds and clippings? Are you sure there are no values in the outcome maps where there should be?

I am not sure what you are referring to by 'thresholds and clippings.'  The outcome map overlaps with areas where I have sufficient power in my lesion masks. I've checked all the masks previously, and they are all binary nifti files in the standard space.
Thanks a lot for your explanations!
Avi

I am not 100% sure all the details of how NPM works but I think it has
permutations at the volume level. You can read the Lesymap wiki which also
has the references to understand permutations.
https://github.com/dorianps/LESYMAP/wiki/Understanding-permutations
About visualizing in MRIcron, I remember some years ago that MRIcron does
some kind of self-thresholding, i.e., removing the values above the 99th
percentile. It used to be a problem for me because I thought all the
results were displayed and then I found that I had to manually set the
thresholds. This may be just my experience, or a wrong memory, but you
should have a look at the range of the data that MRIcron shows, whether
goes between min and max values. If, by any chance, the full range is not
displayed automatically, you may not see some of the voxels that actually
have values.
Out of curiosity, is the result you showed above related to a real
cognitive deficit? It is interesting to see such a focal result in that
area of the brain.
On Wed, Oct 25, 2017, 19:52 avrvaidya<EMAIL_ADDRESS>wrote:

The optimized sparseness for that analysis (with the p-threshold set to
0.05) was 0.051. The CV correlation was 0.425, p = 0.03.
In NPM, the FWER permutation analysis will give you thresholds for BM
z-scores at the p<0.05, 0.01 etc, levels. My understanding to date was that
these permutation tests were carried out at the voxel level, but I will
have to check this. Do you have a citation?
Before we proceed with other checks to see if Lesymap's FWER has a
problem, did you remove MRICron's thresholds and clippings? Are you sure
there are no values in the outcome maps where there should be?
I am not sure what you are referring to by 'thresholds and clippings.' The
outcome map overlaps with areas where I have sufficient power in my lesion
masks. I've checked all the masks previously, and they are all binary nifti
files in the standard space.
Thanks a lot for your explanations!
Avi
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dorianps/LESYMAP/issues/4#issuecomment-339508615, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIqafRMvgDvmBlJ0tRvi3IRLoecmqtBnks5sv8nUgaJpZM4QAMFO
.

Thanks for the link! I misunderstood your description of NPM in your earlier post. I thought that you were suggesting that NPM was carrying out permutations at the level of voxel clusters, rather than permuting behavioral scores (at least for voxels with N > 9).

This may be just my experience, or a wrong memory, but you
should have a look at the range of the data that MRIcron shows, whether
goes between min and max values. If, by any chance, the full range is not
displayed automatically, you may not see some of the voxels that actually
have values.

I have also had experience with this in MRIcron. However, I checked the full range of the BM FWER thresholded results, and they definitely do not match the results from NPM or SCCAN.

Out of curiosity, is the result you showed above related to a real
cognitive deficit? It is interesting to see such a focal result in that
area of the brain.

This result was from a study we did on attentional priming by rewarding stimuli in frontal lobe damaged subjects (https://www.ncbi.nlm.nih.gov/pubmed/26377468). We found that damage to that area (ventromedial frontal lobe) was associated with reduced reward priming. Our patient population included subjects with different kinds of damage (e.g. tumor resection, stroke, aneurysm), which may have reduced some of the covariance between lesioned voxels, and the association between damage and the vasculature.

Nice.
Another thing to try if you want to see if NPM and Lesymap resutls are consistent is repeat the data from your 27 subjects to go above 90. In R you can do something like behavior = c(behavior, behavior, behavior, behavior). Once you do that, you can use method='BMfast'. Actually that is enabled for permutation based multiple comparison, so you can select multipleComparison='FWERperm' or the good old multipleComparison='fdr'. Then you can compare with the results you get from NPM (just copy paste the lines in the .val file.
The above can help understand if there is anything different between NPM and LESYMAP when no voxel-wise permutation is needed.

I tried artificially quadrupling my subjects like you suggested (N = 108) in LESYMAP. When I ran BMfast tests with FWERperm corrections, I got a similar statistical map to LESYMAP's analysis using 27 subjects. The range of BM statistics is unsurprisingly higher (0-565.7), but the location LESYMAP identifies is still very different from BM tests in NPM and SCCAN:
Here is the BMfast FWER-permutation corrected map with 108 "subjects":

This area appears to correspond to the positive effects in my study (i.e. where damage was associated with higher reward priming). It shows up in the SCCAN analysis with a pthreshold set to 1, and is also non-significant in the NPM BM analysis.

Avi, not sure I understand. Which area is significant (or non significant) in NPM, and which one is mismatched in Lesymap?
You should ignore the value range as a comparison to NPM, because NPM only outputs zscores I think.

Also, if there is something really wrong with BM or BMfast, that should not happen with t-tests, so you can try that too. I remember getting fully matching maps between NPM and Lesymap zscores with 130 subjects. If you keep finding major differences, I can try to test your dataset.
Also, check the NPM version you have is the latest one.

For comparison, here are my results from BM tests using NPM (red, uncorrected), showing which voxels are associated with a lower score, and the SCCAN results at pthreshold = 1 (blue):

You can see that there is a good correspondence between both results indicated by the purple color where they overlap.
If you look at the voxels associated with higher scores in NPM, there is a small non-significant cluster of voxels in a dorsal area, below the permutation threshold:

BM tests with correction for multiple comparisons in LESYMAP do not yield any significant results. However, at an uncorrected threshold, the only significant results are this small set of dorsal voxels:

The same result comes up for BM tests with the artificially inflated N, like I showed in my last post (the extent is wider because more voxels are being included in the analysis):

The t-statistic map looks similar to my BM results in NPM and the SCCAN results. Here is the uncorrected t-map for lower scores:

And the uncorrected t-map for higher scores:

Ok, that shouldn't happen. Can you share the dataset so I can have a look? You can use wetransfer and send me an email at albnet at gmail dot com.
In principle, however, it's not a good idea to see uncorrected results. The overlap of uncorrected BM with SCCAN may not overlap at all once the results are properly corrected.

Hi Avi, thanks for sending the data.
Had a quick look and I partly understand is going on.
First, I had some troubles to get zmap.img from lesymap. This might be a bug in itself, but I don't think is causing any problem. You can still see the outcome in stats.img.
Looks like the orbitofrontal finding has a positive relationship with the lesion. Lesioned voxels have higher value.  I think this finding is also quite close to the significance threshold, and is coming up because lesymap is calculating a one-sided test.
When I run the same in NPM, I get a continuous unthresholded map. It has the negative scores in orbitofrontal and positive scores in superior frontal.
Total voxels = 7109137
Only testing voxels damaged in at least 3 individual[s]
Number of Lesion maps = 27
Permutations = 4000
Analysis began 28-October-2017 19:55:05
Voxels damaged in at least 3 individuals = 107372
Memory planks = 0.00539989024400711
Generating BM permutation thresholds
107372 test Std Bonferroni FWE Z 0.050=4.906, 0.025=5.040, 0.01=5.213
387 test (Number of Unique Lesion Patterns with at least 3 lesions) Bonferroni FWE Z 0.050=3.654, 0.025=3.828, 0.01=4.048
BM Range -3.390...3.011
BM +FDR Z 0.050=9.20000000, 0.01=9.20000000
BM -FDR Z 0.050=9.20000000, 0.01=9.20000000
BM+: permutationFWE , 0.050=3.40984416, 0.025=3.71901655, 0.01=3.89059186
BM-: permutationFWE , 0.050=-3.38957906, 0.025=-3.50887871, 0.01=-3.71901655
Analysis finished 28-October-2017 19:56:03
Processing Time (seconds) 58

If I threshold this map to keep significant negative or significant positive scores, there is nothing significant:
> tem = antsImageRead('npm_perm/rewpriming_resultsBMPred1.nii.gz')
> range(tem)
[1] -3.389579  3.011454
> sum(tem>3.409 & tem < -3.389)
[1] 0

In essence, there is no significant result in NPM from what I can see. At least not with a dual sided hypothesis (I don't know how to test one sided hypotheses in NPM). The above threshold is also very relaxed 0.05 negative and 0.05 positive, which is effectively 0.1.
The significant result you get in LESYMAP is probably because by default alternative = 'greater', meaning that 0-voxels are expected to have higher behavioral scores than 1-voxels. I gave it a try to switch to alternative='two.sided' but I may have done something wrong in the code and I got the values in between instead of getting the most extreme tails of the distribution. The way I coded two-sided thresholds might also need a review, because I currently use an "absolute" strategy, meaning that I simply turn the negative values to absolutes before computing the quantile of the permutations. Will need the opinion of a statistician if my choice is wrong.
So, strictly speaking the LESYMAP outcome is not wrong, because is expecting a specific relationship direction. It still needs some work with zmap calculation and two-sided hypotheses, but there is some good agreement between the two software. To reiterate what I mentioned above, NPM does not give any result with permutation FWER.
Now, let's think about SCCAN. You got a decent result, which had some good cross-validation accuracy. Obviously you have noted that your chance of getting any result somewhere is slim with any method, because most of the voxels have small lesion rate. This said, your SCCAN outcome was also borderline significant at p=0.03. It can hold if your hypothesis is one sided, but if your hypothesis is two-sided, you can try to run two different SCCAN analyses, one with the original order of behavioral scores, and the other with the inverted order (behavior = -behavior). In that case you should try each of them with p=0.025, and this will obviously kill your original finding. In short, this result would not be that different with the NPM result, and with what seem to be a set of results close to the borderline significance.
Hope all of this makes sense. I realize some of the lesymap behavior may be buggy, and I'am happy to put my hands into the code to fix those. But first let's try to understand your data, then we can see how to resolve lesymap's misbehavior.
Let me know if you have other questions.

To clarify something from above. The cluster I find in Lesymap has also the most negative values in NPM, so  that cluster according to both software is more "significant" than the anterior one, according to BM analyses. T-test may produce a different outcome because they run a different type of analysis...

And one more follow-up.
SCCAN at the sparseness you mentioned gets both clusters, the posterior orbitofrontal and anterior orbitofrontal. It gives more weight to the anterior one, maybe because it is surrounded by other good voxels, while the posterior one has less weight, maybe because it's on a single slice and does not hold well when smoothing is applied in SCCAN iterations. Cross-validation and p-value is worse that what you mentioned above.
Time: 2017-10-28 21:03:21
LesymapVersion: <IP_ADDRESS>05
method: sccan
correctByLesSize: none
multipleComparison: none
pThreshold: 0.05
flipSign: FALSE
minSubjectPerVoxel: 10%
nperm: 5000
saveDir: NA
binaryCheck: FALSE
noPatch: TRUE
showInfo: TRUE
sparseness: 0.051
alternative: two.sided
Subjects: 27
patchinfo: not computed
Runtime: 33 mins
Range statistic: 0 1
Suprathreshold voxels: 661
Number of Clusters: 2
Cluster sizes (voxels): 483 178
Cluster sizes (mm3): 483 178
optimalSparseness: 0.051
CVcorrelation.stat: 0.385720424753283
CVcorrelation.pval: 0.0469136637685666

The latest commit https://github.com/dorianps/LESYMAP/commit/c84b361a7ecf0f3e155730381b29adfc0831c119 has the fix to run BMfast with two-sided expectation. Please update the package to have it take effect.
You can run something like:
lesymap(..., multipleComparison="FWERperm", alternative="two.sided" or alternative="less" or alternative="greater").
With your data, you can get significant voxels at pThreshold=0.1 two-sided, or at pThreshold=0.05 one-sided.

Hi Dorian, thanks a lot for taking the time to look into this in detail.
Unfortunately, the new update crashes for me. When I try to load the latest version of LESYMAP, I get the following error:

Error in get0(".packageName", env, inherits = FALSE) :
lazy-load database '/Library/Frameworks/R.framework/Versions/3.3/Resources/library/ANTsR/R/ANTsR.rdb' is corrupt
In addition: Warning message:
In get0(".packageName", env, inherits = FALSE) :
internal error -3 in R_decompress1
Error: package or namespace load failed for ‘LESYMAP’

If I understand your response correctly, the issue was that LESYMAP BM tests were testing which voxels were associated with higher behavioral scores? This is why you had to invert the scores or change the alternative hypothesis before running the tests?
I also tried to re-run our NPM analysis in the latest version and got the same results as you. The results I mentioned earlier came from our original analysis using the June 6, 2013 version of NPM. I am not sure why the BM test results are so different (the problem mentioned by Medina et al. was supposed to be fixed in that version). The posterior OFC result does appear to be right at the p = 0.05 permutation threshold though (Z = -3.3895), which is a little reassuring. The more anterior result definitely does not survive though.

One small errata above.
I said NPM does not give any result when using 400 permutations, but that was my mistake. It actually gives 186 voxels:
> tem = antsImageRead('npm_perm/rewpriming_resultsBMPred1.nii.gz')
> sum(tem>3.409 | tem < -3.389)
[1] 186

And they are the same identical voxels that LESYMAP gives with BMfast, FWERperm, 4000-5000 permutations. The match of the finding is one-to-one. BMfast does not give zscore maps on purpose.

Are you saying you found different results between NPM 2013 and NPM 2016?
I am running a couple more tests to figure out what zscores is NPM computing.

Added some code in https://github.com/dorianps/LESYMAP/commit/08144f679e788d2b5c04a732839ee52ba79b99f7 to fix zmap issues. You can get zscores now, and they follow the same pattern as NPM, but the exact values are different. It's kind of difficult to understand NPM's approach. BM scores are supposed to be t-scores, but I remember a while back that NPM uses the normal distribution to compute zscores, instead of the t-distribution, which I thought would be appropriate. Moreover, BM tests have a problem of reaching infinite values when the two groups of voxels separate behavioral scores perfectly without overlap. A solution implemented in some software is the addition of a small value to avoid getting infinite computations.
Let me know if there is anything else that is off place. Thanks for trying lesymap.

About your installation error, looks like the ANTsR installation is corrupt. Try remove.packages('ANTsR') and install again. There is some more suggestions in stackexchange:
https://stackoverflow.com/questions/30424608/error-in-fetchkey-lazy-load-database

Nice to see that the posterior OFC result survives!

Are you saying you found different results between NPM 2013 and NPM 2016?

Yes. In NPM 2013, the anterior medial OFC and posterior OFC effects were both lower (Z values of 3.23 and 3.32, respectively). The permutation threshold for this version of NPM was also a good deal lower (Z>3.21 for p < 0.05 (keep in mind that this version of NPM automatically multiplies all behavioral scores by -1, so that lower scores = higher Z scores)).
Thanks for the tip. The new installation seems to be working fine. I can also see the z-score map. As you say, the results correlate well with NPM, but do not perfectly match their values.
Thanks again for all the help!

Avi,
I have pushed a new lesymap version which addresses two issues that came up here:

There is a new compiled permutation based Brunner-Munzel engine, which runs all statistics without the need for the external nparcomp package. You can simply use method='BMfast' and the voxels that require permutations will use the new code.
I noticed the old method='BM' uses a small number of permutations by default, i.e., 1000 instead of 20000. The user was supposed to set manually a higher number of permutations when using BM, but you may not have known it. I have added some checks and warning messages to inform the user when the number of permutations is too low. The new BMfast engine uses 20000 perms by default, so you will be able to find lower p-values when there is good signal. Note that these permutations do not affect at all the results obtained with multipleComparison='FWERperm', they only affect single voxel p-values when the number of subjects is kind of small.

Hi, sorry for the delayed response...
I tried running the BMfast tests with FWERperm after updating LESYMAP, but I am getting the following error:

15:05:50 Running LESYMAP <IP_ADDRESS>07
15:05:50 Checking a few things...
15:05:50 Computing mask from average >= 3 ...
Error in lesymap(files, scores, patchinfo = NA, method = "BMfast", correctByLesSize = "none",  :
Mask is empty. No voxels to run VLSM on..

This is a new one for me. It  doesn't seem specific to BMfast (I get the same errors for BM tests or SCCAN).
Avi

Closing the issue, please open new one if needed.


Add a New Python Category

Added Most popular Python Web and GUI frameworks and back to menu choice.

Closed , i will try to add more features then i will open new PR


"Device goes offline" when device is disconnected

Have a device connected and opened
Disconnect the device
Observe

Expected: "Device is disconnected" notification
Actual: "Device goes offline" notification

This behavior is coming from the adb server: when usb connection fails to read (even with NO_DEVICE), the device goes "offline" first. It isn't something we can really handle besides adding some throttling to the device updates, but there are pitfalls on this path too.

I'd rather not work on this.

Maybe the latest adb provides a better sequence there, actually.


[build] Update to latest revisions of upstream layers

In build-next as well:
To github.com:ros/meta-ros.git
422e21c17..6ea252c1f  build -> build-next


Cascading worldgen lag. [Server Log]

Forge: <IP_ADDRESS>55
Mods: Dynamic Trees: 0.7.6 (nothing more)
After launching clear forge server i see this message when i generate world or just fly around:
"Dynamic Trees loaded a new chunk [x, y] in dimension 0 (overworld) while populating chunk [x±1, y±1], causing cascading worldgen lag. Please report this to the mod's issue tracker"
More info: https://www.reddit.com/r/feedthebeast/comments/5x0twz/investigating_extreme_worldgen_lag/

Duplicate of Issue #50

I'm still working on a fix for this.  I thought I fixed it in the dev version(0.7.7) but it's still happening.  I understand the nature of the problem it's just taking a while to get all of the little generation things to behave.


Create a separate internal helper function for XLA compilation

XLA backends are written in C++, so method calls don't show up in Python
profiling results from cProfile. Adding an explicit function call fixes that.
This is helpful for interpreting profiling results, e.g., on the example from
https://github.com/google/jax/issues/3847.
Before:
         70814996 function calls (69915267 primitive calls) in 112.804 seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
     1193   24.936    0.021   30.336    0.025 xla.py:227(xla_primitive_callable)
  10524/1   16.342    0.002  112.991  112.991 xla.py:595(_xla_callable)
2014622/1843062    8.745    0.000   16.618    0.000 util.py:29(safe_map)
    18145    3.662    0.000    4.218    0.000 source_info_util.py:27(user_frame)
196061/183909    1.604    0.000   24.647    0.000 partial_eval.py:150(default_process_primitive)
   423499    1.569    0.000    1.569    0.000 {method 'reduce' of 'numpy.ufunc' objects}

After:
         71147652 function calls (70235594 primitive calls) in 101.718 seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
     1294   38.894    0.030   38.894    0.030 xla.py:325(_backend_compile)
2017790/1844559    6.965    0.000   14.139    0.000 util.py:29(safe_map)
    18146    3.317    0.000    3.839    0.000 source_info_util.py:27(user_frame)
196226/184073    1.467    0.000   21.889    0.000 partial_eval.py:150(default_process_primitive)
   423771    1.419    0.000    1.419    0.000 {method 'reduce' of 'numpy.ufunc' objects}

We now clearly see that both xla_primitive_callable and _xla_callable are
slow for the same reason and ~40 seconds is spent inside XLA compilation.

Note that this must be related constant-folding; it is not the time to compile the computation that is eventually produced, which is much shorter.
Perhaps try with the omnistaging branch?


Is this project containing full training data?

I would like to extend my sincere gratitude for your exceptional work. However., It appears that the current version does not include the complete set of training data. I am keenly interested in accessing the full dataset for my work.
Thanks

The data is not part of the GitHub project, please reach out to one of the authors.


How to access the SharedPreferences from Android which is created in Flutter

Hi,
I have created a SharedPreferences  in flutter and inserted some values. Now I want to access the SharedPreferences value in android. How can i do that? Also can we give custom name for SharedPreferences in flutter?
Thanks,
Sathya.

Hi @sathya4code
Flutter :
SharedPreferences prefs = await SharedPreferences.getInstance();
prefs.setInt('counter', 10);

Android :
private static final String SHARED_PREFERENCES_NAME = "FlutterSharedPreferences";
SharedPreferences preferences context.getSharedPreferences(SHARED_PREFERENCES_NAME, Context.MODE_PRIVATE);
int counter = preferences .getInt("counter", 0);

Hi @sathya4code
It seems you are asking for assistance on personal code. Please see https://flutter.dev/community for resources and asking questions like this,
you may also get some help if you post it on Stack Overflow and if you need help with your code, please see https://www.reddit.com/r/flutterhelp/
Closing, as this isn't an issue with Flutter itself. If you disagree, please write in the comments and I will reopen it.
Thank you

Hi @sathya4code
Flutter :
SharedPreferences prefs = await SharedPreferences.getInstance();
prefs.setInt('counter', 10);

Android :
private static final String SHARED_PREFERENCES_NAME = "FlutterSharedPreferences";
SharedPreferences preferences context.getSharedPreferences(SHARED_PREFERENCES_NAME, Context.MODE_PRIVATE);
int counter = preferences.getInt("counter", 0);

Hi @hamdikahloun
Thank you. I will check this.

Hi @sathya4code
It seems you are asking for assistance on personal code. Please see https://flutter.dev/community for resources and asking questions like this,
you may also get some help if you post it on Stack Overflow and if you need help with your code, please see https://www.reddit.com/r/flutterhelp/
Closing, as this isn't an issue with Flutter itself. If you disagree, please write in the comments and I will reopen it.
Thank you

Hi @TahaTesser
Thank you for your response. But i think this is a bug. I cannot give Sharedpreference name like Android.

Hi @sathya4code
Can you please provide your flutter doctor -v and flutter run --verbose logs, and a minimal complete reproducible code sample
Thank you


Repo starts but starting openrefine creates internal server error

Hi, and first of all thanks very much for the work and instructions. After having had a lot of issues recently with betatims version I found this repo. I have been successful in starting binder with it, but when I click on the tile to start open refinde I get an internal server error. This also happens when I try to access open refine directly via the link provided. Is there any chance this could be fixed?
Thanks in advance!

The binder part of this repo is rather old.. I will trynto have a look at it this week.

That would be fantastic, thanks!

I updated the java package and the openrefine package, but Binder just sits for me on the Pulling image step (minutes and minutes...). Please let me know if you can actually get an image to launch, and if so, whether it works.

Okay - seems to run okay now either from Binder open to openrefine link, or via launcher icon in Jupyterlab

Thank you very much! That is awesome!


story: "Select a stemcell for your BOSH deployment" out of date

bosh upload-stemcell https://bosh.io/d/stemcells/bosh-google-kvm-ubuntu-trusty-go_agent?v=VERSION
should be
bosh upload-stemcell https://bosh.io/d/stemcells/bosh-google-kvm-ubuntu-xenial-go_agent?v=VERSION
(trusty --> xenial)

This looks like a dupe of this github issue: https://github.com/pivotal-cf/onboarding/issues/179. I'll close this out.


about the miou and pa?

hi @Tramac , thanks for your job. i have reproduced the miou(54.3%) and pa(92.1%) at cropsize=768 . but i want to know whether you reproduce the paper's result(68.0%) or not.

Hi! Can you share me with the learning rate you use? I try to run the code, but the result is too bad. Could you tell me your learning rate and batch_size? Thank you very much!

呵呵，我（娄艳阳）已收到您的信，祝你事事顺心，快乐相随


tools: Don't upgrade stripe automatically during dependency upgrade

Merged, after expanding the commit message to explain why this is a problem.  (Though I suppose it's kinda covered in the error message)


修复无法对已爬取的帖子进行更新的问题

还是用的老办法，因为我不太清楚哪里出了问题😂

谢谢，我今晚或者明天看看，先看看能不能直接修

From: oarinv @.>
Sent: Tuesday, August 1, 2023 8:36:42 PM
To: ludoux/ngapost2md @.>
Cc: Subscribed @.***>
Subject: Re: [ludoux/ngapost2md] 修复无法对已爬取的帖子进行更新的问题 (PR #67)
还是用的老办法，因为我不太清楚哪里出了问题😂
—
Reply to this email directly, view it on GitHubhttps://github.com/ludoux/ngapost2md/pull/67#issuecomment-1660228543, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADGWKTBF2HEPYQ2U4KARET3XTDZ5VANCNFSM6AAAAAA27WDJJ4.
You are receiving this because you are subscribed to this thread.Message ID: @.***>


bam->fastq -- Error: output file unexpectedly small

Brad,
In the wild running into this on seemingly valid/non-truncated [1] input bam files -- in the first step converting to fastq. Poking around in the source it looks like in file_reasonable_size() (here) there's a check if the resulting fastq is less than 1/5 of the input bam.
I think this is reasonable, but fails in my case due to a particularly verbose/long read-group (on every line in the bam). My guess [2] is maybe gzip (in the fastq.gz) is taking much better advantage of this than the compression used in bam? (resulting in unexpectedly smaller file size).
[1] both samtools flagstat and samtools view file.bam | tail produce something reasonable for all files this happens on (see example below) -- please advise if this might miss a bad bam (and there's a better way to check)
> samtools flagstat file.bam
132741016 + 0 in total (QC-passed reads + QC-failed reads)
0 + 0 secondary
0 + 0 supplimentary
6894944 + 0 duplicates
132741016 + 0 mapped (100.00%:-nan%)
132741016 + 0 paired in sequencing
66487463 + 0 read1
66253553 + 0 read2
131592924 + 0 properly paired (99.14%:-nan%)
132494426 + 0 with itself and mate mapped
246590 + 0 singletons (0.19%:-nan%)
730130 + 0 with mate mapped to a different chr
575360 + 0 with mate mapped to a different chr (mapQ>=5)

[2] wild guess, for all I know bam compression is gzip underneath, making this a pretty bad guess
Very tangentially related: I noticed just one of the converted fastq files (xxx-1.fq.gz, but not xxx-2.fq.gz) was transactional. The other stuck around in the align_prep directory despite the failure. Digging around the source to find the conversion command (running manually for now to bypass this) I think I may have stumbled onto the reason here (fastq_two not getting it's own file_trscation?)

As a quick & dirty workaround I changed ratio = 5.0 to ratio = 7.0 infile_reasonable_size() function and this seems to do it. Though I suspect something more general might be in order :)

Roy;
Thanks for this. The check is really just a sanity check and 5.0 is picked arbitrarily so happy to adjust to be sure it fits for your case. If the BAMs have huge read groups these won't be present in the output fastq files so that makes sense they'll be smaller.
The transactional issue is not too big of a problem since it will always re-check on the first input, which only gets copied over on completion, so the second will be re-done in partially finished cases. So it won't continue with partially completed inputs, which is the goal of the transactions.
Thanks again for all this.

Great!
Right, I see what you mean regarding the transaction -- thanks for explaining that.


Texture Wrap does not work for non-power-of-two images on iOS

Simplest method to reproduce this error (for iOS):

Setup default project with project setup JAR
Resize the included "badlogic.jpg" from 256x256 to 256x257 or some non-power-of-2 dimensions.
Enable Texture Wrap on the image with the following line placed within the create method:
img.setWrap(TextureWrap.Repeat, TextureWrap.ClampToEdge);

Result will be a black void where the image is expected to be. If either the image is power-of-two or Texture Wrap is disabled, the image will appear correctly.

This is in line with the open gles spec, you need POT textures for that wrapping mode.
----- Reply message -----
From: "David Li"<EMAIL_ADDRESS>To: "libgdx/libgdx"<EMAIL_ADDRESS>Subject: [libgdx] Texture Wrap does not work for non-power-of-two images on iOS (#3178)
Date: Fri, May 29, 2015 10:31 AM
Simplest method to reproduce this error (for iOS):

Setup default project with project setup JAR
Resize the included "badlogic.jpg" from 256x256 to 256x257 or some non-power-of-2 dimensions.
Enable Texture Wrap on the image with the following line placed within the create method:
img.setWrap(TextureWrap.Repeat, TextureWrap.ClampToEdge);

Result will be a black void where the image is expected to be. If either the image is power-of-two or Texture Wrap is disabled, the image will appear correctly.

Reply to this email directly or view it on GitHub:
https://github.com/libgdx/libgdx/issues/3178

Understood. Was not aware of it. Thanks.


fix: resolve path to benchmark

@yegor256 I saw CI didn't pass on master, the correct path to the script was missing, added commit with fix

@vardbabayan Hey there! 👋 We appreciate your effort, but naming Git branches like "vb/fix-benchmark-path" isn't recommended. For better practice, use the ticket number you're working on (e.g., "136"). This aligns with our guidelines and helps streamline our workflow. Your current balance is -12 points. Let's work together to improve and make our collaboration even smoother!

@vardbabayan Thanks for your contribution! Your reward is +4 points: +4 base, -16 for no code review, -4 for only 1 comment, -8 for just 2 hits-of-code, +28 adjustment. Remember, our policy encourages more substantial contributions with proper reviews. Aim for 20+ hits-of-code and 6+ review comments to maximize your bonus. Keep improving! Your balance: -20.


Adds cordova (Don't merge)

[ ] iOS build needs to be tested before I'm happy to merge.
[x] We also need to figure out what we can safely gitignore.

@matt-auckland - I wonder if a lot of the files can be added to .gitignore ?

@matt-auckland currently getting the following when building in xcode:
Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x6040002915d0 _UIButtonBarStackView:0x7ff8ec5151b0.trailing == _UIToolbarContentView:0x7ff8ec5046c0.trailing   (active)>

Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.```

also get this when API call is executed:
2018-07-03 11:19:48.421383+1200 Kauri Wallet[47870:2178752] NSURLConnection finished with error - code -1100

@matt-auckland I think using NSExceptionDomains in the info.plist will resolve the API call issue


Add reasoning capabilities to ollama-instructor

Allow reasoning when „format“ = „“
In this case the system prompt will be (in any case) have a instruction for the LLM to respond the JSON in a code Block which starts with ‘‘‘ and ends with ‘‘‘.
What’s needed?
– Two kind of system prompts (old and new) + additional prompt when user comes with own system prompt but chooses format = „“
– new method to extract the JSON from the response (code block)

include in retry feature if code block is missing
– Maybe additional error guidance prompt with only requesting the false responses (if multi BaseModels were provided; only possible when having reasoning capabilities active [format=''])
– Provide the raw response within the response object (should already be the case)

Why?
– enhance the quality of the response by allowing the LLM to reason
– make a chat-like experience possible

Implemented with Release of version 0.4.0
See: https://github.com/lennartpollvogt/ollama-instructor/releases/tag/v0.4.0


Update feature

Update feature

This PR looks really good overall! I'll require a couple days before I have time to pull it down for testing. I'll advise of any issues at that time. Thanks,


changed MA AVRs profile name to a more user friendly name

Trying to change the Device Name as this is not user friendly, as can be seen below:

Well, the device is not in the market yet. So it won't affect any end-user.

@greens
I don't know what it has to do with. But the only place in our code where the term "maX10" appears in is where I changed it. The function you pointed returns the user friendly name set by the user on the JBL app or web interface. By default it will be in the format seen under the column "DEVICE LABEL" (-<6-chars-of-mac>; e.g. "JBL MA9100HP-95...."). Hence, I believe "DEVICE NAME" is basing its value through the profile name. I don't know if it's done in the app code during/after the WWST certification process, but this is the only place this string is used.

@alon-tchelet Ah. I see. Yes, that column comes from the profile name. But that "name" is not visible to the user in many places. Mainly in the spot you've pointed out here.
The issue, as Zach pointed out, is that we cannot delete profiles once they've been created. Renaming it as you've done here will count as removing an existing profile and creating a new one, which will cause the deploy of the driver to fail.

Hello @alon-tchelet The "Device Name" field that is appearing, in the screen shot you provided, is not the same name that the device will show as its default name when the device onboards to SmartThings.
I am going to encourage someone from SmartThings to reach out regarding this PR, as there might be an alternative solution to resolving the issue you are concerned with.

Closing this PR for now as Harman Luxury have decided not to make this change for now as it would require to apply the series to certification again


Add the file and line number that an error occured on to the status_message when product test building fails

This fixes an annoyance when trying to debug errors with product tests, and includes the first line of the backtrace for viewing in the app status message.
It may be worthwhile to consider providing only admins access to the full backtrace in the UI if we feel this is too much information. The problem is on the error message we say "please contact the cypress team with the following error message if the problem persists", and undefined method [] for nil:NilClass isn't a horribly helpful error for us to help debug.
Submitter:

[x] This pull request describes why these changes were made.
[x] Internal ticket for this PR: https://jira.mitre.org/browse/CYPRESS-287
[x] Internal ticket links to this PR
[x] Code diff has been done and been reviewed (N/A)
[x] Tests are included and test edge cases (N/A)
[x] Tests have been run locally and pass (N/A)

Reviewer 1:
Name:

[ ] Code is maintainable and reusable, reuses existing code and infrastructure where appropriate, and accomplishes the task’s purpose
[ ] The tests appropriately test the new code, including edge cases
[ ] You have tried to break the code

Reviewer 2:
Name:

[ ] Code is maintainable and reusable, reuses existing code and infrastructure where appropriate, and accomplishes the task’s purpose
[ ] The tests appropriately test the new code, including edge cases
[ ] You have tried to break the code

Looks like this:


exporting a file to local disk (from another jobStore) reads the entire file into RAM

https://github.com/BD2KGenomics/toil/blob/890480506f977ba5faadab4b1cdb90696a7dd2da/src/toil/jobStores/fileJobStore.py#L223
This means that you run out of memory (raising MemoryError) when exporting large files.

I think it might actually be two methods.  I made a PR: #2047.


Portable Managed BigQuery destinations

Add portable dynamic destinations* to the BigQuery write schematransforms. This can be used in both cross-language and Managed BigQuery writes.

More details about what this means here: #32365

Depends on #31486 getting in

R: @chamikaramj this is ready for a review!

Failing test is unrelated -- merging now


PlutoColumnType.date too hard for using

I have column that using PlutoColumnType.date but when showing choosing date. It very hard to know which month or year for changing. Could you using date column like showDatePicker of flutter.
Another hope you can update an choosing datetime column because my data have some column that contain both date and time value

The datetime type should be added. It would be nice if someone added it. Or I have to do it myself, but I don't have much time.

yes, hope that you will be update it soon. Long time to see you back


fix: add missing code coverage.

:tada: This PR is included in version 1.2.1 :tada:
The release is available on<EMAIL_ADDRESS>Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.3.1 :tada:
The release is available on<EMAIL_ADDRESS>Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.3.1 :tada:
The release is available on<EMAIL_ADDRESS>Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.3.1 :tada:
The release is available on<EMAIL_ADDRESS>Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.1 :tada:
The release is available on<EMAIL_ADDRESS>Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.2.1 :tada:
The release is available on<EMAIL_ADDRESS>Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.2.1 :tada:
The release is available on<EMAIL_ADDRESS>Your semantic-release bot :package::rocket:


Remove deprecated AsciiDoc (.adoc) files.

This change is

Reviewed 16 of 16 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

Comments from Reviewable

Reviewed 16 of 16 files at r1.
Review status: :shipit: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

Comments from Reviewable


coordinates may need restructuring

I would like to store the camera coordinates inside CameraGeometry as a SkyCoord (not really sky, but that's the base class for astropy coordinates, even if confusingly named), but as of right now, this is difficult because when talking about a CameraGeometry, we do not necessarily have the focal length of the telescope in which the camera is installed.
Therefore, I would like to have CameraFrame be a base frame that does not need any parameters (it's just pixel pos in meters, relative to the center of the camera).  Then to transform to an angular system where the pixels are positions on the sky (e.g. the TelescopeSystem), I would then add information about the focal length only.  This system should be the same as CameraSystem, but angular coordinates, still centered on the center of the telescope's FOV.
Finally, I would later go to a AltAz or nominal by adding information on the pointing position of the telescope, etc.
@ParsonsRD is there a reason why it is not done this way? Right now I need to have the focal length to specify a CameraSystem coordinate, but I don't have that info, and it shouldn't be needed.

I guess, to me it makes sense like this:
 CameraFrame ---[telescope optics]---> TelescopeFrame ---[pointing]---> NominalFrame

This would then allow us to store the frame type in the CameraGeometry class (without loading a telescope optics description), and support the various frames described in #255

Hi, sorry was on vacation for the last week. I think thats fine and shouldn't cause any serious problems.

I recently implented a working set of Coordinate Transformation for FACT here:
https://github.com/fact-project/pyfact/blob/master/fact/coordinates/camera_frame.py
I learned quite a lot about how astropy frames are supposed to work and what members they need to have to make transformation work painlessly.
I started working on implementing these in ctapipe, but right now I cannot give a timeframe when I will open a PR for this.
In the mean time, i'd like to know if there are definitions of the camera coordinate system and telescope coordinate system somewhere.
This would be very helpful for writing tests and the actual implementation.

I think @tino-michael is debugging that right now for his reconstruction, and found for example the extra 90 deg rotation that we are missing to go from the sim_telarray coord sys to the sky, etc.  He's not using astropy coordinates yet, but once he has them finalized, they should be translated into them.

see #580

@MaxNoe By definitions of the camera coordinate system and telescope coordinate system, you mean the frame of references for camera and telescope in which you have to provide FACT camera and telescope coordinates information to do the analysis using ctapipe, right?
@kosack is that the final ctapipe coordinate will be sim_telarray coordinate? or the sky one?

@MaxNoe By definitions of the camera coordinate system and telescope coordinate system, you mean the frame of references for camera and telescope in which you have to provide FACT camera and telescope coordinates information to do the analysis using ctapipe, right?

No I mean stuff like: CameraCoordinates are defined as x pointing right and y pointing up, when one looks onto the camera plane from the mirror.
Or anything similiar. The definitions of what x and y should mean.

I see. I don't know if any such CTA document exits. Others might have some more information on that. I see quite some discussion on coordinate systems in  #255.

The standards for coordinate systems don't exist (and indeed each camera is doing things differently), so right now we only support the sim_telarray coordinate system, which is admittedly strange, and I couldn't even really find a reference for it (coordinate definitions are not mentioned in the sim_telarray manual - https://www.mpi-hd.mpg.de/hfm/~bernlohr/sim_telarray/Documentation/sim_hessarray.pdf).  Eventually, we can standardize this better, and in fact the project office has been informed that this is a problem.

see also #580

Hi, agreed @kosack no standards or requirements exist for this. The systems as they are, are a mish -mash between the HESS system, plus some other stuff I thought we might need. I agree this code definitely needs seriously refactoring but should we not try to fix the requirements (or at least get started on them) before we launch into a lot of work about this?
@AMWMitchell, from the PO side of thinks what do you think we need to do about fixing the requirements? Do you know if there is any existing group working on the coordinates standards?
Also, tagging @GernotMaier, what do you think?

Yes, the PO is aware of the need for common pointing / co-ordinate definitions asap, and Gino Tosti  agreed to start a document on this, but as yet I haven't seen any drafts and was considering starting one myself (with the FACT doc started by @MaxNoe as input/reference as well as sorting out the mix of HESS / sim_telarray). Gino has ALMA/ASTRI experience, so between us (incl. those with VERITAS experience) we should have most variants covered.
Not sure which requirements you're thinking about - the only one relevant here would be to follow the applicable standards for co-ordinate definitions (TBD).

Hi @AMWMitchell yeah requirements was a nomenclature fail on my part, agreed the only requirement should be follow the standards :-).
I just think it's probably worthwhile discussing the use cases for the coordinate frames to define what we actually need before launching into anything.

I just think it's probably worthwhile discussing the use cases for the coordinate frames to define what we actually need before launching into anything.

Do you want to start a google doc or something to "brain-storm"?

This is basically implemented with attaching frame to CameraGeometry and adding transform_to


Consider adding data-processing, data-wrangling to your github tags.

Is your feature request related to a problem? Please describe.
I couldn't find your repo. Pain ensued.
Describe the solution you'd like
Found your repo.  Joy ensued.
Describe alternatives you've considered
Hacking all things sed, ack, jq, csvkit, yaml2csv etc.
Additional context
Keep up the good work!

Thanks for the suggestion. I've added those now! 👍


Feat/1104 store selected codelist value in datamodel

Description
Adds the ability to save chosen labels in option inputs as a list of strings in the datamodel.
This PR is a work-in-progress, we might have found a bug in the PATCH logic.

Related Issue(s)

closes #1104

Verification/QA

Manual functionality testing

[ ] I have tested these changes manually
[ ] Creator of the original issue (or service owner) has been contacted for manual testing (or will be contacted when released in alpha)
[ ] No testing done/necessary

Automated tests

[ ] Unit test(s) have been added/updated
[ ] Cypress E2E test(s) have been added/updated
[ ] No automatic tests are needed here (no functional changes/additions)
[ ] I want someone to help me make some tests

UU/WCAG (follow these guidelines until we have our own)

[ ] I have tested with a screen reader/keyboard navigation/automated wcag validator
[ ] No testing done/necessary (no DOM/visual changes)
[ ] I want someone to help me perform accessibility testing

User documentation @ altinn-studio-docs

[ ] Has been added/updated

[ ] No functionality has been changed/added, so no documentation is needed
[ ] I will do that later/have created an issue

Support in Altinn Studio

[ ] Issue(s) created for support in Studio

[ ] This change/feature does not require any changes to Altinn Studio

Sprint board

[ ] The original issue (or this PR itself) has been added to the Team Apps project and to the current sprint board
[ ] I don't have permissions to do that, please help me out

Labels

[ ] I have added a kind/* label to this PR for proper release notes grouping
[ ] I don't have permissions to add labels, please help me out

One more thing! According to the Percy snapshots, there are quite a few errors in the DevTools log now. We should take a look at those (unless you already know what they're about) and see if we can avoid printing them out (or fix the frontend-test app if there's anything wrong in it).

Tested now, and this is working wonderfully! :raised_hands: I'm still missing layout validation for the bindings, but I created an issue for that here:

https://github.com/Altinn/app-frontend-react/issues/1894


Stopflow plan with 0 pre & post stop frames captures infinite frames

Potential fix
    # Wait for pre-delay then open shutter
    SeqTableRow(
        time1=in_micros(pre_delay),
        time2=in_micros(shutter_time),
        outa2=True,
    ),
    # Keeping shutter open, do n triggers
    SeqTableRow(
        repeats=pre_stop_frames,
        time1=in_micros(exposure),
        outa1=True,
        outb1=True,
        time2=in_micros(deadtime),
        outa2=True,
    ) if pre_stop_frames else TableRow(
        repeats=1,
        time1=0,
        time2=0,
    ),
    # Do m triggers after BITA=1
    SeqTableRow(
        trigger=SeqTrigger.BITA_1,
        repeats=post_stop_frames,
        time1=in_micros(exposure),
        outa1=True,
        outb1=True,
        time2=in_micros(deadtime),
        outa2=True,
    ) if post_stop_frames else TableRow(
        repeats=1,
        time1=0,
        time2=0,
    ),
    # Add the shutter close
    SeqTableRow(time2=in_micros(shutter_time)),

This should have been fixed in #53, need to check on the beamline


Writing Image based kernels from Buffer based kernels

Architecture: arm64-v8a
Operating system: Android 9 Pie
Hello,
If we have a buffer based kernel [like current kernels] & I want to write an image based kernel [which use cl::Image instead of cl::Buffer] based on the same, how would I go about doing that? What are the differences in memory layout & what potential problems I might face? Any pointers are appreciated.
Thanks in Advance.

Hi @ssj4gogeta ,
** If you want to copy the buffer to the image,**
You can use clCreateImage, but there are some memory alignment restrictions.

A first restriction is the following:

A 2D image can be created from a buffer by specifying a buffer object in the image_desc->mem_object passed to clCreateImage for image_desc->image_type = CL_MEM_OBJECT_IMAGE2D. If image_desc->mem_object is created with CL_MEM_USE_HOST_PTR, the host_ptr specified to clCreateBuffer must be aligned to the minimum of the CL_DEVICE_IMAGE_BASE_ADDRESS_ALIGNMENT value for all devices in the context associated with image_desc->mem_object and that support images."

While a second restriction is about the size of the image (still refer to the link above).

If you want to use a cl:Image from scratch
It might be simpler in terms of restrictions, but quite cumbersome in terms of code rewriting:

cl::Buffer is used directly in the interface ICLKernel.h. This means you would need to write a new interface to support cl::Image.
All the arg setters for the kernels only support buffers. You would need to write new ones to support images.
All the window slicing logic should support images and not buffers.

All in all, it is not a straightforward change.
I hope this helps,
Giuseppe

Hello @giuseros,
Got it, thanks.


fix: Support pydantic v1.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-4.0%) to 95.96%

Totals

Change from base Build<PHONE_NUMBER>:
-4.0%

Covered Lines:
265

Relevant Lines:
277

💛  - Coveralls


Question: best way to find an open port?

Hi there -- thank you for your great TCP library! I was wondering if you have advice on how to find an open port for listening on the device?
I may be a bit paranoid, but I'm worried that I'm going to ship my app and then my port choice will collide with another app on a user's device. My entire app will cease to function if the local tcp doesn't start up. Is this something that I should be worried about? Is there a recommended approach to finding an open port on the device?
Thank you in advance.

@happymaskterriblefate, you should always use ports above 1024. However, before using those ports above 1024 it is highly recommended to inform yourself about that port, I simple Google search should be enough.


Remove "--export-options-plist" check.

We can use "--export-method" now.

I think it should check whether the export-options-plist or --export-method build args is included

@cenumi Please upgrade to v0.2.7

--export-method can be omitted.
app-store is the default behavior.
    --export-method                                     Specify how the IPA will be distributed.

          [ad-hoc]                                      Test on designated devices that do not need to be registered with
                                                        the Apple developer account. Requires a distribution certificate.
          [app-store] (default)                         Upload to the App Store.
          [development]                                 Test only on development devices registered with the Apple
                                                        developer account.
          [enterprise]                                  Distribute an app registered with the Apple Developer Enterprise
                                                        Program.