$using variable should support method call on it

$using: prefixed variables are used in Foreach-Object -Parallel and Start-ThreadJob to pass value of reference types. Given the value is passed by reference, it's natural to call method on it directly in a thread job or script running in another Runspace, and thus we should remove the semantics check and allow expression to be used on the $using: variable.
Steps to reproduce
{ $using:blah.Add() }

Expected behavior
No error thrown.
Actual behavior
PS> { $using:blah.Add() }
At line:1 char:3
+ { $using:blah.Add() }
+   ~~~~~~~~~~~~~~~~~
Expression is not allowed in a Using expression.
+ CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : InvalidUsingExpression

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.0-preview.4
PSEdition                      Core
GitCommitId                    7.0.0-preview.4
OS                             Microsoft Windows 10.0.18363
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Related: #10499
Depending on exactly what's preventing the current use of methods with $using: (is it a deliberate constraint applied manually? Plumbing not entirely hooked up?)  We may want to implement this alongside changing $using in threadjob/foreach -parallel to $ref:
That is, if the committee agrees with that change when it is reviewed :smile:

There are places where Using can't provide methods (remoting, DSC)
But this is silly
$hash = @{a=1;b=2;c=3}
"a".."z" | foreach -Parallel {$using:hash[[string]$_]}
ParserError:
Line |
   1 | "a".."z" | foreach -Parallel {$using:hash[[string]$_]}
     |                                           ^ Expression is not allowed in a Using expression.

especially as
"a".."z" | foreach -Parallel {$h=$using:hash; $h[[string]$_]}
works.
This would be a good change but it should be made clear somewhere what works and what does not.  This fails
$x=1; 1..5 | foreach -Parallel {$using:x += $_}
because $using:x gives a read only variable. So a method which changes X should only change the copy in the parallel runspace. If users expect to change the copy in the calling workspace that will cause problems.

Honestly given the current strictures of $using, I would think in makes more sense for #10499 to be reconsidered and a different prefix chosen, both to avoid complicating the code paths in the parser for $using (how is the parser meant to differentiate $using restrictions in the different scenarios? That makes little sense to me), and to have it be clear to users.
If they get a parse error for applying indexing or property access to $using now, I don't think making that parse error somehow conditional based on what command it's being passed to is a good user experience at all. What about creating and sharing scriptblocks ahead of time? There's no meaningful way to make the distinction in the parser.
Different prefixes kind of have to be used here, or we have to offload the error states to the individual commands, which leaves us much more open to even more variant, confusing, and inconsistent behaviours.
Not great UX at all in my opinion.

I have struggled to get my head round this, but this may help others.
#10499  basically says "using in foreach-object -parallel is dangerous"
What we have here is the parser blocking those dangerous operations - where they are can be seen.
$x = 1 ; 1..5 | foreach -Parallel {$using:x += $_}
Gives an error " The assignment expression is not valid. The input to an assignment operator must be an object that is able to accept assignments"
$hash = @{a=1;b=2;c=3}; "a".."z" | foreach -Parallel {$using:hash[[string]$_]}
Gives an error "Expression is not allowed in a Using expression"  as does
$hash = @{a=1;b=2;c=3}; "a".."z" | foreach -Parallel {$using:hash.ContainsKey([string]$_)}
However one can hide the unsafe behaviour
$hash = @{a=1;b=2;c=3}; "d".."f" | foreach -Parallel {
    $p = $using:hash.psobject ;
    $p.baseobject.add($_,"99")
}
$hash
Name                           Value
----                           -----
e                              99
d                              99
a                              1
b                              2
c                              3
f                              99

This doesn't work for simple types like strings and integers.
So we have two requests, one here which says make it easier to do things which are not thread-safe, and #10499 - I'm not sure if it is saying block non-thread safe things completely or ensure that people can't do something unsafe by accident - the parser is doing the latter.
Having a different prefix, say $ref: , would make it clearer that it is a thread-unsafe reference; but you can be sure than some users will just accept "$ref" as "what you use to do this" and will get themselves into trouble....
With $using: you can call baseobject.add() or use baseobject["b"] , it is cumbersome but can't be done by accident
I don't think every argument for one way or the other has a roughly equal counter argument

@jhoneill the latter parts of the discussion in #10499 make it more clear that a $ref: keyword rather than $using: was indeed the desired outcome, my apologies for not making that clear.
$ref: isn't a perfect solution, but frankly I don't think one really exists. It makes it clear that "hey, this is a different thing you're working with here! watch out!", it calls back to the existing [ref] that is occasionally useful, and if $using: is ignored or creates errors in threadjobs / foreach -parallel that point to using $ref: instead users know exactly what to search for to better understand what's going on.
There will always be users who don't fully comprehend what they're doing; I think the onus is on us to make it clear that these two usages are different in a pretty important way, and whether users seek to understand it before using it is then up to them. Hiding the difference by simply modifying the existing behaviour of $using: is, in my opinion, doing users a disservice. It doesn't give them a good avenue to explore and further understand.

The quickest workaround for calling methods is to enclose the reference in (...):
PS> $ht = @{ one=1 }; % -parallel { ($using:ht).Add('two', 2) }; $ht

Name                           Value
----                           -----
one                            1
two                            2

I think the confusion stems from thinking of $using:var as a variable reference, when it reality is a variable's value.
PowerShell - unlike Bash, for instance - doesn't normally make that distinction: in $var = ...,  $var is a variable (object) whose value is being modified, whereas in Write-Output $var it is the variable's value.
$using:var is only ever a value, methinks - that's why you can't assign to it or increment it - even though its syntactic form may make you think you can.
Whether the value $using:var is something that is mutable therefore entirely depends on whether $var in the caller's context happens to contain an instance of a reference type.
These are the same by-[reference]-value passing semantics as when you call a script or function (except that nothing prevents you from assigning to a parameter variable later): if the parameter value is a value-type instance, you get a copy, if it's a reference-type instance, you get a copy of the reference - and therefore the potential for modifying the referenced object.
Therefore, I don't think $ref: is appropriate (potential confusion with [ref], which is a fundamentally different thing) or necessary.
I can't think of a prefix that could capture the complexity of the above.
However, we do have to properly document the issue.
And, back  to @daxian-dbw's original issue, there's no reason not to allow method calls directly on $using: "variables", especially given that property access already works (and that member access generally works on values (literals) too; e.g., 'foo'.ToUpper()):
PS> $ht = @{ one=1 }; % -parallel { $using:ht.count }

1

@mklement0 $using: is currently a reference when used in Start-ThreadJob or ForEach-Object -Parallel scriptblocks.
😕

@vexx32:
These terms are not mutually exclusive:

$using:var is the value of variable $var from the caller's scope
That value can be a reference  - namely if the caller's variable contains an instance of a reference type.

This applies to any function/script call in PowerShell - even though the syntax is different here, the concept is the same:
# Same example as above, only with a local script-block call:
PS> $ht = @{ one=1 }; & { param($htParam) $htParam.Add('two', 2) } $ht; $ht

Name                           Value
----                           -----
one                            1
two                            2
---

Again, this is unrelated to [ref], where you essentially pass a value holder (variable-like object) around.

Yes, in the context of Start-ThreadJob and ForEach-Object -Parallel this presents a thread-safety challenge that by definition cannot exist in the different-process based contexts where $using: is also supported (Start-Job, remoting).
That challenge is already documented in https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/foreach-object?view=powershell-7
Despite the context-specific differences, in all these contexts $using: refers to a value from the caller's scope, so it makes sense to use the same syntax form, and, as stated, I couldn't think of a prefix that captures the subtleties of the above without obscuring this commonality and causing further confusion.

@mklement0

$using:var is the value of variable $var from the caller's scope
That value can be a reference  - namely if the caller's variable contains an instance of a reference type.

That's not what happens in foreach-object -parallel
Quick demo
$hash = @{"a"=1}
Invoke-Command -ScriptBlock {$using:hash}    causes an error
A Using variable cannot be retrieved. ...  When it is used with Invoke-Command, the Using variable is valid only if the script block is invoked on a remote computer.
This works
Invoke-Command -ScriptBlock {$using:hash} -ComputerName localhost -EnableNetworkAccess

Name                           Value
----                           -----
a                              1

Can we change the contents ? And does that change the content of source variable. ?
Invoke-Command -ScriptBlock {($using:hash).add("B",2) ; $using:hash } -ComputerName localhost -EnableNetworkAccess

Name                           Value
----                           -----
a                              1
B                              2

$hash

Name                           Value
----                           -----
a                              1

The "remote" machine can't write back to the original - it's Call-by-value behavior.
Now take the same script block and run it with foreach-object -parallel
1,2 | ForEach-Object -Parallel {($using:hash).add("B",2) ; $using:hash }

Name                           Value
----                           -----
B                              2
a                              1
MethodInvocationException: Exception calling "Add" with "2" argument(s):
"Item has already been added. Key in dictionary: 'B'  Key being added: 'B'"
B                              2
a                              1

We got an error because one thread job sees the modification made by the other.
$hash

Name                           Value
----                           -----
B                              2
a                              1

The value in the callers scope has changed. This is call-by-reference behavior.
@PaulHigin  explained it in post here.
https://devblogs.microsoft.com/powershell/powershell-foreach-object-parallel-feature/

there is a big difference when using the $using: keyword in ForEach-Object -Parallel. And that is for remoting, the variable being passed is a copy sent over the remoting connection. But with ForEach-Object -Parallel, the actual object reference is being passed from one script to another, violating normal isolation restrictions.

That's what we see here : the parallel runspaces have read/write access to a variable in the calling runspace. There might be some implementation oddity which means it is not truly call-by-reference, but using the "if it walks like a duck and quacks like a duck then just call it a duck" logic,  that's how I'd describe it.
@vexx32  Agree. I think as things are, there is a bit of "jumping through hoops" with using: as it is, that means you don't accidentally get unsafe behaviour. I keep meaning to look at synchronized hash tables and other things which designed for thread safety

