Couch Requests

I will create the hosting and surfing tabs of the messages page.

Done? Feel free to reopen if there are still some small things to tidy up.


Fix wrong padding in widgets list

Related to #13200
This PR fixes the wrong padding of widget element in Widgets list
Acceptance

Go to any of your created maps
Click on the widget tab
Check that the wrong padding is gone

It should look like this:

retest this please

Looks good on ded11 as well 👍


Injecting environment variables into docker

Adding necessary environment variables to docker backend container with 'docker-compose.yml' file. They need to be included in '.bashrc' file and need to be exported to work properly.

.bashrc file only makes it more convienient since this file is run every time bash shell is opened (which might not always be the case). This is why this file is not ideal to store such environment variables. It is easier and more explicit to put them an .env file where you run the docker-compose and docker will automatically export them for you for the command.


refactor(SQS): switch to a more performant JSON lib

Closes: #XXX
What is the purpose of the change
Based on profiling, JSON unmarshaling is a big bottleneck in SQS. Accordingly, we switch the library to a more performant one - https://github.com/json-iterator/go
Based on the new profile, the overall share of the unmarshaling is not as large as before.
Additionally, load testing shows an improvement.
Old load testing:

New load testing:

Old profile (incomplete):

New profile:

Testing and Verifying
This change is already covered by existing tests, such as (please describe tests).
Documentation and Release Note

[ ] Does this pull request introduce a new feature or user-facing behavior changes?
[ ] Changelog entry added to Unreleased section of CHANGELOG.md?

Where is the change documented?

[ ] Specification (x/{module}/README.md)
[ ] Osmosis documentation site
[ ] Code comments?
[ ] N/A

Should we make an issue to use this in the SDK for import/export genesis?

https://github.com/cosmos/cosmos-sdk/issues/18704


DRILL-3340: Add operator metrics registry for metric definitions

Display metrics as a table within an operator profile panel
Rename FragmentStats#getOperatorStats to newOperatorStats

I am not a UI expert; where is the best place to present operator metrics as a table in our query profile page?

I think the way metrics are displayed is fine, and it's definitely an improvement compared to no metrics at all.

I have 2 minor comments that need to be addressed, otherwise LGTM
+1


[FEATURE] Bar chart with full height background colour

The option to add a full height background colour to a bar chart using ChartJS (without the need to use a plugin) does not seem to be possible in the current version of the library.
Example screenshot has been added showing the intended appearance:

This has been raised as a question in a previous issue that was raised, but still requires a work-around to implement this feature (https://github.com/chartjs/Chart.js/issues/4791).
Using the 'stacked' property requires additional work to hide the tooltip that is displayed when using a secondary bar for the background of each column, and to calculate the overall length of the chart when using two bars when stacked.
Having a property that is part of the standard ChartJS library that would apply a full height background behind each bar chart, would be a useful additional feature. This would also avoid the need to use 'stacked' or third-party plugins (as raised in a number of previous issue tickets) to achieve a relatively simple UI feature.
Currently using Chart v2.7.1

The reason that I tagged the original issue as 'implement as plugin' is that this feature seems like a very specific request.
It could also have a lot of complexity that would affect the size of the library. For instance, when there are multiple stacks, they would need to be filled individually. I think there would also need to be some config settings to control how this behaves for negative bars and charts that have both positive and negative bars. Having this code in a plugin would allow faster releases of fixes and only increase the size for users who need these features.
CC @simonbrunel @benmccann what are your thoughts here?

I'd probably lean towards saying this is a plugin as well

Closing since there is agreement that this should be a plugin


Chatbot: bot-generated responses

Acceptance criteria
Everything except CSS (Nemo, Buddy)

The backend algorithm is that if semantic similarity doesn't match it to a human-written response, then default to a bot response
The "Bot-generated response" tag with tooltip is shown (copy pending)
The citations should be referenced as (a) number(s) at the end of the paragraph (I think that's how it works) (if taking code from current bot, just take off brackets)
The citations themselves should include

Number with color
Title
Author
Type of post with icon (actually let's discuss feasibility here because I don't know if this is in the database)

links out to current link in a new tab (like it currently does)

Make the citations pretty rainbow colors (whatever backend is required here)

CSS (Archana, Melissa)

Visuals should match design including typography, the superscript inline references, the dividing line from the citations, the colors of all the references/citations, and the typography etc. of the citations

Links

bot responses: https://www.figma.com/file/qqfeYAh6Z7QdyJXsQjIUfh/Stampy?type=design&node-id=2197%3A6641&mode=dev&t=9lrQdhpZsKoF1qGs-1
🌈: https://www.figma.com/file/qqfeYAh6Z7QdyJXsQjIUfh/Stampy?type=design&node-id=3488%3A8359&mode=dev&t=9lrQdhpZsKoF1qGs-1

Note: make sure multiple paragraphs show up


[Feature Request] Option to only unconceal the current line

Currently, when I enter insert mode, the whole file changes the conceal level. What would be better is if only the current line changed the level of conceal, or perhaps the current "context", e.g. code block.

The obsidian style. Would be great if we could have this feature

Last time I tried it was very VERY buggy.
I am going to try again later to see if I can do something.

Maybe this feature better suited to be in Neovim core?

Maybe this feature better suited to be in Neovim core?

Neovim core already has this. You can check it by setting the conceallevel to 2.
The only issue is it doesn't hide virtual text. So things like inline code, link have the same text shown twice.

I found a workaround for this, at least for markdown wiki links and md links.
I placed this in my after/ftplugin/markdown.lua
vim.api.nvim_create_autocmd("CursorMoved", {
	buffer = vim.api.nvim_get_current_buf(),
	callback = function()
		if vim.fn.mode():sub(1, 1) == "i" then
			return
		end
		local cursor = vim.api.nvim_win_get_cursor(0)
		local line = vim.fn.getline(cursor[1])
		local is_wiki_link = line:match("%[%[.*%]%]")
		if is_wiki_link then
			vim.o.concealcursor = ""
			return
		end
		local is_md_link = line:match("%[.*%]%(.*%)")
		if is_md_link then
			vim.o.concealcursor = ""
			return
		end
		-- local is_todo = line:match("- %[.%]")
		-- if is_todo then
		-- 	vim.o.concealcursor = ""
		-- 	return
		-- end
		vim.o.concealcursor = "n"
	end,
})

You can use the new options configuration option to make it unconceal text on the current line.

Use this in your config.
options = {
    on_enable = {
        conceallevel = 2,
        concealcursor = ""
    },
    on_disable = {
        conceallevel = 0,
        concealcursor= ""
    }
}

Is this still valid? I've tried the following, but it doesn't seem to be working for me:
	require 'markview'.setup {
		options = {
			on_enable = {
				conceallevel = 2,
				concealcursor = ""
			},
			on_disable = {
				conceallevel = 0,
				concealcursor= ""
			}
		}
	}

Even when I manually :set conceallevel=0 or :set concealcursor="", it flashes for a second, then instantly switches back to full conceal.

Is this still valid? I've tried the following, but it doesn't seem to be working for me:
	require 'markview'.setup {
		options = {
			on_enable = {
				conceallevel = 2,
				concealcursor = ""
			},
			on_disable = {
				conceallevel = 0,
				concealcursor= ""
			}
		}
	}

Even when I manually :set conceallevel=0 or :set concealcursor="", it flashes for a second, then instantly switches back to full conceal.

options has been renamed to callbacks. Use this,
require 'markview'.setup {
    callbacks = {
        on_enable = {
            conceallevel = 2,
            concealcursor = ""
        },
        on_disable = {
            conceallevel = 0,
            concealcursor= ""
        }
    }
}

See default values here.

options has been renamed to callbacks. Use this,

Hi @OXY2DEV, I’m trying to have the cursor line unconcealed, tried both what you suggested above and also functions as callbacks but only my on_disable is called:

lazy setup opts

  {
    "OXY2DEV/markview.nvim",
    enabled = true,
    -- ft = "markdown",
    lazy = false,
    opts = {
      callbacks = {
        on_enable = function(_, window)
          print("enabled")
          vim.wo[window].conceallevel = 2;
          vim.wo[window].concealcursor = "";
        end,
        on_disable = function(_, window)
          print("disabled")
          vim.wo[window].conceallevel = 0;
          vim.wo[window].concealcursor = "";
        end,
      }
    },
  },

I’m trying to have the cursor line unconcealed

When are you trying to have them unconcealed?

If you are trying to have the line under cursor always unconcealed you need to use the on_mode_change callback. See the wiki

When are you trying to have them unconcealed?

I’m trying to have similar behavior to what is displayed in your screen recording above where the cursor line is unconcealed when the cursor moves, similar to the default behavior of render-markdown.

If you are trying to have the line under cursor always unconcealed you need to use the on_mode_change callback too

Maybe I’m missing something, but the mode doesn’t change when I’m moving the cursor on normal mode, I want the current line to show the original text only without any decorations, shouldn’t the trigger for this happens when the cursor moves?

I’m trying to have similar behavior to what is displayed in your screen recording above

You can simply just do,
hybrid_modes = { "n" }

No need to use the callbacks.

I’m trying to have similar behavior to what is displayed in your screen recording above

You can simply just do,
hybrid_modes = { "n" }

No need to use the callbacks.

Ty @OXY2DEV! this is exactly what I was after :)

Hybrid mode is interesting but, what if we want to unconceal only the current line while in Insert mode?
I'm trying some options but didn't quite work for that purpose yet.
Setting conceallevel=2 doesn't seem to do the trick as well.
Even tho @OXY2DEV  mentioned this to be quite buggy, is this too much buggy? I was trying to give it a shot.

Hybrid mode is interesting but, what if we want to unconceal only the current line while in Insert mode?

I will probably add an option to add this.

I'm trying some options but didn't quite work for that purpose yet.

Because it's kinda hard-coded on the main branch.

Setting conceallevel=2 doesn't seem to do the trick as well.

Because this only affects conceals.

Even tho @OXY2DEV mentioned this to be quite buggy, is this too much buggy?

The initial version was buggy because I couldn't get the lines numbers to not show the decorations in.
I was trying to get similar behavior as render-markdown but after testing it, it got in the way more than it helped(which kinda beats the point of having the feature).
It should be easy to re-implament now though.
I will give it a try tomorrow.

Cool .. thanks!

@rodhash I have added this feature in the dev branch.
So, it should be available in v25.
If you would like to test it out put this in your config,
preview = {
  linewise_hybrid_mode = true
}

Thank you for the quick development but for me it still unconcealing the whole file.
I have dev branch installed:

My config file:

      require("markview").setup({
        linewise_hybrid_mode = true
      })

Am I missing something?

Am I missing something?

You first need to enable hybrid mode.
I am assuming you want to use it in [i]insert mode. This is what you need to use.
require("markview").setup({
  preview = {
    modes = { "n", "no", "c", "i" },
    hybrid_modes = { "i" },
    linewise_hybrid_mode = true
  }
});

Apologies for not making it clear.

Hey, no worries!
Even tho "dev" branch worked before this time I got an error trying to install it:

Interesting that, even with that error it seems to be working and unconcealing only current line.

Even tho "dev" branch worked before this time I got an error trying to install it:

That's because I forgot to remove the old sections of the help file.

Interesting that, even with that error it seems to be working and unconcealing only current line.

Yes, this error doesn't affect the plugin itself and rather is an issue with opening the help files for the plugin.

Thank you!!! I've been waiting a long time for a plugin like this!
On dev, with the following config, it's nearing perfection!
require 'markview'.setup {
	preview = {
		modes = { "n", "no", "c", "i" },
		hybrid_modes = { "i", "n" },
		linewise_hybrid_mode = true
	}
}

What's stopping it from reaching perfection?

Haha! If you could show images inline like hologram.nvim, it would be amazing. But you can probably wait until more mainstream terminal support at least one of the competing graphics protocols (Kitty, iTerm2, Sixel). And perhaps there's a way to make hologram.nvim and markview.nvim work together, to avoid duplicating the work.
Also, text seems to jump right by one character then back again when revealing it.
See the following consecutive frames of a recording:

Also, soft-wrapped lists don't maintain their indentation:

Also, conceal gets disabled when my autocompletion appears:

All that said, this is still the best Markdown plugin for Neovim! Thank you!

If you could show images inline like hologram.nvim

I personally don't want add extra dependencies(unless absolutely needed) as testing them for potential bugs is impossible in some cases.
Unfortunately, image rendering is super slow. It takes ~2s just to load a 200kb image so testing it is not ideal.
I will wait for image support in Neovim(this is being discussed by the contributors). As that would make maintaining the feature easier.

Also, text seems to jump right by one character then back again when revealing it.

This is something I can try to fix. I originally didn't do this as iterating over a lot of nodes may not be ideal. I will see if I can fix it.

Also, soft-wrapped lists don't maintain their indentation:

This is a sacrifice I had to make as otherwise inline codes & $math * symbols$ get stretched. There's also no good way to determine where a line is wrapped. So, counting it character by character could be the cause of lags.

Also, conceal gets disabled when my autocompletion appears:

Unfortunately, I couldn't reproduce this. I use nvim-cmp. Unless your mode changed during completion(this will happen 3 times whenever you use snippets, and 2 times when using some completions).

EDIT: OSC8 URL support would be cool

Some terminal do provide something similar to this. For example if you use xfce4-terminal you can hover over links and they act like the links in the browser.
I don't want to use mouse events(as it could potentially break stuff and I don't enough confidence that my code won't have bugs, I have seen the creator of NvChad heavily use this but it gets very laggy for me when using this approach).

Btw, this is what I was talking about relating to links.

Regarding links, if it's working for you in xfce4-terminal, maybe it's just my terminal (Tried in Windows Terminal and WezTerm) or my Neovim version (v0.10.2) which is lacking. (Are you running a development version of Neovim?)
I did find one more glitch. Inline code over hard line breaks doesn't conceal properly:

Are you running a development version of Neovim?)

