100% CPU usage if TCPSocket reads data after it can't connect

Issue
This is really simple to replicate, but I'm terrible at explaining things so please bear with me.
If you run server.cr first, then run client.cr it works perfectly! CPU Usage of client.cr is 0-1%.
However, if you run client.cr first, then server.cr, it works.. except there is one catch. The CPU usage for your client.cr in top is at constant 100%, indefinitely! Even after it made the connection.
You might be wondering what's the use case? Well, I have a Master Server and if it goes down and back up, I want my game instance servers to automatically connect and authenticate themselves. It works beautifully, except this part :P
server.cr:
require "socket"

IP   = "<IP_ADDRESS>"
PORT = 9300

server = TCPServer.new(IP, PORT)
puts "Server bound on port #{IP}:#{PORT}"

def handle_connection(socket)
  puts "New connection! #{socket}"
  loop do
    payload_size = socket.read_bytes(Int32)
    message = socket.read_string(payload_size)
    puts message
  end
rescue e
  puts e
end

while socket = server.accept?
  spawn handle_connection(socket)
end

client.cr:
require "socket"

def handle_connection(socket)
  begin
    loop do
      payload_size = socket.read_bytes(Int32)
      puts payload_size
      raw_message = socket.read_string(payload_size)
      puts raw_message
    end
  rescue e
    puts "Disconnected from the Master Server"
    puts e
  end
end

def gogo
  begin
    puts "Waiting for the server to become connectable.."
    check = TCPSocket.new("<IP_ADDRESS>", 9300)
    check.tcp_nodelay = true
    puts "Successfully connected to the Master Server"
    spawn handle_connection(check)
    loop do
      sleep 1
    end
  rescue e
    puts e
  end
end

gogo()

Crystal 0.26.1 [391785249] (2018-08-27)

Try the following code @girng
Server:
require "socket"

def handle_connection(socket)
  loop do
    puts "Connected to the Client"
    socket.puts "message\n"
    puts "Message has been send"
    sleep 1
  end
rescue e
  puts "Disconnected from the Client"
  puts e
end

begin
  puts "TCPServer"
  server = TCPServer.new("<IP_ADDRESS>", 52300)
  while client = server.accept?
    spawn handle_connection(client)
  end
rescue e
  puts e
end

Client:
require "socket"

def handle_connection(socket)
  loop do
    message = socket.read_string(5)
    puts message
  end
rescue e
  puts "Disconnected from the Master Server"
  puts e
end

loop do
  begin
    check = TCPSocket.new("<IP_ADDRESS>", 52300)
    #check.tcp_nodelay = true
    puts "Successfully connected to the Master Server"
    spawn handle_connection(check)
  rescue e
    puts e
  end
  sleep 1
end

This code works great on my system without a CPU going at 100%.
Run under Ubuntu VM with a 1700x.
Tested:
Start Server / Start Client ...
Start Client / Start Server ...
Start Server / Start Client / Stop Client / Start Client ...
Start Client / Start Server / Stop Server / Start Server / Stop Server ...
All work normally here ... CPU usages goes back to 0% after all attempts.
In your code example there are several errors:

Server reads messages just like the client...
Client tries to connect to the server, if the connection fails or is disconnected, you enter the loop sleep routine and never leave this infinite loop.

Ty @bowyan unfortunately still maxes out at 100% cpu usage.

No it isn't lol

Check your htop ... green is normal CPU usage. Red is IO blocking. The code is clearly blocking on IO. And this is beside the point.
Your reported issue is that when you disconnect the server, aka kill the server, the CPU usage keeps at maximum usage. Test this out...

No it isn't lol

Check your htop ... green is normal CPU usage. Red is IO blocking. The code is clearly blocking on IO. And this is beside the point.
Your reported issue is that when you disconnect the server, aka kill the server, the CPU usage keeps at maximum usage. Test this out...

I don't mean to be rude but are u trolling? This is a serious issue and what you are saying is not true.
Here is me pinging the server every 1 second, and cpu usage is 0-1%
https://gyazo.com/b2db069e2493bdcfa86666ef28b2e5b0
socket.cr: https://paste.ee/p/f5dGG
server.cr: https://paste.ee/p/sfxCt
However, if I start client.cr first, then server.cr, cpu usage goes to 100%. That is not normal.

I don't mean to be rude but are u trolling?

Solve it yourself with that attitude.

Solve it yourself with that attitude.

Thanks for ruiining my github thread. I reduced my code example so the devs can see the issue and you posted false information about CPU usage, trying to say my code is wrong, and you did not even read my OP

Your reported issue is that when you disconnect the server, aka kill the server, the CPU usage keeps at maximum usage. Test this out...

That's not my issue at all. The issue is if I start client.cr first, then server.cr. It has nothing to do with "disconnecting the server"

require "socket"

def handle_connection(socket)
  loop do
    message = socket.read_string(5)
    puts message
  end
rescue e
  puts "Disconnected from the Master Server"
  puts e
  connect_to_server()
end

def connect_to_server
  check = TCPSocket.new("<IP_ADDRESS>", 52300)
  # check.tcp_nodelay = true
  puts "Successfully connected to the Master Server"
  handle_connection(check)
rescue e
  puts "TCPSocket disconnected"
  puts e
  sleep 2.second
  puts "TCPSocket reconnectin attempt"
  connect_to_server()
end

connect_to_server()

require "socket"

def handle_connection(socket)
  i = 0
  loop do
    puts "Connected to the Client"
    socket.puts "message\n"
    puts "Message has been send" + i.to_s
    i = i + 1
    sleep 5
  end
rescue e
  puts "Disconnected from the Client"
  puts e
end

begin
  puts "TCPServer"
  server = TCPServer.new("<IP_ADDRESS>", 52300)
  while client = server.accept?
    spawn handle_connection(client)
  end
rescue e
  puts e
end

Here is your problem solved.
Remove "sleep 5" in the server code, to flood your client connection with thousand of messages and get 100% IO blocking Cpu usage.
Under normal usage ( set a delay on the sending ). you will see almost no cpu usage.
This code also efficiently reconnects from disconnected connections. Its not going to win a beauty price but it does the job.
I hope this closes the topic... /The "Troll" is out...

Of course that's going to increase IO if I remove sleep 5. IO is not the issue because my code examples don't have an IO problem.
  loop do
    payload_size = socket.read_bytes(Int32)
    message = socket.read_string(payload_size)
    puts message
  end

Is perfectly valid Crystal code for client->server communication with TCP and works great. The issue is, if you start client.cr first and wait a second, then start server.cr.  If you start server.cr first, then client.cr it works fine. I don't know how many times I need to explain this dude :/

sigh .... this is the code you posted.
Server:
 loop do
    payload_size = socket.read_bytes(Int32)
    message = socket.read_string(payload_size)
    puts message
  end

Client:
    loop do
      payload_size = socket.read_bytes(Int32)
      puts payload_size
      raw_message = socket.read_string(payload_size)
      puts raw_message
    end

Both are trying to read from the connection with nothing being send. That is also wrong as a example issue.

The issue is, if you start client.cr first and wait a second, then start server.cr. If you start server.cr first, then client.cr it works fine.

No it does not! In both orders my code works without any issue. All you need to do is take care, that you do not end up in a infinite loop with reconnect the TCPSocket.

I don't know how many times I need to explain this dude :/

I do not know how many times i need to explain to you, the above code works with connects and disconnects without the issue that you describe.
And no offence but for somebody asking for help, all i see is constant attitude. Your accusing somebody as a troll for pointing out that something in the code is IO blocking, what it is ( it was TCPSocket Looping, that was a error on my part )!
But this new code fixes that issue and works beautifully. Connect Server, then Client, no issue. Client, then Server, no issue. CPU usage is normal. If i flood the connection with 1000s of requests per second, yes, it will hit large CPU usage as that is normal when your sending thousands of requests per second.
But it does not go into large CPU usage when the client or server get disconnected and reconnect ( unless you flood the connection, again, normal ).
Now i am suddenly your "dude". I know you are frustrated but lashing out at people only makes things worse!

No it does not! In both orders my code works without any issue. All you need to do is take care, that you do not end up in a infinite loop with reconnect the TCPSocket.

@bowyan   It still maxes out the CPU if you start client.cr first, then server.cr.

Now i am suddenly your "dude". I know you are frustrated but lashing out at people only makes things worse!

I'm not lashing at anyone. You came in here, claimed my code was wrong, said CPU utiziliaton is supposed to be 100% when communicating messages between client->server (which is not true). And made up code with actual IO issues to try to say I'm wrong. You are the one who is instigating this.

And no offence but for somebody asking for help, all i see is constant attitude. Your accusing somebody as a troll for pointing out that something in the code is IO blocking, what it is ( it was TCPSocket Looping, that was a error on my part )!

You are wrong. My code examples are not IO blocking.

Then you have some magical bug because i can start the client first, wait one second and see my cpu usage under a VM after the initial startup spike going to 0 a 2% on all 4 cores, withing a second and staying like this.
Start server with flood: 60 a 70% core 1, 20% on core 2 .. ( mostly from the put messages being pushed to the CLI ). Stop server ... Client goes into search mode for the server and going to 0 a 2% on all 4 cores.
Aka exactly how it needs to work. In other words, if you are running my exact same code as posted above and you have the issue that you mention about, then the issue is on your setup. Older Crystal? WSL? LLVM issue? ...

You are wrong. My code examples are not IO blocking.

I give up, no reasoning with you ...
/Crystal moderators, please remove my posts from this topic.

I give up, no reasoning with you ...

See edit. Not IO blocking to warrant 100% CPU usage, that you claimed.

Both are trying to read from the connection with nothing being send. That is also wrong as a example issue.

That doesn't mean it goes to 100% CPU usage. I was just not sending anything, because I wanted to reduce my code example  as much as  possible. If you check my previous post, CPU usage is 0-1%, even when sending a ping per second while using that code.
It's not "wrong as an example issue". It's perfect, and shows the issue very clearly.

Please keep it civil, personal accusations have no place in the crystal community.

Also, I can't reproduce.
crystal client.cr immediately fails if server.cr is not started. This makes sense because there is no retry logic if TCPSocket.new fails.

@girng sending ping per second sounds way less than sending it as fast as possible, just thinking out loud...

I am not sending anything as fast as possible in my examples..
I am about done here.

