[Eclipsedotnet-developers] (no subject)

[<jpp...@gm...>]

Kunle, I hope you don=92t mind me posting here the contents of one of =
your
entries in the project blog, but I think that these issues are =
important.

=20

=20

Kunle Odutola said...=20

Hi again Jo=E3o,

I guess I should really be using your mailing list on SourceForge for =
this
but, here goes...

Your latest binary release

I have downloaded and tried your latest release. I can report that it =
starts
up fine under .NET 2.0, the menus are functional and, the About box =
works
(complains about missing info if you request more info about some =
plug-ins).
It seems to run slowly though this might be due to debug-compiled =
assemblies
and/or Eclipse itself. Eclipse v2.1.3 wasn't exactly a snappy =
application.

One snag, it barfs if it is run from a directory that has spaces in the =
full
path.

There were also a number of entries like the ones at the very end of =
this
post in the file RuntineTraces.txt.

Replies to your points

1. I understand that it will diverge from Eclispe once it is up and =
running.

I'm familiar with NUnit. Once I get the latest sources, I'll have a look =
at
the testing framework. We should really co-ordinate this on SourceForge.

Would the Debugging Framework still apply on the .NET platform. Is it
sufficiently generic?

2. I've come to agree with you that Windows Forms (SWF) is the way to go =
for
.NET version. I hope we can still keep the JFace/SWT support though. =
They
offer a richer model that SWF.

5. Is the latest code usually in CVS?


Example of entries in RuntineTraces.txt


Activating plugin: Core.Runtime
Plugin activation stack:
Core.Runtime
Class loading stack:
Stack trace:
at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
at System.Environment.get_StackTrace()
at Core.Internal.Runtime.PluginStats.TraceActivate(String id, =
PluginStats
plugin)
at Core.Internal.Runtime.PluginStats.StartActivation(String pluginId)
at Core.Internal.Plugins.PluginDescriptor.DoPluginActivation()
at Core.Internal.Plugins.PluginDescriptor.get_Plugin()
at Core.Internal.Runtime.InternalPlatform.ActivateDefaultPlugins()
at Core.Internal.Runtime.InternalPlatform.LoaderStartup(Uri[] =
pluginPath,
String locationString, Properties bootOptions, String[] args, =
IExecutable
handler)
at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[]
arguments, SignatureStruct& sig, MethodAttributes methodAttributes,
RuntimeTypeHandle typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[]
arguments, Signature sig, MethodAttributes methodAttributes,
RuntimeTypeHandle typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, =
Boolean
skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at Core.Internal.Boot.InternalBootLoader.Startup(Uri pluginPathLocation,
String location, String[] args, IExecutable handler)
at Core.Internal.Boot.InternalBootLoader.Run(String applicationName, Uri
pluginPathLocation, String location, String[] args, IExecutable handler)
at Core.Boot.BootLoader.Run(String applicationName, Uri =
pluginPathLocation,
String location, String[] args, IExecutable handler)
at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[]
arguments, SignatureStruct& sig, MethodAttributes methodAttributes,
RuntimeTypeHandle typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[]
arguments, Signature sig, MethodAttributes methodAttributes,
RuntimeTypeHandle typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, =
Boolean
skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at Launcher.Launcher.BasicRun(String[] args)
at Launcher.Launcher.Run()
at Launcher.Launcher.RunEclipse(Launcher launcher)
at Launcher.Launcher.Main()


I would have investigated further and tried to fix the issues I found =
but, I
no longer have the latest code ;-). Is this in CVS?

Thanks

Kunle=20

Tuesday, November 22, 2005 7:55:36 PM=20

=20

=20

=20

As for the slowness in running the application, it could well be because =
of
what you mentioned: debug-enabled assemblies. I made the zip file based =
on
the latest working assemblies I had (which I always compile with =
debugging
enabled, to know exactly where the app failed, if it happens). I was =
also
aware of the =93directory with spaces in it=94 problem (I believe I =
mentioned
this in the notes of the first release, in September, although I=92m not
sure).

=20

Relatively to the entries in the RuntimeTraces.txt file, they are =
perfectly
normal. When a plugin is activated, one of the actions that takes place =
is
the printing the current stack trace to this file. This way, one can =
have a
good idea of where/why the plugin was activated. Eclipse itself does =
this
too, although I think it is not it=92s default behaviour.

You can witness this in:

=20

Activating plugin: Core.Runtime
Plugin activation stack:
Core.Runtime
Class loading stack:
Stack trace:
at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
at System.Environment.get_StackTrace()



The whole stack trace is obtained not from an exception, but from the
Environment (i.e., it is the stacktrace from the point where the program =
was
first started to the point where Environment.StackTrace is called).

=20

Now, other points of interest.

=20

1. What I originally had in mind was a somewhat-of-a-port of Eclipse=92s =
own
testing framework, which consists of an extension to the
=93Core.Runtime.Applications=94 extension point. That way, one could use
Eclipse.NET to test itself, with Nunit as a backing plugin to support =
the
execution of tests. However, this is open to discussion, as it could =
lead to
this project suffering from the =93too many eggs in the same basket=94 =
issue
that I believe IBM=92s Eclipse is marching into.

I have some code of this ported, in the src_platform_tests CVS module.
However, I won=92t take an ego beating if this code goes straight down =
the
toilet ;-) .

=20

2. Keeping SWT/Jface is always a possibility, although that would also =
mean
the added task of maintaining their plugins.

However, that is the =93beauty=94 of Eclipse, and the reason why I liked =
this
architecture very much: if we wish to change the =93windowing system=94, =
we just
need to put new plugins in the /Plugins dir. :-) No special config files =
or
anything of the sort necessary :-D .

=20

5. Yes, the latest code is usually in CVS. However, I always try to =
leave in
CVS the latest code that still works (so that anyone who downloads the =
code
and tries to build it won=92t receive a million errors). As an example, =
I=92m
currently reviewing the Core.Resources plugin (bug-hunting), and because
this is a quite large plugin, I haven=92t commited changes to this =
module yet
(as many of its classes are interconnected, and changing something in =
one of
them requires altering others.

But, yes, my personal policy is for the latest code to be in CVS, unless =
I
have a very good to commit it immediately.

=20

=20

I=92ll post later a schematic of the modules in the CVS repository (as =
some of
them are deprecated; it=92s these times that show us that CVS sucks and =
SVN
rules! :-\ ).

=20

=20

Best regards,

            JS