How to handle documentation around validate in plugin framework

Confirmation

[X] My issue isn't already found on the issue tracker.
[X] I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version
Making an issue for this following https://github.com/cloudflare/terraform-provider-cloudflare/pull/2977
There is the issue with the terraform docs plugin that traces back to the terraform-plugin-framework, which prevents documentation of resources from indicating that a resource must be replaced if an attribute is changed. This leads to a poor user experience, as they might not be expecting to have to replace a resource after reading the documentation.
A possible solution is to make add more functions to the utils section to work around this issue and rely on manually requiring it to be added to the schema of a resource.
Affected resource(s)
d1_database
email_routing_address
r2_bucket
ruleset
Expected output
There is documentation around when resources will have to be recreated due to plan modifiers
Actual output
The documentation is blank.
Steps to reproduce
Add a resource via the plugin framework with a planmodifier that requires replace, and the docs won't render like they do in sdkv2.
References
https://github.com/hashicorp/terraform-plugin-framework/issues/625

yes, for now we just need to manually add it when we come across them or migrating schemas. i'm not going to wait for the docs plugin to address this.


Best filesystem for seaweedfs?

What is the best filesystem for seaweedfs? What about software RAID? Will ext4 or btrfs bee good?

"Best" is hard to define: what're the criteria and how to measure them?
Most file systems should work well.


drivers: sensor: bmm150: support pm turn on/off

This patch extends PM support for BMM150 driver
to be able to reinitialize the device after it was cut off the power.

These actions are reserves for power domains

Could you elaborate how to implement this instead? I don't see any other interface to initialize a device again after power was cut.

For more context: The device is going to be powered off and on by a PMIC and I was hoping that this API would be the right place, maybe even supporting triggering these actions automatically if the power domains are configured correctly. For now, I would be more than happy if there was any way at all to initialize the device again without rebooting the app.

I guess we need then a regulator based power domain? cc: @JordanYates

These actions are reserves for power domains

Triggering the actions should be reserved for power domains (in a robust system), but handling them is 100% a job for the device drivers.
I would highly recommend looking into using pm_device_driver_init, as the current implementation is not going to behave correctly if the device isn't powered at boot.

@JordanYates how should I proceed? Does the init function always get executed, even if the power domain is off? Should it be supported to resume when a device hasn't been suspended before? Is there any zephyr driver supporting power management in a proper way?

@JordanYates how should I proceed?

In a world without PM, device drivers should be (and are currently) doing the following actions:

Initialise any data structures
Do any work that should be done when the device is first physically powered
Do any work needed to put the device into a state where it is running.

Happily, each of these can map very cleanly into the PM world

The device init function
PM_DEVICE_ACTION_TURN_ON
PM_DEVICE_ACTION_RESUME

pm_device_driver_init is conceptually doing the same work as the first sequence, but using the PM implementation, while also stopping at the point appropriate to the current power state of the device.

Does the init function always get executed

The init function is always executed, it has no way of knowing whether the device is powered, and it can still perform useful work (initialising data structures etc) even if it isn't.

Should it be supported to resume when a device hasn't been suspended before?

This should not be done through the init function, but rather through the PM action callback.

Is there any zephyr driver supporting power management in a proper way?

The answer is almost no, IMO any driver not using pm_device_driver_init is not doing it correctly, because no driver I have seen is actually considering whether it is powered or not at boot. The one driver that does is the device I ported with the implementation. Hopefully it is simple enough to demonstrate the principle. https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/power_domain/power_domain_gpio.c

@JordanYates Thanks for the explanation! I updated the PR so it uses pm_device_driver_init. Also, things should work fine issuing the actions in the order you described.

@JordanYates Thanks for the explanation! I updated the PR so it uses pm_device_driver_init. Also, things should work fine issuing the actions in the order you described.

You're on the right path, but not quite there.
The point of pm_device_driver_init is that it removes all the need for conditional #ifdef for various PM configurations.
pm_device_driver_init is defined to call the correct sequence of functions no matter the configuration, and if it doesn't, thats a bug.
This means that #if defined(CONFIG_PM_DEVICE) can be removed entirely from the file, as pm_action now runs (and is therefore tested) under all configurations.

I removed the ifdefs now and it seems to work.

@ceolin Hi! Do you think this is the right way to go?

@maxd-nordic the pm logic is looking nice IMHO, just some concerns about the trigger part.

@ceolin @JordanYates could you have another look?

Please don't take this as personal criticism, because I appreciate the effort you've put in here, and absent the statements below I would be happy to approve.
Personally I see this as a perfect reason why the existing documentation of "Devices should always handle PM for themselves" is undesirable in practice. The requirement to save every configuration value in RAM, and then need to re-apply it on every sample is just silly to push onto every sensor driver.
See #62779 (comment) for my reasoning why this should be done by the user (for the sensor subsystem at least).
@ceolin is free to override the -1 as maintainer, but I see this as a pattern that should not be endorsed.

I am not going to override it, we need to converge to a consensus. I agree with you that subsystems have to take care of pm, period.
What is probably not a consensus is whether or not devices should also do it, my opinion (for now) is that yes, devices should collaborate with it as much as possible, especially because there are cases where they export their own API and are not used through subsystems. entropy devices, for example, are used sometimes directly and not through random subsys.
Taking this device as example, if the sensor subsystem is also responsible for pm, what will happen is:
subsys| pm_device_runtime_get(dev); /* dev now is active */
subsys| call_some_dev_operation(dev);
    dev| pm_device_runtime_get(dev); /* dev pm reference is increased */
    dev| /* does what was requested */
    dev| pm_device_runtime_put(dev); /* dev pm reference is decrease, but device is still active */
subsys|  /* done with device */
subsys| pm_device_runtime_put(dev); /* only now device is suspended */

So, in this case, the pm logic was effectively controlled by the subsys. That adds an overread?  Yes, but it is consistent across different devices.
My main concern is starting to have things like, are you writing a sensor device ? Don't need to implement runtime pm, the subsystem will take care. Are you writing an entropy device ? You have to implement runtime pm ...

What is probably not a consensus is whether or not devices should also do it, my opinion (for now) is that yes, devices should collaborate with it as much as possible

If it didn't add substantial complexity (as demonstrated by this PR) then sure, but that is not the case. It is making the driver demonstrably worse to maintain, while also increasing RAM and ROM footprint.

especially because there are cases where they export their own API and are not used through subsystems

Then that is not a portable API in the first place and it is free to do as it sees fit, I don't believe that is relevant here.

My main concern is starting to have things like, are you writing a sensor device ? Don't need to implement runtime pm, the subsystem will take care. Are you writing an entropy device ? You have to implement runtime pm ...

I am not suggesting that the driver doesn't implement runtime PM, it still obviously needs to implement the action CB.
I don't think it's too much to ask that someone writing a sensor driver implements a different usage pattern than a flash driver, they are obviously not the same thing in the first place.
From the user perspective, the sensor API already defines requirements on the user (sensor_sample before sample_fetch for example), I don't see why extending that requirement with respect to PM is problematic.

What is probably not a consensus is whether or not devices should also do it, my opinion (for now) is that yes, devices should collaborate with it as much as possible

If it didn't add substantial complexity (as demonstrated by this PR) then sure, but that is not the case. It is making the driver demonstrably worse to maintain, while also increasing RAM and ROM footprint.

That is where I said as much as possible, we obviously can't blindly implement it, drivers need to be reasonable about it.

especially because there are cases where they export their own API and are not used through subsystems

Then that is not a portable API in the first place and it is free to do as it sees fit, I don't believe that is relevant here.

It is because devices doing it still should care about pm

My main concern is starting to have things like, are you writing a sensor device ? Don't need to implement runtime pm, the subsystem will take care. Are you writing an entropy device ? You have to implement runtime pm ...

I am not suggesting that the driver doesn't implement runtime PM, it still obviously needs to implement the action CB. I don't think it's too much to ask that someone writing a sensor driver implements a different usage pattern than a flash driver, they are obviously not the same thing in the first place.
From the user perspective, the sensor API already defines requirements on the user (sensor_sample before sample_fetch for example), I don't see why extending that requirement with respect to PM is problematic.

I am not limiting the discussion to the sensor subsystem and instead trying define a general policy for pm, subsystems can tuning this  policy though. There are devices that are used through subsystems ... or cases where devices need additional handling and the subsystem is not aware and so they need to hold/leave a pm reference.
I don't want to force all devices to blindly implement runtime pm, but that they consider to do it if it makes sense and not only expect that an upper layer will do it.

@JordanYates @ceolin What would be the next step going forward?

That is where I said as much as possible, we obviously can't blindly implement it, drivers need to be reasonable about it.

This is the root of my concern. "As much as possible" doesn't work when defining behaviour of an API. There needs to be a set in stone rule that you can point to and say, this driver complies, this driver does not.
I believe my arguments for why the sensor API cannot handle PM internally are clear, therefore users of the sensor API must wrap calls in pm_device_runtime_get/put themselves.

I am not limiting the discussion to the sensor subsystem and instead trying define a general policy for pm

Different subsystems by definition have different behaviours, expectations and usage patterns. Trying to specify a global "PM must be implemented like this internally in drivers" is never going to work out.

I don't want to force all devices to blindly implement runtime pm, but that they consider to do it if it makes sense and not only expect that an upper layer will do it.

I am not suggesting that all devices (or even all sensors) need to implement PM. I am arguing only that sensor drivers should expect an upper layer to manage PM, if PM is enabled. Other subsystems can and will have different expectations.

That is where I said as much as possible, we obviously can't blindly implement it, drivers need to be reasonable about it.

This is the root of my concern. "As much as possible" doesn't work when defining behaviour of an API. There needs to be a set in stone rule that you can point to and say, this driver complies, this driver does not.
I believe my arguments for why the sensor API cannot handle PM internally are clear, therefore users of the sensor API must wrap calls in pm_device_runtime_get/put themselves.

They are and I have the same opinion (and not only for sensors tbh). Maybe the thing that we may be diverging here, is that I don't think we should forbidden them to do it if they need (exceptional cases and not the norm)

I am not limiting the discussion to the sensor subsystem and instead trying define a general policy for pm

Different subsystems by definition have different behaviours, expectations and usage patterns. Trying to specify a global "PM must be implemented like this internally in drivers" is never going to work out.

