Alan Ezust | 1 Jun 04:23 2012
Picon

unnecessary option: "backup on every save?"

I don't understand the point of this checkbox. It doesn't do
anything. If I un-check it, I still get backups unless I also set the
max number of backups to 0.
So what is the point of having the checkbox?

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
--

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

Alan Ezust | 1 Jun 04:53 2012
Picon

updaterplugin via ivy

I am trying to modify jedit's ivy.xml so that it brings in common
controls and updater plugin.
CommonControls worked fine. i can't get ivy  to find updater plugin
though. I tried both of these lines:

		<dependency org="org.jedit.plugins" name="UpdaterPlugin" rev="0.3"
conf="default-plugins" />
		<dependency org="org.jedit.plugins" name="Updater" rev="0.3"
conf="default-plugins" />

Actually, the problem might be that it is called "Updater.jar" but it
is in "UpdaterPlugin-0.3"

Help?

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
--

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

Kazutoshi Satoda | 1 Jun 04:58 2012
Picon

Re: [ jedit-Feature Requests-3529923 ] Option to disable Undo for search&replace-all operations

Hi Thomas,

> here some numbers and results based on attached prototype patch:
>
> 10.000 lines (2.260.000 changes "," -> ", ")
> ...: Call= 1 DiffTime=13.148.368.127 DiffUsedMem= 6.111.360   - Drop Undo
> ...: Call= 2 DiffTime=8.980.303.341  DiffUsedMem= 372.544.648 - Keep Undo
> ...: Call= 3 DiffTime=3.660.864.354  DiffUsedMem= 20.112.424  - Drop Undo
> ...: Call= 4 DiffTime=4.553.024.598  DiffUsedMem= 360.235.976 - Keep Undo

Thank you for the measure.

Here are some requests to make the answers for my previous questions:

Could you please show the code of measure so that others (including me)
can do measures as they like? It may fulfills the answers for the
following requests.

Could you please take measures for 1, 10, 100, 1000 lines? It will show
some answers for "worse than O(N)" suspicion.

What is the unit of DiffTime and DiffUsedMem? I can assume bytes for
DiffUsedMem. But DiffTime seems too short a bit with ns and too long
with us.

> 50.000 lines (11.300.000 changes "," -> ", ")
> ...: Call= 5 DiffTime=37.807.525.594 DiffUsedMem= 47.003.104  - Drop Undo
> ...: Call= 6 DiffTime=31.706.368.273 DiffUsedMem= 46.073.128  - Drop Undo
>
> 10.000 lines (2.260.000 changes "," -> ", ")
(Continue reading)

Jarek Czekalski | 1 Jun 07:50 2012
Picon

Re: [ jedit-Feature Requests-3529923 ] Option to disable Undo for search&replace-all operations

W dniu 2012-05-31 21:49, SourceForge.net pisze:
>> Comment By: Thomas Meyer (thomasmey)
> Date: 2012-05-31 12:49
>
> Message:
> Hello,
>
> here some numbers and results based on attached prototype patch:
>
> 10.000 lines (2.260.000 changes "," ->  ", ")
> 21:10:30 [AWT-EventQueue-0] [debug] AWT-EventQueue-0: Call= 1
> DiffTime=13.148.368.127 DiffUsedMem= 6.111.360   - Drop Undo
Besides Kazutoshi's remarks I have one. Absolute readings are almost 
useless themselves. We also need something to compare to, so percentage 
diffs would also be desired. If 13 s means 100 instead of 113, then the 
gain is not very significant.

Jarek

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
--

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

Jarek Czekalski | 1 Jun 07:57 2012
Picon

Re: unnecessary option: "backup on every save?"

Probably there are also other circumstances that trigger the backup, but 
not on every save. And I don't remember what are they. If this is not 
documented, it may be worth to have a bug report for that.

Jarek

W dniu 2012-06-01 04:23, Alan Ezust pisze:
> I don't understand the point of this checkbox. It doesn't do
> anything. If I un-check it, I still get backups unless I also set the
> max number of backups to 0.
> So what is the point of having the checkbox?
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
--

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

Jarek Czekalski | 1 Jun 08:03 2012
Picon

Re: updaterplugin via ivy

Alan, you may try to download the whole zip using syntax from 
ivy.plugin.deps.template.xml file from build-support. It goes like this:

<dependency org="jedit-plugins-zip" name="ErrorList" rev="1.9"/>

Then zip must be unzipped using one of the ant tasks.

