Visual Studio Code + Haxe = Swell editor / debugger

[Jeff Ward]

So Franco pointed me to Visual Studio Code - a free cross-platform and open source IDE from Microsoft (much like atom.io). However, it not only has language plugin support (syntax highlighting, completion, etc), it also exposes a language-agnostic debugger plugin interface (UI for managing breakpoints, pause/play, stack and variable display, etc.)

It is the latter I'm interested in, for hxcpp specifically. After looking over the docs, I think this is certainly within the realm of possibility, hopefully equally across all 3 major OSes (Win, Linux, Mac). I'm going to investigate this. I'm not typically a IDE/debugger person, but sometimes you just need it. There's already a hxcpp CLI debugger that I can look at, perhaps even leverage / extend.

Is anybody else interested in VSC? Is anybody interested in investigating the language plugin support? Minimally syntax highlighting, maybe code completion, or auto-compile and error display like try.haxe.org? Maybe refactor options?

Cheers,

-Jeff

[Hudson Ansley]

We need some Mac compatible IDE with debugging/breakpoint support, so definitely interested. VSC looks nice, like sublime text, but possibly easier to hook up a debugger to.

Cheers,

Hudson

[Phillip Chertok]

I'm very interested in this.  I love FlashDevelop it's fantastic but alas it is single platform.  I've been searching for a nice fast IDE to replace it for when I work on other platforms.   VS Code looks and feels great.  My only question would be why would one choose VSCode over Atom?  I guess Atom does not have the Debugger plugin interface you mention?  Ideally whatever IDE it is should support debugging on all natively supported haxe platforms - I understand this is a massive task (much bigger than I can handle with my skills) but I will continue to dream for this mythical IDE to rule them all.

On Monday, November 23, 2015 at 1:50:29 PM UTC-5, Jeff Ward wrote:

[Dan Korostelev]

Hi. I'm not very "interested" in developing a plugin yet, but I set up an extension and ported hx/hxml syntax highlighting from the sublime text plugin and also tried to write hello world extension in Haxe/js: https://github.com/nadako/vscode-haxe

понедельник, 23 ноября 2015 г., 21:50:29 UTC+3 пользователь Jeff Ward написал:

[Jeff Ward]

@Phillip - I like the atom editor, and I've searched (not extensively, but a bit) for info pertaining to building debugger plugins for Atom, and all I came up with was a few people saying, gee that'd be nice: https://discuss.atom.io/t/debugger-for-various-languages/9679

By comparison, VSC is like: here's the API, documentation, and a mock example for you. Please extend me!

@Dan - thanks, I'll check that out.

[Atul Kumar]

I definitely am very interested. As Hudson stated there is no decent debugger solution on mac yet (intellij still does not work for me).

In generell sublime works good for me for now, but the debugger is missing of course. Even if we wouldn't have decent "writing support" in VSC, I would be happy if I just could leverage the debugger and keep sublime for coding. However to have the whole package with VSC would be perfect.

I am however also very interested in having a working flash debugger (at this time even more than for hxcpp), since I think the flash runtime is still great and I am still using it a lot.

Also I think the lack of tooling is what keeping some people from considering using Haxe. At least for me it is hard to promote Haxe to my colleagues without presenting them a decent coding solution. And most developers I know are using macs, btw. So I believe having a great VSC plugin would benefit haxe adoption in generell.

Unfortunately I am also lacking skill / time to work on that myself. I would be extremely happy if somebody would make that happen, though.

Btw, as far as I know VSC is even based on the atom editor. So maybe there is a lot of code which can be reused from the atom haxe plugin? Then only the debugging thing has to be started from scratch.

Cheers.

[Philippe Elsass]

VSC is not based on Atom, only on the chromium shell (electron), but they surely could share some internals and I believe that the guys working on the Atom Haxe plugin are thinking about this use case.

In any case,  having coloring  and basic completion is only the first step of a less-dumb editor -  hopefully people get together to build a solid foundation for JS-based editors!

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--

Philippe

[underscorediscovery]

Aside from atom-haxe similarity in platform, there isn't much to share as is yet because we have been rewriting in Haxe.

Some will know about this but please keep in mind that over the last few months,
we have been migrating all the code that is shared from atom-haxe (and sublime) to being written in Haxe itself.

This makes it easier to have parsing/completion/linting feature parity and consistent bug fixes/tests in a single repo, without disjoint efforts.
Most of the work has been done in scratch repos or experimental branches on atom and sublime till now:
Currently we are finalizing the shared code into it's actual repo for moving forward with.

