NOTICE! This is a static HTML version of a legacy Fiji BugZilla bug.

The Fiji project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Bug 793 - TrakEM Scripting not working after imageJ 2.0.0-rc-2
TrakEM Scripting not working after imageJ 2.0.0-rc-2
Status: RESOLVED FIXED
Product: Fiji
Classification: Unclassified
Component: ImageJ2
unspecified
PC Windows
: P4 blocker
Assigned To: ImageJ Bugs Mailing List
Depends on:
Blocks:
 
Reported: 2014-06-16 09:22 CDT by Falk Lucas
Modified: 2014-06-24 10:42 CDT
3 users (show)

See Also:

Description Falk Lucas 2014-06-16 09:22:16 CDT
a call to create a new project will result in this error:

Traceback (most recent call last):
  File "X:\Falk\AtlasImport Tools\AtlasImporter20120224.py", line 108, in <module>
    project = Project.newFSProject("blank", None, directory, True)		
NameError: name 'Project' is not defined

	at org.python.core.PyException.fillInStackTrace(PyException.java:70)
	at java.lang.Throwable.<init>(Throwable.java:181)
	at java.lang.Exception.<init>(Exception.java:29)
	at java.lang.RuntimeException.<init>(RuntimeException.java:32)
	at org.python.core.PyException.<init>(PyException.java:46)
	at org.python.core.PyException.<init>(PyException.java:43)
	at org.python.core.PyException.<init>(PyException.java:61)
	at org.python.core.Py.NameError(Py.java:246)
	at org.python.core.PyFrame.getname(PyFrame.java:257)
	at org.python.pycode._pyx4.f$0(X:\Falk\AtlasImport Tools\AtlasImporter20120224.py:325)
	at org.python.pycode._pyx4.call_function(X:\Falk\AtlasImport Tools\AtlasImporter20120224.py)
	at org.python.core.PyTableCode.call(PyTableCode.java:165)
	at org.python.core.PyCode.call(PyCode.java:18)
	at org.python.core.Py.runCode(Py.java:1261)
	at org.scijava.plugins.scripting.jython.JythonScriptEngine.eval(JythonScriptEngine.java:76)
	at org.scijava.script.ScriptModule.run(ScriptModule.java:172)
	at org.scijava.module.ModuleRunner.run(ModuleRunner.java:167)
	at org.scijava.module.ModuleRunner.call(ModuleRunner.java:126)
	at org.scijava.module.ModuleRunner.call(ModuleRunner.java:65)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)

Information about your version of Java:

  os.arch => amd64
  os.name => Windows 7
  os.version => 6.1
  java.version => 1.6.0_20
  java.vendor => Sun Microsystems Inc.
  java.runtime.name => Java(TM) SE Runtime Environment
  java.runtime.version => 1.6.0_20-b02
  java.vm.name => Java HotSpot(TM) 64-Bit Server VM
  java.vm.version => 16.3-b01
  java.vm.vendor => Sun Microsystems Inc.
  java.vm.info => mixed mode
  java.awt.graphicsenv => sun.awt.Win32GraphicsEnvironment
  java.specification.name => Java Platform API Specification
  java.specification.version => 1.6
  sun.cpu.endian => little
  sun.desktop => windows
  file.separator => \

The up-to-date check says: REMIND_LATER

Information relevant to JAVA_HOME related problems:

  JAVA_HOME is set to: D:\Fiji.app/java/win64/jdk1.6.0_20//jre
  imagej.dir => D:\Fiji.app

Information about the version of each plugin:

Activated update sites:
ImageJ: http://update.imagej.net/ (last check:20140616153006)
Fiji: http://fiji.sc/update/ (last check:20140612230314)