I don't want to force all devices to blindly implement runtime pm, but that they consider to do it if it makes sense and not only expect that an upper layer will do it.

I am not suggesting that all devices (or even all sensors) need to implement PM. I am arguing only that sensor drivers should expect an upper layer to manage PM, if PM is enabled. Other subsystems can and will have different expectations.

I agree, my only concern here, is to state that sensors are not allowed to use runtime pm, there may cases where the driver needs to use it to avoid get into an inconsistent state if only the subsys will trigger it. But that should be exceptions and not the common case. If you are not saying that (that sensors are forbidden to use it if they need) I believe we can move with this approach for sensors (and consequently to other subsystems as well).

If you are not saying that (that sensors are forbidden to use it if they need) I believe we can move with this approach for sensors (and consequently to other subsystems as well).

There are two potential ways to use runtime PM in a sensor driver:

PM on another device (SPI bus etc): Perfectly fine and even encouraged
PM on itself: If the API requires that the device is in active mode before running any API functions, what possible utility could the driver gain from also running PM on itself? By definition it is already in active mode.

Therefore while I wouldn't say forbidden, I don't see any possible use case for it. Driver specific extensions (for the sensor API) should probably be considered as non-portable extensions to the API, with the same expectation that the device is already in active mode.

Therefore while I wouldn't say forbidden, I don't see any possible use case for it. Driver specific extensions (for the sensor API) should probably be considered as non-portable extensions to the API, with the same expectation that the device is already in active mode.

I am a bit lost here. You are basically saying here that sensors drivers should not do PM on their own and PM should be done somewhere else, but why? And does not this really depend on how the driver is implemented and the usecase?   If the driver can deal with waking up the device/sensor and suspending it gracefully and getting all the registers set correctly, then the following can all be managed by the driver and there is no need to push this up to the "application" (extremely simplified):

application wants to read some sensor data, call sensor API
the sensor API call does the following:

wake up device if suspended (get)
read data and send it to application
suspend device (put)

Now you might choose to do the get/put on the application level, and this should be fine, maybe you the overhead of suspending/resuming is greater than the interval within which you want to be reading the data, so you keep the device up by reserving it (get) at a higher level, which is fine....
Was curious about sensor drivers in linux and how it is done there, given runtime pm was inspired from linux:
git grep pm_runtime_get drivers/iio/ | wc -l
94

And does not this really depend on how the driver is implemented and the usecase?

The below are my comments from this PR and the docs PR you opened. The TLDR is "Behaviour must be consistent, different behaviour in different implementations is undesirable and unportable":
This is the root of my concern. "As much as possible" doesn't work when defining behaviour of an API. There needs to be a set in stone rule that you can point to and say, this driver complies, this driver does not.

Note that the driver has to be aware of its capabilities, as you mention the sensor example, if a sensor loses context when suspending itself, it clearly cannot suspend itself ...

Now take the example a step further. You have two boards, identical except for a different temperature sensor. One loses state on power down, the other doesn't.
The whole purpose of the sensor API is to provide a common interface to broadly similar devices, so this should be no problem. But if you want code you write to work across both boards, you have no choice but to work in the way I suggest.
If the drivers are following the model of "call get(self) only if you can", and the user does not explicitly call PM functions, using the sensor which does lose state will always fail. Whereas if the user always calls PM explicitly, it works for both, even if the driver that preserves state is not calling get(self).
For a robust system, you don't have the option of choosing on a per-implementation basis what the behaviour should be, it needs to be specified at the API level. My argument would be that any API with linked call structures must be driven by external users, while simple API's can be done internally, with the obvious option of users running higher level PM operations to optimise use cases.

The below are my comments from this PR and the docs PR you opened. The TLDR is "Behaviour must be consistent, different behaviour in different implementations is undesirable and unportable":

That is the issue, what different behaviors are you referring to? The sensor API must functions the same way.
Adding power management support in the driver should not change how the sensor driver works, it does this saving power. A loss of state you refer to is something that need to be dealt with in the driver, i.e. when the device is resumed, it will need to restore its state, or transition to a state that allows maintaining the state but still saving power.

This is the root of my concern. "As much as possible" doesn't work when defining behaviour of an API.

not something I said but I agree, this is vague. All device drivers should have runtime PM if they support different modes, period.

That is the issue, what different behaviors are you referring to? The sensor API must functions the same way.
Adding power management support in the driver should not change how the sensor driver works, it does this saving power. A loss of state you refer to is something that need to be dealt with in the driver, i.e. when the device is resumed, it will need to restore its state, or transition to a state that allows maintaining the state but still saving power.

The behaviours I am referring to are the differing behaviours of sensor hardware when put into a "sleep" state. Some preserve configuration, some don't. This is a problem because the sensor API has a dedicated function for applying configuration data (sensor_attr_set).
If there is no requirement (for the sensor API) that the device remain in active mode across calls to sensor_attr_set and sensor_fetch, the sensor_attr_set implementation has no choice but to not actually do any work, but instead buffer any configuration in RAM until sensor_fetch, and then apply the configuration there.
Ignoring the ROM and RAM footprint increases from an approach like that, it also just makes the driver harder to follow and validate it is doing the right thing. It is not obvious that this PR does not currently behave correctly, and that is a problem IMO.

This is the root of my concern. "As much as possible" doesn't work when defining behaviour of an API.

not something I said but I agree, this is vague. All device drivers should have runtime PM if they support different modes, period.

That was not my intended meaning. I am saying that the following statement does not work for an API:
"devices should run device PM on itself internally, as long as configuration state is not being lost"
The quote was from @ceolin:

That is where I said as much as possible, we obviously can't blindly implement it, drivers need to be reasonable about it.

Just dropping some thoughts here:
One could define the behavior the following way:

drivers that don't support modern PM and therefore have to stay "active" all the time
drivers that do support modern PM

guarded by a KConfig option, device configuration needs to be buffered (keeping small footprint where needed)
there should be API functions for cold boot, warm boot/exit sleep, enter sleep, shutdown
a driver should be able to specify whether the device needs to stay on (sampling etc.) or off (warm up, cool down) for a period (could return a timeout on a PM callback)
driver has to make sure the device is always in a known state - devices cannot lose configuration due to some PM happening in the background
the subsystem needs to make sure that you cannot call the fetch/attr_set/attr_get/... functions of a sleeping device (e.g. wake it up automatically)
the subsystem needs to make sure that devices that have triggers configured will not be turned off


Implementation of required Dashboards and Integration with Grafana Prometheus Cloud

Developed some Grafana dashboards:

Number of connected clients (realtime, groupped by hour/day)
Number of connected clients by canister id
Number of active pollers
Time to resolve tls
Time to open connection

Integrated the remote writer on prometheus server (always deployed) to send metrics on the Grafana prometheus cloud

I made the minor changes requested during the call. Dashboard clients by hour/day sometimes have strange behavior, so keep an eye on it (when we have more data).


follow up for pr#4339, remove the space

What is the purpose of the change
follow up for pull request #4339
Brief changelog
XXXXX
Verifying this change
XXXXX
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a GITHUB_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Run mvn clean install -DskipTests=false & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #4591 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #4591      +/-   ##
============================================
- Coverage     64.07%   64.05%   -0.02%
- Complexity      450      453       +3
============================================
  Files           768      768
  Lines         32868    32865       -3
  Branches       5179     5178       -1
============================================
- Hits          21061    21053       -8
- Misses         9400     9404       +4
- Partials       2407     2408       +1

Impacted Files
Coverage Δ
Complexity Δ

...o/common/extension/AdaptiveClassCodeGenerator.java
94.95% <ø> (ø)
0 <0> (ø)
:arrow_down:

.../apache/dubbo/qos/protocol/QosProtocolWrapper.java
64.1% <0%> (-17.95%)
0% <0%> (ø)

...apache/dubbo/common/config/ConfigurationUtils.java
64% <0%> (-8%)
0% <0%> (ø)

...bbo/registry/support/ProviderConsumerRegTable.java
80.48% <0%> (-4.88%)
0% <0%> (ø)

.../dubbo/remoting/transport/netty4/NettyChannel.java
61.17% <0%> (-4.71%)
0% <0%> (ø)

...ng/transport/dispatcher/WrappedChannelHandler.java
44.11% <0%> (-4.54%)
0% <0%> (ø)

...bo/rpc/cluster/support/FailbackClusterInvoker.java
67.21% <0%> (-3.28%)
0% <0%> (ø)

.../apache/dubbo/remoting/transport/AbstractPeer.java
63.04% <0%> (ø)
0% <0%> (ø)
:arrow_down:

...org/apache/dubbo/registry/redis/RedisRegistry.java
48.44% <0%> (+0.28%)
32% <0%> (+1%)
:arrow_up:

...he/dubbo/remoting/transport/netty/NettyServer.java
73.21% <0%> (+3.57%)
9% <0%> (+1%)
:arrow_up:

... and 2 more

Continue to review full report at Codecov.

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


Add consent API support

I will work on this

@chaopeng any plan to work on it soon?

No plan in 2 week


Better format for error messages

The current error messages are not consistent and nested together. We should have a better error message format.
mesabox head:
$ ./target/debug/mesabox head -c - tests/fixtures/head/lorem_ipsum.txt
head: error: Invalid value for '--bytes <NUMBER>': '-' is not a number or is too large

mesabox cat:
$ ./target/debug/mesabox cat fdsfs
cat: fdsfs: No such file or directory (os error 2)
cat: encountered 1 error(s)

Some examples for reference:
GNU coreutils:
$ head -c - tests/fixtures/head/lorem_ipsum.txt
head: invalid number of bytes: ‘’

BSD (OS X):
$ head -c - tests/fixtures/head/lorem_ipsum.txt
head: illegal byte count -- -

BusyBox:
$ ./busybox head -c - busybox_unstripped.out
head: invalid number ''

Cargo:
$ cargo build --release sss
error: Found argument 'sss' which wasn't expected, or isn't valid in this context

USAGE:
    cargo build --release

For more information try --help

The original plan was for the format to be utilname: error: msg in most cases, but I've started to think the error:  bit wastes too much space (as with most of these utilities almost any message written to stderr is an error).
I'm not entirely sure what you mean by "nested together" unless you are referring to Invalid value for '--bytes <NUMBER>': '-' is not a number or is too large, which I believe is a result of clap.  I also think the GNU and BusyBox errors messages are not clear unless you already understand how the utility works.