Our goal is to make efforts like vscode-haxe skip directly to the meat of the plugin,
so ideally the efforts going toward vscode should keep this in mind and avoid redundancy by working with us.
 

It's worth mentioning that the atom and sublime plugins will be our primary focus, immediate term.

But, vscode related developments could/should still progress alongside but with the shared haxe backend in mind.

[hosey hosey]

Last week I was messing around with https://code.visualstudio.com/docs/customization/colorizer  to make a plugin for vs code.  https://github.com/hoseyjoe/vscode_haxelang is what came out of the process.  Code coloring seems to work as well  code completion using ctrl+space.  Not sure how to get the system to compile though

[byFd]

Just stumbled over this https://github.com/hoovercj/vscode-extension-tutorial, i didn't dive into vscode extension development, but i thought that might be of help.

[Jeff Ward]

Quick update - some progress on the debugger. I got a barebones debugger extension written in Haxe that receives and responds to a couple commands (initialize & launch) from vscode. So as you can see, the debugging interface actually does show up.

It's a little slow going as the only examples are heavily steeped in TypeScript / node. But it's always fun to make a small first step.

[Marcelo de Moraes Serpa]

> But it's always fun to make a small first step.

Amen :)

Looking good!

[Lars Doucet]

Given that one of Haxe's main "missing pieces" is proper tooling, and Jeff now seems to have gotten on the ball with not just one, but TWO excellent and central haxe tools (HxScout and now hxcpp debugger integration)... any chance either the Haxe Foundation or some motivated individuals on this forum might want to kick in and give some momentum to this?

His Patreon is here:

https://www.patreon.com/hxscout?ty=h

HxScout is already amazingly useful, and with a little bit of polish could become indispensible. Combine that with a hxcpp debugger for a popular IDE and 2016 could be the year Haxe really starts to break out.

[Marcelo de Moraes Serpa]

I don't use HxScout currently, but I appreciate a lot the work Jeff has been doing. My pledge is there :) Hope it helps and gives some momentum for others to contribute also. Go Jeff!

[Cambiata]

Just to remind ourselves about how super-cool it would be with a interactive debugger for Neko...
https://github.com/HaxeFoundation/neko/issues/74

[Jeff Ward]

I'll try to make sure the actual debugger interface is abstracted, in case neko runtime gets a debug interface. :)

[Jeff Ward]

Thanks Lars and Marcelo, I appreciate the support and kind words. Cheers!

[Atul Kumar]

or fdb ;)

Thanks a lot.. That looks very promising. Really great work!!

If I find some time I might try to get fdb working also. If it does not get to complicated ;).. already found some documentation from adobe about the interface though.

Cheers..

[Jeff Ward]

Hey all, just a quick update -

I'm still making good progress - starting the debugger from VSCode launches my adapter, which runs a compilation command (specified by a <project>/.vscode/launch.json file, e.g. haxe build.hxml or openfl build linux). The compile status is reported back to VSCode, and it starts a HaxeServer debug instance, then launches your app. (Actually, it'll be a slightly modified HaxeServer with a custom controller I'm modifying from CommandlineController.)

I'm receiving the breakpoint definitions from VSCode and I'll soon be injecting those into the controller. Then I have to figure out how to get variable and stack information passed back and forth between vscode and the debugger in the format they each expect.

There are a few issues -- the vscode debugger console inexplicably isn't displaying all the messages I'm sending to it (I pass all the compile process stdout so you can see the build progress, but it only displays some lines.) And on the Haxe side, the sparsely documented Process.kill() doesn't seem to be actually killing the process (e.g. if the user presses stop, I need to kill the compile or running app -- neither is being killed.)

