Eclipse Community Forums Forum Search:

Home » Eclipse Projects » Test and Performance Tools Platform (TPTP) » Probes: invalid unicode
Probes: invalid unicode Mon, 13 March 2006 05:16
 Michael MoserMessages: 914Registered: July 2009 Senior Member
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 #57789 is a reply to message #57765] Mon, 13 March 2006 06:09
 Michael MoserMessages: 914Registered: July 2009 Senior Member
Well, I found a work-around (sort-of...)
I simply deleted that comment in the generated my_probe_probe.java file
and then I was able to instrument the class and the probes actually
fired (i.e. the System.out.println-s showed up on the console during
execution).

Very, very odd! What could cause the comment
------------------
....
/* probekit \some\path\here\src\myprobe.probe
*/

....
------------------
to be flagged as "Invalid Unicode"???

And what's that comment good for, if it obviously can be deleted without
adverse effect? Is it only to have a reference from which .probe file
this stems from?

Michael

"Michael Moser" <mmo@zurich.ibm.com> wrote in message
news:dv3gtq$euk$1@utils.eclipse.org...
>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 #57883 is a reply to message #57789] Mon, 13 March 2006 14:00
 Eclipse User
Originally posted by: Navid_Mehregani_nmehrega.ca.ibm.com

This is a multipart message in MIME format.
--=_alternative 0068409C85257130_=
Content-Type: text/plain; charset="US-ASCII"

It's strange that you're getting compilation errors on Java comments.
Multiple source folders in a project is supported for probekit. I tried
creating probes in a project with three source files and it works fine.
The path you pasted looks a bit strange. I have the following path for my
probes:

/* probekit \<project_name>\src\myprobe.probe
*/

I'm glad you were able to resolve it.