Will reboot (and edit this post when I'm back, ty)

@RX14 Okay, I tried it after a reboot, same results: (client.cr on right, server.cr on left)
https://i.gyazo.com/029417fb0019ec695b7a5b30e4e53067.mp4
It hangs, then connects to the server.cr when it starts up, but remains at 100% CPU usage. But, if server.cr is started before  client.cr connects and cpu usage goes down.

I literally have done nothing wrong, but getting mass accusations about stuff that my code doesn't even do. [...]

@girng Chill out, please. As I see it, this ain't about right or wrong, more about the attitude of approaching the problem. No one here accuses you or your code of anything, we all are just trying to find out the root source of the problem. Misunderstandings and differents PoV are quite common thing, no need to get personal about it...

No it isn't lol

I don't believe my code example above has any errors (to show this example)

I don't mean to be rude but are u trolling? This is a serious issue and what you are saying is not true.

Thanks for ruining my github thread. I reduced my code example so the devs can see the issue and you posted false information about CPU usage, trying to say my code is wrong, and you did not even read my OP

I am about done here. This is getting ridiculous.

All of the above quotes seem to me quite personal and inappropriate, especially towards someone who tries to help you - even if there's lack of understanding the problem, from one side or the other.

@girng Chill out, please. As I see it, this ain't about right or wrong, more about the attitude of approaching the problem. No one here accuses you or your code of anything, we all are just trying to find out the root source of the problem. Misunderstandings and differents PoV are quite common thing, no need to get personal about it...

Put yourself in my shoes. I'm not the one going around accusing other people their code is wrong, and making up code to say my code has an IO issue when it's not even related at all. I tried to keep my code reduced and simple for the developers to take a look at. Then you are saying I'm sending data non-stop, which is not true and my code does not even do that. You guys are passively trying to put me down and put fault on me, when it's not my fault at all.

@Sija this post is probably best sent in private. Please keep this thread technical only.

@girng are you sure the code you're running is the exact same as the code in the OP? This is what I get when I run client.cr without server.cr running.

@RX14 Yep, 100%.
https://i.gyazo.com/7aa23bb1c2b0fda6f6fe96be7b4f39bd.mp4

@girng well it must be some kind of WSL bug then because that's absolutely not how TCP should behave.

By the way, I feel very disincentivized to make another bug report here again. Just re-reading this issue really makes my heart sink.   It's just sad, no reason to treat people like this who are reporting a legitimate and valid issue they are experiencing. I appreciate RX14's help though, at least he understands where I'm coming from instead of creating false accusations and trying to put me down

@girng this still isn't the place or time, but I'd say that you shouldn't take the actions of a single community member as representative of the whole issue tracker.


List same page multiple times in sidenav

Currently, if you list the same page in multiple sections of the sidenav, both sections expand. We should figure out how to make just the immediate section expand.

We'll look at overall info architecture in Q2/Q3, which will supercede this issue.


Integrate WASM with Scala CLI

Is your feature request related to a problem? Please describe.
We currently support emitting Wasm via Scala.js, but we do not yet integrate it with Scala CLI features.
Describe the solution you'd like
I'd like to be able to run Scala code with Wasm directly from Scala CLI.
Additionally, I'd like to be able to choose a runtime and let Scala CLI download it for me.
Unsure which runtimes should be supported, + we should likely have a default.

[ ] support running Wasm from Scala CLI

[ ] a CLI flag --wasm
[ ] a corresponding directive, likely a wasm param for the platform directive

[ ] allow to pick a Wasm runtime + have a default

[ ] command line option
[ ] directive

[ ] consider Wasm for other Scala CLI features (likely out of scope) and create follow-up issues

Additional context

initial support for WASM: #3213

cc @sjrd @tanishiking

Note that currently, the Wasm support of Scala.js always emits JS+Wasm files. So you need a JS runtime to run it, like the existing Scala.js-on-JS.
In addition, one may need to provide specific flags to the engine, in order to enable experimental Wasm features that Scala.js-on-Wasm needs. See https://www.scala-js.org/doc/project/webassembly.html

It would be nice to have this, then can use it in https://github.com/bddicken/languages :)


⚠ ClamAV has degraded performance

In e143be0, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 718 ms

Resolved: ClamAV performance has improved in b9e0fcc.


CI: run tests on cp312

@aglavic, can you have a look at this? The orsopy test suite doesn't run on cp312.

@aglavic, can you have a look at this test fail? The orsopy test suite doesn't run on cp312. In general it seems quite fragile to use private methods of a package that can be subject to churn.

I'll have a look. I think this hack was necessary to allow having the comment attribute for derived Orso classes or something about the right yaml generation. I'll have to check and probably improve the comments to explain why this is necessary.
I remember that I didn't like going into the deep guts of dataclass but didn't see an alternative solution at that time.


[OMID-102] Support for user Filter when using coprocessor for snapshot filtering

This is great, @yonigottesman! Do the Phoenix unit tests FlappingTransactionIT.testInflightUpdateNotSeen() and testInflightDeleteNotSeen() pass with this change? You can try running them from the omid2 feature branch.

Nice work, @yonigottesman. I made a few minor comments, @ohadshacham. My main question is do the Phoenix unit tests FlappingTransactionIT.testInflightUpdateNotSeen() and testInflightDeleteNotSeen() pass with this change? You can try running them from the omid2 feature branch in Phoenix against the phoenix-integration branch in omid2 with your patch applied.

All FlappingTransactionIT tests pass


Button in (disabled) link causes navigation.

🐛 Bug Report

🤔 Expected Behavior
When a button is pressed inside an anchor only the button should fire and not the surrounding link.

😯 Current Behavior
When a button is pressed inside an anchor tag it causes the browser to navigate to the provided href. Even when this anchor is disabled. This seems like default browser behavior for which I dont understand the use case.
It's rather easy to circumvent this behavior by preventing default in onClick on the nested button but this gives a deprecation warning.
onClick is deprecated, please use onPress
Another solution is to wrap the onClick handler prop from useButton and prevent default there. Problem is that every button needs some context aware code (am I in a anchor tag wrap with....).
function tweakClick(onClick) {
  const prevClick = onClick;

  // almost the same as in usePress onClick
  return function (event) {
    if (event && !event.currentTarget.contains(event.target)) {
      return;
    }

    if (event && event.button === 0) {
      event.preventDefault();
      prevClick(event);
    }
  };
}

💁 Possible Solution

usePress only prevents default for onClick on isDisabled right now. Why is this not the default? Since onMouseDown also does this.
🔦 Context
Maybe it's a big nono to put buttons in anchors but in this use case it's a list item that navigates to a specific route and it also has a button that pops out a context menu with some actions. So now when a user clicks the context menu button they are routed away instead of only opening the menu.

💻 Code Sample
https://codesandbox.io/s/react-aria-linking-u0kdb?file=/src/App.js

🌍 Your Environment

Software
Version(s)

react-spectrum
-

react-aria
3.9.0

Browser
Chrome (92.0.4515.159 (64-bit)), Firefox (91.0.1 (64-bit))

Operating System
Windows

🧢 Your Company/Team

🕷 Tracking Issue (optional)

You are correct, a link with a button inside is a big accessibility no-no.
Depending on the list implementation it's also a big no no to put an interactive element such as a button inside any list item.
You could use a table?

 It's also not valid html.
Depending on the list implementation it's also a big no no to put an interactive element such as a button inside any list item.
You could use a table?

Ah indeed it's not even valid html 🤦♂ . I will try to find some other solution. Thank you for the fast response.


New workflow for creating release branches

New workflow only for creating release branches off of already existing release branches. This is intended only to use when master is on a different minor branch then the one we are currently using. This will be needed for new 4.x minors while 5.0 is currently in development.
Related issue: https://github.com/iTwin/itwinjs-backlog/issues/1316

This commit  on branch TEST/0.0x is an example of what we would see when running this off of a release branch. Branch TEST/0.0.x was auto created by this pipeline, so that value represents what will be a normal release branch ex. release/4.12.x.
Here  is the workflow run that performed this.
Slight differences from my test and what would actually take place:

as mentioned this was triggered by my PR. Normally this should be triggered manually, but GH does not seem to allow manual triggers for workflows that do not exist on master.
I hard coded values for the branch name TEST/0.0.x as an env var. This should really be an input var set under workflow_dispatch. This is very similar to parameters that we set on run time for ADO.
this was ran off of a branch based on master. So this commit might look a little different compared to when running off of a release branch. However, I believe it should look mostly the same, and the logic still all holds true.


Use "/usr/local" as default prefix for "make install"

Conventional filesystem standards imply that /usr prefix should be used only by system package managers. Custom installations should go to /usr/local by default. However, on Linux machines make install installs to /usr, messing with package manager installations. Let's install to /usr/local/ everywhere.
However, we should keep /usr prefix for packaging, therefore override the default for deb and rpm targets.

How this will affect current users that have Themis installed in /usr?

Good question...
Assuming these are users that install from source code, I can see make uninstall breaking if they wish to use newer version to uninstall the previous one. The users will have to explicitly set PREFIX=/usr to uninstall the previous version from correct path.
Similarly, if Themis 0.11 is installed to /usr (by current default) then installing Themis 0.12 to /usr/local will not overwrite the previous install (as it is now). Instead, Themis 0.12 will be installed alongside Themis 0.11. Usually /usr/local takes precedence over /usr, so effectively Themis 0.12 should be used. But that depends on the software, and it may break in case of misconfiguration. In particular, Themis libraries do not have versions embedded into them so the software can load a wrong library.
Overall, I feel that we will have to ask those users who install from source to cleanly uninstall previous version of Themis using previous source code, and then install an upgrade using the new source code.
Alternatively, I think we could detect whether Themis is already installed to /usr and not managed by package manager. If so then we keep using the old prefix, otherwise default to /usr/local (unless the user explicitly sets something). Together with that we could urge users to switch to the new default and eventually drop the special case.

@vixentael I've pushed a commit that implements the backwards compatibility behavior described in the previous commit.
With that, on systems that do not have Themis installed (yet) we'll be using the new /usr/local prefix. However, if the system already has Themis manually installed to /usr (not by the package manager) then we'll keep using /usr. If the user explicitly specifies the prefix then we'll be using that instead.

I'd avoid to set path automatically. How about next behavour:

if we detected themis installed in path differ from /usr/local, but included into ldconfig, then stop with special error code (differ than default ones);
add environment variable, for example THEMIS_ALLOW_MULTIPLE_INSTALLS that allows to install even when previous installation detected.

@shadinua, well, that's a reasonable approach as well. Though, I feel that installing a local version to /usr/local in parallel with system version in /usr will be quite often used by developers for local testing, so I don't think that we should make it more annoying. We can't account for all the conflicts that are possible by multiple installations.
Ideally, I'd avoid doing all this guesswork altogether (as it's bound to fail for someone, human perversion has no limits). If you install Themis from source then well, do manage your versions yourself if you insist on not using any sort of package manager.

I've added one more convenience for the users: now we print the installation prefix so the users know where Themis has been installed to or removed from.
Now, what should we do about multiple installations and upgrades?

Decline this PR. Keep installation paths as is.
Pro: users can continue being blissfully ignorant of where they install stuff.
Con: sudo make install on a system with installed packages overwrites the packages.

Accept current PR. Prefer /usr/local, unless there is an existing installation in /usr.
Pro: users can still be somewhat ignorant.
Pro: we won't overwrite package manager installations anymore.
Con: complicates installation, endorses bad behavior.

Revert guesswork, follow @shadinua. Deny multiple installations, unless asked to.
Pro: not taking chances, fail early if we detect a conflict.
Pro: still allows multiple installs if needed.
Con: complicates installation, has to be documented.

Revert guesswork. Just install to /usr/local from now on.
Pro: dead simple.
Con: previous installation to /usr has to be manually removed.

Any other options out there?

@vixentael?
As for paths, I believe that we'd run into conflicts either way if we ever going to fix the mismatch on CentOS (libraries should go to /usr/lib64, not /usr/lib). For that we will have to ask the users to cleanly remove their previous installation of Themis and install the new version from scratch. That gives us freedom to change the new installation path however we like.

