[Grammar Adjustment] Learn - content next to the "Get Early Access" form

Current State:

Link to website: https://play.meshery.io/
Currently, the text reads as follows: "Sign-up to receive a user account, entitled with perpetually free and full access the Playground environment."

Desired State:

The suggested change is to add the word to so it reads: "Sign-up to receive a user account, entitled with perpetually free and full access to the Playground environment."

Screenshot

This issue is opened in wrong repo. It should be in the "play" repository.

Hi, @VivekBaldha0712 are you currently working on this issue?

Yes. But this issue is opened in wrong repo

This issue is raised in the wrong repo. It should be on meshery, I've gone ahead and replicated the issue in the appropriate repo.
@VivekBaldha0712  Consider requesting re-assignment in that repo (play).
@abhijeetgauravm  As a contributor, I probably don't have the authority to close an issue, could you do this in the meantime?

Thank you for pointing it out @VivekBaldha0712 @sandramsc. I'm closing this issue now.


ESP v5.0 removed mdns Why? (IDFGH-9213)

In v4.4.3 we had mdns which I was using.
Upgraded to v5.0 and its gone.
Why did they remove it from the components folder, and examples ?

https://components.espressif.com/components/espressif/mdns

I have replied here: https://esp32.com/viewtopic.php?f=2&t=31770


refactor: rename superblocks.ts to curriculum

This reflects the fact that it's the top level of the entire curriculum.
Checklist:

[x] I have read and followed the contribution guidelines.
[x] I have read and followed the how to open a pull request guide.
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Yeah, I'm trying to figure out a nice approach right now, but my thinking is just that (at a high level) this represents the curriculum (i.e. it's an array of superBlocks).


Exception when using models having primary key names different from 'id'

To reproduce the issue, add a custom primary_key field to the FkModel test model
FkModelId = models.AutoField('ID', primary_key=True, editable=False)
@python_2_unicode_compatible
class FkModel(models.Model):
    FkModelId = models.AutoField('ID', primary_key=True, editable=False)
    name = models.CharField(max_length=200)
    relation = models.ForeignKey('self', null=True, blank=True)
    noise = models.ForeignKey('OtoModel', null=True, blank=True)
    taxpayeraccount = models.ForeignKey(iTaxPayerAccount, null=True, blank=True)

    for_inline = models.ForeignKey('self', null=True, blank=True,
                                   related_name='reverse_for_inline')
    def __str__(self):
        return self.name

Following exception is thrown when adding new values to this model
OperationalError at /admin/basic/fkmodel/2/
no such column: id
Request Method:	GET
Request URL:	http://eternity:8000/admin/basic/fkmodel/2/
Django Version:	1.7.3
Exception Type:	OperationalError
Exception Value:
no such column: id

The problem is the statement
            clauses = ' '.join(['WHEN id=%s THEN %s' % (pk, i) for i, pk in
                    enumerate(self.values)])

in the method order_choices of autocomplete_light/autocomplete/model.py
It is assumed the primary key name is id
    def order_choices(self, choices):
        """
        Order choices using :py:attr:`order_by` option if it is set.
        """
        if self.values:
            # Order in the user selection order when self.values is set.
            clauses = ' '.join(['WHEN id=%s THEN %s' % (pk, i) for i, pk in
                    enumerate(self.values)])
            ordering = 'CASE %s END' % clauses
            return choices.extra(
                select={'ordering': ordering}, order_by=('ordering',))

        if self.order_by is None:
            return choices

        if isinstance(self.order_by, six.string_types):
            return choices.order_by(self.order_by)

        return choices.order_by(*self.order_by)

To fix the issue, change the above statement in:
            clauses = ' '.join(['WHEN "%s"=%s THEN %s' % (self.model._meta.pk.name, pk, i) for i, pk in
                    enumerate(self.values)])
            ordering = 'CASE %s END' % clauses

Now use the model primary_key name, which is "id" by default

Even with the fix suggested above the SQL query will fail if the primary key is not an integer, because the value isn't quoted.

The change to order_values() also seems to overwrite any default ordering on the queryset. Is there a situation where self.values will be set, but the conditions on the queryset will allow it to include other values from the database? If so, then the values will be ordered first, but everything else will be random because you are ignoring self.order_by.

Basically in the fix, the only change is replacing "id" with the actual primary_key name of the model. which should fix the reported bug. Any other issues such as reported by rhunwicks is from my opinion not related to this reported bug.

Closing in favor of PR #417, please join the discussion there.
It tests non-id non-numeric id.
@rhunwicks
The purpose of this feature is to keep the order the user selected it in.

Could you try with 2.2.0rc1 which was released yesterday ?
Thanks.

Hi, I had the non-id primary key issue with 2.1.1 (was using CharField(16)) and it is fixed after "sudo pip install -U --pre django-autocomplete-light" upgrading to 2.2.0rc2

Thanks for your feedback BRO
Le 28 mai 2015 04:19, "Dave Lawrence"<EMAIL_ADDRESS>a écrit :

Hi, I had the non-id primary key issue with 2.1.1 (was using
CharField(16)) and it is fixed after "sudo pip install -U --pre
django-autocomplete-light" upgrading to 2.2.0rc2
—
Reply to this email directly or view it on GitHub
https://github.com/yourlabs/django-autocomplete-light/issues/413#issuecomment-106149043
.


Provided accumulators should support fact retraction

The accumulators in clara.rules.accumulators namespace don't handle handle retraction of facts, which can lead to confusing behavior. For instance, the count accumulator won't decrement the count if one of the items it is counting is retracted from the working memory. This and others (such as c.r.a/sum, c.r.a/average, c.r.a/all, c.r.a/distinct) can be easily added by providing a retract-fn.
In the example of the count accumulator, the current code is:
(defn count
  "Returns an accumulator that simply counts the number of matching facts"
  []
  (accumulate
   :initial-value 0
   :reduce-fn (fn [count value] (inc count))
   :combine-fn +))

We simply need to add a retract-fn like this:
   :retract-fn (fn [count retracted] (dec count))

Maybe I'm off base here, but if this is a sensible default, then perhaps it
wouldn't be a bad idea to make the definition of an accumulator enforce the
presence of a retract fn.
On Mon, Oct 5, 2015 at 12:04 PM Ryan Brush<EMAIL_ADDRESS>wrote:

The accumulators in clara.rules.accumulators namespace don't handle handle
retraction of facts, which can lead to confusing behavior. For instance,
the count accumulator won't decrement the count if one of the items it is
counting is retracted from the working memory. This and others (such as
c.r.a/sum, c.r.a/average, c.r.a/all, c.r.a/distinct) can be easily added by
providing a retract-fn.
In the example of the count accumulator, the current code is:
(defn count
"Returns an accumulator that simply counts the number of matching facts"
[]
(accumulate
:initial-value 0
:reduce-fn (fn [count value] (inc count))
:combine-fn +))
We simply need to add a retract-fn like this:
:retract-fn (fn [count retracted] (dec count))
—
Reply to this email directly or view it on GitHub
https://github.com/rbrush/clara-rules/issues/127.

I think this issue strongly related to
https://github.com/rbrush/clara-rules/issues/86
Which I don't think we ever really came to a resolution on.
Perhaps reading that will give you some background devn.

For what it's worth though. The way we dealt with this for our usage is we provided a general purpose "wrapper" for creating Clara accumulators. It turns he default "non-state-preserving" accumulators into an accumulator that implicitly keeps track of the state of everything seen so far and a default, naiive retract fn that just runs an entire reduce over all facts seen, minus what has been retracted. This is less than ideal but maintains consistency with the truth maintenance of the engine and performs alright if there aren't heavy retraction rework happening.
The engine may be able to provide a better default from within the engine itself perhaps with something like batches retracts instead of one at a time. However I haven't gotten to think about this much yet.
The issue I linked to above is what the inspiration of the general purpose wrapper came from though.