I can't. The development version for 0.11 added a new dependency and unfortunately, this dependency isn't available in Termux.
So, unless someone patches that for Termux. I won't be able to use development builds. Also, I will have to wait for binaries to release before installing newer versions of Neovim(if the dependencies aren't available).

I did find one more glitch. Inline code over hard line breaks doesn't conceal properly:

That might have been caused by a typo on my end.
I will fix that(along with some other minor bugs).

Thanks for the tip about nvim-cmp. I was still on the deprecated predecessor nvim-compe. Switching to nvim-cmp has fixed the flicker when autocompletion activates.


FIX: Resolve deployment issues

Related to enthought/terraform#126
Resolves some of the following errors:
* module.brood_staging_stack.aws_security_group.cluster_group_on_specified_vpc: 1 error(s) occurred:

* aws_security_group.cluster_group_on_specified_vpc: Error creating Security Group: InvalidParameterValue: Invalid security group name. Valid names are non-empty strings less than 256 characters from the following set:  a-zA-Z0-9. _-:/()#,@[]+=&;{}!$*
        status code: 400, request id: d7b52495-463a-4181-97b7-090bcaef6d33
* aws_security_group.brood_staging_stack_on_main_vpc (destroy): 1 error(s) occurred:

* aws_security_group.brood_staging_stack_on_main_vpc: DependencyViolation: resource sg-a27df3eb has a dependent object
        status code: 400, request id: d3fccb7a-6632-427d-a455-eeac94b60e79
* module.brood_staging_stack.aws_cloudformation_stack.docker_cluster: 1 error(s) occurred:

* aws_cloudformation_stack.docker_cluster: Creating CloudFormation stack failed: ValidationError: Parameter 'EncryptEFS' must be one of AllowedValues
        status code: 400, request id: 81c7c3da-7586-11e8-912e-41bf444d515e
* module.brood_secret_store.aws_iam_policy.secret_retrieval_policies: 1 error(s) occurred:

* aws_iam_policy.secret_retrieval_policies: Error creating IAM policy brood_staging_secret_retrieval: MalformedPolicyDocument: Statement IDs (SID) must be alpha-numeric. Check that your input satisfies the regular expression [0-9A-Za-z]*
        status code: 400, request id: 81bd8a1d-7586-11e8-861f-4f204f46d212

Interpolated the stack name into a variable with a format string that
had been forgotten - resolves error creating security group
Converted "yes"/"no" boolean into "true"/"false" for encrypt efs -
resolves error in stack for EncryptEFS parameter
Converted _ to - in aws_iam_policy names for secret retrieval -
resolves MalformedPolicyDocument

Not sure how to resolve the issue of the dependent resource. I am hoping
TF's parallelism will allow that to work on a secondary run, since it
retries quite a few times before it decides it didn't work.

@dpinte bump?


Compilation error on linux

You recently added a function pfd::settings::available() which is very nice, but it does not compile on Linux.
The reason is that the static method is calling a non static method. That method is calling a method of another class which is unaccessible (and needs m_async initialized).

Thanks. I was in the middle of refactoring this and forgot to test the Linux part. It should be OK again.


[REQUEST] Can i create sortable by Relation ?

I have a job with many views.
In grid, I have been join relation and get the view. Can I add sortable for that column

It's impossible to do order by query on related column througth one-to-many relation.
One solution is, add a column views_count in current table, so you can make it sortable as other columns.


Tests for this library?

This library doesn't appear to have automated tests to verify that it functions as it should?

That's correct. It does not, but should.


AUI-1894

Hey @mairatma,
Attached is an update for http://issues.liferay.com/browse/AUI-1894.
Please let me know if you have any questions.
Thanks!

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


Fe-homework-12

Screenshot
LINK to design  ::: Drawing LINK
component breakage

UI LAPTOP

UI TAb

UI Mobile

Drift video
Watch this video

Metric
Value

alert_status
:white_check_mark: OK

bugs
0

code_smells
0

reliability_rating
A (0 Bugs)Note: A being best, E being worst

security_rating
A (0 Vulnerabilities)Note: A being best, E being worst

vulnerabilities
0


Use SharedSQLContext For Consistency

What changes were proposed in this pull request?
Use SharedSQLContext For Consistency
Otherwise, we'll encounter below warning:
Multiple running SparkContexts detected in the same JVM
How was this patch tested?
Unit test passed

merge it since only changed tests.


Fix for requriments.txt and please add LICENSE.

Introduction
The current requriments.txt is invalid. The normal opensimplex module does not work with Numba. Installing opensimplex[numpy] would fix all problems. Also having the dependencies without their version would have a possibility of incompatible modules being installed and thus the error ...
$ python main.py
pygame 2.1.2 (SDL 2.0.18, Python 3.10.2)
Hello from the pygame community. https://www.pygame.org/contribute.html
RuntimeError: module compiled against API version 0xf but this version of numpy is 0xe

requriments.txt fix
pygame==2.5.0
moderngl==5.8.2
numba==0.57.1
PyGLM==2.7.0
numpy<1.25,>=1.21
opensimplex[numpy]==0.4.4

LICENSE please
Also I recommend adding a LICENSE file, this tell people what they cant and can do with your code. Currently they are legally not allowed to do anything, so following your video and copying the code would be breaking the law (even if you want them to do so). https://choosealicense.com/ can help you to choose a LICENSE that you want. It is best practice to put a file called LICENSE inside the repository root. Then GitHub will parse the file and label the repository appropriately.

I had to upgrade pygame in order make it work, but I still get this error: Could not create GL context: GLXBadFBConfig pygame. Do I need to upgrade something else?

I'm not sure what you need but you do need a GPU (separate or integrated) that supports OpenGL 3.3 core profile. Most GPUs should support OpenGL 3.3 core profile. Pygame 2.5.0 works for me.

Ah alright, I'm trying to run this on my raspberrypi,but I have OpenGL 2 instead of 3.
I understand, thanks

Are there any other Python libs for OpenGL 2 that i could use for the raspberry pi?

@Pludam You can use the same libraries but you need to change this so it's something like MAJOR_VER, MINOR_VER = 2, 0. Also you may need to remake the shaders. I'm not an expert on Open GL 2 shaders.

I am currently getting this warning when installing opensimplex with numba here 🤔
WARNING: opensimplex 0.4.4 does not provide the extra 'numpy'


Updating support policy for Azure Storage Accounts

After an escalation today there is a need to update and clarify the support for the wasb:// interface when accessing azure storage. The previous version was unclear and had errors in examples.

@jrowlandjones : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Hi @jrowlandjones - Contributors who work in the Product Manager role should open pull requests in the private repository for advanced quality validations and staging (you also can sign off directly in the private repo). To edit an article in the private repo from within the documentation, after you select Edit on an article page,  add “-pr” to the URL. We’ll leave this PR for review in the public repo, but would you make future article updates in the private repo?  Thanks!

Thank you Kristine,
Duly noted and will do this in future.
Did you let the change through as-is? I can't see the PR anywhere.
Kind Regards, JRJ
Get Outlookhttps://aka.ms/qtex0l for iOS

