eclipsedotnet-developers — Discussions about Eclipse.NET development

[Eclipsedotnet-developers] V0.02 released

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

Hi.

Just to inform that I released v0.02 to SF.net, as this was long overdue
(there were some bugfixes since v0.01, and 0.01 was getting outdated). This
new release already includes the changes I made yesterday, and the
resolution of that little bug I mentioned yesterday too.

I named it v0.02 not because of anything breath-taking changes, but because
I had no better idea for it :P .


Regards,
JS


P.S.: My connection to download the zip is slow as molasses, so I haven't
tried the uploaded zip yet. However, when it finally gets here, I'll check
it out. If there are any problems, I'll put something here.

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.13.13/195 - Release Date: 08-12-2005
 

FW: [Eclipsedotnet-developers] AssemblyLoader mechanism improved

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

Damn. I replied only to you, Kunle, instead of to the list :( .
Sorry for the duplicate mail :( . I'll check the mailing list options to =
see
if I can change the ReplyTo address.

Regards,
JS

> -----Original Message-----
> From: Jo=E3o Saraiva [mailto:jpp...@gm...]=20
> Sent: quinta-feira, 8 de Dezembro de 2005 19:35
> To: 'Kunle Odutola'
> Subject: RE: [Eclipsedotnet-developers] AssemblyLoader=20
> mechanism improved
>=20
> The only one I have in mind for the platform itself is the=20
> loading of plugins into their own AppDomains (instead of into=20
> a default AppDomain, which is what's going on now). I had=20
> thought of this some time ago, and I believe you also=20
> mentioned it in one of your mails.
>=20
> There's nothing wrong with loading the assemblies/plugins=20
> into the default app domain, but in doing so we cannot=20
> explicitly unload the plugin: we have to lose all references=20
> to all types of all the assemblies of that plugin and _hope_=20
> that the garbage collector does its job.
>=20
> Nevertheless, the code I committed served only the purposes I=20
> mentioned: give some more relevance to DelegatingLoader and=20
> remove some hacks I had (especially in PluginLoader) to make=20
> the mechanism work well.
>=20
> Anyway, this is just a note for the future. I haven't really=20
> written any code for this AppDomain end. It's just a "would=20
> be nice to have" thingie ;) . When I started making a UML=20
> model of the mechanism yesterday (in paper), I noticed that=20
> maybe using the AssemblyLoader class to encapsulate an=20
> AppDomain may not be a very bad idea. But I still have to=20
> read a lot about this; my major concerns are assemblies=20
> references (i.e., dll dependencies), performance impact, and=20
> what types _must_ inherit from System.MarshalByRefObject.
>=20
> Of course, any comments/suggestions/criticisms are greatly=20
> appreciated, as this is still a concept brewing in my mind,=20
> and I would like to have every information possible about=20
> (dis)advantages of using multiple AppDomains. Hence the=20
> research I still have to do ;) .
>=20
>=20
> Regards,
> JS
>=20
> P.S.: I just remembered there is something I still have to do=20
> in the code. Plugins need not declare their dependance on=20
> Core.Runtime and Core.Boot (as they are implicit imports:=20
> they are always activated and loaded in memory when other=20
> plugins are loaded). The code, in its present state, succeeds=20
> in finding classes in the plugin and its imports _except_ for=20
> the import of Core.Runtime/Core.Boot . In other words, if the=20
> developer, in a plugin, tries to use the AssemblyLoader=20
> mechanism to search for a class in Core.Runtime/Core.Boot,=20
> this search will fail.
> The resolution to this should be very small and=20
> straightforward (in the code, besides all imports, add an=20
> import of Core.Runtime; Core.Runtime already has an import of=20
> Core.Boot). Tomorrow morning, I'll do the correction and test it.
>=20
>=20
> ------------------------------------
> Jo=E3o Paulo Pedro Mendes de Sousa Saraiva Estudante=20
> jps...@ne... jpp...@ho...=20
> jpp...@gm... Rua Mateus Vicente, 9, 10=B0 Dto
> 1500-445 Lisboa
> tel: 217267899
> mobile: 965403291
> IM: jpp...@ho...
> http://mega.ist.utl.pt/~jmss/
> ------------------------------------
> =20
>=20
> > -----Original Message-----
> > From: ecl...@li...
> > [mailto:ecl...@li...]
> > On Behalf Of Kunle Odutola
> > Sent: quinta-feira, 8 de Dezembro de 2005 19:25
> > To: ecl...@li...
> > Subject: RE: [Eclipsedotnet-developers] AssemblyLoader mechanism=20
> > improved
> >=20
> > Jo=E3o,
> >=20
> > > This was also to start paving the way to using AppDomains in the=20
> > > platform, although I still have a lot to read regarding
> > this subject,
> > > as it can have great effects on the platform.
> >=20
> > What other uses for AppDomains are you suggesting/planning here?.
> >=20
> > Kunle
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep=20
> through log=20
> > files for problems?  Stop!  Download the new AJAX search=20
> engine that=20
> > makes searching your log files as easy as surfing the  web.=20
>  DOWNLOAD=20
> > SPLUNK!
> > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick
> > _______________________________________________
> > Eclipsedotnet-developers mailing list
> > Ecl...@li...
> >=20
> https://lists.sourceforge.net/lists/listinfo/eclipsedotnet-developers
> >=20
> > --
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.1.362 / Virus Database: 267.13.12/192 - Release
> > Date: 05-12-2005
> > =20
> >=20
>=20
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.362 / Virus Database: 267.13.12/192 - Release=20
> Date: 05-12-2005
> =20
>=20

--=20
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.12/192 - Release Date: =
05-12-2005
=20

RE: [Eclipsedotnet-developers] AssemblyLoader mechanism improved

[Kunle O. <kun...@vi...>]

Jo=E3o,

> This was also to start paving the way to using AppDomains in=20
> the platform, although I still have a lot to read regarding=20
> this subject, as it can have great effects on the platform.

What other uses for AppDomains are you suggesting/planning here?.

Kunle

[Eclipsedotnet-developers] AssemblyLoader mechanism improved

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

Hi. Just to tell you that I just committed some changes I made to the
AssemblyLoader mechanism.

The changes I made are basically the following:

- the log files are written to a directory called Logs. Each execution of
the platform generates 2 new log files (for the Console.Out and
Console.Error streams), and the name of the files are "log_<day>_<time>_[Out
| Error].txt".

- I somewhat improved the AssemblyLoader mechanism:

	- Java.Lang.Loader is now called Java.Lang.LoaderRegistry (I think
this name is much more straightforward than the previous one)

	- DelegatingLoader now serves a purpose similar to Eclipse's
DelegatingURLClassLoader: to handle the plugin's requirements (i.e., plugin
imports). So, in a nutshell, DelegatingLoader handles plugin's requirements
(imported plugins, through the <requires> and <import> tags in the plugin
manifest), and PluginLoader handles plugin's runtime loading (assemblies
that should be loaded, through the <runtime> and <library> tags).

	- I removed some hacks I had previously introduced to make the