For the first question:

utilname: error: msg
error: msg
utilname: msg

I'm not sure which one is better. Seems that Rust's tradition tends to use the second one and "error" is highlighted in red.
For the second question, I mean the error message is in  one line and separated in colon. E.g., the current one is:
utilname: error: msg: sub-msg
It looks a little wired (probably because of the prefix utilname: error). Yes, the current message of GNU and BusyBox is not clear, and I was not suggesting to be consistent with them.
cargo uses the same format:
$ cargo build -j abc
error: Invalid value: could not parse `abc` as a number

I think we need to keep everything as one line, so the best way to fix this I guess would be to remove the error:  part.

Ok, agree.
BTW, I'm coming up this issue when writing testcases for errors.


IOS version out of date, 8.4 these days :)

When trying to get ios-simple to work/run

Latest update of Xcode comes with iOS 9.2, so you get an environment error when running iOS samples (eg. mocha ios-simple.js). I was able to get 'sample-code/node/' to work by updating the helpers/caps.js "ios81" config to platformVersion: '9.2',


A way to list all the commands in the file

Description
Please add a reserved command, or maybe a switch, to list all the commands bonnie knows about in the folder where the toml resides. Something like bonnie ls, bonnie list, or bonnie --list.
Reasoning
Bonnie is awesome but, unless I'm mistaken, you must open the toml file to see what commands exist, and there's no quick reference. You have to read through it all and, in some cases, parse the bonnie structure to figure out what works.
Are you willing to work on an implementation of this?
I am not confident enough in my rust skills yet to dissect someone else's code and add such a command. If I get to that point, I will be happy to send a PR, but in the meantime, I am placing my hopes in someone else who has such skill and recognizes this as a good feature to add. If not, I suppose I will live without it for the time being. Thank you!

This already exists with bonnie help. You can provide descriptions of commands with the .desc property, but that command will list all user-provided commands. Does that satisfy your use-case?

Wow, yep, that does it. I didn't try bonnie help because most rust commands use only the command --help structure and don't respond to just help at all or use it as an argument for something else that will break things. This works fine, thanks.

Would it be a good or bad idea to alias bonnie help to just bonnie? I certainly would have discovered it easier. Or, at least include a message pointing users at bonnie help if they just type bonnie. Something like "Please provide a command to run. Type bonnie help for a list of commands."

I'm pretty sure it's under bonnie -h, but it may not be...
I'm certainly willing to add a message pointing users to it when they run bonnie though, that's a great idea!

I'll take it!


Package request: xremap

Project description

Key remapper for X11 and Wayland

Metadata

homepage URL: https://github.com/k0kubun/xremap
source URL: https://github.com/k0kubun/xremap
license: mit
platforms: linux

The MIT-licensed https://github.com/xremap/nix-flake/ can probably greatly simplify this work.

For some odd reason, it looks like gnomeExtensions.xremap was packaged without xremap itself being packaged... odd.


Unit Test -- GitHub Actions/ Pytest verification

Script Title -
what will change -
Instructions

Create a new folder for your script and file/folder name should be appropriate.
Create a README.md in your folder for program Instructions
add requirements.txt if needed

Please add/delete options that are not relevant.

[x] Adding New Code
[x] Improving Code
[x] Improving Documentation
[x] Bug Fix

Programming Language

[x] Python

