Change backspace and delete keys

Whenever I say 'delete', the backspace key seems to be pressed. I find this unexpected since delete is a dedicated key and I would expect that to be pressed in almost every circumstance. For instance, when in the file explorer and wanting to delete a file, I have to say "forward delete" to delete the file, which is awkward. Even when text editing delete should remove the character in front of the cursor, not behind.
And I know I can change this myself, but I'd like to stay close to the base to make it easier to merge upstream changes. Moreover, if I find this unexpected I'm sure many other people will run into the same thing. I believe this change would make talon more newbie-friendly.

aegis had some comments in slack that I've copied over here:

It's an awkward situation because the right answer is per platform
I would vote against changing the binding for all platforms at once.
I think we need a clear distinction between "the correct command to delete one letter" vs the key commands, and try to make the key commands os specific

aegis had some comments in slack that I've copied over here:

It's an awkward situation because the right answer is per platform
I would vote against changing the binding for all platforms at once.
I think we need a clear distinction between "the correct command to delete one letter" vs the key commands, and try to make the key commands os specific

another consideration is whether talon behaves the same across operating systems, which changing this would break as far as text goes

another consideration is whether talon behaves the same across operating systems, which changing this would break as far as text goes

I'm only familiar with linux and windows. Is delete a fundamentally different key on Mac?

I'm only familiar with linux and windows. Is delete a fundamentally different key on Mac?

https://store.storeimages.cdn-apple.com/4982/as-images.apple.com/is/MLA22LL?wid=2000&hei=2000&fmt=jpeg&qlt=95&op_usm=0.5%2C0.5&.v=1496944005839

https://store.storeimages.cdn-apple.com/4982/as-images.apple.com/is/MLA22LL?wid=2000&hei=2000&fmt=jpeg&qlt=95&op_usm=0.5%2C0.5&.v=1496944005839

Ok that is awkward. For reference all my (and windows/linux users) keyboards look like this

Ok that is awkward. For reference all my (and windows/linux users) keyboards look like this

It makes sense to make this mapping differ based on the OS then. Would you all agree? If yes I will try to modify the PR to reflect that.

It makes sense to make this mapping differ based on the OS then. Would you all agree? If yes I will try to modify the PR to reflect that.

I agree

I agree

My biggest issue with an os specific change is if a user is using both Mac and Windows, and installs knausj on both:
On one computer, saying delete will delete a character to the left. On the other, saying delete will delete a character to the right.

My biggest issue with an os specific change is if a user is using both Mac and Windows, and installs knausj on both:
On one computer, saying delete will delete a character to the left. On the other, saying delete will delete a character to the right.

I agree that is suboptimal in that case. But it is a niche case and right now for windows and linux users the mapping makes no sense at all, which is arguably the biggest chunk of the users. Can you think of a solution that would solve all cases in a satisfactory way? What about:

Map backspace always to backspace
Map 'forward delete' always to delete
Map 'delete' to delete on windows and linux, and to 'backspace' on Mac

This way all users get their native expected behavior, and crossplatform users could use the explicit backspace/forward delete combination.

I agree that is suboptimal in that case. But it is a niche case and right now for windows and linux users the mapping makes no sense at all, which is arguably the biggest chunk of the users. Can you think of a solution that would solve all cases in a satisfactory way? What about:

Map backspace always to backspace
Map 'forward delete' always to delete
Map 'delete' to delete on windows and linux, and to 'backspace' on Mac

This way all users get their native expected behavior, and crossplatform users could use the explicit backspace/forward delete combination.

I just checked and Talon has slightly more Mac users than both Windows and Linux users combined, FYI.
This proposed change also changes the behavior of delete for existing Windows/Linux users who have been using it this way for a while. I'm still leaning strongly against this.
"muscle memory" is a big thing. I completely understand the motivation behind some new users wanting something different, but this is not a common complaint and it's really unfortunate if a few hundred existing Windows/Linux users git pull and a common command changes without warning. Even if there's a solid argument that the keys are in the wrong order for them, they've learned the wrong order and been dealing with it, so making the decision to change the mapping for existing users would be unfortunate.
I searched the Slack and only found two obvious complaints about the delete key order in the last three years, yours included. Someone also actually tried to make this change in 2019 with the talon_community repo, and there was a user complaint immediately:

oof. who switched us to the Windows style of deletion? delete became backspace and forward delete became delete

For backwards compatibility, I would recommend adding a setting for this, which could cover more behavior than just delete, would be easy for any user to change, and would solve both backwards compatibility and consistency across operating systems.
Like user.os_feel = "windows"

I just checked and Talon has slightly more Mac users than both Windows and Linux users combined, FYI.
This proposed change also changes the behavior of delete for existing Windows/Linux users who have been using it this way for a while. I'm still leaning strongly against this.
"muscle memory" is a big thing. I completely understand the motivation behind some new users wanting something different, but this is not a common complaint and it's really unfortunate if a few hundred existing Windows/Linux users git pull and a common command changes without warning. Even if there's a solid argument that the keys are in the wrong order for them, they've learned the wrong order and been dealing with it, so making the decision to change the mapping for existing users would be unfortunate.
I searched the Slack and only found two obvious complaints about the delete key order in the last three years, yours included. Someone also actually tried to make this change in 2019 with the talon_community repo, and there was a user complaint immediately:

oof. who switched us to the Windows style of deletion? delete became backspace and forward delete became delete

For backwards compatibility, I would recommend adding a setting for this, which could cover more behavior than just delete, would be easy for any user to change, and would solve both backwards compatibility and consistency across operating systems.
Like user.os_feel = "windows"

Backwards compatibility makes sense here I guess. An os_feel variable sounds like a reasonable option to me. I'm not very fluent with the talon API yet, so I will try to make some time in the near future to figure out how that would work.

Backwards compatibility makes sense here I guess. An os_feel variable sounds like a reasonable option to me. I'm not very fluent with the talon API yet, so I will try to make some time in the near future to figure out how that would work.

I would not be in favor of setting for this, I rather have MAC style by default. Users of this Repository have to become accustomed to changing keywords to their likings anyway. But I'm more in favor of making this OS specific, I value "lower learning curve" Over "backwards compatibiility". The steep learning curve will scare people off and not having a backspace is part of that, but existing users will simply change the key binding back (after complaining a bit).

I would not be in favor of setting for this, I rather have MAC style by default. Users of this Repository have to become accustomed to changing keywords to their likings anyway. But I'm more in favor of making this OS specific, I value "lower learning curve" Over "backwards compatibiility". The steep learning curve will scare people off and not having a backspace is part of that, but existing users will simply change the key binding back (after complaining a bit).

I personally think there's an immense amount of value in consistent behavior across OSes. I do understand this perspective/frustration, though.
I personally use a combination of OS X and Windows. Once you develop some muscle memory, platform-specific behavior on common commands become a substantial liability, error-wise. I've put in some effort to keep things platform-agnostic for this reason.
That said, I'm not really opposed to a setting for this.

I personally think there's an immense amount of value in consistent behavior across OSes. I do understand this perspective/frustration, though.
I personally use a combination of OS X and Windows. Once you develop some muscle memory, platform-specific behavior on common commands become a substantial liability, error-wise. I've put in some effort to keep things platform-agnostic for this reason.
That said, I'm not really opposed to a setting for this.

The benefit of a setting is you can set it to windows on your Mac too, if you went the other direction

The benefit of a setting is you can set it to windows on your Mac too, if you went the other direction

If the os_feel setting would not be set to the native OS by default, then we'd lose benefit of giving new windows/linux users a sane mapping by default.

If the os_feel setting would not be set to the native OS by default, then we'd lose benefit of giving new windows/linux users a sane mapping by default.

knausj_talon can upgrade new users gradually without disrupting any existing users by doing two complementary updates at different times.

Automatically create a knausj_settings.talon file when knausj_talon runs, if it does not already exist. Start by putting os_feel = "mac" in it.
A few months later, update knausj_talon to create the file (for new users only, if the file does not already exist) using the current OS value instead.

This means as long as existing users update within the few month grace period, the behavior won't ever unexpectedly change. And new users will eventually get the current OS behavior out of the box.

knausj_talon can upgrade new users gradually without disrupting any existing users by doing two complementary updates at different times.

Automatically create a knausj_settings.talon file when knausj_talon runs, if it does not already exist. Start by putting os_feel = "mac" in it.
A few months later, update knausj_talon to create the file (for new users only, if the file does not already exist) using the current OS value instead.

This means as long as existing users update within the few month grace period, the behavior won't ever unexpectedly change. And new users will eventually get the current OS behavior out of the box.

That sounds like a viable strategy. Are there any other mappings we need to consider for os_feel, apart from backspace/delete?

That sounds like a viable strategy. Are there any other mappings we need to consider for os_feel, apart from backspace/delete?

@lunixbochs  I wanted to take a crack at this today, but I realized that this scenario is likely to occur more than once.
It would be really beneficial if we could generalize the update-scheme laid out above to work more than once. And for more plugins. Checking if a settings file exists will only work once, since for any future breaking tweaks it will already exist.
So maybe we shouldn't check if a file exists, but rather if a setting exists.
The general idea is then

Add an explicit setting that preserves the current behavior and ship.
Later, remove this explicit setting in a way that existing users will keep it but new users will not.

Some thoughts:

When these settings are simply tracked in the git repository of the plugin it won't work, since a git pull to update the plugin will apply the breaking change for all users.
When the setting created in step 1 is not tracked in the git repository of the plugin there needs to be an untracked file somewhere in which they are kept. Should this exist on a plugin level, or on a user level? The latter sounds better since you won't end up with untracked files all over your plugin infrastructure, and you keep all compatibility settings in once place which improves the visibility.

Some thoughts (FWIW):

When a user switches between systems, they have to adjust to differences in the platforms - like the delete key behavior or using forward-/back-slashes for paths. This is completely independent of any voice considerations. I'm not saying that talon shouldn't make things easier when possible, but this cognitive dissonance is already a familiar fact of life and it's not really talon's job to decide which variations should take precedence. That is, I think it's enough to provide people with a way to customize things but perhaps the default behavior should simply mirror the native style for each platform.
Two new settings might be called for, one for os feel and another for selecting between new and legacy behavior.
The legacy behavior can remain the default for as long as desired, as long as people have a way to switch away from it. However, it's probably less disruptive to make the change now than it would be later when the community has grown. That is, if 10% of the people are going to ask for help due to confusion over the change in behavior, then it's better to do it when there are 100 users than 1000 (or 10,000). Also, the current user community is likely more sophisticated and flexible than future users might be.

@lunixbochs Suppose we implement you roll out scheme and after a few months everyone has automatically defined an os_feel setting reflecting their original behavior. So far so good. Then some plugin or script decides to take os_feel into account for some OS-sensitive mappings. Suddenly a bunch of people who pull that script have breaking behavior, because the mapping they got used to are not the ones matching their defined os_feel setting. Do you feel what I'm getting at?