previous version work. Hopefully, this new version is (much) cleaner and
easier to understand.



This was also to start paving the way to using AppDomains in the platform,
although I still have a lot to read regarding this subject, as it can have
great effects on the platform.

Well, I'm tired and hungry. Going home :) .

Regards,
JS


P.S.: I will update the AssemblyLoader documentation in the pdf file when I
have the chance. Until so, feel free to email me with any questions.

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.13.12/194 - Release Date: 07-12-2005
 

[Eclipsedotnet-developers] New CVS repository commits mailing list

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

Hi!

This is just to inform that I=92ve created a new mailing list, which =
will
automatically receive a new mail when there is a commit to the CVS
repository. This is to help developers know when they should make a cvs
update on their local files, instead of just making cvs updates every 30
minutes or so :P .

You should join only if it will help you to know when there are new =
commits.
Otherwise, there's no need to join (as this ML will probably have a LOT =
of
mails...)

Regards,
JS

P.S.: The mailing list is
ecl...@li... .

RE: [Eclipsedotnet-developers] .NET 1.1 vs .NET 2.0 again

[Kunle O. <kun...@vi...>]

Hi Rui,

> There are some factors that may influence our decision, I=20
> will talk about=20
> these:
> - Productivity

+1

I can't argue with that. Switching to .NET 2.0 does offer some nice
productivity benefits not least is the fact that MS's IDE now offer
refactoring out-of-the-box and, VS.NET project files are now MSBuild =
files
that can [probably] be used as is with CI systems like Draco.NET and
CruiseControl.NET.

> - Marketing

+1

Hey look guys, we are using the coolest and the newest!. Join us and you =
can
too!  ;-)

Seriously though, there's a good vibe around Whidbey - C# 2.0, VS 2005 =
and
.NET 2.0. I'm back to believeing that it would be a shame not to tap =
into
it.


Kunle

RE: [Eclipsedotnet-developers] .NET 1.1 vs .NET 2.0 again

[Kunle O. <kun...@vi...>]

> Hi!

Hi David,

> I think that the best for the project Eclipse .NET is to=20
> integrate and=20
> explore .NET 2.0 framework?s functionalities as soon as=20
> possible. It is=20
> not a question of following the high tech hype.

You are right of course.

I see improvements to the AppDomain bits (particularly cross-domain =
calling
performance) as important given our framework of loadable/unloadable =
plug-in
architecture.

> As my other colleagues referred, it?s a matter of recognizing the=20
> benefits that this framework brings to the developer in terms=20
> of C# 2.0=20
> and the productivity gains by using VS2005. Despite that I?m=20
> not using=20
> currently these in my prototype, I?m planning to integrate them soon.
>=20
> Besides that, if the hole community (Microsoft and Mono Project) is=20
> making the change I thing that resisting to .NET 2.0 is contributing=20
> for Eclipse .NET to become outdated.

Yep.

> Jo=E3o has already made some changes not because the hype but=20
> especially=20
> for his own profit in terms of developing facilities. He also had the=20
> determination to reason carefully about what you said and=20
> presented us=20
> with a detailed logical explanation that convinced me more about the=20
> need of this change.

Welcome to the dark side  ;-)

I'm drifting back to my original position that .NET 2.0 is cooler than =
warm
tequila.

> For me integrating .NET 2.0 is for the best. Besides no one likes to=20
> ?pass from horse to donkey? this is a bad translation from a=20
> Portuguese=20
> saying, but I think you?ll understand ?

Yeah, I can imagine. Proverbs are short sentences drawn from long =
experience
so, I concur. Let's ride the horse and lose the donkey.

Kunle

Re: [Eclipsedotnet-developers] .NET 1.1 vs .NET 2.0 again

[<da...@me...>]

Hi!

I think that the best for the project Eclipse .NET is to integrate and 
explore .NET 2.0 framework?s functionalities as soon as possible. It is 
not a question of following the high tech hype.

