IRC Archive for channel #xwiki on 29 January 2015
Last modified by Vincent Massol on 2015/01/29 23:43
<momomomomo> has quit
00:01 <vmassol> has quit
00:13 <woshilapin> has quit
00:16 <fmancinelli> has quit
00:19 <Chuguniy> has joined #xwiki
00:23 <vmassol> has joined #xwiki
00:41 <sburjan`> has joined #xwiki
00:44 <vmassol> has quit
00:45 <sburjan> has quit
00:45 <sburjan`> is now known as <sburjan>
02:00 <Chuguniy> has quit
05:24 <Chuguniy> has joined #xwiki
05:57 <Chuguniy> has quit
06:00 <Denis> has quit
06:00 <Denis1> has joined #xwiki
07:11 <msmeria> has joined #xwiki
07:42 <RamonaConoro> has joined #xwiki
08:03 <gsmeria> has joined #xwiki
08:08 <vmassol> has joined #xwiki
08:14 <gsmeria> has quit
08:18 <gsmeria> has joined #xwiki
08:26 <KermitTheFragger> has joined #xwiki
09:01 <[d__d]> has quit
09:03 <[d__d]> has joined #xwiki
09:22 <vrachieru> has joined #xwiki
09:26 <cjd> has joined #xwiki
09:30 <woshilapin> has joined #xwiki
09:42 <mflorea> has joined #xwiki
09:46 <vmassol> mflorea: good morning
09:46 <vmassol> would you have any quick idea as to why this would fail in the wysiwyg editor: http://jira.xwiki.org/browse/XWIKI-11695# (see my comments and especially the last one)?
09:51 <mflorea> vmassol: good morning, checking
09:52 <vmassol> checking when it stopped working by testing on earlier versions now
09:53 <vmassol> works in 6.2.4
09:53 <bouquetf> has quit
09:55 <vmassol> probably something thomas worked on I'd say
09:56 <vmassol> he worked on velocity isolation AFAIK so it could be related
09:58 <gdelhumeau> has joined #xwiki
10:01 <bouquetf> has joined #xwiki
10:01 <lucaa> has joined #xwiki
10:04 <mflorea> it works in inline edit mode (which uses the edit action also)
10:07 <vmassol> mflorea: I think it could be caused by http://jira.xwiki.org/browse/XWIKI-11403
10:07 <vmassol> and in edit mode somewhere we're missing a call to VelocityEngine#startedUsingMacroNamespace
10:07 <vmassol> thus each velocity execution is isolated
10:07 <mflorea> no, as I said, it works in edit mode when inline
10:07 <vmassol> yes but there can be some different paths used
10:07 <vmassol> for inline and for edit
10:08 <mflorea> but the distinction here is that the content of the wysowyg editor is taken by rendering a velocity template
10:08 <mflorea> /edit/Space/Page?xpage=wysiwyginput
10:08 <mflorea> let's see if we can reproduce with another template
10:09 <vmassol> thomas has changed the behavior and has fixed several places but my guess is that he forgot some
10:09 <mflorea> it may be the wysiwyg script service
10:09 <mflorea> which does the rendering
10:09 <vmassol> hmm actually no it's the opposite
10:09 <mflorea> https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-wysiwyg/xwiki-platform-wysiwyg-server/src/main/java/org/xwiki/wysiwyg/server/script/DefaultWysiwygEditorScriptService.java#L90
10:09 <vmassol> he made it automatic AFAICS in teh code
10:11 <mflorea> actually this is called https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-wysiwyg/xwiki-platform-wysiwyg-server/src/main/java/org/xwiki/wysiwyg/server/script/DefaultWysiwygEditorScriptService.java#L120
10:11 <Chuguniy> has joined #xwiki
10:12 <tmortagne> has joined #xwiki
10:13 <vmassol> tmortagne: good morning, I need your input :)
10:13 <vmassol> (you can check the last 3 comments on http://jira.xwiki.org/browse/XWIKI-11695# )
10:13 <tmortagne> vmassol: sure, give me a few minutes to wakeup
10:13 <vmassol> I'm trying to understand your change
10:13 <vmassol> in DVE
10:14 <vmassol> DefaultVelocityEngine
10:14 <vmassol> about startedUsingMacroNamespaceInternal/stop*
10:14 <mflorea> vmassol: I can reproduce in a wiki page by calling
10:14 <mflorea> {{{$services.wysiwyg.toAnnotatedXHTML($myDoc.content, $myDoc.syntax.toIdString())}}}
10:14 <vmassol> ok
10:14 <mflorea> where $myDoc is the doc that has the content you posted in your comment
10:15 <vmassol> to me it looks lile some namespace stuff
10:15 <vmassol> but tmortagne will know better
10:15 <mflorea> yes
10:15 <tmortagne> vmassol: did you checked http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki64#HCleanupunprotectednamespaces ?
10:16 <tmortagne> it explain the change with an example
10:17 <mflorea> toAnnotatedXHTML calls this https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-wysiwyg/xwiki-platform-wysiwyg-server/src/main/java/org/xwiki/wysiwyg/server/internal/converter/DefaultHTMLConverter.java#L145
10:17 <tmortagne> did not looked at the detail but from what I understand it looks like the issue is that the wysiwyg does not declare a transformation id for the content it execute
10:17 <mflorea> this is probably the job of DefaultHTMLConverter, in toHTML
10:17 <tmortagne> TransformationManager#performTransformations is automatically taking care of that so I guess it means the wysig execute its own txs
10:18 <mflorea> yes, because it executes only macro transformaitons
10:18 <mflorea> see https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-wysiwyg/xwiki-platform-wysiwyg-server/src/main/java/org/xwiki/wysiwyg/server/internal/converter/DefaultHTMLConverter.java#L145
10:18 <tmortagne> ok will look at the code
10:19 <vmassol> so we need to wrap the toHTML() with a start/stop?
10:19 <mflorea> #parseAndRender should be fixed too (also in DefaultHTMLConverter)
10:19 <tmortagne> by the way it mean the wysiwyg used to leak velocity macros
10:20 <tmortagne> vmassol: basically when you think it's possible that you execute several script you need to use start/stop
10:21 <tmortagne> most of the time you use transformation manager and other APIs that take care of that for you so you don't really care but sometime you are doing cutom stuff
10:23 <fmancinelli> has joined #xwiki
10:25 <tmortagne> I think I can find some criteria to fix the issue directly in MacroTransformation
10:25 <tmortagne> should reduce issues with custom codes that use only this tx
10:27 <tmortagne> vmassol: can I assign XWIKI-11695 to me ?
10:28 <tmortagne> or do you want do to it with some pointers maybe ?
10:28 <vmassol> tmortagne: sniff my BFD issue goes away… :) go ahead I'll find another one
10:28 <tmortagne> I can give you some advice on how it could be fixed if you want
10:28 <vmassol> yes maybe it's better
10:28 <vmassol> so that I understand the changes you made
10:30 <tmortagne> vmassol: in MacroTransformation#transform you get a TransformationContext which among other things contains a transformation id, you can compare it to th current transformation id (RenderingContext#getTransformationId) and if it's not the same put the whole transformation around a start/stop with the transformation id from the TransformationContext
10:31 <Guest16855> has joined #xwiki
10:32 <vmassol> ok
10:32 <tmortagne> that way the whole transformation will share the same namespace
10:33 <tmortagne> actually you don't even need to check if it's the same since start/stop hard a stack internally so if the current id is already the right one it's ok too, it's just useless, as you want
10:34 <vmassol> ok so the code checks the stack and it's the same it doesn't create a new element on the stack?
10:34 <vmassol> *same id
10:34 <vmassol> will check the code
10:35 <tmortagne> vmassol: also don't forget to update the rendering context since that's probably another bug of the WYSIWYG, if it does not start/stop I guess it also does not make sure to update the rendering context
10:35 <tmortagne> you can look at transformationmanager code for all this
10:35 <vmassol> yep I'm reaing it now
10:35 <vmassol> *reading
10:35 <tmortagne> we are starting to ave code that count on rendering context to be right so we need to make sure it's always right
10:36 <vmassol> this starts to be quite complex overall though...
10:39 <vmassol> tmortagne: why did you introduce MutableRenderingContext instead of refactoring RenderingContext?
10:39 <vmassol> this forces ugly casts
10:39 <tmortagne> vmassol: I did not
10:40 <tmortagne> Denis did
10:40 <tmortagne> MutableRenderingContext is internal
10:40 <tmortagne> and RenderingContext was supposed to be read only
10:40 <vmassol> still there's a problem
10:40 <tmortagne> he did not wanted to have it modifiable
10:40 <vmassol> ((MutableRenderingContext) this.renderingContext).transformInContext(transformation, context, block);
10:40 <vmassol> is not nice
10:40 <tmortagne> it's not supposed to be used much
10:41 <vmassol> why do this:
10:41 <vmassol> @Inject
10:41 <vmassol> private RenderingContext renderingContext;
10:41 <vmassol> instead of being inject a mutable RC?
10:41 <vmassol> *injected
10:41 <tmortagne> the role is RenderingContext
10:41 <vmassol> yes with a different role then
10:41 <tmortagne> would be a different context
10:41 <vmassol> AFAICS all the RenderingContext stuff is 6.0 so still unstable
10:41 <tmortagne> different role means different instance
10:41 <Denis1> the mutable aspect of it is not public API
10:42 <vmassol> I know Denis1 but the impl is ugly
10:42 <tmortagne> vmassol: you can propose something else
10:42 <vmassol> yes sure like I have the time to redo eveything Denis did :)
10:43 <vmassol> I don't think the answer is to ask someone finding a problem to redo everything others did :)
10:43 <vmassol> I'm just questioning the need for the cast which IMO is a design smell
10:43 <Denis1> this is the best I could do at the time it has been done, and if you consider that we should get rid of the mutable aspect, I do not see where you have a problem
10:44 <vmassol> what I know is that if I have to design something from scratch I 'll never force c ast
10:44 <vmassol> *cast
10:44 <Denis1> is now known as <Denis>
10:44 <Denis> I do not want to keep a MutableContext in the end
10:44 <vmassol> now I don't know enough about what was done to suggest something ATM
10:44 <Denis> so if you have the time to refactor what need be to get rid of it, go on :)
10:45 <tmortagne> vmassol: the answer is not to just say "that's crap" without any counter proposal, Denis tough a lot about it and did what he could
10:45 <Denis> as you said, I am inheriting of someone else work, and we can always redo what as been done
10:45 <vmassol> what I meant
10:46 <Denis> s/can/can't
10:46 <vmassol> is that this new concept of Rendering Context is new
10:46 <vmassol> still new
10:46 <vmassol> but not for a long time more
10:46 <Denis> the RenderingContext as non-mutable is clean
10:46 <vmassol> (it's going to be out of unstable)
10:46 <Denis> the mutable stuff is internal
10:46 <vmassol> and if we wait too long
10:46 <vmassol> we'll have no options
10:46 <tmortagne> MutableRenderingContext is internal, we can change it anytime we want
10:46 <Denis> we should not be afraid
10:46 <vmassol> you don't understand tmortagne
10:46 <Denis> the dirty aspect has been kept internal
10:46 <vmassol> I'm talking design
10:47 <vmassol> and you're talking impl
10:47 <tmortagne> again what is public is only the read only part and there is no issue there
10:47 <tmortagne> nobody need to cast anything to get the current rendering context properties
10:48 <tmortagne> anything else IS impl so you are talking about impl
10:48 <Denis> the designed aspect is clean Vincent, there is no issue there. This is why I done it that way
10:49 <Denis> I really do not get why you are worried
10:49 <vmassol> ok so you consider casting clean we're not going to agree on that :)
10:49 <vmassol> let's stop here
10:49 <Denis> this is implementation details in internal stuffs
10:49 <vmassol> internal impl doesn't mean it has to be hackish
10:49 <Denis> this has nothing to do with the our public API
10:49 <vmassol> of course I could use relfection everywehre
10:49 <vmassol> instead of calling setters
10:50 <Denis> ok, if you have plenty of time, change it !
10:50 <vmassol> it'll still work
10:50 <vmassol> and still be internal
10:50 <vmassol> but it wouldn't be right
10:50 <vmassol> let's stop here because I don't hae the time to change and you think it's right
10:51 <Denis> to get rid of that casting, there is a lot to do, I have evaluate it, and taking timing aspect into consideration, I have made the current implementation. If you do not like it, and you have more time, you can improve. I have not cut your options
10:51 <vmassol> ok I prefer this answer :)
10:51 <Denis> do we have ever say something else ?
10:51 <vmassol> that you know it's not right but you did it for time considerations
10:51 <vmassol> I can accept taht
10:52 <vmassol> yes thomas was saying it was right
10:52 <Denis> since the beginning, I said that the mutable aspect of the RC should be get rid of
10:52 <tmortagne> vmassol: I said the public API was right...
10:53 <Denis> exactly
10:53 <Denis> and to get the public API right, I have introduce that cast
10:53 <tmortagne> re XWIKI-11695 the best would probably be to allow passing transformations to TransformationManager
10:53 <Denis> until we have time to really not need it
10:53 <tmortagne> that way TransformationManager will take care of rendering context and stuff
10:54 <vmassol> all I know is that this is one more complex thing to understand
10:54 <Denis> that should, and currently we have tons of place where you can really use it
10:54 <Denis> this is where the design was flawed
10:54 <vmassol> and I defy anyone to write code that is correct
10:54 <Denis> and this not my work
10:54 <vmassol> the proof is the bug I'm trying to fix
10:54 <vmassol> if you check the wysiwyg code it has to understand the cast apparently
10:54 <tmortagne> setting the rendering context is not supposed to be common stuff, that's why it's internal
10:55 <vmassol> yes we probabmy need a way
10:55 <vmassol> to execute only some transformations
10:55 <vmassol> and not let that to users of the api
10:55 <vmassol> to figure out
10:55 <tmortagne> and I just suggested who to do it in a cleaner way
10:55 <tmortagne> "he best would probably be to allow passing transformations to TransformationManager"
10:55 <tmortagne> s/who/how/
10:56 <vmassol> yes I agree and I believe we even discussed that at the beginning of the rendering module but we didn't do it
10:56 <vmassol> I think I didn't do it initially becasue it was suppose to be easy just to look up one Tx and execute t
10:57 <vmassol> *it
10:57 <vmassol> but it's now complex
10:57 <vmassol> since there are several stuff to prepare
10:58 <tmortagne> the bug you are working on is not about rendering context
10:58 <vmassol> I'm talking about transformations here
10:58 <tmortagne> I'm just talling you that there is probably others bugs because of that
10:58 <tmortagne> s/talling/telling/
10:58 <vmassol> well you shell that to yourself because you introduced the change :)
10:58 <vmassol> *should tell
10:58 <vmassol> so better check it out
10:59 <vmassol> all places that calls Tx diretly
10:59 <tmortagne> again Denis introduced it
10:59 <tmortagne> if you don't want to do it don't do it
10:59 <vmassol> I'm talking about the isoaltion stuff
10:59 <vmassol> velocity isoaltion
10:59 <tmortagne> since you were working on it I tough it was a good thing to check other things to
11:00 <Bugendolf> has quit
11:02 <Denis> When I introduce the RC, I had check out to my best all places that are running transformation, and I was disappointed to see so much duplicated code, but a complete refactoring was out of my reach at that time
11:02 <Denis> hence the cast stuff which was the cleanest way to solve it out for the moment
11:08 <lucaa> has quit
11:08 <Bugendolf> has joined #xwiki
11:10 <vmassol> Denis: ok
11:10 <vmassol> thanks for the explanations
11:15 <vmassol> tmortagne: so if I understand correctly when you create a new TransformationContext you should always pass an id as otherwise there's no open/close done
11:15 <vmassol> so why not make the id part of the constructor and deprecate the current constructors not taking an id, to make it mandaotry?
11:15 <tmortagne> you mean when you call transformationmanager ?
11:15 <vmassol> no I mean when calling new TransformationContet()
11:16 <tmortagne> TransformationContet does not call any start/stop
11:16 <vmassol> AFAICS in XWikiRenderingContext
11:16 <vmassol> if the id is not set then no open/vlose
11:16 <vmassol> yes but with the code in XWikiRenderingContext we kind of require an id or it won't work properly
11:16 <tmortagne> so you are talking about RenderingContext
11:17 <vmassol> I'm talking about user code
11:17 <vmassol> if someone writes new TransformationContext() the nit's likely to not work
11:18 <tmortagne> if you don't give an id it means you want to stay with the current id AFAIK
11:18 <vmassol> ok then all this needs to be documented
11:18 <vmassol> right now when I read the javadoc for Tx I don't understand that
11:18 <vmassol> fixing it
11:19 <vmassol> so our problem is that we're not inside any current Tx
11:19 <vmassol> (and thus no id is set)
11:20 <vmassol> maybe there's a way to check that in our code automatically
11:20 <tmortagne> yes that's RederingContext job
11:21 <tmortagne> it contain the current rendering related properties
11:21 <tmortagne> this is why I suggested you to check it before calling start/stop in my first message
11:22 <vmassol> yes but I don't care here I think
11:23 <vmassol> unless toHTML and parseAndRender are called recusrively
11:23 <lucaa> has joined #xwiki
11:24 <vmassol> ok I'll do the "clean" way just to prove I understand :)
11:26 <tmortagne> vmassol: I don't know much about toHTML but if it's just a helper to convert a XDOM to HTML with macro execution it might be reused by a macro or something
11:27 <tmortagne> the question is more do we want toHTML to be isolated or not
11:27 <vmassol> tmortagne: any best practice for naming a tx id?
11:28 <vmassol> planning to use "wysiwygtxid"
11:30 <tmortagne> we don't really have naming rules right now, the template path is used for template and the document reference for document rendering
11:30 <tmortagne> you don't need to worry about two thread using the same namespace the velocityengine is taking care of that
11:31 <vmassol> yep seen that code
11:43 <vmassol> tmortagne: we're already in a tx actually
11:44 <vmassol> id = "/skins/flamingo/wysiwyginput.vm"
11:44 <vmassol> so it means this tx has not set an id
11:44 <vmassol> or has not called start/stop
11:45 <vmassol> so when we parse a template we create a tx now?
11:45 <tmortagne> "the template path is used for template"
11:46 <tmortagne> there id when executing a template yes
11:46 <vmassol> why is there a Tx when executing a template?
11:46 <vmassol> and how do I differentitate a template tx from other tx?
11:46 <tmortagne> transplates are content executed
11:47 <tmortagne> some are only velocity and some are wiki syntax
11:47 <vmassol> this one is velocity
11:47 <tmortagne> but you still need to indicate what is the current id used
11:47 <vmassol> that's what I don't understand
11:47 <tmortagne> it's the same
11:47 <tmortagne> the transformation id is the id used to execute script
11:47 <vmassol> so the velocity execution goes throgh the Rendering as a Velocity Macro being executed?
11:47 <tmortagne> the source being wiki syntaxe or directly velocity it's the same you still execute something
11:47 <tmortagne> like if you had only a velocity macro in your wiki content
11:48 <tmortagne> it does not create a XDOM no to not spend time on useless stuff but it still properly set the rendering context for anyone to reuse a transformation id, velocity namespace etc
11:49 <vmassol> why is the template exectuion not calling start/stop? imagine there's two velcocity macros in a template?
11:49 <tmortagne> it does
11:50 <vmassol> hmm then I don't understand why the wysiwyg doesn't work
11:50 <tmortagne> no idea, you could put a breakpoint in the velocity engine to see what namespaces are used
11:51 <vmassol> ok I'll debug further
11:51 <tmortagne> but I don't think we want to reuse the template id anyway
11:51 <tmortagne> the WYSIWYF should execute what he want to execute in an isolated way IMO
11:51 <tmortagne> to not pollute the WYSIWYG template
11:51 <vmassol> but we don't have a way to differentiate template tx from non template tx do we?
11:52 <tmortagne> like document rendering use it's own namespace
11:52 <vmassol> ok then we shouldn't do the "if" you suggested right?
11:52 <tmortagne> vmassol: it depends what is executed exactly here
11:52 <vmassol> or we could
11:53 <vmassol> but just to not recreate a new id when the current id is the wysiwyg one
11:53 <vmassol> just in case it's called recursively there after
11:53 <vmassol> i'l do that
11:53 <tmortagne> I suggested a if mostly for the macro transformation to not break anything but maybe the WYSIWYG should force an isolation
11:53 <tmortagne> I don't know exactly the use case
11:53 <vmassol> still going to see what namespace is used. I'm curious
11:55 <tmortagne> vmassol: the id used in practice is the one in the transformation context when executing a velocity macro so the issue is probably with null in the velocity macro
11:55 <tmortagne> what is in the renderingcontext is an information that we try to keep up to date
11:56 <tmortagne> maybe its generating a namespace instead of using the current one
11:57 <vmassol> namespace used is "unknown namespace"
11:57 <tmortagne> probably because of the null in the transformation context indeed then
11:57 <vmassol> yes apprently
11:59 <vmassol> so
11:59 <vmassol> if you don't set an id, even if you're inside a Tx, velocity scripts will be ioslated
12:00 <vmassol> we treat "unknown namespace" in a psecial way?
12:00 <vmassol> (need to check that part)
12:00 <vmassol> apparently not
12:00 <vmassol> hmm then I don't get it
12:01 <vmassol> the 2 velocity macros shoiuld both use "unknown namespace" as their namespace
12:02 <vmassol> tmortagne: I don't understand this code in DefaultVelocityEngine:
12:02 <vmassol> startedUsingMacroNamespaceInternal(namespace);
12:03 <vmassol> ah I understand
12:04 <vmassol> it works because it's a put in a Map so it's not going to create a new "namespace"
12:04 <tmortagne> lunch time, back in 1 or 2h
12:04 <vmassol> so if it's empty then no isolation...
12:38 <gsmeria> has quit
12:44 <Slashman> has joined #xwiki
12:49 <cjd> has quit
12:54 <Guest16855> hello can i hava a help with a problem with xwiki 6.4 after upgrade from 6.3 ?
13:05 <vmassol> Guest16855: hi, you need to state your problem or we won't be able to help you :)
13:31 <Guest16855> ok thanks
13:32 <Guest16855> after upgrade xwiki from 6.3 to 6.4, i have a problem with solr
13:32 <vmassol> yep
13:32 <Guest16855> org.apache.solr.common.SolrException: Error loading class 'org.xwiki.search.solr.internal.XWikiDismaxQParserPlugin'
13:32 <vmassol> http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki64
13:32 <vmassol> it's in red letters to make it easy to notice :)
13:39 <Guest16855> ok thanks it's allright
13:40 <Guest16855> remove solr directory
13:40 <Guest16855> yesterday, i have clean the directory and not delete
13:40 <Guest16855> and in this case, problem
14:03 <lucaa1> has joined #xwiki
14:03 <lucaa> has quit
14:12 <vmassol> Guest16855: ok
14:19 <tmortagne> vmassol: something weird on mail test, maybe you forgot to commit something:
14:19 <tmortagne> [ERROR] /home/hudsonagent/jenkins_root/workspace/xwiki-platform/xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-test/xwiki-platform-mail-test-tests/src/test/it/org/xwiki/mail/test/ui/MailTest.java:[100,21] cannot find symbol symbol: method setDiscardSuccessStatuses(boolean) location: variable sendMailPage of type org.xwiki.mail.test.po.SendMailAdministrationSectionPage
14:19 <vmassol> hmm thanks tmortagne, checking
14:20 <vmassol> it's building fine here
14:21 <vmassol> this means the pageobjets module wasn't built which is strange
14:22 <vmassol> seems to be there though: https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-test/xwiki-platform-mail-test-pageobjects/src/main/java/org/xwiki/mail/test/po/SendMailAdministrationSectionPage.java#L87
14:22 <vmassol> looks like a problem on jenkins somewehre
14:23 <vmassol> but I don't see how it could not build the pageobjects
14:24 <vmassol> apparently it didn't build the pageobjects in this bild
14:24 <vmassol> *build
14:24 <vmassol> at http://ci.xwiki.org/job/xwiki-platform/789/console
14:25 <vmassol> there's a test depednency on it though
14:25 <tmortagne> vmassol: jenkins is configured for partial build so sometimes it fail and then not build what was not built in the previous run
14:25 <vmassol> so I don't know what happened but a full build shuld solve it
14:26 <tmortagne> should be ok if you start platform build by hand, will rebuild the whole thing
14:31 <Guest16855> has quit
14:31 <cjd> has joined #xwiki
14:40 <vmassol> gdelhumeau: errro html export doesn't work at all for me on 7.0, it's just hanging...
14:41 <gdelhumeau> it is very long now
14:41 <vmassol> so that's a bug regression
14:41 <vmassol> it's not usable a tall for me
14:41 <vmassol> I've waited over 1 minute and still nothing
14:41 <vmassol> it used to be immediate, after 1 second
14:42 <tmortagne> gdelhumeau: I can understand the time spend on less build but less build is not 1 minute
14:42 <gdelhumeau> it is compiled multiple times
14:42 <vmassol> and it shouldn't recompile here either
14:43 <vmassol> in any case that's a blocker regression gdelhumeau
14:43 <gdelhumeau> it's better on 6.2.x, maybe some page using LESS in SSX
14:43 <tmortagne> what is the creteria to rebuild it in the same html export ?
14:43 <tmortagne> criteria
14:43 <gdelhumeau> I was hopping that less4j would solve this
14:43 <vmassol> no
14:43 <gdelhumeau> tmortagne: the URL
14:43 <vmassol> no tool will ever solve this
14:43 <gdelhumeau> the url for a CSS is not the same for then main page
14:43 <vmassol> there's an intrinsic problem
14:44 <vmassol> exporting HTML is already a complex process, adding overhead is just not going to to doit
14:44 <tmortagne> gdelhumeau: you mean an URL in the page which is exported ?
14:44 <gdelhumeau> yes
14:44 <tmortagne> why ?
14:45 <Chuguniy> has quit
14:45 <vmassol> my cpu is going crazy too during the export
14:46 <tmortagne> you mean each css included in the page produce a new less build ?
14:46 <gdelhumeau> those which uses LESS
14:46 <tmortagne> in standard it's what ? just style.css ?
14:46 <tmortagne> if I export an empty page in XE for example it generate how many builds ?
14:47 <vmassol> 1 minute 22 seconds
14:47 <vmassol> to export the sandbox.webhome page
14:47 <tmortagne> is it only the first time or nothing is cached ?
14:47 <vmassol> used to be areound 1 second
14:47 <gdelhumeau> everything is explained there: http://jira.xwiki.org/browse/XWIKI-11658#
14:47 <vmassol> I don't understan dhow you can consdier this acceptable/normal gdelhumeau
14:48 <vmassol> ...
14:48 <vmassol> and why it wasn't raised
14:48 <vmassol> is there are jira issue?
14:48 <gdelhumeau> it was good for 6.2.x for which I've made it
14:48 <vmassol> (for the html export)
14:48 <gdelhumeau> but I don't know why 6.4 is so long
14:48 <vmassol> it doesn't that you don't know why
14:48 <vmassol> the minimum to do if you knew bout it
14:48 <vmassol> was to raise a bocker
14:48 <vmassol> *blocker
14:49 <vmassol> do we have a jira issue?
14:49 <gdelhumeau> no
14:49 <vmassol> ok creating one
14:49 <vmassol> sigh… one more blocker :(
14:49 <tmortagne> I'm surprise we don't get a timeout in the HTMLExportTest test if it's that long
14:51 <tmortagne> we should probably put a shorter timeout there
14:52 <vmassol> tmortagne: we should include export performance tests in the test report too maybe?
14:53 <tmortagne> vmassol: a timeout in the automated test would catch it way quicker
14:53 <tmortagne> since we already have such a test
14:53 <vmassol> yes but it'll never work good enough
14:53 <vmassol> if you put a timeout at 3 seconds
14:53 <vmassol> the tests will fail too often
14:54 <vmassol> and if you put it at 30 seconds it's too long, even 3 seconds is too long for exporting 1 pzage
14:54 <vmassol> *âge
14:54 <vmassol> grr
14:54 <vmassol> *page
14:54 <tmortagne> sure but you are talking about something that takes more than 1 minutes here, putting 10 or 20 s should not produce too many false positive
14:54 <tmortagne> it's not going to be less than 3s
14:55 <tmortagne> building less takes 8s itself already
14:55 <vmassol> then we should drop less
14:55 <cjd> you're not making the azerty keyboard seem easy to use
14:55 <vmassol> we cannot penalize all our features becaude of less
14:55 <vmassol> I'm getting seriously pissed by less
14:55 <vmassol> it's a nightmare
14:55 <vmassol> did I say I hate generators :)
14:56 <tmortagne> it's better with less4j according to gdelhumeau but probably still slow
14:56 <vmassol> it's never going to be fast enough
14:56 <tmortagne> but there is probably things we can prebuild, right now we rebuild everything all the time
14:56 <vmassol> one option is to forget dynamcity and precompile stuff
14:57 <gdelhumeau> then it's a regression
14:57 <vmassol> less itself is a regression on the performance aspect in several places
14:57 <tmortagne> gdelhumeau: is thare caching or html export rebuild everything each time ?
14:57 <vmassol> it brings some new feature but at too high a cost ATM
14:57 <tmortagne> we have cache in view and it's dine
14:57 <tmortagne> fine
14:57 <gdelhumeau> tmortagne: no cache
14:57 <gdelhumeau> it used to have one
14:58 <gdelhumeau> but it was breaking icons
14:58 <vmassol> even view is not fine tmortagne, it's taking too long on the first run
14:58 <tmortagne> there is a specific blocker or just do not had time to look at it ?
14:59 <tmortagne> vmassol: it's taking 8s on the very fist run among many other stuff, less is not the only thing happening on first run
14:59 <vmassol> thaty's not tre tmortagne
14:59 <vmassol> your confusing stuff
14:59 <vmassol> the first page accessed
14:59 <vmassol> and when you make changes later on in xobjets
14:59 <vmassol> for example
14:59 <vmassol> or in skin
14:59 <vmassol> so you do get the timeout several times
14:59 <vmassol> it's a pain
15:00 <vmassol> and make xwiki slugglish
15:00 <tmortagne> sure but the skin is not something you modify all the time
15:00 <vmassol> as a feeling
15:01 <tmortagne> not many people experience the first slow run unless your wiki restart all the time
15:01 <vmassol> personally I feel we've regressed because of LESS (in term of overall perf)
15:01 <vmassol> re memory I hope the cache is not taking too much either
15:02 <msmeria> has quit
15:02 <tmortagne> I would not say overall perfs, once it's built it's just css so it's not slowing down the whole thing
15:02 <tmortagne> only the first access is impacted, which is not very nice for devs I agree but not that visible for users
15:03 <tmortagne> but if html export does not cache anything that's another mater
15:03 <tmortagne> I agree that i html export is that slow all the time it's quite bad
15:05 <tmortagne> anyway if gdelhumeau said it was ok in 6.2.x it should be debugged first
15:05 <tmortagne> vmassol: on the memory side I think is a filesystem cache, right gdelhumeau ?
15:06 <gdelhumeau> right
15:06 <gdelhumeau> but we store a mutex for each less ressource
15:06 <tmortagne> sure but a mutex is nothing
15:07 <vmassol> ok that's good if it's not taking memory
16:04 <tmortagne> 6.4.1 will be welcome indeed
16:05 <vmassol> :(
16:05 <vmassol> I have the feeling we're generating lots of bugs/regressions
16:06 <vmassol> we're surely missing tests
16:06 <vmassol> we need to improve and get better, it's taking too long to stabilize ATM
16:09 <tmortagne> or we rush too much during BFD (the issue vrachieru fixed was a typo introduce in a BFD issue)
16:10 <vmassol> yes we definitely rush too much by not taking the time to always have a test to prove that what is fixed will continue to work thereafter
16:10 <vmassol> (I know I've done this mistake myself several time in order to do more issues....)
16:34 <KermitTheFragger> has quit
16:49 <Chuguniy> has joined #xwiki
16:55 <RamonaConoro> has quit
17:04 <tmortagne> has quit
17:21 <Bugen_do> has joined #xwiki
18:01 <gdelhumeau> has quit
18:04 <fmancinelli> has quit
18:07 <cjd> has quit
18:22 <lucaa1> has quit
18:27 <tmortagne> has joined #xwiki
18:34 <woshilapin> has quit
18:41 <vmassol> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-remote-resources-plugin:1.4:process (xwiki-license-resources) on project xwiki-enterprise: Resources archive cannot be found. Could not find artifact org.xwiki.commons:xwiki-commons-tool-license-resources:jar:7.0-SNAPSHOT
18:41 <vmassol> [ERROR]
18:41 <vmassol> oops
18:41 <vmassol> sorry
18:41 <vmassol> bazd paste
18:43 <mflorea> has quit
19:19 <sdumitriu> has quit
19:24 <sdumitriu> has joined #xwiki
19:40 <tmortagne> has quit
19:47 <Slashman> has quit
20:15 <lucaa> has joined #xwiki
20:48 <momomomomo> has joined #xwiki
20:56 <bblfish_> has joined #xwiki
21:01 <fmancinelli> has joined #xwiki
21:08 <Bugen_do> has quit
21:29 <kyndel> has joined #xwiki
21:30 <kyndel> Hello. I have a new wiki on the wikifarm and I'm wondering how to make it viewable without being logged in
22:01 <lucaa> has quit
22:19 <momomomomo> has quit
22:30 <momomomomo> has joined #xwiki
22:52 <vmassol> kyndel: what wikifarm?
22:52 <vmassol> (Hi)
22:53 <vmassol> has quit
23:11 <kyndel> myxwiki.org
23:12 <kyndel> also, how do i make a page horizontally scrollable, so if i have a really big table it doens't squish all the rows
23:19 <kyndel> or rather, how do i increase the minimum row width
23:21 <bblfish_> has quit
23:34 <sburjan> has quit
23:37 <kyndel> also, how do i edit the wiki description i see in the "Wiki Information" Gadget??
23:39 <sburjan> has joined #xwiki
23:39 <fmancinelli> has quit
23:43 <vrachieru> has quit
00:01 <vmassol> has quit
00:13 <woshilapin> has quit
00:16 <fmancinelli> has quit
00:19 <Chuguniy> has joined #xwiki
00:23 <vmassol> has joined #xwiki
00:41 <sburjan`> has joined #xwiki
00:44 <vmassol> has quit
00:45 <sburjan> has quit
00:45 <sburjan`> is now known as <sburjan>
02:00 <Chuguniy> has quit
05:24 <Chuguniy> has joined #xwiki
05:57 <Chuguniy> has quit
06:00 <Denis> has quit
06:00 <Denis1> has joined #xwiki
07:11 <msmeria> has joined #xwiki
07:42 <RamonaConoro> has joined #xwiki
08:03 <gsmeria> has joined #xwiki
08:08 <vmassol> has joined #xwiki
08:14 <gsmeria> has quit
08:18 <gsmeria> has joined #xwiki
08:26 <KermitTheFragger> has joined #xwiki
09:01 <[d__d]> has quit
09:03 <[d__d]> has joined #xwiki
09:22 <vrachieru> has joined #xwiki
09:26 <cjd> has joined #xwiki
09:30 <woshilapin> has joined #xwiki
09:42 <mflorea> has joined #xwiki
09:46 <vmassol> mflorea: good morning
09:46 <vmassol> would you have any quick idea as to why this would fail in the wysiwyg editor: http://jira.xwiki.org/browse/XWIKI-11695# (see my comments and especially the last one)?
09:51 <mflorea> vmassol: good morning, checking
09:52 <vmassol> checking when it stopped working by testing on earlier versions now
09:53 <vmassol> works in 6.2.4
09:53 <bouquetf> has quit
09:55 <vmassol> probably something thomas worked on I'd say
09:56 <vmassol> he worked on velocity isolation AFAIK so it could be related
09:58 <gdelhumeau> has joined #xwiki
10:01 <bouquetf> has joined #xwiki
10:01 <lucaa> has joined #xwiki
10:04 <mflorea> it works in inline edit mode (which uses the edit action also)
10:07 <vmassol> mflorea: I think it could be caused by http://jira.xwiki.org/browse/XWIKI-11403
10:07 <vmassol> and in edit mode somewhere we're missing a call to VelocityEngine#startedUsingMacroNamespace
10:07 <vmassol> thus each velocity execution is isolated
10:07 <mflorea> no, as I said, it works in edit mode when inline
10:07 <vmassol> yes but there can be some different paths used
10:07 <vmassol> for inline and for edit
10:08 <mflorea> but the distinction here is that the content of the wysowyg editor is taken by rendering a velocity template
10:08 <mflorea> /edit/Space/Page?xpage=wysiwyginput
10:08 <mflorea> let's see if we can reproduce with another template
10:09 <vmassol> thomas has changed the behavior and has fixed several places but my guess is that he forgot some
10:09 <mflorea> it may be the wysiwyg script service
10:09 <mflorea> which does the rendering
10:09 <vmassol> hmm actually no it's the opposite
10:09 <mflorea> https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-wysiwyg/xwiki-platform-wysiwyg-server/src/main/java/org/xwiki/wysiwyg/server/script/DefaultWysiwygEditorScriptService.java#L90
10:09 <vmassol> he made it automatic AFAICS in teh code
10:11 <mflorea> actually this is called https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-wysiwyg/xwiki-platform-wysiwyg-server/src/main/java/org/xwiki/wysiwyg/server/script/DefaultWysiwygEditorScriptService.java#L120
10:11 <Chuguniy> has joined #xwiki
10:12 <tmortagne> has joined #xwiki
10:13 <vmassol> tmortagne: good morning, I need your input :)
10:13 <vmassol> (you can check the last 3 comments on http://jira.xwiki.org/browse/XWIKI-11695# )
10:13 <tmortagne> vmassol: sure, give me a few minutes to wakeup
10:13 <vmassol> I'm trying to understand your change
10:13 <vmassol> in DVE
10:14 <vmassol> DefaultVelocityEngine
10:14 <vmassol> about startedUsingMacroNamespaceInternal/stop*
10:14 <mflorea> vmassol: I can reproduce in a wiki page by calling
10:14 <mflorea> {{{$services.wysiwyg.toAnnotatedXHTML($myDoc.content, $myDoc.syntax.toIdString())}}}
10:14 <vmassol> ok
10:14 <mflorea> where $myDoc is the doc that has the content you posted in your comment
10:15 <vmassol> to me it looks lile some namespace stuff
10:15 <vmassol> but tmortagne will know better
10:15 <mflorea> yes
10:15 <tmortagne> vmassol: did you checked http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki64#HCleanupunprotectednamespaces ?
10:16 <tmortagne> it explain the change with an example
10:17 <mflorea> toAnnotatedXHTML calls this https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-wysiwyg/xwiki-platform-wysiwyg-server/src/main/java/org/xwiki/wysiwyg/server/internal/converter/DefaultHTMLConverter.java#L145
10:17 <tmortagne> did not looked at the detail but from what I understand it looks like the issue is that the wysiwyg does not declare a transformation id for the content it execute
10:17 <mflorea> this is probably the job of DefaultHTMLConverter, in toHTML
10:17 <tmortagne> TransformationManager#performTransformations is automatically taking care of that so I guess it means the wysig execute its own txs
10:18 <mflorea> yes, because it executes only macro transformaitons
10:18 <mflorea> see https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-wysiwyg/xwiki-platform-wysiwyg-server/src/main/java/org/xwiki/wysiwyg/server/internal/converter/DefaultHTMLConverter.java#L145
10:18 <tmortagne> ok will look at the code
10:19 <vmassol> so we need to wrap the toHTML() with a start/stop?
10:19 <mflorea> #parseAndRender should be fixed too (also in DefaultHTMLConverter)
10:19 <tmortagne> by the way it mean the wysiwyg used to leak velocity macros
10:20 <tmortagne> vmassol: basically when you think it's possible that you execute several script you need to use start/stop
10:21 <tmortagne> most of the time you use transformation manager and other APIs that take care of that for you so you don't really care but sometime you are doing cutom stuff
10:23 <fmancinelli> has joined #xwiki
10:25 <tmortagne> I think I can find some criteria to fix the issue directly in MacroTransformation
10:25 <tmortagne> should reduce issues with custom codes that use only this tx
10:27 <tmortagne> vmassol: can I assign XWIKI-11695 to me ?
10:28 <tmortagne> or do you want do to it with some pointers maybe ?
10:28 <vmassol> tmortagne: sniff my BFD issue goes away… :) go ahead I'll find another one
10:28 <tmortagne> I can give you some advice on how it could be fixed if you want
10:28 <vmassol> yes maybe it's better
10:28 <vmassol> so that I understand the changes you made
10:30 <tmortagne> vmassol: in MacroTransformation#transform you get a TransformationContext which among other things contains a transformation id, you can compare it to th current transformation id (RenderingContext#getTransformationId) and if it's not the same put the whole transformation around a start/stop with the transformation id from the TransformationContext
10:31 <Guest16855> has joined #xwiki
10:32 <vmassol> ok
10:32 <tmortagne> that way the whole transformation will share the same namespace
10:33 <tmortagne> actually you don't even need to check if it's the same since start/stop hard a stack internally so if the current id is already the right one it's ok too, it's just useless, as you want
10:34 <vmassol> ok so the code checks the stack and it's the same it doesn't create a new element on the stack?
10:34 <vmassol> *same id
10:34 <vmassol> will check the code
10:35 <tmortagne> vmassol: also don't forget to update the rendering context since that's probably another bug of the WYSIWYG, if it does not start/stop I guess it also does not make sure to update the rendering context
10:35 <tmortagne> you can look at transformationmanager code for all this
10:35 <vmassol> yep I'm reaing it now
10:35 <vmassol> *reading
10:35 <tmortagne> we are starting to ave code that count on rendering context to be right so we need to make sure it's always right
10:36 <vmassol> this starts to be quite complex overall though...
10:39 <vmassol> tmortagne: why did you introduce MutableRenderingContext instead of refactoring RenderingContext?
10:39 <vmassol> this forces ugly casts
10:39 <tmortagne> vmassol: I did not
10:40 <tmortagne> Denis did
10:40 <tmortagne> MutableRenderingContext is internal
10:40 <tmortagne> and RenderingContext was supposed to be read only
10:40 <vmassol> still there's a problem
10:40 <tmortagne> he did not wanted to have it modifiable
10:40 <vmassol> ((MutableRenderingContext) this.renderingContext).transformInContext(transformation, context, block);
10:40 <vmassol> is not nice
10:40 <tmortagne> it's not supposed to be used much
10:41 <vmassol> why do this:
10:41 <vmassol> @Inject
10:41 <vmassol> private RenderingContext renderingContext;
10:41 <vmassol> instead of being inject a mutable RC?
10:41 <vmassol> *injected
10:41 <tmortagne> the role is RenderingContext
10:41 <vmassol> yes with a different role then
10:41 <tmortagne> would be a different context
10:41 <vmassol> AFAICS all the RenderingContext stuff is 6.0 so still unstable
10:41 <tmortagne> different role means different instance
10:41 <Denis1> the mutable aspect of it is not public API
10:42 <vmassol> I know Denis1 but the impl is ugly
10:42 <tmortagne> vmassol: you can propose something else
10:42 <vmassol> yes sure like I have the time to redo eveything Denis did :)
10:43 <vmassol> I don't think the answer is to ask someone finding a problem to redo everything others did :)
10:43 <vmassol> I'm just questioning the need for the cast which IMO is a design smell
10:43 <Denis1> this is the best I could do at the time it has been done, and if you consider that we should get rid of the mutable aspect, I do not see where you have a problem
10:44 <vmassol> what I know is that if I have to design something from scratch I 'll never force c ast
10:44 <vmassol> *cast
10:44 <Denis1> is now known as <Denis>
10:44 <Denis> I do not want to keep a MutableContext in the end
10:44 <vmassol> now I don't know enough about what was done to suggest something ATM
10:44 <Denis> so if you have the time to refactor what need be to get rid of it, go on :)
10:45 <tmortagne> vmassol: the answer is not to just say "that's crap" without any counter proposal, Denis tough a lot about it and did what he could
10:45 <Denis> as you said, I am inheriting of someone else work, and we can always redo what as been done
10:45 <vmassol> what I meant
10:46 <Denis> s/can/can't
10:46 <vmassol> is that this new concept of Rendering Context is new
10:46 <vmassol> still new
10:46 <vmassol> but not for a long time more
10:46 <Denis> the RenderingContext as non-mutable is clean
10:46 <vmassol> (it's going to be out of unstable)
10:46 <Denis> the mutable stuff is internal
10:46 <vmassol> and if we wait too long
10:46 <vmassol> we'll have no options
10:46 <tmortagne> MutableRenderingContext is internal, we can change it anytime we want
10:46 <Denis> we should not be afraid
10:46 <vmassol> you don't understand tmortagne
10:46 <Denis> the dirty aspect has been kept internal
10:46 <vmassol> I'm talking design
10:47 <vmassol> and you're talking impl
10:47 <tmortagne> again what is public is only the read only part and there is no issue there
10:47 <tmortagne> nobody need to cast anything to get the current rendering context properties
10:48 <tmortagne> anything else IS impl so you are talking about impl
10:48 <Denis> the designed aspect is clean Vincent, there is no issue there. This is why I done it that way
10:49 <Denis> I really do not get why you are worried
10:49 <vmassol> ok so you consider casting clean we're not going to agree on that :)
10:49 <vmassol> let's stop here
10:49 <Denis> this is implementation details in internal stuffs
10:49 <vmassol> internal impl doesn't mean it has to be hackish
10:49 <Denis> this has nothing to do with the our public API
10:49 <vmassol> of course I could use relfection everywehre
10:49 <vmassol> instead of calling setters
10:50 <Denis> ok, if you have plenty of time, change it !
10:50 <vmassol> it'll still work
10:50 <vmassol> and still be internal
10:50 <vmassol> but it wouldn't be right
10:50 <vmassol> let's stop here because I don't hae the time to change and you think it's right
10:51 <Denis> to get rid of that casting, there is a lot to do, I have evaluate it, and taking timing aspect into consideration, I have made the current implementation. If you do not like it, and you have more time, you can improve. I have not cut your options
10:51 <vmassol> ok I prefer this answer :)
10:51 <Denis> do we have ever say something else ?
10:51 <vmassol> that you know it's not right but you did it for time considerations
10:51 <vmassol> I can accept taht
10:52 <vmassol> yes thomas was saying it was right
10:52 <Denis> since the beginning, I said that the mutable aspect of the RC should be get rid of
10:52 <tmortagne> vmassol: I said the public API was right...
10:53 <Denis> exactly
10:53 <Denis> and to get the public API right, I have introduce that cast
10:53 <tmortagne> re XWIKI-11695 the best would probably be to allow passing transformations to TransformationManager
10:53 <Denis> until we have time to really not need it
10:53 <tmortagne> that way TransformationManager will take care of rendering context and stuff
10:54 <vmassol> all I know is that this is one more complex thing to understand
10:54 <Denis> that should, and currently we have tons of place where you can really use it
10:54 <Denis> this is where the design was flawed
10:54 <vmassol> and I defy anyone to write code that is correct
10:54 <Denis> and this not my work
10:54 <vmassol> the proof is the bug I'm trying to fix
10:54 <vmassol> if you check the wysiwyg code it has to understand the cast apparently
10:54 <tmortagne> setting the rendering context is not supposed to be common stuff, that's why it's internal
10:55 <vmassol> yes we probabmy need a way
10:55 <vmassol> to execute only some transformations
10:55 <vmassol> and not let that to users of the api
10:55 <vmassol> to figure out
10:55 <tmortagne> and I just suggested who to do it in a cleaner way
10:55 <tmortagne> "he best would probably be to allow passing transformations to TransformationManager"
10:55 <tmortagne> s/who/how/
10:56 <vmassol> yes I agree and I believe we even discussed that at the beginning of the rendering module but we didn't do it
10:56 <vmassol> I think I didn't do it initially becasue it was suppose to be easy just to look up one Tx and execute t
10:57 <vmassol> *it
10:57 <vmassol> but it's now complex
10:57 <vmassol> since there are several stuff to prepare
10:58 <tmortagne> the bug you are working on is not about rendering context
10:58 <vmassol> I'm talking about transformations here
10:58 <tmortagne> I'm just talling you that there is probably others bugs because of that
10:58 <tmortagne> s/talling/telling/
10:58 <vmassol> well you shell that to yourself because you introduced the change :)
10:58 <vmassol> *should tell
10:58 <vmassol> so better check it out
10:59 <vmassol> all places that calls Tx diretly
10:59 <tmortagne> again Denis introduced it
10:59 <tmortagne> if you don't want to do it don't do it
10:59 <vmassol> I'm talking about the isoaltion stuff
10:59 <vmassol> velocity isoaltion
10:59 <tmortagne> since you were working on it I tough it was a good thing to check other things to
11:00 <Bugendolf> has quit
11:02 <Denis> When I introduce the RC, I had check out to my best all places that are running transformation, and I was disappointed to see so much duplicated code, but a complete refactoring was out of my reach at that time
11:02 <Denis> hence the cast stuff which was the cleanest way to solve it out for the moment
11:08 <lucaa> has quit
11:08 <Bugendolf> has joined #xwiki
11:10 <vmassol> Denis: ok
11:10 <vmassol> thanks for the explanations
11:15 <vmassol> tmortagne: so if I understand correctly when you create a new TransformationContext you should always pass an id as otherwise there's no open/close done
11:15 <vmassol> so why not make the id part of the constructor and deprecate the current constructors not taking an id, to make it mandaotry?
11:15 <tmortagne> you mean when you call transformationmanager ?
11:15 <vmassol> no I mean when calling new TransformationContet()
11:16 <tmortagne> TransformationContet does not call any start/stop
11:16 <vmassol> AFAICS in XWikiRenderingContext
11:16 <vmassol> if the id is not set then no open/vlose
11:16 <vmassol> yes but with the code in XWikiRenderingContext we kind of require an id or it won't work properly
11:16 <tmortagne> so you are talking about RenderingContext
11:17 <vmassol> I'm talking about user code
11:17 <vmassol> if someone writes new TransformationContext() the nit's likely to not work
11:18 <tmortagne> if you don't give an id it means you want to stay with the current id AFAIK
11:18 <vmassol> ok then all this needs to be documented
11:18 <vmassol> right now when I read the javadoc for Tx I don't understand that
11:18 <vmassol> fixing it
11:19 <vmassol> so our problem is that we're not inside any current Tx
11:19 <vmassol> (and thus no id is set)
11:20 <vmassol> maybe there's a way to check that in our code automatically
11:20 <tmortagne> yes that's RederingContext job
11:21 <tmortagne> it contain the current rendering related properties
11:21 <tmortagne> this is why I suggested you to check it before calling start/stop in my first message
11:22 <vmassol> yes but I don't care here I think
11:23 <vmassol> unless toHTML and parseAndRender are called recusrively
11:23 <lucaa> has joined #xwiki
11:24 <vmassol> ok I'll do the "clean" way just to prove I understand :)
11:26 <tmortagne> vmassol: I don't know much about toHTML but if it's just a helper to convert a XDOM to HTML with macro execution it might be reused by a macro or something
11:27 <tmortagne> the question is more do we want toHTML to be isolated or not
11:27 <vmassol> tmortagne: any best practice for naming a tx id?
11:28 <vmassol> planning to use "wysiwygtxid"
11:30 <tmortagne> we don't really have naming rules right now, the template path is used for template and the document reference for document rendering
11:30 <tmortagne> you don't need to worry about two thread using the same namespace the velocityengine is taking care of that
11:31 <vmassol> yep seen that code
11:43 <vmassol> tmortagne: we're already in a tx actually
11:44 <vmassol> id = "/skins/flamingo/wysiwyginput.vm"
11:44 <vmassol> so it means this tx has not set an id
11:44 <vmassol> or has not called start/stop
11:45 <vmassol> so when we parse a template we create a tx now?
11:45 <tmortagne> "the template path is used for template"
11:46 <tmortagne> there id when executing a template yes
11:46 <vmassol> why is there a Tx when executing a template?
11:46 <vmassol> and how do I differentitate a template tx from other tx?
11:46 <tmortagne> transplates are content executed
11:47 <tmortagne> some are only velocity and some are wiki syntax
11:47 <vmassol> this one is velocity
11:47 <tmortagne> but you still need to indicate what is the current id used
11:47 <vmassol> that's what I don't understand
11:47 <tmortagne> it's the same
11:47 <tmortagne> the transformation id is the id used to execute script
11:47 <vmassol> so the velocity execution goes throgh the Rendering as a Velocity Macro being executed?
11:47 <tmortagne> the source being wiki syntaxe or directly velocity it's the same you still execute something
11:47 <tmortagne> like if you had only a velocity macro in your wiki content
11:48 <tmortagne> it does not create a XDOM no to not spend time on useless stuff but it still properly set the rendering context for anyone to reuse a transformation id, velocity namespace etc
11:49 <vmassol> why is the template exectuion not calling start/stop? imagine there's two velcocity macros in a template?
11:49 <tmortagne> it does
11:50 <vmassol> hmm then I don't understand why the wysiwyg doesn't work
11:50 <tmortagne> no idea, you could put a breakpoint in the velocity engine to see what namespaces are used
11:51 <vmassol> ok I'll debug further
11:51 <tmortagne> but I don't think we want to reuse the template id anyway
11:51 <tmortagne> the WYSIWYF should execute what he want to execute in an isolated way IMO
11:51 <tmortagne> to not pollute the WYSIWYG template
11:51 <vmassol> but we don't have a way to differentiate template tx from non template tx do we?
11:52 <tmortagne> like document rendering use it's own namespace
11:52 <vmassol> ok then we shouldn't do the "if" you suggested right?
11:52 <tmortagne> vmassol: it depends what is executed exactly here
11:52 <vmassol> or we could
11:53 <vmassol> but just to not recreate a new id when the current id is the wysiwyg one
11:53 <vmassol> just in case it's called recursively there after
11:53 <vmassol> i'l do that
11:53 <tmortagne> I suggested a if mostly for the macro transformation to not break anything but maybe the WYSIWYG should force an isolation
11:53 <tmortagne> I don't know exactly the use case
11:53 <vmassol> still going to see what namespace is used. I'm curious
11:55 <tmortagne> vmassol: the id used in practice is the one in the transformation context when executing a velocity macro so the issue is probably with null in the velocity macro
11:55 <tmortagne> what is in the renderingcontext is an information that we try to keep up to date
11:56 <tmortagne> maybe its generating a namespace instead of using the current one
11:57 <vmassol> namespace used is "unknown namespace"
11:57 <tmortagne> probably because of the null in the transformation context indeed then
11:57 <vmassol> yes apprently
11:59 <vmassol> so
11:59 <vmassol> if you don't set an id, even if you're inside a Tx, velocity scripts will be ioslated
12:00 <vmassol> we treat "unknown namespace" in a psecial way?
12:00 <vmassol> (need to check that part)
12:00 <vmassol> apparently not
12:00 <vmassol> hmm then I don't get it
12:01 <vmassol> the 2 velocity macros shoiuld both use "unknown namespace" as their namespace
12:02 <vmassol> tmortagne: I don't understand this code in DefaultVelocityEngine:
12:02 <vmassol> startedUsingMacroNamespaceInternal(namespace);
12:03 <vmassol> ah I understand
12:04 <vmassol> it works because it's a put in a Map so it's not going to create a new "namespace"
12:04 <tmortagne> lunch time, back in 1 or 2h
12:04 <vmassol> so if it's empty then no isolation...
12:38 <gsmeria> has quit
12:44 <Slashman> has joined #xwiki
12:49 <cjd> has quit
12:54 <Guest16855> hello can i hava a help with a problem with xwiki 6.4 after upgrade from 6.3 ?
13:05 <vmassol> Guest16855: hi, you need to state your problem or we won't be able to help you :)
13:31 <Guest16855> ok thanks
13:32 <Guest16855> after upgrade xwiki from 6.3 to 6.4, i have a problem with solr
13:32 <vmassol> yep
13:32 <Guest16855> org.apache.solr.common.SolrException: Error loading class 'org.xwiki.search.solr.internal.XWikiDismaxQParserPlugin'
13:32 <vmassol> http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki64
13:32 <vmassol> it's in red letters to make it easy to notice :)
13:39 <Guest16855> ok thanks it's allright
13:40 <Guest16855> remove solr directory
13:40 <Guest16855> yesterday, i have clean the directory and not delete
13:40 <Guest16855> and in this case, problem
14:03 <lucaa1> has joined #xwiki
14:03 <lucaa> has quit
14:12 <vmassol> Guest16855: ok
14:19 <tmortagne> vmassol: something weird on mail test, maybe you forgot to commit something:
14:19 <tmortagne> [ERROR] /home/hudsonagent/jenkins_root/workspace/xwiki-platform/xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-test/xwiki-platform-mail-test-tests/src/test/it/org/xwiki/mail/test/ui/MailTest.java:[100,21] cannot find symbol symbol: method setDiscardSuccessStatuses(boolean) location: variable sendMailPage of type org.xwiki.mail.test.po.SendMailAdministrationSectionPage
14:19 <vmassol> hmm thanks tmortagne, checking
14:20 <vmassol> it's building fine here
14:21 <vmassol> this means the pageobjets module wasn't built which is strange
14:22 <vmassol> seems to be there though: https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-test/xwiki-platform-mail-test-pageobjects/src/main/java/org/xwiki/mail/test/po/SendMailAdministrationSectionPage.java#L87
14:22 <vmassol> looks like a problem on jenkins somewehre
14:23 <vmassol> but I don't see how it could not build the pageobjects
14:24 <vmassol> apparently it didn't build the pageobjects in this bild
14:24 <vmassol> *build
14:24 <vmassol> at http://ci.xwiki.org/job/xwiki-platform/789/console
14:25 <vmassol> there's a test depednency on it though
14:25 <tmortagne> vmassol: jenkins is configured for partial build so sometimes it fail and then not build what was not built in the previous run
14:25 <vmassol> so I don't know what happened but a full build shuld solve it
14:26 <tmortagne> should be ok if you start platform build by hand, will rebuild the whole thing
14:31 <Guest16855> has quit
14:31 <cjd> has joined #xwiki
14:40 <vmassol> gdelhumeau: errro html export doesn't work at all for me on 7.0, it's just hanging...
14:41 <gdelhumeau> it is very long now
14:41 <vmassol> so that's a bug regression
14:41 <vmassol> it's not usable a tall for me
14:41 <vmassol> I've waited over 1 minute and still nothing
14:41 <vmassol> it used to be immediate, after 1 second
14:42 <tmortagne> gdelhumeau: I can understand the time spend on less build but less build is not 1 minute
14:42 <gdelhumeau> it is compiled multiple times
14:42 <vmassol> and it shouldn't recompile here either
14:43 <vmassol> in any case that's a blocker regression gdelhumeau
14:43 <gdelhumeau> it's better on 6.2.x, maybe some page using LESS in SSX
14:43 <tmortagne> what is the creteria to rebuild it in the same html export ?
14:43 <tmortagne> criteria
14:43 <gdelhumeau> I was hopping that less4j would solve this
14:43 <vmassol> no
14:43 <gdelhumeau> tmortagne: the URL
14:43 <vmassol> no tool will ever solve this
14:43 <gdelhumeau> the url for a CSS is not the same for then main page
14:43 <vmassol> there's an intrinsic problem
14:44 <vmassol> exporting HTML is already a complex process, adding overhead is just not going to to doit
14:44 <tmortagne> gdelhumeau: you mean an URL in the page which is exported ?
14:44 <gdelhumeau> yes
14:44 <tmortagne> why ?
14:45 <Chuguniy> has quit
14:45 <vmassol> my cpu is going crazy too during the export
14:46 <tmortagne> you mean each css included in the page produce a new less build ?
14:46 <gdelhumeau> those which uses LESS
14:46 <tmortagne> in standard it's what ? just style.css ?
14:46 <tmortagne> if I export an empty page in XE for example it generate how many builds ?
14:47 <vmassol> 1 minute 22 seconds
14:47 <vmassol> to export the sandbox.webhome page
14:47 <tmortagne> is it only the first time or nothing is cached ?
14:47 <vmassol> used to be areound 1 second
14:47 <gdelhumeau> everything is explained there: http://jira.xwiki.org/browse/XWIKI-11658#
14:47 <vmassol> I don't understan dhow you can consdier this acceptable/normal gdelhumeau
14:48 <vmassol> ...
14:48 <vmassol> and why it wasn't raised
14:48 <vmassol> is there are jira issue?
14:48 <gdelhumeau> it was good for 6.2.x for which I've made it
14:48 <vmassol> (for the html export)
14:48 <gdelhumeau> but I don't know why 6.4 is so long
14:48 <vmassol> it doesn't that you don't know why
14:48 <vmassol> the minimum to do if you knew bout it
14:48 <vmassol> was to raise a bocker
14:48 <vmassol> *blocker
14:49 <vmassol> do we have a jira issue?
14:49 <gdelhumeau> no
14:49 <vmassol> ok creating one
14:49 <vmassol> sigh… one more blocker :(
14:49 <tmortagne> I'm surprise we don't get a timeout in the HTMLExportTest test if it's that long
14:51 <tmortagne> we should probably put a shorter timeout there
14:52 <vmassol> tmortagne: we should include export performance tests in the test report too maybe?
14:53 <tmortagne> vmassol: a timeout in the automated test would catch it way quicker
14:53 <tmortagne> since we already have such a test
14:53 <vmassol> yes but it'll never work good enough
14:53 <vmassol> if you put a timeout at 3 seconds
14:53 <vmassol> the tests will fail too often
14:54 <vmassol> and if you put it at 30 seconds it's too long, even 3 seconds is too long for exporting 1 pzage
14:54 <vmassol> *âge
14:54 <vmassol> grr
14:54 <vmassol> *page
14:54 <tmortagne> sure but you are talking about something that takes more than 1 minutes here, putting 10 or 20 s should not produce too many false positive
14:54 <tmortagne> it's not going to be less than 3s
14:55 <tmortagne> building less takes 8s itself already
14:55 <vmassol> then we should drop less
14:55 <cjd> you're not making the azerty keyboard seem easy to use
14:55 <vmassol> we cannot penalize all our features becaude of less
14:55 <vmassol> I'm getting seriously pissed by less
14:55 <vmassol> it's a nightmare
14:55 <vmassol> did I say I hate generators :)
14:56 <tmortagne> it's better with less4j according to gdelhumeau but probably still slow
14:56 <vmassol> it's never going to be fast enough
14:56 <tmortagne> but there is probably things we can prebuild, right now we rebuild everything all the time
14:56 <vmassol> one option is to forget dynamcity and precompile stuff
14:57 <gdelhumeau> then it's a regression
14:57 <vmassol> less itself is a regression on the performance aspect in several places
14:57 <tmortagne> gdelhumeau: is thare caching or html export rebuild everything each time ?
14:57 <vmassol> it brings some new feature but at too high a cost ATM
14:57 <tmortagne> we have cache in view and it's dine
14:57 <tmortagne> fine
14:57 <gdelhumeau> tmortagne: no cache
14:57 <gdelhumeau> it used to have one
14:58 <gdelhumeau> but it was breaking icons
14:58 <vmassol> even view is not fine tmortagne, it's taking too long on the first run
14:58 <tmortagne> there is a specific blocker or just do not had time to look at it ?
14:59 <tmortagne> vmassol: it's taking 8s on the very fist run among many other stuff, less is not the only thing happening on first run
14:59 <vmassol> thaty's not tre tmortagne
14:59 <vmassol> your confusing stuff
14:59 <vmassol> the first page accessed
14:59 <vmassol> and when you make changes later on in xobjets
14:59 <vmassol> for example
14:59 <vmassol> or in skin
14:59 <vmassol> so you do get the timeout several times
14:59 <vmassol> it's a pain
15:00 <vmassol> and make xwiki slugglish
15:00 <tmortagne> sure but the skin is not something you modify all the time
15:00 <vmassol> as a feeling
15:01 <tmortagne> not many people experience the first slow run unless your wiki restart all the time
15:01 <vmassol> personally I feel we've regressed because of LESS (in term of overall perf)
15:01 <vmassol> re memory I hope the cache is not taking too much either
15:02 <msmeria> has quit
15:02 <tmortagne> I would not say overall perfs, once it's built it's just css so it's not slowing down the whole thing
15:02 <tmortagne> only the first access is impacted, which is not very nice for devs I agree but not that visible for users
15:03 <tmortagne> but if html export does not cache anything that's another mater
15:03 <tmortagne> I agree that i html export is that slow all the time it's quite bad
15:05 <tmortagne> anyway if gdelhumeau said it was ok in 6.2.x it should be debugged first
15:05 <tmortagne> vmassol: on the memory side I think is a filesystem cache, right gdelhumeau ?
15:06 <gdelhumeau> right
15:06 <gdelhumeau> but we store a mutex for each less ressource
15:06 <tmortagne> sure but a mutex is nothing
15:07 <vmassol> ok that's good if it's not taking memory
16:04 <tmortagne> 6.4.1 will be welcome indeed
16:05 <vmassol> :(
16:05 <vmassol> I have the feeling we're generating lots of bugs/regressions
16:06 <vmassol> we're surely missing tests
16:06 <vmassol> we need to improve and get better, it's taking too long to stabilize ATM
16:09 <tmortagne> or we rush too much during BFD (the issue vrachieru fixed was a typo introduce in a BFD issue)
16:10 <vmassol> yes we definitely rush too much by not taking the time to always have a test to prove that what is fixed will continue to work thereafter
16:10 <vmassol> (I know I've done this mistake myself several time in order to do more issues....)
16:34 <KermitTheFragger> has quit
16:49 <Chuguniy> has joined #xwiki
16:55 <RamonaConoro> has quit
17:04 <tmortagne> has quit
17:21 <Bugen_do> has joined #xwiki
18:01 <gdelhumeau> has quit
18:04 <fmancinelli> has quit
18:07 <cjd> has quit
18:22 <lucaa1> has quit
18:27 <tmortagne> has joined #xwiki
18:34 <woshilapin> has quit
18:41 <vmassol> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-remote-resources-plugin:1.4:process (xwiki-license-resources) on project xwiki-enterprise: Resources archive cannot be found. Could not find artifact org.xwiki.commons:xwiki-commons-tool-license-resources:jar:7.0-SNAPSHOT
18:41 <vmassol> [ERROR]
18:41 <vmassol> oops
18:41 <vmassol> sorry
18:41 <vmassol> bazd paste
18:43 <mflorea> has quit
19:19 <sdumitriu> has quit
19:24 <sdumitriu> has joined #xwiki
19:40 <tmortagne> has quit
19:47 <Slashman> has quit
20:15 <lucaa> has joined #xwiki
20:48 <momomomomo> has joined #xwiki
20:56 <bblfish_> has joined #xwiki
21:01 <fmancinelli> has joined #xwiki
21:08 <Bugen_do> has quit
21:29 <kyndel> has joined #xwiki
21:30 <kyndel> Hello. I have a new wiki on the wikifarm and I'm wondering how to make it viewable without being logged in
22:01 <lucaa> has quit
22:19 <momomomomo> has quit
22:30 <momomomomo> has joined #xwiki
22:52 <vmassol> kyndel: what wikifarm?
22:52 <vmassol> (Hi)
22:53 <vmassol> has quit
23:11 <kyndel> myxwiki.org
23:12 <kyndel> also, how do i make a page horizontally scrollable, so if i have a really big table it doens't squish all the rows
23:19 <kyndel> or rather, how do i increase the minimum row width
23:21 <bblfish_> has quit
23:34 <sburjan> has quit
23:37 <kyndel> also, how do i edit the wiki description i see in the "Wiki Information" Gadget??
23:39 <sburjan> has joined #xwiki
23:39 <fmancinelli> has quit
23:43 <vrachieru> has quit
