typeof discards previous non-null checks

TypeScript Version:  3.2.0-dev.20181025

Search Terms:
unknown typeof object null
Code
Run the following code via tsc --noEmit --strict test.ts
declare const x: unknown;
x !== null && typeof x === 'object' && 'field' in x;

Expected behavior:
It should pass the type check as the first condition ensures x is not null and the second one narrows the type to object | null. Together with the previous non-null check it should result in the object type.
Actual behavior:
test.ts:2:42 - error TS2531: Object is possibly 'null'.

2 x && typeof x === 'object' && 'field' in x;
                                           ~

A workaround is to switch the order of typeof and the x truthiness check:
declare const x: unknown;
typeof x === 'object' && x !== null && 'field' in x;

Playground Link:  Note: you need to enable strictNullChecks manually!
https://www.typescriptlang.org/play/#src=declare const x%3A unknown%3B
x !%3D%3D null %26%26 typeof x %3D%3D%3D 'object' %26%26 'field' in x%3B

Related Issues:  #27180

I made a mistake in the related issue number, it should have been #27180. Edited.

This is a design limitation in the control flow analyzer. Control flow analysis fundamentally is concerned with narrowing union types, so when the current control flow type of x is unknown, the expression x !== null doesn't narrow x because unknown is a non-union type and undivisible, so to speak. However, the check typeof x === 'object' changes the control flow type of x to object | null and following that it is possible to narrow away the null. So, it works if when you write it in the opposite order. Would be nice to do better, but it is not a trivial task.

If this is a "design limitation" this needs some serious documentation. This is completely unexpected. See my tiny examples in #32301 — how would anyone guess what's going on there?

@lll000111 how much slower are you willing to make builds in order to allow that to happen?

@RyanCavanaugh I refer to my comment. What a strange question. Also, I don't see how this connection you make is a natural law. If it was this whole issue would not be so surprising because we would be used to it. Facebook's Flow does not have this problem. If you want to explain to me something about the internals of TS &,dash; well, see my previous comment. I mean, IMO this is quite a stunning revelation, this particular issue, and I've been reading the issues for a long time (both Flow and here) and accept a lot of the limitations of both tools because I do understand the enormous complexity and hate the hype of the fanboys "why doesn't ecmascript adopt types", people who are not aware of the huge amount of issues, many of them unsolvable, when you write a tool that tries to make hard statements about people's code.

If this is a "design limitation" this needs some serious documentation. This is completely unexpected. See my tiny examples in #32301 — how would anyone guess what's going on there?
I think that it should not be the implementation that is the focus, but the result and the impact. What is easier: Get all TS developers to know that in TS the order of OR-connected expressions in an if() used for refinement matters, sometimes, or to change the implementation? Does the sky turn around us in the center, or is it the earth that's turning?

Will https://github.com/microsoft/TypeScript/pull/29317 address this?

Not sure if related but in case:
I wanted to write a function that ensures a value has an expected type at runtime and also infers the type at compile time but typeof emits a type that doesn't make sense:
type ValueType = string | string[] | number | boolean

function checkType<T extends ValueType>(value: unknown, fallbackValue: T): T {
  if (value === undefined) return fallbackValue;
  const type = typeof value;
  const validType = typeof fallbackValue;
  if (type === validType) return value;
  throw new Error(`Unexpected param value type: ${type}. Should be ${validType}.`);
}
// usage:
checkType<string>(value, '')

Emitted type for validType is "string" | "number" | "bigint" | "boolean" | "symbol" | "undefined" | "object" | "function" even though it should be "string" since fallbackValue (and therefore T) is of type string.
Consequently, value doesn't have the correct type and the function does not compile.
I have to cast the return value as follows return value as T for it to compile.
But this effectively makes the whole type checking useless since I could have whatever and it would work.
Am I missing something?


adding new peripheral class as a container for simulator and activating simulated buzzer code

This revisits and finishes up the ability to receive a tone alarm over mavlink from the px4 simulator. There is a corresponding  px4 pr that implements sending the message here:
https://github.com/PX4/Firmware/pull/11431
In addition this pr also adds a new peripheral class which can be modified to add leds, gimbals, other buzzers and any other simulated peripheral that would be a benefit.
Original concept/prototype demonstration is here (this pr adds same functionality):
https://www.youtube.com/watch?v=t7cvCfbbXbE

@catch-twenty-two , would you resolve the conflicts in this PR so that I can test it?  Thanks!

@catch-twenty-two , I've applied your changes in this PR to the current jMAVSim master branch and I get exceptions thrown from the modified code:
Exception in Simulator.world.update() :
java.lang.NullPointerException
	at me.drton.jmavsim.MAVLinkHILSystem.handleMessage(MAVLinkHILSystem.java:145)
	at me.drton.jmavsim.MAVLinkConnection.sendMessage(MAVLinkConnection.java:36)
	at me.drton.jmavsim.MAVLinkNode.sendMessage(MAVLinkNode.java:29)
	at me.drton.jmavsim.UDPMavLinkPort.update(UDPMavLinkPort.java:147)
	at me.drton.jmavsim.MAVLinkConnection.update(MAVLinkConnection.java:44)
	at me.drton.jmavsim.World.update(World.java:33)
	at me.drton.jmavsim.Simulator.run(Simulator.java:510)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

Line 145 where the exception occurs is where filterMessage() is being called: vehicle.getPeripherials().getBuzzer().filterMessage(msg);
Could you deconflict/rebase this PR so that I try to validate your work?  Thanks!
-Mark

@catch-twenty-two , should we try to resolve the conflicts in this PR or close it out?


Specify pg & pgm num to distribute data across OSDs for replica-1 pools

We support adding additional OSDs for each replica-1 pool. But as the pg & pgm num always stays at 1, the data always gets stored in the same OSD. Ideally we would want the data to be distributed across all the OSDs for a particular cephblockpool for a failure domain.

/lgtm

/retest

/retest

/test ocs-operator-bundle-e2e-aws

/cherry-pick release-4.16

/cherry-pick release-4.15


Looking for new maintainer

To anyone interested,
It has been a while since I updated this project and I currently don't have the bandwidth / time that this project requires.
I have seen that there are plenty of contributions and contributors so please let me know here if you are interested on becoming the maintainer of this project.

Hi there, thanks for your efforts with this tool! Our group might be interested, would you be able to shed a bit more light on what sort of things have taken significant time in the past?

Hi,
Looking around the code, the PR and the issues, I think I can handle it. And I'd be interested to do so :)
But obviously, if somebody else does it, that's totally fine for me too.


Redundant type-checking in the generated JS

Consider the following Elm function:
linear : (Float, Float) -> (Float, Float) -> (Float -> Float)
linear (inputMin, inputMax) (outputMin, outputMax) input =
  outputMin + (input - inputMin) / inputMax * outputMax

and the associated compiled JavaScript:
var linear = F3(function (_v0,
_v1,
input) {
   return function () {
      switch (_v1.ctor)
      {case "_Tuple2":
         return function () {
              switch (_v0.ctor)
              {case "_Tuple2":
                 return _v1._0 + (input - _v0._0) / _v0._1 * _v1._1;}
              _U.badCase($moduleName,
              "on line 12, column 3 to 56");
           }();}
      _U.badCase($moduleName,
      "on line 12, column 3 to 56");
   }();
});

In the generated JS you can see two checks of the constructor name performed and two closures introduced to achieve that. It's quite an overhead I must say! So why waste resources on those checks when compiler's type-checker makes them redundant?

The same argument can be made for user-defined types with exactly one constructor (but possibly several fields in that constructor):
type D a b = C a Int b

Any case-of on a value of some type of the form D T1 T2 could skip checking the constructor to be C.

This has already been fixed in elm-compiler master. Evan implemented a
decision tree analyser, which ignores checks which are unnecessary and
generates minimal code to check the rest.
It will be available in Elm 0.16.
On Monday, September 21, 2015, Janis Voigtländer<EMAIL_ADDRESS>wrote:

The same argument can be made for user-defined types with exactly one
constructor (but possibly several fields in that constructor):
type D a b = C a Int b
Any case-of on a value of some type of the form D T1 T2 could skip
checking the constructor to be C.
—
Reply to this email directly or view it on GitHub
https://github.com/elm-lang/elm-compiler/issues/1065#issuecomment-141881474
.

Yeah, whether it is user defined stuff or tuples or whatever, it is all left out in 0.16 if it is not necessary.


Log/view openai API Request/Response

Hi There,
Is there a way to log openai api request and response?
I am using llamaindex by creating index based on pdf files. I wan to see what is being sent to openai api.
Thank You.

@gladiatorksk  You can try setting the logs to debug to print to terminal

import logging
import sys

logging.basicConfig(stream=sys.stdout, level=logging.DEBUG)
logging.getLogger().addHandler(logging.StreamHandler(stream=sys.stdout))

Or you can use the llama logger (see the bottom of this notebook)
https://github.com/jerryjliu/llama_index/blob/main/examples/vector_indices/SimpleIndexDemo.ipynb

Awesome!  Thanks!
The following did the trick, the debug logger does not provide the api request/response.
service_context.llama_logger.get_logs()

Yes, Just print(service_context.llama_logger.get_logs())...


Space Simulator Alpha 0.1.3

There is no earth in this project
http://scratch.mit.edu/projects/93750790/
http://phosphorus.github.io/#93750790
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36