Oh, and I built a slick little asynchronous wrapper around haxe.io.Input so you can determine whether the Input hasData() before you enter a blocking read() method. (It probably already exists, but I didn't find one.)

Anyway, it's still early, but encouraging progress!

Once I get to a semi-working state, I'll open up the repo for feedback and help! :)

Best,

-Jeff

[byFd]

This sounds super cool, looking forward to it.

Thanks already for the effort you put into it!

[Jeff Ward]

FYI, in case you didn't see Twitter, I now have call stacks, variables, pause, and continue working in vscode.

But I have a couple questions. Is anybody familiar with the hxcpp-debugger? Hugh, or anyone who's used it a bit? I've verified that I'm getting the same variables in VSCode that I get in the commandline debugger, and I notice a couple things of note:

• I see a lot of errors evaluating/printing various values.
• I also see a lot of nulls, null types, null values, etc

See screenshots below. These issues inhibit visibility and usefulness, and I'm wondering if there are technical limitations, or things I should filter out, or perhaps if there are known issues?

Best,

-Jeff

Interestingly, these are functions, and e.g. the signature of findSlash is:

    private static function findSlash(str : String, index : Int) : Int

[Jeff Ward]

So, I got file/source working, step in/out and next. This is getting really close to usable -- I need to get breakpoints implemented, then test on Windows and Mac before release.

BTW - I think it seems only fair to give my patreon supporters early access... Just sayin. ;D

gfy-video: https://gfycat.com/SnappyGrotesqueFreshwatereel

gif:

[Franco Ponticelli]

Are you going to support debugging for JS (node/browser)?

Great work!

--

[Adam Parrott]

This is great!  Let me know if you need anything tested under Linux and I'll be your huckleberry.  :-)

Adam

[Jeff Ward]

Hi Adam - I'm on Ubuntu myself, so hopefully Linux is in decent shape. :)

Hey Franco - I hadn't really considered JS yet -- I assume the browser tools are decent? I think Lars said he got source maps working. I don't work much in Haxe->JS at the moment, but I probably will soon.

As for node, I just don't know much about it. The ideal situation from my current codebase is that there is a CLI debugger for the given runtime that I can wrap, such as Flash's fdb. Is that the case with node?

Best,

-Jeff

[Marcelo de Moraes Serpa]

Great work, Jeff!

As for node, I never had much luck debugging through the CLI (as I do for Ruby), but this works great: https://github.com/node-inspector/node-inspector. You can debug node apps using regular `debugger` statements or breakpoints using the browser inspector (Webkit). 

[Hudson Ansley]

Wow, this is looking great! Just signed up for your Patreon, thanks for working on this!

Cheers,

Hudson

[Hudson Ansley]

BTW- this is the type of thing the Haxe Foundation should support! It will make Haxe much more attractive to developers to have a Mac debugger tool.

[Jeff Ward]

Not to worry, the Haxe Foundation has given me a courteous ping. :)

[Greybeard]

On Saturday, December 5, 2015 at 5:01:05 PM UTC-8, Jeff Ward wrote:

 

But I have a couple questions. Is anybody familiar with the hxcpp-debugger? Hugh, or anyone who's used it a bit? I've verified that I'm getting the same variables in VSCode that I get in the commandline debugger, and I notice a couple things of note:

• I see a lot of errors evaluating/printing various values.
• I also see a lot of nulls, null types, null values, etc

There are a couple of reasons that you will see null for variable display:

1) The value hasn't been initialized yet.

2) The value actually calculates to null.  (Which may be correct behavior.)

3) The value can't be calculated: Values returned through the debugging interface are retrieved through reflection, and ultimately Std.string().  Therefore only base types are handled natively.  Complex types end up running toString() on your objects (toString() should never have side effects!).  If toString() doesn't exist or return a String value, then you will see the null values. 

There are also some variable names returned that are not really Haxe objects, but are .cpp created variables -- those created in external libraries like openfl.  Those will generally give an evaluation error, rather than returning null.

See screenshots below. These issues inhibit visibility and usefulness, and I'm wondering if there are technical limitations, or things I should filter out, or perhaps if there are known issues?

Best,

-Jeff

Interestingly, these are functions, and e.g. the signature of findSlash is:

    private static function findSlash(str : String, index : Int) : Int

Type.getClassFields() is used to retrieve variable names.  The debugger used to only return actual variables; we would remove those from the list that matched Reflect.isFunction().  However, the fields for private variables are not included in the list from Type.getClassFields(); only their accessors are.  Therefore, to allow the values of private variables to be displayed, we removed the filter.  The result is what you see: you get entries for all of the functions as well.  Annoyingly, if a field is not private and it uses accessors anyway, you get the value twice: once for the variable, and again for the accessor.

 

[Ahmad Aulia Noorhakim]

"...then test on Windows and Mac before release."

now that is something you don't hear often. Loving it. Will definitely try it out when it's publicly available.

[BP]

Yeah this is a total win if you can get this to work - one of the big issues I have with developing on a mac!

[Jeff Ward]

FYI, making progress on Windows support (thanks for the help Lars, and got a bug fixed from the vscode guys), Mac support (with my friend & coworker, Sean), and recently implemented multi-threaded debugging support.

Best,

-Jeff

[whitetigle]

Bravo !

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

-- 
--
François Nicaise
www.francoisnicaise.fr
Freelance Developer / Designer 
https://www.linkedin.com/in/fnicaise

