Vampire (jEdit | 1 Apr 01:52 2010
Picon
Picon

Re: Memory leak in jEdit ?

For me the font substitution doesn't make any difference. The error happens with and without the option being active.
But I found out how to reliably reproduce the problem and also that we possibly don't have a problematic leak here because it is very short-living.
JProfiler tells me the allocation of that char[] was done in  org.gjt.sp.util.SegmentBuffer.ensureCapacity() with one allocation.
The reference hold to it is in sun.font.GlyphLayout though.
To be concrete, the char[] is still available in an instance of sun.font.TextRecord.
This TextRecord is an instance variable of a GlyphLayout.
The GlyphLayout in question is referenced as static field "cache" in class GlyphLayout.
If someone calls GlyphLayout.done(GlyphLayout) the given GlyphLayout is referenced as cache and the next time someone calls GlyphLayout.get(LayoutEngineFactory) this cached GlyphLayout is returned and reused and the cache reference is set to null.
Actually org.gjt.sp.jedit.syntax.Chunk.addGlyphVector(Font, FontRenderContext, char[], int, int) calls java.awt.Font.layoutGlyphVector(FontRenderContext, char[], int, int, int) which in turn first calls GlyphVector.get(null), then layouts the glyphs with GlyphVector.layout(...) and then calls GlyphLayout.done(GlyphLayout) which causes that GlyphLayout to be stored in the cache reference.
This means, as soon as some other text is displayed, the memory is freed as the TextRecord then has the contents of the next file.
So if you have some buffer open with text in it, you will not notice any memory leak as the GlyphLayout is reused as soon as you display some other text. If you have only Untitled-1 without any text open, you should be able to reproduce the bug reliably with Java 6 running. I even was able to reproduce the bug this way with 4.3.1, so it was no change in jEdit, it was just not discovered yet.
The only difference I see between the Java 5 and Java 6 version of GlyphLayout is that the cache field is volatile in Java 6. In Java 5 the cache is null if I break jEdit with leak and look at the variable. In Java 6 cache is set to the old GlyphLayout.
One solution to this would be to call sun.font.GlyphLayout.get(null); after layoutGlyphVector() in Chunk:494, which will cause cache to be set to null and as we don't reference it, it can be garbage-collected.
Though we 1. would use a sun. class which is not recommended and can break with any Java update without prior notice and 2. we would thereby disable the mechanism to reuse GlyphLayout instances for saving memory and performance.
Is there maybe a better option?
Do we really need to "fix" this?
Maybe we should look if this is reported as leak already and if not report it as major leak. It would e. g. be sufficient in GlyphLayout.done(GlyphLayout) to clear the char[] in the TextRecord.

Regards
Vampire


Matthieu Casanova schrieb:
I'll try tomorow, I don't remember if the font substitution is active but it is possible since I tried the option. In fact the leak is strange, it doesn't seems to grow. When I open a big file then close it, my jEdit grow to 180/190MB, but if I open any other file including big files it doesn't grow anymore like if the JVM was keeping a cache of fonts, that's very strange Matthieu 2010/3/31 Marcelo Vanzin <vanza <at> users.sourceforge.net>:
On Wed, Mar 31, 2010 at 2:37 AM, Matthieu Casanova <chocolat.mou <at> gmail.com> wrote:
so there may be a bug in Sun's JDK 1.6 if it doesn't happens with Java 1.5 (I also tried with open-jdk 1.6 and have the same problem). If I'm not wrong there was a change about fonts in the TextArea between 4.3.x and 4.4 isn't it ? maybe this made the bug appear ?
I changed something in that area but the feature is off by default. Can you check if you have it enabled? (It's the "font substitution" stuff in the TextArea pane.) Although I'm using trunk with that option enabled, on Java 1.6, and haven't noticed any leaks, but then I'm not opening huge files. -- Marcelo Vanzin mmvgroups <at> gmail.com "Life's too short to drink cheap beer." ------------------------------------------------------------------------------ Download Intel&#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ----------------------------------------------- jEdit Developers' List jEdit-devel <at> lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jedit-devel
------------------------------------------------------------------------------ Download Intel&#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel
Vampire (jEdit | 1 Apr 02:06 2010
Picon
Picon

Re: Request for Comment : Using cross-platform single installer for JEdit

HI Siegfried,

as we already have free FOSS license of JProfiler from ej-tech, I know 
they give out free licences.
While their tool maybe is nice, I don't see much of a need to use it. 
Besides the point Matthieu mentioned.
What I still don't get is your point. We have a cross-platform single 
installer for jEdit. This is the Java-based installer. It can be used on 
any platform where Java is supported which is a pre-requisite to using 
jEdit anyway. This installer is highly custom and does exactly what is 
needed for jEdit.
The platform dependent installers for Mac and Windows and the Repository 
for Debian are mainly just for convenience, as Windows users usually 
prefer an EXE installer and Mac users like internet-enabled DMG files 
like we provide them, which you can just download and double-click which 
causes them to unpack the Application Bundle on the desktop and moves 
the DMG to the trash automatically. I don't think Install4J or IZPack 
could provide any of this. To be honest, I never personally used the 
Java based installer. On my Windows machines I prefer using the EXE 
installer. On my Ubuntu machines I prefer using the Debian repository 
where I get all updates immediately and semi-automatically pushed 
without the need to check if there is an update.
Why do you care about being able to build the windows installer on your 
Mac at all? It is only important that I am able to build it as I create 
the releases. I bet it would even be possible to use wine on Mac OS X to 
create the windows installer.

Siegfried Goeschl schrieb:
> Hi folks,
>
> I contributed a Windows native application launcher (based on launch4j) 
> for JEdit a while ago and exchanged a few emails with Eric Berry and 
> Kazutoshi Satoda. AFAIK the launcher works but we need to add it to the 
> Inno Setup installer which is a Windows app - ouch, no Windows box 
> anywhere near ... :-)  ... so a java-based installer would be really 
> cool in order to create the windows installer on Mac OS (as in my case).
>
> Okay, so I followed two options
>
> +) using the free IZPack installer which looks good (but I have never 
> used it)
>
> +) using a commercial installer such as install4j (which I used for a 
> couple of years)
>
> At that point I was wondering if ej-technologies (the company behind 
> install4j) would provide a free license for open-source projects and 
> decided that I could ask them directly - and yes they would be 
> interested in it assuming that this donation is somehow visible on the 
> web site and/or blog
>
> Using install4j would have a few advantages such as
>
> +) native application launchers for Windows, Linux and Mac are supplied 
> out-of-the-box
>
> +) install4j also provides shell and rpm based installers
>
> +) install4j comes with Ant integration
>
> +) install4j supports building the installers cross-platform, i.e. I'm 
> creating all my installers on Mac OS
>
> Having said that
>
> +) I asked as a private person and did not mention any project since I 
> have no JEdit hat
>
> +) I'm in no way affiliated with ej-technologies
>
> +) would it be acceptable for the community to rely on free but 
> commercial tools? It is perfectly okay for some projects (as in Apache 
> land for IntelliJ or JIRA) but might be a no-go for other projects
>
> Thanks in advance,
>
> Siegfried Goeschl
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
>   

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel

Marcelo Vanzin | 1 Apr 04:59 2010
Picon
Picon

Re: Memory leak in jEdit ?

On Wed, Mar 31, 2010 at 4:52 PM, Vampire (jEdit) <Vampire0 <at> gmx.net> wrote:
> But I found out how to reliably reproduce the problem and also that we
> possibly don't have a problematic leak here because it is very short-living.
> JProfiler tells me the allocation of that char[] was done in
...

If that's the case, then I don't think there's anything that needs to be done.

-- 
Marcelo Vanzin
mmvgroups <at> gmail.com
"Life's too short to drink cheap beer."

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel

Matthieu Casanova | 1 Apr 10:44 2010
Picon

Re: Memory leak in jEdit ?

Hi, that's well done, another idea : instead of calling
sun.font.GlyphLayout.get(null) after calling layoutGlyphVector in the
Chunk cache, we could call this just before calling System.gc() in the
showMemoryDialog(), or in the end of TokenMarker.markTokens() so we
would not call this too often ?

Matthieu

2010/4/1 Vampire (jEdit) <Vampire0 <at> gmx.net>:
> For me the font substitution doesn't make any difference. The error happens
> with and without the option being active.
> But I found out how to reliably reproduce the problem and also that we
> possibly don't have a problematic leak here because it is very short-living.
> JProfiler tells me the allocation of that char[] was done in
> org.gjt.sp.util.SegmentBuffer.ensureCapacity() with one allocation.
> The reference hold to it is in sun.font.GlyphLayout though.
> To be concrete, the char[] is still available in an instance of
> sun.font.TextRecord.
> This TextRecord is an instance variable of a GlyphLayout.
> The GlyphLayout in question is referenced as static field "cache" in class
> GlyphLayout.
> If someone calls GlyphLayout.done(GlyphLayout) the given GlyphLayout is
> referenced as cache and the next time someone calls
> GlyphLayout.get(LayoutEngineFactory) this cached GlyphLayout is returned and
> reused and the cache reference is set to null.
> Actually org.gjt.sp.jedit.syntax.Chunk.addGlyphVector(Font,
> FontRenderContext, char[], int, int) calls
> java.awt.Font.layoutGlyphVector(FontRenderContext, char[], int, int, int)
> which in turn first calls GlyphVector.get(null), then layouts the glyphs
> with GlyphVector.layout(...) and then calls GlyphLayout.done(GlyphLayout)
> which causes that GlyphLayout to be stored in the cache reference.
> This means, as soon as some other text is displayed, the memory is freed as
> the TextRecord then has the contents of the next file.
> So if you have some buffer open with text in it, you will not notice any
> memory leak as the GlyphLayout is reused as soon as you display some other
> text. If you have only Untitled-1 without any text open, you should be able
> to reproduce the bug reliably with Java 6 running. I even was able to
> reproduce the bug this way with 4.3.1, so it was no change in jEdit, it was
> just not discovered yet.
> The only difference I see between the Java 5 and Java 6 version of
> GlyphLayout is that the cache field is volatile in Java 6. In Java 5 the
> cache is null if I break jEdit with leak and look at the variable. In Java 6
> cache is set to the old GlyphLayout.
> One solution to this would be to call sun.font.GlyphLayout.get(null); after
> layoutGlyphVector() in Chunk:494, which will cause cache to be set to null
> and as we don't reference it, it can be garbage-collected.
> Though we 1. would use a sun. class which is not recommended and can break
> with any Java update without prior notice and 2. we would thereby disable
> the mechanism to reuse GlyphLayout instances for saving memory and
> performance.
> Is there maybe a better option?
> Do we really need to "fix" this?
> Maybe we should look if this is reported as leak already and if not report
> it as major leak. It would e. g. be sufficient in
> GlyphLayout.done(GlyphLayout) to clear the char[] in the TextRecord.
>
> Regards
> Vampire
>
>
> Matthieu Casanova schrieb:
>
> I'll try tomorow, I don't remember if the font substitution is active
> but it is possible since I tried the option.
> In fact the leak is strange, it doesn't seems to grow. When I open a
> big file then close it, my jEdit grow to 180/190MB, but if I open any
> other file including big files it doesn't grow anymore like if the JVM
> was keeping a cache of fonts, that's very strange
>
> Matthieu
>
> 2010/3/31 Marcelo Vanzin <vanza <at> users.sourceforge.net>:
>
>
> On Wed, Mar 31, 2010 at 2:37 AM, Matthieu Casanova
> <chocolat.mou <at> gmail.com> wrote:
>
>
> so there may be a bug in Sun's JDK 1.6 if it doesn't happens with Java
> 1.5 (I also tried with open-jdk 1.6 and have the same problem).
> If I'm not wrong there was a change about fonts in the TextArea
> between 4.3.x and 4.4 isn't it ? maybe this made the bug appear ?
>
>
> I changed something in that area but the feature is off by default.
> Can you check if you have it enabled? (It's the "font substitution"
> stuff in the TextArea pane.)
>
> Although I'm using trunk with that option enabled, on Java 1.6, and
> haven't noticed any leaks, but then I'm not opening huge files.
>
> --
> Marcelo Vanzin
> mmvgroups <at> gmail.com
> "Life's too short to drink cheap beer."
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> --
> -----------------------------------------------
> jEdit Developers' List
> jEdit-devel <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
>

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel

SourceForge.net | 1 Apr 12:46 2010
Picon
Picon

[ jedit-Plugin Bugs-2976642 ] CtagsSidekick - mode-specific options pane

Plugin Bugs item #2976642, was opened at 2010-03-25 20:48
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2976642&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Robert Schwenn (rschwenn)
>Assigned to: Shlomy Reinstein (shlomy)
Summary: CtagsSidekick - mode-specific options pane

Initial Comment:
In the mode-specific options pane of CtagsSidekick all fields are deactivated for "<Global Standards>".

CtagsSidekick 1.4
jEdit 4.3.1
SUN JRE 1.6.0_18

----------------------------------------------------------------------

>Comment By: Shlomy Reinstein (shlomy)
Date: 2010-04-01 13:46

Message:
Fixed in SVN 17566 (in SideKick).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2976642&group_id=588

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel

SourceForge.net | 1 Apr 12:55 2010
Picon
Picon

[ jedit-Plugin Bugs-2974842 ] CtagsInterface NullPointerException

Plugin Bugs item #2974842, was opened at 2010-03-22 23:03
Message generated for change (Comment added) made by shlomy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2974842&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: aftermidnight (aftermidnight)
Assigned to: Nobody/Anonymous (nobody)
Summary: CtagsInterface NullPointerException