From: Kristine Toliver<EMAIL_ADDRESS>Sent: Tuesday, June 30, 2020 8:16:04 AM
To: MicrosoftDocs/sql-docs<EMAIL_ADDRESS>Cc: James Rowland-Jones<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/sql-docs] Updating support policy for Azure Storage Accounts (#5062)
Hi @jrowlandjoneshttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjrowlandjones&data=02|01|jrj%40microsoft.com|041c86a7511241b9d44008d81d088264|72f988bf86f141af91ab2d7cd011db47|1|0|637291269668862623&sdata=STiFHb9YbB44qyveae6rkfFdADIYE503t2Pa%2FPUQF6E%3D&reserved=0 - Contributors who work in the Product Manager role should open pull requests in the private repository for advanced quality validations and staging (you also can sign off directly in the private repo). To edit an article in the private repo from within the documentation, after you select Edit on an article page, add "-pr" to the URL. We'll leave this PR for review in the public repo, but would you make future article updates in the private repo? Thanks!

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fsql-docs%2Fpull%2F5062%23issuecomment-651859761&data=02|01|jrj%40microsoft.com|041c86a7511241b9d44008d81d088264|72f988bf86f141af91ab2d7cd011db47|1|0|637291269668862623&sdata=GhATtWOClEvJM9ayvHPs441LKraow%2B7qN9eYU%2B0wjzQ%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACQKR6RYS7637XFRLNL4NY3RZH6TJANCNFSM4OLXUH2Q&data=02|01|jrj%40microsoft.com|041c86a7511241b9d44008d81d088264|72f988bf86f141af91ab2d7cd011db47|1|0|637291269668872606&sdata=M4%2BFJk8tapP4W5LQr%2F6xXr5RGyNvrqkO8FzlmYiJrKc%3D&reserved=0.

Thank you @CarlRabeler and @ktoliver for the guidance and support.


skylark: zip: support iterables of unknown length

Hi Alan, thanks for very detailed explanation of the issues involved. And I though it would be a simple change ;) As you suggested I am going to change my first PR to use defer to call Done and will re-implement this PR to materialise a list (in a few days).

Closing in favour of https://github.com/google/skylark/pull/24


WV: Updated query to match new variable names from WV's API

It looks like they changed the names of some of their variables and they moved first/both doses into the same table, 'COVID_Vaccine'. I think this fixes it.

@sglyon 🙏


Terra time input

Summary
The terra-time-input component is an input for entering time. During time entry the value is masked to conform to the time format.
Translations are currently hard-coded. Will update translations once we have a strategy to get the translated strings (i.e. using react context).

This has been deployed to gh-pages branch.


Feature request: Inapp screenshots

Greetings, your program is nearly perfect solution as SMTP to Telegram gateway.
I use it in docker together with https://github.com/gogap/go-wkhtmltox and https://github.com/ncarlier/webhookd
Bash script (70 lines) does all the job.
Could you integrate go-wkhtmltox in you API to make screenshots (and even pdf) directly without extra overhead?
It exists in form of go library.

Hi @baiomys. I'm glad to hear you have a nearly perfect solution for your gateway.
Regarding native screenshot support (which is I think what you are asking for) - No sorry, that is just not possible, at least not possible without the reliance on many third party tooling which Mailpit then becomes dependent on, meaning it would no longer just be a single self-contained binary.
To generate things like screenshots a web rendering engine must be used (often Webkit/Chromuim or Gecko/Firefox) . This is why utilities such as wkhtmltopdf (which gogap/go-wkhtmltox uses) all require thinks like the QT webkit engine installed which they then call in the background. These engines require a whole series of graphical dependencies to be installed too (in the Docker image).
If I was to bundle all of that into the Mailpit Docker image, then:

the Docker image would increase from 10MB to a 500MB+ just contain the requirements
the Mailpit binary would not work on all platforms without having all those system dependencies installed
the Mailpit binary would not longer be a static binary due to the reliance on system libraries (C/C++)
the Mailpit binary would become much bigger
there would very likely be licencing issues when you consider all the dependencies

It exists in form of go library.

I'm curious as to which library you mean, but I'm pretty sure it is just a wrapper to use something like wkhtmltopdf under the hood, which then brings us straight back to the list I posted above.

Thank you for quick response, it's late at night in NZ now I guess. =)
I got you point, size and portability matters.

It is getting late - but that's sometimes the best time to work on open source ;-) Exactly, size and compatibility matter a lot.


Add networking-extensions-approvers as CODEOWNERS

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

v1.0.0
GitHub release

Your semantic-release bot :package::rocket:


CI detects model changes w/o migrations

Coverage remained the same at 62.186% when pulling ce4c13a8889f9a95470254576c39f5a79f42a8e4 on 補migrations into 8008680ecca420886e826119a4c181a94e94e8d4 on master.

Coverage increased (+0.3%) to 62.463% when pulling ce4c13a8889f9a95470254576c39f5a79f42a8e4 on 補migrations into 8008680ecca420886e826119a4c181a94e94e8d4 on master.


Memory leaks in component Table

Actual Behavior
After I did the scenario (that below) a couple of time, I see the JS heap size and count of DOM Nodes grow dramatically
Reproduce Scenario (including but not limited to)
To reproduce the scenario in your example (https://opensource.adobe.com/coral-spectrum/examples/#tabview)  and switch between component table page and tab list page(for example) .
Browser name/version/os (ie Chrome Version 62.0.3202.94 (Official Build) (64-bit) MacOS)
Chrome Version 89.0.4389.114 (Official Build) (64-bit) Windows
Coral Spectrum version
https://opensource.adobe.com/coral-spectrum/examples/#table
Screenshots (if applicable)

fyi @Pareesh


MSVC: suppress warning 4146

suppress this warning
warning C4146: unary minus operator applied to unsigned type, result still unsigned

Looks good, merged!


Various changes

Update image for deployer and debug job
Add DataStage Enterprise

We now do not directly push to techzone branch. All PRs are made to development branch then development branch is merged with techzone. This is done to keep both the branches in sync.
I have made these changes in development and willbe pushing them to techzone shortly.
PR : https://github.com/IBM/CPDemoFramework/pull/186


remove generated ReducerProject_IncludeParser.js from repo

Shouldn't have been committed in the first place.

Codecov Report

Merging #1110 (d3788fb) into develop (7d6ffec) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop    #1110   +/-   ##
========================================
  Coverage    59.31%   59.31%
========================================
  Files           83       83
  Lines         4528     4528
========================================
  Hits          2686     2686
  Misses        1842     1842

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Error when copying a WAF policy between two clusters

Describe the bug
When we try to copy a WAF policy between two AVI clusters, we get the following error:
$ python3 clone_vs.py -c C1 -dc C2 -t Tenant -2t Tenant generic wafpolicy Repo Repo-clonetest
clone_vs.py version 2.0.2
Password for admin@C1:
Password for admin@C2:
Creating source API session to C1...OK!
Creating destination API session to C2...OK!
Detected API version 22.1.2. Reconnecting.
Creating source API session to C1 (22.1.2)...OK!
Creating destination API session to C2 (22.1.2)...OK!
Trying to clone object of type wafpolicy with name Repo [Tenant] to Repo-clonetest [Tenant]...
Unable to clone wafpolicy "Repo" as "Repo-clonetest" (400:{"error": "Invalid configuration: WafPolicy application signature provider not found."})
=> Unable to clone wafpolicy "Repo" as "Repo-clonetest"

Copying the WAF policy within the same AVI cluster works without problems:
$ python3 clone_vs.py -c C1 -dc C1 -t Tenant -2t Tenant generic wafpolicy Repo Repo-clonetest
clone_vs.py version 2.0.2
Password for admin@C1:
Password for admin@C1:
Creating source API session to C1...OK!
Creating destination API session to C1...OK!
Detected API version 22.1.2. Reconnecting.
Creating source API session to C1 (22.1.2)...OK!
Creating destination API session to C1 (22.1.2)...OK!
Trying to clone object of type wafpolicy with name Repo [Tenant] to Repo-clonetest [Tenant]...
OK!
New object of type wafpolicy created as follows:
Name: Repo-clonetest
Tenant: Tenant

Actions taken were:

Cloned wafpolicy "Repo" in tenant "Tenant" to "Repo-clonetest" in tenant "Tenant"

Reproduction steps
python3 clone_vs.py -c C1 -dc C2 -t Tenant -2t Tenant generic wafpolicy wafpolicy wafpolicy-clone
Expected behavior
I would have expected that you can copy a WAF policy not only in the same cluster, but also to other clusters.
Additional context
No response

Thanks for raising this. Please note that this script is provided as a example only and does not claim to be a fully-supported or comprehensive tool, especially for cross-cloud and cross-Controller scenarios (as noted in the README). However this particular issue will be addressed in a future update. Please check the development branch which should now have an update for this scenario (https://github.com/vmware/alb-sdk/tree/rc-clone_vs_refactoring/python/avi/sdk/samples).


Js bug with properties functions

Challenge Testing Objects for Properties has an issue.
User Agent is: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.
My code:

// Setup
var myObj = {
  gift: "pony",
  pet: "kitten",
  bed: "sleigh"
};

function checkObj(checkProp) {
  // Your Code Here
  if (myObj.hasOwnProperty(checkProp)){
  return myObj[checkProp];
  } else return "Not found";
}

// Test your code by modifying these values
checkObj("house");

hi @moromer90 there's something wrong with your code. if you need help solving JavaScript challenges you should ask first at JavaScript help room before posting a git hub issue.
happy coding 😄

No the code is OK. the problem is that your test-check-application doesn't differ caps in test-answears.
So if the result should be "Test fullfilled successfully" and you wrote "test fullfilled successfully" -> the program doesn't pass that reply as correct.

Hi @moromer90
Thanks for reporting, while your code is arguably correct, but unfortunately, this is expected.
As a developer, you are expected to return the exact output. This is very important in programming.
While both results look similar, they are actually NOT.
Closing this as not a bug.


CRCError: CRC validation failed

2023-11-28 19:46:13.096 WARNING (SyncWorker_3) [custom_components.solarman.solarman] Querying [512 - 597] failed with exception [CRCError: CRC validation failed.]
2023-11-28 19:46:13.595 WARNING (SyncWorker_3) [custom_components.solarman.solarman] Querying [512 - 597] failed, [1] retry attempts left
2023-11-28 19:46:13.676 WARNING (SyncWorker_3) [custom_components.solarman.solarman] Querying [512 - 597] failed with exception [CRCError: CRC validation failed.]

Any ideas ?

Inverter HYD-3000-EP
Firmware LSW3_15_270A_1.68
Serial 23XXXXXX41

edit: DEBUG logs
2023-11-28 20:01:58.055 INFO (SyncWorker_4) [custom_components.solarman.solarman] Connecting to solarman data logger <IP_ADDRESS>:8899
2023-11-28 20:01:58.060 DEBUG (SyncWorker_4) [custom_components.solarman.solarman] Socket setup completed... <socket.socket fd=41, family=2, type=1, proto=6,
laddr=('<IP_ADDRESS>', 55218), raddr=('<IP_ADDRESS>', 8899)>
2023-11-28 20:01:58.061 DEBUG (SyncWorker_4) [custom_components.solarman.solarman] SENT: a5 17 00 10 45 5b 00 7d fe f5 8e 02 00 00 00 00 00 00 00 00 00 00 00
00 00 00 01 03 02 00 00 56 c4 4c 33 15
2023-11-28 20:01:58.192 DEBUG (SyncWorker_4) [custom_components.solarman.solarman] RECD: a5 13 00 10 15 5b 83 7d fe f5 8e 02 01 07 7a 6d 00 32 15 00 00 1d bf
f8 64 01 90 02 00 03 1a 15
2023-11-28 20:01:58.192 WARNING (SyncWorker_4) [custom_components.solarman.solarman] Querying [512 - 597] failed with exception [CRCError: CRC validation fail
ed.]
2023-11-28 20:01:58.192 INFO (SyncWorker_4) [custom_components.solarman.solarman] Disconnecting from solarman data logger <IP_ADDRESS>:8899

Tried :

sofar_g3hyd.yaml
sofar_hyd3k-6k-es.yaml
sofar_wifikit.yaml
sofar_lsw3.yaml
solis_hybrid.yaml
hyd-zss-hp-3k-6k.yaml

Ok so the register are totally different between ES and EP.
Using registers from sofar2mqtt project seems to work.
I'll be creating a specific .yaml file for HYD-3k-6k-EP soon if this is confirmed.

My bad, I was using hyd-zss-hp-3k-6k.yaml when it worked. This is what should be used with HYD-3k-6k-EP.


When a user account is disabled and user tries to login needs to notify that his account is disabled

Suggested Labels
Affected : 5.8.0- alpha2
Severity: Major
Priority: Highest
Component: Account Locking
Type-Bug
Steps to Reproduce

Add a user and assign with a role
Add a resident IDP as admin user
Enable Account Disabling by Resident IDP > Account Disabling > check the box
Claims > list > http://wso2.org/claims > Account Disabled > check supported by default
Log into the mgt console as admin user and in normal users profile check the account disabled option.
Try to login to the system as user created in step 1

Observation
Carbon console will give a error message as
[2019-03-27 15:37:20,026] ERROR {org.wso2.carbon.core.services.authentication.AuthenticationAdmin} -  System error while Authenticating/Authorizing User : Account is disabled for user shanika123 in user store PRIMARY in tenant carbon.super. Cannot login until the account is enabled.
But when the user tries to log in the error message shown in the UI is as below
Login failed! Please recheck the username and password and try again.
Needs to prompt the message for the user mentioning that his Account is disabled.

It can be done through customization as mentioned in [1]
[1] https://docs.wso2.com/m/mobile.action#page/87705502

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


Skips .files on Mac

I can't seem to successfully compile files prepended with . (.babelrc, .eslintrc.js, .env) on Mac.
I installed dir-archiver as a node package and run it as a npm script via CLI.
Failing command:
"build:prepare:src": "dir-archiver --src . --dest ./output.zip --exclude build dist .vscode .parcel-cache node_modules src/_dev",

This should exclude .vscode folder, but should inslude files such as those mentioned above.
node: node@16

My bad, ls -a was what I should use. Closing now.


Adding Channels - Welcome screen

For implementation, please use this design template:

channels are already there so I'm closing this one


Creating pass code

While creating passcode
case 1.) if a user creates a passcode and re-enters the passcode correctly happy path.
but in
Case 2.) If the User Enters incorrect passcode at the place of re-enter passcode and delete it and tries to enter again then the user has to select the box at the first step and enter the digit in the second step (which becomes 2 step process.)
https://user-images.githubusercontent.com/107177634/181436818-07b8b3a4-417a-41da-b2fb-489bb4c5654f.mp4