[Lewis Lepton]

i sadly cant help back this project since i do charity work which is free. but will look forward to the public release of this ;)

[Jeff Ward]

Hey guys,

So I've decided to open this up, as I could use some help with Mac and Windows support. Know that right now there are missing features, it partially works on Windows (one project does, one project doesn't), and I haven't seen it work on Mac at all (app crashes).

Hopefully the community can figure out the remaining issues and get this up and working!

Here's the vscode-hxcpp-debug repo. The readme should cover setup and testing. The issues are listed in the issues panel.

Let me know if/how it works for you, and feel free to be in touch and submit issues and PRs!

Also, if anyone is still working on better language support (auto completion, go to definition, etc), I'd be interested in your progress!

Best,

-Jeff

[Boris ( Mario Pozzo )]

Jeff,

I've been trying to make it work in windows, but so far I've been unsuccesfull.
I've cloned the github repo in the extension folder, as instructed,
and configured the project in vscode, but it's complaining about the
DebugAdapter bin folder not being found.

So I tried to build the adapter doing

haxe build-windows.hxml

but I get this error

src/debugger/VSCHaxeServer.hx:21: characters 7-29 : Type not found :
debugger.VSCController
src/Main.hx:34: lines 34-886 : Defined in this class

I tried installing the debugger lib from haxelib, but I still get the error.

I'm doing something wrong?

Thanks

Mario Pozzo

[Jeff Ward]

Hi Mario,

Oops, that's what I get for last-minute changes. I removed an old import statement. Sorry - pull and try again.

Best,

-Jeff

[Jeff Ward]

A couple other notes for people trying this:

- You need the git version of hxcpp-debugger (not the haxelib version) - it's in the readme

- The test cli sample project should work on windows (it did for me, the test openfl project did not).

- For linux / mac, you need to use the right launch.json file in project/.vscode/

- the bin directory is not checked in, so you will need to build the debugger with haxe build-<platform>

Ideally at some point this will get more productized and scripted / templated to make it easier to use.

I also pinged Dan K asking if there is any chance of "code completion" and "go to definition" support in vscode-haxe.

If we can pull some more features together, we could have a really nice cross-platform IDE solution.

Best,

-Jeff

[Boris ( Mario Pozzo )]

Jeff

Thanks, I can compile de adapter now.

Now I'll try the sample projects.

Mario

[Jeff Ward]

FYI, I've made a titch of progress toward code completion in Visual Studio Code. It's far from ready to go, but it does prove it's doable. The VSCode GUI does provide some nice functionality, and the JavaScript-y / promise-y API isn't too bad. :)

Best,

-Jeff

[Jeff Ward]

Hey all,

I've published the alpha version of my code completion vscode-haxe extension. It's a fork from Dan's to which I'm adding code completion support.

Note that it has some pretty big limitations -- most significantly is that 1) you have to start the haxe completion server by hand, and 2) it requires a build.hxml file (named that) in the root of your workspace.

As Sven said, there's an effort called Tides underway to externalize some of the common IDE functions into a shared library (including starting and managing the haxe completion server) -- so I'll integrate that when it's available.

There's a test_proj project included with a build.hxml so you can quickly try it -- open the test_proj folder in vscode.

Note: This isn't working on my Windows box -- I'm debugging why now, but it's not hitting the completion server (firewall, something else?)

Best,

-Jeff

[Jeff Ward]

Ok, fixed windows paths. pull away. :)

[Todd Kulick]

Jeff el. al.,

I finally took some time to read a bit about Visual Studio Code. While I'm a sort of die hard emacs user myself, it looks pretty cool. That said, I was looking at the license terms and I saw this...

"2. TIME-SENSITIVE SOFTWARE. The software will stop running on 31/12/2016 (day/month/year). You will not receive any other notice. You may not be able to access data used with the software when it stops running."

I'm curious what you think of and make of that. I guess it makes me a bit suspicious of investing effort on this IDE.

As you may know, at TiVo we are working to make IntelliJ a better Haxe environment for code development and debugging. While I'm down with the OSS philosophy of moving in lots of directions at once and tapping people's passion, Haxe is a smaller community and we certainly all benefit if we can get aligned to get high quality tools.

What do you think of the longer term prospects of Code as a free, multi platform Haxe IDE...?

[Nico May]

Todd, I would *think* that was for the closed source version, believe microsoft open-sourced it recently so I doubt that would stand, but I cannot say for sure,

Nico

[Todd Kulick]

Hrm. Welp, I'm not at all certain, but I just read that today from license link that you must acknowledge before downloading the software. Seems to be in play...very interested to hear any other advice or insight on this issue.