If you wish to have a dedicated task for this, I can implement it. I was 
doing such things, because I managed to perform automatic download of 
dependency plugins based on the properties file. Downloading only the 
plugin jar is not enough if you want a runtime version, with other files 
that are in plugin zip.

Jarek

W dniu 2012-06-01 04:53, Alan Ezust pisze:
> I am trying to modify jedit's ivy.xml so that it brings in common
> controls and updater plugin.
> CommonControls worked fine. i can't get ivy  to find updater plugin
> though. I tried both of these lines:
>
> 		<dependency org="org.jedit.plugins" name="UpdaterPlugin" rev="0.3"
> conf="default-plugins" />
> 		<dependency org="org.jedit.plugins" name="Updater" rev="0.3"
> conf="default-plugins" />
>
> Actually, the problem might be that it is called "Updater.jar" but it
> is in "UpdaterPlugin-0.3"
>
> Help?
(Continue reading)

Matthieu Casanova | 1 Jun 09:02 2012
Picon

Re: [ jEdit-commits ] SF.net SVN: jedit:[21739] jEdit/trunk

In fact I don't see any reason to keep some lists or compare anything. If the rule that says that the write lock can only be took by EDT, and the invokeAndWait cannot be called when having any lock, I think this solve any case, don't you ?

2012/5/31 Jarek Czekalski <jarekczek <at> poczta.onet.pl>
W dniu 05/31/2012 05:23 PM, Matthieu Casanova pisze:
I find that it is strange, in that case you will or will not be able to do what you need according to an id on which you have no control.
You are allowed to use smarter means. Like that:

ArrayList<Buffer> bufs = new ...
bufs.add(...)
bufs.add(...)
bufs = Collections.sort(bufs);
for (b: bufs) b.readLock();

I'm not sure this compiles, but that's an idea. Thanks to compareTo you may use sort, that's the clue.

Jarek



2012/5/31 Jarek Czekalski <jarekczek <at> poczta.onet.pl>
W dniu 2012-05-31 17:13, Matthieu Casanova pisze:
I'm not sure I understood well that order idea:

every buffer has a unique id, and it is only possible to acquire a lock if the lock I already own is on a buffer with a lower id ?

2012/5/31 <jarekczek <at> users.sourceforge.net>
Revision: 21739
         http://jedit.svn.sourceforge.net/jedit/?rev=21739&view=rev
Author:   jarekczek
+ * <li>When acquiring more than 1 buffer lock, it must be done in increasing
+ *     order determined by <code>compareTo</code>.

Yes. Otherwise you need to unlock and lock again in correct order. Or tryLock.

buf1.readLock();
if (buf2.compareTo(buf1) < 0)
  throw new LockNotPossible();
assert(buf2.compareTo(buf1) > 0);
buf2.readLock();

Jarek



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel
Jarek Czekalski | 1 Jun 09:56 2012
Picon

Re: [ jEdit-commits ] SF.net SVN: jedit:[21739] jEdit/trunk

No, Matthieu. When you reply and quote someone, it means you read it, doesn't it? Please see this:

http://jedit.9.n6.nabble.com/jEdit-devel-dealing-with-deadlocks-in-jedit-avoid-them-tp4998871p4998906.html

If you have remarks regarding avoiding deadlocks, please continue in the above thread, not this one.

Jarek

W dniu 2012-06-01 09:02, Matthieu Casanova pisze:
In fact I don't see any reason to keep some lists or compare anything. If the rule that says that the write lock can only be took by EDT, and the invokeAndWait cannot be called when having any lock, I think this solve any case, don't you ?

2012/5/31 Jarek Czekalski <jarekczek <at> poczta.onet.pl>
W dniu 05/31/2012 05:23 PM, Matthieu Casanova pisze:
I find that it is strange, in that case you will or will not be able to do what you need according to an id on which you have no control.
You are allowed to use smarter means. Like that:

ArrayList<Buffer> bufs = new ...
bufs.add(...)
bufs.add(...)
bufs = Collections.sort(bufs);
for (b: bufs) b.readLock();

I'm not sure this compiles, but that's an idea. Thanks to compareTo you may use sort, that's the clue.

Jarek



2012/5/31 Jarek Czekalski <jarekczek <at> poczta.onet.pl>
W dniu 2012-05-31 17:13, Matthieu Casanova pisze:
I'm not sure I understood well that order idea:

every buffer has a unique id, and it is only possible to acquire a lock if the lock I already own is on a buffer with a lower id ?

