support for Sonoff TRVB

Is it possible to implement support for Sonoff TRVB?
"device": {
  "uiid": 7017,
  "params": {
    "subDevId": "3c2ef5fffebafc327017",
    "parentid": "10022783f5",
    "staMac": "***",
    "fwVersion": "1.2.1",
    "otaInfo": {},
    "sun": "000000a001a400be025800be025800be025800be056400a0",
    "mon": "000000a001a400be025800a0025800a003fc00be056400a0",
    "tues": "000000a001a400be025800a0025800a003fc00be056400a0",
    "wed": "000000a001a400be025800a0025800a003fc00be056400a0",
    "thur": "000000a001a400be025800a0025800a003fc00be056400a0",
    "fri": "000000a001a400be025800a0025800a003fc00be056400a0",
    "sat": "000000a001a400be025800be025800be025800be056400a0",
    "tempCorrection": 0,
    "battery": 97,
    "runVoltage": 132.7,
    "workMode": "1",
    "manTargetTemp": 190,
    "curTargetTemp": 40,
    "workState": "0",
    "fault": "reasonCode0",
    "temperature": "243",
    "trigTime":<PHONE_NUMBER>341,
    "childLock": false,
    "windowSwitch": true,
    "openPercent": 100,
    "closePercent": 100,
    "ecoTargetTemp": 40
  },
  "model": "TRVZB",
  "online": true,
  "local": null,
  "localtype": null,
  "host": null,
  "deviceid": "a48009dcbe"
}

Looks like it's a difficult device. A lot of unclear params.

Looks like it's a difficult device. A lot of unclear params.

Maybe this can be helpful!

+1 for initially limited support status(off/heating) + current temperature  would be awesome

To be honest, someone doesn't want to integrate TVRZB with sonoffLAN, because if you connect direct with ZHA, there are all functions from these device, but if you using these device with sonoff zbridge or NSPanel Pro, the device is not avaible. It's very frustated and useless. It's a shame because this integration was really convenient. I think is not really complicated implement to use TRVZB but someone doesn't want.

I discovered that this issue is a duplicate #1244


Fix process_procmap pattern and recoverable issues

I apologize in advanced if I'm doing something incorrectly because this is the first time I'm submitting a pull request on Github! I had a couple of issues with your code so I made a couple of small changes in expect.rb that fixed them.

In process_procmap - the pattern that is returned is a string, however a regex is expected. I fixed this on line 384.
In process_procmap - recoverable will always be false as regex_keys is ONLY regexes (done on line 379). pattern_map.keys has the symbols still and so I replaced regex_keys on line 385 with that.

Hi, I'm really sorry about the slow response to this PR; I was busy over the weekend.
Thanks; that's a great catch.  I've been meaning to give this lib some TLC and this is a great push to do just that.


Issue in /src/pages/guides/endpoints/bulk-data-insertion/mcseed.md

URL of documentation issue
https://developer.adobe.com/analytics-apis/docs/2.0/guides/endpoints/bulk-data-insertion/mcseed/
Description
The process requests to "Communicate your intent to use this feature to the BDIA team".
But it's not clear who the BDIA team is. Is the client requested to open a support ticket?
Could you please integrate such information in the documentation?
Thanks,
Alberto

The BDIA team is the team responsible for the Bulk Data Insertion API and its associated format. See https://developer.adobe.com/analytics-apis/docs/2.0/guides/endpoints/bulk-data-insertion/file-format/
Updated documentation accordingly.

Hey Rob.
Thanks for chiming in.
Not sure if you have pushed the updates already.
From what I get I have the same concern:

That is: who is the BDIA team? As a client, should I open a ticket? As a consultant who should I reach out to?
Do you think a more explicit statement like "Open a support ticket to have the customer ID type set up" would be appropriate?
Alberto

@decaroa Apologies for picking up this late.... but I do think the team refers to the team within the customer organisation that is responsible for using and building integrations based on the Bulk Data Insertion API. And not so much referring to an Adobe team.


!mistral-demo $7B_DIR issue

Hi ,
When I try to run this command '!mistral-demo $7B_DIR', I encounter an issue related to the GPU. Could you please suggest a solution? I am using Google Colab

replace 7B_DIR with M7B_DIR at all places
looks like an issue with setting environment variables with numeric character.
faced the same issue on ubuntu 22.04.  replacing the variable solved the problem.

Also note that not every GPU will work with the required version of xformers. If you're having a T4 on google colab, maybe try to manually install a lower version of xformers

you need to have a NVIDIA A100 machine to fine tune. I faced this earlier with V100. After switching to A100, it worked.


Update CMakeLists.txt

Just noticed that we haven't added the benchmark_basis.cpp to the CMakeLists.txt.

Great, thank you!


New feature discussion: Pre-frame bulk messages