Call it knausj_os_feel if you're that worried, and document what it's for. There's no issue as long as only the knausj repo is using it and the folks maintaining it know what it's for.

Call it knausj_os_feel if you're that worried about third parties messing it up, and document what it's for. There's no issue as long as only the knausj repo is using it and the folks maintaining it know what it's for. I don't think we have enough cross repo dependency to worry about that right now anyway. It's fine to only guarantee how it affects knausj.
After the switch over, code shouldn't use the setting unless it uses the setting from the first time the code is written. That means it's fine to write new code at any point in knausj using os_feel, but it's incorrect to modify existing knausj code down the line to use the setting in a way that breaks user workflows.

As a Linux/Windows user who initially found this behavior confusing but has now gotten used to it, I'd vote we maintain the status quo.  It's nice to keep a consistent cross-platform experience, since many of us use one OS at work and a different OS at home.

As a new user of talon who develops on both windows and Mac daily, I didn't find the mapping of delete to backspace on windows at all challenging. IIRC I did have to make a mental note when I was first learning that it wasn't directly mapped to the named key, but tbh I prefer this mapping. I quickly learned to use clear right when I want to delete the character to the right of the cursor. The clear ligatures are generally more useful/easier for me to pronounce clearly anyway. 100% agree commands should be platform agnostic as much as possible, even if that results in a few quirks. When I switch between windows/Mac keyboards, I actually use the same physical keyboard and press a button to change the key mapping. The physical movement of my fingers is almost identical between OSs, with the vast majority of the difference being key combos that only exist on one OS.

I'm probably going to close this one since I generally prefer the commands to be platform-agnostic as much as is reasonable.
That said, I'm not entirely opposed to the proposed "choose you preference" approach, if someone really wants to take the time and re-open. It's not a priority for me, though.


test.ts should contain // tslint:disable:ordered-imports

Bug Report or Feature Request (mark with an x)
- [ ] bug report -> please search issues before submitting
- [x ] feature request

Command (mark with an x)
- [ x] new

Desired functionality
TSLint has feature for auto fixing. And in our project we do have check for ordered-imports, and after I did save my test.ts by adding new code tslint reordered my imports which cause failure for test fakeAsync. While import order is important there is not information about that in file. There is also issue which was solved https://github.com/angular/angular/issues/11317.
To prevent this type of issues would be nice to update test.ts file when you create a project with disabling tslint rule for this case.

If its get approved I can make a PR

This rule doesn't come by default when create a new application.
Thus, I don't think we should disable rules that have been might be added by consumers. In that case it is up to the consumer to decide were a rule needs to be disabled and if it should be disabled at all.

@alan-agius4  But then how to avoid problem like this? When I did run my tests it shows me error without any clue what is wrong.

@alan-agius4 It might not, but since, if someone does ng new, edits tslint (spaces to tabs, imports order), and then run ng lint, it will just break without the user ever knowing what happened, it is the only file where imports have meaning side effects. This gave us a headache for a few days


ImportError: cannot import name 'LightGBMClassifier' in v0.18.1

Describe the bug
When I try to load LightGBMClassifier with from mmlspark import LightGBMClassifier, I get the error: ImportError: cannot import name 'LightGBMClassifier'
It was working in my previous version of mmlspark (a dev version of 0.17), but since updating to 0.18.1, it no longer works.
Info:

MMLSpark Version: v0.18.1
Spark Version: 2.4.3
Spark Platform: Databricks (Runtime 5.5 LTS ML)

@tyler-romero the namespaces changed, I think it is now from mmlspark.lightgbm import LightGBMClassifier, FYI @mhamilton723 do we have a doc on which namespaces changed to where?

Thanks! Found the new namespaces here: https://mmlspark.blob.core.windows.net/docs/0.18.1/pyspark/modules.html


Support filtering of Results using name of the PipelineRun/TaskRun

Feature request

Currently there is no filtering option that can search for result created for a particular PipelineRun/TaskRun. The current flow is to search for records and then find the result name from them.
There should be a filtering option that can directly be applied to the Results using PipelineRun/TaskRun name.
Use case

This feature will be useful in:

For dashboards where the user is trying to populate data about a Run. This feature will cut down on number of API calls and bandwidth used.

Approach
We can add a new annotation to the Result.Summary that contains the name of the PipelineRun/TaskRun creating that results. The current path is records.data.metadata.name. After adding annotation the filter for results can be used as
filter='summary.annotations["RunName"]=="name"'

There can be other approaches as well.

cc @enarha

Any progress on that front? That's something we would consider contributing at some point if there is no active work done on this. We need this feature to integrate the dashboard with the results api. I like the approach you suggested @avinal . It sounds like a quick win that could be put in place relatively fast.

Don't we support this with CEL filtering?


feat: Implement server-client communication

Features Implemented

A Session class that handles the communication between the server
and the client, using Boost ASIO for the networking
A SessionManager class that manages all the sessions
A Server base class that handles the server logic and accepts new
connections in multiple threads
A UniverseServer derived class that provides an interface for the
game logic
A NetworkClient class that handles the client logic and communicates with
the server using Boost ASIO and multiple threads
A ClientApplication as the main class of the program with basic
showing TitleScreen functionality
A ClientController class that provides functions for the client to
change between different states and scenes
A Logger class that provides different levels of logging and supports
std::format style formatting

Chore

Modify the CMakeLists.txt to include the Boost library and resolve
path formatting issues
Modify the CMakeLists.txt to enable AddressSanitizer in MSVC
Modify title name in TitleScreen
Modify the ClientApplication's constructor for more encapsulation
Optimize codes style and add some comments

Known Issues
When compiling the project with Visual Studio 2022 Enterprise MSVC x86,
the communication_tests have a 20% chance of running into an error:
cannot dereference string iterator because the iterator was invalidated
Solution: Compile the project with Visual Studio 2022 Community MSVC x86


docs: Improve "Thinking in React" for color-blind people

What this PR does:
Updates an image and its alt-text in the "Thinking in React" section of the docs to make it accessible for people with color blindness. Kind of hard for color blind to see those colors - let's lead by example ☺
Before:

After:

lgtm - @eps1lon ?

Bonus points for anybody that converts this to actual HTML for even better a11y

@eps1lon Do you by chance happen to know other sections of the docs that need a bit of a11y care? 🙂

@eps1lon Do you by chance happen to know other sections of the docs that need a bit of a11y care?

I've never really looked into it for reactjs.org to be honest. Since a11y is a continuous process it's probably best to re-evaluate it occasionally.
Though the docs are currently being rewritten so I would suggest you wait for https://github.com/reactjs/reactjs.org/issues/3308 to be completed.


Cannot receive any sensor data

Hi guys I have spent 2 hours trying to receive any data from the wallbox.
so I switched the mosquitto to debug mode and got this
2023-02-28 17:22:25: Received PUBLISH from go-echarger_093546 (d0, q0, r1, m0, 'go-eCharger/093546/rssi', ... (3 bytes))
2023-02-28 17:22:25: Received PUBLISH from go-echarger_093546 (d0, q0, r1, m0, 'go-eCharger/093546/utc', ... (25 bytes))
2023-02-28 17:22:25: Received PUBLISH from go-echarger_093546 (d0, q0, r1, m0, 'go-eCharger/093546/loc', ... (32 bytes))
2023-02-28 17:22:25: Received PUBLISH from go-echarger_093546 (d0, q0, r1, m0, 'go-eCharger/093546/rbt', ... (7 bytes))
2023-02-28 17:22:25: Received PUBLISH from go-echarger_093546 (d0, q0, r1, m0, 'go-eCharger/093546/nrg', ... (39 bytes))
2023-02-28 17:22:25: Received PUBLISH from go-echarger_093546 (d0, q0, r1, m0, 'go-eCharger/093546/fhz', ... (6 bytes))
2023-02-28 17:22:26: Received PUBLISH from go-echarger_096071 (d0, q0, r1, m0, 'go-eCharger/096071/utc', ... (25 bytes))
2023-02-28 17:22:26: Received PUBLISH from go-echarger_096071 (d0, q0, r1, m0, 'go-eCharger/096071/loc', ... (32 bytes))
2023-02-28 17:22:26: Received PUBLISH from go-echarger_096071 (d0, q0, r1, m0, 'go-eCharger/096071/rbt', ... (6 bytes))
2023-02-28 17:22:26: Received PUBLISH from go-echarger_096071 (d0, q0, r1, m0, 'go-eCharger/096071/nrg', ... (39 bytes))
2023-02-28 17:22:26: Received PUBLISH from go-echarger_096071 (d0, q0, r1, m0, 'go-eCharger/096071/fhz', ... (6 bytes))
2023-02-28 17:22:26: Received PUBLISH from go-echarger_093546 (d0, q0, r1, m0, 'go-eCharger/093546/utc', ... (25 bytes))
2023-02-28 17:22:26: Received PUBLISH from go-echarger_093546 (d0, q0, r1, m0, 'go-eCharger/093546/loc', ... (32 bytes))
2023-02-28 17:22:26: Received PUBLISH from go-echarger_093546 (d0, q0, r1, m0, 'go-eCharger/093546/rbt', ... (7 bytes))
2023-02-28 17:22:26: Received PUBLISH from go-echarger_093546 (d0, q0, r1, m0, 'go-eCharger/093546/nrg', ... (39 bytes))
2023-02-28 17:22:26: Received PUBLISH from go-echarger_093546 (d0, q0, r1, m0, 'go-eCharger/093546/fhz', ... (6 bytes))
2023-02-28 17:22:27: Received PUBLISH from go-echarger_096071 (d0, q0, r1, m0, 'go-eCharger/096071/utc', ... (25 bytes))
2023-02-28 17:22:27: Received PUBLISH from go-echarger_096071 (d0, q0, r1, m0, 'go-eCharger/096071/loc', ... (32 bytes))
2023-02-28 17:22:27: Received PUBLISH from go-echarger_096071 (d0, q0, r1, m0, 'go-eCharger/096071/rbt', ... (6 bytes))
2023-02-28 17:22:27: Received PUBLISH from go-echarger_096071 (d0, q0, r1, m0, 'go-eCharger/096071/nrg', ... (39 bytes))
2023-02-28 17:22:27: Received PUBLISH from go-echarger_096071 (d0, q0, r1, m0, 'go-eCharger/096071/fhz', ... (6 bytes))
2023-02-28 17:22:27: Received PUBLISH from go-echarger_093546 (d0, q0, r1, m0, 'go-eCharger/093546/utc', ... (25 bytes))
2023-02-28 17:22:27: Received PUBLISH from go-echarger_093546 (d0, q0, r1, m0, 'go-eCharger/093546/loc', ... (32 bytes))
2023-02-28 17:22:27: Received PUBLISH from go-echarger_093546 (d0, q0, r1, m0, 'go-eCharger/093546/rbt', ... (7 bytes))
2023-02-28 17:22:27: Received PUBLISH from go-echarger_093546 (d0, q0, r1, m0, 'go-eCharger/093546/nrg', ... (39 bytes))
2023-02-28 17:22:27: Received PUBLISH from go-echarger_093546 (d0, q0, r1, m0, 'go-eCharger/093546/fhz', ... (6 bytes))
2023-02-28 17:22:28: Received PUBLISH from go-echarger_096071 (d0, q0, r1, m0, 'go-eCharger/096071/utc', ... (25 bytes))
2023-02-28 17:22:28: Received PUBLISH from go-echarger_096071 (d0, q0, r1, m0, 'go-eCharger/096071/loc', ... (32 bytes))
2023-02-28 17:22:28: Received PUBLISH from go-echarger_096071 (d0, q0, r1, m0, 'go-eCharger/096071/rbt', ... (6 bytes))
2023-02-28 17:22:28: Received PUBLISH from go-echarger_096071 (d0, q0, r1, m0, 'go-eCharger/096071/nrg', ... (39 bytes))
2023-02-28 17:22:28: Received PUBLISH from go-echarger_096071 (d0, q0, r1, m0, 'go-eCharger/096071/fhz', ... (6 bytes))
2023-02-28 17:22:28: Received PUBLISH from go-echarger_093546 (d0, q0, r1, m0, 'go-eCharger/093546/utc', ... (25 bytes))
2023-02-28 17:22:28: Received PUBLISH from go-echarger_093546 (d0, q0, r1, m0, 'go-eCharger/093546/loc', ... (32 bytes))
2023-02-28 17:22:28: Received PUBLISH from go-echarger_093546 (d0, q0, r1, m0, 'go-eCharger/093546/rbt', ... (7 bytes))

