Probes: invalid unicode [message #57765] |
Mon, 13 March 2006 05:16  |
Eclipse User |
|
|
|
I am having trouble writing and applying probes.
I created a new probe (with an entry fragement that does a plain
System.out.println - just as described in the online help) and was
trying the next step, i.e. to instrument some class with it. This is
refused because there are errors in the fragment.
In the problem views the <foo>.probe file as well as the
<foo>_probe.java file are both marked with an error "Invalid Unicode".
It seems as if the path of the probe file (which contains a couple of
window's '\' characters) causes the problem. The path appears as part of
the header comment in the .java file:
--------------
....
/* probekit \some\path\here\src\myprobe.probe
*/
....
--------------
and the second path fragment (i.e. '\path' in the above example) has
wiggles underneath. No error indication whatsoever is given in the
..probe file itself (neither in the probe editor nor in the text editor).
To see whether that changes something also tried to use encoding UTF-16
or ISO-8859-1 but then I first get an alert "<encoding> conflicts with
the encoding defined in the content type (UTF-8)" and that problem
doesn't go away, either.
My project contains several source folders. Is this not supported?
Any ideas on how to fix this???
This is using:
eclipse 3.2.0M5a
tptp.runtime-TPTP-4.2.0-200602281515
emf-sdo-xsd-SDK-2.2.0M5
Michael
|
|
|
|
|
|
|
|
Re: Probes: invalid unicode [message #58516 is a reply to message #58326] |
Wed, 15 March 2006 10:47  |
Eclipse User |
|
|
|
Originally posted by: Navid_Mehregani_nmehrega.ca.ibm.com
This is a multipart message in MIME format.
--=_alternative 005679DF85257132_=
Content-Type: text/plain; charset="US-ASCII"
> I moved the probe file into that folder and that seems to have done the
trick: no more complaints re. unicode...
Yes, this'll have the same exact effect I suggested.
> Now - the next wish would of course be that one doesn't always have to
re-instrument (i.e. to reselect the corresponding classes) over and over
again after doing some changes in the app's source.
You should look forward to Dynamic Probekit in TPTP4.2. With dynamic
probekit, everything is done on-the-fly. The instrumentation is done in
memory so none of the files on disk need to be modified. You can simply
apply your probes in profile mode and let the framework do all the hard
work. There is no clean-up required at the end and you don't have to
instrument your classes manually every time. TPTP 4.2 is scheduled to be
released in June 2006, but you'll most likely be able to take advantage of
dynamic probekit by grabbing one of our stable 4.2 builds in mid to end of
April.
Navid Mehregani
--=_alternative 005679DF85257132_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="Arial">> I moved the probe file into that folder
and that seems to have done the trick: no more complaints re. unicode...</font>
<br>
<br><font size=2 face="Arial">Yes, this'll have the same exact effect I
suggested.</font>
<br>
<br><font size=2 face="Arial">> Now - the next wish would of course
be that one doesn't always have to re-instrument (i.e. to reselect the
corresponding classes) over and over again after doing some changes in
the app's source.</font>
<br>
<br><font size=2 face="Arial">You should look forward to Dynamic Probekit
in TPTP4.2. With dynamic probekit, everything is done on-the-fly.
The instrumentation is done in memory so none of the files on disk
need to be modified. You can simply apply your probes in profile
mode and let the framework do all the hard work. There is no clean-up
required at the end and you don't have to instrument your classes manually
every time. TPTP 4.2 is scheduled to be released in June 2006, but
you'll most likely be able to take advantage of dynamic probekit by grabbing
one of our stable 4.2 builds in mid to end of April.</font>
<br>
<br><font size=2 face="Arial">Navid Mehregani</font>
--=_alternative 005679DF85257132_=--
|
|
|
Powered by
FUDForum. Page generated in 0.03386 seconds