Initial Comment:
on ubuntu jaunty, i downloaded and installed the jar file for jedit 4.3.1.
then, using the jedit plugin manager, i installed about a dozen plugins.

i made a small project, using the Project Viewer plugin.
i installed the latest exuberant-ctags and made a ctags file.
when i chose Plugins / CtagsInterface / Add tag file and gave
the full pathname of my ctags file, i got this beanshell error:

java.lang.NullPointerException
	at ctagsinterface.main.CtagsInterfacePlugin.addTempTagFile(CtagsInterfacePlugin.java:178)
	at ctagsinterface.main.CtagsInterfacePlugin.addTagFile(CtagsInterfacePlugin.java:186)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.gjt.sp.jedit.bsh.Reflect.invokeMethod(Reflect.java:134)
	at org.gjt.sp.jedit.bsh.Reflect.invokeStaticMethod(Reflect.java:98)
	at org.gjt.sp.jedit.bsh.Name.invokeMethod(Name.java:871)
	at org.gjt.sp.jedit.bsh.BSHMethodInvocation.eval(BSHMethodInvocation.java:75)
	at org.gjt.sp.jedit.bsh.BSHPrimaryExpression.eval(BSHPrimaryExpression.java:102)
	at org.gjt.sp.jedit.bsh.BSHPrimaryExpression.eval(BSHPrimaryExpression.java:47)
	at org.gjt.sp.jedit.bsh.BSHBlock.evalBlock(BSHBlock.java:130)
	at org.gjt.sp.jedit.bsh.BSHBlock.eval(BSHBlock.java:80)
	at org.gjt.sp.jedit.bsh.BshMethod.invokeImpl(BshMethod.java:362)
	at org.gjt.sp.jedit.bsh.BshMethod.invoke(BshMethod.java:258)
	at org.gjt.sp.jedit.bsh.BshMethod.invoke(BshMethod.java:186)
	at org.gjt.sp.jedit.BeanShellFacade.runCachedBlock(BeanShellFacade.java:225)
	at org.gjt.sp.jedit.BeanShell.runCachedBlock(BeanShell.java:423)
	at org.gjt.sp.jedit.BeanShellAction.invoke(BeanShellAction.java:73)
	at org.gjt.sp.jedit.gui.InputHandler.invokeAction(InputHandler.java:352)
	at org.gjt.sp.jedit.jEdit$4.invokeAction(jEdit.java:3255)
	at org.gjt.sp.jedit.jEdit$4.invokeAction(jEdit.java:3237)
	at org.gjt.sp.jedit.EditAction$Wrapper.actionPerformed(EditAction.java:221)
	at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
	at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
	at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
	at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
	at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
	at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1225)
	at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1266)
	at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:272)
	at java.awt.Component.processMouseEvent(Component.java:6263)
	at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
	at java.awt.Component.processEvent(Component.java:6028)
	at java.awt.Container.processEvent(Container.java:2041)
	at java.awt.Component.dispatchEventImpl(Component.java:4630)
	at java.awt.Container.dispatchEventImpl(Container.java:2099)
	at java.awt.Component.dispatchEvent(Component.java:4460)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4574)
	at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4238)
	at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168)
	at java.awt.Container.dispatchEventImpl(Container.java:2085)
	at java.awt.Window.dispatchEventImpl(Window.java:2475)
	at java.awt.Component.dispatchEvent(Component.java:4460)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

i also get NullPointerExceptions when i choose Plugins/PluginOptions/CtagsInterface/SourceTrees or Projects.

----------------------------------------------------------------------

>Comment By: Shlomy Reinstein (shlomy)
Date: 2010-04-01 13:55