The devices do not show up at the broker and the integration does not show any values. Do you have any ideas?

It looks like you did hit this issue: #67
Please add slash to the base topic as workaround.

yes such a minor thing so in base topic you need to state
go-eCharger
and not
/go-eCharger

I will fix the issue soon to avoid annoying more users.

Hi There, just a hint for those looking for this very same problem.
This integration is building the topic where the messages are expected like /basetopic/serialnumber
Therefore, the base topic you would specify when adding your wallbox in HA should be /basetopic
In the go-e app it looks different (IDK if it was working in the past but with my current version i need to do some extra work).
Under Advance_Config, MQTT Api, Prefix you need to include the serial number in your prefix. At the end it should look like:
/basetopic/serialnumber
where "basetopic" is the same string you specify in the HA app and "serialnumber" is the serial number of your wallbox. For some reason the Integration is expecting the serial number in the topic and the wallbox does not include it unless you explicitly put it in the prefix.

Could you provide some examples to make the differences explicit? :-)

Could you provide some examples to make the differences explicit? :-)

Of course. Let me structure the answer a little bit.
In the integration I have to enter a base topic and the serial number.
Let's pick some values to enter on the integration in HA (please notice the slashes, this seems to be relevant as mentioned in this and other tickets).
base topic = /wallbox
serial number = 123456
My understanding is that the integration will (based on those 2 variables) expect the messages to be published in a topic like /wallbox/123456/
@syssi maybe you can confirm this.
Now let's jump to the go-eCharger app.
There I entered the url mqtt://username:password@HA_IP_Address:1883
In the Prefix field I entered /wallbox/123456/
It seems the go-eCharger is not adding the serial number automatically to the MQTT topic where the messages will be published. (this may be different for other devices/Firmwares).
Here some data from my box
FW is 055.5
HW version is V3
Variant 11kW

My understanding is that the integration will (based on those 2 variables) expect the messages to be published in a topic like /wallbox/123456/

This is correct. In the past (firmware versions) the topic was hardcoded by the manufacturer to something like this:
/go-eCharger/093546/<key>

Some customers wasn't happy about the leading / so a new setting was introduced to make the prefix optional:
go-eCharger/093546/<key>               # no prefix
/go-eCharger/093546/<key>              # prefix: `/`
/customprefix/go-eCharger/093546/<key> # prefix: `/customprefix/`

Long story short: The serial number was always part of the topic in the past. It looks like this isn't the case anymore.


curl: 7.61.1 -> 7.62.0 (security)

The package curl before version 7.62.0 is vulnerable to multiple issues
including arbitrary code execution and information disclosure:
https://curl.haxx.se/changes.html#7_62_0
This should also be backported to 18.09.
Maintainer: @lovek323
Things done

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

[ ] 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 nox --run "nox-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)
[X] Fits CONTRIBUTING.md.

@GrahamcOfBorg build curl

It's already in staging : #49514

Success on x86_64-linux (full log)
Attempted: curl
Partial log (click to expand)
patching script interpreter paths in /nix/store/z2dk19f6sahh4m6qqg3nsm2jxfb0nzw0-curl-7.62.0-man
checking for references to /build in /nix/store/z2dk19f6sahh4m6qqg3nsm2jxfb0nzw0-curl-7.62.0-man...
shrinking RPATHs of ELF executables and libraries in /nix/store/mvq1a2gyr4kym6b6h2qsn3gizdkw95jz-curl-7.62.0-devdoc
gzipping man pages under /nix/store/mvq1a2gyr4kym6b6h2qsn3gizdkw95jz-curl-7.62.0-devdoc/share/man/
patching script interpreter paths in /nix/store/mvq1a2gyr4kym6b6h2qsn3gizdkw95jz-curl-7.62.0-devdoc
checking for references to /build in /nix/store/mvq1a2gyr4kym6b6h2qsn3gizdkw95jz-curl-7.62.0-devdoc...
shrinking RPATHs of ELF executables and libraries in /nix/store/s21j9bs7xj48kv3vpihh6vzh62jzlf50-curl-7.62.0-debug
patching script interpreter paths in /nix/store/s21j9bs7xj48kv3vpihh6vzh62jzlf50-curl-7.62.0-debug
checking for references to /build in /nix/store/s21j9bs7xj48kv3vpihh6vzh62jzlf50-curl-7.62.0-debug...
/nix/store/jnman3ksmqvd3rynkdgcbsmw0rbbx8ka-curl-7.62.0-bin

Damn, forgot to check staging. @c0bw3b thanks!

Success on aarch64-linux (full log)
Attempted: curl
Partial log (click to expand)
patching script interpreter paths in /nix/store/zr9m7hngklwzbpxcbn1i5bn9fmcskagz-curl-7.62.0-man
checking for references to /build in /nix/store/zr9m7hngklwzbpxcbn1i5bn9fmcskagz-curl-7.62.0-man...
shrinking RPATHs of ELF executables and libraries in /nix/store/x8qjxxps1b21ly0yd6ymnmi5fjwk4y5q-curl-7.62.0-devdoc
gzipping man pages under /nix/store/x8qjxxps1b21ly0yd6ymnmi5fjwk4y5q-curl-7.62.0-devdoc/share/man/
patching script interpreter paths in /nix/store/x8qjxxps1b21ly0yd6ymnmi5fjwk4y5q-curl-7.62.0-devdoc
checking for references to /build in /nix/store/x8qjxxps1b21ly0yd6ymnmi5fjwk4y5q-curl-7.62.0-devdoc...
shrinking RPATHs of ELF executables and libraries in /nix/store/djzc5iy65m3cmwhakmapa4pdvbdg08i7-curl-7.62.0-debug
patching script interpreter paths in /nix/store/djzc5iy65m3cmwhakmapa4pdvbdg08i7-curl-7.62.0-debug
checking for references to /build in /nix/store/djzc5iy65m3cmwhakmapa4pdvbdg08i7-curl-7.62.0-debug...
/nix/store/ffzgjvcplq2x1mrz7q94nrbikryz9jl5-curl-7.62.0-bin

Success on aarch64-linux (full log)
Attempted: curl
Partial log (click to expand)
/nix/store/ffzgjvcplq2x1mrz7q94nrbikryz9jl5-curl-7.62.0-bin

Success on x86_64-linux (full log)
Attempted: curl
Partial log (click to expand)
patching script interpreter paths in /nix/store/z2dk19f6sahh4m6qqg3nsm2jxfb0nzw0-curl-7.62.0-man
checking for references to /build in /nix/store/z2dk19f6sahh4m6qqg3nsm2jxfb0nzw0-curl-7.62.0-man...
shrinking RPATHs of ELF executables and libraries in /nix/store/mvq1a2gyr4kym6b6h2qsn3gizdkw95jz-curl-7.62.0-devdoc
gzipping man pages under /nix/store/mvq1a2gyr4kym6b6h2qsn3gizdkw95jz-curl-7.62.0-devdoc/share/man/
patching script interpreter paths in /nix/store/mvq1a2gyr4kym6b6h2qsn3gizdkw95jz-curl-7.62.0-devdoc
checking for references to /build in /nix/store/mvq1a2gyr4kym6b6h2qsn3gizdkw95jz-curl-7.62.0-devdoc...
shrinking RPATHs of ELF executables and libraries in /nix/store/s21j9bs7xj48kv3vpihh6vzh62jzlf50-curl-7.62.0-debug
patching script interpreter paths in /nix/store/s21j9bs7xj48kv3vpihh6vzh62jzlf50-curl-7.62.0-debug
checking for references to /build in /nix/store/s21j9bs7xj48kv3vpihh6vzh62jzlf50-curl-7.62.0-debug...
/nix/store/jnman3ksmqvd3rynkdgcbsmw0rbbx8ka-curl-7.62.0-bin


Release 3.0.2

@jakorostami added docstring to Experiment class
@joaomilho fix spelling error
Added tornade version requirement to protect agains vulnerability

@iampelle do we need to update setup.cfg too with the new version?

@iampelle do we need to update setup.cfg too with the new version?

Yes! And also the history and readme files.

What do you think about the description of your change in the History file @ankargren? Feel free to tweak it if you like.

Sorry just saw this now @iampelle – but it looks good!


All the capital cities in a continent organised by largest population to smallest.

SELECT Name, CountryCode, District, Population
FROM city
WHERE city.ID IN ( SELECT capital FROM country WHERE Continent = "Europe" )
ORDER BY Population DESC


Using operator

Using operator
http://reactivex.io/documentation/operators/using.html

Not relevant (replaced by context management)


Demo modals components - can't be closed

When I try to close the modals using the top-right button (X) in the demo nothing happens

I do confirm.

The bug reproduces in version 0.4.0. In 0.5.0 everything is ok.

Closing based on the above comment, and confirmed this has been resolved 👍


compilation of app for i386 arch "undefined: SQLiteConn"