@akshay8551 is also working on the same issue of pledge and also we had this same issue in keeper we need to figure it out.

done


proposal: encoding/json, encoding/xml: support zero values of structs with omitempty

Support zero values of structs with omitempty in encoding/json and encoding/xml.
This bites people a lot, especially with time.Time.  Open bugs include #4357 (which has many dups) and #10648.  There may be others.
Proposal
Check for zero struct values by adding an additional case to the isEmptyValue function:
case reflect.Struct:
        return reflect.Zero(v.Type()).Interface() == v.Interface()

This will solve the vast majority of cases.
(Optional) Introduce a new encoding.IsZeroer interface, and use this to check for emptiness:
Update: I am dropping this part of the proposal, see below.
type IsZeroer interface {
        IsZero() bool
}

Visit this playground link and note that the unmarshaled time.Time value does not have a nil Location field.  This prevents the reflection-based emptiness check from working.  IsZero() already exists on time.Time, has the correct semantics, and has been adopted as a convention by Go code outside the standard library.
An additional check can be added to the isEmptyValue() functions before checking the value's Kind:
if z, ok := v.Interface().(encoding.IsZeroer); ok {
        return z.IsZero()
}

Compatibility
The encoding.IsZeroer interface could introduce issues with existing non-struct types that may have implemented IsZero() without consideration of omitempty.  If this is undesirable, the encoding.IsZeroer interface check could be moved only within the struct case:
case reflect.Struct:
        val := v.Interface()
        if z, ok := val.(encoding.IsZeroer); ok {
                return z.IsZero()
        }
        return reflect.Zero(v.Type()).Interface() == val

Otherwise, this change is backward-compatible with existing valid uses of omitempty.  Users who have applied omitempty to struct fields incorrectly will get their originally intended behavior for free.
Implementation
I (@joeshaw) have implemented and tested this change locally, and will send the CL when the Go 1.6 tree opens.

The empty struct approach is implemented in CL 13914 and the IsZeroer interface is implemented in CL 13977.
In order for them to be reviewable separately they conflict a bit -- mostly in the documentation -- but I will fix for one if the other is merged.

In the CLs @rsc said,

I'd really like to stop adding to these packages. I think we need to leave well enough alone at some point.