As my other colleagues referred, it?s a matter of recognizing the 
benefits that this framework brings to the developer in terms of C# 2.0 
and the productivity gains by using VS2005. Despite that I?m not using 
currently these in my prototype, I?m planning to integrate them soon.

Besides that, if the hole community (Microsoft and Mono Project) is 
making the change I thing that resisting to .NET 2.0 is contributing 
for Eclipse .NET to become outdated.

Jo=E3o has already made some changes not because the hype but especially 
for his own profit in terms of developing facilities. He also had the 
determination to reason carefully about what you said and presented us 
with a detailed logical explanation that convinced me more about the 
need of this change.

For me integrating .NET 2.0 is for the best. Besides no one likes to 
?pass from horse to donkey? this is a bad translation from a Portuguese 
saying, but I think you?ll understand ?

Best regards,
David Ferreira

RE: [Eclipsedotnet-developers] Removing SWT dependency on IKVM

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

> Please don't post HTML mail to the list.

Sorry. I had Outlook configured to send html messages by default and I'm so
used to it that I don't even notice when I'm using HTML. Me bad :( .

> AFAIK (and I'm not a Jface/SWT expert), the SWT API and Jface 
> are fully managed. Apps using Jface/SWT never interact 
> directly with the native code layer. 
> 
> The real difference IMO is one of ubiquity/distribution. One 
> is more likely to find WinForms/GDI+ and GTK#/GTK on a system 
> than Jface/SWT so, one must be prepared to distribute all of 
> SWT (managed and native) with one's apps.

And I never said otherwise. What I meant to say with all this is that, even
in distribution the developer does not need to create a distribution zip
file for each different target OS, i.e., 1 zip file for Windows, 1 zip file
for Linux, 1 zip file for MacOSX, etc. Instead, one only has to state in the
system requirements: "Needs the .NET Framework or the Mono Framework
installed.". Distributing SWT is like distributing WinForms :-P . But you're
right, the question at the core of this all is ubiquity and distribution, as
you mentioned.
Still, you have to admit that creating multiple distributions, one for each
OS, does *kind-of* defeat the cross-platform purpose of Java...
But I suppose that's a necessary evil, and we have to deal with it.

> Well, SWT's API and Jface are fully managed code. It should 
> be possible to build a fully managed SWT/Jface on top of SWF 
> (i.e. WindowsForms) or another API.
> 
> I am not suggesting that we should do this btw, just pointing 
> out that it is possible. We might even build it on top of 
> System.Drawing just like Mono's fully managed SWF implementation.

SWF and SWT are somewhat similar in the way that they both use the
Single-Thread Appartment model. However, the differences between them can
turn out to complicate the implementation of SWT on top of SWF. One of those
differences is in the fact that SWF only exposes a small part of the Win32
API (as an example, you have the Tree control, but in SWF you can't use the
tri-state options that are available through the Win32 API - and which SWT
uses).
Maybe it would be best in the long run to use System.Drawing. Maybe some of
the SWT widgets should be emulated and others should use the SWF controls.
I'll take a look at these things and get back to you later (I'm not an
expert in this either :P ).

> SWF is a *must* I think. It may not be the best but we don't 
> have the option of not supporting it. Even the Mono guys came 
> to realise that.
> 
> SWT is a little different. If synergy with Eclipse (including 
> ease of porting plugins between Eclipse and Eclipse.NET or 
> maintaining a pluging on
> both) is important, so is SWT support. It's a little richer 
> than SWF, is CPE for more platforms than SWF today and, is 
> still being very actively developed.
> 
> Priority-wise, SWF I think. SWT already works. Sort of...  ;-)

Personally, I think that the *really* important thing is not to cut
developers' wings. Therefore, we should keep their options as open as
possible/convenient and only prune their choices when we have a very good
reason.


OK. Taking this into account, I think it's safe for me to create a
subproject called SWF_UI in the src_platform module (like SWT_UI) and move
some of UI's content into it. That way, we can have the two projects running
simultaneously, so that one does not hamper the other.


Regards,
JS

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.10/189 - Release Date: 30-11-2005
 

RE: [Eclipsedotnet-developers] Removing SWT dependency on IKVM

[Kunle O. <kun...@vi...>]

Please don't post HTML mail to the list.

> I would like to have people's opinion on this: do you=20
> think that we should maintain the SWT branch (once=20
> WinForms/some other better windowing toolkit is up=20
> and running)?

Short answer? - "Yes".=20

Long answer? - "Maybe, it depends on whether we care about synergy with
Eclipse and on the resources available to us".

> And now, for my opinion:
=20
> I believe SWT is not cross-platform, no matter how=20
> much the IBM/Eclipse guys try to tell us it is=20
> cross-platform.

Well, if portability amongst the supported OSes is good enough for you =
then,
it is definitely CPE!

Where: CPE =3D=3D Cross-platform enough  ;-)

> I think the real question here is: "Where do we=20
> draw the line? When should we consider something=20
> to be cross-platform or not?"

When it runs on most/all of the platforms we care about. For many =
millions,
WindowsForms (even if it was Windows-only) is CPE!

> The major difference I see between SWT and WinForms / GTK#
> is that WinForms / GTK# are "frameworks" that effectively=20
> hide the underlying native layer from the developer, from=20
> code implementation time all the way to a "late" stage=20
> such as deployment time.

Isn't that true of Jface/SWT as well?.=20

