#foswiki 2016-02-13,Sat

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
gac410hi vrurg. I *think* so [00:07]
vrurghttp://foswiki.org/Tasks/Item13897 – I've just finished describing the problem here. [00:08]
gac410The process of parsing the topic meta into a form usable in query / formfield / search macros is very expensive. So MetaCache tries to do that process once [00:08]
vrurggac410: I know. The problem is a bit complicated. Previously Foswiki relied upon manually called finish() methods. [00:08]
gac410Michael was trying at one point to push process into Store, but that saves the Read I/O, not the cost of parsing it all apart.
It was *extremely* important to query performance.
[00:08]
vrurgIt has to be automated, so I rely on Moo's DEMOLISH called upon object destruction. As I'm no ready to take care of all finish methods I simply call them from Foswiki::Object::DEMOLISH. [00:09]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Object::DEMOLISH [00:09]
gac410I know there are other proposals to try to untangle Meta into other object. read only version, etc. I don't really understand it all. [00:10]
vrurgAs a result, wile SEARCH is wokring deeply inside there is a call to haveAccess() which loads a web meta which gets destroyed upon haveAccess return – and cleans up the whole metacache.
I'm trying to find a way to fix it. But so far only implemented a workaround which is working but I don't really like it.
[00:11]
gac410The MetaCache impact was a complex query search of Lavr's took page load from 61 seconds, down to 17 seconds, brought 2.0 into line with 1.1.9 performance. [00:13]
vrurgBTW, this workaround has already broke another test, it seems. [00:13]
gac410y. the objective is to really only parse a topic for it's meta once. Cache should be if possible loaded once and destroyed at end of transaction. [00:14]
vrurggac410: It still works... Or it works again – I spent few days tracing down the problem. ;) [00:14]
gac410y. It was pretty complex, it was only luck I found the bug - patched in https://github.com/foswiki/distro/commit/4e7a76058509
gac410 wonders if it's really implemented in the wrong place. called by various Search routines, but not by Meta. It seems to be that Meta ought to cache itself.
seems to me
[00:15]
vrurgOk, perhaps it's not a subject for irc. I still cannot find enough time and power to start the proposal we talked about on the last release meeting. But it now loks like MetaCache would be a good subject for that topic too.
gac410: I think that we may need a universal Cache class which knows nothing about the type of objects it stores. It has only be told by external code that 'I would put this object with this ID here' and 'I withdraw object with this ID'. Cache would only count former and latter requests and when the balance come to 0 simply deletes corresponding key. Basic and clean. There are implementation details, which I do not consider here.
[00:19]
gac410We have a lot of caches all over the place. HtPasswdUser caches the .htpasswd file - but across transactions. Ldap caches mappings. TopicUserMapping caches mappings but only for the life of the transaction .
some are quite specialized. like in mapper. login->cUID, cUID->login cUID-WikiName ... a whole bunch of combinations.
[00:24]
vrurggac410: I think it's all could be under control of a common cache. Different subsystems may register their own storages or use a kind of path as a part of object ID – whatever. In either way any cache is about 'keep it while we need it'. Other functionality could be delegated to the subsystems.
I think this way it should be easier to control the code.
vrurg put it on the TODO list.
[00:28]
dldl-workcan I get the parent web name somehow? [00:30]
gac410yeah. makes sense. When you register something to the cache, specify the "life" - transaction or "until reset" (like .htpasswd file - cached until update of the file is detected.
dldl-work: Probably have to parse apart the %WEB% which is parent/parent/web
[00:31]
vrurggac410: Kind of, right. For .htpasswd – there should be third method in addition to add/remove – overwrite or refresh.
Ok, I wanna fix one more problem before leaving home.
[00:34]
gac410ldap would probably be similar to the .htpassd. Probably the only one that doesn't count is the PageCache, which isn't stored in memory, but is indexed in a database, and stored on disk. [00:35]
vrurggac410: Cache may store objects representing cached pages. So, eventually it's still uniform interface. The only question here is how simple and practical this particular implementaiton will be. But then again – it will depend on many factors. [00:39]
...................... (idle for 1h46mn)
gac410vrurg, There is an old parked proposal that talked some about the current Meta / Store interaction ... Foswiki:Development/SimplifyTheStoreMetaSemantics [02:25]
FoswikiBothttp://foswiki.org/Development/SimplifyTheStoreMetaSemantics [ SimplifyTheStoreMetaSemantics ] [02:25]
***ChanServ sets mode: +o Lynnwood [02:26]
..................................................................... (idle for 5h42mn)
ChanServ sets mode: +o CDot [08:08]
.................................................................. (idle for 5h28mn)
ChanServ sets mode: +o gac410 [13:36]
........................................................................................ (idle for 7h18mn)
foswiki_irc4hello [20:54]
................. (idle for 1h22mn)
gac410hello foswiki_irc4 [22:16]
***ChanServ sets mode: +o Lynnwood__ [22:22]
foswiki_irc4hello gac410 [22:33]
gac410howdy ... Do you have some questions? [22:34]
foswiki_irc4yes ;-)
i found that after a page's edited and the <!-- and --> are saved as &lt;-- and --&gt;, which are displayed on the page along with what's included with them.
[22:34]
gac410What version of foswiki, which editor? [22:37]
foswiki_irc42.0.1
from the Edit button
[22:37]
gac410So that's probably the Wysiwyg editor - TinyMCE. Yes, if you type in a < you will indeed see a < when viewing the page. If you want to enter html, you can use the plain text editor, (Link on lower right of page) [22:38]
foswiki_irc4sorry 2.0.2 [22:38]
gac410edit wiki text. [22:38]
foswiki_irc4okay. i'll try that. another question. [22:39]
gac410With the WYSIWYG editor, you can highlight the <html...> and format it as "PROTECT FOREVER" with the drop down menu [22:40]
foswiki_irc4we just wanted to comment out some texts with <!-- and -->.
but when < turned to &lt; and > turned to &gt;, they lost their function.
[22:40]
gac410Yes, that should work fine. Just be careful, <!-- --> must never "nest" that will break things. You can't to <!-- some big block with embedded <!-- comments --> and other stuff -->
That's a limitation of html, not foswiki.
[22:42]
foswiki_irc4not nested. [22:42]
gac410okay. Sometimes that catches you unaware. <!-- some stuff %INCLUDE{"anotherTopic"}% ... --> if that included topic contains <!-- it will break as well. [22:43]
foswiki_irc4the saved file should have <!-- ... -->, but instead they are &lt;!-- ... --&gt; [22:43]
gac410As I said, with Wysiwyg editor, you have to enter <!-- highlight it, and mark it "PROTECT FOREVER" [22:44]
foswiki_irc4there're just several english words between them. it's the conversion which i think shouldn't be done.
okay.
the other question.
[22:44]
gac410WYSIWYG. What you see is what you get. You enter <!-- --> and you will SEE <!-- --> when viewing the page [22:45]
foswiki_irc4understood. [22:46]
gac410next question ? [22:46]
foswiki_irc4i saw a warning on pages that saying updates found for x extension(s). Upgrade Ignore for 7 days.
what i should do?
[22:48]
gac410Okay, yeah that's the "UpdatesPlugin" you can just click ignore.
Some of the updated extensions have some compatibility challenges, so don't just do a quick update blast from configure
Only AdminUsers see that warning. If you really don't want them, disable the UpdatesPlugin
[22:48]
foswiki_irc4when i clicked Upgrade, i got to a page with actions to be done.
how to disable the updatesplugin?
my account is in the admingroup
[22:49]
gac410In bin/configure, on the Extensions tab, you can scroll down, un-check the UpdatesPlugin and save. [22:50]
foswiki_irc4okay. [22:51]
gac410Of course if you are not the server admin, probably not a good idea to go in to configure disabling extensions :D [22:51]
foswiki_irc4where is the drop down menu? for PROTECT FOREVER [22:54]
gac410upper left corner of the editor, shows "format" by default,
the protect forever is one of the formats.
Sorry, it's not all caps.
just "Protect forever" I was thinking of a couple of the others that are all caps
[22:54]
foswiki_irc4saw it. i didn't scroll down to the bottom. [22:56]
gac410Looks like you could also use "protect on save" ... in this case seems to do the same thing.
For simple things like comments <!-- ... protect on save is sufficient. protect forever will add some special <sticky><!-- your comment --> </sticky> markup into the topic.
[22:57]
foswiki_irc4okay. it only affect hightlighted portion or the whole page? [22:59]
gac410It only affects the highlighted portion. [23:00]
foswiki_irc4okay [23:00]
when i unchecked updatesplugin and click save, a confirmation window popped out.
but the text says save changes to: {Plugins}{UpdatesPlugin}{Enabled}
[23:05]
........ (idle for 38mn)
JaniHis there a "clean" copy of style.css and colors.css available? the ones I've got do not seem to have any line breaks (or maybe i'm ignorant on how things are done) [23:45]
gac410look for the same name file but either with "uncompressed" in the name, or _src in the name [23:47]
JaniHoh wow. thanks.
i was set on the task of cleaning but this is great :)
[23:47]
gac410All of the javascript and css are shipped in both uncompressed format, and in a "minified" and compressed format. [23:48]
JaniHis there a reason this is done? just curious why not just use the nicely spaced css? [23:49]
vrurgJaniH: this way load time is reduced. [23:56]
JaniHvrurg: thanks. good to know :) [23:57]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)