We recently decided to integrate Material Design into our mature GWT application and this has finally forced our hand on moving from Legacy dev Mode to Super dev mode. We have this working fairly well using Chrome and Intellij IDE, 2016.2. One lingering problem though is viewing Java containers (Lists, Maps, etc.) in the debugger. In the screenshot below, the two expanded supportingCopyWidgetPresenters and supportingCopyEventPageBlockContentElements are both declared as java.util.Lists:
In case this is hard to read, the debugger is showing both lists values to be:
array = Internal error: com.google.gson.JsonParseException: Expected BEGIN_ARRAY but was BEGIN_OBJECT at line 1 column 1386
Is there a special argument I need to pass to super dev mode to have it interpret Lists (and Maps, for that matter) correctly in the debugger? Is this a matter of telling super dev mode to use a different JSON parser?
Any help is greatly appreciated!
This was an issue with the version of Intellij. This was answered in the GWT google group.
Related
We have a problem using Paperclips (printing library for SWT) on scaled monitors, but I don't think it has anything to do with the framework and all with the Eclipse environment.
Let's see an example:
Left is the print with no scaling (or 100%), right is the same print started on a monitor with 175% scaling. I know what you are thinking: the monitor and its resolution / scaling should have no influence on a print. Right, should.
While that's sad and all, it would not be much of a problem. But there comes the kicker: The above prints were generated by a JUnit test case run as plug-in test. If I run them as a regular unit test both work.
Clearly something in the Eclipse environment works differently when started in an OSGi context, and I'm trying to find out what it is (so I can maybe prevent it).
And I think that's a nice puzzle.
If you need a hint for what SWT class might be the , I narrowed it down to this file ScalePrint.java for the table (i.e if I remove the instance of ScalePrint from my demo, the table is displayed correctly; the header is still wrong, though).
I can confirm the error exists only in Eclipse 4.6, and not 4.5 or 3.7 (which is not entirely surprising, since 4.6 is the first version to support scaling). And if I add -Dswt.autoScale=100 to the VM options to disable scaling, it works as expected, too.
I could append my test case, but as I said, I don't really think it has anything to do with Paperclips per se.
So... what could break the scaling when the entire Eclipse framework is started compared to running the same code in a plain Java application?
The Problem is the use of the class Transform, which itself uses the static field DPIUtil.deviceZoom (in the form of DPIUtil.autoScaleUp(float dx)).
Since DPIUtil.deviceZoom is a static field everything fails when used with a primary monitor that has scaling (since printers don't).
I often need to check content of list during debugging dart app in Webstorm (Intellij). When I do evaluate expression it shows me:
To see what is inside the list I have to manually evaluate each of: some_list[0], some_list[1]... etc. Are there some more convenient ways of browsing lists during debugging?
This works fine when debugging Dart server/console application but isn't yet supported for Dart browser applications.
See https://youtrack.jetbrains.com/issue/WEB-13889
I usually use watches like _players[0] to investigate the values. I know know a very convenient workaround ...
Context
As a university project we want to change the the pharo vm to use an object-table and see what happens.
We use a pharo-vm clone from github and VMMaker. Building the VM works fine.
To get started we added a primitive that returns an incremented Integer:
InterpreterPrimitives>>primitiveIntegerIncrement
"increments an integer"
self pushInteger: self popInteger + 1 .
and modified StackInterpreter class>>initializePrimitiveTable accordingly
MaxPrimitiveIndex := 576.
"... and so on ..."
(575 primitiveFail)
(576 primitiveIntegerIncrement))
And it works.
Problem
When we make changes to the VM we want to test-run already in the SmalltalkImage so we do not need to compile and see it did not work.
Something like:
StackInterpreter test: '1 inc'
And then I can debug if the primitive is wrong or an error occurs. Of course there needs to be done much more but how can I achieve this?
What we tried
category VMMaker-InterpreterSimulation class StackInterpreterSimulator. Trying the code in the comments
DoIt
^ (StackInterpreterSimulator new openOn: Smalltalk imageName) test
errors:
displayForm := 'Display has not yet been installed' asDisplayText form.
the ByteString does not understand asDisplayText
(CogVMSimulator new openOn: Smalltalk imageName) test
(InterpreterSimulator new openOn: Smalltalk imageName) test
error:
PrimitiveFailed: primitive #basicNew: in Array class failed
I also found this screen cast but it only debugs the VM from outside using gbd: http://vimeo.com/22485382#
Our project is hosted here: http://smalltalkhub.com/#!/~kirstin/PharoObjectTable
Current Status
We started implementing an object table. The lookup of attributes can go throught the object table. Full object table support and no usage of direct pointes is very tricky since pointers are expected everywhere. So we use pointers into the object table to identify when a lookup should go through the OT. We also found all object creation primitives and add new objects to the table.
How long is your project and how many people are you ? To me what you try to do is quite some work. Do you have good knowledge about low level behavior ?
To answer your question, the main problem here is that the cog simulator is not maintained in the pharo vm fork. This is because no one in the pharo crew use the simulator. We only use external debugging from gdb. In fact the pharo folks work mostly on VM plugins, the core of the VM is mainly maintained and developed by Eliot Miranda which works on Squeak. Therefore we report to him when there's a bug in the VM core.
For your project you would have to split it in at least 2 steps:
step 1: make the object table work with the stack VM
step 2: make the JIT work with your object table
Note that for step 2 I would recommend not to change the way an object access its header, therefore having a VW-like object table where you have the fixed size header on the one in the the object table, and the fields of the objects (and maybe header extensions) in the heap.
So use the StackVMSimulator and build the StackVM first. When everything will work (including context), you can think about hacking the JIT. Recently Guillermo Polito ported the Stack VM to the build process (see PharoSVMBuilder instead of PharoVMBuilder), a guy reported problems with this builder but you could hack it a bit to make it work.
Now to make the simulator work on Pharo 2.0 (which is the Pharo version of the generator image you have), you have to open the monticello browser and merge from Eliot's branch the Cog package (repo MCHttpRepository location: 'http: //source. squeak. org/VMMaker'), but not the latest Cog, the one at around the same date as the current VMMaker package of pharo-vm because the latest Cog and VMMaker of Eliot's branch are not stable.
The alternative being to start from Eliot's build image and merge things from the pharo branch. Here are infos about how to build the squeak development image (http://www.mirandabanda.org/cogblog/build-image/).
Then Eliot gave me this script once:
| cos |
cos := CogVMSimulator newWithOptions: #(Cogit SistaStackToRegisterMappingCogit).
cos desiredNumStackPages: 8.
cos openOn: 'my/favourite.image'.
cos openAsMorph; toggleTranscript; halt; run
You don't need the SistaStackToRegisterMappingCogit option. I guess some similar script with the StackVMSimulator should work.
Lastly there are some documentation about the simulator but it is only for the CogSimulator (these documentations expects you already knows how the StackSimulator works, and just give you hints about how to use it with the JIT):
http://www.mirandabanda.org/cogblog/2008/12/12/simulate-out-of-the-bochs/
and in one of the video named "Cog VM (part x)", x being from 1 to 6, Eliot shows how he uses the simulator to disassemble x86, print the stack and inspect the heap.
Another tip, ask your questions on the pharo mailing list (pharo users or pharo dev), because here no one may notice your question (fortunately someone pointed me out your question this time).
And tell on the pharo mailing list if you managed to run the simulator in Pharo 2.0, some people (as me) are very interested in it. I was planning to do it at some point.
Good luck ! Nice project anyway.
The last time I tried to use the simulator is roughly a year ago, and I did not make it work.
However, there are a few patches, which I assume never got integrated that might be of help:
https://code.google.com/p/cog/issues/detail?id=106
https://code.google.com/p/cog/issues/detail?id=107
https://code.google.com/p/cog/issues/detail?id=108
Issue 107 includes a patch for your asDisplayText issue.
I've been trying to use the JFace ProjectionViewer to implement folding in a standalone Java app. I got the idea from this article:
http://www.eclipse.org/articles/Article-Folding-in-Eclipse-Text-Editors/folding.html
However the source code provided with the article is for an Eclipse plug-in, not for a standalone.
The particular problem I'm having is that I can't get the VerticalRuler to respond and cause folding/unfolding.
Since I get the expected results, i.e. line numbers in the ruler, when I change from using a VerticalRuler to a LineNumberRuler while leaving everything else the same, I think my problem is specific to the implementation of the relationship among the ProjectionViewer, the VerticalRuler, and the Annotations.
My exact question is whether anyone has gotten this to work in a stand-alone code and, if so, how?
I have been developing a project which contains a TestLauncher class that'll read a given directory and for each file it contains, run it against my tool and yield the results.
So, when coding in Eclipse, it would show up one result for each test (as expected). Today I've been toying with Intellij, and I've decided to try to run and code a bit of this project in Intellij.
When trying to run the tests, though, it seems to be only showing up 2 results instead of the 100+ it should. Although I am sure it is running the full suite, it seems to be folding all the results of a given category in a single result. That means that if I have at least one failing test in each category, it shows up as a "failed test".
I guess this must not be a bug, but rather some configuration that I am not aware about and that is on by default in Intellij but not in Eclipse. Could anyone explain what might be going on?
Edit: I am using the latest Intellij (downloaded one of these days).
Thanks
What you're seeing is simply a difference in the way the Eclipse and IDEA plug-ins are implemented. I implemented the Eclipse plug-in to be pretty clever in its display, so it will show different things depending on various factors such as the presence of a toString() method in your test class or whether your test class implements org.testng.ITest.
I suggest you ask this question on the IDEA forums and if you don't get any response, feel free to email the testng-users list and I can put you in touch with the JetBrains engineer in charge of the TestNG plug-in.
The IntelliJ-IDEA TestNG Plugin has a filter symbol called "Hide Passed" above the output Test Results. You can toggle that to display all tests, including the passed ones.