Though, I feel that installing a local version to /usr/local in parallel with system version in /usr will be quite often used by developers for local testing, so I don't think that we should make it more annoying.
By default /usr/local/lib is included to ldconfig search paths of most distributives. Thus in case when we have different versions of library that installed simultaneously in /usr/lib and /usr/local/lib, it will change behaviour anyway. I wouldn't like to think that installing the new version of the library for development purposes while we changing behaviour of whole system is the right way. Isn't it better to put the library in the project folder?

Ideally, I'd avoid doing all this guesswork altogether ...
I completely agree. That is why I'd suggest to choose one of standard, predictable and simple variants to solve this issue.

Isn't it better to put the library in the project folder?

This is involves much more hassle than make install. You have to get Themis to your project directory, setup all lookup paths in your project, etc. I don't really imagine people using make install for that. I'd personally would just copy binaries out of build directory if I don't want to keep Themis installed in my system.

By default /usr/local/lib is included to ldconfig search paths of most distributives. Thus in case when we have different versions of library that installed simultaneously in /usr/lib and /usr/local/lib, it will change behaviour anyway.

Yeah, that's exactly the point. Imagine you're using PyThemis and there's some bug in the core library. Your core library is installed from package repositories. However, you are able to grab the latest source code, sudo make install it, check whether the bug is fixed for you (without having to fiddle with Python library lookup), and then sudo make uninstall everything back. And the system-managed installation of Themis is kept intact.

Another common approach is system-wide installation to /opt, when you do make install PREFIX=/opt/themis-0.11 and configure multiple projects to use the same installation. I believe we should allow such installations without any additional required flags and variables, regardless of whatever is or is not installed in /usr and /usr/local.
I think that we can keep it simple by installing to specified prefix if it is explicitly requested by the user. If they request it, they have their reasons and did their homework.

Yeah, that's exactly the point. Imagine you're using PyThemis and there's some bug in the core library. Your core library is installed from package repositories. ...

 For some of them, this is an advantage. For some — a disadvantage. These libraries can be installed not only on the developers' machines, where changing in the behaviour of the whole system is normal.
In the proposed variant, parallel installation of the library using make install is absolutely possible. Howeve, in my opinion, for responsible libraries, such as Themis, it is better to be sure that the user is consciously doing this.

Well. I'll not insist on that behaviour. I'd prefer to have Makefile without any extended logic inside.
Let's choose variant #4. But we have to implement CentOS detection to set correct paths.

Let's choose variant #4. But we have to implement CentOS detection to set correct paths.

With this option I would feel better if we notify user that installation path was changed. For example, if we detect that Themis is already installed in /usr, we can write a warning log message after successful installation ~ "Multiple Themis installation found. If you didn't do it intentionally consider removing old versions."

@shadinua @vixentael I have reverted the 'AI-commit' and added a simple check with a warning if we detect Themis in both /usr and /usr/local simultaneously, suggesting to remove the (presumed) old installation from /usr and keep installations by make install in /usr/local.


manifest and service worker files aren't automatically generating on build (react)

I'm trying to convert an existing vite react app to PWA but when I build the manifest and sw files are being automatically generated in dist
vite.config.jsx:
import {defineConfig} from 'vite'
import react from '@vitejs/plugin-react'
import {VitePWA} from "vite-plugin-pwa";

export default defineConfig({
    plugins: [
        react(),
        VitePWA({
            registerType: 'autoUpdate',
            injectRegister: 'inline',
            manifest: {
                name: 'My Awesome App',
                short_name: 'MyApp',
                description: 'My Awesome App description',
                theme_color: '#ffffff',
                icons: [
                    {
                        src: './src/assets/react.svg',
                        sizes: '192x192',
                        type: 'svg'
                    },
                    {
                        src: './src/assets/react.svg',
                        sizes: '512x512',
                        type: 'svg'
                    }
                ]
            }
        }),
    ],
})

package.json:
{
  "name": "project",
  "private": true,
  "version": "0.0.0",
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  },
  "dependencies": {
    "@emotion/react": "^11.10.8",
    "@emotion/styled": "^11.10.8",
    "@mui/icons-material": "^5.11.16",
    "@mui/lab": "^5.0.0-alpha.129",
    "@mui/material": "^5.12.3",
    "@mui/x-data-grid-premium": "^6.3.0",
    "@mui/x-date-pickers": "^6.3.0",
    "@react-spring/web": "^9.7.2",
    "@use-gesture/react": "^10.2.26",
    "axios": "^1.4.0",
    "date-fns": "^2.30.0",
    "html2canvas": "^1.4.1",
    "leaflet": "^1.9.3",
    "lodash": "^4.17.21",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "react-leaflet": "^4.2.1",
    "react-router-dom": "^6.11.0",
    "recharts": "^2.5.0"
  },
  "devDependencies": {
    "@types/react": "^18.0.28",
    "@types/react-dom": "^18.0.11",
    "@vitejs/plugin-react": "^3.1.0",
    "vite": "^4.2.0",
    "vite-plugin-pwa": "^0.16.3"
  }
}

Output when I build
vite v4.3.9 building for production...
✓ 13763 modules transformed.
dist/index.html                                              0.72 kB │ gzip:   0.45 kB
dist/assets/Logo-green-black-146caedc.svg           5.70 kB │ gzip:   2.00 kB
dist/assets/Logo-purple-black-1b7e0306.svg          6.00 kB │ gzip:   2.03 kB
dist/assets/SpaceGrotesk-VariableFont_wght-e13b56b9.ttf    134.11 kB
dist/assets/index-60002d85.css                               0.76 kB │ gzip:   0.47 kB
dist/assets/exceljs.min-1552016b.js                      1,156.66 kB │ gzip: 290.84 kB
dist/assets/index-565fc476.js                            2,104.44 kB │ gzip: 612.66 kB

(!) Some chunks are larger than 500 kBs after minification. Consider:
- Using dynamic import() to code-split the application
- Use build.rollupOptions.output.manualChunks to improve chunking: https://rollupjs.org/configuration-options/#output-manualchunks
- Adjust chunk size limit for this warning via build.chunkSizeWarningLimit.
✓ built in 12.66s

I've also tried passing the minimum VitePWA({ registerType: 'autoUpdate' }) as written in the docs too.  I thought at this base level it should be generated?  Sorry I can't see what I am missing

Ok found the problem.  After transferring some a lot of react files from a create-react-app project, I did a lot of renaming from *.js -> *.jsx.  In the process  also renamed vite.config.js to vite.config.jsx.  Switched it back and now the files are generating on build


Extension service list

Further addition of four client services from the MWDI.  Used to derive link aggregation and WAN/LAN Port Roles.

Services were reviewed


There is a Persistent Cross-Site Scripting in the member contributions.

Vulnerability found in Eyoucms1.4.6 and before.
In the member center member contribution office, after editing the contribution content through the editor, intercept the data package, modify the parameter addonfieldext [content], and construct the payload "< img SRC = 1 onerror = alert（ document.cookie )>”

After the administrator logs in the background, when viewing the content submitted by the user, it triggers the payload to obtain the cookie information.

已修复


Fix #42: RoqObjectMapperBuildItem

Fix #42: RoqObjectMapperBuildItem
I am not sure I got this right and its definitely not as full featured as the Jackson module.
Should I just use the quarkus jackson config item instead of creating my own?

Yeah i wasn't sure the best approach?  Also I didn't actually replace the ObjectMapper() in roq-data i wasn't quite sure how to do that so i thought @mcruzdev would be able to do that after this PR is in.

I removed all the "writable" configs so on deserialization configs.


pretrain directory

Do I have to create the pretrain/ directory in the root directory of spc2 by myself to put the downloaded pretrained weights?

Yes. And BTW, the pretrained weights have been updated to fix some key naming incompatibility issues.


add import of Nb for ease copy/pasting from examples

mainly suggesting to add the import in the hello world so when you try copypaste from examples it works without having to locate the import.

good idea thanks


envoy stuck initializing cluster after we updated to 6ea29c7

Since we synced with 6ea29c7, we are seeing that Envoy never finishes initializing clusters that depend on SDS. E.g.:
[2019-06-12 20:46:45.051][17][debug][upstream] [external/envoy/source/common/upstream/cluster_manager_impl.cc:74] cm init: adding: cluster=foo primary=1 secondary=17

but something like:
[2019-06-12 20:46:45.246][17][debug][upstream] [external/envoy/source/common/upstream/cluster_manager_impl.cc:102] cm init: init complete: cluster=foo primary=0 secondary=18

never happens. The TLS context for the foo cluster looks like this:
    "tls_context": {
      "common_tls_context": {
        "tls_certificate_sds_secret_configs": [
          {
            "name": "foo_certificate_chain",
            "sds_config": {
              "api_config_source": {
                "api_type": "GRPC",
                "grpc_services": [
                  {
                    "envoy_grpc": {
                      "cluster_name": "local_sds"
                    }
                  }
                ]
              }
            }
          }
        ],
        "validation_context_sds_secret_config": {
          "name": "foo_root_ca",
          "sds_config": {
            "api_config_source": {
              "api_type": "GRPC",
              "grpc_services": [
                {
                  "envoy_grpc": {
                    "cluster_name": "local_sds"
                  }
                }
              ]
            }
          }
        }
      }
    },

cc: @fishcakez

cc @htuch @fredlas

Err, sorry for the confusion but #7200 is actually newer. I'll look around a bit more.

Hmm a bit suspicious about #6525 now, given that we use gRPC to talk to our SDS sidecar.

Hmm, taking a closer look this morning it seems to be between these changes:
https://github.com/envoyproxy/envoy/compare/9d47062517cf9d728d0c09246ebdcb1111449c6a...6ea29c7475652e1ff9bb035dfb9a5bad7de1f4c3
Bisecting now.

I would potentially suspect https://github.com/envoyproxy/envoy/commit/1e34a2e29cdb33cb9e9d089c775caad0e3b5e2ba

@mattklein123 literally just reverted it and trying that :-)

stay tuned.

Alas, 1e34a2e wasn't the problem. Still stuck at:
[2019-06-13 16:23:59.650][18][info][upstream] [external/envoy/source/common/upstream/cluster_manager_impl.cc:123] cm init: initializing secondary clusters

