{"push_id":639121708,"size":5,"distinct_size":5,"ref":"refs/heads/master","head":"6b0ccfc8f08287ba683ace8cf8c83f1674aaed3c","before":"9bc1802ca2c4821e3ef9101925cf53399e15e9df","commits":[{"sha":"e5955b2d5337862346faada9f10d29483a96574a","author":{"email":"fdfdeda19e62492563bdf4586ce42a0acc2dac8c@gmail.com","name":"Michał Pociecha"},"message":"Correct resumeToSuspension and checkStackFrame methods\n\nThere's corrected name of the resumeToSuspension and the message in\nassertions.\n\nassertEquals in checkStackFrame compares strings built using all\ntested values so in case of an error we'll see all information in\nthe logged message.\n\nAlso corrected one typo in a comment.","distinct":true,"url":"https://api.github.com/repos/wpopielarski/scala-ide/commits/e5955b2d5337862346faada9f10d29483a96574a"},{"sha":"81d19f9df22a64f1901921418bf71113896b793d","author":{"email":"fdfdeda19e62492563bdf4586ce42a0acc2dac8c@gmail.com","name":"Michał Pociecha"},"message":"Basic support for Hot Code Replacement in debugged JVM\n\nThis commit adds the possibility to modify and compile code, when an\napplication is run in a debug mode, and to have these changes visible\nand taken into account by the debugged VM without restarting the\napplication. This feature can be turned on/off (right now it's turned\noff by default). User can decide whether files containing compilation\nerrors should be skipped. Stack frames affected by changes can\nbe automatically dropped. Sometimes users don't like automatic\ndropping frames after HCR and they prefer to do that manually (see HCR\nin IntelliJ). Right now there's added also such a possibility. On the\nother hand it's a question whether it should be available, if we'll\nknow it can cause problems. Therefore, it may be removed in the future,\nif the HCR with automatic dropping frames would be much more reliable.\nThere are also added several integration JUnit tests.\n\nNote that HCR is limited by JVM's support for replacing classes. Its\ngoal is to allow to experiment with the code inside methods/blocks\nrather than to develop the whole application in the interactive mode.\nChanges of methods' signatures etc. don't work - similarly to other\nHCR implementations from Eclipse or other IDEs.\n\nThe implementation is inspired by the HCR support for Java. Scala\ndebug target, threads etc. don't extend the default Java/JDI model and\nbuild their own one. Therefore, they are skipped when processing\nevents by various Java-focused managers.\n\nThere's added ScalaHotCodeReplaceManager which implements HCR support\nusing the Scala model. Every ScalaDebugTarget has its instance of\nmanager which is also the listener waiting for events related to\nchanged resources. When we get an event about changed class files, we\nget byte arrays containing new versions of these files and replace the\nold ones in VM. After this operation it's needed to rebind frames\n(optionally also drop the obsolete ones) and to refresh breakpoints.\n\nEach from several added tests contains a fragment where the code is\nmodified and recompiled. To ensure that all events and messages are\ncorrectly propagated after the additional incremental build, it was\nneeded to use Thread.sleep with 500 millis. I know it's quite ugly\nsolution but it seems to work well and there are not many such tests.\n\nThere are serious reasons why this implementation is called the basic\nsupport:\n\n- Automatic dropping frames is based on the information which frames\nare marked as obsolete.\n\n- We get this information after performing HCR but it can cause\nproblems. According to the comment from Eclipse's HCR implementation\nfor Java, JVM is faulty when there are frames rendered as obsolete.\nTherefore, in Java implementation they try to find affected frames\nand drop them before performing HCR. We should do the same thing\nbecause VM sometimes crashes after HCR and some additional operations.\nThis is the serious blocker. Anyway even current implementation can be\nquite helpful in many situations. Except JUnit tests it was used to\ndebug e.g.some multithreaded application using futures.\n\n- There's also another problem. After performing HCR sometimes\nalready existing breakpoints behave strange. I had situations where\nfrom time to time I was getting a JDI event for the line breakpoint\nwith the different location than the line specified for this\nbreakpoint (sometimes it was one line before or after the expected\none). I was investigating this for a while but didn't figure out what\nto do with that. Also I wasn't able to reproduce such a behaviour in\ntests. It's something, what should be checked once again after the\naddition of the new approach to drop affected frames. In case of\nproblems it's always possible to recreate given frame manually, drop\nto the above frame and go to the expected breakpoint once again.\nNote: it's sometimes hard to hit breakpoints in Scala IDE even without\nHCR (they quite often are nondeterministic from the end-user's point\nof view of). Hence, it's not so simple to test this. It's not possible\nto fix everything, which basically is not related to this particular\nfeature, but is also used when debugging.\n\n- Dialogs shown when replacing classes is not supported by VM or fails\ndon't contain buttons to terminate or restart debug session. Currently\nthere's only an adequate message.","distinct":true,"url":"https://api.github.com/repos/wpopielarski/scala-ide/commits/81d19f9df22a64f1901921418bf71113896b793d"},{"sha":"1c512b9b100e04f226f36610ebada9cf94bce36b","author":{"email":"fdfdeda19e62492563bdf4586ce42a0acc2dac8c@gmail.com","name":"Michał Pociecha"},"message":"Minor corrections in Hot Code Replacement\n\nThis commit provides corrections after the code review.\n\nA class and an object used as messages when reenabling breakpoints are\ndescribed and placed in proper companion objects.\n\nChangedClassFilesVisitor can't be reused anymore but we got rid of var\nand `reset` method.\n\nIn case of error we use eclipseLog so users will be aware that\nsomething went wrong. I find it quite informative, when I see that\nredefining classes failed e.g. because of:\njava.lang.UnsupportedOperationException: Add method not implemented\nat org.eclipse.jdi.internal.VirtualMachineImpl.redefineClasses(VirtualMachineImpl.java:1245)\n(...)\nThere's also used EclipseUtils.withSafeRunner when it's possible.\n\nAlso corrected comments and logged messages (inter alia they are more\nconsistent with other error messages which we have in Scala IDE).","distinct":true,"url":"https://api.github.com/repos/wpopielarski/scala-ide/commits/1c512b9b100e04f226f36610ebada9cf94bce36b"},{"sha":"ad986591955f3fea8b2588d56cf2d99847bd8794","author":{"email":"fdfdeda19e62492563bdf4586ce42a0acc2dac8c@gmail.com","name":"Michał Pociecha"},"message":"Get rid of second full stop at the end of a sentence in error messages\n\nSince EclipseUtils.withSafeRunner adds . at the end of the passed error\nmessage, we don't need another ones directly in the message.","distinct":true,"url":"https://api.github.com/repos/wpopielarski/scala-ide/commits/ad986591955f3fea8b2588d56cf2d99847bd8794"},{"sha":"6b0ccfc8f08287ba683ace8cf8c83f1674aaed3c","author":{"email":"53fdba43521c8d2c2b4ff3a6f81e9f27ad86e7ac@gmail.com","name":"Iulian Dragos"},"message":"Merge pull request #921 from mpociecha/feature/hot-code-replace\n\nBasic support for Hot Code Replacement in debugged JVM","distinct":true,"url":"https://api.github.com/repos/wpopielarski/scala-ide/commits/6b0ccfc8f08287ba683ace8cf8c83f1674aaed3c"}]}