Stub for exceptions debugger on large arrays #22
Conversation
… in the calling function
… of classes. It seems to work fine on Mac and Windows, too. Added back the check on the number of classes being sent over the wire to make sure this still works fine with IntelliJ (need someone to test it)
Changes to handle big projects. Advances client/server protocol version to v1.2.
…t is possible to use HaxeServer with another controllers
…eturning false. 2. Fixed static fields printing: Reflect.getProperty should be on class to get static field.
Different improvements and fixes
Stub for exceptions in debugger on large arrays
Stub large array
|
So, what is your reason for doing this? What are you trying to accomplish? Where do you expect these changes to be used? I'm asking because you've updated the protocol_v1.1 branch -- to a newer protocol version. We can't do that; it's effectively a frozen branch, and updating it MUST NOT change the protocol in any way. Only bug fixes are allowed there. IntelliJ IDEA requires the 1.1 version - using the protocol_v1.1 branch. It looks to me that this will change the format of the data coming through the protocol, which means that we need to bump this to a 1.3 version, which also requires changing the rendezvous strings as well as the reported version number. (I can always create a protocol_v1.2 branch from the master before your changes to support Visual Studio.) |
|
It seems I'm confused in the branches. I want to make a view restriction just for an array. Because it leads to crash of the debugger (Inteliji Idea, protocol v 1.1). In any case, it seems strange to me that a debugger crash 300 entries in the array. In general, the debugger often crash, but I did not have time to find other reasons. Crash -- I mean critical uncaught exception (in debugger) and program stop. |
No description provided.