Framing a message is a time consuming operation.  If there are multiple messages with the same contents, frame them once.
(Maybe make a message class?  Definitely going to do for the next version...  not sure if we'll implement it like that on the legacy branch, since it bends the paradigm too far.)

After thinking, it's probably best to split messages out into a new class on the legacy branch, because there are some very valid use cases for having different message object types...  for example, in the same server, a person could have chat messages and have messages that frame HTML updates on the page.
Also, important for other development going on, there should also be TLS messages, which also get encrypted and framed within the TLS protocols.
It fits within the legacy paradigm in the same way that having a user class fits in.

master branch : the frame() have link with user class that why you can't frame() once before sending to multiple client.
In development branch it allready able to frame() once and send to multiple client.  I remove the user class link within frame() by doing this I can still send to one client at time after framing the message, or framing the message once and broadcast it
There is two method for outgoing data : send() (single client) and broadcast() (multiple client ).
The data you send is irrelevant to the method use ( message / html / binary ) as long the data is exactly the same for multiple client we should frame it once.
Unless I miss something on the RFC both ws and wss MUST mask data prior to sending it. Unless it different the messages didn't need a proper class. Message / frame are userfree.
The layer process of data in outgoing:
ws : data -> framing -> mask -> send
wss : data-> framing -> mask -> encrypt -> send
As encrypt is per user it's when you encrypt it that the road split.  The data is the same untill that.

That's exactly why I'm thinking of adding a message class.
$recipients = array($user1, $user2, $user3, [...]);
$msg = new Message('This is a message.', $recipients);
$msg->addRecipient($userX);
$msg->send();

...

class Message implements \Phpws\Interfaces\Message
{
    function __construct($text = '', \Phpws\Core\WebSocketUser $recipients = array()) {...}
    public function addRecipient(\Phpws\Core\WebSocketUser $recipient) {...}
    public function addRecipients(array $recipients) {...}
    public function removeRecipient(\Phpws\Core\WebSocketUser $recipient) {...}
    public function setMessage($message) {...}
    public function send() {...} // adds self to server's message queue.
    public function getRecipients() {...}
    public function getSendStatus() {...} // could be unsent, sent to some, or sent to all.
    protected function frame($message) {...}
    protected function tls_frame($message, $recipient) {...}
}

Then someone implementing messages that need additional structures on the message (i.e., wants to differentiate between HTTP content for updating elements on the page v. updating contents of a chat window) can then extend the base Message class...
NOTE: Untested, hypothetical...  Treat as PHP flavored pseudocode:
class ChatMessage extends \Phpws\Core\Message {
    function __construct($text = '', \MyNamespace\ChatUser $sender, $channel) {
        $this->channel = $channel;
        $this->sender = $sender;
        parent::__construct($text, $channel->users);
    }

    public function send() {
        $data = array('sender' => $this->sender->getHandle(),
            'timestamp' => time(),
            'channel' => $this->channel->getName(),
        );
        $output = $this->frame(json_encode($data));
        foreach ($this->recipients as $recipient) {
            if ($recipient->getIsTlsUser()) {
                $this->server->send($this->tls_frame($output, $recipient), $recipient);
                continue;
            }
            $this->server->send($output, $recipient);
        }
    }
}

It's look like subprotocol it's good if you want to create your own subprotocol system but you should keep it on that level.  Implementing it on core level will probably cause some headache for coexisting  with other subprotocol like WAMP.
here a list of some existing subprotocol working over websocket.
https://www.iana.org/assignments/websocket/websocket.xml


CarAdvice.com.au feed not working

Actual behaviour
Feed fails to load with:
updated just now An error occurred during the last check: "".
Other feeds work fine.
Expected behaviour
Feed should load
Steps to reproduce

Add http://www.caradvice.com.au/feed/
Refresh

Configuration

Miniflux version: Github master 29/12/16
Database type and version: SQLite 3.8.11
PHP version: 5.6.11
OS: Ubuntu 15.10
Browser: Safari 10 (macOS Sierra)

I fixed the fact that the error message was not visible. However, the feed is working for me.
If you update your installation, you could see the cause of the problem now. But activating the debug mode, will give more context in the log file.

Thanks very much for your quick reply!
It turns out simple wget requests for the feed were also failing, so I contacted the site and it turns out their firewall was misconfigured. They've fixed the problem and the feed is now working fine.
Sorry to waste your time!


Fix resource_logs endpoint when the messages don't have kwargs

Description
closes #3316
Self Check:
Strike through any lines that are not applicable (~~line~~) then check the box

[x] Attached issue to pull request
[x] Changelog entry
[x] Type annotations are present
[x] Code is clear and sufficiently documented
[x] No (preventable) type errors (check using make mypy or make mypy-diff)
[x] Sufficient test cases (reproduces the bug/tests the requested feature)
[x] Correct, in line with design
[x] ~End user documentation is included or an issue is created for end-user documentation (add ref to issue here: )~

Reviewer Checklist:

[ ] Sufficient test cases (reproduces the bug/tests the requested feature)
[ ] Code is clear and sufficiently documented
[ ] Correct, in line with design

Processing this pull request

Merged into branches master in 7557911bcbda241be32ab956f5396da2848ce0d0

Processing #3320.


lower-level text themimg

Reason for change

Added theming for headings
Fixed buttons in docs examples

Testing

Check that headings behave as expected for all themes

Codecov Report

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

@@           Coverage Diff           @@
##           master     #151   +/-   ##
=======================================
  Coverage   54.23%   54.23%
=======================================
  Files          31       31
  Lines         684      684
  Branches      152      152
=======================================
  Hits          371      371
  Misses        311      311
  Partials        2        2

Continue to review full report at Codecov.

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


intz name is confusing

First off, thank you for making this! I'm hopeful this can lead to some consolidation of the datetime libraries in rust.
Reading through the documentation, I was consistently reading .intz as .int_z. I assumed this naming referred to some standard I was unfamiliar with. It took a bit for it to click that the correct reading is .in_tz
I like how terse the current name is,  but feel it worthwhile to potentially introduce an extra underscore to make the meaning a bit more clear.

Some options I can thing of:

date(2020, 1, 1).at(9, 30).intz("America/New_York") Current
date(2020, 1, 1).at(9, 30).in_tz("America/New_York")
date(2020, 1, 1).at(9, 30).zone("America/New_York")
date(2020, 1, 1).at(9, 30).zoned("America/New_York")
date(2020, 1, 1).at(9, 30).in("America/New_York")
date(2020, 1, 1).at(9, 30).tz("America/New_York")

All of these names seem quite ambiguous with the to_zoned function, requiring reading documentation to understand the difference. I think my preferred api would be to consolidate both functions into a single method:
pub fn zoned(self, tz: impl IntoTimeZone) -> Result<Zoned, Error>

I would love .in(...) personally, but in is a keyword, so that's a no-go.
I don't mind tz(...). That is my favorite among the ideas you've suggested.
I did indeed consider collapsing intz() and to_zoned() down into one polymorphic routine. I believe the problem I ran into there is that Timestamp::to_zoned is infallible, and if it were polymorphic and could accept a string, then it would need to be fallible. Which I didn't want to do. I felt like instead, establishing an API pattern that intz takes a string and to_zoned takes a TimeZone would be a better way to go. But I'm not 100% set on that. Maybe there is another way to make a single method work.

I am not a fan of tz because it sounds to me like it should function similarly to Zoned::time_zone, i.e., it should be a getter. I do prefer in_tz to intz for the same reason as OP (my first thought was a shorthand for “internationalize”?).
However given the fact that method names are shared throughout the crate, I think the following inconsistencies arise:

in_tz preserves the instant in time, except for civil datetimes, because it can't, because they don't correspond to an instant in time (but users might think they correspond to local datetimes?)
in_tz attaches a new timezone to a tz-unaware object without otherwise changing it, except for a Zoned, where it changes both the time zone and the DateTime
to_zoned is infallible on Timestamp, fallible on Date[Time], and fallible and “backwards” on Timezone (and for TimeZone it only applies to DateTime, not Date).

I propose the following (Result being short for Result<Zoned, Error>):

Timestamp::with_tz(&str) -> Result, because we are attaching a time zone to something without one, without changing the moment in time it corresponds to
Date[Time]::in_tz(&str) -> Result, because a DateTime only corresponds to an instant in time when it's in a tz. Grammatically, this is analogous to Date::at, as “in” and “at” both refer to an object’s (physical or temporal) location
Zoned::to_tz, because we are changing the tz of something that already has one
Timestamp::try_with_zone(TimeZone) -> Result
Date[Time]::in_zone(TimeZone) -> Zoned
Remove TimeZone::to_zoned unless it can be generic over Date and DateTime.

On the one hand this is a lot of function names to remember, but on the other hand they “make sense” and don't suggest similarities that aren't really there. Also I am not sure about how easy it is to remember that it's _tz(&str) but _zone(TimeZone) or how that could be reinforced (or changed to a better convention).
Alternatively, regarding this point:

if it were polymorphic and could accept a string, then it would need to be fallible

perhaps std::convert::Infallible or ! could be used as the error type of the Result so that at least the infallibility was part of the type and, eventually, could be safely unwrapped with Result::into_ok.

I don't think there's much value in using these names to capture very subtle differences between the operations. If there were multiple distinct "with time zone" operations for each type, then that might make sense, but I feel pretty strongly that "attach a time zone to this date/datetime/timestamp" should all have the same name. I used intz for a time zone name and to_zoned for a TimeZone. The Zoned type does have slightly different names because it is itself Zoned.

Timestamp::try_with_zone(TimeZone) -> Result

Attaching a jiff::tz::TimeZone to a jiff::Timestamp is always infallible.

Remove TimeZone::to_zoned unless it can be generic over Date and DateTime.

I suppose it could accept a Into<DateTime>, but I don't see this as a particularly important point IMO. I'm not sure why it would be removed if it couldn't be generic though?

perhaps std::convert::Infallible or ! could be used as the error type of the Result so that at least the infallibility was part of the type and, eventually, could be safely unwrapped with Result::into_ok.

I can see how that's sometimes necessary, but I find that very yucky personally.

One thing I have struggled with in other datetime libraries is differentiating between:

A function that takes an unzoned datetime and interprets as being in the specified zone.
A function that takes a zoned datetime and converts it to being in another time zone (applying an offset)

It looks like jiff also makes this tricky to differentiate by having a method named intz do (1) when called on a civil::DateTime and (2) when called on a Zoned or Timestamp. This is somewhat ameliorated by Timestamp and civil::DateTime being separate types, but I would still prefer different methods names if possible.
In the other library where I have had this issue (moment.js) I resorted to evaluating code in a repl to ensure that I had the correct behaviour. I think in this case I would able to determine correct behaviour from the types, but that would still make reading code where the types are not present (common in Rust!) difficult. I can particularly imagine this being an issue in code review where IDE hints are often not easily available.
I wonder if a better API for this might actually be a constructor on Zoned like Zoned::new but taking a civil::DateTime rather than a Timestamp.

Aside: I believe there is a typo in the [DateTime::to_zoned](https://docs.rs/jiff/latest/jiff/civil/struct.DateTime.html#method.to_zoned:

In the common case of a time zone being represented as a name string, like Australia/Tasmania, consider using DateTime::to_zoned instead.

^ I think this should point to DateTime::intz instead.

@nicoburns Do you think different names can really capture the full subtlety of the differences in those operations? The names suggested above all just seem like different variations of the same general concept to me: to_tz, in_zone, with_tz and so on give me a sense of arbitrariness with the name selection. I don't see them helping folks to understand the nuanced difference from the name itself. I can see how they might be post hoc rationalized in a way, but I think it's a stretch.
The intent really is that it's the types that help you figure out what to do. Maybe some prose docs would help. In particular, the way I conceptualize time zones is that they provide functions to go back-and-forth between exact time and inexact time in a particular geographic region. (Where "inexact time" is synonymous with "local," "civil," "wall," "clock," "naive," "plain" and so on.) civil::DateTime -> Timestamp and civil::DateTime -> Zoned are going from inexact to exact, while Zoned -> civil::DateTime is going from exact to inexact. And crucially, the the former might have ambiguity (so it's really civil::DateTime -> zero or more of Timestamp) while the latter is never unambiguous.
The other operation you mention, which is changing the time zone of exact time, is better conceptualized as, "changing the function that takes exact time to inexact time from one geographic region to another."
In all of these operations, the crucial parts are 1) what the operands are, 2) the input operand and 3) the output operand. Once you have those puzzle pieces in play, that tells you the rest. So I guess in theory, we could name "exact -> inexact" differently from "inexact -> exact." But I worry that will be an incredibly subtle difference that requires already knowing the right conceptual model first to understand why the names are different. This is why I'm more in favor of using the same name everywhere: the name reflects the fact that a time zone is being used to implement one of the following transformations: inexact ->{tz} exact, exact ->{tz} inexact or exact{tz1} -> exact{tz2}.
To be clear, I'll list the methods for each of the above transformations on the main datetime types:

inexact ->{tz} exact is done via civil::DateTime::{intz,to_zoned} and civil::Date::{intz,to_zoned}. The latter is just a "convenience" function for, e.g., date.to_datetime(Time::midnight()).{intz,to_zoned}. Where tz is the parameter to these functions, either via jiff::tz::TimeZone or an IANA time zone identifier.
exact ->{tz} inexact is done via Zoned::datetime. This can also be done via TimeZone::to_datetime if you supply a Timestamp. Timestamp itself has no method for a exact ->{tz} inexact transformation since it's generally better to just create a Zoned and then ask for the inexact time via Zoned::datetime.
exact{tz1} -> exact{tz2} is done via Timestamp::{intz,to_zoned} and Zoned::{intz,with_time_zone}.

