bug: memory leaked by change_detection

Did you check docs and existing issues?

[X] I have read all the lazy.nvim docs
[X] I have searched the existing issues of lazy.nvim
[X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)
v0.10.0-dev-915+g898ef1835
Operating system/version
Arch Linux in WSL2
Describe the bug
The memory will be slowly leaked by the change_detection function if enabled due to the periodical execution of the following lines.
https://github.com/folke/lazy.nvim/blob/2a9354c7d2368d78cbd5575a51a2af5bd8a6ad01/lua/lazy/manage/reloader.lua#L61-L63
Steps To Reproduce

Use the minimal repro config at the end of the issue.
Shorten the checking interval to make the memory leak more observable:

diff --git a/lua/lazy/manage/reloader.lua b/lua/lazy/manage/reloader.lua
index 6938231..f7db577 100644
--- a/lua/lazy/manage/reloader.lua
+++ b/lua/lazy/manage/reloader.lua
@@ -18,7 +18,7 @@ function M.enable()
   if #Config.spec.modules > 0 then
     M.timer = assert(vim.loop.new_timer())
     M.check(true)
-    M.timer:start(2000, 2000, M.check)
+    M.timer:start(2000, 50, M.check)
   end
 end

Launch nvim, then the memory occupied by nvim will slowly go up at a constant speed even without any operations. On my machine, this is about 20KB/s.

Expected Behavior
The memory usage stays steady when change_detection is enabled.
Repro
-- lua/plugins.lua
return {}

-- init.lua
local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
	vim.fn.system({
		"git",
		"clone",
		"--filter=blob:none",
		"https://github.com/folke/lazy.nvim.git",
		"--branch=stable", -- latest stable release
		lazypath,
	})
end
vim.opt.rtp:prepend(lazypath)
require("lazy").setup({ import = "plugins" }, {
	change_detection = {
		enabled = true,
		notify = true,
	}
})

not idea. There's nothing special going on in that code. Might be something in core. Who knows.
Not worth further investigating. Closing

i often keep several vim windows open for days/weeks at a time, and this eventually caused my computer to grind to a halt

Exactly the same here.  Over the past year I just fell into a routine where I would wait for my system to start thrashing swap, do a killall -9 nvim , and rinse/repeat after a few days.
Disabling change detection has entirely fixed the problem.  Thanks!
The real puzzle for me is why this isn't getting more traction.  Why aren't people running into it left and right, considering it's enabled by default?

For what it's worth, I was able to reproduce this on stable by changing the update interval from 2000ms to 20ms.
On nightly, there's nothing leaking.
So this is likely fixed in core, or that PR linked by @yioneko is now included in the libuv build.

So this is likely fixed in core, or that PR linked by @yioneko is now included in the libuv build.

Great to hear!
I am somewhat able to confirm on my end, except the nightly appimage segfaults on me after a few seconds for 90% of the files I open.  For the 10% where it doesn't, as you say, the leak is no longer reproducible.


[Windows, 3.0 Preview 3.1] SkiaSharp throws exception using .NET MAUI 9.0 Preview 6 in Microsoft Store certification

Description
We are trying to get our game to Microsoft Store. It works fine on all our Windows computers (including servers), but during the certification process in Microsoft Store, it throws the following exception in SkiaSharp:
System.Runtime.InteropServices.COMException: Class not registered (0x80040154 (REGDB_E_CLASSNOTREG))
System.TypeInitializationException: The type initializer for 'SkiaSharp.Views.WinUI.Native.PropertySetExtensions' threw an exception.
  ?, in IObjectReference PropertySetExtensions.get__objRef_global__SkiaSharp_Views_WinUI_Native_IPropertySetExtensionsStatics()
  ?, in void PropertySetExtensions.AddSingle(PropertySet propertySet, string key, float value)
  ?, in void GlesContext.CreateSurface(SwapChainPanel panel, Size? renderSurfaceSize, float? resolutionScale)
  ?, in void AngleSwapChainPanel.EnsureRenderSurface()
  ?, in void AngleSwapChainPanel.OnSizeChanged(object sender, SizeChangedEventArgs e)

This seems to be related to AngleSwapChainPanel.cs in SkiaSharp.Views.WinUI and GlesContext.cs in SkiaSharp.Views.WinUI\GlesInterop. In the latter, the lines
    if (resolutionScale.HasValue)
    {
         PropertySetExtensions.AddSingle(surfaceCreationProperties, Egl.EGLRenderResolutionScaleProperty, resolutionScale.Value);
    }

seem to fail. What may be causing this in Microsoft Store certification? Does anybody know any workarounds for this?
Code
https://github.com/hyvanmielenpelit/GnollHack
Expected Behavior
Microsoft Store certification does not result in exceptions.
Actual Behavior
Microsoft Store certification throws System.Runtime.InteropServices.COMException: Class not registered (0x80040154 (REGDB_E_CLASSNOTREG))
Version of SkiaSharp
3.x (Alpha)
Last Known Good Version of SkiaSharp
Other (Please indicate in the description)
IDE / Editor
Visual Studio (Windows)
Platform / Operating System
Windows
Platform / Operating System Version
Windows 10.0.22631.3296
Devices
Dell Latitude 5520, during Microsoft Store certification process
Relevant Screenshots
No response
Relevant Log Output
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

This seemed to be now fixed by Microsoft Store adjusting their setup.


Add "Quit" action to allow exit on a Cmd-W or Cmd-Q

Adds a new "Quit" action and binds it to Cmd-W and Cmd-Q on Mac OS in an
attempt to make Alacritty feel more like a "normal" citizen of the
operating system. Alternatives like Ctrl-D are okay, but I usually want
to leave my shells nested within Tmux open even if I exit my terminal.
It's also largely selfish: I've built up muscle memory over the years
that takes my fingers to Cmd-Q first (and I suspect I'm not the only
one).
The implementation for an exit is copied from event.rs which notably
is already tagged with a FIXME. It seems that tty.rs contains a
process_should_exit system to help handle a SIGCHLD, and it's
possible that these two exit implementations should be merged together.
I could probably tackle that as my next project.
As mentioned in #218, Alacritty can't really spawn other windows right
now, so I've tied in Cmd-W as simply another synonym for quitting until
that's implemented.
One other thought: I'm not super convinced on the approach of having all
key bindings configured directly from a Yaml file and without any
defaults. You can see that even here it will be a bit of a problem
because there may be hundreds of Mac users out there who won't get this
key binding until they port it in manually for bootstrap from a fresh
version of the repository's default configuration file.
Fixes #218.

One other thought: I'm not super convinced on the approach of having all
key bindings configured directly from a Yaml file and without any
defaults. You can see that even here it will be a bit of a problem
because there may be hundreds of Mac users out there who won't get this
key binding until they port it in manually for bootstrap from a fresh
version of the repository's default configuration file.

This will become much less of a problem once the project matures. I'm ok with the trade.

It seems that tty.rs contains a
process_should_exit system to help handle a SIGCHLD, and it's
possible that these two exit implementations should be merged together.
I could probably tackle that as my next project.

We can always improve the shutdown handling later. This seems far better than nothing.
Thanks for putting this together!

This will become much less of a problem once the project matures. I'm ok with the trade.

Cool. I guess there's a point where new bindings certainly become much more unusual.

We can always improve the shutdown handling later. This seems far better than nothing.

Thanks! I'll see if I can introduce an incremental improvement there as my next minor patch.


FIX: remove cmake installer after compiling ANTs

Changes proposed in this pull request
The file /cmake-3.11.4-Linux-x86_64.sh is used for compiling ANTs but is left in the container root directory. Removing it saves 33 Mb.

Documentation that should be reviewed

None

Nice catch! Thank, Phil


Plan is created with invalid credentials

Tested with plugin version v0.4.3, Terraform v0.14.11
The provider happily creates a plan with invalid credentials, which if applied (a) fails (b) can delete valid resources from state.
Expected behaviour:

Terraform should refuse to create a plan if the provider is unable to authenticate.
Resources are not deleted from state when the wrong credentials are provided.

To reproduce:
provider "sigsci" {}
resource "sigsci_site" "test" {
  short_name             = "test-tf"
  display_name           = "Test"
  block_duration_seconds = 86400
  agent_anon_mode        = ""
  agent_level            = "block"
}

terraform {
  required_version = ">= 0.13"
  required_providers {
    sigsci = {
      source = "signalsciences/sigsci"
    }
  }
}

Apply the configuration with correct authentication:
sigsci_site.test: Creating...
sigsci_site.test: Creation complete after 2s [id=test-tf]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
$ terraform state list
sigsci_site.test

Set some invalid authentication parameters:
$ cat .envrc
PATH_add ../../../bin
export SIGSCI_EMAIL=foo
export SIGSCI_TOKEN=bar
export SIGSCI_CORP=baz