Hmm what's going on here:
Thread 7 (LWP 32616):
#0  0x00007fb41b1504d9 in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
#1  0x000000000103d719 in absl::synchronization_internal::Futex::WaitUntil (t=..., val=0, v=0x7fb41bf3f150) at external/com_google_absl/absl/synchronization/internal/waiter.cc:106
#2  absl::synchronization_internal::Waiter::Wait (this=this@entry=0x7fb41bf3f150, <EMAIL_ADDRESS>at external/com_google_absl/absl/synchronization/internal/waiter.cc:143
#3  0x000000000103d5c2 in AbslInternalPerThreadSemWait<EMAIL_ADDRESS>at external/com_google_absl/absl/synchronization/internal/per_thread_sem.cc:87
#4  0x000000000103d1e0 in absl::synchronization_internal::PerThreadSem::Wait (t=...) at external/com_google_absl/absl/synchronization/internal/per_thread_sem.h:105
#5  absl::Mutex::DecrementSynchSem (mu=0x3bda380, w=<optimized out>, t=...) at external/com_google_absl/absl/synchronization/mutex.cc:562
#6  absl::CondVar::WaitCommon (this=this@entry=0x3bda390, mutex=mutex@entry=0x3bda380, <EMAIL_ADDRESS>at external/com_google_absl/absl/synchronization/mutex.cc:2534
#7  0x000000000103d2cc in absl::CondVar::Wait (this=this@entry=0x3bda390, mu=mu@entry=0x3bda380) at external/com_google_absl/absl/synchronization/mutex.cc:2569
#8  0x00000000009631c3 in Envoy::Thread::CondVar::wait (mutex=..., this=0x3bda390) at bazel-out/k8-opt/bin/external/envoy/source/common/common/_virtual_includes/thread_lib/common/common/thread.h:56
#9  Envoy::AccessLog::AccessLogFileImpl::flushThreadFunc (this=0x3bda350) at external/envoy/source/common/access_log/access_log_manager_impl.cc:116
#10 0x0000000000ef3f65 in std::function<void ()>::operator()() const (this=<optimized out>) at /usr/include/c++/7/bits/std_function.h:706
#11 Envoy::Thread::ThreadImplPosix::<lambda(void*)>::operator() (__closure=0x0, arg=<optimized out>) at external/envoy/source/common/common/posix/thread_impl.cc:39
#12 Envoy::Thread::ThreadImplPosix::<lambda(void*)>::_FUN(void *) () at external/envoy/source/common/common/posix/thread_impl.cc:41
#13 0x00007fb41b7296ba in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#14 0x00007fb41b15641d in clone () from target:/lib/x86_64-linux-gnu/libc.so.6

Thread 6 (LWP 32615):
#0  0x00007fb41b156a13 in epoll_wait () from target:/lib/x86_64-linux-gnu/libc.so.6
#1  0x0000000000cc1f7a in epoll_dispatch (base=0x3d51340, tv=<optimized out>) at /build/tmp/_bazel_bazel/b570b5ccd0454dc9af9f65ab1833764d/execroot/envoy/external/com_github_libevent_libevent/epoll.c:465
#2  0x0000000000cbbd7e in event_base_loop (base=0x3d51340, flags=<optimized out>)
    at /build/tmp/_bazel_bazel/b570b5ccd0454dc9af9f65ab1833764d/execroot/envoy/external/com_github_libevent_libevent/event.c:2019
#3  0x0000000000976185 in Envoy::Event::LibeventScheduler::run (this=this@entry=0x3d535a8, mode=mode@entry=Envoy::Event::Dispatcher::RunType::RunUntilExit)
    at external/envoy/source/common/event/libevent_scheduler.cc:47
#4  0x000000000096479a in Envoy::Event::DispatcherImpl::run (this=0x3d53560, type=Envoy::Event::Dispatcher::RunType::RunUntilExit) at external/envoy/source/common/event/dispatcher_impl.cc:178
#5  0x0000000000ef3f65 in std::function<void ()>::operator()() const (this=<optimized out>) at /usr/include/c++/7/bits/std_function.h:706
#6  Envoy::Thread::ThreadImplPosix::<lambda(void*)>::operator() (__closure=0x0, arg=<optimized out>) at external/envoy/source/common/common/posix/thread_impl.cc:39
#7  Envoy::Thread::ThreadImplPosix::<lambda(void*)>::_FUN(void *) () at external/envoy/source/common/common/posix/thread_impl.cc:41
#8  0x00007fb41b7296ba in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#9  0x00007fb41b15641d in clone () from target:/lib/x86_64-linux-gnu/libc.so.6

Thread 5 (LWP 32614):
#0  0x00007fb41b156a13 in epoll_wait () from target:/lib/x86_64-linux-gnu/libc.so.6
#1  0x0000000000a90868 in pollable_epoll (deadline=<optimized out>, p=0x3b24000) at external/com_github_grpc_grpc/src/core/lib/iomgr/ev_epollex_linux.cc:956
#2  pollset_work (pollset=0x3cd1108, worker_hdl=<optimized out>, deadline=<optimized out>) at external/com_github_grpc_grpc/src/core/lib/iomgr/ev_epollex_linux.cc:1144
#3  0x0000000000a7045a in cq_next (cq=0x3cd1040, deadline=..., reserved=<optimized out>) at external/com_github_grpc_grpc/src/core/lib/surface/completion_queue.cc:1040
#4  0x00000000009e4481 in grpc_impl::CompletionQueue::AsyncNextInternal (this=this@entry=0x3d16d98, tag=tag@entry=0x7fb4198372e8, ok=ok@entry=0x7fb4198372e7, deadline=...)
    at external/com_github_grpc_grpc/src/cpp/common/completion_queue_cc.cc:48
#5  0x00000000009d8fd1 in grpc_impl::CompletionQueue::Next (ok=0x7fb4198372e7, tag=0x7fb4198372e8, this=0x3d16d98) at external/com_github_grpc_grpc/include/grpcpp/impl/codegen/completion_queue_impl.h:179
#6  Envoy::Grpc::GoogleAsyncClientThreadLocal::completionThread (this=0x3d16d90) at external/envoy/source/common/grpc/google_async_client_impl.cc:46
#7  0x0000000000ef3f65 in std::function<void ()>::operator()() const (this=<optimized out>) at /usr/include/c++/7/bits/std_function.h:706
#8  Envoy::Thread::ThreadImplPosix::<lambda(void*)>::operator() (__closure=0x0, arg=<optimized out>) at external/envoy/source/common/common/posix/thread_impl.cc:39
#9  Envoy::Thread::ThreadImplPosix::<lambda(void*)>::_FUN(void *) () at external/envoy/source/common/common/posix/thread_impl.cc:41
#10 0x00007fb41b7296ba in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#11 0x00007fb41b15641d in clone () from target:/lib/x86_64-linux-gnu/libc.so.6

Thread 4 (LWP 32613):
#0  0x00007fb41b72f709 in pthread_cond_timedwait@@GLIBC_2.3.2 () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x0000000000a9e41f in gpr_cv_wait (cv=cv@entry=0x15fa300 <g_cv_wait>, mu=mu@entry=0x15fa340 <_ZL4g_mu>, abs_deadline=...) at external/com_github_grpc_grpc/src/core/lib/gpr/sync_posix.cc:233
#2  0x0000000000a7fb41 in wait_until (next=<optimized out>) at external/com_github_grpc_grpc/src/core/lib/iomgr/timer_manager.cc:211
#3  timer_main_loop () at external/com_github_grpc_grpc/src/core/lib/iomgr/timer_manager.cc:265
#4  timer_thread (completed_thread_ptr=0x3b72140) at external/com_github_grpc_grpc/src/core/lib/iomgr/timer_manager.cc:294
#5  0x0000000000a9ce1a in grpc_core::(anonymous namespace)::ThreadInternalsPosix::<lambda(void*)>::operator() (__closure=0x0, v=<optimized out>)
    at external/com_github_grpc_grpc/src/core/lib/gprpp/thd_posix.cc:114
#6  grpc_core::(anonymous namespace)::ThreadInternalsPosix::<lambda(void*)>::_FUN(void *) () at external/com_github_grpc_grpc/src/core/lib/gprpp/thd_posix.cc:119
#7  0x00007fb41b7296ba in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#8  0x00007fb41b15641d in clone () from target:/lib/x86_64-linux-gnu/libc.so.6

Thread 3 (LWP 32612):
#0  0x00007fb41b72f360 in pthread_cond_wait@@GLIBC_2.3.2 () from target:/lib/x86_64-linux-gnu/libpthread.so.0
--Type <RET> for more, q to quit, c to continue without paging--
#1  0x0000000000a9e3c7 in gpr_cv_wait (cv=cv@entry=0x3bdf038, mu=mu@entry=0x3bdf000, abs_deadline=...) at external/com_github_grpc_grpc/src/core/lib/gpr/sync_posix.cc:217
#2  0x0000000000a8af87 in grpc_core::Executor::ThreadMain (arg=0x3bdf000) at external/com_github_grpc_grpc/src/core/lib/iomgr/executor.cc:245
#3  0x0000000000a9ce1a in grpc_core::(anonymous namespace)::ThreadInternalsPosix::<lambda(void*)>::operator() (__closure=0x0, v=<optimized out>)
    at external/com_github_grpc_grpc/src/core/lib/gprpp/thd_posix.cc:114
#4  grpc_core::(anonymous namespace)::ThreadInternalsPosix::<lambda(void*)>::_FUN(void *) () at external/com_github_grpc_grpc/src/core/lib/gprpp/thd_posix.cc:119
#5  0x00007fb41b7296ba in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#6  0x00007fb41b15641d in clone () from target:/lib/x86_64-linux-gnu/libc.so.6

Thread 2 (LWP 32611):
#0  0x00007fb41b72f360 in pthread_cond_wait@@GLIBC_2.3.2 () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x0000000000a9e3c7 in gpr_cv_wait (cv=cv@entry=0x3bdc038, mu=mu@entry=0x3bdc000, abs_deadline=...) at external/com_github_grpc_grpc/src/core/lib/gpr/sync_posix.cc:217
#2  0x0000000000a8af87 in grpc_core::Executor::ThreadMain (arg=0x3bdc000) at external/com_github_grpc_grpc/src/core/lib/iomgr/executor.cc:245
#3  0x0000000000a9ce1a in grpc_core::(anonymous namespace)::ThreadInternalsPosix::<lambda(void*)>::operator() (__closure=0x0, v=<optimized out>)
    at external/com_github_grpc_grpc/src/core/lib/gprpp/thd_posix.cc:114
#4  grpc_core::(anonymous namespace)::ThreadInternalsPosix::<lambda(void*)>::_FUN(void *) () at external/com_github_grpc_grpc/src/core/lib/gprpp/thd_posix.cc:119
#5  0x00007fb41b7296ba in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#6  0x00007fb41b15641d in clone () from target:/lib/x86_64-linux-gnu/libc.so.6

Thread 1 (LWP 32609):
#0  0x00007fb41b156a13 in epoll_wait () from target:/lib/x86_64-linux-gnu/libc.so.6
#1  0x0000000000cc1f7a in epoll_dispatch (base=0x3b642c0, tv=<optimized out>) at /build/tmp/_bazel_bazel/b570b5ccd0454dc9af9f65ab1833764d/execroot/envoy/external/com_github_libevent_libevent/epoll.c:465
#2  0x0000000000cbbd7e in event_base_loop (base=0x3b642c0, flags=<optimized out>)
    at /build/tmp/_bazel_bazel/b570b5ccd0454dc9af9f65ab1833764d/execroot/envoy/external/com_github_libevent_libevent/event.c:2019
#3  0x0000000000976185 in Envoy::Event::LibeventScheduler::run (this=this@entry=0x3b1b008, mode=mode@entry=Envoy::Event::Dispatcher::RunType::Block)
    at external/envoy/source/common/event/libevent_scheduler.cc:47