@mrrodriguez, thanks for bringing up #86. Looking at it now, I think the default behavior I mentioned in the discussion in #86 wasn't the right choice. I think Clara's provided accumulators should behave in the least surprising way possible, even if that's not as efficient as an accumulator that doesn't have to deal with retractions. To @devn's point, I agree that requiring the caller to specify a retract-fn also makes sense...and if a caller wants to define an accumulator that doesn't keep old state he is welcome to do so and have a retract-fn that does nothing. (This change could break users that don't offer one, but it will fail fast with a clear message and I think the 0.9.0 stream is a good point to introduce such changes.)
The nice thing is that Clara's accumulator abstraction makes it easy for users to define their own accumulators that do whatever makes sense for the case at hand. So @mrrodriguez's wrapper model could continue to be used there.

I went ahead and added retract support and tests to the provided accumulators in the above commit. I'll probably merge it to master soon but wanted it in the branch in case anyone wanted to take a look or suggest a different course beforehand.

I think this approach is interesting and will work with minimal effort.
I want to discuss a bit on the tradeoffs of this approach though:

This will mean that the :reduce-fn for many accumulators will in a way stop behaving like the intuitive notion of what a reducing function means in a typical reduce operation.
e.g. If I'm writing an accumulator to find the newest timestamp on some fact, I'd expect to write the comparison logic for the newest in the :reduce-fn.  With this approach, the :reduce-fn often does little more than collect everything to delay the "reducing decision/step" until the :convert-return-fn.
To summarize:

This is a loss of intuition around what the :reduce-fn means (to me and perhaps others).
This is, in a way, a leak of the underlying engine details.  The consumer is expected to manage their own accumulator memory.
This isn't how Drools works with accumulators.  It will just rerun the accumulate with the item removed if no "reverse" operation is provided.  I'm not sure about other mainstream engines.  This may not be that important though.
If the :convert-return-fn becomes heavy-weight I do worry that this logic isn't happening in the "ideal place" since it isn't even in the the accumulators reduce, but rather after it.  That may just be a misguided performance concern though mostly.  I think we would be losing the ability for parallel processing the reducing work though (which isn't used right now, but sort of positioned to be).

--
I think I mostly understand the tradeoff here.  This approach is simple and allows the engine to continue to not maintain any memory within these nodes.
However, what are we gaining from the engine not maintaining this node memory though?  There is a certain "stream" ability for an accumulate node right now, but does that matter when we have to retain all of these references in (global) working memory anyways?
I think this may relate some to the distributed Storm approach that I have not had a lot of time to work with at this point.  Couldn't we just add a flag to an accumulator definition if we wanted it to behave in a streaming way, so that that became the edge case rather than changing the typical all-in-memory case?
--
If the engine did maintain accumulate memory, we could have a naive :retract-fn for "free" that just did what this commit calls clara.rules.accumulator/drop-one-off and then performed a reduce with the reducing function being the :retract-fn (Drools does similar).

Given my points above, I'm still leaning towards preferring the Clara engine maintaing accumulate node memory.  I am curious for your feedback on this though, especially around what tradeoffs we are working with precisely.

We could easily change the min and max accumulators to maintain a heap of values in the reduce-fn, and the convert-return-fn would simply pull the item off the heap. But lacking a convenient heap structure I suspect it's more efficient to do the sort at return time, rather than doing a sort as values are added to the reduce-fn. I don't think this pattern of do-the-work-when-we-return-the-value is necessarily representative of other accumulators...it was just the simplest implementation that presented itself.
I would be okay with adding a :supports-retract option (and default it to true), so an implementation of min/max could keep only the actual value rather than all records. It looks like this is actually what Drools does by default.
Managing this state efficiently when hosting rules in a distributed system is a pretty complicated topic in itself. If we provide the option to let things work as they do now, users of a distributed system could use that to gain efficiency.  We should consider ways to support richer semantics when distributed as well, but I'm not quite ready to get into that here. ;)

I agree that the implementation choice for min and max probably are doing it in an efficient way.  Perhaps that would be the case for many accumulators and my points off-base.
Maybe Clara should just provide an accumulator wrapper impl that would turn any accumulator into one that had a :retract-fn that would be able to retract automatically.  This requires managing some "hidden state" of the facts seen behind the :initial-value, :reduce-fn, and :combine-fn, but isn't too hard to do.
The wrapper approach could be sufficient if it isn't going to be any slower than what the engine would be capable of doing with specific node memory (I haven't gotten to think about that one enough yet).
The only drawback to this to me still is that without the wrapper the default behavior is surprising.
To reduce the surprise, we could keep the :retract-fn as required and you could just call the decorator when you wanted one for "free".
Something like:
(clara.rules/accumulate (clara.rules/with-retract-support {:reduce-fn my-reduce-fn}))

I'm a bit reluctant to add the wrapper pattern into Clara itself since I'm not sure it's a common, general pattern. We would definitely support that pattern, but it might make more sense for it to live in user libraries. I think this is still open for debate...I just want to keep the API small.
For users wanting to create accumulators with simple reduce functions, I think we can add some functions for that as a convenience. What if we deprecate today's "accumulate" function add add an overloaded "accumulator" function like this:
(accumulator {:initial-value 0, :reduce-fn +, combine-fn + retract-fn -}) ; Creates an accumulator with all options available today.
(accumulator my-reduce-fn) ; Creates a simple accumulator that uses the given reduce method
(accumulator my-reduce-fn :update-on-retraction false) ; Creates an accumulator without retraction support.

Basically the accumulator function would accept either a map or a simple reduce function and options to grant more control for special use cases, and everything would have defaults resulting in the least surprising behavior. I think we'd deprecate clara.rules/accumulate and replace it with this (perhaps moving it to the clara.rules.accumulators namespace since it seems to fit better there.)

+1
I like your last proposal here.
Are you thinking
(accumulator my-reduce-fn)

has :update-on-retraction defaulting to true and that means that Clara will provide the retraction capabilities to the accumulator?  Or if it isn't the default, is that what true means still?

Yes, :update-on-retraction would default to true and Clara will provide the retraction capabilities itself.

Alright, I got a chance to get back to this today. I ended up going with new accum and reduce-to-accum functions in the accumulators namespace, and patterned it after some logic Mike had worked out to convert reduce functions into accumulators.
All built-in accumulators now support retraction properly by default, and it should be easier to create user-defined accumulators that do so as well. Feedback is welcome. If nothing comes up I'll merge to master in the next few days.

I think this commit looks good. Thanks for all the rounds of quick feedback on this issue too!

Merged! Thanks for the input.

:clap: Thanks to you all for your work on this.


increase consistency of buttons and labels

The font sizes, styles and behaviors of buttons and their tooltips vary considerably. The cards would be a bit less busy, if they had a bit more consistency. Quick observations:

share: currently no tooltip → add a similar tooltip as for Umdrehen!
share and turn icons have different sizes → use similar size, increase size of share button
info: currently the label is shown, with very different font/weight than Umdrehen! tooltip → consider removing the label and use similar tooltip as for the other(s)
toggle might benefit from a small tooltip underneath as the Umdrehen tooltip
on hover the share and info buttons/icons change their color (differently so though), but toggle and turn do not → make on-hover color change consistent and add something like it to toggle and turn icons
next card: yet another font size :)

[ ] share: currently no tooltip → add a similar tooltip as for Umdrehen!
[ ] share and turn icons have different sizes → use similar size, increase size of share button
[ ] info: currently the label is shown, with very different font/weight than Umdrehen! tooltip → consider removing the label and use similar tooltip as for the other(s)
[ ] on hover the share and info buttons/icons change their color (differently so though), but toggle and turn do not → make on-hover color change consistent and add something like it to toggle and turn icons


[WIP] feat: @ZiplineId

closes: #1048

I’ll take a look at this! But please in the future let us know before you proceed to build features? We’re not actively seeking external contributors.


Type not narrowed when putting optional1 || optional2 condition in if statement and repeating it in its body

Suggestion
🔍 Search Terms
type inference in repeated expression
repeated or condition
or condition

✅ Viability Checklist

My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion
This code (playground link):
function required(x: number): number {
  return x;
}
function optional(a?: number, b?: number): number {
  if (a || b) {
    return required(a || b);
  }
  return 0;
}