@jhoneill:
None of what you state contradicts my explanation, except for fuzzy terminology that may explain why you think there is a disagreement (see below).
Yes, there is a thread-safety issue that is unique to ForEach-Object -Parallel and Start-ThreadJob (though given that you need to start each thread individually, it's probably less likely to surface there in practice).
To recap my argument:

$using:, across all uses cases, has the commonality of referring to the value of a variable from the caller's scope (whether that value is a value-type instance or a reference-type instance), which is why it makes sense to use the same syntax form in all cases:

In the remoting / background scenarios, that value is is always a fully independent copy of the object that the value refers to, so there is no concern about concurrent access; note that this copy is an imperfect copy in many scenarios, because serialization / deserialization is involved, where only a handful of types are deserialized with type fidelity.

In the ForEach-Object -Parallel / Start-ThreadJob scenarios, the very same object reference is passed to the threads if the caller's variable contains a reference-type instance - and that's where you need to ensure thread safety if you're modifying the object being referenced.

The thread-safety pitfall requires documenting  - it already is documented in the ForEach-Object topic; it wouldn't hurt to mention it in Start-ThreadJob too.

As for your examples:
$using: variables only apply in remoting / job contexts, that's why Invoke-Command without -ComputerName doesn't support them - just as it isn't supported in directly invoked script blocks (& { $using:HOME }  breaks, for instance)

And does that change the content of source variable. ?

Here's where it gets fuzzy: It isn't the content of the source variable that is changed, at least not in the sense that a different value is now stored in it - the latter is impossible in this scenario.
What changes is the object that the unchanged variable-content references.

This is call-by-reference behavior.

As argued before, it is by-reference behavior in the same sense as passing any reference-type instance to a script/function passes a copy of the reference.
This is fundamental PowerShell / .NET behavior that is to be expected, and needs to be understood generally, in all contexts where you pass parameters in-process.
To recap my previous example:
PS> $ht = @{one=1}; & { param($htParam) $htParam.Add('two', 2) } $ht; $ht

Name                           Value
----                           -----
one                            1
two                            2

$htParam received a reference to the same hashtable instance that $ht references.
Technically, this is still passing by value in that a copy of the $ht variable's value is passed.

If $ht contained a value-type instance, $htParam would indeed receive a copy of its data, because the variable value is the data.
If $ht contains a reference-type instance, as in this case, $htParam receives  a copy of its reference, which, of course, points to the very same object.

So, in effect, what is technically by-value passing is situationally "object-pointer passing" - as in C/C++, except that the fact is more obvious there.
The type of by-value semantics that you have in mind - always passing an independent copy of the data  - are de facto impossible to achieve.

It would require a generic deep-cloning mechanism that works with any data type - and there is no such thing.

Hence the imperfect approximation of deep-cloning in cross-process scenarios (remoting, background jobs), where passing a copy of the data is a necessity.

Even if that were an option, It would be impractical - at least as the default behavior - due to the potentially large performance penalty incurred by cloning.

All this back and forth only seems to perfectly illustrate the exact reason that we should separate the two types of $using: behaviour, to me.
The confusion and lengthy discussions are already present, and a few notes in documentation are unlikely to be sufficient to properly illustrate the differences, in my view. 🙂

My conclusion is different:

If you want to use remoting / background jobs / thread jobs / parallel foreach-object properly, there is no way around understanding the underlying concepts - documentation should do its best to explain them.

The way this discussion unfolded suggests to me that needing to understand the fundamentals of parameter passing is the  primary problem, which goes deeper than the ForEach-Object -Parallel / Start-ThreadJob issue at hand.

Given how fundamentally the value-type/reference-type dichotomy impacts by-value parameter passing (which $using: in essence is), it is more than a technicality. I get that it's conceptually tricky, but there's no way around needing to understand it.

No different prefix name such as $ref: can compensate for that:

Generally, it obscures the underlying commonality that $using: represents: passing a value from the caller's scope and requires you to memorize another syntax.

Hypothetically, if $using: also worked, with copy-data-always behavior, there would be a useful distinction, but the only way to get that would be to employ serialization / deserialization (as in the cross-process scenarios), which, apart from the loss of type fidelity, would defeat the purpose of using thread-based concurrency due to the overhead involved.

Specifically, $ref: may mistakenly suggest that you can pass value-type instances by reference too; that is, it may more explicitly promote the misconception that $ref:var is a variable rather than a value.

Pragmatically speaking, the issue only arises:

if a $using: reference expands to a reference-type instance

and you're modifying that instance in-place.

It is only then that you need to be aware of the thread-safety issue, and an explanation of the issue in the ForEach-Object topic  (already present, along with showing how to solve the problem with System.Collections.Concurrent data types) and the Start-ThreadJob topic (to be added) should suffice.
I suppose we should also document the complementary solution: wanting to work with thread-local clones of $using: values; e.g.:
# OK, because thread-local clones of the hashtable are being modified.
PS> $ht = @{one=1}; 1..2 | % -parallel { $ht = ($using:ht).Clone(); $ht.Add('two', 2); $ht }

Name                           Value
----                           -----
one                            1
two                            2
one                            1
two                            2

[hashtable] conveniently offers - shallow - cloning, but in general you'll face the usual cloning challenges.

🤔 Fair points.
I dislike the confusion that is more or less inevitable here, but you're right in that $ref: will create its own misconceptions. 🤷♂
Appreciate you taking the time to lay it all out! 💖

@mklement0
I'll let you argue with @BrucePay , see https://github.com/PowerShell/PowerShell/issues/10499#issuecomment-529691685

while the rest of PowerShell passes variables by value.

This is not actually correct. In fact, PowerShell always passes by reference both with reference types and boxed value types.

I understand what you are saying; after executing $ht = @{one=1}; leaves $ht as a pointer to a hash table, not the hash table itself; Passing a copy of that pointer (call-by-value) gives behavior which looks like call-by-reference because the original pointer and the copy both point to the same data (it's like being back in 1st year computer science, 35 years ago :-) ) . It's just that the guy who implemented it says it doesn't do that.
Using: is restricted to certain places. In remoting or DSC "pointed to" data is expanded, because sending a pointer to a remote machine or writing it to a MOF file won't be helpful.
In foreach-object -parallel it's a "live" pointer. It's a moot point whether that live pointer is the original one or a copy...
The point being made in #10499 a writer not realizing this using giving live pointers in one place could be dangerous and the point here this variables from outside the script block should act like any other scriptblock referring to its parent scope.  One solution, which doesn't tie the parser in knots is to use another label. The other is to say that making use of the live pointer is not onerous but sufficient to make it clear that you are doing it.

@jhoneill:

variables from outside the script block should act like any other scriptblock referring to its parent scope

They behave the same as in the parameter-passing / thread-based $using: scenario: if the parent scope's variable value happens to be an instance of a reference type, you can modify the object being referenced (whereas if you assigned to $ht you'd create an independent local variable):
$ht = @{ one = 1 }; & { $ht.one = 2 }; $ht

Name                           Value
----                           -----
one                            2

making use of the live pointer is not onerous

It's only onerous (treacherous, counterintuitive) if the underpinnings aren't understood - hence the need for documenting the potential pitfalls.

On the flip side, the thread-based behavior is a feature  if you actively take advantage of it: it enables collaborative cross-thread population of a data structure - if you understand that it is your responsibility to ensure thread safety (synchronize access to the data structure).
This option is not available in cross-process $using: scenarios (remoting, background jobs, DSC).

Also note that users who are accustomed to $using: in the context of remoting / background jobs / DSC probably don't expect - and certainly shouldn't - to be able to directly modify values in the caller's scope.
It is only if they happen to pass $using: values that (a) are reference-type instances and (b) are mutable and (c) in-place mutation methods are actually called that the behavior would change in the thread-based scenarios.
Again: A different namespace prefix is incapable of conveying these subtle differences while obscuring the commonalities and increasing developers' memory burden.

@jhoneill: As for the quote from https://github.com/PowerShell/PowerShell/issues/10499#issuecomment-529691685:
That PowerShell uses boxing (wrapping value-type instances in a reference-type instance) behind the scenes is irrelevant to the effective behavior in PowerShell code:
PS> $i = 1; & { param($intParam) ++$intParam } $i; $i

1  # The value-type instance stored in the caller's $i variable was NOT modified.

C# - sensibly - employs the same logic (you can paste the code directly at a dotnet-script prompt):
> class Foo { public static void Bar(object i) { i = 2; } }; var i = 1; Foo.Bar(i); i

1  // Despite boxing, the value-type instance stored in the caller's i variable was NOT modified.

@jhoneill: As for the quote from #10499 (comment):
That PowerShell uses boxing (wrapping value-type instances in a reference-type instance) behind the scenes is irrelevant to the effective behavior in PowerShell code:

Look, you can argue with Bruce if you want to :-) The OP talks about it as by reference, and   @PaulHigin 's post talks about parallel being different from other using, being by reference.

PS> $i = 1; & { param($intParam) ++$intParam } $i; $i

1  # The value-type instance stored in the caller's $i variable was NOT modified.

++ $x does $x=$x+1 ,it doesn't call an increment() method. You said yourself  in the previous post