AFAIK (and I'm not a Jface/SWT expert), the SWT API and Jface are fully
managed. Apps using Jface/SWT never interact directly with the native =
code
layer.=20

The real difference IMO is one of ubiquity/distribution. One is more =
likely
to find WinForms/GDI+ and GTK#/GTK on a system than Jface/SWT so, one =
must
be prepared to distribute all of SWT (managed and native) with one's =
apps.
=20
> But then the guys at Mono/Novell came to their senses=20
> and realized that their .NET implementation would be=20
> much more useful if they included something that many=20
> .NET developers use: WinForms.

And so must we. We have to support SWF. Period.

> And, worse yet, the compilation of SWT java source code=20
> is also target-platform dependent (as you can see in=20
> src_platform/java_src/org.eclipse.swt_2.1.3, there are=20
> multiple classpath files, one for each of the target OSs).
> In fact, I think it is safe to say that the only thing=20
> actually platform-independent in SWT is the API.

I think this is to be expected. The native code portion is different on =
the
platforms and so must the interface between the Java part and the native
code (if performance overrules an adapter pattern link).

> I think this clearly defeats the purpose of=20
> platform-independence that Java was based on and, to be=20
> honest, this is the point where I most disagree with the=20
> choices for Eclipse development.

You may be right but, Java also has JNI for a reason.

> Now, returning to the beginning question: do you think=20
> we should maintain the SWT windowing toolkit? If so,=20
> then a complete port to C# would be the best move, I=20
> completely agree on this. However, if not, maybe the=20
> development time would be better spent on starting a=20
> SWF-oriented re-implementation of the UI plugins (Jface,
> UI.WorkBench, etc.).=20

Well, SWT's API and Jface are fully managed code. It should be possible =
to
build a fully managed SWT/Jface on top of SWF (i.e. WindowsForms) or =
another
API.

I am not suggesting that we should do this btw, just pointing out that =
it is
possible. We might even build it on top of System.Drawing just like =
Mono's
fully managed SWF implementation.

Personally, I think leveraging the Eclipse guys work on SWT is easier. =
Our
C# port can continue to use an evolution of their native code layers. =
SWT
support on other OSes can be added when someone needs to scratch an =
itch.
All we need do is just keep the SWT code we have.
=20
> Also, does everyone agree that SWF is the best way to go?
> Or would you rather take the GTK# path?

SWF is a *must* I think. It may not be the best but we don't have the =
option
of not supporting it. Even the Mono guys came to realise that.

SWT is a little different. If synergy with Eclipse (including ease of
porting plugins between Eclipse and Eclipse.NET or maintaining a pluging =
on
both) is important, so is SWT support. It's a little richer than SWF, is =
CPE
for more platforms than SWF today and, is still being very actively
developed.

Priority-wise, SWF I think. SWT already works. Sort of...  ;-)

Kunle

[Eclipsedotnet-developers] Removing SWT dependency on IKVM

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

This one is in regard to a feature request posted by Kunle at the SF.net
tracker. This feature request also touches a very delicate subject and =
(what
I think is) the Achilles=92 Heel of IBM=92s Eclipse (and, to a degree,
Eclipse.NET).

=20

For anyone who hasn=92t seen it, it reads:

=20

=20

=20

Remove SWT dependency on ikvm

=20

=20

In the current codebase, SWT support is enabled by the use of the =
excellent
ikvm toolkit. This means SWT has been ported at all, just statically
compiled/run via ikvm.

This is a tactical decision that has speeded the delivery of the =
platform.
Nevertheless, it is less than optimal and a complete port of SWT to C# =
would
be the strategic goal.

I should note here that the SharpDevelop team attempted a port a few =
years
ago - called #WT - and their work may be of some use in this task.=20

**PLEASE READ THE #WT LICENSE CAREFULLY, ECLIPSEDOTNET HAS A LIBERAL =
LICENSE
AND THE #WT LICENSE MAY BE TOO RESTRICTIVE.**

=20

=20

=20

=20

I would like to have people=92s opinion on this: do you think that we =
should
maintain the SWT branch (once WinForms/some other better windowing =
toolkit
is up and running)?

=20

=20

And now, for my opinion:

=20

*************** BEGIN PERSONAL OPINION =96 PLEASE INSULT AT WILL (but =
behind
my back, please :-P ) *********************

=20

I believe SWT is not cross-platform, no matter how much the IBM/Eclipse =
guys
try to tell us it is cross-platform. I discussed this somewhat in
http://eclipsedotnet.blogspot.com/2005/09/whats-been-going-on.html . The
thing is, SWT uses native code and forces the code developer to ship =
his/her
product with swt.jar AND the dll for the OS in which it should operate.

=20

And WinForms (and by WinForms I mean SWF)? It=92s not cross-platform =
either.
Neither is GTK#. WinForms is an abstraction layer for GDI (only =
available in
Windows; and Wine, I think, but I=92m not sure). GTK# is just .NET =
bindings
for the GTK binaries.

=20

=20

I think the real question here is: =93Where do we draw the line? When =
should
we consider something to be cross-platform or not?=94

=20

=20

The major difference I see between SWT and WinForms / GTK# is that =
WinForms
/ GTK# are =93frameworks=94 that effectively hide the underlying native =
layer
from the developer, from code implementation time all the way to a =
=93late=94
stage such as deployment time.

=20

When one uses GTK#, the only thing concern regarding the UI system is
whether GTK# is installed in the target system or not. If the target =
system
is MacOSX, Linux, Windows or anything else shouldn=92t be a concern when
deploying the product; that=92s one of the ways I see the =93managed =
code=94
novelty (btw, I don=92t know if GTK# runs in MacOSX, but the point is =
still
here). In fact, that=92s the reason I adapted the native code of the
org.eclipse.core.resources plugin to managed code in the Core.Resources
plugin: so that the .NET framework handles the native part of the work.