no problem compiling the app for 64-bit arch, but when i set GOARCH=386 running go build this error is reported:
sqlite3_go18.go:18:10: undefined: SQLiteConn

You needo to install cross-C-compiler for 386.

Hello Mattn,
I have already install GCC v7.2.0, still encountering the same error.
Maybe it would help if I mention I'm using Windows 10 64-bit
Thanks

please show me your go env?

Im sorry i uploaded an image.. i dont know how to paste a formatted text

try set CGO_ENABLED=1

github.com/mattn/go-sqlite3
../../go/src/github.com/mattn/go-sqlite3/sqlite3_go18.go:18:10: undefined: SQLiteConn
WIth CGO_ENABLED=1 I get:
runtime/cgo
In file included from /usr/include/features.h:399:0,
from /usr/include/stdlib.h:24,
from _cgo_export.c:2:
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
include <gnu/stubs-32.h>
                       ^

As I mentioned above, you need to install 386 compiler.
2017/11/20 午前6:23 "Eliezer Croitoru"<EMAIL_ADDRESS>
github.com/mattn/go-sqlite3
../../go/src/github.com/mattn/go-sqlite3/sqlite3_go18.go:18:10:
undefined: SQLiteConn
WIth CGO_ENABLED=1 I get:
runtime/cgo
In file included from /usr/include/features.h:399:0,
from /usr/include/stdlib.h:24,
from _cgo_export.c:2:
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file
or directory
include <gnu/stubs-32.h>
                   ^

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mattn/go-sqlite3/issues/483#issuecomment-345550760,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAnf0YV6_jEV2YGKo-1fy241BcMcwwZks5s4JxUgaJpZM4QhjAM
.

@mattn I am using Debian\Ubutnu , can you give me a hint on what might be the right package for this?
I have seen these docker containers:
https://github.com/dockcross/dockcross
But yet to understand how to use them.

sudo apt install gcc-mingw-w64-i686
and please point $CC to the compiler.

compiling on windows 10 64-bit for my app to run on 386:
with CGO_ENABLED=1
encountered "skipping incompatible.." errors
this is using mingw-w64 compiler

there are two compilers w64 and i686. you need to install i686 version.

Thank you for your patience and great help @mattn upon checking my BIOS Virtualization is not enabled. Upon enabling it the compilation works perfectly.

good to hear. :+1:


vue-components: add Icon component

Icon Component (internal for now)
Split out of #193 to ease review.
This intentionally only includes 2 icons in 3 colors and 2 sizes, because those were the ones that are needed for the TextInput component. The rest of the component is going to be implemented at a later point in time.
Figma spec: https://www.figma.com/file/gi3JYwSUQYhKS0mHwK25cQwi/WiKit?node-id=2510%3A4053

Loading it in my computer, the color of icons in the storybook seems all base. I think they should change for alert and error yellow50 and red90

Loading it in my computer, the color of icons in the storybook seems all base. I think they should change for alert and error yellow50 and red90

Nope, @SaiSan-WMDE asked us to only show the icons in the default color on this storybook page. The colors you mention are what you get by passing the respective color props to the component, as you can see in the TextInput PR.

Loading it in my computer, the color of icons in the storybook seems all base. I think they should change for alert and error yellow50 and red90

Nope, @SaiSan-WMDE asked us to only show the icons in the default color on this storybook page. The colors you mention are what you get by passing the respective color props to the component, as you can see in the TextInput PR.

Ack.


ValueError: expected only letters, got u''

