Log of the #nice channel on irc.freenode.net

* arjanb leaves02:08
* alexgreif joins11:28
* bonniot joins11:39
hello alex11:40
<alexgreif>hi daniel,
good that you join, I have a problem:
I want to retype the following method of the interface IMarker:11:41
setAttribute(String??attributeName, Object??value)
value can be null
I tried:
<T> setAttribute (IMarker, String, ?T) = native IMarker.setAttribute(String, T);
but nicec tells:
Encountered "?".11:42
Was expecting one of:
"-" ...
any idea?
oops the return type is missing
on both sides
is the value really of any type?
<alexgreif>Unknown java class T
<bonniot>you must put Object on the right11:44
after native, you must write exactly the Java Type
<alexgreif>javadoc tells:
The value must be null or an instance of one of the following classes: String, Integer, or Boolean. If the value is null, the attribute is considered to be undefined.
<bonniot>i see
<alexgreif>I dont know whether its possible to tell taht only 4 types are allowed11:45
<bonniot>if you wanted to typecheck it statically, you could write three overloaded versions, one for each valid type
<alexgreif>I will do that in the second run
<bonniot>and you choose one of them to include the null type11:46
the following line still not ok:11:47
marker.setAttribute(IMarker.SEVERITY, IMarker.SEVERITY_ERROR);
Ambiguity for symbol setAttribute. Possibilities are :
<Any T> nice.lang.void setAttribute(IMarker, String, ?T)
nice.lang.void setAttribute(org.eclipse.core.resources.IMarker, ?java.lang.String, nice.lang.int)
<bonniot>what is the type of IMarker.SEVERITY_ERROR ?11:48
<bonniot>is a null String really valid in the version with the int argument?
in any case, it will work if you write the type safe version (with 3 methods)11:49
<alexgreif>you mean the retyping?
<alexgreif>I dont understand the first question11:50
<bonniot>does setAttribute(IMarker, String, ?T)
<alexgreif> nice.lang.void setAttribute(org.eclipse.core.resources.IMarker, ?java.lang.String, nice.lang.int) really accept null in its second argument, or should it be retyped?
SORRY: does setAttribute(org.eclipse.core.resources.IMarker, ?java.lang.String, nice.lang.int) really accept null in its second argument, or should it be retyped?11:51
<alexgreif>the key must not be null
<bonniot>so it should be retyped to say that
afterwards the call will not be ambiguous
<alexgreif>the setAttribute method is 4 times overloaded11:52
setAttribute(String??attributeName, boolean??value)
setAttribute(String??attributeName, int??value)
setAttribute(String??attributeName, Object??value)
so I retype the int varsion too11:53
<alexgreif>fine its solved. thx11:54
another question on Location:
when is Option relevant? you told if used as nicec option, but do you have an example?11:55
<bonniot>for instance if you call 'nicec dummy', when dummy is not a valid package11:56
<alexgreif>ah, so not something in --sourcepath or some other nicec option?
<alexgreif>you mean no?11:57
<bonniot>sorry, i didn't read well
<alexgreif>ok, I understand
<bonniot>a priori, it could be any compilation option
that is wrong, so the compiler want to report it11:58
the package to compile is one of these options
<alexgreif>I will test "nicec bla" to see what happens
Q: i have a field: ?IProgressMonitor monitor;12:03
progress(packageName, phase) {
if (monitor == null) return;
monitor.subTask("" + phase + " package: " + packageName);
nicec tells:
Arguments (?org.eclipse.core.runtime.IProgressMonitor, java.lang.String) do not fit:
nice.lang.void subTask(org.eclipse.core.runtime.IProgressMonitor, ?java.lang.String)
<bonniot>you have to store it in a local variable
<alexgreif>does nicec not automatically make a notNull after the if?12:04
<bonniot>yes, but not for fields, because it is not safe
<alexgreif>ah, you told that baucause of threading?
<bonniot>(a field could be modified by another thread between the test and the use)
<alexgreif>ok, but if i sure that no threading prob occures, then I have no other choice than to use notNull(monitor) ?12:05
<bonniot>no, you store it in a local variable12:06
let monitor = this.monitor;
if (monitor == null) ...
(being sure that something does not happen is often the source of bugs, because even when it is true now, it might change in the future)12:07
is it possible to write if ((monitor = this.monitor) == null) ... ?12:08
<bonniot>but you want to use it outside of the if too...
<alexgreif>yes, its only a question whether nicec allows this syntax12:09
<bonniot>yes, the syntax is valid
<alexgreif>let monitor = this.monitor; can I aslos use var ... I still dont understand when to use which12:10
<bonniot>use var only if you want to modify the value later
<alexgreif>in this case let is fine12:11
<bonniot>let x = ... is the same as final SomeType x = ... in Java
but let is better, because you don't need to write the type in most cases
<alexgreif>I see
<bonniot>you can still write it if you wish
<alexgreif>I can try without first12:12
<bonniot>var = "variable"
* arjanb joins
<bonniot>hi arjan
<arjanb>daniel what do you think of the problem yesterday with globalconstants? is it a new bug?12:21
<bonniot>i have to look12:28
what is the testcase?12:30
<arjanb>i couldn't find one
<bonniot>do you have a testcase?12:34
<alexgreif>not a self-contained one , only in the plugin context
<bonniot>so can you send it by email? both the source and the compiled version12:36
<alexgreif>ok, but it takes a few minutes
the buggy version?12:37
<alexgreif>ok, the bug works, I tar all and send the mail...12:44
the tarball contains the whole plugin, so you can put it in the eeclipsehome/plugins folder12:48
mail sent
the buggy place is in file NiceProject.nice line: let QualifiedName MAIN_PACKAGE_STORE_ID_QNAME....12:50
<bonniot>how does the bug manifest itself?12:51
<alexgreif>the plugin not even starts up, eclipse says cannot initiate nice perspective...12:52
if a editor was open, the a class not found exception came
so I think in all cases a CNF Exception is thrown but eclipse dies not show them12:53
the constant is used in method: NiceProjectPropertyPage.storeValues()
the shell script to compile the plugin is included 12:55
<bonniot>ok i look13:07
it could be a dependency problem between the package constants13:20
<alexgreif>it works if the constant is in the same package13:22
<bonniot>is setPersistentProperty executed?13:25
<alexgreif>in ehich class 13:26
<bonniot>in NiceProjectPropertyPage13:27
<alexgreif>at that place the plugin must be runnung, but the bug prevents the plugin to start, the perspective cannot be initialized13:28
all log outputs were not printed, so the code was not reached13:29
<bonniot>doesn't eclipse report an exception?
<alexgreif>unfortunetely not
not even under the help menu13:30
if an editor was open, then an ClassNotFoundException is reported
thats the only exc that eclipse showed in the console13:31
could you reproduce the bug?
<bonniot>and what class is not found?13:32
<alexgreif>huh, the message was yesterday... wait I try to repr
Exception creating editor: Unable to instantiate editor: net.sf.nice.nice_file_editor org.eclipse.core.runtime.CoreException: Plug-in net.sf.nice was unable to load class net.sf.nice.ui.editors.NiceFileEditor.13:36
Exception creating editor: Unable to instantiate editor: net.sf.nice.nice_file_editor org.eclipse.core.runtime.CoreException: Plug-in net.sf.nice was unable to load class net.sf.nice.ui.editors.NiceFileEditor.
it tells also : Problems occured while building workspace13:37
I think a class is corrupted in the jar13:38
I try to put a log in the plugin initializer13:40
to see wherther the plugin class is instatiated correctly13:41
<arjanb>the problem could be caused by eclipse that starts the classloading at a different place13:44
<alexgreif>daniel: could you reproduce the behaviour?13:45
<bonniot>can I do it outside of eclipse?13:47
<alexgreif>I think no13:48
eclipse rads the xml file well but in creating some plugin classes it has problems
somehow it does not find anything in the jar13:49
one way would be to debug into eclipse but this would take time :((
<bonniot>where is the class org.eclipse.ui.texteditor.AbstractTextEditor defined?14:02
<alexgreif>in the eclipse sources or in my14:03
<bonniot>in which jar14:05
you need the source java file?
hum, my bytecode verifier tells me that that class (which is part of eclipe) is incorrect...14:10
Pass 2:
Number of LocalVariableTable attributes of Code attribute '<CODE>' (method 'static void <clinit>()') exceeds number of local variable slots '0' ('There may be no more than one LocalVariableTable attribute per local variable in the Code attribute.').
<alexgreif>which class?
<arjanb>so this is a bug in eclipse?14:11
<alexgreif>the error occures even if no editor is involved
<bonniot>this does not mean that it is the cause of your problem. maybe it is, maybe not
the thing is that it makes debugging difficult for me14:12
could you try the following:
make a small main function that tries to load your classes, in the same way eclipse would load them
or otherwise, find a debug mode in eclipse, so that we can know what is happening14:13
the error you reported me is: Exception creating editor: 14:14
so it seems to involve creating the editor...
<alexgreif>I think it begins with NicePerspectiveFactory
only if the editor was open
if the editor was closed it could not init the perspective14:15
<bonniot>but what error do you get?
<alexgreif>only a message that an error occured while worspace creation14:16
<bonniot>there must be a way to get a precise error message
<alexgreif>I have also a problem that the log file under the Help menu seems to be empty14:17
<bonniot>that's where the errors should be reported, right?14:18
<alexgreif>I think so
<bonniot>so the first think could be to get this working14:19
<alexgreif>I dont find a file in the eclipse folder that stores log files. you do?14:21
<bonniot>i don't know how eclipse does logging at all14:22
but you used to get logs in the help menu, right?
<alexgreif>Anyway I can alwaqys reproduce the bug, but I first have to find a reflection bug when invoking the compiler
I have to see how it worked
the reflection bug is eclipse related, not nicec :)14:23
but I have to go now, I come back in the evening
* alexgreif leaves
<bonniot>arjan, what are you up to these days?15:11
<arjanb>i started with the prepartions for the tests i have over one and half week15:23
i'm experimenting with the stdlib but i haven't writen things for the compiler last days15:27
<bonniot>you have tests in august?15:37
<bonniot>that's very strange to me! is it normal university tests?15:50
<arjanb>yes but it are the retry's for the ones i skipped/ didn't pass :-(15:53
<bonniot>ah ok15:58
do you think alex's bug has to do with global variable initialization order?15:59
<arjanb>it think so why else would moving the constant to the other package solve the problem16:02
or it must be the classloading of eclipse16:03
<bonniot>then the error should be that some value is null when it should not be16:17
but that might as well be what happens, only eclipse does not report it16:18
I think this has to be solved first, or we will lose lots of time debuging
in the JVM, an error is always associated to a stack trace
so eclipse must report it, so we know where the problem is16:19
<arjanb>yes it's strange that eclipse eats all the error by default16:20
<bonniot>yes, it should go in the log window16:22
<arjanb>field override commited i see20:48
<bonniot>yep :-)20:49
there is a small problem with the improvement in error messages for field accesses:20:53
import javax.swing.*;
class J extends javax.swing.JPanel
void foo()
WHEN_IN_FOCUSED_WINDOW is a field of class
and nothing more...
<arjanb>where does that error message come from20:59
the thing is that it is a static field, so it is wrong to add an implicit 'this' to the call
i'm working on it
a question is whether this code should be valid21:01
it works if you write JPanel.WHEN_IN_FOCUSED_WINDOW
In Java you don't need to qualify a static field when you are in a subclass of the declaring class21:04
<arjanb>i think it should be allowed but i'm doubting about the case where the method is outside the class21:05
btw is it possible to retype java fields?21:08
yeah, i suppose it is surprising for people used to Java if it does not work, at least when inside the class21:11
i have it working now, and i will add a testcase to make sure21:12
<arjanb>globalconstants don't need a prefix either and importing all final static fields into global scope is not a solution21:13
* alexgreif joins21:24
<bonniot>hello alex21:25
<alexgreif>two cocktails intus... I hope I will ask reasonable questiuons this evening :)21:26
"intus" ?
<arjanb>daniel is the type by an value override needed?21:27
<bonniot>no, but that's not implemented yet
there will be a second type of override, just for values
that one will not require that the original field be final
<arjanb>although a type by a value override doesn't look bad as syntax21:28
<bonniot>the first type was more important I think, because this is something that makes the type system more powerful21:29
overriding the default value is practical, but you can always provide the other value if you wish
if you always provide the type, it is less clear what you are doing21:30
it is important because of the safety restriction to final fields when changing the type
of course you could check if the type stayed the same, but that is fragile
(i.e. it could be a "coincidence")21:31
<arjanb>i think a type should be allowd for value overrides
<bonniot>but then you cannot easily distinguish the two21:32
<alexgreif>daniel: the log file seems to be eclipse/workspace/.metadata/.log21:35
<arjanb>daniel i have a testcase that doesn't work21:44
class A {21:45
final ?String s;
class B extends A {
override String s = "abc";
<alexgreif>daniel: in the logs is an interesting exception :21:46
java.lang.reflect.InvocationTargetException: java.lang.ExceptionInInitializerError: java.lang.IllegalArgumentException:
at org.eclipse.core.internal.runtime.Assert.isLegal(Assert.java:56)
at org.eclipse.core.internal.runtime.Assert.isLegal(Assert.java:41)
at org.eclipse.core.runtime.QualifiedName.<init>(QualifiedName.java:43)
at net.sf.nice.core.fun.<clinit>(src/net/sf/nice/core)
at net.sf.nice.core.NicePlugin.<init>(NicePlugin.nice:11)
at java.lang.reflect.Constructor.newInstance(Native Method)
<bonniot>ah, that's better :-)21:47
what is the contract for QualifiedName ?
<alexgreif>whom do you mean?
<alexgreif>ah me :)
contract? do you need the source?
<arjanb>so the Qualifiedname constructor is call with a null value
<alexgreif>QualifiedName:43 is the second line of:21:50
public QualifiedName(String qualifier, String localName) {
Assert.isLegal(localName != null && localName.length() != 0);
this.qualifier = qualifier;
this.localName = localName;
I hope this helps you guys
<bonniot>yes, it's good to know where the error occurs21:51
so it surely is problem with the initialization order
the thing is that in Nice like in Java, the compiler does not try to "guess" in what order to initialize the constants (static fiels in Java)21:52
so when they depend on each other it can be tricky to get it right
<alexgreif>so Qualified name is first instantiated, and then the String that will be passed as 1. or 2. arg?21:53
<bonniot>that's possible21:54
<alexgreif>hm can we influence this behaviour?
<bonniot>the constants in a same file must be initialized in the order they are defined
and if a package A depends on another B, then he constants of B should be initialized before A21:55
<alexgreif>is this the right way? What if there is a circular dependancy?
<bonniot>(provided that they are not mutually dependent, of course)
you could even have values that depend on each other, eg21:56
let int i = j;
let int j = i;
in two different packages
could you try putting all the constants of the .core package in one file, and in a sensible order?21:57
<alexgreif>how should I order them?21:58
<bonniot>in the dependency order21:59
let int i = 1;
let int k = i;
not k before i
so you declare a value before you use it
<alexgreif>ok, and all in one file. Does it matter if something else is in this file?22:00
<bonniot>the stange thing is that if NICE_PLUGIN_ID is null, then the second argument should produce a null pointer, even before instantiating the class
no, it does not matter
<bonniot>oh, maybe it is 22:01
<alexgreif>now the order is:22:02
let String NICE_PLUGIN_ID = "net.sf.nice";
let String MAIN_PACKAGE_STORE_ID = NICE_PLUGIN_ID + ".main_package_store_id";
all in the file_core.nice
<bonniot>there are other QualifiedName constants, no?22:03
<alexgreif>yes, two others. oesszesen harom22:04
ketto masik mogotte
let QualifiedName CLASSPATH_STORE_ID_QNAME = new QualifiedName(NICE_PLUGIN_ID, NICE_PLUGIN_ID + ".classpath_store_id");22:05
let QualifiedName JAR_NAME_STORE_ID_QNAME = new QualifiedName(NICE_PLUGIN_ID, NICE_PLUGIN_ID + ".jar_name_store_id");
the same error :(22:06
<bonniot>ah I see, MAIN_PACKAGE_STORE_ID is not initialized first
<arjanb>you could try in reverse dependence order22:07
<alexgreif>of which ones?
<alexgreif>ok ...
<bonniot>no, the order seems random
this is a bug
<alexgreif>should I cancel the test=
<bonniot>wdym cancel?22:09
i'm looking at the way the initialization is generated
<arjanb>the order might depend on the order that they are resolved
<alexgreif>changing orders still crahes22:10
as you said
<bonniot>alex, this is not blocking you, is it?22:14
<alexgreif>no, I have a workaround, but can always switch to the buggy version back if you want22:15
<bonniot>ok, we'll see how it goes22:16
<alexgreif>do you need my help with the buggy version for the next time? otherwise I would develop my stuff forward
<bonniot>you should go forward22:17
<alexgreif>thanks... yust now I found the bug that concernes me for the last hours :))22:18
I see I should more often dring cocktails before I write nice code :))
or do bugfixing22:19
now i have a testcase for this, it's a good step22:22
I hope Im a good beta-tester
daniel: May I use u as an eclipse beta-tester in the next time?22:26
for the plugin?
<bonniot>sure, but i think it would be best to have several people trying it22:29
<alexgreif>yes of course, but its sufficient for the moment if I see that it works on another platform too22:30
I hope I can send you this evening the first test... I will inform you
<bonniot>that's great22:31
will it have compilation?
<alexgreif>yes :)
<bonniot>arjan, do you have eclipse installed?
<alexgreif>I have my linux box but I have no X installed on it22:32
<arjanb>yes version 2.1
<alexgreif>thats fine!!22:33
ok, the I get another beer ...
<bonniot>mixing beer and cocktail... we'll see the results!22:34
<bonniot>I think i have a simple way to make globals initialized in the correct order, even when they are in a random order, and/or in different files...22:36
yes, it works in all the cases i tried22:38
the great thing is that it needed only a few lines :-)22:39
<alexgreif>good tell me if I can download it
<arjanb>does it solve the oldest open bug too?
<bonniot>i'll try22:41
<alexgreif>if a method can return an array or null is the type IProject[?] or ?IProject[] ?22:47
the array items are all non-null if the array exists22:48
<alexgreif>the nicec tells null may be null22:49
IProject[?] compiles fine
<arjanb>and IProject[] ?22:50
<alexgreif>also nunn may be null
nunn = null22:51
the last line in the method is "return null"
arjan I use the following retyping that compiles:22:53
IProject[?] build(IncrementalProjectBuilder, int, ?Map<String,String>, ?IProgressMonitor)
= native IProject[] IncrementalProjectBuilder.build(int, Map, IProgressMonitor);
<bonniot>you cannot return null if you say that the result is not null!22:54
<arjanb>sorry i was confused with array nullness things again :-(22:55
<bonniot>if you find the notation for arrays confusing you can also use:
?Array<T> and Array<?T>
<alexgreif>I want to return null but if the return type is ?IProject[] the nicec says: "null might be null"22:57
<arjanb>yes ?IProject[] == Array<?IProject>22:58
i hope i didn't confuse you too alex
<alexgreif>?Array<IProject> compiles fine but not ?IProject[] are they different?22:59
<arjanb>?Array<IProject> == IProject[?]23:00
<alexgreif>and Array<?IProject> == ?IProject[] ?
<bonniot>btw, you can also use parenthesis:
<bonniot>?(T[]) and (?T)[] maybe that's more clear
<alexgreif>?Array<IProject> == IProject[?] means that the return type may be null? And ?IProject[] means that return type is non-null but the array contents may be null ?23:02
<alexgreif>huh, I need a beer
<arjanb>i'm not sure that helps against confusion23:04
<alexgreif>I think I will use () as daniel said
() make it really clear!
<bonniot>i sent the new development version, that improves the initialization of globals23:28
<alexgreif>I make my final tests with compiling in the plugin23:29
<bonniot>now the compiler finds the good order, for globals that refer directly to each other (like in Alex's case)
<alexgreif>daniel: do you remember our problem that your eclipse version didi not have the problem view? I hava an offcial pdf from IBM from 2000/2001 where they mention problem markers. strange!23:35
<bonniot>maybe it was removed, then put again23:37
or renamed in the middle
<alexgreif>or the markers existed but not the Problems-view. maybe all problem markers were displayed in the tasks-view23:38
daniel: can you give me a nice example where nicec reports a warning?23:47
<bonniot>let String s = "ABC";23:50
if (s == null) ;
it's a warning because s can never be null
<alexgreif>ok I try...
<bonniot>arjanb: if found the cause of the bug with overrides
it's the generation of default constructor for calling from java
class A {String s;}
that generates only one constructor: A(String)
class B {override String s = "";}
that generates two constructor: B(String) and B()
but B() expects to call A(), which does not exist
<arjanb>so this one is not easy to fix23:51
<alexgreif>daniel: I dont get eclipse to display warning markers :(( hmmmm errors are displayed fine :)23:59
<bonniot>the listener does not receive the warnings?00:00
<arjanb>do you get a warning outside eclipse?
<alexgreif>d: the listener works fine, but eclipse not00:02
<bonniot>do you have the same code that displays warnings and errors?00:05
<alexgreif>yes, only the type differs00:06
I mean the eclipse marker type00:07
<bonniot>did you try using the same marker
<alexgreif>not yet
ok, I have the first testable nice plugin version . here are the instructions how to get it run:00:24
1) download http://flow4j.sourceforge.net/nice_plugin.tgz
2) expand the tarball into eclipse/plugins
3) start/restart eclipse
4) create a project of type "Nice Project" with the name "nice1"
5) change to the "Resources Perspective"
6) create a new Folder for the main package like "test"
7) click on the "nice1" folder
8) Menu "Project"->"Properties"
9) select "Nice Project Properties"
10) set main package: test
11) leave classpath empty
12) set jar name: nice1.jar
13) create a new file "test.nice" in the "test" package
14) type VALID code in "test.nice"
15) save the file
now compilation should be started
a file nice1.jar is created in the "eclipse/workspace/nice1" folder
16) make the code invalid
17) save again
the error is reported to the console for debugging reasons
a "Problems" view should be opened with the error/errors
if the view is still empty then click on the black triangle on the right of the problems view title bar
select "Filters..."00:25
check "Nice Problem"
18) doubleclick on the problem entry -> select the line in the nice code
<bonniot>alex, could you put these instructions on a wiki page?00:32
I have the warnings in the problems view :))00:33
<bonniot>i should delete the old plugin first, right?
<alexgreif>move it in a temp folder outside of plugins00:34
<arjanb>it works for me :-)
<alexgreif>I uploaded a new version where warnings are shown too in the problems view00:36
it is now v 0.1.2
<arjanb>multiple errors do also work but multi line errors are printed a bit strange in the problem view00:37
<alexgreif>you can see the curently deployed plugin version in menu Help->About Eclipse Platform->Plugin Deatils00:38
can you post the nice code for multi line errors?
<arjanb>any parse error00:39
<alexgreif>daniel: thanks for the tip to display the warnings as error marker. this was the right decision
arjan: we have to decide how it should be selected in the source00:40
<bonniot>is there a different marker for warnings?
<alexgreif>I thought it but there isnt. only this changes:00:41
marker.setAttribute(IMarker.SEVERITY, IMarker.SEVERITY_WARNING);
instead of
marker.setAttribute(IMarker.SEVERITY, IMarker.SEVERITY_ERROR);
<bonniot>if there isn't, then you got a compiler error?00:42
<bonniot>when you used IMarker.SEVERITY_WARNING
which does not exist
<bonniot>are you sure it does not exist then?
<alexgreif>IMarker.SEVERITY_WARNING is fine but I have to use resource.createMarker(NICE_MODEL_PROBLEM_MARKER); for errors and warnings, because both have to appear in the problems view
formerly I used resource.createMarker(NICE_MODEL_WARNING_MARKER); but this was ignored because thwere is no Warning view00:44
<bonniot>hum, so that's only an eclipse issue. you know better :-)00:45
<alexgreif>It was copied from the ruby source... so there its still a bug :)))
<bonniot>? what is the bug?00:46
<alexgreif>that warnings are not shown in the problems view in the ruby plugin
<bonniot>ah, a bug in their plugin...
you should tell them then
<alexgreif>so there its still a bug in the ruby plugin :)))
<bonniot>alex, this is very good to have an eclipse plugin again, and written in Nice! :-)
<arjanb>warnings work here
<bonniot>it would be great to be able to set the sourcepath too00:48
because I like to have a src subdirectory
<alexgreif>yes, I will do that, because I have all my sources in a src folder . so I need this too00:49
dito :)
this is a good style in eclipse to have src, lib, bin folders in the project
<bonniot>do you plan to put the plugin in CVS soon?00:50
<alexgreif>yes, why?
<bonniot>it's a good idea00:51
should it be in a new CVS module in the nice project of SF?
or would you like it somewhere else?
<alexgreif>I font know exactly, the ruby plugin has an own sf project00:52
called eclipseruby
<arjanb>why not in the nice project cvs for now?00:55
everyone who may make changes to the plugin is allready developer in the nice fs project00:56
<alexgreif>yes, maybe we can make a eclipse-plugin forum or mailing list00:58
<arjanb>btw does martin still have plan the help on the plugin?01:00
<alexgreif>he did not contact me
arjan: where in the cvs tree? Nice/plugins/eclipse ?01:06
<arjanb>no better not in the Nice module but just as niceswing does01:08
but i don't know that much of cvs daniel?
<alexgreif>arjan: so on this level: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/nice/ ?01:09
<bonniot>yes, i agree it should be in a separate module01:10
<alexgreif>so in a top level module called "plugins" or "plugin" ??
<bonniot>what about "eclipse" ?01:11
<alexgreif>and if somebody writes a jedit plugin?
<bonniot>if a different plugin was started, it would be mostly a different work
so it can be in a different module
<alexgreif>ok, the in eclipse
<bonniot>the package names are a bit strange i think01:12
nowhere it says that it is related to eclipse01:13
<alexgreif>but net.sf.nice should stay
<bonniot>why? because Sun said so?
<alexgreif>no because all other plugins make it the same way...01:14
org.eclipse.jdt.debug.ui_2.1.0 plugin has also /org/eclipse/jdt/debug/ui
<bonniot>ok, i don't mind that01:15
<alexgreif>"In general, you should use Java package name prefixes for all of your ids in order to ensure
uniqueness among all the installed plug???ins."
<bonniot>does the id have to be the same as the package name, or are they two different things?
<alexgreif> so plugin sources and id's use this convention01:16
they go one step further they have eg .../core and ../internal/core packeges
<bonniot>yes, but the question is what package name to chose
<alexgreif>in order to define internal and external apis01:17
the package names after net.sf.nice is our choice, or do you want net.sourceforge.nice, or something completely different?01:18
<bonniot>why is this better that public/private ?
<alexgreif>you mean internal/core and core?
<alexgreif>I still dont need internal and not internal01:19
I dont know whether other plugins will contribute to zhe nice pkugin in future so I dont see a necessity to make internal/notinternal or private/public packages
maybe flow4j in future :)01:20
daniel: you can make a suggestion about the package stucture so we can discuss better about the different version 01:22
<bonniot>i think the packag structure is your decision01:23
<alexgreif>never mind, these are cosmetics... Im glad that, as it seems to be, the plugin can be written in nice itself, so we have layn a good groundwork
we just need to agree on a root package name
<alexgreif>yes, but I want to hear your suggestion , how you would structure it
the cvs root module should be called "eclipse"
inside that you should probably have src/
<alexgreif>src/ bin/
<bonniot>and a build.xml if it is built by ant01:26
bin/ should not be in CVS
only sources go in CVS
<alexgreif>oops /lib
build.xml besides src/
<bonniot>but yes, the build process can write the generated classes in some dir like bin or classes
no, i would have build.xml at toplevel01:27
<alexgreif>the build process makes a jar in the lib inside net.sf.nice/
so that its deployable
<bonniot>then lib is not in CVS either, then
anyway, everything that is not in CVS can be changed easily
<alexgreif>ok, src/net.sf.nice/lib/nice.jar ? but nice.jar is not a source
I will make a suggestion i the next days :) Im too tired now01:29
<bonniot>what i mean is that the lib directory is not stored in the repository
<alexgreif>the ant script should make the plugin deployable so lib/nice.jar is maybe ok on toplevel
<bonniot>but the build process can create the lib directory
<alexgreif>and where does it get the nice.jar=?01:30
<bonniot>the compiler?
<alexgreif>or dont you ewant to put nice.jar in the plugin itself?
<bonniot>hum, we have to think about that
<bonniot>but nice.jar should not be in the repository01:31
<alexgreif>why not?
<bonniot>because it is not a source, it can be generated
CVS is there to store what humans produce :-)
the rest is generated by scripts
<alexgreif>hm, all xerces and xalan jars can be genarated too, but all distribs have then in binary form01:32
<bonniot>a distrib is different from a CVS repository
the nice.jar might be distributed with the plugin
<alexgreif>yes I see, but it mustnt be too complicated01:33
to build the plugin
<bonniot>i think that after getting the sources from CVS
(sources of the plugin)
<arjanb>i found another point where nice does better than java 1.5 new T[] where T is a type parameter not possible in java 1.501:34
<bonniot>you would just copy (or link) the nice.jar you want to use at some specific place, like a lib subdirectory
<alexgreif>my soltion: user gets the plugin sources and gets the nicec jar and then ant can build the dist
<bonniot>arjanb: yes, that's true. it's also a pain to compile, but it's worth it :-)01:35
alexgreif: yes, i agree
<alexgreif>daniel: so ant will complain when nice.jar is not there. ok?
<alexgreif>and where should we do build.xml?01:36
I would put it on toplevel beside src/
many other projects do it like zhis
<bonniot>yes, at toplevel, not inside src
<alexgreif>no, beside src/
<bonniot>like in Nice: Makefile is at toplevel
<bonniot>what about the package names?
net.sf.net.eclipse.* ?01:38
net.sf.nice.eclipse.* ?
<alexgreif>what about the plugin name?
<bonniot>or just nice.eclipse.* ?
<alexgreif>I would not use eclipse in the plugin name
the plugin name/id is always the first part of the package struct01:39
<bonniot>the package name should say what it is about,no?01:41
<alexgreif>why not net.sf.nice/* ?
<bonniot>for package names?01:42
<alexgreif>yes, but we have to decide whether we use net.sf.nice/eclipse or without eclipse
I look at some other plugins ...01:43
<bonniot>i'm not sure i understand your mixing of . and /
<alexgreif>I see them as the same
package deimiters
but the plugin name/id has only dots01:44
<bonniot>well, if you have a package net.sf.net.tools, it could be something that clashes with general tools for nice
i see that in your current plugin, there is a directory net.sf.nice/01:45
<alexgreif>yes thats an argument, but I dont think that other plugins have "eclipse" in their package path
<bonniot>but tha packages are net.sf.nice.tools, etc
<alexgreif>the root package is net01:46
<bonniot>net.sf.nice is the id at the moment?
<alexgreif>yes, its also the name of the plugin folder
<bonniot>ok, so cannot the id be that, and the package net.sf.nice.eclipse.* ?01:47
<alexgreif>ok, we can
<bonniot>we can think over it... i need some sleep, and you too!01:48
<alexgreif>I thinkother plugins dont have the word "eclipse" in their package path, but to avoid clashes, its ok
do you already have packages like net/sf/nice ??01:49
<bonniot>but the package names is something private, isn't it?
<alexgreif>private ?01:50
<bonniot>so inside eclipse, you cannot even know what they are. you just know the id, no?
<alexgreif>no, in the xml you see the id="" and class="" of the plugin class itself,
see the first entry in a plugin.xml
<bonniot>ok, but that something in the internals of eclipse, isn't it?01:51
it does not matter for anything
<alexgreif>the class="" is only for reflection
"The specific name that you use after the prefix is completely up to you. However, if your plug???in id prefix is01:52
exactly the same name as one of your packages, you should avoid using class names from that package.
Otherwise it will become difficult to tell whether you are looking at an id name or a class name."
"In general, you should use Java package name prefixes for all of your ids in order to ensure01:53
uniqueness among all the installed plug???ins."
<bonniot>imagine that somebody write a jedit plugin01:54
they might want to use the same net.sf.nice prefix01:55
so the editor name must be added to make the package name unique
<alexgreif>yes I see , this coud lead to problems
but then the packages could be named: net/sf/nice/plugin/eclipse/*
like net/sf/nice/tools/ant01:56
<bonniot>i don't think that's necessary
yes, only I don't use net.sf.nice, just nice
<alexgreif>ok, it gets philosophical :)01:57
<bonniot>because i think we can consider the nice prefix is reserved for us :-)
<alexgreif>yes I just saw that in the ant source
<bonniot>of course, it's the time for philosophy :-)
<alexgreif>at 2:00 ??
<alexgreif>ok, here why I chose net.sf.nice:01:58
<bonniot>couldn't the id be net.sf.nice, and the package names nice.eclipse.* ?
<alexgreif>its url like, and its lookung the same as other plugins, and this is a fine package path prefix
yes it could be anything, but its the question do we do it like other plugins or do we go out own way?01:59
the id should be net.sf.nice02:00
<bonniot>my point is: only the id matters for others
the package of the plugin class is only of use for freaks :)
its one entry in the xml and only for reflection
<alexgreif>btw do you want to begin all nice packages with only "nice...."
or with something more url like?
because the url of nice is "nice.sf.net"02:02
thats why I used this for the plugin id
<bonniot>nice.* is only for "official packages" linked with the core language
like java.*
<alexgreif>so the eclipse packegeas too?02:03
<bonniot>yes, but maybe someday nice will not be on sourceforge anymore
but every project should have a permanent url !??!02:04
<bonniot>i think the eclipse ids should use the url, because that is the public unique name for now
projects don't have permanent urls02:05
especially if they are linked to a company
for instance a project started by compaq would have been com.compaq.*
but then they were bought by HP, so everything should be renamed com.hp.*02:06
<alexgreif>ok, I thought it, like org.jdom, or org.junit
and will it be renamed?
<alexgreif>or dies it stay com.compaq.* ?02:07
<bonniot>it should be renamed, that's the problem
<alexgreif>so with the nice prefix we wont have any problems02:08
<bonniot>because after some time the domain of the bought company will be resold
if somebody buys us a domain for Nice, i will be happy of course :-)
<alexgreif>ok, then the eclipse id will be net.sf.nice and all sub id's in the plugin. And the source packages will begin with nice.eclipse.*
<alexgreif>a toplevel domain like de or com ?
<bonniot>shorter to type when writing the plugin code :-)
de would be strange
<alexgreif>so I only have to replace net.sf.nice in the pacjage names by nice.eclipse
yes :)02:10
<bonniot>but I think all nice.{com,net,org} are taken
maybe .comp will be created someday :-)02:11
<alexgreif>then nice.dyndns.org :)
<arjanb>nicelang.{org,net} are free
<alexgreif>when will you wake up tomorrow?
nicelang is good02:12
<bonniot>yes, ruby has ruby-lang.something
<alexgreif>nicelang.net sounds good
<bonniot>about tomorrow, why?
<alexgreif>I have registered my linux box as "orthanc.homeunix,net"
yust a question, because I want to go with the kids swimming in the morning after ... 6 hours sleep :-/02:13
its sleeping my linux box :)
<bonniot>i'll go sleeping too02:15
<alexgreif>me too
<bonniot>but we made quite good progress today!!
<alexgreif>yes, Im really happy!02:16
what about martin and the plugin?
he said he was interested
you should make the new version available though the wiki
<alexgreif>I think he has no time
the link is there , its the old one, Ill change the text02:17
ok, time to sleep
<bonniot>good night
* alexgreif leaves
<bonniot>bye arjan02:18
<arjanb>good night
* bonniot leaves
* arjanb leaves