TrueCrypt : tsconfig creation and behavior when it's not there

[hansrwindhoff]

I seem to remember that a couple of weeks ago the plugin would behave differently, the tsconfig was created automatically...
However, now when I open a .ts file from a folder that has no tsconfig, for the most part the plugin doesn't work, does not compile and is mostly inactive except for syntax coloring. It took me a long time to figure out that the missing tsconfig was the problem. The plugin does not show a message (that I could find) or indicate what is missing.

When I add a tsconfig to the folder I have to restart atom to get it recognized. After that every thing is fine. Is this intended behavior?

Otherwise the plugin is really great!

[basarat]

Thanks. Can you delete the tsconfig file and see if there is an error in the console : https://raw.githubusercontent.com/TypeStrong/atom-typescript-examples/master/screens/debugPromises.gif

[hansrwindhoff]

I don't see this exception after pushing ctrl+alt-I and ctrl+shift+r, regardless of wether the tsconfig is in the folder or not. May I add that I am on windows 8.1/ 64 bit.

[basarat]

It still creates it for my test case :

So I don't have a good reproduction.

[hansrwindhoff]

hmm strange, you are right when I use a folder with a single ts file I get the message and the tsconfig is created. But when I open a file from a folder containing many ts file it doesn't seem to work I will investigate some more... later: it doesn't have any thing to do with the size of the folder.

[hansrwindhoff]

...now it looks like it has something to do with the drive the folder is on, I have many projects on truecrypt volumes: when I open a ts file from windows explorer into atom, and the file is on a truecrypt (ntfs format) volume the tsconfig does not get created, when I copy the project to a "real" ntfs volume the creation works.

[basarat]

@hansrwindhoff on that truecrypt volume, can you execute : node -e "require('fs').writeFileSync('foo.json','{}')"

and see if foo.json shows up?

[hansrwindhoff]

yes it gets created

[basarat]

@hansrwindhoff run atom-typescript with parent.debug set to true : https://github.com/TypeStrong/atom-typescript/blob/master/CONTRIBUTING.md#debugging and see if you get errors?

[hansrwindhoff]

I am sorry I dont get what I have to do? tried to edit the parent.js file in the package folder and started atom but dont get any new messages?

[hansrwindhoff]

I did switch into dev mode but no new messages either:

[hansrwindhoff]

so here is some log info:
first opening atom on a "real" ntfs vol:
D:\temp\LIFOFIFO>atom --dev -f lifofifo.ts
App load time: 141ms
[8048:0401/194306:INFO:renderer_main.cc(212)] Renderer process started
[8432:0401/194307:INFO:CONSOLE(14)] "AtomTS worker started", source: C:\Users\hansw.atom\packages
worker\parent.js (14)
[8432:0401/194307:INFO:CONSOLE(669)] "'save-session.dataSaveFolder' could not set the default. Att
ned; Schema: {"type":"string","description":"The folder in which to save project states"}", source
ta\Local\atom\app-0.189.0\resources\app\src\config.js (669)
[8432:0401/194307:INFO:CONSOLE(57)] "Window load time: 1617ms", source: file:///C:/Users/hansw/App
189.0/resources/app/static/index.js (57)
[8432:0401/194352:INFO:CONSOLE(614)] "Error deactivating package 'snippets'", source: C:\Users\han
app-0.189.0\resources\app\src\package.js (614)
[8432:0401/194356:INFO:CONSOLE(167)] "ts worker successfully stopped", source: C:\Users\hansw.ato
ript\dist\worker\lib\workerLib.js (167)

D:\temp\LIFOFIFO>

now the same project but on a truecrypt vol:

U:\code\LIFOFIFO> atom --dev -f lifofifo.ts
App load time: 141ms
[10428:0401/194715:INFO:renderer_main.cc(212)] Renderer process started
[11252:0401/194716:INFO:CONSOLE(14)] "AtomTS worker started", source: C:\Users\hansw.atom\packages\atom-typescript\dist
\worker\parent.js (14)
[11252:0401/194716:INFO:CONSOLE(669)] "'save-session.dataSaveFolder' could not set the default. Attempted default: undef
ined; Schema: {"type":"string","description":"The folder in which to save project states"}", source: C:\Users\hansw\AppD
ata\Local\atom\app-0.189.0\resources\app\src\config.js (669)
[11252:0401/194717:INFO:CONSOLE(57)] "Window load time: 1744ms", source: file:///C:/Users/hansw/AppData/Local/atom/app-0
.189.0/resources/app/static/index.js (57)
[11252:0401/194723:INFO:CONSOLE(614)] "Error deactivating package 'snippets'", source: C:\Users\hansw\AppData\Local\atom
\app-0.189.0\resources\app\src\package.js (614)
[11252:0401/194724:INFO:CONSOLE(167)] "ts worker successfully stopped", source: C:\Users\hansw.atom\packages\atom-types
cript\dist\worker\lib\workerLib.js (167)

U:\code\LIFOFIFO>

looks pretty identical:

[hansrwindhoff]

So I did some searching for tsconfig in the lib folder of the plugin and then put some break points into the projectService.js file, but I am not hitting the function calls. you could tell me what to look for? Or we could do a team viewer session?

[basarat]

you could tell me what to look for

Basically a call to getOrCreateProjectFile and within that the path to https://github.com/TypeStrong/atom-typescript/blob/master/lib/main/lang/projectService.ts#L179-L184 i.e. createProjectSync : https://github.com/TypeStrong/atom-typescript/blob/master/lib/main/lang/projectService.ts#L180

