no service provider for mac_os_x on chef 12?

we're working on upgrading from chef 11 -> 12, but hit this updating our mac_os_x cluster...
chef > Chef::VERSION
 => "11.16.4"
chef > Chef::Platform.find_provider_for_node node, :service
 => Chef::Provider::Service::Macosx

chef > Chef::VERSION
 => "12.2.1"
chef > Chef::Platform.find_provider_for_node node, :service
ArgumentError: Cannot find a provider for service on mac_os_x version 10.10.3
	from /opt/chef/embedded/apps/chef/lib/chef/platform/provider_mapping.rb:446:in `find_provider'
	from /opt/chef/embedded/apps/chef/lib/chef/platform/provider_mapping.rb:373:in `find_provider_for_node'
	from (irb):5
	from /opt/chef/embedded/apps/chef/lib/chef/shell.rb:76:in `block in start'
	from /opt/chef/embedded/apps/chef/lib/chef/shell.rb:75:in `catch'
	from /opt/chef/embedded/apps/chef/lib/chef/shell.rb:75:in `start'
	from /opt/chef/embedded/apps/chef/bin/chef-shell:37:in `<top (required)>'
	from /usr/bin/chef-shell:51:in `load'
	from /usr/bin/chef-shell:51:in `<main>'

@nathwill You're accessing an internal part of the old provider mapper directly. As of 12.2.0/c3552dc11831379a4b4753964451498e1340611e the OS X providers are no longer statically resolved, so the old provider mapper no longer knows about them.
I'm not sure what you're using that code for, but because resources can have unique attributes, you should look at using Chef::Resource.resource_for_node(:service, node).

@btm hmmm... in my experience, it's generally used as a proxy for detecting the chef-preferred init system for the platform (e.g. https://github.com/atomic-penguin/cookbook-nfs/blob/master/attributes/default.rb#L44 or https://github.com/nathwill/chef-haproxy-ng/blob/master/recipes/install.rb#L85). being able to use that is/was a lot more lightweight than maintaining/duplicating an internal mapping for each cookbook that needed to support multiple init systems.
Chef::Resource#resource_for_node doesn't quite fit the bill from what i'm seeing, it seems to resolve to Chef::Resource::Service on EL6, EL7, mac_os_x, and Ubuntu 12.04. Is there anything better that can be considered a stable interface?
thanks for the help so far.