Files not up-to-date:
  9cf5f8c5 (LOCAL_ONLY) 20101122152004 macros/AddZeros.ijm
  924708a7 (LOCAL_ONLY) 20101122151547 macros/Batch_FindMag.ijm
  510dc392 (LOCAL_ONLY) 20120130151227 macros/CreateFileListHelios2_.ijm
  a6a918d7 (LOCAL_ONLY) 20110127110544 macros/CreateFileListTXT.ijm
  a9f2c8d8 (LOCAL_ONLY) 20101123103018 macros/FindMag_New.ijm
  59a9dfb8 (LOCAL_ONLY) 20100602102203 macros/KeenView_PixelSize.txt
  6ebedb20 (LOCAL_ONLY) 20101122115945 macros/MacroExt.ijm
  140d0957 (LOCAL_ONLY) 20100602095206 macros/MegaView_PixelSize.txt
  9c9e4176 (LOCAL_ONLY) 20101123114420 macros/MosaicMorghani.ijm
  feffea10 (LOCAL_ONLY) 20101118104325 macros/PixelSize_KeenView.txt
  6756bf17 (LOCAL_ONLY) 20101118101953 macros/PixelSize_MegaView.txt
  c4649978 (LOCAL_ONLY) 20101122151951 macros/RenameMia.ijm
  dd974de2 (LOCAL_ONLY) 20101119093122 macros/RenameMia.txt
  667a30b0 (LOCAL_ONLY) 20101118162051 macros/TestArgument_.ijm
  cd933dc2 (LOCAL_ONLY) 20140318144817 macros/falk_.ijm
  0b412ee7 (LOCAL_ONLY) 20101123114304 macros/myTool.txt
  f07ea19d (LOCAL_ONLY) 20130507122737 macros/test.txt
  1455d44a (LOCAL_ONLY) 20111104141853 macros/toolsets/EMEZ Tools.ijm
  d60d1942 (LOCAL_ONLY) 20111104141934 macros/toolsets/EMEZ Tools2.ijm
  33c6c457 (LOCAL_ONLY) 20130604133657 macros/toolsets/Falk's Toolset.txt
  bb3b18aa (LOCAL_ONLY) 20130604133640 macros/toolsets/IJ.txt
  b8355a05 (LOCAL_ONLY) 20100601103313 macros/toolsets/IconTools.ijm
  ddcaf60f (LOCAL_ONLY) 20130604133930 macros/toolsets/MacroDev.txt
  e9cb6eb7 (LOCAL_ONLY) 20121210155405 plugins/Image_CorrelationJ_1o.class
  8e243042 (LOCAL_ONLY) 20140117093038 plugins/SCS_Semiautomated_Segmentation.jar
  6e155e63 (NOT_INSTALLED) 20101208111418 plugins/Samples_.jar
  36f3e680 (LOCAL_ONLY) 20140318150746 scripts/New_.py
  d3260180 (LOCAL_ONLY) 20100909153741 scripts/Record_Desktop.py
  0ea7f8fc (LOCAL_ONLY) 20100909153741 scripts/Record_Window.py
Comment 1 Johannes Schindelin 2014-06-20 15:22:15 CDT
I *think* this is a problem with auto-imports. In particular your AtlasImporter script, in line 108, where it uses Project and does not import the full class name.

From hitting 't' and typing 'project' in https://github.com/fiji/TrakEM2 it seems that the class you want is
https://github.com/fiji/TrakEM2/blob/master/TrakEM2_/src/main/java/ini/trakem2/Project.java

Therefore, you have to import it using

    from ini.trakem2 import Project

in your script.