Message:
This exception is caused by a mis-configured tag database. Did you use the
"Change database settings" menu item of CtagsInterface? If you did, you
probably set some incorrect parameters in that dialog. If you didn't, it
probably means that there's a problem with the default configuration, which
is very unlikely.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=2974842&group_id=588

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel

SourceForge.net | 1 Apr 18:19 2010
Picon
Picon

[ jedit-Plugin Patches-2980620 ] JavaSideKick patch

Plugin Patches item #2980620, was opened at 2010-04-01 11:19
Message generated for change (Tracker Item Submitted) made by kog13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997937&aid=2980620&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Damien (kog13)
Assigned to: Nobody/Anonymous (nobody)
Summary: JavaSideKick patch

Initial Comment:
This patch makes a number of improvements:

- Completion resolves implicit types (e.g. StringBuffer append() method)
- Completing a classname followed by "(" displays its constructors
- Completing after a classname (with no "." or "(") completes available packages
- Classes with more than one package, unless a specific import
  or full class name is used, displays an "ambiguous class" error
- Methods list their parameters and return type, and fields display their type
- If SuperAbbrevs is installed, completing a method with parameters uses the plugin
  to insert the completion with each parameter highlighted
- Project-specific settings are saved in the project's properties, rather than jEdit's
- Entries added to or removed from the project's classpath are now updated correctly
- Basic casting is enabled
- Removed actions.xml (it's not used)

This patch does nothing to the documentation, however, which should be updated before an update is released.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997937&aid=2980620&group_id=588

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel

SourceForge.net | 1 Apr 18:21 2010
Picon
Picon

[ jedit-Plugin Patches-2946337 ] AntFarm: remove dockable dependency

Plugin Patches item #2946337, was opened at 2010-02-04 21:52
Message generated for change (Settings changed) made by kog13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997937&aid=2946337&group_id=588

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Damien (kog13)
Assigned to: Damien (kog13)
Summary: AntFarm: remove dockable dependency

Initial Comment:
It is not possible to run commands through the Ant shell (provided by AntFarm) without the AntFarm dockable
window popping up, and after some investigation I discovered it's because the "parseBuildFile" method
belonged to the dockable's class. The parse build file action is in no way dependent on the dockable being
visible, so this patch moves that method from AntFarm to AntFarmPlugin so that other plugins may parse
build files through the Ant shell without requiring that the AntFarm window be visible.

This patch also removes the ProjectBridge class as it used outdated PV api, and was impossible to compile
with it included. It also appeared that the only reference to that class in the plugin was in a
commented-out line, so it wasn't even used despite its inclusion.

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2010-02-04 22:06

Message:
Ok, I added you to the project, now you have svn access. And I am assigning
this ticket to you.
Welcome to the team! let me know when you want me to test AntFarm.

----------------------------------------------------------------------

Comment By: Damien (kog13)
Date: 2010-02-04 22:01

Message:
Sure. If that's the case, I'll probably make a few other changes based on
other ideas I have for the plugin, and if everyone is okay with them, I'll
go ahead and commit it.

----------------------------------------------------------------------

Comment By: Alan Ezust (ezust)
Date: 2010-02-04 21:56

Message:
There is no maintainer for antfarm. Would you like to commit your changes
directly and prepare antfarm for release at some point?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=997937&aid=2946337&group_id=588

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel

Siegfried Goeschl | 1 Apr 18:44 2010
Picon
Picon

Re: Request for Comment : Using cross-platform single installer for JEdit

Hi Björn,

let's recap the story

+) last year I worked on Windows box and contributed a native 
application launcher for JEdit based on launch4j (aka jedit.exe). Having 
a Windows executable is quite handy for a Window user ...

+) last week the patch was tested but the question popped up how to add 
the "jedit.exe" to the existing Inno Setup Windows installer - mhmm, no 
Windows box around.

+) in my company it is perfectly normal to make a release build on a Mac 
(when I work remotely) or on a Windows box (office) in order to create 
the required installers (foo_linux.rpm, foo_macos.dmg, foo_unix.sh, 
foo_unix.tar.gz, foo_windows.exe). I'm then using various images to 
check that the released software works on the different target 
platforms. This is done using install4j and I generate all the 
installers using a single install4j project using Ant (without tinkering 
with launch4j, JavaApplicationStub and/or various shell scripts)