[Todd Kulick]

Yah, code on github seems to say MIT license...

[Daniel Llewellyn]

> On 20 Dec 2015, at 19:10, Todd Kulick <to...@kulick.com> wrote:
>
> Hrm. Welp, I'm not at all certain, but I just read that today from license link that you must acknowledge before downloading the software. Seems to be in play...very interested to hear any other advice or insight on this issue.

Visual Studio Code is Open Source under the MIT license (https://github.com/Microsoft/vscode/blob/master/LICENSE.txt). The license you cite, I believe, is for the current downloadable pre-compiled version which was released before the source code was opened.

[katopz todsaporn]

Judge form title here https://code.visualstudio.com/license#vscode

It's for “BETA” release software, source code is MIT so it should be fine.

And yes haxe must get in VSCode ASAP, It's time to make a move! :)

[Christian Afonso Ferreira]

The lack of debugging tools is the only thing keeping me from use Haxe whenever I can use a high-level language.
The hxcpp-debugger wiki seems to be outdate about how it works and there no much info about the debug helpers in hxcpp so I've just given up on Haxe for some projects.

I'm very interested in the development of this extension.

[Jeff Ward]

FYI, Patrick Le Clec'h did some awesome work on the vscode-haxe extension:

• Organized the code
• Added "jump to definition" (ctrl-click on a function, or peek with just ctrl-hover, see below)
• Added support for Haxe 3.3 and his custom in-memory-file-patch compiler, with seamless fallback to 3.2.1.

I've merged this back into my vscode-haxe repo.

Thanks Patrick!

Best,

-Jeff

[AlienCoder]

First of all:

Thank you Jeff, for this debugger. It definitely fills a gap.

But regrettably I do not get it to work...

I have followed the instruction until the point of building the Debug Adapter. It has been compiled so far.

But then, after a restart of VS Code there is still this error message telling me, that the Debug Adapter bin has not been found.

Did I do something wrong by not linking to that adapter? Should I refer to it manually by telling VS Code where to find it?

Or do you have any other suggestions, what I could have done wron?

Kind regards
Michael

[Jeff Ward]

Hi MIchael,

The debug adapter bin is the binary that gets built when you run the haxe build-<platform>.hxml build. You can see where vscode expects to find the file here: https://github.com/jcward/vscode-hxcpp-debug/blob/master/package.json#L31-L39

Of course it depends on which platform you're on, and this must be under your .vscode/extensions/vscode-hxcpp-debug directory.

Which platform are you on?

Also note that the debugger doesn't work well on Windows/OSX, and there's a fix currently in the works.

Best,

-Jeff

[AlienCoder]

PS:

VS Code runs on a Linux mashine ( Ubuntu )

[AlienCoder]

Thank you very much for your reply. I have overseen one step.

Now, I have stepped into another tricky thing.

But I will have a look at it tomorrow and I will first try to solve it on my own.

Bye
Michael

[AlienCoder]

Is it possible to make it more error tolerant? Throwing an error message instead of freezing would be great.

Please don't get me wrong. Of cause, I do not want to criticize your work, as it is very generous from you to share it with us. And probably the trouble maker lies in the Debugger-Adapter-Philosophie of CS Code (just a guess).

But the trouble I have to face is, that the system hangs. And following your instructions, the problem most assumingly lies in the .json file.

Regrettably trying out to fix it is no effective way of working, if the computer hangs for at least 30 minutes after each crash.

I have reactivated an older computer of mine to exklusively dedicate it to Linux (Ubuntu) and the debugging process with VS Code. This old mashine goes in slow-motion anyway.

Having an easy way of debugging would be quantum leap for the evolution of HAXE. So I hope, that we can take a few more steps to make the debugging more stable.

But thanks for your efforts anyway.

[Jeff Ward]

Hi, I believe the freezing issue (if it's on Windows or Mac) is related to: https://github.com/jcward/vscode-hxcpp-debug/issues/25

It's in the process of being fixed, with discussion on the PR at: https://github.com/HaxeFoundation/hxcpp-debugger/pull/10

Best,

-Jeff

[AlienCoder]

Well, I don't know if the following hint helps:

This issue also occurs on a Linux Mashine ( Ubuntu ) accessing a Windows filesystem via SMB protocoll.

So, my first reaction was, that it's not a Windows issue. But maybe it has to do something with the Windows filesystem? Or is there a constellation where also Linux crashes?

I wish you good luck, figuring that out.

Kind regards
Michael