Make --all-packages the default?

When setting up a uv workspace in a monorepo, I was surprised to find that uv sync would change which packages were installed depending on which directory I ran it from. For example:

it removed all my transitive dev dependencies when run from the root directory
when run within a sub-package, it removed dependencies (required and dev) for all other packages!

Overall, it's confusing that the behavior of uv sync changes depending on where you run it from within a workspace that just has one shared environment.
Without --all-packages, uv sync seems to behave as though the virtual environment belongs only to whichever package you're currently in—which would make sense in non-workspace mode, where each package has its own environment. But in a workspace, the environment is shared between all members, so it feels odd for each member to trample on this shared resource by default.
Some specific repros
You can recreate these with https://github.com/gjoseph92/uv-monorepro
The transitive dev dependencies aren't available in the base workspace (I'd expect py-spy and pip to be here):
uv-monorepro main*(uv-monorepro) ❯ uv tree
Resolved 15 packages in 2ms
uv-monorepro v0.1.0
├── needs-things v0.1.0
│   ├── thing1 v0.1.0
│   │   ├── cowsay v6.1
│   │   └── py-spy v0.4.0 (group: dev)
│   └── thing2 v0.1.0
│       ├── trio v0.27.0
│       │   ├── attrs v24.2.0
│       │   ├── idna v3.10
│       │   ├── outcome v1.3.0.post0
│       │   │   └── attrs v24.2.0
│       │   ├── sniffio v1.3.1
│       │   └── sortedcontainers v2.4.0
│       └── pip v24.3.1 (group: dev)
└── thing1 v0.1.0 (*)
(*) Package tree already displayed
uv-monorepro main*(uv-monorepro) ❯ which pip
pip not found