=20

When using WinForms some time ago, one had also to worry about whether =
the
underlying OS was Windows. That=92s why I was very uneasy at the time I
started this project about making the UI in WinForms; I was getting =
tempted
by GTK#. But then the guys at Mono/Novell came to their senses and =
realized
that their .NET implementation would be much more useful if they =
included
something that many .NET developers use: WinForms. And so the worry of
whether Windows was the underlying OS or not was lifted, as Mono made =
SWF
available for the platforms in which it runs (Linux, Windows, MacOSX =96 =
I
don=92t know if the MacOSX implementation of SWF is complete or not, =
though).

=20

For the developer, this means that he only needs to worry whether the =
target
framework is installed (in the case of WinForms, Mono or Microsoft=92s =
.NET
Framework; in GTK#=92s case, Mono / .NET and GTK#) on the target =
computer; he
doesn=92t need to worry about the native components of the target =
computer at
all. Clearly not the case when distributing an SWT-based application =
(where
we must also include OS-dependent dlls).

In fact, the reason there are so many IBM/Eclipse download choices (one =
for
each OS) is exactly that: different zip files include different native
library dlls.

=20

And, worse yet, the compilation of SWT java source code is also
target-platform dependent (as you can see in
src_platform/java_src/org.eclipse.swt_2.1.3, there are multiple =
classpath
files, one for each of the target OSs). In fact, I think it is safe to =
say
that the only thing actually platform-independent in SWT is the API... I
think this clearly defeats the purpose of platform-independence that =
Java
was based on and, to be honest, this is the point where I most disagree =
with
the choices for Eclipse development.

=20

*************** END PERSONAL OPINION =96 NO MORE INSULTS NOW, PLEASE :-P
*********************

=20

=20

Now, returning to the beginning question: do you think we should =
maintain
the SWT windowing toolkit? If so, then a complete port to C# would be =
the
best move, I completely agree on this. However, if not, maybe the
development time would be better spent on starting a SWF-oriented
re-implementation of the UI plugins (Jface, UI.WorkBench, etc.).

=20

Also, does everyone agree that SWF is the best way to go? Or would you
rather take the GTK# path?

=20

Opinions are welcome, these things need to be discussed.

=20

=20

=20

OK, sorry for the lengthy mail, but I think this is a subject that =
should be
well discussed before any decisions are actually made and implemented.

=20

=20

Regards,

JS

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

Re: [Eclipsedotnet-developers] .NET 1.1 vs .NET 2.0 again

[Rui S. <rmt...@gm...>]

There are some factors that may influence our decision, I will talk about 
these:
- Productivity
- Marketing

In the productivity field, we are worried if the adoption of the .NET 2.0 is 
what we need to increase the development of the tool. The major advance I 
see here, is that VS2005 is a big improvement over VS2003, and it can really 
increase our productivity. As a drawback of switching to VS2005, we cannot 
use .NET1.1 .
Today, the major improvements in the development cycle arrive from the use 
of a good IDE, and not from a small set of features introduced in a new 
version of a language. Another force that we have to deal are the libraries, 
in this domain I haven't the knowledge to express an opinion.

Another thing we have to take into account is Marketing, we should think 
about what platform our users are using and if they are able to switch to 
the new platform? About this, I have to say that almost everyone will make 
that switch, because microsoft and mono are motivating the users to do that.

Rui 

RE: [Eclipsedotnet-developers] .NET 1.1 vs .NET 2.0 again

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

 

> Not really. We just have to decide and bite the bullet. We don't *need*

> .NET

> 2.0 (or C# 2.0) to build the platform but, we might prefer to target it

> anyway if it boosts our productivity for instance.

 

Agreed.

Frankly, I tend towards picking .NET 2.0, not because of the IDE or because
of Generics (the parts of the platform that use generics can be easily
adapted to use normal collections, it's just a matter of 1 or 2 days' work,
as I previously mentioned), but because the .NET 2.0 framework can load .NET
1.1 assemblies. So, if one has plugin dlls made in 1.1, those can be used
without problems. The opposite (.NET 1.1 using 2.0 assemblies) is not true,
and forces the developer to use 1.1 (most shouldn't find that a problem, but
there may be cases that do).

However (and this just came to my mind right now), this "advantage" can turn
out to be a disadvantage: if the platform assemblies are made in 2.0,
developers that (re)compile their assemblies must use the 2.0 compiler (not
the 1.1). The reason is that the compiler will need to access referenced
assemblies in compile time, and so it must be able to load those referenced
assemblies (in 2.0).

 

 

And, on a personal opinion, I do think that .NET 2.0 (especially generics)
can greatly improve developer productivity. Just yesterday, I corrected some
bugs (in the SWT_UI solution) that would never have gotten there in the
first place if I had generics when I first made the code :( . BTW, the
preferences dialog should now show all pages without throwing the infamous
"There was an error alerting a preference listener." :D .

 

 

But VS2003/2005 can still be a big pain in the butt. That's why I have in my
next TODO tasks to take a deep breath and look at Nant, to add the scripts
to build the assemblies (therefore bypassing VisualStudio and removing the
need for it).

 

 

JS

 

RE: [Eclipsedotnet-developers] .NET 1.1 vs .NET 2.0 again

[Kunle O. <kun...@vi...>]

> OK, nothing more is coming to mind right now. Please complete=20
> this list as much as possible.

Seems complete.

> Meanwhile, I'm taking a look at the SharpDevelop IDE too, as=20
> a possible replacement for Visual Studio. Maybe the answer=20
> could be lying in the change of the IDE, instead of changing=20
> the .NET framework.

Not really. We just have to decide and bite the bullet. We don't *need* =
.NET
2.0 (or C# 2.0) to build the platform but, we might prefer to target it
anyway if it boosts our productivity for instance.

Kunle

[Eclipsedotnet-developers] Spaces in the launch path bug corrected?

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

I=92ve committed some files to fix the =93spaces in the launch path =
throws an
error=94 bug. It appears to be working ok over here, but could someone =
also
test this, to make sure it=92s nothing (my) machine-dependant?

=20

The binaries are on a site near you:
http://ottawa.inesc-id.pt/eclipsedotnet_files (get the =
bin_28-11-2005.zip
file). I=92ve included some of the .pdb files to help in further =
debugging, if
necessary (but you can delete them if you wish).

=20

As always, the latest source is in CVS.

=20

Regards,

JS

[Eclipsedotnet-developers] AssemblyLoader doc in CVS

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

Just informing that I have put a document (in pdf) describing the =
Assembly
Loader mechanism in the CVS repository. It is in the same location as =
the
previous article (docs_platform module, other_docs folder).
=20
Regards,
JS
=20



Jo=E3o Paulo Pedro Mendes de Sousa Saraiva
Estudante 	Rua Mateus Vicente, 9, 10=B0 Dto
1500-445 Lisboa =09
HYPERLINK "mailto:jps...@ne..." \njp...@ne...
HYPERLINK "mailto:jpp...@ho..." \njp...@ho...
HYPERLINK "mailto:jpp...@gm..." \njp...@gm...
IM: jpp...@ho...
HYPERLINK "http://mega.ist.utl.pt/~jmss/" =
\nhttp://mega.ist.utl.pt/~jmss/

tel:=20
mobile: 	217267899
965403291 =09
 =09

	 =09
=09

HYPERLINK "http://www.plaxo.com/signature" \nSignature powered by Plaxo
HYPERLINK "http://www.plaxo.com/signature" \nWant a signature like this?

HYPERLINK
"https://www.plaxo.com/add_me?u=3D4295041056&v0=3D144967&k0=3D1899216598"=
 \nAdd me
to your address book...=09
=20

--=20
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.8/183 - Release Date: =
25-11-2005
=20

[Eclipsedotnet-developers] .NET 1.1 vs .NET 2.0 again

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

I've been giving some more thought into this matter, as it is quite
important for the development of the project. I think the best way to go at
this is by gathering all the pros and cons of using .NET 2.0 we can think
of, and then make an educated choice.


Here are the cons I have on my mind:

- The user NEEDS to have .NET 2.0 installed on his machine (although .NET
1.1 and .NET 2.0 work fine on the same machine).
- MS Visual Studio 2005 is a CPU/RAM/DISK hog, and VS2003 is much lighter.
(1)
- The platform isn't actually using any .NET 2.0 features as of yet (except
for Generics, and that is easily taken out).

And the pros:

- .NET 2.0 can load and execute .NET 1.1 assemblies. (2)
- .NET 2.0 has some useful features for the developer, such as Generics.


(1) I agree with this. However, VS2003 does have a very annoying (in my
opinion) behaviour: it locks the assemblies that projects reference. For
example, if you have a solution with 2 projects, A and B, and project B
references the DLL output of project A (I mean the actual output file, not
just the project). You can only build the solution once. If you compile A,
then B, and then try to compile A again (for some reason, like changing
code), the compiler will complain that it cannot copy the output file to the
destination directory. This was a VERY BIG pain in the a** during pre-VS2005
development of the Eclipse.NET platform, as I'm sure you can guess... VS2005
does not have this behaviour, and you wouldn't believe how relieved I was
when I noticed this while trying it out (David and Rui saw it, however ;) ).


(2) I mentioned this point because the contrary is not true, i.e., .NET 1.1
can not load .NET 2.0 assemblies. This means that, with .NET 2.0, people
that develop plugins for the platform can develop and compile plugins in
both .NET 1.1 and/or .NET 2.0 (although .NET 1.1 plugins would probably be
considered "legacy plugins"). With .NET 1.1, developers can only use .NET
1.1 (no 2.0). The question that is hammering my mind, regarding this point,
is: "Are the features in .NET 2.0 enough reason for us to support it (right
away)?". I'd like to have as many opinions on this as possible, as just one
(my) opinion is certainly too biased to be considered as "correct".