#4  0x000000000096479a in Envoy::Event::DispatcherImpl::run (this=0x3b1afc0, type=Envoy::Event::Dispatcher::RunType::Block) at external/envoy/source/common/event/dispatcher_impl.cc:178
#5  0x000000000091e324 in Envoy::Server::InstanceImpl::run (this=0x3beb800) at external/envoy/source/server/server.cc:491
#6  0x00000000004bd054 in Envoy::MainCommonBase::run (this=this@entry=0x3b3f6f0) at external/envoy/source/exe/main_common.cc:102
#7  0x0000000000422103 in Envoy::MainCommon::run (this=<optimized out>) at bazel-out/k8-opt/bin/external/envoy/source/exe/_virtual_includes/envoy_main_common_lib/exe/main_common.h:91
#8  main (argc=17, argv=0x7ffd5e72b998) at external/envoy/source/exe/main.cc:39

Ok, definitely related to our tls_context. I remove it, it starts without a problem. So might be something in our setup and not an upstream thing.

So the issue gets triggered by running two instances of our sds sidecar [unclear why this is bad in itself, but reverting fixes it].
I leaving this open, since there might be room for improving how Envoy handles a misbehaving sds cluster/instance.

Turns out, the problem was our sds service was returning incorrect secrets to Envoy, which Envoy would ignore and request again. Envoy would then block setting up clusters/listeners until it got a secret response it expected. Since this never happened, Envoy would block forever...
Sorry for the false alarm.


119 create basic threejs 3d component

added a basic threejs component to the Crops3dView
There are probably some things, which are not correct in terms of ts or composition api (for example the excessive use of the any type)
would be cool if you could have a look on how to improve the code

somehow building the proto files fails

@lniehaus Who is responsible for this build?

@lniehaus Who is responsible for this build?

I am not sure since i did not change any build related files. I created this branch out of dev with the Issue "new branch" function you showed me.
For me it seems like the build in dev might not work as well but i am unsure on how to test the build Pipeline in dev. Maybe @Anafabula or @jarkenau can help.

The grpcio-tools package is missing, but I'm not sure why :thinking:

The pull request was pointed at the main branch, so it pulled the docker container from the main branch, which doesn't have grpcio_tools

The pull request was pointed at the main branch, so it pulled the docker container from the main branch, which doesn't have grpcio_tools

Ah yeah, you are right. So it is not the branch which is broken but the "PR config" is? So restarting with the new "PR config" should do the trick.

The pull request was pointed at the main branch, so it pulled the docker container from the main branch, which doesn't have grpcio_tools

Ah yeah, you are right. So it is not the branch which is broken but the "PR config" is? So restarting with the new "PR config" should do the trick.

I tried it but he does not seem to recognize to get the docker container from dev

hmm.. something strange happened. So I can validate your theory by creating a duplicated PR with the same code but a differently named branch. The PR was directly pointed to dev (instead of main, which then was changed to dev like I did in this PR). The build did complete successfully. But strangely now this PR builds successfully as well. It seems like github recognized to update the "PR config" and build this PR with the dev container.


literalExpressions are displayed as string literals

literalExpression "expr" is displayed as "expr" instead of expr.
Example: Default value of networking.fqdn.
cc @ncfavier @ysndr

@ysndr for reference, here's the Nix pretty-printer in Python we had before the Rust rewrite:
https://github.com/NixOS/nixos-search/blob/f866edd1cfc3e0f68cd0ad314b09b3d0ae1a6ce0/import-scripts/import_scripts/nix.py
Not sure how you want to go about this.

Thank you
I think its an issue of parsing the expression type though. I'm on it after the weekend!

Ignore my previous comment, brainfart.

So the first step is to stop treating literal* specially in flake_info.nix so that the information is available in the produced JSON. Then we can handle literalExpression/literalExample e.g. in the pretty-printer by just returning o["text"], and literalDocBook in export.rs using pandoc.

I got a bit confused here by the structure of your sentence..
Anyway, @ncfavier and @erikarvstedt feel free to check out
https://61c5f09cfa1ce4b942596b58--nixos-search.netlify.app
This should fix this issue

Don't worry about it 😅 what you have implemented now is probably better than what I was trying to formulate anyway.

Fixed in #395


⚠ Bofrost.be has degraded performance

In 2b82528, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1430 ms

Resolved: Bofrost.be performance has improved in 09d6fb8 after 6 minutes.


Create functionality: add a product to our cart

As a customer/visitor,  I want to be able add a product to my cart so I can collect my desired products in one place.
Implementation:

create a button on front-end for "add to the cart"
back-end

So I refactored the seed file to work out some of the backend mechanics for this. I added documentation via comments above each section. I'd love for everyone to review... and now I just need to figure out how to generate a PR... @marybelousova @ChidiOk @FeliciaKh


Problem with postgres data volume

Hello
I'm using postgres 9.4 image and I wish to have my data persisted under /data/2life/db. In compose, I have such a definition where i bind /data/2life/db to /var/lib/postgresql
db:
   image: postgres:9.4
   environment:
      - POSTGRES_USER=rr
      - PGPASSWORD=rr
      - POSTGRES_PASSWORD=rr
   volumes:
      - /data/2life/db:/var/lib/postgresql

however when I inspect my container I notice that the data is persisted in an other volume /var/lib/docker/volumes... which i didn't asked.
    "Volumes": {
        "/var/lib/postgresql": "/data/2life/db",
        "/var/lib/postgresql/data": "/var/lib/docker/volumes/c90e06963f716494b5d3a3c24a61796dcaee983697ad65c3d76fe069f45d17b1/_data"
    },

does someone has an explanation or another way to persist data where we want ?
thx

The VOLUME is declared as /var/lib/postgresql/data, so you would need to asjust your bind mount to be that directory.
I think we need better documentation on what to mount to persist data to your host; like mysql

but if i bind to  /var/lib/postgresql/data then it's empty and there is the following error:
db_1    | postgres cannot access the server configuration file "/var/lib/postgresql/data/postgresql.conf": No such file or directory

Postgres will create that file on first start with postgres initdb, so it should only be empty if the postgres user in the container is unable to write to the directory which only happens if root in the container was unable to chown it.  Maybe docker info, docker version, uname -a, and docker logs on the container?

you're right it is about write rights. (what a sentence to pronounce!)
I wasn't able to use another user as POSTGRES_USER=postgres but once i used postgres it worked.
thanks for you help

Could anyone give me an example?

@vallettea - I just bumped into this exact issue. Could you please provide a solution example? I know there is a way to solve this from reading the comments in this issue. But I don't know how.

I'd recommend trying a dedicated support forum such as the Docker Community Forums, the Docker Community Slack, or Stack Overflow.


403 on fetching script for Google Sign in button

Hi, thanks, I like your pwa wrapper,
I added sign in with Google account, in Safari all is ok, but in wrapper I got 403 error when fetching js script https://accounts.google.com/gsi/client.
Not sure, maybe app should be added somewhere in google cloud console or install Pod for google or creating separate OAuth sign in credentianl in Google Console

@aidar87 login is limited by the redirect approach. You shouldn't get any error by fetching js. Maybe you need to add google domains to info.plist. What exactly error do you get?

Tried to add accounts.google.com to in app bounded domain to  Info.plist, to authOrigins in Settings.swift but it didn' help.
Here are screenshots from pwa-wrap with errors:

And here is screenshot where it works on iOS safari:

Try to debug this function and see what happens with this request.

webView function was not called on this request.

Sure, https, the referer header in screenshots are the same. I tried on real iphone XR ios 15.3.1  - safari is OK, pwa app which is published to App Store get 403 error.
I tried to add script tag in html, appending using js both got 403 from google server.

Can I replace user-agent in pwa-wrapper webview? Asking because safari user-agent differs from webview's

Yeah of course https://github.com/khmyznikov/ios-pwa-wrap/blob/f01a2600ba62b093187f1507a8ee2533fe4afbfe/pwa-shell/WebView.swift#L51

Thank you very much, with custom UserAgent it works!

Thank you very much, with custom UserAgent it works!

Do you used this string? Or added something extra?

Yes, I did. I am using your previous project before you added this feature with custom user agent

@aidar87 Could you tell for more details on what did you do for google social login. I have the issue when you choose the user and then I stuck on the consent screen and that's all. I used debug for check - but all is ok. Errors are absent. In the browser all is ok.

Guys, sorry for the late answer. It is working. Here is workaround:
I used redirect for Google OAuth, pop up didn't  work. Added accounts.google.com to the zoomia/Info.plist and
authOrigins variables in  zoomia/Settings.swift, changed webView.customUserAgent to any different.

@keysen1 @dmytro-podolianskyi-ew did you find any solution for consent screen? I have same issue and @aidar87 solution is not enough. I sign by google, login by google, end up with 400 on consent https://accounts.google.com/signin/oauth/consent?...
When I try login by google again, there is already session and it works


[server] 3/n Endpoint for set_env

[server] 3/n Endpoint for set_env
Summary:
Stack contains changes that updates overall environment setup flow for vscode extension.
This diff implements the server side endpoint. Will test on top with vscode
Test Plan:
payload={'env_file_path': {}}
Status Code: 400
Response JSON: {'message': 'Invalid request, specified .env file path is not a string.'}

payload={'env_file_path': '/hi'}
Status Code: 400
Response JSON: {'message': 'Specified .env file path does not exist.'}

payload={'env_file_path': '.env'}
Status Code: 200
Response JSON: {'message': 'Updated .env file path.'}

Stack created with Sapling. Best reviewed with ReviewStack.

#1384
-> #1383
#1382

added basic validation of .env
updated testplan


Added PokeStatus script

Interesting. Why would you want to buy a wordpress theme for this though?

Wow. 74 sales. I am impressed.


../../../flutter/.pub-cache/hosted/pub.flutter-io.cn/flutter_markdown-0.3.1/lib/src/style_sheet.dart

../../../flutter/.pub-cache/hosted/pub.flutter-io.cn/flutter_markdown-0.3.1/lib/src/style_sheet.dart:184:32: Error: Getter not found: 'systemGrey6'.
color: CupertinoColors.systemGrey6,I got this messages,when I use 0.3.0

Closing this as resolved based on above comment.


Add GA version of APIs for MySQL and PGSQL

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information
This PR is moving the definition under 2017-12-01-preview to stable folder and make sure the api-version to use  2017-12-01 instead of 2017-12-01-preview.

[ ] The title of the PR is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[ ] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[ ] If applicable, the PR references the bug/issue that it fixes.
[ ] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[ ] I have read the contribution guidelines.
[ ] My spec meets the review criteria:

[ ] The spec conforms to the Swagger 2.0 specification.
[ ] The spec follows the guidelines described in the Swagger checklist document.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

Automation for azure-sdk-for-node

Automation for azure-libraries-for-java

Automation for azure-sdk-for-python

Automation for azure-sdk-for-go

Hello @QingqingYuan ! This PR looks good :D
Question, is this already deployed?

Thanks @mcardosos for the quick response! Yes, this has already been deployed. However, we will announce GA on 3/20 and don't want this go public at this moment. We'd like this get merged on 3/18 or 3/19 morning. I updated the PR title to indicate this. Thanks!

@AutorestCI rebuild azure-sdk-for-go

@mcardosos  Can you help to merge this? Thanks!


Catalog table filter ignores title field

