"on" modifier not working in ember-cli v3.6

https://github.com/mansona/ember-cli-notifications/blob/1fe3388cb6d3f4245fcf6eb4a7b7d0b6edbbaac1/addon/templates/components/notification-message.hbs#L2
Console Error: on is not a modifier: Helpers may not be used in the element form

@hsduiii Which ember version are you using with?

@hsduiii Which ember version are you using with?

Ember 3.6

We're getting the same error on Ember 2.18.2 after upgrading to version 6.2.0 of this package.
Any ideas?
Thanks!

@hsduiii I tried it with ember 3.6.1 and it is working fine for me. Can you provide little more information?
@joshuaswift @hsduiii  As far as I know, {{on}} modifiers works just fine in ember > 3.11.0 without any polyfill. But if you are < 3.11, please add ember-on-modifier polyfill if you haven't. By default ember-cli-notification has the on modifier polyfill, but just try manual installation and do let me know if that works.

Adding ember-on-modifier solved for me, thanks!

Yep solved it for me too 😄 thanks!

@hsduiii @joshuaswift Thanks for your quick reply and Please close the issue if it is solved.


Change global default AS number to be 64512

Reference: https://github.com/projectcalico/libcalico/issues/140


Job Summary in GitHub Actions shows many unrelated projects

Please see example screenshot below.  This is just a small snippet, there are hundreds of projects listed here.  This happens for each of our builds.
We use self-hosted runners that are long-lived / not ephemeral.
Two of my initial thoughts are a cluttered cache, or a cluttered gradle home.
I've tried to resolve the gradle home issue by running the following first in my workflow:
rm -rf ~/.gradle
However, this doesn't change anything for me.

@nnellanspdl Each Gradle build writes a results JSON file to $RUNNER_TEMP/.build-results.
The action then iterates over these to generate the job summary.
I guess we should either clean these up after the job completes, or make the directory unique for a Job invocation.
Pending a fix in the action, you can ensure that $RUNNER_TEMP/.build-results is cleared after each job. You shouldn't need to remove the ~/.gradle directory.

Clearing that worked, thanks!

This is still something we should address in the action implementation.

Fixed in #133


Zephyr Native POSIX select() implementation too frequent wakeup on pure timeout based use

Describe the bug
The implementation of the POSIX select() statement operates a bit inefficiently, by waking up prematurely at intervals much more frequently than the timeout specified to the statement.  This results in some thread inefficiencies.
What have you tried to diagnose or workaround this issue?
To ensure that select() was not being tripped up with any of the selectors, to isolate the return to just the timeout mechanism, I removed them from the statement similar to the following test condition:
        int count = zsock_select(maxFD + 1, 0, 0, 0, (struct zsock_timeval *)&tvTimeout);
What is also not clear is the relationship between the timeouts specified to the select statement in units of microseconds (e.g. 10,000 usec for a 10 ms interval) and the timestamp indicated in the logging.  There seems to be significant differences between them assuming the units are in milliseconds in the display content (e.g. 00:34:43.190,000, is the 190 milliseconds?)
To Reproduce
Steps to reproduce the behavior:

west build for Native-POSIX target
west run
make
See error

Expected behavior
I expect the select() statement update to be somewhat consistent with the timeout value provided as an argument.  Perhaps I misunderstand the specifics of how it is implement for the POSIX environment.   For example, when I set a timeout value of approximately 10 ms, I expect a wake up in that interval, i.e. I expect the thread to pend for a much longer duration.  Instead, the statement is not pending for anywhere near that interval, most likely it pends for hundreds of microsecond ranges.
Impact
Not a show stopper, just trying to understand the behavior and seeing if anything can be done to make the implementation more efficient.
Logs and console output
The following log shows the timing for condition IN to the select() and OUT of the select. Here the timeout values are in the 10 ms range.  The OUT log shows the elapsed time at exit in the hundred of microsecond range.  Epochs are listed numerically based on a 10 ms interval.  The underlying time base used is the POSIX monatomic clock at clock_gettime() as shown below.  Emulation is being performed on Native-POSIX without implementing any delays in Zephyr (e.g. the kernel configuration setting CONFIG_NATIVE_POSIX_SLOWDOWN_TO_REAL_TIME=n is present).
int rc = clock_gettime(getTimeOfDay ? CLOCK_REALTIME : CLOCK_MONOTONIC_RAW, &ts);
Environment (please complete the following information):

OS: (e.g. Linux)
Toolchain (e.g Zephyr SDK, ...)
Commit SHA or Version used latest of this date as:
*** Booting Zephyr OS build zephyr-v2.6.0-2852-g4b5bab2bc1d2  ***

Additional context
Program logs as follows:

4:42.510,000] <dbg> app.exec: select() OUT[epoch 16]: now (21192/169501), timeout (0/834), tvNextEpoch (21192/170000), elapsed (0/335), count 0
[00:34:42.510,000] <dbg> app.exec: select() IN [epoch 16]: now (21192/169807), timeout (0/193), m_tvNextEpoch (21192/170000)
[00:34:42.530,000] <dbg> app.exec: select() OUT[epoch 16]: now (21192/170133), timeout (0/193), tvNextEpoch (21192/170000), elapsed (0/326), count 0
[00:34:42.530,000] <dbg> app.exec: Pre-select: past next epoch: TDMA epoch 17 at now (21192/170431), timeout (0/193), next epoch (21192/170000)
[00:34:42.530,000] <dbg> app.setTvNextEpoch: Set m_tvNextEpoch (21192/180000)
[00:34:42.530,000] <dbg> app.onEpochTimeout: Epoch 17 at (21192/170884)
[00:34:42.530,000] <dbg> app.exec: select() IN [epoch 17]: now (21192/171033), timeout (0/8967), m_tvNextEpoch (21192/180000)
[00:34:42.550,000] <dbg> app.exec: select() OUT[epoch 17]: now (21192/171337), timeout (0/8967), tvNextEpoch (21192/180000), elapsed (0/304), count 0
[00:34:42.550,000] <dbg> app.exec: select() IN [epoch 17]: now (21192/171652), timeout (0/8348), m_tvNextEpoch (21192/180000)
[00:34:42.570,000] <dbg> app.exec: select() OUT[epoch 17]: now (21192/171963), timeout (0/8348), tvNextEpoch (21192/180000), elapsed (0/311), count 0
[00:34:42.570,000] <dbg> app.exec: select() IN [epoch 17]: now (21192/172255), timeout (0/7745), m_tvNextEpoch (21192/180000)
[00:34:42.590,000] <dbg> app.exec: select() OUT[epoch 17]: now (21192/172534), timeout (0/7745), tvNextEpoch (21192/180000), elapsed (0/279), count 0
[00:34:42.590,000] <dbg> app.exec: select() IN [epoch 17]: now (21192/172836), timeout (0/7164), m_tvNextEpoch (21192/180000)
[00:34:42.610,000] <dbg> app.exec: select() OUT[epoch 17]: now (21192/173175), timeout (0/7164), tvNextEpoch (21192/180000), elapsed (0/339), count 0
[00:34:42.610,000] <dbg> app.exec: select() IN [epoch 17]: now (21192/173512), timeout (0/6488), m_tvNextEpoch (21192/180000)
[00:34:42.630,000] <dbg> app.exec: select() OUT[epoch 17]: now (21192/173840), timeout (0/6488), tvNextEpoch (21192/180000), elapsed (0/328), count 0
[00:34:42.630,000] <dbg> app.exec: select() IN [epoch 17]: now (21192/174160), timeout (0/5840), m_tvNextEpoch (21192/180000)
[00:34:42.650,000] <dbg> app.exec: select() OUT[epoch 17]: now (21192/174463), timeout (0/5840), tvNextEpoch (21192/180000), elapsed (0/303), count 0
[00:34:42.650,000] <dbg> app.exec: select() IN [epoch 17]: now (21192/174787), timeout (0/5213), m_tvNextEpoch (21192/180000)
[00:34:42.670,000] <dbg> app.exec: select() OUT[epoch 17]: now (21192/175122), timeout (0/5213), tvNextEpoch (21192/180000), elapsed (0/335), count 0
[00:34:42.670,000] <dbg> app.exec: select() IN [epoch 17]: now (21192/175450), timeout (0/4550), m_tvNextEpoch (21192/180000)
[00:34:42.690,000] <dbg> app.exec: select() OUT[epoch 17]: now (21192/175796), timeout (0/4550), tvNextEpoch (21192/180000), elapsed (0/346), count 0
[00:34:42.690,000] <dbg> app.exec: select() IN [epoch 17]: now (21192/176025), timeout (0/3975), m_tvNextEpoch (21192/180000)
[00:34:42.710,000] <dbg> app.exec: select() OUT[epoch 17]: now (21192/176277), timeout (0/3975), tvNextEpoch (21192/180000), elapsed (0/252), count 0
[00:34:42.710,000] <dbg> app.exec: select() IN [epoch 17]: now (21192/176494), timeout (0/3506), m_tvNextEpoch (21192/180000)
[00:34:42.730,000] <dbg> app.exec: select() OUT[epoch 17]: now (21192/176695), timeout (0/3506), tvNextEpoch (21192/180000), elapsed (0/201), count 0
[00:34:42.730,000] <dbg> app.exec: select() IN [epoch 17]: now (21192/176911), timeout (0/3089), m_tvNextEpoch (21192/180000)
[00:34:42.750,000] <dbg> app.exec: select() OUT[epoch 17]: now (21192/177160), timeout (0/3089), tvNextEpoch (21192/180000), elapsed (0/249), count 0
[00:34:42.750,000] <dbg> app.exec: select() IN [epoch 17]: now (21192/177371), timeout (0/2629), m_tvNextEpoch (21192/180000)
[00:34:42.770,000] <dbg> app.exec: select() OUT[epoch 17]: now (21192/177616), timeout (0/2629), tvNextEpoch (21192/180000), elapsed (0/245), count 0
[00:34:42.770,000] <dbg> app.exec: select() IN [epoch 17]: now (21192/177820), timeout (0/2180), m_tvNextEpoch (21192/180000)
[00:34:42.790,000] <dbg> app.exec: select() OUT[epoch 17]: now (21192/178075), timeout (0/2180), tvNextEpoch (21192/180000), elapsed (0/255), count 0
[00:34:42.790,000] <dbg> app.exec: select() IN [epoch 17]: now (21192/178288), timeout (0/1712), m_tvNextEpoch (21192/180000)
[00:34:42.810,000] <dbg> app.exec: select() OUT[epoch 17]: now (21192/178535), timeout (0/1712), tvNextEpoch (21192/180000), elapsed (0/247), count 0
[00:34:42.810,000] <dbg> app.exec: select() IN [epoch 17]: now (21192/178752), timeout (0/1248), m_tvNextEpoch (21192/180000)
[00:34:42.830,000] <dbg> app.exec: select() OUT[epoch 17]: now (21192/178978), timeout (0/1248), tvNextEpoch (21192/180000), elapsed (0/226), count 0
[00:34:42.830,000] <dbg> app.exec: select() IN [epoch 17]: now (21192/179192), timeout (0/808), m_tvNextEpoch (21192/180000)
[00:34:42.850,000] <dbg> app.exec: select() OUT[epoch 17]: now (21192/179424), timeout (0/808), tvNextEpoch (21192/180000), elapsed (0/232), count 0
[00:34:42.850,000] <dbg> app.exec: select() IN [epoch 17]: now (21192/179631), timeout (0/369), m_tvNextEpoch (21192/180000)
[00:34:42.870,000] <dbg> app.exec: select() OUT[epoch 17]: now (21192/179822), timeout (0/369), tvNextEpoch (21192/180000), elapsed (0/191), count 0
[00:34:42.870,000] <dbg> app.exec: Pre-select: past next epoch: TDMA epoch 18 at now (21192/180029), timeout (0/369), next epoch (21192/180000)
[00:34:42.870,000] <dbg> app.setTvNextEpoch: Set m_tvNextEpoch (21192/190000)
[00:34:42.870,000] <dbg> app.onEpochTimeout: Epoch 18 at (21192/180338)
[00:34:42.870,000] <dbg> app.exec: select() IN [epoch 18]: now (21192/180438), timeout (0/9562), m_tvNextEpoch (21192/190000)
[00:34:42.890,000] <dbg> app.exec: select() OUT[epoch 18]: now (21192/180677), timeout (0/9562), tvNextEpoch (21192/190000), elapsed (0/239), count 0
[00:34:42.890,000] <dbg> app.exec: select() IN [epoch 18]: now (21192/180885), timeout (0/9115), m_tvNextEpoch (21192/190000)
[00:34:42.910,000] <dbg> app.exec: select() OUT[epoch 18]: now (21192/181127), timeout (0/9115), tvNextEpoch (21192/190000), elapsed (0/242), count 0
[00:34:42.910,000] <dbg> app.exec: select() IN [epoch 18]: now (21192/181338), timeout (0/8662), m_tvNextEpoch (21192/190000)
[00:34:42.930,000] <dbg> app.exec: select() OUT[epoch 18]: now (21192/181584), timeout (0/8662), tvNextEpoch (21192/190000), elapsed (0/246), count 0
[00:34:42.930,000] <dbg> app.exec: select() IN [epoch 18]: now (21192/181799), timeout (0/8201), m_tvNextEpoch (21192/190000)
[00:34:42.950,000] <dbg> app.exec: select() OUT[epoch 18]: now (21192/182038), timeout (0/8201), tvNextEpoch (21192/190000), elapsed (0/239), count 0
[00:34:42.950,000] <dbg> app.exec: select() IN [epoch 18]: now (21192/182271), timeout (0/7729), m_tvNextEpoch (21192/190000)
[00:34:42.970,000] <dbg> app.exec: select() OUT[epoch 18]: now (21192/182540), timeout (0/7729), tvNextEpoch (21192/190000), elapsed (0/269), count 0
[00:34:42.970,000] <dbg> app.exec: select() IN [epoch 18]: now (21192/182765), timeout (0/7235), m_tvNextEpoch (21192/190000)
[00:34:42.990,000] <dbg> app.exec: select() OUT[epoch 18]: now (21192/182970), timeout (0/7235), tvNextEpoch (21192/190000), elapsed (0/205), count 0
[00:34:42.990,000] <dbg> app.exec: select() IN [epoch 18]: now (21192/183194), timeout (0/6806), m_tvNextEpoch (21192/190000)
[00:34:43.010,000] <dbg> app.exec: select() OUT[epoch 18]: now (21192/183461), timeout (0/6806), tvNextEpoch (21192/190000), elapsed (0/267), count 0
[00:34:43.010,000] <dbg> app.exec: select() IN [epoch 18]: now (21192/183675), timeout (0/6325), m_tvNextEpoch (21192/190000)
[00:34:43.030,000] <dbg> app.exec: select() OUT[epoch 18]: now (21192/184098), timeout (0/6325), tvNextEpoch (21192/190000), elapsed (0/423), count 0
[00:34:43.030,000] <dbg> app.exec: select() IN [epoch 18]: now (21192/184438), timeout (0/5562), m_tvNextEpoch (21192/190000)
[00:34:43.050,000] <dbg> app.exec: select() OUT[epoch 18]: now (21192/184696), timeout (0/5562), tvNextEpoch (21192/190000), elapsed (0/258), count 0
[00:34:43.050,000] <dbg> app.exec: select() IN [epoch 18]: now (21192/184915), timeout (0/5085), m_tvNextEpoch (21192/190000)

