ovn-k8s-overlay: Flush the IP address of physical interface.

When we add a physical interface for a gateway, we copy
its IP address and MAC address and make it the IP address
and MAC address of the gateway router port in the logical space.
In the physical space, we add that interface as a port of br-int.
Once we do that, we should flush its IP address.
Signed-off-by: Gurucharan Shetty<EMAIL_ADDRESS>

Thanks, I was doing that manually so far.


Bump ks cli to version v0.0.58

https://github.com/kubesphere-sigs/ks/pull/241 fixed a potential issue that might cause the token of Jenkins to be empty.
See the release request https://github.com/kubesphere-sigs/ks-versions/pull/10
/kind bug
/label no-changelog

/cherrypick release-3.2


Fix issue where forms using url data have headers stripped

Build headers based on  this.props.component.data.headers and pass along to _formiojs2.default.request. Along with options for if formio JWT auth should be enabled.

I implemented this in the src directory in a way that is compatible with our other renderers.
https://github.com/formio/react-formio/commit/91a4dea662ec5ae7f97fd0c487ef6703a97a6e06


Respect Folders While Mystifying in Item Directory

Currently, if you mystify an item within a folder in the Item Directory, the mystified item appears in the parent Item Directory folder.  It would be helpful if the mystified item was in the same folder as the original, identified item.
Nice module, thanks.

I have discovered the 'replace' feature does this, never mind!


Search for specific title

Is it possible to search for specific movie or TV titles based off exact matches of the text that you provide?  So far my testing on just_watch.search_for_item withquery and original_title it always seems to return all results that match any of the words, for example:
from justwatch import JustWatch

just_watch = JustWatch(country='US')

results = just_watch.search_for_item(
    query = "Ant-Man and the Wasp",
    original_title="Ant-Man and the Wasp",
    content_types=['movie'],
    monetization_types=["flatrate","free","ads"])

print(results.items())

