Any reason why we can't have an OptionalGetter annotation?

I've read the responses to Optional around here and how the authors seem to generally hate it, and I agree that it pretty much never makes any sense to have an API take in some type Optional<T> parameter.
However, are there any arguments against having something like this? I saw something similar posted in this issue here, but it was never addressed before being closed.
public class Foo {
    @NonNull @OptionalGetter @Setter
    private String bar;
}

public class Foo {
    private String bar;

    public Optional<String> getBar() {
        return Optional.ofNullable(bar);
    }

    public void setBar(@NonNull String bar) {
        this.bar = bar;
    }
}

There are a lot of instances where I'd like to more clearly indicate "no value set yet" rather than just returning null to the caller.

Just to throw in a couple more arguments for adding this feature:

Optional getter is not against Optional design - see Stuart Marks Optional talk at 55:06
any kind of argument against using Optional because of boxing or performance considerations is invalid as the goal is to make Optional a value type in the future (same talk at [47:10])(https://youtu.be/Ej0sss6cq14?t=47m10s) => performance is a moving target but today's workarounds are tomorrow's technical debt (if you don't add this feature).

public class Foo {
    @NonNull @OptionalGetter @Setter
    private String bar;
}

IMHO, @NonNull shouldn't be there, as otherwise your "Optional" would be "Mandatory" (as you could never get absent). I guess, @OptionalGetter should imply @Nullable on the field (and setter argument), but the generated getter should be annotated with the @No[tn][Nn]ulls the user wants (configuration).

The purpose of @NonNull in this particular example was to be more restrictive in rejecting any nulls as arguments to the setter, which effectively allows the optional getter to only be empty if it hasn't been set yet. In other words if Foo.getBar() is empty, then it's guaranteed that hasn't been set yet. @NonNull just affects generated constructors/getters, right?
Perhaps it would have been more clear if I'd written the example like this:
public class Foo {
    @NonNull @OptionalGetter @Setter
    private String bar = null;
}

Anyway, after looking through the Lombok code, I think it might be easier to implement this feature instead as:
@Getter(optional=True)

There seems to be a lot of code to detect stacking Getter annotations that would need to be duplicated to handle OptionalGetter. I may try to implement support myself at some point, but in general, the scope of this project is way beyond my expertise :stuck_out_tongue:

@NonNull just affects generated constructors/getters, right?

Right. And you're right: Without generating a constructor, the field may be null even when annotated @NonNull. Forbidding to set it to null explicitly might make sense.

it might be easier to implement this feature instead as @Getter(optional=True)

I guess so. This precludes the possibility to generate also a normal getter, but having two getters would be pretty strange anyway. I wouldn't call the argument just optional, but rather useOptional or alike (as the getter isn't really optional).
A nicer possibility could be to use @UseOptionalGetters as a modifier, possibly on class level, or even a configuration, similar like @Accessors works.

In case of modifier at type level, it would be nice if bean validation annotations were also supported (@NotNull).

:+1: for an optional getters configuration.

+1

+1

I would really enjoy optional getters too. +1

+1

+1 please implement this feature, I came here to request this feature and did a search and found this github issue. I am in this same situation, specifically I am using Lombok with JPA, to generate my Business Entities. That works great, but I want to have Optional Getters, as JPA can't really map the type "Optional" directly.
Something like this would be amazing:
	@OptionalGetter
	@Column(nullable = true)
	private VehicleType type;

If you add this, I will dance at your wedding.
+1

+1

+1

+1

To make this future request less obtrusive you could also consider to introduce a additional getters for nullable fields. As Lombok is all about reducing boilerplate I would already be very happy with having ...AsOptional methods, i.e.
With Lombok:
@OptionalGetters
class Foo {

 String bar;
 @OptionalGetter(replaceGetter=true) String anotherBar;
}

Vanilla Java:
class Foo {
 String bar;
 String anotherBar;

 public String getBar() { return bar; }
 public String getBarAsOptional() { return Optional.ofNullable(bar); }
 public String setBar(String bar) { this.bar = bar; }

 public Optional<String> getAnotherBar() { return Optional.ofNullable(anotherBar); }
 public String setAnotherBar(String anotherBar) { this. anotherBar = anotherBar; }
}

Are you open to a PR for this?

Not sure whether we should create two methods, a “plain” value return and a separate “wrapped-in-optional” return. The point about Optional is to make the code safer and to avoid NPEs. But for achieving this, it shouldn’t be up to the consumer to decide which of the two accessors to use. A asOptional suffix also feels a bit like hungarian notation and only repeats information that is already provided in the signature. (This is a personal preference, though.)
I would prefer the following usage. It would be straightforward and avoids the ambiguity that arises when two annotations are present (e.g. @OptionalGetter and @Getter).
@Getter(optional=true)
class MyClass {

 String foo; // -> Optional<String> getFoo()

 @Getter(optional=false) // override for individual field
 String bar; // -> String getBar()
}

(optional=false) would be the default, for backwards compatibility. It can be set on class and on field level, where field level would take precedence.

They've talked about it before
https://stackoverflow.com/questions/31670785/optional-in-lombok
https://www.voxxed.com/2015/01/embracing-void-6-refined-tricks-dealing-nulls-java/
They even quote Brian Goetz, the Oracle engineer who introduced Optional:

You should almost never use it as a field of something or a method parameter. I think routinely using it as a return value for getters would definitely be over-use.

That said, I strongly disagree with their stance and I think this feature to allow Optional getters should be implemented.  Even in that Goetz quote its clear that sometimes using it as a return value for getters makes sense, which is all we're asking for here.

I think the arguments about not passing Optionals around are based in the
fact that Optional itself it is not serializable and it was deliberately
designed this way to avoid using it that way if I am not wrong. That's why
the reccommendation is against class members of type Optional.
But on contrary I can see use cases where the return of a getter can box
the field in an optional, that's why I also would like the Lombok optional
getter.
P.S. vavr (a great Java lib that provides functional programming
constructs) Option is serializable!
On Wed, Feb 13, 2019, 16:02 Ben<EMAIL_ADDRESS>wrote:

They've talked about it before
https://stackoverflow.com/questions/31670785/optional-in-lombok
https://www.voxxed.com/2015/01/embracing-void-6-refined-tricks-dealing-nulls-java/
They even quote Brian Goetz, the Oracle engineer who introduced Optional:
You should almost never use it as a field of something or a method
parameter. I think routinely using it as a return value for getters would
definitely be over-use.
That said, I strongly disagree with their stance and I think this feature
to allow Optional getters should be implemented. Even in that Goetz quote
its clear that sometimes using it as a return value for getters makes
sense, which is all we're asking for here.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/rzwitserloot/lombok/issues/1214#issuecomment-463231712,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AdT09IvmurwI0IHfHi-zwUq094R-AMFdks5vNCkWgaJpZM4KccUJ
.