I have been told this is due to the latest python-babel package.
This was reported against Debian, and reproduced against version 1.8.0.
for loc in django_extensions/locale/*; do \
	python setup.py compile_catalog --directory django_extensions/locale/ --locale $(basename $loc) --domain django; \
done
running compile_catalog
compiling catalog django_extensions/locale/cs/LC_MESSAGES/django.po to django_extensions/locale/cs/LC_MESSAGES/django.mo
running compile_catalog
catalog django_extensions/locale/da/LC_MESSAGES/django.po is marked as fuzzy, skipping
running compile_catalog
compiling catalog django_extensions/locale/de/LC_MESSAGES/django.po to django_extensions/locale/de/LC_MESSAGES/django.mo
running compile_catalog
compiling catalog django_extensions/locale/el/LC_MESSAGES/django.po to django_extensions/locale/el/LC_MESSAGES/django.mo
running compile_catalog
catalog django_extensions/locale/en/LC_MESSAGES/django.po is marked as fuzzy, skipping
running compile_catalog
compiling catalog django_extensions/locale/es/LC_MESSAGES/django.po to django_extensions/locale/es/LC_MESSAGES/django.mo
running compile_catalog
compiling catalog django_extensions/locale/et/LC_MESSAGES/django.po to django_extensions/locale/et/LC_MESSAGES/django.mo
running compile_catalog
compiling catalog django_extensions/locale/fr/LC_MESSAGES/django.po to django_extensions/locale/fr/LC_MESSAGES/django.mo
running compile_catalog
compiling catalog django_extensions/locale/hu/LC_MESSAGES/django.po to django_extensions/locale/hu/LC_MESSAGES/django.mo
running compile_catalog
compiling catalog django_extensions/locale/it/LC_MESSAGES/django.po to django_extensions/locale/it/LC_MESSAGES/django.mo
running compile_catalog
compiling catalog django_extensions/locale/ja/LC_MESSAGES/django.po to django_extensions/locale/ja/LC_MESSAGES/django.mo
running compile_catalog
catalog django_extensions/locale/pl/LC_MESSAGES/django.po is marked as fuzzy, skipping
running compile_catalog
compiling catalog django_extensions/locale/pt/LC_MESSAGES/django.po to django_extensions/locale/pt/LC_MESSAGES/django.mo
running compile_catalog
Traceback (most recent call last):
  File "setup.py", line 156, in <module>
    'Topic :: Utilities',
  File "/usr/lib/python2.7/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/usr/lib/python2.7/dist-packages/babel/messages/frontend.py", line 182, in run
    self._run_domain(domain)
  File "/usr/lib/python2.7/dist-packages/babel/messages/frontend.py", line 221, in _run_domain
    catalog = read_po(infile, locale)
  File "/usr/lib/python2.7/dist-packages/babel/messages/pofile.py", line 331, in read_po
    parser.parse(fileobj)
  File "/usr/lib/python2.7/dist-packages/babel/messages/pofile.py", line 265, in parse
    self._process_comment(line)
  File "/usr/lib/python2.7/dist-packages/babel/messages/pofile.py", line 224, in _process_comment
    self._finish_current_message()
  File "/usr/lib/python2.7/dist-packages/babel/messages/pofile.py", line 164, in _finish_current_message
    self._add_message()
  File "/usr/lib/python2.7/dist-packages/babel/messages/pofile.py", line 158, in _add_message
    self.catalog[msgid] = message
  File "/usr/lib/python2.7/dist-packages/babel/messages/catalog.py", line 603, in __setitem__
    self.mime_headers = _parse_header(message.string).items()
  File "/usr/lib/python2.7/dist-packages/babel/messages/catalog.py", line 406, in _set_mime_headers
    self.locale = Locale.parse(value)
  File "/usr/lib/python2.7/dist-packages/babel/core.py", line 267, in parse
    parts = parse_locale(identifier, sep=sep)
  File "/usr/lib/python2.7/dist-packages/babel/core.py", line 1093, in parse_locale
    raise ValueError('expected only letters, got %r' % lang)
ValueError: expected only letters, got u''

Thanks for reporting this !
I have added compile-catalog as a target in tox and travis so we get alerted on this in the future.
Cannot quickly see why it only PT fails. I might just remove the translation to get the build working again.
p.s.  I would love to get the debian build files into the repository if we can.

Should be fixed in 1.8.1

found some other issues, so not yet able to close this

Should be fixed in the upcoming 1.8.1 release.
If Debian wants to patch the older version, this patch should help:

diff --git a/django_extensions/locale/pt_BR/LC_MESSAGES/django.po b/django_extensions/locale/pt_BR/LC_MESSAGES/django.po
index c5e12b0..5928e28 100644
--- a/django_extensions/locale/pt_BR/LC_MESSAGES/django.po
+++ b/django_extensions/locale/pt_BR/LC_MESSAGES/django.po
@@ -12,7 +12,7 @@ msgstr ""
 "PO-Revision-Date: 2013-09-13 22:49-0300\n"
 "Last-Translator: Claudemiro Alves Feitosa<EMAIL_ADDRESS> "Language-Team: LANGUAGE<EMAIL_ADDRESS>-"Language: \n"
+"Language: pt_BR\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"


Multiple GPUs

ljspeech/run.sh with ngpu=8 gives
Traceback (most recent call last):
File "/home/ubuntu/.local/bin/parallel-wavegan-train", line 11, in
load_entry_point('parallel-wavegan', 'console_scripts', 'parallel-wavegan-train')()
File "/home/ubuntu/tts/ParallelWaveGAN/parallel_wavegan/bin/train.py", line 775, in main
shuffle=True,
TypeError: init() got an unexpected keyword argument 'shuffle'
Thanks in advance.

Maybe your pytorch version is old.
Please try pytorch >= 1.2.

Yes. Pytorch is old.
Thanks.


Fix Currency for english store view of UAE and Kuwait sites

Thanks for your Pull Request! We love contributions.
However, you should instead open your PR on the main repository:
https://github.com/symfony/symfony
This repository is what we call a "subtree split": a read-only subset of that main repository.
We're looking forward to your PR there!


Much code using texture arrays of skinconfig-driven length assume all texture files are present

Can you write a one-sentence description of the bug?
Much code using texture arrays of skinconfig-driven length assume all texture files are present, so if they are missing the app will crash.
What is the current behavior?
Missing animation texture files can crash the app. At least two variations are anticipated:

Definitely: A crash due to the array element never being assigned a reference, resulting in an NRE
Possibly: A crash due to the array element, properly assigned a reference while using one skin, being left referencing a disposed texture after a skin change, resulting in any number of odd exceptions including but not limited to Object Disposed Exception, various D3D exceptions, and maybe even some of the Access Violation Exceptions which have been reported.

Please provide the steps to reproduce and if possible a minimal demo of the problem.
Choose one of the affected animating texture sequences and rename out one of the texture files in the middle of the set. Triggering the animation will crash the app.
What is the expected behavior?
As a general rule, TJAPlayer3 should log about missing assets at skin load time but should not crash thereafter.

Suggestions, in rough order of implementation:

Consider making TextureLoader.LoadTexture call its DisposeTexture method so that it happens consistently without callers needing to. This will add a redundant dispose cycle during app start-up but is likely a safer place to be.
Align texture array initialization:

(As many as possible should move toward initializing the array during LoadTexture because the skin-controlled ones must do it there by necessity, and consistency with that would be safest.)
Some initialize the array at the texture array declaration site
Some initialize the array just before filling it with textures (because the length varies as specified by the skin)

Align knowledge of texture array lengths, especially in TextureLoader but elsewhere also:

(As many as possible should move toward .Length unless they absolutely must do something more special.)
Some things use the skin config properties which set the length
Some things use .Length of the texture array
Others use hard-coded numbers
Yet others use other sources, e.g. special values of enumerations (ugh) like Difficulty.Total

De-duplicate texture array loading in TextureLoader. For this you can literally scroll from the top of the source file on down.
Then move onto the usage sites to ensure they are:

indexing/iterating correctly
appropriately conditional upon indexed/iterated members being non-null


Improve Search functionality

Description

Replaced algolia's netlify search plugin with algolia's autocomplete.js lib.
namespaced search bars with current page scope (currently only blog, handbook and docs scope used)
Updated article nav entries for better indexing
styling

Related Issue(s)
Has to be accepted after https://github.com/FlowFuse/website/pull/2659 to avoid a broken blog search
closes https://github.com/FlowFuse/website/issues/2630
Checklist

[x] I have read the contribution guidelines
[x] I have considered the performance impact of these changes
[ ] Suitable unit/system level tests have been added and they pass
[ ] Documentation has been updated

There will be a short period where the blog search bar will not work (will not return any results) until Algolia indexes the 'blog' keyword correctly.
Should I break up the addition of the blog keyword into a separate PR, release it before this one in order to avoid this?

Should I break up the addition of the blog keyword into a separate PR, release it before this one in order to avoid this?

Very sensible

I created https://github.com/FlowFuse/website/pull/2659 that should update the indices. I'm not going to cherry pick the changes out of this PR, they should sort themselves out when https://github.com/FlowFuse/website/pull/2659 is merged in main and main in merge in the current PR.
After deploying https://github.com/FlowFuse/website/pull/2659, I'll check manually for the algolia indices to be updated and the deployment branch. Until then, I'll leave this PR marked as draft

After deploying #2659, I'll check manually for the algolia indices to be updated and the deployment branch. Until then, I'll leave this PR marked as draft

Algolia successfully updated the new indices

Is this ready for review @cstns?

The blog namespaced search should work now, but can't tell why the tests (untitaker step ) are failing

After tackling the problem like a deaf man hitting a church bell, I was able to finally figure out why the untitaker/hyperlink checks were failing.
The problem laid in the plugin's inability to resolve dynamic urls, thus resolving/treating <a href="${item.url}" ... and <img src="${item.image}" ... to literal strings which of course are not url spec compliant.
Although there is a closed issue on the matter, for whatever reason script src's are not ignored in our case, even though we are using a version greater than the one containing the fix.
The only feasible workaround I could come up with is to add the url/src values as data attributes on the elements and swap them at runtime when the autocomplete query changes state.

@Yndira-E, I know you requested to have the search result title/heading bold but the autocomplete.js lib highlight does exactly that when highlighting results for content titles.
I can revisit the highlighting functionality when tackling the global search task if needed.


chore: Removed CLI nags, added community invites.

Thank you so much for contributing to Datapane, please help us by filing out this PR template and ensure you have read the CONTRIBUTING.md.
It may take a few days to review your PR and merge it - please bear with us!
Thanks!
Prerequsites

[x] Has been tested locally
[ ] If a bugfix, have included a breaking test if possible

Proposed Changes

Removes multiple nags for Datapane Cloud, features, and product survey.
Invites user to community on signup and hello-world.
Removed the stochastic display messages. User feedback indicated that these were annoying.
Held off on introducing a display message upon first save to avoid editing the CLI config system for now.

On hello-world:

On Cloud signup:

btw, the screenshot seems to show console-style output rather than markdown - is the jupyter detection perhaps not working as intended?

@mands Jupyter detection works nicely when using the Python package. It looks like it's not detected when using the bang syntax (shortcut for system magics). This looks like expected behaviour to me.


remove connector node from risedev

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?

Remove the connector node from risedev, since its functionality has been integrated into compute right now.

Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

Do we always want it to be part of compute-node? Are there any occasions we will want to deploy it separately?

Do we always want it to be part of compute-node? Are there any occasions we will want to deploy it separately?

We want to simplify our system architecture, so we won't deploy it separately. The cloud team will also remove it from the k8s later.


Can't convert  project

Project https://scratch.mit.edu/projects/66980580 can't be converted by snapin8r. I don't think it has unsupported features.
Stefano

Any error message?

You were right, I had to remove a "backdrop name" block. But I had also to remove a "next backdrop" block in order to be able to complete the conversion. Shoudn't it be a supported block? I noticed that in the new Scratch 2.0 it is now called internally "next scene".


allow for use against domainAlias instead of domainId

My application might not have any knowledge on authzforce UUID for a given domain (all I'm given is domain name) so ideally I'd like to be able to translate name to UUID
I thing this can be done with org.ow2.authzforce.rest.api.jaxrs.DomainsResource#getDomains
so I'd suggest something like
private DomainResource setupProxy(boolean doDomainIdTranslation) {
		DomainsResource domainsResource = JAXRSClientFactory.create(String.valueOf(this.serverEndpoint), DomainsResource.class);
		if (doDomainIdTranslation) {
			this.domainId = getDomainIdFromAlias(domainsResource, this.domainId);
		}
...

and
private String getDomainIdFromAlias(DomainsResource domainsResource, String domainAlias) {
  Resources resources = domainsResource.getDomains(domainAlias);
  return resources.getLinks().get(0).getHref();
}

in org.ow2.authzforce.sdk.core.Net

Question would this be considered a break in architecture? I ask because the way I understand it the GET /domains?externalId endpoint is considered as part of the Domain Management API according to docs
If this is an acceptable I have a PR that will come in shortly

I think this is acceptable. As you've said the application might not be aware of authzforce UUID.

@hargathor , excellent. In that case #9 should do the trick.


LUCI not running presubmit checks

Example

Deduplicating with https://github.com/flutter/flutter/issues/86383


Added missing test for SelectionArea example

Added missing test for SelectionArea example. Issue #130459
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] I followed the breaking change policy and added Data Driven Fixes where supported.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

(triage): @iam-amanxz Do you still have plans to come back to this PR to address the feedback given above?

@goderbauer yes, please allow me some time. I will work on this over the weekend.

@bleroux Can you please tell me why the Linux analyze is still failing?

@bleroux Can you please tell me why the Linux analyze is still failing?

@iam-amanxz
This is related to the content of check_code_samples.dart, looks like your PR is not based on the last version of this file.
Some examples were added in between the time your filed this PR and now.

@iam-amanxz
Can you try to rebase this branch on master and fix the conflict (probably in check_code_samples.dart)?
(some other API examples probably landed in between).


Disable transactional DDL in alembic

Our support for DDL in transactions is limited, so we're better off
not trying.

LGTM except I don't see a change for Comments are now dropped from table definitions as CockroachDB does not support them.?

That was in a separate PR that merged since 0.2.0.


UI Espresso TestCase

Hi,
after call with @rdpanek we agreed that I'll continue with his work on Android tests, because he is working also on iOS and Web page tests.
This is based on his PR #182 but I had to edit it a little bit to make it work on my device. I've also tried to add some improvements based on reviews that were already there.
I did not want to touch app code because I have no experience with Android, so there are no Idling resources.
@davidvavra @rdpanek check the latest changes and if possible check the test even on your device 🙏
this closes #182

@davidvavra mělo by to být fixnuté. Tak se na to prosím znovu podívej.
Plus jsem přidal po domluvě s @rdpanek i nasypání dat do DB, a poslání. Zatím je to ale jen checkované přes UI. Zítra se s ním chci domluvit co dál by chtěl přidat.


Support for DDS-XTypes 1.2

Hello,
I would like to ask if the Fast RTPS implementation supports any of the
Extensible and Dynamic Topic Types for DDS as seen in the
https://www.omg.org/spec/DDS-XTypes/1.2
Please help us on this , we are trying to check interoperability test between different vendors to see if this supports.
Thanks
Sudharsan

The documentation might be worth looking at.

Thank you for pointing out to the documentation link, Will go through that.

@rnareddy646 Does the documentation help you? If it was helpful, could you close the issue? Thanks

Please specify the implementation status of the following parts of the DDS-XTypes standard:

IDL/XML parser and Fast-RTPS (de)serializer support for data type evolution with @extensibility=mutable| append|final, id, optional, mustUnderstand, tryConstruct;
discovery-Time Data Typing (the dynamic features of DDS-XTypes depend on the ability of components to discover the data types used by their peers);
introspecting existing types by user;
Type Consistency Enforcement at Discovery-Time.

The current status in master is:

IDL/XML parser and Fast-RTPS (de)serializer support for data type evolution with @extensibility=mutable| append|final, id, optional, mustUnderstand, tryConstruct;

Our idl generator supports those annotations. But our serialization library doesn't still support XCDR standard, needed to use those annotations at serialization.

discovery-Time Data Typing (the dynamic features of DDS-XTypes depend on the ability of components to discover the data types used by their peers);

You have documentation about this here. The feature is in master but not released yet in an official release.

introspecting existing types by user;

The user is able to introspect existing dynamic types. Maybe this example and this one could help you.

Type Consistency Enforcement at Discovery-Time.

At discovery level, Fast-RTPS is prepared, but Fast-CDR is still not supporting XCDR.
Support all DDS-XTypes 1.2 is in the eProsima's roadmap.

Thank you for your support on this

You're welcome. I close the issue.

Hi ,
I was trying to check the sample code workign for inherited struct types in the IDL.
Though the subscriber seems to receive the data from other applications, the publisher crashes in CDR serialize(int32) with NoMemoryException.
I was wondering if it was related to the incomplete support for XCDR in serialization library.
Could you please confirm if the sample generated for the following IDL is due to this issue?
struct Msg {
@Key long userID;
//@ID 0
string message;    //@ID 1
};
//@Extensibility EXTENSIBLE_EXTENSIBILITY
struct MsgExtended : Msg {
long dummy;    //@ID 2
};
//@Extensibility EXTENSIBLE_EXTENSIBILITY
HelloWorld_IDL.txt
I made further changes in the test code (and some debug logs in Cdr.cpp too)to check if things would work but without any luck.
As the sample code itself crashes ,I am atttaching only the IDL .
Please let me know if any additional info is required.
The installation was from master. (i.e. compiled from source)
Thank you,
Viresh


[wip] adoption of sendable

motivation: adopt to sendable requirments in swift 5.6
changes:

define sendable shims for protocols and structs that may be used in async context
adjust tests
add a test to make sure no warning are emittted

I think we must not forget to mark LambdaRuntime and LambdaTerminator also as Sendable.

yes, I will merge the terminator PR first than rebase and update

I think we must not forget to mark LambdaRuntime and LambdaTerminator also as Sendable.

done for LambdaTerminator. why would we want LambdaRuntime to be Sendable? it is not used directly by the users atm afaik.

Why would we want LambdaRuntime to be Sendable? it is not used directly by the users atm afaik.

@tomerd LambdaRuntime is supposed to be used by framework developers that wish to integrate with Lambda, since it allows adopters to hook it into their own lifecycle methods. The vapor lambda bridge works this way. For this reason LambdaRuntime is also part of the public API.
LambdaRuntime should be @unchecked Sendable, since it is thread safe by dispatching to the same eventLoop. This is currently not true for the start method, which needs to be fixed with the pattern:
    public func start() -> EventLoopFuture<Void> {
        if self.eventLoop.inEventLoop {
            return self.start0()
        } else {
            return self.flatSubmit { self.start0() }
        }
    }

    private func start0() -> EventLoopFuture<Void> {
        // current start implementation
    }

After that we should have marked everything in the public API as Sendable that needs to be Sendable.


Allowing any value type in dropdown

Hello,
It would be great to allow any type in dropdown values. I'm currently using it with objects and it's raising errors. :(
If you agree to the change, I can make a PR.
Thanks for the work you've done!

Yeah, i think it's a good idea)

Released in 0.4.1


add support for reserved default object param

Changes
This commit adds support for reserved default object param.Users can reference to default object param values without needing to declaring them in remote Task&Pipeline. Validation err will be returned if referencing to non-existent object key.
This is the PR to run all tests: https://github.com/tektoncd/pipeline/pull/7484
Signed-off-by: Yongxuan Zhang<EMAIL_ADDRESS>
Submitter Checklist
As the author of this PR, please check off the items in this checklist:

[ ] Has Docs if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps
[ ] Has Tests included if any functionality added or changed
[ ] Follows the commit message standard
[ ] Meets the Tekton contributor standards (including functionality, content, code)
[ ] Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
[ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of good release notes.
[ ] Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes
NONE

/assign


Update [SDF User Acquisition - In-App Distribution stellar.org] #sdf #custodian GDKIJJ…CCWNMX

Address: GDKIJJIKXLOM2NRMPNQZUUYK24ZPVFC6426GZAEP3KUK6KEJLACCWNMX
Tags: sdf custodian
Title: SDF User Acquisition - In-App Distribution  Domain: stellar.org
Requested by @abdulkiram

Transfer funds to my stellar account

Hello @AbdulKiram,
Can you please give more details about what you are requestion.
Looking Towards The Future With You,
Rob

Hello @AbdulKiram,
Please feel free to reopen this issue if you feel there is new information about this issue.
Looking Towards The Future With You,
Rob


[BUG]: Remove DeprecatedDotnet2_2_And_3_0 message and Net5Update

New issue checklist

[X] I searched for existing GitHub issues
[X] I read pipeline troubleshooting guide
[X] I checked how to collect logs

Task name
DotnetCoreCLIV2
Task version
No response
Issue Description
After updating our first apps to .NET 8 I once again stumbled over the ancient messages writen by DotNetCoreCLI@2 about .NET 2.2, 3.0 and 5.x.
We are using Azure DevOps Server in latest version and use only support .NET runtimes/SDKs. Our Devs ask every than and now why these messages still pop up.
I would like to see this message removed or at least give us an environment variable (e.g. SKIP_HOSTED_AGENT_INFOS) to skip these messages
Environment type (Please select at least one enviroment where you face this issue)

[X] Self-Hosted
[ ] Microsoft Hosted
[ ] VMSS Pool
[ ] Container

Azure DevOps Server type
Azure DevOps Server (Please specify exact version in the textbox below)
Azure DevOps Server Version (if applicable)
Azure DevOps Server 2022.0.1
Operation system
Windows Server 2022
Relevant log output
Starting: Install dotnet tools
==============================================================================
Task         : .NET Core
Description  : Build, test, package, or publish a dotnet application, or run a custom dotnet command
Version      : 2.202.0
Author       : Microsoft Corporation
Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
==============================================================================
C:\Windows\system32\chcp.com 65001
Active code page: 65001
Info: .NET Core SDK/runtime 2.2 and 3.0 are now End of Life(EOL) and have been removed from all hosted agents. If you're using these SDK/runtimes on hosted agents, kindly upgrade to newer versions which are not EOL, or else use UseDotNet task to install the required version.
"C:\Program Files\dotnet\dotnet.exe" tool restore
Tool 'dotnet-ef' (version '8.0.0') was restored. Available commands: dotnet-ef

Restore was successful.
Info: Azure Pipelines hosted agents have been updated and now contain .Net 5.x SDK/Runtime along with the older .Net Core version which are currently lts. Unless you have locked down a SDK version for your project(s), 5.x SDK might be picked up which might have breaking behavior as compared to previous versions. You can learn more about the breaking changes here: https://docs.microsoft.com/en-us/dotnet/core/tools/ and https://docs.microsoft.com/en-us/dotnet/core/compatibility/ . To learn about more such changes and troubleshoot, refer here: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#troubleshooting
Finishing: Install dotnet tools

Full task logs with system.debug enabled

 [REPLACE THIS WITH YOUR INFORMATION]

Repro steps
No response

Could we get an update about this?


.give

Command take flower from first user but not give other user.

pgsql

no error in console

Indeed, found the problem and fixed 24ceeca
Thanks, closing it now.


ui: Fix missing config warning

Signed-off-by: Ryan Northey<EMAIL_ADDRESS>Fix #268

Codecov Report

Merging #290 (a222907) into main (7c0638d) will decrease coverage by 0.03%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main     #290      +/-   ##
==========================================
- Coverage   52.05%   52.01%   -0.04%
==========================================
  Files         117      117
  Lines        3218     3220       +2
==========================================
  Hits         1675     1675
- Misses       1543     1545       +2

Impacted Files
Coverage Δ

ui/src/proxy/forms/config.js
10.52% <0.00%> (ø)

ui/src/proxy/forms/proxy.js
6.38% <0.00%> (-0.29%)
:arrow_down:

ui/src/shared/modal.js
12.00% <0.00%> (ø)

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 7c0638d...a222907. Read the comment docs.


Collecting Example Scenes

For new contributors, having straight forward examples is a very good resource for quickly learning manim.
Therefore, here are some guidelines for creating the examples (these are currently only my ideas, so please give feedback, I will then continuously update this list):

Examples should be as minimal as possible --> easy to understand
There should be a balance of animated and non-animated examples.

as manim is there to make animations, we should, of course, include lots of animated examples
HOWEVER: I think that lots of examples (like the size of a plot-axis, making an area, annotation stuff, setting opacities, making texts) will also work very well as images. For people that read the docs, it will be a lot more convenient to look at an example and immediately see what they want to see, instead of having an animation, that has also the time component and therefore one more abstraction level. So animations should be avoided when they are not necessary.

Examples should not have uncommented code or comments -> this can go into the markdown files.
Examples can be organized into chapters and subchapters

For now, we can collect examples in a markdown pad where one can drag and drop images/gifs that are automatically uploaded: https://pad.gwdg.de/Kyv7fYxfTKC4NVxbNw2cbQ
As soon as this pad grows too large, it can be split into sub-pads.

And here is an idea how we could structure the folders:

Shapes
Annotations
Plots
Text
Formulas
Updater
3D
Animations

Transformations
Updates

AdvancedProjects

General suggestion: once you are happy with the guidelines we have gathered on this issue, let's close this issue and put these guidelines somewhere in the documentation.
Suggestion for new guideline: Please record which version of manim was used to generate this example. (If necessary, please provide the commit hash and date.)
I like the structure you are suggesting! I also want to suggest adding a "Neat projects" or "Neat examples" chapter. These may be simple but neat, so they are not necessarily the same as "Advanced Projects".

Closed in favour of
https://github.com/ManimCommunity/manim/wiki/Guide-to-contribute-Examples-to-docs
and
https://github.com/ManimCommunity/manim/wiki/Docs-Example-Ordering


Signpost potential bugs / unsupported ops in MPS backend

fixes #1679 .
The MPS backend seems to still have some correctness issues or does not have full coverage of operations. Fixing this is out of our hands, but informing users of this is helpful.

cc @lintangsutawika


Add support for extending OpenApi info object via extensions

Clear and concise description of the problem
Given the below Typespec example, which passes a custom decorator @skill() on a namespace that aims to extend the OpenApi info object via extensions:
main.tsp
import "@typespec/http";
import "@typespec/rest";
import "@typespec/openapi3";
// IMPORTED CUSTOM SKILLS DECORATOR

using TypeSpec.Http;
using TypeSpec.Rest;
// using TypeSpec.Skills; (uncomment when ready)

alias sunoSkill = {
  name_for_human: "Suno";
  description_for_human: "Suno is a tool that can generate songs based on a description. The user provides a description of the song they want to create, and Suno generates the song lyrics. Suno is a fun and creative way to create songs for any occasion.";
  logo_url: "https://th.bing.com/th?id=OSK.935650835684F7E18AC3F31034DE6DF3";
  contact_email<EMAIL_ADDRESS>  privacy_policy_url: "https://app.suno.ai/privacy";
  legal_info_url: "https://app.suno.ai/legal";
};

/**
 * Suno is a tool that can generate songs based on a description. The user provides a description of the song they want to create, and Suno generates the song lyrics. Suno is a fun and creative way to create songs for any occasion.
 */