I see what he's getting at.  CL 13977, which implements the IsZeroer interface is clearly an enhancement and adds API to the standard library that needs to be maintained forever.  So, I am abandoning that CL and that part of the proposal.
However, I still feel strongly about omitempty with empty structs, and I want to push for CL 13914 to land for Go 1.6.
I use the JSON encoding in Go a lot, as my work is mostly writing services that communicate with other services, in multiple languages, over HTTP.  The fact that structs don't obey omitempty is a frequent source of confusion (see #4357 and its many dups and references, and #10648) and working around it is really annoying.  Other programming languages do not conform to Go's ideal "zero value" idea, and as a result encoding a zero value is semantically different in JSON than omitting it or encoding it as null.  People run into this most commonly with time.Time.  (There is also the issue that decoding a zero time.Time does not result in an empty struct, see https://github.com/golang/go/issues/4357#issuecomment-66071897 for background on that.)
I think it should be considered a bug that Go does not support omitempty for these types, and although it adds a small amount of additional code, it fixes a bug.

This proposal is marked as unplanned, yet the related bug report  #10648 is marked as go1.7.
Is it still being worked /thought on?

To my knowledge, it is not being worked on. Honestly this seems fairly low
priority and will likely miss Go 1.7.
On Sun, Mar 27, 2016 at 12:22 PM Jérôme Andrieux<EMAIL_ADDRESS>wrote:

This proposal is marked as unplanned, yet the related bug report #10648
https://github.com/golang/go/issues/10648 is marked as go1.7.
Is it still being worked /thought on?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/11939#issuecomment-202097961

OK.
This is more of a convenience than a priority indeed.
It can be a pain point when dealing with libs that don't support "embedded structs" as pointer though.

I wonder if a low-impact alternative to the IsZeroer interface would be to allow one to return an error called json.CanOmit (or similar) from an implementation of the Marshaler interface. That way the dev is in control of determining what constitutes a zero value, and it doesn't impact other code.
It's not a perfect solution, since one can't add methods to types defined in another package, but this can be worked around to a degree.
Taking the time.Time example:
type MyTime struct {
  time.Time
}

// Implement the Marshaler interface
func (mt MyTime) MarshalJSON() ([]byte, error) {
  res, err := json.Marshal(mt.Time)

  if err == nil && mt.IsZero() {
    return res, json.CanOmit // Exclude zero value from fields with `omitempty`
  }
  return res, err
}

I haven't looked into implementation, but on the surface it would seem like a low-overhead solution, assuming the only work would be to check if an error returned equals json.CanOmit on fields where omitempty was included.
Using errors as a flag is not without precedent in the standard library, e.g. filepath#WalkFunc allows one to return filepath.SkipDir to skip recursion into a directory.

@Perelandric I mentioned a possible sentinel error value in https://golang.org/cl/13914 but I didn't get feedback on the idea or an opportunity to implement it before the Go 1.7 freeze.  After Russ's comments on my original CL (and showing the unexpected difficulty in implementing this) I think that's the better way to go.

While it's clear that we can do this, it's not clear that we want to. I'd like to see a formal proposal document that weighs the advantages and drawbacks of this feature addition. In particular, I am concerned about compatibility and maintenance burden.

thanks Andrew. I worked on this a little bit at GopherCon. I will look into putting together a formal proposal.

@joeshaw we ran into this issue at my place of work and I'm eagerly awaiting your proposal. Feel free to contact me if you would like any help. Email is on my profile.

@joeshaw Is the proposal you're considering based on the sentinel object idea, or are you considering a different approach? Do you think you'll have time for this before the next release?

@Perelandric Yes, I think the sentinel object idea is the most straightforward way to go.
Other options include:

The IsZeroer interface (but I think this has potential backward compatibility issues)
"Backspacing" over objects that serialize to {} (but I think this requires too big a change to the JSON encoder code, and doesn't handle json.Marshaler implementers like time.Time)

I don't think I will be able to do this (proposal + implementation) before Go 1.8.  If someone else wants to take it on for 1.8, I will gladly pass along my knowledge and partial implementation.

Thanks @joeshaw. I created an implementation using the sentinel error for the encoding/json package and will start to work on the proposal in a bit. I think I'll focus primarily on this approach.
The Marshaler interface in encoding/xml is different from that in encoding/json, and seems as though a custom zero-value can already be established without needing to return anything special. Did you find that to be true?
After I make a little more progress, I'll post a link to a branch in case you, @albrow or anyone else wishes to review and contribute.
If you have any additional thoughts or info in the meantime, please let me know. Thank you!

Change of heart on this. If there's resistance to adding to packages, then this won't fly. Maybe someone else wishes to advocate for this.

Mentioned in one of the duplicate issues was the idea to let MarshalJSON return (nil, nil) to skip the field. Borrowing your earlier example:
type MyTime struct { time.Time }

func (mt MyTime) MarshalJSON() ([]byte, error) {
    if mt.IsZero() {
        return nil, nil // Exclude zero value from fields with `omitempty`
    }

    return json.Marshal(mt.Time)
}

In Go 1.7, returning nil is not a valid implementation for MarshalJSON and leads to "unexpected end of JSON input" errors. This approach doesn't require any visible change to the encoding package (not even adding an error value).
For what it's worth, I just intuitively wrote a MarshalJSON method like that, expecting a field to be omitted from the JSON output.

@pschultz That approach seems reasonable to me, but it can't be used with omitempty.
The reason you get that error is because the JSON encoder checks for the validity of the JSON coming out of MarshalJSON and the result of returning a nil byte slice is (something like) "key":,.  If returning a nil byte slice indicated that it should be omitted that'd be a different way to omit something from being encoded in the JSON than omitempt.  (That might be fine, it seems ok to me.)
The benefit of the error value is that it could fit in with the existing omitempty because you'd return something like []byte(""), ErrOmitEmpty and it'd obey omitempty yet still return a valid value ("") if not set.

@pschultz: A nil return wouldn't be able to be used as a flag for omitempty without causing undesired errors when omitempty is not present, since the implementation of MarshalJSON doesn't know when omitempty is actually there.
I don't know if having nil as an alternative to omitempty would be the best either. Seems like the user of a type should be the one deciding when it is omitted. IMO, the implementation of MarshalJSON should always return some useful representation, or an error when that's impossible.

It appears there are only two ways to have omitempty work with a struct.

Use a pointer to the struct where the pointer is nil rather than a zero value struct.
Implement Marshaler interface interface for the surrounding type to provide special handling for zero value structs

The later can be somewhat cumbersome to maintain field parity for large structures. The former means data is no longer contiguous and requires care for multi-threaded use.
I came to this by way of #9719, which isn't unlike the time.Time case. Using code like below it's possible to change the JSON output for nullable SQL types from "field":{"String":"","Valid":false} to "field":null, but in itself it can't affect omitempty.
// NullString represents a string that may be null.
type NullString struct {
	sql.NullString
}

// MarshalJSON implements the json.Marshaler interface.
func (x *NullString) MarshalJSON() ([]byte, error) {
	if x.Valid {
		return json.Marshal(nil)
	}
	return json.Marshal(x.String)
}

There are other reasons why that solution isn't ideal, including the way composite literals work with struct embedding, requiring: models.NullString{sql.NullString{String: "101", Valid: true}}.
So I'm likely going to scatter pointers all over my models and hope for the best. 😞
I do think this proposal can be simplified. Writing the code to check if a zero struct is empty or not isn't a huge problem (though it can be a bit cumbersome to maintain the field parity).
The issue is not having the ability to tell Marshal that a struct is empty without using a pointer. With that, a wrapper around time.Time or sql.NullString would do the trick, rather than implementing Marshaler on every surrounding type.

json.Marshal(nil) return [4]uint8 array (the string "null").  The function isEmptyValue() in json package (used by encode() functiion) can handle this special case and return true.

A simple patch:
@ -303,7 +303,9 @@ func (e *encodeState) error(err error) {

 func isEmptyValue(v reflect.Value) bool {
        switch v.Kind() {
-       case reflect.Array, reflect.Map, reflect.Slice, reflect.String:
+       case reflect.Array:
+               return v.Len() == 0 || (v.Len() == 4 && bytes.Equal([]byte("null"), v.Interface().([]uint8)))
+       case reflect.Map, reflect.Slice, reflect.String:
                return v.Len() == 0
        case reflect.Bool:
                return !v.Bool()

@bradfitz In https://github.com/golang/go/issues/10648#issuecomment-97983761 (which is now frozen), you said:

This bites me with time.Time{} values often. Camlistore has its own time.Time alias, just so we can do JSON differently.

Just wanted to check, is the named type you were referring to https://godoc.org/go4.org/types#Time3339, or did you have another one in mind (that I couldn't find)?

@shurcooL, yeah, that's its current home. It used to live in Camlistore's tree.
Note its implementation:
func (t Time3339) MarshalJSON() ([]byte, error) {
	if t.Time().IsZero() {
		return null_b, nil
	}
	return json.Marshal(t.String())
}

func (t Time3339) String() string {
	return time.Time(t).UTC().Format(time.RFC3339Nano)
}

@bradfitz I see, thanks. The reason I asked is because even with that custom type, it still doesn't get omitted when time is zero. It gets encoded as "null" and the field is included. See https://play.golang.org/p/oxEdyj5TFL.
Based on what you said, I expected it to have more of an effect (well, encoding as "null" helps a little, but I wanted it to be omitted entirely). Given that, it seems no better than using *time.Time with omitempty option, unless I'm missing something.

I created a simple library that patches isEmptyValue function in memory and declares Zeroer interface: https://github.com/lokhman/json-zeroer. Use it at your own risk :)

I'd really like to help out as this has also been a fairly large source of confusion in my organisation, but until this (or another) proposal is accepted it doesn't seem like there's anything to do?

@wayneashleyberry The work to be done here is to put together a proposal.
As I see it there are at least 3 different possible approaches:

Check for implementation of an interface, like IsZeroer.  @rsc wasn't too keen on adding to the stdlib for this, though.  (https://go-review.googlesource.com/c/go/+/13977#message-acaf24b35b85cf7f5fa7cef41a304888430b04bb)
Add a sentinel error value from MarshalJSON that would cause marshaling of the value to be skipped.  The implementation is a little tricky because by this point the key has already marshaled to the buffer, so some code reorganization would be needed.
Whenever any struct would marshal to {}, omit it.  This is an idea @rsc brought up in https://go-review.googlesource.com/c/go/+/13914#message-89b368b14fcdc0a03089aa34dc8185710144947f but it doesn't handle Marshaler types like time.Time and it would be awkward to implement this for those types.

I don't see any way to implement this without adding some surface to the encoding/json package, unfortunately, whether it's a new interface type or a sentinel error value.
I like the IsZeroer interface, but as @bradfitz points out in https://go-review.googlesource.com/c/go/+/13977#message-54fb3469327f16170962c57896824a4cdd5cd541 that could be pretty expensive and I've not done any performance analysis on this.  There are potential backward compatibility issues (or at least potentially surprising behavior) surrounding people's misunderstanding of the omitempty tag with structs.
I also like the sentinel value, but that only works for types that implement json.Marshaler.  But for the most commonly-desired types like time.Time that's fine, but it doesn't solve the asymmetry of the fact that omitempty doesn't work out of the box on structs.  And this sentinel error value would be orthogonal to omitempty, so it is potentially confusing in that respect.
So what this needs is someone to do some further analysis, implement these (and/or take my lame implementations further), see which is best and put forth a formal proposal.  (But that's not going to be me, as my failure to do this in the past two years shows 😄)

Are there any experience reports concerning types other than time.Time? If this issue is mostly about time.Time, maybe we should focus on that rather than come up with a more general solution covering mostly only hypothetical issues.

@mibk I often run into this issue using sql.NullString, mysql.NullTime etc.

@wayneashleyberry I see. But these cases could be handled using the third approach:

Whenever any struct would marshal to {}, omit it. This is an idea @rsc brought up in https://go-review.googlesource.com/c/go/+/13914#message-89b368b14fcdc0a03089aa34dc8185710144947f

which seems like a good idea regardless this issue. The third approach, IMO, also has the biggest potential to make it to the standard library.

Is this still being discussed for implementation? This just bit me today.

I hope to work on this for Go 1.12.

That just made my week @rsc, thank you so much 🙏

@Xe please hold off. We have not figured out the design yet. As I indicated above, I want to work on this for Go 1.12, probably in mid-September.

@rsc Is it helpful to add a slightly different use case for this issue?
We use a custom ID type that is represented as a [16]byte. Our type implements the MarshalJSON() method to encode the byte array as a more readable string. I believe the same issue occurs when using UUIDs from either popular uuid library. A zero ID is represents as [16]byte{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}, but that json serializes to [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0], so even hacks with unsafe.Pointer don't work.
If I'm reading this correctly, the third proposed solution (whenever any struct would marshal to {}, omit it.) would not work for this use case, at least not without requiring a wrapper struct. I'm personally a fan of using IsZero since we already use that extensively, but the sentinel value also seems to work.

On hold for JSON sweep.

Hey just wanted to ask if this proposal would consider when embedded struct field values are the zero value. For example:
https://play.golang.org/p/kjVSZsoor6p
Right now in order to get an empty struct I would need to add omitempty for every field inside the embedded struct. Sorry if it's implicit, just one to be clear on the matter.

Would it be an idea to extend the Nullable types to include NullTime as well?
Something like
type NullTime struct {
    Time  time.Time
    Valid bool
}

// Scan implements the Scanner interface.
func (nt *NullTime) Scan(value interface{}) error {
    if value == nil {
        nt.Time, nt.Valid = time.Time{}, false
        return nil
    }
    nt.Valid = true
    return convertAssign(&nt.Time, value)
}

// Value implements the Valuer interface.
func (nt NullTime) Valuer() (driver.Value, error) {
    if !nt.Valid {
        return nil, nil
    }
    return nt.Time, nil
}

Just copy paste into types.go, should work.

I know this is an old thread but I was able to work with nillable structs using jsoniter using the code below. Hopefully this will help someone.
	//encode - if we have a nil value this object can be treated as empty 	jsoniter.RegisterTypeEncoderFunc("field.Int64Field", func(ptr unsafe.Pointer, stream *jsoniter.Stream) { 		value := (*int64)(unsafe.Pointer((*Int64Field)(ptr).Value)) 		if value != nil { 			stream.WriteInt64(*value) 		} 	}, func(ptr unsafe.Pointer) bool { 		return (*string)(unsafe.Pointer((*Int64Field)(ptr).Value)) == nil 	})

@obashistu please do, i'd be interested to see how it's done.

@obashistu please do, i'd be interested to see how it's done.

This is a POC nillable string field we've been playing with recently. I've left out the boring marshalling and unmarshalling bits, if you need guidance on that (virtually the same as the standard lib with the addition of declaring a json var) check here : jsoniter.
https://gist.github.com/obashistu/caf5763a4e3b7f81de54b4c621aac634

@obashistu please do, i'd be interested to see how it's done.

This is a POC nillable string field we've been playing with recently. I've left out the boring marshalling and unmarshalling bits, if you need guidance on that (virtually the same as the standard lib with the addition of declaring a json var) check here : jsoniter.
https://gist.github.com/obashistu/caf5763a4e3b7f81de54b4c621aac634

Any chance this can get looked at again?

Slightly different implementation proposal #33400 :
Add an omitnull option, which will omit the given field if it's marshalled JSON value is null.
Similar to the sentinel return value proposal in terms of how it would need to be implemented.

I would love to see this in the go 1.13 release. Is this proposal still on the roadmap? Is there anything we can do to help push this along?
In the meantime, for those who need this functionality for json right away, I created a mirror of latest go1.12.7 encoding/json and added filtering for zero value structs (https://github.com/clarketm/json).

@clarketm I like your solution. It stays true to the original intent of omitempty. Curious of the performance of it, especially with larger structs and structs that many other structs in it.
I'd still personally like to see some interface that could be used thought I do not think IsZero() should be used simply because it is already a well established pattern and could mean different things and so using for this might have unintended consequences.
Like you though I would definitely love to see this get in 1.13 if possible.

Like you though I would definitely love to see this get in 1.13 if possible.

1.13 is about to come out so the merge window has been closed for a while. The 1.14 merge window is about to open, so that would be the earliest place it could go (though I wouldn't hold your breath, there doesn't seem to be much interest from the Go team in working on the encoding package; they have a lot on their plate with all the new features, I suppose; hopefully one of them can supply more information).

Curious of the performance of it, especially with larger structs and structs that many other structs in it.

You are right, it is a linear scan of all struct fields recursively. It will exclude private fields which helps a bit on performance.

I do not think IsZero() should be used simply because it is already a well established pattern and could mean different things and so using for this might have unintended consequences.

It looks like Go 1.13 Release Notes have a mention of a new Value.IsZero method for the reflect package which interestingly uses this same procedure (minus the private field exclusion) to determine if a struct is zero

Is it possible something from the Go team can give some feedback on this and what it might take to get this into 1.14? Would a PR with @clarketm implementation be ok? Is an interface the preferred approach? Are we all wasting our time thinking this will ever get acted on?

I'd still personally like to see some interface that could be used though I do not think IsZero() should be used simply because it is already a well established pattern and could mean different things and so using for this might have unintended consequences.

Can you explain what do you mean by "a well established pattern and could mean different things"...

@lukatendai Suppose you have a struct like:
type Foo struct { ... }

func (f Foo) IsZero() bool { ... }

And you have a *Foo in a struct serializing to JSON:
type JSONThing struct {
    Foo *Foo `json:"foo,omitempty"`
}

By making omitempty obey if there is an IsZeroer interface and omitting if it returns false, you are changing the behavior.  Before if the pointer were nil, it would be omitted from the JSON output.  Now it depends on both whether it is nil and whether IsZero returns false.  We can't say with certainty that is what users want.

@lukatendai I meant that IsZero() is already used in a lot of places. For time.Time has a IsZero() method. So if we made an interface that used that method, it could cause a lot of people's structs to start omitting time fields when they currently do not and that could cause unintended consequences. I have also seen IsZero() used in other libraries outside the stdlib so it has become an established community pattern.

@MrTravisB Yes... this I understand but IMO it won't effect "these" people... because time cannot be "empty" in current implementation, nobody adds "omiempty" to the json tags so if IsZero becomes interface than it wont change anything unless somebody added "omitempy" which probably they don't want to have zero time anyway. I use IsZero as a method on other structures to know if the structure does contain the data worth marshaling... any kind of marshaling/serializing, json, bson, protobuf, etc...

If we assume people don't add omitempty to time fields then yes, it wouldn't effect anyone. I'm just not sure if that is a safe assumption. I still reflexively add omitempty to time (and other struct) fields even though I know it doesn't do anything simply because I expect that it should.

because time cannot be "empty" in current implementation, nobody adds "omiempty" to the json tags so if IsZero becomes interface than it wont change anything unless somebody added "omitempy" which probably they don't want to have zero time anyway.

But *time.Time can be empty, and it is common to add omitempty to those values, exactly to get the desired behavior of not serializing a zero time value.  It is unfortunate that you have to use a pointer type for this, but at least it works.
I agree that time.Time is not the best example here because its zero value is very bad for JSON serialization, but the IsZero example I showed above illustrates that this is a behavioral change that can't be opted into, and which might break things broadly across the countless types that implement IsZero.
To do IsZero safely you'd need to create a new struct tag that opts into that behavior -- an omitzero tag was suggested earlier in the thread.

I think omitting zero values is the wrong approach semantically. It's weird that you have a type whose zero value has a valid JSON serialisation, but you are overriding that in the containing struct to omit it instead.
It makes a lot more sense to define your type such that it serialises to null when it isn't a meaningful value, and have a new omitnull struct tag that omits the key for the field if it serialised to null.
Only the library has to change to support this approach, it doesn't interact with any external interfaces like IsZero, and you don't even have to introduce a special sentinel err value for MarshalJSON - someone who wants to use it just marshals to null (which they should anyway), and tags their struct field with omitnull.

After 7 years of Go development I believe "omitempty" with IsZero() is a simply solution. If someone uses omitempty with time.Time right now, clearly they don't care. Also, I use custom marshalers but for more complicated things than getting rid of zero time.

I support what @Qhesz said.

@Qhesz

I think omitting zero values is the wrong approach semantically. It's weird that you have a type whose zero value has a valid JSON serialisation, but you are overriding that in the containing struct to omit it instead.

There is a fundamental mismatch in the JSON and Go type systems.  Namely, values in JSON are nullable, and non-pointer types in Go are not.
The omitempty flag is a convenience for dealing with this mismatch, by observing that many APIs (those not written in Go, primarily) do not obey Go's view on zero values and treat them separately from a null value.  In Ruby, for example, the empty string ("") evaluates true, whereas nil does not.  Thus, a JSON document of {"foo": ""} versus {} or even {"foo":null} are very different things in Ruby.  This issue deals with the fact that this convenience flag doesn't extend to struct types.
In your proposal, how do you deal with non-nullable types, particularly the built-in ones like string?

I understand the issue. omitempty on structs would let you choose between outputting {"foo":{"bar":0}} and {}, whereas omitnull would let you choose between outputting {"foo":null} and {}. (My point about semantics is that neither 0 nor a struct containing it are "empty". They're "zero" in golang terms, but 0 could still be a meaningful value.)
String is one type where I think omitempty makes sense. Primarily because it's called "the empty string", and the wording matches. Plus, historically, UI frameworks might not distinguish between absent and empty string inputs very well, so you might be stuck with that behaviour and genuinely want to special case the empty string to match.
If my JSON api included an optional integer, I would define a Golang type that matches. So if I wanted my Golang integer field to be optional (and didn't want to use pointers, eg. to preserve ==, copy by struct assignment etc.), I'd make it an explicit OptionalInt struct type, with a bool for presence and an int value. So 0 would be a valid value, I could test for presence separately, and I'd marshal it out as null if it wasn't present. And then use omitnull in the struct containing it, because my convention is ommited fields instead of null values in JSON.
And if my JSON api included a required integer, I'd use a normal Golang int field that defaults to 0 if it was absent from/null in the JSON. If I really wanted to validate that it must be present, that's outside the scope of this serialisation library, and I'd validate the JSON separately before deserialising it.
In direct response to your question: I deal with JSON/golang type mismatches, by not having type mismatches.

A note on implementation: I'd prefer a json.Decoder flag OmitNull() rather than a struct tag, so I can define it once for my whole project. The struct tag I'd end up adding to every struct field I define, which would be a lot of repetition.
With this, #33835 and #33854, encoding/json would have sane and consistent management of json null and absent fields, both when unmarshalling and marshalling. All would be opt-in, but at least it would be possible.

I'm running into this issue when using null.String from https://pkg.go.dev/gopkg.in/guregu/null.v3. I'd be willing to help work on a solution.

@walkingeyerobot If you don't mind *int, then that should be enough to distinguish between null and 0.

@diamondburned pointers work great for unmarshaling if you need to distinguish between empty and 0, but they're not so friendly when you need to marshal. You would need to write a custom Marshaler interface for the parent struct or use two different structs and map between them

On hold for JSON sweep.

@rsc - any chance that there would be a solution to this issue? Its been 5 years

Intuitively, a struct "feels" like a complex type, while "time" feels like a simple value. I believe that it is not necessary to generalize the notion of an "empty" struct. However, an "empty time" is already defined, with the IsZero() method. Add to encoding/json/encode.go/isEmptyValue():
case reflect.Struct:
	switch v := val.Interface().(type) {
        case time.Time:
    		if v.IsZero() {
			return true
		}
	}
}

Intuitively, a struct "feels" like a complex type, while "time" feels like a simple value. I believe that it is not necessary to generalize the notion of an "empty" struct. However, an "empty time" is already defined, with the IsZero() method. Add to encoding/json/encode.go/isEmptyValue():
case reflect.Struct:
	switch v := val.Interface().(type) {
        case time.Time:
    		if v.IsZero() {
			return true
		}
	}
}

Intuitively, a struct "feels" like a complex type, while "time" feels like a simple value. I believe that it is not necessary to generalize the notion of an "empty" struct. However, an "empty time" is already defined, with the IsZero() method. Add to encoding/json/encode.go/isEmptyValue():
case reflect.Struct:
	switch v := val.Interface().(type) {
        case time.Time:
    		if v.IsZero() {
			return true
		}
	}
}

That could be improved to also support aliased time.Time types, so it'll need to include a step to see if it's: val.Type().ComparableTo(reflect.TypeOf((*time.Time)(nil)).Elem()).
Adding a Zeroer interface would make it a lot simpler, and you can easily do this in your own application, but I agree that being able to distinguish during unmarshalling should be part of stdlib.
Are there libraries that do solve this issue? I went through a couple, but most initiatives appear to be around Encoding, rather than the reverse.

Intuitively, a struct "feels" like a complex type, while "time" feels like a simple value. I believe that it is not necessary to generalize the notion of an "empty" struct. However, an "empty time" is already defined, with the IsZero() method. Add to encoding/json/encode.go/isEmptyValue():
case reflect.Struct:
	switch v := val.Interface().(type) {
        case time.Time:
    		if v.IsZero() {
			return true
		}
	}
}

That could be improved to also support aliased time.Time types, so it'll need to include a step to see if it's: val.Type().ComparableTo(reflect.TypeOf((*time.Time)(nil)).Elem()).
Adding a Zeroer interface would make it a lot simpler, and you can easily do this in your own application, but I agree that being able to distinguish during unmarshalling should be part of stdlib.
Are there libraries that do solve this issue? I went through a couple, but most initiatives appear to be around Encoding, rather than the reverse.

With Mr. van der Velden's advice, I added the following case to the switch in encoding/json/encode.go:IsEmptyValue() to my Go deployment.
	case reflect.Struct:
		if v.Type().ConvertibleTo(reflect.TypeOf(time.Time{})) {
			return v.IsZero()
		}

I added the following type alttime, Optionals fields, and optionalsExpected lines to encoding/json/encode_test.go for the TestOmitEmpty test:
// issue golang.org/issues/11939
type alttime time.Time

func (t alttime) MarshalText() ([]byte, error) {
	return time.Time(t).MarshalText()
}

	// issue golang.org/issues/11939
	Tmr time.Time `json:"tmr"`
	Tmo time.Time `json:"tmo,omitempty"`
	Atr alttime   `json:"atr"`
	Ato alttime   `json:"ato,omitempty"`

 "tmr": "0001-01-01T00:00:00Z",
 "atr": "0001-01-01T00:00:00Z"

The test passes:
cd $GOROOT/src/encoding/json
go test -v
=== RUN   TestOmitEmpty
--- PASS: TestOmitEmpty (0.00s)

With Mr. van der Velden's advice, I added the following case to the switch in encoding/json/encode.go:IsEmptyValue() to my Go deployment.
	case reflect.Struct:
		if v.Type().ConvertibleTo(reflect.TypeOf(time.Time{})) {
			return v.IsZero()
		}

I added the following type alttime, Optionals fields, and optionalsExpected lines to encoding/json/encode_test.go for the TestOmitEmpty test:
// issue golang.org/issues/11939
type alttime time.Time

func (t alttime) MarshalText() ([]byte, error) {
	return time.Time(t).MarshalText()
}

	// issue golang.org/issues/11939
	Tmr time.Time `json:"tmr"`
	Tmo time.Time `json:"tmo,omitempty"`
	Atr alttime   `json:"atr"`
	Ato alttime   `json:"ato,omitempty"`

 "tmr": "0001-01-01T00:00:00Z",
 "atr": "0001-01-01T00:00:00Z"

The test passes:
cd $GOROOT/src/encoding/json
go test -v
=== RUN   TestOmitEmpty
--- PASS: TestOmitEmpty (0.00s)

The omitempty tag option does not influence unmarshaling. Decoding is driven by the incoming JSON. It might be of value to add that. Here is an example, though the current behavior allows a structures fields to be updated with several Unmarshal calls, perhaps if one is initializing a structure from several JSON objects.
package main

import (
	"fmt"
	"encoding/json"
	"time"
)

func main() {
	type example struct {
		Word string    `json:",omitempty"`
		Time time.Time `json:",omitempty"`
	}

	x := example{Word: "abc", Time: time.Now()}
	buf, _ := json.MarshalIndent(x, "", "  ")
	fmt.Printf("%s\n", buf)

	buf = []byte(`{"Time": "2021-01-02T12:10:25.527-05:00"}`)
	json.Unmarshal(buf, &x)

	fmt.Printf("%+v\n", x)
}

{
  "Word": "abc",
  "Time": "2009-11-10T23:00:00Z"
}
{**Word:abc** Time:2021-01-02 12:10:25.527 -0500 -0500}

Note that the x.Word value remains "abc". The omitempty option does not influence unmarshaling behavior.
Unmarshaling that would be sensitive to all the "json" tags in a structure requires adding a pass through the structure. I am not sure what I would even want unmarshaling to do in this case. If we want an existing structure value retained if not in the JSON, do we add a new tag option "ignoreabsent"?
For Marshaling however, I hope that the suggestion for time.Time handling of omitempty is reasonable. Documenting how to interpret "0001-01-01T00:00:00Z", and why, in REST API's does cause occasional confusion for my non-Go acquaintances. :)

The omitempty tag option does not influence unmarshaling. Decoding is driven by the incoming JSON. It might be of value to add that. Here is an example, though the current behavior allows a structures fields to be updated with several Unmarshal calls, perhaps if one is initializing a structure from several JSON objects.
package main

import (
	"fmt"
	"encoding/json"
	"time"
)

func main() {
	type example struct {
		Word string    `json:",omitempty"`
		Time time.Time `json:",omitempty"`
	}

	x := example{Word: "abc", Time: time.Now()}
	buf, _ := json.MarshalIndent(x, "", "  ")
	fmt.Printf("%s\n", buf)

	buf = []byte(`{"Time": "2021-01-02T12:10:25.527-05:00"}`)
	json.Unmarshal(buf, &x)

	fmt.Printf("%+v\n", x)
}

{
  "Word": "abc",
  "Time": "2009-11-10T23:00:00Z"
}
{**Word:abc** Time:2021-01-02 12:10:25.527 -0500 -0500}

Note that the x.Word value remains "abc". The omitempty option does not influence unmarshaling behavior.
Unmarshaling that would be sensitive to all the "json" tags in a structure requires adding a pass through the structure. I am not sure what I would even want unmarshaling to do in this case. If we want an existing structure value retained if not in the JSON, do we add a new tag option "ignoreabsent"?
For Marshaling however, I hope that the suggestion for time.Time handling of omitempty is reasonable. Documenting how to interpret "0001-01-01T00:00:00Z", and why, in REST API's does cause occasional confusion for my non-Go acquaintances. :)

So does anyone know if there has been any official word/movement on this issue?   I see theres been a number of proposals but they all seems to have just been abandoned over the years?
It definitely feels like if we can tag fields as "omitempty" it should work for both marshaling and unmarshaling equally (ie, if a struct has a nill/zero field and tagged "omitempty" it should not produce a JSON field, just as a JSON field that is null/omitted will not populate a value into a struct field.)
If there was an interface like IsNiller that was very simple, just one function like IsNil() bool. Then add a tiny bit of logic into marshal.go / encode.go:
func isEmptyValue(v reflect.Value) bool {
...
	case reflect.Struct:
 		if sv, ok := v.interface().(nillerPackage.IsNiller); ok {
			return sv.IsNill()
		}
...
}

Then any struct that wanted to be skipped just implements that interface. And would pretty much take care of the issue from what I can see? Plus it leaves the exact behavior up to the developer who is implementing the struct's behavior.   (ie. if time.Time doesn't want this to be the default behavior, it doesn't need to implement it, but it is still easy enough to wrap and implement it in your own struct, win win)
I might be missing something here, but it feels like a relatively small change for something that would be so helpful for everyone that works with Go for web APIs/ JSON tasks in general.

This feels like one of those issues which is causing real pain for the community, but sees no traction from @rsc, @adg, and others due to "not a problem at Google".
What would it take to move this proposal forward?

If there was an interface like IsNiller that was very simple, just one function like IsNil() bool. Then add a tiny bit of logic into marshal.go / encode.go:

I'd suggest something like this instead:
type IsZeroer interface {
  IsZero() bool
}

This matches time#Time.IsZero and semantically aligns with the Go idea that zero values are the default.
I would be willing to champion this proposal (or whatever equivalent metaphor is most accurate), I am not a Googler or on the Go team but I am willing to do the legwork needed to make this happen.

The original post(back mid 2015) suggested the IsZeroer interface, but noted there may be some compatibility issues:
"The encoding.IsZeroer interface could introduce issues with existing non-struct types that may have implemented IsZero() without consideration of omitempty."
Which is the only real reason I figured a change to IsNil would be appropriate, especially where in the cases Im thinking its useful for, will be used for omitting fields that are nil structs (or that wish to be considered nil, for example if they keep track of if they have been modified since creation or something?).   Plus, if you need the new behavior for time.Time, you can very easily wrap it as a field in your own struct and implement whatever IsNil behavior you wish.
Essentially avoiding any backwards compatibility issues, and leaving the exact behavior in the hands of the developer who is defining the structs.

An approach I don't see listed in this issue is:

Add to the Encoder type a func (e *Encoder) SetEmptyPredicates(predicates map[reflect.Type]func(reflect.Value)bool) (see note at end)
Pass this map in the options used during encoding (obviously)
During encoding, we only call the given function for fields marked as omitempty which have a type in the map.

The advantage of this approach is:

We avoid a potentially expensive interface check in the vast majority of cases
Users can decide if something is "empty" however they please, including on objects declared outside of their package (e.g. time.Time)

I'd hesitate to let users modify the global encoding options, but maybe adapters for things in the standard library (e.g. time.Time) could be pre-added.
Note: of course we don't have to make users pass a map, they could pass one reflect.Type, func (reflect.Value) bool at a time. I recommend the function takes reflect.Value because the user can convert it to a usable thing in the most efficient way -- they might not need to convert it.

#5901 (accepted) is custom per encoder/decoder matshal/unmarshal functions

#5901 (accepted) is custom per encoder/decoder matshal/unmarshal functions

Thanks for that reference, it makes me think this approach might not get laughed all the way out of town-- however note that the omit-or-not decision is (at least in the current code) made by the caller of the marshal/unmarshal function, so it's not exactly the same problem.

I think this is a two part issue. The first part is a bug report and the second is a proposal.
Over the last ten years, it has been inconsistent and surprising that an empty struct value whose type has an omitempty tag is still not treated as empty when marshaled by default. Special cases for time.Time and opt-in interfaces are a red herring and distract from the bug present in this package.
If this bug is not going to be fixed due to perceived incompatibility (such as what happened to https://github.com/golang/go/issues/31924), that should be clearly stated.

I made a stand-alone proposal which could address partially also concerns here: that returning nil from MarshalJSON would omit the field: https://github.com/golang/go/issues/50480
It allows some other use cases (like dynamic decision based on data itself) but it can help here, too, I think (for some use cases, not all though).

I agree with everyone who thinks it's really unfortunate that all attempts to address this so far have been abandoned with the general reason of "let's not add to these packages." My only extra comment is this:
Now that Go has generics, there are strong reasons for people to implement a type like Optional[T] for representation of optional types (the main reasons are immutability and nil-safety). Such a type will likely (or necessarily?) be implemented as a struct like { defined bool; value T }. But currently there is no way to get omitempty behavior for such a thing— so anyone who wants unset properties to be dropped must continue using pointers. And that's true even if T is a simple type; that is, you can get omitempty behavior with a plain bool, but that means false values will be dropped; if the semantics you want are "true, false, or undefined" and you can't use a type like Optional[bool], then your only option is to use *bool which has the disadvantages I mentioned. To me that's a not-insignificant usability problem for the package.

@eli-darkly

I agree with everyone who thinks it's really unfortunate that all attempts to address this so far have been abandoned with the general reason of "let's not add to these packages." My only extra comment is this:
Now that Go has generics, there are strong reasons for people to implement a type like Optional[T] for representation of optional types...

Exactly our use-case, and it's infuriating that there is no way to omit fields using std library when you have an implementation such as this.
All above solutions work, but I'd personally find it most clean if return nil, ErrOmitEmpty were to be implemented. I'd love to help drive this forward, this has been an open issue for ~7 years now, what are the next steps?

what are the next steps?

Convincing the Go team to reconsider, I guess. :/

@lavalamp ok, if you think that the problem is in old object I'll give you athoter example
https://go.dev/play/p/0h94gw997Tu
to make it clear, there is no way  to set "mistery_field" to null in this faked api call, that's the idea behind this and previuos pieces

Like I said, that's not the problem this issue is about. The intended way to not have that problem is to only unmarshal into newly constructed objects. Neither of your samples follows this rule.
You have a further problem, I think -- you're not going to be able to get JSON to differentiate between the concepts "I don't care" and "I want this to be nil" without putting in a fair amount of work. Kubernetes server-side apply is an example of how much work. overview; source code that does merging

null is a value. omitempty tagged field  shouldn't be omitted with null value

@lavalamp Here is another example for u
https://go.dev/play/p/Cca09jBoHKG
with all new newlyConstructed object

This exchange doesn't belong on this issue. I hope an admin can delete or hide it.

It's been eight years and haven't figured out a solution yet?

If this proposal is on hold, is there a new alternative that is being proposed?

There are some slow-moving plans for encoding/json/v2.

Hi all, we kicked off a discussion for a possible "encoding/json/v2" package that addresses the spirit of this proposal at least for JSON. See the "omitzero" struct tag option under the "Struct tag options" section.

My team inherited maintenance duties for a Go application, and we just had to fix a bug caused by the legacy code trying to use the omitempty tag on a nested (inline) struct member for JSON serialization.
I've read a lot of related issues here, and started digging through this one, but Github is terrible at presenting a large number of comments on a single issue.  I'm trying to understand the current state of things -- if there's a good summary somewhere in the middle of the ~200 comments on this issue, I'd appreciate a link.
As a JS developer, I can tell you that sending an empty object value ({}) over the wire is, to a first approximation, never the desired outcome.  I could point to a decade (!) of issues where people are trying to emit sensible JSON.  From an outsider's perspective, "all" it would take to accomplish this is to make the existing keyword do what it says on the tin, instead of having no effect (!) -- we just want the package to follow the Principle of Least Surprise.  It sounds like there is some implementation detail that makes avoiding empty-object output difficult, or would incur an unacceptable performance penalty.  Personally, I would rather have good output slowly than bad output fast.

As a workaround, I've had good luck using https://github.com/clarketm/json (which is a re-implementation of encoding/json that omits empty structs) and using a type alias to prevent recursion
import (
	"encoding/json"

	jsonx "github.com/clarketm/json"
)

func (s OuterStruct) MarshalJSON() ([]byte, error) {
	// Use a type Alias to prevent Marshal recursion
	type TmpStruct OuterStruct
	// PE-11258: jsonx omits empty structs
	return jsonx.Marshal(TmpStruct(s))
}

The omitzero proposal in #45669 is pretty similar to the original proposal, and should cover the main use cases, so I am going to close this issue.  A new issue will need to be raised for encoding/xml but it would be good for that to be its own issue.

If this is being closed in favor of #45669, is there a separate issue already going that I could follow to make applying omitempty to nested struct members -- which, if I understand correctly, can never do anything -- emit a compiler error, or at least a gopls warning?

That sounds like a reasonable govet enhancement.

Thanks @dsymonds , do you know where it would be appropriate to make that request?  I can't tell if govet is managed in this repo or under https://github.com/golangci/golangci-lint -- I did find a https://github.com/golangci/govet but it was archived last year with no notes about why or where to take govet issues...

@thw0rted: This issue tracker is probably fine. There's plenty of other issues for govet already here.

A new vet check should be opened in this issue tracker as a proposal.  See https://go.dev/s/proposal.  Thanks.

@ianlancetaylor it looks like the candidate implementation for #51261 actually covers this case, even though the title of that proposal still says it's only about time.Time.  Does a new proposal still make sense in that case, compared to updating the scope of the existing one?

Thanks, I agree that the existing proposal is sufficient here.


no basic auth credentials with nexus registry

Bug description
Hello, I am using portainer-ce in version 2.9.01(latest) and i am having some problems when I want to deploy a stack with my private nexus registry.
I added my registry with credential and when I want to deploy my stack, I have the following error
failed to deploy a stack: Pulling push (url_of_my_registry/image_name:version)... Head https://url_of_my_registry/v2/image_name/manifests/image_name:version: no basic auth credentials : exit status 1
Portainer Logs
On the portainer agent, I dont have logs. On the system logs of the agent :
Oct 5 19:56:31 dock1-qua dockerd[68163]: time="2021-10-05T19:56:31.988581097+02:00" level=error msg="Handler for POST /images/create returned error: Head https://url_of_my_registry/v2/image_name/manifests/image_name:version: no basic auth credentials"

If I go on the host of the agent and I pull the image, I don't have any problem
Technical details:
Portainer version: 2.9.1
Docker version (managed by Portainer): 20.10.4
Platform (windows/linux): Centos 7.8
Command used to start Portainer (docker run -p 9443:9443 portainer/portainer):
docker run --name portainer -d -p 8000:8000 -p 9000:9000 --env HTTPS_PROXY=http://my_proxy:8080 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest
Browser: Chrome
Use Case (delete as appropriate): Using Portainer at Home
Have you reviewed our technical documentation and knowledge base? Yes

To use a proxy for pulling images, create the file /etc/systemd/system/docker.service.d/http-proxy.conf on the host where Portainer or the Agent is running.
And populated it with something like:
[Service]
Environment="HTTP_PROXY=http://proxy.example.com:80"

I still have the same error with this configuration.
If I pull the image from the image menu, no problem
If I use the stack, still the same error :

On the agent systemed logs
Dec  3 17:39:55 docker-agent dockerd[48990]: time="2021-12-03T17:39:55.966545020+01:00" level=info msg="Attempting next endpoint for pull after error: Head https://##########/v2/##########/manifests/1.0.2: no basic auth credentials"
Dec  3 17:39:55  docker-agent dockerd[48990]: time="2021-12-03T17:39:55.972881629+01:00" level=error msg="Handler for POST /images/create returned error: Head https://##########/v2/#########/manifests/1.0.2: no basic auth credentials"

Thanks for that info. We're still trying to figure out what exactly is going on.
In the mean time can you please try:
set HTTP_PROXY=http://admin:password@proxy_ip:proxy_port

Hello, still the same (sorry !)

Hello, I think I have a similar issue, but on pulling the image.
Basically, I've configured my aws private registry on portainer UI, I also did a docker login with the docker-cli, but when I attempt to create a container, via portainer proxy API, that use an image on ECR I have the error "Head https://.dkr.ecr.eu-central-1.amazonaws.com/v2/: no basic auth credentials"
The called API is: https://localhost:9443/api/endpoints/2/docker/v1.35/images/create?tag=&fromImage=.dkr.ecr.eu-central-1.amazonaws.com/**
Am I wrong in somethings?

For the ECR problem, can you please create a separate GitHub issue?
(this Nexus issue is caused by a http proxy, like squid etc)

@Quentinvarquet our current thinking is that the proxy problem does not occur when Portainer is deploying on a local environment, but does occur when deploying via the agent.

@Quentinvarquet
Would you please  let me know your Docker agent version? So I could make further investigation. Thanks

Hello, sorry i did not see the notification
I m using docker 20.10.4
docker --version
Docker version 20.10.4, build d3cb89e

I actually don't think this will work through the Agent.
To deploy something, Portainer will be invoking:
https://github.com/portainer/docker-compose-wrapper/blob/6569596db8404aae5f570faa797a6ff818610832/compose/internal/composeplugin/composeplugin.go#L115
Where the URL is something like -H tcp:x.x.x.x:45051.
However, docker will ignore the proxy settings in that case:
https://github.com/moby/moby/pull/10739

I face similar problems since last Portainer update.
Some examples, when error occurs - or not:

Pulling an image using "Images -> Image list -> Pull the Image" works without problems an all nodes/agents
Stopping service, removing containers, removing all related images from all nodes and redeploy service using "Stack -> Editor -> Update the stack" works, pulling latest image.
Stopping service, removing containers from all nodes and redeploy service using "Stack -> Editor -> Update the stack" works, using available images.
Updating service by using "Stack -> Services -> mark Service -> click Update -> enable 'Pull latest image version'" fails on all nodes with log output shown at the end
Updating service by using "Services -> mark Service -> click Update -> enable 'Pull latest image version'" also fails with same errors on all nodes
While Portainer keeps trying to update the service and changes node to start container, I made a manual image pull using "Images -> Image list -> Pull the Image" to the node, Portainer currently tries to start the service and this will work and start the service on this node.

Some more information:

Private registry using Nexus 3.39.0. Tested basic auth using browser - no issues.
Portainer 2.13.1 and Agents using docker swarm with image portainer/agent:alpine on 3 nodes (latest image version from 2022-05-12).
Docker 2.10.16
Debian 11

Jun 25 16:47:01 ### dockerd[1137919]: time="2022-06-25T16:47:01.391012299+02:00" level=error msg="pulling image failed" error="Head \"https://###/v2/###-service/manifests/latest\": no basic auth credentials" module=node/agent/taskmanager node.id=### service.id=### task.id=###
Jun 25 16:47:06 ### dockerd[1137919]: time="2022-06-25T16:47:06.070891483+02:00" level=info msg="Attempting next endpoint for pull after error: Head \"https://###/v2/###-service/manifests/latest\": no basic auth credentials"

Hi, sounds like you've run into: https://github.com/portainer/portainer/issues/6566

Hi, any updates on this issue? We are experiencing the same behavior as @pcvolkmer on closely the same setup/environment.


fix import on case-sensitive filesystems

This typo caused the program to fail on non-windows systems

I should probably say this closes #14

it's been almost a year since I proposed this, do you plan on merging it @stravant ?

I came here to make this same PR. Would like to have this merged, could have saved me a handful of minutes.

Approved. Apologies for the delay, this project isn't really supported anymore.

nice! happy to see this go in after all!


DjangoDebugging: Value is not accepted

DjangoDebugging: Value is not accepted
{} launch.json
   `"name":` "Python: Django",
    "type": "python",
    "request": "launch",
    "stopOnEntry": true,
    "pythonPath": "${config:python.pythonPath}",
    "program": "${workspaceFolder}/manage.py",
    "cwd": "${workspaceFolder}",
    "args": [
        "runserver",
        "--noreload",
        "--nothreading"
    ],
    "env": {},
    "envFile": "${workspaceFolder}/.env",
    "debugOptions": [
        "RedirectOutput",
        _***"DjangoDebugging"***_`

Received the below Error: Value is not accepted. Valid values: "RedirectOutput", "DebugStdLib", "BreakOnSystemExitZero", "Django", "Sudo", "IgnoreDjangoTemplateWarnings", "Pyramid"
Also Terminal is launching python file, every time I run my code and stops there, after execution.

Please change the value from Django to DjangoDebugging

Also Terminal is launching python file, every time I run my code and stops there, after execution.

The new default is to load a terminal window. If you do not prefer this you can change your console to none in launch.json

Thanks. It worked.

Received the below Error: Value is not accepted. Valid values: "RedirectOutput", "DebugStdLib", "BreakOnSystemExitZero", "Django", "Sudo", "IgnoreDjangoTemplateWarnings", "Pyramid"

Leaving the value as is should still work, is spite of the warning.