IRC Archive for channel #xwiki

Last modified by Vincent Massol on 2012/10/18 19:12

penyaskito_ joined #xwiki at 00:30
penyaskito left at 00:33 (Ping timeout: 252 seconds
jvelociter left at 00:38 (Quit: jvelociter
sdumitriu left at 02:22 (Ping timeout: 260 seconds
jvelociter joined #xwiki at 02:39
abusenius left at 03:15 (Ping timeout: 258 seconds
SvenDowideit left at 04:07 (Ping timeout: 240 seconds
SvenDowideit joined #xwiki at 04:08
silviar joined #xwiki at 08:40
kibahop joined #xwiki at 08:41
kibahop left #xwiki at 08:41
tmortagne joined #xwiki at 08:49
sdumitriu joined #xwiki at 09:08
silviar left at 09:46 (Quit: Leaving.
silviar joined #xwiki at 09:52
asrfel joined #xwiki at 09:54
tmortagne left at 10:02 (Quit: Leaving.
tmortagne joined #xwiki at 10:03
sburjan joined #xwiki at 10:08
abusenius joined #xwiki at 10:21
cjdelisle - (10:34): while [ 1 -eq 1 ]; do top -b -n1 | sed -n -e '8,8 p' >> top.hogs; sleep 1; done;
cjdelisle - (10:34): fix that sneaky process that kills my music with 100% cpu for 5 seconds then hides everytime I'm looking at top.
jbrBridge left at 10:42 (Ping timeout: 265 seconds
jbrBridge joined #xwiki at 10:43
fmancinelli joined #xwiki at 10:43
abusenius - (10:43): cjdelisle: hi, so what was your idea for a test?
cjdelisle - (10:44): Look for double escaped characters.
abusenius - (10:44): ah, ok, that's already on my todo list
cjdelisle - (10:45): We can't guarantee that there should never be & in a document but I think if it's in a test it should raise a flag.
abusenius - (10:45): yes, we could use the same approach to try all parameters, but look for url(url(test string))
abusenius - (10:46): s/url/xml/
abusenius - (10:46): (would double the number of tests)
cjdelisle - (10:48): only 25 days of uptime and I got processes freaking out. even killed the bridge.
abusenius - (10:48): btw, should I sens yet another proposal/vote before actually moving escaping tests? :)
cjdelisle - (10:48): maybe just a "heads up, committing".
abusenius - (10:49): yea, I'll answer to the last proposal
abusenius - (10:53): tmortagne: do you have some time?
tmortagne - (10:56): abusenius: not yet sorry, give me 1h max
nickless joined #xwiki at 10:56
jbrBridge left at 10:56 (Remote host closed the connection
jbrBridge joined #xwiki at 10:56
lucaa left at 10:57 (Ping timeout: 240 seconds
fmancinelli left at 10:58 (Ping timeout: 260 seconds
abusenius left at 10:58 (Ping timeout: 252 seconds
nickless is now known as abusenius ([email protected]
cjdelisle - (10:58): !shutdown
jbrBridge left at 10:58 (Remote host closed the connection
jbrBridge joined #xwiki at 10:59
fmancinelli joined #xwiki at 10:59
abusenius - (11:01): cjdelisle: do you mind closing http://jira.xwiki.org/jira/browse/XWIKI-4757? it should be fixed by now
cjdelisle - (11:02): ahh yes, whenever I assigned myself I found I couldn't close the issue either.
cjdelisle - (11:03): integration tested?
abusenius - (11:03): I'd say so
abusenius - (11:04): (escaping tests)
cjdelisle - (11:04): closed.
abusenius - (11:04): thx
cjdelisle - (11:05): just restarted and forked all processes which were running in terminal. Killed the last terminal and it took like 15sec and freed like 100M of memory.
abusenius - (11:07): :)
cjdelisle - (11:07): oh right. 20,000 line backscroll.
abusenius - (11:07): I also have an impression tht some programs leak memory after several days
cjdelisle - (11:08): evince.
cjdelisle - (11:08): firefox.
abusenius - (11:08): no, I tried restarting almost all of them
cjdelisle - (11:08): 1Gb swap space? wipe out all those pdfs.
abusenius - (11:08): it must be X or kwin or something like that
cjdelisle - (11:10): ff used to be bad. kill that and there goes 800M of ram and 500 of swap.
abusenius - (11:10): ff is not that bad for me, but eclipse also tends to eat all my memory
abusenius - (11:11): like now, 700M for displaying itself...
cjdelisle - (11:12): yea eclipse is huge. FF is much better now. I think it implements it's own "swap space" million tabs build up and like 200M of memory?
abusenius - (11:14): maybe, + add-ons (especially flash) need a lot
abusenius - (11:15): good that nowerdays it is possible to kill flash separately
tmortagne - (11:23): abusenius: back
abusenius - (11:23): cool
abusenius - (11:23): so, I was playing around with events
abusenius - (11:23): for refactoring abstract macro
abusenius - (11:24): seems to work so far
tmortagne - (11:24): ok cool
lucaa joined #xwiki at 11:24
abusenius - (11:24): now the question is, will 2 different events sent by the same thread be handled in the same thread if there is one listener?
abusenius - (11:25): I used threadlocal to store the original class loader
tmortagne - (11:26): events are always sent in the thread of the event caller
tmortagne - (11:26): also no need to use your own threadlocal
tmortagne - (11:26): use the context
tmortagne - (11:26): executioncontext
tmortagne - (11:26): it's here for that
abusenius - (11:26): good
abusenius - (11:26): ah, ok
abusenius - (11:27): I can upload the patch of the changes so far somewhere if you want to have a look
abusenius - (11:28): I basically moved class loader stuff and nested validator to listeners
abusenius - (11:28): and added 2 events, script execution starts and script execution finished
abusenius - (11:28): the first one is cancelable
tmortagne - (11:29): ok sounds good
abusenius - (11:29): I'd say validators can be removed, liteners are nicer
tmortagne - (11:30): yep i agree
tmortagne - (11:30): what do you send with the event starts event ?
tmortagne - (11:31): as datas i mean
tmortagne - (11:32): s/event starts event/script starts event/
abusenius - (11:32): context and macro parameters
abusenius - (11:32): (transformation context)
tmortagne - (11:32): context is useless
abusenius - (11:33): why?
tmortagne - (11:33): it's a bad thing that is done in old document events
tmortagne - (11:33): because context is already in threadcontext
tmortagne - (11:33): any component can access the context
abusenius - (11:33): ok, then it is not needed
tmortagne - (11:34): so we should not give it as parameter anymore since it was the goal
tmortagne - (11:34): to sumurize don't try to mimic document events
tmortagne - (11:34): do what make sense for you event
tmortagne - (11:35): i'm not sure about macro parameters
tmortagne - (11:35): it should maybe be something more generic
abusenius - (11:35): class loader code uses them to get the jars
tmortagne - (11:35): actually no forget that
tmortagne - (11:36): the validation needs macro informations anyway
tmortagne - (11:36): to get macro parents etc.
tmortagne - (11:37): so it's a macro specific event actually but it's ok I guess
abusenius - (11:37): if it stored in thread context, it could take it frome htere
tmortagne - (11:39): no it's difficult to know for the listener if it's a script executed by another script or really the content of the macro, i think we should keep it the way you did
tmortagne - (11:39): anyway there will be a discussion on the mailing list for it
abusenius - (11:39): ok
abusenius - (11:40): btw, why does onEvent have Object as data parameters and is not generic instead?
tmortagne - (11:40): because a listener can register to several events
tmortagne - (11:40): for example remote event manager register to all events
abusenius - (11:41): ah, I see
tmortagne - (11:44): btw we should use the same thing to check for programming right in script macros other that velocity, i never liked the fact that theses macro depends on this concept at rendering level
abusenius - (11:47): right, it would be something like ListeningPremissionChecker
abusenius - (11:47): (btw. if you have an idea how to call classes that listent to execution start and finish to set something up for the execution, let me know)
abusenius - (11:48): I called them ListeningScriptClassLoader and ListeningNestedScriptMacroValidator
tmortagne - (11:51): abusenius: better put "Listener" at the end of the class name
tmortagne - (11:51): NestedScriptMacroValidatorListener
abusenius - (11:51): ok
abusenius - (11:52): ScriptClassLoaderListener doesn't sound right though
tmortagne - (11:52): that's usually how we name on implementation of an interface
tmortagne - (11:52): yep
tmortagne - (11:52): let me think
tmortagne - (11:54): nop no better name yet
tmortagne - (11:56): also i'm think that's maybe not the right way deal with script macros classloader
tmortagne - (11:57): i don't really speak about events but more the fact that we put set the classloader which in the same for all script macro at the beginig of each macro
tmortagne - (11:57): we should probably set it at the  beginning of the rendering
tmortagne - (11:57): and then when a macro comes with some jar add them to it when needed
abusenius - (11:58): so usually, those methods return the same class loader, unless there are custom params?
tmortagne - (11:59): there is actually two aspect in this classloader things:
tmortagne - (11:59): - inject jars
tmortagne - (11:59): - keep the same classloader for all macros to share classes definied in the script with a following one
tmortagne - (12:01): so all script macros use the same classloader
tmortagne - (12:02): if you look at findClassLoader you will see that the script classloader is stored in the execution context
abusenius - (12:03): yea, allready using it instead of threadlocal
abusenius - (12:03): naming idea: ScriptClassLoaderChooserListener ?
abusenius - (12:03): or Selecter
tmortagne - (12:04): selector is better yes
tmortagne - (12:04): or Setter maybe
tmortagne - (12:04): could be Manager actually
tmortagne - (12:05): what do you do in the listener ?
tmortagne - (12:05): just the set or also the jar part ?
tmortagne - (12:05): ScriptClassLoaderHandlerListener
abusenius - (12:05): also the jar stuff
abusenius - (12:06): all the private related methods from abstract macro
abusenius - (12:06): getClassLoader() uses all of them
tmortagne - (12:07): yep, that will be a big cleanup of AbstractScriptMacro
abusenius - (12:07): btw, clirr complains if I remove protected getClassLoader(), is it really an issue?
tmortagne - (12:08): well he is kind of right, since it's a public class, someone would extends this protected method to provide a différent classloader in his script macro
abusenius - (12:09): I doubt somebody actually did
tmortagne - (12:10): usually vmassol put private until he really need protected, maybe velocity macro use it some way ?
tmortagne - (12:11): no it does not
abusenius - (12:12): maybe it used to, but was allready refactored?
tmortagne - (12:12): anyway clirr is right and it's an API breakage, if someone really needs to change the way to deal with classloader for some script macro it will become difficult
tmortagne - (12:13): abusenius: i don't think so
abusenius - (12:13): so, deprecate, return null by default?
abusenius - (12:13): or parent class loader
tmortagne - (12:14): deprecate it would not change anything
tmortagne - (12:14): since you don't use it anymore in AbstractScriptMacro
tmortagne - (12:14): that is what really break the API actually
tmortagne - (12:14): better remove it completely that keep it unused
abusenius - (12:15): ok, so remove and document
abusenius - (12:15): same with canHaveJarsParameters
tmortagne - (12:15): at least that way some one that want to migrate his macro for 2.5 would see the method doe snot exist anymore and he have to change something
abusenius - (12:15): but they might be used in groovy
tmortagne - (12:16): WDYM ?
abusenius - (12:16): canHaveJarsParameters() is also used in class loader code only
abusenius - (12:17): and is protected
tmortagne - (12:17): I meant what do you mean by "but they might be used in groovy" ?
abusenius - (12:17): they = it, forget it, it is not used :)
tmortagne - (12:18): ok
tmortagne - (12:19): (groovy macro only exist to declare the "groovy" shortcut for what is actually entirely implemented in AbstractJSR223ScriptMacro)
abusenius - (12:19): how do I convince clirr that removing those methods is what I want?
tmortagne - (12:20): you set in in the core-parent pom.xml
tmortagne - (12:20): look at the end
tmortagne - (12:21): make me think we need to remove most of it now that 2.4 is released
abusenius - (12:21): found
tmortagne - (12:21): could you remove then when adding yours ?
abusenius - (12:21): shouldn't we change the version to compare to 2.4?
tmortagne - (12:21): yep
abusenius - (12:21): sure
tmortagne - (12:23): the only issue with script class loader listener is that it make it more difficult to understand script macro behavior
tmortagne - (12:23): when looking at the code
abusenius - (12:26): yes, it is not obvious, maybe I should explain it a bit in the class comment
abusenius - (12:28): <!-- Moved internal classes that should have been in the internal package to the internal package -->
abusenius - (12:28): should it also go away?
abusenius - (12:28): org/xwiki/query/xwql/**/*<
tmortagne - (12:28): that's 2.4 too if i remember well
abusenius - (12:32): what about protected fields that are not used any more (but used in subclasses)
abusenius - (12:32): ?
tmortagne - (12:33): you mean componentmanager ?
abusenius - (12:33): document access bridge
tmortagne - (12:33): you should probably deprecate it if fix subclasses you know about
abusenius - (12:34): for component menager too
tmortagne - (12:34): s/if fix /and fix /
abusenius - (12:35): ah, component manager is used
abusenius - (12:36): and doc access bridge is used in canExecuteScript() in JSR223, it should be moved there imo
tmortagne - (12:37): i can't find canExecuteScript in AbstractScriptMacro
tmortagne - (12:38): I have in only in JSR223
abusenius - (12:38): yes, thats what I meant
abusenius - (12:38): getComponentManager() is used to get parser
tmortagne - (12:39): ha sorry i missread
tmortagne - (12:39): yep document access bridge has nothing to do in AsbtractScriptMacro it seems
abusenius - (12:45): what is the reason to deprecate fields, but not methods?
tmortagne - (12:47): it's not about methods vs fields
tmortagne - (12:47): i did not said you should not deprecate methods
tmortagne - (12:48): thee issue with getClassLoader is that a subclass don't use it, it's supposed to overwrite it
tmortagne - (12:48): and then it's used by AbstractScriptMacro
tmortagne - (12:48): so even if you deprecate it it's still broken
tmortagne - (12:49): since abstractscriptmacro does not use it anymore
tmortagne - (12:49): so it's better to remove it so that nobody think of overwriting it
tmortagne - (12:50): basically you deprecate something when you can make it still work
tmortagne - (12:51): otherwise it's a trap
abusenius - (12:51): I see
tmortagne - (12:51): i have to go
tmortagne - (12:51): good luck ;)
tmortagne left at 12:52 (Quit: Leaving.
silviar left at 13:07 (Quit: Leaving.
sdumitriu - (13:25): abusenius: Can you check now if you can close issues?
sdumitriu - (13:26): I think Jira didn't actually save my changes yesterday
fmancinelli left at 13:58 (Ping timeout: 240 seconds
nickless joined #xwiki at 13:58
abusenius left at 13:58 (Ping timeout: 258 seconds
fmancinelli joined #xwiki at 13:59
nickless is now known as abusenius ([email protected]
abusenius - (14:00): ah, seems to work now, thanks
abusenius - (14:01): sdumitriu: I guess http://jira.xwiki.org/jira/browse/XWIKI-4756 should be closed now
sdumitriu - (14:03): You should run the command from the first comment and see if all the results are escaped
abusenius - (14:04): running... (but now there are escaping tests for that doing much better job btw)
sdumitriu - (14:05): Yep, I know
sdumitriu - (14:05): Just to check *that* issue
abusenius - (14:08): ok, I'll leave it for later, it requires looking at the templates yet again
abusenius - (14:08): but I'm quite sure that templates [a-m]*.vm are fixed
abusenius - (14:09): (with a few know exceptions)
silviar joined #xwiki at 14:31
nickless joined #xwiki at 15:08
abusenius left at 15:08 (Ping timeout: 272 seconds
SvenDowideit is now known as SvenDowide ([email protected]
SvenDowide is now known as SvenDowideit ([email protected]
nickless is now known as abusenius ([email protected]
SvenDowideit left at 15:15 (Changing host
SvenDowideit joined #xwiki at 15:15
sburjan left at 16:24 (Ping timeout: 252 seconds
silviar left at 16:30 (Quit: Leaving.
Enygma` joined #xwiki at 16:33
evalica joined #xwiki at 16:48
lucaa left at 16:48 (Quit: Leaving.
evalica left at 16:49 (Read error: Connection reset by peer
asrfel left at 17:13 (Quit: Leaving.
fmancinelli left at 17:30 (Ping timeout: 276 seconds
abusenius left at 18:39 (Ping timeout: 240 seconds
fmancinelli joined #xwiki at 18:53
lucaa joined #xwiki at 18:54
fmancinelli left at 19:05 (Ping timeout: 246 seconds
Enygma`1 joined #xwiki at 19:34
Enygma` left at 19:36 (Ping timeout: 264 seconds
abusenius joined #xwiki at 19:57
lucaa left at 20:39 (Ping timeout: 265 seconds
nickless joined #xwiki at 20:50
abusenius left at 20:51 (Ping timeout: 245 seconds
nickless is now known as abusenius ([email protected]
nickless joined #xwiki at 21:24
abusenius left at 21:24 (Ping timeout: 272 seconds
nickless is now known as abusenius ([email protected]
fmancinelli joined #xwiki at 22:20
fmancinelli left at 23:08 (Ping timeout: 252 seconds
lucaa joined #xwiki at 23:33

Get Connected