@service({
  title: "Suno"
})
@skill(sunoSkill)
@route("/createSong")
namespace Suno {
  /** Create a song given the user preferences */
  @get op createSong(
    /** The requested song description, eg. `a country song about Thanksgiving` */
    @query topic: string): string;
}

The expected OpenApi file output should be:
openapi.yaml
openapi: 3.0.0
info:
  title: Suno
  description: Create any song you want based on a description
  version: 1.0.0
  contact:
    email<EMAIL_ADDRESS>  x-logo: https://w7.pngwing.com/pngs/208/848/png-transparent-musical-note-logo-clef-music-logo-design-other-text-musical-composition.png
  x-ai-description: Suno is a tool that can generate songs based on a description. The user provides a description of the song they want to create, and Suno generates the song lyrics. Suno is a fun and creative way to create songs for any occasion.
  x-legal-info-url: https://app.suno.ai/legal
  x-privacy-policy-url: https://app.suno.ai/privacy
tags: []
paths:
  /createSong:
    get:
      operationId: createSong
      description: Create a song given the user preferences
      parameters:
        - name: topic
          in: query
          required: true
          description: The requested song description, eg. `a country song about Thanksgiving`
          schema:
            type: string
      responses:
        '200':
          description: The request has succeeded.
          content:
            application/json:
              schema:
                type: string
components: {}

However, this is currently not supported. We need to have a way of extending an OpenApi info object via extensions.
Checklist