OK, nothing more is coming to mind right now. Please complete this list as
much as possible.

Meanwhile, I'm taking a look at the SharpDevelop IDE too, as a possible
replacement for Visual Studio. Maybe the answer could be lying in the change
of the IDE, instead of changing the .NET framework.


Opinions (preferably, ones that are different than mine) are most welcome.


Regards,
JS

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.8/183 - Release Date: 25-11-2005
 

[Eclipsedotnet-developers] Some more files committed

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

Hi. This is just to inform that I have committed the files for
Core.Resources. I caught some (minor) bugs there, but it was mostly
refactoring work and some optimization. I have also taken the =
opportunity to
correct some bugs related to the preferences screen (to the Fonts =
section,
actually). That section should now present itself correctly. There are =
still
some problems in applying the fonts (by clicking the Apply button), but =
I
think that's related to SWT's parsing of some strings; I'll look at it =
when
I have the time.
=20
So, the changes made were in the src_platform/Core solution and the
src_platform/SWT_UI solution. Update these to be up to date.
=20
=20
Regards,
JS
=20
=20



Jo=E3o Paulo Pedro Mendes de Sousa Saraiva
Estudante 	Rua Mateus Vicente, 9, 10=B0 Dto
1500-445 Lisboa =09
HYPERLINK "mailto:jps...@ne..." \njp...@ne...
HYPERLINK "mailto:jpp...@ho..." \njp...@ho...
HYPERLINK "mailto:jpp...@gm..." \njp...@gm...
IM: jpp...@ho...
HYPERLINK "http://mega.ist.utl.pt/~jmss/" =
\nhttp://mega.ist.utl.pt/~jmss/

