Cant output es2017

Laravel Mix Version: 6.0.39 (npm list --depth=0)
Node Version (node -v): 17.1.0
NPM Version (npm -v): 8.1.2
OS: macOS BigSur

Description:
When I import a library from node_modules I can control how it's compiled, but when I bundle my own code it's always transpiled to es6 no matter what settings I use.
Steps To Reproduce:

laravel new mix-es2017-fail
put this in your app.js:

let AsyncFunction = Object.getPrototypeOf(async function() {
}).constructor;

npm install && npm run dev
This will output a transpiled babel polyfill. Get it to output es2017 with any config.

Things I've tried:

Webpack custom config:

.webpackConfig({
    target: 'es2017',
    output: {
        chunkFormat: 'array-push',
    },
    resolve: {
        fallback: {
            fs: false,
        },
    },
})

Browserslist config:

supports async-functions
not iE 11

Babel config
All possible combinations and settings

Am I missing something?

I guess we have the same problem. Figures that there wouldn't be any reply to the issue in over a year. Laravel and the node-based build system(s) have a very high hype-train feel to them.
What's the build system in L9? I forgot...


goddammit

Acrolinx Scorecards
A minimum Acrolinx score of 80 is required.
Click the scorecard links for each article to review the Acrolinx feedback on grammar, spelling, punctuation, writing style, and terminology:

Article
AcrolinxScore
LowestCategoryScore
Issues
Scorecard
Processed

enterprise-graph/input-data-concepts.md
80
41
7
link
:white_check_mark:

More info about Acrolinx

Install Acrolinx locally for VSCode
False positives or issues

OPS Build status updates of commit e65cd96:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

enterprise-graph/input-data-concepts.md
:white_check_mark:Succeeded

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


Couchbase plugin

This PR introduces Couchbase support.
I took on the work of #404 , which was partially-working, and added lots of new features. Primarily:

Many, many more new metrics added
Easy to add new metrics in the future
Memcached buckets no longer crash the plugin
Bonus: pep8 + pep257 :smile:

This PR is split into two commits: The first is the original #404 code with the unrelated parts taken out (nagiorelic). The second is the complete re-write I did.
We at Rounds have been running this on production and it's working great.

@rounds/server

@gmr @notnmeyer mrg plz?


Is this right?

The 1098-1117 lines of tool_error.py are as follows
    init_error = []
    for i, (u, l) in enumerate(zip(
        error.survey.inc_rad[1:], error.survey.inc_rad[:-1]
    )):
        init_error.append(0.0)
        if all((
            u > kwargs['header']['XY Static Gyro']['End Inc'],
            l <= kwargs['header']['XY Static Gyro']['End Inc']
        )):
            for tool in kwargs['errors'].gyro_stationary:
                temp = kwargs['errors'].errors[tool].e_DIA[i - 1][2]
                if tool in ['GXY_RN']:
                    temp *= kwargs['header']['Noise Reduction Factor']
                init_error[-1] += temp

    temp = [0.0]
    for i, (u, e) in enumerate(zip(dpde[1:, 2], init_error)):
        temp.append(0.0)
        if u != 0.0:
            temp[-1] += np.sqrt(temp[-2] ** 2 + u * mag)

in these code, "init_error"  totally unused, and the function name is "GXY_GRW", why "GXY_RN" used in code

@zhaoyipeng this code was experimental and shouldn't be used - it was a start and I never finished it off.


Add Porter Terraform Example

This adds an example to the examples directory that leverages the porter-azure and porter-terraform mixins to install, upgrade and uninstall some infrastructure.

@vdice i updated this, take a look.


pull request for e2e test at 01/29/2017 03:26:15

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


fix: FilterTestTrait Undefined variable $filterClasses

Description
Fixes #8113
Follow-up #8058
Checklist:

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

Thanks @kenjis - this was still on my list to get to.


Pin the CMAKE version

Context:
Pin CMake to 3.24.x in wheel-builder to avoid Python not found error in CMake 3.25, when building wheels for PennyLane-Lightning-GPU.
Description of the Change:
All wheels are consistently pinned to the same CMAKE version.
Benefits:
When building Linux wheels for PennyLane-Lightning-GPU, the building process will have a consistent CMAKE version throughout the suite.
Possible Drawbacks:
Related GitHub Issues:

[sc-29794]

Thank you, @chaeyeunpark and @mlxd!


#7401: moved where page mappings are made to outside buffer constructor

Currently the page mappings are being formed in the constructor of device buffer. This is sub-optimal because 1) this is done at runtime 2) not all buffers even need the mappings.
This recently came up with a regression in Bert and ViT perf (which is why I'm labelling this as a p0. @jliangTT )
We only need the mappings when writing directly to a sharded buffer, reading back directly from a sharded buffer and the creation of the program in reshard. For most on device ops we can bypass this.
CC: @davorchap @mo-tenstorrent

Short and simple, 40x improvement on create_sharded_device_tensor with this PR.
Left side is main, 214ms total time spent on create_sharded_device_tensor right is the branch 5.9ms.
BERT FPS is back to expected if not slightly improved.


Ability to define and reuse schemas for primative types

Feature description
I would like to define a schema for an existing type somehow, and use that instead of defining a format everywhere.
For instance, it would be nice to be able to do something like
/**
 *  0x prefixed hexadecimal string
 *
 *  @pattern ^0x[a-fA-F0-9]*$
 */
export type Hex = `0x${string}`

export interface Foo {
   lorum: Hex
}
export interface Bar {
   ipsum: Hex
}

which would ideally output something like
export const hexSchema = z.string().regex(/^0x[a-fA-F0-9]*$/)
export const fooSchema = z.object({lorum: hexSchema})
export const barSchema = z.object({ipsum: hexSchema})

This could potentially also allow schema from third party package to be supported (though their definitions may have to be declared using something other than the jsdoc)
I have not looked too deeply into the code - does something like this seem feasible to implement?

Hello @elee1766
I'm not sure what you're asking 😄
👉 ts-to-zod does not support the template literal 0x${string} but the following input:
/**
 *  0x prefixed hexadecimal string
 *
 *  @pattern ^0x[a-fA-F0-9]*$
 */
export type Hex = string;

export interface Foo {
  lorum: Hex;
}
export interface Bar {
  ipsum: Hex;
}

will output:
// Generated by ts-to-zod
import { z } from "zod";

export const hexSchema = z.string().regex(/^0x[a-fA-F0-9]*$/);

export const fooSchema = z.object({
  lorum: hexSchema,
});

export const barSchema = z.object({
  ipsum: hexSchema,
});

👉 it also supports imports, so if you you want to have
/**
 *  @pattern ^0x[a-fA-F0-9]*$
 */
export type Hex = string;

in a specific file — say hexa.ts —  and the corresponding generated zod validator in hexa.zod.ts then, if you them in your ts-to-zod.config.js like that:
/**
 * ts-to-zod configuration.
 *
 * @type {import("./src/config").TsToZodConfig}
 */
module.exports = [
  { name: "hexa", input: "src/hexa.ts", output: "src/hexa.zod.ts" },
];

any file importing Hex from hexa.ts will automatically import the validator in its generated zod file:
// Input

import { Hex } from "./hexa";
export interface Foo {
  lorum: Hex;
}

// Output

import { z } from "zod";
import { hexSchema } from "./hexa.zod";

export const fooSchema = z.object({
  lore: hexSchema
});

👉 As for 3rd party libraries, if you have a specific example, we could evolve the Config specification to enable imports of Zod Schema from those.

oh, maybe it was the templated literal that was messing with things then? It wasn't working for me. Let me try again and see what happens.
thanks!

Hey @elee1766,
Have you had a chance to try it again?

hey yeah!
so it's working for us for string types but not string template types.
it would be nice if we could also get it working for a string template type. is there any way we can hack around it ?

Hey,
I don't think it is very easy to handle this kind of string template with JSDoc tag, there would be too many specific cases to handle IMO.
A workaround you can rely on is the use of the @schema tag:

// input
/**
 *  0x prefixed hexadecimal string
 *
 *  @schema string().regex(/^0x[a-fA-F0-9]*$/)
 */
export type Hex = `0x${string}`;

// output
// Generated by ts-to-zod
import { z } from "zod";

export const hexSchema = z.string().regex(/^0x[a-fA-F0-9]*$/);

You basically can define whatever you want to be output after the z for your schema that way.

that is good enough i think!


[kddockwidgets] seems to have optional deps

DragController.cpp.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) class std::shared_ptr<class spdlog::logger> __cdecl spdlog::get(char const *)" (__imp_?get@spdlog@@YA?AV?$shared_ptr@Vlogger@spdlog@@@std@@PEBD@Z)
  Hint on symbols that are defined and could potentially match:
    "__declspec(dllimport) public: static class QQmlEnginePrivate * __cdecl QQmlEnginePrivate::get(class QQmlEngine *)" (__imp_?get@QQmlEnginePrivate@@SAPEAV1@PEAVQQmlEngine@@@Z)
    "__declspec(dllimport) public: static class QQuickItemPrivate * __cdecl QQuickItemPrivate::get(class QQuickItem *)" (__imp_?get@QQuickItemPrivate@@SAPEAV1@PEAVQQuickItem@@@Z)
    "__declspec(dllimport) public: static class QQuickItemPrivate const * __cdecl QQuickItemPrivate::get(class QQuickItem const *)" (__imp_?get@QQuickItemPrivate@@SAPEBV1@PEBVQQuickItem@@@Z)

bin\kddockwidgets-qt62d.dll : fatal error LNK1120: 1 unresolved externals

Seems to lookup qtdeclarative/qtquick but is only declaring a dependency on qtbase

https://github.com/KDAB/KDDockWidgets/blob/eb4304f39c706862fa698dc59122ae95fc58c26c/CMakeLists.txt#L162-L190
Definitely auto detected deps here.

Broken by #35882 removing -DKDDockWidgets_QTQUICK=OFF and not controlling KDDockWidgets_FRONTENDS explicitly (since that seems to be the new way to control it). @MonicaLiu0311 please fix your introduced regression


Stop FileList from trying to access system root

Denis noticed that RoR v10 tried to access his system root (rather than the project root as expected) if config.node_modules_location was set to the new default of "" instead of being set to "client". I was able to reproduce this behavior and this is my fix.

This change is

I don't understand why this fix is necessary.
The new default is the rails root directory since v9.

Reviewed 5 of 5 files at r1.
Review status: all files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