Please understand that auto-imports were tenable as long as Fiji was a puny project, but now it grew to a point where there would be simply too many clashes. Therefore scripts must not rely on auto-imports, ever (just imagine a random plugin being added that implements a 'Project' class? Exactly. You'd be in exactly the same spot as right now, so the removal of the auto-imports is not the problem; the lack of the explicit import is).
Comment 2 Falk Lucas 2014-06-21 06:55:23 CDT
Thx, for looking into it.
I'm new to Jython scripting and copied scripts from Albert Cardona's examples and then just modifying tiny bits to get started.
The examples were extremly helpfullto get started, but if the do not work anymore, they should be adapted I think
Comment 3 Johannes Schindelin 2014-06-22 14:14:29 CDT
> I'm new to Jython scripting and copied scripts from Albert Cardona's examples and then just modifying tiny bits to get started.
> The examples were extremly helpfullto get started, but if the do not work anymore, they should be adapted I think

I agree that the examples are helpful and that they should be updated. Hopefully Albert will do that soon.
Comment 4 Albert Cardona 2014-06-22 14:34:08 CDT
Lukas,

to fix the scripts, open them in the Script Editor, select a capitalized word, and then go to "Tools - Open help for class (with frames)"

E.g for:

p = Project.getProjects()

... you'll find Project under "ini.trakem2.Project". Therefore, place at the very top of your script an import statement:

from ini.trakem2 import Project


Johannes: given that you have introduced the breaking change, it would be appropriate that the change is not released half-way but it is seen through to completion. I would appreciate very much if you could therefore complete the task by making all the necessary adjustments in examples and documentation alike, prior to releasing it to the world.
Comment 5 Curtis Rueden 2014-06-24 09:17:06 CDT
> it would be appropriate that the change is not released half-way but it is
> seen through to completion.

In an ideal world, of course. But it is pragmatically infeasible without help from the greater ImageJ community. We cannot accomplish everything alone.
Comment 6 Albert Cardona 2014-06-24 09:33:08 CDT
Curtis and Johannes,

releasing a breaking change and expecting everybody, both users and developers, to swiftly adapt, leads to many issues as you have seen, creating work for every developer and confusion for end-users.

A transition could be supported by e.g. startup scripts for every language that include all imports, therefore supporting current working setups as they are without interruption, while providing the opportunity to each user to remove the default imports and therefore avoid class name clashes. At least this you could implement to support the currently breaking change.

After announcing this change, then there is an opportunity for all developers to use a grace period for adapting scripts and documentation, and for end -users to be forewarned. Eventually the default imports could be removed. If one such announcement was done long ago, I am afraid myself and all end-users missed it.
Comment 7 Curtis Rueden 2014-06-24 09:41:27 CDT
> releasing a breaking change and expecting everybody, both users and
> developers, to swiftly adapt, leads to many issues as you have seen,
> creating work for every developer and confusion for end-users.

Absolutely agreed!

> A transition could be supported

Yes. It is a question of time and priorities. We are at the limits of our bandwidth fixing issues which affect many more users in more situations than the auto-import scripting issue does.

There is an opportunity cost for everything. On the surface your proposal is absolutely correct and reasonable, but you have to weigh it against what will _not_ be done as a consequence. The only way I know of to mitigate this is on the "supply side": more people pitching in to help -- the "scratch your itch" philosophy of open source.
Comment 8 Albert Cardona 2014-06-24 09:57:32 CDT
Curtis,

if time is at stake, then perhaps the introduction of a breaking change was not a good decision at this point.

Keep in mind that the interpreters, with their autoimports, are what transform Fiji from an expanded ImageJ to something akin to Matlab: an interactive environment for developing and testing out programs, and executing complex pipelines piece-wise thanks to the persistence of state.

Breaking this is hard to understand from an end-user point of view, and a devastating blow to the usability of Fiji for a lot of users.

Demanding that an end-user knows where to find basic ImageJ classes is burdensome for beginners, while advanced users would have no issue with an announcement that stated "from now on, run this script (URL) in your interpreters when you open them, which supplies all the imports which are no longer imported by default".

In retrospect, the interpreters should have always have had, as they did, the default imports (or an "environment" pull down menu to choose e.g. all of ImageJ, all of TrakEM2, etc.); it is the Script Editor and the execution of scripts that should not have had them.

Albert
Comment 9 Curtis Rueden 2014-06-24 10:18:20 CDT
> if time is at stake, then perhaps the introduction of a breaking
> change was not a good decision at this point.

I am sorry you are disappointed with the direction of the project. I truly hope you are in the minority, but satisfied people are rarely as vocal as those unsatisfied. If it is truly important to you, I urge you to participate at a more direct and technical level (i.e.: coding). Otherwise, please understand that this project is driven by the needs of those who _do_ participate.

> a devastating blow to the usability of Fiji for a lot of users.

I agree that ImageJ should keep the interpreter functionality. It will be reworked to be language agnostic, in line with the rest of the scripting framework. If you desire this to happen more quickly, consider allocating some of your resources towards that goal.

> Demanding that an end-user knows where to find basic ImageJ classes is
> burdensome for beginners

Agreed, we probably want an "organize imports" style feature that tries to add the imports at the top of the script.
Comment 10 Albert Cardona 2014-06-24 10:42:46 CDT
Curtis,

> I agree that ImageJ should keep the interpreter functionality.
> It will be reworked to be language agnostic, in line with the
> rest of the scripting framework. If you desire this to happen
> more quickly, consider allocating some of your resources
> towards that goal.


The efforts you guys are putting in are fantastic. What I object to is the removal of functionality that a lot of Fiji users rely on, without having a ready replacement. Demanding that others produce said replacement quickly, so that the gap is not long, is not acceptable--we all have our schedules and priorities.

Albert