2012/5/31 <jarekczek <at> users.sourceforge.net>
Revision: 21739
         http://jedit.svn.sourceforge.net/jedit/?rev=21739&view=rev
Author:   jarekczek
+ * <li>When acquiring more than 1 buffer lock, it must be done in increasing
+ *     order determined by <code>compareTo</code>.

Yes. Otherwise you need to unlock and lock again in correct order. Or tryLock.

buf1.readLock();
if (buf2.compareTo(buf1) < 0)
  throw new LockNotPossible();
assert(buf2.compareTo(buf1) > 0);
buf2.readLock();

Jarek



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
--

-- 
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel
SourceForge.net | 1 Jun 10:08 2012
Picon
Picon

[ jedit-Merge Requests-3516540 ] php highlight simplification

Merge Requests item #3516540, was opened at 2012-04-10 08:55
Message generated for change (Comment added) made by kpouer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1235750&aid=3516540&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: for 4.5.x
>Status: Closed
Resolution: Rejected
Priority: 5
Private: No
Submitted By: Matthieu Casanova (kpouer)
Assigned to: Nobody/Anonymous (nobody)
Summary: php highlight simplification

Initial Comment:
These are not very important bugs, so since the changes are important I'm not sure it is worth merging them.
The most important bug is probably #1813839 fixed by rev 20808

Do not highlight php code in phpdoc
20808 (fix bugs #1803310, #3029383, #3316733), also probably fix bug #1813839

20809 (fix bug #2985508)
20810 (fix bug #3151072)

http://jedit.svn.sourceforge.net/jedit/?rev=20808&view=rev
http://jedit.svn.sourceforge.net/jedit/?rev=20809&view=rev
http://jedit.svn.sourceforge.net/jedit/?rev=20810&view=rev

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

>Comment By: Matthieu Casanova (kpouer)
Date: 2012-06-01 01:08

Message:
I was also not sure as it changes a lot of things, in that case let's close
it.

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

Comment By: Alan Ezust (ezust)
Date: 2012-05-31 11:18

Message:
Normally mode fixes don't go into merge requests. I am not sure if I should
accept this.

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

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
--

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

Matthieu Casanova | 1 Jun 10:18 2012
Picon

Re: dealing with deadlocks in jedit - avoid them

So, let's continue this conversation:


The rule that everyone agreed is (correct me if you don't agree) :
only EDT can aquire a write lock
invokeAndWait cannot be called when the current thread has a lock (read lock since the current thread is not EDT)

But that's not enough because of your previous example

1. T1 acquires read lock for A
2. T2 enters EDT and acquires write lock for B
3. T1 wants read lock for B, T2 wants write lock for A

In that case we could add another rule: only one write lock can be aquired at the same time. I think it would solve that case.
Would it be acceptable ?

Another thing: I think that all those rules do not apply to temporary buffers, since those buffers are not in the buffer list and not displayable, they are not shared by different threads.

2012/5/30 Matthieu Casanova <chocolat.mou <at> gmail.com>
Hi, I think I agree, a thread must not enter EDT when having a lock, and write lock must only be took in EDT thread.
Maybe to help debugging a new constant like Debug.BUFFER_WRITE_LOCK_DEBUG could be added, and when activated the thread would be tested in JEditBuffer.writeLock(), and if it is not EDT an exception is thrown (like Substance look & feel does when you change the UI in the wrong thread)


2012/5/30 Jarek Czekalski <jarekczek <at> poczta.onet.pl>
So I was wrong in 2 things, thank you Matthieu and Kazutoshi for
correcting me. This however doesn't change the general idea, because the
deadlock is still possible regarding buffer locks.

1. T1 acquires read lock for A
2. T2 enters EDT and acquires write lock for B
3. T1 wants read lock for B, T2 wants write lock for A

We must have a rule to make this situation forbidden. Sorting of buffers
cuts it. I think what Przemek suggested is quite right, but it will be
simpler using AtomicInteger.

Przemek, your understanding of getting locks after entering EDT is same
as mine. As Kazutoshi pointed, it is already documented that insert,
which contains writeLock, must be called from EDT. So it only confirms
that such a rule should be published: a thread must not enter EDT, if it
possesses a buffer lock.

If there are no objections, I'll assemble these rules into wiki and javadoc.

Jarek

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
--
-----------------------------------------------
jEdit Developers' List
jEdit-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jedit-devel


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
--

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

Gmane