[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ptp-user] PTP synchronized projects - Environment Management * was: Ooops, remote make doesn't execute ?
|
On Tuesday, November 06, 2012 10:28:42 John Eblen <jeblen@xxxxxxx> wrote
> Hi
>
> I have also noticed missing modules. Environment management filters module
> names with "special" characters. This is
> done to filter extra output lines that are not module names, but it seems
> to be too strict in some cases. In my case,
> C++ modules are missing because the + character is special. I'll file a bug
> report for this.
Hi John,
good to see that this is a known issue - in principle. In my case, however, I
don't think it is related to special characters. See detailed analysis below.
>
> The relevant code is in file org.eclipse.ptp.ems.core.ModulesEnvManager in
> function "collectModuleNamesFrom"
> "MODULE_NAME_PATTERN" is the guilty regular expression. In the console view
> of your development environment,
> you should see an error message for each line that is filtered.
>
> John
I started debugging by setting several breakpoints in ModuleEventManager.java,
method "private Set<String> collectModuleNamesFrom(List<String> output)".
The variable "output" has the following value at method entry.
(java.util.ArrayList<E>) [/sw/aix61/modules-3.2.7b/Modules/versions:,
/sw/aix61/modules-3.2.7b/Modules/3.2.7/modulefiles:, /sw/aix61/Modules:,
FERRET/6.1, GAMS/23.7, GAMS/default, GCC/gcc-4.3.3, GCC/gcc-4.3.3-1,
GCC/gcc-4.4.0-1, GCC/gcc-4.4.2, GCC/gcc-4.5.1, GLOBUS/4.2.1, GLOBUS/default,
GNU/autoconf/2.69, GNU/autoconf-2.64, GNU/autoconf-2.68, GNU/automake/1.11.5,
GNU/automake/1.11.6, GNU/automake-1.11, GNU/automake-1.11.1,
GNU/libtool/2.4.2, GNU/libtool-2.4, IBM/hpct5.1.0.2, IBM/xlC10.1.0.0,
IBM/xlC10.1.0.10, IBM/xlC10.1.0.13, IBM/xlC10.1.0.3, IBM/xlC10.1.0.4,
IBM/xlC10.1.0.5, IBM/xlC10.1.0.6, IBM/xlC10.1.0.7, IBM/xlC11.1.0.10,
IBM/xlC11.1.0.11, IBM/xlC11.1.0.2, IBM/xlC11.1.0.3, IBM/xlC11.1.0.4,
IBM/xlC11.1.0.5, IBM/xlC11.1.0.7, IBM/xlC11.1.0.8, IBM/xlC12.1.0.0,
IBM/xlC12.1.0.1, IBM/xlc10.1.0.10, IBM/xlc10.1.0.13, IBM/xlc10.1.0.2,
IBM/xlc10.1.0.3, IBM/xlc10.1.0.4, IBM/xlc10.1.0.5, IBM/xlc10.1.0.6,
IBM/xlc10.1.0.7, IBM/xlc11.1.0.10, IBM/xlc11.1.0.11, IBM/xlc11.1.0.2,
IBM/xlc11.1.0.3, IBM/xlc11.1.0.4, IBM/xlc11.1.0.5, IBM/xlc11.1.0.6,
IBM/xlc11.1.0.7, IBM/xlc11.1.0.8, IBM/xlc12.1.0.0, IBM/xlc12.1.0.1,
IBM/xlf12.1.0.0, IBM/xlf12.1.0.11, IBM/xlf12.1.0.3, IBM/xlf12.1.0.4,
IBM/xlf12.1.0.5, IBM/xlf12.1.0.6, IBM/xlf12.1.0.7, IBM/xlf12.1.0.8,
IBM/xlf13.1.0.0, IBM/xlf13.1.0.10, IBM/xlf13.1.0.11, IBM/xlf13.1.0.2,
IBM/xlf13.1.0.3, IBM/xlf13.1.0.4, IBM/xlf13.1.0.5, IBM/xlf13.1.0.6,
IBM/xlf13.1.0.7, IBM/xlf13.1.0.8, IBM/xlf14.0.0.1_BETA, IBM/xlf14.1.0.0,
IBM/xlf14.1.0.1, IGES/grads2.0.a6, NAG/5.1.340, NCAR/ncarg5.1.0,
NCAR/ncarg5.1.1, NCAR/ncarg5.2.0, NCAR/ncarg6.0.0, NCL/6.0.0-beta, NCO/3.9.9,
NCO/4.0.8, NCVIEW/1.93g, NCVIEW/2.0beta4, NCVIEW/default, NETCDF/4.2,
NETCDF/4.2.1, NETCDF/4.2.1.1, PYTHON/2.6.4, PYTHON/2.6.4-buildbot-0.8.2,
PYTHON/2.7.1, SVN/1.6.16, SVN/1.7.5, TAU/2.18.3, TAU/2.19, TEX/default,
UNITE/1.0, afterburner/4.4.0, afterburner/4.5.1, afterburner/4.6.0,
afterburner/4.6.1, afterburner/4.6.2, afterburner/4.6.3, afterburner/default,
cdo/1.4.0.1, cdo/1.4.1, cdo/1.4.3, cdo/1.4.4, cdo/1.4.5, cdo/1.4.5.1,
cdo/1.4.6, cdo/1.4.7, cdo/1.5.0, cdo/1.5.1, cdo/1.5.2, cdo/1.5.3, cdo/1.5.4,
cdo/1.5.5, cdo/1.5.6, cdo/1.5.8, cdo/default, default,
/sw/aix61/unite/modulefiles/tools:, ddt/2.6.13711-aixpoe-ibm, ddt/3.0.17813-
aixpoe-ibm, ddt/3.1.20638-aixpoe-ibm(default), ddt/3.2.24924-aixpoe-ibm,
marmot/2.4.0-aixpoe-ibm, scalasca/1.3.3-aixpoe-ibm, scalasca/1.4.1-aixpoe-ibm,
scalasca/1.4.2-aixpoe-ibm(default), vampirserver/vampirserver-7.5.0(default),
vampirtrace/5.11-aixpoe-ibm, vampirtrace/5.12.2-aixpoe-ibm,
vampirtrace/5.13.1-aixpoe-ibm(default)]
At least the "IBM/xlc<some_version_number>" that I was missing previously, are
still in this list. Please note the list entries of the form
"IBM/xlC<same_version_number>". For xl Compilers, C and C++ share much of the
product development, so IBM/xlc and IBM/xlC pretty much always come in pairs,
and so do the modules generated from them.
The first entry after all "IBM/xlCxxx" entries is "IBM/xlc10.1.0.10". For this
entry I am seeing the following.
* "shouldIgnore(line)" == false
* MODULE_NAME_PATTERN.matcher(moduleName).matches() == true
* method "add" evaluates to "return m.put(e, PRESENT)==null;"
* In TreeMap.class, method "public V put(K key, V value)", the following loop
iterates until t == IBM/xlC10.1.0.10
do {
parent = t;
cmp = cpr.compare(key, t.key);
if (cmp < 0)
t = t.left;
else if (cmp > 0)
t = t.right;
else
return t.setValue(value);
} while (t != null);
If t == IBM/xlC10.1.0.10, we get cmp == 0, and the method exits with
"return t.setValue(value)".
This means that the put method (and hence the calling add method) consider
"IBM/xlc10.1.0.10" and "IBM/xlC10.1.0.10" as identical. This is wrong, because
one module means xlC ( == C++) and the other means xlc (== C).
Consequently, the module list in Eclipse PTP contains only those versions of
the xlc Compiler that doesn't have a matching module for the C++ compiler with
identical version number.
Hope that was clear enough to demonstrate the bug. Unfortunately, I can't
propose a cure. I just don't know enough of the code. If possible, one cure
would be to turn cpr.compare case sensitive.
--
Mit freundlichen Grüßen / Kind regards
Dr. Christoph Pospiech
High Performance & Parallel Computing
Phone: +49-351 86269826
Mobile: +49-171-765 5871
E-Mail: christoph.pospiech@xxxxxxxxxx
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland GmbH / Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Martina Koederitz (Vorsitzende), Reinhard Reschke, Dieter
Scholz, Gregor Pillen, Joachim Heel, Christian Noll
Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, HRB
14562 / WEEE-Reg.-Nr. DE 99369940