Expected Behavior
If the title and the name of an entity is different (e.g. name=abc and title=bubu), the title is displayed in the table as name.
I can filter the table (the filter to the right of the table title) with bu or bubu and the entity named abc is showing up.
Actual Behavior
If I search for bu oder even bubu the entity named abc is not showing as result.
Steps to Reproduce
See above.
Your Environment
Backstage version 1.2.2

I think this code is responsible for showing the title as name if existing but doesn't consider the filter functionality.
https://github.com/backstage/backstage/blob/master/plugins/catalog/src/components/CatalogTable/columns.tsx#L36-L39

Nice thanks.
I would suggest this solution has to be moved into Backstage. Filtering by title should be possible out-of-box. The current behavior is really bad from a user experience standpoint and should be fixt, right?

It would probably be a good thing to add to the default catalog table, sure! Would you like to contribute that?


remove compass dependent sass

remove things that can't be used at all without compass - sprites, browsers, inline-block. Rework box-sizing helpers to not use compass. Some of the components files still use compass mixins and will have to be updated with replacements
This is a big scary one, I do not expect that it will be merged easily.
I tried to remove as much as possible in one go. If you think I've removed something unnecessarily please tell me.
I am opening an issue to discuss our options for replacing the compass mixins being used in the components files
@incuna/frontend

@incuna/frontend please review

:+1:

There are a few comments on incuna-sass/_normalize.sass - perhaps we could consider using the bower package for it instead?

@perry we're just discussing this, I think we're going to give this one a try: https://github.com/necolas/normalize.css/blob/master/normalize.css

Sounds like a plan. Perhaps add it to the bower.json of this project as a dependency? You may have to add the directory as an import path in sass/compass/whatever.

@hippogriffic @perry hi perry! :D yeah, perhaps if we dont need to change that we can just do it as perry suggest. But perry.. no compass anymore! ;)

@perry ok, so I have normalise.sass now, what am I doing with bower.json?

@incuna/frontend please review

Looks good to me, let's do it !


set seed in weight init

Hi ;
I am implementing a fully conv network which has conv and transposed convolution modules in them. I was wondering if it possible to set the seed so that I would be able to reproduce my results . Below is the code I wrote for weight init.
def init_weights(m):
if type(m) == nn.Conv2d :
init.xavier_uniform(m.weight, gain=np.sqrt(2))
if type(m)==nn.ConvTranspose2d:
init.xavier_uniform(m.weight, gain=np.sqrt(2))
model.apply(init_weight)

Hi @varghesealex90
Just a side note, this module is now integrated into the latest pytorch release and you should use that version (as that is the one being maintained).
However, you should be able to set the seed by setting the randomstate/seed in random and in torch.
Closing the issue here, if you run into any other issues please open an issue on the PyTorch repo.


fix: region logical regions after catching up

I hereby agree to the terms of the GreptimeDB CLA.
Refer to a related PR or issue link (optional)
What's changed and what's your intention?
Register metric logical regions after invoking catchup
Checklist

[ ] I have written the necessary rustdoc comments.
[x] I have added the necessary unit tests and integration tests.
[ ] This PR requires documentation updates.

@WenyXu Please describe the PR in detail. What issue does it address? What happened before this patch etc.


Standardize SQL database interface for TS/JS

It's a topic that has been brought up every now and then in the Deno DB community, but as Deno is becoming more stable, supports NPM and Node, and we got JSR, I believe it's time to consolidate and create a db standard SQL interface for TS and JS.
I have created a POC in my repo PR.
Any input and contribution is greatly appreciated and encouraged as it would be best to make this a collaborative effort amongst the database maintainers since they know the pitfalls for the different engines.
The milestones are as follows:

Decide on an interface for DB clients that can be implemented by any SQL based db. Wrappers can be created for existing database clients to locate potential issues with the interface and current implementations.
Refactor existing databases to implement these interfaces.

The goal for this is to be able to easily transition between databases and have a familiar interface and usage between them.
Consider the PR as a parent issue to have discussions, and where we can finalize the implementation.

RFC has been created: https://github.com/halvardssm/deno_stdext/pull/6


Update layout for new statuses

Description

Add columns for In Progress, In Review, and Done
Add additional bootstrap components

bootstrap layout and utility styles added to match design brief and layout requirements


casperjs-0.6.* crashes cmd.exe on Windows 7

Comment below from Scott Argenziano at http://groups.google.com/group/casperjs/browse_thread/thread/4b683e14f1d737b2?hl=fr%3Fhl%3Dfr

Hello there,
I've been using CasperJS for a couple months now. Now I'm having some
trouble. I have updated to Phantom 1.4.1 and am using the latest CasperJS
0.6.1. I have updated my scripts to use the new phantom.casperPath and
phantom.injectJS. My non-casperjs scripts run fine. When I attempt to run
any CasperJS script from the command line I get a win7 error stating the
application crashed:
Problem signature:
Problem Event Name:    APPCRASH
Application Name:    phantomjs.exe
Application Version:    <IP_ADDRESS>
Application Timestamp:    4f0363b6
Fault Module Name:    QtWebKit4.dll
Fault Module Version:    <IP_ADDRESS>
Fault Module Timestamp:    4e8c13d3
Exception Code:    c0000005
Exception Offset:    00a8deec
OS Version:    6.1.76<IP_ADDRESS>.256.48
Locale ID:    1033
Additional Information 1:    c108
Additional Information 2:    c108a3bb9a127f5be86591f443205009
Additional Information 3:    0242
Additional Information 4:    024211bf95c84e7100551937dc689526

Anyone else experience this, or am I missing something? My test script here
is nothing more than this:
phantom.casperPath = '/includes/casperjs';
phantom.injectJs(phantom.casperPath + '/bin/bootstrap.js');

var url = 'http://www.google.com';
var casper = require('casper').create();

casper.start(url, function()
{
    this.echo('Page Loaded.')
});

casper.run(function()
{
    this.echo('All Done.')
}

I wonder what /includes/casperjs resolves to on Windows… It might the problem, can someone test with a valid Windows path, eg. C:\includes\casperjs? eg.:
phantom.casperPath = 'C:\\includes\\casperjs';
phantom.injectJs(phantom.casperPath + '\\bin\\bootstrap.js');

PS: I still need to find/setup a Windows VM to make my own testing, so any help much appreciated in the meanwhile.

I have some VMs, I'll install casper etc on one now and give that a try.

Thanks :)

More info (some progress, but not there yet).
This reaches the log without crashing cmd.exe
phantom.casperPath = 'lib\casperjs-0.6.0';
phantom.injectJs(phantom.casperPath + '\bin\bootstrap.js');
console.log('BOOM!');

This also reaches the log without crashing cmd.exe
phantom.casperPath = 'lib\\casperjs-0.6.0';
phantom.injectJs(phantom.casperPath + 'bin\\bootstrap.js');
console.log('BOOM!');

But in both cases, the next line
var casper = require('casper').create();

returns
$ undefined:0 Unknown module casper for require()

Thanks.

What console.log(require('fs').workingDirectory) gives?

Got it, infine loop when using fs.dirname() on Windows. Patch on its way :)

Nice one Niko!

For info, with Niko's commit e4aafdf9a0d47428c5bdae9b0fa7a4407b84b3bd applied, the below works;
phantom.casperPath = 'C:\\path\\to\\your\\repo\\lib\\casperjs-0.6.0';
phantom.injectJs(phantom.casperPath + '\\bin\\bootstrap.js');
var casper = require('casper').create();
/// do stuff


ENH: Move fake_epics into package for external use

We would like to use the using_fake_epics_pv wrapper for some external packages containing Ophyd devices. In the current state it is difficult to access these because the tests directory is not inside the package itself.
In the long term it might be nice to just put the tests inside the ophyd module much like Bluesky is setup. I figured that for now this would be the less invasive change.

50/50 to exposing this out to the world.  I would prefer to move away from this in the ophyd test suite as well (and move to using caproto to stand up test servers), but can see why this is useful.

Yeah I've experimented with using pcaspy to simulate the IOC we are testing but you end up dealing with strangeness in both pcaspy and pyepics. It is also a lot of leg work to mock all of the records you need. This seemed like a solid way to smoke test devices, but I could see why it isn't quite polished enough to be part of the main repo.
Any thoughts on sticking the test directory inside ophyd so I can just use:
from ophyd.tests import using_fake_epics_pv

This way it also matches the bluesky structure

:+1: to moving the tests in, not sure why they are outside here actually...

Closing this PR as #406 voids the need for this change


Testing To-Do List: Part 1

Testing To-Do List: Part 1 😎
Hello there, my kind reviewer! First, I need to mention that, in this feature branch, I had to work alone due to my coding partner's inactivity since the start of the week. He reached out to me yesterday and mentioned that he's sick, but I haven't heard from him since then, even though I messaged him several times on slack. I understand his situation and that this is a collaborative project, but I'm getting worried about repeating the week due to this circumstance 😟
In the present branch, the following features were implemented:

Jest framework for the testing ✅
A  test file ([..].test.js) for a file containing the add item and delete item functions that you want to test ✅
Mock localStorage ✅
Mock HTML to test if add/delete functions add or remove exactly one  element to/from the list in the DOM ✅

Hi @mwismann ,
Good job so far! There are some issues that you still need to work on to go to the next project but you are almost there!
Highlights

Pull request description is good 👍

Required Changes ♻

[ ]  Kindly remove inline comments from your code
[ ]  Kindly inform student success as per your team member not communicating due to illness

Optional suggestions
Every comment with the [OPTIONAL] prefix is not crucial enough to stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better.
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear. Please, remember to tag me in your question so I can receive the notification.
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.
As described in the Code reviews limits policy you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.

Hello @AshakaE ,
Thank you for your quick review!
Concerning my partner's situation, I reached student success yesterday. I'm currently exchanging emails with one of their team members regarding my circumstance.
Thank you kindly for mentioning it!


could not launch process: EOF

Please answer the following before submitting your issue:
Note: Please include any substantial examples (debug session output,
stacktraces, etc) as linked gists.

What version of Delve are you using (dlv version)?

To dlv start a debug session

What did you see instead?

could not launch process: EOF

Same issue and same MAC OS version, just updated today.

Same as @luq885 .

me too. @luq885

my go version is 1.10.1

IDEA version is 2018.1

Same issue as @warjiang  and now I updated Mac OS to 10.13.4

@Khamliuk everything is ok when i used Mac OS 10.13.3。After i update Mac OS to 10.13.4, I can't use delve to debug programe. It seems the problem of codesign on MacOS

@warjiang Yes, I have the same situation

same, I believe it was the 10.13.4 update that caused this. I'm in this situation after updating.

Im on macOS High Sierra 10.13.3 and have same problem!

Did you upgrade the Command Line Tool Tools? @antuspenskiy

I upgrade macOS High Sierra 10.13.4, Go 1.10.1  in the same day

I feel soooo regret for my upgradtion to 10.13.4.

