docker-compose fails when running from the integrated PS terminal

Running docker-compose commands fails when running from the integrated powershell terminal. Running same commands in the standalone powershell terminal works fine. Here's the failing message:
> docker-compose -f .\docker-compose.dev.yml pull

Pulling redis (redis:latest)...
latest: Pulling from library/redis
d13d02fa248d: Downloading [===>                                               ]  1.867MB/30.11MB
a1846f364e39: Download complete
dba901efed8c: Download complete
Traceback (most recent call last):
  File "docker-compose", line 6, in <module>
  File "compose\cli\main.py", line 68, in main
  File "compose\cli\main.py", line 121, in perform_command
  File "compose\cli\main.py", line 653, in pull
  File "compose\project.py", line 512, in pull
  File "compose\service.py", line 1031, in pull
  File "compose\progress_stream.py", line 44, in stream_output
  File "compose\progress_stream.py", line 63, in print_output_event
  File "codecs.py", line 370, in write
  File "site-packages\colorama\ansitowin32.py", line 40, in write
  File "site-packages\colorama\ansitowin32.py", line 141, in write
  File "site-packages\colorama\ansitowin32.py", line 169, in write_and_convert
  File "site-packages\colorama\ansitowin32.py", line 174, in write_plain_text
IOError: [Errno 0] Error
Failed to execute script docker-compose

This looks like another instance of this issue - that one was reported to the docker repo, but the reporter does note that this only happens in the VS Code integrated terminal.
Also, please note, that I didn't have this problem up until today when I've installed the Fall Creators Update to Windows.

Not sure. How can I check? I do have python 2.7 installed locally.

Hi.
It seems I have the same issue with docker and vscode since I installed fall creator 2 days ago.
In my case I have python 2.7 installed and python extensions in vscode.

Docker --version and Docker-Machine --version works as expected. Only Docker-Compose --version is failing in my preliminary test.  Hope this helps

@jacek-dargiel you would probably know if you were using it 🙂
@Ahryman40k @TheWozMSN are you both on Windows?

I am on the current insider build of windows 10.
Get Outlook for iOShttps://aka.ms/o0ukef