produces this type error on the return required(a || b) line:
Argument of type 'number | undefined' is not assignable to parameter of type 'number'.

but TypeScript should be able to infer that a || b can only be a number not number | undefined because the || expression must be true in the if block.
📃 Motivating Example
I am checking two optional properties of an object and using them interchangeably. Currently I have to use an as expression.
💻 Use Cases
See above.

Duplicate #35260


Create a test profile for R4.

We currently have this STU3 test profile for testing extension features in Bunsen. We should create a similar one for R4 and add enable the corresponding unit-tests.
This is a left-over from #286. There are already unit-tests that test extension functionality using US Core profiles (which are readily available for R4).

Enabled unit tests for R4 for extended fhir profiles via this PR #924


🔖 Bump version to 0.4.2

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

Project coverage is 100.00%. Comparing base (67b0944) to head (4ec3d21).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff            @@
##            master      #109   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           14        14
  Lines          359       359
=========================================
  Hits           359       359

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


Some webfonts not working (only firefox)

On my webapp I have both an icon font (which works everywhere) and some other fonts for text. Both are imported in fontface right after each other, both are local. Only the Icon font is being acurately rendered by pico. This only appears to be an issue on Firefox (76). On Chrome/Chromium my App is being rendered perfectly.
Any idea what's going on here? Really glad to have found this library, since it seems exactly what I was looking for!

Ok I guess the issue here should be anti-fingerprinting measures by firefox. Not really a problem of this library.


norminette

seems like norminette doesn't accept files names with norminette "$RET0"

Good point! Thanks!
As I don't have access right on your branch patch-1, may be you could add for me an additional error message before I merge :-)
Here is what I mean:
if [ "${RET0}" != "" ]
then
    # do things
else
    printf ${C_RED}"  No source file (.c) or header (.h) to be checked"${C_CLEAR}
fi

And the complete context:
		RET0=$(find . -type f | sed '/^\.\/\./d' | grep -E \\.\[hc\]$ | tr '\n' ' ')
		if [ "${RET0}" != "" ]
		then
			RET2=`norminette $RET0 2>&1`
			cd "$RETURNPATH"
			echo "$RET2" > "$RETURNPATH"/.mynorminette
			RET2=`cat .mynorminette | grep Error`
			RET3=`cat .mynorminette | grep Warning`
			RET4=`cat .mynorminette | grep "command not found"`
			if [ "$RET2" == "" -a "$RET3" == "" -a "$RET4" == "" ]
			then
				printf $C_GREEN"  All files passed the tests"$C_CLEAR
			else
				if [ "$RET4" != "" ]
				then
					printf $C_RED"  Command not found"$C_CLEAR
				else
					if [ "$RET2" == "" ]
					then
						TOTAL=0
					else
						TOTAL=`echo "$RET2" | wc -l | sed 's/ //g'`
					fi
					if [ "$RET3" == "" ]
					then
						TOTA2=0
					else
						TOTA2=`echo "$RET3" | wc -l | sed 's/ //g'`
					fi
					(( TOTAL = $TOTAL + $TOTA2 ))
					printf $C_RED"  $TOTAL error(s) or warning(s)"$C_CLEAR
				fi
			fi
		else
			printf ${C_RED}"  No source file (.c) or header (.h) to be checked"${C_CLEAR}
		fi

Good point! Thanks!
As I don't have access right on your branch patch-1, may be you could do some changes before I merge :-)
Here is what I mean:

finding in "$MYPATH"
add a new error message when no file to be checked
move the command "cd" juste before the "norminette"

RET0=$(find "$MYPATH" -type f | sed '/^\.\/\./d' | grep -E \\.\[hc\]$ | tr '\n' ' ')
if [ "${RET0}" != "" ]
then
    cd "$MYPATH"
    RET2=`norminette $RET0 2>&1`
    cd "$RETURNPATH"

    # do other things

else
    printf ${C_RED}"  No source file (.c) or header (.h) to be checked"${C_CLEAR}
fi

And the complete context:
		RET0=$(find "$MYPATH" -type f | sed '/^\.\/\./d' | grep -E \\.\[hc\]$ | tr '\n' ' ')
		if [ "${RET0}" != "" ]
		then
			cd "$MYPATH"
			RET2=`norminette $RET0 2>&1`
			cd "$RETURNPATH"
			echo "$RET2" > "$RETURNPATH"/.mynorminette
			RET2=`cat .mynorminette | grep Error`
			RET3=`cat .mynorminette | grep Warning`
			RET4=`cat .mynorminette | grep "command not found"`
			if [ "$RET2" == "" -a "$RET3" == "" -a "$RET4" == "" ]
			then
				printf $C_GREEN"  All files passed the tests"$C_CLEAR
			else
				if [ "$RET4" != "" ]
				then
					printf $C_RED"  Command not found"$C_CLEAR
				else
					if [ "$RET2" == "" ]
					then
						TOTAL=0
					else
						TOTAL=`echo "$RET2" | wc -l | sed 's/ //g'`
					fi
					if [ "$RET3" == "" ]
					then
						TOTA2=0
					else
						TOTA2=`echo "$RET3" | wc -l | sed 's/ //g'`
					fi
					(( TOTAL = $TOTAL + $TOTA2 ))
					printf $C_RED"  $TOTAL error(s) or warning(s)"$C_CLEAR
				fi
			fi
		else
			printf ${C_RED}"  No source file (.c) or header (.h) to be checked"${C_CLEAR}
		fi

Or may be we can remove the "cd" command as we find files with absolute path.
There is may be another issue:
With paths containing spaces (that's why I used ´"$RET0"´). We should add a backslash before spaces..

yep I write find $MYPATH instead

Ok cool
I re-wrote the find line to escape spaces with a backslash \.
With this new way to list the files...
RET0=$(find "${MYPATH}" -type f | sed '/^\.\/\./d' | grep -E \\.\[hc\]$ | awk 'BEGIN {ORS=" "} {gsub(/\ /, "\\ "); print}')

...we get the absolute path of the files, listed as bellow:
/Users/admin/Documents/libft/test1.c /Users/admin/Documents/libft/test2.c /Users/admin/Documents/libft/test3.h

So that we can call the norminette from everywhere:
norminette /Users/admin/Documents/libft/test1.c /Users/admin/Documents/libft/test2.c /Users/admin/Documents/libft/test3.h

Tell me if you want me to write the new code, but I would like you to commit this fix.
Thanks

Ok cool.
I re-wrote the way to get the file list to check:
RET0=$(find "${MYPATH}" -type f | grep -E \\.\[hc\]$ | awk 'BEGIN {ORS=" "} {gsub(/\ /, "\\ "); print}')

We now get the absolute path to the files like:
/Users/admin/Documents/ma\ libft/test1.c /Users/admin/Documents/ma\ libft/test2.c /Users/admin/Documents/ma\ libft/test3.h

So that we do not need to "cd" anymore because the following command will work from every directories:
norminette /Users/admin/Documents/ma\ libft/test1.c /Users/admin/Documents/ma\ libft/test2.c /Users/admin/Documents/ma\ libft/test3.h

We can remove "cd", but we have another issue: Add "eval" before "norminette" to make it work:
RET2=`eval norminette $RET0 2>&1`

Tell me if you want me to change the code, but I would like you to commit this fix

yep i'm on, it fail here i'm searching why

I close here, I done one other pull request ( sorry, I have emmêlés mes pinceaux with git )


Run test error

λ  python .\testclient.py
E1030 15:36:09.480000000 11252 src/core/ext/transport/chttp2/server/insecure/server_chttp2.c:38] {"created":"@1509348969.480000000","description":"No address added out of total 1 resolved","file":"src/core/ext/transport/chttp2/server/chttp2_server.c","file_line":245,"referenced_errors":[{"created":"@1509348969.480000000","description":"Failed to add port to server","file":"src/core/lib/iomgr/tcp_server_windows.c","file_line":510,"referenced_errors":[{"created":"@1509348969.480000000","description":"OS Error","file":"src/core/lib/iomgr/tcp_server_windows.c","file_line":199,"os_error":"Only one usage of each socket address (protocol/network address/port) is normally permitted.\r\n","syscall":"bind","wsa_error":10048}]}]}
.....ERROR:root:Exception iterating requests!
Traceback (most recent call last):
  File "C:\ProgramData\Anaconda3\lib\site-packages\grpc\_channel.py", line 185, in consume_request_iterator
    request = next(request_iterator)
  File "C:\ProgramData\Anaconda3\lib\site-packages\aiogrpc\utils.py", line 223, in __next__
    raise r
  File "C:\ProgramData\Anaconda3\lib\site-packages\aiogrpc\utils.py", line 204, in _next
    self._q.put((await nf, False))
  File ".\testclient.py", line 119, in test_input2
    raise ValueError('testerror')