:star2: Star it :fork_and_knife:Fork it :handshake: Contribute to it!
Maintainers
Divakar -- Discord id (root#5998)
Sanchit -- Discord id (sanchit#5988)
Discord server  - https://discord.gg/e47wmTW
Happy Coding,

What do you need in this issue?

Hey @Yagueteiro, Sorry but we have already fixed this issue, Anyways thanks for checking in.


Update to EF Core 7 RC 2

fixes #10

Thank you @ErikEJ! 🙏🏻

Awesome!

I forgot to notify you earlier, but 7.0.0-rc.2 is on NuGet now ☺

Added to latest daily build of EF Core Power Tools


Libluasocket support

Provides network functionalities.
To build on android ndk requires some changes in lua5.0->lua5.1 compat layer, but finally it works.

It's cool to finally have this working.
Did you forget to add the src/lib/luasocket sources?
Either way, I don't think I will be merging this PR, because there is a fancy new plugin system that should allow this to be easily added to builds.  Plugins are currently on the dev branch, and I haven't documented them yet.  But the main workflow is to make a plugins folder in the repo root and copy/clone/submodule plugins into there.  Plugins are regular repositories with CMakeLists in them.  Here are 3 examples of plugins: bjornbytes/lua-cjson, bjornbytes/lua-enet, bjornbytes/lua-deepspeech.  Most of the time no changes need to be made to make stuff compatible as lovr plugins.  Let me know if I can help out with the process.

I tried to build libluasocket independently, but it heavily depend on lua machine, almost all protocol-specific code are written on lua and I haven't found another solution, than just compile it with the engine itself.

When built as a lovr plugin it will automatically have access to the Lua headers/libraries

@bjornbytes

Let me know if I can help out with the process.
Now I'm trying to rebuild it as LOVR plugin, but encountered a problem (Error: no module 'luasocket.http' in file ./luasocket.so) to define submodules inside single .so/.dll file. AFAIK I should change luasocket.c someway to define all it's submodules but currently I can't figure out how exactly. Help is welcome.

So, with some workarounds now it can works. The final question is how to avoid symlinking libraries.

That is very cool.  So it looks like luasocket is using the "all-in-one" approach documented in Lua's manual, and lovr.filesystem's native library loader doesn't support that yet.  I can look into adding support for it, it would help match the functionality of Lua's built-in loader.

(Implementation question I'm thinking about: Should it be a new loader that gets added or could it somehow be integrated into the existing one?)

Where it's located? AFAIU all loaders are placced inside api/l_filesystem.c and on line 429 metioned, that lovr should search native libraries next to executable, but instead of it, lovr search it in pwd. So, I think it's a bug.


Some additional error handling

heh, did not see where you dont that lol

done*

;)
P.S. for future pull requests, please make sure not to commit time_waste :P
It's not committed due to GPL license


Fix read-blocking in server dispatcher

The intent was to block reads on channels where the client required ordered responses, to prevent the server caching an unlimited number of responses while waiting for some response that needs to be sent before the others. But the code was actually sometimes blocking reads on out-of-order-aware channels, which was a problem because the unblocking code was only operating for order-required channels.

Agree with @haijunz, can save a mutex lock. Otherwise, lgtm

I addressed Haijun's comments and merged this.


Update sbt-microsites to 0.9.4

Updates com.47deg:sbt-microsites from 0.9.3 to 0.9.4.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention @scala-steward in the comments below.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.47deg", artifactId = "sbt-microsites" } ]

labels: semver-patch

Codecov Report

Merging #1146 into master will increase coverage by 0.09%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1146      +/-   ##
==========================================
+ Coverage   80.51%   80.61%   +0.09%
==========================================
  Files          54       54
  Lines        1016     1016
  Branches       32       32
==========================================
+ Hits          818      819       +1
+ Misses        198      197       -1

Impacted Files
Coverage Δ

core/src/main/scala/io/finch/Endpoint.scala
73.14% <0%> (+0.57%)
:arrow_up:

Continue to review full report at Codecov.

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


Update security-center-recommendations.md

@monhaber

@MiriLandau : Thanks for your contribution! The author, @rkarlin, has been notified to review your proposed change.

@rkarlin  please send to Monica


[Hexagon] Do not auto-build apps when building TVM

The Hexagon cmakes have recently become unwieldy due to a complex network of dependencies between various automatically built components. This was in large part because of trying to automatically build some apps, which then tried to build TVM runtimes again, but with their own configurations.
This patch removes the ability to automatically build any Hexagon-related apps from the main TVM build. The following cmake options are now deprecated:

USE_HEXAGON_LAUNCHER
USE_HEXAGON_PROXY_RPC

In order to build the binaries needed for HexagonLauncher from tvm.contrib.hexagon:

Build TVM+runtime for x86, with codegen for Hexagon enabled. This can be done via USE_HEXAGON_DEVICE=sim or target.
Build Android runtime and tvm_rpc with -DUSE_RPC=ON, -DUSE_CPP_RPC=ON, and -DUSE_HEXAGON_RPC=ON.
Build Hexagon runtime with -DUSE_HEXAGON_RPC=ON, and -DBUILD_STATIC_RUNTIME=ON.

Thanks for contributing to TVM!   Please refer to guideline https://tvm.apache.org/docs/contribute/ for useful information and tips. After the pull request is submitted, please request code reviews from Reviewers by @ them in the pull request thread.

cc: @mehrdadh

I like the idea of simplifying the build process, but I'm worried that this would make it more difficult for developers to test changes.  This PR would reduce the complexity of the existing cmake setup, but I think it would result in passing that complexity to the developer to manually handle.
Build details, as I understand them.

Three TVM builds are required.  (Host, connected Android, connected Hexagon)
Each of the three builds has different values for the RPC and static/dynamic options.
All three builds must have the same values for several build variables.

Hexagon: USE_HEXAGON_SDK and USE_HEXAGON_ARCH
Android: USE_ANDROID_TOOLCHAIN

All three builds must have be built from the same version of TVM.
All three builds must output to the same location (currently $BUILD_DIR/apps/hexagon_*).

Brainstorming on options

Option 1: Top-level TVM CMake launches the three independent builds as external projects

Current implementation on main.
Pro: Developer can run make && run_my_test.py to rebuild all three tests in a single step.
Con: Difficult to manage setup.

Option 2: Developer launches the three independent builds

Current implementation in this PR.
Pro: Easier to manage cmake setup.
Con: Interactions between the three builds must be handled by each developer, either manually or by writing a wrapper build script.
Con: Removes the app from the TVM framework.  Compiling TVM is no longer sufficient to use tvm.contrib.hexagon.

Option 3: App Cmake launches all three independent builds

Pro: Developer can run tests from a single location
Pro: Includes occur only in one direction, from the app to the TVM build.
Con: Removes the app from the TVM framework.  Compiling TVM is no longer sufficient to use tvm.contrib.hexagon.

Between the high-level options, I'd prefer Option 1, since it would maintain the same developer-facing interactions.  Thoughts?

I chatted with Mehrdad and we're going with an app that will build the Hexagon RPC support.


Fixes issues with shape of output for reduce_logsumexp in graph mode

Also adds docs for select_v2 (maybe could be removed from PR since not relevant)
addr: #35099

@googlebot I signed it!

@rrkarim  Can you please resolve conflicts? Thanks!

@rrkarim Can you please resolve conflicts? Thanks!

Not sure what do you mean by resolving the conflicts. I've resolved all the issues and addressed the lack of docs.

@rrkarim  File tensorflow/python/ops/math_ops.py have conflicts. To check conflicts, please click on Resolve conflicts button. Please, resolve them. Thanks!

@gbaned resolved, sorry for the delay on that.


pull request for e2e test at 12/15/2016 01:56:09

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


Update docs for Remote Segment and Remote Translog store stats surfaced via nodes/indices/cluster stats APIs

Description
Continuing with https://github.com/opensearch-project/documentation-website/pull/4995
Checklist

[x] By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and subject to the Developers Certificate of Origin.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Closing in favor of the original PR. I went ahead and implemented the edits there.


Add strict mode

This commit adds strict mode: a special bundle of Microcosm that
includes development-only assertions. It also adds an installation
guide for setting up strict mode with Webpack.
Fixes:
https://github.com/vigetlabs/microcosm/issues/280

Codecov Report

Merging #285 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #285   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          22     22
  Lines         771    771
=====================================
  Hits          771    771

Continue to review full report at Codecov.

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

@leobauza We probably want to flesh out the installation.md doc more. This is just the bare minimum I thought necessary.


[GAL-2036] add link to support article in gallery editor

TODO

[ ] Add notion link

Demo
https://user-images.githubusercontent.com/4480258/215938723-55dd47a6-8635-4994-be7a-6721269086be.mp4

@Robinnnnn updated the icon. Might looks much better

thank you @jakzaizzat 🔥 🔥 🔥


[Python] Provide pybind11 type casters

Describe the enhancement requested
pybind11 allows defining custom type casters to translate between C++ classes and Python objects:
https://pybind11.readthedocs.io/en/stable/advanced/cast/custom.html
We already provide a C++ API to wrap and unwrap PyArrow objects from/to PyObject pointers. It would probably nicer to pybind11 users if we also provided a more automated facility.
A draft implementation of some type casters was done by @timkpaine here:
https://github.com/timkpaine/arrow-cpp-python-nocopy/blob/main/src/apn-python/caster.hpp
Component(s)
Python

@AlenkaF @jorisvandenbossche

I copied this from @maartenbreddels https://github.com/vaexio/vaex-arrow-ext/blob/master/src/caster.hpp
It’s definitely useful to have this pybind utility, the only thing I think would be important is to make a big (bigger?) warning about ABI compatibility. Every 6 months or so I forget that if I’m writing my own C++ library that I want to bind out into python to transfer arrows back and forth, I can’t necessarily just naively use the pyarrow interfaces.

Also cc @danepitkin

Shouldn't Apache Arrow use nanobind instead if possible? I guess the Arrow project is modern enough to use it (Python 3.8+, C++17 required)

s/shouldn't/couldn't
I think pybind is preferable given its popularity, but such an effort in pybind should be easy enough to translate into other binding libraries.

Shouldn't Apache Arrow use nanobind instead if possible? I guess the Arrow project is modern enough to use it (Python 3.8+, C++17 required)

PyArrow uses neither. This issue is about better supporting users of pybind11, not using it in PyArrow.


The method 'getSample' not working

I search in many places where the code to put to work but I can't find

Can you share your code please?
Generally you need to do it after initialisation.
Plus, be aware that this function is in the master, but not in npm (you need to user link to github in order to use it)

This is my class responsible to put the data the way I need.
import AppleHealthKit from 'rn-apple-healthkit';
import * as math from 'mathjs';
import { convertMetersToKm } from 'app/utils/number';

class AppleWatch {
  static name = 'AppleWatch';
  static options = {
    permissions: {
      read: [
        "Height",
        "Weight",
        "StepCount",
        "DateOfBirth",
        "HeartRate",
        "ActiveEnergyBurned",
        "DistanceCycling",
        "DistanceWalkingRunning"
      ]
    }
  };

  start() {
    return new Promise((resolve, reject) => {
      AppleHealthKit.initHealthKit(AppleWatch.options, error => {
        if(error) {
          reject(error);
        } else {
          resolve();
        }
      });
    })
  }

  getStepCount(date) {
    return new Promise(resolve => {
      AppleHealthKit.getStepCount({ date }, (error, results) => {
        resolve(!error ? this.clearValue(results.value) : 0);
      });
    });
  }

  getEnergyBurned(startDate, endDate) {
    return new Promise(resolve => {
      AppleHealthKit.getActiveEnergyBurned({ startDate, endDate }, (error, results) => {
        resolve(!error ? this.calculateValues(results) : 0);
      });
    });
  }

  getHeartBeats(startDate, endDate) {
    return new Promise(resolve => {
      AppleHealthKit.getHeartRateSamples({ startDate, endDate }, (error, results) => {
        resolve(!error ? results.map(item => item.value) : []);
      });
    });
  }

  getDistanceWalkingRunning(date) {
    return new Promise(resolve => {
      AppleHealthKit.getDistanceWalkingRunning({ unit: 'meter', date }, (error, results) => {
        resolve(error ? 0 : convertMetersToKm(results.value));
      });
    });
  }

  getActivities(startDate, endDate) {
    return new Promise(resolve => {
      AppleHealthKit. getSamples({ startDate, endDate }, (error, results) => {
        resolve(error ? {} : results);
      });
    });
  }

  calculateValues(data) {
    let value = data.reduce((acc, item) => {
      acc = math.add(math.bignumber(acc), math.bignumber(item.value));
      return acc;
    }, 0);

    value = math.floor(value);
    value = value.valueOf();

    return value;
  }

  clearValue(value) {
    value = math.floor(math.bignumber(value));
    return value.valueOf();
  }
}

export default AppleWatch;

My action:
export const getActivities = async (device, startDate, endDate) => {
  const reference = await getApiReference(device);
  return reference.getActivities(startDate, endDate);
};

function getApiReference(device) {
  return new Promise(async resolve => {
    switch(device) {
      case AppleWatchApi.name:
        const api = new AppleWatchApi();
        await api.start();
        resolve(api);
      break;
    }
  })
}

The erro is: "getSamples" is not a function and yes I try to using the master branch.

for getSamples in options you need to use also type field.
Check docs here https://github.com/terrillo/rn-apple-healthkit/blob/master/docs/getSamples().md
However the error is strange... Only getSamples is not working?
Maybe the world went crazy and the problem is in a space after dot AppleHealthKit. getSamples ?
small advice, better to use constants, somelike this:
const PERMS = AppleHealthKit.Constants.Permissions;
const healthKitOptions = {
  permissions: {
    read: [
      PERMS.ActiveEnergyBurned,
      PERMS.DistanceCycling,
      PERMS.DateOfBirth,
      PERMS.FlightsClimbed,
      PERMS.Height,
      PERMS.BiologicalSex,
      PERMS.StepCount,
      PERMS.Steps,
      PERMS.DistanceWalkingRunning,
      PERMS.Weight,
      PERMS.Workout,
    ],
    write: [
      PERMS.Weight,
    ],
  }
};

I will try put it to work considering your observations, but this error only shows up when I try to use this method.
About permissions constants: Yes, I see that constants a few days ago, thanks for the tip.

Also sometimes I had problems with package manager, that when changing package.json and call install command - packages didn't change.
So, also pls check node_modules/rn-apple-healthkit/RCTAppleHealthKit/RCTAppleHealthKit+Queries.m
is content the same as https://github.com/terrillo/rn-apple-healthkit/blob/715a0ebe9e50fb867f8a07a4bd9d2e89a2ebd425/RCTAppleHealthKit/RCTAppleHealthKit%2BQueries.m#L110 ?

Ok, I will check this.
And John, thanks for everthing.

Hi, I found the problem: I forget to rebuild in xcode, I just update the package and put to run, now works well.
Thanks for your tips.


Add check to allow sized assoc types

While most associated types are not dyn-compatible, they can be when bounded by Self: Sized. This PR allows such associated types to work with typetag. It additionally removes the check on the impl block for associated types.
As an example, this now functions properly
#[typetag::serde]
trait MyTrait {
    type MyType
    where
        Self: Sized;
}

#[derive(serde::Serialize, serde::Deserialize)]
struct MyStruct;

#[typetag::serde]
impl MyTrait for MyStruct {
    type MyType = i32;
}

Note, I'm fairly new to syn, so if there's an easier way to check for Self: Sized, I'm happy to tweak it to clean it up.

Looking at the CI and after some digging, it looks like this was made possible in Rust 1.74?
So if this is to be merged, I would guess the pinned rust version would also need to be bumped unfortunately.


Where is the HybridLLMPlanner script available?

Hi @hairuoliu1,
we implemented all baselines in a fork of the tuplan_garage.
We are currently in the process of releasing this code as well and contributing it to the official repository.
I will follow up here once the code is available.

Quick follow-up: until the final release, you can find the code for the LLM-Planners here: https://github.com/mh0797/tuplan_garage_llm_baselines

Quick follow-up: until the final release, you can find the code for the LLM-Planners here: https://github.com/mh0797/tuplan_garage_llm_baselines

Does this code work, and how to run it

Hi,
it does work. Simply install the repository. Then you should be able to run the planners in the same way as all remaining planners from tuplan_garage.


Gateway metrics and statistics

Gateway operators would benefit from historical stats on the services offered to federations and it's users. These may include

volume: count of all payments processed
size: aggregate (in sats) of all payments processed
outcome: rates of success / failure in processing payments
derived: derived stats on individual payments processed, for example, the average size of a payment from a federation

Note: metrics might be aggregated along these dimensions

incoming vs outgoing paymens
per federation / globally for this gateway
by time ranges

seems related to #1583 .wonder if you have some time for a chat about implementation details sometime this week @okjodom


remove 'jspm_packages' by default

since it's smart enough to avoid linting node_modules and bower_components, let's also remove jspm_packages

We don't currently ignore bower_components. This is a slippery slope. I don't want standard to be responsible for ignoring files for every new alternative package manager. You can ignore folders manually by following these instructions in the readme.

@la-yumba If you are using any editors like VS Code with standard extension, you can ignore those jspm_packages globally by configuring settings.json instead of configuring every package.json of your projects.


Add-Type fails on large environment variables

remove Add-Type in IIS psm to pass in definitions using large amount of environment variables

I need to get a resolution on this task. Manually editing deployed files from the task just would scale for us.
Also, I lack permissions to see why the CI build failed


Combine #301 & #302 dependabot prs

Combine #301 & #302 into one PR which will compile, individually, the 2 would not.

There is a problem with these go mod updates, lint and test actions are failing:
# github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema
Error: ../../../go/pkg/mod/github.com/hashicorp/terraform-plugin-sdk/v2@v2.28.0/helper/schema/provider.go:511:9: cannot use NewGRPCProviderServer(p) (value of type *GRPCProviderServer) as tfprotov5.ProviderServer value in return statement: *GRPCProviderServer does not implement tfprotov5.ProviderServer (missing method GetMetadata)

Skipping these and waiting for next ones.


fixed the stroke width issue with single color in streamlines

Overview: What does this pull request change?

Fixed #3363
Now the single color also has no issue with stroke width

Motivation and Explanation: Why and how do your changes improve the library?

Links to added or changed documentation pages

Further Information and Comments

Reviewer Checklist

[ ] The PR title is descriptive enough for the changelog, and the PR is labeled correctly
[ ] If applicable: newly added non-private functions and classes have a docstring including a short summary and a PARAMETERS section
[ ] If applicable: newly added functions and classes are tested

Thanks for these proposed changes! It would be nice to have a test for this, could you perhaps add one to either this file: https://github.com/ManimCommunity/manim/blob/main/tests/module/mobject/types/vectorized_mobject/test_stroke.py or in a new file for the streamlines mobject?


0.1.0 Quirks

EDIT: FIXED. It would appear we don't support python 3.5 before 3.5.4 (fails at initialization in 'safe_import').

Investigate why, see if it's worth tweaking approach to broaden python support.

Behaviour changed in 3.5.4, changing the type of error in some situations.

pip install fooof[plot] doesn't seem to actually install a working install of matplotlib (on MacOS - fails with backend error). This is also true with pip install fooof[all]

So, for some reason, specializing matplotlib as a dependency that gets installed with it doesn't lead to a working install of mpl out of the box.
Figure out why / how to fix.

So the 'pip install fooof['all']' or 'pip install fooof['plot']' still has the issues mentioned above, but it really isn't anything to do with us (it's a matplotlib install thing), and I think it's probably a pretty rare event. I'm going to close this now - if we hear about any issues with this point, we can / should perhaps add some comments into the docs / README / install instructions.


chore(menu): migrate to new life cycles

also fixes dispose (yay)!
IFW-882

Summary

Result

You have the fix the merge issue, the menu uses getConfiguration({}) somewhere.


Corrections to health checks doc

Description
https://jira.mesosphere.com/browse/MARATHON-7557
Urgency

[ ] Blocker
[ ] High
[X] Medium

Requirements

Test all commands and procedures.
Build content locally and test for formatting/links.
Add redirects to dcos-website/redirect-files.
Change all affected versions (e.g. 1.7, 1.8, and 1.9).
See the contribution guidelines.

@joel-hamill comments addressed


Remove clang_experimental build for real this time

Problem
This build was intended to be removed in 9488c1ab2 ("Remove linux
clang_experimental build (#7467)") but was left in the matrix and has
since been wasting capacity.
Change overview
To prevent waste going forward, make unrecognized build types in the
matrix fail when deriving the arguments. Also, simplify the arguments
setting a bit - for brevity options that are defaults are not specified;
the original builds worked this way but the new logging build did not.
Testing
Run CI.

@jepenven-silabs @Damian-Nordic @saurabhst


Schema updates

[x] Fix #39 by making NaN a missing value
[x] Fix #40 by making a number of columns optional
[x] Switch order to lat, long
[x] Add source_file column, #41

Todo

[x] Verify with @adokter
[x] Update https://aloftdata.eu/vpts-csv/#example with new column and data s3://noaa-nexrad-level2/2016/09/01/KBGM/KBGM20160901_000212_V06
[x] Indicate that sort order is radar, datetime, height and source_file. The latter will make sure that duplicates are more easy to spot within a height
[x] Move source file to aloft repo
[x] Ping @stijnvanhoey about these changes

I've added a requirement to source_file inspired by Frictionless's url-or-path that restricts values that start with ../ and /. This to avoid injection of file paths that might be harmful. I hope that is ok.

https://aloftdata.eu/vpts-csv/ now reflects the updated format

@peterdesmet can we reflect the version of the csv-schema in a follow up PR? cfr. https://github.com/enram/vptstools/issues/21

Done, there is now a v1.0 release: https://github.com/enram/vpts-csv/releases/tag/v1.0


Can't start app from VS 2022 when WT is set as the default terminal

An error box is display anytime I start a console application from VS 2022 after an app was closed (clicking on the cross) before it's finished. Unsetting WT as the default terminal fixes the issue.
Repro:

Set WT as the default terminal in the settings
Create a console application in VS with a Console.ReadLine()
Start the application from VS (CTRL+F5), and close it to terminate it
Start the application from VS, the following message is displayed

---------------------------
My.exe - Application Error
---------------------------
The application was unable to start correctly (0xc0000142). Click OK to close the application.
---------------------------
OK
---------------------------

Version tested:
WT 1.12.2931.0
VS 2022 17.1.0 Preview 1.0
Mitigations:

After restarting VS the issue disappears.
After setting Windows Console host as the default terminal application the issue disappears.

Thanks for the suggestion! This is actually already being tracked by another issue on our repo - please refer to #10974 for more discussion.
/dup #10974


Two typos?

config/initializers/session_store.rb:
-Forums::Application.config.session_store :cookie_store, key: '_forums_session'
+Forums::Application.config.session_store :cookie_store, :key => '_forums_session'
config/initializers/wrap_parameters.rb:
-ActionController::Base.wrap_parameters format: [:json]
+ActionController::Base.wrap_parameters :format => [:json]

Holger

I'm sorry but I don't understand. Those are files rails generates if you use MRI Ruby 1.9.x

OK, sorry, I'm new to this. I had to make above changes to get it to run. I'll close the issue. Thanks!

No problem :-) thanks!


feat: Angular2 Currency Pipe not working on iOS

Type: feat
Ionic Version: 2.x
Platform: ios 9 webview
Angular2 is using the ECMAScript Internationalization API for e.g. its currency pipe.
Unfortunately all current Safari browser don't support that API, so {{product.price' | currency: 'USD':true}} won't work on iOS.
I got this working for now by using this polyfill:
https://github.com/andyearnshaw/Intl.js
I'm aware that this is an angular2 issue but I'd suggest to include this polyfill until this is fixed on angular side to not confuse ionic2 users.