Hi @bob2oneil . I'm not completely sure I understand what you describe. But it would seem the issue is about mixing simulated time and real time.
I'm assuming the following from your description:

When you say select you always refer to zsock_select() (Zephyr's API, and never to the host kernel/Linux);
You have a small loop, calling  clock_gettime() (a call to the Linux kernel), using the Zephyr logger to print that time stamp out,  , calling zsock_select(), and clock_gettime() and printing with the logger again.

What you can see is that while the Zephyr kernel advances 1 tick (10ms) of simulated time (the only time the Zephyr kernel knows about), much less real time passes.
That is just due to running native_posix in non-real time. Please see:
https://docs.zephyrproject.org/latest/boards/posix/native_posix/doc/index.html#about-time-in-native-posix
The logger timestamp (between []) is the Zephyr time. And we can see that advances in jumps of 10ms between the logger calls (I presume you have the default 10ms system tick resolution).
If this answers your question, feel free to close the issue

Thanks for the quick response.  You have characterized this issue correctly in terms of the implementation.  Note that I am running this application with CONFIG_NATIVE_POSIX_SLOWDOWN_TO_REAL_TIME=n, so presumably Native-POSIX is running as quickly as possible.  The is broadly is that entry into zsock_select specifies a timeout value of close to 10 ms (my epoch interval), but zsock_select(), which should pend for that duration since none of the file handles would trigger an exit, returns very quickly pending for one a few hundred microseconds.
Consider the following log entry, here the timeout is set to 9562 microseconds, but zsock_select() appears to return while waiting only 239 microseconds.
I do not fully understand the correlation between the logging timestamp and the time values returned from the POSIX clock_gettime() API when running without slowdown
[00:34:42.870,000]  app.exec: select() IN [epoch 18]: now (21192/180438), timeout (0/9562), m_tvNextEpoch (21192/190000)
[00:34:42.890,000]  app.exec: select() OUT[epoch 18]: now (21192/180677), timeout (0/9562), tvNextEpoch (21192/190000), elapsed (0/239),

I do not fully understand the correlation between the logging timestamp and the time values returned from the POSIX clock_gettime() API when running without slowdown

They are not correlated :). The logging timestamp is in simulated time. The call to the host clock_gettime() is real/host/wall time. It takes very little real time to advance those 10ms of simulated time.

OK, note that the elapsed time measured is the wall clock time at entry and exit to zsock_select().

Aside for the timestamp correlation (or lack thereof), the primary point was that zsock_select() does not pend for the duration specified (as a timeval) as measured using wall clock time.  Maybe there is an explanation for that behavior?

Aside for the timestamp correlation (or lack thereof), the primary point was that zsock_select() does not pend for the duration specified (as a timeval) as measured using wall clock time. Maybe there is an explanation for that behavior?

That  zsock_select() will wait for the timeval duration in simulated time. Nothing in Zephyr cares about wall/host/real time when CONFIG_NATIVE_POSIX_SLOWDOWN_TO_REAL_TIME=n

Would it be at all easy to modify the Zephyr source code so that the logging uses wall clock time when CONFIG_NATIVE_POSIX_SLOWDOWN_TO_REAL_TIME is set to 'n'?

Would it be at all easy to modify the Zephyr source code so that the logging uses wall clock time when CONFIG_NATIVE_POSIX_SLOWDOWN_TO_REAL_TIME is set to 'n'?

That would not be a good idea. The basic principle is that when you run decoupled from the host time, nothing in Zephyr or your app is aware of the host time.
The only reason why you are aware in your test of the host time is because you are calling out into the underlaying Linux kernel.

Closing as this question would seem to be answered now. If that is not the case, please reopen the issue.