Plan/apply with incorrect authentication parameters:
$ terraform apply
sigsci_site.test: Refreshing state... [id=test-tf]

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # sigsci_site.test will be created
  + resource "sigsci_site" "test" {
      + agent_level            = "block"
      + block_duration_seconds = 86400
      + block_http_code        = (known after apply)
      + display_name           = "Test"
      + id                     = (known after apply)
      + primary_agent_key      = (known after apply)
      + short_name             = "test-tf"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

sigsci_site.test: Creating...

Error: Unauthorized: You must be logged in to call this API

  on sigsci_sites.tf line 1, in resource "sigsci_site" "test":
   1: resource "sigsci_site" "test" {

State is wiped:
$ terraform state list
$

Hey @elblivion, thanks a lot for this issue report. Still with Terraform v1.0.7 I could not reproduce the issue. It might be related to an issue in and older version of Terraform itself and not to the plugin.
Also .envrc seems to be ignored in the mentioned Terraform version as you see below as I had to enter some of the credentials interactively.

Hi @loxal , weird that we don't get this with other providers. It's your call as to whether to spend time on fixing this, in our case we're not yet ready to go to Terraform 1.0 and it might be the case of other folks too.
Sorry, I should have specified that I was using direnv to manage environment variables, I included that just to illustrate that I was modifying the config.
The error Terraform logs is this:
2021-09-20T08:08:00.612Z [WARN]  plugin.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2021-09-20T08:08:00.613Z [DEBUG] plugin: plugin process exited: path=.terraform/providers/registry.terraform.io/signalsciences/sigsci/0.4.3/linux_amd64/terraform-provider-sigsci_v0.4.3 pid=42
2021-09-20T08:08:00.613Z [DEBUG] plugin: plugin exited

So I guess this was fixed in https://github.com/hashicorp/terraform/pull/26694. Weird that you do not see any error when planning with invalid credentials though, IMHO if a plan is still created this is a problem.

@elblivion sure, I understand your migration concerns as I remember migrating code for one of the pre-1.0 versions.
I think missing direnv was not the issue as wrong credentials can be passed in several ways. The issue was rather the combination of our plugin and a pre-1.0 Terraform version.
I see an authentication issue when doing terraform plan but fixing the credentials subsequently and running terraform apply does not corrupt the state:

I agree that a new plan should not be created once terraform fails an operation. However I am afraid I wouldn't be able to justify a major prio for fixing this issue as you are using an older version and there is a "workaround" available (not using wrong credentials). I know, from a usability point of view it's not perfect.

Sorry for looking at this late, but the solution for this seemed to be pretty easy so I will include it in the next release as I think this is a good idea. Although I couldn't corrupt the state either as @loxal said, the provider is getting confused and behaving incorrectly.

Just chiming in that we have seen strange behavior as well regarding sigsci running a plan when it fails authentication and we are on 1.x. I am not sure if I have seen it recently but I am not sure if that is because auth is being provided properly in our execution environment.


Feature/objective wise none replacement

If one wants to use infinity as the numerical loss representation for None objective values, the direction of the objective matters. This PR introduces backward compatible support for individual none representation values per objective.
An alternative that I decided against due to the lack of generality and transparency to the call context is detecting inf and adding a sign according to the objective direction in the loss vector function.

I somehow got confused about objective directions when what we anyway return is losses only, so there really is no need to specify objective direction dependent None replacement values. Closing accordingly, apologies for the confusion @sfalkner 😇


Document FromType trait

Objective
Prevent future unnecessary mental effort spent figuring out why this trait exists and how to resolve the TODO.
Solution
I happened to notice this trait being used when expanding the #[derive(Reflect)] macro in my own crate to figure out how it worked, and noticed that there was a TODO comment on it because it is only used in the derive macro and thus appeared to be unused.
I figured I should document my findings to prevent someone else from finding them out the hard way in the future :laughing:

Doc is good, but I worry about the code block falling behind when something is changed... Maybe have it not as a doc comment but just a comment? What do you think?

Doc is good, but I worry about the code block falling behind when something is changed... Maybe have it not as a doc comment but just a comment? What do you think?

Yea this worries me a little bit too.
We should either have it actually be able to compile or probably just remove the code snippet entirely.
The comment could be expanded a bit more and cover for the missing code example perhaps?

You're right, especially since Bevy's still going through a lot of API churn it doesn't make sense to include a code example anyway, and I think the revision I just made is easier to read anyway.


[Feature Request] Custom channel name by built-in keyboard.

In the original firmware, uvk5 just only can save channel with the name 'CH-XXX'.
If we want to custom channel name, we have to write channel by PC, which is so inconvenient.
Therefore, it will be convenient if we can custom channel name by built-in keyboard (T9 input method).

Yes that's right, I tried the original QS firmware back in the radio the other day, was somewhat surprised that I had great difficulty using it, just couldn't get the hang of it.

[ ] I did that to show a colleague  the differnce and my head screamed at me.. within seconds was back on custom..felt so much better.

The name on device is a good idea and one that would be useful at somepoint in the distant future...

yes lol.
Anyway, it's there, it's been there from almost the beginning.

yes lol.
Anyway, it's been there from almost the beginning ..

Ok now am confused..
How does it even work??

Press Menu button
Scroll to "CH NAM" (around number 17)
Press the Menu button to enter
Use up/down keys to choose the desired channel
Press the Menu button again to enter edit name mode
Use the up/down keys to cycle through the letters etc
Press the Menu button again to move to the next character position
Repeat steps 5 and/or 6 till you reach the end
Press Menu button to save

Press the Exit button at any time to cancel the edit and return to the main menu.
Sounds a lot but once you done it a few times it will seem easy - hopefully.

I'll put that in the readme.md file.

Yes it only edits the name, so it only works on channels that are already there.

I'm sorry for my carelessness. Thank you for implementing this life change function

No it's fine, don't worry.


1 Channel images not working

I am using timm version 0.5.0, and I plan to train a greyscale image, but the data loader is outputting RGB images.
The model I intend to use works fine
vit_tiny = timm.create_model('vit_tiny_patch16_224', pretrained=True, num_classes=2, drop_rate=0.2, in_chans=1)
vit_tiny.patch_embed.proj
Out: Conv2d(1, 192, kernel_size=(16, 16), stride=(16, 16))

And my loader is as follows:
train_dataset = create_dataset(name="train", root=DATA_DIR, split="train")
train_loader  = create_loader(train_dataset,
                              input_size=(1, 224, 224),
                              batch_size=8,
                              use_prefetcher=False,
                              is_training=True,
                              no_aug=True,
                              auto_augment='aa',
                             num_workers=1,
                         )

However, the output size is as follows
train_loader.dataset[0][0].shape
Out: torch.Size([3, 224, 224])

@etetteh yes, models work fine with arbitrary input channels but the data pipeline components are defaulted to RGB as they've really only been used with color images.
The folder dataset has 'RGB' hardcoded as the PIL conversion, that needs changing to 'L', any normalization mean/std args need to be passed in as single elelement lists and tuples [0.5]. It might work if you make those changes...

Thanks so much for the response. I guess the input size is also hardcoded, which makes it impossible to use, say, vit_tiny_patch16_224 with different input sizes, say, (512, 512).
Is this going to change in the future?

@etetteh unlike majority of convnets, changing the resolution of the vit or mlp mixer model is essentially a different model. The sequence lengths change and with it the embeddings are different.
The vit models support interpolating the embedding to a different size, but loses quite a bit of accuracy, however not a big issue if you are fine-tuning anyways. So you can pass img_size= to the model with an extra arg (that's not in the train script since it only works on some models, to fix that someday), it will interpolate the pretrained weights for you if it can.

@rwightman Thanks a lot. I am finetuning, so that ain't an issue as you said. I passed the 'img_size argument, and everything is fine now. I downloaded the dataset.py and dataset_factory.py scripts and changed the RGB to L. Everything is working fine.
I would suggest the channel's type, RGB OR L, to be passed as arguments in the create_dataset function, instead of the hardcoding

@etetteh yes, I will leave this open until I have a chance to add support to dataset and also will push some better handling into the transforms fn so that it can warn / resolve a mismatch between input size and normalization inputs

Is it means timm cannot deal with greyscale? I am using Resnet50 on the greyscale images, model shows the input_size: (3, 224, 224), and it gives me the training results. The results is wrong?

@rwightman Thanks a lot. I am finetuning, so that ain't an issue as you said. I passed the 'img_size argument, and everything is fine now. I downloaded the dataset.py and dataset_factory.py scripts and changed the RGB to L. Everything is working fine.
I would suggest the channel's type, RGB OR L, to be passed as arguments in the create_dataset function, instead of the hardcoding

Could you share you modification code for grey sclae? Thanks!

long time, but no hard coded needed anymore, passed through to folder, huggingface, webdataset, and tfds dataset readers .. only torchvision datasets aren't easily supported


Refactor module initialization

Changed to use the same stages as extensions.
Makes the initialization more coherent, helping solve problems due to lack of stages.
Makes it easier to port between module and extension.
removed the DRIVER initialization level (no longer needed).

@AndreaCatania Does this fully supersede #50179? It's not quite the same, do you miss anything in this one?

I think I was using DRIVER in actual extensions seeing the OpenXR extension was originally a driver, not that it matters anymore now that it is core :)

This is a good feature!
I think that the only missing thing is to call initialize_modules(MODULE_INITIALIZATION_LEVEL_BEGIN); at the really start of Error Main::setup and initialize_modules(MODULE_INITIALIZATION_LEVEL_DONE); at the really end of Main::setup2
The first one is useful so you can hook the initialization even before the core & platform are initialized, indeed initialize_modules(MODULE_INITIALIZATION_LEVEL_CORE); is called only after the core is fully initialized.
The former is useful so you can do stuff when everything is initialized, and the engine is ready to be used as normal.
Other than that, it looks really nice.

@AndreaCatania There is not much you can do before CORE is initialized so IMO that is a bit pointless. If you want to override some core things like filesystem drivers or other stuff, you can still do it after it is initialized.

@reduz It would be handy in case you want to configure some core functionality during the engine initialization, so you can execute the configurator before the core is started.
Also, since there is no initialization order at the moment, you may override a core functionality making it dependent from another functionality: which should be initialized before.
Add another event should not make things bad anyway, so probably is worth add that to make these two --^ possible.

@AndreaCatania I understand the concern, but for the time being I will not add another level unless there is a specific need for it. Its easy to add if the need arises.

This looks mostly okay for me, few notes:
I'm getting ERROR: Condition "int32_t(p_level) != level" is true. on exit due to leftover extension_deinitialization in unregister_server_types and unregister_editor_types (trying to deinitialize the same level twice), they should likely be removed from register_[servers/editor]_type.cpp, along with the extensionmanager include I guess.
This solves my issue with webrtc (thanks!) so I'm closing #60454 , but the contributor in #60317 requires additional changes (namely register_server_singletons to happen before the last init level.
I think this is because the need to call functions in servers singletons (e.g. XRServer::add_interface/XRServer::set_primary_interface) which right now happens on singletons.
Maybe, having static method support, we could refactor those methods in case, but there might be more cases where you want your extension to interact with server singletons before scene instantiation begins.
Something on the line of (untested):
diff --git a/main/main.cpp b/main/main.cpp
index 5ddce818ca..07daf583d0 100644
--- a/main/main.cpp
+++ b/main/main.cpp
@@ -1947,6 +1947,19 @@ Error Main::setup2(Thread::ID p_main_tid_override) {
 	initialize_modules(MODULE_INITIALIZATION_LEVEL_SCENE);
 	NativeExtensionManager::get_singleton()->initialize_extensions(NativeExtension::INITIALIZATION_LEVEL_SCENE);

+	register_platform_apis();
+
+	MAIN_PRINT("Main: Initialize server singletons.");
+
+	camera_server = CameraServer::create();
+
+	initialize_physics();
+	initialize_navigation_server();
+	register_server_singletons();
+
+	initialize_modules(MODULE_INITIALIZATION_LEVEL_READY);
+	NativeExtensionManager::get_singleton()->initialize_extensions(NativeExtension::INITIALIZATION_LEVEL_READY);
+
 #ifdef TOOLS_ENABLED
 	ClassDB::set_current_api(ClassDB::API_EDITOR);
 	EditorNode::register_editor_types();
@@ -1957,10 +1970,6 @@ Error Main::setup2(Thread::ID p_main_tid_override) {

 #endif

-	MAIN_PRINT("Main: Load Modules");
-
-	register_platform_apis();
-
 	// Theme needs modules to be initialized so that sub-resources can be loaded.
 	initialize_theme();

@@ -1981,14 +1990,6 @@ Error Main::setup2(Thread::ID p_main_tid_override) {
 		}
 	}

-	camera_server = CameraServer::create();
-
-	MAIN_PRINT("Main: Load Physics");
-
-	initialize_physics();
-	initialize_navigation_server();
-	register_server_singletons();
-
 	// This loads global classes, so it must happen before custom loaders and savers are registered
 	ScriptServer::init_languages();

@BastiaanOlij I'm not sure, it's more like a guess, but basically right now extensions cannot call Engine::get_singleton("ServerSingleton") (XRServer, AudioServer, etc) during initialization phase.
I didn't understand which method exactly the OP need to call in #60317 so maybe @kidrigger can clarify on that.

@reduz looks good to me now, just one nit-pick, we should also remove the line:
#include "core/extension/native_extension_manager.h"

in both editor/editor_node.cpp and servers/register_server_types.cpp which is no longer needed.

Alright, done with the changes and suggestions. If no further changes are desired, it should be ready to merge once it passes CI.

Thanks!


Fix CampaignImpact to get activities back on the campaign detail page (yes, really)

This is a TEMPORARY fix to #351. This will get activities to show up again on the campaign detail page but the main problem is that there are some problems with how the CampaignImpact table is defined in the database, but I haven'y fully figured that out yet. This can be merged, but there will be more to come.
Closes #351. The relationship between CampaignImpact and Campaign was messed up causing EF to behave in undesired, weird ways that I don't understand. The SQL schema generated for CampaignImpact made Id not a private key identity, but a foreign key link to Campaign.Id. This meant that the only possible valid CampaignImpact Ids are Campaign IDs and EF was having none of it. Now, I've added Campaign.CampaignImpactId as a foreign key to CampaignImpact.Id and CampaignImpact.Id is now a private key identity.
WARNING This fix is destructive because it has to burn down and re-create the CampaignImpact table to ensure its Id column properly set up as a PKI. I thought I could get this done with incremental migrations, and even though there was a command in the migration that said to set the Id column to be an identity, SQL didn't make it happen. Bankruptcy was the only other way through.
Also fixed a namespace mixup between the CampaignController classes.

Pinging @dpaquette or @MisterJames for review on my use of the nuclear option here.

also pinging @tonysurma to determine impact on current private beta.

Ok with losing campaign impact table contents, not ok with losing campaign table (which isn't what your saying but just stating out loud)

Not sure why the incremental migration didn't work for you @mheggeseth but I guess we are using beta bits.
This should be fine as long as @tonysurma is okay with losing the campaign impact table. If the deployment goes sideways and we lose more than that, we should be able to rollback with a point in time restore in SQL Azure.


Two component files resolving to the same name

Environment

Operating System: Darwin
Node Version:     v23.3.0
Nuxt Version:     3.14.1592
CLI Version:      3.16.0
Nitro Version:    -
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      -
Runtime Modules:  -
Build Modules:    -

Reproduction
Just add any shadcn component to nuxt project
Describe the bug
Numerous warnings in console:
 [nuxt:tailwindcss] ℹ Tailwind Viewer: http://<IP_ADDRESS>:3000/_tailwind/
admin-1                |
admin-1                |  WARN  Two component files resolving to the same name UiAccordion:
admin-1                |
admin-1                |  - /app/apps/admin/components/ui/accordion/index.ts
admin-1                |  - /app/apps/admin/components/ui/accordion/Accordion.vue
admin-1                |
admin-1                |
admin-1                |  WARN  Two component files resolving to the same name UiAlert:
admin-1                |
admin-1                |  - /app/apps/admin/components/ui/alert/index.ts
admin-1                |  - /app/apps/admin/components/ui/alert/Alert.vue
admin-1                |
admin-1                |
admin-1                |  WARN  Two component files resolving to the same name UiAspectRatio:
admin-1                |
admin-1                |  - /app/apps/admin/components/ui/aspect-ratio/index.ts
admin-1                |  - /app/apps/admin/components/ui/aspect-ratio/AspectRatio.vue

Additional context
There are several closed issues about such problems, but it still exists
Logs

my bad, fixed by correcting path in shadcn.componentDir — it was pointing to ../../packages/ui (shared dir in monorepo), but this in fact was not working and components were installing in ./components/ui. Pointing to right place resolved warnings (but why didn't it work in the first place... but that's another problem)


searching with many words may cause problem

/asset/js/search.js ,line 38,it should be words = query.split('+'); instead of words = query.split(' ');
Because your search words will be joined by '+' in your program.

// refs #31 #32


coverage: sharding coverage runs

This results in coverage test runtime being 5x faster.
Risk Level: Low (if there's test flakes, send 'em my way)
Testing: works locally: testing on CI now.
Docs Changes: n/a
Release Notes: n/a

Argh, coverage scripts run streaming.  Needs more work

We're working on switching to native Bazel coverage FWIW. Need to figure out why the native Bazel coverage support dies in CI.

yeah, but 1.5 months later I'm still sitting here waiting on one hour 40+ minute coverage runs.
Testing upstream to see if turning off streamed output helps any.

goodness gracious, over an hour for build alone.  will close this back off again and maybe reopen if you haven't bazel natived by the time I get back :-P


[Snyk] Upgrade fireblocks-sdk from 5.20.0 to 5.31.2

Snyk has created this PR to upgrade fireblocks-sdk from 5.20.0 to 5.31.2.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 14 versions ahead of your current version.

The recommended version was released on 2 months ago.

Release notes

Package name: fireblocks-sdk

5.31.2 - 2024-09-10Changes
🚀 Features

Add maxTotalFee tx-request param @ yuval-fireblocks (#290)

5.29.0 - 2024-08-13Changes
🧰 Maintenance

Removed unnecessary field from BurnCollectionTokenRequest @ trongvnau (#289)

🚀 Features

Add set asset price api @ vsiskin (#277)
Add link contract routes @ phanigovindaraju (#287)

5.28.1 - 2024-07-30Changes
🐛 Bug Fixes

Tokenization Collection API - Changed token metadata objects' fields from camel Case to snake case @ trongvnau (#288)

5.28.0 - 2024-07-15Changes
🚀 Features

Add Tokenization Collections API @ or109 (#285)

5.27.2 - 2024-06-23Changes

Set NCW wallet required algorithms @ yuval-fireblocks (#281)

🐛 Bug Fixes

Fix getWalletDevices return type @ yuval-fireblocks (#278)

5.27.1 - 2024-06-20Changes

functions instead of abi @ brohamgoham (#280)

5.27.0 - 2024-06-17Changes

Add algorithm id to asset response @ goweiss (#271)

🚀 Features

Fetch address by chain and tx hash @ amimagid (#279)

5.26.0 - 2024-05-31

5.25.1 - 2024-04-16

5.25.0 - 2024-04-10

5.24.0 - 2024-04-02

5.23.0 - 2024-03-14

5.22.0 - 2024-03-12

5.21.0 - 2024-02-29

5.20.0 - 2024-01-30

    from fireblocks-sdk GitHub release notes

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:

🧐 View latest project report
📜 Customise PR templates
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Resolved in release v1.3.12


Unexpected response from Steam

Steam response:

Before was working well but now I have this issue. Fixes by adding this to all curl requests by this library:
curl_setopt($ch, CURLOPT_ENCODING, "gzip");

Does it affect non-gzipped responses?

I am bad at curl, requests and api, so I don't understand what are you talking about. It works well on my 2 hosts. I found solution on stackoverflow

Now tried at remote host without fix - all works. Don't know what is this.

Anyone else experiencing this problem?

Now stable. I think it's OS settings or network bug


License is missing

There appears to be no license, can this be added to the repository.

Resolved #6


latest progress

hi, @JafarAkhondali  is there any latest progress now? I'm ready to continue developing unplugin-vue-fervid and @farmfe/plugin-vue

Hi @ErKeLost, curious as to why you ping Jafar as he isn't a part of the project.
To answer your project, I am actively working on making Fervid fully compliant with the official specification. You can see progress on the umbrella issue: https://github.com/phoenix-ru/fervid/issues/16
If you want to contribute, there are two untouched opportunities at the moment:

Working on the SSR code generation (this will open up integrating Farm as the official fully-native build tool into Nuxt, which is my ultimate goal).
Working on making the Node.js / Farm plugins better. They already support lots of options and work good enough to pass spec tests, but are somewhat limited and not well polished.

Please tell me if you're interested in any of the options above or maybe would like to contribute somewhere else? :)

My idea is that if the basic project unplugin-vue-fervid can be successfully run on various frameworks, then I am very willing to continue to help you solve the remaining problems and then develop the final goal of farm's native plugin.

if we ignore the ssr issue for the time being, can the entire behavior support me to complete the unplugin-vue-fervid project

Yes, the CSR code output is almost identical with some minor discrepancies which I am actively trying to cover. It is generally very usable already (although needs "highly experimental" note).

ultimately maintain the same behavior as vue/compiler-sfc

I am afraid it is technically impossible to maintain 1-to-1 compatibility without severely crippling the native speed of Fervid. The reason being - JS compiler is lousy in that it uses JS plugins, functions, etc:

Babel Plugins https://github.com/vuejs/core/blob/5a5406d002f568e928489920d0dcc7086c808a8d/packages/compiler-sfc/src/compileScript.ts#L76
Custom Filesystem https://github.com/vuejs/core/blob/5a5406d002f568e928489920d0dcc7086c808a8d/packages/compiler-sfc/src/compileScript.ts#L119-L123
Custom Element function https://github.com/vuejs/core/blob/5a5406d002f568e928489920d0dcc7086c808a8d/packages/compiler-sfc/src/compileScript.ts#L127

Fervid intends to be the real parallel compiler (with speed of up to 60K files/sec), and calling JS destroys that dream

The ultimate goal is to implement a pure native @farmfe/plugin-vue plug-in so as to ensure 100% performance output

I agree here, I think having a native plugin is the ultimate goal :)

unplugin-vue-fervid can be successfully run on various frameworks

What do you mean by "frameworks"?

final goal of farm's native plugin

I see Farm initially providing a plugin for CSR and later supporting SSR as well

The goal is to benefit some other frameworks such as rspack vite webpack first. The current problem is that, for example, rspack does not support rust plug-ins. I think we can provide them with js plugins first to enhance our influence, so that more and more people know that not only react has rust compiler vue

Farm, the function of ssr, can also be realized. I want to implement unplugin-vue-fervid first and then help you solve ssr issues with all your strength. Farm is about to release 2.0. The goal of 2.0 is to create a complete set of rust ecological chain.

Framework means implementing js versions of plugins for other frameworks

I agree with your points. Is there anything else or more specific you have questions about?

Not yet. I want to start this project. If I have any questions, I will always ask you.

hi @phoenix-ru
this is my current understanding of the vue compilation process
i will first summarize it as a whole and then proceed to the point of compiling the specific core parts of the code
i will only describe the vue compilation process and the current difference between fervid and compiler-sfc, the next goal is to get as close to compiler-sfc functionality as possible
i choose vite-plugin-vue as the segmentation point among vue-loader and vite-plugin-vue to be more in line with the modern plugin process
plugin compilation process
unplugin-vue compiles vue

handle helper code

load(id) {
  // 1. handle helper code
  if (id === EXPORT_HELPER_ID) {
    return helperCode;
  }
}

helper code
export const EXPORT_HELPER_ID = "\0/plugin-vue/export-helper";

export const helperCode = `
export default (sfc, props) => {
  const target = sfc.__vccOpts || sfc;
  for (const [key, val] of props) {
    target[key] = val;
  }
  return target;
}
`;

merge options

sfc.vccOpts || sfc: Get the option object of the component __vccOpts is Vue Component Compiled Options, If there is no __vccOpts, use sfc itself directly

inject props

Traverse the props array, injecting each attribute into the component options
These attributes typically include:

__file components name
__scopeId css scoped id
__hmrId handle hmr
render or ssrRender render function

The role of this helper is to ensure:
Correct attribute merge: Ensure that all compile-time attributes are correctly merged into the component
Scope isolation: Supported scoped CSS through __scopeId
transform code
such as vite bundler, We need to distinguish between the development environment and the production environment. For example, vite optimizes the development environment dev server and does not split multiple module requests, that is, it does not split the entire vue file into multiple js modules and return the esm http request.
There are three operations in transform:

transformMain: main request

Triggered when a. vue file is requested directly, the first compilation is triggered

For example:/src/App. vue

if (!query.vue) {
  return transformMain(
    code,
    filename,
    options.value,
    context,
    ssr,
    customElementFilter.value(filename),
  );
}

Main responsibilities:

Integrate all sub-modules (template, script, style)

export async function transformMain(code, filename, options, ...) {
  // 1. create descriptor
  const { descriptor, errors } = createDescriptor(filename, code, options);

  // 2. handle script
  const { code: scriptCode, map: scriptMap } = await genScriptCode(
    descriptor,
    options,
    pluginContext,
    ssr,
    customElement,
  );

  // 3. handle template
  let templateCode = '';
  if (hasTemplateImport) {
    ({ code: templateCode } = await genTemplateCode(
      descriptor,
      options,
      pluginContext,
      ssr,
      customElement,
    ));
  }

  // 4. handle styles
  const stylesCode = await genStyleCode(
    descriptor,
    pluginContext,
    customElement,
    attachedProps,
  );

  // 5. handler custom blocks
  const customBlocksCode = await genCustomBlockCode(descriptor, pluginContext);

  // merge all compilation code
  const output: string[] = [
    scriptCode,
    templateCode,
    stylesCode,
    customBlocksCode,
  ];
}

Generate final component definitions

// 1. add components props scopedId
if (hasScoped) {
  attachedProps.push([`__scopeId`, JSON.stringify(`data-v-${descriptor.id}`)]);
}

// 2. add file info (for dev tools)
if (devToolsEnabled || (devServer && !isProduction)) {
  attachedProps.push([
    `__file`,
    JSON.stringify(isProduction ? path.basename(filename) : filename),
  ]);
}

// 3. use helper to merge all properties (helper will merge all properties into component)
output.push(
  `export default /*#__PURE__*/ _export_helper(_sfc_main, [
    ${attachedProps.map(([key, val]) => `['${key}',${val}]`).join(",\n    ")}
  ])`,
);

Handling HMR-related logic

// 1. check if HMR is enabled
if (
  devServer &&
  devServer.config.server.hmr !== false &&
  !ssr &&
  !isProduction
) {
  // 2. add HMR ID
  output.push(
    `_sfc_main.__hmrId = ${JSON.stringify(descriptor.id)}`,

    // 3. create HMR record
    `typeof __VUE_HMR_RUNTIME__ !== 'undefined' && ` +
      `__VUE_HMR_RUNTIME__.createRecord(_sfc_main.__hmrId, _sfc_main)`,

    // 4. listen to file changes
    `import.meta.hot.on('file-changed', ({ file }) => {
      __VUE_HMR_RUNTIME__.CHANGED_FILE = file
    })`,
  );

  // 5. check if only template has changed
  if (prevDescriptor && isOnlyTemplateChanged(prevDescriptor, descriptor)) {
    output.push(
      `export const _rerender_only = __VUE_HMR_RUNTIME__.CHANGED_FILE === ${JSON.stringify(
        normalizePath(filename),
      )}`,
    );
  }

  // 6. add HMR accept handling
  output.push(
    `import.meta.hot.accept(mod => {
      if (!mod) return
      const { default: updated, _rerender_only } = mod
      if (_rerender_only) {
        // only template changed, just rerender
        __VUE_HMR_RUNTIME__.rerender(updated.__hmrId, updated.render)
      } else {
        // other changes, reload the entire component
        __VUE_HMR_RUNTIME__.reload(updated.__hmrId, updated)
      }
    })`,
  );
}

Add SSR support (pending now fervid not support ssr)

The above is the logic of all transform main. In the first stage, we can actually complete all hmr and vue compilation functions in the development environment
The main code logic we generated is
This is the most important code in the first phase of dev mode

script code

  "import { defineComponent as _defineComponent } from 'vue'\n" +
    'import { ref } from "vue";\n' +
    '\n' +
    'const _sfc_main = /*@__PURE__*/_defineComponent({\n' +
    "  __name: 'App',\n" +
    '  setup(__props, { expose: __expose }) {\n' +
    '  __expose();\n' +
    '\n' +
    'const msg = ref("22222222");\n' +
    'console.log(123132);\n' +
    '\n' +
    'const __returned__ = { msg }\n' +
    "Object.defineProperty(__returned__, '__isScriptSetup', { enumerable: false, value: true })\n" +
    'return __returned__\n' +
    '}\n' +
    '\n' +
    '})',

template code

'import { createElementVNode as _createElementVNode, toDisplayString as _toDisplayString, vModelText as _vModelText, withDirectives as _withDirectives, createTextVNode as _createTextVNode, openBlock as _openBlock, createElementBlock as _createElementBlock } from "vue"\n' +
  "\n" +
  "function _sfc_render(_ctx, _cache, $props, $setup, $data, $options) {\n" +
  '  return (_openBlock(), _createElementBlock("div", null, [\n' +
  '    _cache[1] || (_cache[1] = _createTextVNode(" 123132 ")),\n' +
  '    _cache[2] || (_cache[2] = _createElementVNode("div", null, "4565465", -1 /* HOISTED */)),\n' +
  '    _cache[3] || (_cache[3] = _createElementVNode("h1", null, "Hello world", -1 /* HOISTED */)),\n' +
  '    _cache[4] || (_cache[4] = _createTextVNode(" 3123132ww ")),\n' +
  '    _createElementVNode("h2", null, _toDisplayString($setup.msg), 1 /* TEXT */),\n' +
  '    _cache[5] || (_cache[5] = _createTextVNode("<PHONE_NUMBER>1222146521312wwwwww321 ")),\n' +
  '    _withDirectives(_createElementVNode("input", {\n' +
  '      "onUpdate:modelValue": _cache[0] || (_cache[0] = $event => (($setup.msg) = $event)),\n' +
  '      type: "text"\n' +
  "    }, null, 512 /* NEED_PATCH */), [\n" +
  "      [_vModelText, $setup.msg]\n" +
  "    ])\n" +
  "  ]))\n" +
  "}",
  "\n";

style code

 'import "/Users//examples/vite/src/App.vue?vue&type=style&index=0&lang.css"',

hmr code

'_sfc_main.__hmrId = "7a7a37b1"',
  "typeof __VUE_HMR_RUNTIME__ !== 'undefined' && __VUE_HMR_RUNTIME__.createRecord(_sfc_main.__hmrId, _sfc_main)",
  "import.meta.hot.on('file-changed', ({ file }) => {",
  "  __VUE_HMR_RUNTIME__.CHANGED_FILE = file",
  "})",
  "import.meta.hot.accept(mod => {",
  "  if (!mod) return",
  "  const { default: updated, _rerender_only } = mod",
  "  if (_rerender_only) {",
  "    __VUE_HMR_RUNTIME__.rerender(updated.__hmrId, updated.render)",
  "  } else {",
  "    __VUE_HMR_RUNTIME__.reload(updated.__hmrId, updated)",
  "  }",
  "})";

then we finally generate the code with

import _export_sfc from '\x00/plugin-vue/export-helper'",
  `export default /*#__PURE__*/_export_sfc(_sfc_main, [['render',_sfc_render],['__file',"/Users//examples/vite/src/App.vue"]])`

Running this code, we complete the compilation of vue. This is the complete first stage of the process.
Next we start to describe the details
First function point descriptor

createDescriptor

const { descriptor, errors } = createDescriptor(filename, code, options);

descriptor structure

interface SFCDescriptor {
  // file path
  filename: string;
  // source code
  source: string;
  // unique identifier
  id: string;

  // information of each block
  template: SFCTemplateBlock | null;
  script: SFCScriptBlock | null;
  scriptSetup: SFCScriptBlock | null;
  styles: SFCStyleBlock[];
  customBlocks: SFCBlock[];

  // CSS variables
  cssVars: string[];
  // Whether it contains the Slotted API
  slotted: boolean;
}

interface SFCTemplateBlock extends SFCBlock {
  type: "template";
  content: string;
  lang?: string; // such as 'pug'
  ast?: any; // template AST
  src?: string; // external template path
}

interface SFCScriptBlock extends SFCBlock {
  type: "script";
  content: string;
  lang?: string; // such as 'ts'
  src?: string; // external script path
  setup?: boolean; // whether it's a setup script
  bindings?: BindingMetadata; // variable bindings
}

interface SFCStyleBlock extends SFCBlock {
  type: "style";
  content: string;
  lang?: string; // such as 'scss'
  scoped?: boolean; // whether it's scoped style
  module?: string | boolean; // CSS Modules configuration
}

Descriptor main logic:

share the same descriptor for all components in the same file

// handler script info
const scriptBindings = descriptor.scriptSetup?.bindings;
// handler scoped id check if has scoped
const hasScoped = descriptor.styles.some((s) => s.scoped);

Hmr support

// diff old descriptor and new descriptor to detect if only template has changed
if (prevDescriptor && isOnlyTemplateChanged(prevDescriptor, descriptor)) {
  // update template only
}

Cross-block communication

// Example: CSS variables are passed from style to template
const cssVars = descriptor.cssVars;

Importance of Descriptors:

Unified interface: Provides a unified data structure for different compilation stages

Information sharing: Allow different compilation steps to share information

Incremental updates: support for HMR and on-demand compilation

Extensibility: Support custom blocks and various preprocessors

Optimization support: Provide necessary information for various optimizations

There are also a few more important methods in the compilation of vue
I was thinking about distinguishing these methods and code logic in fervid. Now that fervid only provides one method, can we achieve consistent behavior with compiler-sfc?
I am thinking that without considering caching and ssr in the first step, we need to implement the following method

compiler.compileScript (generate script code main __sfc_main)
compiler.compileTemplate (generate template code)
compiler.compileStyle (generate style code)
compiler.parse (generate descriptor)

Hi @ErKeLost, I've read through your research and it looks mostly correct.
To answer your question as to why Fervid only provides a single method in comparison to the official compiler — costs of serialisation/deserialisation are very high.
Instead of doing back-and-forth between JS and Rust side, I provide only one input and return only one output.
Fervid also significantly differs in a way it compiles the code. Instead of doing string concatenation like the official compiler, Fervid fully operates with IR+AST. It provides some guarantees about the processing and the output. The official compiler is also moving towards AST, but very slowly and inconsistently.
As to assembling the parts of SFC into a single file (which you called "optimization"), Fervid does it out-of-the-box and much smarter. Since it works with AST directly, it merges properties directly into the object and thus no helpers/additional things are needed.
The only thing Fervid does not handle by design is HMR (because it differs across bundlers). This will be up to the plugin.
So, in short — there will be no descriptor in the JS side and any manipulations should happen in the Rust side.

Has fervid already done all the operations on the rust side? For example, the problem of attribute merging incorporates some functions like scopedId? I haven't checked the specific code of fervid yet. I will check the code logic in the near future.

Yep. Most of Rust transforms are implemented and I am polishing them at the moment so that it matches the official compiler as much as possible.

my idea is whether we can synchronize compiler-sfc methds as much as possible and expose them through napi, which will allow us to better optimize the code and synchronize the code in the future, regardless of compiler-sfc updates or we can eventually replace compiler-sfc. Of course, we can support the current effect of compile. I wonder if we can split it more carefully and release different js methods for different functions.

synchronize compiler-sfc methds

Would this mean exposing the descriptor somehow? If you want to go this route, we can certainly do it using External
You would need to provide methods which operate on an External descriptor. It should be doable, although there is no direct mapping of compiler-sfc descriptor to the one used by Fervid (as Fervid uses a lot of internal structs instead)

Another question - how much freedom in JS-land do you want to have? You wouldn't be able to operate on a descriptor except for calling Napi functions exported by Fervid

What I want to do is try to keep the api consistent. The descriptor only corresponds to the behavior of compiler-sfc. I don't seem to need to change the descriptor at the moment. I don't know if there are still some deviations in my understanding


output format error of vscode

VSCode Version:1,17.2
OS Version:windows 10

ID	Class
xl001	xl002	xl003	xl004	xl005	xl006	xl007	xl008	xl009	xl010
The two line should be in one line.

I write a simple Perl script (test.pl) to make a file to match another. The perl script is
#!/usr/bin/env perl -w
use strict;
use feature 'say';

open F, "<", $ARGV[0]; #class.file1. The content is(split by \t): ID\tclass
my %hash;
while (<F>) {
    chomp;
    my @in = split( /\t/, $_ );
    $hash{ $in[0] } = $in[1];
}
close F;

open FF, "<", $ARGV[1]; #another file2 to make a match. the content is (split by \t): ID	ml001	ml002	ml003	ml004	ml005	ml006	ml007	ml008	ml009	ml010
while (<FF>) {
    chomp;
    my @in2 = split( /\t/, $_, 2 );
    say "$in2[0]\t$hash{$in2[0]}\t$in2[1]";
}
close FF;

Steps to Reproduce:

test.pl file1 file2 >out.file.txt  #this perl script was run by the terminal (bash, zsh) integrated in vscode.
the matched line in the output file has been split into 2 lines.
I have made a test by cmd, all things ok. I think the problem may be caused by the default integrated terminal in vscode?

Reproduces without extensions: Yes/No

@mbzls can you take a screenshot of the issue within the integrated terminal and also of the desired output in cmd?

The figure is the output file, which was produced through the integrated terminal in vscode by (test.pl file1 file2 >out.file.txt).

The figure is the output file, which was produced through the cmd by (test.pl file1 file2 >out.file.txt).

@mbzls which part of the code exactly is meant to be sending the line feed character? Can you identify it and come up with a minimal repro case?
Also is this under WSL?

@Tyriar just follow my steps as above. you will find the problem.
yes, this is under wsl. ubuntu, downloaded from windows store.

Not sure what I'm doing wrong:

What's meant to be in file1 and file2?


Add support for non-interactive ejection process

Fixes https://github.com/react-community/create-react-native-app/issues/196

Thanks! I have a pretty busy week coming up with React Europe but this is on my radar

Please, oh please, prioritize this. It's been more than three years now without a comment on this PR. In today's world, automation should be a top priority for any decent framework.

@Zomis where are you getting three years? This is ~2 months old.
Also for what it's worth I don't think that automating eject in CI is very well aligned with the reasons we originally built CRNA: to make it easier to learn React Native. Don't get me wrong, it's really awesome that people are able to build whole apps with it and to then run their native build in CI, but I feel like we should have a better solution for "production" CRNA projects.

@Zomis This is not for building 'production' apps.  I need a develop -> build -> deploy cycle for a CRNA app.  In my environment, the only way to get an app onto a device is to sign it using an enterprise certificate.  That process has been automated.  This step only makes it easier to plug the CRNA into such an environment.
I agree with you that this should not be used to build 'production' apps.

I think a better solution here is to refactor react-native-scripts/src/scripts/eject.js such that it exports a function that you can call directly to eject, then exporting that from the main package so you can add a script to your project to do the eject for you.
it would look like:
import { eject } from 'react-native-scripts';

eject({
  projectName: '..',
  otherThing: '..',
});

what do you think @bigosmallm?

That should work as well.  That sounds a more involved changes to eject.js.  If you are going to do that, that would be great!

I am not going to work on it, but anyone who would like this feature is welcome to implement it as described above and I will accept a pr for it.
I really appreciate you putting it together and I'm very sorry that it took me so long to get a response to you on it. I manage a lot of different projects and when I'm unsure about whether I'd like to add something to a project or not I have a tendency to ignore the issue, I need to get better at that. I think that the non-interactive eject option as originally proposed adds a maintenance burden on CRNA maintainers and is a niche option that only few people will actually use, and I should have expressed this sooner and suggested an alternative proposal as I did today, above. Hopefully someone implements the proposal, until then I will close this PR.

No problem.  Thanks for the response.

@dikaiosune Whoops, "three months" of course. Self-note: Don't comment on github PRs right before going to sleep.
@brentvatne @bigosmallm I do get slightly annoyed when you say "This is not for building 'production' apps." and decide to close this issue. Especially given the eject documentation: "Warning: Running eject is a permanent action". I thought "Well, I'll just let Jenkins do it and then it is not permanent". I did not intend to use this for production. If ejecting is a permanent action and should not be done by Continuous Integration, then when should I eject? I would recommend documenting the "recommended workflow" better. All I wanted to do was to automatically build a prototype of my app for my phone (I'm even planning to use ./gradlew assembleDebug after automatically ejecting) so that I could bring it with me without having my computer at home running npm start.

@dikaiosune @brentvatne @bigosmallm See my Pull Request #345 . I spent some time learning more JavaScript only to be able to give you this pull request. It was educational.

Ping @brentvatne . It's been more than a month now since I added a PR.


feat: Initial E2E framework and simple tests

Initial E2E framework and simple tests
Resolves issue #137

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 46.89%. Comparing base (3356368) to head (f4f1592).
Report is 3 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #211      +/-   ##
==========================================
+ Coverage   46.86%   46.89%   +0.02%
==========================================
  Files          57       57
  Lines        4886     4956      +70
==========================================
+ Hits         2290     2324      +34
- Misses       2420     2451      +31
- Partials      176      181       +5

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Fix option default type for booleans

This pull-request does 2 things:

Add an if statement to check if default type is a boolean, if so correct Python type is output (line 85 and 86 in avro_to_pydantic.py).
Fix a typo in function name (line 5 in avro_to_pydantic.py)

Codecov Report

Merging #20 (61e04f3) into main (a0e43d1) will increase coverage by 0.14%.
The diff coverage is 75.00%.

@@            Coverage Diff             @@
##             main      #20      +/-   ##
==========================================
+ Coverage   87.73%   87.87%   +0.14%
==========================================
  Files           2        2
  Lines         163      165       +2
==========================================
+ Hits          143      145       +2
  Misses         20       20

Impacted Files
Coverage Δ

src/pydantic_avro/avro_to_pydantic.py
80.23% <75.00%> (+0.47%)
:arrow_up:

Continue to review full report at Codecov.

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


Send embedding requests to OpenAI api in batches

Previously the OpenAI embedding class was making one call to the OpenAI API for each document, but this is much slower than it needs to be and also prone to getting rate-limited and or getting a "come back later" response. OpenAI's API is not well documented, but I think this is the intended use. Their example of usage for a single doc was a bit confusing. This PR fixes that problem and it also works for large numbers of documents.

Also, add a rate limiting parameter that will throttle the number of calls or wait and re-retry .


Fixes needed to get jazzy source build to work on nobleo-main

Thanks, please also open up an upstream PR.

Done: https://github.com/autowarefoundation/autoware.universe/pull/9178


program not fast enough

Dear BisocM,
Thank you for developing this program to automate my typing practice, I'm sure my skills will improve heavily with this program. I did come across one problem however and that is that the program is not fast enough meaning that it does not reflect my typing speed (500 WPM) whereas the program only runs at roughly ~350 WPM which means that I am being capped off.

Seems speedy enough to me! It is hard to reflect the exact mechanism MK uses to calculate WPM, discrepancy between the desired WPM and actual WPM is to be expected, as the project was not trying to be 100% faithful to the implementation anyhow.


13058 COLIN API failure - Front and Backend Change validation of the first name field in Coop IA UI and/or Corp Party table

Issue #: /bcgov/entity#13058
Description of changes:

change the max length of "firstName" to 20
change UI before the schema change

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the bcrs-entities-create-ui license (Apache 2.0).

@lewischenstudio so create-ui doesn't make use of the shared component you just updated?

@lewischenstudio so create-ui doesn't make use of the shared component for completing party you just updated?

Some components use it. The CompletingParty component uses the first name rule from create ui.

I merged bcrs-shared PR with completing-party: 2.0.4 and tried to update local package.json file with this version. It's not available to install. I think we need to push that project to live before we update the max length in first name rules for UIs.

I merged bcrs-shared PR with completing-party: 2.0.4 and tried to update local package.json file with this version. It's not available to install. I think we need to push that project to live before we install the new version for completing party and update the max length in first name rules for UIs. Create UI doesn't use the rules from bcrs-shared, so it's fine for now.

You did not follow the instructions in the readme in bcrs-shared-components.
But I ran steps 14-15 anyways and the new version is not available for import.

I was making the test case for the completing party component in the DissolutionFirm.spec.ts.
I then found out this PR was merged 😆
I must ran out of time ⌛, and I'll be faster next time 😄
I asked @vysakh-menon-aot to include the test case in his PR. Thank you 👍


Empty testcase report of pyTest means PASS

There are new status 'READY' and 'RUNNING' added for test report,
mainly for interactive mode. If a test case report has no entry then
the default status is 'READY'. We also support integrating pyTest
into our report, and adding assertion using Result object. If no
assertion added then there is no entry in the testcase report, but
actually it has passed because no error raised in pyTest.

It would be better if you can add some testcases

Looks good to me. I made a similar change for PyUnit already but missed PyTest, thanks for fixing it up.
Personally, I much prefer to explicitly set the status of an empty testcase to Passed rather than implicitly expecting the report entry to default to Passed.

I don't think it is a decent solution to add such logic to all different types of test that we have. The test's state and their precedence/aggregation needs more thoughts and better design.


How to serialize DataSets / DataTables?

Describe the bug

What are you trying to do?
I try to serialize System.Data.DataSet types with Ceras.

What do you think should happen?
They should be serialized to byte[] properly.
May be I have to set some special config to allow DataSet seralization, but I don't know what to do.
The FAQ says nothing about DataSets.
I don't care if DataSets are rated bad or insecure by some people, because I have large applications with a big code base that I don't want to write from scratch.

What is actually happening?
I'm getting a Ceras.Formatters.BannedTypeException: The type 'System.Data.DataSet' cannot be serialized, please mark the field/property that caused this Type to be included with the [Exclude] attribute or filter it out using the 'ShouldSerialize' callback. Specific reason for this type being banned: "This type can be exploited when deserializing malicious data". You should open an issue on GitHub or join the Discord server for support.
at Ceras.Formatters.BannedTypes.ThrowIfBanned (System.Type type) [0x0017e] in :0
at Ceras.CerasSerializer.CreateMetaData (System.Type type, System.Boolean isStatic) [0x0001f] in :0
at Ceras.CerasSerializer.GetReferenceFormatter (System.Type type) [0x00000] in :0
at Ceras.CerasSerializer.Serialize[T] (T obj, System.Byte[]& buffer, System.Int32 offset) [0x00055] in :0
at Ceras.CerasSerializer.Serialize[T] (T obj) [0x00010] in :0
at CerasDataSetDemo.Program.Main (System.String[] args) [0x000f6] in :0

How to reproduce the bug
Here is my example code to reproduce the issue:
        var dataSet = new DataSet("TestDataSet");
        var table = new DataTable("Person");
        var personIDColumn = table.Columns.Add("PersonID", typeof(int));
        personIDColumn.AutoIncrement = true;
        personIDColumn.AutoIncrementSeed = -1;
        personIDColumn.AutoIncrementStep = -1;
        table.Columns.Add("FirstName", typeof(string));
        table.Columns.Add("LastName", typeof(string));
        table.PrimaryKey = new DataColumn[] {personIDColumn};
        dataSet.Tables.Add(table);
        var row = table.NewRow();
        row["FirstName"] = "Max";
        row["LastName"] = "Mustermann";
        table.Rows.Add(row);
        row.AcceptChanges();
        row["FirstName"] = "Maxine";
        var ceras = new CerasSerializer();
        byte[] raw = ceras.Serialize(dataSet);
        var dataSet2 = ceras.Deserialize<DataSet>(raw);
        Console.WriteLine(dataSet2.Tables["Person"].Rows[0].RowState);
        Console.WriteLine(dataSet2.Tables["Person"].Rows[0]["FirstName"]);
        Console.WriteLine(dataSet2.Tables["Person"].Rows[0]["FirstName", DataRowVersion.Original]);

Platform

I'm using Ceras for net4.7+

I don't care if DataSets are rated bad or insecure by some people, because I have large applications with a big code base that I don't want to write from scratch.

Ok, whatever, I won't stand in your way 😝
You can compile the code yourself, comment out the corrosponding part here:
https://github.com/rikimaru0345/Ceras/blob/master/src/Ceras/Helpers/BannedTypes.cs#L74
But it is not a bug, the concern is valid.
If you add a setting that enables one to turn off those bans, I'd merge it (assuming it is off by default).

Thank you so much.
This will help.
Sorry for tagging this issue as bug. You're right, DataSet serialization has security issues and so it should only be used in a trusted environment and never exposed to the Internet.
I'll try to extend settings with a "AllowDataSetSerialization" property, which is set false by default.

I am going to second this request. I actually have a large number of applications that make use of large datatables and being able to cache these in something like redis would really help. I tried to muck with the BannedTypes but ran already into issues serializing CultureInfo. So an effort on DataTable would really be appreciated.

@andreasmaier-abt Alright, noted.
I'll add it to my todo list. But but it's probably going to take a while before I can make time to work on Ceras again (sorry ☹).

[ ] Add a way to disable specific type-bans

but ran already into issues serializing CultureInfo.
What exactly is the problem with CultureInfo?
I never really worked with it, but after looking at:  https://docs.microsoft.com/en-us/dotnet/api/system.globalization.cultureinfo.-ctor?view=netframework-4.8#System_Globalization_CultureInfo__ctor_System_Int32_
it seems like its basically just an int.

But if someone creates their own CultureInfo (based on some existing one and then just changing some properties), it's a little bit more complicated to serialize.
Anyway, whatever the issue with it is, adding support for it in Ceras is most likely very easy.


documentation link for setup.py (catkin_python_setup) is 404

As stated above, the following link http://ros.org/doc/api/catkin/html/user_guide/setup_dot_py.html is dead.

a quick google search indicated to a ros Jade documentation (catkin 0.6.19).
archive.org told me the link was alive at least until 2021/01/11 (catkin 0.8.19).
by looking at the api html, the page itself is gone.
the link is presented at least in the following locations:

http://wiki.ros.org/catkin
a newly created CMakeLists.txt

Questions:

is the function depreciated, or dead?
if not, can(should) we revive the documentation?

The entire documentation is down, not just one page...
This should be fixed by a new release of catkin-sphinx, see https://github.com/ros-infrastructure/catkin-sphinx/issues/14

A new release of catkin-sphinx has been published. So the documentation generation should be working again.
@dirk-thomas @wjwwood @ivanpauno @gbiggs could one of you please trigger a new documentation job for noetic.

There is some kind of misbehavior in the doc job. The user_guide and howto sections are not appearing.
Using ros_buildfarm to generate a local reproduction and run it reproduces the problem but generating docs locally directly with sphinx generates those sections.
generate_doc_script.py https://raw.githubusercontent.com/ros-infrastructure/ros_buildfarm_config/production/index.yaml noetic default catkin ubuntu focal amd64 > /tmp/noetic_catkin_doc/run.sh


[SPARK-28775][CORE][TESTS] Skip date 8633 in Kwajalein due to changes in tzdata2018h that only some JDK 8s use

What changes were proposed in this pull request?
Some newer JDKs use the tzdata2018h database, which changes how certain (obscure) historical dates and timezones are handled. As previously, we can pretty much safely ignore these in tests, as the value may vary by JDK.
Why are the changes needed?
Test otherwise fails using, for example, JDK 1.8.0_222
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Existing tests

You are quick :)

Test build #109366 has started for PR 25504 at commit 6a022ce.

Merged build finished. Test PASSed.

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

Oh, it does again. Thank you, @srowen . I also downloaded and checked this.
+1, LGTM.
BTW, could you update the PR title and description from tzdata2018h to tzdata2019i? In Java community, tzdata2018h seems to be skipped.

https://bugs.openjdk.java.net/browse/JDK-8215981 (tzdata2018h, `Won't Fix)
https://bugs.openjdk.java.net/browse/JDK-8224901 (tzdata2018i, Fixed).

Yep confirmed in https://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html

Test build #109366 has finished for PR 25504 at commit 6a022ce.

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

Merged build finished. Test PASSed.

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

Merged to master/2.4/2.3.


Bluetooth: Controller: Assert on CIS when connecting ACL after CIS disconnect

Describe the bug
The central will hit an assert if connecting and pairing an ACL after disconnecting a CIS:
ASSERTION FAIL [cis] @ WEST_TOPDIR/zephyr/subsys/bluetooth/controller/ll_sw/ull_conn_iso.c:215

To Reproduce
Steps to reproduce the behavior:

Build /samples/bluetooth/hci_rpmsg/ with nrf5340_cpunet_iso-bt_ll_sw_split.conf for the nRF5340 netcore, then as the central do the following
Connect ACL_1
Pair ACL_1
Create CIG_1
Connect CIS_1
Disconnect CIS_1
Delete CIG_1
Connect ACL_2
Pair ACL_2
See the above assert

Expected behavior
Expect pairing to not have anything to do with CIS and the assert.
Impact
Significant
Logs and console output
central_cis_disconnect.txt
Environment (please complete the following information):

Commit SHA or Version used: f66b14974268b9692980317dfb4663a03aee949b

Additional context
N/A

@erbr-ot seems like https://github.com/zephyrproject-rtos/zephyr/pull/56979 has exposed possible issue in use of ll_conn_iso_stream_get_by_acl ?


Fixes for new Admin fate command

Closes #2974

Another advantage to have the fate command run in Admin is that it doesn't require Accumulo to be running.  The only exception is cancel requires the Manager to be running.


Is it possible to install ruby of lower version?

If I run a alpine docker image and execute apk add ruby, it will install the latest ruby. I want to install specific version of ruby, ie. 1.8.7, 1.9.3, 2.2.2 etc. I execute apk search ruby, I can see only the latest ruby 2.2.4-r0. Is it possible to install lower version package? Thank you very much.

@polarlights I'm sorry, but it seems that there is no such feature in Alpine Linux, and since Alpine uses musl libc, you won't be able to use RVM unless they have ruby built against musl libc. It seems that you will need to compile the required version of Ruby yourself from sources. By the way, you can reuse Alpine APKBUILD of ruby package and it should make your life much easier since it will build a package for you, so you can even setup your own Alpine repo with various ruby versions.

@frol  I see. I will try build my own package as the official website writes. Thanks a lot.


Cash coupon

refactoring Client::register() to accept instance as well as class name for performance.
add command mmpaymkttransfers/sendredpack.

follow up with command mmpaymkttransfers/gethbinfo

Not ready yet.

Zhibin, I haven't been able to merge yet, sorry. I expect to take care of this on Monday.
Thanks for your contribution.


Use simple data I/O streams instead of JSON

Pull Request Description
Improving #8553 by using DataOutputStream and DataInputStream instead of complex JSON serialization and deserialization.
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[ ] All code follows the
Java,
style guides.
All code has been tested:

[ ] Unit tests continue to pass
[ ] Benchmarks look better: https://github.com/enso-org/enso/actions/runs/7422691615

Do you plan to also get rid of the JSON Object mapper in https://github.com/enso-org/enso/blob/c1098865f2bf093d89f60fa981c73352d2d13f34/engine/runtime/src/main/java/org/enso/interpreter/caches/ImportExportCache.java#L183 and in https://github.com/enso-org/enso/blob/c1098865f2bf093d89f60fa981c73352d2d13f34/engine/runtime/src/main/java/org/enso/interpreter/caches/SuggestionsCache.java#L30 ?
These are the only usages of com.fasterxml.jackson in runtime. We could then get rid of that dependency altogether.

Do you plan to also get rid of the JSON Object mapper in
https://github.com/enso-org/enso/blob/c1098865f2bf093d89f60fa981c73352d2d13f34/engine/runtime/src/main/java/org/enso/interpreter/caches/ImportExportCache.java#L183
and in
https://github.com/enso-org/enso/blob/c1098865f2bf093d89f60fa981c73352d2d13f34/engine/runtime/src/main/java/org/enso/interpreter/caches/SuggestionsCache.java#L30
?
These are the only usages of com.fasterxml.jackson in runtime. We could then get rid of that dependency altogether.

That could be nice, since their initialization is pretty expensive, even if done only once.

Looks like elimination of Jackson is a way to go. The startup decreased from 2940ms to 2780ms - e.g. 5% speedup:

Do you plan to also get rid of the JSON Object mapper in
https://github.com/enso-org/enso/blob/c1098865f2bf093d89f60fa981c73352d2d13f34/engine/runtime/src/main/java/org/enso/interpreter/caches/ImportExportCache.java#L183
and in
https://github.com/enso-org/enso/blob/c1098865f2bf093d89f60fa981c73352d2d13f34/engine/runtime/src/main/java/org/enso/interpreter/caches/SuggestionsCache.java#L30
?

Yes, let's do it! I've just added two tasks into this PR and I will do that by Monday.

These are the only usages of com.fasterxml.jackson in runtime. We could then get rid of that dependency altogether.

That would be great achievement! The less dependencies, the better.

Do you plan to also get rid of the JSON Object mapper in
...
These are the only usages of com.fasterxml.jackson in runtime. We could then get rid of that dependency altogether.

That could be nice, since their initialization is pretty expensive, even if done only once.

The only alternative is to switch to annotation processor based analysis like micronaut serde and eliminate the expensive initialization during runtime.
However, given how easy it is to use DataOutputStream for our purposes, we should really get of the JSON altogether.

The final results of last week speedups are visible in graph generated by:
enso/tools/performance/engine-benchmarks$ ./bench_download.py -s stdlib -b develop wip/jtulach/AvoidJacksonOnstartup_8553

On Jan 2 the Startup_empty_startup benchmark was running in 3218ms. On Jan 8 it runs in 2794ms. Result of:

#8668
#8664
#8696
Using simple data I/O streams instead of Jackson in ModuleCache

E.g. 13% speedup, congrats @Akirathan, @hubertp!

To eliminate compile time dependency on Jackson isn't really easy. There is polyglot-api project which depends on Jackson. I've just created a branch wip/jtulach/NoCompileTimeJackson that shows a possible approach to eliminate such dependency:

splits polyglot-api project into two and creates engine-common
moves suggestions handling into runtime-suggestions project

The remaining problem is SerializationManager it needs access to suggestions, but it is also required to be in the runtime. Not sure how to solve this problem yet. As such I just report the status here, without attempting to move it forward right now.


Disallow null uri as value

I am not sure if this is something we want for v7 or we should raise a deprecation notice on 7 and target this PR on 8

We should probably include change log or upgrade guide or both in these PRs, otherwise we will forget these removed deprecations.

I already started another PR about upgrade guide.. will push it there... what is your suggested procedure that we must follow?
We can merge that one and then start doing update of the CHANGELOG/UPGRADE per PR?
related PR #2473

We can merge this PR now. Good thing that you added this PR to the "Breaking changes in 7" project.


Use JSONSerialization to create json strings in swift3Action

Fixes issue #2144 -- update code to use JSONSerialization to create strings to improve performance.

Looks good, thanks for the speedy fix 👍


Github migration

[x] Migration of repo
[ ] CI: #61
[ ] Website: #66
[x] Issues
[x] Releases
[ ] MRs to PRs
[x] Archive gitlab
[x] reddit pass
[x] blog pass
[x] discourse pass
[x] other websites pass
[ ] brew package
[ ] aur package
[ ] freebsd: comment below
[ ] nixpkgs: comment below
[ ] flathub: https://github.com/flathub/com.kitware.F3D/issues/25
[x] OpenSuse community: https://build.opensuse.org/package/show/home:AndnoVember:Debian/f3d
[ ] Upcoming debian package ?
[ ] GLTF Project Expolorer: https://github.com/KhronosGroup/glTF-Project-Explorer/pull/130

@Meakk could you take care of closing and migrating the remaining gitlab MRs ?

@yurivict : please note F3D has migrated repository. I could not find a way to open an issue on freshports.

@bcdarwin : please note F3D has migrated repository. I could not find a way to open an issue on nixpkgs.

please note F3D has migrated repository. I could not find a way to open an issue on freshports.

For FreeBSD ports the right place is https://bugs.freebsd.org/bugzilla/ , but there's no need any more now, I'll update the port soon.

For future reference, for Nixpkgs the issue tracker is at github.com/NixOS/nixpkgs but in the present instance I've already opened a PR.

Thanks for the info @bcdarwin @yurivict !

@Meakk : suggestion for f3d aur package:
# Maintainer: Michael Migliore<EMAIL_ADDRESS>
export GIT_LFS_SKIP_SMUDGE=1
pkgname=f3d
pkgver=1.1.1
pkgrel=1
pkgdesc='A fast and minimalist 3D viewer'
arch=('x86_64')
url="https://gitlab.kitware.com/${pkgname}/${pkgname}"
license=('BSD')
depends=('vtk' 'ospray')
makedepends=('git' 'git-lfs' 'cmake')
source=("https://github.com/$pkgname-app/$pkgname/archive/refs/tags/v$pkgver.tar.gz")
sha256sums=('68bdbe3a90f2cd553d5e090a95d3c847e2a2f06abbe225ffecd47d3d29978b0a')

build() {
  cd "$srcdir/$pkgname-$pkgver"
  mkdir -p build
  cd build
  cmake -DCMAKE_INSTALL_PREFIX=/usr \
        -DCMAKE_BUILD_TYPE=Release \
        -DBUILD_TESTING=OFF \
        -DF3D_INSTALL_DEFAULT_CONFIGURATION_FILE=ON \
        ..
  make
}

package() {
  cd "$srcdir/$pkgname-$pkgver/build"
  make DESTDIR="$pkgdir" install
}

@Meakk :  suggestion for f3d-git aur package
# Maintainer: Michael Migliore<EMAIL_ADDRESS>
export GIT_LFS_SKIP_SMUDGE=1
_name=f3d
pkgname=$_name-git
pkgver=v1.1.0.r133.ge68d74a
pkgrel=1
pkgdesc='A fast and minimalist 3D viewer'
arch=('x86_64')
url="https://github.com/$_name-app/$_name"
license=('BSD')
depends=('vtk' 'ospray' 'opencascade')
makedepends=('git' 'git-lfs' 'cmake')
provides=('f3d')
conflicts=('f3d')
source=("git+https://github.com/$_name-app/$_name.git")
sha256sums=('SKIP')

pkgver() {
    cd "$_name"
    git describe --long | sed 's/\([^-]*-g\)/r\1/;s/-/./g'
}

build() {
  cd "$srcdir/$_name"
  mkdir -p build
  cd build
  cmake -DCMAKE_INSTALL_PREFIX=/usr \
        -DCMAKE_BUILD_TYPE=Release \
        -DF3D_MODULE_OCCT=ON \
        -DF3D_MODULE_RAYTRACING=ON \
        -DF3D_INSTALL_DEFAULT_CONFIGURATION_FILE=ON \
        ..
  make
}

package() {
  cd "$srcdir/$_name/build"
  make DESTDIR="$pkgdir" install
}

@Meakk : please update brew package when you can.

website and brew package will be updated with 1.2 release


Load pretrained model

After loading a pretrained model the pretrained losses and learning rates are not added in the loss/lr plots.

Referred in #77. Losses are plotted. Not sure about the learning rates tough.

Update: Now the learning rates are also saved and added to loss/lr plots while using pre-trained models in #77 .


ja: Make docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md follow v1.18 of the original text

This is a Feature Request

What would you like to be added
Update docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md to follow v1.18 of the original (English) text.
Why is this needed
content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md is outdated.
Comments
/language ja
/good-first-issue
File to update
https://github.com/kubernetes/website/blob/dev-1.18-ja.1/content/ja/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
Original
https://github.com/kubernetes/website/blob/fb6364d/content/en/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
diff between translated and v1.18
https://gist.github.com/434628eabe02833d728fb412f1f8c520
Note
Currently, we use dev-1.18-ja.1 branch. Please open a PR targeting the branch.
ref
https://kubernetes.io/ja/docs/contribute/localization/
If you have a question, feel free to ask us at slack.k8s.io #kubernetes-docs-ja channel

/assign

/close


Allow for periods in key of groups

I'm submitting a ...  (check one with "x")
[ ] bug report => search github for a similar issue or PR before submitting
[X] feature request
[ ] support request

Current behavior
Plunker
If I have a key to a fieldGroup like "key":"file.config.group.legend" it fails but "key":"legend" works. The weird thing is, this only seems to be a limitation of a field Group not a field itself. For example this works....
[ {
  "key":"legend",
  "fieldGroup":[{
    "key":"file.rootDirectory", // notice this
    "type":"input",
    "defaultValue":null,
    "templateOptions":
    {
              "type":"text",
              "label":"file.rootDirectory.label",
              "placeholder":"file.rootDirectory.placeholder"
     }
  }]
}]

Expected behavior
Allow for periods in key of group
Minimal reproduction of the problem with instructions
See plunker
What is the motivation / use case for changing the behavior?
For namespacing this is the way our forms currently work.
P.S. I will try to look into it as well if I can get some time.

I think this got fixed by #293

In the demo application, I tried
{
        key: 'address.value', // [changed]
        className: 'row',
        wrappers: ['panel'],
        templateOptions: {
          title: 'Address',
        },
        fieldGroup: [{
          className: 'col-md-6',
          type: 'input',
          key: 'street.key', // [changed]
          validators: {
            validation: ['required'],
          },
          templateOptions: {
            label: 'Street',
            placeholder: '604 Causley Ave. ',
            description: 'Enter a valid US Address',
          },
        }
}

and it saves it like
"address": {
    "value": {
      "street": {
        "key": "input value"
      }
    }
  },

Sorry not sure what "Demo application" and "saves it" means. Is there a plunker with the new version so we can confirm?
I tried that on plunker and got the same results...
https://plnkr.co/edit/uidAiWaD4hVptNDd5SPA?p=preview

Sorry I think I understand, by saving it you mean what is in the ngModel right?
That looks like it should be fine for what we are doing. It might be nice to allow people to turn that feature off if they really want the string to have a period in the key, but then again that would be invalid JSON I believe.

Right now you are using v2.0.0-beta.13, and we had a pull request after that by @Krustie101 #293 which probably resolved this issue. You cannot check this on plnkr, you have to clone this project to run the demo application.
Clone the project, install dependencies using (yarn or npm install) and run npm run demo to run the demo application included in this repository.

Ok thanks I will try it out and get back to you

Another little facet to this bug is that even though the form works with a period in the field name, this causes the label to fail. So for example here we don't see the address label, however, removing the period in the key shows the label. Will this be fixed as well?

For now use this workaround https://plnkr.co/edit/o2gDlyQNqs3OXnwMdTzN?p=preview

Check this demo https://plnkr.co/edit/o2gDlyQNqs3OXnwMdTzN?p=preview
It uses updated formly (which is not yet released)

I just tried the demo that you mentioned and there are a couple things...
1.) Can I try this in my own app? I tried overwriting the bundle folder in node_modules but no dice.
2.) There appears to be an issue still. I changed the first couple like this...

I get an error...

Cannot find control with name: 'person.title1'

BTW I can confirm that the nested ones seem to work just not the "new" nested ones I make.

@jrgleason looks like its the type: radio that didn't work with nested ones, but type input does work


Gas Limit reported lower than the Gas Used of a block

Problem
For block  at height 755106, the gasLimit value is lower than the gasUsed. Wondering, based on EIP-1559 if the gasLimit should be bumped up to the max cap of 30M, as gasUsed target more than 15M of the limit.
Steps to Reproduce
curl https://mainnet.evm.nodes.onflow.org -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0xB85A2", false],"id":1}' | jq

Context
Running a block parser and found under the validation step gasLimit < gasUsed

@infsaulo Nice catch :100: We need to update that constant for the block gas limit. And I guess it might go over 30M as well.


iex_debugTrap link error

when using adsk fbx lib & other lib that include your lib we get link error over debugTrap, any plan to fix that ?

You can get around the problem by defining your own iex_debugTrap() as
void iex_debugTrap() { std::cout << "what the heck" << std::endl; }
I suggest reporting this problem to Autodesk as the issue lies with the fbx distribution.

Looking into the OpenEXR issue backlog.  Does not seem to be an OpenEXR issue, so closing.

That is a good point about the namespacing introduced across the rest of the library to resolve these kinds of collisions. TBH iex_debugTrap should probably be removed. It's not a normal sort of thing to find in a modern library. I personally added this mechanism a loooooong time ago, when debuggers such as the Visual Studio debugger were unable to break when exceptions were thrown. Those days are long gone, and the mechanism is archaic.


Update Abstraction dll from export 24.5.1f76

Please pull this in!

This PR changes are not required and was un-intentional.
Closing the PR.

This PR changes are not required and was un-intentional.
Closing the PR.


macOS download 2.3.0 doesn't contain a version number

the app https://featherwallet.org/files/releases/mac/feather-2.3.0.dmg is missing the bundleVersion and ShortVersionString information inside the info.plist:
  <key>CFBundleShortVersionString</key>
  <string></string>

  <key>CFBundleVersion</key>
  <string></string>

so the system doesn't show any version information:

Thank you, fixed in 0ddaa58c78dd1274aceab028cc1d4ab46936995d


Avoid implementing a query language (#BigIssue)

#BigIssue
Noting Alex's statement in Slack

I don’t want to do is get to a point that requests to our query APIs expand to things like “can i do where statements that select data from other tables”, etc and we effectively implement our own query language.  To me, I like the idea of an API layer being focused on a faceted sort of search methodology - let me do some boolean operations and filtering on a well defined set of fields.  If those APIs can return either the results or the SQL it generated, users who want more power can use that SQL template to further refine things.

Examples explored here (see #13 and #14) begin to identify that the expressivity of a full query language is necessary for even queries which, from a domain/scientific perspective, are quite basic. Creating issue here to give visibility to this question, linked to specific examples.

We are working towards implementing granularity on what can be searched and what can be returned in future releases.  Not implemented in Release 2.  Thank you for the feedback.

In addition to the granularity question the MIDRC notebook (to be committed shortly) highlights another example where it is easier to do something via SQL than via a Q query. Mainly because SQL has the count function. It is conceivable how to do it in Python on the returned json from a Q query but the above option is simpler.
A count function could be implemented in Q. It would also need some equivalent of group by. This comes back to Alex's instinct to avoid implementing a query language when there are good xQL's which provide this functionality and have a wide user base that knows how to use them, plus supporting toolsets.

@ianfore, thanks for your feedback.  We have implemented a production release where you are a beta-tester.  Please give us your feedback on that.


LogLevelModifier

An IIQ plugin which allows modifying log4j log levels of all OOTB and custom java classes. This can be particularly useful during development and debugging and is mostly for developers.

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


PWA-186 fix unit tests suite

Pull Request Test Coverage Report for Build 485

0 of 0 (NaN%) changed or added relevant lines in 0 files are covered.
30 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.8%) to 38.399%

Files with Coverage Reduction
New Missed Lines
%

pages/ProductGallery/components/ZoomPanSlider/index.jsx
11
0.0%

pages/Product/components/ImageSlider/index.jsx
19
0.0%

Totals

Change from base Build 483:
-0.8%

Covered Lines:
1850

Relevant Lines:
4597

💛  - Coveralls


Fix for #259 - interactive

This fix adds labels in interactive mode using almost identical code as used in non-interactive mode. The labels don't always look great as depending on the units used the number component of the label can have many digits, causing the label to wrap around the whole circle. However, perhaps this fix is sufficient for this release.

Manual testing required.


RSpec/EmptyHook auto-correct creates syntax error

Example:
RSpec.describe Foo do
  describe 'foo' do
    let(:foo) { 'bar' }

    after do
    end

    it 'does some test' do
      var = true
      expect(var).to eq false
    end
  end
end

Running
rubocop spec/foo_spec.rb --only RSpec/EmptyHook -a

creates:
RSpec.describe Foo do
  describe 'foo' do
    let(:foo) { 'bar' }    it 'does some test' do
      var = true
      expect(var).to eq false
    end
  end
end

which is syntax error.
❯ rubocop -V
1.21.0 (using Parser <IP_ADDRESS>, rubocop-ast 1.11.0, running on ruby 3.0.2 x86_64-darwin20)
  - rubocop-performance 1.11.5
  - rubocop-rails 2.12.2
  - rubocop-rake 0.6.0
  - rubocop-rspec 2.4.0

It was fixed in #1176, but not released on RubyGems yet.
I suggest you to use the version from git.
Sorry for the trouble.

Perhaps it's time for a release :)


Update TypeNameResolver.cs

check name if null before using it

@msarilar this LGTM thank you for submitting this. Mind signing the Elastic CLA https://www.elastic.co/contributor-agreement so they we may pull these bits in?

Ported to 6.x and 5.x. Thanks for the PR @msarilar 👍


WARNING:root:StreamedResource not available without bundle

UnityPack should support extracting FSBs from an .assets file as long as there is a .resources file with the same name in the same directory.
eg.
sharedassets0.assets
sharedassets0.resource
sharedassets1.assets
sharedassets1.resource

The Unity script for QuickBMS takes this into account, I don't see why extract.py couldn't.

I don't think I want to rely on naming, same-directory logic and such. But I'd be fine with it looking in the environment instead of the bundle itself; unityextract can load all the files you give it to the environment before attempting to extract anything (I think it might already do that)


Open gitpod in a new tab

What would you like to share?
Could we make the gitpod button open the app in a new tab?
Additional information
No response

I don't believe this is possible.
GitHub removes certain attributes from anchor tags when it renders and target is one of them.
See this StackOverflow post

I don't believe this is possible.
GitHub removes certain attributes from anchor tags when it renders and target is one of them.
See this StackOverflow post

👍🏻 Will close this issue.


WIP, Build Package Updated 4x

Extension of PR #459 NPM & ReadMe Updates
Changes:

ReadMe

NPM script updates
Unit testing

NPM

Script aliases for Grunt tasks
NPM Ignore for cleaner install

Bower

JSON ignore, for cleaner install

Grunt

Less copy as part of the dist/distribution

Remaining work, less files need to be properly aggregated into dist

@jeff-phillips-18 @dtaylor113 need input on the last piece of the build updates. It's related to how we should be handling line 1 in angular-patternfly.less once it gets distributed...
@import "../node_modules/patternfly/dist/less/color-variables.less";

Up for alternatives, especially if there's something like Webpack that may benefit from another layout. A couple of proposals...
Either
We could handle it similar to how base Patternfly handles it by including a dist/less/dependencies/patternfly/less/[single related less file here] directory and updating angular-patterfly.less to appear as:
@import "patternfly/less/color-variables.less";

Or being a little bit nicer by updating the path for immediate consumption
@import "dependencies/patternfly/less/color-variables.less";

Or simply flatten the structure down to
@import "color-variables.less";

An advantage, immediately able to consume the less
A disadvantage, if we ever needed to clean up again we may be unintentionally creating a downstream dependency
A disadvantage, if we try to include all less dependencies, instead of the single color-variables.less, from Patternfly we may end up with a larger directory than intended

Or
We could we could simply leave the reference as is, pointing at node_modules:
@import "../node_modules/patternfly/dist/less/color-variables.less";

A disadvantage, this ignores Bower consumption

We should consider using a less import syntax that does not require the consumer to specify complex less build paths when they choose to customise the angular-patternfly CSS.

Readme updates for consuming Less to be added.

see PR #475

Apparently I closed this when I delete the b.0-dev branch.  I assume it's been superseded by #475, otherwise feel free to reopen it.