text:
Windows 10 version 1.11.2 crashes when opening file

Prerequisites

[X ] Can you reproduce the problem in safe mode?
[ X] Are you running the latest version of Atom?
[ X] Did you check the debugging guide?
[ X] Did you check the FAQs on Discuss?
[ X] Are you reporting to the correct repository?
[ X] Did you perform a cursory search to see if your bug or enhancement is already reported?

For more information on how to write a good bug report or enhancement request, see the CONTRIBUTING guide.
Description
In Windows 10 Anniversary version 1607  build 14393.321 can not open any file or project, Atom crashes
Steps to Reproduce

Goto open file in the menu
select file

Expected behavior:
the file to be opened in Atom
Actual behavior:
Windows Crash window appears asking to close the app or reload it.
Versions
You can get this information from executing atom --version and apm --version at the command line. Also, please include the OS and what version of the OS you're running.

Can you provide details of the crash?  Perhaps a screen shot or dump?

I am having the same issue with Atom. It crashes when opening a file or a folder. I am running the latest version (Atom 1.11.2). I tried to delete cache, reinstalling atom and opening in safe mode. none of this worked for me. attached a screen shot of the crash:
D:\Users\ouassimk>atom --safe
D:\Users\ouassimk>
[656:4364:1031/120553:VERBOSE1:crash_service_main.cc(68)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[656:4364:1031/120553:VERBOSE1:crash_service.cc(142)] window handle is 00250362
[656:4364:1031/120553:VERBOSE1:crash_service.cc(290)] pipe name is \.\pipe\Atom Crash Service
dumps at D:\Users\ouassimk\AppData\Local\Temp\Atom Crashes
[656:4364:1031/120553:VERBOSE1:crash_service.cc(294)] checkpoint is D:\Users\ouassimk\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[656:4364:1031/120553:VERBOSE1:crash_service_main.cc(84)] Ready to process crash requests
[656:5828:1031/120553:VERBOSE1:crash_service.cc(323)] client start. pid = 8140
App load time: 239ms
[656:5828:1031/120554:VERBOSE1:crash_service.cc(323)] client start. pid = 5672
[8104:5872:1031/120554:VERBOSE1:crash_service_main.cc(68)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[8104:5872:1031/120554:VERBOSE1:crash_service.cc(142)] window handle is 005C04AA
[8104:5872:1031/120554:VERBOSE1:crash_service.cc(290)] pipe name is \.\pipe\Atom Crash Service
dumps at D:\Users\ouassimk\AppData\Local\Temp\Atom Crashes
[8104:5872:1031/120554:VERBOSE1:crash_service.cc(294)] checkpoint is D:\Users\ouassimk\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[8104:5872:1031/120554:ERROR:crash_service.cc(301)] could not start dumper

I just wanted to add that I am working on Windows 10 PC. and this problem happens only if the folder or the file is located on google drive. I never had this problem on mac. I also tried version 1.11 and 1.9.9 of Atom and had the same issue.

if I drag a file into atom I can open the file.

It works for me also when I add the whole 'Google Drive' directory, but if I add a sub-directory of Google Drive, it crashes. Also the Google Drive account I am using is a university account (I have no idea if this would have any impact)

I also have this issue. I'm also using google drive, my project is located in google drive sub-folder.

Same here except the file is on a samba mount. Happens sporadically. Version 1.12.3
Exception user id: 37c2a3e3-90fb-21bb-ff1f-3665f3713064

Same result for me. It crashes when I click on "open project" folder, It crashed randomly and when I followed the debugging guide and removed configuration + safe mode +reset state it now crashes when I try to open any file. I see a file opening dialog to open but before it is fully rendered the application already crashed. I try to open a regular folder. SSD drive a new device with new installation.
Atom    : 1.13.1
Electron: 1.3.13
Chrome  : 52.0.2743.82
Node    : 6.5.0
Windows 10 Pro - version 1607 OS Build 14393.693
[1588:8600:0105/012407:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[1588:8600:0105/012407:VERBOSE1:crash_service.cc(142)] window handle is 00300464
[1588:8600:0105/012407:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[1588:8600:0105/012407:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[1588:8600:0105/012407:VERBOSE1:crash_service_main.cc(92)] Ready to process crash requests
[1588:348:0105/012407:VERBOSE1:crash_service.cc(317)] client start. pid = 9836
[1588:348:0105/012408:VERBOSE1:crash_service.cc(317)] client start. pid = 2128
[11376:11764:0105/012408:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[11376:11764:0105/012408:VERBOSE1:crash_service.cc(142)] window handle is 000705F8
[11376:11764:0105/012408:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[11376:11764:0105/012408:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[11376:11764:0105/012408:ERROR:crash_service.cc(295)] could not start dumper
[1588:5020:0105/012413:VERBOSE1:crash_service.cc(325)] client end. pid = 2128
[1588:5020:0105/012413:VERBOSE1:crash_service.cc(325)] client end. pid = 9836
[1588:5020:0105/012414:VERBOSE1:crash_service.cc(346)] zero clients. exiting
[1588:8600:0105/012414:VERBOSE1:crash_service.cc(486)] session ending..
[1588:8600:0105/012414:VERBOSE1:crash_service.cc(491)] clients connected :2
clients terminated :2
dumps serviced :0
dumps reported :0
[1588:8600:0105/012414:VERBOSE1:crash_service_main.cc(97)] Session end. return code is 0
[26488:28020:0124/131833:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[26488:28020:0124/131833:VERBOSE1:crash_service.cc(142)] window handle is 00080F3E
[26488:28020:0124/131833:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[26488:28020:0124/131833:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[26488:28020:0124/131833:VERBOSE1:crash_service_main.cc(92)] Ready to process crash requests
[26488:24904:0124/131833:VERBOSE1:crash_service.cc(317)] client start. pid = 26836
[26488:24904:0124/131834:VERBOSE1:crash_service.cc(317)] client start. pid = 22928
[29552:29660:0124/131834:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[29552:29660:0124/131834:VERBOSE1:crash_service.cc(142)] window handle is 00250CBE
[29552:29660:0124/131834:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[29552:29660:0124/131834:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[29552:29660:0124/131834:ERROR:crash_service.cc(295)] could not start dumper
[26488:6508:0126/123055:VERBOSE1:crash_service.cc(325)] client end. pid = 22928
[26488:6508:0126/123055:VERBOSE1:crash_service.cc(325)] client end. pid = 26836
[26488:6508:0126/123056:VERBOSE1:crash_service.cc(346)] zero clients. exiting
[26488:28020:0126/123056:VERBOSE1:crash_service.cc(486)] session ending..
[26488:28020:0126/123056:VERBOSE1:crash_service.cc(491)] clients connected :2
clients terminated :2
dumps serviced :0
dumps reported :0
[26488:28020:0126/123056:VERBOSE1:crash_service_main.cc(97)] Session end. return code is 0
[4508:11812:0126/145530:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[4508:11812:0126/145530:VERBOSE1:crash_service.cc(142)] window handle is 0003070E
[4508:11812:0126/145530:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[4508:11812:0126/145530:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[4508:11812:0126/145530:VERBOSE1:crash_service_main.cc(92)] Ready to process crash requests
[4508:8784:0126/145530:VERBOSE1:crash_service.cc(317)] client start. pid = 13196
[4508:8784:0126/145531:VERBOSE1:crash_service.cc(317)] client start. pid = 9900
[11832:12252:0126/145532:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[11832:12252:0126/145532:VERBOSE1:crash_service.cc(142)] window handle is 000C04A0
[11832:12252:0126/145532:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[11832:12252:0126/145532:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[11832:12252:0126/145532:ERROR:crash_service.cc(295)] could not start dumper
[4508:3436:0201/175035:VERBOSE1:crash_service.cc(325)] client end. pid = 13196
[4508:3436:0201/175035:VERBOSE1:crash_service.cc(325)] client end. pid = 9900
[4508:3436:0201/175036:VERBOSE1:crash_service.cc(346)] zero clients. exiting
[4508:11812:0201/175036:VERBOSE1:crash_service.cc(486)] session ending..
[4508:11812:0201/175036:VERBOSE1:crash_service.cc(491)] clients connected :2
clients terminated :2
dumps serviced :0
dumps reported :0
[4508:11812:0201/175036:VERBOSE1:crash_service_main.cc(97)] Session end. return code is 0
[24212:23932:0201/175038:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[24212:23932:0201/175038:VERBOSE1:crash_service.cc(142)] window handle is 00210652
[24212:23932:0201/175038:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[24212:23932:0201/175038:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[24212:23932:0201/175038:VERBOSE1:crash_service_main.cc(92)] Ready to process crash requests
[24212:13444:0201/175038:VERBOSE1:crash_service.cc(317)] client start. pid = 7752
[24212:13444:0201/175039:VERBOSE1:crash_service.cc(317)] client start. pid = 24036
[21084:27032:0201/175039:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[21084:27032:0201/175039:VERBOSE1:crash_service.cc(142)] window handle is 001215E6
[21084:27032:0201/175039:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[21084:27032:0201/175039:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[21084:27032:0201/175039:ERROR:crash_service.cc(295)] could not start dumper
[24212:17528:0201/175046:VERBOSE1:crash_service.cc(325)] client end. pid = 7752
[24212:17528:0201/175047:VERBOSE1:crash_service.cc(325)] client end. pid = 24036
[24212:17528:0201/175048:VERBOSE1:crash_service.cc(346)] zero clients. exiting
[24212:23932:0201/175048:VERBOSE1:crash_service.cc(486)] session ending..
[24212:23932:0201/175048:VERBOSE1:crash_service.cc(491)] clients connected :2
clients terminated :2
dumps serviced :0
dumps reported :0
[24212:23932:0201/175048:VERBOSE1:crash_service_main.cc(97)] Session end. return code is 0
[23008:17860:0201/175049:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[23008:17860:0201/175049:VERBOSE1:crash_service.cc(142)] window handle is 0041058C
[23008:17860:0201/175049:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[23008:17860:0201/175049:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[23008:17860:0201/175049:VERBOSE1:crash_service_main.cc(92)] Ready to process crash requests
[23008:20644:0201/175049:VERBOSE1:crash_service.cc(317)] client start. pid = 26240
[23008:20644:0201/175050:VERBOSE1:crash_service.cc(317)] client start. pid = 26428
[25840:27060:0201/175050:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[25840:27060:0201/175050:VERBOSE1:crash_service.cc(142)] window handle is 003A18A2
[25840:27060:0201/175050:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[25840:27060:0201/175050:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[25840:27060:0201/175050:ERROR:crash_service.cc(295)] could not start dumper
[23008:20644:0201/175118:VERBOSE1:crash_service.cc(317)] client start. pid = 6464
[24800:26708:0201/175118:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[24800:26708:0201/175118:VERBOSE1:crash_service.cc(142)] window handle is 00080286
[24800:26708:0201/175118:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[24800:26708:0201/175118:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[24800:26708:0201/175118:ERROR:crash_service.cc(295)] could not start dumper
[23008:16904:0201/175751:VERBOSE1:crash_service.cc(325)] client end. pid = 26428
[23008:20644:0202/002824:VERBOSE1:crash_service.cc(317)] client start. pid = 18256
[22056:22420:0202/002824:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[22056:22420:0202/002824:VERBOSE1:crash_service.cc(142)] window handle is 00270BF6
[22056:22420:0202/002824:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[22056:22420:0202/002824:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[22056:22420:0202/002824:ERROR:crash_service.cc(295)] could not start dumper
[23008:29428:0202/134448:VERBOSE1:crash_service.cc(325)] client end. pid = 18256
[23008:29428:0202/134449:VERBOSE1:crash_service.cc(325)] client end. pid = 6464
[23008:29428:0202/134449:VERBOSE1:crash_service.cc(325)] client end. pid = 26240
[23008:29428:0202/134450:VERBOSE1:crash_service.cc(346)] zero clients. exiting
[23008:17860:0202/134450:VERBOSE1:crash_service.cc(486)] session ending..
[23008:17860:0202/134450:VERBOSE1:crash_service.cc(491)] clients connected :4
clients terminated :4
dumps serviced :0
dumps reported :0
[23008:17860:0202/134450:VERBOSE1:crash_service_main.cc(97)] Session end. return code is 0
[2392:13256:0202/200648:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[2392:13256:0202/200648:VERBOSE1:crash_service.cc(142)] window handle is 0012078E
[2392:13256:0202/200648:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[2392:13256:0202/200648:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[2392:13256:0202/200648:VERBOSE1:crash_service_main.cc(92)] Ready to process crash requests
[2392:5340:0202/200648:VERBOSE1:crash_service.cc(317)] client start. pid = 15796
[2392:5340:0202/200649:VERBOSE1:crash_service.cc(317)] client start. pid = 2096
[15216:11976:0202/200649:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[15216:11976:0202/200649:VERBOSE1:crash_service.cc(142)] window handle is 000B0AD0
[15216:11976:0202/200649:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[15216:11976:0202/200649:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[15216:11976:0202/200649:ERROR:crash_service.cc(295)] could not start dumper
[2392:17192:0203/103220:VERBOSE1:crash_service.cc(325)] client end. pid = 15796
[2392:17192:0203/103221:VERBOSE1:crash_service.cc(325)] client end. pid = 2096
[2392:17192:0203/103222:VERBOSE1:crash_service.cc(346)] zero clients. exiting
[2392:13256:0203/103222:VERBOSE1:crash_service.cc(486)] session ending..
[2392:13256:0203/103222:VERBOSE1:crash_service.cc(491)] clients connected :2
clients terminated :2
dumps serviced :0
dumps reported :0
[2392:13256:0203/103222:VERBOSE1:crash_service_main.cc(97)] Session end. return code is 0
[16236:16220:0203/103223:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[16236:16220:0203/103223:VERBOSE1:crash_service.cc(142)] window handle is 00150DEA
[16236:16220:0203/103223:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[16236:16220:0203/103223:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[16236:16220:0203/103223:VERBOSE1:crash_service_main.cc(92)] Ready to process crash requests
[16236:13052:0203/103223:VERBOSE1:crash_service.cc(317)] client start. pid = 10804
[16236:13052:0203/103224:VERBOSE1:crash_service.cc(317)] client start. pid = 19336
[17328:14364:0203/103224:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[17328:14364:0203/103224:VERBOSE1:crash_service.cc(142)] window handle is 00480B20
[17328:14364:0203/103224:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[17328:14364:0203/103224:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[17328:14364:0203/103224:ERROR:crash_service.cc(295)] could not start dumper
[16236:19060:0203/103236:VERBOSE1:crash_service.cc(325)] client end. pid = 10804
[16236:19060:0203/103236:VERBOSE1:crash_service.cc(325)] client end. pid = 19336
[16236:19060:0203/103237:VERBOSE1:crash_service.cc(346)] zero clients. exiting
[16236:16220:0203/103237:VERBOSE1:crash_service.cc(486)] session ending..
[16236:16220:0203/103237:VERBOSE1:crash_service.cc(491)] clients connected :2
clients terminated :2
dumps serviced :0
dumps reported :0
[16236:16220:0203/103237:VERBOSE1:crash_service_main.cc(97)] Session end. return code is 0
[14436:14860:0203/103253:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[14436:14860:0203/103253:VERBOSE1:crash_service.cc(142)] window handle is 001D0980
[14436:14860:0203/103253:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[14436:14860:0203/103253:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[14436:14860:0203/103253:VERBOSE1:crash_service_main.cc(92)] Ready to process crash requests
[14436:2968:0203/103253:VERBOSE1:crash_service.cc(317)] client start. pid = 18376
[14436:2968:0203/103254:VERBOSE1:crash_service.cc(317)] client start. pid = 16460
[4028:6832:0203/103254:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[4028:6832:0203/103254:VERBOSE1:crash_service.cc(142)] window handle is 000E04F6
[4028:6832:0203/103254:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[4028:6832:0203/103254:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[4028:6832:0203/103254:ERROR:crash_service.cc(295)] could not start dumper
[14436:19108:0203/103413:VERBOSE1:crash_service.cc(325)] client end. pid = 16460
[14436:19108:0203/103413:VERBOSE1:crash_service.cc(325)] client end. pid = 18376
[14436:19108:0203/103414:VERBOSE1:crash_service.cc(346)] zero clients. exiting
[14436:14860:0203/103414:VERBOSE1:crash_service.cc(486)] session ending..
[14436:14860:0203/103414:VERBOSE1:crash_service.cc(491)] clients connected :2
clients terminated :2
dumps serviced :0
dumps reported :0
[14436:14860:0203/103414:VERBOSE1:crash_service_main.cc(97)] Session end. return code is 0
[2792:11936:0203/103419:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[2792:11936:0203/103419:VERBOSE1:crash_service.cc(142)] window handle is 000D0A94
[2792:11936:0203/103419:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[2792:11936:0203/103419:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[2792:11936:0203/103419:VERBOSE1:crash_service_main.cc(92)] Ready to process crash requests
[2792:14784:0203/103419:VERBOSE1:crash_service.cc(317)] client start. pid = 15620
[2792:14784:0203/103419:VERBOSE1:crash_service.cc(317)] client start. pid = 8724
[6512:15808:0203/103419:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[6512:15808:0203/103419:VERBOSE1:crash_service.cc(142)] window handle is 000F0A72
[6512:15808:0203/103419:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[6512:15808:0203/103419:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[6512:15808:0203/103419:ERROR:crash_service.cc(295)] could not start dumper
[2792:3800:0203/103429:VERBOSE1:crash_service.cc(325)] client end. pid = 15620
[2792:3800:0203/103429:VERBOSE1:crash_service.cc(325)] client end. pid = 8724
[2792:3800:0203/103430:VERBOSE1:crash_service.cc(346)] zero clients. exiting
[2792:11936:0203/103430:VERBOSE1:crash_service.cc(486)] session ending..
[2792:11936:0203/103430:VERBOSE1:crash_service.cc(491)] clients connected :2
clients terminated :2
dumps serviced :0
dumps reported :0
[2792:11936:0203/103430:VERBOSE1:crash_service_main.cc(97)] Session end. return code is 0
[16568:7396:0203/103503:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[16568:7396:0203/103503:VERBOSE1:crash_service.cc(142)] window handle is 00110E1A
[16568:7396:0203/103503:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[16568:7396:0203/103503:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[16568:7396:0203/103503:VERBOSE1:crash_service_main.cc(92)] Ready to process crash requests
[16568:19128:0203/103503:VERBOSE1:crash_service.cc(317)] client start. pid = 15852
[16568:19128:0203/103504:VERBOSE1:crash_service.cc(317)] client start. pid = 15044
[17560:6164:0203/103504:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[17560:6164:0203/103504:VERBOSE1:crash_service.cc(142)] window handle is 00140948
[17560:6164:0203/103504:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[17560:6164:0203/103504:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[17560:6164:0203/103504:ERROR:crash_service.cc(295)] could not start dumper
[16568:9028:0203/103519:VERBOSE1:crash_service.cc(325)] client end. pid = 15852
[16568:9028:0203/103519:VERBOSE1:crash_service.cc(325)] client end. pid = 15044
[16568:9028:0203/103520:VERBOSE1:crash_service.cc(346)] zero clients. exiting
[16568:7396:0203/103520:VERBOSE1:crash_service.cc(486)] session ending..
[16568:7396:0203/103520:VERBOSE1:crash_service.cc(491)] clients connected :2
clients terminated :2
dumps serviced :0
dumps reported :0
[16568:7396:0203/103520:VERBOSE1:crash_service_main.cc(97)] Session end. return code is 0
[15808:18460:0203/103650:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[15808:18460:0203/103650:VERBOSE1:crash_service.cc(142)] window handle is 0027088A
[15808:18460:0203/103650:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[15808:18460:0203/103650:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[15808:18460:0203/103650:VERBOSE1:crash_service_main.cc(92)] Ready to process crash requests
[15808:17252:0203/103650:VERBOSE1:crash_service.cc(317)] client start. pid = 18488
[15808:17252:0203/103651:VERBOSE1:crash_service.cc(317)] client start. pid = 18996
[16788:9908:0203/103651:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[16788:9908:0203/103651:VERBOSE1:crash_service.cc(142)] window handle is 002509B0
[16788:9908:0203/103651:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[16788:9908:0203/103651:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[16788:9908:0203/103651:ERROR:crash_service.cc(295)] could not start dumper
[15808:11880:0203/103702:VERBOSE1:crash_service.cc(325)] client end. pid = 18488
[15808:11880:0203/103702:VERBOSE1:crash_service.cc(325)] client end. pid = 18996
[15808:11880:0203/103703:VERBOSE1:crash_service.cc(346)] zero clients. exiting
[15808:18460:0203/103703:VERBOSE1:crash_service.cc(486)] session ending..
[15808:18460:0203/103703:VERBOSE1:crash_service.cc(491)] clients connected :2
clients terminated :2
dumps serviced :0
dumps reported :0
[15808:18460:0203/103703:VERBOSE1:crash_service_main.cc(97)] Session end. return code is 0
[13136:14736:0203/103725:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[13136:14736:0203/103725:VERBOSE1:crash_service.cc(142)] window handle is 002B0974
[13136:14736:0203/103725:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[13136:14736:0203/103725:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[13136:14736:0203/103725:VERBOSE1:crash_service_main.cc(92)] Ready to process crash requests
[13136:2796:0203/103725:VERBOSE1:crash_service.cc(317)] client start. pid = 16944
[13136:2796:0203/103726:VERBOSE1:crash_service.cc(317)] client start. pid = 18144
[15576:17444:0203/103726:VERBOSE1:crash_service_main.cc(76)] Session start. cmdline is [--reporter-url=https://crashreporter.atom.io --application-name=Atom --v=1]
[15576:17444:0203/103726:VERBOSE1:crash_service.cc(142)] window handle is 001F0D5A
[15576:17444:0203/103726:VERBOSE1:crash_service.cc(284)] pipe name is \.\pipe\Atom Crash Service
dumps at C:\Users\petrch\AppData\Local\Temp\Atom Crashes
[15576:17444:0203/103726:VERBOSE1:crash_service.cc(288)] checkpoint is C:\Users\petrch\AppData\Local\Temp\Atom Crashes\crash_checkpoint.txt
server is https://crashreporter.atom.io
maximum 128 reports/day
reporter is electron-crash-service
[15576:17444:0203/103726:ERROR:crash_service.cc(295)] could not start dumper
[13136:5636:0203/103753:VERBOSE1:crash_service.cc(325)] client end. pid = 16944
[13136:5636:0203/103753:VERBOSE1:crash_service.cc(325)] client end. pid = 18144
[13136:5636:0203/103754:VERBOSE1:crash_service.cc(346)] zero clients. exiting
[13136:14736:0203/103754:VERBOSE1:crash_service.cc(486)] session ending..
[13136:14736:0203/103754:VERBOSE1:crash_service.cc(491)] clients connected :2
clients terminated :2
dumps serviced :0
dumps reported :0
[13136:14736:0203/103754:VERBOSE1:crash_service_main.cc(97)] Session end. return code is 0

:wave: Anyone who is experiencing this issue, can you please try updating to Atom 1.19.0 and see if the crash still happens?  1.19.0 includes some low-level changes that may have resolved this crash.

authors: 50Wliu EvgenyAGM damieng dawnerd ouassimk petrchpetr skipjac


text:
Uncaught TypeError: Cannot read property 'has' of null

Go to Atom package manager
Uninstall the platformio-ide-terminal
Uninstall the platformio package

Atom: 1.15.0 x64
Electron: 1.3.13
OS: Mac OS X 10.12.2
Thrown From: 'platformio-ide' package vundefined
Stack Trace
Uncaught TypeError: Cannot read property 'has' of null
At /Users/joscha/.atom/packages/platformio-ide/lib/init/command.js:185

TypeError: Cannot read property 'has' of null
    at intendToPerformIndexRebuild (/packages/platformio-ide/lib/init/command.js:185:26)
    at /packages/platformio-ide/lib/init/command.js:209:13

Commands
  3x -4:37 core:move-down (input.hidden-input)
  3x -4:34 core:move-up (input.hidden-input)
     -4:33.1.0 core:move-left (input.hidden-input)
     -4:31.5.0 core:backspace (input.hidden-input)
     -4:31.1.0 core:move-up (input.hidden-input)
     -4:30.9.0 core:move-right (input.hidden-input)
     -4:30.6.0 core:backspace (input.hidden-input)
  2x -4:30 core:move-down (input.hidden-input)
     -4:27.7.0 core:save (input.hidden-input)
     -4:27.6.0 build:refresh-targets (atom-workspace.workspace.scrollbars-visible-always.theme-one-dark-syntax.theme-one-dark-ui)
     -4:14.5.0 platformio-ide:target:upload (input.hidden-input)
     -4:14.5.0 platformio-ide:target:upload-/Users/joscha/Development/wala/wala-sodaqone_3 (atom-workspace.workspace.scrollbars-visible-always.theme-one-dark-syntax.theme-one-dark-ui)
     -3:31.5.0 platformio-ide:target:clean (div.build.tool-panel.native-key-bindings)
     -3:31.5.0 platformio-ide:target:clean-/Users/joscha/Development/wala/wala-sodaqone_3 (atom-workspace.workspace.scrollbars-visible-always.theme-one-dark-syntax.theme-one-dark-ui)
     -3:24.3.0 platformio-ide:target:upload (input.hidden-input)
     -3:24.3.0 platformio-ide:target:upload-/Users/joscha/Development/wala/wala-sodaqone_3 (atom-workspace.workspace.scrollbars-visible-always.theme-one-dark-syntax.theme-one-dark-ui)

Non-Core Packages
atom-beautify 0.29.17
atom-jasmine 0.8.1
autocomplete-clang 0.10.0
autocomplete-paths 1.0.5
build 0.67.0
busy 0.7.0
busy-signal 1.3.0
editorconfig 2.2.2
file-icons 2.0.17
intentions 1.1.2
jsformat 0.9.3
language-arduino 0.4.2
language-docker 1.1.7
language-gherkin 1.0.4
language-ini 1.19.0
language-lua 0.9.11
language-protobuf 0.7.1
language-scala 1.1.8
linter 2.1.0
linter-coffeelint 1.2.1
linter-docker 0.1.4
linter-eslint 8.1.4
linter-gcc 0.7.1
linter-javac 1.9.4
linter-jsonlint 1.3.0
linter-jsxhint 0.1.2
linter-php 1.3.2
linter-ui-default 1.2.1
merge-conflicts 1.4.4
minimap 4.26.8
react 0.16.2
tool-bar 1.1.0
travis-ci-status 1.3.1
visual-bell 1.0.0

Thanks for contributing!
It appears that this is being caused by the platformio-ide package, not Atom itself. It may be that there is still a bug in Atom. If so, we'll need the maintainer of the package that is causing the problem to help track that down. You should file this issue on their repository so they can either fix the problem or tell us where the problem is coming from. The Atom FAQ has information on how to contact the maintainers of any Atom community package or theme.

source: gharchive/issue

repo: atom/atom

license: MIT

license_type: permissive

license_source: github-api


text:
Oracle Linux 7.6: 1.39.0.beta3: Error: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found

[X] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: https://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: https://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
Error: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /usr/share/atom-beta/resources/app/apm/node_modules/git-utils/build/Release/git.node)
Steps to Reproduce
$ apm-beta --color upgrade
Expected behavior:

Actual behavior:
$ apm-beta --color upgrade
module.js:664
return process.dlopen(module, path._makeLong(filename));
^
Error: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /usr/share/atom-beta/resources/app/apm/node_modules/git-utils/build/Release/git.node)
at Object.Module._extensions..node (module.js:664:18)
at Module.load (module.js:554:32)
at tryModuleLoad (module.js:497:12)
at Function.Module._load (module.js:489:3)
at Module.require (module.js:579:17)
at require (internal/module.js:11:18)
at Object. (/usr/share/atom-beta/resources/app/apm/node_modules/git-utils/lib/git.js:8:16)
at Object. (/usr/share/atom-beta/resources/app/apm/node_modules/git-utils/lib/git.js:371:4)
at Module._compile (module.js:635:30)
at Object.Module._extensions..js (module.js:646:10)
Reproduces how often:
100%
Versions
This happens with rpm pkg: atom-beta.x86_64 0:1.39.0.beta3-0.1
The previous beta is fine: atom-beta.x86_64 0:1.39.0.beta2-0.1
Additional Information
libstdc++-0:4.8.5-36.0.1.el7_6.2.x86_64
]$ strings /lib64/libstdc++.so.6 | grep GLIBCXX_3.4
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
$ cat /etc/yum.repos.d/atom.repo
[Atom]
name=Atom Editor
baseurl=https://packagecloud.io/AtomEditor/atom/el/7/$basearch
enabled=1
gpgcheck=0
repo_gpgcheck=1
gpgkey=https://packagecloud.io/AtomEditor/atom/gpgkey
thanks very much.

Thanks for the report @cdmackay - just to clarify, you're only having trouble with apm but running Atom works fine?

Apologies, I ought to have made that clear.
apm gives the error, but atom-beta itself just fails to start, with no apparent error. Both work fine on rpm beta2, and both fail on beta3.
I just used apm to illustrate the problem because of the detailed error message.

Same error for Ubuntu 14.04.6

Unsubscribe!!!
On Tue, Jul 23, 2019 at 4:44 PM Alberto Pires de Oliveira Neto <
notifications@github.com> wrote:

Same error for Ubuntu 14.04.6
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/atom/atom/issues/19682?email_source=notifications&email_token=AL7TK5CTERPLVCPRJLQ5BKDQA5USXA5CNFSM4IFL7QN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2UMB2Y#issuecomment-514375915,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AL7TK5GZ5U2IDY3MLASZCMTQA5USXANCNFSM4IFL7QNQ
.

--
Cheryl Miller 440-539-1339

We're investigating a similar issue in https://github.com/atom/atom/issues/19690. I think both issues stem from the same root cause described in https://github.com/atom/atom/issues/19690#issuecomment-514397823. We're actively investigating a fix for these issues.

:wave: @cdmackay : I think we've got a fix for this issue. You can find an rpm with the proposed fix at https://github.visualstudio.com/Atom/_build/results?buildId=46092&view=results:

Would you mind trying it out and letting us know if it resolves the issue for you? If it does, then we'll publish a new release with this fix.

I had the same problem with my 14.04 (Mint 17 flavoured) with the Atom 1.39.0.
Uncaught Exception:
Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /usr/share/atom/resources/app.asar.unpacked/node_modules/nslog/build/Release/nslog.node)
at process.module.(anonymous function) [as dlopen] (ELECTRON_ASAR.js:166:20)
at Object.Module._extensions..node (internal/modules/cjs/loader.js:740:18)
at Object.module.(anonymous function) [as .node] (ELECTRON_ASAR.js:180:18)
at Module.load (internal/modules/cjs/loader.js:620:32)
at tryModuleLoad (internal/modules/cjs/loader.js:559:12)
at Function.Module._load (internal/modules/cjs/loader.js:551:3)
at Module.require (internal/modules/cjs/loader.js:658:17)
at require (internal/modules/cjs/helpers.js:20:18)
at Object. (/usr/share/atom/resources/app.asar/node_modules/nslog/lib/nslog.js:5:11)
at Object. (/usr/share/atom/resources/app.asar/node_modules/nslog/lib/nslog.js:15:4)
followed your direction and installed 1.39.1:
Unpacking atom (1.39.1) over (1.39.0) ...
Setting up atom (1.39.1) ...
Fixed issue.

@jasonrudolph that's marvellous, thanks very much indeed.
As @bashbang says, that worked perfectly for me (rpm version). Tested both apm and atom, both fine.
thanks again for fixing this so quickly.

Thanks @jasonrudolph
This update solve also for me

@cdmackay @bashbang @AleMingh: Thanks for confirming that the updated RPM package resolved the issue for you. :bow:
Atom 1.39.1 and 1.40.0.beta1 are out now with this fix, so I'm going to close out this issue.

authors: AleMingh albertopires bashbang cdmackay jasonrudolph mommabear734 rsese


text:
problem is that no one even look at this appp and realize is has no names for anything idiots

Summary

Motivation

Describe alternatives you've considered

Additional context

Thanks for reaching out!
We require the template to be filled out on all new issues and pull requests. We do this so that we can be certain we have all the information we need to address your submission efficiently. This allows the maintainers to spend more time fixing bugs, implementing enhancements, and reviewing and merging pull requests.
Thanks for understanding and meeting us halfway :grinning:


text:
Atom API produces HTTP 500

Prerequisites

[ X] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: https://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: https://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description

Atom repeatedly produces 500 errors on the web. It is also not possible to search/install packages using desktop. Seems that there may be a problem on the server side.
Steps to Reproduce

Go to Atom.io or try search for a package in the desktop version.

Expected behavior:
Everything works.
Actual behavior:
The 500 error stub or the error message in the terminal.
Reproduces how often:
Always...
Versions
I'm using macOS Monterey 12.6, Atom 1.60.0

Can also confirms that this occurs

Experiencing the same issue
Using macOS Monterey 12.3 | Atom 1.60

Maybe Atom server is down...

@whutao You should try again, however, I suspect the server can't able to handle these requests correctly. Unfortunately, there won't be an answer from the maintainers, since Atom is going to be officially discontinued at the end of 2022. It's very unlikely anyone would fix this.

The same here. On Windows 11. I can´t also install any package...

Can confirm that

Same. Looks like atom is almost dead.

authors: BLouie2 CJYKK Knoxi-Code drEnilight pee111 preland rilysh whutao


text:
Editor blank on startup intermittently

Upon startup, Atom goes into a whitescreen dev mode type of environment. After closing and reopening, the IDE interface appears. Not sure if this is by design. Windows 7 64-bit, atom v0.146

Same here:

I believe this issue has been fixed via several changes to electron, bundling the app in an asar bundle, and better handling of startup errors.
So I'm going to close this out but please comment back if you still see it happening on Atom 1.0+.

It happened to me as well, uninstalling and reinstalling didn't solve it.
I believe it happened after I opened a filed (don't remember which one) and then after every time I tried to start atom, it tried to load it.
Solution was to delete
%userprofile%\AppData\Roaming\Atom
not sure why uninstall doesn't clear it.

Problem persists in atom 1.6.0
$ atom or $ atom --safe

$ atom --version
1.6.0

@guptadivyansh Your issue is most likely #10819.

@50Wliu Thanks!
Downgraded atom to get it to work

I had a similar issue.
Interface loads as blank screen. (Windows 10 x64, Atom 1.6.1)
As suggested by @guptadivyansh, clearing out the roaming folder solved it.
https://github.com/atom/atom/issues/4351#issuecomment-186504559
Log file:
blankload.SquirrelSetup.log.txt

Upgrading to atom 1.8.0-beta1 has fixed the issue for me. Working flawlessly now :)

Still seeing this problem on 1.8.0, beta does not fix, clearing roaming folder does not fix.

@keenan-burnett If you look at the error message, it is saying that you don't have permissions to read a file under C:\Users\IBM_ADMIN\.atom\compile-cache. That is the problem you need to fix.
The problem you're having is not related to the original issue at all. Also, we're trying to control the amount of Issues that we have to triage and track. For general questions, the Atom message board is where you'll probably be able to find answers faster.

Was this issue resolved?
I am seeing it now:

(blank window when opening atom)
Note: I'm trying to open atom from command line with:
atom .

(this used to open the project folder for the CWD in the terminal window)
My Atom version is apparently "up-to-date":

Running on Mac OS Sierra v 10.12.6 (16G29) (also latest)

authors: 50Wliu PyroSA brunorios1 guptadivyansh jakepark keenan-burnett kevinsawicki lee-dohm nelsonic roshimon zaheer9869


text:
rendering issue with submodules

I have a repo that contained a number of submodules.
All my submodules have been listed in the .gitignore file.
When I open a submodule with atom, it's not recognized as a git package and all its folders are greyed out. I assume it's because the parent .gitignore mentionned it.

I have the same issue

I'm not sure I understand – if the submodules are in the .gitignore file then the intended behavior is that they'll be grayed out in the tree-view.

@mnquintana that's the expected behavior if I open the top-most folder as the "project"
repo
| submodule1 // should be grayed out
| submodule2 // should be grayed out
.gitignore

However it's not the expected behavior if I open one of the submodule as the "project"
submodule1 // should not be grayed out

@mnquintana for example
I have a vagrantfile repo, it is include a project source code as as git submodule.
I just want keep the repo clean, so I add source code folder into .gitignore.
the bug is: currently, all source codes in tree view are gray when I open its directory as root directory in Atom
another bug, Search can not search the submodule file.
Textmate not have those bugs, I think Atom should fix it too

authors: kunyan mnquintana olivierlesnicki


text:
Ask for comment character when toggling line comments when unknown

If I'm editing a file (in this case play/play's mpd.conf) and there isn't a known comment syntax for the file, when I toggle line comments, Atom should ask me what the comment character is. You know, like comment-region in Emacs.

Integrating this would be a solution to #13370

authors: thedaniel tjgerot


text:
replace OSX window title bar with custom title-bar

This pull request is intended to naively implement a custom titlebar on OSX.
I've included fallback styling to match El Capitan's titlebars, which is probably not necessary as I modified the four included themes to provide their own titlebar styling. I'll create PRs for these in their respective repositories if this PR gets considered.
I'd like to hear your thoughts on the implementation, I just banged on the code until it worked 😁
This is what it looks like by default:

This is the titlebar provided by one-dark-ui, with the oceanic-next syntax

This is one-light-ui, with the atom-light syntax

Things left to do:

[x] ✅ specs

This is a partial continuation of https://github.com/atom/atom/pull/10208 albeit without the combined title-bar-and-tabs functionality, for which this would be the groundwork. (As requested in https://github.com/atom/atom/issues/4599 for example.)

Any change to get rid of the black separation line between the title bar and the three file view? I think it would look much better.

@FezVrasta These screenshots are just a first stab at theming the title-bar and intended to show what it could look like. At any rate, you could always remove that line by tinkering with your user stylesheet :)
@simurai Would you like me to go ahead and create some PRs on https://github.com/atom/one-dark-ui/ and https://github.com/atom/one-light-ui/?

I wonder if the background should just be @base-background-color? So that "abandoned, but still in use" themes would adapt too. Then maybe make a PR with the current grey gradient for themes that try to stay close to OS X. Like unity-ui or native-ui.

I wonder if the background should just be @base-background-color?

That's a much better idea than using the grey gradient! I'll change it.

atom-dark with a title-bar gradient based on @base-background-color

What's the status of this PR? I think the top grey bar is one of the most annoying things of Atom. If I have to use it the whole day I need a pleasant environment, and that gray bar doesn't help at all 😓
In my opinion, this PR should have high priority.

I just can't stress how awesome and cool this thing looks to me. Would love to see it!

Let us know when you have the specs complete for this @brumm :grinning:

Made a few more comments.. sorry.. :innocent: I tried to make a PR to your PR, but your fork somehow didn't show up in the list to compare against.

Thanks for the comments! All good points. I'll be able to work on this in a few hours 👍

@simurai i made a couple of changes:

followed your advice and added title-bar as a headerPanel instead, which allowed me to undo the changes I made to workspace styling
moved title-bar variables into title-bars' less file and simplified the styling to a single background-color: @base-background-color. After much back-and-forth I decided against @tab-bar-background-color to preserve some contrast between title-bar and the rest of the UI, but I do like both.
cleaned up some superfluous code from title-bar-element and added a simple test

I'm for @tab-bar-background-color, it would look much better (and will allow a better integration in the existing themes)

@tab-bar-background-color

@base-background-color

As far as I can tell, the failed travis build doesn't seem to be related to my changes.
Should I squash now or after another once-over?
@lee-dohm @simurai

After much back-and-forth I decided against @tab-bar-background-color to preserve some contrast between title-bar and the rest of the UI, but I do like both.

Yeah, sounds good. For the bundled One + Atom themes, we can still thinking about customizing it. Also having a border by default should help make it clear where you can start dragging the window.
@FezVrasta In case your favorite theme doesn't look seamless, you could always make it transparent in your styles.less with:
.title-bar {
  background-color: transparent;
  border-color: transparent;
}

Should I squash now or after another once-over?

Only if you want, so far we haven't really bothered about it. Maybe one day we will enable it on the merge button, now that GitHub added that feature.

As far as I can tell, the failed travis build doesn't seem to be related to my changes.

Ya, looks like an unlreated timeout.

ok, so the styling is 👍
So hopefully we can get somebody from @atom/core to take a look at the code. And maybe @amytruong can give it another test drive?

I love this! Other than my above comment, I say it's ready for 🚀 !

Thanks for the reviews and comments, everyone! :shipit:

So, one thing that this doesn't appear to offer is the title bar icon:

This would appear to be a regression. We would either need to maintain this functionality or come up with a way to enable/disable the feature. Both are pretty complex since we don't currently have a system for either having configuration options specific to a platform or restarting when a configuration option is changed.
Is this something that you would be able to cover @brumm?

Sorry, the correct term for the thing I was calling a "title bar icon" is "proxy icon":
https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/WindowAppearanceBehavior.html#//apple_ref/doc/uid/20000957-CH33-SW1

Hah, I knew I was missing something ;)
I'd hazard a guess that while it would be possible to approximate the proxy icon, it'd be hard/impossible to really get right (a cursory google search suggests that getting a file icon from node is not a solved problem for instance).
I'd be happy to work on providing a settings interface for this feature, which is something I wanted to do in a later PR anyway.
That would mean extending the config-schema with a way to

Define a platform for the setting
Indicating that this setting will need a restart/reopened window.
We could probably get away with just mentioning the fact inside the setting description, and then reacting to a setting change with a dialog.

Maybe like this:
customTitleBar:
  platform: 'darwin' # 'darwin', 'freebsd', 'linux', 'sunos' or 'win32'
  type: 'boolean'
  default: false
  description: 'Use custom window and theme-aware title-bar. Note: This currently does not include a file icon or title context menu.
This setting will require a restart to take effect.'

If 'polluting' the config namespace is a concern, we could abstract these two new use cases for the config schema to mean

Setting visibility/applicability
Setting side effects

customTitleBar:
  show: { platform: 'darwin' }
  sideEffect: ['restart-app']
  type: 'boolean'
  default: false
  description: 'Use custom window and theme-aware title-bar. Note: This currently does not include a file icon or title context menu.
This setting will require a restart to take effect.'

What's the purpose of such icon?

It's a representation (or in osx terms, proxy) of the currently opened file. Click-holding the icon allows you to drag the file out of the title bar to move/copy/alias it.
The title bar also provides a context menu of the currently opened file's parent directories on right-click.

On 27 May 2016, at 18:36, Fez Vrasta notifications@github.com wrote:
What's the purpose of such icon?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

It's a bit tricky, but couldn't Electron provide the proxy icon directly from the OS X API like it does for the window control buttons?
Probably it would be difficult/impossible to position the icon on the left of the text, but you could just put in on the right corner maybe.

@zcbenz Do you think it would be feasibly (aka not too much work) to add an API for this in Electron? And by this, I mean an API that will allow us to basically re-implement the "proxy icon" functionality. We'd ideally need access to the icon somehow, as well as being able to trigger (and position) the menu.

I can imagine positioning the native proxy icon would be pretty hard. Adding a config option, as proposed in ☝ https://github.com/atom/atom/pull/11790#issuecomment-222191019 feels more realistic. Then people can choose to use the native title bar with all its functionality or use the simple, but customizable one.
Maybe depends if platform specific configs would be beneficial for other things too? Or added just for this use-case?

Maybe depends if platform specific configs would be beneficial for other things too? Or added just for this use-case?

That's what I was wondering :)
I'll start with the simple platform version and see what others like @lee-dohm might say in the meantime.

Right, finally got around to actually doing this.
There are some wording problems in promptForRelaunch, since we're not actually relaunching Atom, for which I'll happily accept better phrasing.

I'm running into the same error message as the CI, badges.less isn't found.

Ah, seems like a bad rebase conflict resolution. Weird that the build script did not complain about this...

Looks like the cursor blink spec timed out, travis looks okay otherwise

Tried it out and works!!! 👍

There are some wording problems in promptForRelaunch, since we're not actually relaunching Atom, for which I'll happily accept better phrasing.

Should the button say "Quit Atom"? The word "Relaunch" suggest that it will quit AND re-open Atom automatically.

Should the button say "Quit Atom"? I feel like the word "Relaunch" suggests that it will quit AND re-open Atom automatically.

Thanks, I changed it to
{
  message: "You will need to relaunch Atom for this change to take effect."
  buttons: ['Quit Atom', 'Cancel']
}

We'll be able to actually relaunch Atom once we're using electron 1.2.2

Made sure that we set a sheet offset when using the custom titlebar:

Is this almost ready to merge? If so, that'd be great; I can't wait to have this.
I also think that @tab-bar-background-color looks better, fwiw, so I hope that will be configurable.
Overall, great work 👍

@simurai Hey, it'd be great if you could take a look at https://github.com/atom/atom/pull/11790/commits/3e53a03871ac25e68269f3897896fc93170ef471.
I decided to transition this instead of a hard display: none because the change happens after the fullscreen animation on OSX and is kind of abrupt.

I found a weird bug: If .tree-view-directory is overflowing .tree-view, toggling treeview visibility causes <atom-workspace> to scroll down by at least the height occluded and at most the height of the titlebar, effectively hiding the titlebar.
As far as I can tell, this is not caused by programmatically setting scrollTop of <atom-workspace>.
Screencast: http://i.imgur.com/hG6Zl2Z.gifv

@brumm Can confirm this. I observed this behaviour when building atom with @paulcbetts PR on this same feature (#10208).

Note: This currently does not include a file icon

This should read "Note: This currently does not include a proxy icon"

@brumm I found a weird bug

That feels like a deja-vu.. do you have the color-picker package installed? It looks like it's the same issue that tool-bar also has. A fix got merged, but I think it didn't get published yet?

Thanks @simurai! This was indeed the problem. I opened a new issue and asked @thomaslindstrom to release a new version which includes the fix.

@simurai @brumm Sorry, I thought I'd done this already. It's out in 2.2.0!

@simurai @brumm Just a quick update: v2.2.0 including the fix for this issue broke color-picker completely. I've published v2.2.1 that reverts the fix, but that means that this issue is still present.

Whats the latest here?

Looking forward to this

Ugh, sorry, I was trying to push a branch based on this to to atom/atom and accidentally pushed to master. I'm making some adjustments and working toward merging this, but it's not there yet.

✨  Thanks @brumm for putting this together. I'm already enjoying the more stylish title bar in my dev environment. This should go out with Atom 1.11.0-beta0 in the next release cycle. ⚡

Now to wait for theme support once this is released 😁

@onbjerg Material UI already supports it 😄

Thanks you so much @nathansobo for picking this up! I'm stoked to see this getting merged 🎉

I'm trying to implement this work in my beta (1.10.0-beta1).  When I add the below snippet to my style.less and save, restart atom, nothing happens. Is what I'm doing supposed to work?
Thanks!!
.theme-one-dark-ui {
.tree-view::before,
.tab-bar:before,
.tab.active:before {
display: none;
}
}

@maxwellzdeamon This won't land until 1.11.0, so you'll have to build from source until then if you want it.

@brumm is there any way to change the position of the window controls using CSS?

@FezVrasta The window controls are drawn by the OS and positions can't be changed indivdually.
You might get some milage out of changing titleBarStyle to hidden-inset which moves the controls a bit further down, but also increases the size of the title bar.
I always figured that we'd have to completely hide the titlebar to support the 'tabs-on-top' style proposed in #10208, and dynamically switch draggable areas on and off with css.
That's what I came up with the other day:

Thanks for the reply. If it can be helpful I posted my custom CSS on https://github.com/atom/atom/pull/10208#issuecomment-241346442

@brumm We came up with that design too - it looks great but the problem is that objects in the non-client area (i.e. the invisible bar from the traffic lights onward) cannot be dragged, so reordering tabs is busted :cry:

Couldn't we hide the title bar altogether, and create fake window buttons with CSS, as shown here? @paulcbetts @brumm

@controversial In Atom's case, window buttons are rendered by the OS and can't be changed.

@silvestreh Why couldn't that be changed? This is a PR to the atom core...

@controversial This is what the titlebar's DOM element looks like:

As you can see, the buttons aren't part of the DOM. You can't style them with CSS because the window manager, not Chrome, is rendering them.
AFAIK, you can't move, resize, nor hide them.

You can spawn a frameless window, which would hide the title bar completely, then you could emulate the buttons using custom CSS. https://github.com/electron/electron/blob/master/docs/api/frameless-window.md
Maybe this isn't available in the version of Electron atom is on though.

Maybe this isn't available in the version of Electron atom is on though.

This does indeed require a more modern Electron. We're very close to shipping #12300 though 🎉

Ah, great. I'll look forward to #12300 😃

@controversial I think it's not a good practice to replace native OS UI controls. They are a hell to maintain and avoids OS level customization and third party software control over them.

Yeah, you're probably right. Waiting for the newer Electron version will be a much better choice.

I love this addition so much! I'm just trying it out right now but I've noticed a little bit of extra black under the bar with Nuclide. Not sure if this an Atom issue or a Nuclide issue.

Not a huge issue, just thought it was worth noting.

Any plans to have something like this for other operating systems, given 57% of the Atom userbase is on Linux or Windows? 😄

You can spawn a frameless window, which would hide the title bar completely, then you could emulate the buttons using custom CSS

I agree with @sveggiani... Emulating native OS controls is tricky and very difficult to maintain. It's better to use the native APIs to render the native controls (for example, I believe the title bar of Google Chrome does it this way). This used to be reasonably common with native apps on Windows, I don't know if Electron exposes this functionality though.

@Daniel15 Electron does expose this, but only in a version of Electron that's later than the one Atom uses. I think a fake control would be good for the short term, using the native controls once we get to that version of Electron.

Now that Atom is on a modern Electron version can we do this? I really like @brumm's solution, even though the tabs can't be reordered. Hyper does this and the tabs aren't reorderable, but it never really bothers me. If this was an option that could be enabled by users, I think it'd be great to include some kind of solution in the Atom core.

I'm probably late to the party, but is there any way I can do this currently?  Is there a dev branch or beta release with this enabled?

@lacostenycoder, look for Title Bar option in latest stable Atom release

@MaximSokolov, already found that thanks!

source: gharchive/pull-request

authors: BinaryMuse Daniel15 FezVrasta MaximSokolov brumm controversial hultberg keplersj lacostenycoder lee-dohm maxwellzdeamon nathansobo olegakbarov onbjerg paulcbetts silvestreh simurai sveggiani thomasjo thomaslindstrom


text:
Send buffers over IPC

IPC doesn't seem to support sending Buffers; you have to serialize them to a string, or it will send an array of ints. This adds some overhead in messaging.
It would be nice to have that! Even better would be the zero-copy Transferables that workers have. We do image processing in the UI, so it's hard to avoid sending buffers to the main process.

Data sent through IPC are JSON encoded, and since Buffer is not part of JSON specification it is impossible to achieve this with our current architecture.
Using the remote module can pass Buffer to main process without manual conversion though.

authors: pfraze zcbenz

repo: atom/electron


text:
rcedit.exe crashes in windows server 2012

Hi,
rcedit.exe crashes in windows server 2012 with the following stack trace.
Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	rcedit.exe
  Application Version:	0.2.0.0
  Application Timestamp:	528436dd
  Fault Module Name:	MSVCP100.dll
  Fault Module Version:	6.3.9600.17736
  Fault Module Timestamp:	550f42c2
  Exception Code:	c0000135
  Exception Offset:	0009d4f2
  OS Version:	6.3.9600.2.0.0.400.8
  Locale ID:	1033
  Additional Information 1:	1abe
  Additional Information 2:	1abee00edb3fc1158f9ad6f44f0f6be8
  Additional Information 3:	1abe
  Additional Information 4:	1abee00edb3fc1158f9ad6f44f0f6be8

Read our privacy statement online:
  http://go.microsoft.com/fwlink/?linkid=280262

If the online privacy statement is not available, please read our privacy statement offline:
  C:\Windows\system32\en-US\erofflps.txt

Strangely when i build from mac (with wine), it just works fine.. wonder whats causing this

Similar situation, rcedit.exe has no effects on windows 7 64 bit;

I had the exact same issue than you with another exe file. I noticed MSVCP100.dll was missing from my System32 folder. It's been fixed after I installed https://www.microsoft.com/en-us/download/confirmation.aspx?id=13523.

Is anyone still seeing this issue with 0.6.0 or later? There were fixes to address the dll issues.

authors: Rameshv kevinsawicki kuno rdubois

repo: atom/node-rcedit

license: mit

license_source: bigquery


text:
Show the bottom bar when going to a line

Just like with searching, add a bottom input bar when typing the line number for going to a specific line.  Very useful so you can see what you're typing, and is also the default functionality of vim.

In other words, show the operator-pending text in the status bar while typing.  :)
I'd like that.

In addition, when searching for a pattern, if none could be found, show a message, such as:

Also, if you reach the end of the file while searching and go back to the top, also show a message:

I hope you don't mind Scott that I've added these here as well since they all are related to search status.  If you'd rather break them into multiple let me know.

Looks great.  Maybe update the title, something about showing more vim-mode status in the status bar?  Not just what mode you're in.

Great Idea, I almost open a new Issue about that :), but someone thinks first XD

As stated in the README, this package is no longer maintained and is deprecated. We recommend that people use the vim-mode-plus package instead. Because of this, we are archiving this repository and closing all issues and pull requests. Thanks very much for your support and contributions!

authors: bronson caiocutrim lee-dohm msmaili

repo: atom/vim-mode


text:
Add update for 2018-03-19

Rendered
This update mostly links out to other material, so even though it looks small I actually put a lot of effort into explaining where we are at this week. I just opted to put my efforts into a more permanent document that we can hopefully maintain on an ongoing basis.
Gonna let this bake over the weekend and merge it on Monday. Comments and questions are welcome and may help improve the update.
/cc @ashumz

@nathansobo and @as-cii, thank you for your hard work on this. I'm tracking the project eagerly! (And once I come to terms with Rust's more esoteric features I'll do my best to help out.)
I like the switch to a client/server architecture. With respect to the communicating Workspace state between the client and server, I wonder if a GraphQL-like query language might make sense for relaying changes. Not only would it provide a concise syntax for changes in the updates() stream, it would also set the stage for a more granular render() response from the server down the line.
Starting with sending the whole state on render() would still make sense; my suggestion is that the GraphQL semantics might allow for a thinner layer of data being passed on render() at some point in the future.
The decision to use React on the client makes sense to me, for the context feature as noted, but also because it would potentially enable the facile development of clients on other platforms through 'React Native' libraries. GraphQL as a query language makes further sense to me here: different clients might require slightly different states, and GraphQL's syntax would accommodate and document attributes of the state that are added as the platform grows.
Cons of adding GraphQL or a GraphQL-ish query language for client/server communication: cognitive burden for developers?
Maybe you've already thought of this and reasoned against it: I'd be interested to hear your thoughts!

@breezykermo Thanks for your support! GraphQL crossed my mind early on in the process of designing what we're implementing here, so I can definitely see why you're bringing it up. Ultimately, though, I don't think it's a good fit.
What we're implementing here is pretty different from the typical architecture of a web application, because most web apps need to assume non-trivial and unpredictable latency between the client in the server. The typical web front-end manages its own internal state and processes all user interactions locally to minimize the impact of latency. It then pulls the data that it needs to support those interactions from the server, and this is where GraphQL is really useful. It allows the client to formulate a query that expresses its exact data needs.
In our case, the window is connected to the server over a local socket, meaning that latency is effectively zero. This allows us to invert the typical design. We don't even really process user interactions on the client at all, and instead forward them directly to the server. This allows us to maintain an abstract server-side representation of the entire user interface. Whenever the UI needs to change, we push data to the view. The view is never in a position to make a request. It only handles incoming data and updates to reflect the latest state.
I hope this clarifies why something like GraphQL doesn't quite fit into the model. It might make more sense when communicating between two servers, but even there we may want to implement a more custom protocol.

@nathansobo, makes sense! Thank you for taking the time to respond so thoughtfully and comprehensively. :)

authors: breezykermo nathansobo

repo: atom/xray


text:
Use correct value to fix percentage change

This was broken when we moved to CoinGecko.
Will do a followup PR to remove all references to CMC and instead refer to prices as fiatPrice instead of cmcPrice etc.

👍 Looks good.

authors: lukechilds sindresorhus

repo: atomiclabs/hyperdex


text:
Locked Secondary. Hive error on scan

Secondary non responsive and on further investigation looks like a HiveBox error
$ openssl s_client -ign_eof -brief 98cb53a3-b7ad-5c22-b56a-bc4803b8a405.hornet.atsign.zone:1898
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Requested Signature Algorithms: ECDSA+SHA256:RSA-PSS+SHA256:RSA+SHA256:ECDSA+SHA384:RSA-PSS+SHA384:RSA+SHA384:RSA-PSS+SHA512:RSA+SHA512:RSA+SHA1
Peer certificate: CN = 98cb53a3-b7ad-5c22-b56a-bc4803b8a405.hornet.atsign.zone
Hash used: SHA256
Signature type: RSA-PSS
Verification: OK
Server Temp Key: X25519, 253 bits
@scan
error:AT0010-Internal server error : HiveError: Box has already been closed.
@

Restarted secondary and all is well but we need to be able to detect this and recover seamlessly without admin interaction.
Should be straightforward to detect..

We have also put in place monitoring that checks every @sign every 15 minutes and lets us know if odd stuff is happening!

@cconstab Please close this issue if you no longer see the error in production

authors: cconstab murali-shris


text:
Render graph binding and driver patterns

This is an open discussion on the existing patterns as of v0.3, which has not been released to crates.io yet pending other ecosystem package updates (see Cargo.toml). I'll update this issue.
Status:

Stability alpha: validly does all the things but some things can still be requested in a way that triggers validation errors
API signature alpha: ensures a level of safety but feels quite "weighty" with the binding concept
Documentation pre-alpha: feel free to comment "this area confused me" here and I would ❤ to hear how/any feedback
Performance/allocation optimization: not really started except for experiments and critical bits

Particularly lacking features:

Cache/pool abstraction: currently creates new resources except for exact info matches; basically entirely todo!()
Ray-tracing: waiting for compute/graphic passes to stabilize a tiny bit more; API is mostly commented out
Full screen/resize/swapchain-recreate bugs

Anything else:

Comment on anti-patterns you see, impediments to contribution, etc.
"This should be just a graph!" - Well, maybe it should - what would that look like to you?
Success? Like the patterns? Help perfect them!

Thank you!

Bindings could be removed as a concept if we store the resource state using the private data extension. That way each image/buffer/accel would be given the appropriate barriers without having to "hold" the binding and then return an "updated" one on unbind.
I think the end result would be basically bind-by-reference instead of bind-by-value; and this would definitely simplify usage patterns for no appreciable downside.

When figuring out what kind of cache types are offered, it would be helpful to distinguish between swapchain images and "regular" images because this one class of resource is always a known size. See https://github.com/attackgoat/screen-13/pull/13


text:
🛑 MernCrud is down

In d2ca0b2, MernCrud (https://mern-crud-ki1x.onrender.com/db-status) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MernCrud is back up in 7efb32e after 16 minutes.

repo: atual-dev/upptime


text:
[Travis] more test tweaks

So many great tests in this project now! Great to see :+1:
I made some minor tweaks:

Cache cocoapods
Use Travis' pod install
CGFloat consts

I thought there was a problem with Travis not installing pods, but turns out :+1:

Also, pod install is not run if the Pods directory is vendored and there have been no changes to the Podfile.lock file.

Cool man, I have ported all of non-sound tests to XCTests, just now looking at clever ways to test that the right sounds were made.  Thinking of creating wavs and hashing them to compare against known out put, or even just taking an FFT of the output and comparing some markers.

authors: aure jhersh

repo: audiokit/AudioKit


text:
Redirect in child router (navigation strategy), when parent is using navigation strategy

I'm submitting a bug report

Library Version:
1.3.0 (also tried in 1.5.0)

Please tell us about your environment:

Operating System:
Windows 10

Node Version:
9.2.1

NPM Version:
5.7.1

JSPM OR Webpack AND Version
JSPM 0.16.53

Browser:
all (Chrome 64 | Firefox 59 | Edge 41 )

Language:
ESNext

Current behavior:
Redirecting in child router using navigation strategy is not working, when parent router also has a navigation strategy defined.
https://gist.run/?id=087cf483ccb4476a3c7cb8a76a49823e
If you uncomment app.js/line 27, navigation to rooms route stops working. The Url is being updated correctly, but the view models are not being loaded into the corresponding viewports. I could not perfectly localize the bug, but the viewport plan is empty. I think it is nearby AppRouter._dequeueInstruction method
Expected/desired behavior:
Redirect works in child router, even if parent route has used navigation strategy

What is the motivation / use case for changing the behavior?
Dynamic redirect based with navigation strategy, when parent route is using a navigation strategy

@EisenbergEffect something to consider for vNext?

If you point me to the right direction, I'm happy to contribute with a PR

This bug is a race condition. Adding the navigation strategy handler adds one too many items to the wrong queue, which causes the navigation pipeline before the navigation instruction is created.
The source of the bug is on history-browser/index.js#L235:
_loadUrl(fragmentOverride: string): boolean {
  let fragment = this.fragment = this._getFragment(fragmentOverride);

  return this.options.routeHandler ?
    this.options.routeHandler(fragment) :
    false;
}

this.options.routeHandler refers to Router.loadUrl, which returns a Promise. Once the promise is disregarded in the history-browser code, the race is on.
The right thing to do would be to

Correct the typings to return a promise,
propagate the promise upwards, and
await the promise in the Router.processResult function, here.

You'll end up with something like this:
function processResult(instruction, result, instructionCount, router) {
  if (!(result && 'completed' in result && 'output' in result)) {
    result = result || {};
    result.output = new Error(`Expected router pipeline to return a navigation result, but got [${JSON.stringify(result)}] instead.`);
  }

  let finalResult = null;
  let generateNavigationInstruction = null;
  if (isNavigationCommand(result.output)) {
    generateNavigationInstruction = result.output.navigate(router); // grab the promise
  } else {
    finalResult = result;

    if (!result.completed) {
      if (result.output instanceof Error) {
        logger.error(result.output);
      }

      restorePreviousLocation(router);
    }
  }

  // await the promise, or proceed immediately if no promise
  return Promise.resolve(generateNavigationInstruction).then(() => {
      return router._dequeueInstruction(instructionCount + 1)
    }).then(innerResult => finalResult || innerResult || result);
}

The most time consuming part of any fix is good working tests. Submitting the best tests possible will help me process your PR quickly!
Thanks for reporting this issue.

Sure, I'll check that :)

Should I create a PR in browser-history and then in router? Or is it okay to send in parallel?

@balazsmeszegeto you can send in parallel with mentions of each other.. that one depends on another if that's the case

Sure. I cannot promise to be ready during the weekend, but I'll work on it next week

@balazsmeszegeto don't promise anything.. It ends up badly usually (-:

@Alexander-Taran I've sent in the PR last week as promised :) When can I expect some review?

@balazsmeszegeto  I see that  @davismj assigned himself. Let's wait and see.

authors: Alexander-Taran balazsmeszegeto davismj

repo: aurelia/router


text:
Set 'routeConfig.navModel.title' cannot change title except in canActivate();

routeConfig.navModel.title only can be set in canActivate(). Hope it can be changed in other place.

I'm able to set it in both canActivate() and activate(), as long as the change happens before the router commits. That is, if you set routeConfig.navModel.title asynchronously, you must return the promise from activate so the router knows to wait for your change.
@boogunote Where is it you're hoping to set routeConfig.navModel.title? Can you post the code that'd like to work?
@EisenbergEffect It does seem like we're missing support for a valid use case here. Using aurelia/app-contacts as an example, say I wanted to activate the details view immediately and show a loading indicator while the contact was fetched. I could do that by not returning the promise in activate, but then I wouldn't be able to update the document title when the data loaded because the router would have already run the CommitChangesStep. How do you feel about supporting delayed title updates?

@bryanrsmith I definitely think we should fix this. I haven't looked into it to see how much work it would be. If you want to investigate further, let me know what you think would be a reasonable solution.

In the current implementation the navModel is a plain object property of the route configuration. We're allowing view models to mutate the config.navModel, and then reading that data in the final step of the navigation pipeline.
I propose separating the navModel from the route config. Other parts of the router use it to store state, such as isActive, which I think makes it more than just a "config" sort of thing. This would be a breaking change because route configs can provide their own navModel property. I don't think we document that anywhere, and Router.add copies all the navModel data off the top level config properties. I'd guess that's the API that most are relying on since it's what all the docs and examples use.
Once we pull navModel off the config we can create a NavModel class that holds a reference to the current instruction or context. Then we can move the title generation and setting logic into a setTitle or title setter that can perform the update outside the scope of the navigation pipeline. It would still need to coordinate the change with the pipeline to avoid updating the document title before the navigation is committed, but that shouldn't be a problem.
Paired with #74, the new signature of activate and canActivate could be
activate(params, routeConfig, navModel)

Or we could even collapse both config and navModel into a route object if we want to bundle everything up together.
Thoughts?

On second thought, perhaps canActivate should not receive the navModel at all. We should probably wait until we've decided to activate before making changes like setting the title.

Correct, we don't want anyone changing the title until the activate phase. One trick to bear in mind is that the title property is designed to be databound to and if we make it into a getter/setter then we can't bind to it without dirty checking it, so we need to avoid that somehow... If we can keep the title a simple property, that would be best. We might need some additional api that could update the title property and cause a rengeration of the document's title, which you mention.
Any ideas how long it would take to get this working?

Right, I forgot about the data binding. Maybe a title property for binding and a setTitle method that sets it & then handles the document.title change?
I wouldn't expect it to take more than an hour or two. I might be able to make the API change quickly if I can't find the time for the full fix tonight.

Yes, I think that would be the way to go. We can do the release on Tuesday if you want some extra time to get this in. I can easily s

I looked closer at this last night. Splitting navModel from config will take a bit more work than I originally estimated. The config object is what gets passed around as the main route representation, including in the route recognizer, so I think we'd need to change the internal representation of a route to make navModel a sibling of the config. I don't think I can confidently get that done by tomorrow. A few options...

We can stick with the plan, but bump the change to next release.
I can hack in the API change so that we start adding navModel as the third parameter to activate and canActivate. I'd circle back and fill in the internal refactor and fix the main issue of delayed title setting before the next release.
We can leave navModel on the config object so that we don't need the more extensive refactor. I discovered that we actually don't allow the consumer to provide their own navModel object, so this wouldn't be as bad as I originally suggested it might be. We could safely replace the plain navModel object with a class instance. This would be less work, and the change could probably be non-breaking. We'd just start recommending the use of config.navModel.setTitle(newTitle) instead of config.navModel.title = newTitle.

Option 3 is looking more attractive to me now that I know navModel isn't part of the initial config object provided by the consumer. I'd like it even better if the documentation and sample apps renamed the activate parameter name from "config" to "route", or something to better indicate that it's a stateful object.
activate(params, route, navigationInstruction) { // I neglected to include the final navigationInstruction parameter in earlier posts
  route.navModel.setTitle('New Title');
}

Ok, I think I agree with you. Let's go with 3 and we can work on renaming things in code and docs to support the idea. How does that sound? Thoughts on when this might be ready? No rush. I'd like to know if I should wait on the release or go ahead and do it tomorrow.

authors: EisenbergEffect boogunote bryanrsmith


text:
How were the diagrams generated?

Hi and thank you for this project @aurelien-rainone ! :)
How (using which tools) were the diagrams (eg https://raw.githubusercontent.com/aurelien-rainone/go-rquad/readme-docs/Creation.png) generated? They look so smooth!

Hi and thanks!
I used go standard benchmark report file, a bit of python to extract the data and plot it (with matplotlib). You can see the source go benchmark report and the plotting script in the readme-docs orphan branch

repo: aurelien-rainone/go-rquad


text:
Italian translation

The title is self-explanatory
it_IT.txt

Added! Thanks for the translation!

Added! Thanks for the translation!

repo: aurgiyalgo/BetterTownyWars


text:
🛑 repl.co is down

In 1c1e368, repl.co (https://hello-repl.auteen.repl.co) was down:

HTTP code: 404
Response time: 705 ms

Resolved: repl.co is back up in 6597933.

repo: auteen/autoreplit


text:
Example of linking without Lock

Are there plans to create an example of linking and unlinking accounts not using Lock? It would be helpful since I don't plan on using Lock in my implementation. It might be useful to just add an example to the auth0-javascript-samples repository.

The express app is now updated to use universal login.
https://github.com/auth0-samples/auth0-link-accounts-sample/pulls

Both SPA and Regular Web Apps are updated to use Universal Login.  Closing this issue.

authors: camiblanch zamd