correct file_obj reference.

Addressing comment.

Tested with
      def test_download_url(self):

          url = "http://www.patentsview.org/data/20171226/botanic.tsv.zip"
          hash_value = "94c642405619b20ecaf657b30e84bab787320649e751ed6ac629c0be613ded44"
          download_folder = "."

          from torchaudio.datasets.utils import download_url
          download_url(url, download_folder, hash_value=hash_value)


Adding an example for seq2seq learning.

Adding implementation of sequence to sequence learning for string reversing.

This appears not to be Seq2Seq, but rather an encoder-decoder with a fixed input and output length. This is similar to other existing examples, such as the addition_rnn example.
We are interested in an example demonstrating canonical Seq2Seq. If you are interested, please submit one.


I get the error: ValueError: unsupported pickle protocol: 5

I get the error 'unsuported pickle protocol: 5' running ai4u with Unity 2021.3.16f1 on Windows 11 with Python 3.7. I install all dependencies. Full stack trace exceptions:
PS C:\Users\edu\experimento6\experimento6\controllers\controller1> python .\appgym_sb3test.py
C:\Users\edu\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\gym\spaces\box.py:74: UserWarning: WARN: Box bound precision lowered by casting to float32
  "Box bound precision lowered by casting to {}".format(self.dtype)
ai4u2unity started...
Agent configuration: id= 1  maxstep= 0
Begin of the episode....
Begin of the episode....
Traceback (most recent call last):
  File ".\appgym_sb3test.py", line 11, in <module>
    model = SAC.load("logs/rl_model_3000000_steps")
  File "C:\Users\edu\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\stable_baselines3\common\base_class.py", line 663, in load
    print_system_info=print_system_info,
  File "C:\Users\edu\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\stable_baselines3\common\save_util.py", line 421, in load_from_zip_file
    data = json_to_data(json_data, custom_objects=custom_objects)
  File "C:\Users\edu\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\site-packages\stable_baselines3\common\save_util.py", line 164, in json_to_data
    deserialized_object = cloudpickle.loads(base64_object)
ValueError: unsupported pickle protocol: 5

It's a documentation problem because error occurred in third part component. This problem can be fixed by upgrade from your current python version to python version (python 3.10 or upper) supporting pickle 5 protocol. Other solution is install pickle5 package:
pip install pickle5

.


Wrong conversion for IST timezone

For example, when parsing 9h00 PDT, the IST one is displayed as 21h00, missing the :30 part.

Fixed by #13


Kartoza Epic 5: User Story 3:  Create docker osm API layer

We need a layer to communicate between docker osm with healthsites
child of #1012

duplicate with : https://github.com/healthsites/healthsites/issues/1116


Error: cppan command '0' not found

I tried compiling by following the instruction on https://github.com/tesseract-ocr/tesseract/wiki/Compiling.
When I run the command cmake ..
it gave me an error message: cppan command '0' not found, hence the solution (.sln) file was not created.
Please help.
Environment

Tesseract Version: 4.00
Commit Number:
Platform: Windows *8 64 bit

Current Behavior:
Getting error message cppan command '0' not found.

Error log attached.
CMAKE.zip
Expected Behavior:
Suggested Fix:

Hi,
Check if you're running the latest cppan client.
Remove your tesseract/build dir and re-create it again.
If this does not help, delete c:\users\u\.cppan\storage\tmp and re-run your commands.
If this does not help, remove the whole storage and try again.

Hi,
It is solved. Apparently I forgot to set the PATH for CMAKE and GIT in the System Environment Variables.
I set the path and ran the command again.
Cheers.


Remove circular import NotificationDto

Fix circular dependency on ResourceDTO.
Mentioned in issue https://github.com/projectmgr/projectmanager-sdk-python/issues/21

Thank you for this PR!  I've also updated the code generator so it won't generate nested references again.


[Feature] Passwords to use /LP

I've a good feature request for this kind of situations where some people joins the server with a hackclient that can run commands as the console (It's exist, i've dealth with it)
Add a password protection for LP commands, we set a password in configs (if we want to) and everytime we want to use any kind of LP command no matter what permission we have (including the console itself) has to confirm the password before running a LP command. (I'd be even more awesome if we can add passwords into specific commands as well by using LP Editor) for example
Player:
1-) /lp user Spontini permission set *
2-) Output: You need to confirm the password first! /lp confirm <password>
3-) /lp confirm DEFAULTPASSWORD
4-) Output: You've confirmed your password, you'll be able to use any LP command until your next session.
And to run it as the console it may be something like this;
Console:
/lp user Spontini permission set * password DEFAULTPASSWORD
Another thing is, if we can also set passwords into specific permissions we can not by using lp command so we can block some dangerous commands. Myself and few server owners have been dealing with some group who is using a client that bypasses mojang packets to spawn items with nbt data that run commands as console.

I am one of the server owner who have been dealing this issues. It will be perfect if you add this.

Way out of scope for LP.
If your server is protected in the right way (i.e. disable OP, don't have remote access to console through like DiscordSRV's console channel, etc.) is this kind of issue non-existant.
Your problem comes from a poorly setup server and nothing more.
This feature would barely bring any benefit to any users other than yourself.

Way out of scope for LP.
If your server is protected in the right way (i.e. disable OP, don't have remote access to console through like DiscordSRV's console channel, etc.) is this kind of issue non-existant.
Your problem comes from a poorly setup server and nothing more.
This feature would barely bring any benefit to any users other than yourself.

