These are chat archives for TypeStrong/atom-typescript

16th
Apr 2015
Steve Ognibene
@nycdotnet
Apr 16 2015 03:04
I just found that console.error((<any>Error()).stack); works pretty well to get a stack trace at any point - worth putting in contributing.md?
Basarat Ali Syed
@basarat
Apr 16 2015 03:07

Note : I've done : https://github.com/TypeStrong/atom-typescript/blob/master/lib/main/lang/core/languageServiceHost.ts#L3-L7 this exact same thing (great minds think alike) ;)

But don't as we would prefer to have debug = true and then console.error gives you the stack trace for free ;)

Seperate from this discussion That language service host is what the TS team is using in TSServer / Sublime text. I've found it to be buggy and rolled my own based on atom's buffer package : https://github.com/TypeStrong/atom-typescript/blob/master/lib/main/lang/core/languageServiceHost2.ts
Steve Ognibene
@nycdotnet
Apr 16 2015 03:16
ok then
Basarat Ali Syed
@basarat
Apr 16 2015 03:16
@nycdotnet why did you end up needing the stacktrace?
Steve Ognibene
@nycdotnet
Apr 16 2015 03:16
Is there no way to hit breakpoints? I'm finding this "got here" style of debugging somewhat difficult
I'm just trying to get acquainted with the code base and seeing what leads where
Basarat Ali Syed
@basarat
Apr 16 2015 03:17
@nycdotnet you can use breakpoints if you set debug = true. That way the worker executes synchonously in the UI thread and you can use the standard debug tools
Steve Ognibene
@nycdotnet
Apr 16 2015 03:18
I see
Basarat Ali Syed
@basarat
Apr 16 2015 03:18
If you set debug = true then console.error will print the stack trace as well for free ;)
Steve Ognibene
@nycdotnet
Apr 16 2015 03:18
sometimes I feel like I'm in a time warp
I read things and I go "ok" but I guess I don't really get it
Basarat Ali Syed
@basarat
Apr 16 2015 03:19
I used stack only before I had debug = true feature added ;)
Steve Ognibene
@nycdotnet
Apr 16 2015 03:19
Like I just read that and didn't really understand
thanks Bas
Basarat Ali Syed
@basarat
Apr 16 2015 03:19
:rose:
Steve Ognibene
@nycdotnet
Apr 16 2015 03:22
are you working on the "implement this" refactoring?
that would be so awesome
Basarat Ali Syed
@basarat
Apr 16 2015 03:22
@nycdotnet : TypeStrong/atom-typescript#256 nope. Working on TypeStrong/atom-typescript#257 first. Asking TS team for help ;) Microsoft/TypeScript#2788
Steve Ognibene
@nycdotnet
Apr 16 2015 03:23
257 is definitely the more critical one - I agree
that's what I meant actually
Basarat Ali Syed
@basarat
Apr 16 2015 03:23
Cool. Yeah as you pointed out elsewhere its critical for JS to TS class code migration
Steve Ognibene
@nycdotnet
Apr 16 2015 03:23
meaning you use it and then TS says "hey what is that?" and you say "I dunno - implement it"
yeah well DQ isn't convinced so I guess "fix it with tooling" is the answer
actually I think the worst part of TS right now is not allowing custom this capture variables
having to rename a captured variable to this and implement lambdas sews chaos through code bases
at least it's labeled "in discussion" Microsoft/TypeScript#1859
Basarat Ali Syed
@basarat
Apr 16 2015 03:29
To be honest those code bases will have a hard time migrating any other form of ES6 either. I am more focused on ES6 code bases like babel/traceur to migrate to TS
Steve Ognibene
@nycdotnet
Apr 16 2015 03:41
yeah but it doesn't have to be :-)
Basarat Ali Syed
@basarat
Apr 16 2015 03:41
agreed :heart:
Steve Ognibene
@nycdotnet
Apr 16 2015 04:04
Hey my course should be out by next week
2:21 - longer than many feature films
You think F6 should work on tsconfig.json?
Basarat Ali Syed
@basarat
Apr 16 2015 04:09
@nycdotnet doesn't work right now. We only do stuff on .ts file being active
Steve Ognibene
@nycdotnet
Apr 16 2015 04:24
@basarat well I got in there and stumbled around a bit - I am going to take a crack at allowing the "error" to show up for TypeStrong/atom-typescript#244 while still allowing the emit to work as expected
at this point I'm thinking there needs to be some sort of way to bring an error along for the ride rather than throwing it
perhaps you can find some room in your heart for a threshold where we don't warn people at all - maybe 20 js files?
Basarat Ali Syed
@basarat
Apr 16 2015 04:25
@nycdotnet I was imagining that tsconfig.getProjectForFile takes a function that can take messages. If there is stuff like deprecations or (--out) that are unreliable than this callback is called.
Steve Ognibene
@nycdotnet
Apr 16 2015 04:26
that's fair - like what would have been needed for --allowBool etc
Basarat Ali Syed
@basarat
Apr 16 2015 04:26
and then projectService passing such a callback to tsconfig.getProjectForFile and then informs the parent child.notifyOrSorts that the tsconfig it is reading is not so good
@nycdotnet for allowBool it can be an error ... That infrastructure is already there. For error cases we throw our hands in the air (tsconfig throws an error) and we tell the user to fix it
Steve Ognibene
@nycdotnet
Apr 16 2015 04:28
I'm not making sense tonight
It was fun learning some stuff tonight - thanks Bas
you're a fire hose of knowledge
Because we throw it ... we've basically raised our hands to say ... can't do it. This was to keep tsconfig.ts perhaps usable by other projects later. But I guess taking a callback for a more gentle (I have an error but can continue) scenario
Steve Ognibene
@nycdotnet
Apr 16 2015 04:31
:thumbsup: will continue working on this tomorrow
Basarat Ali Syed
@basarat
Apr 16 2015 04:32
:heart: sweet dreams
Steve Ognibene
@nycdotnet
Apr 16 2015 04:43
did you see this? http://www.rq.crockford.com/
Basarat Ali Syed
@basarat
Apr 16 2015 04:45
@nycdotnet isn't async : https://github.com/caolan/async a) the same and b) Better as its callbacks follow the nodeback convention of error first argument
Steve Ognibene
@nycdotnet
Apr 16 2015 04:46
could be - I haven't worked with async yet
rq does support cancel
Basarat Ali Syed
@basarat
Apr 16 2015 04:47
@nycdotnet you're lucky :) don't. Instead use promises ;)
Writing cancel support with promises is like 3 line code
Steve Ognibene
@nycdotnet
Apr 16 2015 04:49
do you support it as a special reject?
Basarat Ali Syed
@basarat
Apr 16 2015 04:49
iTakePromisesAndCancel(promises:Promise[]){
   var defer = Promise.defer():
   Promise.all(promises).then((res)=>{
        if(!defer.promise.resolved)
              defer.resolve(res);
   }):
   return defer; 
}
If the user wants to cancel they would defer.resolve outside the iTakePromisesAnCancel
Steve Ognibene
@nycdotnet
Apr 16 2015 04:50
I see
cheers o7
Jari Pennanen
@Ciantic
Apr 16 2015 07:35
but the visiblity must be checked on the activate or editorWatch = atom.workspace.observeTextEditors too
just testing which one gets loaded first
Basarat Ali Syed
@basarat
Apr 16 2015 07:35
@Ciantic you could not worry about it being visible or not. No harm in making something visible > visible again
Jari Pennanen
@Ciantic
Apr 16 2015 07:35
I also see that this might be useless way to check, since it already relys on extension
    if (editor.getGrammar() instanceof typescriptGrammar.TypeScriptSemanticGrammar) {
        console.log("Show bar");
    } else {
        console.log("Hide bar");
    }