It's because Google code has shut down  so the canvg JS links no longer work (and costumes don't work as a result). Tjvr has the updated links [here] (https://github.com/nathan/phosphorus/pull/635) , but the pull request hasn't been merged yet


TS-4672: Add lifecycle events to hook-trace example plugin.

FreeBSD build successful! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/445/ for details.

Linux build successful! See https://ci.trafficserver.apache.org/job/Github-Linux/339/ for details.

I wonder if we should move this out of the examples tree? It seems useful as a debugging tool, and most people probably don't look in examples for useful tools :).

Yeh lets have a new JIRA for that.


[SPIRV] Mising declaration of Geometry capability when emiting PrimitiveId builtin for fragment shaders.

Fixed in #3705.


Add g:oscyank_silent to disable copy confirmation.

Good idea. I've changed the option so that it takes a boolean (or 0/1` for older versions of Vim) instead of a string. Thank you for the PR :)

I'm not the expert so I appreciate the changes. 🍻


How to remove only one desktop environment

Hi, i have crouton with unity and after some day i have installed lxde with the -u parameter. I want to preserve unity and remove lxde. Do you have any solution ?
Thx.

See #717.  Currently all you can do is remove it from /etc/crouton/targets and uninstall packages manually.


[Bug]: SQLITE_UNKNOWN: SQLite error: no such table: main.user

Package
lucia-auth
Describe the bug
I am using the following tech stack: Elysia, Lucia, Drizzle and Turso.
This is what my auth module looks like:
import { libSqlClient } from "@/db";
import { TableName } from "@/db/table-names";
import { envVars } from "@/environment-variables";
import { libsql } from "@lucia-auth/adapter-sqlite";
import { github } from "@lucia-auth/oauth/providers";
import { lucia } from "lucia";
import { elysia } from "lucia/middleware";

export const auth = lucia({
  env: envVars.ENVIRONMENT,
  adapter: libsql(libSqlClient, {
    key: TableName.userKeys,
    session: TableName.userSessions,
    user: TableName.users,
  }),
  middleware: elysia(),
  getUserAttributes(databaseUser): { username: string } {
    return {
      // @ts-expect-error Fix this: Typescript is not aware of the username
      username: databaseUser.username,
    };
  }
});

export const githubAuth = github(auth, {
  clientId: envVars.GITHUB_CLIENT_ID,
  clientSecret: envVars.GITHUB_CLIENT_SECRET,
});

export type Auth = typeof auth;

For some reason I am getting the following error when trying to create a user: SQLITE_UNKNOWN: SQLite error: no such table: main.user
My table names do not contain this table name and never did.
These are my table names:
export const TableName = {
  users: "users",
  userKeys: "user_keys",
  userSessions: "user_sessions",
  ...
}

I don't understand what the issue is. Would appreciate some help.
This is the user creation code:
  const user = await auth.createUser({
          key: {
            password: body.password,
            providerId: "email",
            providerUserId: body.username,
          },
          attributes: {
            username: body.username,
          },
        });

your tablename contains those user on the line in 1st code-block:
    user: TableName.users,

see the key:value pair. the key is user which is probably the table name.
if it helps, check out my old project that shows how you should use tableNames if you want to keep them in 1 place (source of truth) only.

your tablename contains those user on the line in 1st code-block:
    user: TableName.users,

see the key:value pair. the key is user which is probably the table name.
if it helps, check out my old project that shows how you should use tableNames if you want to keep them in 1 place (source of truth) only.

Hey, my ‘TableName.users’ is ‘“users”’ and not what the error suggests

@asafs94 read what i said again. user is what you pass. check the codeblock. or better yet, see my code.

or better yet do it like my tableNames :)

Either I don’t understand what you meant or you don’t understand me…
Either way, I moved to v3 and it’s much better and works so closing…

you are not understanding me. i understood that you think the bug is users but re-read the bug again carefully. it says .user doesn't exist which literally means your key:value pair bcz that is the only place you mention user (singular). every other place its plural users.
glad that you got v3 working. still waiting for a stable release for now.

Sorry for commenting on this closed issue.
In case others had the same issue, I just went through it too.
Check your relation to users table on sessions table, might there is a typo.

Sorry for commenting on this closed issue. In case others had the same issue, I just went through it too. Check your relation to users table on sessions table, might there is a typo.

Absolute legend mate. This was what I was missing. Thanks for commenting on an otherwise unresolved issue.


Adds known issues for Linux.

@nenonix @JohanFreelancer9 Copy editing is needed for this PR. Thanks.


Voting for new owners for 2025/1/1 ~ 2025/12/31

To follow the rules from GOVERNANCE.md:
@woodpecker-ci/advisors @woodpecker-ci/maintainers
Only maintainers and advisors are eligible to vote or be elected. If anyone does not wish to be considered for election, please comment on this issue. Each maintainer may cast two votes or fewer for other maintainers, along with a comment identifying those individuals. Votes cannot be cast for oneself. Voting is open from now until December 31, 2024, or until all eligible voters have submitted their votes.

see #1467, #2903 for inspirations

@6543 @anbraten

@xoxys @qwerty287

@qwerty287 @anbraten


Fix doc-comments: Eff -> Effect

What does this pull request do?
Updates doc-comments (leftovers) for a couple of functions.

Thanks!


Version 2.2.1

Codecov Report
Patch and project coverage have no change.

Comparison is base (ad825a8) 89.77% compared to head (785e3fd) 89.77%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #688   +/-   ##
=======================================
  Coverage   89.77%   89.77%
=======================================
  Files          78       78
  Lines       13495    13495
=======================================
  Hits        12115    12115
  Misses       1380     1380

Flag
Coverage Δ

unittests
89.77% <ø> (ø)

unittests-rust
89.77% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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


error in training

give me the following:
Processing image 24990 of 24999 (train/5250.png)
Processing image 24991 of 24999 (train/69661.png)
Processing image 24992 of 24999 (train/86409.png)
Processing image 24993 of 24999 (train/49488.png)
Processing image 24994 of 24999 (train/10603.png)
Processing image 24995 of 24999 (train/47914.png)
Processing image 24996 of 24999 (train/93227.png)
Processing image 24997 of 24999 (train/118034.png)
Processing image 24998 of 24999 (train/155332.png)
Processing image 24999 of 24999 (train/79525.png)
Preprocessing permutation matrices P for nearly-free 8x more learning examples ...
Computing h ...
|/home/hat/.local/lib/python3.5/site-packages/numpy/linalg/linalg.py:1874: RuntimeWarning: overflow encountered in det
  r = _umath_linalg.det(a, signature=signature)
Finished.

Sorry for the late reply, Can you send me the image that generates the error, if possible. Thanks!

I don't think I have access to it now but the picture was very small, maybe less than 150x150.

I met the same warning when there were to many images( over 400). Its influence to the filter and results are unknown. I just ignored it.


[SPARK-27276][PYTHON][SQL] Increase minimum version of pyarrow to 0.12.1 and remove prior workarounds

What changes were proposed in this pull request?
This increases the minimum support version of pyarrow to 0.12.1 and removes workarounds in pyspark to remain compatible with prior versions. This means that users will need to have at least pyarrow 0.12.1 installed and available in the cluster or an ImportError will be raised to indicate an upgrade is needed.
How was this patch tested?
Existing tests using:
Python 2.7.15, pyarrow 0.12.1, pandas 0.24.2
Python 3.6.7, pyarrow 0.12.1, pandas 0.24.0

Need to check about Pandas / Numpy requirements that might go along with this.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/9639/
Test PASSed.

I think we go with 0.12.1 because of https://issues.apache.org/jira/browse/ARROW-4582, might cause a problem

Test build #104301 has started for PR 24298 at commit 5f91d98.

@shaneknapp this passes locally for me so lets give it a shot with the new environment when you have time, thanks!  cc @HyukjinKwon @ueshin

Test build #104301 has finished for PR 24298 at commit 5f91d98.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/104301/
Test PASSed.

@shaneknapp are you going to leave Pandas at version 0.19.2 or is that being upgraded as well for the python 3.6 env?

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/9664/
Test PASSed.

Test build #104331 has started for PR 24298 at commit 057f505.

Test build #104331 has finished for PR 24298 at commit 057f505.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/104331/
Test FAILed.

Test build #104402 has started for PR 24298 at commit cc9a305.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/9733/
Test PASSed.

Test build #104402 has finished for PR 24298 at commit cc9a305.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/104402/
Test FAILed.

Test build #104459 has started for PR 24298 at commit 852dc0f.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/9789/
Test PASSed.

Also to note that Arrow v0.13.0 has recently been released. There were no breaking changes so it is still compatible and increasing the minimum to that version wouldn't help clean up this code anymore. Version 0.12.1 has been pretty stable so far and I still think it's the best choice for a minimum supported version right now.

Test build #104459 has finished for PR 24298 at commit 852dc0f.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/104459/
Test PASSed.

test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/10071/
Test PASSed.

Test build #104756 has started for PR 24298 at commit 852dc0f.

Test build #104756 has finished for PR 24298 at commit 852dc0f.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/104756/
Test PASSed.

From the test output, it passed all pyarrow tests on Python 3.6 with pyarrow 0.12.1, so I think this is good to go! It looks like pyarrow 0.8.0 is installed in the Python 2.7 environment, which shows tests skipped messages. This isn't a problem since we do Arrow testing with Python 3, so the old version of pyarrow can be uninstalled sometime later to clean up the test output. Let's test this one more time and I'll merge later if no more comments.

test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/10076/
Test PASSed.

Test build #104761 has started for PR 24298 at commit 852dc0f.

From the test output, it passed all pyarrow tests on Python 3.6 with pyarrow 0.12.1, so I think this is good to go! It looks like pyarrow 0.8.0 is installed in the Python 2.7 environment, which shows tests skipped messages. This isn't a problem since we do Arrow testing with Python 3, so the old version of pyarrow can be uninstalled sometime later to clean up the test output. Let's test this one more time and I'll merge later if no more comments.

if i'm not mistaken, you're looking at the Running PySpark packaging tests section and seeing the 2.7/arrow tests being skipped.
could you copy/pasta the skipped message you're seeing so that we can ascertain if we're indeed looking at the same thing?

Test build #104761 has finished for PR 24298 at commit 852dc0f.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/104761/
Test PASSed.

Update: @shaneknapp is planning to upgrade the Python 2.7 env to use Pandas 0.24.2 and Pyarrow 0.12.1 also, which will be good to verify Arrow tests pass with both Python 2 & 3. This will hopefully be done on Monday and then this PR can be merged after.

Update: @shaneknapp is planning to upgrade the Python 2.7 env to use Pandas 0.24.2 and Pyarrow 0.12.1 also, which will be good to verify Arrow tests pass with both Python 2 & 3. This will hopefully be done on Monday and then this PR can be merged after.

actually, i just had a thought:
all spark branches (master, 2.3, 2.4) use the same python2.7 env...  will this impact the older branches negatively?
i can (and will) test to confirm.

all spark branches (master, 2.3, 2.4) use the same python2.7 env

I forgot about the branches sharing the same env, in that case we definitely don't want to upgrade pyarrow for the branches. I think it's ok if we leave as is, then master will just skip arrow tests for Python 2 and we are still running the same tests with Python 3.

I forgot about the branches sharing the same env, in that case we definitely don't want to upgrade pyarrow for the branches. I think it's ok if we leave as is, then master will just skip arrow tests for Python 2 and we are still running the same tests with Python 3.

sgtm++

Merged to master.

Thanks all! I'll keep an eye out on Jenkins and make sure this is running ok.

this build was triggered by the merge:
https://amplab.cs.berkeley.edu/jenkins/job/spark-master-test-sbt-hadoop-2.7/5764
all the python tests passed, but holy CRAP the "skipped tests" output is super verbose and could use a for-serious refactor.