I've disabled VPNs, I've blocked all the ports except 25565 (which my Bungee's default port) I'm running modded servers and the OP does not effect anything after installing LuckPerms, DiscordSRV is already disabled since ever. There is few modded clients that can run commands as the console, in the modded network community it's a big deal, you can trust me i'll not be the only one who gets benefits from it, i know bunch of people (some are really experienced, top servers in modded community) who got hit by those clients.

Those clents would just abuse bad plugins/mods.
The fact that they gain access to the console tells me that a plugin/mod gives them acces and LP does NOT do that, so having this wouldn't help at all...

Those clents would just abuse bad plugins/mods.
The fact that they gain access to the console tells me that a plugin/mod gives them acces and LP does NOT do that, so having this wouldn't help at all...

Those clents would just abuse bad plugins/mods.
The fact that they gain access to the console tells me that a plugin/mod gives them acces and LP does NOT do that, so having this wouldn't help at all...

Also one another thing, they do not gain access to console, they literally do it with a modded/ hacked client.

Luckperm is a permissions plugin, not an anti cheat plugin. If you have players with hacked client luckperm isn’t the place to solve it.

Luckperm is a permissions plugin, not an anti cheat plugin. If you have players with hacked client luckperm isn’t the place to solve it.

Jesus dude, i'm not asking for a anticheat plugin this feature doesn't make anything anti cheat related, it just makes anyone who got access to anything somehow can't ruin anything, LP is some kind of a protection plugin so it can have this feature, it will not give harm to anyone, it's really useful feature literally for everyone. I'm asking this to be a option for the Config not a default open feature

LP is not some kind of a protection plugin, it is a permission plugin to set permissions for players on a MC server. Luckperm does not deal will hacked client, its completely out of scope of luckperms. If hacked clients can gain console access, no matter the permissions is set by luckperm, console will always have all permissions and can run all commands regardless of luckperm's permission or setting as luckperm doesnt do not and will not do any console locking. Sure, having password protection maybe a possible feature, but if you set luckperms permission nodes correctly i dont see an issue. Thus, this does not stop your issue of players hacking having console access, since having console access means the ability to use every single plugin command and even stop the server.

LP is some kind of a protection plugin so it can have this feature, it will not give harm to anyone, it's really useful feature literally for everyone.

Wrong. LP was and always will be a permission plugin. Protection is not LPs job, but the job of other plugins like WorldGuard or CoreProtect, so this feature wouldn't make much sense in that context.
Additionally is there no proof that it will be useful for anyone. People will wonder "Uhm, what is that", set it and then get confused as to why they have to constantly write a password down in order to run basic commands.
Also, how in the world would plugins (i.e. Rankup plugins) handle this???
To be completely honest: This is a half-assed suggestion that would cause more issues for others than it can solve for you.
Your issue can be boiled down to some (human) errors:

You messed up inheritance (Make groups get perms from wrong groups) or simply gave wrong permissions to (default) groups
You run the server/network in offline mode, allowing people to use any name they like without proper UUID validation.

In case of a network could it also be caused by not protecting the backend server from direct connects (Private proxying)

Someone else gave the users permissions.

On a normal, properly setup server/network would players with "cheat clients" not have a chance with LP.
The fact that you're the first one requesting this kind of feature within years of LPs existance proofs, that this is not an issue as most servers don't face this issue because they're setup properly.
Your issue is a minority and - as mentioned before - wouldn't bring any benefits to most people but rather more complications.

LP is some kind of a protection plugin so it can have this feature, it will not give harm to anyone, it's really useful feature literally for everyone.

Wrong. LP was and always will be a permission plugin. Protection is not LPs job, but the job of other plugins like WorldGuard or CoreProtect, so this feature wouldn't make much sense in that context.
Additionally is there no proof that it will be useful for anyone. People will wonder "Uhm, what is that", set it and then get confused as to why they have to constantly write a password down in order to run basic commands.
Also, how in the world would plugins (i.e. Rankup plugins) handle this???
To be completely honest: This is a half-assed suggestion that would cause more issues for others than it can solve for you.
Your issue can be boiled down to some (human) errors:

You messed up inheritance (Make groups get perms from wrong groups) or simply gave wrong permissions to (default) groups

You run the server/network in offline mode, allowing people to use any name they like without proper UUID validation.

In case of a network could it also be caused by not protecting the backend server from direct connects (Private proxying)

Someone else gave the users permissions.

On a normal, properly setup server/network would players with "cheat clients" not have a chance with LP.
The fact that you're the first one requesting this kind of feature within years of LPs existance proofs, that this is not an issue as most servers don't face this issue because they're setup properly.
Your issue is a minority and - as mentioned before - wouldn't bring any benefits to most people but rather more complications.

I don't know what kind of rankup plugins do you guys use but in the one i can put whatever command i want to into my rank up plugin so if i tell my rankup plugin to run /lp user Spontini permission set * password DEFAULTPASSWORD it will run it and it will work just fine since it got the correct password in it's configs.
In other question this is excatly what happens during i'm getting hacked, just like other 3 server owners, happened exactly the same thing.
11cab11 is the guy who is hacking.
ABeing is myself.
[11:00:42] [pool-10-thread-1/INFO] [minecraft/DedicatedServer]: [LP] #1 (10h 52m 47s ago) (11cab11) [U] (11cab11)
[11:00:42] [pool-10-thread-1/INFO] [minecraft/DedicatedServer]: [LP] > webeditor add * true
[11:00:42] [pool-10-thread-1/INFO] [minecraft/DedicatedServer]: [LP] #2 (7h 57m 32s ago) (ABeing) [U] (11cab11)
[11:00:42] [pool-10-thread-1/INFO] [minecraft/DedicatedServer]: [LP] > permission unset *

Also this;
[11:01:47] [pool-10-thread-1/INFO] [minecraft/DedicatedServer]: [LP] #35 (10h 55m 20s ago) (Console) [G] (default)
[11:01:47] [pool-10-thread-1/INFO] [minecraft/DedicatedServer]: [LP] > permission set * true
[11:01:47] [pool-10-thread-1/INFO] [minecraft/DedicatedServer]: [LP] #36 (10h 53m 52s ago) (11cab11) [G] (default)
[11:01:47] [pool-10-thread-1/INFO] [minecraft/DedicatedServer]: [LP] > webeditor remove * true
[11:01:47] [pool-10-thread-1/INFO] [minecraft/DedicatedServer]: [LP] #37 (10h 37m 24s ago) (11cab11) [G] (default)
[11:01:47] [pool-10-thread-1/INFO] [minecraft/DedicatedServer]: [LP] > permission set sponge.command.plugins true
[11:01:47] [pool-10-thread-1/INFO] [minecraft/DedicatedServer]: [LP] #38 (10h 36m 52s ago) (11cab11) [G] (default)
[11:01:47] [pool-10-thread-1/INFO] [minecraft/DedicatedServer]: [LP] > permission set bungeetablistplus.command true

There is some log records;
[00:05:00] [Server thread/INFO] [net.minecraft.server.dedicated.DedicatedServer]: Welcome to EltegraNetwork 11cab11, enjoy your stay!
[00:05:00] [Server thread/INFO] [net.minecraft.server.dedicated.DedicatedServer]: [+] 11cab11

So He joined at 00:05:00 for the first time to the server,
and the other line that logs catch is this;
[00:05:27] [Server thread/INFO] [nucleus]: 11cab11 ran the command: /lp
so with in 5 minutes he is able to run /lp commands and the part he adds default group the * permission is not even shown in the .logs files
If you wanna take look; https://pastebin.com/ayqahxeR

It's a waste of time to tell you this, because you won't listen, but here we go again:
99% of such issues can be boiled down to at least one of these errors:

You messed up the permission system, being it making groups inherit the wrong permissions or setting permissions to the wrong groups.
You didn't setup your server properly. This can be a server running in offline mode and not having a proper Auth system in place or a server on a network not being protected against joins from outside.
Another plugin/mod is installed that the client is accessing to then get access to commands. You would be surprised how many plugins/mods have a backdoor installed that give other people OP, permissions or similar.

Your issue is more a human error on your end and nothing that LP really could fix.
Even if Luck would add a password system would this not guarantee that this stuff would stop, as there sure are other ways to gain access again.
The best protection is basically useless if someone else messes stuff.
I myself have enough of this and won't waste my time with this as you clearly can't see the larger picture of why this is more an issue than a solution to your problem.

It's a waste of time to tell you this, because you won't listen, but here we go again:
99% of such issues can be boiled down to at least one of these errors:

You messed up the permission system, being it making groups inherit the wrong permissions or setting permissions to the wrong groups.
You didn't setup your server properly. This can be a server running in offline mode and not having a proper Auth system in place or a server on a network not being protected against joins from outside.
Another plugin/mod is installed that the client is accessing to then get access to commands. You would be surprised how many plugins/mods have a backdoor installed that give other people OP, permissions or similar.

Your issue is more a human error on your end and nothing that LP really could fix.
Even if Luck would add a password system would this not guarantee that this stuff would stop, as there sure are other ways to gain access again.
The best protection is basically useless if someone else messes stuff.
I myself have enough of this and won't waste my time with this as you clearly can't see the larger picture of why this is more an issue than a solution to your problem.

I'm like 100% sure i do not have anything messed up with my permissions.
My servers arent cracked, i'm blocking all connections from the the ports except the 25565 port, and i also block proxy, VPN connections.
It'd be seen in the logs if they done such thing with a mod or plugin, a person can not have magically all the perms out of nowhere except they're using a hack client.

My servers arent cracked, i'm blocking all connections from the the ports except the 25565 port, and i also block proxy, VPN connections.

Pretty sure that is not guaranteed to protect your server properly.
How should a server know what IP is from a VPN and which aren't? That's not a proper protection imo.

It'd be seen in the logs if they done such thing with a mod or plugin, a person can not have magically all the perms out of nowhere except they're using a hack client.

You are aware that backdoors are made in a way to be silent, right?
Not every exploit screams into the console "YEHAWWWW!
Many exploits/backdoors are silent which is why they are exploits/backdoors....
Some plugins had such things for YEARS and where only discovered because someone decided to check the source code, or something.

That's like looking away from a fire and pretending it doesn't exist.

And I shall reiterate again that luckperm is a permissions plugin, not an anti hacking/cheating plugin or a hack client blocker. To be honest, you should really just ban those players that are hacking, its part of being a server admin.

@Andre601 I feel that you’re being very naive and oblivious to the situation that is actually at hand. I’m not sure if you run any dedicated modded servers, but you clearly aren’t grasping the issue.
Regardless of whether or not this is to prevent hackers, LuckPerms is a permission plugin that controls access to every plugin in the game, whether it allows for changing game modes, the destruction of hub servers, or the ban of every player across a network.
Due to the importance and power that this plugin has, regardless of any situation, I feel that having a super secret safe setting that requires you to authenticate yourself in another way other than having a permission (like a password lets say) could be very sufficient, even for administrators with trust issues that are worried that other staff members could abuse their permissions.
The uses of this are quite broad beyond just people gaining back door access using a cheat.
Be a bit more respectful instead of just shitting on a kindly-in-depth suggestion.
Thanks

I am as respectful as you can be in this situation.
What you guys are asking for is nothing more than damage control and nothing else.
When a player suddenly has access to LP commands is my first question "How did he get access to them?" and not "How can I prevent him from running LP commands?"
The main issue here is not that the player can execute LP commands without any authentication in place, but that he somehow gained permission to access those commands in the first place.
As a server owner should it be your top priority to fix the source of the issue (How did he get access?) and not try to reduce damage.
This is the wrong aproach to this issue and won't fix anything for the long term.

@Andre601 I agree that the root causes of issues should be fixed, however, you have the sole power to create a one size fits all solution to literally every one of these issues that allow exploiters to gain access to permissions, and it's just as simple as adding a new argument that cross-checks a configured value.
Even if this isn't within the scope of LuckPerms, it'd massively improve the plugin's usefulness and it would be a hugely attractive feature for those looking for permissions plugins.
I don't want to tell you what to think, but it'd be fantastic if you could look at this from the perspective of improving your plugin and expanding its reach, rather than your current standpoint.

Currently the root of the issue is the hacked client. If the player with hacked client can have console access, I am very sure there are hacks that will allow things like command spy. This will result in the hack client able to see commands like /lp confirm <password> even if there is such a feature, allowing the hacked client to have access to the password.
Sure adding a password will always be more secured, its the same for every plugin. If a hacked client also used WorldGuard commands, you can also say "password should be added to WorldGuard commands as hacked client was able to use its commands through some form of console access bypass." However, this will apply is every plugin. Does this mean that every plugin needs a password?
I do agree that adding a password has possible benefits to mitigate illegal access to luckperm commands, but its benefits not very huge and do not tackle the problem at hand, which is hacked clients. I think its important to look at the bigger picture of hacked client as a whole. In order to tackle the root of the issue is to actively block the hacks from being possible in the first place by patching exploits, fixing bugs and flaws.
Therefore, adding a password protection may have possible benefit, but going back to my first paragraph, it evident that having password will not be a solution to stopping hacked client from causing damage to a server. Password, in this case, is merely a small safeguard to increase the difficulty slightly for hacked client to gain unauthorized access, but not to stop it in any way or form.

@benwoo1110 I think it's important to make the distinction that these hacked clients are doing when they "gain access to console". They are able to spawn in items with NBT data that run commands. Such as signs that run /lp permission set * commands, they aren't actually gaining access to console as they cannot see the output of the commands they run as console.
Commands run by console don't show in commandspy, so it wouldn't be a problem to have a password as long as the password isn't run in a command in-game by a user.
And sure, an exploit caused by a mod oversight can be patched in time, but it's gonna take a lot of effort from many different people to put a stop to exploiters causing damage to servers.
As more mods are made, more exploits pop up, so why should it be the case that the developers of LuckPerms can't lend a hand with mitigating these issues? It would be a relatively small feature to add, and it would go a long way in helping to prevent the damaged caused by exploits.
As mentioned earlier, it's up to the server owners and the exploitable mod developers to fix these issues. But if the LuckPerms developers were to add a password system, it would be an incredibly useful tool for server owners to mitigate damage, so that they can free up time to work on the root causes.

The bottom line is this: if you have an exploit that is letting malicious players execute whatever commands they like from the console - you have bigger problems than just permissions on your hands.
Hypothetically, I add the password system you suggest to LP - then they're just going to move onto other commands, /stop, /ban, /give, /kill, access to WorldEdit, etc etc, all of which are arguably able to cause more damage to a server than editing permissions.
I understand where you're coming from, but ultimately, it's the root cause that should be fixed here. Bloating LuckPerms with extra password systems isn't going to solve anything.
Best of luck finding the culprit mod/plugin. (some advice: I'd start by patching the server to print a stack trace every time the console executes a command & then go from there.)

I'd quickly like to chime in and point out a few things.

Keep in mind that Andre is not an authority of any kind of this plugin. And neither am I!
I whoelheartedly agree that preventing hackers from using LP is at best just a band aid on a flesh wound. With console access in malicious hands you have bigger things to worry about. All this would do is slightly inconviniece the hackers.
Instead of asking random plugins to implement security band aids you should instead focus your efforts on finding the cause. Get together and try to work out how these people are doing it.
My personal guess is that they are giving themselves signs with NBT data. When they are right clicked they can run any command as the command block user, which has full permissions (except a few handful ones). Now vanilla doesn't just let hackers spawn items at will. And I doubt Forge is the issue here either. I think it's a backpack like mod that has no validiation that lets you create any item you want. Get in contact with any dev of a mod that add some kind of additional inventory to a player and have them verify that the client can't change items.
To reiterate; I'm not saying your issue doesn't exist or isn't bad, I'm just saying you're barking up the wrong tree by asking LP to implement superficial security.

It really could be a good idea for the few that want to protect LP commands, however the users are only giving themselves all perms through LP in order to be able to do things in-game easily... They'll still be able to run any other plugin or mod command through console, including sudo commands on opped/players with permission, thereby even allowing in-game commands to still be done, though not as easily.

Those clents would just abuse bad plugins/mods.
The fact that they gain access to the console tells me that a plugin/mod gives them acces and LP does NOT do that, so having this wouldn't help at all...

It's a modded server like i said, i can not just go and ban a random mod or whatever mod does it because it will literally kill the whole progress because 95% of the mods are connected to each other and needs each other to work properly. That's how modpacks works, you can not just go and delete a random mod or ban it, if you do that you'll kill the whole progress in a pack.

You can make a fork, add your changes, test it works and share results


RangeError maximum calls stack size exceeded

I keep getting this error after the app runs for a while only on one page the others are almost the same code but works fine

please help

Can you provide us some samples or code snippets?

`

{{data.value}}

 {{opt.value}}

          {{errorMessage}}

              {{$t('viewPoll.sendVote')}}

              {{$t('viewPoll.results')}}

`
this is the component on that page

Hi @ImadBoumzaoued
How big if data.options, how many items does it have?

at the moment the max it has is 15 items but it's kinda not the problem it seems to work on another page with exactly the same data but not with input checkbox

Can you try to see which line cause this error @ImadBoumzaoued ?

How i really can't see it in the error output,

@ImadBoumzaoued Is there any error on your server side console?

the error is gone now if it happens again I'll see if there is any

this is all there is in the console
this is app is on docker, its a bit loaded with users who keep going between two pages
one with the checkboxs which causes the error and one with just divs that display data which never caused the error.
any idea what causes this ? i'm on nuxt latest

Forgot to say that the page with the error has a count down timer with setInterval but it's behind a v-if
could that cause the error anyway ?

When is that timer initiated? If not on mounted hook SSR will make much troubles unless ensure clearTimer is called before destroy :)

its on mounted yes and I use clearInterval but seems it doesn't work anyway :P

I'm using timers in our nuxt projects without any problems :D If possible would you please try with dev branch of nuxt (using yarn link) We have added some source map helpers for even production. That may help.

I will, but for now I don't feel confident enough to try, I removed the timer and I´ll try without it, because it took down my production app 4 times until now :P
thanks a lot for the help and the awesome project, I'll keep you posted.

@Atinux In production，Wrong：
https://dolceviva.com/productlist/53
Why

The same error for me after updating to rc3.
BTW it happens every time in dev mode when I update something in the *.vue files

@chunge0328 @Fantomax Are you using timers in your code ? (setTimeout and setInterval)

@pi0 no

And there was no similar issue on alpha.4 with the same code. I updated alpha.4 to rc3 today

@Fantomax Can you please provide more logs? And possibly sharing your source code repository would allow us deeper investigate.

pi0 unfortunately I cannot share source code. I work on commercial project.
https://puu.sh/wYH7R/4d0af1ef69.png
https://puu.sh/wYH5c/bca354838a.png

I use custom server on express 4.15.3.
Other
dependencies: {     "aws-sdk": "2.80.0",     "axios": "0.16.1",     "body-parser": "1.17.2",     "chart.js": "^2.6.0",     "cookie": "^0.3.1",     "cross-env": "4.0.0",     "css-loader": "^0.28.3",     "element-ui": "^1.3.4",     "es6-promise": "^4.1.1",     "express": "^4.15.3",     "express-validator": "3.2.0",     "js-cookie": "^2.1.4",     "jsonwebtoken": "7.4.1",     "lodash": "^4.17.4",     "moment": "^2.18.1",     "multer": "1.3.0",     "node-sass": "^4.5.3",     "node-schedule": "1.2.3",     "nodemailer": "4.0.1",     "nuxt": "^1.0.0-rc3",     "pg": "6.2.2",     "pg-hstore": "2.3.2",     "s3fs": "2.5.0",     "sequelize": "3.30.4",     "sequelize-cli": "2.7.0",     "socket.io": "^2.0.3",     "socket.io-client": "^2.0.3",     "source-map-support": "0.4.14",     "vee-validate": "^2.0.0-rc.5",     "vue-style-loader": "^3.0.1",     "winston": "^2.3.1"   }

@pi0 I've noticed that vee-validate is the factor of my issue. If I disable it - app works

@Fantomax True. I think vee-validate isn't ssr friendly. Suggest using vuelidate by awesome monterail guys which work well with Nuxt too. (Potentially my answer is so Advertising 😆 )

Thanks, @pi0
Will check vuelidate from your friends 👍

I just reproduced the same issue (with identical stack trace) on hn.nuxtjs.org. I was using the PWA, so no details are available.
It also occurs occasionally with my personal app too.

Yup still have it too, no idea what causes it yet

Moving discussion to newer #1354 topic. BTW thank you all for this bug report.


Alternative ports producing 503 error

When using this as a front end to a grafana installation alternative ports are not working. This is with both the virtual_port environment variable being used and not being used (port 3000 is the only exposed port) it produces the same error. Here are the compose files below.
version: '3'
nginx-proxy compose file
services:
nginx-proxy:
image: <IP_ADDRESS>:5000/nginx-stickyproxy .  <- nginx-proxy container image renamed
volumes:
- /var/run/docker.sock:/tmp/docker.sock:ro
ports:
- "80:80"
- "443:443"
networks:
- net
networks:
net:
external: true

grafana compose file
version: '3'
services:
webui:
image: <IP_ADDRESS>:5000/grafana
environment:
VIRTUAL_HOST: grafana.example.com
GF_SERVER_ROOT_URL: http://grafana.example.com
GF_SECURITY_ADMIN_PASSWORD: test123
volumes:
- /srv/docker_content/grafana:/var/lib/grafana
networks:
- net
networks:
net:
external: true

It appears this is not really designed for warms. Unless the container happens to land on the same node as the nginx proxy it will not update the config. Could you please update your documentation to reflect that? This was not a listed limitation. At least I didn't notice it when trying to select a sticky proxy to use. Thank you

Yeah, its currently not designed to work with swarm mode. However it can be customised to do so however it takes away some of the automation


As a DevExchange developer, I want any team member (and possibly clients) to be able to update/add more content without requiring developer involvement so that we can more quickly and efficiently respond to situations requiring content changes.

Caveat that I may not have some incorrect impressions since I am new to the team, but the backstory on this is a sense that some content updates/adds are more technical than they need to be or should be. Specifically:

profile page updates - I believe this now requires a database update plus some structured file edits. also, the documentation describing the process seems to be out of date.  ideally, client organizations could manage their own profile pages (following a proscribed format) and publishing would be controlled via trivial operations by team members
developer, program manger, and technical contact guides - these should be housed in an easily updatable form/location that is "outside" of the site and can updated by team members as needed, without requiring developer involvement. Also the publishign channel should support document constructs such as table of contents, easy navigation, etc.  GitHub Wiki seems to be a natural fit here.

Another option to evaluate in this dicsussion is using GitHub pages for some parts of the site, with dynamic elements "embedded" as widgets/iframes or employing client-side API calls.


[Rails] Fix a small line-height issue with text in the Speaker cards in the new CMS

The new Admin refactor branch adds a whole new CMS to Terrastories, accessed at /en/member/ when logged in to a community.
There is a minor issue with line-height in the Speaker cards in the new CMS:

I can take this @rudokemper

I think we actually ended up solving this recently; my bad for having this up still.


[ZEPPELIN-3540] Show Spark inline UI in Non-Secure mode

What is this PR for?
After running a paragraph via Spark interpreter, we will be showing a "Spark UI" link. On clicking it, we show the Spark UI with the respective running job running.
What type of PR is it?
[Improvement]
What is the Jira issue?
[ZEPPELIN-3540]
How should this be tested?
Using Spark interpreter, run a paragraph. On successful execution, we will see a Spark UI link(as shown in screenshot below) Click on the link and the pop up modal opens up showing the Spark job in the Zeppelin context.
Screenshots (if appropriate)

@prabhjyotsingh @r-kamath - Just a reminder to review this.

ping @shahsank3t Any updates ?

@zjffdu Apologies missed out the earlier notification.

I didn't try this PR, but I didn't see backend pass spark.ui.allowFramingFrom to frontend, so how does frontend know whether it should show spark ui inline or in another windows of the old method ?

Yes, you are right. Frontend is not checking the property spark.ui.allowFramingFrom and always explicitly showing spark ui inline(within a modal).
If we want to provide the support to fallback, we can check the specified property for any value and show ui inline and if no value is set, show in another windows. Sounds good?

One drawback of inline UI is that user can not switch from spark ui and notebook, this may make user annoyed .

can we open a pop up with options, like clicking on a url link in google doc?

can we open a pop up with options, like clicking on a url link in google doc?
possible options: open, open in new tab

@zjffdu Above suggestion makes sense right? User can click which ever desired option.
@felixcheung Thanks for the suggestion, I'll look into it.

Make sense for me to provide options to allow use to chose.

@zjffdu @felixcheung
Integrated your suggestions.
Below screenshot when single job is running:

Below screenshot with multiple job is running:

Please have a look.

I just have concern that is it possible to implement it via less code change. Because it seems to be a very simple function to pop an iframe window. Not sure why it would involve so many code change. But I am not frontend expert, I may be wrong on this. Wait for other frontend expert for more comments. \cc @prabhjyotsingh

I agree with @zjffdu. AFAIK, we already have a modal for some other reasons. Can we reuse them for this issue?

@jongyoul @zjffdu @prabhjyotsingh
Updated the code by reusing modal and other available methods. Please review it.

@prabhjyotsingh Done enabling CI

@zjffdu @prabhjyotsingh Updated the PR with all the changes and documentation. Please review and let me know if I should rebase and squash the commits.

@zjffdu Thanks for the review, I wasn't aware of Zeppelin context as another thing. Have addressed your comments and fixed the wording.

@r-kamath - addressed your review comments. Please have a look again. Thanks in advance.


Beta - CSS Grid - CSS Grid should be capitalized in the challenges.

Challenge Name

All CSS Grid Challenges
Issue Description

CSS Grid should be capitalized in the title of the challenges.
To fix this issue, 'css-grid': 'CSS Grid', should probably be added after line 5 in the blockNameify function linked below.
https://github.com/freeCodeCamp/freeCodeCamp/blob/staging/common/app/utils/blockNameify.js#L5
Screenshot

I would like to work on this issue if possible.

@ahmadabdolsaheb sure thing


[Apocalypse Keys] Doomsday Delights -- new moves, new playbooks

Submission Checklist
Required

[x] The pull request title clearly contains the name of the sheet I am editing.
[x] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[x] The pull request makes changes to files in only one sub-folder.
[x] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

Changes / Description
Support for additional DIVISION moves and three new playbooks from Apocalypse Keys: Doomsday Delights. This includes a change to how Conditions are rendered; they're now text fields rather than static names, as there are several moves in the new playbooks that can result in folks needing to edit/change/replace their starting Conditions.

Character Sheet Info Roll20 Internal Use only.


Fix loginregister page navbar

CURRENT NAVBAR

THE NAVBAR SHOULD BE

Hi @mirazxmondal, can you assign me this issue please

@mirazxmondal when I open the website, the navbar is displayed correctly, the login/register button looks good. Can you please explain in detail what needs to be fixed? thank you

The problem is that in all the pages for example in Home, Explore, About the Navbar is like this

However, in the Login Register page the Navbar is showing something like this with the same CSS styling applied

As you can see the Login/Register button has been enlarged. That's the bug and could you clarify what's your screen size because this bug has occurred for the 15.6” inch screen size

@mirazxmondal  Okay now I see the bug. I was on a 1366 x 768 resolution before, now I see it on 1920 x 1080. I'll start working on it now

@alchuu00 Okay, after which please raise a PR!

@mirazxmondal I fixed the bug and opened pull request


Replace custom colour implementation with colorama colours

Currently, this package implements its own colours. Since colorama is already a dependency to fix the display of said colours on windows machines, we may aswell use colorama's colour implementation and reduce the codebase a bit.
I don't see any drawbacks to this except the additional effort it takes to refactor the codebase for this change.
Are you able and willing to implement this feature yourself and open a pull request?

[x] Yes, I can provide this feature.

done #457


Example is broken on rotation

Thanks for the feedback @gerchicov-bp. Will add support for landscape orientation as well.


Explore tab crashes

Please see
https://sentry.openbook.social/okuna/okuna-app/issues/12101/?query=is:unresolved top
and https://sentry.openbook.social/okuna/okuna-app/issues/12096/?query=is:unresolved top

Fixed in release/0.0.59


Build Error, .proto File not found

Hello, I follow the build instructions and get
CMake Error at /home/gmy/ros2_ws/install/rosidl_adapter_proto/share/rosidl_adapter_proto/cmake/rosidl_adapt_proto_interfaces.cmake:65 (message):
Proto file generation failed, error code:
builtin_interfaces/msg/Time.proto: File not found.
dvs_msgs/msg/Event.proto:9:1: Import "builtin_interfaces/msg/Time.proto"
was not found or had errors.
dvs_msgs/msg/Event.proto:23:3: "builtin_interfaces.msg.pb.Time" is not
defined.
std_msgs/msg/Header.proto: File not found.
dvs_msgs/msg/EventArray.proto:9:1: Import "dvs_msgs/msg/Event.proto" was
not found or had errors.
dvs_msgs/msg/EventArray.proto:10:1: Import "std_msgs/msg/Header.proto" was
not found or had errors.
dvs_msgs/msg/EventArray.proto:18:3: "std_msgs.msg.pb.Header" is not
defined.
dvs_msgs/msg/EventArray.proto:23:12: "dvs_msgs.msg.pb.Event" is not
defined.
Looks like something in builtin_interfaces and std_msgs are missing, particularly regarding to those .proto files. I am really a newbie to ROS, is there anything I missed? My ROS version is ROS2 Humble, on ubuntu 22.04, Thanks a lot!

I worked it out, looks like I have to make an empty workspace folder as in the tutorial, instead of using my previous workspace folder, otherwise my existing packages may interfere build process.


Remove version: Jackett.Jackett version 0.20.3889

404 - release deleted
Microsoft Reviewers: Open in CodeFlow

URL: https://github.com/Jackett/Jackett/releases/download/v0.20.3889/Jackett.Installer.Windows.exe
Response Error: The remote server returned an error: (404) Not Found.
(Automated message - build 918)


docs: remove reference to localhost

Sorry for the additional PR, but I'm currently using the web-editor and it created a new branch 😅

@timdeschryver Dude, thanks for being a copy editor for me considering how sloppy I've apparently been


Create plot from the results

Use the resulting JSON files in the reports/ folder to generate some nice looking plots like in https://www.xlang.ai/blog/openlemur

I am generally interested in outside contributions. Some notes about how I would imagine this feature:

The code that outputs static images would be best implemented in python. I am trying hard to keep the general installation for the user as simple as reasonable possible and keep the number of dependencies down.
If I would add this feature myself, I would probably use https://matplotlib.org/stable/gallery/specialty_plots/radar_chart.html since it's the only library I'm familiar with. For that reason I would also still prefer if matplotlib would be used since I have to maintain the code and I don't have time to get familiar with other libraries. Other libraries might also be fine, but I haven't really looked at them so I'm not familiar with what they do better.
The plotting itself wouldn't be done done during normal evaluation. Normal evaluation would still just output the scores to the JSON files in the reports/ folder. The plotting would be done afterwards using something like ./fasteval plot [flags...] or so. It could be implemented in a mostly separate file that is then just registered as the plot subcommand in ./fasteval. The script would read the files in the reports/total folder and plot a comparison between the models that the user specified on the benchmarks that the user specified using flags.


docs: add basic docs for isolator, mention capabilities

A common question is how to retain linux capabilities in an ACI via
acbuild, which is done with the isolator command.
This commit adds docs on the command, which includes a simple example
for retaining a capability.

LGTM


select filter bug

After filtering options and focus at list item through key up or key down, selects bad element

Please reopen if you still see this issue.


Standardize the One True Way for defining literals

With a plan for merging #265 on the roadmap, there are now quite a few (inconsistent!) ways to specify literals:

UInt(value, width)
UInt.Lit(value), UInt.Lit(value, width)
value.asUInt(), value.asUInt(width)
value.U

And several ways to construct value-less fields:

UInt(width)
UInt.width(width)

(and I'm probably missing a few, please add them...)
Since we'd like to break as much of the API as we need to before chisel3 (to minimize continued breakage in the future), let's try to standardize on one. The rest should be deprecated and/or moved into compatibility packages (so existing chisel2 compatibility code continues to work), and users can continue defining their own in their own codebases if they like, but officially, chisel3 should have just one.
I'm of the opinion that UInt(width) and UInt(value, width) should be mutually exclusive, because the first parameter isn't consistent in both cases, and they also do very different things.
Whether we keep UInt.Lit(value, [width]) or value.asUInt([width]) or value.U is a cosmetic and style question. .asUInt is structurally similar to Scala's toInt() methods, and the distinction between .U and .asUInt is just verbosity (though there's a good argument of favoring readability over code conciseness, before your code turns into symbols and alphabet soup)
Thoughts?

IMO, 1.U is also more readable than 1.asUInt; the extra chars are clutter.
This is a DSL. The distinction between Int and UInt should not be so
strong. It would be ridiculous if it took fewer chars to express a literal
in the IR than in the language.
On Friday, September 23, 2016, Richard Lin<EMAIL_ADDRESS>wrote:

With a plan for merging #265 https://github.com/ucb-bar/chisel3/pull/265
on the roadmap, there are now quite a few (inconsistent!) ways to specify
literals:

UInt(value, width)
UInt.Lit(value), UInt.Lit(value, width)
value.asUInt(), value.asUInt(width)
value.U

And several ways to construct value-less fields:

UInt(width)
UInt.width(width)

(and I'm probably missing a few, please add them...)
Since we'd like to break as much of the API as we need to before chisel3
(to minimize continued breakage in the future), let's try to standardize on
one. The rest should be deprecated and/or moved into compatibility packages
(so existing chisel2 compatibility code continues to work), and users can
continue defining their own in their own codebases if they like, but
officially, chisel3 should have just one.
I'm of the opinion that UInt(width) and UInt(value, width) should be
mutually exclusive, because the first parameter isn't consistent in both
cases, and they also do very different things.
Whether we keep UInt.Lit(value, [width]) or value.asUInt([width]) or
value.U is a cosmetic and style question. .asUInt is structurally similar
to Scala's toInt() methods, and the distinction between .U and .asUInt is
just verbosity (though there's a good argument of favoring readability over
code conciseness, before your code turns into symbols and alphabet soup)
Thoughts?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ucb-bar/chisel3/issues/294, or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-7wmNQ02k_O3WiJgi6L-VAGI6cwCe9ks5qtG2bgaJpZM4KFgD0
.

BTW, I don't think the PR should be merged til the exact syntax is
resolved. This is about the API, after all!
On Friday, September 23, 2016, Andrew Waterman<EMAIL_ADDRESS>wrote:

IMO, 1.U is also more readable than 1.asUInt; the extra chars are clutter.
This is a DSL. The distinction between Int and UInt should not be so
strong. It would be ridiculous if it took fewer chars to express a literal
in the IR than in the language.
On Friday, September 23, 2016, Richard Lin<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>> wrote:

With a plan for merging #265
https://github.com/ucb-bar/chisel3/pull/265 on the roadmap, there are
now quite a few (inconsistent!) ways to specify literals:

UInt(value, width)
UInt.Lit(value), UInt.Lit(value, width)
value.asUInt(), value.asUInt(width)
value.U

And several ways to construct value-less fields:

UInt(width)
UInt.width(width)

(and I'm probably missing a few, please add them...)
Since we'd like to break as much of the API as we need to before chisel3
(to minimize continued breakage in the future), let's try to standardize on
one. The rest should be deprecated and/or moved into compatibility packages
(so existing chisel2 compatibility code continues to work), and users can
continue defining their own in their own codebases if they like, but
officially, chisel3 should have just one.
I'm of the opinion that UInt(width) and UInt(value, width) should be
mutually exclusive, because the first parameter isn't consistent in both
cases, and they also do very different things.
Whether we keep UInt.Lit(value, [width]) or value.asUInt([width]) or
value.U is a cosmetic and style question. .asUInt is structurally similar
to Scala's toInt() methods, and the distinction between .U and .asUInt is
just verbosity (though there's a good argument of favoring readability over
code conciseness, before your code turns into symbols and alphabet soup)
Thoughts?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ucb-bar/chisel3/issues/294, or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-7wmNQ02k_O3WiJgi6L-VAGI6cwCe9ks5qtG2bgaJpZM4KFgD0
.

That's true, but the other argument is that this could be a much longer debate (and arguably an issue that wasn't introduced by the PR, though it certainly contributed to the addition of styles). Note that there are some other issues still being worked out with the PR, so it's entirely possible this debate could be resolved before the PR is ready, and the results integrated.
More people should chime in: @jackkoenig @sdtwigg @chick @ucbjrl (probably many more I missed)
Including the DSP people, and whether their DSP DSL can be stylistically consistent: @grebe @shunshou

Hopefully @grebe will respond, but I think he was saying that there was some bug with Vec of Vec of Lits? Something about Lits just taking on the minimum width they needed to take on, but due to not supporting non-homogeneous Vecs [I assume for some ROM thing?], there was some error thrown...
And his intended work around was something like first declare UInts of unknown widths and then assign them to Lits... ???

Regardless, I think it's useful to be able to specify a Lit where it auto calculates the width, and, if there's some chance that code might break (as in @grebe's case and possibly others, although I can't think of any atm), specify a Lit where you can give it a width that it would pad to.
1.U and -1.S seem cute? I haven't played around with Chisel3DSP front end yet (next week!), but I would assume you wouldn't be able to do something like -1.333.F for Fixed pt vals? (can you have two "."'s? and you'd still need to specify # of fractional bits...)
I believe @chick @azidar and @grebe have picked some way to represent Lit's... I'm personally ok with whatever as long as I get to use them in the ways I'd like to use them...

I like 1.U. I forget if you need the dot. @shunshou is right to bring up -1.333.F, but I think that it works (or if it doesn't, then (-1.333).F does, and if you don't need the dot maybe -1.333 F will work). I think the real issue is that it looks a bit funny. I'm positive that @chick showed me some examples that made me feel good but I'm forgetting exactly what they are. I don't think we've thought a lot about what literals should look like for Complex numbers, but I don't see a problem with Complex(real.U, imag.U) or whatever.
The Vec of Vec issue I think is orthogonal to how you actually specify literals, as long as there is a way to specify the width of a literal (which I feel is extremely necessary).
I also like UInt.Lit and getting rid of UInt(value), but of course the problem is fixing all the code that uses UInt(value). I don't think there's anything particularly special about DSP here.

@grebe the main idea here is to specify the One True Way for chisel3. The ways to want to remove can be deprecated for a few versions before being removed and added to chisel2 compatibility mode, which avoids breaking anyone's code immediately. RTL which makes extensive use of deprecated constructs and which really don't want to migrate can define their own compatibility layers past deprecation.
Anyways, what I'm getting here is that:
We want to keep 1.U over 1.asUInt. Perhaps also add 1.U(width) for consistency?
Kill UInt(value), UInt(value, width) with fire. Probably keep UInt(width) (it's sufficiently different from a literal constructor)?
Not sure what to do about UInt.Lit. Some like it, though it would be duplicated with 1.U now.

The main temptation behind (at least retaining) asUInt is that I think it
reads better in more cases than just .U.
When just instantiating from actual scala constants without width
specifications like with 1.U and 1.asUInt, either looks fine.
When instantiating from scala identifiers like maxElements.U and
maxElements.asUInt, just U can 'get lost' or be more unclear since you
don't have the context of seeing a literal number to jump off from. This
also applies to writing expressions like (0 until 8) map (.U) versus (0
until 8) map (.asUInt)
When specifying a width in both cases, asUInt(width) provides a nice
symmetry with the UInt(width) for constructing UInt-types. e.g. 1.asUInt(2)
would be something we can definitely put into a Reg(UInt(2)) and matches
visually.
Even if you make it package private, you should still have Lit or some
variant in the constructor so that the actual code for constructing a
literal UInt is 'close' to the UInt class definition. The stuff in the
package object implicits then is just using a simple function call to
delegate to the more complex code.
On Tue, Sep 27, 2016 at 1:29 PM, Richard Lin<EMAIL_ADDRESS>wrote:

@grebe https://github.com/grebe the main idea here is to specify the
One True Way for chisel3. The ways to want to remove can be deprecated for
a few versions before being removed and added to chisel2 compatibility
mode, which avoids breaking anyone's code immediately. RTL which makes
extensive use of deprecated constructs and which really don't want to
migrate can define their own compatibility layers past deprecation.
Anyways, what I'm getting here is that:
We want to keep 1.U over 1.asUInt. Perhaps also add 1.U(width) for
consistency?
Kill UInt(value), UInt(value, width) with fire. Probably keep UInt(width)
(it's sufficiently different from a literal constructor)?
Not sure what to do about UInt.Lit. Some like it, though it would be
duplicated with 1.U now.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ucb-bar/chisel3/issues/294#issuecomment-249988642,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA9_-DAQAm6bVM7TU8eS-JtlG4syBTOZks5quXy0gaJpZM4KFgD0
.

So... keep both .U and .asUInt (with the former intended for constructing basic numerical literals, and the latter for readability when constructing literals programmatically - perhaps as part of style guidelines)?
And make .U and .asUInt just call into a UInt.Lit (chisel3-private), which is the internal way to construct literals?
So UInt(value, width), UInt(value), UInt.width(width), and UInt.Lit (all variants) would be deprecated from the public API?
Do we want to add .U(width)? Probably not, since it's not particularly readable, especially if we're keeping .asUInt(width)?

UInt(width) is awful, it goes against tons of existing Chisel code (and tutorials and docs) and it's not intuitive.  I'm not sure why the hate against UInt(value) and UInt(value, width), other than we needed a better ability to throw errors/warnings when people did things like Reg(UInt(4)) instead of Reg(UInt(width=4)) or Reg(init=UInt(4)).

What should the API be for a constructing a value-less UInt of specified width then?
(my reason for the hate against UInt(value) is because of the potential confusion you stated, I prefer an API that makes things unambiguous, especially for people who haven't had years to learn the quirks)

I've always been quite content with UInt(width=x); it's very clear.

As of current Scala, macros break with named and default arguments. I don't think we've needed macros with UInt yet, but this may limit options in the future.
Finding the constructor for UInt(width=x) also isn't very clear, behind the scenes there's a default dummy first parameter that disambiguate it from the UInt(x) case.

Maybe I am missing something, but I was surprised to find out that
assert((UInt(1) + UInt(1)) === UInt(2))
started failing in Chisel3. Could not find anything in migration guides
about this.
I hope UInt(x) is either removed due to it's ambiguity or kept to still
mean UInt(value).

It is confusing, but this is actually a bug fix. In both chisel versions, + is modular addition. Since UInt(1) is one bit wide, the result of adding UInt(1) to UInt(1) should be one bit wide, i.e. UInt(0).
Chisel2 performed the modular addition of one or both inputs was not a literal, but incorrectly performed exact addition if both were literals.
To get the behavior you desire, there's a new operator, +&, which performs exact addition.

Oops, I replied before seeing your edit.

Sorry about the noise. Great to see +& entering the language, much cleaner than Cat'ing with 0.

Can I still beg that eventually + not be modular addition and instead use a separate +% for modular addition?

Since it has been like that for 6 years, the backwards incompatibility is likely to cause more confusion than it solves.

Bump bump bumpity bump. We should really (at least!) resolve the One True Literal Constructor.
(and we could still keep all the legacy code working without rewriting through compatibility shims while presenting only one clean way in new code)

We discussed this at the Chisel meeting today, and the proposal we came up with for chisel3 going forward (as in, no removals / deprecations to Chisel compatibility package) is:

Constant literal specifier: 2.U and myInt.asUInt.
Deprecate UInt(value, width), UInt(value), UInt.Lit(...).
Width specifier: UInt(width), where width must be of Width type.

Deprecate UInt.width(width) and UInt(width=x:Int)
Previous code written with UInt(value) will type error and be "safe". Because of the different type signatures, this could also be backported to Chisel2.
We will add a shorthand specifier to construct Width from a Int, like 4.W. Exact semantics up for debate.
This makes our version somewhat similar to certain forks that have a UInt(width: Int) constructor, where width is just an Int. Implicit conversions (won't be part of standard Chisel) can bridge the gap.
The .U and .asUInt constructor will be consistent with the UInt constructor, for example 2.U(4.W) would create a 4-bit wide literal with value 2.
Future: the width field in the constructor would be generalized to handle ranges. The ranging PR is coming soon, but the whole constructor would look something like UInt(range"[0, 32)") (a UInt from 0 inclusive to 32 exclusive)
This makes the difference between Chisel data types, Scala numbers, and widths explicit and exposed in the API.

Thoughts? @aswaterman @shunshou @sdtwigg @azidar @jackkoenig

I'm all for being explicit. Hopefully everyone agrees on this as a convention and I can start using it, instead of having to recode everything for the n-th time. :p

Seems reasonable.
Re: ranges: it's important that widths and ranges are kept entirely separate, rather than implementing widths in terms of ranges.  A width of N is not the same thing as a range [0,2^N-1], because the ranges allow optimizations that would not be allowed for widths, changing the semantics.  This goes for both Chisel and Firrtl.

So how do you propose two numbers (one specified w/ worst case width; the other specified with a possible range) be added? Seems to make sense to add range + width converted to range in that case.
Generally speaking, I probably wouldn't be mixing and matching too often, if at all, but...

Or is it better then to have some kind of RangedUInt that gets propagated throughout if you want to be able to differentiate between the two easily?

Mixing and matching them is fine. If you add a ranged thing with a
widthed thing, you get a ranged thing.
If you add a widthed thing with a widthed thing, you should get a
worst-case widthed thing, not a slightly-more-optimistic ranged thing.
UInt literals must be widthed by default, not ranged, to preserve current
behavior.
The width inference problem rcan't be expressed as a range inference
problem, because it is incorrectly optimistic.
I'm saying that if you add two width'd things, you should get a worst-case
width'd thing, not a ranged thing. And the width inferencer can't be
On Wednesday, November 16, 2016, Angie Wang<EMAIL_ADDRESS>wrote:

Or is it better then to have some kind of RangedUInt that gets propagated
throughout if you want to be able to differentiate between the two easily?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ucb-bar/chisel3/issues/294#issuecomment-261095249,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-7wiDXq2tY6cBHrTOqfFz849XQufbPks5q-4WfgaJpZM4KFgD0
.

I believe it is possible, if both width and range information is kept for the inferencer, to do range optimization on width-declared wires only when the effects of optimization aren't visible. For example, if you always take the lowest bit from an addition, you can certainly back-propagate that constraint to trim widths. This like head, bits, tail, etc. should dictate these requirements.

I'd say that you'd likely get the most optimization when treating Lits (with unspecified widths) as having a range of [itself,itself]. But that probably doesn't matter if you expect to be adding a Lit to a ranged thing.

Re: lowest bit from an addition, you then have to separate out +% and + behavior? Or are you assuming +% always is kind of "widthed" vs. + is "ranged" = would never overflow?

As long as it has zero effect on the widths of width-inferred things vs.
current algorithm, that's fine. The extra info can then be used to
optimize ranged things.
On Wednesday, November 16, 2016, Adam Izraelevitz<EMAIL_ADDRESS>wrote:

I believe it is possible, if both width and range information is kept for
the inferencer, to do range optimization on width-declared wires only when
the effects of optimization aren't visible. For example, if you always take
the lowest bit from an addition, you can certainly back-propagate that
constraint to trim widths. This like head, bits, tail, etc. should dictate
these requirements.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ucb-bar/chisel3/issues/294#issuecomment-261098161,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-7wqssFYt1sFRfak65wksM5ppY9KN2ks5q-4h5gaJpZM4KFgD0
.

@angie that would be backwards incompatible. Current code can correctly assume that 1.U+1.U+1.U has a width of 3.

Sorry I meant +& not +

Firrtl only has one add operator, so if ranged UInts want to use that behavior, they need to use %+.

I'm talking about Chisel operators. Anyway, my point is, make sure Chisel's current behavior is exactly preserved.  Range inference is a new feature and should have absolutely no effect on code that doesn't use it.

I believe that @azidar and @chick and I had a discussion some time ago about how to do ranges with the same width-inference behavior. The idea was that wherever range inference could trim something, it would produce a UInt/SInt with a width the same as the normal width inference, but those bits that can be trimmed would be replaced with constant 0s/sign extension.

Probably possible. I propose large designs passing a formal equivalence check should be required before merging that. It's a little scary.

I agree. I think there should always be a setting so that range inference reverts to "conservative" width inference

You mean constant 0's / sign extension [up to full width] that you then leave the synth tools to take care of presumably b/c they're good at that? I guess I buy that.
I mean, i thought in that case, you might as well make range inference an optional pass that you can run on top of width inference if you so desired...

The separate-pass approach seems more prudent to me.

In that case, you'd have to probably be a bit more choose-y on modules to perform the pass on [i.e. don't touch rocket-chip related modules b/c you guys like your bitwidths but get optimization-happy with DSP] -- and in that case, is there an easy way to group modules you don't want to touch without having to go through things one by one if, for example, rocket-chip is actually top level?

Module annotation?

Sure. Just annotate which modules are "safe" for range inference, I guess?  But then again, you probably shouldn't be annotating as the systems guy, and it should be each individual block designer's job to annotate whether his/her block is range inferrable.
My problem right now is (well, at least in the summer), when you use rocket-chip, you're kind of locked into its ecosystem and you have to abide by its rules unless you compile your stuff separately and black box it.

I mean, ideally the optimization should never affect any behavior, regardless of whether you declare a wire with a range or a fixed width. So in the long term (after verification), this optimization should be fine to run on rocket-chip. If in the interim you want to selectively run it, that's fine, but we should make this goal clear.

In some contexts, it makes sense to think of stuff with only widths... so ranges shouldn't apply to everything. I also really don't like that Bits is equivalent to UInt. I know you've discussed this with Paul a bit, but what does bitwise and, or, etc. mean in the context of a UInt? IMO, you should only be allowed to do that if you've explicitly casted the UInt to be Bits.
Even if you could theoretically consider ignoring stuff in a range optimizer, I think it's important to separate out numbers that have range from bits that you want to do bit manipulations on [which is more of a processor thing?]...
I thought part of the point of Chisel was to be type-safe, but if you confuse Bits/UInts, you're not really abiding by the philosophy, IMO.

UInts are defined to use standard binary encoding and SInts are defined to use two's complement, so the bitwise operators are pretty clearly defined.  Also, Verilog, C, Java, Scala, etc. define bitwise operators on integers for the same reason, so it seems least surprising to permit them.
Bits == UInt is a wart from chisel1.  The old Bits companion object should be deprecated in chisel3.  It's not actually possible to construct a concrete Bits, anyway, since it is an abstract class.

In any case, range inference works fine for bitwise operators, too.  The rules are just more complicated than for arithmetic.

@shunshou, are you saying that you want the distinction between UInts and "Bits" because you don't want ranged optimizations to happen on things you intend to be "Bits"? If that is your worry, it shouldn't be. Again, any ranged optimization will not affect the circuit. Thus, any use of a UInt in a "Bit" context will have its exact behavior preserved.

I thought part of the point of Chisel was to be type-safe, but if you confuse Bits/UInts, you're not really abiding by the philosophy, IMO.

Its only "not abiding by that philosophy" if there is an observable difference between the two. Since there isn't, there is no need to add additional distinctions with no added benefit.

I just don't think the output of a bitwise operation should be allowed to have a range, unless you're doing something more general like selecting [Mux] between 2 numbers, even if ranging doesn't affect the circuit.
Like do you ever associate ranges with boolean algebra? Maybe someone who knows more should fill me in...

It seems weird to prohibit, since it's just another operator.  As Adam points out, it should be invisible to the user, anyway, so why does it matter what optimizations the compiler is performing?
An example where this would actually show up is in floating-point rounding hardware.

Ok, guess it doesn't matter. As long as Chisel functionality keeps growing, I'll be content...

After almost two months, this is finally done!
(the discussion here also went off a tangent on ranging, that should probably be tracked in a separate issue if it's still an outstanding item)


Query Regarding iRMSE calculation.

Hello,
Thank you for the great work.  I want to ask one small query regarding the iRMSE calculation. In your code iRMSE is calculated as follows
        # convert from meters to km
        inv_output_km = (1e-3 * output[valid_mask])**(-1)
        inv_target_km = (1e-3 * target[valid_mask])**(-1)
        abs_inv_diff = (inv_output_km - inv_target_km).abs()
        irmse = math.sqrt((torch.pow(abs_inv_diff, 2)).mean())`

I want to ask two things

In the first two lines according to your comment, you are converting meters to kilometers. Why are you multiplying with 1e-3 and taking the power to the -1? shouldn't it be 1e3?
inv_output_km is causing the iRMSE to go Nan. This is because output[valid_mask] is 0 at some entries of the tensor. Is this normal behavior?. I am using the same dataset as yours. Is it expected to decrease in late epochs? I only ran training for 5 epochs and iRMSE and IMAE are going Nan.
P.S I am training ENet so I am on round 1.

Thanks for helping out.

Hi!
For the first question: it is 1e-3 as we can see output m = (1e-3*output) km.
For the second question: it is expected to decrease in late epochs. However under the settings in the paper (or the same environments and command line in readme)  the inverse metrics are not no longer nan after 2 epochs.

Thanks for the reply, So iRMSE should go down after 2 epochs in your setting?


Update ice4j to mainline and off custom fork

Have you seen this commit?
https://github.com/Geosearchef/ice4j/commit/52c8e4bcef5c3af9d299ffcdcc07b9e87bf8959a
Without that and some reflection hack in the adapter code (not sure if that breaks with a newer version), your relay connections will time out and die after 10 mins.

I played multiple full games beyond 10 minutes with the latest version

Also the lifetime is supposed to be explicitly set from the stun response as well. So using the value returned is proper. As this is the interval requested by the stun server

If you didn't use a relay candidate, it doesn't matter that it worked for you, it won't work for others who need a relay candidate.
About the lifetime value, in theory that should be correct, in practice I can just tell you it didn't work back when I developed this and the turn server did not act according to documentation.
Do with that what you will, just saying, there's a reason I had to do this and you should test multiple games with multiple people with the new adapter before deploying any business logic changes to the adapter.

I had force relay on for some of the games as well. And yes I plan on testing

I had force relay on for some of the games as well. And yes I plan on testing

Ok, then it's probably fine.
Just providing some info from when this was developed, as there were a lot of quirks I had to work around.
(If I remember correctly, back in the day, the TURN server requested 10 mins, but timed out at 6, so I set it at 4 below 50%)
But if it works now as intended, even better.

Understood. I appreciate the background as to why


automatically added unique index in OneToOne

ClassMetadata -> _validateAndCompleteOneToOneMapping
code:
...
if ($mapping['type'] === self::ONE_TO_ONE && ! $this->isInheritanceTypeSingleTable()) {
    if (count($mapping['joinColumns']) == 1) {
        if ( ! isset($mapping['id']) || ! $mapping['id']) {
            $joinColumn['unique'] = true;
        } else {
            $uniqueConstraintColumns[] = $joinColumn['name'];
        }
    }
...

I think it's not good to add automatically unique index on ONE_TO_ONE join... this make me mess in project ... If am I wrong, please tell me why :)

or please tell me what to do, becouse I CAN NOT HAVE IT (uniqiue index in database)

A one-to-one requires uniqueness on the association. If this breaks your constraints, that means that you are looking at a many-to-one association.

in my project I must have ONE_TO_ONE .. relation exists or not
but I'm also using softDeleteable
so when I make ONE_TO_ONE  relation ... soft delete relation ... then I can not make new one

Yeah, that's because soft-deletes are break integrity by design.
This has nothing to do with one-to-one by itself: you will have to redesign all your unique indexes anyway (making them span over the soft-delete keys).
Closing as invalid


Latest rulesets.

@pranavgaikwad reviewed and thought the changes made sense based on changes in the ruleset repository.


Calculus

I LOVE YOU!!!
Your article with $\LaTeX$ was so awesome, I got mach about math with those things you wrote.
Wating for your new masterpiece.

Thanks for report! Unfortunately, I don't plan to fix the bug that my article is so awesome.


Add a Readme with description and how to run

Could you please add a Readme file with the description of the project and how to run it?
Originally posted by @FireAndBlood12 in https://github.com/akrava/software-engineering-methodology-practices/pull/1#discussion_r863938287

This issue was generated from the comment, which was left as part of the review initial PR of this task.

So, I'm agree that we need to create a Readme file to make project purposes more clearer. I'll do it, thanks @FireAndBlood12

I've opened PR #13 in order to add documentation for this project

Fixed in https://github.com/akrava/software-engineering-methodology-practices/commit/2b6cc7eebad51472321315281580a2d62b021ecb. So this issue is closed. Feel free to reopen if needed


Create documentation with details

[x]  Structure for documentation @sasachan
[ ]  Update landing page
[x]  Create different sections

Structure for documentation is created.
Also created different sections in page


feat(Radarr): Add RlsGrp W4NK3R to HD Bluray Tier 03

Pull Request
Purpose

Add RlsGrp W4NK3R to HD Bluray Tier 03
Approach

Added RlsGrp W4NK3R to HD Bluray Tier 03
Open Questions and Pre-Merge TODOs

[x] Tested locally
[x] Sorted Json A-Z
[x] Imported the JSON in locall Radarr to test for import errors

Requirements

[x] These changes meet the standards for contributing.
[x] I have read the code of conduct.

https://github.com/TRaSH-Guides/Guides/pull/1942#issuecomment-2119341555
On hold because this also needs to be checked for this one

Checked and this one doesn't need any of those changes, because it's just a extra condition in a CF and not a NEW CF

Checked and this one doesn't need any of those changes, because it's just a extra condition in a CF and not a NEW CF

Just replying to confirm - changes to existing CFs don't necessitate updates to the profile JSONs.


Reaction Role

Proposal:
Proposal written by 0RedFox0/Jonas
What is the title of your proposal?: Reaction Role
Is it a suggestion for the website or for the bot?: Bot
Explain your proposal more accurately (It's best to give as much information as possible, so that we can implement the proposal better): If you react to a reaction you receive a role
Why should we add this feature?: Because you can´t fix that  without having knowledge in coding and I don´t want to have thousands of bots
ReportID: 105

➤ LenoxBot commented:
Approve:
agree with "nicklel" 😂
Profxy#5396

➤ LenoxBot commented:
Approve:
Good proposal! 😃
CrEePeR28 ~~ Furkan#3532

➤ LenoxBot commented:
Approve:
agree with Furkan and Profxy
Wandi#9576


Initial storage merge

Merge storage topic branch into master. This merge adds WIP storage functionality into the master branch so that development can continue on master.

Coverage increased (+0.8%) to 66.421% when pulling 8a679850669e82793e0ef8f3119ebf3b731e233a on kaccardi/topic/storage into 2aec2f34c667e28dbf6aaff4051ab2014513f1cd on master.

Coverage increased (+0.8%) to 66.421% when pulling 8a679850669e82793e0ef8f3119ebf3b731e233a on kaccardi/topic/storage into 2aec2f34c667e28dbf6aaff4051ab2014513f1cd on master.

@kaccardi  ciao-controller/openstack_volume.go is missing a copyright header.

So is openstack/block/api_test.go

And openstack/identity/identity_test.go

Coverage increased (+0.8%) to 66.414% when pulling a6a8c50650dd08f7118aca51165c327122be64a3 on kaccardi/topic/storage into 2aec2f34c667e28dbf6aaff4051ab2014513f1cd on master.


Add fuzzing, same way as done for https://github.com/martinus/unordered_dense

Is your feature request related to a problem? Please describe.
Might find problems
Describe the solution you'd like
Same implementation as for https://github.com/martinus/unordered_dense, it's awesome

done! also fixed a bug found by the fuzzer


Error: '$' is not an identifier; use backticks to escape it

When I install the project on a new Xcode Project and compile it, Xcode shows this error:
UAObfuscatedString.swift:101:9: '$' is not an identifier; use backticks to escape it

Looks like this is fixed in master but the cocoapod hasn't been updated

I emailed @coneybeare directly to address this, so hopefully the cocoapod will be updated soon!


NoClassDefFoundError: jdk/net/ExtendedSocketOptions during connection

Driver version
10.2.3
SQL Server version
Microsoft SQL Azure (RTM) - 12.0.2000.8
Client Operating System
CentOS Linux release 7.9.2009 (Core)
JAVA/JVM version
OpenJDK Runtime Environment (Red_Hat-<IP_ADDRESS>.8-2.el7_9)
Table schema
n/a
Problem description
When starting on WildFly 24.0.1, using mssql-jdbc-10.2.3.jre11.jar, our Hibernate-based application is unable to connect to the database. Application gets an IJ031084: Unable to create connection error
Caused by: java.lang.NoClassDefFoundError: jdk/net/ExtendedSocketOptions
Error message/stack trace
Caused by: java.lang.NoClassDefFoundError: jdk/net/ExtendedSocketOptions
        at deployment.mssql-jdbc-10.2.3.jre11.jar//com.microsoft.sqlserver.jdbc.DriverJDBCVersion.setSocketOptions(SQLServerJdbc43.java:66)
        at deployment.mssql-jdbc-10.2.3.jre11.jar//com.microsoft.sqlserver.jdbc.TDSChannel.open(IOBuffer.java:702)
        at deployment.mssql-jdbc-10.2.3.jre11.jar//com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:3180)
        at deployment.mssql-jdbc-10.2.3.jre11.jar//com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:2833)
        at deployment.mssql-jdbc-10.2.3.jre11.jar//com.microsoft.sqlserver.jdbc.SQLServerConnection.connectInternal(SQLServerConnection.java:2671)
        at deployment.mssql-jdbc-10.2.3.jre11.jar//com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:1640)
        at deployment.mssql-jdbc-10.2.3.jre11.jar//com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.java:936)

Any other details that can be helpful

Works fine with mssql-jdbc-10.2.1.jre11.jar
Same error with mssql-jdbc-10.2.2.jre11.jar

hi @dleborgne
Looks like this is an issue with your Wildfly configuration it can not find jdk.net.ExtendedSocketOptions. Older versions of the driver had an issue where it explicitly defined ExtendedSocketOptions that had been fixed in #1953  . Now the driver uses jdk.net.ExtendedSocketOptions directly. I believe you will need to add the jdk.net module to Wildfly. We do not support Wildfly directly so if you have questions on how you can do that, please contact their support.

Hello @lilgreenbird
Thank you for your answer. It looks like the MongoDB Java driver faced a similar issue and ended up removing the hard dependency to jdk.net, which, I quote, is not actually part of the standard library (though in practice it is usually available).
https://jira.mongodb.org/browse/JAVA-4005.

hi @dleborgne
Thank you for the reference this looks reasonable we will look into adding the same in our driver.

fixed for 12.2.0


Feat/paging

#1569

Looks like deltalink is missing as well.

@MIchaelMainer, what is deltalink? This was designed to mirror the autorest extension Autorest x-ms-pageable

@MIchaelMainer the delta link is a mechanism of sync, not paging. By definition when your application gets a delta link, it's done paging the current changes with the next link, and needs to persist it and come back with it later. I don't think this applies to the scope of these changes.


Update user if newer release available

645f721 (Shubham Minglani, 2 minutes ago)
Update user if newer release available
This commit notifies the user if a newer ocdev release is available than
the release that they have installed right now.
If there is an error getting the new release, the error is ignored but
logged, because this should not block program execution.
4a87980 (Shubham Minglani, 3 minutes ago)
Change VERSION to v0.0.1
This commit changes the VERSION that is reflected in ocdev version to
v0.0.1 which is in sync with our release versions on GitHub as well as the
rest of the Kubernetes, OpenShift ecosystem.
083870d (Shubham Minglani, 5 minutes ago)
vendor add: google/go-github and blang/semver
This commit updates vendor/ to bundle in the following dependencies:

github.com/google/go-github
github.com/blang/semver

The output looks like -
$ ocdev

A newer version of ocdev (version: v0.0.1) is available.

Update using your package manager, or run

curl https://raw.githubusercontent.com/redhat-developer/ocdev/master/scripts/install.sh | sh

to update manually, or visit https://github.com/redhat-developer/ocdev/releases

related to https://github.com/redhat-developer/ocdev/issues/71

Just noticed one thing: It noticeably slows  ocdev execution even on a really fast internet connection.

@kadel updated the PR, and yeah, this slows it down :|
I think we should poll once in the program execution in a non-blocking way, and store it to the config file, and not check for errors or something, and only read from the config file during execution. But yeah, let's do that in another PR.

created https://github.com/redhat-developer/ocdev/issues/122 to address issues with current implementation.

@kadel yeah, I think we can merge it for now, it adds about half a second delay, but should be fine for now

@kadel yeah, I think we can merge it for now, it adds about half a second delay, but should be fine for now

But that delay is not small. :-(
Can you please start working on config option to disable this as soon as this is merged?


Removing deprecated AllTypes and AllTypesOf

This PR addresses the removal of AllTypes and AllTypesOf which have been flagged as obsolete based on issue #338

That's an easy one, no unit tests where even using them 👍


updated compute, vpc, firewall, and nat modules as well as their read…

… mes

added functionality to nat and compute modules to allow them to be used more generically rather than just as the original use case, so please even though they can be merged cleanly, PLEASE TEST THEM before merging.


Integarting sharp for web browser

I have successfully integrated sharp for electron but web browser im getting "require is not defined"
I used the webpack for configuring sharp in run time
in webpack.config.js file i have
externals: {
sharp: 'commonjs sharp'
}
im able to perform all operations of sharp in electron app with same code but no luck in browser
I have tried many options from stack overflow and the issues listed in this repo but failed.
Im using sharp in backend for quiet a long time and now when i try to move it to front end angular application it works for electron only. If anyone can point me out what am in doing wrong or any links would be really great.
Uncaught ReferenceError: require is not defined
at Object.sharp (external "sharp":1:1)

This module requires a Node.js runtime and will not work in a web browser.

Thank you for your quick reply @lovell
I tried to use browserify which convert node modules to js files which was supported by other node modules except sharp.
Any future plans to support sharp in browser ?

Please see https://github.com/libvips/libvips/issues/192


[FLINK-2332] [runtime] Adds leader session IDs and registration session IDs

Registration Session IDs
Introduces registration session IDs for all registration messages. Upon receiving a registration message, this ID is checked and if not correct, the message is discarded. That way, it is possible to distinguish old registration messages which are delayed from valid ones.
In the current implementation, a static registration session ID is assigned when the TaskManager actor is created. However, with support for high availability, where the leader can change while trying to register at old leader, it becomes important to distinguish old from new registration messages.
Leader Session IDs
In order to support high availability, we not only have to distinguish the old from the new registration messages, but also control messages which are sent to and from the JobManager and the TaskManager. In order to filter out possibly old messages, this PR introduces a leader session ID which denotes the currently valid messages. However, unlike the registration session ID, leader session IDs are assigned to messages transparently.
Messages which extend the RequiresLeaderSessionID interface will be wrapped in a LeaderSessionMessage which also contains the currently known leader session ID. At the receiving end, the LeaderSessionMessages are unpacked and the received leader session ID is compared to the currently stored leader session ID. If both IDs are the same, the wrapped message is processed. If not, then wrapped message will be discarded.
In order to support this behaviour, the PR introduces a new FlinkActor for Scala actors and a FlinkUntypedActor for Java actors. Both actors provide a decorateMessage method which allows sub types of the FlinkActor/FlinkUntypedActor to decorate outgoing messages. Therefore, all implementing classes are supposed to call decorateMessage before sending a message to another actor.
The FlinkUntypedActor already comes with support for message logging and leader session message filtering. Furthermore, its decorateMessage method implementation checks for each message if it's an subtype of RequiresLeaderSessionID or not and if it is the case, then wraps this message in a LeaderSessionMessage. The receive method of this class, will then take care to unwrap the messages accordingly.
In order to have the same behavior with Scala actors one has to extend the FlinkActor and mixin the LeaderSessionMessages and LoggingMessages mixins. They effectively do the same as the FlinkUntypedActor, but offer a better extensibility of the Scala actors in the future.
In case that a RequiresLeaderSessionID message is received without being wrapped in a LeaderSessionMessage by a FlinkActor, an exception is thrown, which effectively terminates the execution of the actor. The reason for this is that a unwrapped message might leave the system in an inconsistent state if it's a message from an old leader. Furthermore, since not every RequiresLeaderSessionID message requires a response, it is not possible to notify the sender of the wrong message about the missing leader session ID.
ActorGateway refactoring
In order to guarantee the similar wrapping behaviour when one sends messages outside of an actor, the former InstanceGateway has been refactored to ActorGateway and all ActorRef interactions have been replaced by ActorGateway instances. Only the web server still uses ActorRefs, because it is about to be refactored anyway (see #677). However, the PR #677 should be updated accordingly.
AkkaActorGateway implements the ActorGateway and makes sure that all RequiresLeaderSessionID messages are wrapped correctly in a LeaderSessionMessage. In order to make this happen, the AkkaActorGateway is given the current leader session ID upon creation. For any actor interaction from outside of an actor, this class should be used. Using this abstraction will allow us to easily extend the decoration behaviour of messages in the future, too.
Style formatting
The PR also contains some Scala style harmonisation of old Scala code.
TL;DR
In order to support leader session IDs all Flink actors should extend FlinkUntypedActor or FlinkActor with LeaderSessionMessages and LogMessages mixins. Whenever a message is sent from within an actor, the message should be decorated by calling decorateMessage. When messages are sent from outside of an actor, the AkkaActorGateway should be used instead of directly using ActorRef. That way, we guarantee the proper wrapping of the messages.

The mechanism looks good, all in all.
Some comments:

I think it makes the code more understandable, if the decorateMessage() method would be called something like attachSession(), or so. Is the decoration used

We have decided to gradually transition the runtime to Java, as this mixture of languages is making it very clumsy in many parts. All other changes followed the pattern to add new classes only in Java. Are there principle reasons to not do this here as well? Especially by adding classes that are at the core of this new mechanism (like RequiresLeaderSessionID) in Scala, we effectively cement this language blend.

In prior refactoring, we changed it such that JobManager, TaskManager, etc do not use mixins any more. A big part of the decision were "clean logs" and Java interoperability. This patch reverts this effort. Is there any principle reason for that?

The leaderSessionID in the JobManager is constant. Can it not change over time? An example would be when a JobManager looses the ZooKeeper connection (network partition) and looses its leader status, but later comes back, and regains leader status.

Is the JobManagerGateway a temporary solution?
If I understood it correctly, in the full-fledged integration with Zookeeper, an actor that wants to send a message to the JobManager will look up both the leader Akka URL and the leader session ID from Zookeeper.

I chose to call the method decorateMessage because it not necessarily only attaches leader session IDs. In the future we might use this method for something other than just wrapping the messages in a LeaderSessionMessage. Moreover, calling it attachSession would contradict the idea of transparency here. But we can change it as long as we don't have to do any other decorations.

The trait RequiresLeaderSessionID is only a marker trait which does not contain any code. Thus, it is effectively equivalent to a Java interface and  in fact Java classes can implement it. The only reason I chose a trait instead of an interface is that all messages which are sent by the actors are implemented as Scala classes. I can change it to be an interface, however I don't think that it cements the language blend.

I agree that it's not necessary to use mixins here. The reason to implement the logging and leader session message decoration as a mixin was just the beauty of the implementation. But I forgot about the clumsy names in the log output. I will include the mixins in the class FlinkActor.

It is true that the leader session ID can change in the case of HA with ZooKeeper. However, the ZooKeeper HA is not part of this PR.

Do you mean JobManager.getJobManagerGateway? This is only a temporary solution to obtain an ActorGateway for the JobManager for which you have to know the current leader session ID. This will be changed once HA with ZooKeeper is introduced.

Addressed the following comments: Corrected order of visibility and abstract modifiers. Removed the lazy log field from FlinkActor. Now all implementing subclasses have to implement it. Made RequiresLeaderSessionID a Java interface.
All other comments haven been resolved by discussion.

Looks good. +1 to merge this...

Will rebase and then merge this PR.

Tests pass on Travis. Will merge it.


Make the Brush bindable

I'd like to change the icon color to the foreground color of the surrounding control. As the foreground color changes dynamically, I need to bind the icon brush color. Currently this is not possible. Any thoughts on this?

@audacity76 Here is an example with the MahApps Button style, but it should work also with a normal style or any other Control which can set the Foreground.
<Button Foreground="Crimson"
        Margin="10 5">
    <Button.Content>
        <iconPacks:PackIconMaterial Width="20"
                                  Height="20"
                                  Kind="Cookie" />

    </Button.Content>
</Button>

<Button Foreground="Crimson"
        Margin="10 5"
        Content="{iconPacks:Material Cookie, Width=20, Height=20}" />

Thanks for the hint. I was using the converter to bind to an image source. The color then defaults to black:
<Image DataContext="{Binding Icon}"
       Source="{Binding Converter={iconPacks:PackIconMaterialKindToImageConverter}}"
       Height="14" Width="14"/>

Simply changed it as you suggested and the color of the foreground is used:
<iconPacks:PackIconMaterial Kind="{Binding Icon}"
                            Width="14"
                            Height="14" />