[canvaskit] Use ImageFilter.filterBounds to adjust ImageFilter paintbounds

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Use case
The CanvasKit backend in Flutter Web calculates rough paint bounds when rendering. However, for ImageFilters the paint bounds are inaccurate because they do not reflect how the image filter changes the bounds of the content it filters.
Proposal
Use ImageFilter.filterBounds (or equivalent API) when it is made available in CanvasKit (potential PR https://skia-review.googlesource.com/c/skia/+/721299)

Potentially addressed here? https://github.com/flutter/engine/pull/43353


Migrate to Gradle's Plugin DSL

Describe the bug
Flutter has deprecated imperative apply script method to apply Gradle plugins: Deprecated imperative apply of Flutter's Gradle plugins
flutter run issues the following warning:
You are applying Flutter's app_plugin_loader Gradle plugin imperatively using the apply script method, which is deprecated and will be removed in a future release. Migrate to applying Gradle plugins with the declarative plugins block: https://flutter.dev/to/flutter-gradle-plugin-apply

You are applying Flutter's main Gradle plugin imperatively using the apply script method, which is deprecated and will be removed in a future release. Migrate to applying Gradle plugins with the declarative plugins block: https://flutter.dev/to/flutter-gradle-plugin-apply

Solution:
Migrate to Gradle plugins with the declarative plugins block.
Steps to reproduce

From the root of the project, execute - flutter run

Expected behavior
The warning message should not be displayed.
Screenshots

Smartphones
No response
Were you using an atApplication when the bug was found?
No response
Additional context
No response

@JeremyTubongbanua @TylerTrott @XavierChanth
I would love to take this up but I noticed #271 and #270 involve edits to the same files I plan to modify (though the region of intersection isn't huge)
We could either:

Review and merge the said PRs before we begin work on this one. Would save some trouble from rebasing later.
Add these edits to the same PR, perhaps by the same author. But could lead to bleeding of separate concerns and the PR already looks big to review.


Add dark mode toggle and store in local storage

Makes the experience a bit more obvious and testing a bit easier

There's a flaky test. Disregard!


Celo: Serialization changes

Description
Copies celo's serialization changes from #127
The key change is it adds serialize_uncompressed_unchecked.
Currently the implication of serialize_unchecked is to serialize in the uncompressed form, so this PR makes sense in the context of needing to serialize unchecked, compressed data.
The usecase for that is not clear to me, as the check needed for deserializing an affine curve point on a prime order curve is effectively the same as getting the affine representation of the point. (We currently don't implement arithmetic in montgomery form AFAIK)
Is the usecase for skipping subgroup checks for compressed curve points?
@jon-chuang, @Pratyush, is the above correct for where serializing unchecked compressed comes in handy?
I'll handle fixing the merge conflicts, and copying over the changes to make elliptic curves implement this if we agree on the need for the change.
We also have the question of whether the default should be for serialize_unchecked to be compressed or uncompressed. The current form of this PR is a breaking change that will fail silently in many places, by changing the implementation of serialize_unchecked.
Not sure what the best API to be using here right now is.

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[x] Targeted PR against correct branch (main)
[ ] Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
[ ] Wrote unit tests
[ ] Updated relevant documentation in the code
[ ] Added a relevant changelog entry to the Pending section in CHANGELOG.md
[ ] Re-reviewed Files changed in the Github PR explorer

Is the usecase for skipping subgroup checks for compressed curve points?

Yes, this is the intended usecase, I believe. I’m not sure what the overhead of decompression vs subgroup checks is for common curves

@jon-chuang Could you elaborate further on the applications/potential use cases for this? Isn't taking the square root pretty expensive?

Hi, yes, the use case is indeed to skip the subgroup check. We can use a batched subgroup check instead which is about 30-75x faster, iirc.

It would be nice to specialise the impl for vec or [T] where T: AffineCurve etc. to perform the batch subgroup check. Perhaps a change for the future.

Hmm since it's useful, I propose renaming (de)serialize_unchecked to (de)serialize_compressed_unchecked. I am not undecided on whether we should also rename serialize to serialize_compressed in the process. WDYT @ValarDragon @jon-chuang @kobigurk?

Upon further thought, I personally dont like the idea of having checked and unchecked in the API, and am more in favour of one of the two solutions:

Remove such checks entirely, then the responsibility/manner of checking falls on the programmer
create a trait for each type representing the batch version of checking functions, with a default impl doing nothing, and impl for curves doing a batch check

Remove such checks entirely, then the responsibility/manner of checking falls on the programmer

I feel like this is probably going to lead to protocol problems elsewhere, and furthermore breaks the contracts of the curve types (which assume that the input is in the prime order subgroup)

We could try playing around with adding a default parameter to the serialize and serialize_uncompressed methods, so that by default it performs the checks, but if you change the default type parameter to a different one (which avoids the checks), then it does not perform on-curve checks.

Hmm yeah, I guess the solution proposed is meant to allow for minimal breakage.
I guess compression and data integrity checks do form a reasonable quadrant on the type of (de)serialisation one would like generically speaking.
Would you mind giving an example of the type parameter method?

we could separate the unchecked serialization methods into its own trait, that is auto-implemented if canonical serialize is implemented

If something is unchecked, the API should definitely make it clear imo

Im in favor of the approach of having 4 methods
* serialize_compressed
* serialize_uncompressed
* serialize_compressed_unchecked
* serialize_uncompressed_unchecked

Hmm since it's useful, I propose renaming (de)serialize_unchecked to (de)serialize_compressed_unchecked. I am undecided on whether we should also rename serialize to serialize_compressed in the process. WDYT @ValarDragon @jon-chuang @kobigurk?

Wrt to this question specifically, are you proposing to have e.g. deserialize_compressed_.. alongside deserialize_uncompressed..? Shouldn't one be a default, so e.g. we retain just deserialize?

Im in favor of the approach of having 4 methods
* serialize_compressed
* serialize_uncompressed
* serialize_compressed_unchecked
* serialize_uncompressed_unchecked

I think its fine to expose the four options here, and let downstream applications decide which method they want, and which methods they want to expose.

Hmm, well barring curves, most types do not have an option to compress, so shouldn't we have a default that leads to minimal breakage?

Here's some example code, that allows incorporating the batch checks as well:
trait CanonicalDeserialize {
	Specifies how the check should be performed
	type Validator: Checker<Self>;

	fn deserialize<R: Read, C: ShouldCheck = AlwaysCheck>(reader: R) -> Self {
		// get item from R
		if C::should_check() {
			assert!(Self::Validator::check(&[item]));
		}
		item
	}

	fn deserialize_uncompressed<R: Read, C: ShouldCheck = AlwaysCheck>(reader: R) -> Self {
		// get uncompressed item from R
		if C::should_check() {
			assert!(Self::Validator::check(&[item]));
		}
		item
	}
}

/// Actually performs the check
trait Checker<T> {
	fn check(&[T]) -> bool;
}

trait ShouldCheck {
	fn should_check() -> bool;
}

struct AlwaysCheck;

impl ShouldCheck for AlwaysCheck {
	fn should_check() -> bool {
		true
	}
}

struct NoCheck;

impl ShouldCheck for NoCheck {
	fn never_check() -> bool {
		false
	}
}

Here's how you would use it to do both checked and unchecked serialization:
let item = T::deserialize(&mut reader)?;
let item = T::deserialize::<_, NoCheck>(&mut reader)?;

and here's how you would use the Checker API to implement batch checking without specialization

impl<T: CanonicalDeserialize> CanonicalDeserialize for Vec<T> {
	type Validator = VecChecker<T>;

	fn deserialize<R: Read, C: ShouldCheck = AlwaysCheck>(reader: R) -> Self {
		// get item from R
		if C::should_check() {
			assert!(T::Validator::check(&[item]));
		}
		item
	}
}

struct VecChecker<T>(PhantomData<T>);
impl<T: CanonicalDeserialize> Checker<Vec<T>> for VecChecker<T> {
	fn check(items:&[Vec<T>]) -> bool {
		for item in items {
			T::check(item.as_slice())
		}
	}
}

The idea would be to have different implementations of checkers for different types.

Note that the changes relating to the Validator associated type are completely orthogonal to the changes related to the ShouldCheck trait; we could adopt either one.

Here's some example code, that allows incorporating the batch checks as well:
trait CanonicalDeserialize {
	Specifies how the check should be performed
	type Validator: Checker<Self>;

	fn deserialize<R: Read, C: ShouldCheck = AlwaysCheck>(reader: R) -> Self {
		// get item from R
		if C::should_check() {
			assert!(Self::Validator::check(&[item]));
		}
		item
	}

	fn deserialize_uncompressed<R: Read, C: ShouldCheck = AlwaysCheck>(reader: R) -> Self {
		// get uncompressed item from R
		if C::should_check() {
			assert!(Self::Validator::check(&[item]));
		}
		item
	}
}

/// Actually performs the check
trait Checker<T> {
	fn check(&[T]) -> bool;
}

trait ShouldCheck {
	fn should_check() -> bool;
}

struct AlwaysCheck;

impl ShouldCheck for AlwaysCheck {
	fn should_check() -> bool {
		true
	}
}

struct NoCheck;

impl ShouldCheck for NoCheck {
	fn never_check() -> bool {
		false
	}
}

Here's how you would use it to do both checked and unchecked serialization:
let item = T::deserialize(&mut reader)?;
let item = T::deserialize::<_, NoCheck>(&mut reader)?;

and here's how you would use the Checker API to implement batch checking without specialization
impl<T: CanonicalDeserialize> CanonicalDeserialize for Vec<T> {
	type Validator = VecChecker<T>;

	fn deserialize<R: Read, C: ShouldCheck = AlwaysCheck>(reader: R) -> Self {
		// get item from R
		if C::should_check() {
			assert!(T::Validator::check(&[item]));
		}
		item
	}
}

struct VecChecker<T>(PhantomData<T>);
impl<T: CanonicalDeserialize> Checker<Vec<T>> for VecChecker<T> {
	fn check(items:&[Vec<T>]) -> bool {
		for item in items {
			T::check(item.as_slice())
		}
	}
}

The idea would be to have different implementations of checkers for different types.

I like this strategy as it exposes optional fine grained control with fewer breaking changes and more separation of duties.

Instead of the above approach to Vec, I propose instead to have
trait Checker<T> {
    fn check(value: T) -> Result;
    fn check_batch(values: &[T]) -> Result {
        for value in values {
            Self::check(value)?;
        }
        Ok(())
    }
}

So we have a default batch impl, which can be overriden for types.

Hi, @Pratyush @ValarDragon, could I get permission to push to non-protected branches?

Btw, where is serialize_derive actually used? I can't seem to find it used anywhere. For instance, derive_canonical_deserialize isn't.

The serialize-derive repo is often used in a project by adding a dependency on serialize with the feature derive.
https://github.com/arkworks-rs/algebra/blob/master/serialize/src/lib.rs#L19
This allows the Rust to derive the canonical serialization and deserialization.
e.g., https://github.com/arkworks-rs/poly-commit/blob/master/src/data_structures.rs#L107

By the way, thanks a lot for the serialization system by Celo. It has helped one of my projects significantly!

Hi @weikengchen thanks, I guess it's not used in algebra itself, with arrays and simple structs. I see that it's necessary for cases where there are nested structs.
That's great, but according to the above, though, the API seems like it's about to change again.

@Pratyush unfortunately it seems that your strategy doesn't work, becuase:
defaults for type parameters are only allowed in struct, enum, type, or trait definitions.
So I'm still looking for a nice workaround to specify default behaviour without introducing breaking changes and/or clutter.

@weikengchen actually with regards to your example https://github.com/arkworks-rs/poly-commit/blob/master/src/data_structures.rs#L107, it does seem one can get rid of the ugly code bloat by implementing canonical (de)serialize for the String type.

Yes. I will take a look!

Things I am currently unsure about: how to impl derive to incorporate (de)serialize_uncompressed_unchecked.

Is the problem due to whether it should default to (de)serialize_uncompressed or (de)serialize_unchecked?

btw Jon, an alternative to prevent downstream users from having to implement all methods manually would be to have a "Mode", as outlined in https://github.com/arkworks-rs/algebra/issues/145
The idea is to have a mode enum:
enum Compress {
	Yes,
	No,
}
enum Validate {
	Yes,
	No
}

And this enum is passed into a single method
trait Serialize {
	fn serialize_with_mode<R: Read>(self, reader: R, compression: Compression, validation: Validation) -> ioResult;

	fn serialize_compressed(...) {
		self.serialize_with_mode(reader, Compress::Yes, Validate::Yes)
	}

	fn serialize_compressed_unchecked(...) {
		self.serialize_with_mode(reader, Compress::Yes, Validate::No)
	}

	fn serialize_uncompressed(...) {
		self.serialize_with_mode(reader, Compress::No, Validate::Yes)
	}

	fn serialize_uncompressed_unchecked(...) {
		self.serialize_with_mode(reader, Compress::No, Validate::No)
	}
}

So users only have to implement the single method, and everything else is implemented by default?
This should also make writing the Derive macro implementation easier.

Incorporating the ideas above, let me propose the following design:
pub enum Compress {
	Yes,
	No,
}
pub enum Validate {
	Yes,
	No,
}

pub trait Valid {
	fn check(&self) -> Result<(), SerializationError>;
	fn batch_check(batch: &[self]) -> Result<(), SerializationError> {
		for item in batch {
			item.check()?;
		}
		Ok(())
	}
}

pub trait CanonicalSerialize {
	fn deserialize_with_mode<W: Write>(writer: W, compress: Compress) -> Result<(), SerializationError> {
		// write item to W, handling compression as per `compress`
	}

	fn serialize_compressed(...) {
		self.serialize_with_mode(reader, Compress::Yes)
	}

	fn serialize_uncompressed(...) {
		self.serialize_with_mode(reader, Compress::No)
	}
}

pub trait CanonicalDeserialize: Valid {
	fn deserialize_with_mode<R: Read>(reader: R, compress: Compress, validate: Validate) -> Self {
		// get item from R, handling compression as per `compress`
		if let Validate::Yes = validate {
			Self::check(&item)?
		}
		item
	}

	fn serialize_compressed(...) {
		self.serialize_with_mode(reader, Compress::Yes, Validate::Yes)
	}

	fn serialize_compressed_unchecked(...) {
		self.serialize_with_mode(reader, Compress::Yes, Validate::No)
	}

	fn serialize_uncompressed(...) {
		self.serialize_with_mode(reader, Compress::No, Validate::Yes)
	}

	fn serialize_uncompressed_unchecked(...) {
		self.serialize_with_mode(reader, Compress::No, Validate::No)
	}
}

impl<T: Valid> CanonicalDeserialize for Vec<T> {
	fn deserialize_with_mode<R: Read>(reader: R, compress: Compress, validate: Validate) -> Self {
		// get items: Vec<T> from R, handling compression as per `compress`
		if let Validate::Yes = validate {
			T::batch_check(&items)?
		}
		items
	}
}


SONOFF smart bulb B05

I can see the light bulb status in my HA, but i can't control it. Whenever i try to change color e.x. it Goes back to actual value

Duplicate #297


Update readme to not recommend Google Domains

Google domains is being sold to Squarespace and wont exist as it does today.
I made an edit to suggest Cloudflare, but happy to update to anything else that the maintainers think is a good alternative.

@roopakv I would also support this decision as a user of self hosted beeper. - J


Change main field to explicitly pint to file

Please change main in package.json to ./lib/index like in fs-extra library. JSPM does not seem to like an implicit reference even though there is nothing wrong with it.

Hi @CxRes.
Have made this change in v0.2.1, just published on npm.
But can you please raise this as an issue with JSPM? Many other modules may have the same problem (including all the ones I've written).

@overlookmotel - thanks for the update. I made a ticket with Systemjs systemjs/systemjs#760, which turns out to be tracked in another repo jspm/npm#91. Hopefully, it will be resolved soon.

@CxRes OK great. Would you mind letting me know when it's been resolved, so I can safely change it back to ./lib/?

I'll try my best to remember to remind you :). I wonder if there is a reason to prefer ./lib/

Thanks @CxRes. No particular reason to prefer ./lib/ I suppose - just that's how I've written all my modules so I'd like to keep it standardized. I ./lib/ seems neater to me. We all have our little fetishes I guess...


Reading the resolution matrices after continuum fitting

Reading the resolution matrix is a very time consuming IO operation. We should try some optimizations. Currently we are reading them in the beginning, but do not use them later in any operation except to save them in files. We can read them before coadding the valid spectra only in the forest region. This would limit reading to forest-only arms and forest-only wavelengths.

This has been implemented in #50 , but currently is disabled. Initial testing didn't show a significant speed up, but could be tested later.


Adds video upload

This squashes the changes in #929 down to a single commit, incorporating comments from @Harmon758.
Some of this work is due @jamesandres and @Choko256.
This is currently in draft because I have poor internet for the next week and testing video upload isn't feasible. We've waited five years, so another week should be fine. 😄

I think it would be preferable to keep the original commits if possible, to keep credit where it's due.

How about I squash them all into a single commit with multiple authors?

Is there a reason it needs to be a single commit?

Yes. The main branch has changed so much since this was introduced that rebasing each commit is tiresome.

Wouldn't it be possible to use the original commits already in your video-upload2 branch and make a merge commit that merges the main branch and resolves any conflicts? I think if you really wanted to, you could even just copy all the code as it is in this commit and paste it as part of the merge commit. Although, it'd be preferable for the additional changes in this commit to be separate from changes for conflict resolution as well. Another reason for this is that it'd be easier to specifically review the changes you made in addition to what's already in #929 and the additional commits you have in video-upload2 than to re-review the entire thing.

Thank you @Harmon758  and @Maradonna90 for your help reviewing. I've incorporated your suggested changes.
In particular:

new global constants are used for tracking the MIN, MAX and DEFAULT chunk sizes. All of these constants are stored in KiB, and multiplied by 1024 when comparing to bytes.
Enhancement: the api.media_upload method will use chunked upload for images that exceed the standard upload size limit
Repeated logic around checking file types has been removed/simplified
I added two test files (gif and mp4) and three methods (and casettes) around the media upload endpoint.

I am eager for the video upload feature, and respectfully ask that it be added to tweepy as soon as possible. Thank you all for your work on this project.

If I upload a bigger video and try to post a tweet with it I can get a 324 errorcode with not valid video. This happends because the upload hasn't finished yet.
I checked the twitter API and found a method that checks for the upload progress of media. I wrote a small function in my project to use it.
def get_media_upload_status(api, *args, **kwargs):
    """ :reference: https://developer.twitter.com/en/docs/twitter-api/v1/media/upload-media/api-reference/get-media-upload-status
            :allowed_param:
        """

    return bind_api(
            api=api,
            path='/media/upload.json',
            payload_type='media',
            allowed_param=['command', 'media_id'],
            upload_api=True,
            require_auth=True
    )(*args, **kwargs)

potentially the media_upload method should return the media_id when the media_upload finished. The above funciton could be used within a routine.

I'm new to using github. How do I use this video upload version as my tweepy for python? What's the pip command for this specific version to install it? Sorry I'm a newbie

I'm new to using github. How do I use this video upload version as my tweepy for python? What's the pip command for this specific version to install it? Sorry I'm a newbie

I'm also a newbie, but this is what I just did to get it installed:
git clone https://github.com/fitnr/tweepy.git
cd tweepy/
git checkout video-upload-3
pip3 uninstall tweepy (if you have an old version installed. We're going to replace it)
python3 setup.py build
sudo python3 setup.py install

I'm gotten it installed, and have successfully to use it to post the included example video.mp4. When I try to post one of my videos, it is successfully assigned a media_ID, but then with the api.update_status command, I get tweepy.error.TweepError: [{'code': 324, 'message': 'Not valid video'}]
This same video works fine if I upload it by hand in the Twitter web interface. It's a little 17KB MP4, definitely not too big.
I don't know if this is a bug tweepy code or if twitter is just being weird about my MP4s.

I'm gotten it installed, and have successfully to use it to post the included example video.mp4. When I try to post one of my videos, it is successfully assigned a media_ID, but then with the api.update_status command, I get tweepy.error.TweepError: [{'code': 324, 'message': 'Not valid video'}]
This same video works fine if I upload it by hand in the Twitter web interface. It's a little 17KB MP4, definitely not too big.
I don't know if this is a bug tweepy code or if twitter is just being weird about my MP4s.

I'm gotten it installed, and have successfully to use it to post the included example video.mp4. When I try to post one of my videos, it is successfully assigned a media_ID, but then with the api.update_status command, I get tweepy.error.TweepError: [{'code': 324, 'message': 'Not valid video'}]
This same video works fine if I upload it by hand in the Twitter web interface. It's a little 17KB MP4, definitely not too big.
I don't know if this is a bug tweepy code or if twitter is just being weird about my MP4s.

have you tried it with time.sleep(10) between the media_upload call and the api.update_status ?

have you tried it with time.sleep(10) between the media_upload call and the api.update_status ?

Thanks for the suggestion. I've tried this now. Same thing.

I found the solution to my Not Valid Video problem. Seems twitter is very fussy about the video codec.
The ffmpeg command shown here converted my video to a format twitter is happy with
https://gist.github.com/nikhan/26ddd9c4e99bbf209dd7#gistcomment-3232972
and tweepy uploaded it with no complaint!
-K

I've added a commit with @Maradonna90's get_media_upload_status, it's much more efficient than time.sleep(10)

@Harmon758 @Maradonna90 bump

I've gone ahead and made a branch, https://github.com/tweepy/tweepy/tree/video-upload, and merged this into it.
I've also drafted PR #1486 merging it into the master branch.
I'll be making further improvements in that branch and PR, but as I said before, feel free to PR to that branch if anyone else wants to make additional improvements as well.
@vegit0 @savetz See https://tweepy.readthedocs.io/en/latest/install.html and https://pip.pypa.io/en/stable/reference/pip_install/#git.

The [{'code': 324, 'message': 'Not valid video'}] error keeps happening
Shouldn't media_upload wait for it before returning?

The [{'code': 324, 'message': 'Not valid video'}] error keeps happening
Shouldn't media_upload wait for it before returning?

Are you using the video-upload branch / PR #1486? This PR has been superseded by that one.
Regardless, videos need to meet certain specifications for Twitter's API.

Shouldn't media_upload wait for it before returning?

Wait for what?

Are you using the video-upload branch / PR #1486? This PR has been superseded by that one.
Regardless, videos need to meet certain specifications for Twitter's API.

Shouldn't media_upload wait for it before returning?

Wait for what?

I'm using the "video-upload" branch.
Ok let me explain.
When I'm calling
 uploaded_media = api.media_upload(output_filename, media_category='TWEET_VIDEO')

I expect the function to return when the state of the upload is no longer "pending".
Instead I think it's returning right after the "finalize" call. However, after calling finalize you still have to wait until Twitter has ended processing the video, as explained in the docs:

it may also be necessary to use a STATUS command and wait for it to return success before proceeding to Tweet creation.

I feel that the same way the API is handling all the process from start to finalize, it should also wait for STATUS not to be "pending" instead of having to handle that outside this library.
I have currently fixed it on my own code using a while loop and waiting for the proper state like this:
uploaded_media = api.media_upload(output_filename, media_category='TWEET_VIDEO')
while (uploaded_media.processing_info['state'] == 'pending'):
   time.sleep(uploaded_media.processing_info['check_after_secs'])
   uploaded_media = api.get_media_upload_status(uploaded_media.media_id_string)
api.update_status('@' + tweet.author.screen_name + ' ', in_reply_to_status_id=tweet.id_str, media_ids=[uploaded_media.media_id_string])

I hope it's clear now.
Thanks

I'm using the "video-upload" branch.
Ok let me explain.
When I'm calling
 uploaded_media = api.media_upload(output_filename, media_category='TWEET_VIDEO')

I expect the function to return when the state of the upload is no longer "pending".
Instead I think it's returning right after the "finalize" call. However, after calling finalize you still have to wait until Twitter has ended processing the video, as explained in the docs:

it may also be necessary to use a STATUS command and wait for it to return success before proceeding to Tweet creation.

I feel that the same way the API is handling all the process from start to finalize, it should also wait for STATUS not to be "pending" instead of having to handle that outside this library.
I have currently fixed it on my own code using a while loop and waiting for the proper state like this:
uploaded_media = api.media_upload(output_filename, media_category='TWEET_VIDEO')
while (uploaded_media.processing_info['state'] == 'pending'):
   time.sleep(uploaded_media.processing_info['check_after_secs'])
   uploaded_media = api.get_media_upload_status(uploaded_media.media_id_string)
api.update_status('@' + tweet.author.screen_name + ' ', in_reply_to_status_id=tweet.id_str, media_ids=[uploaded_media.media_id_string])

I hope it's clear now.
Thanks

Ah, I see. Thanks for the feedback.
I think I'll probably add a kwarg to allow waiting for the async finalize process to finish.
I'll look into it later and let you know in #1486.

Ah, I see. Thanks for the feedback.
I think I'll probably add a kwarg to allow waiting for the async finalize process to finish.
I'll look into it later and let you know in #1486.

The video-upload branch / pull request #1486 should be complete now.
Any feedback or review would be appreciated.


Fix Markdown links in SUPPORT.md

Add link to CONTRIBUTING.md and fix (presumably broken?) link to Github issues in SUPPORT.md
CLA: trivial
Checklist

[x] documentation is added or updated

Merged to master and 3.0, thanks for the fix.


Disable autoregister

Cool panels!
Would be nice if you could use those separately without the automatic registration in the index.php file.
IMHO clean way would be separation of the panels to the separate composer package, and then have package for the WordPress plugin with this autoregistration only requiring the panels package.

OK, good point, I'll think about it ... :) But for now I leave it open ...


Analysis generation

Related PR:
https://github.com/WorldBank-Transport/rra-datapipeline/pull/4
https://github.com/WorldBank-Transport/rra-frontend/pull/54

Store the admin areas available for a scenario in the database
Add option to mark some of those admin areas as selected for result generation
Add endpoint to trigger result generation (POST /projects/{projId}/scenarios/{scId}/generate)

Tested with the PR branches of all three components + npm run setup -- --data.
Hitting Generate for Sergipe results in a 500 error:
170330/034020.404, [response] http://<IP_ADDRESS>:4000: get /projects/2000/scenarios/2000 {} 200 (26ms)
170330/034038.486, [response] http://<IP_ADDRESS>:4000: options /projects/2000/scenarios/2000 {} 200 (33ms)
170330/034038.525, [response] http://<IP_ADDRESS>:4000: patch /projects/2000/scenarios/2000 {} 200 (42ms)
err Error: Operation does not exist
    at /home/olaf/projects/Rural-Road-Accessibility/app/utils/operation.js:62:48
    at bound (domain.js:280:14)
    at runBound (domain.js:293:12)
    at tryCatcher (/home/olaf/projects/Rural-Road-Accessibility/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/home/olaf/projects/Rural-Road-Accessibility/node_modules/bluebird/js/release/promise.js:510:31)
    at Promise._settlePromise (/home/olaf/projects/Rural-Road-Accessibility/node_modules/bluebird/js/release/promise.js:567:18)
    at Promise._settlePromise0 (/home/olaf/projects/Rural-Road-Accessibility/node_modules/bluebird/js/release/promise.js:612:10)
    at Promise._settlePromises (/home/olaf/projects/Rural-Road-Accessibility/node_modules/bluebird/js/release/promise.js:691:18)
    at Async._drainQueue (/home/olaf/projects/Rural-Road-Accessibility/node_modules/bluebird/js/release/async.js:133:16)
    at Async._drainQueues (/home/olaf/projects/Rural-Road-Accessibility/node_modules/bluebird/js/release/async.js:143:10)
    at Immediate.Async.drainQueues (/home/olaf/projects/Rural-Road-Accessibility/node_modules/bluebird/js/release/async.js:17:14)
    at runCallback (timers.js:651:20)
    at tryOnImmediate (timers.js:624:5)
    at processImmediate [as _immediateCallback] (timers.js:596:5)
170330/034040.964, [response] http://<IP_ADDRESS>:4000: post /projects/2000/scenarios/2000/generate {} 500 (23ms)

This looks great. Merging.


random unresponsive minimize / maximize / close buttons for running game (F5)

Godot version
3.4.4
System information
windows 10
Issue description
When play testing using F5 or F6 - no errors showing up in console : minimize / maximize / close buttons are unresponsive (seems completely random).
Steps to reproduce
seems random, so, no steps to reproduce
Minimal reproduction project
No response

Happens to me too sometimes, but to the godot editor window, also on windows 10. Some clicks on the taskbar (focus/unfocus) usually fix it.

It seems like the editor is randomly getting focus while I'm testing the game.
For instance, when I'm using the wasd keys to move, I am sometimes actually typing inside the script.


Outdated screenshots

Documentation task: https://mattermost.atlassian.net/browse/MM-31595
Updated:

User's Guide > Getting Started > Welcome to Mattermost

Updated all screenshots included on the page

Thanks @cwarnermm!


✅ GCP Spin-Up Instances Tool

Description

Manual at first
Different hardware per validator/client/prover?
Preferably spot instances
How to download/load binaries and custom areas

Connected To:

[x] #56

done via external automation


Toggle Ftrack upload in StandalonePublisher

2.x version: https://github.com/pypeclub/OpenPype/pull/1706
Closes pypeclub/client#86
Removed default_family in collect_context
Moved existing setting for Maya to defaults profile

See additional discussion about advanced filtering https://github.com/pypeclub/OpenPype/pull/1708

Adding screenshot for possible further discussion here:

@jezscha can you publish editorial from standalone publisher with this branch? With different cases with/without review and check if published data in ftrack match expected data?


Fix clang linkflags on macos build

Fixes #36720 as PR was reverted (#36795)
This should work when cross-compiling from Linux (haven't tested)
I was having the same issue on my mac with clang build working on my godot fork (4.2 branch)
clang: error: no such file or directory: 'Carbon'
clang: error: no such file or directory: 'AudioUnit'
clang: error: no such file or directory: 'CoreAudio'
clang: error: no such file or directory: 'CoreMIDI'
clang: error: no such file or directory: 'IOKit'
clang: error: no such file or directory: 'ForceFeedback'
clang: error: no such file or directory: 'CoreVideo'
clang: error: no such file or directory: 'AVFoundation'
clang: error: no such file or directory: 'CoreMedia'
clang: error: no such file or directory: 'QuartzCore'
clang: error: no such file or directory: 'Security'
clang: error: no such file or directory<EMAIL_ADDRESS>clang: error: no such file or directory: 'Metal'
scons dev_build=yes use_llvm=yes linker=lld verbose=yes gives:
clang++ -obin/godot.macos.editor.dev.arm64 -ld_classic -Xlinker -no_deduplicate -arch arm64 -mmacosx-version-min=11.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.5.sdk Cocoa Carbon AudioUnit CoreAudio CoreMIDI IOKit ForceFeedback CoreVideo AVFoundation CoreMedia QuartzCore Security @executable_path/../Frameworks -rpath @executable_path Metal -framework IOSurface -lMoltenVK -L/Users/nordup/VulkanSDK/1.3.280.1/macOS/lib/MoltenVK.xcframework/macos-arm64_x86_64/ -pthread ... -lz -lzmq -lstdc++ -lsodium -lpthread
You can see that "-framework" and "-path" flags are not passed

Tested on
System Version: macOS 14.5 (23F79)
SCons by Steven Knight et al.:
SCons: v<IP_ADDRESS>5be6883fadbb5a545612265acc919595158366, Sun, 17 Mar 2024 17:33:54 -0700, by bdbaddog on M1Dog2021
SCons path: ['/opt/homebrew/Cellar/scons/4.7.0/libexec/lib/python3.12/site-packages/SCons']
Xcode 15.4
Build version 15F31d
Apple clang version 15.0.0 (clang-15<IP_ADDRESS>)
Target: arm64-apple-darwin23.5.0

-ld_classic in the command also suggest your command line tools area outdated, it should be there only for the buggy Xcode 15.0 and 15.0.1 and not for the later Xcode versions.

-ld_classic in the command also suggest your command line tools area outdated, it should be there only for the buggy Xcode 15.0 and 15.0.1 and not for the later Xcode versions.

Might be worth checking what this outputs, maybe our detection logic is failing:
diff --git a/platform/macos/detect.py b/platform/macos/detect.py
index 70cb00c6ff..1149f4e174 100644
--- a/platform/macos/detect.py
+++ b/platform/macos/detect.py
@@ -97,6 +97,7 @@ def configure(env: "SConsEnvironment"):
         env.Append(LINKFLAGS=["-arch", "x86_64", "-mmacosx-version-min=10.13"])

     cc_version = get_compiler_version(env)
+    print(cc_version)
     cc_version_major = cc_version["apple_major"]
     cc_version_minor = cc_version["apple_minor"]
     vanilla = is_vanilla_clang(env)

maybe our detection logic is failing

Compiler version is 15.0.0 which is true

And it's seems to be the latest clang version shipped with xcode 15.4
Updating and reinstalling didn't help((

Compiler version is 15.0 which is true (clang version 15.0.0)

It's always 15.0.0, but the rest of the version should be different, 1500.0 for Xcode 15/15.0.1 and 1500.1/1500.3 for newer.

For the reference on my system (Xcode 15.4 - 15F31d), it's:
{'major': 15, 'minor': 0, 'patch': 0, 'metadata1': None, 'metadata2': None, 'date': None, 'apple_major': 1500, 'apple_minor': 3, 'apple_patch1': 9, 'apple_patch2': 4, 'apple_patch3': -1}

Relevant variables are apple_major and apple_minor.
Sometimes proper reinstallation require manually deleting contents of /Library/Developer/CommandLineTools/ first.

Might be worth checking what this outputs, maybe our detection logic is failing:

It says:
{'major': 15, 'minor': 0, 'patch': 0, 'metadata1': None, 'metadata2': None, 'date': None}
Apple clang version 15.0.0 (clang-15<IP_ADDRESS>)
But it doesn't builds with -ld_classic flag removed too. So version detection is not cause of a problem.
I guess they haven't fixed that bug still? Should I downgrade my xcode?

Can you check the output of clang++ --version?

clang++ --version
Apple clang version 15.0.0 (clang-15<IP_ADDRESS>)
Target: arm64-apple-darwin23.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

That's weird, that should parse fine. I tested it against the regex in
https://github.com/godotengine/godot/blob/master/methods.py#L835-L847
and it works fine for me:
{'apple_major': '1500', 'apple_minor': '3', 'apple_patch1': '9', 'apple_patch2': '4'}

The issue is, scons is likely using the version installed in /Library/Developer/CommandLineTools/ (not sure what scons detection logic is), and it might be different.
If reinstalling doesn't help, check which Command Line Tool version is selected on Locations tab in the Xcode settings.

It seems to work now, thank you!
I'm so sorry to waste your time((

Seems like it was because linker is passing -lstdc++
I'm statically linking some libs in my module with pkg-config --static
I can fix it locally, but what about this pr? @bruvzg

use_static_cpp=yes doesn't seem to include -lstdc++ in the final linking
But pkg-config does when linking something statically
I can make a minimal reproducible example project if you need)

use_static_cpp is not used on macOS. Apple does not recommend statically linking any parts of C/C++ runtime (not sure if it's still supported at all).
Also, libstdc++ is GCC C++ runtime lib (which is not used on macOS and should not be available), macOS is using libc++ (/usr/lib/libc++.1.dylib).

Hmm, you are right it was deprecated to use libstdc++
I guess I have to link my library dynamically))
Thanks again!


[UG] Add a log: format example

Currently: add e/ r/ c/
Should change to: add e/ r/reps c/[comments]

Update format in UI


Gallery submission feedback

Title should be of the format [company name] [tag name] or [tag name] by [company name]).

Hi Natalie, this name is correct? Abandonment Form Tracking by Perpetual Technologies, should we change the name in github or in the tag template?

We updated the name.

Did you update it in the tag template? I don't see the change there. https://github.com/PerpetualTechnologies/Form-Abandonment-Tracking-Template/blob/61f9c7f8e61a200bb4f51b4030efb6d33e37dca8/template.tpl#L16C1-L17C1


Add multiple event return for QueueStatuses

Get the QueueEntry events for a queue

Thank you for the contribution !


Plex Module Ignore Sections

Plex module Ignore Sections:
How do you add more than one ignore section, or enable wild card entries.
For example:
Private Movies
Private Videos
I can enter Private Movies and it will filter that library, but I cant figure out how to filter both of them.

Add them like: Private Movies, Private Videos


Directory Support for Local Schema Location

Using the Open API to JSON utility script provided, I've pulled down the schemas for all the relevant third party CRDs my org uses in our K8S clusters. The -schema-location option can be used multiple times, but for multiple JSON schema files it becomes a bit unwieldy if YAML files containing mixed resources and CRDs is validated against.
Ideally the -schema-location option would support being pointed to a directory rather than expect a single JSON file per usage where it would pick up any JSON files located therein.
As an example, I have a YAML file which contains an Ingress, Service, SealedSecret (bitnami sealed-secrets), and Receiver (fluxcd). In order to validate this particular file I'd need to do something like kubeconform -summary -verbose -schema-location default -schema-location path/to/sealedsecret.json -schema-location path/to/flux/receiver.json foo.yaml. A simpler approach would be to have a directory locally - call it crds/ containing the respective JSON schemas. Then I could do something like kubeconform -summary -verbose -schema-location default -schema-location path/to/crds foo.yaml and not concern myself with the name of a particular CRD's JSON schema.
As an exercise for giggles, I tried feeding in a large number of CRD JSON files doing something like export SCHEMAS="" ; for FILE in *; do SCHEMAS="$SCHEMAS -schema-location $FILE"; done && kubeconform -summary -verbose -schema-location default $SCHEMAS foo.yaml. The result was "file name too long", so there is a limit to how much you can try to feed to it with multiple/many -schema-location flags.

Hi @shin-go , I believe you are mis-using the -schema-location parameter, you are not the first one, and that really points to poor documentation on my part :( Please check out this answer , that should help you do what you are trying to achieve!

I gave that link a read and it's a different use case from what I (tried) to describe originally. In that particular user's case, they knew ahead of time what CRDs were in the YAML file attempting to validate. In my use case, I intend to integrate kubeconform in a validation CICD pipeline - I have no ability to guess what developers may put into their YAML files.
So unless I implement some pre-validation logic to scan what YAML files have changed and look for things like kind: <something> and apiVersion: <version>, trying to use the suggested -schema-location './{{ .ResourceKind }}_{{ .ResourceAPIVersion }}.json' wouldn't work. Without digging into the codebase, I was presuming that when you use the -schema-location flag, the JSON file(s) passed in were being read to find a match for an encountered resource kind and apiVersion.
Let me know if I'm still misinterpreting the recommendation made on that other issue!

Just to clarify, ResourceKind and ResourceAPIVersion are parameters, not place-holders.
Therefore, you don't need to pass the kind and apiVersion, they will be pulled by Kubecoform.
This is a similar concept to how Kubeconform pulls schemas from this repo.
Maybe this video will help you understand how it is implemented. It shows another tool but under the hood, it's Kubeconform so it will work the same :)

Ahhhhhh yes, that makes sense now. Thanks for your patience! One thing I did notice that the Python script seems to accept, but kubeconform parameters don't is the use of {group} when building the JSON schemas. kubeconform reports the following when trying to use group as {{ .Group }}:
failed initialising schema location registry: template: tpl:1:3: executing "tpl" at <.Group>: can't evaluate field Group in type struct { NormalizedKubernetesVersion string; StrictSuffix string; ResourceKind string; ResourceAPIVersion string; KindSuffix string }

Looking at the registry.go struct, Group doesn't seem to be anticipated unless it's used as like {{ .StrictSuffix }}?
Other than that, this works. Thanks again!

I'm also struggling including locally stored schemas with kubeconform.
So how exactly should the option -schema-location be used?
I'm trying to validate flux CRDs but this doesn't seem to work:
kubeconform -schema-location default  -schema-location '/tmp/flux-crd-schemas/master-standalone-strict/{{ .ResourceKind }}-{{ .KindSuffix }}-{{ .ResourceAPIVersion }}.json' ./clusters/lab/
schema files:
alert-notification-v1beta1.json
bucket-source-v1beta1.json
gitrepository-source-v1beta1.json
helmchart-source-v1beta1.json
helmrelease-helm-v2beta1.json
helmrepository-source-v1beta1.json
imagepolicy-image-v1alpha1.json
imagepolicy-image-v1alpha2.json
imagepolicy-image-v1beta1.json
imagerepository-image-v1alpha1.json
imagerepository-image-v1alpha2.json
imagerepository-image-v1beta1.json
imageupdateautomation-image-v1alpha1.json
imageupdateautomation-image-v1alpha2.json
imageupdateautomation-image-v1beta1.json
kustomization-kustomize-v1beta1.json
kustomization-kustomize-v1beta2.json
provider-notification-v1beta1.json
receiver-notification-v1beta1.json

I'm confused

@chuegel The way I got it working was to use the python script to create the CRD schemas and saving the resulting json file(s) exporting the expected env as export FILENAME_FORMAT='{kind}_{version}'. Your case might be different, but I was originally having the CRD schema format as {group}_{kind}_{version}, which didn't seem to be expected by kubeform using the interpolation notation documented. I don't think using underscore versus dash for delimiting is a factor (but maybe try it for giggles).
Ultimately what I run that works is something like kubeconform -summary -ignore-missing-schemas -schema-location default -schema-location './schemas/{{ .ResourceKind }}_{{ .ResourceAPIVersion }}.json' -kubernetes-version <version> .

@chuegel I got it to work with @shin-go 's trick
I renamed all files using the following shell script
for file in *.json; do
    new_name=$(echo "${file}" | sed 's/-.*-/-/')
    mv $file $new_name
done

and also had to provide the schema for CRDs (from https://github.com/yannh/kubeconform/issues/51#issuecomment-1002639168)
kubeconform -summary -schema-location default -schema-location './schemas/{{ .ResourceKind }}-{{ .ResourceAPIVersion }}.json' -schema-location apis__apiextensions.k8s.io__v1_openapi.json ./kustomize_out

@hazim1093 yes, including -schema-location https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/v3/apis__apiextensions.k8s.io__v1_openapi.jsonworked.
Thank you

Looks like this got solved in the end... If you feel the documentation could be made better on that -schema-location parameter please contribute this is a common pitfall :pray:

@shin-go

The way I got it working was to use the python script to create the CRD schemas and saving the resulting json file(s) exporting the expected env as export FILENAME_FORMAT='{kind}_{version}'. Your case might be different, but I was originally having the CRD schema format as {group}_{kind}_{version}, which didn't seem to be expected by kubeform using the interpolation notation documented. I don't think using underscore versus dash for delimiting is a factor (but maybe try it for giggles).

Can I ask where people are finding the flux openapi schema to run the python script against? I think I understand that the python script is used to create CRD files, which I then pass into kubeconform to consume. But I haven't had any luck locating the Open API source for flux.


Change version to private preview

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[x] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
If updating an existing version, please select the specific langauge SDKs and CLIs that must be refreshed after the swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No refresh required for updates in this PR

Contribution checklist:

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following apply to the PR so that label "WaitForARMFeedback" will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits.

[x] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[x] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

Hi @qiaozha - this is a preview version I just merged last week. We realized that the version needed to be with the "privatepreview" suffix so I have updated the swagger accordingly.
Though this may look like a breaking change, this API is still under development and not in use by any internal or external customers yet.  Thanks.

Hi @qiaozha - can you confirm that with the "privatepreview" suffix, no public docs will be generated? If not, can you advise on how to prevent these docs from being generated?
Thanks...

@qiaozha - friendly ping.


Structured Output Best Practices

Hi! One of the DSPy core tenets is to avoid prompt engineering.
But if you want structured input/output, where is it best to indicate that in a program, aside from the training examples?
Would it be in

Signature classes that specify format?

utterance_mapping = dspy.OutputField(desc="A dictionary mapping speaker to utterance")

validation metric for subtask?

We don't always have the luxury of intermediate labels, so if an intermediate task has to have a particular format, it would be nice to have an official best practices recommendation for this case.

Hi @darinkishore,
Yes, for enhanced control over structured input and outputs, utilizing the full-form signature notation is recommended, allowing you to include a prefix to denote your input/output and a desc as a refined description for the corresponding field (as you have illustrated in your example). Usually, brief descriptions suffice, as the aim is to avoid even "signature engineering" where possible and let DSPy do the work with these concise InputFields and OutputFields.
Let me know if that answers your question!

Yes, signature desc and metrics, and compiling, are the ways to control this now.
Soon we will have built-in types that will make this smoother.

@arnavsinghvi11 Definitely answers! Thank you.
I was wondering if you could shed a little more light on the prefix field, though. How does that work?


[DOCS] add missing comma

Description
In readme.md in the example profile which users can copy, there is a missing comma in the milestone section between description and url
 "milestones": [
    {
      "title": "Started Freelancing",
      "date": "December 2021",
      "icon": "dollar",
      "color": "grey",
      "description": "Started freelancing" // add comma at the end of this line
      "url": "https://www.eddiejaoude.io/"
    }

Screenshots
No response
Additional information
No response

@emmalearnscode I will like to work on this, please

Sure, go ahead @PeroHub


Adopt the RISC-V documentation format

This is a 3-step update for which I will be submitting a PR:

Import of docs-resources project as a submodule.
Updates to the Makefile to use more options on asciidoctor PDF build, including the RISC-V theme (.yml file) and the fonts directory.
Updates to the main .adoc file to include more variables for the build and the logo for the title page

Once complete, the side-effect for anyone starting to use this repo locally will be that they'll need to learn to use Git Submodules. Plenty of useful information is here. But the key step is to issue a git submodule update --init after a new clone or the first pull after this PR.
At key points in the future, we may want to use the git submodule update to update to a new level because Submodules always "link" at a given commit level. (More discussion here as we work with this.)
If anyone has questions about the process, please free to let me know.

FYI, I'm working through a bug in the automated build before I submit the PR.  I figured you might want that too...
Hope to submit before EOW.

Problem resolved and PR submitted yesterday.


If using a location string yahoo returns null.

For anyone using not using geolocation; rather the simple location, for instance  'Austin, TX' will return null results from yahoo and simpleWeather will not error out.  Instead locate WOEID for the location until fix.
http://codepen.io/anon/pen/obybBy

See #174 for info.


Upgrades node dependencies

Upgrades all packages in package.json to their latest versions

Hey @tarunbatra thank you for doing this! Just acknowledging for now. Base is on my backburner while I get the new TMC site wrapped up but I will review this and try to include it in the next release :)


[doc] Lists: Do not decrease font size

There's no typographical reason to decrease the font size as we go down
the hierarchy of ordered/unordered lists. Content on the second
hierarchy level is equally important and should be equally readable as
the normal text. The docs are no PowerPoint presentation.

Before:

After:


PHP 5.6 updates to address MySQL password expiration

I'm currently using Homestead 2 and https://atlas.hashicorp.com/laravel/boxes/homestead/versions/0.3.3 which recently got hit by the homestead user's password expiring in mysql 5.7 per http://stackoverflow.com/q/40493594/134335.
As I worked through what I thought would be just simply implementing PR's #59 and #60, I realized it required much more work due to ppa:ondrej/php5-5.6 being deprecated. I realize now I may have been hit by https://github.com/composer/composer/issues/5814, causing the --cableconnected1 and pecl install -Z adjustments though it shouldn't hurt anything to have them in.
There are a few changes I could've made that I'm a little unsure about:

#66 Use maintained redis-server ppa (73dbbe0)
#76 Postgresql 9.5 (b45b2c2)
#79 NodeJS v6 (5a04d03)
#80 Yarn (60fa317)
Remove ssh2 (2ea3b63)
Remove mailparse (fcdca5f)

I didn't know if this should be as close to 1:1 with master as possible, though I personally err on that side of things.
This also requires a tandem patch to Homestead v2 as php5-fpm changes to php5.6-fpm, /var/run/php5-fpm.sock changes to /var/run/php/php5.6-fpm.sock, and /etc/php5/fpm/php-fpm.conf changes to /etc/php/5.6/fpm/php-fpm.conf.
I followed the notes from #59 as closely as possible. I tested for the expiration and it is no longer a problem. I made sure I could produce at least 2 builds in a row before calling it done but ultimately produced about 4-5 without failure . I tested a few separate Laravel projects and saw no noticeable awkwardness but these are very rudimentary projects with no redis usage nor would I know what to look for if some of the php extensions are somehow broken. The gist of my latest build is https://gist.github.com/w0rd-driven/f1cfb4b9577ffd391462ba7cbf4c0c8e.
Lastly, I made one improvement that could make it back into master. I moved the xdebug cli disable above pulling in laravel envoy and installer as the provisioning could also benefit from it.

I don't really have any plans of maintaining a 5.6 branch of Homestead any longer. You are free to fork this and provide one if you want.

I expected as much, primarily due to all the work involved. My only concern is 0.3.3 is "broken" depending on your definition of the word but I'll put the more permanent solution in the SO post. I don't know if I personally have the time to maintain an alternative until support ends in 2018 tbh but given where I am it wouldn't hurt to push the box this creates and go the few steps further at least.
How feasible would it be to pull 0.3.3 down, make the change in PR #60, and push that up as 0.3.4? That's the quickest resolution compared to all of this and what I would've done if I thought I could push it to laravel/homestead instead of whatever my fork would be.


Feature: Limit user pannning to a certain max extent

In case the dataset covers a limited area you might want limit the users pan/zoom to that area.
One possible solution is to limit the entire mapview to this max extent. A problem with this approach is that if you pan to the edge and the zoom out one level (straight up), part of the visible map extent will be outside of the max extent. You could counter this displacing the map extent so that it is within the max extent but this is probably not a great user experience.
An alternatieve is to limit just the center of the map to stay within the max extent. When zooming straight the center of the map extent will still be within the max extent. But part of the map will be visible outside the max extent. How to deal with that:

Just leave it as the background color and accept it
Use an alternative data layer for context
Include the area that fallls outside the max extent but within the visible extent in the prepared dataset. What makes this more complicated is that this area is different for each zoom level. The more zoomed out the larger the area.

Here is different solution implemented in leaflet:
https://www.mapbox.com/mapbox.js/example/v1.0.0/maxbounds/

zooming out is limited to a certain level
A large area outside the target area is visible. This might not suit our scenario. It's an option.
panning is not made impossible, but the map pans back after mouse-up.

Let's go for the simple solution first, center of the map withing extent but keep in mind more advanced scenario's when writing this code.

RestrictPanMode.KeepCenterWithinExtents has been implemented and there are no complications.
RestrictPanMode.KeepViewportWithinExtents has been implemented. This mode is not applicable when the Map.Envelope does not span the full viewport. So we check this and don't restrict zoom in that case. This is checked separately for the horizontal and vertical directions so that you can have situations where horizontal panning is restricted but not vertical and vice versa.
RestrictZoomMode.KeepWithinResolutions is an option to restrict zooming in or out too much.
With RestrictZoomMode.KeepWithinResolutionsAndAlwaysFillViewport it is possible to also prevent the user from zooming out to a level where the map view does not span the viewport. When this is used in combination with RestrictPanMode.KeepViewportWithinExtents the full viewport is always fully covered by the map.
Complications:

When the level where 'the map view spans the viewport' is more zoomed-in that the 'most zoomed-in level' of RestrictZoomMode.KeepWithinResolutions thing become weird. Possibly we should treat  'the map view spans the viewport' as the most zoomed-in level in that case.
The most zoomed-in level is where the tiles show optimal. As a user I would like to be able to zoom-in more than that and blow up those at least one level more. The default should be perhaps go one step further.

To fix complication 1 the AlwaysFillViewport part is skipped when the 'map-spans-viewport-level' is more zoomed-in than the 'most-zoomed-in-level'.

To fix complication 1 we divide by two when determinin the ResolutionExtremes based on the Map.Resolutions.

Ready for testing


Installation of XCTest-Gherkin using carthage.

Hi,
We are looking for installation of XCTest-Gherkin using carthage.

Hi @suniljakhar. This would be a very cool addition to XCTest-Gherkin. We'll be happy to review a pull request that adds this functionality.

Hi - I don't know anything about carthage really, but does this PR fix your problem - https://github.com/net-a-porter-mobile/XCTest-Gherkin/pull/47 ?

Hi, the scheme does not seem to be shared. It works if one checks the main scheme as shared in _Pods.xcodeproj. I can try to make a pull.

@ollitapa Hi - is this issue fixed? (there's a PR for carthage here https://github.com/net-a-porter-mobile/XCTest-Gherkin/pull/47 but I don't use carthage so I don't know if it's working!) If this works with carthage now can you confirm so we can close this issue please? Thanks!

I can confirm the Carthage installation works.


Add support for ERC-1271 signature verification

🟡 Heimdall Review Status

Requirement
Status
More Info

Reviews

🟡
0/1

Denominator calculation

Show calculation

1 if user is bot
0

1 if user is external
0

From .codeflow.yml

1

Additional review requirements

Show calculation

Max
0

0

From CODEOWNERS

0

Global minimum
0

Max

1

1

1 if commit is unverified
1

Sum
2

@****

Review Error for WOweeWee4real @ 2024-12-29 04:42:47 UTC
User must have write permissions to review

Review Error for WOweeWee4real @ 2024-12-29 05:24:41 UTC
User must have write permissions to review


password reset does not work because msmtprc ownership is wrong

Trying to do: have a password reset link mailed when I enter my email address in the password forgtten screen
result: error message complaining invalid characters for mailserver
remedy:
cd /etc && chown nginx:www-data msmtprc && chmod 600 msmtprc

outdated // works with current images


Use new REPL notebook API

Thank you for doing this - I'm giving this a check right now.
Is it expected behavior that we see the little jupyter icon next to Python REPL? @amunger

need to update smart execute command for repl.execute

I've locally tested this and it seems like Intellisense is broken (not completely broken), but rather acting in weird way it doesn't provide all of the completions that it used to:
The screenshots are the Intellisense we would get without this PR:

which provide all the familiar completions from standard library module, but after pulling in the PR into local branch I've noticed different behavior (the video is building the extension after pulling in local branch):
https://github.com/user-attachments/assets/a7ee7c5c-5802-4d2e-9f10-63388f5d2e82
Also one more bug finding: The very first code sent to native REPL doesn't seem to run/generate output with this PR.

@amunger In the video you can see it updating the problems view. Should it?

Also realized the editor name is different in the video (with changes in this PR)
Before we used to have "Python REPL" as the editor tab name like this(where you would always see Python REPL as editor tab name for native REPL instead of "REPL-1" that you see on the video above:

I think this is because before this PR, we used to run the interactive.open command and specify the editor tab name like:
const interactiveWindowObject = (await commands.executeCommand(
            'interactive.open',
            {
                preserveFocus: true,
                viewColumn: ViewColumn.Beside,
            },
            undefined,
            notebookController.id,
            'Python REPL',
        )) as { notebookEditor: NotebookEditor };

but with switching to using
openNotebookDocument

we aren't passing in the editor tab name.
This would break our logic for https://github.com/microsoft/vscode-python/blob/63280be2279484fae9d0d61c5b94576a36b9c693/src/client/repl/replUtils.ts#L99 since we are relying on the editor tab name for searching.

I think we can modify the search so that we look through all the ones with @ REPL - <some_number> but wasn't sure if this was intended. I think having just Python REPL as tab name would be good for now since we only allow one universal Python native REPL, but I didn't see any parameter options for openNotebookDocument to pass in editor tab name ourselves.

@amunger In the video you can see it updating the problems view. Should it?

It's just another notebook cell, so it will update the problems like anything in the history of the repl would

after talking with @amunger, it seems like the issues for (intellisense, editor tab name, first command getting lost problem) were all resolved after updating vscode-insiders to the latest.
Bumping up the version number should hopefully prevent all of this happening for users.


Config tests

Get config code UTed and ready for review.

In case this conversation might precipitate more non-trivial work in the config area - please see also my comments at https://github.com/Metaswitch/calico/issues/326.

This isn't currently passing UTs, but the failures are relatively insignificant, so I'm going to merge it now so we can start merge to master and start testing sooner.  I'll fix these failures up in parallel.


Wherever a text field calls for a few things (like child name/country, what/when/where, country/date, etc.) it would be nice if the field label gave a format example or instructions.

I have this on the agenda for our meeting.

I asked for feedback. They will provide as needed.


kafka: new deserializers

Commit Message: kafka: new deserializers
Additional Description: new deserializers for kafka variable-length encoded int32 & int64 (called varint, varlong there). These deserializers will be used in kafka-mesh-filter to decode internals of received kafka produce request objects so we can get the real messages out of the envelope (like here), and forward them to kafka producers.
Risk Level: Low
Testing: unit tests
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A

/assign-from @envoyproxy/first-pass-reviewers

/wait

/wait let's wait for the builds first

/wait

/retest


use BooleanBuffer::collect_bool in the make_comparator documentation example

Which issue does this PR close?
No issue as there were no bug or feature requests behind it
Rationale for this change
using BooleanBuffer::collect_bool is supposed to be faster as it eliminates the conditional Iterator::next
What changes are included in this PR?
update docs example from:
let values = (0..len).map(|i| cmp(i, i).is_eq()).collect();

to :
let values = BooleanBuffer::collect_bool(len, |i| cmp(i, i).is_eq());

Are there any user-facing changes?
Nope

In this case it is unlikely to be faster, as the comparator contains a dyn dispatch, and will result in more codegen. Do you perhaps have a benchmark showing it is faster in this case?

Only the docs:
https://github.com/apache/arrow-rs/blob/ba85fa3bc68fd6fdc2b401adcf5eddb9f482b7c9/arrow-buffer/src/buffer/mutable.rs#L449-L454

I'm fairly new to Rust, where can I learn more about why this would not necessarily be faster?


CREATE NEW UPDATE PACKAGE OF THIS PACKAGE

I had to make PR to update null-safety, but the author didn't accept it. So I have created a new package with the help of this package with null-safety enabled and added half star selection option.
Check out the package: flutter_rating_native

updated the package


Backend configuration jsonschema does not support open_pulse: true

Information

Qiskit Terra version:
Python version:
Operating system:

What is the current behaviour?
The backend configuration does not support open_pulse: True.  See:https://github.com/Qiskit/qiskit-terra/blob/f66351785116b4c6533de868ca3874214f6cc5cb/qiskit/schemas/backend_configuration_schema.json#L308
Steps to reproduce the problem
Try and validate a pulse backend configuration with open_pulse: True
What is the expected behaviour?
open_pulse: true should be allowed.

Closing as while confusing the schema is actually correct.
The linked line in the initial issue only applies to the coreconfig and enforce open_pulse is false if only the core config is present. open_pulse = True is still allowed by the oneOf statement which includes the coreconfig and the openpulse_config


Unable to add certificate

Summary
We have a plugin which requires a configured TLS certificate in order to work. When we add the certificate through the management API it works fine. But we are unable to add the certificate to Kong via the kubernetes-ingress-controller with kubectl.
Kong Ingress controller version
0.6.1
Kong or Kong Enterprise version
1.4.0
Kubernetes version
1.12.0
Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.0", GitCommit:"0ed33881dc4355495f623c6f22e7dd0b7632b7c0", GitTreeState:"clean", BuildDate:"2018-09-27T17:05:32Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.0", GitCommit:"0ed33881dc4355495f623c6f22e7dd0b7632b7c0", GitTreeState:"clean", BuildDate:"2018-09-27T16:55:41Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}

Environment

Cloud provider or hardware configuration: running locally with minikube version: v1.5.2
OS (e.g. from /etc/os-release): Ubuntu 18.04.3 LTS (Bionic Beaver)
Kernel (e.g. uname -a): 4.15.0-70-generic
Install tools:
Others:

What happened
We run kubectl create -f <our file> on a file containing
apiVersion: v1
data:
  key: <our key, base64 encoded>
  cert: <our cert, base64 encoded>
kind: Secret
metadata:
  name: ids-cert
  namespace: kong
type: Opaque

Expected behaviour
The certificate would appear in Kong as a certificate which our plugin can use to function successfully.
Steps To Reproduce

Run minikube start --kubernetes-version v1.12.0 to start minikube.
Run

curl -sL https://bit.ly/kong-ingress > kong-ingress.yaml

kubectl create -f kong-ingress.yaml

kubectl create -f <our certificate file> (as above)
View the "Certificates" page in Konga. It appears empty.

https://kubernetes.io/docs/concepts/services-networking/ingress/#tls
You need to configure an Ingress resource with TLS section for Kong to serve the traffic using the above certificate.

We figured it out. Should have been
  - apiVersion: v1
    data:
      tls.crt: <our cert, base64 encoded>
      tls.key: <our key, base64 encoded>
    kind: Secret
    metadata:
      name: ...
      namespace: ...
    type: kubernetes.io/tls


Updated AerialCore msgs

I agree with this change, even with the new service, i.e.,
mrs_msgs/Action
---
bool success
string message

As for the name, I don't know if it makes sense to call it AerialCoreActions' because it should be already a message of Aerial-Core type. I mean, something like aerial_core/Action`. In this case, I think, there would be no misunderstanding with the existing messages.
Also, regarding the question:

Does it make sense to have it inside of mrs_msgs? We already have repos with msgs for projects like DARPA, MBZIRC or NAKI. So maybe it will be better to have it in a separate repo, something like aerialcore_msgs.

I would say yes, it makes sense because the MRS software framework will be used in the project as a reference tool to perform experiments with Unmanned Aerial Vehicles (both fixed and rotatory wings). Also, as Tomas pointed out, the number of messages should not be huge, so it is best to have everything in one place

As for the name, I don't know if it makes sense to call it AerialCoreActions' because it should be already a message of Aerial-Core type. I mean, something like aerial_core/Action`. In this case, I think, there would be no misunderstanding with the existing messages.

I think name aerial_core/Action is not possible. As I know, generated messages are always under the name of the package, where they are specified. So it doesn't matter if you put it under some subfolder such as msg/aerial_core/Action.msg. This message will be generated as header mrs_msgs/Action.h. That is why Tomas wants to have a more specific name. Also, Action can be a misleading name because ROS has a specific msg type named actions.
To have include aerial_core/Action.h the message has to be generated in package name aerial_core.

Ah, ok. In this case, feel free to change it. I will update the deliverable of Aerial-Core that points to that message.

@gsilano can we close this one too?

Yes, sure. This pull request was related to #2


Can't bind functor returned by std::bind

I have a function like:
Scene * Foo::createScene(
    const std::string &name,
    std::uint32_t width,
    std::uint32_t height)

Since I want it to be used like a static in lua, I bind it using
    state["createScene"].setFunction(std::bind(
        &Foo::createScene, this, _1, _2, _3));

But this does not work (at least in VS17, and I'm using C++ 17).
Looks like because decltype(&T::operator()) in has_operator_fn failed for some reason.
Any ideas?

Seems to be caused by the const/nonconst overloads of operator() of the object returned by std::bind.


Bump version from 2021.9.9 to 2021.9.29

[x] Bump wallet version using make_release.sh script

Comments
Since the node-bump is already merged, I think aiming for a release tomorrow already is fair. Shouldn't matter if we finalise the release the 30th either, even though the version is 2021.9.29.
ℹ Sorry for tagging more people for review than necessary, but if someone on Australia time wants to approve and bors, it would be appreciated, as there would be less waiting EU morning 🙏
Issue Number

bors r+


fix: remove old command for align packages versions

Summary:
While working on a couple things, me Riccardo and Nicola noticed that in main for some reason the old align-package-versions command in the root package.json was still there in main branch.
This was "merged into" bump-all-updated-packages by @hoxyq all the way back in March; here's the commit for 0.72 branch -> https://github.com/facebook/react-native/commit/a469927c16e175b637b2eaf9a84af94f2e8cb519
We are not sure why, but for some reason the same commit in main was borked in some way, and didn't actually remove the command: PR (https://github.com/facebook/react-native/pull/36568) and commit (https://github.com/facebook/react-native/commit/04df252aa7bff34a02b24f8381b3f2f1dd122c2f)
So this commit just takes care of that.
Changelog:

[INTERNAL] [REMOVED] - remove old command for align packages versions
Test Plan:

N/A - it's a removal

I guess I've just changed my mind between merging it into 0.72 and main.
This command still can be used, though. There is not so much sense to use it alone now, but still.
Make sure removing this section in docs, if you end up removing this command.

I guess I've just changed my mind between merging it into 0.72 and main.
This command still can be used, though. There is not so much sense to use it alone now, but still.

Actually that command doesn't seems to work anymore (that's what we experienced on Friday last week). That's also what triggered this investigation and removal @hoxyq


Implement HTML Documentation Generator

Luna Build provides the ability to generate HTML documentation from the source files.

[ ] Can parse the generated AST.
[ ] Handles the new syntax (#144)
[ ] Generates HTML documentation.

This issue is... Done? @wdanilo @lgawlik

Oh, this is a duplicate of https://github.com/luna/luna/issues/302 -- I created #302 to accomodate the PR, because it wasn't connected anywhere. Please connect your PRs ;)


Adding Lazy option and fix directives

closes #74

Adding the search for the closest input element to the "updated" directive
Add 'lazy' option to maintain compatibility with UI frameworks (example: Naive UI, ElementUI etc..)

NaiveUI Working Example
<n-input
    v-model:value="price"
    v-money="{
      decimal: ',',
      thousands: '.',
      precision: 2,
      masked: false,
      debug: true,
      lazy: false
    }"
/>

I merged this pull request in, but I stopped development of this feature until the following topics are checked:

[ ] Understand better the the need to change the name of the event that the directive dispatches every time a value changes.
[ ] Understand why a setup validation method should be called on every updated method execution.

If the new feature is delivered it should have:

[ ] Tests
[ ] Docs

@jonathanpmartins
Yes, for it to work with Naive UI, an "input" event needs to be emitted.
In the next commit I will document, test and explain the functionality better.
Thanks

Yes, I believe this suggestion is more comprehensive than what I had suggested, as the user can define the name of the event as they wish. I also agree with the naming so that it is very clear what 'emittedEventName' is about.


siteUrl, assetPrefix aren't prepended to links on dendron publish export

Please select the area your bug applies to. (Multiple selections are Possible. You can leave blank if you're not sure.)

[ ] Workspace.  VSCode workspace, vaults, Intellisense/autocomplete, Dendron settings
[ ] Lookup.  Dendron's Lookup Command
[ ] Views.  Dendron Preview, Tree View, Side Panels in the UI
[ ] Schema.  Dendron Schemas
[ ] Pod.  Data import from / export to Dendron
[x ] Publish.  External Site Publish
[ ] Markdown.  Markdown features, such as syntax support and features

Describe the bug
On a machine without vscode or a dendron extension, I'm trying to use:
npx dendron publish export
to generate a static html site. After the build process concludes, my site does not have the appropriate siteUrl or assetPrefix prepended to html links.
To Reproduce
In the bash shell:

npm i @dendronhq/dendron-cli@latest (0.89)
copy over dendron.yml and code-workspace files to workspace root
cd $dendron_workspace_root
npx dendron publish init
npx dendron publish export (generates a next site)
copy .next/out/* into html served folder (see the bug, css has wrong path, links don't work, etc.)

Expected behavior
A published and working site with links that include the siteUrl and assetPrefix.
Screenshots
Desktop (please complete the following information)

OS: arch
any browser
Versions (all that apply to bug):

Dendron Extension: NA
VS Code version: NA
Dendron CLI: 0.89

Additional context
Workspace root has a dendron.yml and code-workspace copied over from my machine with vscode and dendron installed which generated said files for this particular vault I'm trying to publish.
dendron.yml VERSON 5, publishing section
publishing:
siteUrl: [https://site.com/]
assetPrefix: [/~user]
enableFMTitle: true
enableNoteTitleForLink: true
enableMermaid: true
enablePrettyRefs: true
enableKatex: true
copyAssets: true
siteHierarchies: - root
writeStubs: false
siteRootDir: docs
seo:
title: Dendron
description: Personal Knowledge Space
github: enable
EditLink: true
editLinkText: Edit this page on GitHub
editBranch: main
editViewMode: tree
enableSiteLastModified: true
enableFrontmatterTags: true
enableHashesForFMTags: false
enableRandomlyColoredTags: true
enablePrettyLinks: true
Dendron Log file
NA(?), using CLI

Thanks for reporting @stevefan - we are tracking.

hey @stevefan are you still seeing this issue? this should have been fixed


Cypress/E2E: fixed cypess test cases

Summary
fixed image_link_preview_new_window test case
fixed image_link_preview test case
fixed slash_commands test case
fixed markdown_image test case
fixed common_commands_2 test case
fixed image_attachment test case
fixed inline_images_open_preview_window test case
Screenshots

Release Note
NONE

/e2e-test

Triggering e2e testing with options:
<nil>

Successfully triggered e2e testing!
https://git.internal.mattermost.com/qa/cypress-ui-automation/-/pipelines/167878


[Hotfix] Make routes and views for PATs public

Purpose

Allow users to create Personal Access Tokens
Allow OSF-Offline to function with production data

Changes
Remove DEV_MODE restrictions for PATS
Side Effects
None

Merged into release/0.57.0


Core: Drop custom copymem/zeromem defines

We've been using standard C library functions memcpy/memset for these since
2016 with 67f65f66391327b2967a20a89c3627e1dd6e84eb.
There was still the possibility for third-party platform ports to override the
definitions with a custom header, but this doesn't seem useful anymore.

Cherry-picked for 3.4. (Actually redone manually.)

Note to module developers: this breaks compat for custom modules in 3.x who use those defines as in Godot. But it should be straightforward to port existing code.


Version 0.10.8 ships unnecessary artifacts

Hi @alexkuz,
it looks like something went wrong during the last release. The release on npm includes a packages/react-json-tree-demo-app folder of 71 MB.
This makes our build fail due to flow errors: https://travis-ci.org/nteract/hydrogen#L178

Ouch.

Fixed, thank you!

Awesome thanks.