DO NOT MERGE CI for #2825

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/3789/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/5010/
Test PASSed.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/3790/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/5011/
Test PASSed.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/3791/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/5012/
Test PASSed.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/3793/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/5014/
Test PASSed.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/3796/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/5017/
Test PASSed.


Videogular - resizing height (not width) automatically - doesn't work in Chrome

Hi there,
I am trying to write up an appropriate CSS that automatically adjusts the height of the video based on available screen size. This does not seem to work on Chrome. It works on Safari.
Please see this codepen http://codepen.io/pliablepixels/pen/aBddda
If you run it in Chrome and decrease the height, it does not automatically decrease the video height. The same codepen works in Safari.
Any thoughts? Thanks.

I worked around this issue by enclosing the container inside another container with device width and height in pixels (recomputed each time size changes)


Extending from a class with generics breaks type checking?

Hello all.
Whle trying to implement a simple serialization for my models, I stumbled upon what I think is a bug.
Consider the following scenario:
interface ITest {
	a: number,
	b: number
}

class Test extends BaseModel<ITest> {
	constructor(obj:ITest) {
		super(obj);
	}
}

class BaseModel<T> {
	constructor(obj:T) {
		for (var propName in obj) {
			this[propName] = obj[propName];
		}
	}
}

var array:Test[];
array.push({c: "test"});

I expect the array.push() in the last line to fail because I would be pushing something that does not conform. Instead, no error is thrown on that line.
Am I doing something wrong?

Problem is that the Test type has no members, meaning that any object type assignable to it. This is an effect of TypeScript's structural type system (specifically, a source object type is assignable to a target object type as long as the source object type has all the properties of the target object type--which in your case is none). Once you add members to Test you get the expected behavior.


No such package 'tools/android'

Since commit 5b4ffaec96af206, Bazel now requires the tools/android package even if a project does not use Bazel's Android support.  To me, this is another case like https://github.com/google/bazel/issues/191 where Bazel is increasing its usage requirements unnecessarily.  However, unlike the CROSSTOOL configuration, this should be easy to stop right now before the Android rules become too coupled with the rest of Bazel.

I believe Lukacs already made it a priority to decrease the burden of the android toolchain.

Yep, this is unfortunately a heritage of Bazel coming from a place where
everything is in the source control. I have some ideas about fixing this.
How much does this hurt at the moment?
Out of curiosity, how are you using Bazel so that this is a problem? I sort
of expected that people would copy the tools/ directory to their source
control in its entirety, in which case you'd also get tools/android "for
free".
Here is my plan (which I hope I will get around soon):

Move incremental_{split_,}stub_application, resources_processor and
aar_generator from the configuration to an implicit dependency
Make it so that it's not an error if --android_sdk cannot be loaded
Profit.

On Tue, Jun 16, 2015 at 6:36 PM, Damien Martin-Guillerez <
<EMAIL_ADDRESS>wrote:

I believe Lukacs already made it a priority to decrease the burden of the
android toolchain.
—
Reply to this email directly or view it on GitHub
https://github.com/google/bazel/issues/249#issuecomment-112491264.

--
Lukács T. Berki | Software Engineer |<EMAIL_ADDRESS>|
Google Germany GmbH | Dienerstrasse 12 | 80331 München | Germany |
Geschäftsführer:
Graham Law, Christine Elizabeth Flores | Registergericht und -nummer:
Hamburg, HRB 86891

We have our own workspace setup in the http://github.com/google/kythe repository.  It contains copies of the required files from the base workspace with some tweaks.  This means that I could leave out the --package_path arguments in my .bazelrc before this change.  For now, I can add back those flags and things work fine.  I don't think we want to start vendoring the Bazel-Android toolchain any time soon.

This setup also breaks when we make an incompatible change in the interface
between the tools and Bazel, right?
We should really figure something out for this. We don't really take any
care to keep that interface simple. I have a plan that is deviously simple
and elegant. I hope I can make it work tomorrow, at least to a
proof-of-concept level.
On Tue, Jun 16, 2015 at 6:46 PM, Cody Schroeder<EMAIL_ADDRESS>wrote:

We have our own workspace setup in the http://github.com/google/kythe
https://github.com/google/kythe repository. It contains copies of the
required files from the base workspace with some tweaks. This means that I
could leave out the --package_path arguments in my .bazelrc before this
change. For now, I can add back those flags and things work fine. I don't
think we want to start vendoring the Bazel-Android toolchain any time soon.
—
Reply to this email directly or view it on GitHub
https://github.com/google/bazel/issues/249#issuecomment-112494281.

--
Lukács T. Berki | Software Engineer |<EMAIL_ADDRESS>|
Google Germany GmbH | Dienerstrasse 12 | 80331 München | Germany |
Geschäftsführer:
Graham Law, Christine Elizabeth Flores | Registergericht und -nummer:
Hamburg, HRB 86891

Yes, we also had to update our workspace when the extdir change happened.

Started a thread on bazel-dev.
On Tue, Jun 16, 2015 at 6:52 PM, Cody Schroeder<EMAIL_ADDRESS>wrote:

Yes, we also had to update our workspace when the extdir change happened.
—
Reply to this email directly or view it on GitHub
https://github.com/google/bazel/issues/249#issuecomment-112495659.

--
Lukács T. Berki | Software Engineer |<EMAIL_ADDRESS>|
Google Germany GmbH | Dienerstrasse 12 | 80331 München | Germany |
Geschäftsführer:
Graham Law, Christine Elizabeth Flores | Registergericht und -nummer:
Hamburg, HRB 86891

What's the ETA on this?  This also breaks our presubmit, and I'd like to make use of b6f557b4c1b16a1e955dd773e2de9550f10d59fb.

ETA on what? In the meantime you can add the android package.

ETA on removing the built-in need //tools/android to exist at all when a project doesn't need or want Android support.

ETA to make it properly is probably going to be end of Q3 unfortunately.

In the meantime, you can rebind the targets there: https://github.com/google/bazel/blob/master/src/main/java/com/google/devtools/build/lib/bazel/rules/android/android.WORKSPACE to an empty filegroup

Thanks, I'll make the stubs for now.  Hopefully there won't be any need for more after this?

I cannot promise but we'll try to announce them and propose migitation in
the future. As soon as we have our release process it should make things
easier.
On Wed, Jun 24, 2015 at 6:30 PM Cody Schroeder<EMAIL_ADDRESS>wrote:

Thanks, I'll make the stubs for now. Hopefully there won't be any need for
more after this?
—
Reply to this email directly or view it on GitHub
https://github.com/google/bazel/issues/249#issuecomment-114934083.


Discuss if adapters should enable keep alive by default

A user posted an issue with connection being dropped of with Postgres:
https://groups.google.com/forum/#!topic/elixir-ecto/XDIQfwMhHd8
Some search revealed that libpq, for example, enables keepalive by default. Should we do the same in our adapters?
At least I recommend all adapters to support configuring the tcp connection. I have pushed this commit to Postgrex and I recommend the other adapters to the the same: https://github.com/ericmj/postgrex/commit/5704b6988fecb0bf8841da453c355190a6733629
/cc @ericmj @liveforeverx @mobileoverlord @fishcakez (please ping this thread once you have added the socket_options and your opinions regarding keep alive).

Added: https://github.com/xerions/mariaex/commit/d4c5cb7a5b4ddb64e091f8771659667b8e0bb681 and released 0.1.5.
Inactive clients will be proactive closed by MariaDB (at least on Galera Cluster per default). It has there very tiny default inactive interval (something like 1 second, and after that connection will be closed).  If there will be something like network split, without keepalive, the connection willn't be proactive closed, seems, that it would be good to have keep-alive for this case.

If the connection is regularly dropped within 10mins on the network, as in the email, I think raw socket options will be required to set a low enough keepalive interval. These are OS specific.
@liveforeverx Keep alive is at the tcp level so wont prevent application level idle timeouts.

@fishcakez , I know. But, keepalive should help on network splitts and firewalls(which are mostly drop inactive connections too).

Ah I am confused by your 1 second comment.

@fishcakez want only mention, that I doesn't seen such behaviour(as in error in mailing list) with Mariadb/MySQL at all, as it wasn't silently closed, that it was always explicit closed. With galera cluster, I'll see after one second of inactivity the connection is closed. Connection closed explicitly in this inactive interval, and for next query ecto starts simple new connection without errors.

The cause of the issue was another one. Let's not change keep alive defaults but still provide :socket_options so users can configure it. Thanks everyone.

All up to date
livehelpnow/tds@ 3f9ebb4757821627b0ac07a15c1798fa445a8d89


eDSL: reserved names, nonexistent ports

Right now the eDSL lets you generate pretty free-wheeling Calyx, even if that Calyx is clearly wrong. I wonder how people feel about making the eDSL a little cleverer.
Below I refer to mwe.py; it generates mwe.yx.
Reserved Names
As we know, Calyx adds go and done ports to components so that they may be used as cells in multi-component designs. However, the eDSL happily lets you add ports with those very names.
https://github.com/calyxir/calyx/blob/148690e96179c73c16d53f4ba7fa85b7fb51a464/calyx-py/test/mwe.py#L4-L7
I don't know what Calyx would make of this; hopefully it would catch it and stop you from proceeding. However, I kinda think that the eDSL could just weed out some of this stuff if we teach it some rules.
Nonexistent Ports
The eDSL lets you assign to ports that don't exist.
https://github.com/calyxir/calyx/blob/148690e96179c73c16d53f4ba7fa85b7fb51a464/calyx-py/test/mwe.py#L9
I regret to share that I don't actually have a port called flamingo on that component. Similarly, the eDSL lets you define a std_add called adder and then read/write to a port called adder.penguin. I think, when someone uses the {thing}.{port_name} notation to read from or write to a port, the eDSL could just check if thing actually has a port by that name. Another example of a thing that Calyx probably catches later on, but the eDSL is totally equipped to catch early on.

Sounds like a good idea to me! Also, do you mind adding relevant labels to the issue ("calyx-py", "need triage / available")