Basarat Ali Syed
@basarat
Apr 16 2015 07:37
Jari Pennanen
@Ciantic
Apr 16 2015 07:38
var filePath = editor.getPath();
var ext = path.extname(filePath);
if (ext == '.ts') { ... } is already in the observeTextEditors
Basarat Ali Syed
@basarat
Apr 16 2015 07:38
@Ciantic observeTextEditors is for editors opening ... thats not what we want. The user can open editor tab away etc
Jari Pennanen
@Ciantic
Apr 16 2015 07:39
but I want to run this hide/show thing when the editor loads after ctrl+alt+r
so it needs to hook two places
Basarat Ali Syed
@basarat
Apr 16 2015 07:40
@Ciantic give me an hour :heart: I need to wrap up what I am doing and I'll try ... your might be right :rose:
Jari Pennanen
@Ciantic
Apr 16 2015 07:40
I think I can get this done by then, but one extra, why run this:
when it's not TS file?
I think I'll throw that in the extension condition too
oh I see, it already does it's own if ext
now I get it, that thing already does the if/else for me
Basarat Ali Syed
@basarat
Apr 16 2015 07:46
@Ciantic I just reviewed the code. It needs a bit bigger refactor.
@Ciantic I need to fix how mainPanelView attaches.
Jari Pennanen
@Ciantic
Apr 16 2015 07:46
I haven't yet figured out where the bar is in the code, but that word gets me closer
Basarat Ali Syed
@basarat
Apr 16 2015 07:47
@Ciantic its mainPanelView and it is attached by (sadly) errorView as error view was all we had originally :)
Jari Pennanen
@Ciantic
Apr 16 2015 07:48
problem I meant with is illustrated by this:
atom.workspace.onDidChangeActivePaneItem((editor: AtomCore.IEditor) => {
    if (atomUtils.onDiskAndTs(editor)) {
        var filePath = editor.getPath();

        // Refresh errors stuff on change active tab.
        // Because the fix might be in the other file
        // or the other file might have made this file have an error
        parent.errorsForFile({ filePath: filePath })
            .then((resp) => errorView.setErrors(filePath, resp.errors));
        console.log("Show bar");
    } else {
        console.log("Hide bar");
    }
});
since neither of those is logged when I hit Ctrl+Alt+R
so there must be a hook in init somewhere too
Basarat Ali Syed
@basarat
Apr 16 2015 07:48
They wouldn't be . ... see my fix soon :)
Basarat Ali Syed
@basarat
Apr 16 2015 07:59
@Ciantic feel free to ask any questions about that commit : TypeStrong/atom-typescript@22c09c5 :heart: I do appreciate your effort, hopefully this will help familiarize atom / atom-ts a bit more :rose:
@Ciantic There a bit of typing in atom console (stuff like atom.workspace.getActiveEditor) involved
@Ciantic using the console is my main means of discovering atom API (despite documentation)
Jari Pennanen
@Ciantic
Apr 16 2015 08:01
I'm more used to VS style of discovering api, autocompletion in editor
and yes in JS projects the console autocompletion
Basarat Ali Syed
@basarat
Apr 16 2015 08:04
After using the atom fuzzy finder for autocompletion I find the VS / Js console auto complete finder highly lacking
Jari Pennanen
@Ciantic
Apr 16 2015 08:05
I don't like fuzzy at all, I disabled it. When I autocomplete typed part of code, I don't want it to suggest random things.
Basarat Ali Syed
@basarat
Apr 16 2015 08:06
@Ciantic I was talking about the algo, fuzzaldrin to be precise :)
Jari Pennanen
@Ciantic
Apr 16 2015 08:08
oh, I have no opinon on that :)
Basarat Ali Syed
@basarat
Apr 16 2015 08:08
@Ciantic the more you use atom e.g. ctrl+p or our autocomplete ... the more you will
Jari Pennanen
@Ciantic
Apr 16 2015 08:09
is that the within string auto-completion it's handy, but I don't want to have suggestions in typed parts of code which autocompletes wrong stuff, I'm used to relying on typed code that the suggestions are 100% accurate
otherwise if the suggestion list is filled with random strings, I can't rely on it as a API or help equivalent
Basarat Ali Syed
@basarat
Apr 16 2015 08:11
@Ciantic consider foo.reallyLongMethod we will find it from rm .... vs will force your rea and even resharper will force you rlm
as long as they are prioritized right and are correct it doesn't matter what one types
Jari Pennanen
@Ciantic
Apr 16 2015 08:12
yea, that kind of autocompletion is good, it only filters the known suggestion based on fuzzy algorithm, not generating suggestions based on fuzzy algorithm
Basarat Ali Syed
@basarat
Apr 16 2015 08:13
Yup. I did get what you were saying
Jari Pennanen
@Ciantic
Apr 16 2015 08:19
I've to get back to Real Work (tm). Thanks for the patch, I learned quiet a bit from it. I'm surprised how easily typescript extension is to modify, I suspect it has something to do with Atom's automatic TS support which landed few versions ago. There doesn't seem to be any extra JS files hanging around here eith.
Basarat Ali Syed
@basarat
Apr 16 2015 08:20