Add missing configuration metada

Great! LGTM, of course!
Thank you, @eddumelendez , for contribution!
Would you mind to share with us the trick you have used to spot these missing properties?

Would you mind to share with us the trick you have used to spot these missing properties?

Not a big one. I used to look at the *AutoConfiguration classes and look for properties at @ConditionalOnProperty which are not so many. Then, look if they are all added in the additional-spring-configuration-metadata.json


use message.reply insted of a embed

yeah, nothing else to say

Is this project still alive? Coul`d be very usefull, while supported.

s this project still alive? Coul`d be very usefull, while supported.

nope, use the spearated bridge of automod.

spearated bridge of automod

Whats that? Can you share a link?

Everything works men. Checked. Duno what are you talking here about..

Everything works men. Checked. Duno what are you talking here about..

Whats that? Can you share a link?
Automod removed bridge function, if u are searching a updated bridge bot use automod from that repo


New version: Toolips v0.1.0

Registering package: Toolips
Repository: https://github.com/ChifiSource/Toolips.jl
Created by: @emmettgb
Version: v0.1.0
Commit: c3267ca247d50acfac102c9f5ead25421a2b3346
Reviewed by: @emmettgb
Reference: https://github.com/ChifiSource/Toolips.jl/issues/15#issuecomment-1163662128
Description: a manic web-development framework

@emmettgb please see the message above.  Once you fix the automerge issues you can register again the new revision without changing the version number and this pull request will be automatically updated.
[noblock]


Inbound ID from ReportStream

Story
As a Lab, so that I know when the order was ingested and who sent it, I need the metadata endpoint to report order ingestion time and who sent it.
Acceptance Criteria

[ ] RS sends us an ID that works in the history API
[ ] We are authenticated and authorized to call the history API with that ID

Tasks
Research

[ ] Research work needed to complete the story
[ ] Foundational: High-level research that will support this and future efforts

Engineering

[ ] Engineering work needed to complete the story
[ ] Foundational: Technical runway work to support this and future efforts

Definition of Done

[ ] Documentation tasks completed

[ ] Documentation and diagrams created or updated

[ ] Implementation guide (/ig folder)
[ ] ADRs (/adr folder)
[ ] Main README.md
[ ] Other READMEs in the repo
[ ] If applicable, update the ReportStream Setup section in README.md

[ ] Threat model updated
[ ] API documentation updated

[ ] Code quality tasks completed

[ ] Code refactored for clarity and no design/technical debt
[ ] Adhere to separation of concerns; code is not tightly coupled, especially to 3rd party dependencies
[ ] Code is reviewed or developed by pair; 1 approval is needed but consider requiring an outside-the-pair reviewer
[ ] Code quality checks passed

[ ] Security & Privacy tasks completed

[ ] Security & privacy gates passed

[ ] Testing tasks completed

[ ] Load tests passed
[ ] Unit test coverage of our code >= 90%

[ ] Build & Deploy tasks completed

[ ] Build process updated
[ ] API(s) are versioned
[ ] Feature toggles created and/or deleted.  Document the feature toggle
[ ] Source code is merged to the main branch

Research Questions

Optional: Any initial questions for research

Decisions

Optional: Any decisions we've made while working on this story

Notes
This story involves making changes to the RS code, not the intermediary.
Each step in RS's pipeline is assigned a unique ID.  It is only the first unique ID assigned to a message, when it is first ingested into RS, that can be used on the RS history API.  The inbound ID we get in the HTTP request header today from RS can't be used to call the RS history API because it is the unique ID of that last pipeline step.
After talking with Arnej, he wants us to change the ReST API delivery logic to be able to send that first unique ID which will work in the history API.  Arnej states that there is already a method in RS that can calculate that first unique ID when given any of the other pipeline IDs.  So, ostensibly, all we need to do is call that method with the ID that RS is already sending to the intermediary today and then send that first unique ID to the intermediary instead.
I have a hunch that when the intermediary calls RS's history API with this new inbound unique ID, we may get a unauthorized HTTP status if the sender of the order to RS is not the same organization as flexion, which is the organization our intermediary uses.  I'm a little unsure about this, so like I said, it is a hunch.  If indeed we get an unauthorized HTTP status, we will need to work with RS on how to get around this.

This Story helps complete the requirement:
MVP-REQ-27 - Intermediaries will provide metadata required, including elements to calculate timeliness metrics

This Story helps complete the requirement:
MVP-REQ-27 - Intermediaries will provide metadata required, including elements to calculate timeliness metrics

This Story helps complete the requirement:
MVP-REQ-29 - Each Intermediary shall have a dashboard for some higher level internal monitoring metrics – team who is troubleshooting and supporting would need access to these different views of the system

@halprin reminder to update with prose

Need to make a devx/opex ticket for code cleanup?

https://github.com/CDCgov/prime-reportstream/issues/12624

@halprin @sfradkin
From Max on 02/28/24 "Hi Shawn,
#12624 isn't prioritized in our roadmap and we don't have capacity to take it on right now.
Our recommendation would be for Flexion to implement the change needed in ReportStream. We can help orient whichever engineer takes on the work and we can review/merge the pull request when it's ready. Happy to discuss more on Friday.
Thanks,
Max"

RS Engagement team standing by to support this work if questions come up.

(for future Peter) This story is being closed because TI will be calling the RS deliveries API. The RS deliveries API requires a "sent reportid" and we are already receiving that. No additional work needed.


Roll engine 33bb91cc1591..f80928a9e403 (4 commits)