tel:=20
mobile: 	217267899
965403291 =09
 =09

	 =09
=09

HYPERLINK "http://www.plaxo.com/signature" \nSignature powered by Plaxo
HYPERLINK "http://www.plaxo.com/signature" \nWant a signature like this?

HYPERLINK
"https://www.plaxo.com/add_me?u=3D4295041056&v0=3D144967&k0=3D1899216598"=
 \nAdd me
to your address book...=09
=20

--=20
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.8/183 - Release Date: =
25-11-2005
=20

RE: [Eclipsedotnet-developers] .NET 1.1 vs .NET 2.0 again

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

Damn.

I just noticed a huge typo in my previous mail. When I said "Putting the
platform back to 1.1 should be too difficult.", what I meant to say was
"Putting the platform back to 1.1 shouldn't be too difficult.".

Amazing how 3 teeny weeny characters can screw the meaning of a sentence
altogether... :\

Sorry for any misinterpretations.

JS


-----Original Message-----
From: Jo=E3o Saraiva [HYPERLINK
"mailto:jpp...@gm..."mailto:jpp...@gm...]
Sent: s=E1bado, 26 de Novembro de 2005 15:31
To: 'ecl...@li...'
Subject: RE: [Eclipsedotnet-developers] .NET 1.1 vs .NET 2.0 again

That's a good point. Eclipse.NET really isn't using anything special in =
.NET
2.0 as of yet (except for Generics ).

The reason I recently migrated the platform to 2.0 was because this =
would
have to be done eventually, although I admit that I might have been =
hasty in
this matter. Another reason was the redefinition of the Eclipse.NET GUI =
to
be based on SWF rather than SWT, and SWF 2.0 offers some enhancements =
over
the previous version (from what I've read: new controls, previous =
controls
expose some more properties from the underlying Win32 controls. Also, =
one
very cool feature is LayoutManagers; it appears Microsoft has finally =
come
to its senses and looked at Swing, instead of just looking at Java's =
class
library). But, since this new GUI will take some time to be developed, =
there
is no really good reason for the platform to adopt .NET 2.0 right now.

Putting the platform back to 1.1 should be too difficult. The only thing
from 2.0 I'm using is Generics, and that's nothing a thorough search for
"using System.Collections.Generics;" and some patience can't take care =
of.
However, in defense of 2.0 and from what I've been seeing/reading, using
generic collections is faster (not to mention less error-prone) than =
using
"normal" collections (and, considering the implications of =
boxing/unboxing
when using these "normal" collections, I don't find that hard to =
believe),
although I'm a bit skeptic regarding the values that Microsoft provides =
(2x
faster for collections using reference types, and 3x for value types).

All that said, I am not sure about what position to take regarding this
subject. David and Rui, what are your thoughts on this?

JS=20


--=20
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.8/183 - Release Date: =
25-11-2005
=20

RE: [Eclipsedotnet-developers] .NET 1.1 vs .NET 2.0 again

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

That's a good point. Eclipse.NET really isn't using anything special in =
.NET
2.0 as of yet (except for Generics ).

The reason I recently migrated the platform to 2.0 was because this =
would
have to be done eventually, although I admit that I might have been =
hasty in
this matter. Another reason was the redefinition of the Eclipse.NET GUI =
to
be based on SWF rather than SWT, and SWF 2.0 offers some enhancements =
over
the previous version (from what I've read: new controls, previous =
controls
expose some more properties from the underlying Win32 controls. Also, =
one
very cool feature is LayoutManagers; it appears Microsoft has finally =
come
to its senses and looked at Swing, instead of just looking at Java's =
class
library). But, since this new GUI will take some time to be developed, =
there
is no really good reason for the platform to adopt .NET 2.0 right now.

Putting the platform back to 1.1 should be too difficult. The only thing
from 2.0 I'm using is Generics, and that's nothing a thorough search for
"using System.Collections.Generics;" and some patience can't take care =
of.
However, in defense of 2.0 and from what I've been seeing/reading, using
generic collections is faster (not to mention less error-prone) than =
using
"normal" collections (and, considering the implications of =
boxing/unboxing
when using these "normal" collections, I don't find that hard to =
believe),
although I'm a bit skeptic regarding the values that Microsoft provides =
(2x
faster for collections using reference types, and 3x for value types).

All that said, I am not sure about what position to take regarding this
subject. David and Rui, what are your thoughts on this?


JS


------------------------------------
Jo=E3o Paulo Pedro Mendes de Sousa Saraiva
Estudante
jps...@ne...
jpp...@ho...
jpp...@gm...
Rua Mateus Vicente, 9, 10=B0 Dto
1500-445 Lisboa
tel: 217267899
mobile: 965403291
IM: jpp...@ho...
http://mega.ist.utl.pt/~jmss/
------------------------------------

-----Original Message-----
From: ecl...@li...
[mailto:ecl...@li...] On Behalf =
Of
Kunle Odutola
Sent: s=E1bado, 26 de Novembro de 2005 14:03
To: ecl...@li...
Subject: [Eclipsedotnet-developers] .NET 1.1 vs .NET 2.0 again