Navid Mehregani
--=_alternative 0068409C85257130_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">It's strange that you're getting compilation
errors on Java comments. &nbsp;Multiple source folders in a project is
supported for probekit. &nbsp;I tried creating probes in a project with
three source files and it works fine. &nbsp;The path you pasted looks a
bit strange. &nbsp;I have the following path for my probes:</font>
<br>
<br><font size=2 face="sans-serif">/* probekit &nbsp; \&lt;project_name&gt;\src\myprobe.probe</font>
<br><font size=2 face="sans-serif">*/</font>
<br>
<br><font size=2 face="sans-serif">I'm glad you were able to resolve it.</font>
<br>
<br><font size=2 face="sans-serif">Navid Mehregani</font>
--=_alternative 0068409C85257130_=--
Re: Probes: invalid unicode [message #57906 is a reply to message #57883] Tue, 14 March 2006 04:55
 Michael MoserMessages: 914Registered: July 2009 Senior Member
This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C64755.C418F500
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The strange path is due to the fact that our colleagues in development =
maintain their SW split into "modules" in their favorite versioning =
system and they also keep the actual code seperate from the =
corresponding unit test cases. The plugin we use to connect to that =
versioning system maps these modules to multiple source directories in =
the form

<project_name>\<module_name>\<code|ut>\src\...=20

in our eclipse projects. So we end up with projects that have multiple =
source files like

<project_name>\foo\code\src\...
<project_name>\foo\ut\src\...
<project_name>\bar\code\src\...
<project_name>\bar\ut\src\...
<project_name>\etc\code\src\...
<project_name>\etc\ut\src\...

> I'm glad you were able to resolve it.=20
Well, not really. I am able to tweak the generated file so that I can =
instrument a specific run and execute the thing once. But after the next =
rebuild that file is of course generated again (including the offending =
path) and then I have to manually tweak it again. So, it's not exactly a =
"solution"...

Michael
------=_NextPart_000_000A_01C64755.C418F500
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR>
<STYLE></STYLE>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>The strange path is due to the fact =
that our=20
colleagues in development maintain their SW&nbsp;split into "modules" in =
their=20
favorite versioning system and they also keep the actual code seperate =
from the=20
corresponding unit test cases. T</FONT><FONT face=3DArial size=3D2>he =
plugin we use=20
to connect to that versioning system </FONT><FONT face=3DArial =
size=3D2>maps these=20
modules to multiple source directories in the form</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;=20
&lt;project_name&gt;\&lt;module_name&gt;\&am p;lt;code|ut&gt;\src\... =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>in our eclipse projects. </FONT><FONT =
face=3DArial=20
size=3D2>So we end up with projects that have multiple source files=20
like</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV><FONT face=3DArial =
size=3D2>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;=20
&lt;project_name&gt;\foo\code\src\...
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;=20
&lt;project_name&gt;\foo\ut\src\...</FONT></DIV></FONT ></DIV>
<DIV></FONT><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;=20
&lt;project_name&gt;\bar\code\src\...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;=20
&lt;project_name&gt;\bar\ut\src\...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;=20
&lt;project_name&gt;\etc\code\src\...
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;=20
&lt;project_name&gt;\etc\ut\src\...</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></FONT></DIV></FONT><FONT face=3DArial =
size=3D2></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&gt; I'm glad you were able to resolve =
it.=20
<BR>Well, not really. I am able to tweak the generated file so that I =
can=20
instrument a specific run and execute the thing once. </FONT><FONT =
face=3DArial=20
size=3D2>But after the next rebuild that file is of course generated =
again=20
(including the offending path) and then I have to manually tweak it =
again. So,=20
it's not exactly a&nbsp;"solution"...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Michael</FONT></DIV><FONT =
face=3Dsans-serif=20
size=3D2></FONT></BODY></HTML>

------=_NextPart_000_000A_01C64755.C418F500--
Re: Probes: invalid unicode [message #58247 is a reply to message #57906] Tue, 14 March 2006 17:03
 Eclipse User
Originally posted by: Navid_Mehregani_nmehrega.ca.ibm.com

This is a multipart message in MIME format.
--=_alternative 0078ED0185257131_=
Content-Type: text/plain; charset="US-ASCII"

>The strange path is due to the fact that our colleagues in development
maintain their SW split into "modules" in their favorite versioning system
and they also keep the actual code seperate from the corresponding unit
>test cases. The plugin we use to connect to that versioning system maps
these modules to multiple source directories in the form

This explains it. Probekit requires the user to define their probes in a
source folder that is a direct child of the project. This is a limitation
of probekit that will hopefully be removed in the future. Note that your
probes don't have to be defined in the same project that you want to
instrument your classes in. So here's what I would suggest:

Create a new project -> create a source folder in you project -> create
your probe(s) in the source folder and try instrumenting your classes with
the probe again.

Navid Mehregani

--=_alternative 0078ED0185257131_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="Arial">&gt;The strange path is due to the fact that
our colleagues in development maintain their SW split into &quot;modules&quot;
in their favorite versioning system and they also keep the actual code
seperate from the corresponding unit &gt;test cases. The plugin we use
to connect to that versioning system maps these modules to multiple source
directories in the form</font>
<br>
<br>
<br><font size=2 face="sans-serif">This explains it. &nbsp;Probekit requires
the user to define their probes in a source folder that is a direct child
of the project. &nbsp;This is a limitation of probekit that will hopefully
be removed in the future. &nbsp;Note that your probes don't have to be
defined in the same project that you want to instrument your classes in.
&nbsp;So here's what I would suggest:</font>
<br>
<br><font size=2 face="sans-serif">Create a new project -&gt; create a
source folder in you project -&gt; create your probe(s) in the source folder
and try instrumenting your classes with the probe again.<br>
<br>
Navid Mehregani</font>
<br>
<br>
--=_alternative 0078ED0185257131_=--
Re: Probes: invalid unicode [message #58326 is a reply to message #58247] Wed, 15 March 2006 02:49
 Michael MoserMessages: 914Registered: July 2009 Senior Member
This is a multi-part message in MIME format.

------=_NextPart_000_000E_01C6480D.4EDBF310
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Not quite sure that I understood what you meant (the first item seemed =
to suggest to create a new project...), but what I did was to create in =
the existing project yet another src folder directly under the project =
(i.e. <project>/src) and then I moved the probe file into that folder =
and that seems to have done the trick: no more complaints re. unicode...

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.

Thanks,
Michael

<Navid_Mehregani_nmehrega@ca.ibm.com> wrote in message =
news:dv7eim$b0r$1@utils.eclipse.org...

....
Create a new project -> create a source folder in you project -> create =
your probe(s) in the source folder and try instrumenting your classes =
with the probe again.

Navid Mehregani=20

------=_NextPart_000_000E_01C6480D.4EDBF310
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR>
<STYLE></STYLE>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Not quite sure that I understood what =
you meant=20
(the first item seemed to suggest to create a new project...), but what =
I did=20
was to create in the existing project yet another src folder directly =
under the=20
project (i.e. &lt;project&gt;/src) and then I moved the probe file into =
that=20
folder and that seems to have done the trick: no more complaints re.=20
unicode...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Now - the next wish would of course be=20
that&nbsp;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=20
source.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Michael</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&lt;<A=20
href=3D"mailto:Navid_Mehregani_nmehrega@ca.ibm.com">Navid_Mehregani_nmehr=
ega@ca.ibm.com</A>&gt;=20
wrote in message <A=20
href=3D"news:dv7eim$b0r$1@utils.eclipse.org">news:dv7eim$b0r$1@utils.ecli=
pse.org</A>...</DIV><BR><FONT=20
face=3DArial size=3D2>...<BR></FONT><FONT face=3Dsans-serif =
size=3D2>Create a new=20
project -&gt; create a source folder in you project -&gt; create your =
probe(s)=20
in the source folder and try instrumenting your classes with the probe=20
again.<BR><BR>Navid Mehregani</FONT> <BR><BR></BODY></HTML>

------=_NextPart_000_000E_01C6480D.4EDBF310--
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">&gt; 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">&gt; 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. &nbsp;With dynamic probekit, everything is done on-the-fly.
&nbsp;The instrumentation is done in memory so none of the files on disk
need to be modified. &nbsp;You can simply apply your probes in profile
mode and let the framework do all the hard work. &nbsp;There is no clean-up
required at the end and you don't have to instrument your classes manually
every time. &nbsp;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_=--
 Previous Topic: AGR Tab Folder problems Next Topic: Dnzipping the SDK download asks for a password?!?
Goto Forum:

Current Time: Fri May 24 18:36:07 EDT 2013

Powered by FUDForum. Page generated in 0.05726 seconds