If I go into a subpackage, uv sync uninstalls the required dependency (cowsay) of my other subpackage (because it's not a dependency of this subpackage):
uv-monorepro main*(uv-monorepro) ❯ cd packages/thing2
uv-monorepro/packages/thing2 main*(uv-monorepro) ❯ uv sync
Resolved 15 packages in 2ms
Uninstalled 1 package in 8ms
Installed 1 package in 9ms
 - cowsay==6.1
 + pip==24.3.1
uv-monorepro/packages/thing2 main*(uv-monorepro) ❯ which pip
/Users/gjoseph/scratch/uv-monorepro/.venv/bin/pip

Going to the other subpackage does the inverse:
uv-monorepro/packages/thing2 main*(uv-monorepro) ❯ cd ../thing1
uv-monorepro/packages/thing1 main*(uv-monorepro) ❯ uv sync
Resolved 15 packages in 1ms
Uninstalled 7 packages in 97ms
Installed 2 packages in 2ms
 - attrs==24.2.0
 + cowsay==6.1
 - idna==3.10
 - outcome==1.3.0.post0
 - pip==24.3.1
 + py-spy==0.4.0
 - sniffio==1.3.1
 - sortedcontainers==2.4.0
 - trio==0.27.0
uv-monorepro/packages/thing1 main*(uv-monorepro) ❯ which pip
pip not found

Back in the root workspace, uv sync again does install the necessary dependencies for the subpackages, but not their dev dependencies (py-spy and pip are both gone now). Given that the docs say the dev group is included by default, I would have expected and wanted all the dev dependencies of member packages to be installed too.
uv-monorepro/packages/thing1 main*(uv-monorepro) ❯ cd ../..
uv-monorepro main*(uv-monorepro) ❯ uv sync
Resolved 15 packages in 2ms
Uninstalled 1 package in 3ms
Installed 6 packages in 5ms
 + attrs==24.2.0
 + idna==3.10
 + outcome==1.3.0.post0
 - py-spy==0.4.0
 + sniffio==1.3.1
 + sortedcontainers==2.4.0
 + trio==0.27.0
uv-monorepro main*(uv-monorepro) ❯ which pip
pip not found

--all-packages gets the behavior I want. And most importantly, it always results in the same things being installed no matter which directory I run it from.
uv-monorepro main*(uv-monorepro) ❯ uv sync --all-packages
Resolved 15 packages in 2ms
Installed 2 packages in 8ms
 + pip==24.3.1
 + py-spy==0.4.0
uv-monorepro main*(uv-monorepro) ❯ which pip
/Users/gjoseph/scratch/uv-monorepro/.venv/bin/pip

I couldn't find other issues requesting this, but apologies if this is a dupe. Maybe somewhat related to https://github.com/astral-sh/uv/issues/9261?

I think we're somewhat unlikely to change this... I hear your confusion but it may just be a learning curve that comes from working with the workspace concept? Cargo, for example, behaves the same way: the workspace root is a member, just like any other, and by default cargo run uses the current directory which can be overridden with -p.
In our case, uv sync always does a strict sync. You can use uv sync --inexact if you only want to make the minimal changes necessary to include all dependencies for the current workspace member. (uv run uses these "inexact" semantics by default.)

But in a workspace, the environment is shared between all members, so it feels odd for each member to trample on this shared resource by default.

Well... I think this isn't quite true. You can have members within a workspace that don't depend on any other members. Those members should declare all the direct dependencies that they need. In that case, running uv sync and removing dependencies of other members is totally right.


AngularJS Docs Website is down

It's trying to load from Google's library with a null version id
https://ajax.googleapis.com/ajax/libs/angularjs/null/angular-resource.min.js

Right, we are aware, working on the fix. Thnx for reporting.

Sorry about that. Opening up 1.5.x branch for development messed up the latest docs site. It should be back up now.

Cool! Thanks

https://docs.angularjs.org/guide/directive
Docs site down again?

@allisondeluca - It doesn't look down to me. What are you seeing?


Allow eslint@6 peer

Allow eslint 5 or 6 as a peer dependency

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Split Vagrant provision into bootstrap and app

Also, provide a helpful message when app is running

This is better than what we currently have, but I think that "add project" may still be broken.


Multiple definitions when including Stan headers in several source files

Summary:
Stan headers cause multiple definition errors when included in several source files that are linked together in a library.
Description:
If the Stan headers are included in several source files that are compiled separately and then linked, the compiler fails with multiple definition errors.  I am a C++ novice, but I believe this is because non-inline functions are being instantiated in the header files (e.g. print_mat_size).
Reproducible Steps:
A minimal example to reproduce can be found in this repo.  In short, it has two cpp files that each instantiate templates using Stan variables.  They can be successfully compiled into object files, but the linker fails with multiple definition errors.
// source1.hpp:
# ifndef SOURCE1_H
# define SOURCE1_H

#include <boost/math/special_functions/digamma.hpp>
#include <boost/math/special_functions/gamma.hpp>

using boost::math::lgamma;
using boost::math::digamma;

# include <stan/math.hpp>
# include "stan/math/fwd/scal.hpp"

using var = stan::math::var;
using fvar = stan::math::fvar<var>;

template <typename T> T multivariate_lgamma(T x, int p) {
  T result = log(M_PI) * p * (p - 1.0) / 4.0;
  for (int i = 1; i <= p; i++) {
    result += lgamma(x + 0.5 * (1 - (double)i));
  }
  return result;
}

extern template double multivariate_lgamma(double x, int p);
extern template var multivariate_lgamma(var x, int p);
extern template fvar multivariate_lgamma(fvar x, int p);

# endif

// source1.cpp:
# include "source1.hpp"
# include <stan/math.hpp>
# include <stan/math/fwd/scal.hpp>

using var = stan::math::var;
using fvar = stan::math::fvar<var>;

template double multivariate_lgamma(double x, int p);
template var multivariate_lgamma(var x, int p);
template fvar multivariate_lgamma(fvar x, int p);

// source1.hpp:
# ifndef SOURCE2_H
# define SOURCE2_H

#include <boost/math/special_functions/digamma.hpp>
#include <boost/math/special_functions/gamma.hpp>

using boost::math::lgamma;
using boost::math::digamma;

# include <stan/math.hpp>
# include "stan/math/fwd/scal.hpp"

using var = stan::math::var;
using fvar = stan::math::fvar<var>;

template <typename T> T multivariate_digamma(T x, int p) {
  T result = 0.0;
  for (int i = 1; i <= p; i++) {
    result += digamma(x + 0.5 * (1 - (double)i));
  }
  return result;
}

extern template double multivariate_digamma(double x, int p);
extern template var multivariate_digamma(var x, int p);
extern template fvar multivariate_digamma(fvar x, int p);

# endif

// source2.cpp:
# include "source2.hpp"
# include <stan/math.hpp>
# include <stan/math/fwd/scal.hpp>

using var = stan::math::var;
using fvar = stan::math::fvar<var>;

template double multivariate_digamma(double x, int p);
template var multivariate_digamma(var x, int p);
template fvar multivariate_digamma(fvar x, int p);

Current Output:
The linker fails with errors like this:
[ 33%] Building CXX object CMakeFiles/StanHeaderExample.dir/source2.cpp.o
Linking CXX shared library libStanHeaderExample.so
CMakeFiles/StanHeaderExample.dir/source2.cpp.o: In function `stan::math::print_mat_size(int, std::ostream&)':
source2.cpp:(.text+0x1390): multiple definition of `stan::math::print_mat_size(int, std::ostream&)'
CMakeFiles/StanHeaderExample.dir/source1.cpp.o:source1.cpp:(.text+0x12c0): first defined here
CMakeFiles/StanHeaderExample.dir/source2.cpp.o: In function `stan::math::csr_u_to_z(std::vector<int, std::allocator<int> > const&, int)':
source2.cpp:(.text+0x13c0): multiple definition of `stan::math::csr_u_to_z(std::vector<int, std::allocator<int> > const&, int)'
CMakeFiles/StanHeaderExample.dir/source1.cpp.o:source1.cpp:(.text+0x12f0): first defined here
... and so on.

Expected Output:
A compiled shared library with templates instantiated with Stan types.
Additional Information:
Provide any additional information here.
Current Version:
v2.9.0

I'm afraid you're not going to be able to do what you're trying to do.  The problem is that all the includes include also statics and other non-inline functions, so they can't have multiple definitions.  I don't think this is something we can fix.

Again, I'm a little new to C++, but isn't it unusual to put function definitions in header files like this?  It seems to me that this problem really limits the usefulness of this library.  (Unless there is a work-around, I think it would be a deal-breaker for me, since it significantly drives up compile times for complex models.)
Why can't the functions be inlined?  Most of the ones are giving errors in this example were quite small.

That’s conventual for much of C++ but things get dramatically more
complicated with the introduction of templates, not to mention the
global memory we need for implementing automatic differentiation.
The long compilation times are a serious concern, but at the moment
there aren’t many solutions that don’t resort to having gigantic shared
objects that would introduce their own serious problems.
On Jun 30, 2016, at 3:27 PM, Ryan<EMAIL_ADDRESS>wrote:

Again, I'm a little new to C++, but isn't it unusual to put function definitions in header files like this? It seems to me that this problem really limits the usefulness of this library. (Unless there is a work-around, I think it would be a deal-breaker for me, since it significantly drives up compile times for complex models.)
Why can't the functions be inlined? Most of the ones are giving errors in this example were quite small.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

The problem with multiple includes seems to be tiny little functions like this one:
    int csr_u_to_z(const std::vector<int>& u, int i) {
      check_positive("csr_u_to_z", "u.size()", u.size());
      check_range("csr_u_to_z", "i", u.size(), i + 1, "index out of range");
      return u[i + 1] - u[i];
    }

If one were to compile these functions separately or inline them, would it really result in such a bloated shared library?  Or is there a different problem that I don't see?
For some context, I should explain why this is important.  I routinely perform inference on models composed of a small number of types of random variables.  I'd like to build a library with these distributions and use Stan's autodifferentiation to optimize these models as well as compute derivatives for sensitivity analysis in many different contexts (e.g. this one, and many more if I can get around this difficulty).  As-is, because I cannot pre-instantiate instances of my templates with Stan types in a shared library, I have to wait minutes each time I change a single line of code (e.g. tweak a unit test).  It's grown quite unusable.
In other words, for my own projects I'd be happy to trade bloated shared libraries for faster compile time, but because of a small number of tiny functions in the Stan headers I don't have the option.  It seems to me that Stan the modeling language and I could make different decisions about this tradeoff if only the header files were true header files without function definitions.

It'd be nice if it were just non-templated functions, but
the problem is that you can't have two instantiations of
the same function.
We could break things down into header, definition, and
instantiation, and that could work in most cases.  We did
that where necessary with the grammars to work around Windows
compilation limits.  But it's a lot of work with no payoff in
our use cases.
Instead, we've gone the with the standard header-only library
pattern for heavily templated libraries.  It's the same
organization you see in Boost and Eigen.
When we say bloated shared libraries, we mean really bloated.
As in perhaps terabytes if we di the whole thing.
There are something like 10K instantiations just of the
univariate student-T function!

Bob

On Jun 30, 2016, at 8:32 AM, Ryan<EMAIL_ADDRESS>wrote:
The problem with multiple includes seems to be tiny little functions like this one:
int csr_u_to_z(const std::vector<int>& u, int i) {
  check_positive("csr_u_to_z", "u.size()", u.size());
  check_range("csr_u_to_z", "i", u.size(), i + 1, "index out of range");
  return u[i + 1] - u[i];
}

If one were to compile these functions separately or inline them, would it really result in such a bloated shared library? Or is there a different problem that I don't see?
For some context, I should explain why this is important. I routinely perform inference on models composed of a small number of types of random variables. I'd like to build a library with these distributions and use Stan's autodifferentiation to optimize these models as well as compute derivatives for sensitivity analysis in many different contexts (e.g. this one, and many more if I can get around this difficulty). As-is, because I cannot pre-instantiate instances of my templates with Stan types in a shared library, I have to wait minutes each time I change a single line of code (e.g. tweak a unit test). It's grown quite unusable.
In other words, for my own projects I'd be happy to trade bloated shared libraries for faster compile time, but because of a small number of tiny functions in the Stan headers I don't have the option. It seems to me that Stan the modeling language and I could make different decisions about this tradeoff if only the header files were true header files without function definitions.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

I think there's some miscommunication -- I'm sorry if it's on my part.
Other header-only libraries (e.g. Eigen) do not have the problem that I'm describing in Stan.  I can do something like
First source file:
// source1.cpp
# include <Eigen/Dense>

Eigen::VectorXd MyFun() {
  ... stuff ...
}

Second source file:
// source2.cpp
# include <Eigen/Dense>

Eigen::VectorXd MyOtherFun() {
  ... stuff ...
}

I can then link both to source1.o and source2.o without errors.  This is because Eigen is really header-only -- its headers contain only templates and definitions.  I cannot do this in Stan (per the above example, for instance).
I'm not suggesting that you guys should instantiate all the Stan functions in your library.  My problem is that, in my project which uses Stan, I don't have the option to instantiate them in a shared library.  And the reason I can't do that has nothing to do with the size of the Stan objects, but only because there are these tiny non-templated functions like print_mat_size that are instantiated in the Stan headers preventing me from including the Stan headers in more than one translation unit.
Does this make sense?  Again, I'm sorry if I'm missing some basic point.

A similar issue has been reported previously in stan issue #1149.  I'm not sure why it was closed -- maybe for inactivity.
To clarify, I've made a simpler example (also in the same repo linked to earlier).  Here it is:
source1.cpp:
# include <stan/math.hpp>
stan::math::var Function1() {
  return 0;
}

source2.cpp:
# include <stan/math.hpp>
stan::math::var Function2() {
  return 0;
}

These two files cannot be linked without multiple definition errors (unlike other header-only libraries like Eigen).
To further clarify, the linline branch of my fork fixes the problem (at least for this simple example).  I'm not really asserting that inlining is the answer, but I'm trying to be clear about what the problem is.

Yeah, we had this linker problem with rstanarm (with log_sum_exp IIRC). The only solution I could come up with was to concatenate all the C++ files into one file and compile that.

@bgoodri , up to now that is what I've been doing, too, though with moderately complex projects the compile times have become prohibitively long.

Even in the best case scenario, the compile times are going to be long. But
if we sort this issue out, the C++ files can be compiled in parallel,
possibly at the expense of a lot more memory consumed.
On Sat, Jul 2, 2016 at 6:56 PM, Ryan<EMAIL_ADDRESS>wrote:

@bgoodri https://github.com/bgoodri , up to now that is what I've been
doing, too, though with moderately complex projects the compile times have
become prohibitively long.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/issues/311#issuecomment-230125983, or mute
the thread
https://github.com/notifications/unsubscribe/ADOrqvrzYE2U9Jy1ykFF4u8o_m-6WwMyks5qRuyAgaJpZM4JBjyo
.

Yes.  Also, at least in my case, I could solve my compile time problems by pre-compiling the relatively limited functionality that I need into a shared library.

I think the right general solution is to do what we did
with the grammars:
pure header:    foo.hpp
definition:     foo_def.hpp
instantiation:  foo_inst.cpp
We can do that with most of our library and it'll allow
use as header-only through foo_def.hpp, or as a shared
object by including foo.hpp and linking foo_inst.cpp.
The problem is that foo_inst.cpp changes per instantiation,
and in many of our probability function classes, there are
just too many to preinstantiate.

I wouldn't mind at all if someone refactored all the code
into this pattern.  It's a lot of work!

Bob

On Jul 2, 2016, at 4:51 PM, Ryan<EMAIL_ADDRESS>wrote:
Yes. Also, at least in my case, I could solve my compile time problems by pre-compiling the relatively limited functionality that I need into a shared library.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

@bob-carpenter , that does seem like it would be a lot of work.  But why does all the code have to be rewritten?  Things are mostly fine left as templates and inlines, it seems to me that a few small functions were forgotten.  For example, why can't the following function (and other similarly small functions) be inlined?
    double abs(double x) {
      return std::fabs(x);
    }

There are some exceptions that are longer, like log_sum_exp for vectors of doubles which takes thirteen lines, or cholesky_decompose for matrices of var which is pretty long.  Maybe those could go in a separate cpp files if you think they're too big to inline.  But that's much less work than a re-organization of the entire project.

Is every function and template function declared inline
in Eigen?  Isn't it an error to instantiate the same
template function in two different translation units unless
it's declared inline?
I'd be OK inlining everything if it doesn't increase our
compilation time, generate larger object files, or slow down
run time.

Bob

On Jul 4, 2016, at 1:47 PM, Ryan<EMAIL_ADDRESS>wrote:
@bob-carpenter , that does seem like it would be a lot of work. But why does all the code have to be rewritten? Things are mostly fine left as templates and inlines, it seems to me that a few small functions were forgotten. For example, why can't the following function (and other similarly small functions) be inlined?
double abs(double x) {
  return std::fabs(x);
}

There are some exceptions that are longer, like log_sum_exp for vectors of doubles which takes thirteen lines, or cholesky_decompose for matrices of var which is pretty long. Maybe those could go in a separate cpp files if you think they're too big to inline. But that's much less work than a re-organization of the entire project.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Is every function and template function declared inline in Eigen?

No, the Eigen headers only define templates and their implementations.  AFAIK, they do not instantiate anything.  If they did, you could not include Eigen headers in multiple translation units.

Isn't it an error to instantiate the same template function in two different translation units unless
it's declared inline?

Yes, it is an error to instantiate the same template function in two different translation units unless it is declared inline.  However, you can define a template function and its implementation in headers that are included in several translation units as long as they are not instantiated.  E.g.
Ok for headers (definition but not instantiation):
template <typename T> T MyFunc(T foo) {
  ... do things with foo ...
}

Not ok for headers (instantiation):
template double MyFunc(double);

Also not ok for headers:
double MyFunc(double x) {
...
}

But this is ok for headers:
inline double MyFunc(double x) {
...
}

Did you take a look at my branch?  It might clarify things.
Can you point me to a benchmark that you all use for measuring compile time changes?

Thanks.  That's how I thought things worked and didn't
imagine the use case you have (multiple translation units,
each of which instantiates different translates).
So we should definitely work on this as it shouldn't hurt
anything unless we get a lot of code bloat.
Or we can start being better behaved with our non-templated
functions and pull them into proper header files with
properly compiled versions.  That should just be a win overall
for compile time.
We don't have benchmarks for compilation.  We just look
at wall time using -j4 on our Mac or Linux notebooks.  It'd
be great to do this more methodically, but not a requirement
for anything.

Bob

On Jul 4, 2016, at 2:46 PM, Ryan<EMAIL_ADDRESS>wrote:
Is every function and template function declared inline in Eigen?
No, the Eigen headers only define templates and their implementations. AFAIK, they do not instantiate anything. If they did, you could not include Eigen headers in multiple translation units.
Isn't it an error to instantiate the same template function in two different translation units unless
it's declared inline?
Yes, it is an error to instantiate the same template function in two different translation units unless it is declared inline. However, you can define a template function and its implementation in headers that are included in several translation units as long as they are not instantiated. E.g.
Ok for headers (definition but not instantiation):
template  T MyFunc(T foo) {
... do things with foo ...
}
Not ok for headers (instantiation):
template double MyFunc(double);
Also not ok for headers:
double MyFunc(double x) {
...
}
But this is ok for headers:
inline double MyFunc(double x) {
...
}
Did you take a look at my branch? It might clarify things.
Can you point me to a benchmark that you all use for measuring compile time changes?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Can you try it after adding --allow-multiple-definition  to CXXFLAGS?

@bgoodri , can you elaborate a little on what you have in mind?  I don't see a --allow-multiple-definition option in gcc or clang.  Besides, I think it's better style to simple not multiply define functions across translation units.

I meant LDFLAGS as it is a linker option
http://linux.die.net/man/1/ld
I don't think designing the Stan library correctly is in the cards.

Why do you say it's not in the cards?  Do you have any objection to PR 313, which fixes this problem?

That PR is fine I guess. I was referring to splitting up the header files into def and inst.

Yes.  I think it is not actually necessary to split header files into def and inst.


Make --help the default command

Shows the help menu when a command is missing. Simples

:+1:

Yay :smile:


stream depth data over network (UDP)

Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):