ValueError: testerror
...
----------------------------------------------------------------------
Ran 8 tests in 1.314s

OK

PS C:\QA\aiogrpc> & python c:/QA/aiogrpc/tests/server.py
Server created on ['<IP_ADDRESS>:9901']
Server started
ERROR:root:Exception calling application: TestException
Traceback (most recent call last):
  File "C:\ProgramData\Anaconda3\lib\site-packages\grpc\_server.py", line 383, in _call_behavior
    return behavior(argument, context), True
  File "c:/QA/aiogrpc/tests/server.py", line 40, in ExceptionMethod
    raise ValueError("TestException")
ValueError: TestException
ERROR:root:Exception calling application: TestException
Traceback (most recent call last):
  File "C:\ProgramData\Anaconda3\lib\site-packages\grpc\_server.py", line 383, in _call_behavior
    return behavior(argument, context), True
  File "c:/QA/aiogrpc/tests/server.py", line 40, in ExceptionMethod
    raise ValueError("TestException")
ValueError: TestException
Quit server

This is a correct behavior. This test case covers the situation when the request stream or response stream raises an exception inside the iteration. When these exceptions occur, grpc.io core generates this log.
It might be possible to drop this log with a customized logger, but maybe it is not necessary?

wow  I understand.~ maybe print a tip would be better~( • ̀ω•́ )✧

Maybe we can modify the message to "Testing raising an exception inside GRPC service"?

Feel free to create a pull request, or I can do it myself later.

fixed by a367421158bfeadd2a5bba100c085b2c5a4dc7ac


Denote 0.3.0 Release

Hope does not spring eternal that I can make good things happen with this repo :(

Codecov Report
Attention: Patch coverage is 0% with 3 lines in your changes are missing coverage. Please review.

Project coverage is 40.80%. Comparing base (816b0b7) to head (7dd15cb).

Files
Patch %
Lines

src/ritas/app/app.py
0.00%
3 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main      #28      +/-   ##
==========================================
- Coverage   40.97%   40.80%   -0.17%
==========================================
  Files           9        9
  Lines         493      495       +2
==========================================
  Hits          202      202
- Misses        291      293       +2

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


Upstream into CHIP?

Problem
Is there a plan to move this upstream into CHIP?
Proposed Solution
Please propose an upstream merge :)

Hi @woody-apple , thanks for the interest of this port.
We're just starting but out goal is to contribute upstream with a solid Mbed OS port that would work on all the targets that mbed support. We will start pushing upstream once we have a fully working Shell example.
Out of curiosity, What's the best way to engage with the upstream development team ? Is everything done through Github ? The ZA Slack seem a bit dead.


Watcher.setup(loop=None) raises AttributeError

Using aionotify==0.3.0.
Calling watcher.setup() without a loop will pass loop=None to UnixFileDescriptorTransport
import aionotify
import asyncio