+) so I asked the JEdit community who to proceed from here - leaving the 
things as they are or looking at different installer software (free or 
commercial) to improve the build process

So far so good - based on the feedback there is not much I can do ...

Having said that I asked a similar question within the ASF

+) Daniel Lopez replied that Bitrock would also a free licence for their 
product (http://installbuilder.bitrock.com). I have not used it but it 
supports Debian packages out-of-the-box

Cheers,

Siegfried Goeschl

On 01.04.10 02:06, Vampire (jEdit) wrote:
> HI Siegfried,
>
> as we already have free FOSS license of JProfiler from ej-tech, I know
> they give out free licences.
> While their tool maybe is nice, I don't see much of a need to use it.
> Besides the point Matthieu mentioned.
> What I still don't get is your point. We have a cross-platform single
> installer for jEdit. This is the Java-based installer. It can be used on
> any platform where Java is supported which is a pre-requisite to using
> jEdit anyway. This installer is highly custom and does exactly what is
> needed for jEdit.
> The platform dependent installers for Mac and Windows and the Repository
> for Debian are mainly just for convenience, as Windows users usually
> prefer an EXE installer and Mac users like internet-enabled DMG files
> like we provide them, which you can just download and double-click which
> causes them to unpack the Application Bundle on the desktop and moves
> the DMG to the trash automatically. I don't think Install4J or IZPack
> could provide any of this. To be honest, I never personally used the
> Java based installer. On my Windows machines I prefer using the EXE
> installer. On my Ubuntu machines I prefer using the Debian repository
> where I get all updates immediately and semi-automatically pushed
> without the need to check if there is an update.
> Why do you care about being able to build the windows installer on your
> Mac at all? It is only important that I am able to build it as I create
> the releases. I bet it would even be possible to use wine on Mac OS X to
> create the windows installer.
>
> Siegfried Goeschl schrieb:
>> Hi folks,
>>
>> I contributed a Windows native application launcher (based on
>> launch4j) for JEdit a while ago and exchanged a few emails with Eric
>> Berry and Kazutoshi Satoda. AFAIK the launcher works but we need to
>> add it to the Inno Setup installer which is a Windows app - ouch, no
>> Windows box anywhere near ... :-) ... so a java-based installer would
>> be really cool in order to create the windows installer on Mac OS (as
>> in my case).
>>
>> Okay, so I followed two options
>>
>> +) using the free IZPack installer which looks good (but I have never
>> used it)
>>
>> +) using a commercial installer such as install4j (which I used for a
>> couple of years)
>>
>> At that point I was wondering if ej-technologies (the company behind
>> install4j) would provide a free license for open-source projects and
>> decided that I could ask them directly - and yes they would be
>> interested in it assuming that this donation is somehow visible on the
>> web site and/or blog
>>
>> Using install4j would have a few advantages such as
>>
>> +) native application launchers for Windows, Linux and Mac are
>> supplied out-of-the-box
>>
>> +) install4j also provides shell and rpm based installers
>>
>> +) install4j comes with Ant integration
>>
>> +) install4j supports building the installers cross-platform, i.e. I'm
>> creating all my installers on Mac OS
>>
>> Having said that
>>
>> +) I asked as a private person and did not mention any project since I
>> have no JEdit hat
>>
>> +) I'm in no way affiliated with ej-technologies
>>
>> +) would it be acceptable for the community to rely on free but
>> commercial tools? It is perfectly okay for some projects (as in Apache
>> land for IntelliJ or JIRA) but might be a no-go for other projects
>>
>> Thanks in advance,
>>
>> Siegfried Goeschl
>>
>> ------------------------------------------------------------------------------
>>
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel

Alan Ezust | 1 Apr 19:59 2010
Picon

Re: Memory leak in jEdit ?

I think the issue is whether to call it anywhere at all, and use the
"sun." API in the jEdit code.
If we can put it into the code in such a way that it doesn't break on
other platforms, that would be nice.
If you do it with reflection so it doesn't require it in the API, make it so!

On Thu, Apr 1, 2010 at 1:44 AM, Matthieu Casanova
<chocolat.mou <at> gmail.com> wrote:
> Hi, that's well done, another idea : instead of calling
> sun.font.GlyphLayout.get(null) after calling layoutGlyphVector in the
> Chunk cache, we could call this just before calling System.gc() in the
> showMemoryDialog(), or in the end of TokenMarker.markTokens() so we
> would not call this too often ?
>

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel


Gmane