https://github.com/flutter/engine/compare/33bb91cc1591...f80928a9e403
git log 33bb91cc15916610261097eb971ec8a11b804d06..f80928a9e403c6b2fc1b8de6a00bf6189b715c40 --no-merges --oneline
f80928a9e Roll src/third_party/skia fdd15284affe..ee1c8a733e5b (15 commits) (flutter/engine#7924)
93f339fb6 fix Memory leak when using PlatformView [IOS] #24714 (flutter/engine#7919)
2d33e775f Roll src/third_party/skia 969659dbb313..fdd15284affe (2 commits) (flutter/engine#7922)
6d4edf235 Roll src/third_party/skia 9431161ca973..969659dbb313 (3 commits) (flutter/engine#7921)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff (amirha@google.com), and stop
the roller if necessary.

Auto-roller completed checks. About to merge.


Unable to close Godot window if templates are opened (mbedssl_tls errors)

Godot version:
3.1 beta 4
OS/device including version:
Windows 10
Issue description:

Steps to reproduce:

Open Godot Project list
Click on Templates
Wait few seconds until they are loaded
Try to close the Godot window - you can close it by shutdown console window but not Main window

Ah, true, its about ssl stuff ^^


Request for Detailed README.md for API Integration

It would be greatly appreciated if you could provide a more detailed README.md file. After configuring the Swagger settings, I am stuck and unsure about the next steps to take for the API integration. A comprehensive guide with step-by-step instructions would be extremely helpful in moving forward.

sure, allow me some time. I will put readme.md file

Thanks, @omkardarves! If you could assist me with setting up the Swagger configuration, I would be more than happy to contribute by drafting a detailed README.md file. Your help would enable me to better understand the steps involved, and in return, I can document the process thoroughly for others. Let me know if this works for you.

hey @Venkateshvenki404224 I have updated the README.md, but yes we can talk if you would like some guidance.
I have posted a project structure and API endpoints as well. Please don't hesitate to let me know if you find any trouble.


Fix spacing typo on downloads page

Fixes #903
Changes:
Add space between "Visit" and the permalink "Get Started" in the "Complete Library" section of the downloads page.
Screenshots of the change:

Thanks @tannerdolby!

Your welcome @limzykenneth!


[ISSUE] libcamerasrc is not working with gst-launch-1.0 command

Error in creating pipeline with g-streamer and libcamerasrc
Today, I updated my Raspberry Pi model 4b with the new update for libcamera and libcamera-apps (mentioned in bug report attached). I am now not able to create my gstreamer pipeline with libcamerasrc.
The libcamera-apps like libcamera-still and libcamera-vid can access the camera connected to the CSI cable. But I am not able to access the same camera with libcamerasrc.
For my project, I need to access the camera feed inside Open CV for further transformations. The pipeline was previously working for me, but now it is giving the error message.
I was not able to find enough resources for this error, that's why I posted it here.
Thank you for all the help.
Short description on hardware and software used
For detailed information, see the bug.txt file
** cat /etc/os-release **
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
** libcamera-hello --version **
libcamera-apps build: b9a692385d32 07-01-2022 (16:10:12)
libcamera build: v0.0.0+3384-44d59841

Cameras
libcamera-hello` --list-cameras
[0:29:16.483767384] [5254]  INFO Camera camera_manager.cpp:293 libcamera v0.0.0+3384-44d59841
[0:29:16.498862203] [5255] ERROR CameraSensor camera_sensor.cpp:535 'ov5647 10-0036': Camera sensor does not support test pattern modes.
[0:29:16.519372623] [5255]  INFO RPI raspberrypi.cpp:1313 Registered camera /base/soc/i2c0mux/i2c@1/ov5647@36 to Unicam device /dev/media1 and ISP device /dev/media0

Available cameras
0 : ov5647 [2592x1944] (/base/soc/i2c0mux/i2c@1/ov5647@36)
Modes: 'SGBRG10_CSI2P' : 640x480 1296x972 1920x1080 2592x1944
'SGBRG8' : 640x480
Command Used
Inside Terminal
gst-launch-1.0 -v libcamerasrc ! video/x-raw,width=640,height=480,framerate=90/1 ! videoflip method=clockwise ! videoconvert ! autovideosink
Inside Open CV
libcamerasrc` ! video/x-raw,width=640,height=480,framerate=90/1 ! videoflip method=clockwise ! videoconvert ! appsink
Error
``Setting pipeline to PAUSED ...
[0:29:16.109057821] [5201]  INFO Camera camera_manager.cpp:293 libcamera v0.0.0+3384-44d59841
[0:29:16.125724912] [5208] ERROR CameraSensor camera_sensor.cpp:535 'ov5647 10-0036': Camera sensor does not support test pattern modes.
[0:29:16.146189795] [5208]  INFO RPI raspberrypi.cpp:1313 Registered camera /base/soc/i2c0mux/i2c@1/ov5647@36 to Unicam device /dev/media1 and ISP device /dev/media0
Pipeline is live and does not need PREROLL ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...

Additional debug info:
../src/gstreamer/gstlibcamerasrc.cpp(474): gst_libcamera_src_task_enter (): /GstPipeline:pipeline0/GstLibcameraSrc:libcamerasrc0:
streaming stopped, reason not-negotiated (-4)
Execution ended after 0:00:00.001762380
Setting pipeline to NULL ...
Freeing pipeline ...``
Solution Assumption
I think this error is generated due to the recent update of libcamera libraray causing a driver issue with the camera module. But I am not sure about this.
Bug report
bug.txt

Hi, this issue should already have been fixed in the libcamera library.  To get this fix immediately, you will have to rebuild the libcamera and libcamera-apps libraries from the latest sources.  Instructions can be found here.

Thank you for the response. I will rebuild the libcamera libraries.

I have just recompiled the project and the pipeline works !
But I am still getting these ERROR and INFO messages for my Raspberry Pi camera zero(ov5647).
[1558] ERROR CameraSensor camera_sensor.cpp:551 'ov5647 10-0036': Camera sensor does not support test pattern modes. [0:02:17.231269258] [1558]  INFO RPI raspberrypi.cpp:1326 Registered camera /base/soc/i2c0mux/i2c@1/ov5647@36 to Unicam device /dev/media3 and ISP device /dev/media0
Out of curiosity, can you please tell what could be the reason behind it ?
Is it something related to my hardware being not supported to do functions like autofocus or brightness control through command line ?
Thank you again.

You can safely ignore this message.  It's informing us that the sensor driver has no support for test patters to be generated.  This is not related to normal camera operation.

Okay thanks again.


Active plugins initial

Task/Issue URL: https://app.asana.com/0/488551667048375/1207335546470303/f
Description
This PR adds active plugin points, ie. plugin points that are automatically guarded by remote feature flags.
See this for more context
Steps to test this PR
Feature 1

[ ]
[ ]

#4553  👈
develop

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

Join @aitorvs and the rest of your teammates on  Graphite


remotes/docker: Fix MountedFrom prefixed with target repository

MountedFrom was mistakenly prefixed with the whole target repository instead of just the registry hostname.
Also adjusted the test cases to use the registry hostname.

Yes, will open backports once CI is ok.


Add rocket-plugin

See this PR for my  rocketChat notification plugin.
Already prepared the  wiki page.

I can't find your plugin hosting request. Did you follow the guidelines at https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins ?

thanks for the hint. I overhead the find, see here my filled hosting request: https://issues.jenkins-ci.org/projects/HOSTING/issues/HOSTING-195

So as long as I don't have the hosting request done, we're on wait here, right?

@hypery2k Yes. I linked to this PR from the hosting request, so this gets merged when the hosting request gets implemented.

project is created: https://github.com/jenkinsci/rocket-chat-notifier-plugin

@hypery2k Please note that the repository and artifactId should match (except the repo has a -plugin suffix). So we should either rename the repo rocketchatnotifier-plugin, or change the artifactId to rocket-chat-notifier.
CC @batmat who mentioned a rename in HOSTING-195.
Also, the YAML file name and contents (both name and path) need to be adapted accordingly.

@hypery2k Could you please confirm you want to keep the hyphen-less version of the artifactId? Then I'll merge this and rename your plugin repo to make it match.

yes i can confirm ;)

@hypery2k Someone's already renamed the plugin repo, I didn't notice. Sorry about that.
And I also didn't notice that the name in the YAML file is still rocket. Please note that this must match the last part of the path or it won't work. Sorry about not catching this earlier.

sorry for the confusion. I've renamed it in the YAML file too

@hypery2k I really need to get to the PR builder for this – I'm sorry for this mess.
Please note that the user name to specify is the Jenkins LDAP account used also for JIRA and the wiki. It looks like you have specified your GitHub user name (as the user used to create the wiki page is a different one).
Also, unless you log in once to Artifactory prior to merging this change (which will enable your permissions in ~5 minutes), it will take up to one hour after your initial login to Artifactory to enable permissions. The reason is that Artifactory user database is backed by LDAP, but it only knows about the users that have logged in at least once; and we update permissions from this repo on commit, or periodically.

no problem, for my next plugin I know how it works ;)

@hypery2k  Please note that you need to log in to Artifactory and wait for ~30 minutes before this change will be applied. See prerequisite at https://github.com/jenkins-infra/repository-permissions-updater#requesting-permissions

I can login via Web UI, but via maven  getting following error:
[INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @ rocketchatnotifier ---
Downloading: https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/plugins/rocketchatnotifier/0.2.2-SNAPSHOT/maven-metadata.xml
Downloaded: https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/plugins/rocketchatnotifier/0.2.2-SNAPSHOT/maven-metadata.xml (769 B at 0.6 KB/sec)
Uploading: https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/plugins/rocketchatnotifier/0.2.2-SNAPSHOT/rocketchatnotifier-0.2.2-20161112.135149-2.hpi
Uploading: https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/plugins/rocketchatnotifier/0.2.2-SNAPSHOT/rocketchatnotifier-0.2.2-20161112.135149-2.pom
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 21.366 s
[INFO] Finished at: 2016-11-12T14:51:55+01:00
[INFO] Final Memory: 50M/874M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on project rocketchatnotifier: Failed to deploy artifacts: Could not transfer artifact org.jenkins-ci.plugins:rocketchatnotifier:hpi:0.2.2-20161112.135149-2 from/to maven.jenkins-ci.org (https://repo.jenkins-ci.org/snapshots/): Failed to transfer file: https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/plugins/rocketchatnotifier/0.2.2-SNAPSHOT/rocketchatnotifier-0.2.2-20161112.135149-2.hpi. Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

@hypery2k  401 Unauthorized means you're not correctly sending your credentials to Artifactory. This is different from 403 Forbidden and unrelated to this permission system.
Check this section for suggestions: https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins#HostingPlugins-Workingaroundcommonissues
If none help, consider asking on the jenkinsci-dev list for help.
Also, are you actually trying to upload a snapshot?

Thanks for the hint. Yes, I'm trying to upload a snapshot


apm-server: Run as non-root user

Describe the feature:
I want to run apm-server as a non-root user, same as described here: https://github.com/helm/charts/pull/18366
Currently, if I set podSecurityContext, the Pod fails with the error:
Exiting: error loading config file: open apm-server.yml: permission denied

Hi @caiconkhicon, thanks for submitting this issue.
Can you provide more details about your environment by answering to all the questions asked in the bug report template?

Hi @jmlrt , thank you for your reply. I am happy to provide necessary information. However, IMO, my request here is a feature request.
What I expect is a change to make it possible to run as apm-server with a non-root user. My assumption is that the change should look like https://github.com/helm/charts/pull/18366 in the official Helm chart repository.

This is still valid, however we won't be able to handle it in the short run.
Would you be interested by creating a PR?

@jmlrt : I think I can. Give a one week, I will try to find a time when I can do it.

@jmlrt : There is another problem to let apm-server run as root: the binary is owned by root and cannot be ran by others:
-rwxr-x--- 1 root root 102M Nov 28 07:07 /usr/share/apm-server/apm-server

Thus, when running it as non-root, this error appears:
/usr/local/bin/docker-entrypoint: line 8: /usr/share/apm-server/apm-server: Permission denied

I think the fix should be in the apm-server image. Can you do it? or where to do it? I don't see it looks quite like https://github.com/elastic/apm-server/blob/master/Dockerfile

@caiconkhicon,
Can you open an issue to apm-server repo for that?

@jmlrt : I created an issue in https://github.com/elastic/apm-server and discussed with ppl there. It seems that this is not a bug/issue there but a security limitation. Thus, the apm-server pod must run with runAsGroup: 0. Should we fix it in the Helm chart or let users do it freely (like currently https://github.com/elastic/helm-charts/blob/master/apm-server/values.yaml#L78)


F.hstack is very slow on GPU

Hi all,
I found that F.hstack is very slow on GPU compared to other stack functions.
Does anyone know the reason and fix the problem?
I show my test code below.
import time
import numpy as np
import chainer
import chainer.functions as F
from chainer import cuda
# xp = np
xp = cuda.cupy
a1 = chainer.Variable(xp.array(1*np.eye(3, dtype=np.float32)))
a2 = chainer.Variable(xp.array(2*np.eye(3, dtype=np.float32)))
start = time.time()
b = F.hstack([a1,a2])
end = time.time()
print "hstack          : {0}".format(end-start)
start = time.time()
c = F.concat([a1,a2], axis=1)
end = time.time()
print "concat          : {0}".format(end-start)
start = time.time()
d = F.reshape(F.stack([a1,a2], axis=1), (a1.shape[0], a1.shape[1]*2))
end = time.time()
print "stack + reshape : {0}".format(end-start)
print b.data
print c.data
print d.data
The above concat(axis=1) and stack(axis=1)+reshape can obtain the same result as hstack, when the arrays are 2D matrices.

On CPU
hstack : 0.000693798065186
concat : 0.000406980514526
stack + reshape : 0.00110101699829

When we run those functions on CPU, hstack is fast enough compared to other functions.

On GPU
hstack : 0.18591094017
concat : 0.000824928283691
stack + reshape : 0.00149607658386

However, when we run them on GPU, hstack is too slow compared to other functions.
Does anyone know the reason and fix the problem?

Sorry all.
I found the above reason.
This is not the hstack problem.
This may be memory allocation problem.
When we call concat(axis=1) and stack(axis=1)+reshape before hstak, they are also very slow.


chore(deps): Upgrade to latest Capsize packages

🔗 Linked issue
First step relating to this discussion.
Closes https://github.com/unjs/fontaine/pull/317 and https://github.com/unjs/fontaine/pull/318 (auto-generated PRs)
❓ Type of change
Open to discussing this one, selecting chore for now.

[ ] 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
[ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality like performance)
[ ] ✨ New feature (a non-breaking change that adds functionality)
[x] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description
Upgrading to the latest Capsize packages. This upgrade provides a few key benefits to the Fontaine 🤝 Capsize relationship:

Improved ESM compatibility
Improved types, with consumers encouraged to adopt a moduleResolution strategy that understands the package.json exports key, e.g. Bundler.
Updated xWidthAvg metric, now calculated from more extendable dataset (rather than hard coded English character frequencies) in preparation for supporting other unicode subsets, e.g. Thai.
This is a move away from the original character frequencies collaborated on with the Google Aurora team, and seem to perform same or better, while also having the benefit of no longer being hard coded. As a result the snapshots of metrics and CSS have changed, but here is a visual example of the change to IBM Plex Mono (used in one of the snapshots):

No Capsize:

With Capsize v1:

With Capsize v2:

Note also upgrading to Node 18 in CI due to missing fetch API. Hopefully thats ok given Node 16s move to EOL
📝 Checklist

[ ] I have linked an issue or discussion.
[ ] I have updated the documentation accordingly.

For some reason the codecov bot is comparing this PR to a commit from 4 days ago. If you have any ideas around why that'd be great.


Add support for Findbugs v3

Finalize work started with https://github.com/tim-group/test-driven-detectors4findbugs/pull/24 which did not compile for me out-of-the-box.

Hey, thanks for the patch!


Collada (.dae) meshes with unit != "meter" are broken

If a URDF contains a collada (.dae) mesh which has <unit> != "meter" (e.g. centimeter) on Indigo:
--- collada_unit_meter.dae      2015-02-16 11:14:28.128423513 +0100
+++ collada_unit_centimeter.dae 2015-02-16 11:16:06.542388857 +0100
@@ -7,7 +7,7 @@
     </contributor>
     <created>2015-02-16T11:14:28</created>
     <modified>2015-02-16T11:14:28</modified>
-    <unit name="meter" meter="1"/>
+    <unit name="centimeter" meter="0.01"/>
     <up_axis>Z_UP</up_axis>
   </asset>
   <library_images/>
</COLLADA>

no mesh at all is displayed in rviz RobotModel. It seems the mesh is also ignored for MoveIt! collision checking. The identical URDFs and meshes worked in Hydro.
Test files can be created by simply exporting the default cube as .dae in Blender. Once without modification and once with modified . These files can also be found here: https://gist.github.com/andreasBihlmaier/576b5bc3837c568a6730
Issue is already confirmed by others:
http://answers.ros.org/question/203188/collada-dae-meshes-with-unit-meter-broken/

Here is another set of test meshes that seemed to recently (~ a year ago) work fine (https://github.com/ros-visualization/rviz/issues/751), but currently do not work for me on Ubuntu 14.04.2: https://github.com/garaemon/rviz_collada_marker

Thanks for the report, we'll try to have a look into it as soon as possible.

We tried to reproduce the issue and it turned out that the meshes in centimeters were just coming up too small to be seen. You can check this example repository, if you roslaunch test.launch, you'll see 4 unit cubes: white is in meters, red in decimeters, green in centimeters and blue in inches. If you can't see the centimeters one, just scroll into the origin.
Tested on Ubuntu 14.04.1, RViz 1.11.7 (indigo).
This was tested using markers, we haven't tested URDFs yet.

Just checked that it also worked with URDF on Indigo. Here's a screenshot:

Can you please try out our repository and try to reproduce your issue with it? (make sure you've zoomed in, because the box is very small).

@chapulina thank you for providing the test cases.
Unfortunately, the bug persists for me:

Tested on two hosts with very different GPUs, both running:
> uname -a
Linux myhost 3.16.0-33-generic #44~14.04.1-Ubuntu SMP Fri Mar 13 10:33:29 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

> apt-cache showpkg ros-indigo-rviz
Package: ros-indigo-rviz
Versions:
1.11.7-0trusty-20150307-2257-+0000 (/var/lib/apt/lists/packages.ros.org_ros_ubuntu_dists_trusty_main_binary-amd64_Packages) (/var/lib/dpkg/status)
 Description Language:
                  File: /var/lib/apt/lists/packages.ros.org_ros_ubuntu_dists_trusty_main_binary-amd64_Packages
                  MD5: dc362b1b78b867ed720836e8e80709fe

Just found this old issue and did some tests with latest melodic rviz (1.13.16-1bionic.20210304.161522). Unfortunately the bug persists.
In the collada mesh
<unit name="foo" meter="X"/>
works as expected for all values of X>=1, but nothing shows up for all values X<1.0.

Sorry, but I cannot reproduce the issue. The ros package mentioned in https://github.com/ros-visualization/rviz/issues/853#issuecomment-89043684 works for both, Melodic and Noetic. Are you sure you are using the default libassimp (4.1.0 for Melodic, 5.0.1 for Noetic)? Meshes are all loaded by libassimp. I also verified that this issue isn't related to the language settings.

This is very strange:

The only thing showing up is the "meter_marker"

I'm currently updating my systems at home. Will retry on another system and also this one with focal+noetic tomorrow.

libassimp seems to be system default:
desknew ~/catkin_ws/src/rviz_issue_853> dpkg -S /usr/lib/x86_64-linux-gnu/libassimp.so.4.1.0
libassimp4:amd64: /usr/lib/x86_64-linux-gnu/libassimp.so.4.1.0
desknew ~/catkin_ws/src/rviz_issue_853> apt-cache showpkg libassimp4
Package: libassimp4
Versions:
4.1.0~dfsg-3 (/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_bionic_universe_binary-amd64_Packages) (/var/lib/dpkg/status)
 Description Language:
                 File: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_bionic_universe_binary-amd64_Packages
                  MD5: 19a3b9c95112bea7e3f3134dbd0cf8eb
 Description Language:
                 File: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_bionic_universe_binary-i386_Packages
                  MD5: 19a3b9c95112bea7e3f3134dbd0cf8eb
 Description Language: en
                 File: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_bionic_universe_i18n_Translation-en
                  MD5: 19a3b9c95112bea7e3f3134dbd0cf8eb

Reverse Depends:
  libassimp-dev,libassimp4 4.1.0~dfsg+1~
  ros-eloquent-rviz-rendering,libassimp4
  ros-dashing-rviz-rendering,libassimp4
  ros-crystal-rviz-rendering,libassimp4
  ros-crystal-mrpt2,libassimp4
  ros-bouncy-rviz-rendering,libassimp4
  ros-melodic-rviz,libassimp4
  ros-melodic-robot-self-filter,libassimp4
  ros-melodic-pr2-navigation-self-filter,libassimp4
  ros-melodic-mrpt2,libassimp4
  ros-melodic-mrpt1,libassimp4
  ros-melodic-hpp-fcl,libassimp4
  ros-melodic-geometric-shapes,libassimp4
  ros-melodic-euscollada,libassimp4
  ros-melodic-collada-urdf,libassimp4
  ros-melodic-cob-obstacle-distance,libassimp4
  libassimp4:i386,libassimp4 4.1.0~dfsg-3
  libassimp4:i386,libassimp4 4.1.0~dfsg-3
  python3-pyassimp,libassimp4 4.1.0~dfsg+1~
  python3-pyassimp,libassimp4 4.1.0~dfsg-3
  python-pyassimp,libassimp4 4.1.0~dfsg+1~
  python-pyassimp,libassimp4 4.1.0~dfsg-3
  librviz2d,libassimp4
  libmrpt-opengl1.5,libassimp4
  libkido0.1,libassimp4
  libkido-utils0.1,libassimp4
  libkido-gui-osg0.1,libassimp4
  libgeometric-shapes2d,libassimp4
  libcollada-urdf0d,libassimp4
  libassimp-dev,libassimp4 4.1.0~dfsg-3
  assimp-utils,libassimp4
  doomsday-common,libassimp4
  collada-urdf-tools,libassimp4
Dependencies:
4.1.0~dfsg-3 - libc6 (2 2.14) libgcc1 (2 1:3.0) libminizip1 (2 1.1) libstdc++6 (2 5.2) zlib1g (2 1:1.1.4) libassimp4:i386 (35 4.1.0~dfsg-3) libassimp4:i386 (38 4.1.0~dfsg-3)
Provides:
4.1.0~dfsg-3 -
Reverse Provides:

Maybe you have another version of libassimp installed as well? What's the result of
$ ldd /opt/ros/melodic/lib/librviz.so | grep assimp

Nope, resolves to lib above:
desknew ~/catkin_ws/src/rviz_issue_853> ldd /opt/ros/melodic/lib/librviz.so | grep assimp
        libassimp.so.4 => /usr/lib/x86_64-linux-gnu/libassimp.so.4 (0x00007f70fbb18000)
desknew ~/catkin_ws/src/rviz_issue_853> ll /usr/lib/x86_64-linux-gnu/libassimp.so.4
lrwxrwxrwx 1 root root 18 Dez 21  2017 /usr/lib/x86_64-linux-gnu/libassimp.so.4 -> libassimp.so.4.1.0

I had the same issue on a fresh install of focal + noetic.
The problem is that my systems had
desknew ~> env | egrep '^(LANG|LC)'
LANG=en_US.UTF-8
LANGUAGE=
LC_ADDRESS=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_MONETARY=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_NUMERIC=de_DE.UTF-8
LC_PAPER=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_TIME=de_DE.UTF-8

from the default Ubuntu installer.
After unset LC_NUMERIC everything works as expected:

Hm. I suspected the language settings from the very first moment. Looks like, I missed testing the correct variable...


[incubator/sparkoperator] Add missing namespaces for spark operator resources

What this PR does / why we need it:
The namespace is currently missing from the operator resources so an install leads to a crashlooping operator because the clusterrolebinding doesn't bind to the operator's service account.  Also the operator doesn't get installed in the namespace that you pass with the --namespace flag.
Which issue this PR fixes
n/a
Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ x] DCO signed
[ x] Chart Version bumped
[ x] Variables are documented in the README.md
[ x] Title of the PR starts with chart name (e.g. [stable/chart])

/assign @yuchaoran2011

I'm not sure why you ran into the situation that you described. I just tested the chart and it's working fine. The namespace field isn't required. helm's --namespace flag looks to be working as expected.

@yuchaoran2011
Could you share the output you get from helm template incubator/sparkoperator --namespace spark-operator?

$ helm template incubator/sparkoperator --namespace spark-operator
---
# Source: sparkoperator/templates/spark-operator-serviceaccount.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: release-name-sparkoperator
  labels:
    app.kubernetes.io/name: sparkoperator
    helm.sh/chart: sparkoperator-0.2.3
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/managed-by: Tiller

---
# Source: sparkoperator/templates/spark-serviceaccount.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name:
    release-name-spark
  namespace:
  labels:
    app.kubernetes.io/name: sparkoperator
    helm.sh/chart: sparkoperator-0.2.3
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/managed-by: Tiller

---
# Source: sparkoperator/templates/spark-operator-rbac.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: release-name-sparkoperator-cr
  labels:
    app.kubernetes.io/name: sparkoperator
    helm.sh/chart: sparkoperator-0.2.3
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/managed-by: Tiller
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["*"]
- apiGroups: [""]
  resources: ["services", "configmaps", "secrets"]
  verbs: ["create", "get", "delete", "update"]
- apiGroups: ["extensions"]
  resources: ["ingresses"]
  verbs: ["create", "get", "delete"]
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["events"]
  verbs: ["create", "update", "patch"]
- apiGroups: ["apiextensions.k8s.io"]
  resources: ["customresourcedefinitions"]
  verbs: ["create", "get", "update", "delete"]
- apiGroups: ["admissionregistration.k8s.io"]
  resources: ["mutatingwebhookconfigurations"]
  verbs: ["create", "get", "update", "delete"]
- apiGroups: ["sparkoperator.k8s.io"]
  resources: ["sparkapplications", "scheduledsparkapplications"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: release-name-sparkoperator-crb
  labels:
    app.kubernetes.io/name: sparkoperator
    helm.sh/chart: sparkoperator-0.2.3
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/managed-by: Tiller
subjects:
  - kind: ServiceAccount
    name: release-name-sparkoperator
    namespace: spark-operator
roleRef:
  kind: ClusterRole
  name: release-name-sparkoperator-cr
  apiGroup: rbac.authorization.k8s.io

---
# Source: sparkoperator/templates/spark-operator-deployment.yaml
# If the admission webhook is enabled, then a post-install step is required
# to generate and install the secret in the operator namespace.

# In the post-install hook, the token corresponding to the operator service account
# is used to authenticate with the Kubernetes API server to install the secret bundle.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: release-name-sparkoperator
  labels:
    app.kubernetes.io/name: sparkoperator
    helm.sh/chart: sparkoperator-0.2.3
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/managed-by: Tiller
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: sparkoperator
      app.kubernetes.io/version: v2.4.0-v1beta1-0.8.2
  strategy:
    type: Recreate
  template:
    metadata:
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "10254"
        prometheus.io/path: /metrics
      labels:
        app.kubernetes.io/name: sparkoperator
        app.kubernetes.io/version: v2.4.0-v1beta1-0.8.2
      initializers:
        pending: []
    spec:
      serviceAccountName: release-name-sparkoperator
      containers:
      - name: sparkoperator
        image: gcr.io/spark-operator/spark-operator:v2.4.0-v1beta1-0.8.2
        imagePullPolicy: IfNotPresent
        ports:
          - containerPort: 10254

        args:
        - -v=2
        - -namespace=
        - -ingress-url-format=
        - -install-crds=true
        - -controller-threads=10
        - -resync-interval=30
        - -logtostderr
        - -enable-metrics=true
        - -metrics-labels=app_type
        - -metrics-port=10254
        - -metrics-endpoint=/metrics
        - -metrics-prefix=

---
# Source: sparkoperator/templates/crd-cleanup-job.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: release-name-sparkoperator-crd-cleanup
  annotations:
    "helm.sh/hook": pre-delete
    "helm.sh/hook-delete-policy": hook-succeeded
  labels:
    app.kubernetes.io/name: sparkoperator
    helm.sh/chart: sparkoperator-0.2.3
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/managed-by: Tiller
spec:
  template:
    spec:
      serviceAccountName: release-name-sparkoperator
      restartPolicy: OnFailure
      containers:
        - name: delete-sparkapp-crd
          image: gcr.io/spark-operator/spark-operator:v2.4.0-v1beta1-0.8.2
          imagePullPolicy: IfNotPresent
          command:
            - "/bin/sh"
            - "-c"
            - "curl -ik \
          -X DELETE \
          -H \"Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)\" \
          -H \"Accept: application/json\" \
          -H \"Content-Type: application/json\" \
          https://kubernetes.default.svc/apis/apiextensions.k8s.io/v1beta1/customresourcedefinitions/sparkapplications.sparkoperator.k8s.io"
        - name: delete-scheduledsparkapp-crd
          image: gcr.io/spark-operator/spark-operator:v2.4.0-v1beta1-0.8.2
          imagePullPolicy: IfNotPresent
          command:
            - "/bin/sh"
            - "-c"
            - "curl -ik \
          -X DELETE \
          -H \"Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)\" \
          -H \"Accept: application/json\" \
          -H \"Content-Type: application/json\" \
          https://kubernetes.default.svc/apis/apiextensions.k8s.io/v1beta1/customresourcedefinitions/scheduledsparkapplications.sparkoperator.k8s.io"

---
# Source: sparkoperator/templates/spark-rbac.yaml

---
# Source: sparkoperator/templates/webhook-cleanup-job.yaml

---
# Source: sparkoperator/templates/webhook-init-job.yaml

---
# Source: sparkoperator/templates/webhook-service.yaml

Thanks @yuchaoran2011
That matches what I'm seeing.  And if you create the namespace spark-operator and use kubectl apply to install that manifest, you'll get the behavior I described.
I can only guess that tiller created and inserted the namespace for you when you installed it.  So this PR will allow the chart to produce valid manifests with helm template as well.

Yes you are right that Tiller automatically fills in the namespace for you when running helm install. I've never done the thing you described myself(i.e. kubectl the output of helm template). But I guess it's a valid use case.


Don't display selection list if there are no snippets

Snippets box (field) is now showing up even when there are no Snippets available for particular user. This is annoying to users, which do not use Snippets.
Initially reported in https://mantisbt.org/bugs/view.php?id=23524

This is a regression introduced by commit 0dfa8b19f9ffe356b99505575e723e6652cc1162.


[python] Prototype: better version numbers during development

Issue and/or context: #2547, extends #2560
1.5.0 (Nov '23) is typically the most recent tag that's an ancestor of main, because subsequent release tags all exist on release branches.
This means local installs get versions like 1.5.0rc0.post332.dev6296020074, adapted from git describe (the dev number is the Git short SHA, git log -1 --format=%h, converted to base 10, for PEP440-compliance).
It's a little weird to see 1.5.0* on dev installs, and it crashes in shallow clones (which GHA / RTD use by default).
Changes
1. Fallback version number based on most recent release tag (e.g. 1.11.1.post0.dev67466703006)
If git describe returns 1.5.0 as the nearest tagged ancestor, synthesize a more meaningful version number:

Find the latest release tag in the local repo (or tracked remote, if there are no local tags, e.g. in case of a shallow clone).
Return a version like A.B.C.post0.devN:

A.B.C is the most recent release tag in the repo, and
post0 is intended to signal that we are "ahead" of A.B.C, though the number of commits is not computed/specified.

We are also "behind" by an unknown number of commits, but it's not important to specify either number in the version number.
Something that roughly tracks what the "next" SemVer will be, and encodes the Git SHA, seems better than the status quo.

N is the current short Git SHA, converted to base 10 (as above).

2. "CalVer" fallback (e.g. 2024.05.14.dev67466703006)
The first commit in this PR adds an additional "CalVer"  fallback (suggested by @jp-dark 🙏):
def generate_cal_version():
    today = date.today().strftime("%Y.%m.%d")
    return f"{today}.dev{get_sha_base10()}"

CalVer currently unused
Fallback 1. above should always find the most recent release tag (in the upstream remote, worst case) so this CalVer is never expected to be used, as written, but I've left it in for discussion.
We could merge it, to keep the option available, or "stash" it for later.
3. Preview/Check version number: python apis/python/version.py
I added an __name__ == '__main__' hook to make it easy to interact with this code without running a full pip install -e ..
I also cleaned up a few things (e.g. use open as a ContextManager, convert camelCase names to snake_case).

I've also removed the fetch --unshallow from .readthedocs.yml, which is no longer necessary.
Here's a passing RTD build, corresponding docsite built from this branch.

I'm fine with this PR, but I can't pass up the opportunity to propose a radical simplification of the versioning. I know Python developers like to automate the version bumps (either via setuptools-scm or a custom script like we do here). But this automation is not without its own headaches and maintenance requirements. Getting setuptools-scm to behave in our conda feedstock builds is a pain, and with this PR version.py has grown to over 200 lines.
Manually bumping the version at each release isn't that terrible. When you go to git tag a release, also bump the version in setup.py and DESCRIPTION. Or you could even create a super simple script like bump-version.sh X.X.X that bumps the version to X.X.X in setup.py and DESCRIPTION and then runs git tag -a X.X.X.
I know this proposal is unlikely to be adopted, but I feel compelled to point out this alternative.

What version would you suggest dev builds get right now, when the most recent release tag is 1.11.1?

It depends. What function do we need the dev versions to serve? Do we expect end users to ever see them? Do developers ever actually refer to the dev version, or instead to the exact Git sha? Are dev versions required for RTD to function properly?
For personal and smaller projects (1-4 developers), I tend to manually bump a 4th dev version, so it would be <IP_ADDRESS>, <IP_ADDRESS>, etc., until release time when it would be bumped to either 1.12.0 or 1.11.2. But in a higher-velocity repository like this with many developers, that can get cumbersome (eg having to resolve merge conflicts due to version numbers if someone else's PR is merged before yours).
A simple option would be to add a big number like 9999 after each release to indicate it is a dev version. Then no one touches it until the next release.
And if no one is using the dev version as a diagnostic, we could just leave the version untouched between releases.


oasis: 0.4.6 -> 0.4.7

Motivation for this change
Update oasis to allow new-style setup.ml
Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] OS X
[ ] Linux

[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Kept a copy of oasis_46 around for the moment to service qtest. The opam repository shows this too https://github.com/ocaml/opam-repository/issues/7305 and is keeping 4.6 around for it and similar packages for the moment.

If this lands before #18572 , that PR will need to be updated to use only oasis_46 as well. If this hasn't landed when that does, I'll push another commit to this to deal with it.

I think both definitions could be factored.
Otherwise, :+1:

Do we need to keep the version 46? Notice that I have just updated qtest in 38c143abe2363aa8770a4879b348f7aeaf3fbca1.

@vbgl It's no longer needed for qtest, but I'm still looking whether it can be avoided for #18572

https://github.com/janestreet/js-build-tools/blob/master/opam#L19
As of master, js-build-tools (which is now used to build all jane street core libraries) conflicts with 0.4.7. As a result, I suggest we keep 0.4.6 around for the moment.

@maurer is this ready to go, with the janestreet stuff having been merged?

@joachifm Just added the compatibility patch to the Janestreet stuff, I expect it should be good to go now.

@joachifm I just added the Jane Street compatibility stuff. It should be good now.


Snapdragon power module not working on all boards

The power module (ltc2956) is currently not working on all boards. Could the issue be a hardware revision?
I tried different power modules but the reason seems to be the board. It's the same OS version on all devices...
mini-dm output
[08500/02]  43:36.192  HAP:61:starting LTC2946  0168  df_ltc2946_wrapper.cpp
[08500/00]  43:36.192  HAP:61:started LTC2946  0176  df_ltc2946_wrapper.cpp
[08500/00]  43:36.192  HAP:61:1205568 LTC2946: Open the device path: /dev/iic-3   0111  LTC2946.cpp
[08500/02]  43:36.192  HAP:61:I2C_Write failed: 285212872 num_bytes_written 0  0414  i2c.c
[08500/00]  43:36.192  HAP:61:1205683 Error: i2c write failed. Reported -1 bytes written   0240  I2CDevObj.cpp
[08500/00]  43:36.192  HAP:61:1205712 ltc2946: configure failed!   0091  LTC2946.cpp
[08500/00]  43:36.192  HAP:61:1205735 error: sensor initialization failed, sensor read thread not started   0125  LTC2946.cpp
[08500/00]  43:36.192  HAP:61:1205768 error: Failed to start ISL   0139  LTC2946.cpp
[08500/03]  43:36.192  HAP:61:LTC2946 start fail: -1  0114  df_ltc2946_wrapper.cpp
[08500/03]  43:36.192  HAP:61:DfLtc2946Wrapper start failed  0182  df_ltc2946_wrapper.cpp

@mcharleb @jywilson any ideas?

Did you tested it with power connector connected to Qualcom ESC or APM board, with battery or 5v power supply.
Driver currently expects 2 LTC2946 modules on i2c bus and will fail either in initialization or sensor reading of both of them are not present.
from my tests:

Qualcom ESC - single LTC2964 with address 0x6a(d4), without modifications current driver fails during initialization because it tries to configure LTC2946_I2C_ADDRESS=LTC2946_I2C_ADDRESS_5V
APM with 5v plug - 2 LTC modules but only one of them is powered, config using 0x6b(d6) succeeds  but _measure fails due to second LTC2964 not being powered
APM with 5v and battery - everything works, although config has been applied to only one of the two LTC2964
APM with battery - same as APM with battery and 5v plug

Slightly related, I observed that sometimes when LTC2946 wasn't working properly it caused problems for other i2c drivers on the same bus(df_bmp280_wrapper).


635 update default split value

expected behavior

the default split value is now "true" do to reasons listed in the issue
split will default to a pipe ("|") only because the semi-colon (";") is a valid character in the remote_url header. also removed the colon (":") as an option because I think it could mess up in the same place.

this is still a draft because I haven't tested this code, but these are the changes that felt right to me by just looking at the code.

closing this for the moment rather than leaving it as a draft. the direction on handling this may change (refer to the ticket).


Trouble with BDF stimulus channel (again)

Hi all,
Sorry for having to resuscitate this issue, but I'm having an issue with a BDF file (attached) with the latest MNE dev version. This file is a simple toy example with 8 channels and 16 time samples, with no stim_channel. The  file in question was saved using pyedflib.
When I do :
mne.io.read_raw_edf('eegfile.bdf', stim_channel='auto', preload=True)

I get (as expected) :
<RawEDF  |  eegfile.bdf, n_channels x n_times : 9 x 16 (15.0 sec), ~23 kB, data loaded>
However when I do :
mne.io.read_raw_edf('eegfile.bdf', stim_channel=None, preload=True)

I get :
<RawEDF  |  eegfile.bdf, n_channels x n_times : 9 x 608 (16.0 sec), ~64 kB, data loaded>
... which doesn't make sense. But shouldn't the output of read_raw_edf be the same in my case (no stimulus channel)
Do you have any idea why this could be ?
eegfile.bdf.zip

Without looking at the data, yes I agree this looks broken.

@cbrnr can you have a look? thx

Yes, there seems to be a problem with correctly detecting the sampling frequency. I'll try to hunt down the issue.

On second look, this behavior makes sense. This file contains a stim channel with fs=38Hz, whereas the normal channels have fs=1Hz. If you load it with stim_channel=None, you're actually forcing mne.io.read_raw_edf to load the file in a wrong way, namely as if the last channel were a normal channel.
One thing I noticed though is that the stim channel is called "BDF Annotations", whereas we currently only check for "EDF Annotations" in our code. However, this is a separate issue and doesn't change the behavior if you explicitly set stim_channel=None.

It might be useful to issue an info message whenever a special EDF+/BDF+ annotations channel is detected (these are channels called "EDF Annotations" or "BDF Annotations"). Furthermore, we could issue a warning if an annotation channel is detected, but the user loads the file with stim_channel=None. Or in the latter case, we could also exclude the stim channel completely (which would probably make more sense).

@cbrnr Thanks a lot for checking this. I'm still not sure this is normal behaviour though as I'm never specifying any stim_channel when writing the file with pyEDFlib (my input data is 8 regular channels * 16 samples). Do you think it's a bug with pyEDFlib ?
I wonder if it makes sense to load a stim_channel (in my case BDF annotations) at a different sampling rate than regular channels). Either way, it's probably not a good idea to do it silently... What do you think ?
EDIT: just saw your last message, yes maybe this would be useful

Apparently pyedflib automatically adds an annotation channel. I verified this with SigViewer - there are 8 channels and exactly one event at position 0, duration 0, type "Recording starts".
What's odd though is that even with stim_channel="auto" the annotations are not correctly parsed (the data in the last channel contains 16 zeros, and find_edf_events() returns nothing). This might have to do with the fact that we've never actually had a BDF+ file.

Actually, now I'm not even sure if this is a valid BDF file since BioSig for MATLAB can't open it (I get an error related to a reshape command)...

Sorry for the delay, I'll investigate this with my colleague and will let you know. From what I can tell though this file was simply written with pyEDFlib with no special parameters (and MNE can read it OK with the appropriate stim_channel).

@nbara any update on this?

@larsoner I think you can remove the 0.16 label since this is very likely not a bug.

Sorry all, I have no time to properly investigate this at the moment.
Why don't you close this issue for now and I'll reply here when I have more time on my hands to test it ?

No problem @nbara - we can leave it open and just remove the 0.16 label so that this doesn't block the upcoming release.

@massich can you confirm that as soon as 0.17 is released we will get rid of all of the stim channel synthesis business? If so then please close this issue as it will become irrelevant immediately after release

yes. As soon as we release, we'll remove the stim channel synthesis


Dynamic measurement is still not working

Hi,
I spent hours on this, but I still don't believe dynamic measurement is really working in react-virtual. FYI, I read this issue already: #23
This is the example from the doc, but it has hardcoded width and height based on ${virtualColumn.size}px, and ${virtualRow.size}px. The resulting dimensions are controlled by these values and they are not dynamic in this example.
https://codesandbox.io/s/github/tannerlinsley/react-virtual/tree/master/examples/dynamic
In my case, I have fixed column widths and every cell can have dynamic height. I don't think this is supported. Here are my observations.

I tried removing the hardcoded width and height from the example, but as soon as I do so, I get an error that "Maximum update depth exceeded". It seems it could not calculate the dimensions properly and got stuck in a loop. (Is this a bug?)

Removing only the height from the linked example above makes each cell to have the same height. However, this only works only if every cell in the same row has the same height. As soon as I make several cells have different height within the same row, I get the "Maximum update depth exceeded" error again.

It's dynamic in a sense that each row can have different heights, but not each cell. (And, this is only for using fixed column width. I'm not sure how this would even work if both row and column had dynamic size.) I wouldn't call this behavior dynamic.
If it works if every cell in the same row has the same height, wouldn't it possible to take the maximum height in each row use it across all cells in the row? I'm not sure why it crashes with the error.

Hi, yes examples are wrong in dynamic context, width and height should not be set, we need to update them soonish. If you could provide codesanbox then we can check what's wrong. Also have a look at https://github.com/tannerlinsley/react-virtual/issues/28 there i explain bit more caveats with measureRef.

Thanks!
It'll crash as soon as you remove these two lines.

Not sure if it's helpful, but I created a sandbox here.

And here's another one that I explained in 2 in the original post. Cells in each row have different heights in this one.
https://codesandbox.io/s/fervent-glitter-2v6s9

It'll crash as soon as you remove these two lines. This is what I explained in "1" in my original post.

Ooo, it throws an error because the width is different in some rows for same columns, basic column width must be the exact for each row, same for row.

And here's another one that I explained in "2" in the original post. Cells in each row have different heights in this one. I removed the hardcoded height, but kept the hardcoded width.

Same story, i think you are after masonry layout, so we would need to have virtualizer for each row/column? 🤔
fyi created pr with updated examples https://github.com/tannerlinsley/react-virtual/pull/236

Thanks, I'd expect it to pick the tallest/widest cell and other cells would inherit the same size. This would mean we'll need to scan across every visible cell and that's possibly expensive to do, but this could be something nice to add to the documentation (Just a suggestion ;)).
By the way, I'm not quite sure what you updated in the PR. I visited the link, but the example still has hardcoded width and height.

Thanks, I'd expect it to pick the tallest/widest cell and other cells would inherit the same size.

Sound like good example to add 😉

By the way, I'm not quite sure what you updated in the PR. I visited the link, but the example still has hardcoded width and height.

The trick here is to move hardcoded values to child element, not where we attach the measureRef, this how we simulate the dynamic size.

Thanks, I'll leave it to you whether you want to close this issue as the duplicate of the other issue you mentioned. I wanted to know whether this was supported, and I moved on to react-virtualized for now which seems to support some of this.

We do need to get the examples fixed, but other than that, the dynamic sizing should work just fine. As for the masonry layout features, we'll likely need to work our way into that in the next major version. Closing for now.

I just ran into this so I'll add the solution that worked for me. Try setting a maximum width/height on your virtualized elements. If you have virtualized columns set a maximum width and if you have virtualized rows set a maximum height. In my case, I was virtualizing columns and one of the columns was growing to fill the entire available width. When I added the maximum width constraint, the update loop went away, and I was able to diagnose the problem.


bug: Security vulnerabilities in external Login API endpoint

PR Fixes:

Mitigate potential timing attacks
Reduce excessive data exposure
Implement robust input validation using Zod
Standardize error messages to prevent user enumeration
Improve error handling and logging

Resolves #1416
Description:
This pull request addresses the security vulnerabilities identified in our external Login API endpoint. The following improvements have been implemented:

Timing attack mitigation: Implemented a constant-time comparison for non-existent users to prevent timing-based enumeration attacks.

Data exposure reduction: Limited the user and course data returned in the API response to only necessary fields, preventing exposure of sensitive information.

Input validation: Integrated Zod for robust input validation, ensuring that email and password inputs are properly validated before processing.

Error message standardization: Implemented consistent error messages for invalid credentials, regardless of whether the user exists or not, to prevent user enumeration.

Error handling and logging: Improved error handling with more specific logging while keeping client-facing messages generic to enhance security and maintainability.

These changes significantly enhance the security of our authentication system while maintaining compatibility with the existing job-board application.
Checklist before requesting a review

[x] I have performed a self-review of my code
[x] I assure there is no similar/duplicate pull request regarding same issue

@devsargam @hkirat please review again

LGTM! Will merge after the current version is properly deployed

waiting for merge :)


Split SpaceView -> SpaceViewState + SpaceViewBlueprint

Explicitly separate SpaceViewState, which is part of the Viewport state and persists frame-to-frame from the SpaceViewBlueprint which otherwise controls its behavior.
This is the first phase of:

https://github.com/rerun-io/rerun/issues/2089

Checklist

[x] I have read and agree to Contributor Guide and the Code of Conduct
[ ] I've included a screenshot or gif (if applicable)

PR Build Summary: https://build.rerun.io/pr/2188

Really needs this for all sort of things, so merging without waiting for replies.


Talkback reads webview in its entirety

Talkback does not read webview line by line. Will only read webview at once.

Without additional information, we are unfortunately not sure how to resolve this issue.
We are therefore reluctantly going to close this bug for now.
Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.
Could everyone who still has this problem please file a new issue with the exact description of what happens, logs, and the output of flutter doctor -v.
All system setups can be slightly different, so it's always better to open new issues and reference related issues.


Body snap rotation doesn't work when player is holding an object with two hands

Fluent Y-axis body rotation overrides body snap rotation and immediately moves player back to original position.

Fixed with https://github.com/patrykkalinowski/godot-xr-kit/commit/f8c47a8f1947f0412af403a1017cad7e5ba91d1b


override path where the file is saved

i would like to add in the config destination_path options

Hello,
This package relies on pionl/laravel-chunk-upload, so maybe can you solve your problem by setting this package's configuration according to your needs.
The code where this configuration is used looks like:
\Storage::disk(config('chunk-upload.storage.disk'))->path($filePath);

And the configuration itself is:
<?php
/**
 * @see https://github.com/pionl/laravel-chunk-upload
 */

return [
    /*
     * The storage config
     */
    'storage' => [
        /*
         * Returns the folder name of the chunks. The location is in storage/app/{folder_name}
         */
        'chunks' => 'chunks',
        'disk' => 'local',
    ],
   // ...
];

So, if you define a new disk in your filesystems configuration, you may be able to do what you're intending to do :)
Jeremy


scripts make_deep_image_analogy.sh compile failed.

when I run sh scripts/make_deep_image_analogy.sh,  I encountered an error as below:
/usr/bin/ld: /tmp/tmpxft_00002d53_00000000-41_DeepAnalogy.o: undefined reference to symbol '_ZN2cv7imwriteERKNS_6StringERKNS_11_InputArrayERKSt6vectorIiSaIiEE' /usr/local/lib/libopencv_imgcodecs.so.3.2: error adding symbols: DSO missing from command line
opencv version: 3.2.0
caffe: up to date.
cuda: 7.5

add new line to the bash file.
-lopencv_imgcodecs \


Publish plugin on Gradle Plugin Portal

Plugin not available through gradle plugins block.

It probably shouldn't be. There is a newer gradle plugin we'd prefer developers to use.


Consider adding a toggle for low-ink output

The CSS filter grayscale could possibly be used to achieve a black and white output.
Maybe just adding (-webkit-)filter: grayscale(100%); to all .card elements would do the trick.

However, a "low-ink" version should not just be the same cards in black and white; a user can toggle that when actually doing the printing. Instead, the cards should be less "heavy" versions; i.e. use less background fills and things like that.

This could be a button toggle on the final output. The button would have to be hidden or removed when doing the print.

Closing this. Not necessary- and as mentioned, a low-ink version is more involved and is probably even a different output.


Cyrum commit

User Cyrum added.

Are there any updates here or should we close the PR and label it as spam?

Whoops, missed this email. I'll take care of it tonight.
Thanks!
On Mon, Oct 16, 2017 at 7:39 AM, Salman Shah<EMAIL_ADDRESS>wrote:

Are there any updates here or should we close the PR and label it as spam?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/WebClub-NITK/Hacktoberfest-2k17/pull/380#issuecomment-336861301,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AZgOQ3S6pC9HJfXihsm7BhnyYXezNlxyks5ss0CDgaJpZM4P3yOg
.

--
Alex Petrovich

Any updates?

Are there any updates or should we close the PR?


No Windows support for application packages as images

Description
As one cannot create a FROM scratch image for Windows containers; one cannot create or pull application packages from the Hub.
Steps to reproduce the issue:

Enable Windows containers on Docker Desktop
docker-app save

Describe the results you received:
Error, unable to create FROM scratch image.
Describe the results you expected:
docker-app saves the application package as an image.
cc @sixeyed

The first step is to document this limitation while we work out the way forward.

This is now fixed in master as we now bake our own images and talk directly to the registry.


Availability of the source code

Dear @Jiaxin-Lu,
I've came recently upon your work about the shape assembly and it seems interesting and I would be interested to try it. Thus, I would like to know if you have any ETA for uploading the code.
Thanks.

Hi @ttsesm,
Thanks for your interest in our work. We plan to release the code upon acceptance of the paper, which is an unpredictable process. If you have any specific questions regarding the implementation, please feel free to email me. I'll be happy to help :)
Best,
Jiaxin

Hi @Jiaxin-Lu,
Thanks for the feedback. Yes I know how it is with the review procedure, no worries ;-).
Questions regarding the implementation for sure will raise up once I will be able to check on the source code and have a better understanding of how you are implementing the different parts. However, some quick first questions are the following:

In the paper you mention that you sub-sample the point clouds down to 5000 points as the whole object. This means that the different fragments will have different points size, right? This also means that the density of smaller fragments will be more sparse in regards to bigger fragments. Dont' you think that this might be causing a drop in the accuracy?
In the original breaking bad paper they are actually sub-sampling each fragment to a given number of points, if I am not wrong it is 1024 points per fragment, which also creates this kind of imbalance into the points density representation of the fragments as you can see in the following image:

The smaller piece is more dense in comparison to the larger piece, and in the fragmented area the larger piece is represented from 4 points while the smaller piece from much more points.
The idea of using local feature descriptors makes a lot of sense, however one the reasons that the breaking bad authors were not using it was that it was too much source hungry. Thus, I am not sure that I understood clearly how you did manage to overcome this part.
If I understood correctly you created extra labels over the original breaking bad dataset regarding whether a point is on a fragmented surface or not, is that correct?
Have considered taking into account the whole mesh information instead of just the points. I have the feeling that being able to take into account information like the faces and the vertices connectivity, i.e. the edges, apart from the vertices of the mesh could be a lot more helpful to establish feature vectors for good bijection matching between the fragmented surfaces.

Thanks.

Hi @ttsesm ,
Thanks for your interest and understanding. Here are our response to your question:

We sub-sample points based on the surface area of each piece. This helps to alleviate the imbalance in density across the fragments. It also aligns with the real-world scanning technology. You can find a visualization of our point sampling in Figure 7 in the appendix.
We acknowledge that using local feature descriptors costs more computational resources. However, we have demonstrated that local features are crucial for accurately assembling fracture pieces. Experimental results also clearly illustrate the limitations of global features in this context.
Regarding the extra labels, we compute them based on the ground truth position of each piece in the original Breaking Bad dataset. This process doesn't involve any additional manual labor or introduce new information into the dataset.
The synthetic mesh data exhibits an unrealistic level of optimality that may not reflect real-world applications. To ensure a fair comparison with prior work and maintain alignment with real-world scenarios, we have opted to focus on point clouds as the representation of choice. However, we do understand the importance of capturing structural information. Therefore, we leverage PointNet++ and attention layers to effectively incorporate relevant structural features into the learned representations.

Best,
Jiaxin

Thanks @Jiaxin-Lu for the thorough response.
For the moment I do not have any further inquiries, thus I am looking forward to the release of the code.


Biomes and terrain

load main scene
press play see trees and terrain in scene

Closes #34 and #35


[5.3][stdlib] Add _forEachField(of:options:body:) function (#32873)

This function walks all the fields of a struct, class, or tuple, and calls
body with the name, offset, and type of each field. body can perform
any required work or validation, returning true to continue walking fields
or false to stop immediately.
(cherry picked from #32873)

@swift-ci test

The Windows failure looks to be https://github.com/apple/swift/pull/32898; I've cherry picked that here, too.

@swift-ci test

Build failed
Swift Test Linux Platform
Git Sha - 3aa05d7286f7e7f42dba1e4f226e72a60a0c7814

Build failed
Swift Test OS X Platform
Git Sha - 3aa05d7286f7e7f42dba1e4f226e72a60a0c7814

Build failed
Swift Test OS X Platform
Git Sha - 3aa05d7286f7e7f42dba1e4f226e72a60a0c7814

@swift-ci test linux platform


Update callback_phishing_intuit.yml

Updated Version of #1699
Description
Make Attachment Logic all happen within the same file.explode().scan result
Add logic for callback detail in "bill to" section without any brands detected
Remove bank statement negations
Associated samples

Sample 1

Associated hunts

Hunt 1

/update-test-rules


Nmaynard/legacy ids

This adds the legacy_id column to the hostGenomes and the workflow_runs tables.
See the linkml edits commit for the changes that I made. The rest of the commits are codegen/migrations.
There are some old linkml changes that didn't have their associated migration changes commit in the workflows previously that this alembic migration generation picked up. I guess it's not so bad to have this PR do that catchup as well?

Looks good, though can you undo the change of ports in docker-compose.yml or is that needed? Migrations look good. You'll need to run make fix-lint in both entities/ and workflows/ to fix the lint errors

I meant to leave a note about exposing the port. The workflows db exposes a port and I have been exposing the port on entities db to be able to connect from a db manager (e.g. pgadmin). I figured I would commit it so that it's easier for others to do the same.

Ah I see, got it


Natural Gas Well Production [PYTHON]

App name
dash-oil-and-gas
App

[x] This app is currently deployed on Dash Gallery: https://dash-gallery.plotly.host/dash-oil-and-gas/
[ ] This app is new

Source code repository
https://github.com/plotly/dash-oil-and-gas-demo
Current appearance

Redesign
Link: https://github.com/plotly/streambed/issues/12068#issuecomment-451038434

Link: https://github.com/plotly/streambed/issues/12879#issuecomment-483724642

Playground deployment
[url of playground deployment]

oil & gas.zip

Note on the mobile layout - we're keeping this with a light theme instead of a dark theme.

Note on the mobile layout - we're changing this to have a light theme instead of a dark theme.

Is there a mock up of the mobile layout with the light theme?

Note on the mobile layout - we're changing this to have a light theme instead of a dark theme.

Is there a light theme mobile mockup for me to look at? @angeladaodao

Okay, I will give you a light colour palette for this app