you can modify the object being referenced (whereas if you assigned to $ht you'd create an independent local variable

then

[requestor wants] variables from outside the script block should act like any other scriptblock referring to its parent scope

They behave the same as in the parameter-passing / thread-based $using: scenario:

I thought we had established using with parallel can change the variable in the calling scope (unlike remoting) but method calls don't work unless the passed variable is wrapped in () unlike a script block  -from  the initial post.

$using: prefixed variables are used in Foreach-Object -Parallel and Start-ThreadJob to pass value of reference types. Given the value is passed by reference, it's natural to call method on it directly in a thread job or script running in another Runspace, and thus we should remove the semantics check and allow expression to be used on the $using: variable.
Steps to reproduce
{ $using:blah.Add() }

i.e he doesn't want to write {($using:blah).add() }

making use of the live pointer is not onerous

It's only onerous (treacherous, counterintuitive)

Sorry I was using it in the sense of "excessively work"

Also note that users who are accustomed to $using: in the context of remoting / background jobs / DSC probably don't expect - and certainly shouldn't - to be able to directly modify values in the caller's scope.

This is what was being said in #10499 . And you say users shouldn't be able to modify values in the caller's scope.. Most people would say after this :
>$ht = @{"Value"=999} ;   $ht.value is a value in the current scope . So then ...  > 1..3 | foreach -Parallel {start-sleep -Milliseconds (get-random 1000); ($using:ht).value = $_}`
ensures the last thread to try to change $ht.value is random.
Back in the parent scope it has changed
$ht

Name                           Value
----                           -----
Value                          2

The OP talks about it as by reference, and @PaulHigin 's post talks about parallel being different from other using, being by reference.

Yes. Everything that needs to be said about this has been said.

++ $x does $x=$x+1 ,it doesn't call an increment() method. You said yourself in the previous post

The point of the example was that you can't modify value-type instances in this scenario - whether or not they have mutating methods (which is rare to begin with):
# Define a value type with a mutating method.
Add-Type 'public struct Foo {  public int Value { get; private set; } public void Increment() { ++Value; } }'

$foo = [Foo]::new()
$foo.Increment()  # $foo.Value is now 1

# Passing the value type as a parameter value passes a *data copy* to the
# script block, so any mutating methods invoked on that copy only affect *that copy*.
& { param($fooParam) $fooParam.Increment() } $foo

$foo.Value # still 1

I thought we had established using with parallel can change the variable in the calling scope (unlike remoting) but method calls don't work unless the passed variable is wrapped in ()
i.e he doesn't want to write {($using:blah).add() }

Yes. And I agree that (...) shouldn't be required. Why do you mention that?

Sorry I was using it in the sense of "excessively work"

I'm confused:
Using a "live pointer" is the opposite of excessive work - no cloning / serialization+deserialization overhead required.

And you say users shouldn't be able to modify values in the caller's scope...

I didn't say that, and I didn't mean to (though I certainly think it should be a deliberate action).
Why do you think I did?

Back in the parent scope it has changed

Indeed, as has been amply discussed - including the scenario where that can be used as a feature.
Why do you mention that?

OK....  We have two competing requests. This one which says accessing a method of a using variable should impose less work on the author. And 10499 which says using  is already too easy for an author to change something in a different runspace, meaning that accidental modification can occur. Their wishes for using are mutually exclusive. IF one wants to satisfy both, changing the label from using  to something else (ref has been mooted), might allay the fear of someone writing using with the wrong expectation and could make life easier for authors while avoiding the need for the parser to identify different contextual behaviors allowed for using

I thought we had established using with parallel can change the variable in the calling scope (unlike remoting) but method calls don't work unless the passed variable is wrapped in ()
i.e he doesn't want to write {($using:blah).add() }

Yes. And I agree that (...) shouldn't be required. Why do you mention that?

Right; we all know what can be observed with PowerShell as it is now. And I don't think I'm misrepresenting anything to say in a  "Make it easier" vs "Already dangerously easy"  debate you and the OP in this issue would be inclined towards the former. I'm not strongly for or against either of them. Nor am I convinced that the label should be changed in an attempt to satisfy both. I think the present position is OK, but in an uncommitted and agnostic way :-)

Sorry I was using it in the sense of "excessively work"

I'm confused:
Using a "live pointer" is the opposite of excessive work - no cloning / serialization+deserialization overhead required.

What I tried to say was this; making a script author write ($using:something).method does impose requirements (knowing the needs for () and inserting them) but not excessively so [in my view]. The extra work makes it deliberate and reduces the risk of accidental modification to [what I think is] an acceptable level but not to zero.

And you say users shouldn't be able to modify values in the caller's scope...

I didn't say that, and I didn't mean to (though I certainly think it should be a deliberate action).
Why do you think I did?

I may have misunderstood / lost the context in quoting what you said 3 paragraphs from the bottom of https://github.com/PowerShell/PowerShell/issues/10876#issuecomment-546532279
It doesn't matter whether you misspoke or I misunderstood, it's clear now (I think)

Back in the parent scope it has changed

Indeed, as has been amply discussed - including the scenario where that can be used as a feature.
Why do you mention that?

Because I lost track of what you were saying should or should not be possible. Can we park that since I we agree that it is indeed a feature ?  The question is

Is this feature, as is, a trap, and something which should be made harder and/or blocked (issue #10499) OR
Is this feature a benefit, but too hard too use as is, and should be made accessible (this issue) OR
Does this feature, as-is impose, enough extra work to avoid being a trap; without becoming a burden on those wanting to use it.

I'm inclined towards 3 which is the status quo; nothing said for either of the others (so far) has convinced me of their case - in my view both have equal and opposite merit.

I see this issue and #10499 as unrelated:

#10499: For all the reasons discussed here, I don't think any action is required to address #10499: $using: in thread-based contexts is a potential feature as much as a potential pitfall; you need to understand the ramifications, as documented.

Introducing a separate prefix doesn't replace the need to understand and cannot inspire that understanding, while, conversely, obscuring common functionality and increasing developers' memory burden.

So: yes to 2.

There was never a good reason syntactic reason to require (...) around a $using: reference; $using:var.property already works, making $using:var.method() work amounts to simply removing an inconsistency.

That said, assigning to $using:var.property does not work, and should be allowed as well; the following currently breaks:
[pscustomobject] $o = @{ one = 1 }; % -parallel { $using:o.one = 2 }; $o

The - non-obvious - workaround is again to use (...)
[pscustomobject] $o = @{ one = 1 }; % -parallel { ($using:o).one = 2 }; $o

Re 3.:
I generally think it's not a good idea to encumber the syntax in order to prevent pitfalls (see #6551, for instance); it is of necessity arbitrary and therefore:

makes it non-obvious - I had to experiment to find the (...) workarounds.

ends up burdening proper use of a given feature as well.

While it ultimately doesn't matter, I suspect that the current inability to call methods directly on $using: references was not a deliberate feature; after all:

It was implemented before thread-based jobs / parallel foreach-object, and in the older scenarios the pitfall never presented itself, so there wouldn't have been a need to erect a syntactic barrier.

The current barrier is inconsistent in that (get-only) property access works as-is, without (...)

The only required barrier here is one of necessity: attempts to assign directly to a $using: "variable" (which isn't one, despite its syntactic form - but this ambiguity is at the heart of PowerShell) - $using:var = ... - must be prevented (which already happens), but there is certainly room for improvement in the current error message, which is too general for this specific case:
Current, general error message:

The assignment expression is not valid.
The input to an assignment operator must be an object that is able to accept assignments, such as a variable or a property.

In the case of attempting to assign to a $using: reference, I suggest emitting a specific error, along the lines of:

The assignment expression is not valid.
$using: references are values, not variables, so they cannot be assigned to.

@mklement0
I'm starting to come round to your view :-)   I think #10499 is connected but the danger is overstated...  so no action required.
Using in a remoting scenario serializes and de-serializes objects, so in a lot of cases the method is lost.   In something like this
$p = start notepad -PassThru
Invoke-Command -ComputerName localhost -EnableNetworkAccess -ScriptBlock {$using:p.GetHashCode() | gm }

The parser error is stopping me from trying to call a method which won't exist (and wouldn't make sense).
But if I pass a hash table (for example) the deserialized object does have an add() method and brackets let me say "I know what I'm doing , it's OK to call this method"  get-help about_remote_variables doesn't give this information, so there is a discovery problem
Using  in DSC does writes  $VariableName = <<present value of variable>> to the MOF file and converts all instances of $using: to $ after that. Some roll-your-own serialization is needed in my experience.
Using in a threadjob scenario (with Start-threadjob or foreach-object parallel has the parser behavior for remoting but is accessing the original content without serialization.
Start-threadjob -ScriptBlock {$using:p.kill() }
gives the parser error and again brackets let me say "I know what I'm doing , it's OK to call this method".
In this instance  $using:p.kill() would work, the parser is just requiring authors to demonstrate that they know what they are doing.  I still don't think that's excessive, but (as with remoting) there is a discovery problem.
How easy it is to have one parser behaviour in one place and another somewhere else I don't know.   That's not a reason for opt not to do it, but might mean it's thought to be a good idea but not done.

Glad to hear it, @jhoneill.
Yes, only a handful of known types deserialize with type fidelity in remoting / background jobs; all others are emulated with method-less [pscustomobject] instances.
(#10916 seems to want to change that selectively, which sounds quite challenging.)
As an aside: While that fact is specified in the MS-PRSP protocol specification, there's virtually no information in the end-user documentation (about_Remote_Output, about_Remote_Variables).
For all the reasons previously discussed, my preference is not to erect syntax barriers, especially not selectively - documentation should suffice.
$using:var should be treated like any other expression, on which members can be directly accessed ($using:var.Prop, $using:var.Method()).
As for how likely it is that users will encounter the pitfall: Since methods are often lost  in cross-process parallelism due to deserialization, there may not even be an expectation of being able to call methods - anecdotally, the vast majority of remoting / background-job commands I've seen on Stack Overflow simply pass values that are accessed as-is (no method calls, rarely property access).
So that means that only the following users are affected: Those who actively use not only methods on deserialized objects, but specifically mutating methods and who expect such mutations to be confined to an independent copy of the caller's value.

Finally, let me offer a way through the conceptual fog of by-value vs. by-reference:

The terms by-value vs. by-reference are data holder (container) concepts:

They indicate whether a data holder's data is passed to a function/command or, loosely speaking, the data holder itself, making direct manipulation of the data holder's data by the callee possible.

In that sense, PowerShell (and C#) always pass by value - unless you explicitly opt into a by-reference approach with [ref] (ref, out).

Separately, data in .NET comes in two flavors:

value-type instances, whose content itself is directly stored in data holders; a given value-type instance can never be indirectly referenced: accessing  a data holder's data that is a value-type instance means invariably getting a copy of that data.

reference-type instances, only a reference ("pointer") to which is stored in data holders; the data itself is stored elsewhere, and multiple references can exist to it.

The two concepts are independent of one another, but it gets confusing, because something passed by-value (in the data-holder sense) can still be a reference (in the data sense) that the callee can potentially modify.
Again, this behavior is fundamental to all in-process parameter passing.


Are the attributes manual annotated or word vectors?

I want to know that the provided class attributes in the code are the human annotated attributes or word vector that described in the paper.

The attributes shared are word2vec (300 dim).


[JBRULES-3416] added unit test to replicate working memory coruption

For jira issue
https://issues.jboss.org/browse/JBRULES-3416


Errror while bundling html with typescript code

I am having issues when bundling, it does not bundle the js code:
error: onLoad plugins must return an object with "contents" as a string or Uint8Array
~/handball-liveshow-spain/src/graphics/live.html:1:0

Here is my build file: https://github.com/BalonmanoVetusta/handball-liveshow-spain/blob/a97dedf74609a19527b0551e80bade9274878792/bin/build.js
To test this in your local:
git clone https://github.com/BalonmanoVetusta/handball-liveshow-spain
cd handball-liveshow-spain
git checkout auto_goals
bun install
bun run build

You should see 3 builded directories:

extension - which is build with esbuild because I needed in commonjs
dashboard - src/dashboard
graphics - src/graphics

It build fine the css but not the js after I have deleted parcel from dependencies. You can test full build with:
git checkout dev
npm install # Some different dependencies
npm run build:clean && npm run build

I am sure in dev branch is building because some non deleted old configuration.

@gtrabanco, thanks for your bug report. This has now been fixed with the latest release of v1.3.1. The issue was that if only a single path was provided it would not return the directory, but instead just the file for the root path. Let me know if this works for you.


Edge 17 doesn't support CSS Backdrop Filter without prefix

Currently, Can I Use is showing Edge 17 (and 18) as supporting CSS Backdrop Filter entirely, but the -webkit--prefix is required for it to work and thus it isn't fully supported yet.

Are you sure about that? All I can see is that the support the default one on developer.microsoft.com
but then again maybe -WebKit- is the default for it, as Apple was one of the big leaders to get this feature integrated as a standard at W3C

I'm sure, I've tested it out. In the screenshot below you can see that Edge 17.17134 doesn't even recognize backdrop-filter as a valid property and instead does recognize -webkit-backdrop-filter.

I think this is the case. I'll check why we did this. If other browsers support without a prefix then we really should do that too.

Given that Safari is the only browser beyond Edge to currently support this, it is kinda weird to use the prefixed version here. Yes, Safari uses the prefix version as well, but... well... it's only Safari. Chrome's experimental implementation doesn't support -webkit-backdrop-filter either, only backdrop-filter.

Ref: MicrosoftEdge/Status#595

I checked and it was intentionally added with just the Webkit prefix for now until we know the spec is stable and won't change. We will unprefix it when other browsers are ready to enable by default and ship unprefixed.

So why use the -webkit- prefix for this anyways? Why not just the -ms- prefix?

because existing content uses -webkit- and not -ms-

Not for this particular thing, and someone else doing it doesn't make it a good argument (if I jump from a bridge, would you too?).

It is an argument as devs would tend to not use the ms or moz or o prefix and thus other non webkit browsers wouldn't get the correct experience. This has been a problem for over a decade since before I worked at Opera. That is exactly the reason why there is a WHATWG Compat spec.
There will be very few if any new ms prefixes going forward as the new way is to use feature flags or origin trials until a feature is stable and browsers can release unprefixed. But this feature predates this with Safari releasing a webkit prefixed version. This has also been an in demand feature to enable things like the acrylic material in Fluent design system. Once it is unprefixed the webkit prefix version will likely live along side it for a while, like other webkit prefixed properties.

Have added a note on this.


[prim] Add hamming code as ECC option

Still default to hsiao code
Signed-off-by: Timothy Chen<EMAIL_ADDRESS>

are you okay with the hamming variant having a different file name?
Not sure if you want me to add hsiao to the original ones also.
On Mon, Dec 28, 2020 at 2:02 PM Eunchan Kim<EMAIL_ADDRESS>wrote:

@eunchan approved this pull request.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/lowRISC/opentitan/pull/4681#pullrequestreview-559316528,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH2RSUS44I6R2TEJSC4PJLSXD553ANCNFSM4VMONUUQ
.

are you okay with the hamming variant having a different file name? Not sure if you want me to add hsiao to the original ones also.

Yeah I am okay with it.


postgresql94

I think lots of people will probably be wanting this now that 9.5 is out and on the main homebrew. Can someone make it
Maybe I can be the change I want to see in the world but I'm not sure I'm ready and someone probably knows how to do this easily

Could you try and open a pull request? This should help and I'm happy to walk you through anything else: https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/How-To-Open-a-Homebrew-Pull-Request-(and-get-it-merged).md#how-to-open-a-homebrew-pull-request-and-get-it-merged
Thanks!

Hey, I closed out my PR, and respectfully decided to leave it to the OP after reading the above comment. Keep me updated on the progress :smile:

Somehow I accidently updated my Postgres 9.4.5 -- I thought I had it pinned but perhaps I did something wrong (most frequent explanation!) or homebrew ignored my pin.
In any case, I wound up with 9.5 and needed 9.4.5 back immediately, but didn't see it available anywhere.  I'm not sure how homebrew handles previous versions -- it appears previous-version formulae are eventually moved here?  Again, perhaps I've misunderstood homebrew: admittedly, I've paid scant attention to the details, as Homebrew usually does what I want.
To get 9.4.5 back, I've naively done:
brew uninstall postgresql # Remove the 9.5 which was upgraded.
brew clean --force -s
cd /usr/local
git checkout -b revert-postgres
git show f8509e62904a055f085579aed47fca1faa7a810f:Library/Formula/postgresql.rb > postgresql.rb
brew install postgresql

It compiled and installed without problems.
The OP of this PR seems to have opted out.  Could/should I simply PR Homebrew/homebrew@f8509e62904a055f085579aed47fca1faa7a810f, with a few changes; i.e., class Postgresql94 < Formula?  Also, I'm not sure what to do about the bottle sha256 values.

Closing in favour of https://github.com/Homebrew/homebrew-versions/pull/1105.


Nested calcs are optimized away incorrectly by cssnano

When a nested calc is used for a property value like the following:
calc(var(--pf-c-form-control--PaddingBottom) - calc(var(--pf-c-form-control--focus--BorderBottomWidth) - var(--pf-c-form-control--BorderWidth)))
Cssnano removes the inner calc leading to incorrect evaluation.  This is due to bugs in a cssnano calc plugin that is included in the default set of minification plugins.  My current recommendation is that we avoid nested calcs like the plague until cssnano fixes their bug (even then, if somebody pulls the scss or compiles manually, they might still have this issue).
Cssnano bug:  https://github.com/postcss/postcss-calc/issues/64
Gatsby developers attempted to workaround this here and decided to wait for the above fix:  https://github.com/gatsbyjs/gatsby/pull/9879
https://github.com/gatsbyjs/gatsby/issues/9858
This is included in the default cssnano set as can be seen here:  https://cssnano.co/guides/optimisations/

Hey @dgutride, did you managed to find a workaround for this?

@dgutride do you know if this was resolved upstream? I tested this and nested calc() functions look OK in our compiled CSS.


twister: Add coverage-exclude flag

Allow passing exclude flags for coverage into twister. This helps projects filter out library code by adding these to the commandline.
Example:
To filter a directory third_party/my/lib add
--coverage-exclude third_party/my/lib

@nashif it looks like a lot of the python tests are failing and are unrelated to the coverage or twister environment. Is this already being tracked? I didn't find an issue, but maybe I wasn't using the right search terms.

@nashif please take a look


Clarification Needed

Thanks for your great work. I think I am too unfamiliar with ML to understand some parts of the README. I would be very happy if you could help me out.
1.
Can you explain a little bit more what this means?

data_base = [:dir to your original dataset]
aug_base =  [:dir to your actually trained dataset]

What is the difference? Where should I put my data? Do I need to preprocess it myself?
2.
Are there any cases where you want to omit --resetClassifier? I though fine-tuning is all about resetting the classifier to a new task.
3.
What is mean and std in config.py. Are those the values for my own dataset? Do I have to compute them myself?

Hi,
Thanks for showing interest in my repository.

You only need to put the data you want to fine tune at the data_base
repository (seperated by its class), then you could run the code in my
image_preprocessing repository.
The code will do the rest of the work :)
If you follow the link to my image preprocessing repository, you can see
further instructions.

You're correct. There isn't any case omitting --resetClassifier is
required. That was just a style for showing that I'm performing fine-tuning
on a new dataset.

If you follow the image_preprocessing repository, there is a menu that
automatically calculates the mean and std for you.
There is no need for calculating those variables yourself.
Hope this mail helps you through your data.
E-mail me if you have further questions, and thank you again for visiting
my GitHub.
Sincerely, Bumsoo Kim
2017-11-12 6:17 GMT+09:00 Johannes Filter<EMAIL_ADDRESS>
Thanks for your great work. I think I am too unfamiliar with ML to
understand some parts of the README. I would be very happy if you could
help me out.
1.
Can you explain a little bit more what this means?
data_base = [:dir to your original dataset]
aug_base = [:dir to your actually trained dataset]
What is the difference? Where should I put my data? Do I need to
preprocess it myself?
2.
Are there any cases where you want to omit --resetClassifier? I though
fine-tuning is all about resetting the classifier to a new task.
3.
What is mean and std in config.py. Are those the values for my own
dataset? Do I have to compute them myself?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/meliketoy/fine-tuning.pytorch/issues/2, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AQ5nm6eH9Dby1G3C8isclGvHRshwOPbnks5s1g7NgaJpZM4Qao8U
.

Thanks mate!


[C++] Support cumulative acknowledgement when consuming partitioned topics

Motivation
For C++ client, when a consumer of partitioned topics calls acknowledgeCumulative(), it just simply set result to ResultOperationNotSupported before.
Modifications

Implement PartitionedConsumerImpl::acknowledgeCumulative;
Add an unit test to verify that cumulative acknowledgement works.

Verifying this change

[x] Make sure that the change passes the CI checks.

This change added tests and can be verified as follows:
Run BasicEndToEndTest.testCumulativeAcknowledgeForPartitionedTopic.

@merlimat Thanks for your quick reply.
IMO, The cumulative ack only applies to the single partition but not all the partitions. See the implement of Java client:
    protected CompletableFuture<Void> doAcknowledge(MessageId messageId, AckType ackType,
                                                    Map<String,Long> properties,
                                                    TransactionImpl txnImpl) {
        // ...
        if (ackType == AckType.Cumulative) {
            // find the single topic consumer by the topic partition name which contains the partition id
            Consumer individualConsumer = consumers.get(topicMessageId.getTopicPartitionName());
            if (individualConsumer != null) {
                // call acknowledgeCumulative() of this single topic consumer
                MessageId innerId = topicMessageId.getInnerMessageId();
                return individualConsumer.acknowledgeCumulativeAsync(innerId);
            } else {
                // ...
            }
        } else {
            // ...
        }
    }

I have tested the Java client, by:

Create a 3 partitions topic;
Produce 10 messages in round robin routing mode;
Start a consumer subscribing to this topic, only call acknowledgeCumulative() after 9 messages received, then stop it;
Restart the consumer with the same subscription.

Here're the output of 1st and 2nd consuming:
Message: C | topic: persistent://public/default/FooTest-partition-0
Message: A | topic: persistent://public/default/FooTest-partition-1
Message: B | topic: persistent://public/default/FooTest-partition-2
Message: F | topic: persistent://public/default/FooTest-partition-0
Message: D | topic: persistent://public/default/FooTest-partition-1
Message: E | topic: persistent://public/default/FooTest-partition-2
Message: I | topic: persistent://public/default/FooTest-partition-0
Message: G | topic: persistent://public/default/FooTest-partition-1
Message: H | topic: persistent://public/default/FooTest-partition-2
Message: J | topic: persistent://public/default/FooTest-partition-1
Message: 1 | topic: persistent://public/default/FooTest-partition-2
acknowledgeCumulative

Message: C | topic: persistent://public/default/FooTest-partition-0
Message: F | topic: persistent://public/default/FooTest-partition-0
Message: A | topic: persistent://public/default/FooTest-partition-1
Message: D | topic: persistent://public/default/FooTest-partition-1
Message: I | topic: persistent://public/default/FooTest-partition-0
Message: G | topic: persistent://public/default/FooTest-partition-1
Message: J | topic: persistent://public/default/FooTest-partition-1

We can see when we acknowledgeCumulative the Message 1 of partition-2, only the previous messages in partition-2 were acknowledged.

Java implementation also does not allow cumulative acks on partitioned topics, for the same reason.
From an API perspective, you're not going to know which messages you're acking and which are not going to be acked.

@merlimat Actually Java implementation allows cumulative acks on partitioned topic. You can run CumulativeAckForPartitionedTopic.java. The output will prove what I've mentioned before.

@merlimat Actually Java implementation allows cumulative acks on partitioned topic. You can run CumulativeAckForPartitionedTopic.java. The output will prove what I've mentioned before.

Whoever did that change has done wrong. From an API standpoint, it doesn't make any sense to do the cumulative ack on just one topic.
A consumer is receiving a sequence of messages from multiple partitions/topics and acks cumulatively... though only some of the messages are actually acknowledged...

@merlimat I found the current semantic of cumulative ack on a partitioned topic was from #2347. The reason of this change is

Yeah, earlier I was thinking about ordering but MultiConsumer anyway doesn't maintain ordering among the consumers and we can also do cumulative ack for individual consumer. let me fix it.

Should you have a discuss about this issue, @rdhabalia @sijie ?

@BewareMyPower @merlimat
The MessageId is used for identifying the position within a topic. For a partitioned topic, the MessageId includes the partition index for identifying the "position" within a partitioned topic. acknowledgementCumulative on a partitioned topic means acknowledging cumulative the messages of the partition inferred by the MessageId. This is semantically correct and there is no confusion here. It is the same concept as we usually say ordering is guaranteed using failover consuming a partitioned topic.

acknowledgementCumulative on a partitioned topic means acknowledging cumulative the messages of the partition inferred by the MessageId.

If I'm consuming from a partitioned topic, I'll get a single stream of messages from multiple partitions.
Eg. P1_M1, P2_M1, P2_M2, P1_M2.
Calling cumulative ack on P1_M2 would be semantically completely different in the case of partitioned/non-partitioned case.
If you're consuming these messages, and say, acking cumulative every 1 second, you might never be acking on some of the partitions.
The only way for the cumulative ack to make sense with partitions is if the client lib would be keeping track, for a given message id, of all the highest message ids in the other partitions that we were queued before it in the shared queue.

for a given message id, of all the highest message ids in the other partitions that we were queued before it in the shared queue.

ackCumulative can work either case. It is a matter that we need to make documentation clear. If we think current Java behavior is wrong, let's fix the function behavior. If Java behavior is fine, let's add documentation.


[SPARK-7134][MLlib] Add regParam and feature scaling options to LR with ...

...SGD model 'train' methods.
Check JIRA https://issues.apache.org/jira/browse/SPARK-7134 for details.

I think we've discussed this before, and we don't want to add more object methods as it's getting out of hand. I think it's an accident that the L-BFGS object is public. If we add this, the new method's args should be a strict superset of the last one's, not a different subset. @mengxr what do you think about this?

Yes, we are deprecating the static train methods.  See https://issues.apache.org/jira/browse/SPARK-6682

FWIW, I think LR with SGD should be made public and LR with LBFGS should be left as it is.


Please help - Raspberry PI zero + bluetooth speaker, no sound and can't find setup that works

Hi,
I have found two similar issues but can't find setup that works for me.
I have raspberry pi zero (with rasbian) and bt speaker , that works with for example internet radio but raspotify doesn't work.
Raspotify works with hdmi but not with bluetooth.
a)Could you make some changes in default config file to select active output depending on what is selected in rasbian as audio output?
b) Please could someone create dummy guide step by step how to make raspotify sound output to bluetooth speaker?
Thank you!

Have you checked
https://github.com/dtcooper/raspotify/issues/63 ?

had a similar issue, installing this alongside (and removing pulseaudio if you have it) resolved it for me: https://github.com/bablokb/pi-btaudio

If the issue is resolved, you should close it @aintnogeek


Update README.md

Related issue

What changes does this PR do?
Screenshots (If any)
Questions

Adding my name to the README.md.


⚠ Bofrost.fr has degraded performance

In 3f697fd, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1280 ms

Resolved: Bofrost.fr performance has improved in beada2f after 6 minutes.


Fix inconsistent arg name in CLI, fixes #62

I think this is singular to match the browerify CLI API. That makes me hesitant to change it.

Thanks for the reply.
I think this shouldn't cause problems, as opts.js is merely passed to atomify-js, which already seems to accept only the plural version...


Provide source file template

Today when a new file is added, it is empty. It takes additional effort to add namespace, license, class fixture and so on. These common parts can be automatically generated base on a template.

https://github.com/OmniSharp/omnisharp-vscode/issues/261
Need to be determined on which layer this feature to be implemented.

In atom we use https://github.com/OmniSharp/generator-aspnet through a custom yeoman interface.  I don't know if this belongs to the server or not.


Performance drop for intel uhd graphics 620 and dxvk with lutris <IP_ADDRESS>

Ubuntu 20.04
Lutris <IP_ADDRESS>
UHD Graphics 620 (Wiskey Lake)
16 RAM
World of Warcraft usind DXVK+VK3D DXVK VErsion 1.7L-3322da4-2
After using Lutris <IP_ADDRESS> previously I noticed a FPS drop of 5-10 frames after installing <IP_ADDRESS>
One might say that you should not play WoW with intel hd graphics anyways but well, it's playable with DXVK :) So 5-10 FPS is something you really notice.
Anything changed here that changes DXVK with intel ?
Best regards

Thanks @tannisroot and sorry for opening this in the wrong repo!
It's directx11, i have only the options for this and directx11legacy.
Lowering the dxvk version made it much worse so I switched back to 1.7L-3322da4-2
What made it better was upgrading my graphics stack from the oibaf ppa and I can use the <IP_ADDRESS> version without fps loss.
Previously I had the graphics stack that comes preinstalled with Ubuntu 20.04.0

You might want to try DXVK 1.7.1 version.

Are the DXVK versions automatically downloaded and appear in the Lutris list after a new release has been officially been tagged on lutris/dxvk ?

Could you try switching Wine version to 5.7-8?

Type in "DXVK version", 1.7.1 and it should get it automatically.

This does not work with my setup:

Sorry for the noise :(

This does not work with my setup:

Sorry for the noise :(

Yeah can confirm I can't get it either, very strange can get earlier 1.7 version (maybe they changed something?)


Mavlink rate control is still wonky

So I'm trying to validate the 250 Hz data transfer result from https://github.com/PX4/Firmware/pull/6169, but something still isn't right.
I'm using the USB CDC interface on a Pixhawk, starting only a few streams in mavlink custom mode :
Here's how I'm starting mavlink :
# Mavlink
mavlink start -r 800000 -d /dev/ttyACM0 -m custom -x

# VIO Specific Streams
mavlink stream -d /dev/ttyACM0 -s HIGHRES_IMU 			-r 200
mavlink stream -d /dev/ttyACM0 -s GPS_RAW_INT 			-r 5
mavlink stream -d /dev/ttyACM0 -s ATTITUDE_QUATERNION 		-r 30
mavlink stream -d /dev/ttyACM0 -s CAMERA_TRIGGER 		-r 1000
mavlink stream -d /dev/ttyACM0 -s TIMESYNC 			-r 30
mavlink stream -d /dev/ttyACM0 -s SYSTEM_TIME 			-r 1

# Debug streams
mavlink stream -d /dev/ttyACM0 -s VISION_POSITION_ESTIMATE 	-r 10
mavlink stream -d /dev/ttyACM0 -s LOCAL_POSITION_NED 		-r 10
mavlink stream -d /dev/ttyACM0 -s GLOBAL_POSITION_INT 		-r 10
mavlink stream -d /dev/ttyACM0 -s SYS_STATUS 			-r 5
mavlink stream -d /dev/ttyACM0 -s EXTENDED_SYS_STATE 		-r 5
mavlink stream -d /dev/ttyACM0 -s HOME_POSITION 		-r 1

mavlink boot_complete

Note that setting -r 800000 for mavlink start higher/lower does NOT affect anything, and the issue persists.
Setting the -r 200 for mavlink stream higher (without touching anything else) to e.g 250 DOES increase the rate (to something like 210 Hz) but it never reaches the target rate.
From mavlink status :
instance #0:
        GCS heartbeat:<PHONE_NUMBER> us ago
        mavlink chan: #0
        type:           USB CDC
        flow control:   OFF
        rates:
        tx: 17.202 kB/s
        txerr: 0.000 kB/s
        rx: 0.996 kB/s
        rate mult: 1.000
        accepting commands: YES
        MAVLink version: 1
        transport protocol: serial (/dev/ttyACM0 @2000000)

Note that the rate multiplier is 1.0.
And the actual rate I'm getting (for HIGHRES_IMU):
average rate: 186.141
	min: 0.002s max: 0.010s std dev: 0.00172s window: 177
average rate: 184.189
	min: 0.002s max: 0.010s std dev: 0.00197s window: 360
average rate: 184.016
	min: 0.002s max: 0.010s std dev: 0.00203s window: 544
average rate: 184.252
	min: 0.002s max: 0.010s std dev: 0.00199s window: 728
average rate: 184.166
	min: 0.002s max: 0.010s std dev: 0.00197s window: 765

@LorenzMeier Your help would be greatly appreciated on this one. Been running into it for ages, and I still don't understand why...  (exactly same as https://github.com/PX4/Firmware/issues/3291). I'm determined to get to the bottom of this, this time.

@mhkabir do you have any update on this?

This should be fixed on master.  Let me know if it isn't.

@mhkabir looks like it did yes. Quick question for you, is there anything artificially limiting all the rates to 250Hz? Or were you ever able to get a higher rate for any of the streams Thank you!

@blandry OK the mainloop speed seems to be fine. What message are you trying to send? I'm pretty sure that there is actually no message corresponding to a topic which is updated at more than 250Hz.

@mhkabir hmm right I think you're correct. Somehow I was under the impression that I could get attitude at 500Hz, but the EKF certainly doesn't run at that rate. Thanks!

@blandry It is feasible to run it at that rate - would you like to get some pointers to increase the rate?

@LorenzMeier actually that would be very helpful yes! I'm worried that messing with the scheduler too much without knowing the limitations of the hardware could lead to unforeseen problems.

That would be great to learn how to run the EKF at that rate. What are the pointers to do this? Assuming the EKF runs that fast, changing the estimator rates wouldn't necessarily change the update rates to 250Hz or greater as @mhkabir had mentioned, it seems thats regulated by something else in the code? Thanks in advance.


Fix assembly on windows

#3 broke assembly on windows -- this should make it cross-platform.

Confirmed working on Linux, macOS, Windows.


Invite Alexey Alekhin to the team!

Alexey has been actively contributing to this project since day 2 both
via discussions in issues and pull requests. Welcome!

Feel free to merge at your leisure @laughedelic


Duplicate holiday dates produces an error

With a large list of holidays I've found that there will be accidents with the manual creation process. It is helpful if the error message tells you what is wrong instead of giving you an error that doesn't mean anything.
If you run this:
library(prophet)
data = read.csv("https://raw.githubusercontent.com/facebookincubator/prophet/master/R/tests/testthat/data.csv")

holidays <- data_frame(
  holiday = 'duplicate',
  ds = as.Date(c("2012-05-18", "2012-05-18")),
  lower_window = 0,
  upper_window = 0
)

prophet(data, holidays = holidays)

This is the error:
Error in seq.default(.$lower_window, .$upper_window) :
  'from' must be of length 1

A fix would be to check for duplicate dates and throw an error that says there are redundant holiday dates.

Thanks, since this was working in Python I went ahead and made a commit that fixes it in R. If you install from github it should work for you.


Fix bug when remote_path is also in filePath

Fix for #220
Test has been rewritten to allow manually setting paths

Thank you!

Thank you!


Fix to Pre-processing

Minor fix to links (Zenodo record updated thanks to fix from their team)
Input names fixed (Thanks to J Kim for spotting these)

Thanks @mtekman!


Prepare release 1.1 for location-verification + README + CHANGELOG

What type of PR is this?

correction
subproject management

What this PR does / why we need it:
Prepare location-verification for r1.1
Some fixes after review
Update README (for the 3 APIs)
Update CHANGELOG (for location-verification + placeholders for the others)

Before creating the r1.1 release we have to:

Merge the pending PRs for geofencing (maybe with the exception of the test plan)
Create a PR for geofencing adjusting versions for r1.1
Merge the PR for location-retrieval for r1.1
Merge this PR for location-verification + README/CHANGELOG for r1.1


Fix return if no services to control are available

Because .opoo returns nil, return was never executed because of the short circuit evaluation of and.
Example:
» a = []
» puts 'explode does not exist' and explode if a.empty?
explode does not exist
=> nil
» explode
NameError: undefined local variable or method `explode' for main:Object
from (pry):3:in `<main>'

This was the stack trace before:
$ brew services list
Warning: No services available to control with `brew services`
Error: undefined method `[]' for nil:NilClass
/usr/local/Library/Taps/homebrew/homebrew-services/cmd/brew-services.rb:207:in `list'
/usr/local/Library/Taps/homebrew/homebrew-services/cmd/brew-services.rb:162:in `run!'
/usr/local/Library/Taps/homebrew/homebrew-services/cmd/brew-services.rb:402:in `<top (required)>'
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/usr/local/Library/brew.rb:60:in `require?'
/usr/local/Library/brew.rb:139:in `<main>'

Thanks for your contribution to Homebrew!  You rock!


Hawthorn does not grow

Hawthorn does not currently grow. Looking at the code, it looks like it is supposed to grow like cactus, but you forgot a call to this.setTickRandomly(true); so it never receives block updates.
Using Stygian End 1.0.4 for Minecraft 1.12.2

I doubt this mod will ever be active. Unless you're willing to continue this mod, then its dead.

should be fixed in my fork (indev) : https://github.com/quentin452/enderoni-continuation/


Issues while Hosting label-studio in a remote ubuntu server

Describe the bug
Tried to host the app in an ubuntu -18 remote machine. Looks like most of the inside settings are configured to run the app in localhost.
Request documentation on how to configure server IP instead of localhost.
To Reproduce
Steps to reproduce the behavior:
Deploy the app using docker compose in an ubuntu 18 remote server
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment (please complete the following information):

OS: Ubuntu 18
Label Studio Version :latest

Additional context
Add any other context about the problem here.

If you have external domain for LS, you need to specify it at docker start:
LABEL_STUDIO_HOST=https://subdomain.example.com:7777 docker-compose up

As suggested used LABEL_STUDIO_HOST=http://xx.xxx.xxc.xx docker-compose up to start the application.URLs are mapped to the host IP.But UI appears to be broken.Is there any configurations to be changed on UI service?

Could you check docker console? it must be string about your current hostname at start up. Is there a correct hostname?

Sharing the docker console logs.Here at console the app_1    | => Hostname correctly is set to: http://<IP_ADDRESS>}.Is there any change required in UI settings?
Starting label-studio_db_1 ... done
Recreating label-studio_app_1 ... done
Recreating label-studio_nginx_1 ... done
Attaching to label-studio_db_1, label-studio_app_1, label-studio_nginx_1
app_1    | Postgres is up - executing command
app_1    | => Do database migrations...
app_1    | => Hostname correctly is set to: http://<IP_ADDRESS>}
app_1    | => Database and media directory: /label-studio/data
app_1    | => Static URL is set to: /static/
app_1    |
app_1    | [2021-04-06 15:14:47,704] [urllib3.connectionpool::_new_conn::971] [DEBUG] Starting new HTTPS connection (1): pypi.org:443
app_1    | [2021-04-06 15:14:47,866] [urllib3.connectionpool::_make_request::452] [DEBUG] https://pypi.org:443 "GET /pypi/label-studio/json HTTP/1.1" 200 34251
app_1    | [2021-04-06 15:14:48,469] [core.redis::::14] [WARNING] Redis is not connected.
nginx_1  | /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
nginx_1  | /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
nginx_1  | /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
nginx_1  | 10-listen-on-ipv6-by-default.sh: info: can not modify /etc/nginx/conf.d/default.conf (read-only file system?)
nginx_1  | /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
nginx_1  | /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
nginx_1  | /docker-entrypoint.sh: Configuration complete; ready for start up
db_1     | 2021-04-06 15:14:43.086 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
db_1     | 2021-04-06 15:14:43.086 UTC [1] LOG:  listening on IPv6 address "::", port 5432
db_1     | 2021-04-06 15:14:43.355 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
db_1     | 2021-04-06 15:14:45.267 UTC [22] LOG:  database system was shut down at 2021-04-06 15:11:18 UTC
db_1     | 2021-04-06 15:14:46.196 UTC [1] LOG:  database system is ready to accept connections
app_1    | [2021-04-06 15:14:48,646] [root::read_py::52] [ERROR] Can't read version file: version.py
app_1    | [2021-04-06 15:14:48,646] [root::read_py::53] [ERROR] No module named 'version'
app_1    | [2021-04-06 15:14:49,171] [asyncio::init::59] [DEBUG] Using selector: EpollSelector
app_1    | Operations to perform:
app_1    |   Apply all migrations: admin, auth, authtoken, contenttypes, data_import, data_manager, io_storages, ml, organizations, projects, sessions, tasks, users
app_1    | Running migrations:
app_1    |   No migrations to apply.
app_1    | => Run bash /label-studio/deploy/start_label_studio.sh...
app_1    | => Hostname correctly is set to: http://<IP_ADDRESS>}
app_1    | => Database and media directory: /label-studio/data
app_1    | => Static URL is set to: /static/
app_1    |
app_1    | [2021-04-06 15:14:51,620] [root::read_py::52] [ERROR] Can't read version file: version.py
app_1    | [2021-04-06 15:14:51,620] [root::read_py::53] [ERROR] No module named 'version'
app_1    | [2021-04-06 15:14:51,959] [root::read_py::52] [ERROR] Can't read version file: version.py
app_1    | [2021-04-06 15:14:51,959] [root::read_py::53] [ERROR] No module named 'version'
app_1    | Start browser at URL: http://localhost:8080
app_1    | Performing system checks...
app_1    |
app_1    | System check identified no issues (0 silenced).
app_1    | April 06, 2021 - 15:14:52
app_1    | Django version 3.1.4, using settings 'core.settings.label_studio'
app_1    | Starting development server at http://<IP_ADDRESS>:8080/
app_1    | Quit the server with CONTROL-C.

No, you don't need to change anything in UI.
I see a strange character } at the end of the hostname. It's excess.

I think your nginx is wrongly configured.

mount static folder in the app service in the docker-compose.yml, UI will work properly after that make sure you have pulled the latest code and build the docker locally docker build -t label_studio_app . and then run docker-compose up -d --build
version: '3.3'
services:
nginx:
image: nginx:latest
ports:
- 80:80
depends_on:
- app
volumes:
- static:/label-studio/label_studio:rw
- ./mydata:/label-studio/data:rw
- ./deploy/nginx/${NGINX_FILE:-default.conf}:/etc/nginx/conf.d/default.conf:ro
command: nginx -g "daemon off;"
app:
stdin_open: true
tty: true
# build: .
image: label_studio_app:latest
ports:
- 8080:8080
depends_on:
- db
environment:
- DJANGO_DB=default
- POSTGRE_NAME=postgres
- POSTGRE_USER=postgres
- POSTGRE_PASSWORD=
- POSTGRE_PORT=5432
- POSTGRE_HOST=db
- LABEL_STUDIO_HOST=${LABEL_STUDIO_HOST:-http://localhost}
volumes:
- ./mydata:/label-studio/data:rw
- static:/label-studio/label_studio:rw
command: [ "./deploy/wait-for-postgres.sh", "db", "bash", "/label-studio/deploy/start_label_studio.sh" ]
db:
image: postgres:11.5
hostname: db
restart: always
environment:
- POSTGRES_HOST_AUTH_METHOD=trust
volumes:
- ${POSTGRES_DATA_DIR:-./postgres-data}:/var/lib/postgresql/data
ports:
- 5432:5432
volumes:
static: {}

@abhay-kum that works.Thank you for the suggestion. app is accessible at 8080.
Also since  I already have other applications running on port 80, unable to use port 80 as default in Nginx configuration.
Tried giving port 8008 in Nginx configuration in the docker-compose file as below.
image: nginx:latest
ports:

8008:80
depends_on:

But traffic is not getting routed through 8008..and I have to directly use 8080 port.Any suggestions here for routing the traffic through Nginx with custom port?

@athulprathap facing the same problem did you find any solution?

@suvojit-0x55aa Hi Suvajit,
Yeah.Got a temporary fix. Bypass Nginx service and access the service directly in 8080.

Facing the same issues. Though As suggested once I By-Pass Nginx and directly access 8080 it works.


Fix various issues with CLI and creating .pem and .crx files

If directory is not specified, we'll assume current working directory for all options. If .pem file is not specified, we will create one automatically (like the docs say) and will continue operation. Added a little more error handling.
Fixes
https://github.com/oncletom/crx/issues/33
https://github.com/oncletom/crx/issues/31

+1. Bump. Anything holding this up?

:+1: @workmanw. Anybody?

Sorry for the delay guys! Winter break + loads of other things to do. Thanks for pushing this up :-)

Published as v2.0.1.


undefined method `has_key?' for nil:NilClass (NoMethodError)

Hi Geoff, I'm using ncedit on site with a customer to setup some basic code manager things post-install.  Great work on the tool!
I recently had to re-install PE 2016.4.3 in their sandbox environment and now my previously working script is failing on this stacktrace:
Group PE Master found, getting definition
undefined method `has_key?' for nil:NilClass
undefined method `has_key?' for nil:NilClass (NoMethodError)
/opt/puppetlabs/puppet/lib/ruby/gems/2.1.0/gems/ncedit-0.1.0/lib/ncedit/cmd.rb:253:in `ensure_param'
/opt/puppetlabs/puppet/lib/ruby/gems/2.1.0/gems/ncedit-0.1.0/lib/ncedit/cmd.rb:297:in `block (2 levels) in ensure_classes_and_params'
/opt/puppetlabs/puppet/lib/ruby/gems/2.1.0/gems/ncedit-0.1.0/lib/ncedit/cmd.rb:295:in `each'
/opt/puppetlabs/puppet/lib/ruby/gems/2.1.0/gems/ncedit-0.1.0/lib/ncedit/cmd.rb:295:in `block in ensure_classes_and_params'
/opt/puppetlabs/puppet/lib/ruby/gems/2.1.0/gems/ncedit-0.1.0/lib/ncedit/cmd.rb:291:in `each'
/opt/puppetlabs/puppet/lib/ruby/gems/2.1.0/gems/ncedit-0.1.0/lib/ncedit/cmd.rb:291:in `ensure_classes_and_params'
/opt/puppetlabs/puppet/lib/ruby/gems/2.1.0/gems/ncedit-0.1.0/lib/ncedit/cmd.rb:207:in `block in batch'
/opt/puppetlabs/puppet/lib/ruby/gems/2.1.0/gems/ncedit-0.1.0/lib/ncedit/cmd.rb:190:in `each'
/opt/puppetlabs/puppet/lib/ruby/gems/2.1.0/gems/ncedit-0.1.0/lib/ncedit/cmd.rb:190:in `batch'
/opt/puppetlabs/puppet/lib/ruby/gems/2.1.0/gems/ncedit-0.1.0/exe/ncedit:77:in `block (3 levels) in <top (required)>'
/opt/puppetlabs/puppet/lib/ruby/gems/2.1.0/gems/escort-0.4.0/lib/escort/app.rb:68:in `call'
/opt/puppetlabs/puppet/lib/ruby/gems/2.1.0/gems/escort-0.4.0/lib/escort/app.rb:68:in `execute_action'
/opt/puppetlabs/puppet/lib/ruby/gems/2.1.0/gems/escort-0.4.0/lib/escort/app.rb:55:in `execute'
/opt/puppetlabs/puppet/lib/ruby/gems/2.1.0/gems/escort-0.4.0/lib/escort/app.rb:6:in `create'
/opt/puppetlabs/puppet/lib/ruby/gems/2.1.0/gems/ncedit-0.1.0/exe/ncedit:9:in `<top (required)>'
/opt/puppetlabs/puppet/bin/ncedit:23:in `load'
/opt/puppetlabs/puppet/bin/ncedit:23:in `<main>'
Escort app failed to execute successfully, due to unknown error

The command I'm trying to run is:
++ mktemp
+ ncdatafile=/tmp/tmp.CWMnUKHikS/tmp.UhN9AsARd5
+ echo '---
PE Master:
  classes:
    pe_r10k:
      r10k_basedir: /etc/puppetlabs/code/environments
      remote: ssh://git@stash-ess.acme.com:7999/pe/modules.git
      git_settings:
        provider: rugged
        private_key: /etc/puppetlabs/puppetserver/ssh/id-all_repo.rsa
      deploy_settings:
        purge_levels:
          - environment
          - puppetfile'
+ ncedit --verbosity debug batch --yaml-file /tmp/tmp.CWMnUKHikS/tmp.UhN9AsARd5

The business purpose is to programmatically set the r10k purge level for this customer.

I discovered if I manually add the pe_r10k class to the PE Master node group using the UI then the command succeeds.

Hi Jeff,
Thanks, glad your finding it useful!  I've been adding functionality edit NC data without a yaml file to ncedit today and fixed a bunch of bugs while I was at it.  I think I ran into the issue you had (add parameter to non-existent group fails) myself
I just tested out your sample example code on a fresh master and it works on PE2017.x.  Using ncio to verify the fix I get:
      "pe_r10k": {
        "deploy_settings": {
          "purge_levels": [
            "environment",
            "puppetfile"
          ]
        },
        "git_settings": {
          "provider": "rugged",
          "private_key": "/etc/puppetlabs/puppetserver/ssh/id-all_repo.rsa"
        },
        "r10k_basedir": "/etc/puppetlabs/code/environments",
        "remote": "ssh://git@stash-ess.acme.com:7999/pe/modules.git"
      }

The latest release v0.2.0 should fix for you - please let me know if it works
Cheers


Switching language dynamically using $translate.use doesn't work

My default language is english, selected language is german.
When I try to switch back to english, the language doesn't switch due to below code:
else if (langPromises[key]) {
      // we are already loading this asynchronously
      // resolve our new deferred when the old langPromise is resolved
      langPromises[key].then(function (translation) {
        if (!$uses) {   // <<------------------------ WHY THIS?
          useLanguage(translation.key);
        }
        deferred.resolve(translation.key);
        return translation;
      }, function (key) {
        // find first available fallback language if that request has failed
        if (!$uses && $fallbackLanguage && $fallbackLanguage.length > 0) {
          return $translate.use($fallbackLanguage[0]).then(deferred.resolve, deferred.reject);
        } else {
          return deferred.reject(key);
        }
      });
    }`

langPromises[key] exists, which is a promise for english language data.
We attach a handler to it via then() which gets resolved immediately since it's an already resolved promise. Now, value of $uses  is the language key for german. So below code in that success callback prevents me from switching to  english:
  if (!$uses) {
          useLanguage(translation.key);
  }

Can someone explain why this code is in place..? If I'm using a language ($uses has some value) I can't switch to an already loaded language..?
environment
angular-translate angular-translate and it's plugins - v2.9.2 - 2016-02-21
angular 1.3.5
angular-cookies v1.3.5
Expected behaviour
Language should switch to english when I invoke $translate.use('en') regardless of whether it was already loaded or I'm using a different language.
Actual behaviour
Language doesn't switch.

Can you setup a short plnkr, so we have a valid testcase showing all configuration you have? thanks.

Ok. Got it.
Yes, the line you marked looks incorrect also to me. @knalli any reason for pushing in that if-section lately?

Duplicate of #1415 - closing in favor of this


Stable random number per mesh island

There's a feature request to have a random number per mesh island available for use in material shaders. It should be stable across session restarts (aka animation frames), which can be achieved by not using a RNG, but instead using a hash function on a seed value (passed in via property). In the Blender addon we would use the object's original name as seed.
Here is the implementation of this feature in Cycles: https://developer.blender.org/D6154

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

This is a very important feature to add randomization to complex objects that cannot be split to work with them, like wood planks or tiles, grass blades, etc...

Any news about this option ; can this be included in the near future with Luxcore :

This is under development here: https://forums.luxcorerender.org/viewtopic.php?f=5&t=1918&p=20898#p20896

Done.


Whether to support drilling down

Whether to support drilling down？how to use? thank you

Davinci does support drill-down analysis with charts, but only in Pivot mode currently.
In our roadmap,  Davinci will fully support drill-down feature in both Pivot and Chart mode, and also with specific path (will be set by users themselves in advance) and free drill-down support.

Where do I need to set it? I can't find it. Are there any examples?  thank you.

As the description above, we support drill-down feature partially, it supports free drill-down with Widget in Pivot mode, which means you do not need to set it in advance.
Here are the steps,

add a Widget in Pivot mode
add it to a Dashboard
click the drill-down icon button in top right corner, where the toolbar located, of the dashboard item when hovering it
now you are in  drill-down mode, and you can start to drill with mouse drag and click operations

yes, i do like that, but
,
so i'm confused.

@ruanhan

In fact, we only have drill on charts in some specific modes. it’s on  dev-0.3.
because of the adjustment of past work plans, the  development of the drill has been shelved.
For the next time, I will  refactor these drill functions. And other features released in the next release.

ok

what's the plan of drill function? when can it be released?


React.js Invariant Violation: unable to find child 'x' of element

Hello, I am building a website using React with ES6 and am using Sortable for a page with a drag-and-drop activity. There are 4 Sortable instances, all in the same group. I have 10 items that can be sorted. By default, all 10 start in the 'unsorted' instance. They can be dragged to 'yes', 'maybe', and 'no' groups, as well as back to the 'unsorted' group.
Right now, I am displaying the items in each group using 4 different arrays that belong in this.state. When I drag and drop the first item, the console throws the following error, and drag-and-drop breaks until I refresh the page.
    bundle.js:1100 Uncaught Invariant Violation: processUpdates(): Unable to find child 5 of element. This probably means the DOM was unexpectedly mutated (e.g., by the browser), usually due to forgetting a <tbody> when using tables, nesting tags like <form>, <p>, or <a>, or using non-SVG elements in an <svg> parent. Try inspecting the child nodes of the element with React ID `.<IP_ADDRESS>.4`.
Is there a way I can implement this feature differently to avoid such an error? Or is there a way to fix my current approach? I've included the relevant pieces below:
Here's the state that I have:
unsortedOptions: ["itemId1", "itemId2", "itemId3"]
yesOptions: []
maybeOptions: []
noOptions: []
Here's my code for how I'm setting everything up.
``
componentDidMount() {
this.setupDragAndDrop();
}
setupDragAndDrop() {
Sortable.create(unsorted, {
group: 'mainGroup',
animation: 100,
onAdd: (e) => {
this.processDragDropAction(e.item.id, "unsorted");
}
});
Sortable.create(yes, {
  group: 'mainGroup',
  animation: 100,
  onAdd: (e) => {
    this.processDragDropAction(e.item.id, "yes");
  }
});

Sortable.create(maybe, {
  group: 'mainGroup',
  animation: 100,
  onAdd: (e) => {
    this.processDragDropAction(e.item.id, "maybe");
  }
});

Sortable.create(no, {
  group: 'mainGroup',
  animation: 100,
  onAdd: (e) => {
    this.processDragDropAction(e.item.id, "no");
  }
});

}
processDragDropAction(itemId, columnAddedTo) {
// this method removes the itemId from all the state arrays and adds it to the one corresponding to columnAddedTo
}``
Then inside render:
``
render(){
var unsortedResources = this.state.unsortedOptions.map((input, index) =>
{input}
);
var yesResources = this.state.yesOptions.map((input, index) =>
{input}
);
var maybeResources = this.state.maybeOptions.map((input, index) =>
{input}
);
var noResources = this.state.noOptions.map((input, index) =>
{input}
);
return(

          {unsortedResources}

          {yesResources}

          {maybeResources}

          {noResources}

)
}
``

Dear all! Meteor is moved to the separate repository. If this issue is still actual, please create it there once again and this rojects needs a maintainer:

ES2015+: https://github.com/SortableJS/react-sortablejs 🆘
mixin: https://github.com/SortableJS/react-mixin-sortablejs


Potential stack-based buffer overflow in XDagCore

I didn't see a place to create issues at https://github.com/xrdavies/DaggerGpuMiner, so I hope this is ok place to track them until that is fixed.
XDagCore/XNetwork.cpp
bool XNetwork::ValidateAddress(const char *address, sockaddr_in &peerAddr)
{
    char *lasts;
    char buf[0x100]; // 256

    // Fill in the address of server
    memset(&peerAddr, 0, sizeof(peerAddr));
    peerAddr.sin_family = AF_INET;

    // Resolve the server address (convert from symbolic name to IP number)
    strcpy(buf, address); // here

address is copied into buf without checking if the server address is < 256 bytes and there were no other limits seen on a server address's size.
This can be easily fixed by just checking if address < buf before doing the copy.
Also, in CLminer.cpp there is an issue:
void AddDefinition(std::string& source, char const* id, unsigned value)
{
     char buf[256];
     sprintf(buf, "#define %s %uu\n", id, value);
     source.insert(source.begin(), buf, buf + strlen(buf));
}

If id is not guaranteed to be < 256 bytes, a buffer overflow will occur.
You can fix this by using snprintf() instead of sprintf() and specifying the max size to be sizeof(buf).
These vulnerabilities could allow someone to compromise the process and affect the security of the user running the app.

@glte  This repository if for xdag, and this issue is GPU Miner issue. So I will move to GPU Miner repository.


Trouble using cellEditor InputParameterizedCellEditor in Ag-Grid v25

Hi,
I am currently trying to use the cellEditor InputParameterizedCellEditor after upgrading Ag-Grid from v22 to v25 (all of this under the Angular framework). There were not any problems using the former, but there seems to be some kind of trouble with the later version .
Apparently, everything goes right when compiling the application and when loading grids for editing, but for some reason, when I try to edit a cell using the cell editor aforementioned, the cell is unresponsive (it is not entering into edit mode after pressing enter key or double-clicking it, it remains like if it was noneditable when that is not the case at all).
As I said, previously there not any issues regarding this when using Ag-Grid v22, so my guess is that this library probably it is not up to date with the incoming changes from the newest versions.
Are there any plans to maintain this library or is there any suggestion regarding the preceding problem I have described?
Thanks in advance.

Yeah, for me it's the same, after upgrading to ag-grid v25 this plugin it's not working anymore.


Subgraph composition sql more entities

Add support for querying more entities with a single SQL query.

@lutter I believe that the comments in the find_range() make the matching algorithm for detecting the type of the operation more clear. Not sure if there is an easy way to make it simpler. Also I feel that splitting mutable and immutable cases won't improve things much, as the immutable case is a special case (and simpler one) of the mutable one.

One other thing I am wondering about with this strategy: if you are looking for changes in [10,20) and you find an entity version with a range of [11, 200) will this properly check if there is a version [200,_) to tell whether this is a delete or an update?

One other thing I am wondering about with this strategy: if you are looking for changes in [10,20) and you find an entity version with a range of [11, 200) will this properly check if there is a version [200,_) to tell whether this is a delete or an update?

We don't reason about the situation around 200 since it's > 20. We only check if there is another entry ending at 11 in order to decide if it's creation or modification at 11.


ch 10: incorrect input amount in refund transaction

In chapter 10, updating-the-state-1 (https://savingsatoshi.com/en/chapters/chapter-10/updating-the-state-1), the user creates a refund transaction for the 2-of-2 multisig they make with Laszlo in the previous exercise. In that exercise you need to set aside 1000 sats for miner fees, making a total of 100,000 sats locked in the multisig.
In this exercise, the multisig transaction is the input. In the screenshot below you can see that the input amount is 101,000 sats, but it should really be 100,000 sats.

This is also true for the updating-the-state-3 (https://savingsatoshi.com/en/chapters/chapter-10/updating-the-state-3) exercise:

As I continue to QA chapter 10, I see that this issue impacts subsequent exercises. Here's a comment on how the Laszlo + you amount should probably end up to be 99,000 sats: https://github.com/saving-satoshi/saving-satoshi/pull/1174#discussion_r1842343476

I need to retest this. I believe it has been fixed.

with #1174 and #1195 now merged I think we did finally fix this issue

I am going to close this as I am confident that we fixed our sats amounts


Bug: bibfile path that contains spaces doesn't work

The path to my bibtex file contains spaces. When I run BibtexciteShowcite, the pop-up shows two bibtool errors: it can't open the first part of the path as a bib file, and it can't open the second part of the path as a bib file.
I can simply fix this by adding quotes to the bibtool calling string in autoload/bibtexcite.vim:117. That makes everything work as expected. However, I'm pretty sure that would break support for multiple bib files.

I'm setting the bibtex file path through g:bibtexcite_bibfile

Thanks for the report, I'll take a look at it soon!

Can you check if the latest commit fixes the issue?

It does, thanks for fixing this!

I also added an "open pdf" option (see the other issue and the help), I'd be happy if you could also check if that works for you! Thanks


Much needed update

use latest monit versions
old binaries in particular are unavailable
add proper Centos (and family) support with init script template

Closing this for now.  Working on travis config.


Symlink / rename complex case issue

import pyfakefs.fake_filesystem
import os
fs = pyfakefs.fake_filesystem.FakeFilesystem()
fs.CreateDirectory('/Volumes')
fs.CreateDirectory('/Volumes/ramdisk')
fs.CreateDirectory('/Volumes/ramdisk/test')
os0 = pyfakefs.fake_filesystem.FakeOsModule(fs)
component0 = "gamma"
component1 = "c"
path0 = "/Volumes/ramdisk/test"
path1 = "/Volumes/ramdisk/test"
path2 = "/Volumes/ramdisk/test"
path1 += "/" + component0
component0 = "Alpha"
path0 += "/" + component0
component0 = "a"
os0.symlink(path2,path1)
path1 += "/" + component0
component0 = "f"
path2 += "/" + component0
component0 = "phi"
os0.mkdir(path0)
path0 = "/Volumes/ramdisk/test"
path0 += "/" + component0
component0 = "alpha"
os0.mkdir(path0)
path0 = "/Volumes/ramdisk/test"
os0.mkdir(path1)
os0.symlink(path0,path2)
path0 += "/" + component0
os0.rename(path1,path0)
path0 = "/Volumes/ramdisk/test"
path0 += "/" + component1
os0.mkdir(path0)
os0.mkdir(path1)
result = sorted(os0.listdir(path2))
print result
os gives ['a', 'alpha', 'c', 'f', 'gamma', 'phi']
pyfakefs gives ['Alpha', 'a', 'c', 'f', 'gamma', 'phi']

This was actually a dumb regression. Actually TSTL didn't such a good job normalizing in this case - the test boils down to something like:
    def test317(self):
        self.filesystem.is_case_sensitive = False
        base_path = '/foo/bar'
        self.filesystem.CreateDirectory(base_path)
        self.os.mkdir(base_path + '/Alpha')
        self.os.mkdir(base_path + "/beta")
        self.os.rename(base_path + "/beta", base_path + "/alpha")
        self.assertEqual(['alpha'], self.os.listdir(base_path))

Note that symlink had noting to do with the problem, and also 3 of the created directories.

Hmm, tstl didn't actually normalize it, looks like to me.  Weird.

The gamma and c etc. are pretty clear non-normalized test.  Have to look into that.

The fix didn't fix yet, by the way -- I see commit referencing this, but it still fails on latest, fyi.

Ah, I hadn't merged it yet to master, waiting for travis to have it's say. I merged it just now.

For all case-insensitive stuff, I'm waiting for the Mac builds from Travis CI first, but they have a huge backlog, so it sometimes takes a few hours.


Improve docker registry

See tickets #195, #196, #197
Enable htpasswd auth
Mount the certs and auth files using secrets
Remove hostPath access
Add IP address to allow a user to access the docker registry remotely

Closes #195
Closes #196
Closes #197

2 points not implemented:

Document and pass as file or var a list of users/pwd for htpsswd
Enable/disable auth

Should we implement them now ? @jacobdotcosta


Handling the readable width of components

Need a way to restrict the max and minimum readable width of certain components when used singularly, eg cards.
Trying to keep it between 50 and 70 where possible: https://baymard.com/blog/line-length-readability

This may be an example of where we should let components be constrained by their containers. This allows flexibility, and prevents complexity, such as conditionally allowing image-only cards to be wider, for instance.


Contributions or Change of Maintainer

Hi @indigoviolet
I've noticed that the project has become somewhat stale and that things like Issues and PRs have gone un-replied to or unmanaged. Would you be happy to add me as a contributor or transfer maintenance and/or ownership to me. This is a really great project and tool a would love to make it even more useable by:

adding it as conda package: https://github.com/indigoviolet/conda-pip-minimal/pull/3
adding a license: https://github.com/indigoviolet/conda-pip-minimal/pull/3
fixing semver only versions: https://github.com/indigoviolet/conda-pip-minimal/issues/5
adding pre-commit hooks

and probably much more!
Please let me know if this is something you are interested in.
For now, I'll be working on a fork to get some more functionality working!

Added you as collaborator - thank you for taking it on!

Amazing! Thanks Venky 🙏🏽


Use requests.Session and aiohttp.ClientSession instances with the client constructor argument

These changes enable users to pass requests.Session and aiohttp.ClientSession instances into the client parameter of the Consumer constructor:
# == Requests == #
import requests
requests_session = requests.Session()

# This is equivalent to GitHub(BASE_URL, client=uplink.RequestsClient(requests_session))
gh_sync = GitHub(BASE_URL, client=session)

# == Aiohttp == #
import aiohttp
aiohttp_session = aiohttp.ClientSession()

# This is equivalent to GitHub(BASE_URL, client=uplink.AiohttpClient(aiohttp_session))
gh_async = GitHub(BASE_URL, client=aiohttp_session)

In addition to the above change, here are some backend changes proposed in this pull request:

uplink.clients.get_client: Abstracts creation of a client instance
uplink.clients.register.handler: Register a hook into the client creation process

While implementation is going into v0.3.0, probably won't expose these later changes in the documentation for the next minor release.

Coverage decreased (-0.1%) to 96.059% when pulling 90b58a3a3a9ffcb250fdb9edcd749586875f9dda on feature/v0.3.0/client-register into 4a2cf8b50b2e23bf6c5113da015f0bb5ca137909 on master.

Coverage decreased (-0.1%) to 96.059% when pulling 90b58a3a3a9ffcb250fdb9edcd749586875f9dda on feature/v0.3.0/client-register into 4a2cf8b50b2e23bf6c5113da015f0bb5ca137909 on master.

Coverage decreased (-0.1%) to 96.059% when pulling 90b58a3a3a9ffcb250fdb9edcd749586875f9dda on feature/v0.3.0/client-register into 4a2cf8b50b2e23bf6c5113da015f0bb5ca137909 on master.

Coverage decreased (-0.1%) to 96.059% when pulling 90b58a3a3a9ffcb250fdb9edcd749586875f9dda on feature/v0.3.0/client-register into 4a2cf8b50b2e23bf6c5113da015f0bb5ca137909 on master.

Coverage decreased (-0.1%) to 96.086% when pulling 3d3559dffb6db5b5dd2dad644776e0b04cc67a73 on feature/v0.3.0/client-register into 4a2cf8b50b2e23bf6c5113da015f0bb5ca137909 on master.

Coverage decreased (-0.1%) to 96.086% when pulling 3d3559dffb6db5b5dd2dad644776e0b04cc67a73 on feature/v0.3.0/client-register into 4a2cf8b50b2e23bf6c5113da015f0bb5ca137909 on master.