Occurs to me that while these two tasks are spiritually connected (i.e., should the eDSL be a bit smarter?), they are actually pretty different in scope and difficulty. A little like this xkcd classic.
Task 1 feels like just teaching the eDSL some basic rules. I can crowdsource those rules and add them in easily enough.
Task 2 actually has two flavors.

For user-generated components, groups, cells, etc., limit what ports you can access to the ports that actually exist.
For library cell,

feels like teaching the eDSL, for each of the many many cells that it can generate, the allowable ports for that cell.

Whoops mis-click...


WIP: Enable ITK FFT Factory registration

ITK 5.3 is adding FFT factories. This needs special configuration to
ensure the generated FFT factory code is generated and registered for
the appropriate SimpleITK targets.
The difficulty is that ITK's  UseITK.cmake file set all configuration
properties at a global and directory level. This changes the
configurations for all SimpleITK libraries built in the BasicFilters
directory adding unnecessary include directories, flags, and other
compilation options to targets.

There is a struggle here trying to use the FFT factories on a target level and not on the whole directory.
@dzenanz @tbirdso
Any suggestions?

I haven't done a deep dive in ITK build system in months, probably longer. Tom's mind should be fresh with FFT stuff, so he should be able to help.

I was about to say that @dzenanz may know better than me, uhoh 😅
The heart of the issue here is less about FFT filters and more about object factory infrastructure, the idea behind recent changes and improvements is that the object factory will better support swappable backends across different modules going forward. UseITK.cmake defines only a handful of new compiler definitions for factories and includes only a few additional configuration files that are necessary for registering default factories at runtime.
There has been discussion around refactoring the ITK build structure to rely on CMake targets rather than directories, but that will require a significant effort and I'm not up to date on whether those plans are in the pipeline beyond the idea phase. Perhaps @thewtex would be able to better comment on this discussion?

refactoring the ITK build structure to rely on CMake targets rather than directories

This is still planned. Not sure whether we are targeting 5.4 or, more likely, 6.0.

I have been using this: https://github.com/SimpleITK/SimpleITK/blob/master/CMake/sitkTargetUseITK.cmake
# target_use_itk
#
# This function has the following form:
#   sitk_target_use_itk(<target>
#                       <PRIVATE|PUBLIC|INTERFACE>
#                       [itk_module [itk_module [...]]])
#
#   It configures the target, with the require include directories and
# link libraries to use the list of itk modules provided. The keyword
# to indicate interface of the library is also required.

function(sitk_target_use_itk target_name interface_keyword)

Which has been working very well up until this point. I'll see what I can figure out.

the idea behind recent changes and improvements is that the object factory will better support swappable backends across different modules

Does this mean a compile time configuration/options for modules or runtime options? I can certainly see a place for both.

One more thing, I am interested in getting the FFT classes being instantiated in one library and just used at runtime by other modules, and not requiring library and compilation unit to recompile the FFT classes over and over again, and require the additional include and dependencies every where.

@dzenanz @tbirdso I think I am going to work on a little refactoring in ITK:

move the factory generation code to a cmake function in the ITK configuration file ( this will enable its usage with out using ITK_USE_FILE
split ITK_NO_IO_FACTORY_REGISTER_MANAGER into all the named factory types

the idea behind recent changes and improvements is that the object factory will better support swappable backends across different modules

Does this mean a compile time configuration/options for modules or runtime options? I can certainly see a place for both.

Both, where new factories can be configured at compile time with the FACTORY_NAMES field in itk-module.cmake to be registered at runtime init by default, or manually added to the factory list at runtime for overriding backends.

I think I am going to work on a little refactoring in ITK

Thank you for taking a look at this!

move the factory generation code to a cmake function in the ITK configuration file ( this will enable its usage with out using ITK_USE_FILE)

This sounds good to me, I assume this will reduce your need for including UseITK.cmake in SimpleITK?

split ITK_NO_IO_FACTORY_REGISTER_MANAGER into all the named factory types

By "types" do you mean the existing set of factory manager files (ImageIO, MeshIO, TransformIO, FFT)? I'm not sure exactly how this should be accomplished but if you have an idea I'm happy to give feedback on a PR.

Alternative implementation was merged in #1559


[3Pts] Setting up the database and models

[ ] Make sure the project uses a PostgreSql database
[ ] Database must be built according to the Entity Relationship Diagram.
[ ] Make sure the models include the associations and validations needed.

https://github.com/Log-benjamin/Recipe-app/pull/17


Map plans to specific programs

One feature that Amory Crate has is the ability to map different power plans to specific programs so that when that program runs the linked plan will be activated and when that program start running the plan will be stopped. For example I can have the Omega Saver plan running as default, but if I run a game then a Gaming plan will be automatically activated regardless of global AC/DC mode plan setting, and when the game is closed the Omega Saver plan can be kicked in again. I wonder if that feature can be added to G14Control; user can select a specific program and a plan that activates when that program runs.

That would be cool. The only issue is that I'm pretty busy these days and don't have much time to work on the app. Sorry 😞


We need a way to persist API tokens even when resetting the databases

Will be done as part of the Edusources/Publinova merge inside Harvester service


thellier_gui error with site_int_n

When I try to set the site_int_n parameter to something, i get this on saving:
File "/Users/ltauxe/Programs/PmagPy/GIT/PmagPy/programs/thellier_gui.py", line 2391, in On_close_criteria_box
if not dia.set_site_int_n.GetValue():
AttributeError: 'Criteria_Dialog' object has no attribute 'set_site_int_n'

this happens with both 2.5 and 3.0.

I pushed a fix for the dialog name problem, but not sure about the bigger picture.

Now it does this correctly, BUT thellier_gui now saves all the criteria with the 'ACCEPT' criterion instead of the IE-SPEC, etc. criteria.  This is a new bug.

@ltauxe, are you still having the 'ACCEPT' criterion problem?


fix(highlight): return false when the capture is not a comment

Prevents jump to next/previous todo comment from hitting context.TODO() in go code.
This problems occurs when using a highlight pattern without a colon (e.g.  pattern = [[.*<(KEYWORDS)>]])  even when comments_only is true.

bump

bump

bump

Fixes #301


thres in gene_thres

A small question!
Your ccm_trainer.py
159   index = int(cls_total * prop)
160   cls_thres = cls_prob[-index]
161   cls_thres2 = cls_prob[index]
162   thres[k] = cls_thres
For what consideration, you set your thres be the value of the last ten percent of the probability value?
last bacause of (-index), ten percent because of (prop=0.1)

Hello, to obtain the pseudo label, we adopt a thresholding strategy where only the top 10% samples of each class are assigned with pseudo labels.


feature distillation?

Hi, thanks for your great work. Dose the code contain the feature distillation part?

Hi, please refer to the following work for the feature distillation.
Zhang et al., Improve Object Detection with Feature-based Knowledge Distillation: Towards Accurate and Efficient Detectors.  ICLR2020

Hi, thanks for your great work. Dose the code contain the feature distillation part?

Hi, please refer to the following work for the feature distillation.
Zhang et al., Improve Object Detection with Feature-based Knowledge Distillation: Towards Accurate and Efficient Detectors. ICLR2020


Public property on class not inferred from type of type parameter

🔎 Search Terms
"infer class property", "refine class"
🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about classes.

⏯ Playground Link
https://www.typescriptlang.org/play?#code/KYOwrgtgBAogTnA9nAwogJsAzlA3gKCiKgCEBBAESgF4oAGAGkOIBUYAldgSRIBkYaUAIxNiUMgHUAYgFVeggExMAvvnwAXAJ4AHYLATIKwdQEMAlgBsctAmIDa8JKgzYAdOQoBdAFx4oAdwALTV8sdTgzEABzKGVRYgcDZ0wsVzZOHn4fPyDgOGBQ8MiYuOYiRKc0FNdJWV5s3ADAxEKI6NiVNQBjCxMsHCrgdEdkAB4WQahgAA91UHQcEeTsQSXBrAA+PDKoLsQQMLgwLvVkAAp8k3R9i01dl18JlwYoS+uQW6hMU0ssXyWjD8rHYnphPABKPyqVT4PYHdRQMAgADWIEQ-hAS0E4AsFigfURKLRGPxAxcwySAG58GYAGZQM5I1HozFJVx7TA0ai0NYuVLpbh8GCQ2zEAD0YqgXACiDAFnQU2muhOUAABt9zFZVVBTlAAEZ6fK0yJDHWINUA4yarAVZDrNIcQVZbWBPLAVw7JnE1lOVwa35QLAmdRmLDGlaWoE23nVAWZGCealiOFYRAWd0WRBRRlEllLP1W36uXL5cHU5RAA
💻 Code
I have two public, readonly properties on a class: code and details. The type of details depends on the value of code.
enum ErrorCodes {
    BAD = 0,
    TERRIBLE = 1,
    AWFUL = 2,
}

type ErrorDetails = {
    [ErrorCodes.BAD]: { why: string },
    [ErrorCodes.TERRIBLE]: { where: string },
    [ErrorCodes.AWFUL]: { who: string },
}

class CodedError<TCode extends ErrorCodes = ErrorCodes> {
    constructor(
        readonly code: TCode,
        readonly details: ErrorDetails[TCode],
    ) { }
}

🙁 Actual behavior
When I make an assertion on the value of code I would expect that to refine the type of details but it doesn't seem to in this example:
const unknownError = null as unknown as CodedError;
if (unknownError.code === ErrorCodes.TERRIBLE) {
    unknownError.details satisfies ErrorDetails[ErrorCodes.TERRIBLE]; // ERROR
    console.log(unknownError.details.where); // ERROR
}

🙂 Expected behavior
After having asserted that code === ErrorCodes.TERRIBLE I would expect details to be refined to ErrorDetails[ErrorCodes.TERRIBLE].
Additional information about the issue
No response

What you have here is the same as if you had written
declare const unknownError: CodedError<ErrorCodes>;

which is the same as you'd get if you wrote
const unknownError = new CodedError<ErrorCodes>(ErrorCodes.AWFUL, { why: "not actually ok "});

which shows that it's not safe to perform that narrowing

Put another way, having a Foo<A | B | C> is not the same as having a Foo<A> | Foo<B> | Foo<C>

Though I don't love the API, when I jam everything on to one property of the class I can get the effect I want – albeit my customers will have more characters to type.
type ErrorConfig = Readonly<{
    [P in ErrorCodes]: ErrorDetails[P] & { code: P, }
}>

class CodedError<TCode extends ErrorCodes = ErrorCodes> {
    constructor(readonly details: ErrorConfig[TCode]) {
    }
}

const unknownError = null as unknown as CodedError;
if (unknownError.details.code === ErrorCodes.TERRIBLE) {
    unknownError.details satisfies ErrorDetails[ErrorCodes.TERRIBLE]; // OK
    console.log(unknownError.details.where); // OK
}

new CodedError<ErrorCodes>({ code: ErrorCodes.AWFUL, why: "not actually ok " }); // ERROR
new CodedError<ErrorCodes>({ code: ErrorCodes.AWFUL, where: "not actually ok " }); // ERROR
new CodedError<ErrorCodes>({ code: ErrorCodes.AWFUL, who: "you!" }); // OK

(Playground link)


Handling basic forms encoded with application/x-www-form-urlencoded

Hi, thanks for this library, it's very nice to have!
Say you want to make the most basic of web apps. Say you're coming to Julia from a non-data science background, but you're quite experienced making web apps in other languages, and you're just fiddling around to see how it feels in Julia. You have a user, a page, and a form on that page that the user can fill and submit. The default encoding for forms sent with POST is application/x-www-form-urlencoded, and the HTTP standard encourages you to use POST for anything that may modify data server-side, for good reason.
Seeing how HTTP.jl and Oxygen.jl seem to support some advanced features like plots, WebSockets, protobuf etc, you'd be surprised, then, to find out that currently:

neither HTTP.jl nor Oxygen.jl mention this most basic use case (handling forms received with application/x-www-form-urlencoded) anywhere in their docs
the code in HTTP.jl for sending data with application/x-www-form-urlencoded just uses return write(stream, URIs.escapeuri(body)) and thus is incorrect, because URIs.escapeuri encodes for URLs, and URLs and application/x-www-form-urlencoded encodings are actually different (see https://github.com/JuliaWeb/HTTP.jl/issues/1138)
if you scour the docs on how to handle a form sent to your server, thinking "it's impossible they don't mention this case, right?", and you're not on top of your web encodings knowledge, you may find the example for handling query parameters (https://github.com/OxygenFramework/Oxygen.jl?tab=readme-ov-file#query-parameters) and think you might just be able to use this queryparams function on the body of the incoming request. Seems to work, but then you silently end up with My+Blog+Post+Name instead of My Blog Post Name in your database. Why? Because the browser of course correctly used the application/x-www-form-urlencoded encoding to send the form, and the + are  not decoded as   by queryparams (which is correct for URL encoding, but incorrect for forms).

While it is quite easy to work around these problems in your own app if you know what you're doing, I guess it would be extremely confusing to a newcomer, and quite frustrating to experienced web devs to have to do that themselves, who then might just flee from the language for any serious web-related stuff. Which is sad because having a strong web ecosystem would make Julia much more credible as a general-purpose programming language. For me, coming from Rust (where admittedly, the web ecosystem is incredibly rock-solid), the Julia web ecosystem currently feels very flimsy (not really because of the lack of libraries, but more because of these kinds of basic use cases not accounted for, popping up here and there).
Generally, I suggest there should be an effort to make the Julia web basics solid, correct, unsurprising. I think the above story should not happen for people trying Julia for the web. Maybe I can help, although I'm quite new to Julia.
More specifically, for Oxygen.jl, I suggest the case of application/x-www-form-urlencoded should be explicitly documented, even if to say that it doesn't support it because HTTP.jl doesn't currently support it. If I get some time, I'll work on a PR for HTTP.jl to support the case, and I can do a PR for Oxygen too if you're ok with that.

Hi @nguiard,
This case should already be covered, below is a short example of how to parse out the form data from a request. In this scenario, you don't have to worry about the weird URL encodings as they are handled by the formdata() function.
Assuming this covers this case, I think we could rename this issue to something like "add form parsing docs"
using Oxygen

@get "/" function()
    html("""
    <form action="/form" method="post">
        First name:

        <input type="text" id="firstname" name="firstname">

        Last name:

        <input type="text" id="lastname" name="lastname">

        <input type="submit" value="Submit">
    </form>
    """)
end

@post "/form" function(req)
    data = formdata(req)
    println(data)
    return data
end

serve()

Hi, oh that's perfect! Thanks and sorry for the long rant then haha. I'll change the issue name. Would you like me to try my hand at a PR for documenting the case?

No worries, this feature was completely undocumented.
And you don't have to do that, I can add this later tonight. But I definitely won't stop someone else from writing docs. If you want to give it a shot, I only ask that you keep it concise and place it after the query parameters section in the readme.
Also, don't forget to cd into the docs directory and  run the docgen.jl after making your changes. This copies the changes over to another readme file that is used by documenter.jl to build the docs site.

Ok thanks. I'll let you handle this then, but maybe I'll come back with a few more docs at some point. Thanks again.


typo

Thanks for the PR, @ShingoFukuyama! We'll need you to accept our Contributor License Agreement before we can merge your contributions.
Cheers,
The robots and humans at Realm

:+1: once the CLA is signed

CLA has been signed. Thanks so much for the contribution, @ShingoFukuyama!


What ECMAScript version and module system settings should be used with VS2019?

Can we get some documentation on what currently works with documented tutorials for "ECMAScript version" and "Module system" settings in project properties?
There's 7 "ECMAScript version" options in VS 2019 and 5 Module System options, making for 35 combinations.  I have spent hours every night trying different combinations, going through tutorials on docs.microsoft, for 2 weeks and have yet to get a single tutorial to compile successfully.  None of them specify what these settings should be set to.
Some of the errors I get, I look up and they say it is related to CommonJS, so I switch to a different Module System settings, but then none of my import statements can find modules, and the tutorials don't explain what import is actually doing.  I have the modules under node_modules, but there's no indication in errors as to where it's exactly looking or what it's looking for or why the behavior varies between the module systems.
It would take out alot of the guess work to specify at the beginning of a tutorial what settings should be used for these.

None of them specify what these settings should be set to.

That’s because what these should be set to depends on what environment you’re targeting, how old the browser/Node version is, etc.  There’s no one-size-fits-all setting for these, it entirely depends on your use case.
I can at least tell you that Node should always use commonjs for module type though, at least for the foreseeable future.

To be clear: the module and target settings only affect what tsc produces as output, so if it’s failing to find imports at compile time, changing these settings is not likely to help.

so I switch to a different Module System settings, but then none of my import statements can find modules
When you use commonjs the default moduleResolution is node, but for other module, the default is classic.
https://www.typescriptlang.org/docs/handbook/module-resolution.html#module-resolution-strategies

None of them specify what these settings should be set to.

That’s because what these should be set to depends on what environment you’re targeting, how old the browser/Node version is, etc. There’s no one-size-fits-all setting for these, it entirely depends on your use case.
I can at least tell you that Node should always use commonjs for module type though, at least for the foreseeable future.

In the context of a tutorial, those variables should be scoped for simplicity.  Trying to handle all those possible combinations is a pretty advanced topic.  That's not necessary for a tutorial.  Tutorials should be scoped to maximize chance of success.


Kubernetes on custom VNET

I seem to be having the same problem as described by ticket 120, namely, that when deploying a Kubernetes cluster in a custom VNET (where the VNET is in a different Resource Group from the cluster), I see "RouteController failed to create a route" errors and am unable to see a simple nginx pod move from PENDING status.
kubectl describe nodes | grep -i network
NetworkUnavailable    True    Mon, 13 Feb 2017 22:21:36 +0000         Mon, 13 Feb 2017 22:21:36 +0000         NoRouteCreated                  RouteController failed to create a route
NetworkUnavailable    True    Mon, 13 Feb 2017 22:21:36 +0000         Mon, 13 Feb 2017 22:21:36 +0000         NoRouteCreated                  RouteController failed to create a route
NetworkUnavailable    True    Mon, 13 Feb 2017 22:21:36 +0000         Mon, 13 Feb 2017 22:21:36 +0000         NoRouteCreated                  RouteController failed to create a route
NetworkUnavailable    True    Mon, 13 Feb 2017 22:21:36 +0000         Mon, 13 Feb 2017 22:21:36 +0000         NoRouteCreated                  RouteController failed to create a route

As noted in that issue, support for this scenario was recently added. You need to update, rebuild, regenerate and deploy a new cluster.
I'm going to go ahead and close this, but please reopen it if there's an issue after you update, etc.

I redeployed the cluster from scratch today, using ACS Engine that was also pulled from today. The log was sent from that fresh cluster.
I attempted to deploy a K8s cluster after that with the Vnet in the same resource group but ran into a deployment failure. I'll redo both processes tomorrow and reopen another ticket if the problem recurs.
Sent from my iPhone
On Feb 13, 2017, at 4:57 PM, Cole Mickens <notifications<EMAIL_ADDRESS>wrote:
Closed #268https://github.com/Azure/acs-engine/issues/268.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/Azure/acs-engine/issues/268#event-960489802, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADqzl8UZ6O0zsRZPx2ihb6OPjbRji7Hiks5rcN_ugaJpZM4L_zNT.

Okay. Note that deploying into a vnet in a different resource group is explicitly NOT supported. If you need that, please file a tracking issue for it (though we will probably not get to it very soon, as it requires work in upstream Kubernetes as well).

I'm facing the same issue. What is the work around this ?

@colemickens @dcieslak19973 I created the custom acs cluster today. I am looking for how to connect my cluster using kubectl, could you please share the steps how to connect my k8s cluster using kubectl.
Regards,
Raja


build: Permission Set Group status check not recognizing previously triggered PSG update

Describe the bug
Two source packages that are deployed one after the other affect the same permission set in a permission set group. The second package seems to check if any permission set groups are being updated, which the cli tells me no.
Continuing to deploy the second package, I get the error message that the PSG that the aliasfied permission set belongs to is being updated and to check back later.
To Reproduce
Order two source-packages one after the other, have the first one contain an empty permission set that is part of a bigger PSG. Have the second one contain access to external and named credentials that are org-specific. Have both of them as part of a release-definition to release to any org.
Expected behavior
The CLI should wait until the PSG is done updating.
Screenshots

Platform Details (please complete the following information):
flxbl-io/sfp:latest
Additional context
Does the CLI only check on PSGs that are part of the package - so do I need to add the PSG to the second source package so that the 'updating' part will get recognized?

@dschibster SFP doesn't check only the PermissionSetGroups that belong to the package; it also checks if any PermissionSetGroup in the organization has been updated.
SELECT Id,MasterLabel,Status FROM PermissionSetGroup WHERE Status = 'Updating'.
Any thoughts @azlam-abdulsalam?

@dieffrei That makes it even stranger then. :)

@dschibster can you check if immediately after the deployment of the first package the PSG recalculation started?
The PSG recalculation is asynchronous maybe, it is taking more time than usual to begin to recalculate.
How frequent is this issue?

I waited for an answer until my next release and this time, it found the updating PSG.
Could it be that the PSG update started after the query was executed? That could explain the lack of waiting the first time I ran the release.

@dschibster I will close this issue, if it happens again, let us know!


Update README.md

Add mention of perfect-freehand, which is what I used for the paths in telestrator.

Oh, nice. Thanks for reaching out and for the recommendation. I hadn’t heard of that tool before, and it looks great. Of course, writing our own drawing engine was part of the fun in this project, but perfect-freehand is definitely more powerful!


questions on VISAM: how to fill --mot_path your_data_path?

Can you provide a more specific guide on how to reproduce your demo with VISAM?

for example, --mot_path=/data/Dataset/mot

Thanks for your quick reply. But I think that it failed to load the config file, even if I use your settings. Did I miss anything?
Here is my error log:
(mmedit-sam) wushuchen@wushuchen:~/projects/SAM_test/Grounded-Segment-Anything$ python grounded_sam_visam.py   --meta_arch motr   --dataset_file e2e_dance   --with_box_refine   --query_interaction_layer QIMv2   --num_queries 10   --det_db det_db_motrv2.json   --use_checkpoint   --mot_path ./   --resume motrv2_dancetrack.pth   --sam_checkpoint sam_vit_h_4b8939.pth   --video_path DanceTrack/test/dancetrack0003
/home/wushuchen/anaconda3/envs/mmedit-sam/lib/python3.8/site-packages/torchvision/models/_utils.py:208: UserWarning: The parameter 'pretrained' is deprecated since 0.13 and will be removed in 0.15, please use 'weights' instead.
warnings.warn(
/home/wushuchen/anaconda3/envs/mmedit-sam/lib/python3.8/site-packages/torchvision/models/_utils.py:223: UserWarning: Arguments other than a weight enum or None for 'weights' are deprecated since 0.13 and will be removed in 0.15. The current behavior is equivalent to passing weights=None.
warnings.warn(msg)
Training with Self-Cross Attention.
None aaaaaaaaaaaaaaaaaaaaa
Traceback (most recent call last):
File "grounded_sam_visam.py", line 253, in
detr, _, _ = build_model(args)
File "/home/wushuchen/projects/SAM_test/Grounded-Segment-Anything/VISAM/models/init.py", line 19, in build_model
return build_func(args)
File "/home/wushuchen/projects/SAM_test/Grounded-Segment-Anything/VISAM/models/motr.py", line 731, in build
num_frames_per_batch = max(args.sampler_lengths)
TypeError: 'NoneType' object is not iterable
And my folder structed is as followed:

Sorry, you can use this param" --meta_arch motr --dataset_file e2e_dance --with_box_refine --batch_size 1 --sample_mode random_interval --sample_interval 10 --sampler_lengths 5 --merger_dropout 0 --dropout 0 --random_drop 0.1 --fp_ratio 0.3 --query_interaction_layer QIMv2 --query_denoise 0.05 --num_queries 10 --append_crowd --det_db det_db_motrv2.json --use_checkpoint --mot_path XXX --resume motrv2_dancetrack.pth --sam_checkpoint sam_vit_h_4b8939.pth --video_path DanceTrack/test/dancetrack0003"， I will change readme

I have the same problem:TypeError: 'NoneType' object is not iterable，thank you for your replay. Other question is: what's in e2e_dance  dir?

I have the same problem:TypeError: 'NoneType' object is not iterable，thank you for your replay. Other question is: what's in e2e_dance dir?

I think it is not a dir, it means only detect people.

Ok. Thanks.
Thank you for your work, it's wonderful !

Here is my error new log when using the new command:

All test image data In /vdb1/dataset/visam/mot/DanceTrack/test/dancetrack0003/img1:

Looking forward to your reply~

xxx.txt in  --det_db det_db_motrv2.json. You can open  det_db_motrv2.json, then you will see it

here. you need to delete “/vdb1/dataset/visam/mot/”

Thanks for your guidance, I have got the final result: "visam.avi"file~ The end result is different from the VISAM in README.md.

Sure, I'm using my own weights. Looking forward to our future code.

i just want to use demo to test my own video, so why should i download the dataset into data folder

So... did anyone actually get this to run? And on their own video file?

Can anybody tell me where is det_db_motrv2.json

det_db_motrv2.json

这个不需要。假如真的想用，可以参考MOTRv2


Painting demo notebook

Let's:

[x] Add some explanatory text
[x] Rename the notebook from testing.ipynb to ColoredCatalogs.ipynb
[x] Perhaps make some plots, showing where the lenses (orange points) and images (cyan points) are in some interesting color space,  (g-r) vs (i-W1) perhaps?

I think we want to send Eric the github URL of this notebook when we ship him our first sim catalog!

[ ] Demo notebook needs to show production straight through to a mock PS1 sample, with plots showing its deficiencies. (how many OM10 objects we are able to match/paint, etc.)

Finalization step: make more descriptive axis labels/titles throughout notebooks

I think the ColoredCatalogs notebook is mature enough for us to close this - nice work, @mbaumer !
It could be that this is a good starting point for a new "PaintingByHand" notebook that @jennykim1016 could make: I'll issue that separately.


generate docs db on build time

If we're doing that, we could probably just output it as rust code and include!() it. Actually, we could probably do that anyway and avoid having to depend on serde-json

I think we don't need to care about dependencies for derive module. It will be only used during the build step. We will not use any serde-json code from the end product.

Whats happening to mac test build?

Oh, wait - also my concern about doing this is that it'll make a cpython environment a requirement for building, which I feel is like undesired.

I can agree about python dependency by how you see the dependency is. Maybe checking for python in local environment or download the pre-built database from internet would work.
I don't agree about build time. It will be run only once unless it needs to be updated, and it requires only one second to run.
time python scripts/generate_docs.py > /dev/null
python scripts/generate_docs.py > /dev/null  0.81s user 0.18s system 97% cpu 1.014 total

Huh, on mine it hangs for ten seconds and then core dumps with an illegal instruction. Are you on an M1? :P
Oh, maybe one of the reasons for that is that it checks every module, right? It needs to be in a totally clean environment to just do the stdlib ones.

Yes, I am using a new clean venv for the build

The build error must be one of the reason we should run scripts on CI

I still really don't think invoking cpython in the build process (and specifically depending on the python environment the build process runs in) is a good idea; even in CI that failure isn't from a stdlib package! it's from python-apt which is probably preinstalled on the runner vm. And also this makes the result of the build vary based on which specific version of python is installed (which I feel like is a bad precedent), and IMO downloading the pre-built database from the web is the same thing as just checking it into the repo in the first place.

I could make a quick patch for that unicode escape issue, but I don't think the stdlib docstrings would ever have a non-ascii character in them.

oh, that explains the reason it only fails on linux!
btw, please check the new build.rs. Unlike ast, doc is totally optional. if it cannot run python, it will build rustpython without document.

I added whitelist to skip third party libraries. it will be faster.

I added whitelist to skip third party libraries. it will be faster. The doc generation is totally optional. Maybe we'd better to have doc feature to skip doc embedding to reduce binary size in future.

I... still don't like that the build will be different depending on the python version installed. I mean, it doesn't really matter that the docs are always up to date, right? If we need to update the docs db, we can, I still don't think I see the benefit of generating them as part of the build process.

oh, that reminded me why i made the doc to json file.
For now, this way is increasing doc coverage because we are not managing doc data.
My first plan for json doc db was collecting data from every OS and merge them to single file.

@coolreader18 no instant generation anymore. will you please also review other PRs?


ALPipeline and ALStrategy

We  propose refactoring the code to decouple the functionality of the active learning pipeline from the active learning strategy. This issue is to discuss the development of an ALPipeline class.
In principle the proposed ALPipeline will succeed the GenericALStrategy class in functionality, and serves to help the user decouple the implementation of their strategies from the overall pipeline. The ALPipeline will facilitate the communication between

a DataManager
a ML model
an AL strategy
an oracle (or None for evaluation mode)

The proposed action is to:

Copy the functionalities of pyrelational.strategies.GenericALStrategy to pyrelational.pipeline.ALPipeline
Adjust the active_learning_step function such that it simply calls upon the strategy to perform such a step. Maybe by calling a strategy specific function called propose() or suggest()

This may call for making an interface which strategies should fulfill corresponding to the informativeness measure utilised and the ranking/selection algorithm used after to keep a consistent interface.
My only fear is that this decoupling potentially makes it more difficult to implement sophisticated selection algorithms for the strategies without direct access to iteration counts etc recorded by the ALPipeline in this situation --- without requiring the AL strategy send a message to the ALPipeline, or requiring the user to augment the ALPipeline and overriding the active_learning_step() to provide arguments to the selection algorithm.

Happy to discuss!

I was thinking about the second point to your second point.
One possible solution would be on pipeline side to have the call to the ALStrategy pass both model and dataset but checking which one the ALStrategy expect at call time. Like torchmetrics handles metric updates with a filter_kwargs https://github.com/Lightning-AI/metrics/blob/1ab660e47890b3273c313458d3c39ff698810857/src/torchmetrics/collections.py#L183. Let's discuss

adressed in PR #33


Should we close peerConnection twice in RTCIceConnectionStateClosed and RTCIceConnectionStateDisconnected

I was tracing a bug made by my own, and I found this part that I have a question.
Should we close peerConnection twice in RTCIceConnectionStateClosed and RTCIceConnectionStateDisconnected?
Or should we have a didDisconnect function to call? Or just igore RTCIceConnectionStateDisconnected?
https://github.com/zevarito/Licode-ErizoClientIOS/blob/04b11d51cbd68fb0c15f0e636884cba9c542fdb7/ErizoClient/rtc/ECClient.m#L265

@allenlinli those are really good concerns, definitely that need to be re-visited, please take a look at the link @kekkokk shared and especially this one[0] that is mentioned there, there is comprehensive explanation about how the standard should work, however in my experience it might differ a little between clients and platforms and ultimately you might have to step aside a little to make it work. Not telling this is the case but this[1] is an example of it.
[0] http://w3c.github.io/webrtc-pc/#rtciceconnectionstate-enum
[1] https://github.com/zevarito/Licode-ErizoClientIOS/commit/ffdf21b583703efead8f6bc889f1d7efbf88fade

Just found more reference here:
"disconnected":
Checks to ensure that components are still connected failed for at least one component of the RTCPeerConnection. This is a less stringent test than "failed" and may trigger intermittently and resolve just as spontaneously on less reliable networks, or during temporary disconnections. When the problem resolves, the connection may return to the "connected" state.
"closed":
The ICE agent for this RTCPeerConnection has shut down and is no longer handling requests.
Though I not still not sure should we have two disconnect here, still.

Since I opened this PR (https://github.com/zevarito/Licode-ErizoClientIOS/pull/75), this issue can be closed.


Enable Wasm CI

See #255 and #264
@TimJentzsch do you have any idea how we can keep the target dir from being invalidated on Wasm builds?

I'll try to take a look tomorrow :)

So one thing that strikes me is that this is not only a problem for WASM -- the test-native job also appears to take a very long time.
Take a look at this job for example: https://github.com/janhohenheim/foxtrot/actions/runs/4997406397/jobs/8951737694
Here, the cache has a hit, but the test is still recompiling the dependencies.
This means that cargo depends on something that is not considered in the cache key.
My first guess is that it's the rustc version, which is still an open issue for the cache action: https://github.com/Leafwing-Studios/cargo-cache/issues/12
I assume that cargo doesn't use any of the cached stuff if it was compiled with an older rust version, which makes sense for performance and other stuff.
So in that case, the cache won't be updated, but can never be used for compilation.
Here's the catch though: We currently use the latest nightly version in CI. That means that, even if we fix the cache action to consider the rustc version, it will be outdated every day and we'll basically render the cache useless.
So we should probably do two things:

Add the rust version to the cache key in the action
Use a fixed Rust version in CI (we could also consider using stable Rust if it's possible for foxtrot)

I'm not 100% certain that this will fix the issue, but it's worth a shot.

We can also try this tip from the Cargo book https://doc.rust-lang.org/cargo/faq.html#why-is-cargo-rebuilding-my-code to get more info on why cargo is rebuilding stuff:
$ CARGO_LOG=cargo::core::compiler::fingerprint=info cargo build

So basically setting the CARGO_LOG variable in CI.
Unfortunately that won't help with debugging why the WASM stuff is rebuilding, as trunk doesn't appear to be forwarding that env variable to the build command as far as I could see.
But it could still  be helpful if the native builds aren't caching properly.

Your reasoning sound sound. I'm very open to setting a fixed nightly version and periodically updating it (say, at every new Bevy release)
The reason Foxtrot uses nightly is because of the if let chain feature, which makes some code much much easier to write, and, ironically, gains in compile time, which in my experience can definitely be felt when compiling on my own machine.

Fair point, I'm really looking forward to if let hitting stable. It really is a great feature

@TimJentzsch looks like pinning the nightly version didn't change anything 🤔

@TimJentzsch looks like pinning the nightly version didn't change anything 🤔

Did you clear the caches afterwards? Since the version is not yet included in the cache hash, they need to be regenerated or it will always start with a different nightly version

@janhohenheim It looks like the caches were still from the old nightly setup, I cleared them just now.
So your next PR will first have to regenerate the caches, but afterwards it should (hopefully) be faster again!

Thanks!! You're the best :D

Small update: The Rust version is now included in the cache key for cargo-cache, so at least that should not be causing trouble anymore


Rename storage methods to follow the commonly accepted NFTs terminology.

This PR renames classes and instances to collections and items in the Uniques pallet in order to follow the commonly accepted NFTs terminology.
PR #11389 renamed the extrinsics but storage helpers kept old names

This PR will change the API here:

Should I update some other documentation files somewhere?


APPEND=false broken when first model has no records

Right now, the way appending is implemented is that the default of APPEND is set to false, and then after the first dump, APPEND is set to true. My first model being dumped has no records in it, so the first dump is skipped entirely, including deleting the seeds file when APPEND is set to false, so the seeds file never gets deleted. This results in APPEND=false effectively not working at all.

Can you give me commands to replicate this behavior? I'm not understanding what you mean. APPEND should always default to false.

Create a database where the first model to be dumped has no records. Dump the whole database twice. You will end up with a seeds file with both dumps in it.
By first dump, I mean first time through the loop at https://github.com/rroblak/seed_dump/blob/master/lib/seed_dump/environment.rb#L19
It runs the first loop, last line sets append = true.
Because the first run had no records, this line triggered:
https://github.com/rroblak/seed_dump/blob/master/lib/seed_dump/dump_methods.rb#L6
which means deleting the old seeds file never happened.

Ah, I see. Thank you for taking the time to dig into this. One thing I add— in order to see this bug one has to specify the MODELS parameter, e.g.
rake db:seed:dump MODELS=Author,Post

where Author is a model with no records and Post is a model with records.
If the MODELS parameter is not specified, the model with no records will be filtered out by https://github.com/rroblak/seed_dump/blob/master/lib/seed_dump/environment.rb#L13, which results in the correct behavior.
I have a tentative patch for this, but I'd like to write a proper test for it before I release. I'll aim to release the fixed version tomorrow.

@mschulkind This should be fixed in version 3.2.2. Thanks again for reporting and looking into this issue :)


How to set default value

Everything works fine , but i need to set a placeholder but everytime the date pops up

You can provide startDate and endDate in your options object. If you want your input updated to the same defaults you have to set the initial value manually.


test-dbalastbackup | Out-DbaDataTable BackupDate incompatibility

Bug Report
General Troubleshooting steps

[x] Verified running latest release of dbatools?
[x] Verified errors are not related to permissions?
[x] Can duplicate in new/fresh PowerShell.exe session?

Version Information

Operating System (Name|Version): Windows 10 Version 1703 (OS Build 15063.674)
PowerShell Version: 5      1      15063  674
SQL Server (Edition|Version): Developer Edition | Microsoft SQL Server 2016 13.0.4206.0 (X64)

Steps to Reproduce
Test-DbaLastBackup -SqlInstance localhost | Out-DbaDataTable | Write-DbaDataTable -SqlInstance localhost -Table Utilities.dbatools.BackupRestoreTests -AutoCreateTable

[x] Attach any screenshots (if possible/allowed)

[x] Attach logs generated by dbatools (Get-DbatoolsLog)
dbatools.log
[x] Attach output from PowerShell console (if possible/allowed)
console.log

Additional Info
USE [Utilities]
GO
CREATE TABLE [dbatools].[BackupRestoreTests](
	[SourceServer] [NVARCHAR](MAX) NULL,
	[TestServer] [NVARCHAR](MAX) NULL,
	[Database] [NVARCHAR](MAX) NULL,
	[FileExists] [BIT] NULL,
	[Size] [BIGINT] NULL,
	[RestoreResult] [NVARCHAR](MAX) NULL,
	[DbccResult] [NVARCHAR](MAX) NULL,
	[RestoreStart] [NVARCHAR](MAX) NULL,
	[RestoreEnd] [NVARCHAR](MAX) NULL,
	[RestoreElapsed] [NVARCHAR](MAX) NULL,
	[DbccStart] [NVARCHAR](MAX) NULL,
	[DbccEnd] [NVARCHAR](MAX) NULL,
	[DbccElapsed] [NVARCHAR](MAX) NULL,
	[BackupDate] [DATETIME2](7) NULL,
	[BackupFiles] [NVARCHAR](MAX) NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

BackupDate column type is [DATETIME2](7)
when performing the same command to gridview with:
Test-DbaLastBackup -SqlInstance localhost | Out-GridView

we see that the BackupDate values are not supported by datetime.

i will be able to overcome this by changing [BackupDate] [DATETIME2](7) type but would like to have this done the correct way especially as the -AutoCreateTable switch is used.

Greetings,
This may have been fixed by another patch, please try again with the most updated version.
ConvertTo-DbaDataTable is no longer required 🎉  You can now just execute
Test-DbaLastBackup -SqlInstance sql2017 | Write-DbaDataTable -SqlInstance sql2017 -Table tempdb.dbo.BackupRestoreTests -AutoCreateTable
If it does not work, however, please note that AutoCreateTable is intended to be a best guess bandaid that uses the first row to guess. For long term table use, we do recommend evaluating the best data types for each column and recreating the table with appropriate dadta types. If you find yourself frustrated by the guesses being too restrictive, you can also use -UseDynamicStringLength which will set everything to nvarchar(max) until you can recreate the table with the appropriate data types.


Flatlist can't scroll

I tested with interactablePlayground example but flatlist can't scroll, i only can swipe interable row.
How to scroll flatlist?
Thanks

That's my patch package:
`diff --git a/node_modules/react-native-interactable-reanimated/src/index.js b/node_modules/react-native-interactable-reanimated/src/index.js
index 321ff17..338f084 100644
--- a/node_modules/react-native-interactable-reanimated/src/index.js
+++ b/node_modules/react-native-interactable-reanimated/src/index.js
@@ -481,6 +481,7 @@ class Interactable extends Component {
<PanGestureHandler
maxPointers={1}
minDist={10}

   failOffsetY={[-10, 10]}
   enabled={this.props.dragEnabled}
   onGestureEvent={this._onGestureEvent}
   onHandlerStateChange={this._onGestureEvent}

`

does it solved ?


(chore) Add ESLint Rules for React-Hooks

Requirements

[x] This PR has a title that briefly describes the work done including the ticket number. If there is a ticket, make sure your PR title includes the ticket number in the format OHRI-123 My PR title.
[x] My work includes tests or is validated by existing tests.

Summary
Description:
This pull request introduces the following updates to the OHRI repository:
1. ESLint Rules for React-Hooks:

Implemented ESLint rules specific to React Hooks (missing dependencies, exhaustive-deps, import type) to ensure consistency and adherence to best practices.
The rules are aligned with those used in the OpenMRS patient-chart project, promoting uniformity across projects.

2. Husky and Lint-Staged Integration:

Added Husky to manage Git hooks, enabling automated tasks to run at various stages of the Git workflow.
Configured Lint-Staged to run ESLint checks on staged files before commits, ensuring that code adheres to linting standards before being committed.

Screenshots

Related Issue

Other
The changes were tested by comparing localhost functionality with the OHRI-dev

@nravilla you have some merge conflicts, would you resolve them please.

Hi Hadijah, Eudson,
thank you for your excellent catch (commented line and yarn.lock) during review yesterday. i have resolved all the issues that was raised.  please let me know if you have any questions or concerns, Thank you so much!


Use YAML for twitter-log output

First @sixohsix, thanks for building this project! :smiley_cat:
Second, I found the twitter-log output looked very similar to YAML, but was less auto-magically parse-able with existing tools. This PR includes a change to YAML (just for twitter-log at this point) which can easily be converted into JSON, XML, etc. (using PyYAML, etc) while remaining legible to mere mortals. :smiley:
It looks essentially like this:
bigbluehat:
 - ID:<PHONE_NUMBER>82842880
   Date: Tue Oct 21 14:22:59 +0000 2014
   Tweet: |
    RT @darylginn: How I use todo apps:
    1. Write some todos.
    2. Never open the app again.
    3. Delete app.
 - ID:<PHONE_NUMBER>80654080
   Date: Mon Oct 20 01:39:26 +0000 2014
   Tweet: |
    @CUGreenville how about adding "chaider" to your menu? "chai steeped in cider instead of water." -- @_beechnut

Parsed with PyYAML, it looks like this:
{'bigbluehat': [{'Date': ..., 'Tweet': ...}, ..., ...]}

So Tweets can be referenced in loops, list comprehension, etc.
It would be a simple tweak to output this in two other variations:

each tweet is a distinct YAML document (which would include the screen_name in the document)
make the output an keyed dictionary, rather than a list.

The current format seemed to provide the most flexibility, but let me know if you'd like me to send PRs for the others (or if this is totally not something you want :wink:).
Thanks again, @sixohsix

prevent breaking existing code, it might be more prudent to introduce YAML output as an option rather than setting it as the default. This approach would allow users to opt in to the new format while maintaining backward compatibility.


Using theme created with 'Create From Current Editor Theme' raises errors

Godot version:
Godot 3.0 RC 1
OS/device including version:
Windows 10 64, GeForce GTX 970,
Issue description:
Using theme created with 'Create From Current Editor Theme' raises errors
Steps to reproduce:
Create theme using Create From Current Editor Theme, errors:

Attach theme to a Control with a couple buttons as children, run project. Errors:

Minimal reproduction project:
Test Godot.zip

@toger5 @djrm @volzhs

Haven't tested yet, but I've seen this was fixed.


check if connected cluster has specified version

Users connected to a cluster at version 1.27 but specify --version 1.23 might be surprised when their cluster schemas override their chosen version.
Possible approaches:

If version is specified, the cluster should only be consulted for builtin types when it matches the provided version.
If version is specified, cluster is ignored. If it is not specified, then will use a default hardcoded version only if cluster is not connected.

I'm interested in working on this, is it still available for picking up?


Implement Namespacing without sacrificing typing.

Since WAT is a Plugin, I would like to avoid polluting the global namespace with it. However some scripts require other scripts to be loaded and vice-versa which means we often run into a cyclical issue if we store all the scripts in one namespace.

Add namespace without sacrificing typing & avoiding cyclical errors.

Impossible until Godot adds some features for it. Put on hold.


Updated profiler section of ingestion

Updated profiler section of the documentation

@TeddyCr could you please update the requirements or note here that this works for 0.12 or higher?


Minor formatting fixes in Porting from PostgreSQL

Should've caught these fixes when reviewing https://github.com/cockroachdb/docs/pull/1328

This change is

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/eeac99a815d984f6f7ba4313f7b9cdd458e9293f/


No data in dropdown (Privacy Settings) when creating new team request

After finally getting the app setup properly, when I click on Build new button from "Scratch", nothing fills into the dropdown. I am assuming that the list would include "Private" or "Public") but there is nothing. Nothing prefills when I want to create a new site from template. I assume again that this would show my templates. Did I miss something?

I am having the same issue. nothing in the drop down.

I was able to resolve this!  Looks like changing the SharePoint site\lists in the power app did not properly save the first time I did this.  I went back through my app and found the lists were again pointing to the fake\initial list.  Deleted these, and ran through the SharePoint connector steps again - chose to save and then publish again and now my dropdown for public\private is populating.

Closing this as it's a duplicate


Basic methods first iteration

First iteration for Exercise Concept for Panic Recover

pani_recover.go
panic_recover_test.go

Upcoming iteration-

Add more methods to panic_recover.go
Add more test cases to panic_recover_test.go
Add .meta folder including config, exemplar, design files
Add .docs folder

Not able to pass github tests for PR can you helpo please @junedev

I can't see that error specifically, only this one:
Error: tmp/lint/concept/panic_recover/panic_recover_test.go:43:2: undeclared name: `fmt` (typecheck)
	fmt.Println(val)
	^
Error: tmp/lint/concept/panic_recover/panic_recover_test.go:41:3: val declared but not used (typecheck)
		val := CreatePanic(tt.name, len(tt.name))
		^

I think you tried to solve the "val declared but not used" with the print, but you are not importing fmt in the tests.
Just to give you a bit more context: the script we have in CI copies the .meta/exemplar.go to a folder with the tests you provide and runs the tests against the exemplar. So, for local development you probably want to keep editing panic_recover.go and implement the solution there, just so you have the tests in the same folder of the solution. When you want to run that solution here in CI copy your implemented solution from panic_recover.go to .meta/exemplar.go and push. When you feel you have the code for the exemplar completely ready and you won't do any more code changes, you can replace the code in panic_recover.go to have the stub and leave the solution in the exemplar.

I can't see that error specifically, only this one:
Error: tmp/lint/concept/panic_recover/panic_recover_test.go:43:2: undeclared name: `fmt` (typecheck)
	fmt.Println(val)
	^
Error: tmp/lint/concept/panic_recover/panic_recover_test.go:41:3: val declared but not used (typecheck)
		val := CreatePanic(tt.name, len(tt.name))
		^

I think you tried to solve the "val declared but not used" with the print, but you are not importing fmt in the tests.
Just to give you a bit more context: the script we have in CI copies the .meta/exemplar.go to a folder with the tests you provide and runs the tests against the exemplar. So, for local development you probably want to keep editing panic_recover.go and implement the solution there, just so you have the tests in the same folder of the solution. When you want to run that solution here in CI copy your implemented solution from panic_recover.go to .meta/exemplar.go and push. When you feel you have the code for the exemplar completely ready and you won't do any more code changes, you can replace the code in panic_recover.go to have the stub and leave the solution in the exemplar.
Also, instead of go/exercises/concept/panic-recover we tend to have simpler module/package names for the exercises. The module/package can just be called something like panicrecover in this case.

thanks @andrerfcsantos will update the code as you said

@myworkcircle It has been a few days since the last update to this PR. Are you still working on this? Can we help with anything?
I'm just asking to know if you are no longer interested in working on this or if you just got busy, or if you are stuck with something. If you just got busy, there's no problem. There's no rush from our side, so don't let this comment pressure you - take your time to finish this. If you are no longer interested in this, that's fine too, just let us know.

Hey Andre,
Sorry for delay in the task. Actually i had started the task then i got
stuck with writing the test cases. As to how to write test cases to check
for panic itself.
Recently i got occupied with some personal issues, so couldn't give time to
this task.
I would say that although im interested in the task. But seeing the current
turn of events i will not be able to again start this task for sometime,
due to some tight schedule for some launches. Really sorry for this.
I understand that task has gotten a lot delayed, So im perfectly fine if
you want to assign this task to someone else.
I can later see how the other person has implemented it and discuss on the
same if i have any doubts. Eventually i believe the goal is to learn and
help the community.
Thanks and Regards,
Pallav Agarwal
On Fri, 15 Apr, 2022, 6:52 pm André Santos, @.***>
wrote:

@myworkcircle https://github.com/myworkcircle It has been a few days
since the last update to this PR. Are you still working on this? Can we
help with anything?
I'm just asking to know if you are no longer interested in working on this
or if you just got busy, or if you are stuck with something. If you just
got busy, there's no problem. There's no rush from our side, so don't let
this comment pressure you - take your time to finish this. If you are no
longer interested in this, that's fine too, just let us know.
—
Reply to this email directly, view it on GitHub
https://github.com/exercism/go/pull/2133#issuecomment-1100106776, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AIVDPA5BD4QSVUPVZ27I7FLVFFUQ3ANCNFSM5RFDSPDA
.
You are receiving this because you were mentioned.Message ID:
@.***>

@myworkcircle No problem, thanks for letting us know. We won't assign it to anyone for now, so feel free to come back at any time.
To test for panics, maybe you can take as inspiration the way the testify.assert package does it. They have several tests for testing for panics, and you can check their source code. For instance, something like this would be an easy way to check for a panic: assertions.go

I am sorry but I will have to put this on hold for now.
Here the official note about this:

We are currently in a phase of our journey where we have paused community contributions to allow us to take a breather and redesign our community model. You can learn more in this blog post. As such, all issues and PRs in this repository are being closed.
That doesn't mean we're not interested in your ideas, or that if you're stuck on something we don't want to help. The best place to discuss things is with our community on the Exercism Community Forum. You can use this link to copy this into a new topic there.


Use case for In-Game Development Engine Automation with rendering system

It would be nice to have a workflow when you can actually deploy an unreal game and run it for automation. You can start Unreal with an exec command that could trigger any gameplay workflow, script, or AI-controlled Pawn and collect information about your tests.
An image could be built on each version and tests could run automatically.
This would be rather interesting to simulate multiplayer workflows by deploying the same container on several hosts and connect them to one another.
Hopefully, I followed your contributing guidelines.
Kind Regards

Apologies for the delay in responding to this issue, I've been inordinately busy over the past couple of months and I'm only now making my way through my GitHub backlog.
The system you're describing (albeit without the use of containers) is the Gauntlet Automation Framework, which has shipped with the Unreal Engine since version 4.21.0. Integration between Gauntlet and Unreal Engine containers has been on my list of things to investigate for quite some time now, so I'll treat this as a +1 for encouraging that investigation.


Support namespaced tagged template strings in JavaScript

Resolves #4001
Changes
Instead of just matching html and css (and, for completeness and consistency, gql), \.?html, \.?css, and \.?gql are matched, which allows for namespaced tagged template strings (e.g., Kitten’s kitten.html) to be recognised and highlighted.
Checklist

[x] Added markup tests, or they don't apply here because...
[x] Updated the changelog at CHANGES.md

@joshgoebel Thank you :)


choke on bad shapefile

given a bad shapefile with a feature w/o a geometery, `gips_{inventory,process,project} chokes and seg faults.
should raise a reasonable runtime error

👍


Enable launchpad build

Enable launchpad build  for both bionic and focal:

[x] update debian packaging #1236
[x] update install filenames for the API #1246
[x] set common tolerance for the unittests to pass on launchpad #1248
[ ] lower tolerance further just for debian builds

Do not close this issue till the launchpad build succeeds.

:octocat: cibot: Thank you for posting issue #1251. The person in charge will reply soon.

All builds pass except armhf bionic.

Wonder if we can close this?

armhf bionic still fails.

Sad


Unix Playbook Fails When Attempting To Download Maven

It appears apache have archived the 3.6.3 download of maven, this URL:
https://downloads.apache.org/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.tar.gz
Should now be:
https://archive.apache.org/dist/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.tar.gz

Good to see VPC working again - it was all over the place when I was trying to run it at the end of last week :-)

Good to see VPC working again - it was all over the place when I was trying to run it at the end of last week :-)

Yup, there's a couple of issues with a platform or two (Solaris and Ubuntu 22.04).. if I get a chance, I'll see if I can get those 2 working again this week.


fix: fix citation file

@hannatolle, here are my changes for the citation file.

great, thanks @juancarlosfarah ! :)


[DO_NOT_MERGE] Added integration tests

Motivation
Integration tests for auth.

@jhellar Could we get label for this as we have done for IOS SDK.
Really cool feature!

@jhellar What is the story here?

@wtrocki we decided to run these tests nightly [1] instead. They will be stored in separate repository. Will close this PR now.
[1] https://issues.jboss.org/browse/AEROGEAR-2737


Option to display both metric and imperial

In my upcoming D&D campaign, we're all using D&D Beyond, but I think I'll be the only one with this extension. So it'd be nice to have the option to see both metric and imperial measurements for when someone uses imperial

Hi there ! Well that can definitely be done, although depending on how D&D Beyond made their website (responsive or not) it may not look good everywhere and that's not something I can control :)
But anywho it'll be done as soon as I can ! (Most likely over the weekend)
Also, you mentioned you probably the only one using MetricBeyond, any reason your players aren't using it ? Anything I can do that would make it easier for them to use ?


Make tokens jitsi-compatible

Modifying tokens a little would let Jitsi accept them:
Header:
{
  "kid": "arena-public-key",
  "alg": "RS256",
  "typ": "JWT"
}
Body:
{
  "context": {
    "user": {
      "name": "<ARENA.displayName + "#4r3n4_" + ARENA.idTag>",
       "arenaId": "<ARENA.idTag>",
       "arenaDisplayName": "<ARENA.displayName>",
        "arenaCameraName": "<ARENA.camName>"
    }
  },
  "aud": "arena",
  "iss": "arena-account",
  "room": "<scene-name>",
  "exp":<PHONE_NUMBER>,
  "sub": "<username>",
  "subs": [ "#" ],
  "publ": [ "#" ]
}

This ensures that our jitsi server is only used by arena users.
Not sure we need arenaId, arenaDisplayName, arenaCameraName, but think it does not hurt.

Ah, screenshare clients need a different context.  Maybe the best is to just remove context from the body (sorry!).
Body:
{
  "aud": "arena",
  "iss": "arena-account",
  "room": "<scene-name>",
  "exp":<PHONE_NUMBER>,
  "sub": "<username>",
  "subs": [ "#" ],
  "publ": [ "#" ]
}

Sure, let me know if this takes care of it: https://github.com/conix-center/arena-account/commit/1eafc8c1b47e07b73d255c03d1be5bdf3c2b7298. We can always add it back.


Issue18

Add nng as an external dependency for libparodus build

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Stefan Knott seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Unable to install/uninstall new version.  stuck to 1.6.3

OS
Windows 11 Enterprise, 22H2
Windows or Linux or Mac
VERSION
1.6.3
ISSUE DESCRIPTION
I can not install the new version.  I did try to remove folders in AppData, Install/Uninstall as Admin.  every time I get that another instance of the app is open. I need to close it manually.  There are no other AnotherRedisDesktopManager process open.

Thnaks
Arash

win +r open runner window, input regedit  to open the registry table, and search for "another", delete all of them
Tips: you'd better install this App without adminstration and for yourself only

Agreed. But how can I uninstall?

remove the install folder directly
rm from registry table
install again


✨ Clean up Prow referenced for old branch name

There are three left over references to master in the presubmit, we need to clean those up to fully switch to main.
/kind cleanup
/milestone v0.1.x
Ref #47

closes #47


Enable Azure Key Vault  for compute linked services

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[Y] The title of the PR is clear and informative.
[Y] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[Y] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[Y] If applicable, the PR references the bug/issue that it fixes.
[Y] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[Y] I have read the contribution guidelines.
[Y] My spec meets the review criteria:

[Y] The spec conforms to the Swagger 2.0 specification.
[Y] The spec follows the guidelines described in the Swagger checklist document.
[Y] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

This commit was treated and no generation was made for Azure/azure-sdk-for-python

This commit was treated and no generation was made for Azure/azure-sdk-for-go

Automation for azure-sdk-for-python

Per communication offline, the error in semantic validation is a false alarm.

Oops, this looks like a bug in travis-ci logic. So for PR_ONLY=true mode, we run the semantic validator on the files that were touched in this PR. Unfortunately this is the PR where only the file containing the model definitions (LinkedService.json) was touched. The actual swagger spec (datafactory.json) was not touched. The actual swagger spec should have been the entry point for the semantic validator instead of the external model file.
If I execute the following command on my machine, then everything works fine.
oav validate-spec https://github.com/fhljys/azure-rest-api-specs/blob/19db39b7ade68cf715a6d4102d6faf81d9215f30/specification/datafactory/resource-manager/Microsoft.DataFactory/preview/2017-09-01-preview/datafactory.json
info: No Errors were found.
Bottom line: in PR_ONLY true mode we need to ensure that we are validating a swagger spec and not a model definition file. The problem here is that model definition files are also swagger specs but they only have model definitions no paths. So we need to find an intelligent way to find out the right swagger spec(entry point) and validate accordingly.
Thanks,
Amar

This commit was treated and no generation was made for Azure/azure-sdk-for-go

Swagger to SDK encountered an unknown error: (Azure/azure-sdk-for-go)
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/swaggertosdk/github_tools.py", line 29, in exception_to_github
    yield context
  File "/usr/local/lib/python3.6/dist-packages/swaggertosdk/restapi/github.py", line 180, in rest_handle_action
    return rest_pull_close(body, github_con, restapi_repo, sdk_pr_target_repo, sdkbase)
  File "/usr/local/lib/python3.6/dist-packages/swaggertosdk/restapi/github.py", line 311, in rest_pull_close
    rest_pr.create_issue_comment("Was unable to create SDK %s PR for this closed PR.", sdkid)
TypeError: create_issue_comment() takes 2 positional arguments but 3 were given


durations both incidents and maintenance

It would be nice to set durations on both normal incidents and maintenance scheduled. At the moment we can set the time of an event, but not how long an incident lasted or how long a particular maintenance window might last.

I'm pushing this back to V3, where we'll have a better structure in place :)

Merged into https://github.com/cachethq/Cachet/issues/1176


Multiple versions of the same package are not supported yet<EMAIL_ADDRESS>was already added to a list of dependencies from /tmp/73fd1a5e-5e33-4998-b465-226491d38ff7/node_modules/@deep-foundation/deepcase/node_modules/@deep-foundation/tsx.   But @tand_ferret/useful_hooks also contains<EMAIL_ADDRESS>dependency at /tmp/73fd1a5e-5e33-4998-b465-226491d38ff7/node_modules/@deep-foundation/tsx

{
  "stack": "Error: Multiple versions of the same package are not supported yet.
<EMAIL_ADDRESS>was already added to a list of dependencies from /tmp/73fd1a5e-5e33-4998-b465-226491d38ff7/node_modules/@deep-foundation/deepcase/node_modules/@deep-foundation/tsx.
  But @tand_ferret/useful_hooks also contains<EMAIL_ADDRESS>dependency at /tmp/73fd1a5e-5e33-4998-b465-226491d38ff7/node_modules/@deep-foundation/tsx.
      at getDeepPackagesDependencies (eval at memoized (/node_modules/lodash/memoize.js:62:23), <anonymous>:118:17)
      at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
      at async eval (eval at memoized (/node_modules/lodash/memoize.js:62:23), <anonymous>:229:38)",
  "message": "Multiple versions of the same package are not supported yet.
<EMAIL_ADDRESS>was already added to a list of dependencies from /tmp/73fd1a5e-5e33-4998-b465-226491d38ff7/node_modules/@deep-foundation/deepcase/node_modules/@deep-foundation/tsx.
  But @tand_ferret/useful_hooks also contains<EMAIL_ADDRESS>dependency at<EMAIL_ADDRESS>}

gitpod /workspace/empty (main) $ npm i<EMAIL_ADDRESS>
added 7 packages in 685ms
gitpod /workspace/empty (main) $ npm list @deep-foundation/tsx
empty@ /workspace/empty
└─┬<EMAIL_ADDRESS>  ├─┬<EMAIL_ADDRESS>  │ ├─┬<EMAIL_ADDRESS>  │ │ └──<EMAIL_ADDRESS>  │ └──<EMAIL_ADDRESS>  └──<EMAIL_ADDRESS>

Looks like that republish of @deep-foundation/mathjs package to 0.0.6 did solve the issue.
gitpod /workspace/empty (main) $ npm i<EMAIL_ADDRESS>npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '<EMAIL_ADDRESS>npm WARN EBADENGINE   required: { node: '^18' },
npm WARN EBADENGINE   current: { node: 'v20.11.1', npm: '10.2.4' }
npm WARN EBADENGINE }
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '<EMAIL_ADDRESS>npm WARN EBADENGINE   required: { node: '^18' },
npm WARN EBADENGINE   current: { node: 'v20.11.1', npm: '10.2.4' }
npm WARN EBADENGINE }
npm WARN skipping integrity check for git dependency<EMAIL_ADDRESS>npm WARN deprecated<EMAIL_ADDRESS>Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.
npm WARN deprecated<EMAIL_ADDRESS>See https://github.com/lydell/source-map-resolve#deprecated
npm WARN deprecated<EMAIL_ADDRESS>See https://github.com/lydell/source-map-url#deprecated
npm WARN deprecated<EMAIL_ADDRESS>Chokidar 2 does not receive security updates since 2019. Upgrade to chokidar 3 with 15x fewer dependencies
npm WARN deprecated<EMAIL_ADDRESS>Use your platform's native performance.now() and performance.timeOrigin.
npm WARN deprecated<EMAIL_ADDRESS>Use your platform's native DOMException instead
npm WARN deprecated<EMAIL_ADDRESS>Use your platform's native atob() and btoa() methods instead
npm WARN deprecated<EMAIL_ADDRESS>some dependency vulnerabilities fixed, support for node < 10 dropped, and newer ECMAScript syntax/features added
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-tracing` package is no longer part of Apollo Server 3. See https://www.apollographql.com/docs/apollo-server/migration/#tracing for details
npm WARN deprecated<EMAIL_ADDRESS>The `graphql-extensions` API has been removed from Apollo Server 3. Use the plugin API instead: https://www.apollographql.com/docs/apollo-server/integrations/plugins/
npm WARN deprecated<EMAIL_ADDRESS>This is probably built in to whatever tool you're using. If you still need it... idk
npm WARN deprecated<EMAIL_ADDRESS>The functionality provided by the `apollo-cache-control` package is built in to `apollo-server-core` starting with Apollo Server 3. See https://www.apollographql.com/docs/apollo-server/migration/#cachecontrol for details.
npm WARN deprecated<EMAIL_ADDRESS>This package is part of the legacy caching implementation used by Apollo Server v2 and v3, and is no longer maintained. We recommend you switch to the newer Keyv-based implementation (which is compatible with all versions of Apollo Server). See https://www.apollographql.com/docs/apollo-server/v3/performance/cache-backends#legacy-caching-implementation for more details.
npm WARN deprecated<EMAIL_ADDRESS>Please upgrade to latest, formidable@v2 or formidable@v3! Check these notes: https://bit.ly/2ZEqIau
npm WARN deprecated<EMAIL_ADDRESS>Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.
npm WARN deprecated<EMAIL_ADDRESS>This module has moved and is now available at @hapi/hoek. Please update your dependencies as this version is no longer maintained an may contain bugs and security issues.
npm WARN deprecated<EMAIL_ADDRESS>This module has moved and is now available at @hapi/boom. Please update your dependencies as this version is no longer maintained an may contain bugs and security issues.
npm WARN deprecated<EMAIL_ADDRESS>This module has moved and is now available at @hapi/accept. Please update your dependencies as this version is no longer maintained an may contain bugs and security issues.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-server-errors` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the `@apollo/server` package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-server-types` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the `@apollo/server` package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-datasource` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-server-plugin-base` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the `@apollo/server` package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-server-env` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the<EMAIL_ADDRESS>package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-reporting-protobuf` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the `@apollo/usage-reporting-protobuf` package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>This package has been deprecated and now it only exports makeExecutableSchema.
npm WARN deprecated And it will no longer receive updates.
npm WARN deprecated We recommend you to migrate to scoped packages such as @graphql-tools/schema, @graphql-tools/utils and etc.
npm WARN deprecated Check out https://www.graphql-tools.com to learn what package you should use instead
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-server-micro` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the `@apollo/server` package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-server-types` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the `@apollo/server` package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-server-plugin-base` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the `@apollo/server` package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-server-types` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the `@apollo/server` package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-server-types` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the `@apollo/server` package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-server-plugin-base` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the `@apollo/server` package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>Please upgrade  to version 7 or higher.  Older versions may use Math.random() in certain circumstances, which is known to be problematic.  See https://v8.dev/blog/math-random for details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-reporting-protobuf` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the `@apollo/usage-reporting-protobuf` package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-reporting-protobuf` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the `@apollo/usage-reporting-protobuf` package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-reporting-protobuf` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the `@apollo/usage-reporting-protobuf` package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-server-env` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the<EMAIL_ADDRESS>package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-server-env` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the<EMAIL_ADDRESS>package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-server-env` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the<EMAIL_ADDRESS>package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>The `subscriptions-transport-ws` package is no longer maintained. We recommend you use `graphql-ws` instead. For help migrating Apollo software to `graphql-ws`, see https://www.apollographql.com/docs/apollo-server/data/subscriptions/#switching-from-subscriptions-transport-ws    For general help using `graphql-ws`, see https://github.com/enisdenjo/graphql-ws/blob/master/README.md
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-datasource` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-server-plugin-base` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the `@apollo/server` package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>Please upgrade  to version 7 or higher.  Older versions may use Math.random() in certain circumstances, which is known to be problematic.  See https://v8.dev/blog/math-random for details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-server-types` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the `@apollo/server` package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-server-errors` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the `@apollo/server` package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>https://github.com/lydell/resolve-url#deprecated
npm WARN deprecated<EMAIL_ADDRESS>Please see https://github.com/lydell/urix#deprecated
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-reporting-protobuf` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the `@apollo/usage-reporting-protobuf` package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-server-env` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the<EMAIL_ADDRESS>package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>The `apollo-server-core` package is part of Apollo Server v2 and v3, which are now deprecated (end-of-life October 22nd 2023 and October 22nd 2024, respectively). This package's functionality is now found in the `@apollo/server` package. See https://www.apollographql.com/docs/apollo-server/previous-versions/ for more details.
npm WARN deprecated<EMAIL_ADDRESS>Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.
npm WARN deprecated<EMAIL_ADDRESS><EMAIL_ADDRESS>is no longer maintained and not recommended for usage due to the number of issues. Because of the V8 engine whims, feature detection in old core-js versions could cause a slowdown up to 100x even if nothing is polyfilled. Some versions have web compatibility issues. Please, upgrade your dependencies to the actual version of core-js.

added 2386 packages in 2m

179 packages are looking for funding
  run `npm fund` for details
npm notice
npm notice New minor version of npm available! 10.2.4 -> 10.5.0
npm notice Changelog: https://github.com/npm/cli/releases/tag/v10.5.0
npm notice Run npm install -g<EMAIL_ADDRESS>to update!
npm notice
gitpod /workspace/empty (main) $ npm list @deep-foundation/tsx
empty@ /workspace/empty
└─┬<EMAIL_ADDRESS>  ├─┬<EMAIL_ADDRESS>  │ ├─┬<EMAIL_ADDRESS>  │ │ ├─┬<EMAIL_ADDRESS>  │ │ │ └──<EMAIL_ADDRESS>deduped
  │ │ └──<EMAIL_ADDRESS>deduped
  │ └──<EMAIL_ADDRESS>deduped
  └──<EMAIL_ADDRESS>
gitpod /workspace/empty (main) $

I consider this issue closed. But there the next problem with installation: https://github.com/deep-foundation/npm-packager/issues/100


[1.12.2] Poof! Mekanism Generators crash...

Please use the search functionality before reporting an issue. Also take a look at the closed issues!
Issue description:
MekanismGenerators crash at 5/7 or a thing like that
Steps to reproduce:

Use a big fat amount of mods
Use latest version of mods
Wait and see

Version (make sure you are on the latest version before reporting):
**Forge: <IP_ADDRESS>66
**Mekanism: <IP_ADDRESS>7
Other relevant version:
If a (crash)log is relevant for this issue, link it here: (It's almost always relevant)
crash-2017-12-15_16.39.58-client.txt
[gist/pastebin/etc link here]

Please use the search functionality. Duplicate of #4827


on_joins tinychat_id parsing

I have noticed that the tinychat id is not available at times. Looking at the code we only see that the tinychat_id is set when receiving an "on_join" from a user, however if we were to duplicate that for "on_joins", I seem to be receiving a tinychat_id for any particular user with an account.
The code line 495, should also be after line 521.
tc_info = tinychat_api.tinychat_user_info(join_info_dict['account'])
            if tc_info is not None:
                user.tinychat_id = tc_info['tinychat_id']
                user.last_login = tc_info['last_active']

As far as i remember i didn't ad that because , imagine the bot entering a room with say 100 user and 70 of those users are using an account, we would then start hammering down tinychat's API with user info request really fast, which could possibly lead to a IP ban.

@nortxort , yes I can see what you mean, so I suppose users currently in the room with an account are not recognised as having accounts, there are only a handful of functions which utilise the account anyhow.

@GoelBiju Correct. What we could do is use !uinfo to check whether a account is set and id is not set, if account is set but id is not , we then look up the account info and ad it to the user object. This way we would at least have the info after doing a !uinfo command. I might do this in next version.

@nortxort , great, that sounds like an appropriate method for this. Thanks!