watcher = aionotify.Watcher()
asyncio.run(watcher.setup())

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.10/asyncio/runners.py", line 44, in run
    return loop.run_until_complete(main)
  File "/usr/lib/python3.10/asyncio/base_events.py", line 649, in run_until_complete
    return future.result()
  File "/home/user/tt/venv/lib/python3.10/site-packages/aionotify/base.py", line 91, in setup
    self._stream, self._transport = await aioutils.stream_from_fd(self._fd, loop)
  File "/home/user/tt/venv/lib/python3.10/site-packages/aionotify/aioutils.py", line 128, in stream_from_fd
    transport = UnixFileDescriptorTransport(
  File "/home/user/tt/venv/lib/python3.10/site-packages/aionotify/aioutils.py", line 26, in __init__
    self._loop.call_soon(self._protocol.connection_made, self)
AttributeError: 'NoneType' object has no attribute 'call_soon'

The bug is in base.py's Watcher.setup() method.
    async def setup(self, loop=None):
        """Start the watcher, registering new watches if any."""
        self._loop = loop or asyncio.get_running_loop()

        self._fd = LibC.inotify_init()
        for alias, (path, flags) in self.requests.items():
            self._setup_watch(alias, path, flags)

        # We pass ownership of the fd to the transport; it will close it.
        self._stream, self._transport = await aioutils.stream_from_fd(self._fd, loop)

The last line of the function is the problem. loop is being passed instead of the resolved self._loop.
self._stream, self._transport = await aioutils.stream_from_fd(self._fd, loop)

should be
self._stream, self._transport = await aioutils.stream_from_fd(self._fd, self._loop)

This was not caught in automated testing because loop is always passed.

Current workaround is to always pass loop to Watcher.setup()
await watcher.setup(loop=asyncio.get_running_loop())

Thanks for the report! This has been fixed, and the fix released.


space issue while exporting env var SUPERCRONIC_SHA1SUM

the space in
SUPERCRONIC_SHA1SUM= d7f4c0886eb85249ad05ed592902fa6865bb9d70
causes issue while export env var
sha1sum: 'standard input': no properly formatted SHA1 checksum lines found
from the release page, installation instructions
https://github.com/aptible/supercronic/releases#:~:text=SUPERCRONIC_SHA1SUM%3D d7f4c0886eb85249ad05ed592902fa6865bb9d70

I was caught by this as well. It's a small thing, but it definitely breaks the installation flow when following all the official documentation and attempting to use the Dockerfile instructions from the latest release page.

Yeah I ran into this copy & pasting from the latest release notes https://github.com/aptible/supercronic/releases/tag/v0.2.1
My error was much less clear though, so it took me a while to chase this down.
Another suggestion I have for the release notes; you might consider adding a comment above each copy pasta block that reads like this:

Thanks everyone, the release notes have been updates to omit the space, and future release notes (such as this one) will include the note @bradgessler suggested.


BUG 8258993: Revert change to Assert that is causing a lot of hits on failure path.

This change is

@yongqu review please?

LGTM

@dotnet-bot test Windows x64_release please


problems

[ ] LICENSE
[ ] electron -> electron-prebuilt

suggest： https://github.com/mikaelbr/node-notifier

done


Ultrahdr_app mode 4 is broken again

After a recent update ultrahdr_app api mode 4 appears to be broken again, seemingly related to issue https://github.com/google/libultrahdr/issues/157
ultrahdr_app returns the error "did not receive valid image width for encoding. width :  0" but does not accept width or height parameters as input.

the changes are merged. this can be closed.


Switched CVE Hunting to optional

Description
Until today, CVE hunting was done automatically in kube-hunter.
This resulted in users getting some false positives on specific kuberentes versions (vendor specific)
Due to today's many kubernetes different vendors, it is hard for kube-hunter to say for certain if a cluster is vulnerable just from the K8s version leak it finds.
In any case, kube-hunter is not designed to detect CVEs, this is just a bonus feature.
So to not make users confused, we made CVE hunting optional, with the new flag --enable-cve-hunting
If you really want to scan CVEs you should switch this flag on. (note for possible False Positives)
Contribution checklist

[ ] I have read the Contributing Guidelines.
[ ] The commits refer to an active issue in the repository.
[ ] I have added automated testing to cover this case.

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


Add generic command to run spider from CLI

Add a roach:run <spider> command to start a spider run from the CLI. Currently, you would have to either write a custom Artisan command for this or implement some other way to trigger a spider run. This can be annoying when prototyping spiders, or when trying to start spiders as part of a scheduled command.
I already have this working in a local project, so this shouldn’t be too difficult to add.

Here's mine.
<?php

namespace App\Console\Commands;

use Illuminate\Console\Command;
use Illuminate\Support\Collection;
use Illuminate\Support\Facades\Storage;
use Illuminate\Support\Str;
use RoachPHP\Roach;

final class RunSpider extends Command
{
    protected $signature = 'roach:run {name?}';
    protected $description = 'Run a specific Roach spider';

    public function handle()
    {
        $name = $this->argument('name');
        $spiders = $this->getSpidersList();

        if ($spiders->where('key', $name)->isEmpty()) {
            $name = $this->choice('Which spider?', $spiders->pluck('name')->toArray());
        }

        $spider = $spiders->where('name', $name)->first()['fqdn'];

        if (false === class_exists($spider)) {
            $this->error('Unknow spider class: $spider');

            return self::FAILURE;
        }

        Roach::startSpider($spider);

        return self::SUCCESS;
    }

    protected function getSpidersList(): Collection
    {
        $files = collect(Storage::disk('spiders')->files());

        $spiders = $files->transform(function ($file) {
            if (false === Str::endsWith($file, 'Spider.php')) {
                return null;
            }

            $name = Str::replace('Spider.php', '', $file);
            $key = Str::lower($name);

            return [
                'name' => $name,
                'class' => $name . 'Spider',
                'fqdn' => '\\App\\Spiders\\' . $name . 'Spider',
            ];
        })->reject(fn($item) => empty($item));

        return $spiders;
    }
}

This exists as roach:run <spider name>


Camera proposal

Maybe you want to implement my solution for rotation and scaling (camera zoom) in your package.
vertices transform
https://github.com/setanarut/ebitencm/blob/88eaf86e5af6745ca695a39513490db4e2776379/ebitencm.go#L247
Cursor transform
https://github.com/setanarut/ebitencm/blob/88eaf86e5af6745ca695a39513490db4e2776379/grab.go#L55
Camera demo
Run camera example on your local machine
go run github.com/setanarut/ebitencm/examples/theojansen_cam@latest

Camera Position = WASD
Camera Rotation = Q / E
Camera Zoom = Z / X
Drag object = Cursor
Reset camera = Backspace

Hi @setanarut ,
I wanted to let you know that I’ve created a PR (#3) that implements the proposal you submitted in this issue. Feel free to take a look and share any feedback you might have!
Thanks again for your suggestion!

@demouth unused parameter size -> https://github.com/demouth/ebitencp/blob/b81bea06b68e6cfd9f35db81855ca68d5f959233/ebitencp.go#L230


Nonfunctional changes only

@jonmv please review
Just some random changes I don't want in my next PR.

Hehe.


Accept existing ILoggerFactory in AddLogging()

Programs often initialize their own logger factory on startup before DI is initialized to get logging as soon as possible. To add the factory to DI, we have to manually call AddSingleton(loggerFactory).
However it's easy to get this wrong - the following code will not work properly because this will add the instance for the concrete type LoggerFactory instead of for the interface ILoggerFactory. This means, the existing factory will not be used, but instead AddLogging() will register a new logger factory instance.
var loggerFactory = new LoggerFactory();
services.AddSingleton(loggerFactory);
services.AddLogging();

This PR would allow us to pass an existing logger factory to AddLogging and therefore make sure that this problem can't occur.
This could then also be used in aspnet/hosting -> WebHostBuilder

Hi @cwe1ss, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.
TTYL, DNFBOT;

Programs often initialize their own logger factory on startup before DI is initialized to get logging as soon as possible. To add the factory to DI, we have to manually call AddSingleton(loggerFactory).

They do?

Yes - e.g. in all non-web projects.

And the reason you're calling AddLogging is to get the ILogger support?

After thinking about it, this is actually only meant for scenarios where you don't use WebHostBuilder. With WebHostBuilder, you would just call UseLoggerFactory.
Our console applications (message processors, workers, utils, ...) all use Microsoft.Extensions.Logging, Microsoft.Extensions.DependencyInjection, etc.
Until we get your "uber host builder" we manually have to setup these components. And we always setup Logging as early as possible - which means we do it before we have DI.
This PR would solve a small pain point with the current API in this scenario.

Closing this one.

@cwe1ss The discussion around a more generic HostBuilder for non-web apps that want to use ILogger, Config, and DI impact this. I think you've been following some of that and we should have something more coherent together soon.


Issues when training on my own datasets

Hi,
Thank you for the code. The code here is quite helpful. I successfully implemented it on LIDC dataset and wanted to train my own medical image dataset. The dataset size is 41*41 and training samples are about 8000. The datasets are well preprocessed and loaded through my dataloader. However, when I train it, I got an asset error from net.forward(patch, mask, training=True) where error happens in assert up.shape[3] == bridge.shape[3] in unet_block.py.
After examing the error in detail, I find it comes from RuntimeError: Sizes of tensors must match except in dimension 1. Expected size 12 but got size 11 for tensor number 1 in the list. when it tries to cat up and bridge out = torch.cat([up, bridge], 1).
I am a beginner in this field. Could you give me any insights on what is bridge here and how to tackle this problem? Thanks in advance.

With the provided information I can't really help you. However, the best way to tackle these kind of problems is by printing all intermediate shapes and try to find the step where it goes 'wrong'. Good luck!


Fix buildout security warning.

Pull Request Test Coverage Report for Build 1500

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at ?%

Totals

Change from base Build 1495:
0.0%

Covered Lines:

Relevant Lines:
0

💛  - Coveralls


Try to make install work on old cluster

@klueska check it out.

@klueska The Linux test pass.  I personally see an error on the test from this PR, I think those tests are not covered by CI at the moment. (cf. #1038)


Encode modules with variable-length integers

Update Module::{serialize,deserialize} to use variable-length integers
with bincode to make the output artifacts smaller. Locally this
reduces the size of #2318 from 160 to 110 MB, a 30% decrease in size!
Deserialization performance is slightly slower, but seemingly within the
range of noise locally for me.

To be clear this is just enabling variable length encoding for integers, right? It is not switching to a delta encoding (which would ensure that essentially all addresses are 1-byte encoded) correct?

Ah yes indeed, a delta encoding might make it even more further compact.
I've so far shied away from big changes like that though. I think we may want to do it eventually, but it trades-off in-memory footprint for lookup speed since we can no longer quickly do a random lookup for a particular trapping pc. Not that we necessarily need that to be too too fast.

I'm only advocating for delta encoding in the serialized format, not the in-memory representation.

I'm only advocating for delta encoding in the serialized format, not the in-memory representation.

I think it'd be good to try not to have those two deviate too much: ideally we should at some point be able to mmap the on-disk representation entirely or almost entirely instead of having to read and deserialize it.
There clearly are size/speed tradeoffs to be had here, so that might not be the only thing we support, but I hope it can become a thing we support :)


writing diary to document ideas about AI models

This is to write down ideas to push the project.

Current coverage is 61.71%

Merging #30 into master will not affect coverage as of 56b116f

Powered by Codecov. Updated on successful CI builds.

LGTM


Typo in the basics guide doc

Hi I noticed this minor typo while going through the docs, the text says To do this we, again define a new file lib/scripts.tremor
but the code snippet mentions the wrong file name on top.

thanks good catch 🚀 !


Extremly Slow Request

Hi,
I have a strange situation:
In the API filters for a collection, I use @collection. which references the collection itself, among others. It seems that this part is slowing down any List/Search request (a simple getList(1,10,{}) takes over 10 seconds). However, this only happens if the @collection. rule addresses a large amount of records (over 200 or so). For example: @collection.users.username~'a' -> Problem, but @collection.users.username~'y' -> No problem, fast.
I use multiple @collection. joined with &&.
Now the strange part: The exact same rule exists for the View Rule, but here the request goes through super fast.
Can I take any steps to debug this issue further? I have enabled '--dev' but that only showed me that the query resulting from getList also went through super fast. The debug logs didn't show the query of the permission system (if there is any?).
Thanks for your help!

Without some reproducible steps I'm not sure how to help.
Are you sure that you need the @collection.* rule in the first place? As mentioned in https://github.com/pocketbase/pocketbase/discussions/4928 it performs a JOIN so it could have impact on the perform if not properly used (the same apply if you execute a raw SQL statement).
Do you have custom indexes? If not defined on the correct fields they can also cause performance issue since they may affect what route the query planner will choose (see https://github.com/pocketbase/pocketbase/discussions/3859#discussioncomment-7744045).
If --dev shows that the query executes fast, are you sure that the issue is caused by PocketBase and not by something else (rate limits of the deployment environment, issue with inefficient API interactions from other backends like Next.js or SvelteKit, etc.)?
In any case to rule out PocketBase issue you could create a plain pb_public/index.html with something like:
<!DOCTYPE html />
<html>
<head>
    <meta charset="utf-8" />
    <title>Test</title>
</head>
<body>
    <script type="module">
        import PocketBase from<EMAIL_ADDRESS>
        const pb = new PocketBase("http://<IP_ADDRESS>:8090");

        // authenticate if necessary
        // (authWithPassword is expected to be slow due to the bcrypt hash verification)
        await<EMAIL_ADDRESS>"1234567890")

        const records = await pb.collection("example").getList(1, 10)
        console.log(records)
    </script>
</body>
</html>

Open your browser, navigate to http://<IP_ADDRESS>:8090 and check the request times in the "Network" console tab.
If you are still not able to identify the culprit, please try to create a minimal reproducible repo or at least export your collections configuration as json (Admin UI > Settings > Export collections) and I'll try to investigate further but until then there is nothing much I can help with.

I forgot to mention that custom hooks code could also have impact on the performance, but again without reproducible steps or at least some details it is hard to pinpoint the exact cause.

Thanks for the quick answer!
I could confirm that it wasn't a client-side problem. To clarify: by "the query executed fast" i mean that the sql query for the getList was fast, not the network query. I am using custom hooks, but only triggered on an completely different and unrelated collection. Could that still have an impact.
I have put together a miminal example and would be grateful if you would take a look at it.
Maybe for a general explanation. I am building an event management system in which users can create events, an event then has several lists (e.g. tickets or helpers) and each list has time slots. users can then register in these time slots.
I need the @collection because all persons who are entered in special lists should also see all other entries for this event. this is necessary, for example, so that the "admission helpers" list can check the tickets, etc. The lists that have such a special role are specified in event.privilegedLists.
pb_schema(3).json

I could confirm that it wasn't a client-side problem.

I have no way to verify your findings.

I have put together a miminal example and would be grateful if you would take a look at it.

Where? The above exported json is not enough to reproduce your problem locally. It doesn't contain any information about your custom code, nor details against what collection you are actually executing the request.
If the SQL query executes fast, then I don't see what exactly PocketBase could do result in slow network request in your case.
Couple things based on the provided json:

You don't need the unique constraint for the users.username as there is already existing one created by default because the username is a system field.
In the eventListSlotEntries collection rule if you are comparing a single value against a multiple relation field you need to specify the field (eg. id) you wan tto check, aka<EMAIL_ADDRESS>?= eventListsSlot.eventList.event.privilegedLists

should<EMAIL_ADDRESS>?= eventListsSlot.eventList.event.privilegedLists.id

I'm sorry but this is really frustrating for me and I don't want to deal with this type of constant back-and-forth. I consider it lazy and low effort and I'm not going to invest time on a wild goose chase if the user doesn't want to spend time providing a proper reproducible or at least how many records and what requests they send so that I can try to emulate their setup locally (I don't even understand why do you think this is JS SDK related...).

Thanks for the comments regarding the database schema!
It is by no means my intention to take up too much of your time! I am very grateful for your quick and clear answers.
It is difficult for me to create a reproducible example as the problem seems to occur only in very specific cases. I will try to identify them clearly and then get back to you with an executable example.
many thanks


support.py error on inherited targets with on "core" field

According to https://github.com/mbedmicro/mbed/blob/master/docs/mbed_targets.md the "core" field can be inherited from the parent target.
But if we do that: the tools fail here https://github.com/mbedmicro/mbed/blob/master/tools/data/support.py#L25
Traceback (most recent call last):
  File "/work/linker_hack/mbed-os/core/tools/make.py", line 39, in <module>
    from tools.tests import TESTS, Test, TEST_MAP
  File "/work/linker_hack/mbed-os/core/tools/tests.py", line 18, in <module>
    from tools.data.support import *
  File "/work/linker_hack/mbed-os/core/tools/data/support.py", line 25, in <module>
    if target.core.startswith('Cortex'):
AttributeError: 'NoneType' object has no attribute 'startswith'

Fail how exactly? This behaviour isn't new, core was inherited previously (in the Python version of targets.py).


The cert no longer exists

It seems that Google has ended with this program. Last year I had a scholarship with Google Africa, Andela, and Pluralsight but they told us that "there's no cert this year".

It seems like Google haven't update the page yet, the links are no longer accessible therefore it'd be better to highlight the change on README.md. We can still keep this repo though :)


fieldForLine() with no label by default.

Most of the time, when I want to put a field on a line, I don't want any label.
That is why I suggest to make the fieldForLine() with no label by default.

Is it okay with the new version ?


[FEATURE REQUEST] Allow moving the MRTK settings asset

Describe the problem
MRTK3 is adding visual noise to the Unity Assets root directory by placing its MRTKSettings.asset file in the MRTK.Generated directory. Moving this directory will break building causing an error that no profile has been defined for the current platform. The error is wrong and misleading because MRTK3 expects the MRTKSettings.asset at a specific location in the Assets directory.
Describe the solution you'd like
Previous versions of the MRTK (e.g. MRTK 2.8) had no problem moving the MRTK.Generated directory to a different place. It would be great if you could bring this back.
Describe alternatives you've considered
Moving the directory myself but that causes a build issue.

@keveleigh will investigate addressing this.


Unexpected token . in JSON at position 0

Hello!
The action fails with Unexpected token . in JSON at position 0
JSON is 100% valid (checked with jq)
Is there anything else I can provide to fix the problem?
The workflow step
...

- uses<EMAIL_ADDRESS>  with:
    service-account-json-raw: service_account.json
    package-name: [REDACTED]
    inapp-update-priority: 5
    user-fraction: 1.0

...

service_account.json (edited)
{
  "type": "service_account",
  "project_id": "[REDACTED]",
  "private_key_id": "[REDACTED]",
  "private_key": "[REDACTED]",
  "client_email": "[REDACTED]",
  "client_id": "",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "[REDACTED]"
}

service-account-json-raw takes a string containing JSON text, not a file name. The idea is that you provide the JSON as a secret for your project

service-account-json-raw takes a string containing JSON text, not a file name. The idea is that you provide the JSON as a secret for your project

Ah, now I understand. Thanks for the clarification!
One more question: does this Action provide release notes (like 'whatsNewDirectory' input from r0adkll/upload-google-play)?

I don't think so. Is that something you can/want to configure when promoting releases? I'd imagine your alpha/beta release would already have release notes, which would carry over to the new track

I'd imagine your alpha/beta release would already have release notes, which would carry over to the new track

This is what I need. Will test later. Thanks again!


Bug: Incorrect statement in linear algebra page

Where does the issue happen?
https://learn.qiskit.org/course/ch-appendix/an-introduction-to-linear-algebra-for-quantum-computing
What is the content issue?

The surface of this sphere, along with the inner product between qubit state vectors, is a valid Hilbert space.

But the surface of the Bloch sphere is not a vector space.
Screenshots
No response
Additional information
Brought to our attention via tweet about an SO post.

I believe this is a good first issue. Could I please take this on?

This repository is no longer maintained. It has been superseded by IBM Quantum Learning.


resources: add no mercy in effect id

Just a temporarily solution
Fix #280

No Mercy wasn't the only effect ID impacted, it was just the easiest one to spot check. Looking through just the referenced commit in the linked issue shows WHM's Aquaveil, DRK's Dark Arts, PLD's Holy Sheltron, AST's Macrocosmos, RDM's Magick Barrier, etc etc.

No Mercy wasn't the only effect ID impacted, it was just the easiest one to spot check. Looking through just the referenced commit in the linked issue shows WHM's Aquaveil, DRK's Dark Arts, PLD's Holy Sheltron, AST's Macrocosmos, RDM's Magick Barrier, etc etc.

I remembered, these are all PVP effects added in 6.1... don't know why changed in 6.35 though.

don't know why changed in 6.35 though.

Probably gen_effect_id.ts wasn't run for a while? I'm not sure either, without looking through all the commit logs.

Probably gen_effect_id.ts wasn't run for a while? I'm not sure either, without looking through all the commit logs.

Before that commit is https://github.com/OverlayPlugin/cactbot/commit/75ad0d762e2fae4710f9bc4a9734e19bd406be2f and https://github.com/OverlayPlugin/cactbot/commit/c4ec24f5c4c78f1aaa5233ded48fe638d1ba61be , both created by @Echoring , don't know if it is hand-made.

Before that commit is 75ad0d7 and c4ec24f , both created by @Echoring , don't know if it is hand-made.

Seems indeed manually added, for that time gen_effect_id.ts is temporarily broken.


(MAINTENANCE) create EBE9 event

ticket groups cloned
tickets cloned
ticket groups updated in new tickets
widgets cloned


[BUG] float number error (only on csv, in xls works fine)

Laravel: 5.4.36
Laravel-Excel:2.1.23
some number parse float number error only on export csv

both the result produced with the same code.. ( i also tried to echo the number in my apps and the result is correct 70454.54 )
is this a bug or did i do something wrong for exporting csv ?

I'm also encountering this. The problem appears to come from PHPExcel casting these values to floats internally, which causes this issue for certain values ('70454.54', '957.82 '). (See PHPExcel_Cell_DefaultValueBinder::dataTypeForValue() and PHPExcel_Cell::setValueExplicit().)
I was able to deal with this by using $sheet->setColumnFormat() for the necessary rows:
$this->excel->create('my_csv' . $currentYear, function ($excel) use ($csvRows) {
            $excel->sheet('sheet', function ($sheet) use ($csvRows) {
                $sheet->setColumnFormat(['B:P'=> '0.00']);
                $sheet->fromArray($csvRows);
            });
        })->export('csv');

It appears that $sheet->setColumnFormat() must be called before the data is added to the sheet (i.e., before the fromArray() call here).
Hope that helps!


Validate json schema in function rather than in decorator considering…

… version check

Is this protocol layer now fully compatible with 1.2?


[ANDROID] J2K: Find a Solution for automated "import static" conversion

Problem
Both, Android Studio and IntelliJ IDEA do not convert java import static to a kotlin import.
The resulting code is more verbose, and looses the look&feel of the original java code.
Solutions

Configure the AndroidStudio

see https://github.com/maplibre/maplibre-native/pull/1926#issuecomment-1852640423

As for Google / import .* :
"

https://issuetracker.google.com/issues/205057065
https://doc-26a0-27jg-issuetracker.googleusercontent.com/attachments/kc7eu567pksi0u9a1bnf6bomkfbp1d7c/bv7hgvia7kp5ltr7loa7v6tsv2dqnts4/1702407600000/192750/*/205057065::35378696::192750?q=AN9yeQLCLxWYx6mBKYIi5KRY3rV_ljbWvJfp4bFBfyedp6R7ThSBJAkjJLo8E_R6dzDYmK2bPcSqdIpuBOcNt6-xiQ&download=false
So, changing the configuration to "when at least 500" names used should stop the .* imports during conversion.
"

Alternatives

evaluate/select another conversion tool

Additional Context
This came up during:

#1926

Bounty
(no bounty, handle effort with the root issue)

closing as solve, see Solution

Solution is just a workaround


Microsoft.MachineLearningServices workspaces/computes: missing properties

Resource Type
Microsoft.MachineLearningServices workspaces/computes
Api Version
2022-02-01-preview
Issue Type
Missing property(s)
Other Notes
The objects that vary by ComputeType are missing properties. This issue doesn't exist in 2022-01-01-preview but is present in 2022-02-01-preview and 2022-05-01.
For example, if you look at ComputeInstance in 2022-02-01-preview, you see only ComputeType. However, if you Iook at 2022-01-01-preview, you see a properties object.
If you look at the REST API specification, you see the properties are still present.
Bicep Repro
No response
Confirm

[X] I have searched this repository and have not found similar issue reports.

The root cause for this is that the generator's discriminated union parser assumes a certain pattern in Swagger that Microsoft.MachineLearningServices is no longer following for ComputeType.
Usually, a discriminated union will be expressed using a combination of inherited and inlined properties, with each branch of the union extending a common base type and defining its own properties inline. The parser has a boolean flag (includeBaseProperties) that controls whether inherited properties are included in the generated type, with the assumption being that this would exclude the common base type's properties while still capturing the branch-specific, inline properties. It looks like Microsoft.MachineLearningServices went from inlining branch-specific properties in version 2022-01-01-preview to inheriting them in 2022-02-01-preview.
I believe this issue could be addressed by passing more specific information about which base properties to exclude to the parser, though I will need to do some investigation and testing to make sure that changes effects would be localized to issues like this.


Template declaration and render function priorities

The following problem is common for developers, and I think the information about el in-DOM HTML template and priorities is necessary for them to avoid the problem.
Vue runtime build problem

Thanks!

My pleasure.


I was going through your source code , how you called asynchronous function synchronously in nodejs .

Sorry for duplication


Fix Typo in Dynamic Stackelberg Code

In the process of applying Tom's rewrite to the Julia lectures, I found what I think is a typo in the lecture.
As written, we're checking the dist_vec vector twice, and dist_vec2 zero times.

Thanks @arnavs!
@shizejin , could you please check this?

@arnavs @jstac I think this is a typo and the commitment should fix it!

Makes sense to me.
Thanks guys, nice work @arnavs for finding the error.


feat: Support UK as a synonym for GB country code

ISO 3166-1 Alpha 2 country code for the United Kingdom is "GB" but feed
names use "UK" instead.

@aababilov Which feed names are you referring to, and where are they named? Just trying to understand why this changed is needed, if the feed name is something defined by the person inputting the feed into the validator (as opposed to part of the GTFS feed itself).

@aababilov Which feed names are you referring to, and where are they named? Just trying to understand why this changed is needed, if the feed name is something defined by the person inputting the feed into the validator (as opposed to part of the GTFS feed itself).

All feeds for United Kingdom at Google start from the uk- prefix instead of gb-. I would like to support them out of the box.

All feeds for United Kingdom at Google start from the uk- prefix instead of gb-. I would like to support them out of the box.

I am wondering whether deriving the locale from the feed name is necessarily the most robust way to go about this.
That requires all consumers to name their feeds in the same way, and break in strange and obscure ways if the feed naming pattern is not complied with.
Would it be a better idea to pass the locale explicitly?

I am wondering whether deriving the locale from the feed name is necessarily the most robust way to go about this.
That requires all consumers to name their feeds in the same way, and break in strange and obscure ways if the feed naming pattern is not complied with.
Would it be a better idea to pass the locale explicitly?

Would it be a better idea to pass the locale explicitly?

I agree with @dbabramov on this ☝ - it's a more standardized approach. My concern with the solution in this PR is that we'll be getting all kinds of aliasing and formatting requests to support different naming conventions.
It would also be nice if we could make at least the locale (and maybe name?) parameters optional to simplify things for users. I could see needing to know the locale of feeds upfront potentially problematic for some - I opened an issue for this at https://github.com/MobilityData/gtfs-validator/issues/539.

Would it be a better idea to pass the locale explicitly?

I agree with @dbabramov on this ☝ - it's a more standardized approach. My concern with the solution in this PR is that we'll be getting all kinds of aliasing and formatting requests to support different naming conventions.
It would also be nice if we could make at least the locale (and maybe name?) parameters optional to simplify things for users. I could see needing to know the locale of feeds upfront potentially problematic for some - I opened an issue for this at https://github.com/MobilityData/gtfs-validator/issues/539.

Actually, looking into this more for uk, it looks like ISO does recognize this officially as an alias for gb:
https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Exceptional_reservations
So we'd still be within the ISO spec for this PR implementation.
I propose we merge this PR and then separate the country code from the feed name in a new PR.
@aababilov @dbabramov thoughts?

Actually, looking into this more for uk, it looks like ISO does recognize this officially as an alias for gb:
https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Exceptional_reservations
So we'd still be within the ISO spec for this PR implementation.
I propose we merge this PR and then separate the country code from the feed name in a new PR.
@aababilov @dbabramov thoughts?

I agree to pass the country code to the validator because feed names are too Google-specific. Let's merge this PR for now to unblock me and I will prepare another one.

I agree to pass the country code to the validator because feed names are too Google-specific. Let's merge this PR for now to unblock me and I will prepare another one.

Hmmm, I'm not sure why the CI build is failing again:

org.mobilitydata.gtfsvalidator.cli.CliParametersAnalyzerTest > provideStorageDirectoryCliParameterWithoutSpecifyingUrlShouldReturnFalse FAILED
org.mockito.exceptions.verification.WantedButNotInvoked at CliParametersAnalyzerTest.java:113

It passed locally for me via gradle command line and within IntelliJ.
I'm going to go ahead and merge because it's unrelated to this PR. We'll see if it passes after that and if not open an issue.

Hmmm, I'm not sure why the CI build is failing again:

org.mobilitydata.gtfsvalidator.cli.CliParametersAnalyzerTest > provideStorageDirectoryCliParameterWithoutSpecifyingUrlShouldReturnFalse FAILED
org.mockito.exceptions.verification.WantedButNotInvoked at CliParametersAnalyzerTest.java:113

It passed locally for me via gradle command line and within IntelliJ.
I'm going to go ahead and merge because it's unrelated to this PR. We'll see if it passes after that and if not open an issue.

Huh...passes fine in the master branch 🤷:
https://github.com/MobilityData/gtfs-validator/runs/1665054412

Huh...passes fine in the master branch 🤷:
https://github.com/MobilityData/gtfs-validator/runs/1665054412


Add PS 7 to UseCompatibleSyntax

PR Summary
Adds PS 7 recognition to UseCompatibleSyntax
PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[x] Change is not breaking
[x] Make sure all .cs, .ps1 and .psm1 files have the correct copyright header
[x] Make sure you've added a new test if existing tests do not effectively test the code changed and/or updated documentation
[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.

Well the minimum version doesn't solve all issues; some syntaxes only work below or in a certain version of PowerShell, like workflow and parallel.
Perhaps we need a nicer data structure to deal with version checks (which can deal with only specifying a major version or not)

@rjmholt It seems because the PR got merged a long time after the last PR build that there is an integration tests failure as there are 4 failing tests in master since this merge. Can you please open a PR with a fix for it?

@JamesWTruher and I looked into this yesterday for a while. We weren't able to reproduce it on the 16.04 Docker image, but I feel I have before when I investigated it (I feel like I wrote it in an issue somewhere, but can't find it). Anyway, this is on my list for next week, so I'll keep trying then.

Yes, the fact that some of your tests fail on Ubuntu16 on AppVeyor now as well, really makes me think we either have to find the root cause and fix them or declare technical debt and ignore them on Linux only. The problem on a higher level is that similar tests fail on Ubuntu in Azure DevOps and are a blocker for moving to Azure DevOps. Azure DevOps would give us much faster builds due to free parallelism (Microsoft stopped paying for AppVeyor a few months ago and is on the free plan  now) and also add Mac to the tested platforms. How essential are those few test cases? Having them work at least on Mac is good enough IMHO if the amount of effort seems to be an unknown black hole.

Those tests aren't essential at all in my opinion; they aren't substantially different from the other tests (just added coverage) and we can't repro them. So if they're a blocker we can disable or remove them to get you unblocked while I investigate the cause.


#1633 - Random https port in annotation AutoConfigureWireMock is broken issue

Random https port in annotation AutoConfigureWireMock is broken issue - fix

@GodwinMaravai Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@GodwinMaravai Thank you for signing the Contributor License Agreement!

Congrats @GodwinMaravai on your first contribution :)

This seems to have broken the prior behavior in which AutoConfigureWireMock is used with the default settings: it now configures a random httpsPort and calling WiremockServer::baseUrl() now returns an https url.

Can you create an issue with a test that currently breaks?

I spent a while debugging the failed tests, even though I had a few workarounds that made it work.
What's happening is that the failing test class is annotated with @RestClientTest along with @AutoConfigureMockRestServiceServer(enabled = false) to suppress the creation of spring's MockRestServiceServer.
This triggers the application lifecycle event handled by org.springframework.cloud.contract.wiremock.WireMockApplicationListener before @AutoConfigureWireMock is initialized and it registers dynamic http & https ports.
If you then try to configure your client's RestTemplate with the WireMockServer's baseUrl, you'll get an https://localhost:xxxxx url:
    @TestConfiguration(proxyBeanMethods = false)
    static class AdditionalConfig {

        @Bean
        // Allow WireMockServer to be created and started
        @Lazy
        RestTemplateCustomizer customizer(WireMockServer server) {
            return restTemplate -> RootUriTemplateHandler.addTo(restTemplate, server.baseUrl());
        }
    }

This actually fails the test only if you don't use Apache's HttpClient as the RestTemplate's internal http client since when using Apache, the RestTemplate is customized with a TrustSelfSignedStrategy and a NoopHostnameVerifier.
And indeed I'm using OkHttp's client.


Getting Started section added

Explaining how to generate a GitHub Personal Access Token and add it to the ColdBox config settings.

Thanks, @richardherbert!  I have a couple notes.

It's probably not best to point people to edit a ModuleConfig.cfc file.  If cbgithub is updated, any changes to this file by the use will be lost.  I think we take out that section and just leave in the section about the config/ColdBox.cfc file.

I think we name this section Getting Started with Personal Access Tokens.  Besides personal access tokens, you could choose to use an oauth token granted to you.  This would be one of the cases where you would pass in the tokens to the functions instead of using the settings.  For those reasons, I think that we can be more specific here with your guide and leave room the oauth section for later.

Other than that, looks good!  Thank you!

I've not worked on a ColdBox Module before or used the oAuth features of cfgithub yet so all those points are valid.
May I suggest that we keep the Getting Started section but add a sub heading of Personal Access Tokens so that other getting started sections could be added?
I'll get onto this and raise a new PR.


test share mutex abort in gcc 4.8.4

when compiling test_shared_mutex use gcc 4.8.4 on ubuntu, it will abort with following error message
Testing exclusive locking ...
terminate called after throwing an instance of 'std::system_error'
  what():  Enable multithreading to use std::thread: Operation not permitted
[1]    30666 abort (core dumped)  ./bin/test_shared_mutex

This is similar to https://stackoverflow.com/questions/19463602/compiling-multithread-code-with-g
and can be fixed by add a line in CMakeLists.txt
SET( CMAKE_EXE_LINKER_FLAGS  "-Wl,--no-as-needed ${CMAKE_EXE_LINKER_FLAGS}")

Can you make the modification and test it with gcc 4.8.4? I can merge the PR if this is confirmed to work, as I don't have gcc 4.8.4 at hand.

done in #9


Improve error handling in commands

Cobra, the CLI commander in use in Hugo, has some long awaited improvements in the error handling department.
This enables a more centralized error handling approach.
This commit introduces that by changing all the command funcs to RunE:

The core part of the error logging, usage logging and os.Exit(-1) is now performed in one place and that one place only.
The usage text is now only shown on invalid arguments etc. (user errors)

Fixes #1502

Looks good to me.  Glad to see this error-handling clean-up.  :+1:
Merged as 3f0f7ee.


Set taskbar on right or left of screen

On wide-screen displays I like to maximize my vertical real estate by moving launcher/taskbars to the right or left of the screen. I'd like to see this option in the taskbar placement, rather than just top or bottom.

https://github.com/cairoshell/cairoshell/issues/602#issue-931099943