I can't use teamviewer at the moment.

[hansrwindhoff]

I guess the break points are not being hit because the code executes in a worker thread/process? Even if I load the file from the real volume they are not being hit although the tsconfig is created...
I tried a break in L179-L184 and its not being hit, is there a way to debug a worker process?

[basarat]

is there a way to debug a worker process

Yes. If you have parent.debug set to true, the code should execute in the UI thread and you should be able to set breakpoints

[hansrwindhoff]

So I have in parent.js :

///ts:ref=globals
/// ///ts:ref:generated
var childprocess = require('child_process');
var exec = childprocess.exec;
var spawn = childprocess.spawn;
var workerLib = require('./lib/workerLib');
var parent = new workerLib.Parent();
debug = true;
parent.debug = true;

I am not sure how to otherwise do this? Could you explain?

[basarat]

@hansrwindhoff you should have in parent.js: debug = true :

///ts:ref=globals
/// <reference path="../globals.ts"/> ///ts:ref:generated
var debug = true;                                                              // HERE!
var childprocess = require('child_process');
var exec = childprocess.exec;
var spawn = childprocess.spawn;
var workerLib = require('./lib/workerLib');
var parent = new workerLib.Parent();
if (debug) {
    parent.sendToIpc = function (x) {
        return x;
    };
}

TIP: for later : if you open parent.ts in atom and modify debug = true you would get the same js. But just modify the .js for now to ease any other edge cases you might be suffering

[hansrwindhoff]

OK great, now the break points are being hit.
On the real volume everything is fine.
On the truecrypt volume atom hangs during startup:

U:\code\LIFOFIFO> atom --dev -f lifofifo.ts
App load time: 171ms
[2576:0401/214848:INFO:renderer_main.cc(212)] Renderer process started
[10424:0401/214849:INFO:CONSOLE(20)] "AtomTS worker started", source: C:\Users\hansw.atom\packages\atom-typescript\dist
\worker\parent.js (20)

[basarat]

On the truecrypt volume atom hangs during startup

You could start disabling code paths in atom-typescript till the hanging stops. In any case I'm blaming truecrypt 😛

[hansrwindhoff]

I am not sure if you are still interested but I did some more debugging.

Turns out that when you open a project from a truecrypt drive the creation/spawn of the child.js worker fails but only several minutes after the editor is already up and the plugin not working:

This call to startWorker came from parent.js line 19

one step further (F10) the message gets logged:

and then the on close call back gets called

Only found that by accident, because I had the breakpoints and then got distracted for while, when I came back the debugger was sitting of the break point.

[basarat]

I am not sure if you are still interested but I did some more debugging.

I am. Its a pleasure to see your analysis and that you are enjoying this tool. So lots of ❤️.

Looking at that error it seems that perhaps it isn't related. That error is potentially the worker simply running out of memory (project too large ... or open for a long time perhaps).

[hansrwindhoff]

well the project has only 4 files, out of which one is a ts file with ~10 lines, no subfolders, no node_modules folder, I was distracted for about 10-15min after opening atom... and it is totally reproducible :)

[basarat]

and it is totally reproducible

moving it off of truecrypt fixes it?

[hansrwindhoff]

Ok, I copied the four files over to a normal drive and have by now been waiting for ~15min, break point has not been hit and the plugin works...so I think moving it off fixes it.

[basarat]

I think it might be worthwhile investigating a truecrypt alternative :)

[hansrwindhoff]

I finally figured out what the problem was/is: Turns out it has nothing to do with truecrypt or bitlocker to which I had moved.
When AtomTS doesn't find the tsconfig.json in the folder were a ts file was opened, it searches up the folder tree until it finds one. If none can be found, it creates a new tsconfig in the folder of the opened file.
If it finds a tsconfig higher up in the tree it assumes that this must be the projects tsconfig and uses it. If this is now in a very large folder structure (as in my case, I had "saved" a tsconfig for later use in the root of my code tree) it might go through all the sub-folders (going back down again) looking for .ts files to enter them into the files list in the tsconfig. This either crashes or takes a very long time or something else.
I think it took me many hours of debugging to find this out.
Maybe it would be helpful to display a message about which tsconfig is going to be used, if it is not found in the current folder. That would have probably saved me some debugging, ... not that I don't like debugging ;)
I did try doing this by adding a message to tsconfig.ts if the file is found higher up:

export function getProjectSync(pathOrSrcFile: string): TypeScriptProjectFileDetails {
...
try {
projectFile = travelUpTheDirectoryTreeTillYouFind(dir, projectFileName);
if (dir !== path.dirname(projectFile)){
queryParent.notifySuccess(
{ message: 'AtomTS: tsconfig.json found higher up, make sure it belongs to your project:
' + projectFile }
);
}
}

and it works for small folders, but when the tsconfig.json is found in my large code folder atom isn't ready yet (UI thread not running I guess) and so the message never gets displayed.

[basarat]

Maybe it would be helpful to display a message about which tsconfig is going to be used, if it is not found in the current folder.

I plan to add this #331 probably after #318

Thanks for your investigation 🌹

[hansrwindhoff]

its fixed :), thanks Bas!

[corporatepiyush]

i am getting the same error on TS 1.5.3. whenever i try to create new .ts file in empty folder. i get following error.