Same symptoms after upgrading to 10.13.4 ;( Please helppppp

For me the problem started from Command Line Tools update, didn't make update to 10.13.4 yet. So the problem is somewhere in command line tools :-/

command line tools

Idk what was updated.  I was debugging this morning, after lunch failed to launch debugger.  This is a major issue for me, can't debug anything with GoLand.

In my case,another issue came with this one at the same time:
Xcode stop response during debug the pure C++ project.
Anyone got the same issue?

Did you upgrade the Command Line Tool Tools? @antuspenskiy

Yes it was updated during MacOS 10.13.3-10.13.4.

I rollback my CommandLineTools,
Temporarily solved the problem by removing new Command Line Tools
$ sudo rm -rf /Library/Developer/CommandLineTools
then go to page https://developer.apple.com/download/more/
download and install previous version
Command Line Tools (macOS 10.13) for Xcode 9.2 - Dec 4, 2017

Experiencing the exact same issue, rollback of CLT worked however. Specifically it seems like no debug file is created.

@TomorrowWu thanks, after i rollback command line tools, delve can work

@TomorrowWu thank you

Somebody having this problem should try adding conn.gcmdok = false after $GOPATH/src/github.com/derekparker/delve/pkg/proc/gdbserial/gdbserver_conn.go:109. If it doesn't work, don't post "it doesn't work", turn on logGdbWire and post the output.

So I downloaded the latest master and ran a debug session and it worked fine. But the version from brew does not work.
go version go1.10.1 darwin/amd64
sw_vers
ProductName:    Mac OS X
ProductVersion: 10.13.4
BuildVersion:   17E199
go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/merlin/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/merlin/gopath"
GORACE=""
GOROOT="/usr/local/opt/go/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/opt/go/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/5j/r39qwlt9257g6fgwrgh6k_km0000gn/T/go-build629340659=/tmp/go-build -gno-record-gcc-switches -fno-common"
Working:
Delve Debugger
Version: 1.0.0
Build: db435c184eb79976087fc0cb36c2867c737a9066
Broken for this scenario:
Delve Debugger
Version: 1.0.0
Build: 678576d2ce3b14f7b6b59692669b8acbd7c427ff

I have a workaround.
sudo rm -rf /Library/Developer/CommandLineTools.
Go to https://developer.apple.com/download/more/ and download Command Line Tools (macos 10.13) for XCode 9.2.
This will restore debugging until the issue gets resolved upstream.

@MarkSRobinson I can't find this version of Command Line Tools on the site

@Khamliuk https://download.developer.apple.com/Developer_Tools/Command_Line_Tools_macOS_10.13_for_Xcode_9.2/Command_Line_Tools_macOS_10.13_for_Xcode_9.2.dmg

@aarzilli I couldn't follow those instructions for patching gdbserver.go but this seems to work:
diff --git a/pkg/proc/gdbserial/gdbserver.go b/pkg/proc/gdbserial/gdbserver.go
index a201e57..4791f98 100644
--- a/pkg/proc/gdbserial/gdbserver.go
+++ b/pkg/proc/gdbserial/gdbserver.go
@@ -418,6 +418,9 @@ func LLDBLaunch(cmd []string, wd string) (*Process, error) {

        p := New(proc.Process)
        p.conn.isDebugserver = isDebugserver
+       if isDebugserver {
+               p.gcmdok = false
+       }

        if listener != nil {
                err = p.Listen(listener, cmd[0], 0)

@rcoreilly: cool. Can you try PR #1169, I'd like to disable this only for the specific version of debugserver that is affect.

yep that works!  I didn't see that I could click on that d3ad0cf link on your comment above and get that patch..

@rcoreilly Thank you.

@TomorrowWu  thank you ~

still do not work with applied comment and d3ad0cf

@dkorhov try his method @TomorrowWu. It's new version of Command Line Tools which lead to this issue.

@YaoJunZhao Thanks

@姚俊兆   我没有苹果的开发者账号没办法下载那个工具<EMAIL_ADDRESS>

I also ran into this problem today - any work regarding this on this great debugger.

@RoarkeRandall it did, at least for me:

I disabled auto updates for now - waiting for a proper solution

Hi, Aarzilli,
Manually merged your fix and seems did not fix. So have to use @TomorrowWu's workaround that roll back the command line tools.

p.gcmdok = false worked for 9<IP_ADDRESS> (patched, re-builded glv binary)

goland track:
https://youtrack.jetbrains.com/issue/GO-5527

@adamgoose are you experiencing the same issue after the patch or not?

@MvHugo
@rcoreilly
if the patch doesn't work you need to enable logGdbWire and post the output, or nothing will ever be fixed.

all versions of the patch have worked for me, on MacOs 10.13.4, using xcode / command line tools 9.3, installed Mar 30.  perhaps also for those whom it is not working, they could add some fmt.Printf's  in the patch code to see if g.gcmdok = false is being run, and what the version string is reporting?

Enabling logGdbWire will print the version string, among other things.

@TomorrowWu You saved me... Thanks...

Any estimate as to when this patch might be merged into master so that the rest of us can get it through a simple go get?

@rcoreilly thank you for the workaround. worked well for me with latest command line tools as of today.

@rcoreilly patch works here for me on latest everything. Thanks!

For anyone waiting for this patch, you can patch manually like this.
Run these instructions inside of the
git remote add aarzilli git@github.com:aarzilli/delve.git
git pull aarzilli debugserverfix
GO15VENDOREXPERIMENT=1 CERT=dlv-cert make install

If you need to reload your shell exec $SHELL

Is there a permanent solution to this problem? Is this bug fixed?

As I know many of the GoLand users are watching this issue, GoLand 2018.1.1 / 2017.3.4 were rolled-out with the patch from #1169. Thank you to the Delve team for the fix on this.

@okabbas as far as I know the bug still exists and will resurface when Apple releases a new version of debugserver: https://bugs.llvm.org/show_bug.cgi?id=36968

@derekparker / @aarzilli do you guys think it's possible to tag a new release to include this patch in it? There are a few other commits on master that are not in 1.0.0, but this one would be worthy of at least of 1.0.1 release. Thank you!

go get -u github.com/derekparker/delve/cmd/dlv will solve this issue.

For those using Homebrew like me, upgrade to the HEAD version:
brew upgrade delve --HEAD

Works on 10.13.4 with latest Command Line Tools 9.3.

Here is how I fixed it for GoLang:

Build the latest version of dlv: go get -u github.com/derekparker/delve/cmd/dlv
Now find your "go/bin" directory, you should see the newly built dlv located in the directory
Rename GoLang's old dlv to dlv.old, my GoLang's dlv was located in: /Applications/GoLand.app/Contents/plugins/go/lib/dlv/mac/dlv
Copy "go/bin/dlv" to /Applications/GoLand.app/Contents/plugins/go/lib/dlv/mac/dlv

@henryse, I’d appreciate if yo remove the instruction.

2018.1.1 and 2017.3.5 with the fix were released more than a week ago
The instruction of harmful since it breaks signature of Goland application and breaks future patch update

maybe someone got same situation as me?
moc os
goland
could not launch process: EOF
exit Goland
move /Volumes/GoLand to application
push-off   /Volumes/GoLand
restart
works...

@charnlsxy what's the IDE version you use? Could you please file an issue at https://youtrack.jetbrains.com and attach logs there (Help | Collect logs and show in finder)?

@zolotov version2018.1
i don't know why

@zolotov i don't know why

Update to 2018.1.3 and the Go plugin fixes the issue for me.

I'm getting this with VS Code. I tried the tip to remove latest XCode - no joy :-(

I still have the same issue with the latest codes. go get -u github.com/derekparker/delve/cmd/dlv doesn't work for me.

What worked for me (assuming you use GoLand IDE):

Going to Delve settings in Go. Press cmd+shift+a, type "delve", hit enter.
Select box "Use native backend"

@willis7 Yes. The VS Code extension installs delve via go get on first start.
There's also a command in VS Code by the extension to update all it's Go dependencies.

@dotw Make sure you:

haven't installed dlv in another way (for example with brew). Verify with which dlv that you're actually running the version installed by go get.
have $GOPATH/bin (or something equivalent) in your $PATH.

That was the case for me and after fixing that it seems to work with the version installed by go get.

Has there been a clear solution to this? I'm still running into the same error and I just did go get on delve today (so its the most recent version), but I'm still getting could not launch process: stub exited while waiting for connection: exit status 0

@radugh 's  suggestion looked by far the easiest to give a shot and it worked.
I didn't touch XCode or any OS tools just ran:
go get -u github.com/derekparker/delve/cmd/dlv
OS: 10.13.4
$ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables
package-id: com.apple.pkg.CLTools_Executables
version: <IP_ADDRESS>.1.1521514116
volume: /
location: /
install-time:<PHONE_NUMBER>
groups: com.apple.FindSystemFiles.pkg-group
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.1.0 (clang-9<IP_ADDRESS>)
Target: x86_64-apple-darwin17.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

@WangChangQin Please move this thread to our tracker at https://youtrack.jetbrains.com/issues/Go but this problem should have been solved in 2018.1.1, a long time ago.

As @levrik suggests, for VS Code you can update all of your tools via the Command Pallette.
This is accessed via CMD+Shift+P on MacOS, search for Go: Install/Update Tools and tick at least dlv (Debugging) to update delve.


Namespacing multiple bas files from a source

When namespacing multiple .bas files and they rely on each other, then the new namespaced name doesn't get replaced in the other namespaced files. I.e. we can currently only namespace single .bas files

This is partly why I flatten the files in the following library:
https://github.com/AutoActuary/TemplateGenerator/blob/c479011a770fe0985b2e554c30e3603be72acf05/scripts/compile.py#L48

Hmm... flattening is quite useful in any case. Maybe we should support it...

Blocked by #9. We can easily do this when we have #9 built in.

https://github.com/VirtualActuary/zebra-vba-packager/releases/tag/0.0.8


Discriminated union

Resolves #894.
I implemented the z.discriminatedUnion(discriminator, options) method and aliased it by z.union(discriminator, options). I also added tests and benchmarks.
Here are the results of the benchmarks to demonstrate the speed improvements introduced by the new z.discriminatedUnion method:
z.union: double: valid: a x 318,907 ops/sec ±3.79% (95 runs sampled)
z.union: double: valid: b x 316,293 ops/sec ±0.15% (95 runs sampled)
z.union: double: invalid: null x 51,916 ops/sec ±0.82% (94 runs sampled)
z.union: double: invalid: wrong shape x 45,775 ops/sec ±0.33% (96 runs sampled)
z.union: many: valid: a x 153,385 ops/sec ±3.67% (96 runs sampled)
z.union: many: valid: c x 155,023 ops/sec ±0.41% (93 runs sampled)
z.union: many: invalid: null x 31,763 ops/sec ±0.58% (96 runs sampled)
z.union: many: invalid: wrong shape x 28,859 ops/sec ±0.52% (94 runs sampled)

z.discriminatedUnion: double: valid: a x 855,547 ops/sec ±3.85% (94 runs sampled)
z.discriminatedUnion: double: valid: b x 882,583 ops/sec ±0.10% (98 runs sampled)
z.discriminatedUnion: double: invalid: null x 125,343 ops/sec ±0.63% (96 runs sampled)
z.discriminatedUnion: double: invalid: wrong shape x 121,325 ops/sec ±3.10% (91 runs sampled)
z.discriminatedUnion: many: valid: a x 870,138 ops/sec ±0.13% (99 runs sampled)
z.discriminatedUnion: many: valid: c x 869,438 ops/sec ±0.30% (100 runs sampled)
z.discriminatedUnion: many: invalid: null x 125,895 ops/sec ±0.44% (95 runs sampled)
z.discriminatedUnion: many: invalid: wrong shape x 114,925 ops/sec ±2.39% (94 runs sampled)

z.string: empty string x 3,445,793 ops/sec ±0.13% (99 runs sampled)
z.string: short string x 3,436,956 ops/sec ±0.14% (96 runs sampled)
z.string: long string x 3,398,985 ops/sec ±0.46% (98 runs sampled)
z.string: invalid: null x 137,217 ops/sec ±0.58% (94 runs sampled)
z.string: manual parser: long x 888,891,546 ops/sec ±0.30% (92 runs sampled)
z.object: empty: valid x 2,501,015 ops/sec ±0.25% (97 runs sampled)
z.object: empty: valid: extra keys x 2,296,817 ops/sec ±0.06% (98 runs sampled)
z.object: empty: invalid: null x 145,813 ops/sec ±0.52% (97 runs sampled)
z.object: short: valid x 1,112,832 ops/sec ±4.26% (94 runs sampled)
z.object: short: valid: extra keys x 1,084,645 ops/sec ±0.25% (98 runs sampled)
z.object: short: invalid: null x 141,549 ops/sec ±0.49% (99 runs sampled)
z.object: long: valid x 478,374 ops/sec ±3.26% (92 runs sampled)
z.object: long: valid: extra keys x 467,779 ops/sec ±0.46% (97 runs sampled)
z.object: long: invalid: null x 144,143 ops/sec ±0.88% (96 runs sampled)
Done in 164.54s.

Thanks @alexxander for this PR. The team I work with would have an immediate use for this as the current errors for unions can leave something to be desired. I am not sure what the current approval process for this project is but I would be happy to do an initial review before @colinhacks.

@alexxander this PR is a game changer and very useful. Thank you for the good work. While testing I ran into a case where the error was incorrect if the value of the discriminator didn't match anything in the union. I would expect the error to be something along the lines of: "Received invalid value 'IncorrectType' for discriminator 'type'. Expecting value to be one of [ValidType1, ValidType2, ...]".

Hi @EdsterG, firstly, thanks for the compliments on my work, I am glad you find this useful.
However, I did try to handle that case you mentioned and I am failing to reproduce the incorrect error. Though it might be that something slipped through my fingers. I actually even created a new zod issue type for this particular purpose. See the test case bellow:
test("invalid discriminator value", () => {
    expect.assertions(1);
    try {
      z.discriminatedUnion("type", [
        z.object({ type: z.literal("a"), a: z.string() }),
        z.object({ type: z.literal("b"), b: z.string() }),
      ]).parse({ type: "x", a: "abc" });
    } catch (e: any) {
      expect(JSON.parse(e.message)).toEqual([
        {
          code: z.ZodIssueCode.invalid_union_discriminator,
          expectedOneOf: ["a", "b"],
          received: "x",
          message:
            "Invalid discriminator value. Expected one of: a, b. Received x.",
          path: ["type"],
        },
      ]);
    }
  });

I tried to pass other values in the type property - such as null, an object, undefined. I even tried leaving the property out. And in all the cases it seemed to work. Is there anything I am missing?

Hi @CantelopePeel, before this PR, I also implemented a self-standing function to handle discriminated unions with zod. I guess you might be interested in that as well: https://github.com/colinhacks/zod/issues/792#issuecomment-1023251415.

@alexxander yes that was my mistake. I was getting a very confusing error message and accidentally thought it was related to incorrect discriminator value. Your code correctly reports when an invalid discriminator is passed in. On that same note, there seems to be a previous issue to remove input values from the error messages. Might make sense to follow the same pattern and avoid having the input value as part of the error message. https://github.com/colinhacks/zod/issues/461

On that same note, there seems to be a previous issue to remove input values from the error messages. Might make sense to follow the same pattern and avoid having the input value as part of the error message

Yeah, it has been our practice to not leak input or schema data in error messaging to avoid logging sensitive or personally-identifying information to logs/etc. Applications should have the context at the call-site to report that sort of data themselves if they find it useful.

Previously, the only supported discriminator value type was string. In the last commit, I added support for other primitive types supported by the z.literal function. The drawback is that I needed to use the Map data type. Should this be a problem, I can implement it using a separate object for each type:
const map = {
  'string': {},
  'number': {},
  'bigint': {},
  'boolean': {},
  'object': {},
  'undefined': {}
};
map[typeof discriminatorValue][discriminatorValue] = schema;

Also, there are the failing deno tests. I guess I have to modify the tests to be compatible with both jest and deno? Any hints @scotttrinh?
How about using something like https://github.com/gcaptn/tincan? (Though this might be for a different issue.)

The drawback is that I needed to use the Map data type.

Glad you called that out. Hmm. We don't have a strong platform support story, but if it's easy enough to implement in the nested way you've outlined then that's probably the safest bet here without wanting a major version bump and a line-in-the-sand policy about platform support.

Also, there are the failing deno tests. I guess I have to modify the tests to be compatible with both jest and deno?

Yeah, we are trying to be friendly to the Deno community as much as is feasible. I can take a look at the failing tests, but I have 0 experience with Deno so won't be too much specific help.

Would it be possible to make this support lazy schemas? Otherwise it's not possible to use with discriminated recursive schemas.

@alexxander that would be super helpful, I know there's also a z.late.object methods that's implemented but undocumented. It's referenced here https://github.com/colinhacks/tozod but I'm not familiar with the inner workings of Zod so am having trouble getting it to work.

Just would like to say I'm also looking forward to this PR, more human errors will be a very good improvement.

I know there's also a z.late.object methods that's implemented but undocumented.

I believe that is a 2.0 construct. As far as I can tell in the source code, there is not late class.
I'm actually wondering if we should put off supporting lazy here? @alexxander if you dig in a bit and run into any roadblocks, I think we should consider shipping what you have here and breaking off the further work into a separate PR.

Would it be possible to make this support lazy schemas?
@EdsterG I tried some simple tests with z.lazy, and it seemed to work well. Did you find any particular issues?

@alexxander here's a toy example where I get type errors:
import {z} from 'zod';

type Category1 = {
  type: 'Category1';
  subcategories1: Array<Category>;
};

type Category2 = {
  type: 'Category2';
  subcategories2: Array<Category>;
};

const Category1Schema: z.ZodSchema<Category1> = z.object({
  type: z.literal('Category1'),
  subcategories1: z.array(z.lazy(() => CategorySchema)),
});

const Category2Schema: z.ZodSchema<Category2> = z.object({
  type: z.literal('Category2'),
  subcategories2: z.array(z.lazy(() => CategorySchema)),
});

const CategorySchema = z.discriminatedUnion('type', [Category1Schema, Category2Schema]);
type Category = z.infer<typeof CategorySchema>;

I get the following type error:
error TS2740: Type 'ZodType<Category1, ZodTypeDef, Category1>' is missing the following properties from type 'ZodObject<{ type: ZodLiteral<Primitive>; } & ZodRawShape, any, any, { [x: string]: any; [x: number]: any; }, { [x: string]: any; [x: number]: any; }>': _shape, _unknownKeys, _catchall, _cached, and 16 more.

const CategorySchema = z.discriminatedUnion('type', [Category1Schema, Category2Schema]);

@EdsterG This fails because z.discriminatedUnion expects instances of ZodObject. You, however, typed Category1Schema and Category2Schema  as ZodSchema, which is an alias of ZodType.
Nonetheless, it is still possible to achieve what you want by slightly reorganizing the types.
type Category1 = {
  type: "Category1";
  subcategories1: Array<Category>;
};

type Category2 = {
  type: "Category2";
  subcategories2: Array<Category>;
};

type Category = Category1 | Category2;

const Category1Schema = z.object({
  type: z.literal("Category1"),
  subcategories1: z.array(z.lazy(() => CategorySchema)),
});

const Category2Schema = z.object({
  type: z.literal("Category2"),
  subcategories2: z.array(z.lazy(() => CategorySchema)),
});

const CategorySchema: z.ZodSchema<Category> = z.discriminatedUnion("type", [
  Category1Schema,
  Category2Schema,
]);

This actually even matches the example from the docs. Therefore, I do not really think this is an issue. Any views on this @scotttrinh?

Ah, I see. The idea was that many types of categories would be defined through out the lifetime of the project so I wanted to avoid maintaining two sources of truth:
type Category = Category1 | Category2;

and
const CategorySchema: z.ZodSchema<Category> = z.discriminatedUnion("type", [
  Category1Schema,
  Category2Schema,
]);

However, I would agree that this change should go into a separate PR. In my opinion, this PR should be merged as is because its impact is too great to wait any longer.

import {z} from 'zod';

type Category1 = {
  type: 'Category1';
  subcategories1: Array<Category>;
};

type Category2 = {
  type: 'Category2';
  subcategories2: Array<Category>;
};

const Category1Schema: z.ZodSchema<Category1> = z.object({
  type: z.literal('Category1'),
  subcategories1: z.array(z.lazy(() => CategorySchema)),
});

const Category2Schema: z.ZodSchema<Category2> = z.object({
  type: z.literal('Category2'),
  subcategories2: z.array(z.lazy(() => CategorySchema)),
});

const CategorySchema = z.discriminatedUnion('type', [Category1Schema, Category2Schema]);
type Category = z.infer<typeof CategorySchema>;

I get the following type error:

@EdsterG, actually, even if z.discriminatedUnion accepted anything object-like, typescript would still throw recursion-related errors with your solution quoted above. The thing is that Category is inferred from CategorySchema, which refers to Category1Schema of type Category1. However, Category1 refers to Category.

@scotttrinh I added the simplified implementation of the map data structure as it was outlined in one of my previous comments (util.SimpleMap). It implements get(key), set(key, value), has(key), keys() and the size property. Though I am not completely happy about the additional complexity it introduces (I mean, Map is well documented in the standards, while this one is custom).

@alexxander
Looking at https://caniuse.com/mdn-javascript_builtins_map I'm personally fine with IE11+ here, so Map still seems like a reasonable choice. We use const/let which has even worse support than Map (TIL!).
@EdsterG
RE: The type errors related to ZodSchema/ZodType
We shouldn't do too much work to support explicit types like the examples given here. Zod takes a pretty opinionated and strong stance that it should be the source of truth for types and does a best-effort job of supporting defining the types in TypeScript first. The big place of friction with this is external types that you do not control, so it's definitely ideal for it to work well if possible, but we should not spend too much development effort trying to get it to work. If z.infer/z.input/z.output is able to infer the correct type, that's our primary concern.

@scotttrinh So I should revert it to the state in which Map is used, right?
Is there anything else that has to be done (or that has to be changed) before this can be merged?

@scotttrinh So I should revert it to the state in which Map is used, right?
Is there anything else that has to be done (or that has to be changed) before this can be merged?

Just went back through the code, and it looks very good to me, thank you for all of your hard work here! Once you get it back to using a Map, do you mind just running the benchmarks again and updating the description if they're different at all from the first time you ran it?

@scotttrinh I reverted it. So now it uses Map again. I also ran the benchmarks and updated the pull request description.

Whoa, amazing! This is just what we needed today. But looks like this isn't published to npm yet? Any way we can get a beta published?