Hi,

I think I've had a change of heart on this. I still agree that the
availability of .NET 2.0 and Visual Studio 2005 C# Express, and the fact
that .NET 2.0 and .NET 1.1 can co-exist on a machine is evidence that a =
.NET
2.0-only restriction isn't particularly onerous.

Nevertheless, I'm uneasy because nothing in the platform *needs* .NET =
2.0
features. VS.NET 2005 (including C# Express) is a CPU/RAM/DISK hog. Some
people might prefer the leaner VS.NET 2003 unless the newer version adds
real value. I'm not sure that it does in this case.

Anyways, just my 2=A2...


Kunle



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick
_______________________________________________
Eclipsedotnet-developers mailing list
Ecl...@li...
https://lists.sourceforge.net/lists/listinfo/eclipsedotnet-developers

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.8/183 - Release Date: =
25-11-2005
=20

--=20
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.8/183 - Release Date: =
25-11-2005
=20

[Eclipsedotnet-developers] .NET 1.1 vs .NET 2.0 again

[Kunle O. <kun...@vi...>]

Hi,

I think I've had a change of heart on this. I still agree that the
availability of .NET 2.0 and Visual Studio 2005 C# Express, and the fact
that .NET 2.0 and .NET 1.1 can co-exist on a machine is evidence that a =
.NET
2.0-only restriction isn't particularly onerous.

Nevertheless, I'm uneasy because nothing in the platform *needs* .NET =
2.0
features. VS.NET 2005 (including C# Express) is a CPU/RAM/DISK hog. Some
people might prefer the leaner VS.NET 2003 unless the newer version adds
real value. I'm not sure that it does in this case.

Anyways, just my 2=A2...


Kunle

[Eclipsedotnet-developers] Testing

[<da...@me...>]

Greetings to you all!

David Ferreira

[Eclipsedotnet-developers] Structure of the CVS project repository

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

OK, so here is the CVS repository structure as of today:

=20

\bin =96 contains the binaries and the files necessary to run the =
application.
Binaries that are changed often (i.e., dlls for most plugins) are not
inserted here yet (because of frequent updates to source code)

=20

\bin_emf =96 will contain the binaries for the EMF-port project

=20

\bin_gef =96 will contain the binaries for the GEF-port project

=20

\bin_tests =96 will contain the binaries for executing NUNit tests

=20

\docs_platform =96 contains (some) documentation about the Platform and =
its
development (for example, some schemas for the extension points for
Core.Runtime and Core.Resources)

=20

\java_src =96 contains the java source of those plugins that are being =
IKVM=92ed
into the platform (SWT, Text, Draw2D). Apart from some small changes to =
the
code (to use .NET threads, etc.), this code is exactly like the one from =
the
Eclipse platform. This is why these plugins are named org.eclipse.swt,
org.eclipse.text, etc.

=20

\src_emf =96 contains work-in-progress for EMF (related to my MSc =
thesis, too,
but it=92s supposed to be a somewhat-of-a-port of EMF to Eclipse.NET)

=20

\src_gef =96 contains work-in-progress for GEF

=20

\src_platform =96 contains the source code for the Eclipse.NET platform =
itself

            \Core =96 contains the source code for the Core plugins
(Core.Boot, Core.Runtime, Core.Resources, Java =96 a collection of =
utility
classes and Launcher) =96 pretty stable, but should be more intensivelly
tested

            \Debug =96 should contain the source code for the Debugging
framework; not started yet

            \SWT_UI =96 contains the source code for the SWT-enabled UI;
should undergo heavy revision

            \Text =96 contains the source code for the Text framework =
(for
handling text documents); currently not used, as the IKVM=92ed version =
is
being used

            \UI =96 some =93experiments=94 of mine at creating a version =
of Jface
based on SWF; in the future, should contain the UI source code for the
platform, based on SWF

            \Update =96 nothing much; I had to scrap most of the =
updating
facilities of IBM=92s Eclipse, as the JARs and etc. were not applicable =
to the
.NET framework

            \Utils =96 some zipping utils (this actually consists of
SharpZipLib, but should undergo some revision to see what is necessary =
and
what is not); used by the SWT_UI (for zipping resources, etc.)

=20

\src_platform_tests =96 contains tests for some of the source defined in
\src_platform; should undergo heavy development.

=20

=20

The reason I split up the \bin, \bin_gef, \bin_emf and \bin_tests was so
that the \bin directory contains only the binaries belonging to the =
platform
application itself. Other binaries (tests, EMF, GEF, etc) are not =
considered
part of the platform per-se, but instead are plugins built on top of the
platform.

=20

All CVS modules not referred here (\documentation, \src, etc.) are not
currently used (not by me, anyway).

=20

Also, please note that this repository structure is what I believed was =
the
best for the time-being (as I had nobody saying otherwise, for obvious
reasons :P ). Of course, if anyone has any ideas on how to better =
organize
it, feel free to drop in a word :-) .

=20

Boy, I can=92t wait for SourceForge to have a decent SVN repository, so =
we can
handle it easily=85 CVS sucks. Bigtime. :=92(

=20

=20

Best regards,=20

            JS

[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

[Eclipsedotnet-developers] Innauguration of the list

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

Well, I guess it=92s about time we consider this mailing list as =
=93alive=94. So,
here is its first mail.

=20

Someone with a bottle of champagne for the baptism? :P

=20

Regards,

            JS