dict_items([('page', 0), ('total_results', 2629), ('total_pages', 0), ('items',

Will try and find out if there is an end point for an exact query. If not, ill try and write some logic to get an exact result 👍


ebpf-profiler InvalidArgument

(base) [root@MiWiFi-RA80-srv opentelemetry-ebpf-profiler]# sudo ./ebpf-profiler -collection-agent=<IP_ADDRESS>:11000 -disable-tls
INFO[0000] Starting OTEL profiling agent v0.0.0 (revision main-bdecd683, build timestamp<PHONE_NUMBER>)
INFO[0000] Interpreter tracers: perl,php,python,hotspot,ruby,v8,dotnet
INFO[0000] Found offsets: task stack 0x28, pt_regs 0x3f58, tpbase 0x1828
INFO[0000] Supports generic eBPF map batch operations
INFO[0000] Supports LPM trie eBPF map batch operations
INFO[0000] eBPF tracer loaded
INFO[0000] Attached tracer program
INFO[0000] Attached sched monitor
WARN[0000] /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so: unable to read JVMCI VM structs: unable to find string for heuristic
ERRO[0009] Request failed: rpc error: code = InvalidArgument desc = failed to get process.executable.build_id.profiling from attributes_tables for mapping

OS: rocky 9.4
Kernel: 5.14

Hi @yunzck8s This looks like you are using an incompatible version combination of ebpf-profiler and devfiler. Can you please fetch the latest devfiler version and try again?
https://upload.elastic.co/d/f8aa0c386baa808a616ca29f86b34c726edb5af36f8840a4cf28468ad534a4b5
Authentication token: 2635c0750bf8ea69

@florianl Okay! Thanks.


Recent VSCode updates have some unthemed elements

Since this theme is a bit outdated now, it's starting to show some missing bits. Most notable now is the new sidebar feature where sections are missing separators.
Is there any chance of this theme being updated? It's by far my favorite out of the many pages of themes I have scrolled through - too many of them are either too bright/blue or are solid black. This theme is the perfect medium.

Hi @robmonte. I'm not the original maintainer of the theme, but this is my favorite theme as well, and since it did not receive updates for a long time, I decided to make a fork that I'm going to try to keep updated. If this is still relevant to you, would you mind opening an issue at this repository and elaborate a little bit more? 😄

@mxthevs I made an issue on your fork


Refactor all test assertions to use Fluent Assertions

The reason is assertion in xUnit have limited abilities (e.g. assert if collection is equal regardless item order). After evaluate https://github.com/shouldly/shouldly and https://fluentassertions.com found out Fluent Assertions looks better due to the following reason:

Shouldly required PDB file.
Fluent Assertions have better API design (e.g. good decoupling).
Fluent Assertions have more features (e.g. collection equality regardless order).

After using Fluent Assertions for a while seem like we still need xUnit assertions due to sometime we need the simplify one.


Single float value in numba Dict

I am trying to set a dictionary with int64 as keys and single precision float32 as values.
For example:
from numba.typed import Dict
from numba import types
dict = Dict.empty(
key_type=types.int64,
value_type=types.float32
)
When I assign one single precision value for example to dict[0]
and check what is in dict[0] I find the double precision version of the value.
Curiously if I print with a format identifier %f a single precision value is printed,
but dict[0] is truly a double precision value.
here is a minimal reproducer, I use numba 0.49.0
numba_Dict_float32.txt

When returning a numba.types.float32 from compiled code, Numba will use the python float representation, which is double-precision. So when reading dict[0] from the non-compiled code, you will see a double-precision value.  The reason being that there is no builtin single-precision float type in Python and the numpy.float32 type is very slow.
As for print formatting, it is not an accurate way to tell if the value is single or double precision. You are seeing the difference in decimal precision of the formatter.

Are you suggesting that it is only a matter of print formatting and that numba.typeof should produce a different response? numba.typeof seems to indicate that the type has changed:
numba_Dict_float32_typeof.txt

@oiluigio RE formatting in GitHub issues, for future reference triple backticks can be used to create a code block (with optional language syntax specified), for example: ```python <your code> ```. GitHub also has a basic guide to its markdown syntax available here.
This is your last posted example in such a code block:
import numpy as np
import numba as nb
from numba.typed import Dict
from numba import types

dict = Dict.empty(
    key_type=types.int64,
    value_type=types.float32
)

value = types.float32(np.random.rand())
value_type = nb.typeof(value)
print("value is %f, according to numba.typeof type is %s "%(value,value_type))

dict[0] = value
print("I assign value to dict[0]")
print("If I use formatted print value of dict[0] is %lf"%dict[0])
print("If I use plain print value with no formatting dict[0] is ", end ='')
print(dict[0])
print("According to numba.typeof type of dict[0] is %s" %nb.typeof(dict[0]))

RE: https://github.com/numba/numba/issues/5594#issuecomment-617046344
@oiluigio, yes, it's mostly a matter of formatting and the change of type (float32 being returned as float64) is a quirk with Numba that will not result in a loss of precision.
When I run your script, I got:
value is 0.876713, according to numba.typeof type is float32
I assign value to dict[0]
If I use formatted print value of dict[0] is 0.876713
If I use plain print value with no formatting dict[0] is 0.8767133951187134
According to numba.typeof type of dict[0] is float64

In [2]: str(0.876713)
Out[2]: '0.876713'

In [3]: print(0.876713)
0.876713

# Formatting for float32
In [4]: str(np.float32(0.876713))
Out[4]: '0.876713'

# Formatting for float64
In [5]: str(np.float64(np.float32(0.876713)))
Out[5]: '0.8767129778862'

# Values are equal?
In [6]: np.float64(np.float32(0.876713)) == np.float32(0.876713)
Out[6]: True


Dangerous "name" (and potentially others) global

TypeScript Version:  2.6.0-dev.20170913
Code
if (name === "asdf") {
  console.log("asdf")
}

https://www.typescriptlang.org/play/#src=if (name %3D%3D%3D "asdf") {%0D%0A console.log('hello')%0D%0A}
Expected behavior:
Error out
Actual behavior:
More than once, I had a "local" variable called name, outside a block scope, and it didn't warn me that it's not defined (or used before declaration). even though, in my code, event.name is a string, the global name variable is of type never. it's defined in lib.dom.d.ts, along with other "juicy" global names that will provide some confusion, like length, external, event, closed

one 'fix' (that would be a breaking change) would to make lib.dom-globals.d.ts (the propertiers that are usually accessible through window variable) and make it an opt-in in tsconfig.json compilerOptions.lib array

Duplicate of #9850

that didn't fix the problem. you can still use the variable and the nightly will happily use it without complaining

We keep going around on this and need to come up with something that really solves the issue

Spoke with @mhegazy - let's change it to void so it's not comparable to anything?

how about a tiny breaking change for 2.6 and separate the global DOM declarations into another lib file? is it feasible?

how about a tiny breaking change for 2.6 and separate the global DOM declarations into another lib file? is it feasible?

u can do this today with --lib es6 that does not include the dom.

but I have typings that rely on DOM stuff, even if it's not actually used in node.js (like pouchdb), but there are many other isomorphic typings

Well then you include the DOM library... It doesn't make any sense to have a partial DOM library, or even a globals DOM library...  Because I am assuming you aren't suggesting that the global window and document get moved to this separate global DOM declarations lib file.  Why only half model something?  That sounds very dangerous.

properties of "window" that are considered globals is there, under window global. you shouldn't be using globals anyway. how is that dangerous? you should be using window.name and not name anyway. or window.menubar instead of menubar. classes(ish) are properly named, like Blob, Uint8Array, JSON, and you know you won't be crossing with those by mistake

if you DO want to use browser globals like it's 1999, it's up to you to include the legacy way of accessing global variables that are actually under window

Not using them doesn't make them go away... So you are suggesting that the libraries not reflect the actual environment?

not sure if trolling or serious.

You implied breaking out the DOM definitions.  Mohammed told you how you can do that today.  You then implied that wasn't good enough and seemed to imply something else, like that the global you don't like be located in a separate library file.  Why do that, or more specifically what are you suggesting, because it appears to make no sense to me.

void is a slightly safer type than never, so we'll change this. Should also modify length since it's also problematic

Can you remember #15424?

I guess string | void is better than void.

string | void will still allow string writes

Should it be never | void?
Aside from anything, it sounds REALLY cool — might sell some T-shirts and other memorabilia.

Certainly string | void is not perfect for type safety of local variables but it has a good balance between type safety and usability of global name variable. So I think it is also reasonable.

@falsandtru the global name can be accessed/assigned via typecast with little to no fuss. TS even elides any extra brackets.
Signalling up both name and length would be really helpful in real life code: people do make those errors. Creative declaration for name is a cheap way to get there, alternatively the compiler may have a special handling just for these specific globals.

name: void is also acceptable for me.

A patch exists here: https://github.com/Microsoft/TSJS-lib-generator/pull/240

Simple suggestion: remove name and length declarations altogether. That will error on any use of name/length in global scope, and with a very obvious error message.
Whoever wants to shoot themselves in the foot — they bring their own gun.

Besides, look at this misleading error you get in current TS:
myname = 'Allen'
~~~~~~
Cannot find name 'myname'. Did you mean 'name'?

The existing declaration trickery pushes people into using name global. Not ideal.

@mihailik insufficient because you can still do this
var name;
if (someCond) { name = "hello"; }
if (name !== undefined) {
  // unreachable

Not to complain, but how would name being void in the global scope prevent that logic error?  The local name would mask the global.  I could see people getting confused with some sort of block scoped let or const with name that would be a problem, like:
if (someCond) { let name = "hello"; }
if (name !== undefined) {
  // unreachable

@RyanCavanaugh @kitsonk these are very synthetic cases may safely be left out of scope here.
The current never approach can be improved significantly by un-declaring name — that would cover more use cases than never, and provide much better errors.
If you're suggesting special-casing name at the compiler level, that's even better, but much much more work, testing than deleting a line.

This doesn't happen as often, but it's also bad to undeclare because name converts values to string on writes, i.e.
var name = 10;
if (name === 10) { // unreachable because name is "10"

@RyanCavanaugh are we missing a point here? The proper 100% correct declaration for name is:
declare var name: string;

Anything different is a lie and has downsides. What I am saying cost/value is best for 'undeclare' lie:

Very good error message
Wide coverage of use cases
Cases where it breaks are synthetic and unlikely in normal browser code

Comparing with either void or never there's more benefits and less downsides. You can special-case global name usage in compiler guts, but it's probably quite a lot of work?
Keep in mind, name is browser-specific. And even in browser it can be deleted, after which your examples would be actually fine: delete name; var name = 10; will actually store numerical 10 in name.

I just got bit by this:
const foo = "bar" + name;

Expected: compiler error
Actual: NBD
I dont know how else name can bite people, but I would definitely vote for removing it from lib.d.ts. Even if its technically correct, it is completely bad to have it this way.
If we are going to continue keeping it, perhaps things like adding a never to a string could be a compile error?

Don't forget about the event global.
Just recently I've fixed a bug along the lines of:
events.subscribe(e => {
  if (event instanceof MyEventType) {
    // ...
  }
});

Please, let's simply get rid of them completely. Why keep them in the declarations?

if someone is using Typescript to write legacy IE code, oh boy..... they should be slapped around a bit with a large trout

Can someone explain to me why we even need declare const name: never in lib.dom.ts? It makes no sense to me why we even have that.

@ccorcos Please read the thread; there are multiple examples of bad behavior if the name declaration isn't there

@RyanCavanaugh On the other hand, it seems safe to remove event, doesn't it?

Maybe I'm naive but would it make sense to introduce something like a Forbidden type meaning that any use of the variable should raise a TS error?

wow, just got bitten by this one again, this time on the server side

Now that unknown type has been introduced, would it be a solution to affect this type to window.name and other similar variables?

Yes! If you'd like to send us a PR, please feel free to make the change here and follow the appropriate instructions.

but again, making it unknown is wrong (in the sense of being a real global name in browser scenarios). what is the problem again in having a lib.dom-globals.d.ts lib apart from lib.dom.d.ts? it's something specific that you'd manually add to your libs tsconfig.json

@mhegazy there was an argument for that a while ago: https://github.com/Microsoft/TypeScript/issues/18433#issuecomment-336393249

I think we are just trying to be too clever here. just remove the damn thing :)

Hello guys,
Any progress on this? I came across this issue today. Took me 15 minutes to figure it out 😢
Cheers,

just happened again, this time with close global, tried to call it, it's declared in lib.dom.d.ts as declare function close(): void;

@hyurl some libraries are isomorphic, meaning they are made for the browser and node.js, so removing lib.dom.d.ts isn't something you can do at will

@pocesar Such a library must explicitly include dom lib as I've tried, otherwise, the compilation will fail.

I'm getting this with React 16, <Component value={name}/>. Why is the type checker not complaining that never is being assigned to string, even though my Component's props declare value as string?

something weird happened just now, I had an event called "onSelect", but typescript accepted the global "onselect" (from window.onselect). another one that bit me. it's "null" by default, and my props were | null, took me a while to find this

another one happened to me, my electron window was being closed after my react element was unmount, I had this piece of code:
  const closeAll = useCallback(() => {
    while (unpipes.current.length) {
      const p = unpipes.current.shift()
      if (p) {
        p()
      }
    }

    while (conn.current.length) {
      const p = conn.current.shift()
      if (p && p.close) {
        p.close()
      }
    }
  }, [conn, unpipes])

  useEffect(() => {
    return close
  }, [close])

can you spot the issue? I couldn't until wasting 8 hours trying to fix "the unfixable". close is window.close, and was executing when my component unmounted. the closeAll function was named close before, because it was a single ref and not a ref of an array with registered cleanup callbacks...

Perhaps we could get a compiler flag for noImplicitGlobalThis? Thus using name would be an error but if you want to use globalThis.name you could?

Forgot to destruct my variable 'name' from props and ended up using the global name variable instead. To me it's obviously a very bad idea to have globals with such common variable names as 'name' and 'length'.
Any plans on removing them and letting people access them through window instead? Or have they been already in later versions (I'm using v2.8.3)

the issue is much bigger than it appears to be, since it can ship broken software. even with all the strict functions enabled, and using tslint as well...

This is an obvious BUG, admit it

I agree with this being a bug, even with name being defined as never one can still write code which compiles and results in runtime issues. Consider following examples:
// ------- 1 -------
interface Foo {
    foo: object;
}
const foo: Foo = {
    foo: name
};

// ------- 2 -------
function a(foo: string) {}
a(name);

// ------- 3 -------
function b(params: {foo: string}) {}
b({ foo: name });

All 3 compiles perfectly. All 3 should be compile-time errors instead (not linting errors!) because they are directly related to symbol/type resolution (which is compiler's domain).

I am still unsure why unknown wouldn’t be a better type than never.

this issue missed the timing for a breaking change before wide adoption of TS... we have dom.iterable, that you must provide if you want to iterate using document.querySelector[All], but we don't have dom.globals...

Same on this one🤦🏻♂

I've just been bitten by this, and I'm not even writing TS, I'm using VSCode's type-checking support for plain JS.  I was very suprised to find status was seemingly completely OK, due to being defined in lib.dom-globals.d.ts, and I introduced a bug where I should've been referring to statusCode defined a couple of lines above!

The current functionality has allowed some bugs in our codebase. "name", "length" & "error" being global variables seems like ancient technology to me. Is anybody using TypeScript and still accessing these?
Here's our workaround using an ESLint rule:
"no-restricted-globals": ["closed", "error", "event", "fdescribe", "name", "length", "location", "parent", "top", ],

This just got me in a node project. ReferenceError: name is not defined. I'll be using @thatodieguyspj's ESLint rule, thanks for that!

Experienced dev new to Typescript, just bit by this. I have no position on how this should be improved, but the current behavior is a bad dev experience to the point where it should absolutely be changed.
Names like, well, "name", are extremely common; it's a massive footgun for code to compile successfully and then error at runtime due to what is substantially an undefined variable, even if this global type definition makes sense in the historical context.

If anyone would argue that changing this may lead to unexpected errors for historical projects, I'd like to say that those projects are buggy by themselves.

We keep going around on this and need to come up with something that really solves the issue

@RyanCavanaugh
With PR #40402, we can type those variables as declare const name: throw "using of global deprecated 'name'" and once people use that accidentally console.log(name), it will immediately generate a diagnostic instead of resolving to a never type. How do you think?

#40468 but it requires changes in libdom.d.ts and not easy to i18n

@sandersn this shouldn't be closed, there are many globals that should be changed

I'm cool with keeping it open (it auto-closed) for discussion about the rest of the values, name I think is definitely the worst-case offender in there

how about a tiny breaking change for 2.6 and separate the global DOM declarations into another lib file? is it feasible?

For anyone interested, discussion on ideas for addressing globals in lib.dom is the main topic of discussion in #14306 :)

Thanks for the pointer @david-fong .  IMHO this issue should be closed in favor of that one, or, frankly, both should be closed as wont-fix. I think the eslint rule fully solves the actual problem, which is that implicit window scope is one of The Bad Parts of JS -- valid, but should be discouraged.  That places it squarely in the wheelhouse of a linter, rather than a TS compiler option.
Look at discussions on other issues that want to catch code that has a bad smell but isn't actually wrong, like #13778.  When you add a check like this to the compiler, you're going to either break a lot of code, or put it behind a disabled-by-default flag. New flags will cause a split, where some packages were compiled with it turned off, so now consuming code has to either bug maintainers to change their projects to comply with a flag they didn't ask for, or turn on skipLibCheck (because there's no way to opt-out of checking for a single dependency).
tl;dr: this is better addressed by a linter rule, which is already available.

Those are great points. I didn't think of that. I don't think the lib.dom-strict option mentioned in that discussion would suffer from those problems though- would they? What I like about it is that it seems like it would be very simple to implement in the ts lib generator.
I think it would be great if you paste your comment into #14306 along with your thoughts on the lib.dom-strict option.

I'm not an expert but I think if you fork lib.dom, or split it such that some people are using "bad parts" of the global namespace while others aren't, you open yourself up to the same issues.  Let's say I depend on some-lib and it includes a call to doStuff(name), intentionally referring to window.name using shorthand.  They built their lib using an older version of TS, or they consciously included lib.dom-strict.d, but your consuming project avoids including the "strict" lib.  Without skipLibCheck, the typechecker is going to descend into your dependency and flag the reference to name as an error.

Let's continue this discussion in 14306.


No module named 'playwright' in 0.39.21

Describe the bug
After successfully pulling latest version by docker-compose pull && docker-compose up -d, all sites checking with Playwright stopped working
Version
0.39.21
Screenshots

OS: Orange Pi 3.0.6 Bullseye (Debian)

Solved with <IP_ADDRESS>


Adding all the IndexManagement plugin permissions

Signed-off-by: Ravi Thaluru<EMAIL_ADDRESS>opensearch-project/security-dashboards-plugin pull request intake form
Please provide as much details as possible to get feedback/acceptance on your PR quickly

Category: (Enhancement, New feature, Bug fix, Test fix, Refactoring, Maintenance, Documentation)
Maintenance

Github Issue # or road-map entry, if available:
N/A

Description of changes:
Adding all relevant permissions user will need for successfully using IndexManagement plugin

Why these changes are required?
IndexManagement plugin is introducing new transport actions and fine grained security model, these new permissions will be used by users to successfully use IndexManagement plugin features

By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@thalurur sorry for being late to the review party. I see this has been open for almost half a year now. Is it still needed?

closing due to inactivity for now.
@thalurur Please feel free to re-open if these changes are still needed. Thanks!


Fixed GLFW build on systems having lib64 set as the CMAKE_INSTALL_LIBDIR

I've checked this Git style guide. [Yes]
I've checked this CMake style guide. [Yes]
My change will work with CMake 3.2 (minimum requirement for Hunter). [Yes]
I will try to keep this pull request as small as possible and will try not to mix unrelated features. [Yes]

Released: https://github.com/ruslo/hunter/releases/tag/v0.23.105


objectGUID attribute conversion changed as of ldapjs 3.0

There seems to have changed something with returned values in ldapjs 3.x. I'm trying to convert the returned objectGUID value to a readable uuid string. All of my tried functions no longer return the correct objectGUID string, it's always off by a few characters / digits. Example:
crazyx13th function (https://github.com/ldapjs/node-ldapjs/issues/481#issuecomment-884041032) returns this: fd15fd05-5879-4866-fdfd-6afd1f61526f
but it should actually be this: f715f905-5879-4866-8cd8-6ae81f61526f
Any help would be appreciated as this bricks a lot of functionality in a new project using ldapjs 3.x
Strangely, the counterpart function I used to convert a string uuid into a Buffer (for e.g. ldap search queries that filter based on objectGUID) continue to work as expected. It's only the objectGUID to UUID method (e.g. crazyx13th variant) that returns slightly off values.
This could potentially be solved by getting the raw buffer object, although I can't seem to use entry.raw anymore (only entry.pojo).

I solved it:
Instead of requesting the attribute objectGUID I am now requesting the attribute objectGUID;binary, which returns the values as base64 which I can then correctly parse into a Buffer and translate into the GUID using the methods mentioned above (the crazyx13th and my old functions, they all work).

It is possible there was some data inspection done in the prior release that detected a binary attribute and handled it in some way. I don't recall seeing that, but it could very well be there. Regardless, with v3 we are being much more strict about following the RFCs. If a binary attribute is to be requested, it should be requested with the ;binary option as you have shown.
Regarding .raw vs .pojo: you should investigate the objects for the fields and such they support. In particular:

https://github.com/ldapjs/messages/blob/ec0d3f203bef83723c7e2a5d06955a3c9680a94d/lib/messages/search-result-entry.js
https://github.com/ldapjs/messages/blob/ec0d3f203bef83723c7e2a5d06955a3c9680a94d/lib/ldap-message.js#L10

The .attributes will return an array of https://github.com/ldapjs/attribute/blob/d1cba4723fb6953a932a71b53a8d842eeab564c7/index.js objects. Such objects have a .values property that will render binary attributes as encoded strings.

I solved it:
Instead of requesting the attribute objectGUID I am now requesting the attribute objectGUID;binary, which returns the values as base64 which I can then correctly parse into a Buffer and translate into the GUID using the methods mentioned above (the crazyx13th and my old functions, they all work).

how? Where are you using ;binary

how? Where are you using ;binary

Going through User objects and then going through the User's Attributes allows access with attribute.buffers[0].
The interface is really not documented well and is all over the place in multiple repos (some of which have zero docs). The spaghetti effect is real. The pojo object (terrible name change -ugh- wasn't documented well again) screws up the ability to get the buffers correctly.
Overall, I'm not a fan of this rewrite, but I'm at least finally able to get everything I need even if it's in a round-about way.


Idea: Replace Helmet with

Was toying around with next.js and it looks like they have some pretty nice components built out.
Their <Head> component is 9000 times easier to use than react <Helmet> https://github.com/zeit/next.js/blob/master/lib/head.js
It mimics raw html instead of weird config arrays like Helmet
// this just works like normal html... pretty cool!
<Head>
      <title>My page title</title>
      <meta name="viewport" content="initial-scale=1.0, width=device-width" />
      <script>
        console.log('hi')
      </script>
</Head>

I like this idea. Is there a way to make a proxy? (like phenomic/lib/head => next/head or something like this?)
Btw, curious how they handle next/head to be head/dist/lib/head.js

I will look.
The flat directory structure is achieved by publishing flat modules. The trick there is moving the projects package.json file into the built /lib's folder and npm publishing from there. (at least thats how I do it)

actually nvm. They have "main": "./dist/lib/index.js", in their package (which doesn't seem to exist)

So not sure how that works heh.
But I have published flat packages with my method =P. npm version patch runs through my method below:
  "scripts": {
    "preversion": "npm run build",
    "postversion": "git push && git push --tags && npm run dist",
    "predist": "cp -rf package.json lib",
    "dist": "cd lib && npm publish && echo 'New Version Deployed to NPM!'"
  }

This makes the npm publish command run from my built output folder inside of my project root

@DavidWells you are going to be very happy with new helmet api https://github.com/nfl/react-helmet

helmet v5 is just like next/head api


CI: Investigate JRuby + Ubuntu 22 issues with Typhoeus

WIth commit https://github.com/newrelic/newrelic-ruby-agent/pull/1354/commits/8a8325e7aad156155026c69991cfc1c09a7adb1f, the Typhoeus multiverse suite will now be skipped if JRuby and Ubuntu 22 are involved in the CI run (and they are both involved by default).
We should get to the bottom of why specifically JRuby + Ubuntu 22 + Typhoeus + newrelic_rpm isn't working in the hopes of at least restoring partial testing for that combo. It could be that only a specific old version of Typhoeus is problematic and we can simply have a version cut off in the tests and update our supported libraries documentation appropriately.

We don't have enough customers with the combination causing the test failure to put effort toward this. We will reconsider if we receive a customer request.


Switch to jest

Coverage decreased (-3.9%) to 92.561% when pulling 1a176da09affc1022094be4a98bd9a7daf219032 on switch_to_jest into 9f8e5588763a9879ba959287533c85b97c17b430 on master.

Coverage decreased (-3.7%) to 92.767% when pulling ec3ef7bd0e7e43a8092443912ca61c268c9ef2d6 on switch_to_jest into 9f8e5588763a9879ba959287533c85b97c17b430 on master.

Coverage increased (+0.3%) to 96.745% when pulling 6d495a942c174df27bf5076dc1bf26f2205b5ecf on switch_to_jest into 9f8e5588763a9879ba959287533c85b97c17b430 on master.


Replace the IoVec struct with IoSlice and IoSliceMut from the standard library

As per discussion in #1637, the IoVec<&[u8]> and IoVec<&mut [u8]> types have been replaced with std::io::IoSlice and IoSliceMut, respectively. Notable changes made in this pull request include:

The complete replacement of IoVec with IoSlice* types in both public API, private API, and tests.
Replacing IoVec with IoSlice in docs.
Replacing &[IoVec<&mut [u8]>] with &mut [IoSliceMut], note that the slice requires a mutable reference now. This is how it's done in the standard library, and there might be a soundness issue in doing it the other way.

Resolves #1637

Checks appear to be failing because IoSlice does not implement Hash, PartialEq, and some other common traits. Not sure how it would be preferred to respond to this.

The CI errors appear to be due to a clippy error unrelated to this pull request.

The CI errors appear to be due to a clippy error unrelated to this pull request.

I don't think so.  I think those errors were introduced by this PR.  nmount uses IoVec/IoSlice.

Remainder of CI failures appear to be due to the aforementioned clippy error

The ptrace warning is fixed in master.  You need to rebase.

Is there anything else that I need to do here before I can merge this request?

Could you please rebase?  You've got some conflicts now, and a rebase will also fix the test failure on uclibc.

@notgull are you sure you rebased to the current master?  It doesn't look like it.

Should this be blocking the 0.24 release? It'd be nice to have the feature splits out the door.

@asomers will you have a chance to look at this in the next week or so? If not I can take a look; I agree with @SUPERCILEX that it'd be nice to get a 0.24.0 out soon (even if it means releasing a smaller 0.25.0 shortly thereafter).

Ok, it looks like you've made all requested changes and the tests pass.  Would you please squash now? Then we'll merge it.

Squashed and ready to rumble!

Thanks everyone for helping get 0.24 out! :)


是否有根据源码构建镜像/安装包的步骤的文档说明

Why you need it?
Is your feature request related to a problem? Please describe in details
How it could be?
A clear and concise description of what you want to happen. You can explain more about input of the feature, and output of it.
Other related information
Add any other context or screenshots about the feature request here.

https://github.com/seata/seata/blob/develop/distribution/Dockerfile

多谢指导


open source code？

Hello, when will the code be open sourced?

Hi there, the code will be released soon. Thank you!


Doesn't work

Calendar doesn't appear on click. Styles are not applied. No errors throw though

const DatePicker = require('react-datepicker');
const moment = require('moment');
require('react-datepicker/dist/react-datepicker.css');

class DP extends React.Component {
    render() {

        return (
            <div className={this.props.className}>
                <DatePicker
                    selected={this.state.startDate}
                    onChange={this.handleChange}
                    selectsStart
                    startDate={this.state.startDate}
                    endDate={this.state.endDate}
                />

            </div>
        );
    }

    handleChange (date) {
        this.setState({
            startDate: date,
        });
    }

    constructor(props) {
        super(props);
        this.state = {
            startDate: moment(),
            endDate: moment()
        };
    }

I have the same problem.
Although I see datepicker rendered in html but its' transform properties are calculated all wrong so datepicker is outside of the page.
Maybe something's wrong with tether.js?

Styles works)) And I'm not sure about it
 this.state = {             startDate: moment(),             endDate: moment()         };

Closing due inactivity.


shouldn`t be -0 the last item in the array?

Can you provide an example of what you're asking?

As far as javascript is concerned...
const testString = 'Why, hello there'
testString.slice(-1) //=> 'e'

So I believe the standard is there for starting negative lookups with -1. And since JS does not seem to consider a signed and unsigned version of a zero as different:
0 === -0 //=> true

It's best to start at -1.

@sindresorhus What I guess he means is the following
const array = ['foo', 'bar'];
console.log(array[-0]);
//=> 'bar'

console.log(array[-1]);
//=> foo

I'm 👎 on this as pointed out by @mtimofiiv, things like slice, substring, etc. all start with -1 for negative lookups, -0 is just weird.

Yeah, not going to happen, for all of the above reasons.


mime/multipart: diagnose missing boundary string

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
1.9
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
Linux amd64
What did you do?
Instantiating a multipart.Reader with an empty boundary, as might happen in the case of an invalid Content-Type header, such as the following:
Content-Type: multipart/related

does not result in an error. My reading of RFC 2046 suggests that the boundary must be at least one character:

The only mandatory global parameter for the "multipart" media type is
the boundary parameter, which consists of 1 to 70 characters from a
set of characters known to be very robust through mail gateways, and
NOT ending with white space.

What did you expect to see?
I would have expected an error on the first call to NextPart(), as the reader was instantiated with invalid sate.
What did you see instead?
No error.
Perhaps this isn't the right place to do such a check.  Of note, there is also no check that the boundary conforms to any of the other constraints defined in RFC 2046. In particular, non-ASCII data is not guarded against, nor are boundaries greater than 70 characters in length.

NewReader cannot return an error. It could eventually return nil when boundary is empty but no reason would be given. The proposed fix returns a relevant error on the first call of NextPart.


5.2 removed option for "secure bundled script"

Version 5.2 does not provide an option to secure the bundled script.  Please add this functionality back.

This feature was useless and provided only the illusion of security. It was therefore removed, since it added complexity to the codebase without any benefits.
Just to be clear, anyone with a modicum of knowledge to can always view a clear-text version of the script.


Allocation rate increase after PR 1384

The https://github.com/elastic/apm-agent-java/pull/1384 PR introduced a performance regression for allocation rate, about extra 50 bytes per transactions are now allocated.

This is the culprit:
https://github.com/elastic/apm-agent-java/blob/2259495d153766fe36aa2833a0455394b2fadbb8/apm-agent-core/src/main/java/co/elastic/apm/agent/impl/transaction/TraceState.java#L70
As the sampling rate rarely changes, we could cache the whole tracestate entry, for example  es=s:0.1 if the sampling rate is set to 10%.


feat: add support for Endpoint Protector

solves https://github.com/splunk/splunk-connect-for-syslog/issues/2351

:tada: This PR is included in version 3.22.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Add feature vector extraction from user input

Not sure this should be part of our April 1 milestone. Comments?

Is this the idea of adding in an excel plugin?

Yes, but I am slowly coming to the realization that this might be out of scope for this course.

Out of scope. Maybe in some distant future, maybe....


[release-1.18] revert https://github.com/istio/istio/pull/43560

This is an automated cherry-pick of #44470

pull/43560 is available in release-1.18 and causing issues for or internal Istio fork. It seems pull/44470 and pull/44473 are not merged in release-1.18. This is the cherrypick of pull/44470, will also create cherry pick of pull/44473.


Wrong permission on new folders

Behaviour
Steps to reproduce this issue
Try to create a new folder through volume mount for several purpose (watch folder for autotools, post downloads scripts, ...)
Expected behaviour
The folder should be accessible from inside the container
Actual behaviour
The folder is not accessible because the permission remains the one from the user running the container and not the user inside the container. I didn't had this issue with the lsio's one or even this one in the past
Configuration

Docker version: 20.10.6
Docker compose version if applicable: 1.29.1
Platform (Debian 9, Ubuntu 18.04, ...) :  Debian 10

Logs

Same behavior if I mount it as a sub folder of the default "data" folder...

It is very strict in create folder inside container. FYI, there is already watch folder in /data/rtorrent/watch.
Because of these things I found that create any folder inside /downloads will works better. Otherwise you will need to edit /etc/cont-init.d/03-config.sh inside the container for granting permission at each start which is not recommended since it is shell script that make the container works.

Thanks for your contribution.
The existing watchfolder is the one used by rtorrent which doesn’t support recursive detection like rutorrent autotools does.
To avoid confusion, I would like to use another one like in the Linuxserver former image.
In addition, my request is going above watch folder, the same purpose could be used for post download scripts for example.
rtorrent is design for that and there is no place for such scripts in this image.
For all that reasons, I made a PR to make the chown, on the data folder, recursive to ensure the container can interact with everything which is inside.
Best

when first use this image, there is intructions to chown these folder:
chown ${PUID}:${PGID} data downloads passwd
you might want to do the same with your own folder if it is not inside those folder I think.

@the-lazy-fox

The folder is not accessible because the permission remains the one from the user running the container and not the user inside the container.

That's the purpose of a rootless image using specific a PUID/PGID. Also it's clearly specified in the README:

Note that the volumes should be owned by the user/group with the specified PUID and PGID. If you don't give the volumes correct permissions, the container may not start.

I therefore suggest that you adapt the PUID/PGID.


Fix CHECK_BSD_STYLE_MACROS for OpenBSD and cryptodev-linux

Fixes https://github.com/openssl/openssl/issues/8911
CLA: trivial
This fix works on:

FreeBSD, where both CRYPTO_ALGORITHM_MIN and CRYPTO_ALGORITHM_MAX are known to the preprocessor,
OpenBSD, where CRYPTO_ALGORITHM_MIN will be automatically set by the preprocessor to 0 (lower than the defined CRYPTO_ALGORITHM_MAX),
cryptodev-linux, where the preprocessor will set CRYPTO_ALGORITHM_MIN to 0 and CRYPTO_ALGORITHM_MAX to (0 - 1).

References:

https://github.com/freebsd/freebsd/blob/master/sys/opencrypto/cryptodev.h#L167-L209
https://github.com/openbsd/src/blob/master/sys/crypto/cryptodev.h#L108
https://github.com/cryptodev-linux/cryptodev-linux/blob/f971e0cd4a0ebe59fb2e8e17240399bf6901b09b/crypto/cryptodev.h#L57

Checklist

[ ] documentation is added or updated
[ ] tests are added or updated

In the commit message, I would suggest changing "Proposed fix for" to simply "Fixes".

Hi @Retropotenza
CLA: trivial needs to be added as a seperate line to the actual 'commit' message.

git commit --amend

Nope... git commit --amend -m "..." didn't seem to work unfortunately. Sorry for the multiple pushes here, at the end I remove one space to make a real commit. I hope that the continuous integration scripts will be successful now (they where before...).

Pushed c596b8d

1.1.1 branch
3268087d2cca5f5a882c9620849a12915a4ab0f1


Remove outdated Eclipse Che

Delete references, templates for old Che.
apb bundle prepare modifies Dockerfile.
Tested on v4 cluster.

@joshix Why do you want to remove Che? Shouldn't it be better to add Code Ready Workspaces instead of deleting it completely, if Che is old?

@jorgemoralespou 1) The che spec'd here doesn't work in deployments by @jankleinert and I (and you, I thought, based on earlier conversations).
2) It is my understanding that the Che deployed here is out of date, and that we would not reuse the existing Che bits in here to deploy Code Ready Workspaces (CRW).
3) Cleaning up the Che bits (this PR) is viewed as step one of potentially two, step two being later adding CRW.
I think #2 must be where I misunderstood you and/or the problem. If #2 is not true, then we should close this PR and leave the Che vestiges in place.

I'm ok with it. I'll test it in ocp 3.11 and if it works, I'll merge.


Use undo-redo

Instead of using 'undo-fu', you can just make evil use the undo-redo function that is inbuilt into Emacs 28.
Nobody wants excessive packages being loaded.

Not sure why I've decided to use undo-fu instead of undo-redo, but I'm sure I tried out both before settling with undo-fu.
I try not to use unnecessary packages, but in order to establish required functionality it's not a problem.


Support for webdriver desired_capability in gwen.properties

There should be some mechanism/configuration to support & configure webdriver desired_capabilities.
Below links contains information on the same.
https://github.com/SeleniumHQ/selenium/wiki/DesiredCapabilities

Please raise this in the gwen-web register (since it is web related) here https://github.com/gwen-interpreter/gwen-web. Then close this one. Thanks.

I have moved this to gwen-web
https://github.com/gwen-interpreter/gwen-web/issues/43


Fix API docs CSS files so dark mode works

Description
This fixes the https://master-api.flutter.dev site so that dark mode works properly.
It also re-enables the link button on samples so that you can deep link to a sample (the button was always there, but somehow got disabled and turned the same color as the background).
I've also adjusted the colors and fonts to be a bit closer to those of the main flutter.dev website.
Before:

Fixed Dark Mode:

Fixed Light Mode:

Related Issues

Fixes https://github.com/flutter/flutter/issues/111941

Tests

Fixed sanity test for snippets to be a little more lenient.

test-exempt: configuration change
...though it would be really nice to have some sort of actual end-to-end test for the docs, just so we catch it when we accidentally break search or whatever.


symbols dir in this repo seems unused

A minor detail that comes to my attention: symbols/ directory seems unused here
Hasn't it been moved to web repository?

Thanks - not sure how I didn't spot that!


Added a line about not supporting Azure Monitor Metrics as destination. in azure-monitor-agent-client-installer-limitations.md

Added a line about not supporting Azure Monitor Metrics as destination.

@guywi-ms
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@rboucher please review and approve.

#reassign: @rboucher


BUG: instance_vars does not work inside macro

It seems that trying to use (instance_vars)[https://crystal-lang.org/api/0.35.1/Crystal/Macros/TypeNode.html#instance_vars:ArrayLiteral(MetaVar)-instance-method] inside a macro like finished does not work.
Using the example code, I expanded it to include 3 new methods that defined in various ways using macros. Only 1 of them works as expected:
class Object
  def instance_vars_names
    {{ @type.instance_vars.map &.name.stringify }}
  end
end

class Person
  def initialize(@name : String, @age : Int32)
  end

  def vars
    {% for v in @type.instance_vars %}
    puts "vars: "+{{v.name.stringify}}
    {% end %}
  end

  macro finished
    def fin_vars
      {% for v in @type.instance_vars %}
      puts "fin_vars: "+{{v.name.stringify}}
      {% end %}
    end
  end

  macro def_meth
    def def_meth_vars
      {% for v in @type.instance_vars %}
      puts "def_meth: "+{{v.name.stringify}}
      {% end %}
    end
  end

  def_meth
end

person = Person.new "John", 30
puts person.instance_vars_names
person.vars
person.fin_vars
person.def_meth_vars

Output:
["name", "age"]
vars: name
vars: age

Expected output:
["name", "age"]
vars: name
vars: age
fin_vars: name
fin_vars: age
def_meth_vars: name
def_meth_vars: age

Crystal info:
crystal -v
Crystal 0.35.1 (2020-06-19)

LLVM: 10.0.0
Default target: x86_64-apple-macosx

This is expected I think.  You need to escape the macro code within the other macros so that it runs in the correct scope.  See https://play.crystal-lang.org/#/r/9e76.

This is expected I think. You need to escape the macro code within the other macros so that it runs in the correct scope. See https://play.crystal-lang.org/#/r/9e76.
That's extremely confusing. The whole point of finished is:

finished is invoked after instance variable types for all classes are known.

That's the exact time i would want to use instance_vars.
For example:
class Object
  def instance_vars_names
    {{ @type.instance_vars.map &.name.stringify }}
  end
end

class Person
  def initialize(@name : String, @age : Int32)
  end

  macro finished
    {% puts @type.instance_vars %}
  end
end

person = Person.new "John", 30
puts person.instance_vars_names

Output:
[]
["name", "age"]

@Blacksmoke16 thanks for pointing that out. I guess i can wrap it in verbatim for now. but it seems un-intuitive to me.

That doc is just misleading/wrong, see https://github.com/crystal-lang/crystal-book/pull/416

@kalinon I don't think you need macro finished at all in your code. It should work fine without it. And def_meth is not needed either. Just remove those macros and it works as you expect. Inside methods, @type.instance_vars will be what you expect.
Here's the working code:
class Object
  def instance_vars_names
    {{ @type.instance_vars.map &.name.stringify }}
  end
end

class Person
  def initialize(@name : String, @age : Int32)
  end

  def vars
    {% for v in @type.instance_vars %}
    puts "vars: "+{{v.name.stringify}}
    {% end %}
  end

  def fin_vars
    {% for v in @type.instance_vars %}
      puts "fin_vars: "+{{v.name.stringify}}
    {% end %}
  end

  def def_meth_vars
    {% for v in @type.instance_vars %}
      puts "def_meth: "+{{v.name.stringify}}
      {% end %}
  end
end

person = Person.new "John", 30
puts person.instance_vars_names
person.vars
person.fin_vars
person.def_meth_vars

Ah. @jhass i see. Yeah that's why i tried to use finished i wanted to ensure all instance variables were known. Since it doesnt work that way... i dont need to. Which is @asterite 's point.
I can close this as crystal-lang/crystal-book#416 fixes this misleading point.


chore(docs): update README to include details on Ember support

I thought it might be useful to link to an Ember addon (which I happen to maintain 😅) that adds heroicons integration within Ember apps. Thanks!

Hey, definitely understand the usefulness of having this in the readme. However, we'd definitely want to keep an eye on the package in case it falls out of date. Given that it is unofficial it wouldn't be as readily updatable by us. For now we're gonna hold off on adding any third-party versions of Heroicons to the readme. Appreciate the PR though! ✨
If anyone is searching for one Google would hopefully bring up this PR and/or your package on NPM.


Seed fixing

Description
This PR introduces seed fixing for parameter initialization across all layers. Each layer now includes an additional parameter, seed, which allows for setting a fixed seed for initializing its weights and biases. By default, seed is set to -1, which enables random initialization. If seed is set to a value greater than or equal to 0, it uses that value as the fixed seed.
I also modified the regression_heteros to show how to fix the seed.
net = Sequential(
        # Adding seed to every layer to make the results reproducible
        Linear(1, 128, seed=1),
        ReLU(),
        Linear(128, 128, seed=1),
        ReLU(),
        Linear(128, 2, seed=1),
        EvenExp()
    )

@davidwardan @van-dai-vuong Could you please verify that the seed fixing works in your cases? Also, could you review the code to ensure all cases are covered?

@miquelflorensa I just had a discussion with @jamesgoulet about the random seed issue. We come up with a potential solution to address it. We was thinking of using a SeedManager class like below. Note here that calling SeedManager::getInstance() multiple times does not create multiple instances but rather accesses the same instance each time. It is just an idea but you can test it out to see if it works. Feel free to make it better.
class SeedManager {
public:

    static SeedManager& get_instance() {
        static SeedManager instance;
        return instance;
    }

    void manual_seed(unsigned int seed) {
        global_random_engine.seed(seed);
    }

    std::mt19937& get_engine() {
        return global_random_engine;
    }

private:
    SeedManager() : global_random_engine(std::random_device{}()) {}
    // Delete copy constructor and assignment operator
    SeedManager(const SeedManager&) = delete;
    SeedManager& operator=(const SeedManager&) = delete;
    std::mt19937 global_random_engine;
};

std::tuple<std::vector<float>, std::vector<float>> gaussian_param_init_ni(
    float scale, float gain, float noise_gain, int N)
/* Parameter initialization of TAGI neural network including the noise's hidden
 * states
 *
 * Args:
 *    scale: Standard deviation for weight distribution
 *    gain: Multiplication factor
 *    N: Number of parameters
 *
 * Returns:
 *    m: Mean
 *    S: Variance
 */
{
    // Get generator
    std::mt19937& gen = SeedManager::getInstance().getEngine();

    // Initialize pointers
    std::vector<float> S(N);
    std::vector<float> m(N);

    // Weights
    for (int i = 0; i < N; i++) {
        // Variance for output and noise's hidden states
        if (i < N / 2) {
            S[i] = gain * pow(scale, 2);
        } else {
            S[i] = noise_gain * pow(scale, 2);
            scale = pow(S[i], 0.5);
        }

        // Get normal distribution
        std::normal_distribution<float> d(0.0f, scale);

        // Get sample for weights
        m[i] = d(gen);
    }

    return {m, S};
}

@davidwardan @van-dai-vuong Could you please verify that the seed fixing works in your cases? Also, could you review the code to ensure all cases are covered?

@miquelflorensa I am working on unittests for both Python and C++ (ETA: end of the week), so that we dont need to do manual checks anymore. I'll add you guys as reviewers when it is ready

@lhnguyen102 I just added a setter for the seed in the Sequential class that sets the seed for each layer. It works, but it might be a bit messy 😅. Creating a seed manager class could be a good solution too, but we’d lose the option to define a seed for individual layers easily (though I’m not sure if that’s something we’d ever want). Anyway, I’ll work on your solution tomorrow, and we can see which approach might be best.

@miquelflorensa after fixing the seed, I sill have different results for the test results, even if I did not shuffle data.

@miquelflorensa I'll let you to decide this issue. I think that we just want to (1) reproduce the same initial values for weights and biases for each layer given a random seed and (2) generate random and different values for each layer. I really like this approach from pytorch that sets a random seed for every thing
torch.manual_seed(42)

@lhnguyen102 Right now I am doing a setter in the sequential class like this:
net.manual_seed(0)

The problem is that it only works on GPU cause, because it needs to be set before creating the layers. Should I maybe create  a way to set the seed before even creating the model like:
pyTAGI_seed(0)

The problem is that it only works on GPU cause, because it needs to be set before creating the layers

@miquelflorensa I don't understand what you meant here. Why it does not work for CPU but GPU?. The way I look at this problem is that you currently  have to modified 45 files in order to achieve this randomization of parameters... a lot of changes for this problem and somehow complicated. I would test the SeedManager approach to see if it works because it requires changing a single file param_init.cpp

@lhnguyen102 Yes, I am currently working on the binding for just a Seed Manager class. I will tell you whenever I upload the changes.

@lhnguyen102, I’ve added the changes, but I have two questions: should we call it tagi.manual_seed(0) instead of SeedManager.manual_seed(0)? And for preprocessing functions that involve randomization, should they depend on this manual_seed function, or should we keep them separate and set the seed with np.random.seed(0)?

@miquelflorensa  I would call it pytagi.manual_seed(42) for python version and for c++ is up to you. In the python side, we will have to have to use the randomization function of external library since we wont provide the preprocessing in pytagi.

The real test will be the scenario where given a random seed, we have the same weights and biases for as many re-run on both CUDA and CPU.

@miquelflorensa I would call it pytagi.manual_seed(42) for python version and for c++ is up to you. In the python side, we will have to have to use the randomization function of external library since we wont provide the preprocessing in pytagi.

Done

What would you do? Would you initialize the layers during the first forward pass instead of during model construction?

@miquel-florensa As I understand, this  class SeedManager is a singleton pattern meanings it lives through out the application running. The random engine will automatically transition to another state when it gets called from any function. I think we can do much more simpler than the current implementation. I would implement  the following function that can serve as  binding code to Python i.e., pytagi.manual_seed(42) and the CPP runner. For CPP, taking an example of mnist classification test/fnn/test_fnn_mnist_cpu.cpp, we just need to set a seed at the beginning of the script. As you can see, both Python and CPP behave the same way. If we dont manually set the seed, it will randomly be assigned a seed std::random_device{}()
void manual_seed(int seed) {
    SeedManager::get_instance().set_seed(seed);
}

@miquelflorensa Could you please add the following code for cuda detection in this PR, I dont want to create a PR for it, I would put it in src/common.cpp and create a binding code for Python as well. Thank you!
bool is_cuda_available() {
#ifdef USE_CUDA
    return true;
#else
    return false;
#endif
}

@lhnguyen102 I added the manual_seed and is_cuda_available functions on common.cpp and added their bindings on utils bindings (don't know if we should create another bindings file for them). On the other hand I added a reset_seed function that reinitialize the randomizer so when the device is switch to cuda it creates the same parameters as in c++ (I know the way I did it is not the cleanest, I will think on a better solution tomorrow).

@miquelflorensa it is nice to have a reset_seed().I take a look at the CUDA code. The problem with CUDA layer is that it will initialize once again weights and biases when model.to_device("cuda") e.g., linear layer. As you insist on having a clean manual seed setting for both CPP and CUDA, I think you can transfer weights and biases from CPP layer directly to CUDA layer. Here are my suggestions

Implement a copying function in BaseLayerCuda class that copies all weights and biases to CUDA layer and sending it to device
Call the previous function here
Remove the initializing function for weights and biases in here
I am OK with the currently implementation that you did. However, I never say no to a better solution. Feel free to get creative on the solution because I only provide the my view based on my exp on cuTAGI!

@lhnguyen102 I made a copy_params_from function that is called from to_cuda functions in Linear and LSTM as you said.

@miquelflorensa It looks perfect to me. Any reason that we cannot apply the same technique to conv2d and tconv2d?

@lhnguyen102 I didn’t implement it for the Conv2d and TConv2d layers because parameter initialization is currently handled during the first forward pass. However, I’m now considering whether it might be easier to move all parameter initialization into the forward function. Or should we move them to the constructor of the layer instead?

@miquel-florensa you can remove this section and use the copy function for initializing the parameters. The only thing now we need to take care is the this->allocate_param_delta(). This function can be found here. A solution is to set a condition to trigger this allocation in the forward pass
if (this->training && this->delta_mu_w.size() == 0) {
    this->allocate_param_delta();
}

@lhnguyen102 I’m still unsure why we need to use the copy functions in Conv and TransposeConv. Since both layers initialize their parameters during the forward pass, they are already on the desired device (CUDA or CPU). I tested the current setup, and the initialization works equally on both devices without issues. Also, I rebased my branch with the latest main version, but now all your changes are appearing in this PR as well. Not sure why that’s happening.

@miquel-florensa You're rights! I was overthinking.

Also, I rebased my branch with the latest main version, but now all your changes are appearing in this PR as well. Not sure why that’s happening.

This is weird and it marked that your branch is out-of-date with the base branch.

@lhnguyen102 Ok, now it's good.

@miquelflorensa how did you do it? :)

@lhnguyen102 I went back to the previous commit and I rebased from this same page in GitHub, where there was a button to rebase :)


Update MD file on new branch 2017-12-02_11-30-28

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestRef1.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


OBS data missing

Describe Your Problem:
There are two issues that I am working through. The first is that when I create a new sensor, the humidity sensor is no longer an option. I only see Temp, Fan, and Light. If it try to manually update the json under advanced to create the humidity sensor, that doesnt work either.
The second issue is that when the API tries to connect for the first time, it returns a message that OBS data is missing.
Logs:
12/7/2022, 1:26:47 PMLaxton-HoobsWeatherFlow Tempest PlatformFinished initializing platform: WeatherFlow Tempest Platform
12/7/2022, 1:26:47 PMLaxton-HoobsWeatherFlow Tempest PlatformTempestApi initialized.
12/7/2022, 1:26:47 PMLaxton-HoobsWeatherFlow Tempest PlatformLoading accessory from cache: Outside Temperature
12/7/2022, 1:26:47 PMLaxton-HoobsWeatherFlow Tempest PlatformLoading accessory from cache: Outside Relative Humidity
12/7/2022, 1:26:47 PMLaxton-HoobsWeatherFlow Tempest PlatformLoading accessory from cache: Outside Light Level
12/7/2022, 1:26:47 PMLaxton-HoobsWeatherFlow Tempest PlatformLoading accessory from cache: Outside Wind Speed
12/7/2022, 1:26:47 PMLaxton-HoobsWeatherFlow Tempest PlatformExecuted didFinishLaunching callback
12/7/2022, 1:26:48 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:26:48 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 1 of 30. No cached "obs" data.
12/7/2022, 1:26:48 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:26:48 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 2 of 30. No cached "obs" data.
12/7/2022, 1:26:51 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:26:51 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 3 of 30. No cached "obs" data.
12/7/2022, 1:26:55 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:26:55 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 4 of 30. No cached "obs" data.
12/7/2022, 1:26:58 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:26:58 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 5 of 30. No cached "obs" data.
12/7/2022, 1:27:02 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:27:02 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 6 of 30. No cached "obs" data.
12/7/2022, 1:27:07 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:27:07 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 7 of 30. No cached "obs" data.
12/7/2022, 1:27:14 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:27:14 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 8 of 30. No cached "obs" data.
12/7/2022, 1:27:21 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:27:21 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 9 of 30. No cached "obs" data.
12/7/2022, 1:27:29 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:27:29 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 10 of 30. No cached "obs" data.
12/7/2022, 1:27:38 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:27:38 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 11 of 30. No cached "obs" data.
12/7/2022, 1:27:48 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:27:48 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 12 of 30. No cached "obs" data.
12/7/2022, 1:27:59 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:27:59 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 13 of 30. No cached "obs" data.
12/7/2022, 1:28:11 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:28:11 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 14 of 30. No cached "obs" data.
12/7/2022, 1:28:24 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:28:24 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 15 of 30. No cached "obs" data.
12/7/2022, 1:28:39 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:28:39 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 16 of 30. No cached "obs" data.
12/7/2022, 1:28:54 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:28:54 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 17 of 30. No cached "obs" data.
12/7/2022, 1:29:10 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:29:10 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 18 of 30. No cached "obs" data.
12/7/2022, 1:29:27 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:29:27 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 19 of 30. No cached "obs" data.
12/7/2022, 1:29:45 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:29:45 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 20 of 30. No cached "obs" data.
12/7/2022, 1:30:04 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:30:04 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 21 of 30. No cached "obs" data.
12/7/2022, 1:30:24 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:30:24 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 22 of 30. No cached "obs" data.
12/7/2022, 1:30:45 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:30:45 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 23 of 30. No cached "obs" data.
12/7/2022, 1:31:08 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:31:08 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 24 of 30. No cached "obs" data.
12/7/2022, 1:31:31 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:31:31 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 25 of 30. No cached "obs" data.
12/7/2022, 1:31:55 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:31:55 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 26 of 30. No cached "obs" data.
12/7/2022, 1:32:20 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:32:20 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 27 of 30. No cached "obs" data.
12/7/2022, 1:32:46 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:32:46 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 28 of 30. No cached "obs" data.
12/7/2022, 1:33:13 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:33:13 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 29 of 30. No cached "obs" data.
12/7/2022, 1:33:41 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGResponse missing "obs" data.
12/7/2022, 1:33:41 PMLaxton-HoobsWeatherFlow Tempest PlatformWARNINGRetrying 30 of 30. No cached "obs" data.
12/7/2022, 1:34:10 PMLaxton-HoobsWeatherFlow Tempest PlatformERRORReached max API retries: 30. Stopping.
12/7/2022, 1:34:10 PMLaxton-HoobsWeatherFlow Tempest PlatformFailed to fetch initial Station Current Observations after retrying. Refusing to continue.

Plugin Config:
{
"platform": "WeatherFlowTempest",
"name": "WeatherFlow Tempest Platform",
"interval": 10,
"token": "72685be3-d674-4023-b475-e49160a8d324",
"station_id": "ST-00018457",
"sensors": [
{
"name": "Outside Temperature",
"sensor_type": "Temperature Sensor",
"value_key": "air_temperature"
},
{
"name": "Outside Relative Humidity",
"sensor_type": "",
"value_key": "relative_humidity"
},
{
"name": "Outside Light Level",
"sensor_type": "Light Sensor",
"value_key": "brightness"
},
{
"name": "Outside Wind Speed",
"sensor_type": "Fan",
"value_key": "wind_avg"
}
]
}
Screenshots:

Environment:

Plugin Version: 1.2.2
Homebridge Version:  4.2.8
Node.js Version:  16.18.1
NPM Version:  8.19.2
Operating System:  Rasbian

@npeach Hi thanks for submitting this. I believe the issue is with your Station ID. ST-00018457 does not look like a valid station ID. It should be an integer.
Please go to (https://tempestwx.com/settings/stations/)[https://tempestwx.com/settings/stations/] and click on your station. The URL should update to something like https://tempestwx.com/settings/station/<number>. That <number> is your Station ID.

Facepalm! ok that worked - thank you! the only other issue I am still
experiencing is that I can't set the sensor type for humidity, and so when
the api pulls the data into homebridge, homekit sees it as a temp.
Is there a way to use the motion sensor for windspeed vs. the fan sensor?
thank you !!
[image: Screenshot 2022-12-08 at 2.16.13 AM.png]
On Wed, Dec 7, 2022 at 5:14 PM Chase Nicholl @.***>
wrote:

@npeach https://github.com/npeach Hi thanks for submitting this. I
believe the issue is with your Station ID. ST-00018457 does not look like
a valid station ID. It should be an integer.
Please go to (
https://tempestwx.com/settings/stations/)[https://tempestwx.com/settings/stations/]
and click on your station. The URL should update to something like
https://tempestwx.com/settings/station/. That  is your
Station ID.
—
Reply to this email directly, view it on GitHub
https://github.com/chasenicholl/homebridge-weatherflow-tempest/issues/3#issuecomment-1341662954,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABHLEEYV4JIV2RWNT5APKBTWMED5ZANCNFSM6AAAAAASXFPBH4
.
You are receiving this because you were mentioned.Message ID:
@.***
com>

Really appreciate it! This is a great plugin :)
I can add the sensor type manually and restart. What that does is create
the correct sensor, but as soon as I restart for any reason, it reverts
back to a temp sensor.
on the fan - my thought was that the current sensor type showing up as a
controllable fan is a bit weird and because I have real fans in my home on
homekit, the display is a little awkward. Too bad homekit doesn't have a
true wind speed or rain accumulation sensor type yet.
When I wrote my last note, I was considering that if wind_avg was reported
as a motion event, then every time it would poll, the trigger could be
'motion' and an alert with the speed. If you have ever seen a co2 alert
within homekit - something like that. But I'm not sure that is right either.
Thanks for taking the time to respond!
On Thu, Dec 8, 2022 at 8:08 AM Chase Nicholl @.***>
wrote:

@npeach https://github.com/npeach Great glad that worked!
I'll continue to look into the GUI issue with the sensor types but in the
meantime, for sensor_type I'm noticing in your manual configuration file
the humidity sensor_type is an empty string. Can you try adding the value
of Humidity Sensor and restart?
I could expose a Motion Sensor Accessory. I'm thinking if I did that I
could add an additional attribute trigger_point which would let you
configure a wind speed you would want it to go on/off at? 🤔
—
Reply to this email directly, view it on GitHub
https://github.com/chasenicholl/homebridge-weatherflow-tempest/issues/3#issuecomment-1342711093,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABHLEE7WRBIWXTZATMZGFH3WMHMTBANCNFSM6AAAAAASXFPBH4
.
You are receiving this because you were mentioned.Message ID:
@.***
com>

Thanks!

I can add the sensor type manually and restart. What that does is create
the correct sensor, but as soon as I restart for any reason, it reverts
back to a temp sensor.

Very odd I can't reproduce this, at least not yet. What browser are you using and also what version of homebridge-config-ui-x are you running? Would you mind trying it in a different browser / make sure you are using the latest version etc?
Yes indeed its a shame Homekit doesn't support any Accessories that could be in your yard/outside, the options are very inside your Home orientated.
My little work around is I have an "Outside" room that a throw everything outside in and remove the info from my Home summary so it doesn't effect the averages etc.
🤔 I'd agree having an alert for every wind speed change would become too repetitive, so maybe not the right fit.
However, I felt inspired by your idea and I do plan to expose a Motion Sensor that lets you configure at which wind speed to trigger it. I could see this being useful for warning you of a storm, especially at night for say a Tornado/Huricane warning. e.g. You get a 80mph gust of wind, then you could trigger a home alarm.
I'll keep having a think about what accessories could be better used to display windspeed. 🤔

Closing please respond if https://github.com/chasenicholl/homebridge-weatherflow-tempest/releases/tag/v1.3.0 addresses drop down menu issue. Thank you!


EPIC: Visualization / interaction

Features

Description
reference
status
issues

Topology drawing / editing
https://web.chemdoodle.com/demos/sketcher/

3D geometry manipulation
moldesign.widgets.GeometryBuilder
Preliminary implementation

3D geometry measurement
VMD, Chimera, 3D CAD tools

low-level functionality

Description
reference
status
issues

More viewer UI events (right-click, drag, etc.)

Resizable / floating / pop-out / sticky viewers

#62

Widgets not blocked by cell execution
Threading example, ipython/ipywidgets#642

#30

Improve trajectory animation performance

Miscellaneous
API to export movie files (mp4, etc.) from trajectory animations
API to render high-quality ray-traced images
API to export STL files for printing
Clickable graphs linked to widgets - #71

This will likely flow backwards from MST, and will soon be separated into a separate add-on project for MDT. Closing for now.


open-source: Stop quote used as image for feature from overflowing.

In small screens, the quote used as a standin for image used
to overflow from screen as it didn't had responsive size set.
This image has additional bound of max-width: 100% which
stops them from overflowing which the quote did not.
before:

after:

Merged, thanks @amanagr!


wallet slow to deploy: 22 minutes

Description
I provisioned a testnet client as usual using docker and the testnet faucet.
https://testnet.explorer.agoric.net/account/agoric13lk0cnmehvfqtpcynwq7hx6qu86qtw3cu00qxe
Getting the wallet fully deployed took 22 minutes:
2021-08-24T15:39:35.513Z chain-cosmos-sdk: delivering to chain (trips=1)
...
2021-08-24T15:51:51.716Z chain-cosmos-sdk: delivering to chain (trips=20)
...
2021-08-24T16:01:27.652Z chain-cosmos-sdk: delivering to chain (trips=32)

Expected behavior
Didn't this used to take more like 5 minutes?
Desktop

OS: Ubuntu linux 18.04; docker
Browser: chrome

$ ag-cosmos-helper version --long
name: agoriccosmos
server_name: ag-cosmos-helper
version: 0.26.9
commit: 08ea8bbc8
build_tags: ledger,
go: go version go1.15.8 linux/amd64
...

cc @warner @michaelfig @rowgraus @katelynsills

my client log is in https://github.com/Agoric/testnet-notes/issues/29#issuecomment-904811805


Colored Letter Avatar should display inside email if contact has no avatar

When I was searching for more reference images of Inbox from before it shut down, I found this gif made in March 2019:

When the user clicked on an email, you can see one of the participants in the email thread has a pink 'B' avatar.
Right now, this extension only applies these avatars to the email list, not inside the emails when opened.

While I haven't yet figured out how to grab profile photos to use as an avatar for the email list, I do know how to check if the currently open email does not have one:
const DEFAULT_PROFILE_PHOTO_URL = 'https://ssl.gstatic.com/ui/v1/icons/mail/profile_mask_2x.png';
const profilePhotoElement = document.querySelector('.ajn');

if (profilePhotoElement.src === DEFAULT_PROFILE_PICTURE_URL ) {
    console.log('No profile pic set');
    console.log('Participant Name:', profilePhotoElement.dataset.name);

    // TODO: replace with first letter avatar
    // retrieve from profilePhotoElement.dataset.name[0].toUpperCase()
}

This needs to be hooked onto an observer (maybe with the Gmail.js lib), because when the email first loads, this default img is always loaded in first.

I just noticed the Gmail app on Android does this already, I wonder why they didn't do the same for the web version.
Weirdly enough, the Gmail app on Android never shows profile photos at all, both on the email list or an opened email. You can only see it when you click on the contact.


Ignore all IO errors during completion

Previously, there were two ways to have an error thrown during completion:

try to tab complete a directory that didn't exist at all (example /blah/tab where /blah/ doesn't exist).
try to tab complete in a directory without permissions (example: create /tmp/foo and then chmod 000 /tmp/foo and then in rustyline /tmp/foo/tab).

This change ignores all errors when doing tab completion

Thanks.


Make ITagHelperComponent.Init asynchronous

There are cases when I need to have asynchronous code in tag helper's Init method. Common example for Init usage is when I need to populate Items or ViewData for child tag helpers before they run. Basically, Init and ProcessAsync are just two steps of processing, which allow to order the logic parts between related tag helpers. So, its barely understandable why its not expected that Init can do async stuff in the same way as ProcessAsync. For instance, I want to use IAuthorizationService.AuthorizeAsync and attribute-provided policies in Init to do authorization and put results into ViewData to be used by (non-direct) child tag helpers. In this case I would only run that code once - on the parent tag.
Since this is not possible I have to instead put policies list into ViewData and make each child tag helper call IAuthorizationService.AuthorizeAsync in ProcessAsync every time its run (actually repeating the same code with same results many times).

@DamianEdwards - any thoughts about this?

While I agree with the sentiment, we can't simply change ITagHelperComponent.Init to be async, as it's part of an existing interface.
@rynowak what options do we have for introducing a new async initialization path for Tag Helpers retrospectively in a compatible way? e.g. derived interface, late-bind convention (attributes, method name), something else?

This would actually be pretty easy.

Add a new interface with the async init method ITagHelperAsyncInit or some gross name. This inherits from ITagHelper and adds the new InitAsync`.
Implement this interface on TagHelper and have the new async method call through to the sync one
Update TagHelperRunner to do the right thing. This should be easy

This would pretty transparently make InitAsync just show up for most people authoring tag helpers. I think the cost on this is an S.

Nice. Now the question is when. Do we 🤠 this in 2.1-rc or wait for 2.2

We'll do this in 2.2


Insonsitencies with usage of _WIN32_WINNT

Openssl has some logic in e_os.h to define the macro _WIN32_WINNT if not set by externally by the compiler, and then takes care of including windows.h.
https://github.com/openssl/openssl/blob/87314d24c4f025df1ebf47dc527cc8a96bef354a/include/internal/e_os.h#L86-L101
Supposedly this file should be the only one to be used internally by openssl to include windows headers, but in various places windows.h is included directly on top of the file, for example https://github.com/openssl/openssl/blob/87314d24c4f025df1ebf47dc527cc8a96bef354a/crypto/threads_win.c#L10-L15
In other cases, depending on other internal headers included beforehand, either windows.h is manually included first, or it's included through e_os.h due to chain dependencies, in this case e_os.h is included by time-h https://github.com/openssl/openssl/blob/87314d24c4f025df1ebf47dc527cc8a96bef354a/include/internal/thread_arch.h#L12-L18
These inconsistencies could lead to some files being possibly built with _WIN32_WINNT defined as 0x501 (if e_os is inclded first and it's not changed externally), while others being built with whatever the current sdk sets as default.

Yeah, windows.h should not be included directly. It should always be included via internal/e_os.h.


Increasing pulse width and frequency

Hello, I would like to increase the power output by increasing the pulse width to be as close to the maximum (I believe 100 ns?) as possible and also increase the frequency from 1 kHz to maybe 5 kHz or 10 kHz.
Would you point me to where I could change this in the code? Can I increase the pulse width by using a larger capacitor?

Hello.
1kHz is just test signal frequency, see main.c of "not_scanning_fw" project (TIMER_ELAPSED(timer_1ms) part).
"scanning_fw" reach 10kHz pulse frequency at 15 RPS motor speed.
You can try to increase pulse width by using a larger capacitor, but be careful!

Thank you! What would be the best software version / setup to compile the code?

I don't know what is your hardware, do you need scanning or not, so I can't help you.

I built it as yours, and I don't need scanning and the motor, I am just using the laser.
I just wanted to know the best setup to be able to compile the code (I only used Keil uvison before) because I saw in another thread that there might be problems if the version is different.

I use IAR 7.50 for building this FW.

Software counters, like "timer_1ms", are based on "ms_tick" variable, that is incremented in SysTick_Handler(), which is called by system timer with 1ms period.
This timer is configured by SysTick_Config() function in "hardware.c".
A lot of code here is expecting that this timer has 1ms period.
One option is use hardware CAPTURE_TIMER, that is used in "scanning_fw". It can generate interrupts with needed frequency.
Another way - you can use hardware_dwt_get() function, that return MCU tick count (72 ticks per 1us).
You can see dwt_delay_us() function.
But this kind of delay will lock program execution.

Thank you!

Hello, I have a question for you, I recently came across a piece of code in my project which uses the MS1005 chip using the stop1 channel and stop2 channel connected to the same pin. A rising edge trigger and a falling edge trigger can be used to get the pulse width and use this pulse width to calibrate the distance measured. May I ask why it does this and how it calibrates the distance

Thank you!

ShanLan12 Please, create new issue for your question.


fix: navbar-brand href now links to the BaseURL instead of /

Summary
Currently, the navbar-brand links to "/".
Given that BaseURL is configurabe, I think this is probably a bug.
Basic example
before:
Foo

after:
Foo

Motivation
In some instances, a URL like / is not possible. This is the case for example for websites like GitLab pages which serve under user.pages.instance.tld/projectname
Checks

[x] Read Create a Pull Request
For some reason my IDE is not allowing me to edit commit messages, but this is probably not that big of an issue for this PR, as you can just edit the commit message via squashing this PR into main 😉
[x] Supports all screen sizes (if relevant)
[x] Supports both light and dark mode (if relevant)
[x] Passes npm run test

I think, that this PR should be merged and is not stale

@h-enk any plans to get this one merged?

@h-enk This is a super tiny PR, please either reject it or merge it.

This need to get merged


KAFKA-15908: Remove deprecated Consumer.poll(long timeout)

Remove deprecated Consumer.poll(long timeout)
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

3 unrelated test failures

Thanks for the updates @AndrewJSchofield. Just one comment, are we sure about the failure on AuthorizerIntegrationTest.testPatternSubscriptionWithTopicAndGroupRead not being related? Those tests have been consistently green lately (zk and kraft), and are failing here checking the changes after the poll we changed. I wonder if the case could be that the 500ms that we're using for poll now may not be enough for the assignment changes to happen? (or something else I may not be seeing, but I would start by checking if maybe we pollUntilTrue and check the condition instead of a single poll with 500ms + check condition)

Yeah, I'm a little suspicious too. Didn't seem immediately related, but I will dig into this further.

@lianetm Really the only proper way to wait for metadata with the new poll method is the rebalance listener. I modified the tests to use that. Let me know what you think.


SWARM-1596: Upgrade Flyway to 4.2.0

Motivation
Upgrade Flyway to latest stable version.
Modifications
build-parent pom.xml has been modified to hold the new versions.
Result
Latest version of Flyway is used.

[X] Have you followed the guidelines in our Contributing document?
[X] Have you created a JIRA and used it in the commit message?
[X] Have you checked to ensure there aren't other open Pull Requests for the same issue?
[X] Have you built the project locally prior to submission with mvn clean install?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

add to whitelist


upgrade environment for maze and gym notebooks

Actually i used these dependencies in my version of notebooks and i do not see why it would be so bad to "risk" to have a bit too many dependencies? What is the risk ? At least we do not need to rebuild it once it is done.
For matplotlib, i put it explicitely because i did not realize it was part of the dependencies (probably because of the "official" maze domain in the hub) which does not change anything as you say. I can remove that if you prefer even though i did not think it was worth it...

Actually i used these dependencies in my version of notebooks and i do not see why it would be so bad to "risk" to have a bit too many dependencies? What is the risk ? At least we do not need to rebuild it once it is done.
For matplotlib, i put it explicitely because i did not realize it was part of the dependencies (probably because of the "official" maze domain in the hub) which does not change anything as you say. I can remove that if you prefer even though i did not think it was worth it...

Je pense que c'est une bonne pratique de mettre uniquement les paquets utiles. D'autant plus sur des notebooks qui pourraient être utilisés par des utilisateurs sous divers environnements (que nous n'avons pas testé). Je préfère les ajouter au fil de l'eau - cela ne rend que 15 mn à construire.

@nhuet Do not lose your time on this issue, if your notebooks need a different environment, use a branch on your fork.


Allow merging additional sample info information

If the user has sample metadata (e.g. donor, experiment_id, ...), we need to be able to merge it in the h5mu to be able to perform batch correction on.

Completed in #94


Updates from rspec-dev (2015-08-13)

These are some updates, generated from rspec-dev's rake tasks.

2nd attempt at rspec/rspec-dev#116


Destructuring and Spread Operator in Vanilla JavaScript

Proposed title of article
Destructuring and Spread Operator in Vanilla JavaScript
Introduction paragraph (2-3 paragraphs):
We all know the amazing data structures in JavaScript which help in writing clean and efficient code. Handling the data structures can be hard some times. In this article we are going to learn about destructuring in arrays and objects in JavaScript together with the Spread Operator
Key takeaways:
After reading this article the learner will understand:

Array Destructuring
Object Destructuring
How to Use Object Destructuring with Functions
The spread OPerator

References:
N/A

Hello, @IsaacMuthini Kindly check as I had a similar issue closed:
https://github.com/section-engineering-education/engineering-education/issues/1370
You'll need to ensure that your content doesn't overlap :+1:


Make _stable_1d_sort(nb) optional

Before submitting

[x] Was this discussed/approved via a Github issue? (no need for typos and docs improvements)
[x] Did you read the contributor guideline, Pull Request section?
[n/a] Did you make sure to update the docs?
[x] Did you write any new necessary tests?

What does this PR do?
Fixes #195

@carmocca I think this won't be needed after merging https://github.com/PyTorchLightning/metrics/pull/197#discussion_r618851691


Spam Video ID Submission

Duplicate Links

[X] Yes, I checked that the ID is not currently in the list
[X] I read the wiki explaining each different categories and examples before submitting

(Required) Spam Comment Direct Link
https://www.youtube.com/watch?v=gWUj6wx0UzI
(Optional) Screenshot of comments using the link

(Required) List of the spam video IDs / Links
GD8AIgzc8Uc
rNwr2HDksVQ
7js3ipfzemY
gWUj6wx0UzI

Added


no responding

Why do I sometimes enter a password and then click on the Enter page without responding?

Known issue. See #18
The plugin depends on a external js file: //cdn.bootcss.com/jquery/1.11.3/jquery.min.js". If your theme already contains jquery, you can remove it from the template. Follow steps by: https://github.com/MikeCoder/hexo-blog-encrypt#change-template

I haven't tried this method yet, but when I use google chrome to access your test blog, this is also the problem. Entering the password and pressing Enter does not respond.
https://mhexo.github.io/example-site/2016/10/26/HexoBlogEncrpyt/

我现在解决了，我在这里
https://cdnjs.com/libraries/jquery/1.11.3找了之前的渲染版本，他的链接貌似做了改动。
我将template里
<script src="//cdn.bootcss.com/jquery/1.11.3/jquery.min.js"></script>

改成下面这个
<script src="//cdnjs.cloudflare.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>

就ok了


Fix translation issue

Translate the title “ttyd” in service menu

Your commit title should start with the package name "ttyd:" And your signed-off should contain your real name, but as the change is so trivial, I will merge it this time.

Your commit title should start with the package name "ttyd:" And your signed-off should contain your real name, but as the change is so trivial, I will merge it this time.

Thank you, it's my first time to pull request and I am not clear about the rules.

I am not clear about the rules.

You can find the key items in
https://github.com/openwrt/luci/blob/master/CONTRIBUTING.md


installing node

clarion@clarion-Vostro-1014 ~ $ node app.js
module.js:340
throw err;
^
Error: Cannot find module '/home/clarion/app.js'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Function.Module.runMain (module.js:497:10)
at startup (node.js:119:16)
at node.js:935:3
i got this error while running node app.js. and i cant access localhost:3000- page is not available

please help me with this issue.

It's obviously not an inssue with the application, but a configuration issue.
Most likely you're not in the right directory: the file "/home/clarion/app.js" does not exist. Most likely you've cloned the repository into another directory ("lets-chat" would be likely).  Try to run the app from there.

yea you need to do cd lets-chat
also please make sure you've installed everything as mentioned in the docs


Support Check/all index properties/views in drizzle-kit

This brought me to here: https://github.com/drizzle-team/drizzle-orm/issues/1981#issuecomment-1985634173

IMO, this part of the doc is extremely misleading. Why even mention these functions when they are not even implemented? In fact, adding type definitions to these functions makes things even more confusing. I would rather have the type removed or the function simply throws a "not implemented" exception.

Hello, I am curious if this will include adding views to DrizzleKit?
https://orm.drizzle.team/docs/views

Checks and views have been added to Kit in latest release.

If anything is missing from any index, constraint or view, I feel like we should create specific issues tackling each thing rather than something general/vague like this issue.

According to this article in docs and status of this issue I assume .asc() and . .desc() should be supported? Why I can't use them in<EMAIL_ADDRESS>and<EMAIL_ADDRESS>index('postboard_idx').on(
  postboardTable.createdAt.desc(),
)

index('postboard_idx').on(
  postboardTable.createdAt,
).desc()

Neither works:
Property 'desc' does not exist on type 'PgColumn<...>'.
Property 'desc' does not exist on type 'IndexBuilder'


fix: show 404 page when see /logout if not login

Description
See https://github.com/codeigniter4/shield/pull/921#issuecomment-1771506477
Checklist:

[x] Securely signed commits
[ ] Component(s) with PHPDoc blocks, only if necessary or adds value
[ ] Unit testing, with >80% coverage
[ ] User guide updated
[ ] Conforms to style guide

Hi @datamweb,
Thank you for this PR. But there are some things I'm looking at:

Why do we need to bother about unauthenticated users visiting the /logout page when the system automatically redirects them to the login page?
Why do we need to force a 404 page when the logout page actually exists?

@sammyskills Thanks for the feedback.
Is it reasonable to display message "You have successfully logged out." for a user who is not logged in?

Okay, that is understandable.
But instead of returning an error (which it is not), how about returning to the logoutRedirect() url without the message?

I'm glad you now understand my point.
However, I think it will be an overkill to add a new string if we can always check if a user is logged in or not and show/not show the message, for example:
// user logged in
return redirect()->to($url)->with('message', lang('Auth.successLogout'));

// user not logged in
return redirect()->to($url);

Something along the lines of:
https://github.com/codeigniter4/shield/blob/5b50267c91e5126ab8900dff57c5284a3e42066d/src/Controllers/LoginController.php#L99
What do you think?

Hmm, good point. Send a PR.

😊 @datamweb, thanks for the offer but I think your PR already has what is needed. Just a minor edit and we are good to go!
Please do the honours instead.


Finnish translation, release 1.5, part 2

Some fixes

Release 1.5 will go live tomorrow!
Targeting this for release 1.6.

Thanks @valtlait merging.


added filtering options on mavcan

added UI elements for filtering and bus number

Since this is going to rely on pydronecan 1.0.10 for these gui features to work, the dependancy should be moved forward...
https://github.com/dronecan/gui_tool/blob/3d6b7397ccc7985e70700c65341210581ba806ee/setup.py#L44

once the setup.py is included, i'm ok with this., lets call it merge-on-setup.py-included.

fixed


Petition to rename the project

Seriously, why isn't it called Snackspo? Or Snaxpo?  Think about it.
Snaxpo.io. It rhymes, it's short, cute. But no. Snack.expo.io somehow sounded better.
I'm sad now.

+1


RFAC-88: Making PMD rules more strict

Fix all violations
Added unit tests
Should be applied first https://github.com/riskfocus/flink-generic/pull/38

Let me solve Conflicts.

Let me solve Conflicts.

Done.


AUI-2084 Modal height is updated according to modal content but can't exceeds viewport

Just started reviewing :) :octocat: Sent from GH.


begin/complete callback allways called after .velocity('stop')

The begin and complete callbacks are allways executed after I stop the animation with the stop command.
The begin callback is executed after the delay period which is good. Which gives time to cancel the animation. But after the stop command it is still triggered.
Is this expected behaviour? Is there a way to not execute the callback functions when i stop the animation?

will close this since i didn't get a fiddle and i'm not experiencing the issue myself.