Consider checking out SDK examples.
Have you looked in our documentations?
Is you question a frequently asked one?
Try searching our GitHub Issues (open and closed) for a similar issue.

All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)

Required Info

Camera Model
{ R200 / F200 / SR300 / ZR300 / D400 }

Firmware Version
(Open RealSense Viewer --> Click info)

Operating System & Version
{Win (8.1/10) / Linux (Ubuntu 14/16/17) / MacOS

Kernel Version (Linux Only)
(e.g. 4.14.13)

Platform
PC/Raspberry Pi/ NVIDIA Jetson / etc..

SDK Version
{ legacy / 2.. }

Language
{C/C#/labview/nodejs/opencv/pcl/python/unity }

Segment
{Robot/Smartphone/VR/AR/others }

Issue Description
<Describe your issue / question / feature request / etc..>
I am trying to figure out how to use gstreamer to stream 16bit depth data over the network. It doesn't have to be real-time as I realized the network bandwidth is just not enough for this huge amount of data. It just have to be as quick as it possibly can. I was also advised that saving it to a png image might provide some compression so my plan is first converting 16bit depth image to png and then stream it over UDP.
I'd like ask if this functionality has been developed and if not, I'd like to get some suggestions on my way of streaming the depth data.

@TimConnelly recently highlighted a new gstreamer plugin for RealSense that has been tested by its developers with a RealSense D435i camera.
https://github.com/IntelRealSense/librealsense/issues/2503#issuecomment-613653125
There was also a recently published Intel white-paper document on depth image compression by colorization.
https://dev.intelrealsense.com/docs/depth-image-compression-by-colorization-for-intel-realsense-depth-cameras
Additionally, a new 'Z16H' compressed depth format was introduced to the Librealsense SDK in SDK 2.32.1, though I believe that it is awaiting additional support to be added to the camera firmware driver before it is usable.
https://github.com/IntelRealSense/librealsense/pull/5564

Hi @MartyG-RealSense ,  Thanks for your detailed response. I will try out the method mentioned in the white-paper document.

@johnny-wang16   You're very welcome.   Good luck!

For anyone who's looking for a simple solution to stream both RGB and depth data simultaneously over the network, I wrote some scripts that  does exactly this using the approach suggested above. Here's the link to my repo: https://github.com/johnny-wang16/rs-udpstreaming.git

@johnny-wang16    Thanks so much for sharing your solution!  :)

Hi again @johnny-wang16   Do you require further assistance with this case please, or can it be closed?  Thanks!

I think its ready to be closed. Thank you very much.

Hello @MartyG-RealSense  ,I'd just want to point out that there are some typo in the Intel white-paper document on depth image compression by colorization you mentioned above. All of them are in section 3.2 Depth image recovery from colorized depth images in C++. I'd also like to ask some questions about the code.
I attached the part of code that has some typo here:
		unsigned char R = *in++;
		unsigned char G = *in++;
		unsigned char B = *in++;

		unsigned short hue_value = RGBtoD(R, G, B);

		if(out_value > 0)
		{
			if(!is_disparity)
			{
				unsigned short z_value = static_cast<unsigned short>((min_depth + (max_depth - min_depth) * hue_value / 1529.0f) + 0.5f);
				out++ = z_value;
			}
			else
			{
				float disp_value = min_disparity + (max_disparity - min_disparity) * out_value / 1529.0f;
				*out++ = static_cast<unsigned short>((1.0f / disp_value) / depth_units + 0.5f);
			}
		}
		else
		{
			*out++ = 0;
		}

Firstly, I highly suspect that the out_value in the if statement is actually hue_value as out_value variable is never initialized in this stand alone script. In addition, the depth_unitis variable is also never initialized.
There's also some inconsistency between the code and the formula mentioned in the paper. Mainly, why is it that in both cases of the  if(!is_disparity) statement, there's a + 0.5f ? Is it just simply calibration?  Thank you very much.

@johnny-wang16  I do not have knowledge of how the depth colorization technique in the white paper works, unfortunately.
@dorodnic  Do you have advice please for @johnny-wang16 regarding the questions in the comment above?

Hello there, after I re-read the document , I am pretty sure those are just typos and the way to correct them is what I mentioned above. the 0.5f is just probably calibration.

@johnny-wang16  Thanks very much for the update.

Were you actually able to recalculate the depth values from the colorized image (hue colorizer)? I am not able to reconstruct the same depth values (also by taking into account the typos mentioned by @johnny-wang16 ). Moreover I had a look at https://github.com/TetsuriSonoda/rs-colorize/tree/development , where the equations look slightly different but still were not successful.
My idea was to colorize the 16 bit grayscale image to RGB image with 8 bit per channel and encode this with the e.g. H264 codec. Afterwards one could reconstruct the depth values by knowing min_distance and max_distance

I was able to recalculate the pixel value. its just that im not using it at the moment so I didnt include it. I can update it on my github and  you can test it.

That would be great!

@nicocarl   sorry i didnt read your comment clearly. I have the script for reconstructing depth pixel values but I haven't actually tried it. I will upload it later and you can try it out and let me know if it works or not. I'd expect the result wouldn't fit the original depth value perfectly as the depth pixels have been transformed and compressed


feat: add gitextractor dashboard

Summary
Add a dashboard displaying the metrics by gitextractor plugin

Does this close any open issues?
related to #1771
Screenshots

Other Information
Any other information that is important to this PR.

Thanks for submitting a pull request.
@Startrekzky can you help to review it?


Updated httpoison to version 0.9

Not a necessary update but removes annoying warnings under elixir 1.3

Thanks!


Documentation - layout issue on layout -> header

header

That's intentional because the header takes up the whole width of the window.


Busy spinner failing to render on InputBox, QuickInput, QuickPick controls

VS Code Version: 1.44
OS Version: Windows 10

Steps to Reproduce:

Clone https://github.com/microsoft/vscode-extension-samples/tree/main/quickinput-sample
Load and Debug Project
View -> Command Palette -> Quick Input Samples -> Click 'multiStepInput'
Click any resource group
Type unique name for application service and press enter key
Expect busy spinner to show in InputBox

This appears to be a regression in Version 1.44 as this was not an issue in Version 1.43.  See links below for further details.
Affected APIs
https://code.visualstudio.com/api/references/vscode-api#InputBox
https://code.visualstudio.com/api/references/vscode-api#QuickInput
https://code.visualstudio.com/api/references/vscode-api#QuickPick<T>
Demonstration showing 1.43 did not have this issue
https://code.visualstudio.com/updates/v1_43
https://recordit.co/UAakJ0p5xy
Demonstration showing 1.44 regressed
https://code.visualstudio.com/updates/v1_44
https://recordit.co/5AwTbjkPsx

@kirksl 1.44 is pretty old... did you try this in a more recent version of vscode? We're at 1.58 already.

@TylerLeonhardt Hello.  We were able to reproduce this issue on all versions of VSCode starting from 1.44 all the way to 1.58.

I'm having the same issue on 1.60-insiders. InputBox is not showing the loading state.
Version: 1.60.0-insider (Universal)
Commit: 7c25c174726ab969db3f99058cdf24bcfae1cfbe
Date: 2021-08-11T05:13:17.497Z
Electron: 13.1.8
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Darwin x64 20.5.0

Same here:
Version: 1.68.1
Commit: 30d9c6cd9483b2cc586687151bcbcd635f373630
Date: 2022-06-15T02:58:26.441Z
Electron: 17.4.7
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.13.0-39-generic snap

Still an issue.
Version: 1.74.3 (user setup)
Commit: 97dec172d3256f8ca4bfb2143f3f76b503ca0534
Date: 2023-01-09T16:59:02.252Z
Electron: 19.1.8
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.22621
Sandboxed: No

Some work around the spinner has been done recently. Can you try in the Insiders Build?
If it still doesn't work, can you attach a gif? Like with https://gifcap.dev/

I was a bit to quick, the spinner in QuickPick is working fine.


🤫 Support silent holes, closing #86

Is there any way to detect when you have left a silent hole? (like “5 remaining holes”)

Are you suggesting a way to count the holes? If so, should the counting include all holes (not just the silent ones)?
If all the holes should be included, I feel this might belong to another PR. We would have to change the state monad.

@favonia I realize these are in principle separable features, but I think it is very dangerous to have silent holes that do not give any indication to the user that the development is incomplete. In redtt for instance, I believe there was some indication that the development was incomplete.
Anyway, I am not picky about how this is achieved, but I think we should not add silent holes without having some kind of indication.

Anyway, I am not picky about how this is achieved, but I think we should not add silent holes without having some kind of indication.

I have a question whose answer could speed up my coding significantly: is the problem field in RefineEnv the holes? And, I suppose it's enough to print out the size of that field?
https://github.com/RedPRL/cooltt/blob/96e92686b16f7b8b15ece3c745265485b788e513/src/core/RefineEnv.ml#L27-L42

Anyway, I am not picky about how this is achieved, but I think we should not add silent holes without having some kind of indication.

I have a question whose answer could speed up my coding significantly: is the problem field in RefineEnv the holes? And, I suppose it's enough to print out the size of that field?
https://github.com/RedPRL/cooltt/blob/96e92686b16f7b8b15ece3c745265485b788e513/src/core/RefineEnv.ml#L27-L42

No, the problem field is more of a namespace for holes so you can see where some hole came from. I intended it for when elaborating pattern matching or something, but never got around to really using it in a useful way. (Wouldn't mind if someone wanted to delete it.)

No, the problem field is more of a namespace for holes so you can see where some hole came from. I intended it for when elaborating pattern matching or something, but never got around to really using it in a useful way. (Wouldn't mind if someone wanted to delete it.)

OMG this is so misleading LOL. Perhaps we should clean up this before importing Big Thoughts.


Finalize API v2 specification along with the new requirements

Description
The ask is to prepare new schema for new improved API v2.
List of endpoints required for now (spec is still in progress):

current head layer number and nodeID hash

known chain head block/layer
current highest layer
sync status (in sync, syncing, offline)

detail of given layer by layer number

empty layer, or return single canonical block with:

block header/block ID
list of transactions (effective and ineffective, possibly with option to filter effective only)

account details by address

current balance and counter
projected balance and counter

broadcast raw, signed tx

return txid

tx by txid

state (unknown, pending, contextually invalid/malformed, duplicate, ineffective/contextually invalid, in mempool, included in block, passed hare, passed tortoise/verified, reorg'ed out/replaced)
gas consumed
execution success/failure (receipt)
tx type

single sig spend
multi sig spend
single sig spawn
multi sig spawn

principal
parsed contents

amount
recipient

gas estimation

recommended maxGas per tx type

Here are the list of APIs required by Wallet application:
Network-specific data

Node info: node/nodeinfo
To get a proper HRP,
First genesis layer & epoch size for timestamps
GenesisTime: mesh/genesistime
To calculate timestamps
LayerDuration: mesh/layerduration
To calculate timestamps

Node status:

Node status: node/status
To ensure that Node is synced & can publish txs

User data:

Balance: globalstate/accountdataquery (can be replaced with globalstate/account)
Txs:

Tx data: mesh/accountmeshdataquery
Tx states: transaction/transactionsstate

Rewards: globalstate/accountdataquery

Publishing txs:

Gas estimation: transaction/parsetransaction
Funny thing that it may parse TX without a signature, but then it will estimate the wrong gas amount, like it may be published without a signature. So if you don't have a signature yet — put there 64 zero-bytes and verify: false :)
This statement is valid for gRPC as well.
Submit: transaction/submittransaction

All of them already exist and should work via JSON RPC (I haven't tested all of them yet).
So I'm using them now, and propose to focus on endpoints that consume too much resources or are unsafe.

Done

Activation service: https://github.com/spacemeshos/api/pull/305
Reward service: https://github.com/spacemeshos/api/pull/307
Network service: https://github.com/spacemeshos/api/pull/315

In progress:

Node service: https://github.com/spacemeshos/api/pull/316
Layer and block service: https://github.com/spacemeshos/api/pull/319

Pending

Account service
Layer and block service
Account service
Transaction service

API is implemented and exposed on https://mainnet-api-docs.spacemesh.network/index.html


Long Polling workers do not reconnect if broker goes away then comes back

During Kubernetes node pre-emption, I've observed workers failing to reconnect.
I'd say that somewhere in the long-polling loop is a condition that does not trigger the poll retry in this scenario.
Fixing this will involve setting up - at least local - tests where the broker is bounced. This will be more challenging to simulate in CI, but should not be a blocker for this fix, because it is a critical production failure.

Watching my systems in Camunda Cloud, they do seem to reconnect after some time, so it may be the exponential back-off retry causing a delay after the cluster recovers.

I experience the same, when I connect a Node-RED worker node to Camunda Cloud (stage environent). Sometimes   they're disconnected for minutes, but eventually get reconnected.

This seems to happen when the cluster pods are rescheduled, and the reconnection backs-off. Maybe a switch for aggressive retry?

Some of these scenarios will be dealt with via #96

I can confirm, that https://github.com/creditsenseau/zeebe-client-node-js/issues/96 fixes my issue

It looks like the issue is a combination of two things: the issue fixed in #96, and Camunda Cloud terminating the gRPC connection to nginx after 60s. That caused clients with >59s long-polling periods to encounter the issue fixed in #96 if they did not receive any jobs within 60s.
Closing for now. Reopen if it appears again.


Is it possible to externally charge battery while connected?

I would like to use the same 3.7V Li-ion battery to power the T-Embed and another microcontroller with its own charging circuit. I want to make sure that when charging the battery from the second microcontroller I will not damage the T-Embed. I imagine this will work okay since typically the charging voltage should be around the max battery voltage (4.2V) but I cannot find any information on the charging IC mentioned in the schematics (TP4065B). Can you confirm that this is possible?

http://www.szyucan.com/upfile/IC-PDF/TP4065.pdf
I don't understand your connection method, this is the manual, unfortunately only in Chinese.


opencv: enable videoio on darwin

Motivation for this change
Fixes https://github.com/NixOS/nixpkgs/issues/97575
cc: @jeff-hykin @mjlbach
Things done

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

[X] NixOS
[X] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

@jeff-hykin Can you test? I don't use this functionality.

Yeah, I'm happy too. I might need to wait till next week since I'm got deadlines atm.
The bigger barrier might be, I'm not sure how point nix towards a specific branch/commit. So advice on that would be appreciated, but I can probably figure it out with the docs if needed. I have to learn it anyways for a separate nix issue.

I'll need python37 to test with it. e.g. nix-shell -I nixpkgs=./nixpkgs -p opencv4 isn't enough for me to test. Copying from my shell.nix, I tried nix-shell -I nixpkgs=./nixpkgs -p python37.opencv4 but that failed so I'm going to have to spend more time on it another day.
nix-shell -I nixpkgs=./nixpkgs -p opencv4 did compile opencv for me on Sierra without errors though

@jeff-hykin There are a lot of ways to test this PR. You might want to look into nixpkgs-review
cd to your local checkout of nixpkgs, and run the following command to test:
nixpkgs-review pr --checkout commit  97633 -p opencv4 -p python3Packages.opencv4

You can also just run the following to get a nix-shell with the package available:
nix-shell -I nixpkgs=https://github.com/marsam/nixpkgs/archive/1966a0a4e1c1e07991406e3b90e3b088df252aea.tar.gz -p opencv4 python3Packages.opencv4

I'm merging this as-is, but feel free to open an issue if you find an issue

You can also just run the following to get a nix-shell with the package available:
nix-shell -I nixpkgs=https://github.com/marsam/nixpkgs/archive/1966a0a4e1c1e07991406e3b90e3b088df252aea.tar.gz -p opencv4 python3Packages.opencv4

That is awesome! Thanks @mjlbach
Using that I tested the change just now, and can confirm it works 👍  thanks @marsam for merging this in


when hashed urls are turned on, the _memory db has improperly long-lived cache expiry

if hashed_urls are on, then a -000 suffix is added to the _memory database, and the cache settings are set just as if it was a normal hashed database.
in particular, this header is set:
cache-control: max-age=31536000
this is not appropriate because the _memory-000 database isn't really hashed based on the contents of the databases (see #1561).
Either the cache-control header should be changed, or the _memory db should have a hash suffix that does depend on the contents of the databases.

this has been addressed by the datasette-hashed-urls plugin


Release/6.52.0

Release
Release Name: 6.52.0
Spec Version: 52
Client Version: 6.0.0
Key Changes:
This release includes fixes to discard old ethy messages and few improvements to the protocol

Add `EVENT_INVALID_BELOW = 5683  to discard old messages lesser than that.
remove duplicate gossips of witneses by validators
fixes in gossip validator
passive peers gossip only if they have received finality notification and hence the event metadata.

PRs included:

Client Changes:

[x] Yes
[ ] No

Runtime Changes:

[ ] Yes
[x] No

Storage Changes:
Changed:
Extrinsic Changes:
Added:
Changed:
Event Changes:
Added:
Error Messages:
Added:
Storage Migrations:
Added:
Removed:

Replaced the solution with https://github.com/futureversecom/trn-seed/pull/838. no need to merge to the main.


openapi(engine): standardize error format

What problem does this PR solve?

Issue Number: ref https://github.com/pingcap/tiflow/issues/7475
What is changed and how it works?

Standardize gRPC and HTTP API error format.
Move all error definitions to pkg/errors, and remove rpcerror.
Re-export common functions of errors and github.com/pingcap/errors, so that we can only import one errors package.
Avoid using ErrXXX.Equal, use errors.Is instead. The Equal function is not implemented correctly.

Check List
Tests

Unit test
Integration test
Manual test (add detailed scripts or steps below)
No code

Questions
Will it cause performance regression or break compatibility?
Do you need to update user documentation, design documentation or monitoring documentation?
Release note
None

/run-engine-integration-test

/run-engine-integration-test

integration test dm_full_mode and TestIntegrationS3FileManagerRemoveTemporaryResources failed.
cmd:  curl "http://<IP_ADDRESS>:10245/api/v1/jobs/815e873c-ed25-45be-9b4c-546add95c1a9" | tee /dev/stderr | grep -q 'route-rules global not exist in routes'

[2022-11-07T04:20:22.437Z]   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

[2022-11-07T04:20:22.437Z]                                  Dload  Upload   Total   Spent    Left  Speed

[2022-11-07T04:20:22.437Z]
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100   147  100   147    0     0  52518      0 --:--:-- --:--:-- --:--:-- 73500

[2022-11-07T04:20:22.437Z] {"id":"815e873c-ed25-45be-9b4c-546add95c1a9","type":"DM","state":"Created","config":"","detail":"","error":{"code":"","message":""},"selectors":[]}

[2022-11-07T04:20:22.437Z] failed to execute cmd for 10 times:  curl "http://<IP_ADDRESS>:10245/api/v1/jobs/815e873c-ed25-45be-9b4c-546add95c1a9" | tee /dev/stderr | grep -q 'route-rules global not exist in routes'

[2022-11-07T03:25:07.331Z] === CONT  TestIntegrationS3FileManagerRemoveTemporaryResources
[2022-11-07T03:25:07.331Z]     file_manager_integration_test.go:154:
[2022-11-07T03:25:07.331Z]         	Error Trace:	/home/jenkins/agent/workspace/engine_ghpr_integration_test/go/src/github.com/pingcap/tiflow/engine/pkg/externalresource/internal/s3/file_manager_integration_test.go:154
[2022-11-07T03:25:07.331Z]         	            				/home/jenkins/agent/workspace/engine_ghpr_integration_test/go/src/github.com/pingcap/tiflow/engine/pkg/externalresource/internal/s3/file_manager_integration_test.go:168
[2022-11-07T03:25:07.331Z]         	            				/home/jenkins/agent/workspace/engine_ghpr_integration_test/go/src/github.com/pingcap/tiflow/engine/pkg/externalresource/internal/s3/file_manager_integration_test.go:172
[2022-11-07T03:25:07.331Z]         	Error:      	Error "[DFLOW:ErrResourceFilesNotFound]resource files not found" does not contain "ResourceFilesNotFoundError"
[2022-11-07T03:25:07.331Z]         	Test:       	TestIntegrationS3FileManagerRemoveTemporaryResources
[2022-11-07T03:25:07.332Z] --- FAIL: TestIntegrationS3FileManagerRemoveTemporaryResources (0.91s)
[2022-11-07T03:25:07.332Z] FAIL
[2022-11-07T03:25:07.332Z] coverage: 56.1% of statements
[2022-11-07T03:25:07.332Z] FAIL	github.com/pingcap/tiflow/engine/pkg/externalresource/internal/s3	0.956s

/run-engine-integration-test

/run-engine-integration-test

/run-engine-integration-test

integration test step_3 has passed in https://ci2.pingcap.net/blue/organizations/jenkins/engine_ghpr_integration_test/detail/engine_ghpr_integration_test/1737/pipeline/.

/run-engine-integration-test

/run-engine-integration-test

/run-engine-integration-test

/run-engine-integration-test

/run-engine-integration-test

/merge

/run-verify

/run-verify


section-index returns error when using in combination with material's blog plugin

I want to use "section index" to define my navigation structure with the "literate nav plugin".
Unfortunately in combination with the original mkdocs-material blog plugin I get the following error:
Traceback (most recent call last):
  File "/home/oro/Program/mambaforge/envs/mkdocs/lib/python3.12/site-packages/mkdocs/livereload/__init__.py", line 211, in _build_loop
    self.builder()
  File "/home/oro/Program/mambaforge/envs/mkdocs/lib/python3.12/site-packages/mkdocs/commands/serve.py", line 67, in builder
    build(config, serve_url=None if is_clean else serve_url, dirty=is_dirty)
  File "/home/oro/Program/mambaforge/envs/mkdocs/lib/python3.12/site-packages/mkdocs/commands/build.py", line 299, in build
    nav = config.plugins.on_nav(nav, config=config, files=files)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/oro/Program/mambaforge/envs/mkdocs/lib/python3.12/site-packages/mkdocs/plugins.py", line 596, in on_nav
    return self.run_event('nav', nav, config=config, files=files)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/oro/Program/mambaforge/envs/mkdocs/lib/python3.12/site-packages/mkdocs/plugins.py", line 566, in run_event
    result = method(item, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^
  File "/home/oro/Program/mambaforge/envs/mkdocs/lib/python3.12/site-packages/material/plugins/blog/plugin.py", line 187, in on_nav
    for view in self._resolve_views(self.blog):
  File "/home/oro/Program/mambaforge/envs/mkdocs/lib/python3.12/site-packages/material/plugins/blog/plugin.py", line 496, in _resolve_views
    assert isinstance(next, View)
           ^^^^^^^^^^^^^^^^^^^^^^
AssertionError
ERROR   -  [07:16:33] An error happened during the rebuild. The server will appear stuck until build errors are resolved.

First I thought it is an error within mkdocs-material. But Martin from squidfunk pointed me to this plugin. See the original bug report: https://github.com/squidfunk/mkdocs-material/issues/7283

Thanks for taking this upstream. As pointed out in https://github.com/squidfunk/mkdocs-material/issues/7283#issuecomment-2182236581, both plugins extend the page object, which makes them incompatible with each other. I don't think this can be solved in the way MkDocs works, so I recommended asking here for discussion ☺ Happy to discuss potential solutions so we can make them work together.

Hi everyone,
I just stumbled upon this issue and noticed it was already discussed here. I see that @squidfunk pointed out that the incompatibility is due to both plugins extending the page object, and that it might be difficult to resolve given how MkDocs works.
I was wondering if there have been any updates or potential workarounds discovered since this comment? I'd love to use both plugins together if possible.
Thanks for any insights, and happy to help test if needed!


media query sub-features

Can support tables for sub features be added or does every browser either fully support the css3 media query spec or not?
For example, I know that most browsers by now support min/max width/height and dpi queries, but I don't know which ones support min-aspect-ratio.
https://www.w3.org/TR/css3-mediaqueries/#aspect-ratio
https://codepen.io/rubenvincenten/full/LxQEXw/

Derp, duplicate of https://github.com/Fyrd/caniuse/issues/1911
Also possible related is https://github.com/Fyrd/caniuse/issues/1069


Transfer of large files

Hi, there seems to be an issues when transfering files bigger then 25 MBytes. Does anyboy know why?
I get a lot of timeout errors such as:
13:28:20.706 [NETTY-TOMP2P - worker-client/server - -3-4] WARN  net.tomp2p.connection.TimeoutFactory - channel timeout for channel Server [id: 0x3617620d, /<IP_ADDRESS>:5
In addition I noticed that files bigger then the above mentioned size result in the following error on the recipient side:
13:28:25.198 [defaultEventExecutorGroup-2-9] WARN  o.h.c.n.messages.MessageReplyHandler - Received but denied a message. Acceptance reply = 'NO_CALLBACK_HANDLER_FOR_THIS_MESSAGE', Node ID = 'masterID'.
Thanks for your help!
Edit:
I just noticed that the message was denied due to the signature problems.
[NETTY-TOMP2P - worker-client/server - -3-4] WARN  net.tomp2p.message.Decoder - wrong signature! Message:id=781343603,t=REQUEST_1,c=1,tcp

I lately improved the download of large files. Will be included in the next release.


chore: fix see-lingua update script

:tada: This PR is included in version 12.14.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release
v12.14.0

Your semantic-release bot :package::rocket:


Option to name types based on fully qualified names of .Net Types

B"H
I have one project where the existing DTOs are all of the same name as the EntityFramework classes, just in the DTO namespace.
i.e. we have Customer & Transaction classes as part of our EntityFramework model. However for obvious reasons both business & technical. Our existing REST service does not send those back to the client. So we have separate Customer & Transaction in a namespace called DTO. (we have a dozen more classes like that)
This works great in C# we just use the qualified names.
We also have functions and expressions right in the EF classes for returning the DTOs. So as HotChocolate is scanning the model it ends up with two types named Customer tec. This causes an error to be thrown.

You can override the default naming convention to build up very long names... They just have to conform to the GraphQL naming definition .... meaning no . and so on ....
http://spec.graphql.org/June2018/#sec-Names

You can override the default naming convention to build up very long names... They just have to conform to the GraphQL naming definition .... meaning no . and so on ....
http://spec.graphql.org/June2018/#sec-Names

You can override the default the default naming on a Type by Type basis. (that may very well be the workaround that we will opt for until this is implemented).
However, things would be much simpler and scalable. If we could just have a setting on the AddType<>() method that scans the model. That would name all types by their fully qualified name instead of their local name.
What you have basically answered is that "There is no way to do that in Pure code first. Therefore in this case you should switch over to (or augment) the fluent api approach"

You can override the default the default naming on a Type by Type basis. (that may very well be the workaround that we will opt for until this is implemented).
However, things would be much simpler and scalable. If we could just have a setting on the AddType<>() method that scans the model. That would name all types by their fully qualified name instead of their local name.
What you have basically answered is that "There is no way to do that in Pure code first. Therefore in this case you should switch over to (or augment) the fluent api approach"

@jewpaltz
Michael was talking about naming conventions. These work in all approaches.
We have not updated the docs to v11. But i think this should still work.
https://chillicream.com/docs/hotchocolate/v10/schema/conventions/

@jewpaltz
Michael was talking about naming conventions. These work in all approaches.
We have not updated the docs to v11. But i think this should still work.
https://chillicream.com/docs/hotchocolate/v10/schema/conventions/

So you're saying that I can either start a brand new project from scratch. Or rename all of my existing DTOs to fit HT's naming convention. But adding a feature to use fully qualified names, so that we people can incrementally add it to an existing projects with this naming convention, is not an option.
I hear you. Priority and time need to be dedicated to what you think is will help the most amount of people, and not be squandered where there are workarounds.

So you're saying that I can either start a brand new project from scratch. Or rename all of my existing DTOs to fit HT's naming convention. But adding a feature to use fully qualified names, so that we people can incrementally add it to an existing projects with this naming convention, is not an option.
I hear you. Priority and time need to be dedicated to what you think is will help the most amount of people, and not be squandered where there are workarounds.

No you can add the naming convention anytime you like.

DefaultNamingConventions handles how things are named (e.g. lower-camel-case) or where to fetch the description of member.

HotChocolate uses the INamingConvention to name the types.
just create a new class that extend from DefaultNamingConvetions and then register it in the DI or on the schema builder with
services.AddGraphQL()
    .AddConvention<INamingConvention, YourCustomNamingConvention>()

No you can add the naming convention anytime you like.

DefaultNamingConventions handles how things are named (e.g. lower-camel-case) or where to fetch the description of member.

HotChocolate uses the INamingConvention to name the types.
just create a new class that extend from DefaultNamingConvetions and then register it in the DI or on the schema builder with
services.AddGraphQL()
    .AddConvention<INamingConvention, YourCustomNamingConvention>()

Awesome. No, sorry. I hadn't seen that link. I will look into it.

Awesome. No, sorry. I hadn't seen that link. I will look into it.


GOST34.10 2012  bug fix

I apologize, but it seems that I did not correctly interpret RFC 7091. Test examples in RFC 7091 are given in little endian so we must reverse input hash-message.
Now the implementation has been successfully tested with GostCrypto  library

Thanks! This is now available in https://www.bouncycastle.org/betas

Now on https://www.bouncycastle.org/betas 158b04 or later


Item "Use" button consuming scrolls and wand charges before trick magic item is resolved

pf2e v 5.11.4
As per Player Core:

Current behaviour:
Peek 2023-12-17 01-33.webm

Hi, can you say what specifically is "per Player Core"?

From the wording it would seem to infer that the items cannot be used at all without first succeeding on the check. Would be weird to consume a wand or scroll that you can't even activate.
It doesn't state that a skill needs to be trained in to be used, so I will change the title. 🤔

@nikolaj-a That's just the prerequisite for taking the feat I believe. It doesn't say in the actual text that you need to be trained in a skill you use to trick the item though, but I may be wrong on that one 🤷♂

I guess the distinction matters very little, given how hard it'll be to actually succeed at the untrained check with any sort of reliability beyond, like, level 2 or 3.

Only really matters when you have untrained improvisation, when needing to be actually trained in a skill to use trick magic item would be make a real difference.

Withdrawing this feature request


Fix broken links in linux binary installation

Fix issue reported in ros-infrastructure
FYI, I ended up reporting it to the latte because the 404 page was redirecting me therer in the first place. I'm noting it here in case you want to fix it.

Thanks for the contribution @bergercookie and looking forward for those linting tests!


[PE-D] Mail-x feature description is ambiguous

The mail-x feature is a little ambiguous when it comes to what I can use it with. You can consider stating that all other categorisation types are not supported?

Labels: type.DocumentationBug severity.Medium
original: pyk595/ped#9

Not sure what the reviewer is talking about here tbh


fix(file) add missing validation messages + improve test coverage

While writing the documentation (https://github.com/updatecli/website/pull/161) for the new file features introduced in #313 , I caught missing error messages and an error in the "generic reference YAML example".
This PR aims to fix these.
Test
To test this pull request, you can run the following commands:
  cp <to_package_directory>
  go test

Additionnal Information
Please note that this PR should only result in a pacth version of updatecli/

Thanks for this pr


WMS ID 11641 -- Fix Lab 1 Display by adjusting path names to be all lowercase

Add here your WMS ID
General requirements

Information in the workshop is adequate and updated
Code is correct and working
Links are correct
Make sure you enter the help email link in your manifest.json
Please make sure WMS URLs are updated as needed after your PR is approved

Checklist - Refer to the QA document for the complete list
Please confirm that the following is completed before submitting your PR

[ ] All filenames are lower case (including folders, images, files, etc.)
[ ] Filenames are descriptive
[ ] Your workshop folder structure should be similar to the one used in the sample workshop (https://github.com/oracle-livelabs/common/tree/main/sample-livelabs-templates/sample-workshop)
[ ] Are you using multiple versions (desktop/, sandbox/, tenancy/)? Make sure that each of them contains a manifest.json and an index.html
[ ] Image references in markdown contain an alternate text

Hello @carmenberdant1 what is the Private Info and what lab and images are you referring to?


ISSUES

. Date Handling for the Previous Trading Day
The current implementation assumes that only one day before today can be a trading day. This is not always true (e.g., if today is a Monday, the previous trading day could be Friday). You should fetch historical data and check the last trading day until a valid one is found.
2. Handling Market Hours
The Finance library may not provide data if the market is closed or if the API call is made outside of market hours. You may want to check if the current time is within market hours before attempting to fetch the data.
3. File Handling
When creating a new DataFrame, there should be a check to ensure the CSV file is saved successfully. If there's a failure in writing to the file, it should be handled properly.
4. Duplicate Dates
The check for existing dates is based on the date string format. If there are any leading or trailing spaces in the date column, it may fail to detect duplicates. It’s safer to strip any whitespace.
5. Logging vs. Printing
Instead of using print statements for logging, consider using the logging module for better flexibility and control over log levels.
6. Code Comments and Documentation
Adding more comments and documentation within the code could enhance readability and maintainability.
7. Exception Handling
The exception handling in run_daily_tracking is very broad. It would be better to catch specific exceptions, especially when dealing with file I/O or API calls.
8. Data Fetching Logic
The logic to fetch data can be improved. For example, you can check if the fetched data has any missing values and handle those accordingly.
9. Magic Numbers
The target percentages are hardcoded. Consider allowing these to be passed as arguments to the class constructor.

Nice catches, feel free to address as many issues as you'd like to. So far these issues are solved:

[x] 1. Date Handling for the Previous Trading Day
The current implementation assumes that only one day before today can be a trading day. This is not always true (e.g., if today is a Monday, the previous trading day could be Friday). You should fetch historical data and check the last trading day until a valid one is found.
[x] 2. Handling Market Hours
The Finance library may not provide data if the market is closed or if the API call is made outside of market hours. You may want to check if the current time is within market hours before attempting to fetch the data.
[x] 5. Logging vs. Printing
Instead of using print statements for logging, consider using the logging module for better flexibility and control over log levels.


Bump helm to v3.11.1 to address CVE-2023-25165

Requires a number of other dependency updates.

Fixes OCPBUGS-7683

/retest

/lgtm
/approve

The e2e/e2e-kind test that runs make e2e is failing locally on both this branch and on main.

/jira refresh

/lgtm


Option to add multiple age ranges

"Age" section updated to support multiple age ranges
"Default" bid is initially shown, advertiser can add as many ranges as needed, there's no specific limit for age ranges, but a limit on total number of bids considering all dimensions (set by variable max_fields which remains unchanged)

LGTM

tested, looks good! Thanks for adding this!


mat: added a few godoc examples for Dense methods

Instead of adding all examples at once, I just added a few to see if anyone has comments before working on the rest.

Thank you!


Instantiating callbacks from CLI fails

🐛 Bug
To Reproduce
On master:
python pl_examples/basic_examples/autoencoder.py  --trainer.callbacks=pytorch_lightning.callbacks.early_stopping.EarlyStopping --trainer.callbacks.patience=5

Expected behavior
As described in the docs, we should be able to instantiate the callback from the CLI with the above syntax.
Environment
You can also fill out the list below manually.
-->

PyTorch Lightning Version (e.g., 1.5.0): master and 1.5.8
PyTorch Version (e.g., 1.10): 1.10
Python version (e.g., 3.9): 3.9
OS (e.g., Linux):
CUDA/cuDNN version:
GPU models and configuration:
How you installed PyTorch (conda, pip, source):
If compiling from source, the output of torch.__config__.show():
Any other relevant information: jsonargparse-4.1.1

Additional context
X
cc @carmocca @mauvilsa

You don't need to specify the full classpath using the shorthand notation.
python pl_examples/basic_examples/autoencoder.py  --trainer.callbacks=EarlyStopping --trainer.callbacks.patience=5
You might have noticed already. Posting the answer in case somebody finds this issue.


meteor just broke raix:stubfence

My computer told me to tell you something. This occurred while running the cordova-improvements branch so they might be at fault here. The repo in which this occurred is pretty complex so I'm not sure how easy it'll be to build a reproducing repo, but if the problem isn't clear and that would help, I can certainly try.
W20150803-17:49:57.096(-4)? (STDERR)
W20150803-17:49:57.097(-4)? (STDERR) /media/Storage/emocha/meteor-dev/meteor/dev_bundle/server-lib/node_modules/fibers/future.js:245
W20150803-17:49:57.097(-4)? (STDERR) 						throw(ex);
W20150803-17:49:57.097(-4)? (STDERR) 						      ^
W20150803-17:49:57.101(-4)? (STDERR) Error: Arg! Meteor just broke raix:stubfence! Please report to @raix at github, and he will work his butt off trying to fix this
W20150803-17:49:57.101(-4)? (STDERR)     at inFence (packages/raix_stubfence/packages/raix_stubfence.js:12:1)
W20150803-17:49:57.101(-4)? (STDERR)     at Package (packages/raix_stubfence/packages/raix_stubfence.js:15:1)
W20150803-17:49:57.101(-4)? (STDERR)     at /media/Storage/emocha/meteor-dev/platform-midot-mobile/app/.meteor/local/build/programs/server/packages/raix_stubfence.js:129:4
W20150803-17:49:57.101(-4)? (STDERR)     at /media/Storage/emocha/meteor-dev/platform-midot-mobile/app/.meteor/local/build/programs/server/packages/raix_stubfence.js:136:3
W20150803-17:49:57.101(-4)? (STDERR)     at /media/Storage/emocha/meteor-dev/platform-midot-mobile/app/.meteor/local/build/programs/server/boot.js:242:10
W20150803-17:49:57.101(-4)? (STDERR)     at Array.forEach (native)
W20150803-17:49:57.101(-4)? (STDERR)     at Function._.each._.forEach (/media/Storage/emocha/meteor-dev/meteor/dev_bundle/server-lib/node_modules/underscore/underscore.js:79:11)
W20150803-17:49:57.101(-4)? (STDERR)     at /media/Storage/emocha/meteor-dev/platform-midot-mobile/app/.meteor/local/build/programs/server/boot.js:137:5
=> Exited with code: 8

is this on v1.0.2?

cordova-improvements branch
On Tue, Aug 4, 2015, 11:04 Morten N.O. Nørgaard Henriksen <
<EMAIL_ADDRESS>wrote:

is this on v1.0.2?
—
Reply to this email directly or view it on GitHub
https://github.com/raix/stubfence/issues/3#issuecomment-127643210.

This is happening on 1.2 rc-12

http://cl.ly/image/3D0F0Y0N3W2a

I'll try to fix this today,
@jperl it's ground:db using it - for 1.2 I'm working on: https://github.com/GroundMeteor/db/tree/es2015-localforage This is a rewrite of ground db - so it handles things a bit differently - still much wip :)

No rush. Might be better to put that effort in the rewrite :)
Head of Engineering @ Dispatch | Github: jperl | Skype: perl.jonathan |<PHONE_NUMBER>
On Thu, Sep 10, 2015 at 1:21 AM, Morten N.O. Nørgaard Henriksen
<EMAIL_ADDRESS>wrote:

I'll try to fix this today,
@jperl it's ground:db using it - for 1.2 I'm working on: https://github.com/GroundMeteor/db/tree/es2015-localforage This is a rewrite of ground db - so it handles things a bit differently - still much wip :)
Reply to this email directly or view it on GitHub:
https://github.com/raix/stubfence/issues/3#issuecomment-139119958

This is also happening in <IP_ADDRESS> (released today) for me.


[SPI_Host] Winbond Flash BFM targeted tests

estimate 8
Corresponds to SH:3 on internal tracking

Adding a second level comment with the description as captured from @andreaskurth . This does not map exactly with how @GregAC subdivided the tasks but some relevant points captured there.
Write directed tests to use (configure, write, and read) the W25Q01JV in a way that is representative of the discrete OT. This can take a couple of days, depending on how many directed tests have to be written to cover all mandatory scenarios. → 2-6 days. Some notes:

The spi_host DIF contains code that will drive spi_host and through it the serial flash. Typical read/write sequences could be obtained by breaking the DIF functions down to what spi_host will do with the flash.
The verification env already contains “high-level” functions / tasks to interface spi_host for sending commands and data. These can be leveraged.

Given that this requires a working BFM model this effort is shifted back, post M2.

Triaged for spi_host. This is about adding a block-level test targeting a flash chip BFM (to be added in #15072), which is planned post M2.5. Thus I'm assigning it to https://github.com/lowRISC/opentitan/labels/Type%3AIcebox.


Out of Band Type Annotation Support for Signatures

I am not sure if it would be at all possible or feasible but I would really appreciate Hindley–Milner type signature support in TypeScript:
// stringLength :: String -> Number
const stringLength = word => word.length

I am writing a lot of code like this as I find it much easier to read but unfortunately TypeScript doesn’t understand this notation.
Some relevant reading:

Ramda Type Signatures
Mostly Adequate Guide to Functional Programming
Sanctuary Types

What's the distinction vs this?
const stringLength: (s: string) => number = word => word.length;

Changing the title, since it doesn't actually have anything to do with Hindley-Milner which is an inference algorithm, not a syntactic style. Standard ML, for instance, doesn't use this syntax.

Sorry, I don't understand. How is the intent of
// stringLength :: String -> Number
const  stringLength  =  word  =>  word.length
much different to:
const stringLength: (x: string) => number = str => str.length
console.log("the length is", stringLength("apple"))
// nicely type annotated and outputs: the length is 5
or even:
type String2Number = (x: string) => number
const stringLength2: String2Number = word => word.length
console.log("the length is", stringLength2("banana"))
// also nicely type annotated outputs: the length is 6

Justin Johansson:
https://github.com/johanssj
A first TypeScript mini-project:
Implementation of copy-on-write for JavaScript arrays using ES2015 Proxy
Objects
https://github.com/johanssj/cowarray

(Apologies for resend. Have no idea how subject line got changed in
first reply from subject line by Sorin Iclanzan).
Sorry, I don't understand. How is the intent of
// stringLength :: String -> Number
const stringLength = word => word.length
much different to:
const stringLength: (x: string) => number = str => str.length
console.log("the length is", stringLength("apple"))
// nicely type annotated and outputs: the length is 5
or even:
type String2Number = (x: string) => number
const stringLength2: String2Number = word => word.length
console.log("the length is", stringLength2("banana"))
// also nicely type annotated and outputs: the length is 6

Justin Johansson:
https://github.com/johanssj
A first TypeScript mini-project:
Implementation of copy-on-write for JavaScript arrays using ES2015 Proxy
Objects
https://github.com/johanssj/cowarray

this would be my recommendation:
const stringLength = (word: string) => word.length;

I don't see enough of a motivation to depart from the ECMAScript-reserved syntax, especially given that there's a sufficient mechanism in place that doesn't have any specific problems. Thanks for filing though!

Wow, this was closed fast. I was hoping for more discussion. I know there are other TypeScript users that would like to see something like this supported.

What's the distinction vs this? Just the syntactic location, or the actual form of the signature type?

const stringLength: (s: string) => number = word => word.length;

I find something like the above very confusing/hard to read, and this is for the most basic example.

> Changing the title, since it doesn't actually have anything to do with Hindley-Milner which is an inference algorithm, not a syntactic style.

[Hindley-Milner](https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system) is a type system, which does describe an inference algorithm, but also comes with a syntax which functional languages like Haskell and functional JavaScript libraries have adopted to use as type annotations.

> I don't see enough of a motivation to depart from the ECMAScript-reserved syntax.

What do you mean by “ECMAScript-reserved syntax”? Since when are these type annotations ECMAScript-reserved syntax? With my proposed annotations I can use regular ECMAScript which allows me to use it in projects where the move to the  TypeScript syntax is not desired.

Good you came back and explained further as I completely misunderstood your question in the first instance. Sure, this syntax is very familiar to Haskellers
// stringLength :: String -> Number
const stringLength = word => word.length

and, IIRC, Elm (compile-to-JS) language also makes use of the same .. so you are certainly not alone in having some affinity for it.
I'm just a casual observer though does seem like your issue was closed off & dismissed rather quickly. Maybe for the moment you will just have to accept putting your style of type annotations in alla-comment-style, which, btw, is something that I understand Flow people subsequently embraced.

I am totally fine and actually prefer putting my type annotations in comments. The problem is I get now help from TypeScript using these type signatures.

Today you can write:
type StringLength = (s: string) => number
const stringLength: StringLength = word => word.length

Not even close :/


Update to sbt 1.2.7 to get rid of sbt/sbt#4441

I'm running into the Different extra API hashes issue sbt/sbt#4441. Fortunately this has been fixed in sbt 1.2.7.

Thanks @sbrunk!


Thanatos payload cannot connect to self-signed http service.

Hi,
Using latest Thanatos with latest Mythic.
Built default thanatos payload for Linux x64 with http profile. Http profile's ip address is basic Apache https redirector.
When starting payload, then i get following error:
thread 'main' panicked at src/profiles/mod.rs:117:49:
called `Result::unwrap()` on an `Err` value: IoError(Custom { kind: InvalidData, error: InvalidCertificate(UnknownIssuer) })
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

On https redirector i have self-signed certificate, with SAN records and CA:FALSE.
Other payloads medusa, poseidon and merlin work fine over same https redirector.
Sounds like a bug?

The current HTTP library does not support self-signed TLS certificates https://github.com/MythicAgents/thanatos/issues/6#issuecomment-1110117393. Self-signed TLS certificate support will be added in the rewrite.


Remove underline from folds (GUI only).

This repository doesn't seem to have an Issues section, so I went ahead and did it before asking for an opinion. We can discuss the topic here if the maintainer disagrees with my choice.
In GUI mode, which also includes Neovim's true colour mode, the text of folds appears with an underline. Solarized doesn't do that in GUI mode and in my opinion it just adds visual noise. Folds are already differently coloured, so there should be no need for an extra underline. Furthermore, the underline was only showing in the dark variant, not the light one, so one of them has to be the defective one.
Let me know what you think and if you agree or disagree.

I didn't create this ugly colorscheme for using it; only to provide a simpler alternative to Solarized. So, basically, I have no opinion on the subject… and no desire to give it any more time than strictly needed.
That said, any fix that makes it look more like the original is certainly welcome.

I didn't create this ugly colorscheme for using it

That's... an unusual attitude :P Well, thanks for making it in the first place then.


settings: Fix bug when changing stream specific notification setting.

The class for "tr" element was changed in c22de76af7a891, so get_stream_id function was not able to get the correct stream-id from the target element. This commit fixes get_stream_edit function to also check for closest ".stream-notifications-row" ancestor element and thus it returns the correct stream id.

Fixes:  https://chat.zulip.org/#narrow/stream/9-issues/topic/Changing.20stream.20settings.20from.20notifications.20panel

Self-review checklist

[ ] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[ ] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[ ] Each commit is a coherent idea.
[ ] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[ ] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[ ] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

@timabbott It would be good to integrate a fix for this bug. (I haven't tested the PR, but you probably don't need anything from me on this one.)

Merged, and planned to backport to 6.x. Thanks for fixing this @sahil839!

Backported as d2be34d5aa01676a3e7909294430daf1ff2a2d82.


Requiring unknown module rebound

Just trying to configure it locally, but the app fails to start because of
"Requiring unknown module rebound"
And actually it's really missing in the sources

installed rebound manually


Add alias to make docker log in to AWS ECR

Thanks for the pull request. It looks good to me. Could you possibly rebase this off of the master branch and confirm this contribution is under the terms of the MIT license?

Thanks for the feedback!
Rebase off of master is done and I confirm this contribution is under the terms of the MIT license?

Just FYI. When I tried to run "aws docker-ecr-login" on a mac, I got the following error.

tonychia@Tonys-MacBook-Pro ~/.aws/cli $ which base64
/usr/bin/base64
tonychia@Tonys-MacBook-Pro ~/.aws/cli $ base64 --help
Usage:	base64 [-hvD] [-b num] [-i in_file] [-o out_file]
  -h, --help     display this message
  -D, --decode   decodes input
  -b, --break    break encoded string into num character lines
  -i, --input    input file (default: "-" for stdin)
  -o, --output   output file (default: "-" for stdout)
tonychia@Tonys-MacBook-Pro ~/.aws/cli $

It seems on the Mac, it's using a capital -D for decode but on Redhat/Ubuntu, it's using lower case -d for decode. So I would suggest using "--decode" instead which would work on both Mac and Linux.
Another suggestion that I have is to remove the "-e none" since it was complaining about that flag is going to be removed

tonychia@Tonys-MacBook-Pro ~/.aws/cli $ aws docker-ecr-login
Flag --email has been deprecated, will be removed in 1.14.
Login Succeeded
tonychia@Tonys-MacBook-Pro ~/.aws/cli $

After making those two changes, it worked perfectly on a Mac.

tonychia@Tonys-MacBook-Pro ~/.aws/cli $ aws docker-ecr-login
Login Succeeded
tonychia@Tonys-MacBook-Pro ~/.aws/cli $

Good catch! I've incorporated the suggestions you pointed out.

Awesome. Merging.


Data hole on surface reflecting light

Required Info

Camera Model
D435

Firmware Version
<IP_ADDRESS>

Operating System & Version
Win 10

Kernel Version (Linux Only)

Platform
PC

SDK Version
n/a

Language
Viewer

Segment
others

Issue Description
We run into issue with data holes. I will do my best to describe the conditions:
Certain surfaces reflecting light on angle are causing depth data to have data holes. In the example below left hand (right on a photo) has oily cream applied on it. Right hand has no product. Light source (ie. halogen lamp) is directed on subject (behind camera).
Is this a known limitation or would you suggest any setting for the camera that could improve scan in this case?

An old trick for dealing with gaps in data caused by reflectivity is to use a fine spray-on powder such as foot powder or baby powder to dampen the reflection.  It is reputed that a project to scan a vehicle bodywork repair workshop sprayed the entire workshop in baby powder to remove the reflections of the metalwork.
There are also professional 3D scanning sprays that can do the same job of dampening reflections.   An example use is on jewelry that has to be scanned for a catalog.
https://www.laserdesign.com/3d-scan-spray/?language=en_US
Another way to dampen reflection on large areas is to apply an anti-reflection film to it.  google for 'anti reflection film' for more details.

In the image above I don't think the issue is reflectivity (strictly there is no reflection in the IR image), but rather IR over-saturation. You can try experimenting with different values of exposure and gain controls to fine tune the image to your use case.
In extreme case where you have brightly illuminated surfaces and really dark surfaces, it is impossible to find one value of sensor exposure without having either completely black or completely white regions, but for this case, the camera does offer a control to rapidly switch between two values of exposure.


Android Basics: tip-calculator

URL of codelab
https://developer.android.com/codelabs/basic-android-kotlin-training-tip-calculator?authuser=1&continue=https%3A%2F%2Fdeveloper.android.com%2Fcourses%2Fpathways%2Fandroid-basics-kotlin-unit-2-pathway-1%3Fauthuser%3D1%23codelab-https%3A%2F%2Fdeveloper.android.com%2Fcodelabs%2Fbasic-android-kotlin-training-tip-calculator#5
In which task and step of the codelab can this issue be found?
In Adopt good coding practices, (Optional) Eliminate repetitive code, Step 3.
Describe the problem
Well it's not necessarily a problem, but the code is not updated. To word it better, earlier in that page we were encouraged to remove the following text: (We don't use the variable roundUp anywhere else so just inline it into the if statement)
    val roundUp = binding.roundUpSwitch.isChecked
    if (roundUp) {
        tip = kotlin.math.ceil(tip)
    }

However in step 3, this code is re-introduced and may confuse the reader who would've already removed this and used the following as advised:
        if (binding.roundUpSwitch.isChecked) {
            tip = kotlin.math.ceil(tip)
        }

Steps to reproduce?
Nothing to reproduce, the information above is self explanatory.
Versions
Android Studio version:
API version of the emulator:
Not a problem with android studio or API, but a problem with the documentation.
Additional information
Include screenshots if they would be useful in clarifying the problem.

Hello @joel16,
Thank you for reaching out to us. The codelab instructions have been updated, so hopefully there won't be any more confusion.


Tabbar icons pixelated

I'm using BATabBarController(Cocoa pod), everything works fine, but the tab icons are pixelated, tried variant size of icons still icons are pixelated especially in 5s,6,7&8, attached screenshots

Could that be due to the image resolution and not having properly 2x and 3x icons?


Order of bsub non-standard arguments from lsf.yaml file

https://github.com/Snakemake-Profiles/lsf/blob/c88fcb9fc60ce74596fbf8f516fef31574eef5de/{{cookiecutter.profile_name}}/lsf_config.py#L33
Hi,
I would suggest changing the order of rule-specific parameters to first rule_params and then default_params. bsub takes the first argument and ignores any other occurrences, hence the default is always taken.
Thanks for the work and best,
Nico

Hi @NBMueller. It is actually the other way around, it uses the last option and disregards all others. This is the behaviour I also observe on my system with testing of multiple different options

Hi @NBMueller. It is actually the other way around, it uses the last option and disregards all others. This is the behaviour I also observe on my system with testing of multiple different options

Thanks for the quick reply!
Which LSF version is your hpc using? Ours is
>>> lsid
IBM Spectrum LSF Standard <IP_ADDRESS>, Dec 18 2018
Copyright International Business Machines Corp. 1992, 2016.

If I run the following:
bsub -W 0:01 -W 0:02 -J "test" "ps -al"

the job requests 1 min runtime, not 2 mins.
Maybe the behavior changes with different LSF versions?

Thanks for the quick reply!
Which LSF version is your hpc using? Ours is
>>> lsid
IBM Spectrum LSF Standard <IP_ADDRESS>, Dec 18 2018
Copyright International Business Machines Corp. 1992, 2016.

If I run the following:
bsub -W 0:01 -W 0:02 -J "test" "ps -al"

the job requests 1 min runtime, not 2 mins.
Maybe the behavior changes with different LSF versions?

I am using IBM Spectrum LSF Standard <IP_ADDRESS>, May 25 2018. I tested your example and see the same behaviour as you.
It is frustrating because if I do
bsub -q q1 -q q2 -J "test" "sleep 10"

the job gets sent to queue q2. I can't really find much about ordering in the docs...
Given the inconsistencies between options, the best solution seems to be to try and deduplicate all options with the rule-specific options taking priority.

I am using IBM Spectrum LSF Standard <IP_ADDRESS>, May 25 2018. I tested your example and see the same behaviour as you.
It is frustrating because if I do
bsub -q q1 -q q2 -J "test" "sleep 10"

the job gets sent to queue q2. I can't really find much about ordering in the docs...
Given the inconsistencies between options, the best solution seems to be to try and deduplicate all options with the rule-specific options taking priority.

@NBMueller let me know if v0.1.0 (i.e. https://github.com/Snakemake-Profiles/lsf/commit/57302c69c9eff456b5a5d727a7ac30b2b684845d) still gives you issues

@NBMueller let me know if v0.1.0 (i.e. https://github.com/Snakemake-Profiles/lsf/commit/57302c69c9eff456b5a5d727a7ac30b2b684845d) still gives you issues


Server mode: take file extension from uploaded file

Changes to take temp file extension from uploaded file so we can support more than .tf when in server mode.
Alternately - I was thinking of adding GetDefaultExtension() to each of the iac-providers and then naming the temp file based on the iac type passed. That might be a little more secure, but not by very much. Gimme thoughts...

I was thinking of adding GetDefaultExtension() to each of the iac-providers and then naming the temp file based on the iac type passed.

It is good an idea to add extensions based on iac-type. But, the changes in the current PR look good to me. We can add extensions based on iac-types if the current implementation fails for some scenario.


Send the Admission plugin version to the Insights API, from the version.txt file

This PR is an alternate possibility for PR 582 that avoids copying plugin version.txt files within the pkg sub-directory, and breaking local plugin builds.
Checklist

[x] I have signed the CLA
[x] I have updated/added any relevant documentation

Description
What's the goal of this PR?
Submit the plugin version, taken from the version.txt file, in submissions to the Insights API, including plugin packages used by other plugins, such as Admission using OPA / Polaris.
What changes did you make?

Added an embed.go to the root of each plugin, which must be located at the same location as the version.txt file we use to track the plugin version.
Import the new package, using an alias: admission version "GitHub.com/fairwindsops/insights-plugins/plugins/admission
Use these packages to obtain current plugin versions, such as admission version.String() or opaversion.String().

What alternative solution should we consider, if any?
This Slack thread contains discussion about other options.

Using a hard link to mirror the version.txt file within pkg sub-directories doesn't work because git doesn't preserve hard links.
Copying version.txt within pkg sub-directories (via the Dockerfile) does work, but it complicates / breaks a local go build, and requires the Admission Dockerfile to copy version.txt in place for other plugins (OPA / Polaris).

This strategy looks great to me. Thanks for working through it Ivan and Barnie!

@rbren / @makoscafee I'd like to call out that importing the new version pkg from embed.go is not able to include the word version; it uses the top-level plugin path in the import. That looks like:
import (
  admission version "GitHub.com/fairwindsops/...../admission"
)

I have tried to improve on this, but naming the package something more descriptive in the import would require the package be located in a different sub-directory ... which defeats the purpose of having embed.go located with version.txt.
I want to make sure you're aware of / ok with this?

This strategy looks great to me. Thanks for working through it Ivan and Barnie!

@rbren / @makoscafee I'd like to call out that importing the new version pkg from embed.go is not able to include the word version; it uses the top-level plugin path in the import. That looks like:
import (
  admissionversion "GitHub.com/fairwindsops/...../admission"
)

I have tried to improve on this, but naming the package something more descriptive in the import would require the package be located in a different sub-directory ... which defeats the purpose of having embed.go located with version.txt.
I want to make sure you're aware of / ok with this?

We covered this in Slack:
RobertB: :nod: yeah I think that's fine At 3:28 PM yesterday


Fix method signature of gesture detector classes

I'm not sure if this will affect any previous versions of flutter, but in the versions Flutter 3.8.0-12.0.pre.15 and Dart 3.0.0 (build 3.0.0-229.0.dev) it is conflicting with the TextSelectionGestureDetector method signatures

@znjameswu  cc, fluffychat will break on flutter 3.10 because of this

fixes https://github.com/simpleclub-extended/flutter_math_fork/pull/64

Any update when this will be live?

Version 0.7.0 is now available on pub.dev.
cc: @DouglasSerena @KarimAbdo @Decodetalkers


npm v6.4.0

I'm trying to use the @sendgrid/mail setTimeout. I see it in the github repo but when i pull it into my own repo that function doesn't show in the node modules. It says its version 6.4.0.
I don't think npm package @sendgrid/mail v6.4.0 matches to the github repo version 6.4.0 but some older version.
Please explain.

Not sure how the change didn't make it into the release, but the release tag matches what's in npmjs: https://github.com/sendgrid/sendgrid-nodejs/tree/v6.4.0
It will be included in the next release, which is happening more frequently than previously.


Vertical Select with middle click is not working

Issue Type: Bug
In older versions of VSCode, I did vertical selection by clicking the middle button on the mouse and dragging.
It seems like this doesn't work anymore.
VS Code version: Code 1.40.1 (8795a9889db74563ddd43eb0a897a2384129a619, 2019-11-13T16:49:30.162Z)
OS version: Linux x64 5.0.0-36-generic snap

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz (8 x 1960)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: disabled_softwareskia_renderer: disabled_offsurface_control: disabled_offsurface_synchronization: enabled_onvideo_decode: unavailable_offviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
4, 2, 1

Memory (System)
7.76GB (0.16GB free)

Process Argv
--force-user-env --no-sandbox --unity-launch --no-sandbox

Screen Reader
no

VM
0%

Extensions (4)

Extension
Author (truncated)
Version

plantuml
jeb
2.13.5

intellij-idea-keybindings
k--
0.2.37

python
ms-
2019.11.50794

vscode-yaml
red
0.6.1

@yanniszark In some Linux distributions, middle clicking is reserved for moving windows. Did you perhaps change window compositors, or have upgraded your distribution since it last worked? Does middle clicking work for you in other applications?

@alexandrudima thanks for the response!
I'm working on Ubuntu 18.04.
This is the output of lsb_release -a:
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.3 LTS
Release:	18.04
Codename:	bionic

In Jetbrains Goland, vertical selection with middle click works as expected.

Thanks for your quick reply.
VS Code is built with Electron, which is built with Chromium. Can you please try opening https://vscode-web-test-playground.azurewebsites.net (it might take a long time to load) in Chromium on the same machine? Does using the middle mouse button work there?

@alexandrudima I loaded the web page and the middle click vertical select still doesn't work.
When I try to select vertically, it just selects normally.
Also, middle click for paste works.

Also, middle click for paste works.

Aha! Thanks for the last extra detail to jog my memory. Indeed, the middle mouse button by default will paste the selection clipboard on Linux. You can disable that via "editor.selectionClipboard": false. Once the selection clipboard is disabled, the middle mouse button can be used for column selection.

@alexandrudima yes that was it!
Thanks a lot for the help!
I can now go back to my favorite editor :smile:


Return Standard as a pointer, instead of a value

Fixes #77

Codecov Report

Merging #78 into master will increase coverage by 0.21%.
The diff coverage is 61.53%.

@@            Coverage Diff             @@
##           master      #78      +/-   ##
==========================================
+ Coverage   58.52%   58.73%   +0.21%
==========================================
  Files         116      116
  Lines        6102     6102
==========================================
+ Hits         3571     3584      +13
+ Misses       1933     1924       -9
+ Partials      598      594       -4

Impacted Files
Coverage Δ

pkg/wallet/transactions/coinbasetx.go
48.14% <0%> (ø)
:arrow_up:

pkg/gql/query/mempool.go
23.68% <0%> (ø)
:arrow_up:

pkg/wallet/transactions/standardtx.go
73.17% <0%> (ø)
:arrow_up:

pkg/wallet/transactions/bidtx.go
60% <100%> (ø)
:arrow_up:

pkg/wallet/transactions/staketx.go
57.89% <100%> (ø)
:arrow_up:

pkg/wallet/transactions/timelock.go
63.63% <100%> (ø)
:arrow_up:

pkg/wallet/wallet.go
47.88% <100%> (+1.69%)
:arrow_up:

pkg/gql/query/blocks.go
76.27% <100%> (ø)
:arrow_up:

pkg/core/consensus/selection/selector.go
70.93% <0%> (+2.32%)
:arrow_up:

... and 2 more

Continue to review full report at Codecov.

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


feat: support full text scan strategy

At some scenarios, we need to use config file to set icon instead of using SvgIcon directly.
Another scenario is that we may need to wrap a component of SvgIcon to set some extra style and props.
So I made an option scanStrategy to support these scenarios.
BTW, Thank you for made this awesome plugin.

Firstly, Thanks for your PR!
In my opinion, the developer should keep this icon name unique when using the text scan strategy, so we should remind the developer in the readme.md, what's more,  if the scan strategy can support function type, it will be wonderful!

Yes, a functional type maybe better, but i think maybe we need another PR. And I prefer leave this PR as simple as possible.