lib/react_on_rails/utils.rb, line 125 at r1 (raw file):

    def self.prepend_cd_node_modules_directory(cmd)
      prefix = ReactOnRails.configuration.node_modules_location

prefix is not the right variable name

Comments from Reviewable

Reviewed 5 of 5 files at r1.
Review status: all files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

lib/react_on_rails/configuration.rb, line 136 at r1 (raw file):

                   i18n_dir: nil, i18n_yml_dir: nil,
                   server_render_method: "ExecJS", symlink_non_digested_assets_regex: nil)
      self.node_modules_location = node_modules_location

IMO this is where we should be assigning a default in case of a blank string, not inline in the method. Then the keyword arg default could just be nil like the others.
self.node_modules_location = node_modules_location.present? ? node_modules_location : Rails.root

Comments from Reviewable

Review status: all files reviewed at latest revision, 3 unresolved discussions, some commit checks failed.

lib/react_on_rails/utils.rb, line 126 at r1 (raw file):

    def self.prepend_cd_node_modules_directory(cmd)
      prefix = ReactOnRails.configuration.node_modules_location
      return cmd if prefix.blank? || prefix == "."

given that we've already defaulted the ReactOnRails.configuration.node_modules_location to . in the case that it's blank inside of lib/react_on_rails/configuration.rb, I don't think we really need to make any changes to this file

Comments from Reviewable

@justin808 Because the rails root is NOT currently the default. The system root (i.e. "") is. Denis & I both can attest to that.

Review status: 3 of 4 files reviewed at latest revision, 3 unresolved discussions, some commit checks failed.

lib/react_on_rails/configuration.rb, line 136 at r1 (raw file):
Previously, robwise (Rob Wise) wrote…
IMO this is where we should be assigning a default in case of a blank string, not inline in the method. Then the keyword arg default could just be nil like the others.
self.node_modules_location = node_modules_location.present? ? node_modules_location : Rails.root

Thanks for this. I was sure there was a better way to do it.

lib/react_on_rails/utils.rb, line 126 at r1 (raw file):
Previously, robwise (Rob Wise) wrote…
given that we've already defaulted the ReactOnRails.configuration.node_modules_location to . in the case that it's blank inside of lib/react_on_rails/configuration.rb, I don't think we really need to make any changes to this file

Well, given that I made your suggested change in configuration.rb, ReactOnRails.configuration.node_modules_location.blank? should always be false, correct?

Comments from Reviewable

Reviewed 2 of 2 files at r2.
Review status: all files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

lib/react_on_rails/utils.rb, line 126 at r1 (raw file):

Well, given that I made your suggested change in configuration.rb, ReactOnRails.configuration.node_modules_location.blank? should always be false, correct?

Yep, exactly. So I don't think we need to change this file?

Comments from Reviewable

Review status: all files reviewed at latest revision, 3 unresolved discussions, some commit checks failed.

lib/react_on_rails/utils.rb, line 126 at r2 (raw file):

    def self.prepend_cd_node_modules_directory(cmd)
      return cmd if ReactOnRails.configuration.node_modules_location.blank?
      "cd #{ReactOnRails.configuration.node_modules_location} && #{cmd}"

@robwise @judahmeek is there a chance that we should always CD to Rails.root unless the node_modules_location is set?
My concern is that the test helper will be invoked from running rspec after CD'ing into the spec directory of the root.

Comments from Reviewable

Review status: all files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

lib/react_on_rails/utils.rb, line 126 at r2 (raw file):

is there a chance that we should always CD to Rails.root unless the node_modules_location is set?

Well, with Judah's changes as of r2, the node_modules_location is always set, because if the user doesn't set it, we set it for them.

My concern is that the test helper will be invoked from running rspec after CD'ing into the spec directory of the root.

I'm not sure I follow this, the test helper will only be invoked if you run a file that requires the rails_helper, it shouldn't be based on pwd?

Comments from Reviewable

Review status: all files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

lib/react_on_rails/utils.rb, line 126 at r2 (raw file):
Previously, robwise (Rob Wise) wrote…

is there a chance that we should always CD to Rails.root unless the node_modules_location is set?

Well, with Judah's changes as of r2, the node_modules_location is always set, because if the user doesn't set it, we set it for them.

My concern is that the test helper will be invoked from running rspec after CD'ing into the spec directory of the root.

I'm not sure I follow this, the test helper will only be invoked if you run a file that requires the rails_helper, it shouldn't be based on pwd?

Guessing PWD might be Rails.root/spec, @robwise.
Seems the key thing is the ability to KNOW where the node_modules is set.
Older React on Rails always went to Rails.root/client

Comments from Reviewable

Review status: all files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

lib/react_on_rails/utils.rb, line 125 at r1 (raw file):
Previously, justin808 (Justin Gordon) wrote…
prefix is not the right variable name

said variable no longer exists

lib/react_on_rails/utils.rb, line 126 at r2 (raw file):
Previously, justin808 (Justin Gordon) wrote…
Guessing PWD might be Rails.root/spec, @robwise.
Seems the key thing is the ability to KNOW where the node_modules is set.
Older React on Rails always went to Rails.root/client

The default value of ReactOnRails.configuration.node_modules_location will now be Rails.root unless explicitly set to something else by the user.

Comments from Reviewable

see comments @judahmeek

Review status: all files reviewed at latest revision, 3 unresolved discussions, some commit checks failed.

lib/react_on_rails/configuration.rb, line 136 at r2 (raw file):

                   i18n_dir: nil, i18n_yml_dir: nil,
                   server_render_method: "ExecJS", symlink_non_digested_assets_regex: nil)
      self.node_modules_location = node_modules_location.present? ? node_modules_location : Rails.root

seems this prevents the value from ever being blank

lib/react_on_rails/utils.rb, line 125 at r1 (raw file):
Previously, Judahmeek (Judah Meek) wrote…
said variable no longer exists

How can this be blank now? see comment above.

Comments from Reviewable

Review status: all files reviewed at latest revision, 3 unresolved discussions, some commit checks failed.

lib/react_on_rails/configuration.rb, line 136 at r2 (raw file):
Previously, justin808 (Justin Gordon) wrote…
seems this prevents the value from ever being blank

That's exactly what it does.

lib/react_on_rails/utils.rb, line 125 at r1 (raw file):
Previously, justin808 (Justin Gordon) wrote…
How can this be blank now? see comment above.

It can't be. See my discussion (now resolved) with Robwise about that same line.

Comments from Reviewable

Review status: all files reviewed at latest revision, 3 unresolved discussions, some commit checks failed.

lib/react_on_rails/utils.rb, line 125 at r1 (raw file):
Previously, Judahmeek (Judah Meek) wrote…
It can't be. See my discussion (now resolved) with Robwise about that same line.