We always had support for multiple providers for a resource (via the provider map) but as provider's started to need unique attributes (like package) we ended up having resources that took a bunch of attributes that may not even apply to chosen provider. Quite a while ago we added the initial provides code for choosing an alternate resource, but it wasn't heavily used.
This feature was refactored recently to support having multiple init systems as you described, and continues to be refactored (see #3077).
There isn't a stable interface. We discussed the need for one in the dsl over in #3071, but generally we're not good at clearly identifying the internal methods that are public and stable.
Maybe this helps:
chef > service_resource = Chef::Resource.resource_for_node(:service, node).new("lookup a provider")
[snip]
chef > service_provider = Chef::ProviderResolver.new(node, service_resource, :start).resolve
 => Chef::Provider::Service::Macosx

@btm ok, thanks. i'd definitely seen some mention of the new dynamic selection stuff, but pending some of that settling out a bit, i haven't bothered to look into it in detail.
the provided solution unfortunately only works on Chef 12, but wrapping the old way and the new way in a version check ought to be straightforward enough, so i'll try to make it work.
FWIW, a search on github seems to indicate that Chef::Platform#find_provider_for_node has been pretty broadly adopted in lieu of an official stable interface. i'm not super familiar with the code in question, but that makes me wonder if it can be made to continue working during and after the transition to the new dynamic matching system so as to minimize ecosystem disruption.
in any case, thanks again for the explanation and pointers! feel free to mark this closed if this seems a reasonable place to leave it.

hmmm, a second look at the search results says nearly all of those are forks and dupes, so maybe not as disruptive as i thought, whew!

nfs cookbook uses it in attributes just as an FYI. I just came across this trying to run chefspec tests on OSX
default['nfs']['service_provider']['lock'] = Chef::Platform.find_provider_for_node node, :service
default['nfs']['service_provider']['portmap'] = Chef::Platform.find_provider_for_node node, :service
default['nfs']['service_provider']['server'] = Chef::Platform.find_provider_for_node node, :service

Are you running the suggested alternative via chef-shell or does it need a full Chef run? I get the following (on the latest ChefDK on OSX). Do I need to require something?:
chef > service_resource = Chef::Resource.resource_for_node(:service, node).new("lookup a provider")
 => <macosx_service[lookup a provider] @name: "lookup a provider" @noop: nil @before: nil @params: {} @provider: nil @allowed_actions: [:nothing, :enable, :disable, :start, :stop, :restart, :reload] @action: "nothing" @updated: false @updated_by_last_action: false @supports: {:restart=>false, :reload=>false, :status=>false} @ignore_failure: false @retries: 0 @retry_delay: 2 @source_line: nil @guard_interpreter: nil @default_guard_interpreter: :default @elapsed_time: 0 @sensitive: false @resource_name: :macosx_service @service_name: "lookup a provider" @enabled: nil @running: nil @parameters: nil @pattern: "lookup a provider" @start_command: nil @stop_command: nil @status_command: nil @restart_command: nil @reload_command: nil @init_command: nil @priority: nil @timeout: nil @plist: nil @session_type: nil>
chef > service_provider = Chef::ProviderResolver.new(node, service_resource, :start).resolve
NameError: uninitialized constant Chef::ProviderResolver
	from (irb):2
	from /opt/chefdk/embedded/apps/chef/lib/chef/shell.rb:76:in `block in start'
	from /opt/chefdk/embedded/apps/chef/lib/chef/shell.rb:75:in `catch'
	from /opt/chefdk/embedded/apps/chef/lib/chef/shell.rb:75:in `start'
	from /opt/chefdk/embedded/apps/chef/bin/chef-shell:37:in `<top (required)>'
	from /usr/bin/chef-shell:51:in `load'
	from /usr/bin/chef-shell:51:in `<main>'

@nathwill are you setting this in an attributes file or are you using it in a provider?
This is something of an annoying change when using Berkshelf and upstream cookbooks use this, the attributes are still evaluated even if you override them in a wrapper cookbook.

For me specifying a different platform in chefspec solved the issue. Still not sure why chef-shell wasn't working but anyway.

The problem is that on ubuntu 14.04 there is no concept of a uniform service since you might get sysv init scripts or might get upstart.   The proper interface to use should be:
Chef::Resource::Service.new("ntpd").provider_for_action(:install)

You are guaranteed to get a service back for why-run messages, so there is the concept of a default fall-back service provider buried inside of how it looks it up:
Chef::Resource::Service.new("doesnotmatter").provider_for_action(:install)

It looks like that has backcompat all the way back to 10.14.0 as well:
https://github.com/chef/minitest-chef-handler/commit/c73f308fcb6e513fc9013a0e9931f9e3f4eb95d8
And, I certainly consider that a stable interface and don't plan on changing that any time soon.  We also deprecated Chef::Resource.resource_for_node and replaced it with that in 12.0.  I suspect it worked up until 12.4.x-ish for some use cases because we hadn't yet fully dumped the platform map out and completed the work of migrating provider discover to the provider resolver.

And the default provider for Ubuntu 14.04-ish did change with 12.0 where in 11.x you used to get sysvinit, but in >=12.0 the default provider is Upstart for all upstart-enabled Ubuntus (if it detects the presence of upstart you get back upstart).  Now with Systemd taking over the world that automatically changes and if systemd is detected as the init system, then the default provider will be systemd (and since its dynamically resolved, if the user rolls back systemd back to upstart then the default provider will get rolled back to upstart, which should be comply with DWIM/DTRT).


Feature request: ArrayLiteral#pop & #shift

ArrayLiteral#push works (although not documented), so I suppose it's possible to add #pop and #shift etc.
Upd
Nice place to start: https://github.com/crystal-lang/crystal/pull/5265

I don't quite understand the request, this appears to exist already:
https://crystal-lang.org/api/0.25.1/Array.html#pop-instance-method

@benglewis This is about macro array literals https://crystal-lang.org/api/master/Crystal/Macros/ArrayLiteral.html

Closing as for https://github.com/crystal-lang/crystal/pull/7109#issuecomment-441625418


Fix errors when using built-ins in shaderinc

Fix https://github.com/godotengine/godot/issues/63337 (also fixed render_mode, autocompletion and highlighting):

Thanks!


question about value of base learning rate

Hi Peize
When I read the yaml file that contains learning parameters, I find the base learning rate is just 2.5e-5, which is much smaller than the learning rate (0.02) used in detectron2. I wonder why the learning rate is so small. Have you tried to train the network with larger learning rate?
Thanks

Hi Peize
When I read the yaml file that contains learning parameters, I find the base learning rate is just 2.5e-5, which is much smaller than the learning rate (0.02) used in detectron2. I wonder why the learning rate is so small. Have you tried to train the network with larger learning rate?
Thanks

we use adam optimizer, so the base learning rate is just 2.5e-5, if we use larger lr, the network will not converge

Hi Peize
When I read the yaml file that contains learning parameters, I find the base learning rate is just 2.5e-5, which is much smaller than the learning rate (0.02) used in detectron2. I wonder why the learning rate is so small. Have you tried to train the network with larger learning rate?
Thanks

we use adam optimizer, so the base learning rate is just 2.5e-5, if we use larger lr, the network will not converge

Hi Peize
When I read the yaml file that contains learning parameters, I find the base learning rate is just 2.5e-5, which is much smaller than the learning rate (0.02) used in detectron2. I wonder why the learning rate is so small. Have you tried to train the network with larger learning rate?
Thanks

if you want to have more discussion with us, you just can add my wechat: Eureka_Yi

Hi Peize
When I read the yaml file that contains learning parameters, I find the base learning rate is just 2.5e-5, which is much smaller than the learning rate (0.02) used in detectron2. I wonder why the learning rate is so small. Have you tried to train the network with larger learning rate?
Thanks

if you want to have more discussion with us, you just can add my wechat: Eureka_Yi


Enable objcopy for qmake

Enable objcopy for qmake to support separate_debug_info flag for cross-compiled application builds.

Follow the README and send it to<EMAIL_ADDRESS>ML if it's still relevant.
And don't forget to add Signed-off-by line.

@stefansonski - If you submit this via the mailing list, please include the other commits from #49.


Moving zeek process into own package

The zeek pkg introduces the zeek.Launcher func and the zeek.Process
interface. These interfaces allows for test that aren't dependent on
having the zeek binary on the system running the tests.
Additionally passing the pcap reader directly as the zeek process
stdin ensures that we will not get the unfortunate "writing to pipe"
errors that occur when the zeek process is killed during ingest.
For the zqd listen command, if zeek is not available in the system
running the test, disable the packet ingest endpoint and signfy in
the logger output that zeek was not found.

With this change, it would be impossible to run zqd w/o a zeek executable available in path or specified via a cli option. I think we should have some way of doing so, even if that puts out a warning.

Whoops. That was not my intention. If exec.Lookup yielded a not found error I was planning to have it start anyways. It appears I made a mistake there.

I don't think it's a good idea generally to have api routes that are only enabled in certain scenarios; the errors seen when hitting these will be 404's, which aren't as useful in bug reports as "ingest failed: zeek not found".

That's fine. I'll just have it report a 500 error "zeek not found". I don't think it should even attempt ingest.

Whoops. That was not my intention. If exec.Lookup yielded a not found error I was planning to have it start anyways. It appears I made a mistake there.

oh - I may have misread the code, sorry if so. It sounds like we agree on the intention to let zqd run w/o a zeek present.

oh - I may have misread the code, sorry if so. It sounds like we agree on the intention to let zqd run w/o a zeek present.

I have a bug in the code I need to fix.

Thanks, great effort to try get zeek times in Brim close to CLI ones.

I discussed with @mattnibs ; he's going to add back the zeek binary download, and we'll retain at least one test that uses the actual zeek binary to verify the behavior here.
FYI, we do have integration tests in Brim that verify the full round trip of using packet ingest, with a real zeek binary, via the Brim UI, so we do have integration test coverage there as well.


Not Seeing Current Usage and Current Price

Hi there - thanks for making the intergration. I switched from the "rainforest" integration to yours. I got everything installed just fine and was seeing values for the Current Usage and Current Price but after a couple of reboots of HASS core and the full NUC that HASS is running on, I no longer have values for those two entities. The current power consumption still shows as well as the summation values. I would try and get logs but there is nothing of note in the HASS logs for the integration. Here is what I am talking about:

I have also tried unplugging and replugging in the device and can see the current price and current usage on the device. Any thoughts? Thanks!

Should mention I am running core-2022.4.5 and Home Assistant OS 7.6.

Hi @Spiffieman,
Can you use a terminal program such as Termite and to see the serial output of the device?
Specifically for the first field, you should see XML for "CurrentPeriodUsage" that looks something like:
<CurrentPeriodUsage>
  <DeviceMacId>0xd8d5b900000041d7</DeviceMacId>
  <MeterMacId>0x000781000081fd17</MeterMacId>
  <TimeStamp>0x1c90932b</TimeStamp>

This might not be in the output by default, you will probably need to send "get_current_period_usage" to see the response.
I'm guessing this response is either not coming back, or is somehow different from expected...

This is what I am seeing once connected. I am using MINICOM and can't
figure out how to send a command.

0xd8d5b900000117a6
0x001c640013550ae6
0x29f4982d
0x00000000007f4094
0x0000000000000000
0x00000003
0x000003e8
0x04
0x05
Y

0xd8d5b900000117a6
0x001c640013550ae6
0x29f49839
0x000129
0x00000003
0x000003e8
0x03
0x05
Y

On Thu, Apr 21, 2022 at 10:32 AM Ryan Winter @.***>
wrote:

Hi @Spiffieman https://github.com/Spiffieman,
Can you use a terminal program such as Termite
https://www.compuphase.com/software_termite.htm and to see the serial
output of the device?
Specifically for the first field, you should see XML for
"CurrentPeriodUsage" that looks something like:

0xd8d5b900000041d7
0x000781000081fd17
0x1c90932b
This might not be in the output by default, you will probably need to send
"get_current_period_usage" to see the response.
I'm guessing this response is either not coming back, or is somehow
different from expected...
—
Reply to this email directly, view it on GitHub
https://github.com/ryanwinter/hass-rainforest-emu-2/issues/6#issuecomment-1105500399,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASH5EGLGNWWETQNWBKHMT2LVGGGMPANCNFSM5T7ZFU4A
.
You are receiving this because you were mentioned.Message ID:
@.***>

--

Andrew

Press CTRL-A, then 'E' to enable local echo (otherwise you cant see what you are typing), then you should be able to just type in the command and press "Enter".
Otherwise you could always try Screen.

But I can see that the device is sending out the Instantaneous and Summation data automatically which is why those fields are automatically updating. The other fields are requested by the integration.

Ya, that is the weird thing. The other data is coming across into Hass. I
have been trying to send that command and each time I get part way typing
it out, the terminal session freezes and I can't seem to get it to work. I
am SSHing into my Home Assistant from an windows box.
On Thu, Apr 21, 2022 at 4:44 PM Ryan Winter @.***>
wrote:

But I can see that the device is sending out the Instantaneous and
Summation data automatically which is why those fields are automatically
updating. The other fields are requested by the integration.
—
Reply to this email directly, view it on GitHub
https://github.com/ryanwinter/hass-rainforest-emu-2/issues/6#issuecomment-1105860515,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASH5EGPTYTUQIRM3SQFUQU3VGHR55ANCNFSM5T7ZFU4A
.
You are receiving this because you were mentioned.Message ID:
@.***>

--

Andrew

Is this running on a raspberry pi? I wonder if this is related to a previous issue I was seeing where the serial port appeared to be locking up whenever I wrote to the device. I thought it had something to do with my setup, but now I'm wondering if there is a locking issue in the integration.

No, it is running as a vm on a nuc. Using proxmox as the vm software. I
used to have Hass running on a Pi
On Fri, Apr 22, 2022, 10:29 Ryan Winter @.***> wrote:

Is this running on a raspberry pi? I wonder if this is related to a
previous issue I was seeing where the serial port appeared to be locking up
whenever I wrote to the device. I thought it had something to do with my
setup, but now I'm wondering if there is a locking issue in the integration.
—
Reply to this email directly, view it on GitHub
https://github.com/ryanwinter/hass-rainforest-emu-2/issues/6#issuecomment-1106718877,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASH5EGMD37VCHKTLO6YZXDLVGLOZFANCNFSM5T7ZFU4A
.
You are receiving this because you were mentioned.Message ID:
@.***>

Ah, then I think this is the exact issue I ran into! I was running HASS in a WSL2 container and was using USBIP to create the serial node inside the VM. I was basically seeing the integration fail whenever I was writing to the serial port when I had the serial port reading in another module.
I assumed it was just something wrong with my setup, but maybe there is more to it. I'll try and reproduce my issue in WSL2 and see if there is something obvious.
One question, when HASS has been running for a bit, can you look at the power sensor history? Does it look like it is tracking history correctly?

Well. I just went through a crazy process of about 1000 reboots of various
things, the nuc, proxmox host, and hass. I uninstalled the HACS repo and
removed the integration. I then changed the Rainforest device in proxmox to
be a USB 2.0 device instead of 3.0 and the rebooted a bunch of times. I
kept on getting stuck at the selection of the rainforest device when I add
the integration. It just hangs. So I did a couple more reboots and
then.....I got it to load and all of the entities are showing values!
[image: image.png]
I am scared to do another reboot to see if it breaks again (I'll end up
rebooting anyway for one reason or another) and I'll let you know if it
fails again.
I'll check tomorrow morning to see if the history looks correct for the
power entity for you.
On Fri, Apr 22, 2022 at 10:39 AM Ryan Winter @.***>
wrote:

Ah, then I think this is the exact issue I ran into! I was running HASS in
a WSL2 container and was using USBIP to create the serial node inside the
VM. I was basically seeing the integration fail whenever I was writing to
the serial port when I had the serial port reading in another module.
I assumed it was just something wrong with my setup, but maybe there is
more to it. I'll try and reproduce my issue in WSL2 and see if there is
something obvious.
One question, when HASS has been running for a bit, can you look at the
power sensor history? Does it look like it is tracking history correctly?
[image: image]
https://user-images.githubusercontent.com/10238039/164766082-35009edf-7ec5-4b4b-92ef-ef2483c54294.png
—
Reply to this email directly, view it on GitHub
https://github.com/ryanwinter/hass-rainforest-emu-2/issues/6#issuecomment-1106725373,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASH5EGNMUFZGQ2D73OHYGFLVGLP4NANCNFSM5T7ZFU4A
.
You are receiving this because you were mentioned.Message ID:
@.***>

--

Andrew

*I should say, I uninstalled everything and then a bunch of reboots of all
the things, reintalled the HACS repo and tried to set up the integration.
Kept on getting timeouts when selecting the device. I then changed the usb
device to 2.0, rebooted everything (had to reboot the HASS core a couple of
times) and it finally let me choose the correct device. Then, when it got
set up, I saw the right values.
On Fri, Apr 22, 2022 at 11:27 AM Andrew Johnson @.***>
wrote:

Well. I just went through a crazy process of about 1000 reboots of various
things, the nuc, proxmox host, and hass. I uninstalled the HACS repo and
removed the integration. I then changed the Rainforest device in proxmox to
be a USB 2.0 device instead of 3.0 and the rebooted a bunch of times. I
kept on getting stuck at the selection of the rainforest device when I add
the integration. It just hangs. So I did a couple more reboots and
then.....I got it to load and all of the entities are showing values!
[image: image.png]
I am scared to do another reboot to see if it breaks again (I'll end up
rebooting anyway for one reason or another) and I'll let you know if it
fails again.
I'll check tomorrow morning to see if the history looks correct for the
power entity for you.
On Fri, Apr 22, 2022 at 10:39 AM Ryan Winter @.***>
wrote:

Ah, then I think this is the exact issue I ran into! I was running HASS
in a WSL2 container and was using USBIP to create the serial node inside
the VM. I was basically seeing the integration fail whenever I was writing
to the serial port when I had the serial port reading in another module.
I assumed it was just something wrong with my setup, but maybe there is
more to it. I'll try and reproduce my issue in WSL2 and see if there is
something obvious.
One question, when HASS has been running for a bit, can you look at the
power sensor history? Does it look like it is tracking history correctly?
[image: image]
https://user-images.githubusercontent.com/10238039/164766082-35009edf-7ec5-4b4b-92ef-ef2483c54294.png
—
Reply to this email directly, view it on GitHub
https://github.com/ryanwinter/hass-rainforest-emu-2/issues/6#issuecomment-1106725373,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASH5EGNMUFZGQ2D73OHYGFLVGLP4NANCNFSM5T7ZFU4A
.
You are receiving this because you were mentioned.Message ID:
@.***>

--

Andrew

--

Andrew

I'll close this for now. There is definitely something wrong with the setup loop, if you have more issues let me know and I'll try and add more debugging.


chore: fix coverage.include

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

Project coverage is 97.15%. Comparing base (de483d1) to head (dd3c70d).
Report is 1 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff            @@
##           main     #239       +/-   ##
=========================================
+ Coverage      0   97.15%   +97.15%
=========================================
  Files         0        8        +8
  Lines         0      281      +281
  Branches      0       24       +24
=========================================
+ Hits          0      273      +273
- Misses        0        7        +7
- Partials      0        1        +1

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


Move code for hOCR renderer to new file

For consistrncy, I suggest to move all the remaining renderers out of baseapi.cpp.


Add dict-style query comment docs

Description & motivation
Adds docs for 0.16.0:

dict-style query comments with append option

Hey, can we put a hold on this for a minute? I'm working on this part of the docs today!


Breaking change in minor revision

Hi,
Just wanted to mildly complain that the 3.17.1 version of vscode-languageserver-protocol is actually a breaking change relative to the previous 3.16.0 version.
According to semantic versioning it shouldn't be a breaking change but due to it bumping vscode-jsonrpc from version  6 to 8, it has caused node version requirements to change from v8 (or so) to v14 and caused https://github.com/typescript-language-server/typescript-language-server/issues/466
We have to move on at some point so requiring node 14 is not necessarily a bad thing but then the parent vscode-languageserver-protocol should also get a major version bump. I don't necessarily want this to be addressed now but considered in the future at least when similar situation occurs.
There is also another issue that might actually be actionable for this report. The vscode-languageserver dependency, that I'm also using in the same project, has vscode-languageserver-protocol pinned to version 3.16.0 so if I upgrade vscode-languageserver-protocol to the latest version, my project will end up with two different versions of that library. And that's never a good thing.

This is a known problem with how we version the protocol extension and we decided a long time ago to reflect the protocol version number against the specification and not a pure semantic version.
I agree that this should be documented in the readme though.

Thanks for the explanation, it makes sense.


Create testing pipeline for bulk schema testing

The https://github.com/OpenAPITools/openapi-generator project has a treasure trove of schemas that can be used to find any bugs that this package may have. They require that regression tests be added after bugs are found, this means that these schemas contain almost every combination that could confuse a generator.
A quick way to help validate that this package works well is to do the following for each schema:

Generate a sample Package
Build a schema
Run the analyzer

If any of these steps fail, it means that there is a problem.
This draft PR will work on creating this pipeline.
Thoughts?

@dickermoshe Hi, thank you for your contribution. I had plans to add more schemas from such sources to e2e tests, which scheme generates content and compares it with a sample (expected result, which is also easy to regenerate if needed).
Can you elaborate on the steps in your testing process? And how does it differ from the current implementation of E2E tests?
There are some comments:
The analyzer, let's say, will not always be able to let us know if the api clients and models were generated correctly.
Maybe we need some kind of pattern matching mechanism to have a more reliable and easy to maintain way of testing.
We need to look into performance, as creating packages and running the generator can take a long time, especially for hundreds of patterns.
We need to keep in mind that initially we are unlikely to be able to support correct generation of absolutely all tests.
I would like to discuss more on this topic to come up with a good testing method by which we can ensure the reliability of this package, so I fully support your contribution.

Pipeline Overview
The steps in the pipeline closely resemble what a user goes through when using the library.
It generates a new dart project, installs swagger_parser from source and the remaining dependencies from pub.dev.
It then creates a swagger_parser_config.yaml for each schema, runs swagger_parser, runs build_runner and finaly the dart analyzer to check for any static errors.
Package Health
This package right now is really broken. In my personal experience it failed every time I've used it.
However there wasn't logical bugs, it just wouldn't compile. Many times swagger_parser failed on valid schemas, other times the build_runner would crash and sometimes the generated code had static errors. I've then went back to using the other OpenAPI generators which work, but have horrible devX.
Static Testing
Writing E2E tests that cover every schema is really hard. Hopefully one day they'll be written. But in the short term writing tests the this package works at all should be a first step.
CI/CD
I'm not arguing for adding to the CI pipeline at this time. It needs to be optimized. I would view this more a development tool to fix the vast amount bugs in the package now. Instead of playing whack-a-mole with Github issues, I'm providing you with 500 hammers to hit all the moles at once.
Developer Trust
Users of a client generator need to trust the developers. Very few are validating the generated code themselves. being handed generated code that doesnt even compile due to static errors really destroys any trust.
So even if:

We need to keep in mind that initially we are unlikely to be able to support correct generation of absolutely all tests.

That should result in a nice error message being thrown, not broken code.
Thanks
I really want to thank you for your work on this package. It's really great.

@dickermoshe Thanks for the detailed reply, I understand the basic idea.
I agree with you that there are still a lot of uncovered cases and need an approach to solve the problems efficiently.
There are some problems with running the generator not directly from the test, but with cli.
The current e2e implementation uses the GenProcessor directly, which allows the debugger to be used. This is a very important aspect that allows you to quickly find and fix errors that occur. Without this, tests lose their main usefulness, especially if we want to use them as a development tool.
I agree that it would also be good to check generated code for static errors and build_runner issues.
I'm not sure that writing e2e tests is hard right now, because we can just take all these schemas directly.
I think we need a system for tests that can generate code according to a pattern and check it for static and build_runner bugs, but also be able to debug and compare to a sample (expected generation) when we have the correct generation and want to avoid regressions. If we can variably customize these parameters (whether static and build_runner should be checked, whether it should compare to a sample, and so on), we can develop a system with which we can efficiently develop the package

I used the cli for doing this because I don't know of any way to statically analyze dart code across multiple files without actually writing them to disk.

I'll migrate the code generation to use the built in GenProcessor.

I've separated the generation, build runner and analyzer into 3 steps.
Run just the testSwaggerParserGeneration tests for now.
I'm new to this whole testing world, so lmk if there is anything I should change.

This is the python script I used to extract the schemas from https://github.com/OpenAPITools/openapi-generator btw
from pathlib import Path
dest_dir = Path("dest")
dest_dir.mkdir(exist_ok=True)
current_dir = Path.cwd()
dest_names = []
for i in current_dir.glob("**/*.yaml"):
    if "openapi: " in i.read_text(encoding="utf8"):
        dest_name = i.name
        if dest_name in dest_names:
            dest_name = f"{i.parent.name}__{i.name}"
        dest_names.append(dest_name)
        dest_file = dest_dir / dest_name
        with dest_file.open("w", encoding="utf8") as dest_file:
            dest_file.write(i.read_text(encoding="utf8"))

@StarProxima

I'm not sure that writing e2e tests is hard right now, because we can just take all these schemas directly.

If it can't generate, build and pass static analysis, you can't do e2e testing.
One thing at a time

I've marked the tests as skip so that CI shouldn't run these just yet.
You will need to use --run-skipped to run these tests.
For now, to run these tests use:
dart test --run-skipped  .\test\static\static_test.dart
To run a single test use:
https://github.com/dickermoshe/swagger_parser/blob/a0050de349187f450545b417c9b6dae314f57abe/swagger_parser/test/static/static_test.dart#L15-L18

@Carapacik
@StarProxima
At this time swagger_parser doesn't crash on valid schemas.
However there are a whole bunch of issue that result in bad code being generated.
I've filed many bugs but haven't had the time to investigate each one manually.
There are 2 that are related to retrofit, one can be worked around, the other will need retrofit to be fixed.
Will you have time you work on these and how clear are the issues?


Fix NestedLoopJoin performance regression

Which issue does this PR close?
Closes #12528.
Rationale for this change
Iterating over the right rows instead of the left while calling build_join_indices increased the number of calls to apply_join_filter_to_indices in cases where the right table has more rows (which applies to most common use cases). Building the indices inside build_join_indices helps reduce the number of calls to apply_join_filter_to_indices
What changes are included in this PR?
This PR builds the indices in one go inside build_join_indices, removing the outer iteration, and reduces the number of calls to apply_join_filter_to_indices to 1 per join_left_and_right_batch call.
Are these changes tested?
--- To be added
Are there any user-facing changes?
Only performance changes.

/benchmark


HTTPError (400) when trying to load a database despite trying proposed solutions

Getting the following error when trying to load a database; I saw #385 #389 with similar issues, but this happens to me when trying to use client.get_collection. I noticed the solution pointed out here; however, I still get the same errors.
Traceback (most recent call last):
  File "/home/revise/Documents/code/strava-notion.py", line 74, in <module>
    update_notion()
  File "/home/revise/Documents/code/strava-notion.py", line 66, in update_notion
    notion_client, cv = get_notion_client()
                        ^^^^^^^^^^^^^^^^^^^
  File "/home/revise/Documents/code/strava-notion.py", line 57, in get_notion_client
    cv = client.get_collection(notion_database)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/revise/Documents/code/lib/python3.11/site-packages/notion/client.py", line 185, in get_collection
    coll = self.get_record_data(
           ^^^^^^^^^^^^^^^^^^^^^
  File "/home/revise/Documents/code/lib/python3.11/site-packages/notion/client.py", line 162, in get_record_data
    return self._store.get(table, id, force_refresh=force_refresh)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/revise/Documents/code/lib/python3.11/site-packages/notion/store.py", line 186, in get
    self.call_get_record_values(**{table: id})
  File "/home/revise/Documents/code/lib/python3.11/site-packages/notion/store.py", line 254, in call_get_record_values
    results = self._client.post(
              ^^^^^^^^^^^^^^^^^^
  File "/home/revise/Documents/code/lib/python3.11/site-packages/notion/client.py", line 260, in post
    raise HTTPError(
requests.exceptions.HTTPError: Something went wrong. (400)

Are there any other workarounds?

I got the same error but I got it working by reducing limits at two places (the solution you linked only had it in one place):

Line 280
Line 329

After this I was able to both load the collection and then also save to it

Ah I found out that the code installed by git is 2 years old.
The newest issues have been fixed in the main branch though.
All my issues were solved once I added this to my requirements.txt:
git+https://github.com/jamalex/notion-py.git

I've tried this multiple times over the last few months, yet it still yields the same HTTPError.  I've added git+https://github.com/jamalex/notion-py.git into my requirements.txt (and a quick inspection of store.py verifies that the installation is indeed the correct one), and I'm still running into this problem.
Maybe automating this project wasn't meant to be :shrug:


Memory overflow

I have a case on 4 nodes that has an unbounded memory usage. The job ends up being killed by the job scheduler. I monitored the memory usage right before the job gets killed (about 1h after it started, the average time per iteration is < 0.1s) using free -m every 10 seconds, the average growth of the memory usage was 5.7MB/s. Doing the same right after start-up, the growth rate was about 24MB/s. This doesn't seem to happen, even after start-up, in anyone of the following cases:

on master, on 2 nodes
on master, without -dm:memoize
on control_replication

What is needed next to debug this?

Is #1327 the only thing preventing you from running on control_replication?

Not sure if the two are related. The buggy attach/detach operation is preventing me from using control_replication because my checkpoint files are corrupted.

Can you not switch to using index space attach/detach?

I looked briefly at the interface and I assume an index attach/detach requires attaching one file per rank. I don't know if this would allow me to restart with a different number of ranks since the map from elements to ranks (and the order) will be completely different.

Index attach/detach operations are just like index space tasks: you can define your own index space for them. There's no need to make them one per rank. You can even have an asymmetrical number of "point" attach operations in each shard of a control replication context. You'll need to figure out which shard does the attach for each file, but it's totally acceptable to have a different number of shards and files.
This example might be helpful:
https://gitlab.com/StanfordLegion/legion/-/blob/control_replication/examples/attach_index_space/index_space_attach.cc

My previous code looked like this
    AttachLauncher attach_launcher(EXTERNAL_HDF5_FILE, restart_lr, restart_lr, false, false);
    attach_launcher.attach_hdf5(file_name.c_str(), field_map, LEGION_FILE_READ_WRITE);
    restart_pr = runtime->attach_external_resource(ctx, attach_launcher);
    restart_pr.wait_until_valid(true /*silence warnings*/);

    // copy launcher from solution_lr to restart_lr

    Future f = runtime->detach_external_resource(ctx, restart_pr);
    f.get_void_result(true /*silence warnings*/);

I am trying to get shard 0 dump the entire content of solution_lr to a single hdf5 file (performance is not an issue here since I do this every N iterations with N large). I modified the code to this
    IndexAttachLauncher launcher(EXTERNAL_HDF5_FILE, restart_lr, false /*restricted*/);
    launcher.privilege_fields.insert(FID_SOL_COEFF_0_START); // seems needed
    if (runtime->get_shard_id(ctx, true /*silence warnings*/) == 0) {
        // only shard 0 is in charge of dumping the restart file for the entire region
        launcher.attach_hdf5(restart_lr, file_name.c_str(), field_map, LEGION_FILE_READ_WRITE);
    }
    resources = runtime->attach_external_resources(ctx, launcher);
    resources[0].wait_until_valid(true /*silence warnings*/);

    // same copy launcher (commented)

    runtime->detach_external_resources(ctx, resources).get_void_result(true /*silence warnings*/);

Currently I hit this assertion
Thread 4 (Thread 0x2aaaaab80940 (LWP 57354)):
#0  0x00002aaab7ef69fd in nanosleep () from /lib64/libc.so.6
#1  0x00002aaab7ef6894 in sleep () from /lib64/libc.so.6
#2  0x00002aaab5420942 in Realm::realm_freeze (signal=6) at /nobackupp17/kbando/Softwares/legion/runtime/realm/runtime_impl.cc:179
#3  <signal handler called>
#4  0x00002aaab7e67387 in raise () from /lib64/libc.so.6
#5  0x00002aaab7e68a78 in abort () from /lib64/libc.so.6
#6  0x00002aaab7e601a6 in __assert_fail_base () from /lib64/libc.so.6
#7  0x00002aaab7e60252 in __assert_fail () from /lib64/libc.so.6
#8  0x00002aaab395fac3 in Legion::Internal::AllGatherCollective<false>::~AllGatherCollective (this=0x2aba7c27aec0, __in_chrg=<optimized out>) at /nobackupp17/kbando/Softwares/legion/runtime/legion/legion_replication.cc:11061
#9  0x00002aaab395352c in Legion::Internal::IndexAttachCoregions::~IndexAttachCoregions (this=0x2aba7c27aec0, __in_chrg=<optimized out>) at /nobackupp17/kbando/Softwares/legion/runtime/legion/legion_replication.cc:15190
#10 0x00002aaab3953548 in Legion::Internal::IndexAttachCoregions::~IndexAttachCoregions (this=0x2aba7c27aec0, __in_chrg=<optimized out>) at /nobackupp17/kbando/Softwares/legion/runtime/legion/legion_replication.cc:15193
#11 0x00002aaab3938ea0 in Legion::Internal::ReplIndexAttachOp::deactivate (this=0x2aba7c275800) at /nobackupp17/kbando/Softwares/legion/runtime/legion/legion_replication.cc:7097
#12 0x00002aaab380b671 in Legion::Internal::Operation::commit_operation (this=0x2aba7c275800, do_deactivate=true, wait_on=...) at /nobackupp17/kbando/Softwares/legion/runtime/legion/legion_ops.cc:2013
#13 0x00002aaab385961e in Legion::Internal::IndexAttachOp::trigger_commit (this=0x2aba7c275800) at /nobackupp17/kbando/Softwares/legion/runtime/legion/legion_ops.cc:21108
#14 0x00002aaab380b396 in Legion::Internal::Operation::complete_operation (this=0x2aba7c275800, wait_on=...) at /nobackupp17/kbando/Softwares/legion/runtime/legion/legion_ops.cc:1961
#15 0x00002aaab380a15e in Legion::Internal::Operation::trigger_complete (this=0x2aba7c275800) at /nobackupp17/kbando/Softwares/legion/runtime/legion/legion_ops.cc:1593
#16 0x00002aaab380ae64 in Legion::Internal::Operation::complete_execution (this=0x2aba7c275800, wait_on=...) at /nobackupp17/kbando/Softwares/legion/runtime/legion/legion_ops.cc:1875
#17 0x00002aaab385919b in Legion::Internal::IndexAttachOp::trigger_ready (this=0x2aba7c275800) at /nobackupp17/kbando/Softwares/legion/runtime/legion/legion_ops.cc:21038
#18 0x00002aaab36e0b53 in Legion::Internal::InnerContext::process_ready_queue (this=0x2aba78407f60) at /nobackupp17/kbando/Softwares/legion/runtime/legion/legion_context.cc:8068
#19 0x00002aaab36ede68 in Legion::Internal::InnerContext::handle_ready_queue (args=0x2aba740bf950) at /nobackupp17/kbando/Softwares/legion/runtime/legion/legion_context.cc:11208
#20 0x00002aaab3c1d7df in Legion::Internal::Runtime::legion_runtime_task (args=0x2aba740bf950, arglen=12, userdata=0x4e6cff090, userlen=8, p=...) at /nobackupp17/kbando/Softwares/legion/runtime/legion/runtime.cc:31420
#21 0x00002aaab53ffc00 in Realm::LocalTaskProcessor::execute_task (this=0x4b4dc10, func_id=4, task_args=...) at /nobackupp17/kbando/Softwares/legion/runtime/realm/proc_impl.cc:1135
#22 0x00002aaab5467fda in Realm::Task::execute_on_processor (this=0x2aba740bf7d0, p=...) at /nobackupp17/kbando/Softwares/legion/runtime/realm/tasks.cc:302
#23 0x00002aaab546cb6c in Realm::UserThreadTaskScheduler::execute_task (this=0x4b4df50, task=0x2aba740bf7d0) at /nobackupp17/kbando/Softwares/legion/runtime/realm/tasks.cc:1632
#24 0x00002aaab546abf2 in Realm::ThreadedTaskScheduler::scheduler_loop (this=0x4b4df50) at /nobackupp17/kbando/Softwares/legion/runtime/realm/tasks.cc:1105
#25 0x00002aaab54725f2 in Realm::Thread::thread_entry_wrapper<Realm::ThreadedTaskScheduler, &Realm::ThreadedTaskScheduler::scheduler_loop> (obj=0x4b4df50) at /nobackupp17/kbando/Softwares/legion/runtime/realm/threads.inl:97
#26 0x00002aaab547fdf1 in Realm::UserThread::uthread_entry () at /nobackupp17/kbando/Softwares/legion/runtime/realm/threads.cc:1337
#27 0x00002aaab7e79190 in ?? () from /lib64/libc.so.6
#28 0x0000000000000000 in ?? ()

What am I doing wrong?

If you go to frame 17 in gdb and run print this->points.size() what does it show as the result?

#17 0x00002aaab385919b in Legion::Internal::IndexAttachOp::trigger_ready (this=0x2aba7c274e70) at /nobackupp17/kbando/Softwares/legion/runtime/legion/legion_ops.cc:21038
21038           complete_execution(Runtime::protect_event(done));
(gdb) print this->points.size()
$1 = 0

We weren't handling the case where a shard had an empty set of local instances correctly. Pull and try again.

The bug above is fixed. Switching to an index attach/detach does not fix the original bug with the same missing copies and, as a result, corrupted checkpoint files. This goes away (at least on a small reproducer) without -dm:memoize or if I disable all other outputs (at least for a particular run, I haven't re-run all the cases that I need). I am going to see if this is sufficient for what I need to do. If not, I don't have a way currently to work around this.

Can you make some new detailed Legion Spy logs? One set with -dm:memoize and one without. I'll still need to look at them manually because I know there are still sharp edges with Legion Spy on multi-node with control replication.

In this run, I have 2 types of HDF5 outputs, one that attaches within an index launch then writes the entries manually with standard READ_WRITE privileges on the output region, and one that index attaches within top-level (only rank 0 calls to launcher.attach_hdf5 as described above) and issues a CopyLauncher to directly dump the content of a region. I have in total 10 outputs of the second type and the 10th one has missing entries (2 missing points in each rank corresponding to the shared elements, the domain being 1D and periodic).
With -dm:memoize:
log_0.log
log_1.log
Without -dm:memoize:
log_0.log
log_1.log

Legion Spy's physical verification analysis is not going to be of any help on these logs in its current state since it still doesn't understand control replication.
Do both of these graphs get the wrong answer or just one of them? They are similar, but differ in small parts. Can you give the UID of the detach operations which are getting the wrong answer? (I recommend using Acrobat Reader to view the PDFs).
nomemo.pdf
memo.pdf

nomemo.pdf gets the right answer, memo.pdf doesn't.
memo.pdf (last round of output which is the one with missing copies):

I do an index launch where only point 0 creates the HDF5 file. The task's name is create_restart_file_task with UID 2714 for point 0 and UID 2671 for point 1. I would expect arrows going out of these boxes since I wait on all futures before continuing but I don't see them in nomemo.pdf as well.
The attach/detach op to look at are respectively of UID 2722 and 2732.
You can see that there are only 2 Realm copy op 2728 for field 3. If you look at the previous one, there are 4 Realm copy op 2488. The two missing copies are exactly the ones missing in the hdf5 file.

nomemo.pdf (same):

create_restart_file_task with UID 2920 for point 0 and 2877 for point 1
attach/detach op with respective UID 2934 and 2944
we see 4 Realm copy op 2940 boxes for field 3 which is the correct behavior

You can see that there are only 2 Realm copy op 2728 for field 3. If you look at the previous one, there are 4 Realm copy op 2488. The two missing copies are exactly the ones missing in the hdf5 file.

I'm not convinced of that yet.  Without actually doing the index space math on those expressions we can't say for sure. I'll try to look into that tomorrow, but if you want to do the math ahead of time that would be helpful. (Just remember, it's possible that the names of index spaces might represent different sets of points in each of the runs.)
Can you also generate a logfile that captures the trace output: -lg:dump_physical_traces -level tracing=2 -lg:parallel_replay 1 ?

The postconditions for the trace do look pretty strange:
[1 - 2aaaaab83980]    0.640554 {2}{tracing}: [Precondition]
[1 - 2aaaaab83980]    0.640571 {2}{tracing}:   Materialized view: 0x2aba6c09b6f0, Inst:<PHONE_NUMBER>000020, Index expr: 138, Name: mesh_elem_logical_re
gion, Field Mask:<PHONE_NUMBER>0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
[1 - 2aaaaab83980]    0.640617 {2}{tracing}:   Materialized view: 0x2aba6c09bf10, Inst:<PHONE_NUMBER>000021, Index expr: 131, Name: mesh_elem_logical_re
gion, Field Mask:<PHONE_NUMBER>0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
[1 - 2aaaaab83980]    0.640628 {2}{tracing}:   Materialized view: 0x2aba6c08d740, Inst:<PHONE_NUMBER>00001c, Index expr: 131, Name: sol_lr, Field Mask:<PHONE_NUMBER>0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
[1 - 2aaaaab83980]    0.640636 {2}{tracing}:   Materialized view: 0x2aba6c054fc0, Inst:<PHONE_NUMBER>000013, Index expr: 138, Name: mesh_elem_logical_region, Field Mask:<PHONE_NUMBER>0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
[1 - 2aaaaab83980]    0.640644 {2}{tracing}:   Materialized view: 0x2aba6c0222e0, Inst:<PHONE_NUMBER>00000d, Index expr: 105, Name: mesh_iface_logical_region, Field Mask:<PHONE_NUMBER>0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
[1 - 2aaaaab83980]    0.640651 {2}{tracing}:   Materialized view: 0x2aba6c08cc60, Inst:<PHONE_NUMBER>00001d, Index expr: 138, Name: sol_lr, Field Mask: 0E000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
[1 - 2aaaaab83980]    0.640658 {2}{tracing}:   Materialized view: 0x2aba6c08f330, Inst:<PHONE_NUMBER>00001e, Index expr: 138, Name: sol_lr, Field Mask:<PHONE_NUMBER>0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
[1 - 2aaaaab83980]    0.640665 {2}{tracing}:   Materialized view: 0x2aba6c08fe50, Inst:<PHONE_NUMBER>00001f, Index expr: 131, Name: sol_lr, Field Mask:<PHONE_NUMBER>0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
[1 - 2aaaaab83980]    0.640672 {2}{tracing}:   Materialized view: 0x2aba70099b50, Inst:<PHONE_NUMBER>000023, Index expr: 105, Name: mesh_iface_logical_region, Field Mask:<PHONE_NUMBER>0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
[1 - 2aaaaab83980]    0.640677 {2}{tracing}: [Anticondition]
[1 - 2aaaaab83980]    0.640683 {2}{tracing}: [Postcondition]
[1 - 2aaaaab83980]    0.640692 {2}{tracing}:   Materialized view: 0x2aba6c08d740, Inst:<PHONE_NUMBER>00001c, Index expr: 131, Name: sol_lr, Field Mask:<PHONE_NUMBER>0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
[1 - 2aaaaab83980]    0.640699 {2}{tracing}:   Materialized view: 0x2aba6c08cc60, Inst:<PHONE_NUMBER>00001d, Index expr: 138, Name: sol_lr, Field Mask: 0E000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

[0 - 2aaaaab70980]    0.711975 {2}{tracing}: [Precondition]
[0 - 2aaaaab70980]    0.711979 {2}{tracing}: [Anticondition]
[0 - 2aaaaab70980]    0.711982 {2}{tracing}: [Postcondition]

The fact that shard trace for node 0 doesn't have any precondition or postcondition is quite unusual. It possible for that to occur if everything was sharded to the other node, but that seems quite surprising if it is occurring.

Is there a way for me to run the 2-node version of this code on sapling? (Does it need two nodes to reproduce or can it happen with just one?) Anything you can do to simplify the example code down would be helpful. It's almost certainly a bug in how the tracing code is computing its postconditions.

To run the reproducer, please do
cd /scratch2/bandokihiro/Issue1329/test
sbatch runslurm.sh

This will launch a 2-rank job on a single cpu node. It doesn't reproduce with 1 rank. To check, you can do
h5dump restarts/restart_00000020.h5

and you'll see that the last 4 points are zeros.
To make changes, the legion source is at /scratch2/bandokihiro/Issue1329/legion. To update (from a cpu node, using CMake),
cd /scratch2/bandokihiro/Issue1329/legion/build
make install
cd /scratch2/bandokihiro/Issue1329/DG-Legion/build
make solver

Can you rebuild just Legion in a full debug mode with -DDEBUG_LEGION as well? The optimizations are just getting in the way a bit too much to make debugging practical. I expect that the problem will still be there even with a full debug build.

Done. And yes, it reproduces in debug mode.

I made some changes to Legion and followed the directions above to rebuild, but I received a ton of link errors on the solver with missing Legion symbols. Are you sure the instructions are right? Maybe they need to change because of the debug build?

Not sure, I had the same errors. I had to start with a make clean on both. Then it built.

(Yet another reason I don't like cmake).
Pull and try again. I'm pretty sure I pushed a fix for the issue. Surprisingly it didn't have anything specific to do with tracing. Tracing a bunch of operations was just altering the equivalence set refinement that the runtime was selecting.

Confirmed and closing.


Define watcher directly when defining data property

What problem does this feature solve?
Imagine we have a function that build a form model for us base on some input.
data () {
    return {
      formErrors: formErrorsModel()
    }
}

If we want to watch those field, we need to define it separately from the function that generate the model. I think it would make sense to define it directly on the data itself.
What does the proposed API look like?
data () {
    return {
      formErrors: {
         value: 'some value',
         watch: function () {}
      }
    }
}

This would limit objects defined in data. If it's something you want to create in your own project you can still create a global mixin that checks the data properties in a created hook through $data and creates the watchers for you


[Bug] Debugger doesnt return to command line when using RobotCode in combination with ScreenCapLibrary

SUMMARY:
When using the robotcode extension, RF doesn't return to the commandline after finishing a testcase.
RF: 4.1.3 and 6.0.2
extension version: 0.28.2
SCENARIO:
Install ScreenCapLibrary
Add 'Start Video Recording' to the TestSetup
Add 'Stop Video Recording' to the TestTearDown
Run a simple testcase logging something
RESULT:

RF log and report get created (OK)
WEBM-file (video) files get created (OK)
It doesnt return to the command line. (NOT OK, see picture)
when trying to start a 2nd test run, it say 'Can't connect to debugger' (see picture)

ok, I checked and found out that the ScreenCapLibrary is deleting the running ThreadPoolExecutor queues from the Python interpreter.
see here: https://github.com/rticau/ScreenCapLibrary/blob/146304edac5a062a39f6c738a0516212acbd0197/src/ScreenCapLibrary/client.py#L37
and here
https://github.com/rticau/ScreenCapLibrary/blob/146304edac5a062a39f6c738a0516212acbd0197/src/ScreenCapLibrary/client.py#L252
This worked under Python 3.8, because the thread queues were still daemon threads. Daemon threads are simply killed by Python on shutdown.
In new Python version it is tried to shutdown these ThreadPoolExecutor threads reasonable, but because the list of ThreadPoolExecutor threads is empty now, because it is deleted by the ScreenCap library, there are still threads running in the background, which are not terminated correctly.
That's why the debugger hangs, because it also runs ThreadPoolExecutor, but since Python doesn't know that it exists anymore, it won't be terminated.
From my point of view this must be corrected in the ScreenCapLibrary, because it not only affects the RobotCode debugger, but probably also other libraries, I know that the BrowserLibrary also uses ThreadpoolExecutors.
I would prefer not to implement a workaround only for a library that hacks the Python interpreter ;-)
I created an issue  in the ScreenCapLibrary project, let's see what happens.
A workaround at the moment is to hack ScreenCapLibrary, just change this line: https://github.com/rticau/ScreenCapLibrary/blob/146304edac5a062a39f6c738a0516212acbd0197/src/ScreenCapLibrary/client.py#L252
like this:
    @staticmethod
    def clear_thread_queues():
        # _threads_queues.clear()
        pass

Hi Daniel,
Thanks for investigating the issue and for providing a workaround!
Daniel

@d-biehl,
I applied the solution you provided locally. Works for me.
I guess this issue can be closed.
Daniel

ok, thanks for feedback!
and maybe you can give this issue a thump up https://github.com/rticau/ScreenCapLibrary/issues/84


Change text colour on iOS in version 2.0.4

Hello!
I am using this plugin (version 2.0.4) and I am displaying a toast with a yellow background. I apparently cannot change the text colour on iOS (Haven't tested on Android yet) and that is really annoying because MessageView has private properties for it:
private static readonly UIColor TitleColor;
private static readonly UIColor DescriptionColor;

I have tried to find a working commit of version 2.0.4 so I can modify the plugin myself so I can do what I want, but no commit of version 2.0.4. is available... and other versions that seem like they are version 2.0.4.  (https://github.com/EgorBo/Toasts.Forms.Plugin/tree/6e6c4271de23ffed73381c3aadacc90f3bd1c128) do not seem to build because they were pushed before they were tested.
Can someone tell me how I could change the text colour or can someone point me to a commit that allows me to modify the 2.0.4. version?

@EgorBo @adamped I would love some help with this :)

@EgorBo @adamped I have the same issue.

@sander1095 @Boeves - its been a while, but can you change it via a custom renderer. You can view this old version of the Readme for an example: https://github.com/EgorBo/Toasts.Forms.Plugin/blob/6ac9479c86d39d1eb8d5026bdb1fc10e14ec0acb/README.md

Not for iOS.

On iOS a class has to be created inherits from MessageBarStyleSheet.

Then you can override 3 methods:

BackgroundColorForMessageType()
IconImageForMessageType()
StrokeColorFOrMessageType()

There is nothing that can be done to change the text color. The text color is defined in MessageView which cannot be changed. The example in the readme is for Windows phone.

On Android it isn't possible either I think, I have to inherit from IToastLayoutCustomRenderer and then fill the Render method. I do not know much about the View class on Android but I cannot see a SetTextColor method or something like that.

Unfortunately I can not help with this because the version is very outdated, and no longer supported. You will have to download the source code for that version and modify yourself to get this feature.

Downloading the source code is tricky because there is no commit related to 2.0.4. Can you help with this?
In the future, add a version identifier to commits or make use of the Releases system in Github? Finding specific versions is not an easy task in this repo..
The only version close to the release of 2.0.4 is
https://github.com/EgorBo/Toasts.Forms.Plugin/tree/6e6c4271de23ffed73381c3aadacc90f3bd1c128
That version is not usable because before it was committed it wasn't built to see if it worked. It doesn't. Files are missing and that is why I opened the issue.

I have a forked repo at 2.0.4: https://github.com/adamped/Toasts.Forms.Plugin

Thanks!


Include example of defer lexical scoping

This patch adds an example of how the defer statement is lexically scoped and will execute at the end of the scope, not the end of a function.

Thanks for adding this.  Some general thoughts:
I agree with Kyle that we're better not introducing the term "lexical scope" here.  Do you think that's something a developer is likely to encounter on blog posts on on Swift Evolution discussions?  If so, what we've done elsewhere is something like this:

The defer statement executes at the end of the scope that it appears in.
This behavior is sometimes called lexical scoping.

The three part intro-code-explanation structure is very common in the guide, but not so much in the reference.  What do you think about adding a some detail to the guide?  I could try expanding what you wrote and adding to the the Error Handling chapter's discussion of defer.  I'd be interested if you think there's a good way to add defer as early as Control Flow, since it's a general flow-control construct, not tied to error handling.  (For my future reference, the "not just error handling" enhancement is rdar://34173603)
As a process suggestion, could you please avoid rebasing and force-pushing to an open pull request?  It makes things more difficult to review.  For example, I started looking at this on Friday, and now it's hard for me to see what changed between that version and the current version.

I agree with Kyle that we're better not introducing the term "lexical scope" here. Do you think that's something a developer is likely to encounter on blog posts on on Swift Evolution discussions? If so, what we've done elsewhere is something like this:

I can drop the lexical scope. It only seems to show up in SE-0025 and SE-0311, so it isn't terribly common in the evolution proposals. It is used a bit more on the forums, but I don't think it's required for someone just starting out with Swift.

The three part intro-code-explanation structure is very common in the guide, but not so much in the reference. What do you think about adding a some detail to the guide?

Yeah, it probably makes sense to add a description in the Control Flow part of the guide. It looks like the description of defer in Error Handling is pretty minimal and could probably even stay there, just a revisitation to show how it can tie in with error handling, kind of like how guard makes a small reappearance.

As a process suggestion, could you please avoid rebasing and force-pushing to an open pull request? It makes things more difficult to review. For example, I started looking at this on Friday, and now it's hard for me to see what changed between that version and the current version.

Sorry about that, everyone has different processes. Here's the diff between the original PR and the rebased PR: https://github.com/apple/swift-book/compare/2856a799f3d2fd0a679a3bc17b6c02852e47799a..fb2bbba0dd9060c2a0fdc5a58e233f535ec7f2e9

This looks pretty good to me.  I made a commit c2d76bd1 to wrap the text as described in the TSPL style guide.
Thanks for adding the swifttest block — that will make backporting this change into the published version faster.
I'd to add some discussion under Control Flow here too, unless you'd prefer to keep this PR focused on just the small addition.  I can push to your branch later this afternoon.

I'd to add some discussion under Control Flow here too, unless you'd prefer to keep this PR focused on just the small addition. I can push to your branch later this afternoon.

Whatever works. I'm happy as long as there is something describing when defers fire that is a little more interesting than just the function scope.

I've sketched some additions to the guide, but there's enough work to do there that I don't want to hold this PR waiting for it.  I'll push those changes on a separate branch.

@swift-ci Please test.


Switch to using URL instead of NSString to determine base URL

Closes #844
The test does not work
It's crapping out when trying to run pkg.productCounts() due to:

Fatal error: Children relation not eager loaded, use $ prefix to access: Children<Version, Product>(for: [version_id]): file FluentKit/Children.swift, line 33
2020-12-06 20:32:07.626463+0000 xctest[18804:5885046] Fatal error: Children relation not eager loaded, use $ prefix to access: Children<Version, Product>(for: [version_id]): file FluentKit/Children.swift, line 33

If someone wouldn't mind pointing me in the right direction that'd be much appreciated 🙏  I've locally run a test using the new approach and it seems to be a bit happier 👍
There is one minor change that the new URL will have a trailing slash, so I've updated the JS to handle this.

I know why that's happening - I'll fix it tomorrow, no worries!


Local dependencies

You just drop the JavaScript libraries in the js directory and the gem will automatically load them when called with -l argument, l for local.

Okay I wrote this in exe/dirtree file but I have no idea why the output html file doesn't work!
if options[:local_dependencies]
  scripts = result.scan(/(<script src="(.+)"><\/script>)/)
  script_t = scripts.transpose
  script_t[0].each do |script|
    src = script_t[1].shift
    result.gsub!(script,"<script>#{open(src).read}</script>")
  end
end

The browser's console says there's something wrong with the jQuery snippet but I can't seem to find it. Help me senpai 😭.

changes.zip

1- used named group in your regular expression to get the src value
2- don't care about the browser console. open the output file and see what's written there if it's ok then look at the browser console.


python setup.py develop errors

On both of my x86_64 and arm64 macOS 13 systems, when I tried to develop install iree-jax with the following commands
git clone https://github.com/iree-org/iree-jax
cd iree-jax
python[3.10] setup.py develop

I got the following error. (A complete list of stderr+stdout is attached at the end of this issue.)
Searching for iree-runtime>=20221121.334
Reading https://pypi.org/simple/iree-runtime/
No local packages or working download links found for iree-runtime>=20221121.334
error: Could not find suitable distribution for Requirement.parse('iree-runtime>=20221121.334')

I can pip install iree-compiler iree-runtime successfully on arm64 macOS. But it gave me both of old version 20220930.282.
And pip install failed on x86_64 macOS with an error No matching distribution found for iree-compiler.

11:26 $ python setup.py develop
/Users/y/miniforge3/envs/iree-jax/lib/python3.10/site-packages/setuptools/dist.py:534: UserWarning: Normalizing '0.1dev1' to '0.1.dev1'
  warnings.warn(tmpl.format(**locals()))
running develop
/Users/y/miniforge3/envs/iree-jax/lib/python3.10/site-packages/setuptools/command/easy_install.py:144: EasyInstallDeprecationWarning: easy_install command is deprecated. Use build and pip and other standards-based tools.
  warnings.warn(
/Users/y/miniforge3/envs/iree-jax/lib/python3.10/site-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
  warnings.warn(
running egg_info
writing iree_jax.egg-info/PKG-INFO
writing dependency_links to iree_jax.egg-info/dependency_links.txt
writing requirements to iree_jax.egg-info/requires.txt
writing top-level names to iree_jax.egg-info/top_level.txt
reading manifest file 'iree_jax.egg-info/SOURCES.txt'
adding license file 'LICENSE'
writing manifest file 'iree_jax.egg-info/SOURCES.txt'
running build_ext
Creating /Users/y/miniforge3/envs/iree-jax/lib/python3.10/site-packages/iree-jax.egg-link (link to .)
Adding iree-jax 0.1.dev1 to easy-install.pth file

Installed /Users/y/w/iree-jax
Processing dependencies for iree-jax==0.1.dev1
Searching for jaxlib>=0.4.1
Reading https://pypi.org/simple/jaxlib/
Downloading https://files.pythonhosted.org/packages/54/d0/ce08c4dd9c7cf4a0223891900717cd197729d07fcd840c71a7b6cac8a88a/jaxlib-0.4.2-cp310-cp310-macosx_11_0_arm64.whl#sha256=63cb14fc6e311b3b67314d1404bb228e96bdb0ee328179c99244fb7e8a75f70b
Best match: jaxlib 0.4.2
Processing jaxlib-0.4.2-cp310-cp310-macosx_11_0_arm64.whl
Installing jaxlib-0.4.2-cp310-cp310-macosx_11_0_arm64.whl to /Users/y/miniforge3/envs/iree-jax/lib/python3.10/site-packages
Adding jaxlib 0.4.2 to easy-install.pth file

Installed /Users/y/miniforge3/envs/iree-jax/lib/python3.10/site-packages/jaxlib-0.4.2-py3.10-macosx-11.0-arm64.egg
Searching for iree-runtime>=20221121.334
Reading https://pypi.org/simple/iree-runtime/
No local packages or working download links found for iree-runtime>=20221121.334
error: Could not find suitable distribution for Requirement.parse('iree-runtime>=20221121.334')

It turned out that I can manually install IREE and iree-jax from source code. https://github.com/iree-org/iree-jax/issues/47#issuecomment-1405876566
I am not an expert on setup.py and lack knowledge about IREE/iree-jax dependencies.


Update 2022-2023 roadmap to include the primary features in the v15 hard fork

The roadmap is currently outdated: https://www.getmonero.org/resources/roadmap/
The 2022 roadmap should be updated to include the primary features set to be deployed with the v15 hard fork (Monero v0.18.0): https://github.com/monero-project/meta/issues/630
The roadmap for 2023 could include the current research being done into Seraphis & JAMTIS, decoy binning, OPSEAD, and more.

I've done the adjustments (merged 2017 into the 2014-2016) tab. and put the mentioned suggestions in (albeit with incorrect status, lets discuss what needs to be added / changed - or if something needs to link somewhere)

Added to december 2021:

"increase ring size to 100+ through Seraphis or Triptych"  is a suggestion for being listed in 'Future'

@plowsof will you create pull request?


Update RabbitMQ Broker docs

Update the RabbitmqBroker Knative docs. The docs need to be updated to include new setup requirements for RabbitMQ broker config.

/close
done by https://github.com/knative/docs/pull/5093


Add other/restrict-ingress-defaultbackend policy

Related Issue(s)

Fixes https://github.com/kyverno/policies/issues/322
Description

Create a sample policy to prevent usage of the Ingress defaultBackend field.
Checklist

[x] I have read the policy contribution guidelines.
[x] I have added test manifests and resources covering both positive and negative tests that prove this policy works as intended.

Thank you for this contribution! Do try and look at the contribution guidelines and especially complete the annotations section as these are what allow the user-friendly filtering on the website.


Update recommendation text relative to latest test

Update recommendation details when the time interval mentioned in the text is relative to the date of the last test (e.g. most recent cytology, histology, etc.)
It can be confusing if the recommendation says "1 one year" of a test which occurred 15 months in the past.
This change adopts the phrase "date of most recent test" to be the reference the time interval applies to. The date value shown is not changed (e.g. Collate.DateOfMostRecentReport + 1 years) but will now make it clear in the recommendation details that it is based on the most recent test, and that's why the date shown may be past.

2. What was your method for choosing which recommendation statements to update?

Statements which included a date offset from some test - e.g. Collate.DateOfMostRecentReport + 1 year
As you noticed, there are some statements which have more than one actionable item in their recommendation, which is also based relative to a test.


bash as hard requirement

I tried installing gogs on a system that doesn't have bash installed (alpine linux), and it worked great until I tried to create a repository. I believe that it is totally possible (and even probably simple) to use sh instead of bash. /bin/sh is POSIX, and is the only interpreter know to be present on all UNIXes. Therefore, I open a ticket for this issue to be solved. I'd rather have gogs working on as many platforms as possible; especially when the requirement is artifical.
Also, while I'm at it, kudos: gogs is very cool.

Hi @7heo , thanks your feedback!
There is actually an config option to set to sh. But this option is for Git repo update hook file(if this is what your problem located, cannot push repo).
Hope helps!

@Unknwon indeed, setting SCRIPT_TYPE = sh solves the issue. Given that sh is a symlink to bash in most distributions, I would recommend setting the default to sh (and take care to avoid any bashism!).
Feel free to close the issue depending on what you think about setting the default to sh. Thanks for the help, and again, congrats for gogs, so far it's excellent.

Thanks your confirmation and suggestion!
But I think it's better to keep bash as default as it is default in the Git hook samples. :beer:


FACT-378 - Fixed issues with local authority not being taken into account on deprecated search endpoint

JIRA link (if applicable)
https://tools.hmcts.net/jira/browse/FACT-376
https://tools.hmcts.net/jira/browse/FACT-378
Change description
Implemented ability to search by postcode area of law and local authority.
Only used when deprecated API is used for 'Children' area of law requests.
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[X] No

This has passed but there is low test coverage which I'm not happy with. Will implement tests for alt path before merger.

@Thomas-Geraghty In your new method, there are 2 other paths not tested yet (i.e. the 2 paths returning emptyList()) so the code coverage will still be low after this test. These 2 paths can be tested easily. The first one is mocking "mapitService.getMapitData(postcode)" so it returns en empty mapit data, and the second test is making "mapitData.getLocalAuthority()" to have a Optional.empty() value


feat: add frozen and locked

Issue #, if available:
Description of changes:
This introduces the frozen and locked behaviors to cargo chef.
See: https://doc.rust-lang.org/cargo/commands/cargo-build.html#manifest-options
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Hi, just saw this PR as I was about to work on something similar, this time to pass on --verbose to the underlying cargo calls.
@jayy-lmao, if you mind including verbose the same way you have frozen and locked when you fix the comments as per @LukeMathWalker request, that would be great.
If not, no big deal, I'll take inspiration in your PR to submit a PR of my own.

Hi, just saw this PR as I was about to work on something similar, this time to pass on --verbose to the underlying cargo calls. @jayy-lmao, if you mind including verbose the same way you have frozen and locked when you fix the comments as per @LukeMathWalker request, that would be great. If not, no big deal, I'll take inspiration in your PR to submit a PR of my own.

Just did this now, ty

with the addition of these flags, would --frozen become the "default" way to use cargo-chef now? i don't see why someone wouldn't want their ci builds to be frozen and only read from Cargo.lock.

It depends—generally speaking, it would probably be alright to make --frozen the default, but it's likely to break some builds and I don't think the benefits outweight the risks here.

@LukeMathWalker i meant default more as in "recommended" configuration, like adding it to the README.

I don't think it adds enough value and it would probably lead to people using it without understanding what it actually does (because they are copying from the example), which would in turn lead to open issues here.


VSCode .Net Core MVC Can't Load Project but Builds and Runs

Environment data
VS Code version: 1.50.1
C# Extension version: 1.23.4
OmniSharp log
[info]: OmniSharp.MSBuild.ProjectManager
        Queue project update for '/path/to/Redacted.Project.csproj'
[info]: OmniSharp.MSBuild.ProjectManager
        Loading project: /path/to/Redacted.Project.csproj
[fail]: OmniSharp.MSBuild.ProjectLoader
        rzc generate exited with code 129.
[warn]: OmniSharp.MSBuild.ProjectManager
        Failed to load project file '/path/to/Redacted.Project.csproj'.
/path/to/Redacted.Project.csproj
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Sdks/Microsoft.NET.Sdk.Razor/build/netstandard2.0/Microsoft.NET.Sdk.Razor.Component.targets(106,5): Error: rzc generate exited with code 129.

[fail]: OmniSharp.Stdio.Host
        ************  Response ************
{
  "Request_seq": 6614,
  "Command": "/v2/highlight",
  "Running": true,
  "Success": false,
  "Message": "\"System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.\\nParameter name: character\\n  at Microsoft.CodeAnalysis.Text.LinePosition..ctor (System.Int32 line, System.Int32 character) [0x00013] in <74e762f007514b0991a005183ec8dcb2>:0 \\n  at OmniSharp.Roslyn.CSharp.Services.SemanticHighlight.SemanticHighlightService.Handle (OmniSharp.Models.SemanticHighlight.SemanticHighlightRequest request) [0x00146] in <845c3087cc7d4530b36a8584d73f1c1d>:0 \\n  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].GetFirstNotEmptyResponseFromHandlers (OmniSharp.Endpoint.Exports.ExportHandler`2[TRequest,TResponse][] handlers, TRequest request) [0x00099] in <0b3dc7d6f0c8428682a86ac3f9663775>:0 \\n  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].HandleRequestForLanguage (System.String language, TRequest request, OmniSharp.Protocol.RequestPacket packet) [0x00163] in <0b3dc7d6f0c8428682a86ac3f9663775>:0 \\n  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].Process (OmniSharp.Protocol.RequestPacket packet, OmniSharp.Endpoint.LanguageModel model, Newtonsoft.Json.Linq.JToken requestObject) [0x0024b] in <0b3dc7d6f0c8428682a86ac3f9663775>:0 \\n  at OmniSharp.Stdio.Host.HandleRequest (System.String json, Microsoft.Extensions.Logging.ILogger logger) [0x000e7] in <0ff274924a1842faabf855aebc686508>:0 \"",
  "Body": null,
  "Seq": 7478,
  "Type": "response"
}
[fail]: OmniSharp.Stdio.Host
        ************  Response ************
{
  "Request_seq": 6617,
  "Command": "/v2/highlight",
  "Running": true,
  "Success": false,
  "Message": "\"System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.\\nParameter name: character\\n  at Microsoft.CodeAnalysis.Text.LinePosition..ctor (System.Int32 line, System.Int32 character) [0x00013] in <74e762f007514b0991a005183ec8dcb2>:0 \\n  at OmniSharp.Roslyn.CSharp.Services.SemanticHighlight.SemanticHighlightService.Handle (OmniSharp.Models.SemanticHighlight.SemanticHighlightRequest request) [0x00146] in <845c3087cc7d4530b36a8584d73f1c1d>:0 \\n  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].GetFirstNotEmptyResponseFromHandlers (OmniSharp.Endpoint.Exports.ExportHandler`2[TRequest,TResponse][] handlers, TRequest request) [0x00099] in <0b3dc7d6f0c8428682a86ac3f9663775>:0 \\n  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].HandleRequestForLanguage (System.String language, TRequest request, OmniSharp.Protocol.RequestPacket packet) [0x00163] in <0b3dc7d6f0c8428682a86ac3f9663775>:0 \\n  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].Process (OmniSharp.Protocol.RequestPacket packet, OmniSharp.Endpoint.LanguageModel model, Newtonsoft.Json.Linq.JToken requestObject) [0x0024b] in <0b3dc7d6f0c8428682a86ac3f9663775>:0 \\n  at OmniSharp.Stdio.Host.HandleRequest (System.String json, Microsoft.Extensions.Logging.ILogger logger) [0x000e7] in <0ff274924a1842faabf855aebc686508>:0 \"",
  "Body": null,
  "Seq": 7484,
  "Type": "response"
}

Actual behavior
Omnisharp fails to load the project. Causing intellisense to fail

@filipw It appears that this is being caused by invalid razor syntax. In one of my razor files I had something equivalent to the following:
MyComponent.razor

Some Header

@if (true)
{

some text

Notice the missing }.
I'm not sure why, but the project was building successfully with dotnet build.
I would expect this to produce a syntax error instead of Omnisharp failing to load the project.
I would also expect this to produce a build error, but that's probably not an Omnisharp issue.

@NTaylorMullen Have you seen this before where you get Microsoft.NET.Sdk.Razor.Component.targets(106,5): Error: rzc generate exited with code 129. during project load when try to compile invalid razor?

Interesting, so that's our build server failing to compile a Razor file as part of MSBuild. That being said it should be treated like every other C# error (diagnostics are piped the same way). Do you fail to load C# projects if there's diagnostics in them? If not, how do you ensure you can load said projects?

Same error on a non-razor project that builds flawlessly. Autocompltetion still works however.
dotnet --info
.NET Core SDK (che rispecchia un qualsiasi file global.json):
 Version:   3.1.403
 Commit:    9e895200cd

Ambiente di runtime:
 OS Name:     ubuntu
 OS Version:  16.04
 OS Platform: Linux
 RID:         ubuntu.16.04-x64
 Base Path:   /usr/share/dotnet/sdk/3.1.403/

Host (useful for support):
  Version: 3.1.9
  Commit:  774fc3d6a9

.NET Core SDKs installed:
  2.2.402 [/usr/share/dotnet/sdk]
  3.1.403 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.2.8 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.2.8 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.9 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.2.8 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.9 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

OmniSharp server started.
    Path: /home/seba/.vscode/extensions/ms-dotnettools.csharp-1.23.5/.omnisharp/1.37.3/run
    PID: 3454

[info]: OmniSharp.Stdio.Host
        Starting OmniSharp on ubuntu 16.4 (x64)
[info]: OmniSharp.Services.DotNetCliService
        DotNetPath set to dotnet
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Located 1 MSBuild instance(s)
            1: StandAlone 16.8.0 - "/home/seba/.vscode/extensions/ms-dotnettools.csharp-1.23.5/.omnisharp/1.37.3/omnisharp/.msbuild/Current/Bin"
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        MSBUILD_EXE_PATH environment variable set to '/home/seba/.vscode/extensions/ms-dotnettools.csharp-1.23.5/.omnisharp/1.37.3/omnisharp/.msbuild/Current/Bin/MSBuild.exe'
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator
        Registered MSBuild instance: StandAlone 16.8.0 - "/home/seba/.vscode/extensions/ms-dotnettools.csharp-1.23.5/.omnisharp/1.37.3/omnisharp/.msbuild/Current/Bin"
            CscToolExe = csc.exe
            MSBuildToolsPath = /home/seba/.vscode/extensions/ms-dotnettools.csharp-1.23.5/.omnisharp/1.37.3/omnisharp/.msbuild/Current/Bin
            CscToolPath = /home/seba/.vscode/extensions/ms-dotnettools.csharp-1.23.5/.omnisharp/1.37.3/omnisharp/.msbuild/Current/Bin/Roslyn
            BypassFrameworkInstallChecks = true
            MSBuildExtensionsPath = /home/seba/.vscode/extensions/ms-dotnettools.csharp-1.23.5/.omnisharp/1.37.3/omnisharp/.msbuild
...
[fail]: OmniSharp.Stdio.Host
        ************  Response ************
{
  "Request_seq": 20,
  "Command": "/v2/highlight",
  "Running": true,
  "Success": false,
  "Message": "\"System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.\\nParameter name: character\\n  at Microsoft.CodeAnalysis.Text.LinePosition..ctor (System.Int32 line, System.Int32 character) [0x00013] in <74e762f007514b0991a005183ec8dcb2>:0 \\n  at OmniSharp.Roslyn.CSharp.Services.SemanticHighlight.SemanticHighlightService.Handle (OmniSharp.Models.SemanticHighlight.SemanticHighlightRequest request) [0x00146] in <8ca5e445b15640a0986680e5a0180b25>:0 \\n  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].GetFirstNotEmptyResponseFromHandlers (OmniSharp.Endpoint.Exports.ExportHandler`2[TRequest,TResponse][] handlers, TRequest request) [0x00099] in <9e06207949b04d41ac60c7c691c8ecbb>:0 \\n  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].HandleRequestForLanguage (System.String language, TRequest request, OmniSharp.Protocol.RequestPacket packet) [0x00163] in <9e06207949b04d41ac60c7c691c8ecbb>:0 \\n  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].Process (OmniSharp.Protocol.RequestPacket packet, OmniSharp.Endpoint.LanguageModel model, Newtonsoft.Json.Linq.JToken requestObject) [0x0024b] in <9e06207949b04d41ac60c7c691c8ecbb>:0 \\n  at OmniSharp.Stdio.Host.HandleRequest (System.String json, Microsoft.Extensions.Logging.ILogger logger) [0x000e7] in <add5f40a6e784fcca3e930b59965388b>:0 \"",
  "Body": null,
  "Seq": 63,
  "Type": "response"
}
[fail]: OmniSharp.Stdio.Host
        ************  Response ************
{
  "Request_seq": 28,
  "Command": "/v2/highlight",
  "Running": true,
  "Success": false,
  "Message": "\"System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.\\nParameter name: character\\n  at Microsoft.CodeAnalysis.Text.LinePosition..ctor (System.Int32 line, System.Int32 character) [0x00013] in <74e762f007514b0991a005183ec8dcb2>:0 \\n  at OmniSharp.Roslyn.CSharp.Services.SemanticHighlight.SemanticHighlightService.Handle (OmniSharp.Models.SemanticHighlight.SemanticHighlightRequest request) [0x00146] in <8ca5e445b15640a0986680e5a0180b25>:0 \\n  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].GetFirstNotEmptyResponseFromHandlers (OmniSharp.Endpoint.Exports.ExportHandler`2[TRequest,TResponse][] handlers, TRequest request) [0x00099] in <9e06207949b04d41ac60c7c691c8ecbb>:0 \\n  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].HandleRequestForLanguage (System.String language, TRequest request, OmniSharp.Protocol.RequestPacket packet) [0x00163] in <9e06207949b04d41ac60c7c691c8ecbb>:0 \\n  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].Process (OmniSharp.Protocol.RequestPacket packet, OmniSharp.Endpoint.LanguageModel model, Newtonsoft.Json.Linq.JToken requestObject) [0x0024b] in <9e06207949b04d41ac60c7c691c8ecbb>:0 \\n  at OmniSharp.Stdio.Host.HandleRequest (System.String json, Microsoft.Extensions.Logging.ILogger logger) [0x000e7] in <add5f40a6e784fcca3e930b59965388b>:0 \"",
  "Body": null,
  "Seq": 77,
  "Type": "response"
}

this is an unrelated problem with semantic highlighting

this is an unrelated problem with semantic highlighting

But @Cooksauce 's message stack trace and mine are the same ...
System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
Parameter name: character
  at Microsoft.CodeAnalysis.Text.LinePosition..ctor (System.Int32 line, System.Int32 character) [0x00013] in <74e762f007514b0991a005183ec8dcb2>:0
  at OmniSharp.Roslyn.CSharp.Services.SemanticHighlight.SemanticHighlightService.Handle (OmniSharp.Models.SemanticHighlight.SemanticHighlightRequest request) [0x00146] in <845c3087cc7d4530b36a8584d73f1c1d>:0
  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].GetFirstNotEmptyResponseFromHandlers (OmniSharp.Endpoint.Exports.ExportHandler`2[TRequest,TResponse][] handlers, TRequest request) [0x00099] in <0b3dc7d6f0c8428682a86ac3f9663775>:0
  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].HandleRequestForLanguage (System.String language, TRequest request, OmniSharp.Protocol.RequestPacket packet) [0x00163] in <0b3dc7d6f0c8428682a86ac3f9663775>:0
  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].Process (OmniSharp.Protocol.RequestPacket packet, OmniSharp.Endpoint.LanguageModel model, Newtonsoft.Json.Linq.JToken requestObject) [0x0024b] in <0b3dc7d6f0c8428682a86ac3f9663775>:0
  at OmniSharp.Stdio.Host.HandleRequest (System.String json, Microsoft.Extensions.Logging.ILogger logger) [0x000e7] in <0ff274924a1842faabf855aebc686508>:0

System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
Parameter name: character
  at Microsoft.CodeAnalysis.Text.LinePosition..ctor (System.Int32 line, System.Int32 character) [0x00013] in <74e762f007514b0991a005183ec8dcb2>:0
  at OmniSharp.Roslyn.CSharp.Services.SemanticHighlight.SemanticHighlightService.Handle (OmniSharp.Models.SemanticHighlight.SemanticHighlightRequest request) [0x00146] in <8ca5e445b15640a0986680e5a0180b25>:0
  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].GetFirstNotEmptyResponseFromHandlers (OmniSharp.Endpoint.Exports.ExportHandler`2[TRequest,TResponse][] handlers, TRequest request) [0x00099] in <9e06207949b04d41ac60c7c691c8ecbb>:0
  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].HandleRequestForLanguage (System.String language, TRequest request, OmniSharp.Protocol.RequestPacket packet) [0x00163] in <9e06207949b04d41ac60c7c691c8ecbb>:0
  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].Process (OmniSharp.Protocol.RequestPacket packet, OmniSharp.Endpoint.LanguageModel model, Newtonsoft.Json.Linq.JToken requestObject) [0x0024b] in <9e06207949b04d41ac60c7c691c8ecbb>:0
  at OmniSharp.Stdio.Host.HandleRequest (System.String json, Microsoft.Extensions.Logging.ILogger logger) [0x000e7] in <add5f40a6e784fcca3e930b59965388b>:0

yes you both are seeing a semantic highlighting problem too but this issue tracks a different problem that is also present in the original log:  rzc generate exited with code 129.
[warn]: OmniSharp.MSBuild.ProjectManager
        Failed to load project file '/path/to/Redacted.Project.csproj'.
/path/to/Redacted.Project.csproj
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Sdks/Microsoft.NET.Sdk.Razor/build/netstandard2.0/Microsoft.NET.Sdk.Razor.Component.targets(106,5): Error: rzc generate exited with code 129.

Semantic highlighting is currently an experimental feature and has some edge cases where it fails. In fact has had these types of failures you mention since the beginning - it's just they were never reported to the logs, and only a recent change in OmniSharp started reporting them so that we get more transparency into  how often they happen.


chore: migrate to nix develop

This uses the experimental nix develop command with Nix Flakes, this way we can use the unstable channel to get the latest packages and lock its revision with ease (Renovate has support for Nix Flakes). I made the list of packages more exhaustive as well.
nix-shell is still usable for now thanks to the flake-compat module.

@kakkoyun any concerns about merging this one?

@kakkoyun any concerns about merging this one?

Noop. I'll merge.


[Docs] Upgrading to v3.0.0

I just noticed that the docs are lacking an upgrade guide for v3.0.0.
I'm looking forward to upgrading, but it would be great if this could be made available first.

Dupe of #4174, #4192, and #4175. Please search before posting a new issue.

Sorry :( I tried searching, but apparently ineffectively


Bump Go to 1.13

Coverage increased (+0.1%) to 90.923% when pulling 439b41c076581adc89b100c59d5aa334460b472e on janisz:patch-1 into 61c7bad89fcc2732a62199c9100816e6aa956412 on allegro:master.

@tomez @AlfredBroda Ping

Thanks @janisz sorry for the delay)


Overridden type works for ARRAY of objects but not for a single object

Version
1.27.0
What happened?
Have a simple ddl for an object in postgres. It uses a TYPE both as an ARRAY and also as a simple object. The sqlc.yaml has an override to map the TYPE (see sqlc.yaml).  In the generated code, the ARRAY is mapped correctly to the overridden type but the simple object is mapped to sql.NullString.
Relevant log output
In the generated code, we see:

type FleetmanagerSchemaTag struct {
        CreateDate pgtype.Timestamp
        ID         int64
        Name       string
        Owner      sql.NullString
        Devices    []common.ObjRef
}
Notice that the Devices element is mapped to []ObjRef correctly but the Owner element is mapped to NullString. And both are of type ObjRef

Database schema
ddls.sql
-- Create schema for fleet manager.
CREATE SCHEMA fleetmanager_schema;

-- Add schema to search path
SET search_path TO fleetmanager_schema, public;

-- Using a domain to ensure that the obj_id and obj_type that are declared in a type are not null
CREATE DOMAIN nonnull_string VARCHAR(255) NOT NULL;
CREATE DOMAIN nonull_int8 int8 NOT NULL;

CREATE TYPE fleetmanager_schema.obj_ref AS  (
    obj_id nonnull_int8,
    obj_type nonnull_string
);

And the Go struct definition is:
type ObjRef struct {

        ObjId string `json:"obj_id" range:"min=8,max=32"`

        ObjType string `json:"obj_type" range:"min=3,max=32"`
}
-----

CREATE TABLE fleetmanager_schema.tag (
   create_date TIMESTAMP DEFAULT NOW() NOT NULL,
   id int8 NOT NULL,
    PRIMARY KEY (id),

   name VARCHAR(255) NOT NULL,
   owner fleetmanager_schema.obj_ref,
   devices fleetmanager_schema.obj_ref ARRAY
);

SQL queries
-----------------queries.sql
-- name: InsertTag :one
INSERT INTO fleetmanager_schema.tag (
    create_date,  name, name,  owner, devices
) VALUES (
             $1, $2, $3, $4, $5
         ) RETURNING *;

-- name: GetTag :one
SELECT *
FROM fleetmanager_schema.tag
WHERE id = $1;

Configuration
------sqlc.yaml
version: "2"
sql:
  - engine: "postgresql"
    queries: "./queries.sql"
    schema: "./ddls.sql"
    gen:
      go:
        package: "db"
        out: "./generated"
        sql_package: "pgx/v5"
        overrides:
          - go_type:
              import: "fleet-api-server/generated/common"
              type: "ObjRef"
            db_type: "fleetmanager_schema.obj_ref"
            null: false

Playground URL
No response
What operating system are you using?
Linux
What database engines are you using?
PostgreSQL
What type of code are you generating?
Go

On further testing, if I add the NOT NULL attribute to the Owner element, then the generated code is correct
`CREATE TABLE fleetmanager_schema.tag (
create_date TIMESTAMP DEFAULT NOW() NOT NULL,
id int8 NOT NULL,
PRIMARY KEY (id),
name VARCHAR(255) NOT NULL,
owner fleetmanager_schema.obj_ref NOT NULL,    -- This NOT NULL leads to proper code generation
devices fleetmanager_schema.obj_ref ARRAY
);
type FleetmanagerSchemaTag struct {
CreateDate pgtype.Timestamp
ID         int64
Name       string
Owner     common,ObjRef
Devices    []common.ObjRef
}`

@kayshav
I think this behavior is expected, considering that although the nonnull_int8 and nonnull_string types of obj_ref are not null, there is still a possibility that the value of obj_ref is null, for example:
insert into tag(create_date, id, name, owner, devices)
values (now(), 1, 'name', null, null);

The query  will not fail, so it is possible to have records with the owner field as null. As the documentation states, if the null parameter in the overrides configuration is set to false, nullable fields will not be overridden.


Fix compatibility with ArduinoJson 5.11.0

See issue #361 and https://github.com/bblanchon/ArduinoJson/issues/541.

@bblanchon awesome, thanks for your contribution! 😃


Review script for paper "2023SoPh..298...35Z" made with predictor "DataLinkerCondenseDetailsWithTemplate"

Created by Paper Data Linking Bot
Please review the download script and instrument details for the paper.
bibcode: 2023SoPh..298...35Z
predictor: DataLinkerCondenseDetailsWithTemplate

results appear to be accurate and queries are nicely executed.


why does warm starting go unstable in some situations?

errors in warm starting energy can grow unbounded, softness and relax stages helps filter this energy like a low pass filter

errors in warm starting energy can grow unbounded, softness and relax stages helps filter this energy like a low pass filter


Add support for Serena TeamTrack Issue Tracking

http://pvcs.synergex.com/products/serena_team_track.aspx
I couldn't find API docs anywhere

We've moved over to a new system for notifications and we have an internal ticket for this. The good news is it shouldn't take us much longer to get this shipped so it should be coming soon!
Closing this issue as this repo is being retired.