There doesn't seem to be any extra JS files hanging around here eith.

There actually there in our project in the dist folder. Reason is we are more bleeding edge than can be supported reliably in an atom release time frame.

Jari Pennanen
@Ciantic
Apr 16 2015 08:22
yes, but I was impressed by other things too, I just cloned it, practically nothing else. No npm installing loads of stuff which might or might not work, nor I had to do any extra steps.
Basarat Ali Syed
@basarat
Apr 16 2015 08:23
@Ciantic thats because we put the npm stuff into the repo https://github.com/TypeStrong/atom-typescript/tree/master/node_modules ... ive been a bad boy
Jari Pennanen
@Ciantic
Apr 16 2015 08:25
I wonder if that is why the repo is so big, it's only thing I was wondering, something like 18MB of code
Basarat Ali Syed
@basarat
Apr 16 2015 08:26
@Ciantic yes. Our code is not that much. Sorry about that
You would need to download those even if these were not in our git
Jari Pennanen
@Ciantic
Apr 16 2015 08:27
it certainly is easier to start developing when dependencies are in repo, fewer steps that could break
Basarat Ali Syed
@basarat
Apr 16 2015 08:28
FWIW I suspect if we run an npm install we will run into paths too long ... I am not looking forward to that bug
Jari Pennanen
@Ciantic
Apr 16 2015 08:29
haha, I hate Windows because of that, I have to use some ugly robocopy to delete node_modules like every time
I wish NPM had a global repository in format "somepackagename.version" so the package cache would be flat
stored in ~/.npm/package.version/ or something such
Markus Johnsson
@markusjohnsson
Apr 16 2015 08:30
hi all. how do I prevent atom-typescript from rewriting tsconfig.json?
Basarat Ali Syed
@basarat
Apr 16 2015 08:30
@markusjohnsson no option for that yet
@markusjohnsson Why wouldn't you want a tsconfig.json ?
not to sound rude :D :heart:
Jari Pennanen
@Ciantic
Apr 16 2015 08:32
I think he wants to TS not make changes to it?
Markus Johnsson
@markusjohnsson
Apr 16 2015 08:32
oh, I want it, I just want to maintain it myself
@Ciantic yeah, exactly
Basarat Ali Syed
@basarat
Apr 16 2015 08:33
@markusjohnsson which changes? the expansion to files?
@markusjohnsson thats the only change we make
Markus Johnsson
@markusjohnsson
Apr 16 2015 08:34
yeah, ok. I can probably live with that (although I think it also adds filesGlob)
Basarat Ali Syed
@basarat
Apr 16 2015 08:34
@markusjohnsson it adds filesGlob only if there is no files or filesGlob already
Markus Johnsson
@markusjohnsson
Apr 16 2015 08:35
I was trying out atom-typescript, others on my team uses other editors and the first thing I saw was that it rewrote the tsconfig
I see
I think it might be a problem if we have multiple editors and all different behaviour for changing tsconfig
Basarat Ali Syed
@basarat
Apr 16 2015 08:37
@markusjohnsson that's actually to help you ... so that files remains consistent for other editors that don't support filesGlob
Markus Johnsson
@markusjohnsson
Apr 16 2015 08:37
yeah, maybe I was to fast to panic about this
Basarat Ali Syed
@basarat
Apr 16 2015 09:03
fixMyTs.gif
Markus Johnsson
@markusjohnsson
Apr 16 2015 09:06
nice! is that driven with the language service?
Basarat Ali Syed
@basarat
Apr 16 2015 09:08
yup
@markusjohnsson Surrounded by infrastructure, here is the core of the code : https://github.com/TypeStrong/atom-typescript/blob/master/lib/main/lang/fixmyts/addClassMember.ts#L9-L58
Markus Johnsson
@markusjohnsson
Apr 16 2015 09:20
very nice indeed
Markus Johnsson
@markusjohnsson
Apr 16 2015 11:04
looks like it shouldn't be too hard to add custom refactorings
Basarat Ali Syed
@basarat
Apr 16 2015 22:28
Isn't hard. Because you get the complete code parsed and type checked ready to go. Thanks to the language service.