Hey @flavordaaave How did you manage to put it to work? i'm using the numeric pipe and i'm importing the polyfill in the entries of the webpack config file and yet my app brokes in IOS.

I'm hesitant to add this to the core of Ionic, as it seems like a pretty large library that many apps may not need. However, having some good docs on how to get add this to webpack yourselves would be pretty useful. Does anyone have a good example on how to include this?

I just did with webpack, in entries after installing the npm package just put:
module.exports = {
  entry: [
    path.normalize('es6-shim/es6-shim.min'),
    'reflect-metadata',
    path.normalize('zone.js/dist/zone-microtask'),
    'intl/index.js',
    'intl/locale-data/jsonp/en.js',
    path.resolve('app/app')
  ],

However this could not be the best way of using it.

Thanks @Luchillo fixed my problem too! https://github.com/driftyco/ionic/issues/5601

I agree that this probably should not be added to the core framework, but this should definitely be included in the docs, maybe in the faq section on the docs? @adamdbradley thoughts?

@Luchillo  Thanks for solution! But didn't worked for me though.
I have installed intl via npm and added following lines to webpack.config.js:
entry: [
    path.normalize('es6-shim/es6-shim.min'),
    'reflect-metadata',
    path.normalize('zone.js/dist/zone-microtask'),
    'intl/index.js',
    'intl/locale-data/jsonp/ru.js',
    'intl/locale-data/jsonp/en.js',
    path.resolve('app/app')

But still I could see that Safari claims

"Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8100/build/js/es6-shim.map"

Please help!
Did I miss something?

Well i'm not sure, i just use the en.js locale and it works with the numeric pipe, which also uses the intl package, idk if it works with the currency pipe or it lacks any other extra step for the currency pipe.
Have you tried with just the en.js alone? in mine i just use that locale data, try and see if the currency pipe works with that and USD currency.

@Luchillo I'm using the same configuration as you do but for me it is working without any errors:
module.exports = {
  entry: [
    path.normalize('es6-shim/es6-shim.min'),
    'reflect-metadata',
    path.normalize('zone.js/dist/zone-microtask'),
    'intl/index.js',
    'intl/locale-data/jsonp/zh.js', // Chinese locale
    'intl/locale-data/jsonp/en.js', // English locale
    path.resolve('app/app')
  ],

@flavordaaave So you made it work? great, it seems you have 2 type of currencies, since @fedorinoGore has also 2 currencies and his app breaks i think his app is miss-configured or installed, can both of you put the output of ionic info to see what version of all are you using? for instance here's mine:
ionic info

Your system information:

Cordova CLI: 6.0.0
Gulp version:  CLI version 1.2.1
Gulp local:   Local version 3.9.1
Ionic Version: 2.0.0-beta.3
Ionic CLI Version: 2.0.0-beta.19
Ionic App Lib Version: 2.0.0-beta.9
ios-deploy version: 1.8.5
ios-sim version: 5.0.6
OS: Mac OS X El Capitan
Node Version: v5.6.0
Xcode version: Xcode 7.2.1 Build version 7C1002

Cordova CLI: 6.0.0
Gulp version:  CLI version 3.9.0
Gulp local:   Local version 3.9.1
Ionic Version: 2.0.0-beta.3
Ionic CLI Version: 2.0.0-beta.19
Ionic App Lib Version: 2.0.0-beta.9
ios-deploy version: 1.8.2
ios-sim version: 5.0.4
OS: Mac OS X El Capitan
Node Version: v5.4.1
Xcode version: Xcode 7.2.1 Build version 7C1002

@fedorinoGore You asked what you may have missed.  You probably didn't miss this, but you must quit in the command line (q) and run ionic serve again, too apply webpack changes.......   I doubt you missed this, but mentioning anyway

@Luchillo
Your system information:
Cordova CLI: 6.0.0
Ionic Version: 2.0.0-beta.3
Ionic CLI Version: 2.0.0-beta.19
Ionic App Lib Version: 2.0.0-beta.9
ios-deploy version: Not installed
ios-sim version: 5.0.6
OS: Mac OS X El Capitan
Node Version: v5.7.1
Xcode version: Xcode 7.2.1 Build version 7C1002

@alexbainbridge Nope, that is not it. I restarted server just after modifying webpack config.

@fedorinoGore What about your package.json and webpack.config.json can you post it to debug?

Hello! Thanks for opening an issue with us! Since it has been a little while since there was any activity on this issue i will be closing it, but feel free to respond back if your still having the issue! Thanks again!

Ups... I was too slow.

Has someone figured out a nice way to include the intl package with the new browserify gulp task?

My solution is to add the needed scripts to src like this:
buildBrowserify({
  watch: true,
  src: [
    './app/app.ts',
    './typings/main.d.ts',
    './node_modules/intl/index.js', // Fix internationalization on safari browsers (used in angular2 currency pipes)
    './node_modules/intl/locale-data/jsonp/zh.js', // Chinese locale
    './node_modules/intl/locale-data/jsonp/en.js' // English locale
  ]
}).on('end', done);
``

@flavordaaave So you moved to browserify? I'm still using Webpack, and it works as a charm, i can't help you with browserify.

I tried to do this by just referencing 'intl/index.js' and 'intl/locale-data/jsonp/en.js' in my index.html and including the files in the build folder but this didn't seem to make it work.
Could do with some help getting this into my project! Using the latest ionic-beta.10

@mbrookson first what build workflow do you use? i made it work in webpack but if you want to use browserify ask @flavordaaave.
Second, for me i just import it in my polyfills.ts file (Where the polyfills should go), idk if it exists in your build workflow but try importing instead of using reference in the html.
Third, make sure it is being loaded, in browser look at the network tab, in ios (which is the real reason to use this polyfill) use safari inspector to inspect the app and then look at the network tab.

@Luchillo I am using the default browserify build. The polyfills.ts file doesn't exist anywhere in my project.
@flavordaaave Where did you add the scripts using browserify? Did you just modify the build file in the ionic-gulp-browserify-typescript folder?

@mbrookson
gulp.task('watch', ['clean'], function(done){
  runSequence(
    ['sass', 'html', 'fonts', 'scripts', 'assets'],
    function(){
      gulpWatch('app/**/*.scss', function(){ gulp.start('sass'); });
      gulpWatch('app/**/*.html', function(){ gulp.start('html'); });
      gulpWatch('app/assets/**/*', function(){ gulp.start('assets'); });
      buildBrowserify({
        watch: true,
        src: [
          './app/app.ts',
          './typings/main.d.ts',
          './node_modules/intl/index.js', // Fix internationalization on safari browsers (used in angular2 currency pipes)
          './node_modules/intl/locale-data/jsonp/zh.js', // Chinese locale
          './node_modules/intl/locale-data/jsonp/en.js' // English locale
        ]
      }).on('end', done);
    }
  );
});

gulp.task('build', ['clean'], function(done){
  runSequence(
    ['sass', 'html', 'fonts', 'scripts', 'assets'],
    function(){
      buildBrowserify({
        src: [
          './app/app.ts',
          './typings/main.d.ts',
          './node_modules/intl/index.js', // Fix internationalization on safari browsers (used in angular2 currency pipes)
          './node_modules/intl/locale-data/jsonp/zh.js', // Chinese locale
          './node_modules/intl/locale-data/jsonp/en.js' // English locale
        ]
      }).on('end', done);
    }
  );
});

@flavordaaave Cool, thanks. So is that the root level gulpfile that you've changed?

@mbrookson yes, I just updaten those 2 tasks in my root gulpfile.

@flavordaaave Does browserify have any notion of order or priority? i would put the dependencies up in the array, does browserify not care about that?

@Luchillo to be honest I don't know. It was working for me that way so I didn't change anything 😉

Hi,
I still have a problem with this, even though I did what @flavordaaave said. I seems that the Intl shim is being loaded however I get this error (Highlighting is my doing):

EXCEPTION: Error: Uncaught (in promise): EXCEPTION: Error in build/pages/nav-frame/nav-frame.html:23:20
ORIGINAL EXCEPTION: SyntaxError: Invalid regular expression: unmatched parentheses
ORIGINAL STACKTRACE:
RegExp@[native code]
RegExp@http://localhost:8100/build/js/es6-shim.min.js:10:28229
http://localhost:8100/build/js/app.bundle.js:69887:30
InitializeNumberFormat@http://localhost:8100/build/js/app.bundle.js:71374:18
NumberFormatConstructor@http://localhost:8100/build/js/app.bundle.js:71135:34
CreateDateTimeParts@http://localhost:8100/build/js/app.bundle.js:73195:35
FormatDateTime@http://localhost:8100/build/js/app.bundle.js:73376:36
F@http://localhost:8100/build/js/app.bundle.js:73145:34
F@[native code]
http://localhost:8100/build/js/app.bundle.js:4404:59
dateFormatter@http://localhost:8100/build/js/app.bundle.js:4414:39
format@http://localhost:8100/build/js/app.bundle.js:4449:29
transform@http://localhost:8100/build/js/app.bundle.js:8400:43
[native code]
http://localhost:8100/build/js/app.bundle.js:34770:24
detectChangesInternal
detectChanges@http://localhost:8100/build/js/app.bundle.js:34084:35
detectChanges@http://localhost:8100/build/js/app.bundle.js:34189:48
detectChanges@http://localhost:8100/build/js/app.bundle.js:34541:78
http://localhost:8100/build/js/app.bundle.js:1320:45
invoke@http://localhost:8100/build/js/zone.js:332:34
onInvoke@http://localhost:8100/build/js/app.bundle.js:39583:47
invoke@http://localhost:8100/build/js/zone.js:331:43
run@http://localhost:8100/build/js/zone.js:225:50
http://localhost:8100/build/js/zone.js:591:61
invokeTask@http://localhost:8100/build/js/zone.js:365:43
onInvokeTask@http://localhost:8100/build/js/app.bundle.js:39574:51
invokeTask@http://localhost:8100/build/js/zone.js:364:55
runTask@http://localhost:8100/build/js/zone.js:265:58
drainMicroTaskQueue@http://localhost:8100/build/js/zone.js:497:43
g@http://localhost:8100/build/js/es6-shim.min.js:11:1440
http://localhost:8100/build/js/es6-shim.min.js:11:1370
promiseReactionJob@[native code]
ERROR CONTEXT:
[object Object]

I checked the html and it is valid and works in Chrome and on Android:
<strong>{{ syncStats.lastSync | date:'mediumDate' }} {{ syncStats.lastSync | date:'mediumTime' }}</strong>

Has anyone had this issue before?
This is my setup:
Cordova CLI: 6.3.1
Ionic Framework Version: 2.0.0-beta.11
Ionic CLI Version: 2.0.0-beta.37
Ionic App Lib Version: 2.0.0-beta.20
ios-deploy version: Not installed
ios-sim version: Not installed
OS: Mac OS X El Capitan
Node Version: v6.4.0
Xcode version: Xcode 7.3.1 Build version 7D1014

@kchat001
Hello!
Did you manage to fix the problem? I have the same one using the DatePipe in Angular 2, Intl and iOS9.
Please let me know if you have any information on this.
Thank you!
René


FileSystemInfo.LinkTarget property is not exposed (this was added in .NET 6)

Describe the bug
I think (?) this is a bug because this is a property on System.IO.FileSystemInfo that is not on System.IO.Abstractions.IFileSystemInfo. This property was added in .NET 6 to help working with symlinks. See https://docs.microsoft.com/en-us/dotnet/api/system.io.filesysteminfo.linktarget?view=net-6.0
To Reproduce

Look at ApiParityTests.FileIno_.NET 6.0.snap
See that "System.String LinkTarget" is marked as a missing member

or

Write an app that needs to access LinkTarget

Expected behavior
I would expect IFileSystemInfo to have a LinkTarget property when this package is consumed by a .NET 6 app.
Note
I will be very happy to implement this. The only question I have is how does this project handle multitargetting? Any gotchas I need to know? Otherwise I'll add it and also add tests and such. I need this for something and want to help make it happen.

I've got the code almost ready to go. I need some guidance on adding to the test helpers--I'll put the PR up and we can discuss.

Thanks for bringing this up! I'll try to answer your questions in the PR!


Feature Request: Ability to apply 'alpha' transparency to icons

[Feature Request]
When using custom icons, it would be awesome to be able to apply an alpha value for transparency for the icon and have it be something we can change in a running dialog. I see that background images used in a dialog can have an alpha value applied, but not sure if this is really limited only to those types of image resources, or if it can apply to icons too.
What I'm thinking of is a way show the icon for an application (using a path to a png file) that is about to be installed and show the icon in a ghosted or semi translucent way, and then when installation is complete, change the icon to full opacity.
The only workarounds I can think of are to use either

2 icons for every application I would want to use this for - one at full opacity, and another one at, say 50% translucency, but that's a lot of work to create all those in advance. Possible, but kind of a lift to accomplish it.

Or, less desirable, would be to use a generic icon like...

...which is from the SF Symbols set, and then switch to the actual app icon. Again, it's a possibility, but it would be nicer if we could use icons with a level of transparency instead.

This was resolved a while ago so not sure why I didn't close this off.
us --iconalpha <value> where  is a number between 0.0 and 1.0 where 0 is transparant and 1 is opaque (e.g. 0.5 would represent 50% transparency)


Engine -> Flutter roll failing on ANR when requesting timeline

Starting with the roll here https://github.com/flutter/flutter/pull/94484
08:38 +10: test/integration.shard/timeline_test.dart: Can connect to the timeline without getting ANR from the application
Warning: test isolate is still active after 5 minutes. This is likely an app-not-responding error and not a flake. See https://github.com/flutter/flutter/issues/79498 for the bug this test is attempting to exercise.

18:19 +10 -1: test/integration.shard/timeline_test.dart: Can connect to the timeline without getting ANR from the application [E]
  TimeoutException after 0:15:00.000000: Test timed out after 15 minutes.
  dart:isolate  _RawReceivePortImpl._handleMessage

Initially suspecting the Dart roll here https://github.com/flutter/engine/pull/30011, which includes additional timeline events from https://dart.googlesource.com/sdk.git/+/ab0d8dc3b15bca336a70171d90fabbea99595ec3.
Another lead is that the first failing roll was the first to use today's randomization seed.

Confirmed that this started with https://github.com/dart-lang/sdk/commit/ab0d8dc3b15bca336a70171d90fabbea99595ec3
Dart has reverted that commit (https://github.com/dart-lang/sdk/commit/08fc11c44ced0aaf44a0cb53c6c5e74b67df0419)

Closing as presumed fix since the Dart revert has landed on the Dart dev branch, and the roller can restart.


Use mdfind for counsel-locate on a Mac

This is the more sensible option as locate isn't configured by default
and spotlight is turned on by default.

Similarly, I would like to set locate-command (for M-x locate) but i'm not sure where's the right place to do so.

We could set locate-command in the :tools macos module. I've also added mdfind support to helm-locate in 19ef10339.
Anyhow, thanks for the help and for bringing this to my attention!


fail to  pip gym==0.21.0

I can  pip install -r requirements.txt (in requirements.txt, gym==0.22.0)

Collecting gym==0.21.0
Using cached gym-0.21.0.tar.gz (1.5 MB)
Preparing metadata (setup.py) ... error
error: subprocess-exited-with-error
× python setup.py egg_info did not run successfully.
│ exit code: 1
╰─> [1 lines of output]
error in gym setup command: 'extras_require' must be a dictionary whose values are strings or lists of strings containing valid project/version requirement specifiers.
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed
× Encountered error while generating package metadata.
╰─> See above for output.
note: This is an issue with the package mentioned above, not pip.
hint: See above for details.

There seems to be an issue with the gym library. You can check out the problem here to see if there is a possible fix for the bug. If not, you can consider using a different version of the gym library around 0.21.0.

I have solved the problem,  below is the version I have installed.
ray==1.8.0
ray[tune]==1.8.0
ray[rllib]==1.8.0
icecream==2.1.3
torch==1.9.0
pettingzoo==1.12.0
pettingzoo[mpe]==1.12.0
supersuit==3.2.0
numpy==1.20.3
importlib-metadata==4.13.0
setuptools==65.5.0
gym==0.21.0
tensorboardx==2.2.0
protobuf==3.20
PyYAML

I had this error as well, but upgrading these packages fixed it.
pip install --upgrade pip setuptools wheel


Fix #140:Pattern 2.6 not Python 3 compatible

There was a syntax error in print.Due to recent changes in python3.
Reference: https://docs.python.org/3/whatsnew/3.0.html#print-is-a-function

:+1:

recent changes in python3

These aren't recent; Python 3.0 was released 8 years ago.

Fix #140:Pattern 2.6 not Python 3 compatible

I haven't looked in detail at the efforts to make Pattern compatible with Python 3, but I think much more is needed than this; see https://github.com/clips/pattern/issues/62.

You, guys are correct.I tried using 2to3 refractoring tool but many errors were coming up.

Perhaps close this PR, then?


Update dataframe.info

Changing this to a clean branch

Generally this looks like a decent approach to me.  Pinging @hussainsultan for his thoughts on dask.dataframe.DataFrame.info

Thank you @mrocklin for your assistance!

Hi @limx0, sorry for letting this sit so long. I only see one thing that needs to be cleaned up (the multiple calls to compute thing that Matt pointed out). You'll also need to fix the merge conflicts on your branch. Other than that, this looks good to me. Are you still interested in working on this?

Yep definitely @jcrist I'll fix this up tomorrow. Thanks!

Ping. If you don't have the time/desire to finish this up, I'd be happy to finish it for you.

@jcrist sorry have been on holiday (vacation) - I will do this today!

Yay for tests passing! Was there anything else you wanted to do here, or is this good to go?

I would have preferred to do it in less than 16 commits ;) but otherwise good to go! Thanks for your help

Thanks for sticking with it though and getting it done :). Merging!


Rewrap using Clang.jl

With #23 we switched to PROJ 6.1.0. This introduces new APIs and deprecates others. Currently the wrapper functions are not yet updated to reflect this. We need to rerun the wrapper with the (much improved) Clang.jl to cover the new API.

This was done in #27


Fix minor typo

Found a minor typo while following along.
Thank you for publishing this series, it's great!

Thanks!


fix typo in various dcp_ data library templates

This PR addresses issue number #249 in data library but should also address a larger projection issue that was found in the QA/QC process for https://github.com/NYCPlanning/db-pluto/issues/315. In db-pluto, @AmandaDoyle found that there were records where census tracts were being populated but the census block column was not which didn't make any sense. @Oysters1874 and I took a look into what the issue might be and she found that the spatial join in db-pluto between census block and tract worked if you specified the projection of the census block files in the join which led us to think that there was an issue with the projection coming from data library.
We discovered that there was a misspelling in the census block files (dcp_cb2020, dcp_cb2020_wi, etc...) with a value in the template "EMPTY_STRING_AS_NULL=YES" (correct way of spelling the var) was actually spelled as "STRING_EMPTY_AS_NULL=YES" in the census block templates. This was never caught in data library because it wouldn't throw an error but it did impact the projection - I don't totally understand as to why but with the correction in spelling the projections seem to be working now. After further exploration, I found 9 total templates with this misspelling error.
You can test this PR by running the files through data-library locally but I also tested it by updating a version of dcp_cb2010_wi in digital ocean https://cloud.digitalocean.com/spaces/edm-recipes?i=266877&path=datasets%2Fdcp_cb2010_wi%2F22a%2F. This link should bring you to the 22a version but with the most recent change in the template
Templates that need to be checked:

[x] dcp_cb2010_wi
[x] dcp_cb2010
[x] dcp_cb2020_wi
[x] dcp_cb2020
[x] dcp_cdta2020
[x] dcp_congressionaldistricts
[x] dcp_nta2010
[x] dcp_nta2020
[x] dcp_ntaboundaries

Great catch! And nice detailed writeup. Is

This was never caught in data library because it wouldn't throw an error but it didn't impact the projection

Supposed to be "but it did impact the projection"?
And how should I go about checking this? Is there one of the nine that hasn't been re-run yet that I can re-run and check the projection? Is looking at the CRS attribute on the geopandas geodataframe a sufficient check?

The first thing I did was to download the dcp_cb2020 and a dcp_ct2020 shapefiles from DO and bring them into QGIS to see if they were getting plotted correctly. To test that the spelling change to the template worked, I downloaded the latest dcp_cb2010_wi and compared that with the dcp_ct2010 file

Yep Jingyi that's right! Thanks for taking a look
I also want to say that the fix works for compressed and uncompressed output

The dcp_cdta2020 data for version 22a on DO appears to have good coordinates? Looking at the compressed file, there is no uncompressed file https://cloud.digitalocean.com/spaces/edm-recipes?i=266877&path=datasets%2Fdcp_cdta2020%2F22a%2F

I ran cdta2020 from the main branch on my local machine and couldn't reproduce the error. I was able to reproduce the error for congressional districts though. I tried compressed and uncompressed for both. Any ideas about why Max?

The congressional districts is still bad on my local machine, even when I remove the quotes around EMPTY_STRING_AS_NULL=YES (not sure if the quotes do anything, that's just one thing I tried)

I am not sure @SashaWeinstein. I just opened up the 22a dcp_nta2010 and dcp_nta2020 from DO (without running them through data-library) and these don't seem to have an issue with their projection either. I can swing by when you are back at your desk to chat

Congressional districts have been fixed with that commit! I think we should have a person other than me, Max or Jingyi review as we all contributed and then we can merge the PR and upload to s3!

@td928 this happens throughout data-library where the certain templates have "" and other's don't. I don't think this impacts the yaml files but it would be nice if we were consistent

@abrieff  If you run the dcp_cb2020 or the dcp_db2010 through data library (without sending to s3), you can see that the shapefile output properly outputs the boundaries in a lat/long within new york but if you switch the back to main and run it locally again the file isn't properly populated in geopandas or qgis (even though the .prj says the file is in wgs_1984 [epsg 4326])


Add Zhengtao's PPP

I think you can consider writing the PPP in past tense, as in the example given!

Codecov Report

Merging #279 (b133230) into master (0d35628) will increase coverage by 11.55%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             master     #279       +/-   ##
=============================================
+ Coverage     47.87%   59.42%   +11.55%
- Complexity      383      472       +89
=============================================
  Files            89       89
  Lines          1815     1824        +9
  Branches        229      232        +3
=============================================
+ Hits            869     1084      +215
+ Misses          846      661      -185
+ Partials        100       79       -21

Impacted Files
Coverage Δ

src/main/java/seedu/address/ui/TaskCard.java
0.00% <0.00%> (ø)

...ava/seedu/address/logic/parser/HarmoniaParser.java
80.00% <0.00%> (+5.00%)
:arrow_up:

...n/java/seedu/address/commons/core/index/Index.java
73.33% <0.00%> (+6.66%)
:arrow_up:

...ava/seedu/address/model/task/CompletionStatus.java
81.81% <0.00%> (+9.09%)
:arrow_up:

src/main/java/seedu/address/model/TaskList.java
74.07% <0.00%> (+11.11%)
:arrow_up:

...rc/main/java/seedu/address/model/ModelManager.java
82.53% <0.00%> (+13.18%)
:arrow_up:

src/main/java/seedu/address/model/task/Name.java
83.33% <0.00%> (+16.66%)
:arrow_up:

src/main/java/seedu/address/model/tag/Tag.java
81.81% <0.00%> (+18.18%)
:arrow_up:

...a/seedu/address/logic/parser/AddCommandParser.java
100.00% <0.00%> (+20.00%)
:arrow_up:

...in/java/seedu/address/logic/parser/ParserUtil.java
65.71% <0.00%> (+25.71%)
:arrow_up:

... and 18 more

Continue to review full report at Codecov.

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


Encoute running successfully, but no results.  Exceeded quota ??

Hello,
I've installed encoute as referred in the documentation. Installation completed successfully. When I ran the program using the command python main.py --api it was executed smoothly. When I tried to play a couple of audio files, I can't see any results in the response section.
I've only one default system microphone and permissions are also given.  What am I missing here ??

What does it mean by exceeded quota ??

Hi! To use the gpt 3.5 API and whisper API your key must be set up with an account with openai credits.
https://stackoverflow.com/questions/75898276/openai-chatgpt-gpt-3-5-api-error-429-you-exceeded-your-current-quota-please


Add LinksTemplate component

In the components/templates folder add a LinksTemplate.tsx file. Copy the structure of one of the other templates (they're all currently the same apart from name - contents will be added later). Update the component name so it matches the file name.
In the pages/[content].tsx file import the template and add it alphabetically in the correct place between the layout tags {page === "links" && <Links />}
Add the template data to the config file in data/pages.tsx: { name: "Links", href: "/links", content: "links" }

Hey @EmmaDawsonDev would love to work on this 😄

Hi @Aniket1026 there is already a pull request for this one but let me create an issue for another component template you can add

Thank you emma 😄


User Story 60501: azure-cognitive-search

Part of POC to test generating sample code and articles using OpenAI.

@grayzu @lonegunmanb This sample is ready for review.


How to use exactly orchy-core server?

How to correctly configure and run Orchy as an orchestrator of the micro frontend?
I'm studying Orchy on that codebase and I correctly created a svelte mfe (orchy/svelte-mfe) using the cli.
After I prepare and run the server:
...
"scripts": {
    "prepare": "cd ./node_modules/orchy-core && pnpm i",
    "orchy": "cd ./node_modules/orchy-core && pnpm w:wc dev",
    ...
}
...

I see the error that it cannot reach something like /api/v1/configuration/ so I write the orchy-config.json, page-config.json and page-cnfig.html into orchy/orchy_static and I serve it correctly using fastify (orchy/main.js):
...
fastify.register(require('@fastify/static'), {
    root: path.join(__dirname, 'orchy_static'),
    prefix: '/api/v1/configuration/',
})
...

If I go to localhost:3000/api/v1/configuration/page-config.com work but because the HTML that I wrote works in a normal web browser, instead the localhost:5173 seems not to work also if the warning is solved.
What do I wrong? How to use it correctly?

Hi Nicola,
I suggest you to take a look at the installation process.
As you'll see, you don't have to install all the orchy-core repository, but just some of its packages which are published on NPM.
About the server, you can actually use whatever you want to expose your static configuration (even the plain serve command is fine)

But I do not understand how to use the page-config.json how to serve it as a web page? Is it like micro-lc playground or do I understand wrong?

That file is used by the orchy orchestrator to download the configuration of the Micro-frontends.
You just need to serve it using your web server

If you have experience with docusaurus, here is how they are exposed for the project documentation: https://github.com/orchy-mfe/orchy-doc/tree/main/static/api/v1/configuration

U speack about the file that I find for example in that example: https://github.com/orchy-mfe/orchy-examples/tree/main/examples/communication-mfe-iframe that have a page-config.json, but it seams similar to the documentation that you share with me, so I must search about docusaurus. I search and I close this thread soon.

All these json files are used to configure orchy. You just need to expose them in the /api/v1/configuration path using the web server you like

and so I return to my problem I serve that files at /api/v1/configuration, so when I go to localhost:3000/api/v1/configuration/page-config.html it work.
But when I go to localhost:5173 it seams do not work I see:

But if I go to localhost:3000/api/v1/configuration/page-config.html I see:

Looking at the code you provided, you are just exposing orchy's configurations without using the orchestrator. Additionally, you are not exposing them in the /api/v1/configuration path


CFFL

CFFL

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_e4cb4ran1u/clone/recipe/meta.yaml:15: pip_install_args: pip install should be run with --no-deps.
ERROR: /tmp/abs_e4cb4ran1u/clone/recipe/meta.yaml:21: missing_wheel: For pypi packages, wheel should be present in the host section
ERROR: /tmp/abs_e4cb4ran1u/clone/recipe/meta.yaml:40: missing_license_family: The recipe is missing the about/license_family key.
ERROR: /tmp/abs_e4cb4ran1u/clone/recipe/meta.yaml:40: missing_dev_url: The recipe is missing a dev_url
WARNING: /tmp/abs_e4cb4ran1u/clone/recipe/meta.yaml:40: missing_description: The recipe is missing a description
ERROR: /tmp/abs_e4cb4ran1u/clone/recipe/meta.yaml:40: missing_documentation: The recipe is missing a doc_url or doc_source_url
Errors were found

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_5cngunz_es/clone/recipe/meta.yaml:15: pip_install_args: pip install should be run with --no-deps.
ERROR: /tmp/abs_5cngunz_es/clone/recipe/meta.yaml:21: missing_wheel: For pypi packages, wheel should be present in the host section
ERROR: /tmp/abs_5cngunz_es/clone/recipe/meta.yaml:40: missing_license_family: The recipe is missing the about/license_family key.
ERROR: /tmp/abs_5cngunz_es/clone/recipe/meta.yaml:40: missing_dev_url: The recipe is missing a dev_url
WARNING: /tmp/abs_5cngunz_es/clone/recipe/meta.yaml:40: missing_description: The recipe is missing a description
ERROR: /tmp/abs_5cngunz_es/clone/recipe/meta.yaml:40: missing_documentation: The recipe is missing a doc_url or doc_source_url
Errors were found


Database storage and updating

Currently the database is not hosted in the repository due to a storage restriction in GitHub. Users are encouraged to download it using the script flight_safety/get_data.py which will download it from dropbox and place it in the data folder, or to do the process themselves.
Issues with this approach:

Original database is a Microsoft Access (mdb) file.
The database we are using is that one, converted to sqlite3, which lets users working on Linux use it comfortably.
The sqlite3 database is stored in a dropbox account. If the original file is updated, we need to convert it and upload it again. As the dropbox account is personal, only @AlexS12 can do it.
The database is hosted in a personal Dropbox account.
This workflow could lead to different users having different versions of the database.
We are forced to maintain the script to download the data and place it in the convenient place.

We should radically change this approach. It could be great if we could find somewhere to place the data in sqlite format and some automatic process could convert the original mdb files each month (they are supposed to be updated every month). When importing flight_safety, it could check if the user is working with the last version of the database and warn him otherwise.
Available options? other approaches?

Have you considered Git LFS?
https://git-lfs.github.com/
According to https://help.github.com/articles/about-storage-and-bandwidth-usage/,

All personal and organization accounts using Git LFS receive 1 GB of free storage and 1 GB a month of free bandwidth.

And lastly, to provide some automated conversion, I can think of two options:

Heroku. I use it to host some Telegram bots and has plenty of free hours. https://www.heroku.com/
An automated Travis CI job with write permissions https://docs.travis-ci.com/user/cron-jobs/


Bigquery database dialect

Create a new database dialect to support Gorm's official Bigquery driver.

Hey @System-Glitch I have recently started working with Go Web Frameworks.
I am interested in working on this issue.
Let me know if it's still open and not assigned to anyone internally.
Thanks

Hello @pn03 and thanks for your interest! This issue is still open, you can start working on it if you want.
Feel free to contact me if you need any help or guidance.

Hey @System-Glitch thanks for the quick response.
I have started working on it. I am perusing code right now, I'll contact you if I am stuck anywhere

Hey @System-Glitch I have looked into the code of bigquery driver via link present in the issue.
I have written below template string for the bigquery resource.
func init() {
	database.RegisterDialect("bigquery", "bigquery://{projectID}/{location}/{dataSet}?{options}", bigquery.Open)
}

The {options} here corresponds to many options that BigQuery provides such as disable_auth, credentials_json, endpoint etc. For example
bigquery://projectID/location/dataset?endpoint=value1&disable_auth=false&credential_file=/etc/certs/private.key&credential_json=base64EncodedJSONString

configuration values of projectID, location etc need to provided in config/config.json of goyave project, right?

The naming and connection string is indeed very different from the other drivers so far. We could use:

{host} for the project ID and location
{name} for the dataset
But I'm not entirely satisfied by the host part, since "projectID/location" isn't really a host.

Alternatively, we could do just like sqlite and just use the {name} placeholder. It would make more sense to me.
Finally, we could add new placeholders and their associated configuration entries but I'm not a fan of this solution neither.

Hey @System-Glitch sorry, I have been a little busy at my work place. I'll work on this next week and get back to you.
Wish you Happy Christmas and a Happy New Year !!

Hey @System-Glitch sorry, I have been a little busy at my work place. I'll work on this next week and get back to you.
Wish you Happy Christmas and a Happy New Year !!

Of course no problem! Have a wonderful end of the year!


Phoenix tracing aborts chef-run

chef-client exists with a long stack trace that boils down to the fact that SYSTEM.TRACING_STATS already exists
^[[1;31mAborting command set because "force" is false and command failed: "CREATE TABLE SYSTEM.TRACING_STATS (trace_id BIGINT NOT NULL, parent_id BIGINT NOT NULL, span_id BIGINT NOT NULL, description VARCHAR, start_time BIGINT, end_time BIGINT, hostname VARCHAR, tags.count SMALLINT, annotations.count SMALLINT, CONSTRAINT pk PRIMARY KEY (trace_id, parent_id, span_id));"^[[m
Closing: org.apache.phoenix.jdbc.PhoenixConnection
---- End output of "bash"  "/tmp/chef-script20160412-15193-1srstf8" ----
Ran "bash"  "/tmp/chef-script20160412-15193-1srstf8" returned 2
[2016-04-12T06:15:59-04:00] ERROR: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

The changes to enable Phoenix tracing was idempotent on HDP 2.2 where the original changes were made. Looks like the behavior of sqlline.py from Phoenix must have changed in the later version included in HDP 2.3.x. Will look into this.

Looking sqlline.py code in HDP repo 2.2 and 2.3.4, there has been a change in the way return code is propagated up to the shell. This change is also made available on Apache Phoenix 4.6 as part of PHOENIX-2323. This change lets us to conditionally run "CREATE TABLE ..."

Resolved in PR #496 .