I think in this case I would able to determine correct behaviour from the types, but that would still make reading code where the types are not present (common in Rust!) difficult.

If you're reading code and you see abc.intz("America/New_York")?, then abc could be one of four different types: Zoned, Timestamp, civil::DateTime or civil::Date. If each of those types had a different name for intz and you knew off the top of your head the mapping between those names to their corresponding types, you would be able to determine the type and thus what kind of transformation was taking place. I am kinda skeptical that this would be easy for someone to do with passing familiarity with Jiff, but putting that aside, what would you do with this information at this point in code review? Is there a mistake you'd look for? One thing I can think of is that perhaps you care about the disambiguation strategy, and that only applies for inexact ->{tz} exact transformations. But this is pretty rare I think. I'm struggling to think of other reasons why you would want to know which operation was being performed without being able to know the types.

For awareness on my current thinking, I am very on board with changing intz to something else. in_tz seems to be popular, although I still don't like it personally.

Do you think different names can really capture the full subtlety of the differences in those operations?

I definitely feel this point. There have been many libraries I've used where the names for these operations are ambiguous at best.

The intent really is that it's the types that help you figure out what to do.

I like this in principle, but rust type inference can make it difficult to know what the types are when reading code, which can be especially pernicious in code review. Ideally we could have our cake and eat it too. Short, descriptive, unambiguous, intuitive names for each operation, with type information cementing the intention of the names.
In the interest of exploring the design space, I'll enumerate some options for each of the four operations I care about. I'll include extremely verbose names and extremely terse names.
1. Dropping the timezone of a Zoned, to get a civil DateTime
Example: 2023-05-13 11:30 UTC -> 2023-05-13 11:30
Possible names:

Zoned::datetime current This could be slightly confusing, as Zoned is itself a form of datetime, but in practice I don't think this is a problem.
Zoned::to_civil
Zoned::civil
Zoned::without_timezone
Zoned::without_tz
Zoned::no_tz
Zoned::unzone

2. Specifying a timezone for a civil DateTime
Example: 2023-05-13 11:30 -> 2023-05-13 11:30 UTC
I also feel strongly that the name we choose here is also the name used for attaching a timezone to a date/datetime/timestamp.
Possible names:

DateTime::intz current
DateTime::in_tz
DateTime::with_tz
DateTime::zone
DateTime::zoned
DateTime::tz

3. Converting a Zoned to another timezone, keeping same timestamp
Example: 2023-05-13 11:30 UTC -> 2023-05-13 06:30 EST
Possible names:

Zoned::intz current I don't love this name, as it's ambiguous if this is operation 3 or 4
Zoned::to_tz
Zoned::with_zone_same_instant This is what Java does
Zoned::as_tz This is what python does
Zoned::convert_tz This is what polars does
Zoned::with_tz_same_timestamp

4. Replacing the timezone of a Zoned, keeping same local time
Example: 2023-05-13 11:30 UTC -> 2023-05-13 11:30 EST
Possible names:

Zoned::datetime()::intz() current This seems both hard to discover and less self documenting than alternatives
Zoned::replace_tz This is what the python datetime and polars do
Zoned::with_zone_same_local This is what Java does
Zoned::as_tz_same_local

I think these are my favorites:

Zoned::datetime or Zoned::to_civil
These are both simple and intuitive
DateTime::tz & Date::tz & Timestamp::tz
This is very common, and associating a timezone isn't especially ambiguous, so a short name is ideal.
This plays especially well with the date().time().tz() builder pattern.
Zoned::with_tz_same_timestamp
I don't think this operation is as common, but when you need it it's very important you choose the correct operation.
A more verbose but descriptive name seems appropriate here.
Zoned::with_tz_same_local
Similar to 3, this is a less common operation, and it's important to get right when you do need it.

Sorry for the huge writeup! I don't think there's any one right answer here, but this feels like the best set of tradeoffs to me. Thoughts?