From: Daniel Imms<EMAIL_ADDRESS>Sent: Thursday, October 26, 2017 12:07:53 AM
To: Microsoft/vscode
Cc: Doug Woznicki; Mention
Subject: Re: [Microsoft/vscode] docker-compose fails when running from the integrated PS terminal (#36630)
@jacek-dargielhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjacek-dargiel&data=02|01|dwoznicki%40msn.com|fbf899d125bc4930ae0e08d51c27221b|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636445876749203371&sdata=MAyv2X%2FBk5q5T0erDeFwwXjqRrSFU%2B%2FY2TSeGEJSmuk%3D&reserved=0 you would probably know if you were using it 🙂
@Ahryman40khttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fahryman40k&data=02|01|dwoznicki%40msn.com|fbf899d125bc4930ae0e08d51c27221b|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636445876749359635&sdata=zf8O3bbeE3OyjplO%2FlZ8BVeHH%2BK3awU2bgzfGlb0pSk%3D&reserved=0 @TheWozMSNhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fthewozmsn&data=02|01|dwoznicki%40msn.com|fbf899d125bc4930ae0e08d51c27221b|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636445876749359635&sdata=svVHI02VrcQ2VxrXfQWD4bp4pMFwZKhN23O78xtEkUw%3D&reserved=0 are you both on Windows?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fvscode%2Fissues%2F36630%23issuecomment-339545452&data=02|01|dwoznicki%40msn.com|fbf899d125bc4930ae0e08d51c27221b|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636445876749359635&sdata=sx%2Fg6n%2FCp7F6f7NYsSINl0eRDKsPC%2FR1s1IA0H3Q9mc%3D&reserved=0, or mute the threadhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAMtuAfJkl_YyK1xKTN0I00uy3k1wcKJLks5swAWZgaJpZM4QAhER&data=02|01|dwoznicki%40msn.com|fbf899d125bc4930ae0e08d51c27221b|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636445876749359635&sdata=13ab1kK5SNda7BjIZJdho7tgng2tC5hlD8VvsMACn%2Bk%3D&reserved=0.

@Tyriar
I'm using Windows 10 Pro.

@Tyriar do I need to install python for docker compose to work in vscode? I got a brand new windows 10 installed running 1709 and I have the same issue

Further Comment.  Docker-Compose works in a regular powershell command window.  Not with Integrated Powershell

Think this might need to be taken up in the docker compose repo. If it is
not already
On Fri, 27 Oct 2017, 13:15 Doug Woznicki<EMAIL_ADDRESS>wrote:

Further Comment. Docker-Compose works in a regular powershell command
window. Not with Integrated Powershell
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/36630#issuecomment-339943863,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABy95AVdqTJHAlAKzcX-5n9ez0L33g_4ks5swbtggaJpZM4QAhER
.

Could anyone look at the bottom of the stacktrace and find out what is making it fail?
File "site-packages\colorama\ansitowin32.py", line 174, in write_plain_text

It might be something to do with the env?

Just hit this issue myself.
PS D:\jorda\Desktop\UF4.0> docker-compose up
Pulling mysql (mysql:5.7)...
5.7: Pulling from library/mysql
85b1f47fba49: Pulling fs layer
27dc53f13a11: Pulling fs layer
095c8ae4182d: Pulling fs layer
0972f6b9a7de: Waiting
Traceback (most recent call last):
  File "docker-compose", line 6, in <module>
  File "compose\cli\main.py", line 68, in main
  File "compose\cli\main.py", line 121, in perform_command
  File "compose\cli\main.py", line 938, in up
  File "compose\project.py", line 430, in up
  File "compose\service.py", line 311, in ensure_image_exists
  File "compose\service.py", line 1031, in pull
  File "compose\progress_stream.py", line 44, in stream_output
  File "compose\progress_stream.py", line 63, in print_output_event
  File "codecs.py", line 370, in write
  File "site-packages\colorama\ansitowin32.py", line 40, in write
  File "site-packages\colorama\ansitowin32.py", line 141, in write
  File "site-packages\colorama\ansitowin32.py", line 169, in write_and_convert
  File "site-packages\colorama\ansitowin32.py", line 174, in write_plain_text
IOError: [Errno 0] Error
Failed to execute script docker-compose

Last time I used this command was 3 months ago, and it had worked then. Most notable changes are updating to Fall Creators Update (non-Insider), several updates to docker, and several VS Code updates. Everything was up to date the last time it worked, and everything is up to date now.
Like the OP, regular PS window works fine.
Taking a look at the stack trace, it seems the error propagates from Colorama, a Python terminal colouring library. I'm terrible at Python, so I can't see any obvious reasons for it to be the cause.
I've spotted the issue at:

StackOverflow, with VS Code used
Colorama GitHub repo, with command prompt used

Looks like this is a bug in Colorama triggered by unknown circumstances.

+1 same issue occured!

+1 same issue

+1 same issue

+1 same issue

+1 same issue here on Fall Creators Update
I can confirm that reverting back to a Windows build prior to Fall Creators Update fixes the issue.

@miniksa @bitcrazed might be an issue with FCU?

+1 same issue here

I have a 1607 (10.0.14393 Build 14393) Windows 10 and an Insider Fast Current windows 10. Both with same error.  I don't have any Python installed.

+1 same issue here on Fall Creators Update BUT I am using the integrated terminal of PhpStorm. So it seems not to depend on VSCode.

+1 same issue here on Fall Creators update too. Dont have python installed on my host too.

Filed as MSFT:14643897. I'll get to it.

@miniksa awesome thanks!

Related? https://github.com/docker/compose/issues/2775

+1 same issue here. Happens after fall creators update

Please do not +1 for the sake of it without anything new that could contribute to the investigation. Please add yourself for notifications when the thread moves and react to other people's comments.
If you have debugged something that could help me figure it out or you can identify the exact build number where this first occurred, that's useful.
Otherwise, please be patient and let me get around to investigating this bug. Thank you for your understanding.

All: Please note that GitHub has added a reaction icon in the top left of each post:

If you want to share that you're impacted by the OP or a post within the thread, please thumbs-up appropriately.
If you don't want to do it for @miniksa, please do it for me - you don't have to work with him when he's all grouchy. SRSLY!!

I got this error upgrading to latest insider

Also use fall creators update. It worked yesterday with the version of visual studio code before this one.

@helto4real Please file this as a separate issue since this is not related to docker-compose failing

I believe it also fails in regular powershell but more silently. It fails but only shows up after you kill the hanging process.

@Tetraib What happens if you run chcp 65001 first?

@bitcrazed I tried chcp 65001, still happens.
docker-compose -f docker-compose.yml up -d --build
Traceback (most recent call last):
  File "logging\__init__.py", line 872, in emit
  File "site-packages\colorama\ansitowin32.py", line 40, in write
  File "site-packages\colorama\ansitowin32.py", line 141, in write
  File "site-packages\colorama\ansitowin32.py", line 169, in write_and_convert
  File "site-packages\colorama\ansitowin32.py", line 174, in write_plain_text
LookupError: unknown encoding: cp65001
Logged from file service.py, line 1027
1.9: Pulling from library/golang
3889bb8d808b: Downloading [===>                                               ]  254.9MB/4.07GB
eTraceback (most recent call last):
  File "docker-compose", line 6, in <module>
  File "compose\cli\main.py", line 68, in main
  File "compose\cli\main.py", line 121, in perform_command
  File "compose\cli\main.py", line 952, in up
  File "compose\project.py", line 431, in up
  File "compose\service.py", line 312, in ensure_image_exists
  File "compose\service.py", line 1036, in pull
  File "compose\progress_stream.py", line 44, in stream_output
  File "compose\progress_stream.py", line 72, in print_output_event
  File "codecs.py", line 370, in write
  File "site-packages\colorama\ansitowin32.py", line 40, in write
  File "site-packages\colorama\ansitowin32.py", line 141, in write
  File "site-packages\colorama\ansitowin32.py", line 169, in write_and_convert
  File "site-packages\colorama\ansitowin32.py", line 174, in write_plain_text
IOError: [Errno 0] Error
Failed to execute script docker-compose

@bitcrazed what seems to make it works in powershell but not in vs code is to

Execute chcp in cmd which returned 850 in my case
Execute chcp 850 in powershell

chcp 65001 does not seems to solve the problem
So for now I stoped using the integrated terminal in vs code and use the native powershell to run docker-compose.
It is sometimes hard to pickup the bug. Sometimes random, sometimes keeps failing in a row.

same issue

I get the same problem on hyper terminal so I suspect this bug came from Electron.

Robot Framework users are encountering same/similar IOError: [Errno 0] Error issue (see robotframework/robotframework#2709). After seeing a StackOverflow question with same error, I thought that the problem could be caused by several processes writing and reading to (possibly) redirected stdout. I thought adding seek(0, 2) before writing to stdout as proposed by the accepted answer to the aforementioned questions would help, but first reports from users aren't very positive. I personally cannot reproduce the problem as I run Linux and only have Windows 7 in a virtual machine.
After browsing through comments to this issue, I started to think could the problem be related to console colors instead. We don't use colorama, but the error occurs in our custom console coloring code which most likely uses same Windows APIs as colorama. Could there have been changes to them in the latest Windows 10 versions?

Hey @pekkaklarck,
There were changes in the console. People are mentioning this is happening since fall creators, and lo and behold: https://blogs.msdn.microsoft.com/commandline/2017/08/02/updating-the-windows-console-colors/
Might be related.

Thanks for the info @all - we've field a bug & will be exploring this issue

Can someone please provide repro steps here from a clean Windows box? I'm unfamiliar with VSCode, Docker, Docker Compose, or anything having to do with web development.
I followed the Getting Started with Docker Compose guide this morning here: https://docs.docker.com/compose/gettingstarted/#step-4-build-and-run-your-app-with-compose and installed https://docs.docker.com/docker-for-windows/install/ which included Compose, apparently.
I ran the "docker-compose up" command and seem to have no problems in either Powershell or the integrated terminal inside VSCode.

PS C:\foo\composetest> docker version
Client:
Version:      17.09.0-ce
API version:  1.32
Go version:   go1.8.3
Git commit:   afdb6d4
Built:        Tue Sep 26 22:40:09 2017
OS/Arch:      windows/amd64
Server:
Version:      17.09.0-ce
API version:  1.32 (minimum version 1.12)
Go version:   go1.8.3
Git commit:   afdb6d4
Built:        Tue Sep 26 22:45:38 2017
OS/Arch:      linux/amd64
Experimental: true
Visual Studio Code:

Windows Version: Build 17046.rs_onecore_dep_aci.171120-1700

Well, fiddling around with it enough, I got it to happen. But I can't figure out which specific call it is failing on. I have no Python-fu so I don't know how to tell what call it is making and failing.
I'm going to keep flailing around here, but one of y'all web devs is going to have to likely step up to help this poor, ignorant systems programmer.

Same issue here, but when trying to use the terminal from PyCharm (cmd/git bash/powershe;ll).
Regular powershell/git bash terminal works fine

@miniksa Try attached zip.
docker-compose-error.zip
Fyi. Compose works fine for simple configuration but fails when there are multiple containers, volumes.

That failed the first run, @shawinder, but then I ran it again and it was fine.

You know, this might be some sort of race between tartley/colorama decoding VT into Win32 calls and rprichard/winpty in its scraping loop to re-encode Win32 calls back to VT under VSCode. When I do get it to repro in VSCode, it's very flaky as if it is a race condition.
I'll keep looking around a bit, but being unable to have a reliable repro or understanding what parameters the colorama python module is actually trying to send and to which Win32 API is hindering my investigation.

You can see how colorama interacts with WIn32 API via ctypes here: https://github.com/tartley/colorama/blob/master/colorama/win32.py

@miniksa I tried running it multiple times and got the same error. Not sure how it works for you second time.
Traceback (most recent call last):
  File "docker-compose", line 6, in <module>
  File "compose\cli\main.py", line 68, in main
  File "compose\cli\main.py", line 121, in perform_command
  File "compose\cli\main.py", line 938, in up
  File "compose\project.py", line 417, in up
  File "compose\project.py", line 646, in warn_for_swarm_mode
  File "site-packages\docker\api\daemon.py", line 90, in info
  File "site-packages\docker\utils\decorators.py", line 46, in inner
  File "site-packages\docker\api\client.py", line 189, in _get
  File "site-packages\requests\sessions.py", line 488, in get
  File "site-packages\requests\sessions.py", line 475, in request
  File "site-packages\requests\sessions.py", line 596, in send
  File "site-packages\requests\adapters.py", line 423, in send
  File "site-packages\requests\packages\urllib3\connectionpool.py", line 595, in urlopen
  File "site-packages\requests\packages\urllib3\connectionpool.py", line 363, in _make_request
  File "httplib.py", line 1042, in request
  File "httplib.py", line 1082, in _send_request
  File "httplib.py", line 1038, in endheaders
  File "httplib.py", line 882, in _send_output
  File "httplib.py", line 844, in send
  File "site-packages\docker\transport\npipeconn.py", line 31, in connect
  File "site-packages\docker\transport\npipesocket.py", line 22, in wrapped
  File "site-packages\docker\transport\npipesocket.py", line 50, in connect
pywintypes.error: (2, 'WaitNamedPipe', 'The system cannot find the file specified.')
Failed to execute script docker-compose

@shawinder, that stack is different from the rest of them that were listed. Not sure what's up there.

@shawinder I think you forgot to do docker-machine env

For me it's not happening in ordinary Powershell, it seems I have quite a number of warnings from the backend in that docker I'm trying to run. I don't see Powershell having issues to display them nor any errors from colorama. I do have quite list of dependable on each other tasks in tasks.json like so. I suspect that the task runner might have some issues actually, like was mentioned before some race condition. Because I see python errors and various steps of the build docker tasks. I ran those tasks one by one in PowerShell without errors.
{
      "taskName": "docker:build-api-code",
      "type": "shell",
      "command": "docker-compose -f ../../build-pipeline/docker-compose.ci.publish.yml up ci-publish-api"
    },
    {
      "taskName": "docker:build-api-container",
      "type": "shell",
      "command": "docker-compose -f ../../build-pipeline/docker-compose.yml -f ../../build-pipeline/docker-compose.override.yml build financialwellness.api",
      "dependsOn": "docker:build-api-code"
    },
    {
      "taskName": "docker:run-api",
      "identifier": "run-api",
      "type": "shell",
      "isBackground": true,
      "command": "docker-compose -f ../../build-pipeline/docker-compose.yml -f ../../build-pipeline/docker-compose.override.yml up financialwellness.api",
      "dependsOn": "docker:build-api-container"
    },

I figured out the root cause this morning and I'm trying to devise a solution now.
It is a regression we caused in WriteConsoleA (https://docs.microsoft.com/en-us/windows/console/writeconsole), but the regression shows up only when someone is attempting to block the console output by generating a selection rectangle on the screen while a Python utility is outputting text.  WriteConsoleW is not affected.
The issue seems to be that when we service WriteConsoleA off of a wait routine, we provide a "lpNumberOfCharsWritten" byte count of more bytes than were initially put in by the client application. That is, when Python writes out the letter "a" to WriteConsoleA, it says it is 1 byte big in nNumberOfCharsToWrite. If we service the request right away, we respond and say lpNumberOfCharsWritten=1. But due to a logical error in capturing the information for later servicing with our wait routines, if it is serviced later off a wait routine, we will respond and say lpNumberOfCharsWritten=2. It appears something in the Python Runtime or a library it is leveraging to output text from behind Python streams is comparing the bytes given to the number we said were written and is throwing the Traceback when they mismatch.
You don't see it outside of VSCode much because I doubt any of you are clicking on your screen to generate a selection rectangle while docker-compose is outputting text to a standard CMD or Powershell session. If you did, you would almost certainly see the same Traceback as soon as you hit escape or otherwise cancelled the selection.
You don't necessarily see it with other applications much because most applications we see do one of the following:

Use WriteConsoleW to emit UTF-16 encoded text into the Windows console. The W version is not afflicted by this bug.
Use WriteConsoleA to emit codepage-encoded text into the Windows console but ignore the return codes and the feedback values like lpNumberOfCharsWritten.

You see it inside VSCode all the time because winpty-agent.exe is extremely rapidly injecting a "select all" command into the underlying console window in a very tight loop in an attempt to block any output while it scrapes out the screen with ReadConsoleOutput (https://docs.microsoft.com/en-us/windows/console/readconsoleoutput) and then injects an "escape" to stop the selection and let output resume. I'm not sure why the winpty-agent.exe authors do this as ReadConsoleOutput will take a lock on the underlying screen buffer and the contents cannot change while it is reading, but I presume they have a good reason.
Also, a special callout to whomever in the VSCode, Electron framework, or winpty-agent.exe pipeline is taking over the exception handlers for conhost.exe in this environment and killing everything whenever something goes wrong. That really made this one a peach to debug as I had to devise a workaround to get the console under a debugger without that getting in the way and killing the whole thing when an exception was generated.
I don't believe I need any more information to figure this one out. I'm staring down the code right now and trying to figure out the right way to return the correct byte count value off of a wait routine servicing a delayed WriteConsoleA call. I'll update the thread when I have a fix.
If there are any further questions as to the background or details, feel free to ask and I'll provide what I can for the curious. Thanks!

I have committed a fix for this into our branch today. We are heading into the holiday season around here, so I wouldn't expect to see it in the outside world until Windows Insider builds early next year.

@miniksa great! I'll close this off since it's an upstream issue.

While we wait for the fix to come in 2018,  you can fix the problem by install [git-scm](https://git-scm.com/download/win terminal and overwrite default power-shell terminal using following setting in VSCODE -> Preferences -> Settings:
{
    "terminal.integrated.shell.windows": "C:\\Program Files\\Git\\bin\\bash.exe"
}

@shawinder Or not. Makes no difference on my end.

@Tyriar is there somewhere we can subscribe since likely everyone has changed their workflows to avoid this issue and won't remember to try this anymore (esp after holidays) since now with the issue closed there won't be any notifications regarding updates.

@shawinder I tried that but still not working.

@miniksa I guess I'll leave this open, if you can please update here when the Windows update starts rolling out.

You see it inside VSCode all the time because winpty-agent.exe is extremely rapidly injecting a "select all" command into the underlying console window in a very tight loop in an attempt to block any output while it scrapes out the screen with ReadConsoleOutput (https://docs.microsoft.com/en-us/windows/console/readconsoleoutput) and then injects an "escape" to stop the selection and let output resume. I'm not sure why the winpty-agent.exe authors do this as ReadConsoleOutput will take a lock on the underlying screen buffer and the contents cannot change while it is reading, but I presume they have a good reason.

ReadConsoleOutput is atomic, but that's not good enough.
In the common case, winpty reconstructs a stream of output corresponding to what's in the console buffer. To do this, it needs to do several things atomically:

Figure out how much the console has scrolled.

Use GetConsoleScreenBufferInfo to get the window position.
Use WriteConsoleOutputW to write a "sync marker" into the older area of the console buffer.
Use ReadConsoleOutputW to find the "sync marker". If it has moved since it was written, we know how many lines the buffer has scrolled.

Read the cursor position (GetConsoleScreenBufferInfo)
Finally, it read the console data proper, including (a) everything that's currently visible, but also (b) lines that were visible during the previous scraping (ReadConsoleOutputW).

The final scraping uses ReadConsoleOutputW, which prior to Windows 8, can only read about 64KiB of data at once. A large console window can be too big to read in a single call. (e.g. 250 * 100 * sizeof(CHAR_INFO) == 100000).
Using selection doesn't prevent an app from modifying the console buffer, but it does block WriteFile/WriteConsole, which is good enough for the kind of console programs that winpty is trying to work with.
If winpty instead worked more like screen and only showed the currently visible console window, then it could presumably avoid using selection, but it'd be an inferior UX. e.g.:

It'd be unobvious how to view the scrollback. (a keybinding to move the console window?)
No more than 9999(?) lines of scrollback. (Maybe the limit's actually 16K or 32K; I'm unsure.)
When a program writes something, the console window snaps back to the bottom, making it hard to view the scrollback.
Searching the scrollback would be difficult.

It is a regression we caused in WriteConsoleA (https://docs.microsoft.com/en-us/windows/console/writeconsole), ...

@miniksa FWIW, when I was examining this issue, I saw that WriteFile was broken but not WriteConsoleA. https://github.com/Microsoft/console/issues/40

@shawinder  using bash works, thanks  In case it didn't just re-pull the images which are causing issues using git bash. Thanks.

@rprichard, both functions end up in pretty much the same area on our side. So the fix will apply to WriteFile as well.

@miniksa, I reached a similar conclusion about the bug several days ago, but only for a WriteFile request that's blocked by an active text selection. For me, WriteConsoleA works correctly in this case. I assumed they'd be handled by the same code in the console host, but you say it's "pretty much the same area".

This hit us hard the last 2 days, glad we found this, we're shifting our workflows elsewhere.  VSCode was primary use.  It fails every other time.

+1 same issue
Windows 10
VSCode
docker-compose

Had to fight some unrelated docker issues in the Windows Insider builds to test this, but it appears the fix gone out (observed on 17093).
Suggest people don't go jumping in right now though (unless they have a machine to treat as a guinea pig) due to those aforementioned issues. Linux containers were a no go for me (LCOW feature on the docker edge build withstanding).

I had the same issue on Windows 10 Home, I was able to fix it using the Docker Toolbox terminal.

That's not a "fix", just a workaround.

Still an issue with the latest version: 1.20.1 on windows 10 (screenshot below)
But on a positive note I may have discovered a real work around:
Run docker-compose version and note the output
Download the latest nightly build of the docker-compose binary from https://dl.bintray.com/docker-compose/master/
Backup your existing docker-compose.exe file (or don't blame me when this possibly doesn't work and you want to go back :innocent: )
Mine was located here: C:\Program Files\Docker\Docker\resources\bin
Copy the downloaded nightly file to the above path and rename it to docker-compose.exe
Run docker-compose version to confirm you're using the new binary
The version I'm using that's working so far:
docker-compose version 1.20.0dev, build 4ceeaad0
docker-py version: 3.1.0
CPython version: 3.6.4
OpenSSL version: OpenSSL 1.0.2k  26 Jan 2017
screenshot of failure with docker-compose version:
docker-compose version 1.18.0, build 8dd22a96
docker-py version: 2.6.1
CPython version: 2.7.14
OpenSSL version: OpenSSL 1.0.2k  26 Jan 2017

@bitcrazed , @chrisdias  - Are you tracking this as a generic VS Code issue or is this one related only to docker?  The reason I ask is because I'm seeing this with any colorizer.  Shall I use this issue to track generic colorizer fails or should I open a new issue?
Also, do you have an ETA on this fix?
Thanks,
Jon

I don't think this is related to docker, as I'm not using it on my machine but I am getting the issue with the integrated terminal.
It doesn't seem to happen when I run a separate PowerShell window and run the python script. I should also mention I'm using Anaconda 5.1.0 for python 2.7.
When initially opening the integrated terminal, Code seems to be running the following line
& cmd /k "C:\Anaconda2\Scripts\activate.bat & PowerShell"

@jonbgallant as I understand from @Tyriar this is a windows issue, not a VS Code, Docker, or VSCode Docker (extension) issue.

Yes it's a problem with Windows (see https://github.com/Microsoft/vscode/issues/36630#issuecomment-344030750, https://github.com/Microsoft/vscode/issues/36630#issuecomment-357084696). With a similar issue in the past I kept it open to make it easier for people to find the issue and not create a stream of duplicates for me to handle. We'll close this off when stable Windows starts getting the fix.

I was having a similar problem (post patch I assume v. 1.18.0 of Docker Compose), so I came here. In case anyone else has the same issue, I'll leave this for reference.
Was a longpaths issue for me due to Jenkins giving the project folder a unique code. I was able to complete my compose using powershell, but Jenkins gave my these errors:
Traceback (most recent call last):
  File "docker-compose", line 6, in <module>
  File "compose\cli\main.py", line 71, in main
  File "compose\cli\main.py", line 124, in perform_command
  File "compose\cli\main.py", line 959, in up
  File "compose\project.py", line 452, in up
  File "compose\service.py", line 308, in ensure_image_exists
  File "compose\service.py", line 967, in build
  File "site-packages\docker\api\build.py", line 150, in build
  File "site-packages\docker\utils\build.py", line 14, in tar
  File "site-packages\docker\utils\utils.py", line 100, in create_archive
  File "tarfile.py", line 1881, in gettarinfo
WindowsError: [Error 3] The system cannot find the path specified: u'C:\\Program Files
(x86)\\Jenkins\\workspace\\repo-name-7F4KYNQD36XGPFD43T2E7OJE3M35TAB44IFL6IX324UGUB4NSC2A@2\\www\\administrator\\components\\com_jfilemanager\\assets\\files\\adsfdfadsf
adsfdasf\\asdfasfdasfdaf\\asdfasdfasf.JPG'

Basically, my copy of the www folder in my compose file failed because the path was too long. I had to enable long paths on the windows server I had docker and jenkins installed on.
  www:
        build: .
        ports:
            - "8001:80"
        volumes:
            - ./www:/var/www/html/
        links:
            - db
        networks:
            - default

All I had to do was follow this:
https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/

I have the same problems but this is not related to:

Windows (I run the same command in powershell.exe/cmd.exe out of Visual Studio Code many times and never get this error)
long paths (path is short, less 32 chars)
virtual env (I don't use virtual environment)
docker (I don't use docker)

And this bug happens very often, for example, several times in a row

I have the same error and all I'm doing is running python code with no modules (also no virtualenv)
If I sequentially "run python file in terminal", the error references random lines each time (line 15, line 25, line 34) and then works, then throws the error again.

I was facing the same issues in November 2017 with the Fall Creators Update. I was able to delay this update until today. Now I'm unable to work with VSCode since all my compile and test scripts don't work anymore. I probably have to look for a different editor while this issue is open ;-(
I really beg you to fix this issue as soon as possible! I really don't want to abandon my beloved VSCode.
My original issue was this: https://github.com/Microsoft/vscode/issues/38068

I think it has something to do with print function - I was able to get around it by wrapping my print calls in a try block and then using print() in the except black, like this:
// Using python click
    def echo(self, text, color="", dim=False):
        try:
            click.secho(text, fg=color, dim=dim)
        except:
            print (text)

I've also had luck putting the futures print at the top of my python script:
from __future__ import print_function

Same issue here. Same command work in a separate powershell, not in the integrated terminal.

@Tyriar Is there a fix on the way? How can I get it earlier?

@Wosi it's fixed in the Windows Insiders channel https://github.com/Microsoft/vscode/issues/36630#issuecomment-359969098, you might not want to commit to that just to fix this though. It should be coming in the upcoming Spring release of Windows w

Appears to be fixed in the latest Windows 10 Spring Creators Update

@Box-Of-Hats It was fixed on Windows 1803!! YAY!!!

🎉 Closing this off as people are confirming it's fixed! If you're experiencing this problem make sure you have installed the Windows 10 April Update (1803).


Re-implement rust-in-macro faster

This function is called repeatedly by syntax-ppss and so needs to be
fast.  We adopt a simpler mechanism for determining whether we are in
a macro.
Fixes #208

r? @mookid
(rust_highfive has picked a reviewer for you, use r? to override)

Thanks for working on this! before diving into the code, do you have a benchmark to compare the old vs the new version?

Yep, best benchmark of all. I tried it with the new version and rust-mode feels fine, while without it feels terrible.
For something slightly more formal  I tried this:
(defun bench ()
  (goto-char (point-max))
  (message "%s"
           (benchmark-run 50
             (syntax-ppss-flush-cache 1)
             (syntax-ppss))))

With different benchmark forms, for elapsed, 10 and 50 times
Elapsed
new
0.204490421

old
0.497328317

benchmark-run-compiled 10
(1.3721566170000001 4 0.39234910600000106)
(4.620864861 7 0.6880264240000002)

benchmark-run 10
(1.2887137860000002 3 0.29979056699999873)
(4.579363357999999 7 0.6914120969999971)

benchmark-run 50
(6.617156954 16 1.616331799000001)
(23.228904235999998 36 3.5606590710000035)

So, only about 4 times faster by this metric. Their might be something else going on like the current implementation flushing the cache more often. I did look for this but could not find it happening.
Unwinding the recursion would probably give a bit of performance as well.

Unwinding the recursion would probably give a bit of performance as well.

yep, thats what I was thinking about.

Yep, best benchmark of all. I tried it with the new version and rust-mode feels fine, while without it feels terrible.
For something slightly more formal I tried this:
(defun bench ()
  (goto-char (point-max))
  (message "%s"
           (benchmark-run 50
             (syntax-ppss-flush-cache 1)
             (syntax-ppss))))

And for which source code do the forms run?

So, full code:

(defun rust-in-macro-old ()
  (save-excursion
    (when (> (rust-paren-level) 0)
      (backward-up-list)
      (rust-rewind-irrelevant)
      (or (rust-looking-back-macro)
          (and (rust-looking-back-ident)
               (save-excursion
                 (backward-sexp)
                 (rust-rewind-irrelevant)
                 (rust-looking-back-str "macro_rules!")))
          (rust-in-macro)))))

(defun rust-in-macro-new ()
  (save-excursion
    (let ((end-bound (point)))
      (when (and
             ;; Find first ! backward
             (rust-backward-to-macro-bang)
             ;; Find next paren
             (re-search-forward "[([{]" end-bound t))
        (backward-char)
        ;; Find matching paren
        (forward-list)
        ;; if point is now passed where we started, we are in a macro
        (> (point) end-bound)))))

(defvar bench-use-old t)

(defun rust-in-macro ()
  (if bench-use-old
      (rust-in-macro-old)
    (rust-in-macro-new)))

(defun bench-old ()
  (interactive)
  (let ((bench-use-old t))
    (bench)))

(defun bench-new ()
  (interactive)
  (let ((bench-use-old nil))
    (bench)))

(defun bench ()
  (goto-char (point-max))
  (message "%s"
           (benchmark-run 20
             (syntax-ppss-flush-cache 1)
             (syntax-ppss))))

Run with  point "raw_vec.rs" from liballoc I get these results
elapse
0.378334104
1.654185709

run 1
(0.390778682 0 0.0)
(1.992712346 1 0.3988344170000033)

run-compiled 1
(0.38834057 0 0.0)
(1.651837399 0 0.0)

run 5
(1.960683374 1 0.35779243200000366)
(8.343783432 1 0.3593990110000007)

run-compiled 5
(1.509828065 0 0.0)
(8.29346977 1 0.3554160189999962)

run 20
(6.496330834 1 0.36043094000000053)
(32.831416548 4 1.4240319729999982)

syntax-ppss does all the relevant calling. It's worth noting that the two implementations have different complexities; mine is linear, scaling with the number of "!" till the first macro, while  the old implementation is linear with rust-paren-level. So the old one scales badly with deeply indented code, while mine scales badly with people who shout a lot in their comments.
I've used this sort of bench because it's more realistic; rust-in-macro is getting called many times in many places in a buffer.

I have a large file which I loads quite slow in rust-mode. It feels even slower with this PR (e.g. instead of counting about 7 seconds for rust-format-buffer to finish, I count about 10 seconds with this PR; not very scientific I know, but still a good indication for me).
(Turning off Match Angle Brackets does make a very significant improvement without the PR, I haven't tested that with this PR.)

is linear, scaling with the number of "!" till the first macro… scales badly with people who shout a lot in their comments.

I think this is what causes the regression in my file, (count-matches "//.*!") returns 589 because of all the assertions in the doc examples in the file.

@tspiteri Well, if you are going to put tests into your files, then I have no sympathy for you at all. Can't you just delete them all?
I tried this with my bench code. You obviously have a faster machine than I because it takes me 70 seconds to run syntax-ppss, with current code, and indeed my PR makes that 170 seconds. Both totally unusable.
Hmm. I can think of ways of speeding this up more, but not simple ones. Let me cogitate.

@phillord

Well, if you are going to put tests into your files, then I have no sympathy for you at all.

Ouch :)

Can't you just delete them all?

They are doc examples, not tests. And the standard way to show the output of a function in a doc example is through an assertion, e.g. i32::saturating_add. And that's what I do, e.g. the Float::to_i32_saturating doc shows an example of no saturation, a saturation down, and a saturation up. Are you suggesting I should remove my examples?

I tried this with my bench code. You obviously have a faster machine than I because it takes me 70 seconds to run syntax-ppss, with current code, and indeed my PR makes that 170 seconds. Both totally unusable.

That difference seems a bit excessive, did you byte compile before measuring? (I'm not really knowledgeable of the elisp environment, but this is the equivalent of the Rust "Are you using --release?", and I always have to look up how to do it when I need it.)

"Are you suggesting I should remove my examples?"
It was my attempt at humour. I thought that the statement was outrageous enough not be taken seriously. Apologies!
"did you byte compile before measuring?"
No, although I have given it a go now and it still takes ages. Byte-compiling doesn't normally make that much difference, especially when most of the time is spent regexp matching and moving around the buffer which is mostly likely in this case. It takes 0.24 seconds with (setq rust-match-angle-brackets nil). The performance crappiness here, I believe, remains that we are operating in at least quadratic time to identify macro scope, when it should be possible with a linear scan.
Again, I will cogitate.

I tried to have a look, but the syntax stuff is all very alien to me. One idea I had is that in one “operation” there will be multiple calls to rust-in-macro, and they will all keep on looking back until
either they're out of nested parens (old) or out of bangs (new). But I think they keep looking over the same text. So maybe at the start of the operation initialize a variable bound to 0, and then any time rust-in-macro returns false, set bound to the position. Then, whenever for example there is a call to backward-up-list or rewind-irreleveant (old) or search-backward (new), if the position is before bound we know that we don't need to keep on looking.
I don't know if this works or not, as I don't know how syntax works or what an “operation” is.

I tried to have a look, but the syntax stuff is all very alien to me. One idea I had is that in one “operation” there will be multiple calls to rust-in-macro, and they will all keep on looking back until either they're out of nested parens (old) or out of bangs (new).

Yep, that's exactly the problem. In your file, rust-in-macro is called around 900 times to syntax parse the entire file.

But I think they keep looking over the same text. So maybe at the start of the operation initialize a variable bound to 0, and then any time rust-in-macro returns false, set bound to the position. Then, whenever for example there is a call to backward-up-list or rewind-irreleveant (old) or search-backward (new), if the position is before bound we know that we don't need to keep on looking.
I don't know if this works or not, as I don't know how syntax works or what an “operation” is.

The functions are a bit baroque, but it's syntax-ppss which is forcing the buffer parse to happen. This in turn calls rust-syntax-propertize which finally calls rust-in-macro. It would be worse if syntax-ppss was not cached, but the cache does get dropped regularly. I suspect that rust-in-macro gets called in some other places as well.
I tried something like your idea. I identify the scope of all macros in rust-syntax-propertize,  then rust-in-macro just checks whether point is in any of these scopes. Identification of scopes is done, but simply searching for ! followed by \w+[({ and then matching forward to the matching brace. It works, in that it brings the parse down to 4 seconds (from 70) on your very big file. Which is lovely, but for reasons I cannot fathom, it breaks indentation.
So this might be a good way forward if I can work out the breakage.
https://github.com/phillord/rust-mode/tree/fix-broken/faster-in-macro

This is another solution that is now nearly working. It finds the scopes in a linear scan and then uses them to answer rust-in-macro. It uses a safe cache through a let binding. There should be no problems with cache invalidation.
It needs a small extension (it does not cope with macro-rules which seems to have a bespoke syntax); and I will optimize further using the start and end parameters of syntax-propretize which should reduce it to a linear scan of the visible area. Nearly there I think.

So this is the performance for the latest patch. Still 6 times slower than with match-angle-brackets to nil, but a lot faster than the current implementation. Still does not handle macro_rules yet, which will slow it down a bit more, unfortunately.
;; big.rs
;; run-5
;; old, new, match-angle-brackets
;;<PHONE_NUMBER>8100005 7 3.090328318999994)
;; (20.047772558 7 2.9489682509999966)
;; (3.7125402989999996 2 0.8323715489999941)

I tried this and it works great! (To test it I added
(and (looking-at rust-re-ident)
     (goto-char (match-end 0))
     (skip-chars-forward " \t\n\r")
     (eq ?\{ (char-after)))

after the checks for ?\[, ?\( and ?\{.)
Now rust-in-macro + rust-macro-scope are using less than rust-is-lt-char-operator and about the same as the rust-in-str-or-cmnt directly inside rust-ordinary-lt-gt-p.
- rust-syntax-propertize                            186  41%
 - rust-ordinary-lt-gt-p                            149  33%
  + rust-is-lt-char-operator                         79  17%
  + rust-in-str-or-cmnt                              45  10%
  + rust-in-macro                                    20   4%
  + rust-paren-level                                  5   1%
 + rust-macro-scope                                  29   6%

HI Phil,
thanks for that work!
I am reviewing the patch during the weekend.

I was testing some, and this reduced test case seems to confuse it:
x! { 1 < 12 }

I looked into it and I believe that when we first assume all [<>] are parens and then suppress afterwards, we are confusing things as then (forward-list) inside rust-macro-scope is confused and thinks the < matches the }. So I tried to remove ?< and ?> from rust-mode-syntax-table and then inside rust-syntax-propertize add the text property instead of removing it.
This fixed things for me, but then the electric pairs test failed, presumably because electric pairs look at the syntax table which now has no < and >, so it is broken. Maybe there's a better way to unconfuse the use of forward-list in rust-macro-scope without breaking the syntax table, but I don't know.

I managed to get it to work by using with-syntax-table inside rust-macro-scope.
https://github.com/tspiteri/rust-mode/commits/both-opts

I've updated it with a some more tests cases and stopped it breaking on unbalanced buffers. I will address the comments above next!

@tspiteri With this example,
x! { 1 < 12 }

Can you tell me what it is you find is confused? I can't see what is wrong.

@phillord Before the balance fixes (so on commit 05a7ef6), if I created a file with only that content, the brackets would be detected as an unmatched { and a mismatched < }. That has already been fixed by your do-not-require-balance fix.

As far as I can see, we are complete now, except for one question depending on the outcome of https://github.com/rust-lang/rust-mode/pull/373 and a big squash. I am afraid I have made the code review above a bit of a mess, but are there any other needed fixes>

Found a bug yesterday. I'd like to use this in practice for a week (didn't write much rust in the last few days because I have been doing lisp) to see if anything else uncovers. @tspiteri I presume you are using it in real life also?

@phillord Yes I'm using it as well. In fact I had thought there was an issue with some highlighting near the point, but it turns out it was lsp-mode that was causing the issue - I have had no issues yet using rust-mode without lsp-mode, but I'll keep on using it and will let you know if anything else comes up.

@phillord Yes I'm using it as well. In fact I had thought there was an issue with some highlighting near the point, but it turns out it was lsp-mode that was causing the issue - I have had no issues yet using rust-mode without lsp-mode, but I'll keep on using it and will let you know if anything else comes up.

That might also have been the bug from yesterday; errors during syntax highlighting are demoted, and only show as messages, but leave the highlighting broken.

It could be: I can't reproduce it today while two days ago I could easily. What threw me off is that when I disabled lsp-mode just to make sure, for some reason I wasn't be able to reproduce it.
On another note, I found an issue with nested macros:
macro_rules! outer {
    () => { vec![] };
}
// rust-macro-scope returns ((46 48) (20 31))
// which correspond to ("[]" "{\n    () =>")

A false positive for rust-macro-scope occurs with the bitwise complement of a bracketed expression.
fn foo<T>() {
    if !(mem::size_of::<T>() > 8) {
        bar()
    }
}
// rust-macro-scope returns ((23, 45))
// which corresponds to ("(mem::size_of::<T>() >")

And in the previous test case above, there was also a mismatch with the "> 8" bit but it did not hurt bracket matching. However below there is a mismatch which does break bracket matching. (This time the exclamation mark is in a proper macro to keep the issues separate.)
fn foo<T>() {
    if mac!(mem::size_of::<T>() < 8) {
        bar()
    }
}
// rust-macro-scope returns ((26, 75))
// which corresponds to ("(mem ... bar()\n    }\n}")

@tspiteri Well, that's hard. It depends on how rigid and accurate we want to be. Consider this:
fn foo<T>() {
    if !(mem::size_of::<T>() > 8) {
        bar()
    }

    dbg !(mem::size_of::<T>() > 8) {
        bar()
    }

    dbg!{hello}
}

I can distinguish between the if and last dbg!{} straight-forwardly using rust-looking-back-macro. But between the first dbg with a space (dbg !), well that's harder. I guess it rust achieves this because if is a keyword.
I'm a bit loath to add that sort of complexity into the checking, so my suggestion would be to fix this but accept that it breaks the second usage dbg !(). WDYT?

I agree with your wariness to complexity, and I like your solution. After all dbg !() is quite uncommon and I think considered bad style. Handling it would not be worth any loss of performance and potential bugs from the extra complexity.

I'll do that they. I actually had to check whether dbg !() was valid syntax when I wrote the first version of it.

@tspiteri
macro_rules! outer {
    () => { vec![] };
}
;; returns ((38 40) (20 45)))

I think this is working as I expected. So, something appears to have fixed this in the last few days.
Been a long haul, this fix, but nearly there, I hope!

I opened the files I had left for those cases and bracket matching works as expected in them.
I've been using this and basically now I can leave Match Angle Brackets On with the same feel as with it off, so for me it's already there. And I wouldn't worry about the corner cases: the worse it would probably do is maybe break some bracket matching around some weird macros, but even without this patch, I used to get mismatched brackets all the time when I used Angle Brackets On; in fact I get the feeling that even bracket matching has improved, not just performance.

I have written some code now with this and @tspiteri  hasn't found anything else, so I think we are good to go here. If we find any other problems, I can fix them on master.

I can fix them on master.

Indeed.
If you prefer to preserve some history feel free to push again.
Thanks @phillord and @tspiteri for the work on this!

Thanks @phillord!


[Update][Easy New File] Optimize file operation

Description

Optimize the selection of files and directories
List layout add Detail show file icon
Some minor view interface updates

Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

@Angelk90 Given that this location is typically used for search (User Intuition + other extensions are search functions), I wouldn't just turn the search bar into an input box for typing filenames.
But I will consider adding a setting to toggle this feature


Possible memory leak or unbounded memory usage?

Hi @ian-kent
Been using websysd for about two weeks for a small project on production.
It has been really useful and has been making managing processes much easier.
Though I've noticed that after a few days usage, that websysd process itself uses a huge chunk of memory. (The processes that it manage have stable memory footprint though)
On my 512MB DigitalOcean droplet, it would start with 6% memory usage, before eventually using 50% after several days, before I had to kill it and restart websysd.
This issue seems worst when the logs are stored in-memory by default (which makes perfect sense).
While setting the STDOUT and STDERR config helps, currently it just delay the inevitable.
Could you kindly advise a way to work around this or help to improve websysd memory usage?
Below is my current config files
global config
{
  "Environment": {
    "GO15VENDOREXPERIMENT": "1",
    "WEBSYSD": "true",
    "PROD": "1",
  },
  "InheritEnvironment": true,
  "Functions": {
    "DiskUsage": {
      "Args": ["$PATH"],
      "Executor": ["/bin/sh", "-c"],
      "Command": "du -sh $PATH"
    },
    "GitBranch": {
      "Args": ["$PATH"],
      "Executor": ["/bin/sh", "-c"],
      "Command": "git --git-dir $PATH/.git rev-parse --abbrev-ref HEAD"
    }
  }
}

workspace1
{
  "Name": "main",
  "Environment": {
    "WORKSPACE": "main"
  },
  "Columns": {
    "Disk usage": { "DiskUsage": [ "$PATH" ] }
  },
  "Tasks": [
    {
      "Name": "ngrok",
      "Command": "ngrok -log=stdout 4001",
      "Stdout": "/home/sogko/logs/$TASK-$RUN.out",
      "Stderr": "/home/sogko/logs/$TASK-$RUN.err"
    },
    {
      "Name": "cron",
      "Environment": {
        "LOGLEVEL": "info"
      },
      "Command": "my_cron",
      "Stdout": "/home/sogko/logs/$TASK-$RUN.out",
      "Stderr": "/home/sogko/logs/$TASK-$RUN.err"
    },
    {
      "Name": "main.go",
      "Environment": {
        "LOGLEVEL": "warning"
      },
      "Command": "my_server",
      "Stdout": "/home/sogko/logs/$TASK-$RUN.out",
      "Stderr": "/home/sogko/logs/$TASK-$RUN.err"
    }
  ]
}

Note: Currently I'm trying to see if removing custom columns (for e.g. the Disk Usage here) would help to improve the situation.
Thanks! 👍🏻

Update:
It has been roughly 5 days since I've tried again by removing custom columns and websysd seems stable, staying below the 1% MEM range.
Closing this since workaround is available.
Cheers!

Thanks @sogko - I'll reopen it until I fix it properly, it definitely shouldn't keep consuming more memory even if custom columns are enabled!

Hi @ian-kent
Awesome, thanks for looking into this 👍🏻
I'll try to provide more details / updates when I come across any.
Cheers!


iOS - Add Privacy Manifest

Summary
Added an empty Privacy Manifest to the iOS project in preparation for the May 1st Deadline for 3rd Party SDKs that include native iOS code.
Description

Starting May 1: You’ll need to include approved reasons for the listed APIs used by your app’s code to upload a new or updated app to App Store Connect.
...
Make sure to use a version of the SDK that includes its privacy manifest and note that signatures are also required when the SDK is added as a binary dependency.

Privacy updates for App Store submissions - Latest News - Apple Developer
Upcoming third-party SDK requirements - Support - Apple Developer
Impact and Testing
Developers using an updated version of this library on their iOS projects shouldn't see any issues related to the Privacy Manifest
Contributor Note
Based on the language on Apple's Website, this change seems to be mandatory for all 3rd Party Libraries. The impact of not adding it is unclear to me, but hopefully having it will be better than not.

@mogol  can this be merged in and a release created please?

@simonpham as the new Apple requirement is rolling out tomorrow it would really benefit to get this PR merge asap. Any updates?

@simonpham @martin-headspace Can one of you merge this PR in order to release a new version as soon as possible please ?

Hey @idrisAd , unfortunately I don't have write access to this repo 😔

@juliansteenbakker - Is this something you may be able to help with? 🤞


Ensure wire always contains a full H/2 frame (#15)

Use atomic operations for reading frames.
If reading the payload of a frame times out (after reading the header), it puts the stream in an odd state.
Types of Changes

Bug fix.

Contribution

[x] I added tests for my changes.
[x] I tested my changes locally.
[x] I agree to the Developer's Certificate of Origin 1.1.

@maruth-stripe @fables-tales I'm considering this PR again.
Not only do we have instances of read_header + read_payload, we also have instances where we have continuation frames on the wire, which have no meaning once the original frames are read. The latter case concerns me, as we can't easily protect against that. We can still do our best to only read full frames, but that won't correspond to a full semantic interpretation of headers + continuation.


Cyt 383 support running external tools syft

Merging the Syft plugin into the main branch.

I'll do another pass through this soon and try to get it merged. What I'm currently thinking is #83 will get merged first which makes some changes to the core directory traversal loop and information passed to the extract_file_info hook to enable additional analysis of files that a plugin might extract from another one -- there could be some ways to use that instead of creating a new hookspec that is fairly similar.

@CCBromia if the changes look okay with you, I can take care of applying + testing them.


test

Codecov Report

Merging #15 (b73f153) into main (ab822e3) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #15   +/-   ##
=======================================
  Coverage   54.29%   54.29%
=======================================
  Files          39       39
  Lines        3597     3597
=======================================
  Hits         1953     1953
  Misses       1531     1531
  Partials      113      113

Continue to review full report at Codecov.

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


Uploading models to Huggingface

I wanted to ask If I am allowed to upload the models to HF with full credit to you. I am asking this because platforms like Dropbox are unreliable and many other projects have been lost due to hosting issues.

Yes. The code is released under the MIT license, and the models are released under the Creative Commons Attribution 4.0 International License license. You are free to do anything as long as you comply with the license.


%history -f hangs with existing file

In [1]: %history -f C\test.txt   => works as expected
In [2]: %history -f C:\test.txt   => hangs
%history should overwrite the file or ask for confirmation first.

Based on the behaviour in a notebook, it's asking for confirmation and we're just not letting it through.

I guess there's a stdin request of some sort that we're not dealing with.

We're closing old issues with no recent activity. If this is still important, please open a new issue.


Support Environment Variables in internalLogFile/NLOG_INTERNAL_LOG_FILE

As of now, the internalLogFile or NLOG_INTERNAL_LOG_FILE can only contain paths to files where NLog will write its internal log messages:
<nlog internalLogFile="d:\logs\nlog.txt">
setx /M NLOG_INTERNAL_LOG_FILE "d:\logs\nlog.txt"

When hosting multiple applications on a single machine, it would be nice to have those logs separated by Process ID, Application Pool Name or whatnot.
This can be done by, as usual, adding an extra level of indirection:
<nlog internalLogFile="%APPLICATION_LOG_ROOT%\%APP_POOL_ID%\nlog.txt">
setx /M NLOG_INTERNAL_LOG_FILE "%APPLICATION_LOG_ROOT%\%APP_POOL_ID%\nlog.txt"

(in this example, %APPLICATION_LOG_ROOT% is a system-wide environment variable, and %APP_POOL_ID% is set automatically for each application by Internet Information Services).
The required change looks trivial enough (InternalLogger.cs):
    private static string GetSettingString(string configName, string envName)
    {
        // ...
        // Existing code goes here
        // ...

        settingValue = Environment.ExpandEnvironmentVariables(settingValue);
        return settingValue;
    }

Now that I think about it, [https://github.com/NLog/NLog/blob/master/src/NLog/Common/InternalLogger.cs#L283](this location) is where the magic should happen.

Now that I think about it, this location is where the magic should happen.

Yes, I think also :)
Looks good! PR would be great. please not that maybe this isn't supported on all platforms (Silverlight etc), just use #if etc.

Will do.

Backwards compatibility?
When older versions of NLog will encounter an environment variable placeholder in LogFile, the File.AppendText() call will fail, most likely with DirectoryNotFoundException.
The only way of resolving this is to introduce another environment variable (e.g. NLOG_INTERNAL_LOG_FILE_EXT) and use it first, and only if it is missing fall back to the original NLOG_INTERNAL_LOG_FILE.

The environment variables are between % isn't?
As the internal log isn't a production tool, i think the small breaking change isn't a prob

Julian,
Breaking change warrants 5.0, doesn't it?

On 15 Jul 2017, at 22:02, Julian Verdurmen<EMAIL_ADDRESS>wrote:
The environment variables are between % isn't?
As the internal log isn't a production tool, i think the small breaking change isn't a prob
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Nah, does't look like a good idea after all. Internal logging should be robust and reliable, yet with this change previous versions of NLog will be failing all over the place.
@304NotModified, it's your call. Should I introduce another environment variable or just close this issue for good?

Nah, does't look like a good idea after all. Internal logging should be robust and reliable,

agree, but do you think  Environment.ExpandEnvironmentVariables(settingValue) would be unstable?

Breaking change warrants 5.0, doesn't it?

Breaking changes in production stuff indeed (targets, layouts, rules), but not for the internal log. IMO the internal log is a debug tool and is not meant for parsing etc.

do you think Environment.ExpandEnvironmentVariables(settingValue) would be unstable?

It's not that. The NLOG_INTERNAL_LOG_FILE is global, so every application running on the server will start attempting to write to an internal log, which they will be unable to do successfully, since File.AppendText("%TEMP%\nlog.txt") will throw an exception on each and every call.

ah the problem is there when you mix older and newer versions of NLog, isn't?

I agree, impact to high. Won't fix.
Thanks for your feedback!


Adding BraceMatching operation

Adding an operation to extract the contents between the opening and closing brackets (user defined), with options for ignoring brackets in strings and escaped brackets

removing PR


[pylode] Creator and publisher missing in generated docs

See for example https://nfdi4cat.github.io/voc4cat/v2023-08-17/voc4cat/
There are values (urls) in the concept scheme turtle file (actually a wrong but valid url).

The problem is how the link title is extracted in pyLODE. name = agent_node.split("/")[-1].split("#")[-1] results in an empty string if the url has a trailing slash.

Fixed in the custom pylode-2.x that will be installed starting from the next release of voc4cat/template.


Installments still visible for debit cards in version 5.35

Describe the bug
Debit card show installment, even with the condition added in the v5.35 to specifically not display installments for debit cards (PR: https://github.com/Adyen/adyen-web/pull/2013/files)
To Reproduce
Steps to reproduce the behavior:

Go to the payment page
Click on card input
Enter a debit card number
Installments select is visible

Expected behavior
The installments select should not be visible for debit cards, only for credit cards
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
All browsers
Smartphone (please complete the following information):
All devices
Additional context
This issue has already been created (and closed) here: https://github.com/Adyen/adyen-web/issues/1882
We tried upgrading our version of adyen-web to 5.35 but still got this issue.
(Not sure but) it seems the prop 'fundingSource' is never passed to the CardInput component.
Some of the debit card test number i used to test this (retrieved from https://docs.adyen.com/development-resources/testing/test-card-numbers):
4871 0499 9999 9910
4035 5010 0000 0008
2222 4000 7000 0005
4111 1120 1426 7661
4000 0600 0000 0006

Hey @flemenach ,
You should pass the property splitCardFundingSource when requesting payment methods or creating the session.
This way, the API will return two different payment methods for card (one for credit, one for debit), in which the debit one does not display the installments options.
Are you properly setting the splitCardFundingSource properly? Are you passing any extra configuration to the SDK related to installments?

We didn't use this parameter, but we want to display a single payment method for credit cards and debit cards.
Since it is possible to detect if a cart is a debit or credit card with the first digits (6 maybe?), the installment select should appear only if we are sure the card is a credit card, even with a single payment method

Hi @ribeiroguilherme, we agree with @flemenach last comment.

I am afraid we can't do much here. We currently can't detect if the Card is debit or credit - this information is available after processing the payment, and not before.
I also discussed internally with the team other options. We could potentially return this on the bin lookup step, but this would require big investigation and effort from different teams, which isn't on our roadmap/priority list right now.
For now, the only solution is to use the splitCardFundingSource as mentioned above. Cheers!


author tape itself as ES Modules

I'm wondering if plans could be made to convert tape to use ES modules, which finally bring a universal module format to JavaScript engines, both in the browser and in Node.js. Right now I am personally having difficulties using tape in the browser because of its use of require statements, and my use of a build system that assumes ES modules. Ideally no build system would be necessary and ES modules seems like a great candidate for allowing that.

node has not yet shipped ESM support unflagged; until it does, it's not appropriate to ship ESM with any package.
I'm not sure what "WAS modules" are, but I'm assuming you mean "ES modules"
Every package that uses require should be bundled.

A build system is, and always will be, necessary - when node has ESM support, packages that ship it will be using non-URLs in their import statements, which browsers won't understand - you will still always require a build process to transform those to URLs, or to bundle them up.

@bennypowers you could certainly use that.

Just to be clear: there's no drop in solution for using the esm package - test authors would need to add the following to their test entrypoint
// Set options as a parameter, environment variable, or rc file.
require = require("esm")(module/*, options*/)
module.exports = require("./main.js")

is that what you meant, or am I misunderstanding?

node --require=esm path/to/tape/test.js?

If I'm understanding the issue at a glance, it has to do with web (browser)? What about node, is there a way to pass --experimental-modules to tape as you would do node  --experimental-modules ?

@OKNoah there’s not, currently, although that seems like a reasonable feature request.

Actually, I've gotten around this issue using Puppeteer for all my tests (where needed). It's gotten pretty mature from its earlier wild west days.
Re: es6 modules https://caniuse.com/#feat=es6-module shows the 6 my team cares about having module support. We're lucky being somewhat bleeding edge I guess. We no longer use non-module libraries.
We are helping projects we depend on be es6 ready.

Three.js: three.module.js already exists, only the examples/ are still es5 .. which include controllers we need. For those, several of us had written scripts to convert them to es6. And the most active Three issue is how to manage conversion of these to umd/esm pairs.
Two.js: only needed the package.json help below, and are releasing that form next publish.
dat.gui: I looked at the code and found out it was nearly there and just needed 4 changes. They did and we're go.
d3: already there and fine grained: 30 sub-repos! And taught us the unpkg trick of having a single npm package export both UMD and ESM via the package.json module: xx field.
hard-cases: we use a "wrapper" around es5 to convert them to a module while helping them refactor to ESM src/ files with Rollups to UMD and ESM pairs, using the package.json stunt for access to both via unpkg & ?module. Here are somewhat old references:
https://medium.com/@backspaces/es6-modules-part-1-migration-strategy-a48de0b7f112
https://medium.com/@backspaces/es6-modules-part-2-libs-wrap-em-up-8715e116d690

@backspaces .module.js isn't a thing; .mjs is the upcoming standard in node. The "module" field is nonstandard, and will be unnecessary the instant node ships an unflagged modules implementation, so you'll want to have .mjs files ready for when that happens.
Separately, although there's a "package name maps" proposal for browsers, until it lands, for any ESM modules to run in both node and browsers without a build step is effectively impossible.

Sweet! Could you do us all a favor? When you do the conversion, write it up on medium or in the project wiki?
I ask because it really is hard for folks to grasp yet-another technology and it would good to help them out.

@backspaces i'm not sure what "conversion" you mean; the instant node supports ES modules, tape will. As for users; any file with .js is a normal CJS module, and .mjs is ESM.

That definitely will work, but note the “experimental” part - it is highly likely to break over time.

Of course! I take the risk using anything experimental. 😀
I mostly made the comment because as I was reading through it was requested that the ability to do so be added to tape. The comment was confirmation that the functionality already exists.

It's not that jsverify won't work in Node with ES modules enabled, it will because node is still using its CommonJS variant as well as ES modules. The point of this issue is to author jsverify with ES modules, so that the source code itself is written with ES modules, and then it will work natively in browsers and Node without build steps, once modules are no longer experimental in Node.

FWIW .mjs is not 100% accepted yet, afaik

Yes, it is. I’m on the modules working group and although other mechanisms may be implemented, there’s basically zero chance mjs won’t be the base disambiguation mechanism.

2019 is almost over. What's the status of this issue?

@cowwoc the date is irrelevant; until node ships ESM unflagged, there's no change in status.

@ljharb Thank you for the clarification. Per https://2ality.com/2018/12/nodejs-esm-phases.html#when-can-i-use-es-modules-on-node.js%3F this will happen on April 2020.
Are you saying you don't plan to begin working on this feature until then? If so, we will be waiting longer than April 2020 for this feature. Would it be possible to begin working on this feature ahead of time with an estimated delivery date shortly after April 2020?

That's a bit out of date; it may happen sooner, but yes, it means the feature won't be worked on until then.
Even if this project is native ESM, though, you still won't be able to use it without a bundler (or without the project using one in advance), because it's a node module. This will be true of virtually everything on npm. You can use tape in a browser now with the same bundlers that have worked for years; there's zero reason anyone needs to wait on tape - or anything else - being native ESM.

@ljharb I'm trying to run tests written in ES6 using tape in npm (no browser involvement). What's the status of this kind of deployment? Should I be able to do this today?

In node? tape being written in ESM has zero impact on that. Since node itself can’t handle ES Modules unflagged, you need to be using babel - either in advance, or via babel/register - just like you would with every single other test runner.

@ljharb So in theory, if (today) I run tape with node --experimental-modules then I should be able to write my tests in ESM and test code that itself is ESM?

Yes.
This issue is about tape itself being authored in ESM - it never has nor ever will have any bearing on how your tests are authored.

@ljharb Okay. Thank you for the clarification.

Even if this project is native ESM, though, you still won't be able to use it without a bundler (or without the project using one in advance), because it's a node module. This will be true of virtually everything on npm. You can use tape in a browser now with the same bundlers that have worked for years; there's zero reason anyone needs to wait on tape - or anything else - being native ESM.

I do not believe this statement is true. There is a standard in progress called import maps. I've used them experimentally in Chrome, and they work. This should allow users to use code authored with ES modules without a bundler. The only build step required for vanilla JS code would be to generate the import map, which can be done with a simple npm script after running an npm install.
More info: https://github.com/WICG/import-maps

That presumes the modules are using functionality that is all present in the browser, or imported but shimmable in the browser, and doesn’t use anything globally available in node including environment variables. I’d be interested to see a study done on npm for how many things would qualify, but i suspect it won’t be that many.

One of the strong advantages of tape is that it works with ES3/5. It also works with older versions of nodejs.
This makes it possible to test older versions for legacy back compat.
It would be a shame to lose that advantage.

We’d never switch wholesale to ESM for that reason; but if there’s a way to do dual packages, it’d be fine to ship both implementations.

There is always a way, using rollup.js, parcel.js or equivalent.

dual packages means that consumers can require or import the same specifier and get the appropriate implementation; if you’re willing to use a bundler this issue’s been irrelevant for a great many years.

@ljharb Correct me if I'm wrong, but I believe you can easily go from ES modules to AMD and older formats but not the other way around.

You can easily go from ESM to CJS, which is what the majority of the ecosystem has been doing with Babel for many many years. AMD isn’t a factor.

Since it looks like I'm not the only one finding this issue when trying to get Tape tests on code containing ES modules to work, here's a separate issue for that: https://github.com/substack/tape/issues/514

Annoyingly, many modules are dropping CJS support altogether: https://github.com/sindresorhus/meta/discussions/15
This guy is migrating over 1000 packages away from CJS. And he's just one person.
So now my library, which depends on strip-ansi, can no longer run unit tests.

@cowwoc and as a result, his packages will likely lose users, because making ESM-only packages is incredibly user-hostile.
You can use strip-ansi all you want - just not the latest major version, which adds nothing except inconvenience.

Honestly I'm glad to see that. The bifurcation of JavaScript packages into ES Modules for web and CommonJS for Node.js has been painful for years, especially if you're trying to write something that works in both environments. And I don't see another way around it except moving toward ES Modules, sooner or later, and preferably sooner.

And to be fair... https://caniuse.com/?search=modules
3-4 years ago, there might have been an excuse to bend over backward for CJS. Nowadays, I simply don't understand it. The cost/benefit has changed drastically.

@donmccurdy CJS will be around forever. The only way to avoid bifurcation at this point is to drop ESM, and that's clearly also too late - thus, "two module systems" will be around forever.
@cowwoc The cost of CJS is minimal - bundlers remain required (native ESM in the browser is slow) and babel remains a best practice, even with native ESM. The benefit of switching to ESM is also minimal - CJS and ESM are precisely as tree-shakeable and statically analyzeable, etc - I'm not aware of any feature or capability that ESM has that CJS does not.

While a dual package is now possible, and we've already added the "exports" field (which would normally be a breaking change), it remains unclear what the benefit would be.

Other than the two people on this thread who actively develop tape itself (me included), why does it have any impact on the rest of you how tape is authored? I'd love to understand the use cases (note that "no build process" is both not practical nor wise, now or for the foreseeable future, so I'm curious about other use cases than that).

@ljharb this is a subjective opinion, but I expect CJS usage to decline significantly over the next 2-4 years. The advantages of ESM in for web developers are not minor — in theory you can tree-shake CJS, but in practice that is harder, and certainly modern bundlers are not investing as much in it.
I'm participating on this thread because testing ES Modules with Tape has been more challenging than testing CJS (see https://github.com/substack/tape/issues/514), and internal adoption of ES Modules might improve that situation. But certainly, please develop Tape however you prefer, the module syntax used by Tape itself is not (directly) my concern.

@donmccurdy noted. this issue is solely about tape's authoring format; tape should support testing ESM files regardless.

If you really care about ESM, then you can check out other projects like https://github.com/Raynos/tapzero
I had the misfortune of working on an ESM-only project and ended up using this ( barely tested, probably buggy ) library.
The main benefit of this library over tape was that it did not require any node builtins and worked nicer with whatever ESM build tool I was using.
I'm sure there's other testing libraries that are actively natively authored as ESM modules and do not support commonJS.
I would not recommend it, but if your stuck between a rock and a hard place then it's an option.

I'm going to close this for now; #547 provides support for the tape runner itself to be able to run on ESM files.
If anyone can answer:

Other than the two people on this thread who actively develop tape itself (me included), why does it have any impact on the rest of you how tape is authored? I'd love to understand the use cases (note that "no build process" is both not practical nor wise, now or for the foreseeable future, so I'm curious about other use cases than that).

then I'd be happy to reopen it.


Force-closing a channel whose registration task was not accepted by an event loop

Sometimes Netty terminates connection abruptly with this stacktrace:
18:38:46.904 [nioEventLoopGroup-34-1] WARN  io.netty.channel.AbstractChannel - Force-closing a channel whose registration task was not accepted by an event loop: [id: 0xcfbdfd31, /<IP_ADDRESS>:36412 => /<IP_ADDRESS>:8888]
java.util.concurrent.RejectedExecutionException: event executor terminated
        at io.netty.util.concurrent.SingleThreadEventExecutor.reject(SingleThreadEventExecutor.java:707) ~[netty-common-4.0.29.Final.jar:4.0.29.Final]
        at io.netty.util.concurrent.SingleThreadEventExecutor.addTask(SingleThreadEventExecutor.java:299) ~[netty-common-4.0.29.Final.jar:4.0.29.Final]
        at io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:690) ~[netty-common-4.0.29.Final.jar:4.0.29.Final]
        at io.netty.channel.AbstractChannel$AbstractUnsafe.register(AbstractChannel.java:421) ~[netty-transport-4.0.29.Final.jar:4.0.29.Final]
        at io.netty.channel.SingleThreadEventLoop.register(SingleThreadEventLoop.java:60) [netty-transport-4.0.29.Final.jar:4.0.29.Final]
        at io.netty.channel.SingleThreadEventLoop.register(SingleThreadEventLoop.java:48) [netty-transport-4.0.29.Final.jar:4.0.29.Final]
        at io.netty.channel.MultithreadEventLoopGroup.register(MultithreadEventLoopGroup.java:64) [netty-transport-4.0.29.Final.jar:4.0.29.Final]
        at io.netty.bootstrap.ServerBootstrap$ServerBootstrapAcceptor.channelRead(ServerBootstrap.java:251) [netty-transport-4.0.29.Final.jar:4.0.29.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308) [netty-transport-4.0.29.Final.jar:4.0.29.Final]
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:294) [netty-transport-4.0.29.Final.jar:4.0.29.Final]
        at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846) [netty-transport-4.0.29.Final.jar:4.0.29.Final]
        at io.netty.channel.nio.AbstractNioMessageChannel$NioMessageUnsafe.read(AbstractNioMessageChannel.java:93) [netty-transport-4.0.29.Final.jar:4.0.29.Final]
        at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511) [netty-transport-4.0.29.Final.jar:4.0.29.Final]
        at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468) [netty-transport-4.0.29.Final.jar:4.0.29.Final]
        at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382) [netty-transport-4.0.29.Final.jar:4.0.29.Final]
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) [netty-transport-4.0.29.Final.jar:4.0.29.Final]
        at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111) [netty-common-4.0.29.Final.jar:4.0.29.Final]
        at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137) [netty-common-4.0.29.Final.jar:4.0.29.Final]
        at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
[

I am at Ubuntu 14.10, Java build 1.8.0_51-b16

@Unisay - A channel is attempted to be registered to an event loop that has been shutdown, thus the registration fails and the channel is closed. I take it that you are requesting that this behavior (channel is closed) changes? If so, do you have any suggestions. If not can you explain the issue?
Why is the event loop being shutdown?

@Scottmitch
Unfortunately I have only rough idea of what is "channel registration" and "event loop".
In my integration tests I use mockserver-netty. For every test (sequentially) I start and stop mockserver (which starts-stops netty). Sometimes start happens just after it has been stopped. I can provide more detailed logs of netty a bit later.

@Unisay basically this means you try to register no channels to a EventLoopGroup after it was shutdown. There is nothing we can do about this. It's kind of the same like shutdown a ExecutorService and calling execute(Runnable) after it.


incorporated slight gramatical and spelling corrections

I tried to make grammatical and spelling corrections while preserving the integrity of what was trying to be communicated.  Thanks for making an awesome plug in!

Hello Septimis.
Thank you for the grammatical and spelling corrections!


Giphy - social & fun integration

What do you think about adding (somehow) possibility to display gifs?
I did not do research so I only know whats possible from giphy site.
I'd like to know the community's opinion.

I think this would be a reasonable integration to add; it's definitely in the category of 2-way integrations (since one needs a way to notify Giphy), so it's something to think about when designing our solution(s) in the general space of #735

This was implemented recently; see contrib_bots/lib/giphy.py.


fix(openshift): prevent race condition in the clusteroperator controller

Use a deep copy of the target ClusterOperator in SyncTracker to avoid unsafe concurrent access.
Signed-off-by: Nick Hale<EMAIL_ADDRESS>

/lgtm


Adds new icons for FoW

Accessible
Cart
Crops
Github
Hospital
Man
Man woman
Map
Marker
Medical kit
Picnic
Pot food
Signpost
Stethoscope
Storefront
Success
Tote
Universal access
Utensils
Woman
Woodland

Closes #1276

@pseys success-fill changed completely, which will be a breaking change...?

@origami-z I'm not sure why but medical-kit-solid isn't displaying correctly in Storybook. It seems fine in Figma.

@origami-z I'm not sure why but medical-kit-solid isn't displaying correctly in Storybook. It seems fine in Figma.

Yes, i will re-check everything again.

Checked everything

removed stroke color on medical-kit-solid in Figma
remove clip content on component layer setting to avoid unnecessary clipPath introduced (also added to the salt icon contribution checker plugin)
@pseys


CB-3442. Integrate CB and FMS with mina management service.

With these changes, CB and FMS have been updated to compute CCM parameters
by communicating with the minasshd management service, and to pass those parameters
down through user data to the CCM scripts on the instances, triggering the registration
of tunnels back to the CDPCP.
Specifically:

Common proto files and their corresponding generated classes have been
moved out of the auth-connector module and into a new grpc-common module.
A new GrpcUtils class has been added to the grpc-common module, and logic
in the ccm-connector module has been updated to use it.
The minasshdmgmt proto file has been added to the ccm-connector module,
along with its generated classes, and wrapper classes providing
convenience functionality.
The CcmParameters infrastructure and freemarker templates for user data
have been updated to distinguish between the keyId, which is based on the
cluster CRN and used to register and decipher the private key, from the
tunnelInitiatorId, which is based on the provider-specific instance ID
and used to register the tunnels.
A CcmException superclass has been added, and existing exceptions in CCM
have been made subclasses.
A new field for whether to use CCM has been added to the Stack entity,
for both CB and FreeIPA, and to the CreateFreeIpaRequest. The value comes
from the environment in StackCreatorService.createStack, and in both cases
is passed down to the code that determines CCM parameters.
A CcmParameterSupplier has been introduced, with a default implementation
that communicates via GRPC with the minasshd management service to compute
the CCM parameters.
The CCM parameter supplier has been autowired into the FreeIpaCreationService
and StackService.

Overall it looks good to me, however there are still missing pieces like using the tunnel for rest communication which is not Salt. Is that going to be address in a later PR?

LGTM. I have tried launching clusters with this change so I think it's safe to merge. Please feel free to do it once the grpc stuff is reviewed.


Attributerror:  self-_heartbeatTask has no attribute cancel()

Hello, a few weeks ago this code have worked fine, i don't think i changed anything on my side. This error happen when the QR Code should be generated. Seems like  self-_heartbeatTask is somehow defined with None.
Anyone may got a solution for this issue?
class RemoteAuthClient:
    def __init__(self):
        self.initCrypto()
        self._heartbeatTask = None
        self.on_fingerprint = self.ev
        self.on_userdata = self.ev
        self.on_token = self.ev
        self.on_cancel = self.ev
        self.on_timeout = self.ev

if p["op"] == "hello":
    await self.send({"op": "init", "encoded_public_key": self.publicKeyString}, ws)
    self._heartbeatTask = asyncio.get_event_loop().create_task(self.sendHeartbeat(p["heartbeat_interval"], ws))

self._heartbeatTask.cancel()

Update remoteauthclient to latest version (1.4.0b3)

changed nothing... i even tried to install direclty from this github page by using pip install -U git+"https://github.com/RuslanUC/RemoteAuthClient"

Are you importing the remoteauthclient class or do you have the RemoteAuthClient (and User) class in your code?

It's in the code i guess

Remove RemoteAuthClient and User classes from code and add import (from remoteauthclient import RemoteAuthClient)

Remove RemoteAuthClient and User classes from code and add import (from remoteauthclient import RemoteAuthClient)

After i've done this, the issue just moved to the class in the libary:
Task exception was never retrieved
future: <Task finished name='Task-26' coro=<RemoteAuthClient.run() done, defined at C:\Users\Administrator\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\LocalCache\local-packages\Python310\site-packages\remoteauthclient\remoteauthclient.py:67> exception=AttributeError("'NoneType' object has no attribute 'cancel'")>
Traceback (most recent call last):
  File "C:\Users\Administrator\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\LocalCache\local-packages\Python310\site-packages\remoteauthclient\remoteauthclient.py", line 108, in run
    self._heartbeatTask.cancel()
AttributeError: 'NoneType' object has no attribute 'cancel'

Issue solved after uninstalling remoteauthclient and installing again with a new version specified remoteauthclient==1.4.0b3


Getting error while attempting to delete row

Hey, I'm using material-table/core along with latest version of react and mui.
I'm seeing this error whenever I try to delete a row - "Cannot read properties of undefined (reading 'id')", upon inspecting the problem arises with the data passed to delete function doesn't have the tableData which holds details about the table, eg. id of a row.
I'm attaching the codesandbox link.
https://codesandbox.io/s/priceless-panna-dpfyj9?file=/src/App.js
P.S. I don't see this behavior with version 4.3.45
Please help if possible.
Thanks!

I'll take a look. Thanks for the Sandbox

The tabledata is removed from the callback to reduce confusion. Its the actual item now.
But you should just delete it from the array for your code. This example from the docs is just a way to simulate a server for example

Thanks for looking into it.  tabledata was quite useful for identifying the data rather than looping through a large data ourselves. Is there any way to get the ID from the table?

Well you are supposed to add your own id anyway. That would solve it.