Optional is not a replacement for null nor a fancy way to prevent NullPointerException.
(@rspilker, https://stackoverflow.com/questions/31670785/optional-in-lombok)

This is an unnecessary limited view. The Optional interface follows monadic laws (comparable to Maybe in Haskell and the like) and the above sentence is the exact purpose of such data structures when it comes to return types: representing something that can either be present or absent, and providing a standardised (i.e. common) way of safely interacting with it.

You should almost never use it as a field of something or a method parameter. I think routinely using it as a return value for getters would definitely be over-use.
(Brian Goetz, https://stackoverflow.com/questions/26327957/should-java-8-getters-return-optional-type)

Optional shouldn’t be used as field type, there is no doubt in that. And it’s certainly a bad practice to use it for method input parameters either. However, it makes a lot of sense as the return type for accessors of nullable (!) fields, because that ultimately allows for a safer and stricter programming style. (“not routinely” != “never”)
So it’s either:
// We might or might not find it:
Optional<Something> findSomethingById(@NonNull String id);

// We can guarantee at compile-time that it will always be there:
@NonNull
Something getSomething();

(Whether or not you write out the annotations is a different story of course, but you get the idea.)

Maybe it's just me but outside of the J2EE world I really do not see the
point of making anything Serializable. As long as you do not use RMI there
are other ways to serialise and deserialise data that do not require that
interface. As far as I can tell not even Hibernate really needs it anymore
for simple applications.
Given that Serializable feels like old deprecated nonsense I do not see the
point of not using Optional wherever you can, either. There is nothing
wrong with Optional<> fields per sé. Frameworks nowadays usually support
this just fine. Jackson does. JPA does. Hibernate sorta can but doesn't
(yet). So what is the reason that using this thing for fields is
discouraged?
Seriously: Why? People aren't discouraging the use of Collection<>, List<>
or Set<> either, so why is Optional<> any different?
On Thu, Feb 14, 2019 at 11:35 AM Jan Heuermann<EMAIL_ADDRESS>wrote:

Optional is not a replacement for null nor a fancy way to prevent
NullPointerException.
(@rspilker https://github.com/rspilker,
https://stackoverflow.com/questions/31670785/optional-in-lombok)
This is an unnecessary limited view. The Optional interface follows
monadic laws (comparable to Maybe in Haskell and the like) and the above
sentence is the exact purpose of such data structures when it comes to
return types: representing something that can either be present or absent,
and providing a standardised (i.e. common) way of safely interacting with
it.
You should almost never use it as a field of something or a method
parameter. I think routinely using it as a return value for getters would
definitely be over-use.
(Brian Goetz,
https://stackoverflow.com/questions/26327957/should-java-8-getters-return-optional-type
)
Optional shouldn’t be used as field type, there is no doubt in that. And
it’s certainly a bad practice to use it for method input parameters either.
However, it makes a lot of sense as the return type for accessors of
nullable (!) fields, because that ultimately allows for a safer and
stricter programming style. (“not routinely” != “never”)
So it’s either:
// We might or might not find it:
Optional findSomethingById(@NonNull String id);
// We can guarantee at compile-time that it will always be there:
@NonNull
Something getSomething();
(Whether or not you write out the annotations is a different story of
course, but you get the idea.)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/rzwitserloot/lombok/issues/1214#issuecomment-463578014,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCRauMa0rwQEP5-rHq-XO5T82VXRv5ks5vNTvfgaJpZM4KccUJ
.

--
"Don't only practice your art, but force your way into it's secrets, for it
and knowledge can raise men to the divine."
-- Ludwig von Beethoven

@randakar if you are fine with declaring fields as Optional, then you can do this today already and Lombok would generate the respective getter for you:
@Getter
private Optional<Something> sth;

The point of this thread is to introduce an accessor for nullable fields to Lombok that would wrap it in Optional “on the fly”. In order for this thread to stay focussed on this initial request I suggest to move the general discussion about optional fields to a different place.

Well, I don't get the problem with introducing Optional getter either.
Let's make it clear: optional is for API designers, so:

Optional should not be used as an argument, thus declaring field as Optional  does not make any sense. Optional is NOT for replacing null, so if one wants to set "no value" then null should be passed. API designer dictates if nulls are allowed or not, not you as a user.

Declaring a field as an Optional is asking for a trouble. Try anything that requires serialization into string, like converting to/from JSON representation and it will become clear what pain it is. That's because Optional was NOT designed to store value.

Optional however WAS designed for APIs. It exists to indicate to the user that returned value MAY not exist. This means that is perfectly fine to have: Optional getSomePossiblyOptionalProperty(). Consider a case of driver class often recalled. API may specify that some property of driver Optional getCache(). That's how user knows that cache may or may not be present and should handle the situation properly. It is much easier to make a mistake and ignore possible null if it would only be Cache getCache().

Summarizing and don't see any cons for Getter(optional = true), only pros.
Please reconsider @rzwitserloot .

"should not be used" - says who? And more importantly, why? I haven't
seen a single good reason to accept nulls anywhere, whereas I've seen lots
of reasons to not do so. The only good reason against Optional I've heard
so far is the serializable interface, which I consider a misdesigned
malfeature. And if you really need that there's still Vavr's alternative
version of this.
Serialisation into string works fine. Jackson does it without any
problems, just make sure you have the dependencies right and put a default
in. And if it doesn't - that's a bug in the serialisation framework, not
the use of Optional.
That distinction between use in an API and regular use is therefore
entirely artificial personal preference.

Summarizing: just make your field Optional<> and you will actually get all
the benefits of compile-time null check enforcement, instead of asking for
a workaround for something that doesn't make sense in the first place.
On Thu, Feb 21, 2019 at 10:47 AM raffig<EMAIL_ADDRESS>wrote:

Well, I don't get the problem with introducing Optional getter either.
Let's make it clear: optional is for API designers, so:

Optional should not be used as an argument, thus declaring field as
Optional does not make any sense. Optional is NOT for replacing null, so if
one wants to set "no value" then null should be passed. API designer
dictates if nulls are allowed or not, not you as a user.
2.
Declaring a field as an Optional is asking for a trouble. Try anything
that requires serialization into string, like converting to/from JSON
representation and it will become clear what pain it is. That's because
Optional was NOT designed to store value.
3.
Optional however WAS designed for APIs. It exists to indicate to the
user that returned value MAY not exist. This means that is perfectly fine
to have: Optional getSomePossiblyOptionalProperty(). Consider a case of
driver class often recalled. API may specify that some property of driver
Optional getCache(). That's how user knows that cache may or may not be
present and should handle the situation properly. It is much easier to make
a mistake and ignore possible null if it would only be Cache getCache().
Summarizing and don't see any cons for Getter(optional = true), only pros.
Please reconsider @rzwitserloot https://github.com/rzwitserloot .
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rzwitserloot/lombok/issues/1214#issuecomment-465932929,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCRVJkQZ3fpcnNwD91HJ6kl-NjTkFmks5vPmsjgaJpZM4KccUJ
.

--
"Don't only practice your art, but force your way into it's secrets, for it
and knowledge can raise men to the divine."
-- Ludwig von Beethoven

As per question why it should not be used as arguments short answer is: because there are better approaches as method overloading. For longer explenation see this article:
http://dolszewski.com/java/java-8-optional-use-cases/

Also you can take a look at this discussion: https://stackoverflow.com/questions/31922866/why-should-java-8s-optional-not-be-used-in-arguments

Sometimes works, sometimes not. Consider it as a bug and wait forever to be fixed. Even if it works it is a waste of resources IMHO for packing/unpacking when it has no practical advantage over simple null.

I don't get your point.

Summarizing - no, because with Setter annotation I get the setter(Optional) then, what is bad design as per point no. 1. So it is not a solution, sorry.

The builder would look even funnier. Imagine: WhateverBuilder.property(Optional).
Making field optional solves nothing and uses more resources.

I don't see how method overloading has anything to do with making fields
Optional<>. And that link you provide mentions that exact case as the most
controversional one, with " the main obstacle which prevents using
Optional as a POJO field is support of libraries and frameworks". Well,
it's now one and a half year later, that support has arrived or is in the
process of arriving, it's time to reconsider this.

I use it all the time. It works. A year or two ago it was a different
story maybe, but now I never have problems with it.

As for the practical advantage? Well. NullPointerException is the most
seen bug in production environments across the globe.
https://blog.overops.com/the-top-10-exceptions-types-in-production-java-applications-based-on-1b-events/
This means that anything you can do to prevent that exception from happing
will have a measureable impact on your bug count. And Optional<> was
designed to force developers to check this, so it will help prevent that
problem.
As for the setter .. don't really care. The method argument overloading
argument from that article doesn't apply. That's about having methods that
actually take decisions based on whether the argument is optional or not. A
setter however just puts the object somewhere and forgets about it. No bad
design at all, it's even faster than instantiating new Optionals whenever
someone calls the getter on that field.
On Thu, Feb 21, 2019 at 11:31 AM raffig<EMAIL_ADDRESS>wrote:

The builder would look even funnier. Imagine:
WhateverBuilder.property(Optional).
Making field optional solves nothing and uses more resources.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rzwitserloot/lombok/issues/1214#issuecomment-465947741,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCRVXxOeNRr3zq8ZZtkLngUjEHWtbkks5vPnWJgaJpZM4KccUJ
.

--
"Don't only practice your art, but force your way into it's secrets, for it
and knowledge can raise men to the divine."
-- Ludwig von Beethoven

ad. 1. It is easy:
Imagine two objects. One has:
makeSomething(Optional a, Optional b, Optional c)
How do you know what combinations are allowed? All parameters may be empty? Or maybe a & b must be present or b & c? Or mayby at least one? Nobody knows, unless you read the javadoc. If it exists :-). Imagine length of that javadoc. Imagine length of code for such method. It breaks most rules of good design. Waste of CPU, memory and what is most important your own, expensive time for reading two screens javadoc explaing how the hell this method should be used.
And now imagine other object with 3 methods:
makeSomething(a, b)
makeSomething(a, b, c)
makeSomething(b)
Ah, much clearer. Passing only a and c is not possible. I know that within 3 seconds. No javadoc? No problem! I still know that a & c is not enough. Each method has short, clear, easy to test implementation and short javadoc.
Maybe you would like to say that setA(Optional) is good example, because maybe value can be empty? Well, for what reason are you calling that setter at all then? To cleanup setA? Hey, method clearA() is much more obvious.
Sorry, I can't find any good example of using optional as an method argument. It only encourages bad, far from obvious design.

And yes, optional helps with NPE. As a returned value. For field it is at least debatable and for argument it is simply a bad design.

And here you go an answer from coauthor of Optional Brian Goetz:
https://stackoverflow.com/questions/26327957/should-java-8-getters-return-optional-type/26328555#26328555
I agree that people can do what they want, one can even stick nails with screwdriver, however I see no reason why that Optional Getter could not be introduced to lombok for people who still prefer hammers.

Let us please keep this thread focused on the initial request, which is to add a getter annotation to Lombok that would wrap a nullable field into Optional on the fly. While the general debate about Optional field types or Optional method parameters is certainly interesting, it doesn’t bring us forward in that matter here.

I agree, I just understood that there is no need or no reason to do this, regarding that this issue is rejected and close. This is why I provided number of reasons why Optional is useful and Optional Getter annotation would be great feature.

Hard to stop arguing when somebody is wrong on the internet.
https://xkcd.com/386/ ;-)
So feel free to stop reading.
Raffig:
Your "makeSomething()" call is besides the point. I agree that is how  you
should do that. But it's not talking about making a field Optional at all
so .. irrelevant.
Besides, I actually try to avoid setters. Setters are for mutable objects,
and objects should be immutable if at all possible. Put @Value on your
class and you won't have any setters.
Even if you had to have setters, if you read the argument against method
arguments it's talking about methods that have conditional logic based on
the content of the optional. A method that just copies a value into a field
of the same type is imho fine. Calling it with an empty optional is fine as
well - if this is just passing in data coming from somewhere else it simply
isn't the responsibility of that piece of code to care about it.
Finally, Brian Goetz - yes, that's that famously quoted example. It's
appeal to authority. He argues that it's not serializable (see earlier) and
that the get() method is poorly named and should not be used. Fair enough.
Doesn't mean Optional is unsuitable for a field, though.
On Thu, Feb 21, 2019 at 2:22 PM raffig<EMAIL_ADDRESS>wrote:

I agree, I just understood that there is no need or no reason to do this,
regarding that this issue is rejected and close. This is why I provided
number of reasons why Optional is useful and Optional Getter annotation
would be great feature.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rzwitserloot/lombok/issues/1214#issuecomment-465997417,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCRY1vJQzcLjPuk5sADsQo2gNIJjR2ks5vPp2jgaJpZM4KccUJ
.

--
"Don't only practice your art, but force your way into it's secrets, for it
and knowledge can raise men to the divine."
-- Ludwig von Beethoven

Summarizing:

Yes, getters should return Optional if it is possible that there is no value.
No, Optional should not be used as parameter - we have found no just cause to do this, every argument is against using Optional this way.
Optional actually could be used as field. Potential problem are serializations of any kind (Java serialization, JSON, Hibernate etc.). If that is not the case, then actually we found no good reason for not using Optional as field - use it or not, it is a matter of taste.

BUT, regarding Lombok features:
Making field Optional when getter AND setter are required dos not solve the problem of missing Optional Getter, as in this case Setter would be bad (see point no. 2 above). Also Builder should be considered with Optional fields so no strange methods were created.
This is why this issue is still valid and justified and I advocate reopen and accept :-)

I don't think it makes sense to argue here about how someone should use Optional. The fact is, there are multiple different opinions, with large groups behind each. For example, talk to anyone with a Scala background that is doing Java, and they will tell you that Optional should be used as much as possible in place of nulls everywhere, because that's exactly how Scala uses it with its equivalent Option type. Now whether they are right or wrong is beside the point, people with this opinion exist, and they form a significantly sized portion of the lombok user community, and would benefit from better support for Optional in lombok. As an example of such a community, the Java APIs for Play Framework, Lagom and Akka all make strong use of Optional in fields and as method parameters, and all three of those frameworks recommend using lombok for immutable Java classes. These are large communities that have this opinion, it's not a fringe view.
So the question is, is the use of Optional something that lombok itself should have an opinion on? I don't see why it should. Providing better support for Optional fields won't have any negative impacts on people whose opinion it is that you shouldn't use Optional fields, because they're not going to use Optional fields and so they'll never see that support. But it will certainly help those whose opinion it is that you can/should. And it doesn't seem to be a feature that would have a very high cost to implement or require significant refactoring in lombok. So why hold out on this portion of your users?


History is Broken for GDAX backtesting

Expected Behavior
self.History('BTCUSD', 60, Resolution.Minute)
Should return historical data
Actual Behavior

it returns
'1, Culture=neutral, PublicKeyToken=null]]'
Reproducing the Problem
def Initialize(self):         self.hist_data = self.History('BTCUSD', 10, Resolution.Minute)         print(self.hist_data[-1])
System Information
Ubuntu 16.04
Python 3.6.4
Latest Master
Checklist

[x] I have completely filled out this template
[x] I have confirmed that this issue exists on the current master branch
[x] I have confirmed that this is not a duplicate issue by searching [issues]
[x] I have provided detailed steps to reproduce the issue

Thanks @lacvapps for the issue! Can you please confirm:

Have the data in place?
You've got the AddCrypto in your algorithm (demo algo even better)
Backtesting or live mode?
Is it resolved with self.History( ['BTCUSD'], 10, Resolution.Minute) array notation?

@jaredbroad Thank you for the quick response I modified the basic crypto algorithm just now to test these things. I have the data downloaded and am able to run backtests without using History, It does not work with either notation. I receive this error when using the following code.
returned a result with an error set
or
print(self.hist_data[-1])  TypeError : unindexable object
`
`
class BasicTemplateCryptoAlgorithm(QCAlgorithm):
def Initialize(self):

    self.SetStartDate(2018, 3, 7)  #Set Start Date
    self.SetEndDate(2018, 3, 7)    #Set End Date
    self.SetCash(100000)          #Set Strategy Cash

    self.SetBrokerageModel(BrokerageName.GDAX, AccountType.Cash)

    # Find more symbols here: http://quantconnect.com/data
    self.AddCrypto("BTCUSD", Resolution.Minute)
    self.hist_data = self.History(['BTCUSD'], 60, Resolution.Minute)
    print(self.hist_data)

def OnData(self, data):
    '''OnData event is the primary entry point for your algorithm. Each new data point will be pumped in here.

    Arguments:
        data: Slice object keyed by symbol containing the stock data
    '''
    if self.Time.minute == 0:class BasicTemplateCryptoAlgorithm(QCAlgorithm):
'''Basic template algorithm simply initializes the date range and cash'''

def Initialize(self):
    '''Initialise the data and resolution required, as well as the cash and start-end dates for your algorithm. All algorithms must initialized.'''

    self.SetStartDate(2018, 3, 7)  #Set Start Date
    self.SetEndDate(2018, 3, 7)    #Set End Date
    self.SetCash(100000)          #Set Strategy Cash

    self.SetBrokerageModel(BrokerageName.GDAX, AccountType.Cash)

    # Find more symbols here: http://quantconnect.com/data
    self.AddCrypto("BTCUSD", Resolution.Minute)
    self.hist_data = self.History(['BTCUSD'], 60, Resolution.Minute)
    print(self.hist_data)

def OnData(self, data):
    '''OnData event is the primary entry point for your algorithm. Each new data point will be pumped in here.

    Arguments:
        data: Slice object keyed by symbol containing the stock data
    '''
    if self.Time.minute == 0:
        if not self.Portfolio.Invested:
            self.SetHoldings("BTCUSD", 1)
        else:
            self.Liquidate()

        btcHoldings = self.Portfolio.CashBook["BTC"].Amount
        usdCash = self.Portfolio.CashBook["USD"].Amount
        self.Log("{} - BTC holdings: {} - USD cash: {}".format(self.Time, btcHoldings, usdCash))

        if not self.Portfolio.Invested:
            self.SetHoldings("BTCUSD", 1)
        else:
            self.Liquidate()

class BasicTemplateCryptoAlgorithm(QCAlgorithm):
'''Basic template algorithm simply initializes the date range and cash'''
def Initialize(self):
    '''Initialise the data and resolution required, as well as the cash and start-end dates for your algorithm. All algorithms must initialized.'''

    self.SetStartDate(2018, 3, 7)  #Set Start Date
    self.SetEndDate(2018, 3, 7)    #Set End Date
    self.SetCash(100000)          #Set Strategy Cash

    self.SetBrokerageModel(BrokerageName.GDAX, AccountType.Cash)

    # Find more symbols here: http://quantconnect.com/data
    self.AddCrypto("BTCUSD", Resolution.Minute)
    self.hist_data = self.History(['BTCUSD'], 60, Resolution.Minute)
    print(self.hist_data)

def OnData(self, data):
    '''OnData event is the primary entry point for your algorithm. Each new data point will be pumped in here.

    Arguments:
        data: Slice object keyed by symbol containing the stock data
    '''
    if self.Time.minute == 0:
        if not self.Portfolio.Invested:
            self.SetHoldings("BTCUSD", 1)
        else:
            self.Liquidate()

        btcHoldings = self.Portfolio.CashBook["BTC"].Amount
        usdCash = self.Portfolio.CashBook["USD"].Amount
        self.Log("{} - BTC holdings: {} - USD cash: {}".format(self.Time, btcHoldings, usdCash))

        btcHoldings = self.Portfolio.CashBook["BTC"].Amount
        usdCash = self.Portfolio.CashBook["USD"].Amount
        self.Log("{} - BTC holdings: {} - USD cash: {}".format(self.Time, btcHoldings, usdCash))

`

In order to get a pandas.DataFrame from a History method call, we need to use the array notation, like @jaredbroad proposed, otherwise we get C# IEnumerable object.
That said, the data frame from the History method is a multi-index data frame. The first index is the Symbol as a string and the second one is the datetime (for derivatives, there are other indexes). We can see them when we plot the data frame (symbol and time indexes):
self.hist_data = self.History(['BTCUSD'], 60, Resolution.Minute)
self.Log(str(self.hist_data))

Output snippet:
                                    open     volume
symbol time
BTCUSD 2016-10-07 03:01:00+00:00  611.99  20.313877
       2016-10-07 03:02:00+00:00  611.97   0.404191
       2016-10-07 03:03:00+00:00  611.97   2.836366
       2016-10-07 03:04:00+00:00  611.98   5.631499
       2016-10-07 03:05:00+00:00  611.99   1.553840

You are getting print(self.hist_data[-1]) TypeError : unindexable object because you are trying to access data from a data frame with an index where this notation is used to access data from an array (pandas.Series). So you should extract the series from the data frame first:
self.hist_data = self.History(['BTCUSD'], 60, Resolution.Minute)
series = self.hist_data.loc['BTCUSD']['close']
self.Log(str(series[-1]))

Output: 612.25.


compose: Rename 'New stream message' to 'New topic'.

This doesn't update documentation, because we need to update that
anyway to show screenshots of the new compose box.

Merged.


slickGoTo method is ignored when called on "afterChange"

Hi there,
I'm using two carousels, one large image only carousel (with one slide to show and scroll, no dots or arrows, and not draggable) and another content carousel (with 2-4 slides to show and 1 to scroll, no dots or arrows, and not draggable) which acts as it's navigation.
Basically, due to the animations and transition speeds that I've used there's a second or two during the transtition between two slides that if you click on another slide during the transition it would disrupt the animations, so I locked the change on "beforeChange" and "afterChange".
I wanted to queue the clicked locked slide by calling $("contentCarousel").slick("slickGoTo", clickedIndex, false) in the "afterChange" event but this method is ignored. Is there a way around this?

I'm having a similar issue - I can't appear to change the carousel from within the afterChange event - is it still doing something in the background at this point?

use the waitForAnimate option to false.

Legend. Thank you very much, works great.


Missing Software From Search results

When searching for software using the extension some software doesn't show up. A couple of examples I tested so far are

mimikatz
nltest
Out1
Ping

Also some software do not show up until you type more not the initial for example "PJApps" doesn't show up until we add a third letter.

Btw this also applies to some searches as well. For example when searching for "threat actor" we get results but adding an "S" will show no results. Even though there exists in the Att&ck website for example.

When searching for software using the extension some software doesn't show up.

Thank you for pointing this out with specific examples. I'll make a PR today to fix it.

Also some software do not show up until you type more not the initial for example "PJApps" doesn't show up until we add a third letter.
…
Btw this also applies to some searches as well. For example when searching for "threat actor" we get results but adding an "S" will show no results. Even though there exists in the Att&ck website for example.

Some of these limitations are inherent to the fuse.js search library used inside ATT&CK Powered Suit (see #4). It is possible we could solve this with some tuning of the fuse.js settings, but it has some tradeoffs in terms of making some queries work better at the expense of other queries becoming worse. Please a comment on #4 if you have more examples of search queries that you don't think are working correctly.


Create dbt.var.get() for python models to retrieve project variables without a yaml file

Is this your first time submitting a feature request?

[X] I have read the expectations for open source contributors
[X] I have searched the existing issues, and I could not find an existing issue for this feature
[X] I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature
Create dbt.var.get() for python models to retrieve project variables without requiring yaml file.
I am narrowly requesting a var feature. However, this can be a small part of a larger initiative to get python at parity with SQL.
Describe alternatives you've considered
Here is a loom walking through the today solution.
The tl;dr is that python models don't have an argument such as dbt.var.get(). We have a dbt.config.get() but that argument is specific to each model (not global).
What we need to do today:

Give the model a passthrough variable for example, run_frequency.
Make a model specific yaml for your python model. This is really we need to do all python model configs if we want SQL parity.
Define the default you want, in this case 'Daily'  in the dbt_project.yml.
Pass the variable override in the command line as usual, in our example, 'Weekly'. So dbt run -s model_name  --vars '{"run_frequency": "Weekly"}'

Who will this benefit?
Our user base that is using python. I realize this is not the majority of users, but it would boost the python experience up to reduce the user experience and ergonomics divide between python and SQL in dbt.
Are you interested in contributing this feature?
Yes, I can be a tester.
Anything else?
No response

I really like this!

Our user base that is using Python

One challenge with adopting Python models is the limitations as you describe here, as well as PR like #8538. At my previous job, I was able to advocate for Python models due PySpark and able to test transformations, but it wasn’t without costs, as I encountered some limitations.
If @hope-wat can help with testing, I’d be happy to help implement this. I have some experience with how Python models work,  because of  #6317 and #8538.

I believe it's a good idea to continue allowing default values inside dbt.config.get because SQL models allow us to do the same within Jinja code

I thought a bit about how to do implement, and it's easy!


[RFC] Need more information about what metrics are exposed through 9108 port

Per https://github.com/infinityworksltd/Guide_Rancher_Monitoring , we can expose metric port during Rancher server startup by using -p 9108:9108. Customer would like to know what metrics are exposed, a full list is required.

Useful
Info

Versions
Rancher v1.6.2 Cattle: v0.181.4 UI: v1.6.5

Access
localauth admin

Orchestration
Cattle

Route
stacks.index

Rancher doesn't export anything on port 9108.
See: https://github.com/rancher/rancher/blob/master/server/Dockerfile
Based on the repo shared, it sounds like that port is being used by prometheus to do something.

@pengjiang80
https://github.com/rancher/rancher/blob/master/server/artifacts/metric-map.conf
Maybe this is useful to you


[UT] Fix a config overwritten issue in UT

What changes were proposed in this pull request?
(Please fill in changes proposed in this fix)
(Fixes: #ISSUE-ID)
How was this patch tested?
(Please explain how this patch was tested. E.g. unit tests, integration tests, manual tests)
(If this patch involves UI changes, please attach a screenshot; otherwise, remove this)

lgtm, thank you @PHILO-HE

lgtm, thank you @PHILO-HE

Thanks for your review!


Move source compilation to a build step, closes #233

OK, here's what we have here:

Created new grunt task 'buildsources' which reads the polyfills dir and produces two files, sources.json and aliases.json in the polyfill directory
Run that task on install, and also as part of the test and deploy tasks (so a failure to build sources is a CI fail)
Moved the Promise polyfill so that promises are available to grunt tasks and when the service is being used as a library (this was working before because I was using a 0.11 version of Node)
Refactored and updated gitignore so that the historic polyfills and the new compiled sources and aliases files are not committed
Moved the feature-gating logic to run on demand rather than when sources are compiled, to reduce the footprint of and avoid repetition of code in the compiled sources file.  A side effect of this is that minified outputs contain some line breaks because the feature-detect code is added post-minification.  Not a big deal.

@samgiles suggested that the compilation be two tasks, one for install, one for test, but I tend to disagree - the only impact of keeping it in one is that if the polyfill code is invalid, the service won't start, which actually seems like a reasonably good thing, as well as being a bit simpler.
What do you think?

@samgiles could you review this?

Ah, sorry, I did review this but forgot to actually press 'Comment'.
This looks good, I think I still prefer the idea of having the tasks separate but can't remember the concrete reason why.  This makes sense as it is now.


Common trait for Client and Server

It's convenient to implement logic around a gRPC interface independently of whether the implementation is local or remote. This enables incremental decomposition and testability.
Specifically:
In generated code, I have something like:
pub mod client {
    #[derive(Debug)]
    pub struct Iface<T> {
        inner: grpc::Grpc<T>,
    }

    impl<T> Iface<T>
    where T: tower_h2::HttpService,
    {
        pub fn new(inner: T) -> Self {
            let inner = grpc::Grpc::new(inner);
            Self { inner }
        }

        pub fn poll_ready(&mut self) -> futures::Poll<(), grpc::Error<T::Error>> {
            self.inner.poll_ready()
        }

        pub fn get(&mut self, request: grpc::Request<Get>) -> grpc::server_streaming::ResponseFuture<Update, T::Future>
        where grpc::unary::Once<Get>: grpc::Encodable<T::RequestBody>,
        {
            ...
        }
    }
}

pub mod server {
    ...

    pub trait Iface: Clone {
        type GetStream: futures::Stream<Item = Update, Error = grpc::Error>;
        type GetFuture: futures::Future<Item = grpc::Response<Self::GetStream>, Error = grpc::Error>;

        fn get(&mut self, request: grpc::Request<Get>) -> Self::GetFuture;
    }

   ...
}

I propose that:

the trait Iface definition is moved from the server module to the parent, without the Clone bound.
fn poll_ready is added to the service trait
the server module defines trait Iface: super::Iface + Clone;
the client module provides an impl super::Iface

If this is done, code that interacts with grpc interfaces can be generic on Iface rather than the underlying Http service.  This makes it easy to implement an Iface in tests, for instance, to mock client behavior.

It's convenient to implement logic around a gRPC interface independently of whether the implementation is local or remote. This enables incremental decomposition and testability.

Just for the record, could you elaborate a bit on this w/ some examples?

@carllerche In Conduit, we have a Destination service. The proxy has a client to this service, and we have code that, given such a client, interacts with the service. I want to provide a mocked, local implementation of this service (1) without writing an HTTP service that speaks gRPC and (2) without binding a socket.
Furthermore, the module that interacts with the Destination service has to be generic over the underlying HTTP client:
https://github.com/runconduit/conduit/blob/b078a27a828464cfde2f02efcb33c1c5cb3161e6/proxy/src/control/destination/background.rs#L99-L104
I argue that having to expose the HTTP-ness of the client is a leaky abstraction: the value proposition of gRPC is that one can write code to the interface and not the transport. This is achievable if the gRPC interface is exposed as a trait that covers both server and client implementations (as is par for the course in other IDL-binders like twitter/scrooge).

Ok, this seems like a good change. I would just say that the server should not define another trait. Instead, it can just add a Clone bound where needed.

Having worked at this some, I have some notes:
In order to have a trait be truly generic, the trait would need to grow associated types for each of the request bodies as well. The current server trait doesn't require this, since we can assume the the bodies are coming from a tower_h2 server implementation, and thus hard-code tower_h2::RecvBody.
We can add a type RecordRouteClientStream: Stream<...> = grpc::Streaming<Point> to the service, such that implementing for a server doesn't require you to define them, since they are the default.
The client currently defines the generics on the methods, which allows the client generation code to not need to know the exact types when generating. To implement the trait for the client, we'd need to dictate what client streaming types they must use...

I'm wrong, turns out default associated types are unstable. ;_;
An alternative is to generate 2 traits, a "lower-level" fully generic trait, and "server" trait, and provide a blanket impl such that if you implement the server trait, it is also the generic trait... Can this work?

Before going too far, it might be worth revisiting the original goal, which was to abstract local vs remote servers.
Can this be done at the Service level? The client takes a service and all calls go through that. The service can be a remote call or it could be the service impl. The service is a much simpler trait and might be easier to abstract over.

What specifically are you referring to? The client is already generic over a service.

@seanmonstar right, my question is whether this is enough and if not, why?

I suppose from a purity point of view, the naming is leaking that it's grpc over tower-h2.
For the other original purpose, I think we can mock a client by just providing a our own HttpService implementation. Is there a reason that isn't OK?

I believe that this issue is an argument for https://github.com/tower-rs/tower/issues/99
In this case, we would not need an associated request body type for each gRPC method.


Error with scipy 1.8.0

I am getting an error with scipy 1.8.0
File "/home/brendan/python/TestVenv/lib/python3.8/site-packages/bayes_opt/util.py", line 65, in acq_max
if max_acq is None or -res.fun[0] >= max_acq:
TypeError: 'float' object is not subscriptable

The problem appears to be that in this new version of scipy, res.fun is returned as a number instead of an array.
I haven't yet found exactly where in scipy the change is. A fix may be as simple as adding an if statement to handle this case.
I'll keep looking into it but for now I suggest limiting scipy installations to 1.7 or less.

I have the same problem. I used   pip install scipy==1.7  and it seems to work.

Came here with the same issue. pip install scipy==1.7 fixed it for me as well.

yeah, same issue, fixed with pip install scipy==1.7

Same, pip install scipy==1.7 did it for me

Glad to see others have reproduced this issue,
#319 should handle this in a version-explicit way.
Thanks!

hey all, just an update on this.
I have permissions to manage this repository now and I have merged #303 into the main branch, which should resolve this error. However, I am still not able to release the code through pypi or conda forge. I will keep trying to get these permissions, but for now I would recommend installing directly from the master branch like this:
 pip install git+https://github.com/fmfn/BayesianOptimization

@bwheelz36 Any update on this? For a package with 6.1k stars, getting this fix pushed to PyPI/conda would seem to be quite critical.

Agreed, the problem is I don't actually have the rights to do that yet. I'll try to get in touch with Fernando again though, thanks for the reminder.

Assuming I get the rights, I can handle the pypi release - does anyone want to volunteer to help with the conda release? I guess I could figure it out but I don't normally use conda...

As far as I am concerned, this has NOT fixed, after I downgraded scipy version to 1.70 and installed "pip install git+https://github.com/fmfn/BayesianOptimization" I still got the same error, can anyone explain why?

Should I only do ONE of the above, namely either downgrade Scipy OR install Master branch of the repo, not both?

@xxl4tomxu98 - either should fix it. if you install scipy version 1.8, install from the master branch here (which will also work with scipy 1.7)
if you pip install, make sure you have scipy version <1.8.
the most likely explanation as to why it didn't work when you downgraded to 1.7 is that somehow you hadn't actually downgraded with 1.7, or you did then it later got updated somehow. you could check:
import scipy
scipy.__version__

well, I do conda list and checked to see scipy is V1.7

My bayes_opt is also installed with conda

Hi @daeh
Thanks! I'm not sure if you already read through #339 - basically the conda package should get updated once the pypi package gets updated, which should happen when I get the rights to it..

@bwheelz36, I'm still getting this error - I tried installing with pip, conda, and github, tried scipy==1.7 and 1.8, each on both python 3.10 and python 3.7. I see this was closed but am curious if this fix was uploaded?
In which environment does this work? Note I'm on Apple Silicon (M1 pro)
SETUP:
pbounds = {
    'n_estimators': (1, 50),
    'max_depth': (4, 40),
    'learning_rate': (0.3, 0.3),
    'colsample_bytree': (0.5, 1.),
    'min_child_weight': (1, 14),
    'subsample': (0.5, 1.),
    'reg_alpha': (0, 6),
    'reg_lambda': (1, 6),
    'gamma': (1, 6)
}

optimizer = BayesianOptimization(
    f=fit_bayesian,
    pbounds=pbounds,
    random_state=1
)

optimizer.maximize(
    init_points=2,
    n_iter=6,
)

ERROR:
/var/folders/96/g2vfz16s07jb12xnxmvl1zc80000gp/T/ipykernel_94169/80009563.py in <module>
      1 optimizer.maximize(
      2     init_points=2,
----> 3     n_iter=6,
      4 )

/opt/anaconda3/envs/bayes/lib/python3.7/site-packages/bayes_opt/bayesian_optimization.py in maximize(self, init_points, n_iter, acquisition_function, acq, kappa, kappa_decay, kappa_decay_delay, xi, **gp_params)
    309                 x_probe = self.suggest(util)
    310                 iteration += 1
--> 311             self.probe(x_probe, lazy=False)
    312
    313             if self._bounds_transformer and iteration > 0:

/opt/anaconda3/envs/bayes/lib/python3.7/site-packages/bayes_opt/bayesian_optimization.py in probe(self, params, lazy)
    206             self._queue.add(params)
    207         else:
--> 208             self._space.probe(params)
    209             self.dispatch(Events.OPTIMIZATION_STEP)
    210

/opt/anaconda3/envs/bayes/lib/python3.7/site-packages/bayes_opt/target_space.py in probe(self, params)
    234         x = self._as_array(params)
    235         params = dict(zip(self._keys, x))
--> 236         target = self.target_func(**params)
    237
    238         if self._constraint is None:

/var/folders/96/g2vfz16s07jb12xnxmvl1zc80000gp/T/ipykernel_94169/129796447.py in fit_bayesian(n_estimators, max_depth, learning_rate, colsample_bytree, min_child_weight, subsample, reg_alpha, reg_lambda, gamma)
     39             reg_alpha=reg_alpha,
     40             reg_lambda=reg_lambda,
---> 41             gamma=gamma
     42             )
     43

/var/folders/96/g2vfz16s07jb12xnxmvl1zc80000gp/T/ipykernel_94169/2885977117.py in fit_model(X_train, y_train, n_estimators, max_depth, learning_rate, colsample_bytree, min_child_weight, subsample, reg_alpha, reg_lambda, gamma)
     25             reg_lambda=reg_lambda,
     26             gamma=gamma)
---> 27         cv_model = model.fit(X_train, y_train)
     28
     29         return cv_model

/opt/anaconda3/envs/bayes/lib/python3.7/site-packages/xgboost/core.py in inner_f(*args, **kwargs)
    573         for k, arg in zip(sig.parameters, args):
    574             kwargs[k] = arg
--> 575         return f(**kwargs)
    576
    577     return inner_f

/opt/anaconda3/envs/bayes/lib/python3.7/site-packages/xgboost/sklearn.py in fit(self, X, y, sample_weight, base_margin, eval_set, eval_metric, early_stopping_rounds, verbose, xgb_model, sample_weight_eval_set, base_margin_eval_set, feature_weights, callbacks)
    970             verbose_eval=verbose,
    971             xgb_model=model,
--> 972             callbacks=callbacks,
    973         )
    974

/opt/anaconda3/envs/bayes/lib/python3.7/site-packages/xgboost/core.py in inner_f(*args, **kwargs)
    573         for k, arg in zip(sig.parameters, args):
    574             kwargs[k] = arg
--> 575         return f(**kwargs)
    576
    577     return inner_f

/opt/anaconda3/envs/bayes/lib/python3.7/site-packages/xgboost/training.py in train(params, dtrain, num_boost_round, evals, obj, feval, maximize, early_stopping_rounds, evals_result, verbose_eval, xgb_model, callbacks, custom_metric)
    176     bst = cb_container.before_training(bst)
    177
--> 178     for i in range(start_iteration, num_boost_round):
    179         if cb_container.before_iteration(bst, i, dtrain, evals):
    180             break

TypeError: 'numpy.float64' object cannot be interpreted as an integer

I think that this is a different error, unrelated to this package. Either start_iteration or num_boost_round is a float/np.float64 when it should be of type int. Can you please post your fit_bayesian function, too?


run ios & doctor TypeError: Converting circular structure to JSON

Makes sure these boxes are checked befor submitting your issue - thank you!

[X] If you encounter any problems using the tool, please check if there has a new version to update(Run weex update [pluginname]@latest).
[X] Check the FAQ, make sure there have not the same issue.

Your development environment

Check weex-toolkit verison (Run weex -v)

2.0.0-beta.26 (Core 2.0.0-beta.26)
- @weex-cli/generator : v2.0.0-beta.16
- @weex-cli/doctor : v2.0.0-beta.20
- @weex-cli/lint : v2.0.0-beta.2
- @weex-cli/debug : v2.0.0-beta.26
- @weex-cli/compile : v2.0.0-beta.24
- @weex-cli/run : v2.0.0-beta.21
- @weex-cli/device : v2.0.0-beta.2
- @weex-cli/build : v2.0.0-beta.15
- @weex-cli/plugin : v2.0.0-beta.22

Detect what's wrong with your environment (Run weex doctor)

Time: 10:20:51, verify if there is an update
⠏ TypeError: Converting circular structure to JSON
    at JSON.stringify (<anonymous>)
    at <anonymous> (/Users/dseeker/.wx/core/node_modules/_@weex-cli_core@2.0.0-beta.26@@weex-cli/core/src/cli/cli.ts:540:46)
    at Generator.next (<anonymous>)
    at fulfilled (/Users/dseeker/.wx/core/node_modules/_@weex-cli_core@2.0.0-beta.26@@weex-cli/core/lib/cli/cli.js:4:58)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:189:7)

Which platform (Win/Mac/Ubuntu..)
macOS 10.13.6

The key error stack message.
Time: 10:20:51, verify if there is an update
⠏ TypeError: Converting circular structure to JSON
    at JSON.stringify (<anonymous>)
    at <anonymous> (/Users/dseeker/.wx/core/node_modules/_@weex-cli_core@2.0.0-beta.26@@weex-cli/core/src/cli/cli.ts:540:46)
    at Generator.next (<anonymous>)
    at fulfilled (/Users/dseeker/.wx/core/node_modules/_@weex-cli_core@2.0.0-beta.26@@weex-cli/core/lib/cli/cli.js:4:58)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:189:7)

Steps to reproduce the problem.(Maybe a dotwe link)
Unsure. Was working until last week. npm run web still works but npm run ios is stuck on this error

@dseeker I have fixed this issue, please try weex repair command to fix it.

repair worked and doctor gives this result, thanks for the quick response
✔ Weex Cli Environment (v2.0.0-beta.27, on darwin 17.7.0):

[✔] @weex-cli/core  - core module for the weex-toolkit
[✔] @weex-cli/generator - Generator for weex-toolkit
[✔] @weex-cli/doctor - Doctor module for weex-toolkit
[✔] @weex-cli/lint - Lint module for weex-toolkit
[✔] @weex-cli/debug - Module for debug weex file
[✔] @weex-cli/compile - Plugin for compile weex file.
[✔] @weex-cli/run - module for running iOS/Android/Web platform with weex-toolkit
[✔] @weex-cli/device - module for lanuch device with weex-toolkit
[✔] @weex-cli/build - Build module for weex-toolkit
[✔] @weex-cli/plugin - Module for manage weex plugin and create plugin project

I'm still getting this after about two to three weeks, everything works, but update returns an error
> weex run ios

Time: 17:1:19, verify if there is an update
[✖] Unkonw error with checking [@weex-cli/generator], can't found @weex-cli/generator latest version
[✖] Unkonw error with checking [@weex-cli/doctor], can't found @weex-cli/doctor latest version
[✖] Unkonw error with checking [@weex-cli/lint], can't found @weex-cli/lint latest version
[✖] Unkonw error with checking [@weex-cli/debug], can't found @weex-cli/debug latest version
[✖] Unkonw error with checking [@weex-cli/compile], can't found @weex-cli/compile latest version
[✖] Unkonw error with checking [@weex-cli/run], can't found @weex-cli/run latest version
[✖] Unkonw error with checking [@weex-cli/device], can't found @weex-cli/device latest version
[✖] Unkonw error with checking [@weex-cli/build], can't found @weex-cli/build latest version
[✖] Unkonw error with checking [@weex-cli/plugin], can't found @weex-cli/plugin latest version


tx hash should be displayed even it is pending

Is it always unable to display? Did the transaction send successfully?
Just tested, it's able to display on my side.

Is it always unable to display? Did the transaction send successfully?
Just tested, it's able to display on my side.

Changed the way to generate tx hash off chain and tested ok. Could you try again? Thanks @katat

Changed the way to generate tx hash off chain and tested ok. Could you try again? Thanks @katat


Picture at the top incompatible with dark mode

I had to switch between dark and light mode in order to be able to read the blue text in the picture at the top of the article.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 2c075d54-1d74-18f5-4fe1-efb8d4a2e114
Version Independent ID: e5c52c87-5f62-63ca-1331-ab3128806d97
Content: Managing Applications with Azure Active Directory
Content Source: articles/active-directory/manage-apps/what-is-application-management.md
Service: active-directory
GitHub Login: @barbkess
Microsoft Alias: barbkess

@fullenw1
Thanks for your feedback! We will investigate and update as appropriate.

@fullenw1 I can see this clearly in both modes. I have assigned the issue to the content author, @barbkess , to look into.

Here is how I see it in dark mode here:
https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/what-is-application-management

@fullenw1 : Thanks for sending this issue.  I have created a backlog item to get this fixed.  It should get fixed very soon.

@fullenw1 : We created a new image and this is fixed now.
#please-close


Can't run tests or build on latest nightly

What version of Rust are you using (rustc --version)?

rustc 1.24.0-nightly (edbd7d232 2017-12-20)

What operating system and processor architecture are you using?

Mac OS X 10.13.2 x86-64

What did you do?

Assuming rustup is installed and the latest nightly toolchain is installed.
git clone git@github.com:pingcap/tikv.git
cargo +nightly test

What did you expect to see?

No build failure.

What did you see instead?

$ cargo +nightly build
   Compiling rustc-serialize v0.3.19
   Compiling tipb v0.0.1 (https://github.com/pingcap/tipb.git#4fed9b6c)
   Compiling syn v0.11.11
   Compiling idna v0.1.0
   Compiling zstd-sys v1.4.1+zstd.1.3.2 (https://github.com/gyscos/zstd-rs.git#a3b05c8a)
   Compiling sys-info v0.5.1
   Compiling dbghelp-sys v0.2.0
   Compiling kernel32-sys v0.2.2
   Compiling ws2_32-sys v0.2.1
   Compiling solicit v0.4.4
   Compiling num-iter v0.1.32
   Compiling unicase v1.4.0
error[E0642]: patterns aren't allowed in methods without bodies
   --> /Users/hoverbear/.cargo/registry/src/github.com-1ecc6299db9ec823/rustc-serialize-0.3.19/src/serialize.rs:147:45
    |
147 |                                             &f_name: &str,
    |                                             ^^^^^^^

   Compiling grpcio-sys v0.1.2
   Compiling librocksdb_sys v0.1.0 (https://github.com/pingcap/rust-rocksdb.git#20d39998)
   Compiling snappy-sys v0.1.0 (https://github.com/busyjay/rust-snappy.git?branch=static-link#be021783)
   Compiling backtrace-sys v0.1.15
   Compiling lz4-sys v1.8.0 (https://github.com/busyjay/lz4-rs.git?branch=adjust-build#41509fea)
   Compiling bzip2-sys v0.1.6 (https://github.com/alexcrichton/bzip2-rs.git#b82dee62)
   Compiling aho-corasick v0.5.3
error: aborting due to previous error

error: Could not compile `rustc-serialize`.
warning: build failed, waiting for other jobs to finish...
error: build failed

Diagnosis
This comes from a bug which was fixed in https://github.com/rust-lang-deprecated/rustc-serialize/pull/169, and released as 0.3.21
TiKV includes a Cargo.lock which, as a binary, is appropriate. One line in the Cargo.lock is this:
https://github.com/pingcap/tikv/blob/8577330ae1ddb9483068d0fae79343b88000b70a/Cargo.lock#L310-L328
The offending line is this:
https://github.com/pingcap/tikv/blob/8577330ae1ddb9483068d0fae79343b88000b70a/Cargo.lock#L321
We pull in this version of hyper via the rust-prometheus dependency:
https://github.com/pingcap/tikv/blob/8577330ae1ddb9483068d0fae79343b88000b70a/Cargo.lock#L657-L671
rust-prometheus does not depend on this particular version of hyper:
https://github.com/pingcap/rust-prometheus/blob/f24ea12943e03da7412e2e2310e6d955e2004887/Cargo.toml#L48-L53
Resolution
We can solve this by either manually bumping the rustc-serialize version required via:
cargo update --package rustc-serialize

Or we can run cargo update and make a PR to update other dependencies.
According to semver this should be fairly safe since we're locking our dependencies to compatible versions in the Cargo.toml. Unfortunately, due to a git based dependencies we have failures:

Lots of `cargo +nightly test` output

$ cargo +nightly test
# ...
   Compiling rocksdb v0.3.0 (https://github.com/pingcap/rust-rocksdb.git#51a5c0c8)
error[E0432]: unresolved import `tipb::select::SelectRequest`
  --> src/coprocessor/endpoint.rs:20:38
   |
20 | use tipb::select::{self, DAGRequest, SelectRequest};
   |                                      ^^^^^^^^^^^^^ no `SelectRequest` in `select`
error[E0432]: unresolved import tipb::select::SelectRequest
--> src/coprocessor/select/select.rs:16:36
|
16 | use tipb::select::{Chunk, RowMeta, SelectRequest, SelectResponse};
|                                    ^^^^^^^^^^^^^ no SelectRequest in select
error[E0432]: unresolved import tipb::select::SelectRequest
--> src/coprocessor/endpoint.rs:20:38
|
20 | use tipb::select::{self, DAGRequest, SelectRequest};
|                                      ^^^^^^^^^^^^^ no SelectRequest in select
error[E0432]: unresolved import tipb::select::SelectRequest
--> src/coprocessor/select/xeval/evaluator.rs:690:9
|
690 |     use tipb::select::SelectRequest;
|         ^^^^^^^^^^^^^^^^^^^^^^^^^^^ no SelectRequest in select
error[E0432]: unresolved import tipb::select::SelectRequest
--> src/coprocessor/select/select.rs:16:36
|
16 | use tipb::select::{Chunk, RowMeta, SelectRequest, SelectResponse};
|                                    ^^^^^^^^^^^^^ no SelectRequest in select
warning: unused import: str
--> src/coprocessor/dag/expr/compare.rs:14:11
|
14 | use std::{str, i64};
|           ^^^
|
= note: #[warn(unused_imports)] on by default
warning: unused import: str
--> src/coprocessor/dag/expr/compare.rs:14:11
|
14 | use std::{str, i64};
|           ^^^
|
= note: #[warn(unused_imports)] on by default
error[E0599]: no method named set_recursion_limit found for type protobuf::CodedInputStream<'_> in the current scope
--> src/coprocessor/endpoint.rs:318:20
|
318 |                 is.set_recursion_limit(recursion_limit);
|                    ^^^^^^^^^^^^^^^^^^^
error[E0599]: no method named set_recursion_limit found for type protobuf::CodedInputStream<'_> in the current scope
--> src/coprocessor/endpoint.rs:329:20
|
329 |                 is.set_recursion_limit(recursion_limit);
|                    ^^^^^^^^^^^^^^^^^^^
error[E0599]: no method named set_recursion_limit found for type protobuf::CodedInputStream<'_> in the current scope
--> src/coprocessor/endpoint.rs:345:20
|
345 |                 is.set_recursion_limit(recursion_limit);
|                    ^^^^^^^^^^^^^^^^^^^
error: aborting due to 5 previous errors
error: Could not compile tikv.
warning: build failed, waiting for other jobs to finish...
error[E0599]: no method named set_recursion_limit found for type protobuf::CodedInputStream<'_> in the current scope
--> src/coprocessor/endpoint.rs:318:20
|
318 |                 is.set_recursion_limit(recursion_limit);
|                    ^^^^^^^^^^^^^^^^^^^
error[E0599]: no method named set_recursion_limit found for type protobuf::CodedInputStream<'_> in the current scope
--> src/coprocessor/endpoint.rs:329:20
|
329 |                 is.set_recursion_limit(recursion_limit);
|                    ^^^^^^^^^^^^^^^^^^^
error[E0599]: no method named set_recursion_limit found for type protobuf::CodedInputStream<'_> in the current scope
--> src/coprocessor/endpoint.rs:345:20
|
345 |                 is.set_recursion_limit(recursion_limit);
|                    ^^^^^^^^^^^^^^^^^^^
error: aborting due to 6 previous errors
error: Could not compile tikv.
To learn more, run the command again with --verbose.

Given that we're currently locking our rustc version in the Rust dockerfile:
https://github.com/pingcap/tikv/blob/8577330ae1ddb9483068d0fae79343b88000b70a/docker/rust_dockerfile#L40-L42
As well as the circle.yml:
https://github.com/pingcap/tikv/blob/8577330ae1ddb9483068d0fae79343b88000b70a/circle.yml#L11
We can even take this chance update them.
Acceptance Criteria
rustup update nightly && cargo +nightly test builds, and all CI tests pass.

Thanks @Hoverbear
Now another reason for us to use 08-09 nightly version is that we use rustfmt 0.2.1 nightly version which can't be installed with the newest rust version, and if we upgrade rustfmt, we need to change lots of codes which may introduce many conflicts with current PRs, :sob:
But upgrading has to be considered now, our rust version seems too old.
/cc @BusyJay @overvenus

+1 for upgrading Rust.
Before upgrading I suggest test it for a while, we have encountered a problem
that  may be casued by the "latest" rust rustc 2016-12-19. https://github.com/rust-lang/rust/issues/37105


Incorrect number of Pods shown by kubectl when scaling Replication Controller

A Replication Controller is started using https://github.com/arun-gupta/kubernetes-java-sample/blob/master/wildfly-rc.yaml and shows:
./cluster/kubectl.sh create -f ~/workspaces/kubernetes-java-sample/wildfly-rc.yaml replicationcontrollers/wildfly-rc

Pods are shown correctly as:
./cluster/kubectl.sh get -w po
NAME               READY     STATUS    RESTARTS   AGE
wildfly-rc-k6pk2   1/1       Running   0          47s
wildfly-rc-wez29   1/1       Running   0          47s

Scaled up by 1 (config file has 2) as:
./cluster/kubectl.sh scale --replicas=3 rc wildfly-rc

and the output is updated correctly:
NAME               READY     STATUS    RESTARTS   AGE
wildfly-rc-aqaqn   0/1       Pending   0          0s
wildfly-rc-aqaqn   0/1       Pending   0         0s
wildfly-rc-aqaqn   0/1       Pending   0         0s
wildfly-rc-aqaqn   0/1       Running   0         2s
wildfly-rc-aqaqn   1/1       Running   0         11s

Replicas are then reduced to 1:
./cluster/kubectl.sh scale --replicas=1 rc wildfly-rc

and the output shows:
wildfly-rc-wez29   1/1       Running   0         1m
wildfly-rc-aqaqn   1/1       Running   0         36s

Ctrl+C and view the list of pods running shows:
./cluster/kubectl.sh get -w po
NAME               READY     STATUS    RESTARTS   AGE
wildfly-rc-k6pk2   1/1       Running   0          2m

Seems like the previous two pods were killed but their status was still updated to Running. This is inconsistent with the current state of Pods running.

So the problem is with the event definition:
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/watch/watch.go#L51
type Event struct {
	Type EventType

	// Object is:
	//  * If Type is Added or Modified: the new state of the object.
	//  * If Type is Deleted: the state of the object immediately before deletion.
	//  * If Type is Error: *api.Status is recommended; other types may make sense
	//    depending on context.
	Object runtime.Object
}

If you scale down a RC then the event received by kubectl has type DELETED and the printed state is from just before the deletion.

cc @lavalamp

Agree, although I'd say the event definition is not the problem, rather kubectl's interpretation of the event is. :)

See also #17612


add this school

http://osvukkaradzic-krnjevo.edu.rs/

There are several files in the request, along with file.zip. It must not be there. Please remove file.zip and make pull request again.  I have to close this request without merging. Thank you for your understanding.


add traffic shaping

add channel traffic shaping for zuul

This seems more like a feature that you may want in your own app, rather than something that needs to be part of the core.

I think traffic shaping is a basic feature of gateway, especially for every channel.


Issue with NSwag v<IP_ADDRESS>: Swagger not loading and C# client code not generating for endpoints returning Task<MediatR.Unit>

I'm currently using NSwag v<IP_ADDRESS> in my project, and I've encountered an issue where Swagger does not load and the C# client code is not generated for endpoints returning Task<MediatR.Unit>.
Reproduction Steps:

Define an endpoint with a return type of Task<MediatR.Unit>.
Attempt to load Swagger UI or generate C# client code using NSwag.

Expected Behavior:
Swagger UI should load successfully, and C# client code should be generated for endpoints returning Task<MediatR.Unit>, similar to how it worked with Swashbuckle.
Actual Behavior:
Swagger UI does not load, and C# client code is not generated for endpoints returning Task<MediatR.Unit>.
Code Snippet:
[HttpPost]
public async Task<BaseResponse<Unit>> Create([FromBody] InvoiceDetail invoiceDetail)
{
  var result = await _mediator.Send(new CreateInvoiceDetailCommand { InvoiceDetail = invoiceDetail });
    return result;
}

[HttpPost]
public async Task<Unit> Create([FromBody] InvoiceDetail invoiceDetail)
{
  var result = await _mediator.Send(new CreateInvoiceDetailCommand { InvoiceDetail = invoiceDetail });
    return new MediatR.Unit();
}

Additional Information:

NSwag version: <IP_ADDRESS>
Previously, I was using Swashbuckle, and it worked correctly with this type of endpoint.

@fauzanzaid


HOLD: ensure defaultPlacement properly initalized for ingress

Currently seeing this in my existing 4.10 clusters at production level code when trying to upgrade to newest hypershift operator

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #
Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

Currently seeing this on existing healthy clusters when upgrading to latest hypershift operator

apiVersion: v1
items:

apiVersion: hypershift.openshift.io/v1alpha1
kind: HostedControlPlane
metadata:
annotations:
hypershift.openshift.io/cluster: master/cbed647109eqdmra2mog
hypershift.openshift.io/disable-pki-reconciliation: "true"
hypershift.openshift.io/konnectivity-agent-image: registry.ng.bluemix.net/armada-master/rh-apiserver-network-proxy:ba74ca29f6cead6c103a109024adc83d4fe6096f
hypershift.openshift.io/konnectivity-server-image: registry.ng.bluemix.net/armada-master/rh-apiserver-network-proxy:ba74ca29f6cead6c103a109024adc83d4fe6096f
idpoverrides.hypershift.openshift.io/IAM: |
{"urls": {"authorize": "https://iam.test.cloud.ibm.com/identity/authorize", "userInfo": "https://iam.test.cloud.ibm.com/identity/userinfo", "token": "https://iam.test.cloud.ibm.com/identity/3e61051bb0694d1184bda0f00b247b44/token"}, "claims": {"id": ["iam_id"], "email": ["email"], "name": ["name"], "preferredUsername": ["preferred_username"]}}
oauth.hypershift.openshift.io/login-url-override: https://c102-e.containers.pretest.cloud.ibm.com:30711/
creationTimestamp: "2022-07-24T05:09:22Z"
finalizers:

hypershift.openshift.io/finalizer
generation: 2
name: cbed647109eqdmra2mog
namespace: master-cbed647109eqdmra2mog
resourceVersion: "1028666706"
uid: 13ce1302-c25d-42ba-9c1e-6e1f49385126
spec:
apiAdvertiseAddress: <IP_ADDRESS>
apiPort: 2040
autoscaling: {}
clusterID: 01bc2f27-1e50-4d73-bb8b-8d3aa3fa37e0
configuration:
apiServer:
audit:
profile: Default
clientCA:
name: ""
encryption: {}
servingCerts:
namedCertificates:
- names:
- c102-e.containers.pretest.cloud.ibm.com
servingCertificate:
name: ibm-named-certs
featureGate:
customNoUpgrade:
disabled:
- ServiceLBNodePortControl
enabled:
- ExpandInUsePersistentVolumes
- RotateKubeletServerCertificate
- DownwardAPIHugePages
featureSet: CustomNoUpgrade
ingress:
domain: ta58b361f448cb77a15e7-d603ff82e51c94176a53d44566df9d79-c000.us-south.satellite.test.appdomain.cloud
items:

apiVersion: config.openshift.io/v1
kind: APIServer
metadata:
creationTimestamp: null
spec:
audit:
profile: Default
clientCA:
name: ""
encryption: {}
servingCerts:
namedCertificates:
- names:
- c102-e.containers.pretest.cloud.ibm.com
servingCertificate:
name: ibm-named-certs
status: {}
apiVersion: config.openshift.io/v1
kind: FeatureGate
metadata:
creationTimestamp: null
spec:
customNoUpgrade:
disabled:
- ServiceLBNodePortControl
enabled:
- ExpandInUsePersistentVolumes
- RotateKubeletServerCertificate
- DownwardAPIHugePages
featureSet: CustomNoUpgrade
status: {}
apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
creationTimestamp: null
spec:
domain: ta58b361f448cb77a15e7-d603ff82e51c94176a53d44566df9d79-c000.us-south.satellite.test.appdomain.cloud
status:
defaultPlacement: ""
apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
creationTimestamp: null
spec:
identityProviders:

mappingMethod: lookup
name: IAM
openID:
ca:
name: ""
claims:
email:
- email
name:
- name
preferredUsername:
- preferred_username
clientID: XXXXX
clientSecret:
name: hypershift-ibm-iam-clientsecret
issuer: https://iam.test.cloud.ibm.com/identity
type: OpenID
templates:
error:
name: ""
login:
name: ""
providerSelection:
name: ""
tokenConfig: {}
status: {}
oauth:
identityProviders:
mappingMethod: lookup
name: IAM
openID:
ca:
name: ""
claims:
email:
- email
name:
- name
preferredUsername:
- preferred_username
clientID: XXXXXXXXXXX
clientSecret:
name: hypershift-ibm-iam-clientsecret
issuer: https://iam.test.cloud.ibm.com/identity
type: OpenID
templates:
error:
name: ""
login:
name: ""
providerSelection:
name: ""
tokenConfig: {}
controllerAvailabilityPolicy: HighlyAvailable
dns:
baseDomain: ta58b361f448cb77a15e7-d603ff82e51c94176a53d44566df9d79-c000.us-south.satellite.test.appdomain.cloud
etcd:
managementType: Unmanaged
unmanaged:
endpoint: https://etcd-cbed647109eqdmra2mog-client:2379/
tls:
clientSecret:
name: cbed647109eqdmra2mog-etcd-client-tls
fips: false
imageContentSources:

mirrors:

us.icr.io/armada-master/ocp-release
source: quay.io/openshift-release-dev/ocp-release

mirrors:

us.icr.io/armada-master/ocp-release
source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
infraID: cbed647109eqdmra2mog
infrastructureAvailabilityPolicy: HighlyAvailable
issuerURL: https://kubernetes.default.svc/
machineCIDR: <IP_ADDRESS>/16
networkType: Calico
olmCatalogPlacement: guest
platform:
ibmcloud:
providerType: UPI
type: IBMCloud
podCIDR: <IP_ADDRESS>/16
pullSecret:
name: pull-secret
releaseImage: registry.ng.bluemix.net/armada-master/ocp-release:4.9.33-x86_64
serviceCIDR: <IP_ADDRESS>/16
services:

service: APIServer
servicePublishingStrategy:
nodePort:
address: c102.containers.pretest.cloud.ibm.com
port: 30711
type: NodePort
service: OAuthServer
servicePublishingStrategy:
nodePort:
address: c102-e.containers.pretest.cloud.ibm.com
port: 32075
type: NodePort
service: Konnectivity
servicePublishingStrategy:
nodePort:
address: c102-e.containers.pretest.cloud.ibm.com
port: 32035
type: NodePort
service: Ignition
servicePublishingStrategy:
nodePort:
address: c102-e.containers.pretest.cloud.ibm.com
port: 30883
type: NodePort
sshKey: {}
status:
conditions:
lastTransitionTime: "2022-07-24T22:54:08Z"
message: 'cannot parse configuration at index 2: strict decoding error: unknown
field "defaultPlacement"'
observedGeneration: 2
reason: InvalidConfiguration
status: "False"
type: ValidHostedControlPlaneConfiguration
lastTransitionTime: "2022-07-24T05:09:32Z"
message: Etcd cluster is assumed to be running in unmanaged state
observedGeneration: 2
reason: EtcdRunning
status: "True"
type: EtcdAvailable
lastTransitionTime: "2022-07-24T05:11:34Z"
message: ""
observedGeneration: 2
reason: AsExpected
status: "True"
type: KubeAPIServerAvailable
lastTransitionTime: "2022-07-24T05:09:32Z"
message: ""
observedGeneration: 2
reason: AsExpected
status: "True"
type: InfrastructureReady
lastTransitionTime: "2022-07-24T22:58:40Z"
message: Cluster operator console is not available
observedGeneration: 2
reason: ClusterOperatorNotAvailable
status: "True"
type: ClusterVersionFailing
lastTransitionTime: "2022-07-24T05:11:34Z"
message: ""
observedGeneration: 2
reason: AsExpected
status: "True"
type: Available
lastTransitionTime: "2022-07-24T05:09:32Z"
message: Reconciliation active on resource
observedGeneration: 2
reason: ReconciliationActive
status: "False"
type: ReconciliationPaused
controlPlaneEndpoint:
host: c102.containers.pretest.cloud.ibm.com
port: 30711
externalManagedControlPlane: true
initialized: true
kubeConfig:
key: kubeconfig
name: admin-kubeconfig
ready: true
kind: List
metadata:
resourceVersion: ""

Error is

lastTransitionTime: "2022-07-24T22:54:08Z"
message: 'cannot parse configuration at index 2: strict decoding error: unknown
field "defaultPlacement"'
observedGeneration: 2
reason: InvalidConfiguration
status: "False"

That above error causes reconcilation errors in the control-plane-operator


Billing page design encourages confusing between minutes and jobs

A minor point but in step 4 "Enter the amount of Microsoft-hosted CI/CD or Self-hosted CI/CD, and then select Save." the design of the billing page is confusing. It shows the current free tier as "1800 minutes" so my first instinct was to enter a number of minutes into the "Paid" box until I realised it was meant to be the number of jobs. I'm not quite sure what would have happened if I'd really tried to book 3000 parallel jobs but but I'm hoping it wouldn't have been a call from the credit card company! ;-)

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 7734edca-173b-ba47-bf1b-3c19f9bd93e1
Version Independent ID: d6ea8680-546e-f102-fd55-b35af33a6aa5
Content: Buy CI/CD Azure Pipelines - Azure DevOps Services
Content Source: docs/organizations/billing/buy-more-build-vs.md
Product: devops
Technology: devops-billing
GitHub Login: @chcomley
Microsoft Alias: chcomley

Totally agree on this. My team were just doing this, and we were this close to buying 1800 agents, instead of the 2 or 3 that we actually needed.... Very unclear instructions!

Thanks for the feedback! We will make this more clear ASAP. Quick question. If we update the text to say "Paid parallel jobs" and the size of the text box - is that clear enough? See below

That would be better! A step in the right direction, although I still miss some clarity in the fact that "paid jobs" also means "unlimited minutes" (if that even is the case? Kinda confused over here....)
For instance, my teams needs were not related to needing more parallel jobs, but rather "more minutes", as we reached the maximum of the free agents. We simply wanted to "buy more minutes", so the parallel jobs-feature was really just a happy bonus :)

Agree with @Sarrgas  - in fact I'm still a little confused over whether 1 "paid" job means "1800 free minutes on the shared pool + unlimited minutes on 1 dedicated job" or just "unlimited minute on 1 dedicated job" ?  Nevertheless - the new wording is definitely an improvement so thanks for that! :-)


parse_doctype didn't works if doctype is write in lowercase

pugi::xml_parse_result result = doc.load_string(source, pugi::parse_doctype ); return status_unrecognized_tag if doctype is write in lowercase <!doctype html>

XML specification mandates that DOCTYPE is upper-case:
https://www.w3.org/TR/xml/#NT-doctypedecl


Python comments

Comments are lost when parsing using Python stdlib ast module.
https://pypi.org/project/horast/ claims to be compatible with ast and include comment nodes.
https://github.com/adsharma/py2many/pull/350#issuecomment-869257106 mentions libcst.
Most implementations of ast/cst for Python are going to encounter growing pains post 3.10.  See https://github.com/Instagram/LibCST/issues/285#issuecomment-868478609 for the libcst issue about it.
I think we should experiment with horast first.
Also the ast module has slowly been moving towards a cst, and https://bugs.python.org/issue33337 is an open issue to reach that goal.  It might be better to simply wait, rather than switch to an unofficial parser.

horast is used by https://github.com/mbdevpl/transpyle and https://github.com/flatironhealth/ast-refactor


Don't use cache in CI.

I'm sorry, but it requires further explanation of the reasons why.

yeah, but I think it is unlikely + they recommend disabling it for release workflows.
I think you removed it everywhere, no?

I removed it everywhere zizmor was complaining about it. I think that was everywhere in CICD.yml. It says you ought to remove it everywhere you intend to publish build artifacts.

yeah, but i am not convinced we should follow the tool blindly :)


[BUG]:Important and Urgent Bug

[ x] Would you like to take up this task?
[ x] Are you from GSSoC'23?

Important and Urgent Bug.
Need to update gitignore as it does not have yarn.lock and package-lock.json as when clone then at time of contributing every time package-lock,json and yarn.lock are uploaded depending upon local machine which may affect or fail to run on other local machine. Need to fixed this urgently
Screenshots (if any)

Please provide any necessary screenshots to illustrate.

Assign It to me


BUG: No tests have been found in this workspace - for multi folder workspace

When the workspace includes multiple folders/projects the extension will not find the tests.

Only when the project (where tests are) is opened on it's own tests are discovered

The fix should be live.


Add basic tests

Refactor code to allow testability
Still in progress

@bobthekingofegypt This looks like a good path forward. Thanks for tackling this!

I think that is basic test cases for everything in server apart from w3.org/tr [PNG] logic.  I'm not sure exactly what it's aim is.
Some of them are pretty convoluted as it's all one big function, but they should give some coverage.

Thanks! This is an improvement on the status quo of no tests, so I'm fine with merging this once it's rebased against master.

Was avoiding that as it was a pain.  The conflicts had to be fixed manually, so I created test cases for the regexp changes and I split out storage to allow the ping functionality to continue being tested.
All test cases pass again and it appears to work...

Thanks!


Add xyz and rpy offset to published odometry pose

Signed-off-by: Aditya<EMAIL_ADDRESS>🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸
🎉 New feature
Summary
This PR enables the user to specify xyz_offset and rpy_offset in the odometry publisher messages, similar to xyzOffset and rpyOffset in gazebo_ros_p3d plugin in gazebo_ros_pkgs
Test it
Added a test case and an example world.
Checklist

[x] Signed all commits for DCO
[x] Added tests
[ ] Added example and/or tutorial
[ ] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[ ] codecheck passed (See contributing)
[ ] All tests passed (See test coverage)
[ ] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.
🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸

This requires *WithCovariance messages to be added to ign-msgs so that the covariance matrices of the velocities can be published when the Gaussian noise is non zero.

@azeey @scpeters should the behavior be changed in gazebo_ros_p3d as well ?

I'd say we should, but it would be a change in behavior. One thing we could do is add an additional parameter to gazebo_ros_p3d that indicates whether the plugin should use the old behavior.

I'd say we should, but it would be a change in behavior. One thing we could do is add an additional parameter to gazebo_ros_p3d that indicates whether the plugin should use the old behavior.

I think the behavior is proposed to be changed in https://github.com/ros-simulation/gazebo_ros_pkgs/pull/1241. @adityapande-1995 if you don't mind reviewing and merging that then we could port it to noetic and ros2 branches

I'd say we should, but it would be a change in behavior. One thing we could do is add an additional parameter to gazebo_ros_p3d that indicates whether the plugin should use the old behavior.

I think the behavior is proposed to be changed in ros-simulation/gazebo_ros_pkgs#1241. @adityapande-1995 if you don't mind reviewing and merging that then we could port it to noetic and ros2 branches

Will do. Meanwhile, can we move ahead with this one ? Or should we wait for the ones in gazebo_ros_p3d to be merged and backported ?

we don't need to wait for that to merge this one. I've just made one other comment about the test and then this should be ready to merge

This pull request has been mentioned on Gazebo Community. There might be relevant details there:
https://community.gazebosim.org/t/new-ignition-releases-2022-04-13-fortress-edifice/1367/1


Added SABnzbd

Added SABnzbd - a popular newsgroup binary grabber.

Please change checkver to this:
   "checkver": {
        "github": "https://github.com/sabnzbd/sabnzbd"
    }

And run .\bin\checkver.ps1 sabnzbd -f from your reforked repo. (See Wiki: Testing and running autoupdate)


Only 1 collborator gets added when trying to add multiple collaborators

Tested with the following from prod-preview users' list.
HTTP POST https://api.prod-preview.openshift.io/api/spaces/d38c2a6a-929b-46d6-9b54-19be89515a7d/collaborators

{
  "data": [
    { "type": "identities", "id": "b4af45b1-1693-409d-a84f-1d0fc6344cd3" },
    { "type": "identities", "id": "44403794-edbd-46af-861e-118648df74b5" }
  ]
}

On running a GET https://api.prod-preview.openshift.io/api/spaces/d38c2a6a-929b-46d6-9b54-19be89515a7d/collaborators
only 1 of these is listed.

@sanbornsen reported the original issue when he saw that the UI wasnt showing up collaborators when multiple collaborators were added at one go.


Encryption chapter - Need to add big numbers calculator to brute force attacks section

Currently waiting on the calculator to be added to the new field guide.

closed for inactivity, if new information is provided a new issue can be created


_update_kv_and_cache func init cache report error

Describe the bug
Running wenet/bin/recognize.py reports the error: "ValueError: not enough values to unpack (expected 2, got 0)."
To Reproduce
Run the wenet/bin/recognize.py script to infer the streaming efficient model (train_u2++_efficonformer_v1.yaml) with chunksize=18 and streaming=true.
I compared the old version, and the main difference in the code is shown below:
"
old:
if cache.size(0) > 0:
key_cache, value_cache = torch.split(
cache, cache.size(-1) // 2, dim=-1)
k = torch.cat([key_cache, k], dim=2)
v = torch.cat([value_cache, v], dim=2)
new:
key_cache, value_cache = cache
if key_cache.size(0) > 0:
k = torch.cat([key_cache, k], dim=seq_axis)
if value_cache.size(0) > 0:
v = torch.cat([value_cache, v], dim=seq_axis)
"
When the default cache is passed to the _update_kv_and_cache function, the initial cache is torch.tensor([]), which cannot be split into key_cache and value_cache.
Expected behavior
Traceback (most recent call last):
File "/lib/python3.10/runpy.py", line 196, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/lib/python3.10/runpy.py", line 86, in _run_code
exec(code, run_globals)
File "/code-server/extensions/ms-python.debugpy-2024.6.0-linux-x64/bundled/libs/debugpy/adapter/../../debugpy/launcher/../../debugpy/main.py", line 39, in
cli.main()
File "/code-server/extensions/ms-python.debugpy-2024.6.0-linux-x64/bundled/libs/debugpy/adapter/../../debugpy/launcher/../../debugpy/../debugpy/server/cli.py", line 430, in main
run()
File "/code-server/extensions/ms-python.debugpy-2024.6.0-linux-x64/bundled/libs/debugpy/adapter/../../debugpy/launcher/../../debugpy/../debugpy/server/cli.py", line 284, in run_file
runpy.run_path(target, run_name="main")
File "/code-server/extensions/ms-python.debugpy-2024.6.0-linux-x64/bundled/libs/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py", line 321, in run_path
return _run_module_code(code, init_globals, run_name,
File "/code-server/extensions/ms-python.debugpy-2024.6.0-linux-x64/bundled/libs/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py", line 135, in _run_module_code
_run_code(code, mod_globals, init_globals,
File "/code-server/extensions/ms-python.debugpy-2024.6.0-linux-x64/bundled/libs/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py", line 124, in _run_code
exec(code, run_globals)
File "/wenet/bin/recognize_debug.py", line 321, in
main()
File "/wenet/bin/recognize_debug.py", line 292, in main
results = model.decode(
File /wenet/transformer/asr_model.py", line 295, in decode
encoder_out, encoder_mask = self._forward_encoder(
File "/wenet/transformer/asr_model.py", line 223, in _forward_encoder
encoder_out, encoder_mask = self.encoder.forward_chunk_by_chunk(
File "/wenet/efficient_conformer/encoder.py", line 548, in forward_chunk_by_chunk
self.forward_chunk(
File "/wenet/efficient_conformer/encoder.py", line 404, in forward_chunk
xs, _, new_att_cache, new_cnn_cache = layer(
File "python3.10/site-packages/torch/nn/modules/module.py", line 1511, in _wrapped_call_impl
return self._call_impl(*args, **kwargs)
File "python3.10/site-packages/torch/nn/modules/module.py", line 1520, in _call_impl
return forward_call(*args, **kwargs)
File "/wenet/transformer/encoder_layer.py", line 234, in forward
x_att, new_att_cache = self.self_attn(x, x, x, mask, pos_emb,
File "python3.10/site-packages/torch/nn/modules/module.py", line 1511, in _wrapped_call_impl
return self._call_impl(*args, **kwargs)
File "python3.10/site-packages/torch/nn/modules/module.py", line 1520, in _call_impl
return forward_call(*args, **kwargs)
File "wenet/transformer/attention.py", line 393, in forward
k, v, new_cache = self._update_kv_and_cache(k, v, cache)
File "wenet/transformer/attention.py", line 207, in _update_kv_and_cache
key_cache, value_cache = cache
ValueError: not enough values to unpack (expected 2, got 0)

The Cache API changed in this pull request (https://github.com/wenet-e2e/wenet/pull/2481). It is not modified (for export_onn_gpu.py) accordingly.

duplicate with https://github.com/wenet-e2e/wenet/issues/2653


Storage client getHeaders method leads to stack overflow

Describe the bug
Calling the nhostClient.storage.getHeaders() leads to a stack overflow due to what appears to be a mistake here:
https://github.com/nhost/nhost/blob/61a8c6930fd3f4bcf483146ba71a601655372842/packages/hasura-storage-js/src/hasura-storage-client.ts#L244C2-L246C4
To Reproduce
Steps to reproduce the behavior:

Create a new NhostClient
call getHeaders() method on the storage client

Expected behavior
Would expect headers to be returned and no stack overflow error.
Additional context
<EMAIL_ADDRESS>via
<EMAIL_ADDRESS>

Oh, thanks for the report, we will fix ASAP.


Some questions about the code

Code understanding
Summary
CrossBleAdapter is a partial static class that has a property of IAdapter with the name of Current. This gets initialized from the constructors of partial CrossBleAdapter classes. For example, in Apple folder
    public static partial class CrossBleAdapter
    {
        static CrossBleAdapter()
        {
            Current = new Adapter();
#if __MACOS__
            AdapterScanner = new AdapterScanner();
#else
            AdapterScanner = new NotSupportedAdapterScanner();
#endif
        }
...

and in Tizen, it goes like below
    public static partial class CrossBleAdapter
    {
        static CrossBleAdapter()
        {
            AdapterScanner = new AdapterScanner();
            Current = new Adapter();
        }
    }

I have two questions here:

All Adapter classes have same namespace Plugin.BluetoothLE and not all are partial. Why the compiler is not complaining about that?

According to the platform, how the right Adapter gets initialized? It seems like all adapters would get initialized this way :/

Despite the complier giving me red underlined errors, the library compiles on VS for Mac and Rider IDE.
I know this is quite basic but I am having a hard time understanding what is going on here.

All Adapter classes have same namespace Plugin.BluetoothLE and not all are partial. Why the compiler is not complaining about that?

It is a multitargeted library, so it is compiling the same project (each time per platform I define) and only including folders that are defined per platform.  Take a look at Plugin.BluetoothLE.csproj to get a better idea.  There is also a few good blog posts out there - https://www.bugsnag.com/blog/building-multi-targeted-dot-net-libraries

According to the platform, how the right Adapter gets initialized? It seems like all adapters would get initialized this way :/

As soon as you call CrossBleAdapter.Current, the static constructor for the platform lib is called.

Despite the complier giving me red underlined errors, the library compiles on VS for Mac and Rider IDE.

VS4Mac does not support multitargeting yet.  You need to use VS4win to compile things properly.


Set up build process for Paratext 10 Studio

User Story
As a user, I want to be able to download and run Paratext 10 Studio, containing Platform.Bible and some extensions, so that I can start with a good set of features.
As a product manager or developer, I want certainty as to the relationships between all these different repositories and how they combine into our product so I know how to think about the structure of the software and where to put functionality/extensions.
Description
We currently have build processes that create Platform.Bible running in paranext-core. Now we want to white label it and bundle paratext-bible-extensions in with it to create Paratext 10 Studio.

Create a script and GitHub Action that enable building Paratext 10 Studio:
[ ] Get paranext-core

[ ] Clone paranext-core
[ ] Fulfill build environment requirements for paranext-core

[ ] Modify paranext-core

[ ] Change the app name
[ ] Change the file paths (user folder, temp folder, etc.)
[ ] Change "Platform.Bible" in localized strings? Or maybe we need to support localized string keys in the localized strings...? %product_name%
[ ] Change the icon
[ ] Change colors?

[ ] Include

[ ] Clone paratext-bible-extensions and paratext-bible-internal-extensions
[ ] Build their zip files and include in the electron build (extraResources in electron-builder.json5?)

[ ] Build paranext-core

Note: version numbers do not need to be synced between Platform.Bible and Paratext 10 Studio

Potential cost analysis
Note: Public repos get Linux and Windows machines that have double the CPU and RAM that the machines used for private repos. We will just double numbers for Windows and Linux as an estimate.
Free plans get 2000 minutes per month and 500MB (per month...? unclear) storage.

Minute multiplier (each platform costs something different)

Linux: 1 ($0.008/min)
Windows: 2 ($0.016/min)
macOS: 10 ($0.08/min)

paranext Package workflow (Public)

windows-latest 8m 25s
macos-latest 6m 18s
ubuntu-latest 3m 51s
Artifacts: 589 MB total

Storage:
Actions time:
paranext Publish workflow (Public)

windows-latest 14m 26s
macos-latest 8m 31s
ubuntu-latest 4m 27s
Release files: ? (Platform.Bible's latest had ~1034MB.)

Storage:
Actions time:

Platform.Bible White-labeling Repo: https://github.com/paranext/paranext
Paratext 10 Studio: https://github.com/paranext/paratext-10-studio
Set up to run every Monday morning. Hopefully costs will be under $6/month. Set a $10 monthly spending limit.
Manually ran first build of Paratext 10 Studio:
Windows
Mac
Linux

Testing Steps:
Platform.Bible White-labeling Repo: https://github.com/paranext/paranext
Followed instruction on Read me
git clone https://github.com/paranext/paranext.git
cd paranext
npm install
npm run build-ci

After completion, I was able to open Platform.Bible.exe from the
C:\Repos\paranext\dist\Platform.Bible 0.0.1.exe

Paratext 10 Studio: https://github.com/paranext/paratext-10-studio
git clone https://github.com/paranext/paratext-10-studio.git
cd paratext-10-studio
npm install
npm run build-ci

After completing the above was able to open the Paratext 10 Studio application at
C:\Repos\paratext-10-studio\dist\Paratext 10 Studio 0.0.1.exe


pythonPackages.pony: init at 0.7.11

Motivation for this change
pony is an ORM library.
The main motivation for adding this package is to allow migrating trible
to a newer version that supports python3.
Also adding myself to maintainers to not leave this one without, even
though I dont use it myself much, if anybody else feels like it fits their
interests, feel free to add yourselves.
Related: https://github.com/NixOS/nixpkgs/pull/73927

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @

@GrahamcOfBorg build pythonPackages.pony

Could do a from pony.orm.examples.estore import * with that pony, so I assume it's still working :-)

@flokli: I did sth like that but also ran tribler against it and it seemed fine enough.


Login with username or email for an account

Hi all,
Is it possible to configure dj-rest-auth to allow login by username or email for one account? For example:
username/password or email/password?
Thanks,
Steven

Yes it's possible. Have a look at the Django All Auth configuration for more details on enabling that (see ACCOUNT_AUTHENTICATION_METHOD)
https://django-allauth.readthedocs.io/en/latest/configuration.html

iMerica,
Would enabling Django All Auth change the Django Schema in our database, or be disruptive to our current accounts, or is it a seamless transition from base dj-rest-auth?
Thanks,
Steve

All auth has it's own models and a small amount of migrations. If your deployment process already runs migrations automatically it should be seamless. YMMV.


Reduced lag when creating bases

TODO: put the buildings back in

Fixes #160

Did this late at night. Hope it's gud.

Request code review and merge pls.

Looks and works ok for me.

Changed that one function name. Did a test. Will now merge with main.