[X] Follow our Code of Conduct
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

This issue is awaiting the setExtensions feature support on an OpenAPI info object to be added to the Typespec library. Issue tracking this: https://github.com/microsoft/typespec/issues/3446

The implementation of this should basically be the same as setExtension helper.
but setInfoExtension(key: string, value: unknown): void and then add those values to the info data

Maybe it can be workaround for now? @irvinesunday
Typespec:
import "@typespec/http";
import "@typespec/rest";
import "@typespec/openapi";
import "@typespec/openapi3";

using TypeSpec.Http;
using TypeSpec.Rest;
using TypeSpec.OpenAPI;

/**
 * This is a sample server Petstore server.
 */
@info({
    title: "title - info",
    "x-cutome-info": {
        name_for_human: "Suno";
        description_for_human: "Suno is a tool that can generate songs based on a description. The user provides a description of the song they want to create, and Suno generates the song lyrics. Suno is a fun and creative way to create songs for any occasion.";
        logo_url: "https://th.bing.com/th?id=OSK.935650835684F7E18AC3F31034DE6DF3";
        contact_email<EMAIL_ADDRESS>        privacy_policy_url: "https://app.suno.ai/privacy";
        legal_info_url: "https://app.suno.ai/legal";
      },
})
@service
namespace PetStore;

@extension("x-custom", "My value")
op readxxx(): string;

Result:
openapi: 3.0.0
info:
  title: title - info
  x-cutome-info:
    name_for_human: Suno
    description_for_human: Suno is a tool that can generate songs based on a description. The user provides a description of the song they want to create, and Suno generates the song lyrics. Suno is a fun and creative way to create songs for any occasion.
    logo_url: https://th.bing.com/th?id=OSK.935650835684F7E18AC3F31034DE6DF3
    contact_email<EMAIL_ADDRESS>    privacy_policy_url: https://app.suno.ai/privacy
    legal_info_url: https://app.suno.ai/legal
  description: This is a sample server Petstore server.
  version: 0.0.0
tags: []
paths:
  /:
    get:
      operationId: readxxx
      parameters: []
      responses:
        '200':
          description: The request has succeeded.
          content:
            application/json:
              schema:
                type: string
      x-custom: My value
components: {}


Create tutorials

Create detailed tutorials in roswiki to get a tangobot setup running (detailed as Turtlebot tutorial).

[x] Easy setup tutorial (blind / empty map) - See #56
-- Check rosdep installation
-- Source workspace
[ ] Advanced tutorial
-- Map and sensor reqs TBD

First version of this was done long ago


chore: Promote unstable to rc

Promote unstable to rc, created by dt release promote
DO NOT MERGE

Cutting RC so stencil-template-base can depend on this version


Added automatic module name to be compatible with JPMS

@mihxil please fill out the CLA: https://cla.developers.google.com/

@phebehp I filled this CLA out.


import inside story returns 404

Hi, I can run storybook with yarn storybook:

But when I try to load a story named inputdate.js:
import InputDate from<EMAIL_ADDRESS>
export default {
  components: { InputDate },
  title: 'Form/Date',
};

const Template1 = (args) => ({
  components: { InputDate },
  setup() {
    return { args };
  },
  template: `<c-input-date v-model="value" @change="change" />`,
});

export const SingleDate = Template1.bind({});
SingleDate.args = {
  value: '',
  change: (date) => {}
};

The server breaks with:
11:19:04 PM [vite] Internal server error: Cannot read properties of undefined (reading 'get')
  Plugin: vue-docgen
  File: /usr/src/components/Ui/Form/InputDate.vue
      at Object.getArgFromDecorator [as default] (/usr/src/node_modules/vue-docgen-api/dist/utils/getArgFromDecorator.js:30:9)
      at classDisplayNameHandler (/usr/src/node_modules/vue-docgen-api/dist/script-handlers/classDisplayNameHandler.js:35:51)
      at /usr/src/node_modules/vue-docgen-api/dist/parse-script.js:158:82
      at step (/usr/src/node_modules/vue-docgen-api/dist/parse-script.js:52:23)
      at Object.next (/usr/src/node_modules/vue-docgen-api/dist/parse-script.js:33:53)
      at /usr/src/node_modules/vue-docgen-api/dist/parse-script.js:27:71
      at new Promise (<anonymous>)
      at __awaiter (/usr/src/node_modules/vue-docgen-api/dist/parse-script.js:23:12)
      at /usr/src/node_modules/vue-docgen-api/dist/parse-script.js:156:120
      at Array.map (<anonymous>)
      at /usr/src/node_modules/vue-docgen-api/dist/parse-script.js:156:88
      at step (/usr/src/node_modules/vue-docgen-api/dist/parse-script.js:52:23)
      at Object.next (/usr/src/node_modules/vue-docgen-api/dist/parse-script.js:33:53)
      at fulfilled (/usr/src/node_modules/vue-docgen-api/dist/parse-script.js:24:58)

And the browser request:

This is my main.js storybook config:
const vite = require('vite');
const path = require('path');
const vue = require('@vitejs/plugin-vue');
const env = vite.loadEnv(undefined, 'env');

module.exports = {
  stories: [
    "../stories/**/*.@(js|jsx|ts|tsx)"
  ],
  addons: [
    "@storybook/addon-links",
    "@storybook/addon-essentials"
  ],
  framework: "@storybook/vue3",
  core: {
    builder: "storybook-builder-vite"
  },
  async viteFinal(config) {
    return {
      ...config,
      plugins: [
        ...config.plugins,
        vue({ include: [/\.vue$/], })
      ],
      resolve: {
        ...config.resolve,
        alias: {
          ...config.resolve.alias,
          '@': path.resolve(__dirname, '../'),
          'vue': 'vue/dist/vue.esm-bundler.js'
        }
      },
      server: {
        ...config.server,
        host: 'localhost',
        hmr: {
          ...config.server.hmr,
          protocol: 'wss',
          host: env.VITE_APP_DOMAIN,
          port: 443
        }
      }
    };
  },
}

If I do change the path in alias.resolve to anything else it breaks, which means the file is being read initially. I ran out of ideas of what might be causing this, if somebody has any please let me know, thanks!

@theonelucas That version of the beta isn't supported yet. Work is in progress in https://github.com/eirslett/storybook-builder-vite/pull/144

@theonelucas I see you've made updates to the vite config to support the newer versions of storybook, but I think that you don't want to spread the existing server.hmr config in this case, because there are some properties there which cause trouble.  So, try removing the line ...config.server.hmr,, and maybe that will help.

@theonelucas That version of the beta isn't supported yet. Work is in progress in #144

I downgrade it to 6.4.0-beta.19 but it still didn't work. I created a [reproduction repository](https://github.com/theonelucas/vite-storybook-repro) if you wish to inspect, thanks.

@theonelucas I see you've made updates to the vite config to support the newer versions of storybook, but I think that you don't want to spread the existing server.hmr config in this case, because there are some properties there which cause trouble. So, try removing the line ...config.server.hmr,, and maybe that will help.

I tried removing the entire config.server block and running it locally but got the same error. I created a reproduction repository, if you wish to inspect, thanks.


titimul / titimr

Received this email:
What is titimul or titimr in English?
I asked for example usage but got no reply.
By the way, I get about 1 email a month from someone asking basically something like this,
"Help! What is Palauan for THEME? Hurry and answer because I need it for my homework."
LOL.

there is a tree, titimel, with very taste fruits) as for TITIMEL, we already have it in DB. maybe titimul / titimr is just a misspelling


why require ios 8+

Could it support ios 7 ?

@nvcken Yes

Could you explain more detail?
I saw this
Requirements

iOS 8.0+ (for component), iOS 9.0+ (for example)
Xcode 7
Swift 2

In the project you can always change the deployment target to 7.0 from the project info. I switched to 7.0 and works just fine but this project does have iOS 8.0 components. i recommend 8.0 by the way.

yes, thanks


Adding Filename option for Sketch and fixing dates and Unix filenames

badchars were ruining folder / picture names
Fixed default date format, which was creating folders and in a bad format
Changed the json / txt date to be independent of the date format used.

To add to that, using filenameFormat as default for filenameFormatSketch would've been better, but I don't think that's possible without having to rewrite the class

I implemented the separator change, and got rid of needless functions (the value returned is already a str). Though from Wikipedia, which I somewhat I agree with

Representations can be done in one of two formats – a basic format with a minimal number of separators or an extended format with separators added to enhance human readability.[14][15] The standard notes that "The basic format should be avoided in plain text."[16] The separator used between date values (year, month, week, and day) is the hyphen, while the colon is used as the separator between time values (hours, minutes, and seconds). For example, the 6th day of the 1st month of the year 2009 may be written as "2009-01-06" in the extended format or simply as "20090106" in the basic format without ambiguity.

But doesn't matter too much tbh


Support of Radiant ?

IS there a Radiant coin support in a next update ??

This is NOT a bug but a question.
Sure, when is your PR coming?


Failed to find style 'listMenuViewStyle' in current theme

I imported the project using android studio's "import an Android code sample" option, but without making any edits I immediately have render errors in both menu xml files: "Failed to find style 'listMenuViewStyle' in current theme".

I have the same problem.
Using Android Studio 2.3.3

I have the same problem.


python312Packages.jupyter-collaboration: 2.1.2 -> 2.1.3

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python312Packages.jupyter-collaboration is: JupyterLab Extension enabling Real-Time Collaboration
meta.homepage for python312Packages.jupyter-collaboration is: https://github.com/jupyterlab/jupyter_collaboration
meta.changelog for python312Packages.jupyter-collaboration is: https://github.com/jupyterlab/jupyter_collaboration/blob/v2.1.3/CHANGELOG.md
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.1.3 with grep in /nix/store/kwy4qn4129am17rz523x3iv8j3z2zgj2-python3.12-jupyter-collaboration-2.1.3
found 2.1.3 in filename of file in /nix/store/kwy4qn4129am17rz523x3iv8j3z2zgj2-python3.12-jupyter-collaboration-2.1.3

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath

python311Packages.jupyter-collaboration
python312Packages.jupyter-collaboration

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/kwy4qn4129am17rz523x3iv8j3z2zgj2-python3.12-jupyter-collaboration-2.1.3 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python312Packages.jupyter-collaboration https://github.com/r-ryantm/nixpkgs/archive/80f9ce8b11be2017b72ae68bd3e89381b640f4bc.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/80f9ce8b11be2017b72ae68bd3e89381b640f4bc#python312Packages.jupyter-collaboration

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/kwy4qn4129am17rz523x3iv8j3z2zgj2-python3.12-jupyter-collaboration-2.1.3
ls -la /nix/store/kwy4qn4129am17rz523x3iv8j3z2zgj2-python3.12-jupyter-collaboration-2.1.3/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:white_check_mark: 4 packages built:

python311Packages.jupyter-collaboration
python311Packages.jupyter-collaboration.dist
python312Packages.jupyter-collaboration
python312Packages.jupyter-collaboration.dist

Maintainer pings
cc @GaetanLepage @natsukium @thomasjm for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 349010

x86_64-linux

:white_check_mark: 4 packages built:

python311Packages.jupyter-collaboration
python311Packages.jupyter-collaboration.dist
python312Packages.jupyter-collaboration
python312Packages.jupyter-collaboration.dist

aarch64-linux

:white_check_mark: 4 packages built:

python311Packages.jupyter-collaboration
python311Packages.jupyter-collaboration.dist
python312Packages.jupyter-collaboration
python312Packages.jupyter-collaboration.dist

x86_64-darwin

:white_check_mark: 4 packages built:

python311Packages.jupyter-collaboration
python311Packages.jupyter-collaboration.dist
python312Packages.jupyter-collaboration
python312Packages.jupyter-collaboration.dist

aarch64-darwin

:white_check_mark: 4 packages built:

python311Packages.jupyter-collaboration
python311Packages.jupyter-collaboration.dist
python312Packages.jupyter-collaboration
python312Packages.jupyter-collaboration.dist


Translate default blocks and category names

We do not want to trust the quality of the translation of Blockly itself.
We have to prepare the translation ourselves.
For this purpose, this commit is to add blocks with the same name (id)
as the default/builtin blocks.
Do not think that the strings can be translated "word by word". Short words
like "do", "add", "if", "and" etc have multiple meanings and should be
translated into different words in different contexts. To solve this
issue, I have marked up these words as like "_repeat_do" and "_while_do".
Please be aware you have to add translations for these special strings
even for English.

Hi @sgk, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla.microsoft.com.

TTYL, MSBOT;

Signed the CLA.

@sgk i've added a few comments.

@pelikhan Thank you. I replied to two comments, but I will check remaining comments tomorrow because it's midnight here.

For lf() parameter, I forgot about it even I read lf() and lf_va() source code. I will add another commit to use this feature soon.

The above commit is to translate the default variable name "item". However, I would like to use _default_var instead of item for translation source string. I tried to explain the reason in the commit log.

Supporting "ids" in LF requires a bit more work on our end. I would suggest to split those into a new PR if possible -- or file an issue.

@pelikhan Thanks and I understand. We have to "decouple" the multiple-meanings-problem from this PR. I will add another commit to use natural (in English) words instead of ids like "op??" or "_repeat_do".

I'm working on adding support for ids in lf. The syntax will be as follow:
lf("do{id:_for_do}")

See https://github.com/Microsoft/pxt/commit/7088e29a297de67d8a501bc62e3faf25036710ad

I’ve just added support for “ids” in the lf function. https://github.com/Microsoft/pxt/commit/7088e29a297de67d8a501bc62e3faf25036710ad
From: Shigeru KANEMOTO<EMAIL_ADDRESS>Sent: Tuesday, September 6, 2016 9:24 AM
To: Microsoft/pxt<EMAIL_ADDRESS>Cc: Peli de Halleux<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Microsoft/pxt] Translate default blocks and category names (#303)
@pelikhanhttps://github.com/pelikhan Thanks and I understand. We have to "decouple" the multiple-meanings-problem from this PR. I will add another commit to use natural (in English) words instead of ids like "op??" or "_repeat_do".
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/pxt/pull/303#issuecomment-245006502, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD-4KUNLddQq7ut7PQq6Y3yLh2APgrJhks5qnZOKgaJpZM4J0xDr.

@pelikhan Seems to be nice feature!

I did not add {id:???} except the example line you added in 7088e29. Do you want to include them in this PR?

Yes you can now include them in this PR
Sent from Outlook Mobilehttps://aka.ms/djubve

From: Shigeru KANEMOTO<EMAIL_ADDRESS>Sent: Tuesday, September 6, 2016 10:24:54 AM
To: Microsoft/pxt
Cc: Peli de Halleux; Mention
Subject: Re: [Microsoft/pxt] Translate default blocks and category names (#303)
I did not add {id:???} except the example line you added in 7088e29https://github.com/Microsoft/pxt/commit/7088e29a297de67d8a501bc62e3faf25036710ad. Do you want to include them in this PR?

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/pxt/pull/303#issuecomment-245024676, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD-4KQxt4rY-PT26Fj7F1na5Y3dxcTG-ks5qnaHmgaJpZM4J0xDr.

This PR looks good. We could merge it and bring the rest of the changes in a new PR.

Thank you! I will make the new PR later.


Added RTL support for StepperLayout's inner ViewPager

This will change the animation when changing steps while in RTL layout direction.
This supports locale changes.

Codecov Report

Merging #115 into master will increase coverage by 0.26%.
The diff coverage is 66.66%.

@@             Coverage Diff              @@
##             master     #115      +/-   ##
============================================
+ Coverage      46.1%   46.37%   +0.26%
- Complexity      109      113       +4
============================================
  Files            22       24       +2
  Lines           874      882       +8
  Branches         84       85       +1
============================================
+ Hits            403      409       +6
- Misses          407      409       +2
  Partials         64       64

Impacted Files
Coverage Δ
Complexity Δ

...main/java/com/stepstone/stepper/StepperLayout.java
33.99% <ø> (ø)
17 <0> (ø)
:arrow_down:

...get/pagetransformer/StepperRtlPageTransformer.java
100% <100%> (ø)
2 <2> (?)

...epstone/stepper/internal/widget/StepViewPager.java
42.85% <50%> (ø)
1 <0> (?)

...et/pagetransformer/StepPageTransformerFactory.java
50% <50%> (ø)
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 7cf654e...7d56449. Read the comment docs.


Update the meeting demo to adopt to metrics changes

Issue #:
Some metrics returned by useMediaStreamMetrics hook and useBandwidthMetrics hook are deprecated, need to remove them from meeting demo.
Description of changes:
Removed any components that use videoUpstreamGoogFrameHeight, videoUpstreamGoogFrameWidth, videoDownstreamGoogFrameHeight and videoDownstreamGoogFrameWidth.
Testing

How did you test these changes?
Run meeting demo and manually confirm it works as expected.

Can these changes be tested using one of the demo application? If yes, which demo application can be used to test it?
Yes, meeting demo.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Did you update the commit in the submodule to get the latest changes? Or does it auto update when you test this?

Did you update the commit in the submodule to get the latest changes? Or does it auto update when you test this?

git pull --rebase origin main
npm install in the meeting demo and it pulls the commit of Levi’s PR for submodule (You specify this commit in your submodule PR so it is correct) and install it in meeting demo.
cd /amazon-chime-sdk-component-library-react and git pull origin main to update the submodule to latest commit in main (So it's the commit of my PR for React SDK).
npm install in meeting demo again and check the React SDK in node_moduels, it is the latest version.


Double tunnel

 Hi, I would like to tunnel an HPC server to VScode. My access to the server is through WSL and not through windows, so I don't manage to double tunnel VScode to WSL and then from there to the server through the ssh key. Do you have suggestions on how to solve this issue?
Thank you!

You can set up an SSH server in WSL and use it as jump host using these instructions: https://support.cs.wwu.edu/home/survival_guide/tools/VSCode_Jump.html


Fix #1989 fab moves up when snackBar messages are displayed

Fixes #1989
Changes: fab moves up when snackBar messages are displayed
Screenshots for the change:

@heysadboy I guess we can't use BindView when we are accessing a parent view from the fragment.
https://github.com/JakeWharton/butterknife/issues/578
and I get a null pointer exception if I declare it globally so had to declare it multiple times. Any suggestions?

@the-dagger the current PR works fine but when I tried not moving the fab from fragment to activity. I was not able to achieve the same results. As the snackbar messages were given from the DayScheduleViewHolder like this Snackbar.make(slot_content, R.string.added_bookmark, Snackbar.LENGTH_SHORT).show();


Fixing translations

"Schwer bewölkt" -> "Stark bewölkt"
"Schneefall" -> "Schnee" (as a stand-alone word)
"Am/Im Vormittag/Nachmittag/Abend/Nacht" -> "Vormittags/Nachmittags/Abends/Nachts" (the use of adverbs improves the flow of the sentence.)
"gleichbleibend" -> "und gleichbleibend"

Thanks for the patch! Could you also apply your fixes to /test_cases/de.json? Without passing tests, we can't accept the PR.

Merged. Thanks! This will go live sometime this week.


Added Zielona Gora, Poland

Hi, thanks for submitting the Pull Request! I'm not sure about updating the package-lock right in the same PR, would you please remove the changes to that file?

Woops, the file shouldn't be completely removed from the repo. I'm not on a computer right now, but I'll happily manually merge your PR tomorrow.

sorry, my mistake, I did not want to remove it (wrong button ;) ) I will fix it soon

Perfect, thanks!


When replay SC2Replay file in StarCraft II client encounter a error " can not open the map"

when I try to replay the SC2Replay file in the StarCraft II client, I find a error " can not open the map".
How to fix it?

Do you have the maps unique to SMAC imported into your client's map directory?


Resin Supervisor - Provisioning a device on an app that already has deltas pushed

Test Steps:
Provision a device on an app that already has the RESIN_SUPERVISOR_DELTA=1 var and a pushed image.
Expected result:

The device should appear on the dashboard and correctly download the image for the app.
The devices env variables should show RESIN_SUPERVISOR_DELTA env var set to 1.

Recent change since we now don't expose config vars: the device env vars will not show the RESIN_SUPERVISOR_DELTA inside the container.


Artifacts not listed on the correct Access Levels pages in Azure DevOps Server 2020

Hello, We are using Azure DevOps Server 2020 V 18.17.30910.2
In the access levels area, Artifacts is still only listed under VS Enterprise, and is not listed under Basic (default) and Basic + Test Plans.
This page states in it's note that Artifacts now is included with all Basic plans.
Just wanted to point this out, as it caused me some confusion (and panic as I was concerned my org. was going to be billed for VS Enterprise)
Thanks!

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

ID: b51babfa-569b-ef0a-469a-849a3835b21b
Version Independent ID: 97a78c7b-dc57-f040-4cc2-66cd91f9851f
Content: Azure Artifacts overview - Azure Artifacts
Content Source: docs/artifacts/start-using-azure-artifacts.md
Product: devops
Technology: devops-artifacts
GitHub Login: @chcomley
Microsoft Alias: rabououn

Thanks for this, @borshlite, and sorry for your confusion. I'll update the article to reflect this info. Once it goes live, this issue will automatically be closed. Thanks!

I've updated the article; however, I didn't find an access levels section within it. Were you referring to a separate article? If so, please let me know which one. It appears to be clear in this particular article that Azure Artifacts is part of Basic access. Thanks!