To clarify, I pointed out to Rob that I had made this line into dead code and he implied that we should leave it alone (or at least that's the way I interpreted what he said).

Comments from Reviewable

Review status: all files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

lib/react_on_rails/utils.rb, line 125 at r1 (raw file):
Previously, Judahmeek (Judah Meek) wrote…
To clarify, I pointed out to Rob that I had made this line into dead code and he implied that we should leave it alone (or at least that's the way I interpreted what he said).

if I did I apologize, this line is no longer needed after making the default in the configuration, which was why I suggested putting i there, so that we can delete this

Comments from Reviewable

Review status: all files reviewed at latest revision, 3 unresolved discussions, some commit checks failed.

lib/react_on_rails/utils.rb, line 125 at r2 (raw file):

    def self.prepend_cd_node_modules_directory(cmd)
      return cmd if ReactOnRails.configuration.node_modules_location.blank?

I'm confused. Should this line be removed?

Comments from Reviewable

Review status: all files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

lib/react_on_rails/utils.rb, line 125 at r2 (raw file):
Previously, justin808 (Justin Gordon) wrote…
I'm confused. Should this line be removed?

yes

Comments from Reviewable

Reviewed 2 of 2 files at r3.
Review status: all files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

Comments from Reviewable


Exception when using app for telegram

Hi, I am using seq on Linux Ubuntu 22.04 LTS. I also use an app to send information to telegram bot. Periodically I get an exception:
Telegram.Bot.Exceptions.RequestException: Request timed out
---> System.Threading.Tasks.TaskCanceledException: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.
---> System.TimeoutException: A task was canceled.
---> System.Threading.Tasks.TaskCanceledException: A task was canceled.
at System.Threading.Tasks.TaskCompletionSourceWithCancellation1.WaitWithCancellationAsync(CancellationToken cancellationToken)    at System.Net.Http.HttpConnectionPool.HttpConnectionWaiter1.WaitForConnectionAsync(Boolean async, CancellationToken requestCancellationToken)
at System.Net.Http.HttpConnectionPool.SendWithVersionDetectionAndRetryAsync(HttpRequestMessage request, Boolean async, Boolean doRequestAuth, CancellationToken cancellationToken)
at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
at System.Net.Http.HttpClient.g__Core|83_0(HttpRequestMessage request, HttpCompletionOption completionOption, CancellationTokenSource cts, Boolean disposeCts, CancellationTokenSource pendingRequestsCts, CancellationToken originalCancellationToken)
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
at System.Net.Http.HttpClient.HandleFailure(Exception e, Boolean telemetryStarted, HttpResponseMessage response, CancellationTokenSource cts, CancellationToken cancellationToken, CancellationTokenSource pendingRequestsCts)
at System.Net.Http.HttpClient.g__Core|83_0(HttpRequestMessage request, HttpCompletionOption completionOption, CancellationTokenSource cts, Boolean disposeCts, CancellationTokenSource pendingRequestsCts, CancellationToken originalCancellationToken)
at Telegram.Bot.TelegramBotClient.g__SendRequestAsync|22_0[TResponse](HttpClient httpClient, HttpRequestMessage httpRequest, CancellationToken cancellationToken)
--- End of inner exception stack trace ---
at Telegram.Bot.TelegramBotClient.g__SendRequestAsync|22_0[TResponse](HttpClient httpClient, HttpRequestMessage httpRequest, CancellationToken cancellationToken)
at Telegram.Bot.TelegramBotClient.MakeRequestAsync[TResponse](IRequest1 request, CancellationToken cancellationToken)    at Telegram.Bot.TelegramBotClientExtensions.SendTextMessageAsync(ITelegramBotClient botClient, ChatId chatId, String text, Nullable1 parseMode, IEnumerable1 entities, Nullable1 disableWebPagePreview, Nullable1 disableNotification, Nullable1 replyToMessageId, Nullable1 allowSendingWithoutReply, IReplyMarkup replyMarkup, CancellationToken cancellationToken)    at Seq.App.Telegram.TelegramReactor.OnAsync(Event1 evt) in C:\projects\seq-app-telegram\src\Seq.App.Telegram\TelegramReactor.cs:line 83
at SeqCli.Apps.Hosting.AppContainer.SendTypedEventAsync(String clef) in C:\projects\seqcli\src\SeqCli\Apps\Hosting\AppContainer.cs:line 113
Are there any ideas why this exception happens? It hangs my server and i need to reboot it every time...

Hi Anton, thanks for dropping us a line.
This looks most like an issue with the Telegram bot; I'd start over in Seq.App.Telegram and look at updating the version of the Telegram.Bot package dependency there, as well as potentially adding a retry loop (Polly?) around the line that sends the message.
If the entire server hangs I'd suspect something else going on, Seq apps run in separate processes and usually can't cause the main Seq process to fail - interested in any more details you can share, if you think that may be happening.
Best regards,
Nick

Thanks for answer Nick. I figured out what was going on. The server was not powerful enough, when I increased the server resources, the problem disappeared...
Anton, best regards.


Could we replace find().exists() with exists()?

Hi, folks! 👋
The main goal of find() is to assert something exists. However, we should be aware that
expect(wrapper.find('#whatever')).toBeTruthy()

is dangerous, as it might lead to false negatives. This is happening right now, for instance, here https://github.com/vuejs/vue-test-utils-next/blob/master/tests/features/transition.spec.ts#L9.
Just to prove the point, replace line 7 with expect(wrapper.find('#message')).toBeTruthy() and the test still passes (even though "it shouldn't"). btw, I just submitted a PR to ~fix~ improve the assertion: https://github.com/vuejs/vue-test-utils-next/pull/139.
State of the art

find() + toBeTruthy() is dangerous.
In docs, we suggest using find() + exists() to assert whether if it does exist (or not). get() is the way to go to get an existing element.
thus, AFAICT find() does only make sense when bounded to exists().

Suggestion
Given that scenario, would it be sensible to ditch find() and make exists() behave like find().exists()?
To maintain some consistency, what if findComponent became getComponent? So:

get()/getAll(): gets you an (or an array of) element or throws.
getComponent(): gets you a component or throws.
exists(): returns whether if the query for an element succeeded.
find/findAll/findComponent would disappear from the public API.

Doubts? Suggestions? Am I missing some use case for find? 🤔

Removing find is a pretty steep breaking change. Do you mean ditch from codebase or docs? What about findComponent.
Also according to this, exists will work like 'contains', if passed parameters. Would this work on querySelector type DOM queries only, or can we assume that findComponent type queries would also work?

Thanks for sharing your thoughts! 🙌

Removing find is a pretty steep breaking change

It is def a breaking change. The migration would be find() -> get() or find() -> exists(). Not sure if there's a way to narrow the "algorithm" down, but: if find() is followed by exists(), then exists(). If followed by any other method, then get().

What about findComponent

Good question. getComponent?

Would this work on querySelector type DOM queries only, or can we assume that findComponent type queries would also work?

to be honest, findComponent is not something I spend much brain power on 😅 as mentioned above, it could be renamed to getComponent if we want to keep a method that returns a VueWrapper, and even a existsComponent would make sense to match exists. Just thinking out loud, here.

I have noticed that ErrorWrapper is still a truthy value. I can see why this leads to bugs like the one you described.
I agree in theory - with get, find it not very useful except for specifying an element does not exist. We also had a contains method in VTU too, which is similar to the exists you described 🤔
The main problem I foresee is what @dobromir-hristov described - some codebases exclusively interact with components (via findComponent). Eg findComponent(Foo).vm.$emit. Good or bad, this feels like too big a breaking change.
I'm not sure it makes sense to add an entire new API for just one use case.  VTU v1 had a pretty large API, mainly due to adding methods for specific use-cases.
I will keep thinking about this.

some codebases exclusively interact with components (via findComponent). Eg findComponent(Foo).vm.$emit. Good or bad, this feels like too big a breaking change.

To maintain some consistency, what if findComponent became getComponent? So:

get(): gets you an element or throws. Same thing with getAll.
getComponent(): gets you a component or throws.
exists(): returns whether if the query for an element succeeded.
find/findAll/findComponent would disappear.

Adding existsComponent() would also make sense in terms of completeness, even though I'm not sure it is that useful 🤔

I'm not sure it makes sense to add an entire new API for just one use case

Totally agree! That's why I suggest merging find().exists() into exists(), and remove find() :)

This makes a lot of sense to me. I think this is still a very significant breaking change, and should be considered very carefully. As someone looking to improve VTU, I love it. As someone with a large Vue app using VTU heavily, I'm not sure. @dobromir-hristov probably has a better perspective, I know he works on a very large Vue codebase.
Another option is extending get: wrapper.get('#foo', { error: false }). You could use it like find. 🤷♂
Finally, we could continue to have find, to help people upgrade. If we did make this breaking change. Or just leave them, but don't document them.
I will think about this a bit more. I definitely agree the new API you suggested is better, but I feel like people did not respond well to the breaking changes with v1.
I would like to get other opinions and perspectives. Getting feedback about this is quite challenging!

One thing i see allot is in beforeEach ppl mount the wrapper and find 3 4 main elements they work with and save to vars.
Then they assert either existence or attributes in each test, sometimes calling setProps at the beginning of the test. It makes for some very minimal tests, that ofc have their limitations.
Using get would make this approach instantly broken, as it will throw in the beforeEach.

I like this idea tbh, we can always emphasize this is the recommended way to do things from now in, and leave find as an advanced use case, lets say.

If we decide to go ahead with this, we should make an RFC.

One thing i see allot is in beforeEach ppl mount the wrapper and find 3 4 main elements they work with and save to vars.

I didn't think of this. I have seen these kinds of tests (mainly in VTU bug reports and #testing in Vue-land):
let foo
let bar
let wrapper

beforeEach(() => {
  wrapper = mount...
  a = wrapper.find('a')
  b = wrapper.find('b')
})

This would no longer be possible with the above API. This seems like a blocker... have both find and get, which do similar things but solve different problems is a code smell, to me.

Thanks all for the input!

This would no longer be possible with the above API

Yep. However, it is not that VTU fails to cover a use case. It is true, though, that migrating from this kind of setup would not be as straightforward as search&replace.

If we decide to go ahead with this, we should make an RFC.

Do you want me to go ahead and write a proper RFC? I feel we've shared some concerns/ideas and iterated the initial proposal a bit, so I'm OK with writing that up even if it ends up being rejected :)

Hm... how can you accomplish the above with the new API? You would need to change the tests to redeclare foo and bar locally for each test. This really forces people to write their tests in a certain style. While I personally don't mind opinionated libraries, I'm not sure that is the direction an official Vue library has the luxury of taking.
An RFC is definitely the next logical step - not many people will see this discussion, but an RFC will definitely gain more attention.
I would recommend drafting the RFC somewhere (here, notion, where-ever) and getting feedback on it first - that way we can try to anticipate and prepare some responses. What do you think?

While I'm not entirely sure this isn't a direction VTU should not take (it is as "mandatory" as any other decision we made) I understand why this would trouble some users and make it harder for them to upgrade to v2.
I'm still up for this change, but I agree we could explore other alternatives that would led to a more ergonomic API.
Would something along the lines of wrapper.get('#foo', { error: false }) (whatever the option name would be), as @lmiller1990 mentioned, work?
let wrapper, a, b

beforeEach(() => {
  wrapper = mount...
  a = wrapper.get('a', { error: false })
  b = wrapper.get('b', { error: false })
})

This would make this option way less relevant (it's way more hidden than having find()), so people and docs could focus on get() while also providing the ability to use the beforeEach strategy.

re RFC, totally agree that having a draft here is wise 👍 . I'll take care of it once we've decided which version (if any) we're more comfortable with, and which are the alternatives :)

The tests could still be fine with something like the following, no?
beforeEach(() => {
  wrapper = mount...
-  a = wrapper.find('a')
+  a = () => wrapper.get('a')
-  b = wrapper.find('b')
+  b = () => wrapper.get('b')
})

it('should get a, () => {
- expect(a.text).toBe('Hello');
+ expect(a().text).toBe('Hello');

The tests could still be fine with something like the following, no?
beforeEach(() => {
  wrapper = mount...
-  a = wrapper.find('a')
+  a = () => wrapper.get('a')
-  b = wrapper.find('b')
+  b = () => wrapper.get('b')
})

it('should get a, () => {
- expect(a.text).toBe('Hello');
+ expect(a().text).toBe('Hello');

Thought about that, too! (this is how I write tests with Testing Library)
However, I'm afraid expect(a().text).toBe('Hello') would throw anyway. You could write something like expect(a()).toThrow() if you want to assert that something doesn't exist, but the API looks a bit off.

Small update! Evan mentioned that it would great to get all the core libs to move to beta sooner rather than later.
I am thinking we should probably keep breaking changes to a minimum for VTU v2. While the APIs here seem like they might be better, I don't know if we have a lot of time to make breaking changes. I would be much more in favor of additional, optional improvements where possible, instead of breaking changes.
Did anything come from this? Seems like a lot of cool ideas, does anyone have a specific one they would like to peruse?

With all the other core packages going to beta (Router, Vuex)... we should also be heading to beta soon. I think we should not making any more API changes for the time being; we can add additional methods, and deprecating existing ones, but that will not be prior to 2.0.0.

Agree on that!


Solve some security vulnerabilities and bump version to 6.1.2

Before:
166 vulnerabilities (1 low, 66 moderate, 67 high, 32 critical)
After:
10 vulnerabilities (7 moderate, 3 high)
Runtime - 0 vulnerabilities
All tests are green.

since there are tests for older versions of webpack

Let's remove them then if we don't use those versions already

Lowered issues to -
19 vulnerabilities (14 moderate, 5 high)
All high issues are in the latest versions of the packages. I think we can leave it like that for now.

Published<EMAIL_ADDRESS>


Send Successful screen - Need to show the right places sats being sent to

I did not send sats to a vault. I sent it to a bitcoin address. The app should detect where the sats are going and show corresponding icon and text. The variations will be: 1) To an address. (2) To a wallet within Keeper. (3) To a vault within Keeper.
If the user has given a name to the wallet or vault within Keeper, the app should use that.

Not resolved.

Its transferring from vaults to wallets and wallets to vaults (also with addresses) and the icons are working fine


Improve XRSettingsUtilities.IsLegacyXRActive check

Overview
Currently, this property iterates through all subsystem descriptors and checks which ones are XRDisplaySubsystemDescriptors. I missed the fact that I could ask for specific descriptor types in the original implementation...this PR fixes that, to save some iterations and casts.

/azp run


RST rendering on github

Environment variables in the tutorial page render on github as:
:envvar:`DESISURVEY_OUTPUT`

This might be a limitation of the github RST engine, but I believe that github is the only place someone might read this page.  Assigning to @weaverba137 since he did the md->rst conversion.

The when tutorial page appears on Read the Docs, so the Sphinx rst formatting will be appropriate.

In practice it isn't yet on readthedocs and we tend to link to github a lot anyway, so writing our rst in a way that looks good on github is still useful.
Is there any significant difference to using :envvar:DESI_OUTPUT vs. just DESI_OUTPUT or it it mainly a matter of formatting purity?

I see desisurvey on readthedocs but not surveysim.

I was going to set it up soon.

Can I ask for just a teensy bit of patience here?  The file is written in a way that is appropriate to Sphinx + Read the Docs.  That is a good thing!

Its not urgent, thanks.

http://surveysim.readthedocs.io/en/latest/tutorial.html is now active, though it also needs some minor fixes similar to desisurvey.

Addressed by #51.


Some text changes, and cleaning up the real estate format

@adfineberg this need to be merged right?


Support day.js

Is your feature request related to a problem? Please describe.
There are minor issues with the UTC date conversion in the current element due to the fact that the planet is not flat.
Describe the solution you'd like
Support https://day.js.org/ for correct UTC conversion.
Example use of lib https://github.com/Alaska-ECommerce/DisruptionsCenterSite/blob/main/client/utils/dateUtils.js

While the idea was to use dayjs, when I got into this work, updating the whole element API to use dayjs for their way of supporting time zones didn't seem appropriate.
In the end, the issue that really exists is that the date we get from the API is using a non-standard time zone support. So regardless of using the native JS API or dayjs, the issue remains that we need to extract the time zone info from the data and apply the correct time zone strings.
Most of this is already supported by the element as built.


append(char32_t) does not convert back to UTF-8?

Try calling, for example, my_string.append(U'ü'). The character will be garbled.
The workaround is to convert it to a UTF-8 string in any form.

Hi Vadim!
Thanks for the spot! I have hopefully fixed this bug by fixing utf8_string::utf8_string( value_type ).
Please check again with the newest commit and tell me whether it worked.
Thanks
Jakob

Hi Jakob,
Yep - this one is fine! Thank you very much.
Best regads, Vadim

Yay!


Fix authentication with extension in Chrome Incognito mode

It appears that authentication is generally broken in Chrome Incognito mode:

Notify the Pravica team once resolved.

Extensions are generally disabled in incognito mode, right?

By default yea, but you can selectively turn them on for Incognito.


TypeError, Evented undefined

Hello, I encountered an error that says:
"Uncaught TypeError: Cannot read properties of undefined (reading 'Evented')."
Do you have any suggestions on how to resolve it?

This happens when you don't include Mapbox GL JS into your page. Try to include the JavaScript and CSS files of Mapbox GL JS itself AND this plugin in the <head> of your HTML file.
<link href="https://api.mapbox.com/mapbox-gl-js/v2.13.0/mapbox-gl.css" rel="stylesheet" />
<script src="https://api.mapbox.com/mapbox-gl-js/v2.13.0/mapbox-gl.js"></script>
<script<EMAIL_ADDRESS>


Support for input argument deprecation

Is your feature request related to a problem? Please describe.
In the version 15.4.0 the graphql-js package introduced the support for input argument deprecation.
In version 15.5.0, the introspection query was extended and the IntrospectionOptions type was extended by the option inputValueDeprecation. See IntrospectionOptions
The introspection plugin, does not include the new config variable. As a result, this new feature is not usable with the graphql-code-generator.
Describe the solution you'd like
Add an inputValueDeprecation field to the IntrospectionPluginConfig and include the value on the introspectionFromSchema call, see here

Would you create a PR for that change?

I'd be happy to do that, however, the link to your Contributor Workflow Guide seems to be broken, so I'm not sure how I can contribute.

Fixed :)

@ardatan I noticed, that the current implementation does include the deprecated inputFields by default.
I got confused by the fact, that IntrospectionOptions describe the inputValueDeprecation option as false by default, which is applicable for the getIntrospectionQuery method.
However, the introspection-plugin uses the introspectionFromSchema method, which accepts the IntrospectionOptions, but the implementation sets the inputValueDeprecation option to true by default.
Furthermore, apollo-server does not support the deprecation of input fields yet, which I wasn't aware of before.

You can close this ticket and I'd suggest creating a PR with the changes I've already made, if that's wanted.
The changes would

add the deprecation reason of the input field to the generated types. Similar to what is already in place for Fields
allow you to exclude deprecated input fields via the configuration

@dmateiu I'm closing. Feel free to open a PR, we always encourage contributions :)


update dependency name to avoid warning

Thanks, but this has already been resolved in #173. Just need @cgiffard (ping) to publish the changes to npm :)

Just wanted to jump on here to let you guys know I wasn't dead, and I'm getting the emails, but I'm absolutely smashed with work — I'll get to this ASAP tomorrow, I promise! :(


Discussion of how various chemicals in CHEBI are classified as lipids.

In a recent import of CHEBI into the Gene Ontology, a diff report showed several unexpected new inferences involving lipid metabolic processes. that we have not seen in the past:
Added
•	fumarate transmembrane transporter activity SubClassOf lipid transporter activity
Added
•	fumarate transport SubClassOf lipid transport
Added
•	negative regulation of tetrapyrrole biosynthetic process from glycine and succinyl-CoA SubClassOf negative regulation of lipid metabolic process
Added
•	succinate metabolic process SubClassOf lipid metabolic process
Added
•	tyrosine catabolic process to fumarate SubClassOf lipid biosynthetic process

We would NOT expect succinate or fumarate to be connected to lipid metabolic process.  However, they are both classified as 'fatty acids', and hence a lipid.  The  'functional chain' of fatty acid in these two cases seems is very short.

Since the definition 'Lipids'  Chebi CHEBI:18059 Lipid is a loosely defined term for substances of biological origin that are soluble in nonpolar solvent, we looked at numerous resources having information of the solubility of these acids.
Many web sites declare that succinic acid is water-soluble  (58g/l; wiki, although  83 g/1000 ml (25 °C, reported http://www.sciencemadness.org/smwiki/index.php/Succinic_acid)  and is not soluble in non-polar solvents like hexane. ; fumaric acid, however, is certainly less water-soluble (about 4.9g/l, wiki), and Chemical Book states 6.3 g/1000 mL (25 ºC), . It is soluble in ethanol, slightly soluble in water and ether, but insoluble in chloroform.
We are wonder if the classification as a lipid is ignoring the water solubility of these compounds. Does solubility in non-polar solvents preclude water solubility?
Lipidmaps also classifies succinic acid as a fatty acid, but has recently removed fumaric acid (reason not known)

We would also not expect an amino acid, tyrosine, to a lipid. We assume that we pick this up because tyrosine is a 'structural derivative 'of propionic acid which in turn is classified as a fatty acid, and thus a lipid. Would like clarification on what is a structural derivative; we are thinking that we should NOT reason over this relationship.

We think that there may need to be some re-examination of some of these relationships.

Hi Harold,
Indeed the definition of a lipid is pretty vague and in this case the solubility was ignored and the compounds were classified following the LIPID MAPS classification. I have now deleted the relationship to a lipid for fumaric acid.
Regarding tyrosine, I agree with you,I would not expect that an amino acid is classified as a lipid, maybe need to ignore "structural derivative" relationships.

Hi Harold,
As a chemist i personally wouldn't classify succinic acid as a lipid. This is something that the lipid community needs to decide and agree on. A few months ago, i contacted Lipid Maps and received the following response:
'' I guess it both is and isn't a lipid depending on your point of view. As there's no agreed definition of a lipid, its impossible to tell. Succinic acid is  not produced biosynthetically in the same way as longer chain fatty acids, so I can see that it might not count as a lipid biosynthetically, but there's no cut off for when a dicarboxylic acid becomes long enough to be called 'fatty'

We also see that even shorter (malonic acid) appear to be classified as a lipid in CHEBI (3 carbon)
Oxalic acid does not seem to be.;

These relationships are not being added by the ChEBI team. @aimol (Rhea) is making these changes in ChEBI based on the Lipid Maps classification. We have had discussions about this in the past, i think this topic requires further discussion with the Lipids community since they need to decide what constitutes a lipid and what doesn't.

Hi Harold,
Oxalic, like Acetic has only 2 carbons and these are not considered lipids.
From: Harold Drabkin @.>
Sent: Tuesday, December 7, 2021 1:58 AM
To: ebi-chebi/ChEBI @.>
Cc: Lucila Aimo @.>; Comment @.>
Subject: Re: [ebi-chebi/ChEBI] Discussion of how various chemicals in CHEBI are classified as lipids. (Issue #4176)
We also see that even shorter (malonic acid) appear to be classified as a lipid in CHEBI (3 carbon)
Oxalic acid does not seem to be.;
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/ebi-chebi/ChEBI/issues/4176#issuecomment-987016899, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEGTEKJYFOYQQVRYPCN3WK3UPT2TVANCNFSM5JFQPJXQ.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Correct, I added these relations based on LIPID MAPS classification. I have now removed the relationships for succinic and malonic. As discussed, it is hard to define what constitutes a lipid, if we follow the definition of lipid used in CHEBI that they must be soluble in nonpolar solvents, then we disregard LIPID MAPS classification and remove those relationships.
Cheers,
Lucila
From: amalik01 @.>
Sent: Tuesday, December 7, 2021 2:03 AM
To: ebi-chebi/ChEBI @.>
Cc: Lucila Aimo @.>; Mention @.>
Subject: Re: [ebi-chebi/ChEBI] Discussion of how various chemicals in CHEBI are classified as lipids. (Issue #4176)
These relationships are not being added by the ChEBI team. @aimolhttps://github.com/aimol (Rhea) is making these changes in ChEBI based on the Lipid Maps classification. We have had discussions about this in the past, i think this topic requires further discussion with the Lipids community since they need to decide what constitutes a lipid and what doesn't.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/ebi-chebi/ChEBI/issues/4176#issuecomment-987020891, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEGTEKOCIPPUQHDRM365V6DUPT3GZANCNFSM5JFQPJXQ.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

This is great. Can you tell me when these changes will be reflected in the public release CHEBI?

ChEBI's next release will be on the 1st of Jan 2022. You can redo your import after this date.

After updating the CHEBI import with the new release,
https://github.com/geneontology/go-ontology/pull/22657
we still get these inference s
succinyl-CoA binding http://purl.obolibrary.org/obo/GO_0120226
Added
succinyl-CoA binding SubClassOf lipid binding
succinyl-CoA biosynthetic process http://purl.obolibrary.org/obo/GO_1901290
Added
succinyl-CoA biosynthetic process SubClassOf lipid biosynthetic process
succinyl-CoA catabolic process http://purl.obolibrary.org/obo/GO_1901289
added
succinyl-CoA catabolic process SubClassOf lipid catabolic process
succinyl-CoA metabolic process http://purl.obolibrary.org/obo/GO_0006104
Added
succinyl-CoA metabolic process SubClassOf lipid metabolic process
We believe this is because in CHEBI  succinyl-CoA (5-) is a child of both omega carboxyacyl-CoA(5-) and
omega carboxy (fatty acyl) CoA (5-). The latter one is a child of 'lipid' whereas omega caboxyacyl-CoA(5-) is not. Can this be looked at?

I have now removed the  ω-carboxy-(fatty acyl)-CoA(5−) relationship from this entry. If you think there are other issues with some of the other entries, then please do let me know. Thanks


Refactoring packet response handlers to not use GUI as data store

I went to add automated on-connect commands and near the end I realized the majority of packet handling code is directly tied to forms currently being open (GetPasswordsResponse, etc). Rendering that feature I wrote mostly useless.
So, data ingestion/storage in HandlePacket and the views for this data need to be decoupled. This is probably the first step to porting the server to be usable via CLI as well.
I'd propose this design pattern for the refactored handlers, though I'm not a C# pro:

Run a thread to process data into desired format.
Store data into dict/hashmap/list/etc. for the feature, kept in either QuasarServer or CommandHandler or perhaps a new class specifically for feature-data storage/serialization.
Call out to the GUI elements to refresh their data. (either pass the new data or the GUI has access to the data storage singleton?)

Here's a list of handlers that store packet results directly to GUI that need to be modified, ones left out only act as a success-indicator for GUI actions.

[ ] HandleSetStatus
[ ] HandleSetUserStatus
[ ] HandleGetProcessesResponse
[ ] HandleGetDrivesResponse
[ ] HandleGetDirectoryResponse
[ ] HandleDoDownloadFileResponse
[ ] HandleGetSystemInfoResponse
[ ] HandleGetMonitorsResponse
[ ] HandleGetWebcamsResponse
[ ] HandleGetWebcamResponse
[ ] HandleDoShellExecuteResponse
[ ] HandleGetStartupItemsResponse
[ ] HandleGetKeyloggerLogsResponse
[ ] HandleLoadRegistryKey - might not be needed, but I can see use case where you'd want to pull data from client registries asynchronously using this
[ ] HandleGetConnectionsResponse

So that's going to be a weekend project for (me || anyone else who needs this quicker) eventually, I'd love input from people on the project if you'd like to see it implemented differently :)

@dwendt good!

Hey @MaxXor, I've abstracted getting/setting data for unique clients into a Storage singleton. For actually handling the writing/getting/searching in this class a DB makes the most sense. Would you be against a PR that rolls in http://www.litedb.org/ to do this in a local file?

@dwendt I like your idea, but porting all that would rewrite a big part. I think you want to do something like on client connection, request chrome passwords.? Or? You could fix that by adding a new packet, like: ServerRequestPasswords and create a commandhandler entry for it to save it to a file ;)

This has been fixed in https://github.com/quasar/Quasar/releases/tag/v1.4.0


General Improvements

improved checks for registration and enabled repository
created fact for enabled rhsm repos

Hi,
Why did you close the pull request? I did not look at code but the
improvements looked interesting.
Thanks,
Ger
Verstuurd vanaf mijn telefoon.
Op 20 nov. 2015 04:11 schreef "VeriskPuppet"<EMAIL_ADDRESS>
Closed #3 https://github.com/gerapeldoorn/puppet-rhsm/pull/3.
—
Reply to this email directly or view it on GitHub
https://github.com/gerapeldoorn/puppet-rhsm/pull/3#event-469952985.


ProtectedToPrivateFixer: minor optimization

Following https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/2972#discussion_r133924837 I tried to make this fixer faster, but the trait check doesn't let me skip getting the class close before the main loop.
Any other idea is welcome

Thank you @Slamdunk.

merged into 2.2


Versioning library should support adding an auth type in a new version

I could not find a way to specify that a service added a new authentication type in a new version.  I tried:
@versioned(Versions)
@useAuth(
  ApiKeyAuth<ApiKeyLocation.header, "api-key"> |
  @added(Versions.v2) OAuth2Auth<[
    {
      type: OAuth2FlowType.implicit,
      authorizationUrl: "https://login.contoso.com/common/oauth2/v2.0/authorize",
      scopes: ["https://widget.contoso.com/.default"],
    }
  ]>
)
@service({
  title: "Widget Service",
})
namespace DemoService;

enum Versions {
  v1,
  v2,
}

but this gives the error:
error invalid-decorator-location Cannot decorate expression.

Think this comes to the versioning of decorators

pri: 2

This playground shows how you can add the decorator using the is workaround. However, it throws a weird error that seems like a bug.
@markcowl consider flagging this a bug and re-evaluating when that is fixed.


Implemented support for image inputs

Support for image inputs was added in LangChain4j chat API as well as OpenAI & Gemini integrations

@glaforge could you please review Gemini part? Thanks!

@liushuaikobe most probably end of this week or during the next week. In the meantime, you can build a snapshot

Awesome, this update is so timely, I just needed it!


Refactor Kraken2 to use viral db for tests

nf-core/viralrecon pull request
Many thanks for contributing to nf-core/viralrecon!
Please fill in the appropriate checklist below (delete whatever is not relevant).
These are the most common things requested on pull requests (PRs).
PR checklist

[ ] This comment contains a description of changes (with reason)
[ ] If you've fixed a bug or added code that should be tested, add tests!
[ ] If necessary, also make a PR on the nf-core/viralrecon branch on the nf-core/test-datasets repo
[ ] Ensure the test suite passes (nextflow run . -profile test,docker).
[ ] Make sure your code lints (nf-core lint .).
[ ] Documentation in docs is updated
[ ] CHANGELOG.md is updated
[ ] README.md is updated

Learn more about contributing: CONTRIBUTING.md

Im hoping the tests pass now that I changed the code to not download the human Kraken2 database...

PS: I have commented out the PlasmidID processes because they are failing and the error was too cryptic for me to resolve at this time of night! Definitely :bed: now. See you in the morning, bright and early :sun_behind_small_cloud:


DABO - BUG for the number of jobs displayed

ENVIROMENT: production
URL: https://scrapers.peviitor.ro/src/dabodoner/index.html
Browser: Chrome
Device: laptop
OS: Windows 10
STEPS TO REPRODUCE:
Open URL in browser
Type the name of the company in the search bar
Click on the button "Cauta"
Click on the link below the company logo
Open the careers section
Open the original website of the company in the jobs available section
Verify if the number of the jobs on https://scrapers.peviitor.ro/src/dabodoner/index.html is the same like the number of the jobs available on the company website.
EXPECTED RESULTS:
The number of the jobs posted on the https://scrapers.peviitor.ro/src/dabodoner/index.html is the same with the number of the jobs on the company website.
ACTUAL RESULTS:
The jobs number (2 job offers) on https://scrapers.peviitor.ro/src/dabodoner/index.html is less than the number of jobs (5 offers) on the company website.

retested..Pass


HIVE-25139: Filter out null table properties in HiveIcebergMetaHook

What changes were proposed in this pull request?

Why are the changes needed?

Does this PR introduce any user-facing change?

How was this patch tested?

@marton-bod @pvary @szlta Could you please review this PR? Thanks


SHOW_ALL gives incorrect dimension meaning scrolling is needed

A bug in the API

I have been trying to build a full screen mobile game using the full screen mobile template. My game is 600x400 and I have been finding that the game is not being scaled correctly meaning that the bottom of the game is cut off and needs to be scrolled to. My assumption was that SHOW_ALL should show all of the app without the need for scrolling as long as the window is within scale.setMinMax bounds.
I have made an example using the template http://utterlysuperb.com/dev/js/fsm/
I think I may have tracked down the issue, or at least I've found a hack to workaround it. I think the issue is with Element.getBoundingClientRect() which is used in the ScaleManager's getParentBounds function to set the bounds which is then used in setShowAll. This returns the dimensions of the element, not the viewable area, meaning the canvas isn't getting scaled.
All I did was to override ScaleManager.getParentBounds so that it ignores getParentBounds and just uses dom.visualBounds and this seems to fix the problem for me. I have made an example with this override http://utterlysuperb.com/dev/js/fsm2/
I don't know if this will mess up other display modes or if I have missed something obvious but I hope this makes sense.

You might want to add
this.scale.windowConstraints.bottom = 'visual';

when you set up your scale manager, this will make sure that the game won't appear past the bottom, so you don't have t scroll
Doc link

Thanks, that's obviously miles better than my just hacking out part of the code.
I only skimmed it and didn't notice that '' was considered a valid value. I assumed it would default to visual. I still think that it might be worth reviewing the template, and maybe highlighting that this option is needed.

I've been banging my head against the desk for days about this issue. Thanks!

Thank you for taking the time to open this issue. However, official support for Phaser 2 has now ended as we focus on preparing Phaser 3 for beta release. In a bid to keep the project tidy, and avoid confusion, we are closing all v2 related issues.
This does not mean your issue won't be looked-at. In November 2016 the Phaser CE (Community Edition) project began. The aim of Phaser CE was to allow the community to continue v2 development. Since then it has gained significant traction, with many updates and releases.
If you are still interested in having your issue investigated we strongly recommend testing the latest Phaser CE release. And only if the problem persists, opening an issue on the Phaser CE repo.


Add the article 'parts' subdivision, as marked on the TODO list

This PR solves the following problem which is cited on the TODO list

Many WikiHow articles also contain "Parts" which break down further into sub-steps. Write a function to parse these additional divisions.

Now the Step object as a field 'part' which keeps the name of the "parent topic" of that object
Example:
Let's say we have an article on this format
Part 1
Step1=Do A
Step2=Do B
Part 2
Step3=Do C
Step4=Do D
Then we can use the package normally, but when accessing 'step1' we can check where it lives using step1.part

thanks for sending a PR!
at first this looks good, I will only be able to test later but if everything checks out i will get it merged and make a new release

@JarbasAl  I just found some minor bugs in it.
I'll make another PR in a couple of days.
Closing this one.
Thanks!

@JarbasAl I'm working in some other tweaks.
Hopefully I can PR them later.
Thanks!


assign parents

This should have always been there, right? Why wasn’t it?
I know retain cycles are something to worry about, but I’m sure the affected objects have a dozen references to them in various places anyway.
The first commit is the main thing, but I fixed some other minor things while investigating. My gut tells me all that left-arrow code needs to be refactored, but I’m not going any deeper for the moment.

I know retain cycles are something to worry about

Wait, this stores the identifier and not a reference to the object (probably to avoid that very thing), so that’s not even a concern.

OK @tiennou, that should be better. I also added alt children since all of our children deserve love. 😃

I'd personally be tempted to rewrite both as
if (!children) {
  // remove key
  return;
}
// fix the children parents

But I'm also wondering, isn't the parent/child thing also part of QSObjectProvider ? Just wondering though...

And I think the if (/* ptr in dict */ != /* new ptr */) only made sense in a pre-ARC world, but that ought to be general housekeeping stuff.

What happens if I:
I'm assuming if I type Xcode then → and get "Quicksilver.xcodeproj"  then the parent of "Quicksilver.xcodeproj" will be set as Xcode.
If I then search my catalog for "Quicksilver.xcodeproj" and then ← will I get Xcode or the folder containing that file? I should get the folder right?

Yes, I believe if you start a new search, find a file and ← you should see the containing folder, not an app based on recent files or default open with (this isn't iOS :).
If you navigate to the file from an app then ← should take you back the way you came.

will I get Xcode or the folder containing that file?

You should get the folder. The handler’s parentOfObject: is consulted first, if it’s defined, which it is for files. So parentID shouldn’t matter in that case.

What @hmelman described is how it works with these changes (and how it seems to be working anyway). Things that didn’t work before this:

→ into a contact, then ←
→ into a file tag, then ←
→ into an artist, then ←

OK, but my concern is still valid (perhaps not for file objects, because they're a weird edge case that have a parentOfObject: defined.
Do this (I'm sure there are other ways of reproducing:

Install 1Password & the 1Pwd plugin
Enable the '1Pwd Logins' catalog entry in Prefs > Catalog > Plugins
Search for '1Password.app' in the first pane and press →
At this point, your code will be setting parentID on all these objects
Dismiss the interface
Search directly for a 1Password login (e.g. search for 'github' to find your 1Pwd GitHub login)
Press ←
you'll notice that 1Password is selected, since that's the 'parent' of the object. In reality, there is no parent for this object this time

Also, one other thing for your 3 cases:
If you → into a contact/filetag/artist then ← straight out, your search 'scope' has been lost (e.g. the search string is reset). I don't think this is an easy one to fix, and probably not a big deal, but...
Another easy way to see what I mean:

Search for 1Password.app (type the whole string). The results array will likely show just 1 or 2 results.
Right arrow into 1Pwd.app then left arrow back out
The results array will show your applications folder, with the 'scope' (previous search array/search string) being lost

you'll notice that 1Password is selected, since that's the 'parent' of the object. In reality, there is no parent for this object this time

There wasn’t before. There is now. 😃 I see what you’re saying, but isn’t that better than nothing? It’s true that this is inconsistent, since if you searched for a Login item immediately after a relaunch, the parent would be missing. But the solution to that is probably to define parentOfObject: in the 1Password plug-in (and many others).

The results array will show your applications folder, with the 'scope' (previous search array/search string) being lost

I’m not really sure what should happen, but going through it a couple of times, the current behavior seems to match my expectations. Two other things I would say about that:

I didn’t change the left-arrow behavior (in browse) at all, so this isn’t new.
As I said in the opening comment, “My gut tells me all that left-arrow code needs to be refactored, but I’m not going any deeper for the moment.”

Are you saying I need to go deeper?

This was in the 1.5.0 dev preview and no problems have been reported. I’m going to merge.
I believe any outstanding weirdness (which I haven’t seen in months of actual use) can be fixed by implementing parentOfObject: more frequently/consistently.


Pretraining Support for unsloth

This draft is for pretraining by setting up a model with random weights based on a custom configuration.
please keep in mind for now its only for Llama I have not done any optimization no proper  error checking  and no triton kernels for now  , because I'm not sure if you guys will want this if you do I will add the rest
for example you can try running this colab notebook for an example
colab

I see so you want it to be pre-training and full finetuning both at the same time ,that sounds awesome
should I close this draft then ?


Bug Report - AMM-Arbitrage Strategy

Describe the bug
The strategy is no longer available when I run the create command. As per the command from this page
https://hummingbot.org/gateway/running-dex-bots/#strategy-configs
Steps to reproduce

Enter hummingbot
connect a DEX and CEX
'create --script-config'
the AMM

Arbitrage strategy does not come up any more.

Release version
2.0.1
Type of installation
Docker
Attach required files
No response

Oh wow sorry that was really dumb of me, for some reason I thought I could select the strategy at the same time I wrote the create command.
Thanks again David!


Changed the label gateway agile pathway

Fixes

Fixes #344 by @krysal
Description

Modified the label action to agile pathway.

Testing Instructions

Checklist

[x] My pull request has a descriptive title (not a vague title like Update index.md).
[x] My pull request targets the default branch of the repository (main) or a parent feature branch.
[x] My commit messages follow best practices.
[x] My code follows the established code style of the repository.
[ ] I added or updated tests for the changes I made (if applicable).
[ ] I added or updated documentation (if applicable).
[ ] I tried running the project locally and verified that there are no visible errors.

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

The required changes have been updated please check and let me know if there is any further changes required.

@dhruvkb Please check whether the suggested change should be done or not. Thanks!

@sarayourfriend Please merge the PR.

Thanks for the help, @sharmadhiraj86!


refactor: remove subprovider concept

Fixes #98 and #108

I think that now after adding the type matching logic we don't need to treat subproviders separately anymore.
That would simplify adding the __getitem__ and __contains__ methods. So therefore I'm considering making that refactoring here, what do you think @SimonHeybrock ?


React v18 ReactDOMClient

Changes

Update react dependency to v18, PureScript to 0.15.4 (package-lock.json)
Mark old render functions as deprecated
Add ReactDOMClient
Delete Concurrent

References

https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/react-dom
https://reactjs.org/docs/react-dom.html
https://reactjs.org/docs/react-dom-client.html

Tests
I was thinking about adding tests, but because they're executed with node (which needs faking a browser) we're not winning much here. I did try out the current branch and it seemed to work fine for the good case: https://github.com/andys8/type-signature-com/commit/51ad716cb7afedd88f9129ce33e3cc8ea81e2fc4
Warning
There is a handful of older functions that are still working, but will result in a deprecation warning. I ended up adding a deprecation warning to these in ReactDOM.

Related

Solves https://github.com/lumihq/purescript-react-basic-dom/issues/42
Replaces https://github.com/lumihq/purescript-react-basic-dom/pull/43

Thank you @andys8! Really appreciate this and thanks especially for adding the warnings for the deprecations.


Allow configuring start of the week to either Sunday or Monday

Hi, I love using Grist for time tracking instead of my old spreadsheet. However, there's a slight inconvenience regarding filters and weekdays. When I want to see the hours that I made in the past week, I cannot create a date range filter between "Monday of last week" and "Sunday of last week", because Grist assumes that Sunday is the first day of the week, rather than Monday, like roughly half of the world. It would be nice if this could be configured in Grist somehow, or be picked up from the current locale (or both).
Environment: I'm using the AUR package for the standalone grist-desktop, version 0.2.10.

Hello @mpsijm!
Thanks for the report. Could it be a duplicate of https://github.com/gristlabs/grist-core/issues/443?

Indeed, it looks like it! Thanks for pointing it out, it did not show up when querying for "start of week" :smile:


added version of bridge that includes velocities of individual stars …

Note that the changes to bridge itself are minor. It just needs a use_velocities flag and self.vx,self.vy,self.vz need to be passed in get_gravity_at_point. I don't think they are needed in other functions. So it may not be necessary to have a separate file, and bridgev could be folded into bridge.

I would definitely fold it into bridge.py, and make it optional to pass the velocities. It would also make the changes easier to spot for us :).
I think the use_velocities flag should be passed when adding a "kicker" system, individually for each of these. Not all system may support get_gravity_at_point with velocities.

great! I would also put the changes in new (derived) classes in this case (and a more descriptive name than bridgev) in bridge.py. Can you also add an example of its use and some tests wouldalso  be nice?
also next time: i suggest you make a feature branch in your fork and a PR against this (this makes it easier for yourself to work on multiple things at the same time;-)...)

I would definitely fold it into bridge.py, and make it optional to pass the velocities. It would also make the changes easier to spot for us :).
I think the use_velocities flag should be passed when adding a "kicker" system, individually for each of these. Not all system may support get_gravity_at_point with velocities.

Where is the check to see if the system is a "kicker" or not? Its not entirely clear to me where this is in bridge.

great! I would also put the changes in new (derived) classes in this case (and a more descriptive name than bridgev) in bridge.py. Can you also add an example of its use and some tests wouldalso be nice?
also next time: i suggest you make a feature branch in your fork and a PR against this (this makes it easier for yourself to work on multiple things at the same time;-)...)

Thanks for the suggestion. I am still a bit of a git rookie.
I was also hoping you can elaborate on your initial suggestion to put the changes in new (derived)  classes. Are you saying make a class Bridgev (with better name) as opposed to adding the use_velocities option to class Bridge? Similarly, add a class GravityCodeInFieldv instead of adding to GravityCodeInField?

ok, I checked more carefully now: you should indeed make a new:
class BridgeWithVelocityDependendForces(Bridge):
..etc

(or some other descriptive name)..the option use_velocity still has to be present because as it is now you can enable these on a per system basis.
eventually this could be folded back in the Bridge, but I think it is nice to have a new class for now since that makes it clearer what the differences are.
already mentioned this, but tests and a way to validate would also be nice;-)

@ipelupessy should we perhaps just move to get_acceleration_at_point altogether, leaving get_gravity_at_point as an alias for this in case it is different?

Reminder to self that this is close to being mergeable. Just needs a name change for some functions.

keep open for now

keep


Forefront Endpoint Protection 2010 has stopped supporting

Hi team,
I'm moving this from here: https://github.com/MicrosoftDocs/SCCMDocs.zh-cn/issues/5
The user is making a suggestion on the original documentation.
The comment below was Machine translated
@TANSHUAI1993 commented 31 minutes ago — with docs.microsoft.com
Forefront Endpoint Protection 2010 has stopped supporting and is no longer in the WSUS catalog. Whether the document should replace Forefront Endpoint Protection 2010 with System Center Endpoint Protection.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 2a20a2b3-4bee-2b91-5f23-b6e6fcb23f6e
Version Independent ID: e38ad0a6-cff2-f098-ec97-6fda24d681d1
Content: Endpoint Protection malware definitions - Configuration Manager
Content Source: sccm/protect/deploy-use/endpoint-definitions-configmgr.md
Product: configuration-manager
Technology: configmgr-protect
GitHub Login: @mestew
Microsoft Alias: mstewart

Thank you @TANSHUAI1993 for the feedback. Yes, we need to remove references to Forefront from our documentation.

I made changes to this article, thus the issue closed.


Set string.Empty as default value for SenderClientId

As me konw, when the property SenderClientId  of InjectedMqttApplicationMessage type is null, MqttServer. InjectApplicationMessage (InjectedMqttApplicationMessage) will throws an ArgumentNullException. Unfortunately,  MqttServerExtensions.cs provide extension methods without the SenderClientId parameter, it allway throw ArgumentNullException.
public static Task InjectApplicationMessage(
    this MqttServer server,
    string topic,
    string payload = null,
    MqttQualityOfServiceLevel qualityOfServiceLevel = MqttQualityOfServiceLevel.AtMostOnce,
    bool retain = false)

So we might as well give the SenderClientId  property to set the default value of string.Empty

Thank you for your contribution. Good work 👍


Use JsonUtils.fromJsonParser to allow configurability inside of RDF4J

It would be ideal to be calling into JSONLD-Java using JsonUtils.fromJsonParser rather than JsonUtils.fromInputStream, to allow the standard RDF4J configuration options to be used to setup the JsonParser, rather than relying on the default options provided by JSONLD-Java.
https://github.com/jsonld-java/jsonld-java/blob/master/core/src/main/java/com/github/jsonldjava/utils/JsonUtils.java#L189
Related to this issue: https://github.com/jsonld-java/jsonld-java/issues/237

I extended the scope of this issue to also include the other two Jackson based RIO parsers, RDF/JSON and SPARQL/JSON, based in the same way on the new JsonParserSettings


Change translation of "name" to nom in FR locale

Build also fails locally for me on master branch, can you confirm this?

Hi @LaurensN, thanks for the PR, will check what is wrong with the CI pipeline

Hi @LaurensN  sorry for my late feedback, please refresh this PR with the latest master, pipeline errors has been fixed. Will then merge it

Hi @damoiser, done.


feat: contribution guideline updates

Describe the changes you have made in this PR -
New contributions guidelines
Contributed by: @Kartikay304 @Palaksharma23 @Prerna-0202 @pulkit-30 @vedant-jain03
Lead by: @tachyons @Shivansh2407 @ayan-biswas0412
Note: Please check Allow edits from maintainers. if you would like us to assist in the PR.

Coverage remained the same at 81.774% when pulling 0087e5bb9c931fa1fe4c635a23b5dbcefe7cfff5 on vedant-jain03:contribution_guidelines into 29f98c87dd976f9106968ec4277131127f5b9fe0 on CircuitVerse:master.

We can also add labels for a duplicate to identify the duplicate issues and question for questions (some ask questions about features) and priority to differentiate issues on the basis of their priorities as some issues need to be fixed immediately (Priority: high) and some are not (Priority: low).
WDYT @vedant-jain03 @ayan-biswas0412

I think priority will be a good one

I think priority will be a good one

I was thinking of one more, ... some issues are just opened and they have less information about the issue and need more information to reproduce and check the issue. We can have a label to differentiate between these issues.

nice work @vedant-jain03 🚀😃
like @ayan-biswas0412 mentioned, I was also thinking we should insert the label link in the label name.

I think priority will be a good one

I was thinking of one more, ... some issues are just opened and they have less information about the issue and need more information to reproduce and check the issue. We can have a label to differentiate between these issues.

fo that comment section in the issue is enough I think, we should not make a lot of micro issues which will lead to over maintenance at near future

Just a small suggestion. Let me know what you all think about this.
Let's use the word core team member as less as possible. We don't want to people to get intimidated by any power difference. Let's just use a community member for places like
- A core-team member will review your PR
+ A community member will review your PR

Let me know your thoughts on this

Can you replace ... community member by ... a community member, excuse me for being a nitpick sweat_smile
Also just address the Language Check github action comments. Then we're good to merge.

@gr455  I guess that what professionalism is meant to be 💯
I have updated some points you requested/


Deep freeze flat config in defineFlatConfig

Flat configs should be deep frozen so they can't be mutated. For example:
https://github.com/eslint/eslint/blob/4391b71e62b15e54b0493f0dce1ea053ebbc0689/packages/js/src/configs/eslint-recommended.js#L12
Because the config is now flat and config extending happens in user-land, users may try to extend a config by mutating the actual object. Allowing mutation will cause unexpected behavior in complex configurations where multiple config/plugins depend on a shared config.
I think defineFlatConfig is a good place to freeze the config.

I'm not sure if this should be done by eslint-define-config
You can easily do this by yourself via wrapping the defineFlatConfig call with Object.freeze

Object.freeze would need to be applied recursively. And in the recursion, you also have to handle cyclic relationships.
But my motivation is not actually about reducing code. While the convenience of automatic freezing would be appreciated, I see it more as a holistic approach—sealing the config is a finalizing step in the process of creating it.
The benefits extend beyond to safeguarding the config and, by extension, the end-user. Preventing the possibility of config mutation is a proactive measure against unexpected behaviors.
Considering that many config authors may overlook this step, I think this could be a great place to provide the safeguard.


Numbers should be centered in the coins

hyy i can do this .

Yes @chhatrapalsinhzala007, all yours

Any progress on this @chhatrapalsinhzala007?

Not needed now

Not needed now


Alpine 3.4.1

Alpine 3.4.1 is out. Just wondering if you can update and release new gliderlabs and alpine images for it.
Also, I'm curious if you guys could support semantic versioning in releases, somewhat similar to what docker images like golang or ubuntu are doing.
ie:
alpine:3  (would be 3.4.1 under the hood right now)
alpine:3.4  (would be 3.4.1 under the hood right now)
alpine:3.4.0
alpine:3.4.1
alpine:3.3
alpine:3.3.3
etc

There is nothing to update in the image with Alpine 3.4.1 release. See related #129 for more details.

Is there any reason that https://hub.docker.com/r/library/alpine/tags/ currently shows "latest" as having been updated 10 days ago, and "3.4" updated 2 months ago, when the info page ( https://hub.docker.com/r/library/alpine/ ) shows that they supposedly point to the same image?
Just saying, this is pretty confusing to end users.

"edge" is also further out of date than "latest", even though edge is supposed to be more bleeding edge than 3.4, which is what latest points to.
I also there were 2 rebuilds triggered recently to fix a security issue and an issue with busybox stuff, but neither made it into 3.4 somehow.

We've pushed the most recent images recently.

hey guys the issues is closed however I don't see the latest images on docker hub. Any directions?


ImportError: cannot import name 'LocallyConnected2D' from 'tensorflow.keras.layers'

Got this error while building with below requirements
fastapi==0.109.0
uvicorn==0.27.0
Pillow==10.0.1
python-multipart==0.0.6
deepface==0.0.83
2024-03-10 15:13:34   File "/app/app.py", line 2, in <module>
2024-03-10 15:13:34     from deepface import DeepFace
2024-03-10 15:13:34   File "/usr/local/lib/python3.10/site-packages/deepface/DeepFace.py", line 15, in <module>
2024-03-10 15:13:34     from deepface.modules import (
2024-03-10 15:13:34   File "/usr/local/lib/python3.10/site-packages/deepface/modules/modeling.py", line 5, in <module>
2024-03-10 15:13:34     from deepface.basemodels import VGGFace, OpenFace, FbDeepFace, DeepID, ArcFace, SFace, Dlib, Facenet
2024-03-10 15:13:34   File "/usr/local/lib/python3.10/site-packages/deepface/basemodels/FbDeepFace.py", line 29, in <module>
2024-03-10 15:13:34     from tensorflow.keras.layers import (
2024-03-10 15:13:34 ImportError: cannot import name 'LocallyConnected2D' from 'tensorflow.keras.layers' (/usr/local/lib/python3.10/site-packages/keras/_tf_keras/keras/layers/__init__.py)

Already posted here

TLDR; sorted in v0.0.86


fix "later" by "earlier"

I think it should be written "earlier", or nothing at all, since the chapter about Type Inference is the one just before this chapter

Yeah, great point, both the original and these changes might just be inaccurate as this doc lives in the reference section and not in the handbook - I'll take this PR (so you can get the commits), and I'll run over this doc today to make that disconnect more explicit - thanks!


releases: add release notes for v0.8.0

One minor note. Maybe we should try to merge this. I make another PR next week to update the date or anything else we find.
@confidential-containers/confidential-containers-maintainers

Or we can close this one and take the changes here for the new PR to reduce clutter.

One minor note. Maybe we should try to merge this. I make another PR next week to update the date or anything else we find.
@confidential-containers/confidential-containers-maintainers

Or we can close this one and take the changes here for the new PR to reduce clutter.

I'd prefer that we either merge this one and apply any last minute changes next week or keep it open until it is the final draft.
I would not recommend closing this and opening a new one.

@surajssd @fitzthum I'm talking with @stevenhorsman about the best way to flush peer-pods' news on CoCo's RN. So could you keep this open a few days more?

@wainersm yeah, I will probably take over this PR shortly and then we can merge it as the very last step.

Ok, I have commandeered this PR (thanks to @surajssd for getting it started). @dcmiddle PTAL.
@wainersm and @stevenhorsman lmk if there is anything to add for peer pods.
I am thinking we should reworking the template for release notes a little bit for future releases, particularly the part about platform support. Currently it doesn't cover peer pods at all. We should highlight that we have cool stuff working with different CSPs.

@wainersm and @stevenhorsman lmk if there is anything to add for peer pods.

@ChengyuZhu6 had valid feedback that is not included either:

Upstream containerd now shipped in this release,

so instead of this, we could be more verbose about the image pulling inside the guest using upstream containerd and nydys-snapshotter.

Ok, I have commandeered this PR (thanks to @surajssd for getting it started). @dcmiddle PTAL.
@wainersm and @stevenhorsman lmk if there is anything to add for peer pods.

@fitzthum looking at https://github.com/confidential-containers/cloud-api-adaptor/releases/tag/v0.8.0-alpha.1 I would list:
* Added support for pull image via remote-snapshotter (nydus-snapshotter implementation)

* Improved peerpod-ctrl:

  * to check and clean old PeerPod objects
  * added libvirt ssh authentication support
  * Added support for ibmcloud

* Add CDH and ASR support

* Handle container registry authentication via userdata

* Added AMD SEV as well as IBM s390x support for the Libvirt provider

* Enabled public IP usage for pod VM on AWS and PowerVS providers

* webhook: added IBM ppc64le platform support

* Support adding custom tags to podvm instances

* Switched to launching CVM by default on AWS and Azure providers

* Added rollingUpdate strategy in cloud-api-adaptor daemonset

@stevenhorsman @bpradipt @surajssd ^ is this list accurate and complete?

On the peer pods community meeting of this morning we came up with an updated list, @fitzthum :

Enabled image pulling via remote-snapshotter (nydus-snapshotter implementation) as an experimental feature. The io.containerd.cri.runtime-handler: kata-remote annotation should be set on the pod configuration to enable that feature.
Improved peerpod-ctrl:

to check and clean old PeerPod objects
added libvirt ssh authentication support
Added support for ibmcloud

Added runtime secure key release for image decryption via remote attestation on AKS
Handle container registry authentication via userdata
Added AMD SEV as well as IBM s390x support for the Libvirt provider
Enabled public IP usage for pod VM on AWS and PowerVS providers
webhook: added IBM ppc64le platform support
Support adding custom tags to podvm instances
Switched to launching CVM by default on AWS and Azure providers
Added rollingUpdate strategy in cloud-api-adaptor daemonset
Disabled secureboot by default

The following applies to local hypervisor too so you might want to put in a separated section:

imagePullSecrets is now required to pull images from authenticated registry

@stevenhorsman @katexochen @mkulke ^ let me know if did not capture the list correctly :)

@wainersm

Added runtime secure key release for image decryption via remote attestation on AKS

Support for secure key release at runtime and image decryption via remote attestation on AKS.

I added two more commits to fixup some other things in the docs, such as adding the runtime handler annotation to all the yaml examples.


fix: proper definition for useMeasure

Description
Type of [noop, defaultState] is :
Array<(
  | Pick<DOMRectReadOnly, "x" | "y" | "top" | "left" | "right" | "bottom" | "height" | "width">
  | (() => void)
)>

This fix it.

Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as before)

Checklist

[x] Read the Contributing Guide
[x] Perform a code self-review
[ ] Comment the code, particularly in hard-to-understand areas
[ ] Add documentation
[ ] Add hook's story at Storybook
[x] Cover changes with tests
[x] Ensure the test suite passes (yarn test)
[x] Provide 100% tests coverage
[x] Make sure code lints (yarn lint). Fix it with yarn lint:fix in case of failure.
[x] Make sure types are fine (yarn lint:types).

great work @meowtec
I hadn't seen this PR and created another similar one: https://github.com/streamich/react-use/pull/1782.
Out of curiosity: Is there any reason you chose as typeof useMeasure instead of simply as const? I opted for as const as it is simpler and easier to apply as a pattern to other hooks.

@mdugue as typeof solution is better because it strictly requires alternative implemnentaqtion to be aligned with original function.
I'll merge this one in favor of yours.

Fix: #1781

Close: #1782

I see. Makes sense

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Fix goroutine leak when restarting Caddy

What does this change do, exactly?
Each time the Caddyfile reloads and Caddy is restarted, caddytls.NewConfig starts a goroutine for cleaning the certificate storage. This goroutine ranges over a time.Ticker channel; although Stop is called on this ticker, Stop does not close the underlying channel so the goroutine never exits.
This change adds an additional channel that is listened to in the certificate cleaning goroutine so it can exit on restarts.
Please link to the relevant issues.
Fixes #2642
Which documentation changes (if any) need to be made because of this PR?
None
Checklist

[ ] I have written tests and verified that they fail without my change
[x] I have squashed any insignificant commits
[x] This change has comments explaining package types, values, functions, and non-obvious lines of code
[x] I am willing to help maintain this change if there are issues with it later

Open Discussion/Questions

I did not write any new tests for this code because it is contained within a function caddytls.NewConfig which is currently untested. I can carve out some time to test the entire function, though it feels out of scope for this PR.
I observed that calling certmagic.CleanStorage is delayed by 12 hours. If a restart always occurs before 12 hours, this method is never called. Is this concerning? Is the certificate storage cleaned on restart or by some other means? (I don't believe that I am introducing this problem as calling Stop would have the same effect.)

 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.Jared Ririe 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.

I did not write any new tests for this code because it is contained within a function caddytls.NewConfig which is currently untested. I can carve out some time to test the entire function, though it feels out of scope for this PR.

Honestly, Caddy 2 is coming quickly enough that I wouldn't worry about it much.

I observed that calling certmagic.CleanStorage is delayed by 12 hours. If a restart always occurs before 12 hours, this method is never called. Is this concerning? Is the certificate storage cleaned on restart or by some other means? (I don't believe that I am introducing this problem as calling Stop would have the same effect.)

Eh, it's not too common that configs are reloaded that often; it just means that some stale OCSP staples might stick around in storage longer than necessary, but it's unlikely that anything detrimental would happen.
Thanks for the PR!


chore: upgrade R and RStudio versions

testing

@gavin-k-lee I think all the pieces (i.e. dependent libraries) that needed new releases for this to work are now done. I did some tests in a different branch. Are you ok for me to transfer these changes here so that we can have images with newer R and Rstudio versions?

Some related issues we can close with this: #154 and #160.

@olevski yes please! transfer away. thank you!!

Also this is a good guide on the insanity that is R session environment variables. If I change only the Renviron file the path is not updated. I could only get it to work when I change Renviron.site - and that is what is actually recommended.
See: https://rviews.rstudio.com/2017/04/19/r-for-enterprise-understanding-r-s-startup/

@olevski yes the RStudio environment setup is mind-boggling. It basically ignores any reasonable convention that you might expect 😭 🤦

Though I'm a bit confused why adding the paths to Renviron.site is needed - it used to work as is

btw I think the bioc builds might fail since the R and RBioc versions aren't corresponding exactly.
 They should all pass now.

Ok this is ready to go now.
Here is a test project with bioconductor 13: https://dev.renku.ch/projects/tasko.olevski/test-image-upgrade-r-1

Here is a project with just R 4.1.0: https://dev.renku.ch/projects/tasko.olevski/test-r-project-1

Both of the test projects work!

nice! I just tried both projects and when opening in an external tab it worked great and I tested the plotting (which was the most prominent problem before). In the iframe RStudio took a long while to load and I had to fresh the session page a couple of times - not sure if you experience that all? Maybe it is a resource issue?

@gavin-k-lee I have seen the loading issues in the iframe you mention on other versions (in production) too. I am pretty sure it is related to resource usage. I never saw it in test but then I made sure to request 1cpu with the sessions - not sure if that helped really. I think the cpu should not be limited in k8s.
Either way I think this is a problem that shows up sometimes and is not a result of the new images.

On another note...
I def lost some sanity just trying to get these images to build btw. I did notice that building the dockerfiles worked differently on my mac locally and in github CI. But then after I switched to my personal latptop (which runs linux) I could finally get the same outcomes I see in the CI workflows locally and eventually fix them. Just a PSA if some else is having such weird issues.

yeah it seems like you really need to build them with linux to have them equivalent, which is annoying.
@SwissDataScienceCenter/renku-ui-maintainers would we be able to get some help to understand what's going on with the iframes? I tried the highest cpu and ram on dev and the iframe didn't load (but the new tab worked as expected)

I think we can also retire some of the 4.0.X images and bioc images. We could go with:
R 4.1.0, 4.1.1, 4.1.2
Bioc 3.13, 3.14.
R 4.0.5 came out in March 2021 and Bioc 3.12 in October 2020.
Thoughts?

I just tried both the test-image-upgrade and the test-r-project above, and I did not see anything unusual in the iframe experience. Both projects took 40-45s to start, but I had the spinner/bouncer and then they transitioned seamlessly to RStudio once the pods were up. It seems that the problem is intermittent.
If you could note the time (UTC) when you next have issues, we can see if there is anything in the logs that sheds light on what is going on.

@rokroskar I tested the latest version of the R images with the devel images for R and bioconductor. Things work. So this is ready to go!
If you or anyone else is interested here are the projects:

https://dev.renku.ch/projects/tasko.olevski/test-image-upgrade-r-1 (plain R)
https://dev.renku.ch/projects/tasko.olevski/test-r-project-1 (bioconductor)


[Bug]-[1056]:Console shows error for widget binding when JS code is turned off

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
Binding path not found error is displayed when Radio Group widget's options are defined by JS and then this binding is deleted by turning off JS option on the field, then a console error is displayed for binding path.

Steps To Reproduce

On a radio group widget, insert a JS code for Options field of Property Pane
Toggle the JS button so the code is cleared. Now observe the error on browser console as seen in the screenshot

Environment
Release
Version
Cloud

Stats

Stat
Values

Reach
132

Effort (months)
0.25

We can relook at the effort for this. Dropping a rough estimate for now.

@vuiets @ramsaptami This should not be an issue today. #10803 or #12253 should have resolved this.
I cannot replicate this.

Tested this on latest release and this isn't a bug anymore. Hence closing this issue.