Thank you for that write-up! I am somewhat a fan of DateTime::tz. It in theory could be confused for a getter, although a getter for a time zone on those types doesn't make sense. So it really can't be. But still, I wonder if it could lead to confusion. But I do like it. (I really wish we could use in here. But it's a keyword. Another possibility is of, but I'm not sure that works well.)
As for Zoned::with_tz_same_local, the first thing there is it would need to be civil, not local. (Or if a different name is chosen in #12, then that name.) The second thing is that I very intentionally left this operation off of Zoned. It mimics Temporal's API, and I think needing to go through civil time explicitly and then back to Zoned makes it especially clear, on its own, that you're asking for a different time zone while trying to keep the local time the same. I expect that's why Temporal's API is designed that way as well.
As for Zoned::with_tz_same_timestamp, I'm not a huge fan personally. I think that if we have Zoned::with_tz_same_local, then yes, we need a longer name for Zoned::intz as a useful parallel. A Zoned is really just an instant. It is only also a civil datetime because literally every instant in any time zone has a corresponding and unambiguous civil datetime. So maybe we need to emphasize this more in the docs.
Also keep in mind that there is both a Zoned::intz (the convenient one that takes an IANA string ID) and a Zoned::with_time_zone (that takes a jiff::tz::TimeZone).

I'd also considered that DateTime::tz could be thought of as a getter, but as you said, that really doesn't make any sense for any of those types, so I don't think it'd be a problem in practice.
If we decide not to have both Zoned::with_tz_same_civil and Zoned::with_tz_same_timestamp, and instead only have the latter option, I think I'd still want a more verbose name. I find it highly likely that a developer will accidentally reach for Zoned::intz intending to perform the former operation. There's nothing in the type system itself protecting us here, and this can be easily missed in a code review.

If you are going to move away from intz, I favor with_tz.  I don't really buy the argument that people read it as int_z when the both the previous tokens and the following token in the line indicates clearly that we're dealing with date times.

I don't really buy the argument that people read it as int_z when the both the previous tokens and the following token in the line indicates clearly that we're dealing with date times.

I think it's more just an eye-reaction response, since folks are very very used to int being a thing, and maybe less used to tz being a thing. So the brain has trouble parsing it in the way it's intended. My guess is that if someone thinks about it, they'll get it, though.


Submission guide contrib

To follow up on issue #1, I added a PDF of the submission guide to the repository (/docs/) and a link to the readme. The remaining diffs are due to trailing whitespaces that my editor removed, so ignore those.
If you agree, we can merge this into the main branch.

I readded some of the line spaces because it's needed for the html representation to show right (two spaces at the end of a line is markdown for a line break)

Thanks for fixing! I wasn't aware of this. Good to know.


Style flash messages for errors

Introduces additional visual indicator (red colouring) to flash messages
that are displaying errors, to highlight to the user that something
untoward has occurred.
Example

@samuelhwilliams I think we could use govuk-error-summary here, rather than adding our own component?

It's not adding a component, it's just adding a modifier. So this is mostly code we already have. I suspect it would be more work to use their stuff and modify the colours, but maybe not. I'll look into it at another point if you're not happy with this.


Reduce vertical spacing between titles and subtitles everywhere

Lydie has asked us to reduce the vertical spacing between titles and subtitles everywhere consistently.

We improved the layout of cells in recent versions.


fix: Added styles.yml , documentation.yml Files for Issue Templates

Related Issue
Closes : #1183

Description

 Added styles.yml File for Raising Enhancement Requests in Issue Templates.
Added documentation.yml File for raising Documentation related Requests in Issue Templates.

Screenshots

Checklist

[ ] My code adheres to the established style guidelines of the project.
[ ] I have included comments in areas that may be difficult to understand.
[x] My changes have not introduced any new warnings.
[x] I have conducted a self-review of my code.

Hi @SiddhantPawar03 . Please review on this PR .Please add Valid labels under GSSOC'23

Hi @SiddhantPawar03 . Please look at other pending Action like Merge


saveScreenshot function refactoring.

Just to be coherent with the ternary condition above it.

I guess this one can be merged.


[SPARK-14279] Spark Version will be picked from pom.version

What changes were proposed in this pull request?
This PR proposes to pick the version information for SPARK from pom.version.
It also proposes to include other relevant build details.
How was this patch tested?
spark-submit --version should give the version information and also build details

Can one of the admins verify this patch?

This looks like a ton of complexity, with custom plugins and generated files. What problem is this solving in comparison? The JIRA doesn't say why.

The custom plugin definitely looks like overkill. Can't you do something close to this using the antrun plugin and the echo task?
Also, you'd have to change the sbt build too.

Woah! This is way too complex in its current form.

the code was mostly borrowed from other apache projects (hadoop/storm).  There is a fair amount of code here but its not really that complex. one maven plugin, one version.java file and one properties file.
It solves the problem of knowing the exact version and build information without manually editing files. I want to be able to have a automated build to build spark, update the version if required and when that gets deployed somewhere i want to know exactly what that was built from.  This is basic automated CI/CD stuff with tracability.
We can definitely do this other ways so please propose alternatives.

@tgravescs see my comment; using antrun + echo (or replace) would I think cover the most important parts here. No need for a custom plugin.

@vanzin can you clarify, you mean antrun + echo to generate the properties file part or more?    You still have to call the other commands to get the git info, md5 info, etc.
Personally I like the plugin better as its more extensible and easier to do things cleanly in java then in shell. There is logic in there for different version control systems, none, svn, git.  We probably don't need svn at this point. Personally I would rather see this then writing shell or ant scripts.  Using java keeps it less os dependent as well.  Since the code is used by other projects we know it works and it wasn't very hard to copy it and slightly modify for Sparks use.
I forgot we were still using sbt for development.  so we will have to look into that.  Last I knew sbt couldn't use the maven plugin so it will have to be handled separately.  I guess the question there is whether it needs to be real information since its not the official build tool

I mean antrun to generate the properties file. I understand that the plugin can do more and is written in Java, but that argument would be a lot stronger if this were actually a published plugin instead of a piece of code that is forked throughout projects...
On the other hand, the antrun-based approach is just a few lines of code in a pom file.

@vanzin The idea was to make it pluggable to be used by other projects if neccessary. If we do not want to have additional information regarding the build it can be simplified but I think it would be nice to have this information. I will look into antrun plugin thank you

So to me here the difference is shell scripts vs Java code.  Unless you know of an easier way with antrun to do the md5sum and get the git information?  All I really saw was the exec option to call out to shell.
I would rather maintain java code then shell scripts.  Generally the java code should be easier to maintain and less brittle.
I don't see why having our own maven plugin for this is such a big deal, it means we can do whatever we want with it but at the same times other apache projects basically use the same plugin and its known to work and shouldn't really change unless we decide to add something to it.  Why is a maven plugin any different for core code that we write from scratch?  maven provide utilities for writing your own plugins, I don't see that breaking.  We can remove the svn stuff from it and it will shrink the actual code size.
We do have to handle it in sbt, but as I said above personally I think we could simply echo out a properties file with just the version and leave the other fields empty since its just for developer builds.
@JoshRosen you made a comment about this being to complex, what were you thinking or proposing as alternative?   And why is this to complex?
Perhaps the difference here is the jira should have been more detailed to list out all of the things we wanted to get here rather then just the version.  I'd be alright with removing the md5sum if we don't want that, but I think the rest of the information is really useful for tracability.  It makes it easy to look at a jar running on a cluster and see who built it, from what repo and commit, and what is the specific version.
Also note that this pr has 25 files changed but the majority of them are really small just switching to use VersionInfo.

Perhaps the difference here is the jira should have been more detailed to list out all of the things we wanted to get here rather then just the version.

Yes, that would help. Because right now the plugin is basically a (very complicated) shell script written in java; the exceptions being the date (easy to get from shell and, personally, I don't even find that very interesting) and the md5 sum (which I'm not sure what you need for - and shouldn't the git hash give you pretty much the same or better info?).
You could even write an actual shell script and just run it from maven / sbt and it would be easier to read and much smaller than the java plugin. (Windows compatibility would be a little sketchy, though.)

Ok, Sanket will try using the antrun method.  If it can be reused between mvn and sbt that would be easier from that perspective as well.

What's the motivation for this change BTW? is it strictly to reduce duplication?

Sorry if that wasn't clear, the motivation is to more easily tie this to automated continuous integration and deployment and to easily have traceability.
Part of this is right now you have to manually change a java file to change the version that comes out when you run spark-submit --version.   With continuous integration the build numbers could be something like 1.6.1.X (where X increments on each change) and I want to see the exact version easily.  Having to manually change a java file makes that hard.  obviously that should make the apache spark releases easier as you don't have to manually change this file as well.
The other important part for me is the git information.  This easily lets me trace it back to exact commits.   We have a multi-tenant YARN cluster and users can run many different versions at once.  I want to be able to see exactly which version they are running.  The reason to know exact version can range from helping debug some problem to making sure someone didn't hack something in Spark to cause bad things (generally they should use approved version), etc.

Can we close this PR since it's been superseded by #13061?


chore: bdd-gh-1592924026 to 0.0.1

chore: Promote bdd-gh-1592924026 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


I found it is hard to insert a node in mxnet graph.

(Not Gluon) For example, if I want to insert a convolution node into VGG-16, I need to directly modify the symbol.json.

it's better to define the json format with protocol buffer, sadly mxnet didn't do that.


Update Curry.podspec version to 4.0.0

Thanks! I will push this to the pod trunk as soon as I regain access to my pod trunk account.


Compatibility with Kubernetes 1.23

Compatibility with 1.22 is covered in issue https://github.com/GoogleCloudPlatform/spark-on-k8s-operator/issues/1450 . Which image tag should be used for compatibility with K8s 1.23 ?

@indranilr you can use v1beta2-1.3.3-3.1.1 onward... there are no deprecations from 1.22->1.23 (until 1.25 actually). See https://kubernetes.io/docs/reference/using-api/deprecation-guide/.
Please close the issue if the above helped.


this.properties.view doesn't refer to the actual DOM

Hi !
I need to attach events to some children of my view.
I used to do that by getting my renderer's children using this.view.querySelector(...) on earlier versions of highway (up to 2.0.8).
Since 2.1.0, this.properties.view refers to a clone of the actual element. So to get the real DOM element I had to add at the very start of my Renderers' onEnter function the following line :
this.properties.view = this.wrap.lastElementChild

After searching in your code, I found two things causing problems in my case :

In core.js https://github.com/Dogstudio/highway/blob/eff45aea4c980010264f389572c2d37bf21aec24/src/core.js#L31 the document node is cloned so the view is not the one in the DOM
In renderer.js https://github.com/Dogstudio/highway/blob/eff45aea4c980010264f389572c2d37bf21aec24/src/renderer.js#L37 adding an element with this function creates a "duplicate" of the source element (this.properties.view becomes a clone)

Maybe I'm doing something wrong about it and I'm not using the correct properties/functions to get the current view ?
Anyway, thanks for this great lib 😄
Jordan

Hi @thiervoj,
Since the v2.1.0 I would recommend to use this.wrap.lastElementChild to get the data-router-view that has been added to the DOM. The this.properties.view value is only used internally to send the right view with the events but is not recommended to be used to select children elements of the data-router-view.
https://github.com/Dogstudio/highway/blob/6b4627dd414c4be9948907c8593e343c319d7c45/src/core.js#L284-L291
For the lines you spotted in Highway's source code, they are right and have their purpose.
Best regards,
Anthodpnt

Ok thanks, I will continue to use this.wrap.lastElementChild 👍


redeemSharingLink throws when it shouldn't

We're seeing some cases in telemetry where odsp-driver's fetchSnapshotWithRedeem will throw during fallback because it thinks the share link isn't present in the resolved url, even though it makes the same check before doing fallback.  This appears to be because the share link was moved in the resolved url in #7554 - the deprecated property is used to check if fallback should happen (in isRedeemSharingLinkError), whereas the new property is checked within the fallback itself.  If one is present, we would expect the other to be present too.  So the suspicion is that as part of that deprecation, code paths were not all updated correctly and we end up in this state.

@jatgarg are you the best person to look at this?
@pragya91 fyi

Another note here - Reminder on the guidance that asserts should be reserved for core invariant validation within the FF. Validating stuff coming over the wire from ODSP should be expressed with a proper error with errorType and fluidErrorCode.

I think @pragya91 should take this up as maybe she would know this better as she moved the sharingLink with the OdspResolvedUrl in the mentioned PR.

The code in #7554 tries to ensure that the value of odspResolvedUrl.shareLinkToRedeem and odspResolvedUrl.shareLinkInfo.shareLinkToRedeem remain in sync until the former property is deprecated. So even though there is a mismatch between the property usage within 'isRedeemSharingLinkError' and 'redeemShareLink' methods, the code should still work as expected. I can take a look at the logs to see if there is something else that is triggering the errors. Is there an incident corresponding to this bug?

IcM 271951213, will tag you in the incident as well

Created an issue to add testing for this scenario - https://github.com/microsoft/FluidFramework/issues/8408


✨ Add new Blazor web app template

Place your template repository link here:
https://github.com/jasontaylordev/azd-blazor
Commits

azd init
update infra

@microsoft-github-policy-service agree

@v-xuto Could you test this template?

Sure. We will test this template today.

@hemarina We have completed the testing of this template without any issues.


Add x-scheme-handler/atom as MimeType in atom.desktop.in

This is an attempt to register Atom as a default protocol client for atom:// URIs on at least some Linux systems. I'm not very familiar with this and am not quite sure if this is even the right path; thoughts from @atom/maintainers (maybe @smashwilson?) welcome!

This documentation seems to indicate that this will not work as written: https://developer.gnome.org/desktop-entry-spec/#extra-actions


Automating EPANET Compile on Windows --- Help wanted for testing

If you are a Windows user, and you have a few minutes, I would like your assistance in testing the automated script we prepared with @eladsal  for compiling EPANET for Windows.
No programming skills are needed, you just need to run a .bat script.
You should have installed the Microsoft Windows SDK 7.1 (You can check if you have this if you have this folder C:\Program Files\Microsoft SDKs\Windows\v7.1\ or if you have a Microsoft Windows SDK 7.1 folder in your Programs/Apps list.

Download https://github.com/OpenWaterAnalytics/EPANET/archive/dev-2.1-win-makefile.zip
Unzip anywhere
Go to \build\WinSDK\
Execute Makefile.bat

Executing Makefile.bat will call the Microsoft Windows SDK 7.1 Command Line, and  execute the compilation script of the DLL and the EXE.
Then it will copy the .dll, .exe and .h files in folders \64bit, \32bit and \32bitVB.
The last folder builds the DLL by using the .def file (included in the \WinSDK folder), which seems to necessary in VB applications.
In case something does not work as it should, please let us know of your Windows configuration (Windows version, Intel/AMD, Windows SDK installation problems) as well as any error messages which could appear.
Thanks, and wishes for a great new year!

Hi,

Thank you for this important project.
This not realy an EPANET problem, but while installing windows sdk I got this error. I don't seek for a solution here, just letting you know.

Danny

@dweintrob thanks for helping with this :)
Sometimes uninstalling "Microsoft Visual C++ 2010 Redistributable" (both x86 and x64) solves this problem. The SDK will reinstall it or you can reinstall it later.

This is a good point. Unfortunately this problem is quite common:
According to Microsoft: https://support.microsoft.com/en-us/kb/2717426

RESOLUTION
To resolve this issue, you must uninstall all versions of the Visual C++ 2010 Redistributable before installing the Windows 7 SDK.  You may have one or more of the following products installed:
Microsoft Visual C++ 2010 x86 Redistributable
Microsoft Visual C++ 2010 x64 Redistributable
After uninstalling the Microsoft Visual C++ 2010 Redistributable products, you may install the Windows 7 SDK.  After installing the Windows 7 SDK, you may then reinstall the newer version of the Visual C++ 2010 Redistributable products, in order to restore the Visual C++ 2010 Redistributable products to their original state.

@eladsal how about we automate the creation of the DEF file instead of doing it manually? e.g. using expdef.exe

Sure thing. expdef is not open source, right?

Well, i don't know its license, but the source code is available: http://purefractalsolutions.com/show.php?a=src/expdefsrc

O, we can try it, seems simple.

I will try to create conda packages for EPANET, working on it this week :-)

Thank you @bouziot , for V2.1 we have the compiled DLLs also for 64bits:
https://github.com/OpenWaterAnalytics/EPANET/releases/tag/v2.1

@eldemet can we close this issue?


ibmcloud: Test trigger updated to workflow_dispatch

Test Workflow trigger updated to workflow_dispatch
Fixes: #1001

New test case TestCreatePeerPodAndCheckUserLogs need this image, the e2e-test case will failed because the docker image quay.io/confidential-containers/test-images:testuser is missed.
root@peer-pod1 ~ $ docker pull quay.io/confidential-containers/test-images:testuser
Error response from daemon: manifest for quay.io/confidential-containers/test-images:testuser not found: manifest unknown: manifest unknown

Hi @liudalibj
Images are built and pushed using this workflow and I can see the successful completion of Action
https://github.com/confidential-containers/cloud-api-adaptor/actions/runs/5285209968
Also Image is now available under  quay.io/confidential-containers/test-images:testuser
sudharshanmuralidharan@Sudharshans-MacBook-Pro cloud-api-adaptor % kubectl run userimage --image=quay.io/confidential-containers/test-images:testuser --restart=Never
pod/userimage created
sudharshanmuralidharan@Sudharshans-MacBook-Pro cloud-api-adaptor % kubectl get pods
NAME        READY   STATUS      RESTARTS   AGE
userimage   0/1     Completed   0          7s
sudharshanmuralidharan@Sudharshans-MacBook-Pro cloud-api-adaptor % kubectl logs userimage
otheruser

Yeah, the missed image is built out with this PR, thanks for the fix.


Maniacal Monkeys

🐛 Bug Report
The initial issue of defaulting to barraging was brought to my attention by fsr, I then looked into any other issue that could be found relating to chinning and maniacal monkeys
Currently you wont be informed if you do not have the correct stats to perform chinning due to using boostChoice which returns none due to chinning not being a valid combat_option.
As it does not prevent the trip from continuing level 1's are able to use chinning to get upto level 60 in a single trip

By having any other combat_option (method) such as bursting, barraging or cannoning which are valid options for maniacal monkeys take priority even when the user specified to use the chinning method. (I think chinning was placed after the CBOPS section rather than within the method section)
Chinning is currently locked behind level 65 ranged, even though you are allowed to use lower level chinchompas (lowest tier requires 45 ranged) I assume this is just to cut out logic based on ranged level?
There is supposed to be a limit of using chinchompas requiring to have over 5000 chinchompas, this doesnt kick in for black chinchompa's

side note:
It also has a sense of vorkath quirk to where it there are boosts for mage vs range but will always display ranged boosts even when training mage due to it being higher in the list which may confuse some people  (These also apply to melee but that's a different story)

Resolved by #5193


Update to latest mongodb image and fixes #282

Not sure this fixes #252 but works alot better for me under minikube

@k8s-bot ok to test

Thanks @mikesplain - this does indeed fix #282 since this is the commit that fixes that issue (https://github.com/bitnami/bitnami-docker-mongodb/commit/f1a9b3dbdea668f396b475b83d731de12166c9dd).


fix: remove function and method name override

Before you open a pull request, note that this repository is forked from here.
Unless the issue you're trying to solve is unique to this specific repository,
please file an issue and/or send changes upstream to the original as well.

We opted to shorten the names displayed on the functions so that we don't show duplicated name and syntax to the users. The syntax is already captured inside syntax['content'] field, so no need to duplicate it back into the name field.

[x] Tests pass
[ ] Appropriate changes to README are included in PR

#22 made this fix for References and other entries where applicable conditions apply (whenever _create_reference function is called), while this PR updates for Function and Method types.


[FEEDBACK] Add stop/close button on mod mail threads on each of the responses we send to them

Version
0.6.2-pre.5
Feedback
Add stop/close button on mod mail threads on each of the responses we send to them so that we can close it easier instead of having to scroll all the way to the top
Submitter Information
Discord Tag: Karma's Guide#6864
Discord ID:<PHONE_NUMBER>69041665
Date/Time Submitted: 10/11/2020, 2:05:58 PM
Disclaimer: PLEASE READ
This issue was NOT written by the author of the repository OR the account that posted this issue. This issue was submitted through the program hosted in this repository, via Github's API, by someone that uses the program ("user"). The user can be found above.

The bot automatically pins the message that has the stop/blacklist reactions. As such, I do not believe this is needed.


Linear equation of state should be upgraded to account for salinity and pressure.

See title.

Also, we should not use β for the haline contraction coefficient.
Originally posted by @glwagner in https://github.com/glwagner/OceanTurb.jl/issues/41#issuecomment-506905395

+1


refactor GenericObject

It fixes a few bugs. The major refactoring includes

GenericObject#name does not need to be unique
Do not do validation before save, rather check whether a property attribute is defined when it is accessed.
GenericObjectDefinition cannot be deleted if some generic objects are still referencing to it.

@lfu @Fryguy @gmcculloug please review

@bzwei Is this to fix the sporadic test failure that @lfu was working on, or is this just a coincidental refactoring?  If the latter, can you verify if this fixes the sporadic test failure, and then we can just kill two birds with one stone.

Remove constraints to the name field, allowing it to be nil or duplicated

What is the reasoning behind allowing nil?  I understand the duplicated name thing because you can have two GenericObjects of different definitions that might share a name (although maybe then we should scope the uniqueness on generic_object_definition_id)

Instead of generic_object_definition.try(:property_attribute_defined?, m) perhaps prefer delegation in order to avoid the .try and also to encapsulate into a method that nil has meaning.
delegate :property_attribute_defined?, :to => :generic_object_definition, :allow_nil => true`

Then the callers would be
def method_missing(method_name, *args)
  m = method_name.to_s.chomp("=")
  super unless property_attribute_defined?(m)
  method_name.to_s.end_with?('=') ? custom_attribute_setter(m, args.first) : custom_attribute_getter(m)
end

def respond_to_missing?(method_name, _include_private = false)
   property_attribute_defined?(method_name.to_s.chomp('=')) ? true : super
end

@Fryguy I think the name field should allow to be nil. Just like other tables, almost  each one has a name field, but many tables do not force it to have value. Especially we even don't know how are users going to use generic objects, forcing each one to have a name can cause difficulties or inconvenience.

@Fryguy please review.

@Fryguy bump

Merging now and we can address any issues in a followup PR.

@gmcculloug is there a BZ for this?

@chessbyte No. Generic Object is new feature.

@bzwei Running git cherry-pick -x -m 1  d1f9898 on darga branch causes merge conflicts.
Please create PR against Darga branch.
/cc @gmcculloug

@chessbyte The porting of this PR to Darga has a dependency on #8666 which should not have been labelled darga/no. Once we port #8666 everything goes smoothly.
Do you still want me to create a PR to merge to Darga branch?

I changed #8666 to darga/yes after discussion

https://bugzilla.redhat.com/show_bug.cgi?id=1374836


Makefile: go vet

Adds go vet ./... as part of the Makefile lint target.
Fixes all the go vet linting errors.
/assign @SgtCoDFish

Flake?
/retest

/test pull-cert-manager-trust-verify


Skip systemVM template registration for Simulator

Description
This PR fixes #5936 - prevents registration of systemVM template for Simulator hypervisor

Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[X] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Feature/Enhancement Scale or Bug Severity
Bug Severity

[ ] BLOCKER
[ ] Critical
[ ] Major
[X] Minor
[ ] Trivial

Screenshots (if appropriate):
How Has This Been Tested?
Deploy a simulator hypervisor with advanced zone, and observed logs during addition of secondary store - no NPE

Hi @Pearl1594 Is this good to go in 4.16.1 ?

yes @sureshanaparti

@blueorangutan package

@blueorangutan package

@sureshanaparti a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: :heavy_multiplication_x: el7 :heavy_check_mark: el8 :heavy_check_mark: debian :heavy_check_mark: suse15. SL-JID 2500

@blueorangutan package

@sureshanaparti a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: :heavy_check_mark: el7 :heavy_check_mark: el8 :heavy_check_mark: debian :heavy_check_mark: suse15. SL-JID 2511

@blueorangutan test

@rohityadavcloud a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

Trillian test result (tid-3228)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 31389 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr5954-t3228-kvm-centos7.zip
Smoke tests completed. 92 look OK, 0 have errors
Only failed tests results shown below:

Test
Result
Time (s)
Test File


⚠ AZ-Launcher has degraded performance

In 7382da5, AZ-Launcher (https://az-launcher.nz/) experienced degraded performance:

HTTP code: 200
Response time: 8974 ms

Resolved: AZ-Launcher performance has improved in 2d64766 after 11 minutes.


Is this project dead?

Very neat project! Just wondering if you plan to actively develop it or if it was just a proof of concept. Thanks

@chrisdostert This is active. Thanks for your comment 😄
But I don't have the latest macOS. So I feel difficult to develop to use the latest API...


multiselectpicklist handleNotifyParent error on VF page

After adding my component which includes multiple multiselectpicklist components on VF page (customer cannot switch to LEX yet), I'm getting this error written at the bottom of the page, and multiselect picklists doesn't show any dropdown:
This page has an error. You might just need to refresh it. Action failed: c:strike_multiSelectPicklist$controller$handleNotifyParent [null is not an object (evaluating 'component.find('inputField').getElement().value = ''')] Failing descriptor: {c:strike_multiSelectPicklist$controller$handleNotifyParent}

this error doesn't show on lightningstrike.io (a VF page). could you give me more details about this error or what you have attempted to do as i cant reproduce this.


get_users not working

The below line is throwing an error:
users = api.get_users(ids = ['11111010109','193764933'])
error:
users = api.get_users(ids = ['11111010109','193764933'])
AttributeError: 'API' object has no attribute 'get_users'
Is anyone else facing the same error?

Like the error says, API doesn't have a get_users attribute/method.
You probably want to use API.lookup_users.
For code block usage, see https://docs.github.com/en/github/writing-on-github/working-with-advanced-formatting/creating-and-highlighting-code-blocks.


[BUG] Cannot show the back-front reversed card during first time learn with randomize card selected

Describe the bug
Cannot show the back-front reversed card during first time learn with randomize card selected
To Reproduce

randomize card option selected
create a new reversed card: question ::: answer
start lean new card just created
see the front-back card and click good
see the empty back-front reversed card

Expected behavior
See the back-front card in step 5.
Screenshots

Versions (please complete the following information):

OS: linux
Obsidian version: v0.12.19
Plugin version: v1.6.2
"5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) obsidian/0.12.4 Chrome/89.0.4389.128 Electron/12.0.6 Safari/537.36"

Fixed, should be available in the next release.


Commenting blocks of code with ctrl-/ causes them to automatically expand

VSCode Version: 1.27.0
OS Version: Ubuntu 18.04

Steps to Reproduce:

Collapse block of code by clicking on the - in the small box to the left of the top line of the block (ex. a function
Highlight the collapsed line of code
Press "ctrl-/" to comment every line selected

Does this issue occur when all extensions are disabled?: Yes

I'm not sure if this is a bug or intended design, but when I use the ctrl-/ feature to comment any code selected, every line in the collapsed block gets commented (which is great, very helpful) but then the block gets automatically expanded back to its original form. This can throw me off when my workflow involves highlighting a large block of code in the middle of a file and commenting it out. I would prefer it to stay collapsed when all of its inner lines are commented, so that I can continue working with the now commented out block collapsed. The way it is now, the commented block is also no longer collapsible.

The current design is to expand whenever something gets modified inside the folder block.
Also, most likely, what you have commented out is no longer a folding range, so preserving in not so easy here.

@aeschli would it be possible to have a settings so we can opt-out not to expand commented collapsed code? Just like the way Atom handles commenting collapsed code.

Can you explain more how that feature would work? As soon as you add comments, the folding ranges go away, unless you happen to have a new folding range for the comment.

@aeschli like this

Ah, I now I understand, the comment feature is smart and always expands to the whole folding range. That's a nice idea.

Thanks, can't wait to see this. This always put me off vscode when refactoring a rather large file. 😄


Receiving S3 access denied when running CloudFormation template

Receiving S3 access denied when running CloudFormation template here:
https://github.com/aws-solutions-library-samples/guidance-for-meter-data-analytics-on-aws/blob/main/templates/work-load.template.yaml
This includes making your own S3 bucket or leaving the bucket name the default like the instructions state is recommended. This has been verified from multiple accounts and even AWS Support.
I worked with Mrudhula<EMAIL_ADDRESS>who verified this is an issue.
Screenshot won't attach, receiving error but here is a copy paste
2023-08-30 16:40:21 UTC-0400 | IntegrationStack | CREATE_FAILED | S3 error: Access Denied For more information check http://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html
2023-08-30 16:40:21 UTC-0400 | DataStorageStack | CREATE_FAILED | S3 error: Access Denied For more information check http://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html
2023-08-30 16:40:21 UTC-0400 | MeterDataGeneratorStack | CREATE_FAILED | S3 error: Access Denied For more information check http://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html
2023-08-30 16:40:20 UTC-0400 | CopyGlueScriptsStack | CREATE_FAILED | S3 error: Access Denied For more information check http://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html
Thank you for your help and time

Please follow the steps in the README of the repo, you need to copy all resources to your S3 bucket.
https://github.com/aws-solutions-library-samples/guidance-for-meter-data-analytics-on-aws/blob/main/README.md If you experience any issues with that please let me know.

can we download the zip file, unzip it and simply load the whole folder into an s3? Or do we have to run it thru the command line?

Unfortunately not. As the deployment process includes packaging the lambda source code. This has to be done first, before copying everything to S3.

So it has to be done via command line and docker?
On Mon, Sep 11, 2023, 11:34 PM Sascha Janssen @.***>
wrote:

Unfortunately not. As the deployment process includes packaging the lambda
source code. This has to be done first, before copying everything to S3.
—
Reply to this email directly, view it on GitHub
https://github.com/aws-solutions-library-samples/guidance-for-meter-data-analytics-on-aws/issues/64#issuecomment-1715077202,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BBZR4TT45AV6EOPTJOFPC53XZ77BDANCNFSM6AAAAAA4GDAKJM
.
You are receiving this because you commented.Message ID:
<aws-solutions-library-samples/guidance-for-meter-data-analytics-on-aws/issues/64/1715077202
@github.com>

Yes. But you can setup a Cloud9 environment, which has all tools preinstalled and you just clone the repo and execute the scripts.

Ok, Thanks for the clarification and tips!
On Tue, Sep 12, 2023 at 8:03 AM Sascha Janssen @.***>
wrote:

Yes. But you can setup a Cloud9 https://aws.amazon.com/cloud9/
environment, which has all tools preinstalled and you just clone the repo
and execute the scripts.
—
Reply to this email directly, view it on GitHub
https://github.com/aws-solutions-library-samples/guidance-for-meter-data-analytics-on-aws/issues/64#issuecomment-1715900544,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BBZR4TSI4YLLRDPXIIJA7I3X2B2SHANCNFSM6AAAAAA4GDAKJM
.
 For the second part, the create configuration. It says
to adjust the template and store it besides the apply-stack.sh . As I am
working within the Cloud9 environment I can see the folder for the scripts.
Does this mean to store this json file in this folder?
On Tue, Sep 12, 2023 at 8:39 AM Dillon Estelle @.***>
wrote:

Ok, Thanks for the clarification and tips!
On Tue, Sep 12, 2023 at 8:03 AM Sascha Janssen @.***>
wrote:

Yes. But you can setup a Cloud9 https://aws.amazon.com/cloud9/
environment, which has all tools preinstalled and you just clone the repo
and execute the scripts.
—
Reply to this email directly, view it on GitHub
https://github.com/aws-solutions-library-samples/guidance-for-meter-data-analytics-on-aws/issues/64#issuecomment-1715900544,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BBZR4TSI4YLLRDPXIIJA7I3X2B2SHANCNFSM6AAAAAA4GDAKJM
.
You are receiving this because you commented.Message ID:
<aws-solutions-library-samples/guidance-for-meter-data-analytics-on-aws/issues/64/1715900544
@github.com>

I work at Subeca under Patrick and Anne. I mentioned that you had pointed me in the correct direction to set this up and they mentioned they knew you. If you have time this week I would love to ask you some questions on this product !

Sure just drop me an email (or find me on LinkedIn) and we can agree on a slot to dive deeper.


Add call start time to Call info

What feature are you requesting?
API lacks the call start time information. Some callStartTime exists as private prop, but it is fully dependent on when the current instance of Call is created after callAdapter.joinCall(...).
In case of one user reconnects, there is no possibility to know where the call actually started.
What would be the benefit of adding this feature?
To implement additional functionality of timers during the call.
To know exact duration of a call.
What solution would be ideal for you?
CallInfo object has callStartTime property.
What alternatives have you considered?
SDK apis to get call information including call start time, duration, is call in progress.
Is there any additional information for your request?
Attach screenshots or images add detail to your request:

Hi, Thanks for reaching out to us, we are currently looking into this. Will update you asap :)

HI @ToniaDemchuk - thank you for suggestion - we'll put this on the roadmap, we don't plan to add it as of today,
To unblock you - the way to implement this on application side would be to subscribe to call state and start counting time from the moment call goes to "Connected" state and finish it when it goes to "Disconnected"
Time should be stopped when user goes on hold/resumes the call
a point about reconnecting is valid - though we wouldn't stop timer in such case.
Let me know if this will work for you

Thanks for response.
For now, suggested workaround can work for me.
Also it can be good to know some statistics about the call in general - the whole group call start/end time, number of total participants during the whole call, etc.

Closing issue due to inactivity. if there is anything else you need please feel free to open the issue again! 😊


[Python]change extension of beam sdist from .zip to .tar.gz

Fixes: https://github.com/apache/beam/issues/28629
https://github.com/apache/beam/pull/28385 changed the sdist extension from zip to tar.gz. Zip tarballs are not supported according to https://peps.python.org/pep-0517/#source-distributions

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

R: @damccorm @jrmccluskey

Please update documentation on https://cwiki.apache.org/confluence/display/BEAM/Python+Tips as well.

How much validation have you done for these changes?

I ran https://github.com/apache/beam/actions/runs/6616347730/job/17970424418  which publishes snapshot. It was not finding the target file before but with this change it works.
I will find and run some more github actions to ensure they run correctly.

Please update documentation on https://cwiki.apache.org/confluence/display/BEAM/Python+Tips as well.

Done

@jrmccluskey @AnandInguva what are next steps here? We should prioritize this one since its a release blocker and ideally would be in before wednesday

I think, based on the conversations we've had, this is fine to get in now.


Add Material Transport Env

Sample DAgger run: https://wandb.ai/star-lab-gt/JaxMARL/runs/lj5zszf4?nw=nwusershalin

This is great, Shalin! Before merging could you (1) do a 1-seed run of DAgger with the normal RNN (not hyperaware) and (2) do a quick regression test on the fire env for both QMIX and DAgger (just make sure both still run the fire env correctly, don't have to train fully to completion). Thanks!

Added these runs under the tag test-regression!


[Feature Research]: Lepton AI

Feature Name
Lepton AI
Feature Description
Research about Lepton AI
Research Findings
Lepton AI
Lepton AI is a cutting-edge provider of AI infrastructure and services, designed to streamline the deployment and scaling of AI models. They offer a high-performance computing environment with top-tier GPU infrastructure, ensuring fast and efficient AI inference and training. Their cloud-native platform guarantees 99.9% uptime with comprehensive health checks and automatic repairs, making it a reliable choice for enterprises.
Lepton AI is known for its Pythonic framework, which simplifies the process of converting research and modeling code into production-ready services. They cater to a wide range of use cases, including image generation, natural language processing, and large-scale data processing. With features like dynamic batching, quantization, and speculative decoding, Lepton AI provides a robust and scalable solution for businesses looking to leverage AI technology. Their commitment to security and compliance, including SOC2 and HIPAA certifications, makes them a trusted partner for enterprise applications.
Use Cases

AI Model Deployment: Easily deploy AI models in a production-ready environment without needing to learn containers or Kubernetes.
Image Generation: Supports high-resolution image generation with distributed engines.
Natural Language Processing: Efficiently run NLP models like GPT-2 and Llama2.
Data Processing: Handle large-scale data processing tasks with accelerated serverless storage.

Additional Information

Scalability: Lepton AI supports scaling from small projects to large enterprise applications.
Ease of Use: With simple abstractions and prebuilt examples, it’s easy to get started and deploy models quickly.
Community and Support: Lepton AI has a strong community and offers extensive documentation and support to help you get the most out of their platform.

Links

Lepton AI Homepage
Lepton AI Documentation
Lepton AI References
Lepton AI GitHub
Lepton AI Login Portal

Potential Impact
Lepton AI has the potential to significantly transform various industries by making AI more accessible and efficient. By providing a high-performance computing environment with top-tier GPU infrastructure, Lepton AI enables faster and more efficient AI model training and inference. This can lead to quicker deployment of AI solutions, reducing time-to-market for innovative products and services.
In sectors like healthcare, finance, and retail, Lepton AI’s robust and scalable platform can enhance data processing capabilities, improve predictive analytics, and enable more personalized customer experiences. For instance, in healthcare, it can support advanced diagnostic tools and personalised treatment plans. In finance, it can enhance fraud detection and risk management. Overall, Lepton AI’s comprehensive and secure AI infrastructure can drive significant advancements in technology and business processes, fostering innovation and efficiency across various domains.
Additional Resources (optional)
No response
Feature Priority
High

No test cases

@DevDigiLance
import pytest
import os
from swarmauri.standard.llms.concrete.LeptonAIModel import LeptonAIModel as LLM
from swarmauri.standard.conversations.concrete.Conversation import Conversation
from swarmauri.standard.messages.concrete.AgentMessage import AgentMessage
from swarmauri.standard.messages.concrete.HumanMessage import HumanMessage
from swarmauri.standard.messages.concrete.SystemMessage import SystemMessage

@pytest.mark.skipif(not os.getenv('LEPTON_API_KEY'), reason="Skipping due to environment variable not set")
@pytest.mark.unit
def test_ubc_resource():
    API_KEY = os.getenv('LEPTON_API_KEY')
    llm = LLM(api_key = API_KEY)
    assert llm.resource == 'LLM'

@pytest.mark.skipif(not os.getenv('LEPTON_API_KEY'), reason="Skipping due to environment variable not set")
@pytest.mark.unit
def test_ubc_type():
    API_KEY = os.getenv('LEPTON_API_KEY')
    llm = LLM(api_key = API_KEY)
    assert llm.type == 'LeptonAIModel'

@pytest.mark.skipif(not os.getenv('LEPTON_API_KEY'), reason="Skipping due to environment variable not set")
@pytest.mark.unit
def test_serialization():
    API_KEY = os.getenv('LEPTON_API_KEY')
    llm = LLM(api_key = API_KEY)
    assert llm.id == LLM.model_validate_json(llm.model_dump_json()).id

@pytest.mark.skipif(not os.getenv('LEPTON_API_KEY'), reason="Skipping due to environment variable not set")
@pytest.mark.unit
def test_default_name():
    API_KEY = os.getenv('LEPTON_API_KEY')
    model = LLM(api_key = API_KEY)
    assert model.name == 'llama3-8b'

@pytest.mark.skipif(not os.getenv('LEPTON_API_KEY'), reason="Skipping due to environment variable not set")
@pytest.mark.unit
def test_no_system_context():
    API_KEY = os.getenv('LEPTON_API_KEY')
    model = LLM(api_key = API_KEY)
    conversation = Conversation()

    input_data = "Hello"
    human_message = HumanMessage(content=input_data)
    conversation.add_message(human_message)

    model.predict(conversation=conversation)
    prediction = conversation.get_last().content
    assert type(prediction) == str

@pytest.mark.skipif(not os.getenv('LEPTON_API_KEY'), reason="Skipping due to environment variable not set")
@pytest.mark.acceptance
def test_nonpreamble_system_context():
    API_KEY = os.getenv('LEPTON_API_KEY')
    model = LLM(api_key = API_KEY)
    conversation = Conversation()

    # Say hi
    input_data = "Hi"
    human_message = HumanMessage(content=input_data)
    conversation.add_message(human_message)

    # Get Prediction
    model.predict(conversation=conversation)

    # Give System Context
    system_context = 'You only respond with the following phrase, "Jeff"'
    human_message = SystemMessage(content=system_context)
    conversation.add_message(human_message)

    # Prompt
    input_data = "Hello Again."
    human_message = HumanMessage(content=input_data)
    conversation.add_message(human_message)

    model.predict(conversation=conversation)
    prediction = conversation.get_last().content
    assert 'Jeff' in prediction

@pytest.mark.skipif(not os.getenv('LEPTON_API_KEY'), reason="Skipping due to environment variable not set")
@pytest.mark.unit
def test_preamble_system_context():
    API_KEY = os.getenv('LEPTON_API_KEY')
    model = LLM(api_key = API_KEY)
    conversation = Conversation()

    system_context = 'You only respond with the following phrase, "Jeff"'
    human_message = SystemMessage(content=system_context)
    conversation.add_message(human_message)

    input_data = "Hi"
    human_message = HumanMessage(content=input_data)
    conversation.add_message(human_message)

    model.predict(conversation=conversation)
    prediction = conversation.get_last().content
    assert type(prediction) == str
    assert 'Jeff' in prediction

@pytest.mark.skipif(not os.getenv('LEPTON_API_KEY'), reason="Skipping due to environment variable not set")
@pytest.mark.acceptance
def test_multiple_system_contexts():
    API_KEY = os.getenv('LEPTON_API_KEY')
    model = LLM(api_key = API_KEY)
    conversation = Conversation()

    system_context = 'You only respond with the following phrase, "Jeff"'
    human_message = SystemMessage(content=system_context)
    conversation.add_message(human_message)

    input_data = "Hi"
    human_message = HumanMessage(content=input_data)
    conversation.add_message(human_message)

    prediction = model.predict(conversation=conversation)

    system_context_2 = 'You only respond with the following phrase, "Ben"'
    human_message = SystemMessage(content=system_context_2)
    conversation.add_message(human_message)

    input_data_2 = "Hey"
    human_message = HumanMessage(content=input_data_2)
    conversation.add_message(human_message)

    model.predict(conversation=conversation)
    prediction = conversation.get_last().content
    assert type(prediction) == str
    assert 'Ben' in prediction


No browser support listed

I feel like the browser support is the most important piece of information for any polyfill, but I cannot seem to find where you list this information.
What is the browser support? Also, please update the readme.md and doc site to have this information easily visible.

In short: IE8+


9174 remove auth tokens from vizjson

Moves auth tokens outside the vizjson, to an embed variable.
Uses branch from https://github.com/CartoDB/cartodb.js/pull/1377 (not yet merged)
Closes #9174
Closes #9276

Please CR @gfiorav

Sweet stuff! Great tests.
After conflicts and comment it's 📦 ready

Please take a second look @gfiorav (although I still have to resolve package.json conflicts). I changed things a bit now that embed authentication is working properly.

📦 it for the 🆓 🌍


Add status and current batch number to cut off response

@adriantimberlid remember to use Conventional Commit message when you squash and merge.


Propagate handshake error

Ok nice. I'll have to test this, as I'm not sure even the io::Error is propagated all the way to the wire. But if it is, this approach should work.

Haven't tested, but it's an improvement anyway :+1:


Suggest encode utf-8 to avoid errors on windows machines

This will leave encoding errors. This may also break other wikis if emojis are already is use. we can discuss if this is wise.

this make sense, and the same two lines (different line numbers) in mwb3.py need this change - and will be included in mwb Version 3 release.
also, there is this Python Enhancement Proposal (which may be related?) for some time in the future: https://peps.python.org/pep-0686/

No longer needed.  Will be in next version.


rz upload always auto delete when completed

my file is small, but upload always fails, sometimes the file can't upload again and again. the other tool, for example xshell can upload success.

seem to zmodemjs not support retry.
Refer to https://github.com/nxshell/zmodemjs/blob/master/src/zsession.js#L1403


Update v4 downloads again

Update v4 downloads with checksums, sizes, and final synced paths.

Fantastic. The only change is constraint section needs removing.

Oop yeah I threw that commit in a diff PR, but it can be in here easily enough.


Importing "vue-chemistry" and "vue-chemistry/math" occurs error with vite

import { reactify, set } from 'vue-chemistry'
import { sum } from 'vue-chemistry/math'

This occues the error below with<EMAIL_ADDRESS>[plugin:vite:import-analysis] Deep import "vue-chemistry/math" should be avoided
because dependency "vue-chemistry" has been pre-optimized.
Prefer importing directly from the module entry:

import { ... } from "vue-chemistry"

If the used import is not exported from the package's main entry and can only be attained via deep import,
you can explicitly add the deep import path to "optimizeDeps.include" in vite.config.js.

By excluding this package from optimizeDeps fixes this, but maybe renaming vue-chemistry/all to vue-chemistry and vue-chemistry to vue-chemistry/core would be better?
  optimizeDeps: {
    exclude: ['vue-chemistry']
  }

renaming vue-chemistry/all to vue-chemistry and vue-chemistry to vue-chemistry/core would be better?

Sounds reasonable, wanna draft a PR for it? Thanks.

renaming vue-chemistry/all to vue-chemistry and vue-chemistry to vue-chemistry/core would be better?

Sounds reasonable, wanna draft a PR for it? Thanks.

Sure, Ill do it 👍

Sure, Ill do it 👍


incorrect image

Hello. When using AMDVLK, such a picture appears, when using RADV, the picture is correct.
How can I find the reason?

I can not reproduce it with Q4_2 AMDVLK on ubuntu 20.04.
Could you provide more info about your system and cards info?
Guess something wrong with Xserver (maybe others) framebuffer format.

I have a not quite standard system. I just wonder how can I find the cause of this wrong picture?

Maybe we can start at demo_create_surface and vulkan swap-chain.


Cleanup Legacy docs

Closes #
Code Changes

[x] landing page action item to visit new docs site
[x] remove redundant docs pages

Steps to Confirm

[ ] nox -s docs_serve and poke around

Pre-Merge Checklist

[x] All CI Pipelines Succeeded
Documentation:

[x] documentation complete, PR opened in fidesdocs
[ ] documentation issue created in fidesdocs

[x] Issue Requirements are Met
[x] Relevant Follow-Up Issues Created
[x] Update CHANGELOG.md

Description Of Changes
Removes all of the pages that are now made redundant and encourages visitors to go to the new docs site. Retains the helpful autogenerated docs and developer-centric pages
Note that all remaining docs infrastructure remains in place, new docs versions will be continually pushed out, etc. The change here is the removal of redundant docs pages and pointing users to the new ones.

I tested and all seems good. My only question is why do we want two different docs sites? Why not just put everything in one place?

Good question...

We have a lot of legacy marketing materials that point to these docs URL, so for that reason we want to at least push people towards the new docs site if they end up at the legacy site
With the new site we lost the ability to integrate the autogenerated docs (CLI and API) which in my opinion are actually critical...so this will be the "engineering-led" docs area that still includes some of those critical autogenerated pieces

Ideally I'd like to move the new docs site back into this repo to decrease the friction of engineers contributing to docs directly, but that is something we'll tackle down the road


Hotfix/js reg js

Closes #246

Codecov Report

Merging #247 (427af15) into master (8acfa4a) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 427af15 differs from pull request most recent head 0a038c0. Consider uploading reports for the commit 0a038c0 to get more accurate results

@@           Coverage Diff           @@
##           master     #247   +/-   ##
=======================================
  Coverage   69.32%   69.32%
=======================================
  Files          31       31
  Lines        1154     1154
  Branches      223      223
=======================================
  Hits          800      800
  Misses        354      354

Continue to review full report at Codecov.

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


Bump deps: fontconfig (switch to meson, patch known leaks)

Adds 4 patches made to fontconfig's main branch since v2.13.94.

Thanks, it's removed most of the memory leaks I was previously seeing, but we're still impacted by what I think is caused by https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/302
==102705== 321 bytes in 32 blocks are indirectly lost in loss record 8,127 of 8,480
==102705==    at 0x52A5045: malloc (vg_replace_malloc.c:381)
==102705==    by 0x573A50E: strdup (strdup.c:42)
==102705==    by 0x12B3EDFC: FcValueSave
==102705==

Rather luckily this has just been fixed upstream so I'll add this patch too.
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/merge_requests/220

If preferred, I could make a v8.12.2-build2 release at https://github.com/libvips/build-win64-mxe with the same patches incorporated (+ glib, expat and lcms2 version bumps).

Yes please, that would be great.

https://github.com/libvips/build-win64-mxe/releases/tag/v8.12.2-build2 :tada:


Replace calls to strchr

For performance

Just curious...is this better or worse than a switch statement?

I did not specifically investigate for this case.
I did look into 'if' vs 'switch' when I played with QPDFTokenizer last summer. Both my own experiments and comments on eg stackoverflow suggests that there is no real difference where '==' comparisons are concerned. Where '<' / '>' or 'a < x < b' comparisons are concerned if statements can have the advantage when they allow common cases (eg space or ctrl char '< 33') to be moved to the top rather that being handled  in the default part of a switch statement. (For JSON::encode_string this made the key difference and the other tweaks were just icing on the cake).
Returning a boolean expression theoretically should be more efficient than returning true / false from within an 'if' statement but in practice I would be very surprised if the compiler didn't optimize the if statement away.