#foswiki 2013-11-15,Fri

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

WhoWhatWhen
pharveyIt must be friday. The log events I want to make greppable are marked "I AM PROBABLY SPARTACUS" [01:02]
........... (idle for 51mn)
***TimL has left [01:53]
................................................ (idle for 3h59mn)
gac410 has left [05:52]
............... (idle for 1h10mn)
ChanServ sets mode: +o CDot [07:02]
ChanServ sets mode: +o MichaelDaum [07:13]
............ (idle for 58mn)
GuilainC1Hello everybody, does any one have already try to integrate greenshot and foswiki , by a specific plugin, or by using external program ? [08:11]
...... (idle for 25mn)
CDotDoes anyone know where the scripts are that run the nightly unit tests?
MichaelDaum: SvenDowideit: any ideas? I can't find them anywhere in svn
one of the escripts is (I assume) disabling the TinyMCE JQuery plugin, which is what is killing the nightly test runs
[08:36]
MichaelDaumHm George checked in something svn-ish recently, scripts that sync svn to github. [08:40]
CDotwhen I run the tests normally, they don't fail (the plugin is not disabled) so it has to be something in the test server
of course, you *could* argue that an error message in a <div> in the <head> is a genuine failure
CDot is debating making it a <script> instead
but that still doesn't explain why the tests fail on Florian's server, but not when I run them.
[08:40]
MichaelDaumFlorian? who's that? [08:42]
CDotthe nice person who provides our unit test server [08:42]
MichaelDaumargh my radar [08:43]
CDotand sends you mail every day about failures
which of course you read assiduously
[08:43]
MichaelDaumfschlicht [08:44]
CDotI can't find anything in svn that looks like scripts for running the tests on a nightly server
so I have a horrible feeling they are not there :-(
[08:44]
MichaelDaumemail him? [08:45]
CDotthat's the next step. Thought I'd ask here first.
hmmm, I don't have an email address for him
found it
[08:46]
MichaelDaumMichaelDaum rebooting into a new kernel [09:02]
***ChanServ sets mode: +o MichaelDaum [09:14]
.... (idle for 16mn)
SvenDowideitCDot, yes, they are in svn
well 'it' has been for the entire time its existed
[09:30]
CDotoooh, what a tease! Where? [09:30]
SvenDowideitand i'll bet its called something like nightly [09:30]
CDotnope [09:30]
SvenDowideitnoidea, i don't have a foswiki atm [09:30]
CDotI found "tools/distro/test.pl" but it looks very old
I asked Florian, hopefully he'll let me know what they are running.
[09:31]
SvenDowideithttps://github.com/foswiki/core/blob/master/tools/autoBuildFoswiki.pl
er, CDot was that url obvious enough?
or did i lose net connection
[09:32]
CDotdunno - not looked yet
the name is a bit obscure, given that I was looking for test runs, but it'll do :-)
innersting - it does nothing special for the test run
[09:33]
SvenDowideitit does one thing
is assumes a very clean checkout
[09:35]
CDottrue, very true [09:36]
SvenDowideitand then only uses pseudo-install [09:36]
CDotwell, both of those are true of the local checkout I'm trying here [09:36]
SvenDowideitwith my retentive attitude that if the devs can't keep pseudo-install working , they need to be shot [09:36]
CDotmaybe I'm missing something :-/ [09:36]
SvenDowideiti also use a very minimal vm
so nothing nice is installed
[09:37]
CDotshouldn't matter, I don;t think [09:37]
SvenDowideitif i were to work on it today, it'd be a docker container
it does
we've revealed lots of hidden dependencies this way
[09:37]
CDotI doubt it matters to TinyMCE, which is the problem here [09:37]
SvenDowideitand crap code that hides a use in an eval [09:37]
CDotsomehow the TinyMCE JQuery plugin is getting disabled, and I can't see how
the plugin intself is installed and enabled correctly; no problem there
it's the *JQuery* part of it that gets disabled somehow
CDot starts again with a completely fresh checkout, just in case
[09:38]
SvenDowideitSvenDowideit wonders if CDot has some ENV vars he sets in his bashrc
cos i refuse to set any - and we've bumped that once or twice
[09:40]
CDothmmm. I don't think so, but I'll toothcomb them. [09:41]
SvenDowideit(must admit, i also have a user that i use to run the tests
that doesn't get used for anything else
[09:41]
CDotI may do that. We'll see. [09:48]
MichaelDaumwhat do you think about this multiple-disks feature twiki recently added?
MichaelDaum not sure what it is ... just got a vague idea
[09:54]
CDotdidn't see it.
CDot doesn't read their checkins very often
sounds like something that allows you to split the store over different disks; though that's pure guess, and I have no idea why you'd need to change code to do that, since I do it all the time.
[09:59]
MichaelDaumyes thats what I got as well.
my question: why should twiki care about the number of disks?
sounds like poor man's sharding
[10:04]
CDotlord knows; unless you want to interactively specify where a web gets saved
pure guess
[10:06]
MichaelDaumaren't there filesystems that are opaque in this regard
a single fs on the front // multiple disks where it lives on
isnt that called raid zero
[10:07]
CDotaha! finally! managed to repro the <div> bug [10:08]
MichaelDaumnow twiki is running over all kinds of plugins that interact with /pub directly and make it work with their multi-disk feature. [10:08]
CDotat the simplest level, you can simply soft-link dirs on different disks [10:09]
MichaelDaumspot on [10:09]
CDotor mount disks in place of webs [10:09]
MichaelDaumyea etc
so what are we missing here
[10:09]
CDotdunno. /me svn updates his twiki scrapyard [10:10]
MichaelDaumone other more intelligent way to scale cross several disks or even better servers would be to make %PUBURL a real macro, i.e. aware of the context it is being used for. [10:12]
CDotFrom their doc: "Having additional disks and putting symbolic links under !PubDir for some webs to off-load the primary disk doesn't work.
This is because when a topic is deleted, =topic.txt= and =topic.txt,v= are moved from =DataDir/WEB= to the =DataDir/Trash=. And the =PubDir/WEB/topic= directory is moved to =PubDir/Trash=. If =PubDir/WEB= is a symbolic link a different disk, then moving =PubDir/WEB/topic= to =PubDir/Trash= fails."
[10:14]
MichaelDaumsome use cases are (1) different server per file type, e.g. a streaming server for flv videos (2) webdav enabled servers for office documents (3) link into a 3rd party DMS like Alfresco (4) link to an older revision
The move to Trash argument is pretty weak imho. You'd have a trash per disk. That's what desktop move-to-trash impls do.
[10:15]
CDotCDot is puzzled by that, as he's never encountered a problem with soft-linking wbes [10:16]
MichaelDaummoving across disk means heavy io.
moving within the same disk means altering an inode only
which of course only matters for large files
[10:16]
CDotyeah, but how often is it done? Very rarely [10:17]
MichaelDauma trash per web impl makes much more sense [10:17]
CDottheir solution is very heavy, judging from the code.
yes, trash-per-web is essential for proper recovery of dead revs anyway
moving to a trash web was always a hack
CDot has never been faced with a burning need to fix that, however
[10:17]
MichaelDaummost of it should be hidden behind the specific store impl ... a separate trash code makes only sense for one specific kind of store
if your docs are on a google drive, you better don't move them to the Trash web.
instead they should be moved to the trash on the google drive
our current Trash impl somewhat adds the web the object came from to its name ... for topics
hacky
andreli and his crew maintain a large foswiki instance on afs...he might have some other arguments for or against twiki's multi-disk approach
[10:19]
CDotyeah, Trash is hacky - but as I said, no-one ever complained, so I never bothered to fix it.
I always felt that Trash should be handled on a per-topic basis, and as you say, hidden behind the store interface
I like the idea of a macro for PUBURL. My current solutions for that problem are all based in the webserver (redirect rules etc)
[10:26]
MichaelDauma PUBURL macro isn't hard to implement just as a starter [10:30]
CDotyeah, following the same route as I used for %SCRIPTURL{...}% [10:32]
MichaelDaum%PUBURL{"web.topic" file="name" rev="123" mode="relative"}% [10:32]
CDotI wish I'd added topic="" to %SCRIPTURL [10:32]
MichaelDaum%PUBURL{"filename" topic="web.topic" rev="123" mode="relative"}% [10:32]
CDot%SCRIPTURL{"edit" topic="BlahBlah"}%
erm, actually, I did, didn't I?
[10:33]
MichaelDaum:) [10:33]
CDotjust never tried it....
no, I didn't, Thought I had :-(
that should be done at the same time as %PUBURL{}%
[10:33]
MichaelDaumlet's go for it [10:39]
CDotok, I understand what's going on with the test runs. The basic problem is that the unit tests don't load the default configuration from the standard plugins.
becuase the TMCE JQplugin is enabled from config.spec, and not from the default LocalSite.cfg
the standard plugins are enabled by the test runner, but *not* the jquery plugins associated with them
hmmm. That really needs to be done better.
[10:39]
MichaelDaumSvenDowideit, do you mind me converting JQDataTablesPlugin to a Contrib? [10:41]
CDotalso, the JQueryPlugin needs to report errors using <script> instead of <div> [10:41]
MichaelDaumis it a JQREQUIRE macro call?
if so then a warn="off" would suppress any foswikiAlert div
[10:41]
CDotI don't know. But supressing it is not a solution; it's generating a <div> inside the <head> which is bad.
if it generated <script>alert(""}</script> instead, it would be OK
as well as being more "in your face"
[10:42]
jastthere seems to be a small bug in configure's dependency checker
a dependency on, say, Foswiki::Contrib::ModacSkin makes configure try to install Foswiki::Contrib::ModacSkinContrib
[10:45]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Contrib::ModacSkin http://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Contrib::ModacSkinContrib [10:46]
jastyes, thank you, bot [10:46]
CDotjast: release configure, or trunk? [10:47]
jastrelease
haven't checked trunk, probably the same
[10:47]
CDotCDot loses interest, as he's deep in trunk ATM [10:47]
jastyeah, trunk does the same thing [10:48]
I believe this should be changed [10:56]
MichaelDaumMichaelDaum loves dependencies on a skin pkg ;) [10:59]
***ChanServ sets mode: +o Lynnwood [11:00]
jastit's not exactly a common use case, of course, but extremely convenient for an extension à la debian's virtual packages, i.e. an extension that only serves to install a big set of extensions in one go
if you set up a lot of similar wikis, this helps a lot with eliminating mistakes in the procedure
anyway, submitted as Item12658
[11:02]
FoswikiBothttp://foswiki.org/Tasks/Item12658 [ Item12658: Configure: DEPENDENCIES for skins don't work as expected ] [11:04]
........... (idle for 53mn)
jastMichaelDaum: have you tried using a wiki yet with both LDAP and TopicUserMapping-based accounts? [11:57]
MichaelDaumrarely [11:58]
jastthe code looks like it should work, but the mapping fails for TUM users [11:58]
MichaelDaumthis is a dirty area [11:58]
jastwe now have a customer with special IT policies, so they're probably going to need both [11:58]
MichaelDaumLdapContrib needs a bit of a rewrite to make that work properly for everybody [11:59]
jastdo you know of a concrete missing thing? in any case I could probably get them to sponsor fixes [11:59]
MichaelDaumI am all open for this. [11:59]
jastwith the added complication that our fork of LdapContrib is still based on an ancient version... and I still haven't gotten around to syncing it and contributing back our changes :(
but first, lunch break :)
[11:59]
MichaelDaumwhat I'd like to see is: LdapContrib.pm not inherit from TUM.pm. This caused serious performance problems for 1&1 as their Main Web was searched for non-existing TUM users for no good reason.
There is a notion of a secondary component to delegate requests to in case the user wasn't found in LDAP.
this however hard-codes a search order among both: first search ldap, then search the main web.
I can't see how to support a reverse search order using LdapContrib; it might not even be required for your normal LDAP use cases.
so short term would be: separate both LDAP and TUM in a clear way; then integrate both in a cleaner fashion as your client requires.
long term would be a refactoring of Foswikis user code to improve pluggability of a list authentication and identification modules.
{AuthService} = ['ldap1', 'ldap2', 'tum', 'facebook', 'twitter']
[12:00]
........ (idle for 37mn)
jastyeah, that would be nice for sure
in the meantime you could technically do it with 'proxy' user mappings etc.
i.e. a GenericUserMapping that is configured to use various other mappings in turn
pretty kludgy, though
[12:42]
HendrikKoehleri have installed the MediaWikiToFoswikiContrib extension to import MediaWiki XML dumps but when I run "./mediawiki2foswiki --file credativ-20131115094641.xml --web MediaWiki --language de --plugin ../lib/Foswiki/Contrib/MediaWikiToFoswikiContrib/Converter.pm", this happens:
http://pastebin.com/JUvLV6Vp
i have no idea what "Having no space between pattern and following word is deprecated" is supposed to mean and google isn't being helpful
[12:48]
.... (idle for 17mn)
jasthum, what version of perl are you using?
(perl -v)
actually, never mind. I'm going to have a quick look a that, hang on...
[13:05]
HendrikKoehler(v5.14.2) built for x86_64-linux-gnu-thread-multi [13:08]
jastohh
the --plugin argument doesn't want paths
and the one you're trying to pass is loaded automatically, anyway
IOW, try without the --plugin arg
[13:10]
HendrikKoehleroh i was hoping the plugin switch would solve a problem i'm having without it [13:11]
jastsadly, no. :) Converter.pm is what's loading the plugin in the first place, so if your arg had worked, it'd just have made Converter.pm load Converter.pm :) [13:12]
HendrikKoehlerhaha ok
but i get the same error when trying to load a different plugin
like FoswikiPedia.pm
in the same directory
wow
i just found out that no matter what argument i pass to the --plugin switch, the error is always the same
but it does work if i omit the swith completely
[13:14]
does this mean that the Converter.pm isn't used unless the --plugin switch is given? that would explain why special characters like umlauts aren't converted correctly when omitting the switch. [13:24]
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/ffdHOg
foswiki/master 00eb292 CrawfordCurrie: Item12656: add config for plugins that is missing from default LocalSite.cfg, and fix JQueryPlugin error messages so they don't break the HTML validation tests...
[13:30]
***GithubBot has left [13:30]
FoswikiBothttp://foswiki.org/Tasks/Item12656 [ Item12656: Unit tests fail when run in a clean checkout ] [13:30]
MichaelDaumCDot, alert()s are pretty annoying. plus they stop all of the page being processed.
therefore I'd prefer to use something else
INCLUDE's warn parameter comes to my mind. It either takes a boolean (on or of) ... or any other string that is displayed in case of an error
%INCLUDE{"DoesNotExist" warn="return something else"}%
I am not sure where exactly the tinymce is added to the head. is it from within a template or via perl?
[13:33]
***ChanServ sets mode: +o gac410 [13:48]
gac410CDot: Did you get your script question asnwered
They fail because of an un-met perl dependency on the the system.
[13:49]
CDotyes, thanks. Though Florian tells me he's not running the script in subversion, but a homebrew
MichaelDaum: I used alerts because (1) hey are pretty annoying and (2) they stop the page being processed. That's how you get mindshare to get problems fixed.
[13:49]
MichaelDaumI don't like users being annoyed [13:50]
gac410One of the many 1.2 issues .. .we need to figure out what to do about the dependency ... I initially added it as part of LogDispatch, and Sven picked it pu in core, though I don't recall which one. [13:51]
CDotit's nothing to do with TinyMCE (any more). it's ageneral problem with the way jquery works. It resolves all the includes in the <head>, so that's where it outputs any errors
you could cook something more complex to delay the error until $(document).ready(), I guess
but there are obviious risks to that.
[13:51]
MichaelDaumnot when you add a %JQREQUIRE to the topic. It produces an inline alert there. as thats where the error came from. [13:52]
CDotso why was it output in the <head>? [13:52]
MichaelDaum%JQREQUIRE either injects stuff to the head _or_ expands to an inline alert.
i.e. the location of the JQREQUIRE doesn't matter
[13:52]
CDotso perhaps it needs to check {Enabled} earlier [13:53]
MichaelDaumwhere is jquery.tinymce called?
added to the page I mean
[13:53]
***HendrikKoehler has left [13:53]
CDotno idea
somewhere in the templates, I assume
[13:53]
MichaelDaumis it a call on perl level or is it in the templates? [13:53]
CDottemplates AFAIK. I don't know, I don't think I coded it. [13:54]
MichaelDaumif it is in the templates then the fix is a lot more simple: move %JQREQUIRE out of the <head> and insert it somewhere else inside the <body> [13:54]
CDot*this* *is* *not* *a* *problem* *with* *tmce*. It's a general problem with JQueryPlugin [13:54]
MichaelDaumaha, why? [13:55]
CDotin that it can produce error messages when processing the <head> [13:55]
MichaelDaumthen don't put the %JQREQUIRE call inside the <head> [13:55]
CDotand to date, those messages were in <div> [13:55]
jastgac410: doesn't JQREQUIRE use addToZone or something?
whoops, wrong nick, sorry
[13:55]
MichaelDaumjast, right. [13:55]
jasthi gac410 :) [13:55]
gac410good morning er... or whatever [13:56]
MichaelDaumit is there to let you add stuff to a _distant_ place ... like the <head> [13:56]
jastyeah [13:56]
CDotI have no problem with that, so long as it's documented that that's what you have to do. [13:56]
jastso JQREQUIRE expands to an error if it fails? [13:56]
CDotit expands to an alert() now [13:56]
MichaelDaum... which is no good idea, CDot, really. [13:57]
CDotit's a good idea, really. [13:57]
MichaelDaumcan't we cook up something better, please. [13:57]
jastit's not a good idea when 50 customers call us because an extension developer screwed something up [13:57]
CDotthen find a better solution [13:57]
jastin any case, it shouldn't be a big deal to point out in the docs for JQREQUIRE that it shouldn't be used in <head> [13:58]
MichaelDaumI would, but my grep foo is missing the JQREQUIRE tinymce [13:58]
CDotCDot has done all he can. He fixed the problem in the unit tests; the JQueryPlugin issue was a side problem only. [13:58]
MichaelDaumCDot, it would help to calm down [13:58]
CDotif you fix tmce, you only fix tmce. You leave the problem for the next person to find. [13:58]
jastgac410: I added Item12658 which I think would be a good (and fairly low-impact) addition to 1.1.9. what's your take on it? [13:59]
FoswikiBothttp://foswiki.org/Tasks/Item12658 [ Item12658: Configure: DEPENDENCIES for skins don't work as expected ] [13:59]
MichaelDaumMichaelDaum wonders what's going on somethimes :( [13:59]
gac410jast, how critical... I really didn't want to make changes in that I need to then build RC4 and let it cook one more time.
I figure the Release should be identical to the final Release Candidate. It is the candidate :)
[14:00]
jastit's not critical, just inconvenient for our provisioning process
so, how about this: postpone it unless something important comes up that requires a new RC anyway
(which is probably equivalent to "postpone it" :))
[14:00]
gac410I've gotten no other feedback about 1.1.9 yet, but my plan is to build (well rebuild) r17089 as 1.1.9 on monday [14:02]
jastall right
I've taken it out of 1.1.9, and I'll put it back only if it turns out we need to make another RC anyway because of something else
[14:02]
***HendrikKoehler has left [14:05]
gac410So the bug is in Foswiki::Configure::Dependency ? [14:05]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Configure::Dependency [14:05]
jastit's in Foswiki::Configure::Package, actually [14:06]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Configure::Package [14:06]
jastin ->checkDependencies [14:06]
gac410So *Skin should be a 3rd accepted type ..
if ( $dep->{module} =~ m/^(Foswiki|TWiki)::(Contrib|Plugins|Skin)::(\w*)/ ) {
[14:09]
jastI think so, yes [14:09]
gac410hm... There are other tests for Plugin|Contrib ... it also effects were foswiki looks for / loads the Config.spec file I think.
There is another task I vaguely recall about skin packages being not properly recognized.
[14:13]
GithubBot[foswiki] FoswikiBot pushed 2 new commits to master: http://git.io/ttCzRg
foswiki/master 0938486 MichaelDaum: Item12656: make it an inline error again not to annoy users with javascript popups; there's a better fix for TinyMCE...
foswiki/master 4bb4ea1 MichaelDaum: Item12656: use the perl api to load jquery instead of TML ...
[14:14]
***GithubBot has left [14:14]
FoswikiBothttp://foswiki.org/Tasks/Item12656 [ Item12656: Unit tests fail when run in a clean checkout ] [14:14]
gac410Now I can't find it of course. But I think there is more to this than just the Dependency check. [14:16]
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/DdnEcA
foswiki/master 19b0c9b MichaelDaum: Item12656: fixed documentation...
[14:29]
***GithubBot has left [14:29]
gac410gac410 pulls hair. I cannot find it. Checked Development and Tasks web. I hate it when I'm sure I remember another issue and just cannot find it. [14:31]
...... (idle for 25mn)
***ms- has left [14:56]
....... (idle for 31mn)
jastgac410: I *think* everything else about Skins works fine
but I haven't tested Config.spec
Config.spec doesn't make that much sense for skins, I suppose
[15:27]
............ (idle for 59mn)
MichaelDaumargh, jast, I just found out that IE9 doesn't like self-closing <p />s
thankfully newer foswikies render empty lines as <p></p> ... not as <p /> as it was ages before
for IE9 <p /> and <p></p> is _NOT_ equivalent
the DOM tree that the parser creates seems to mess up parent-child relations among nodes
so $this.closest("form").submit() fails when there's a <p /> between $this and the surrounding <form> element ... and the submit() fails.
[16:28]
ModAcOstfirefox complains about <p /> too
Treats it as <p>
[16:36]
...... (idle for 29mn)
MichaelDaumyea but its resulting DOM is okay
IE9 somewhat gets further parents wrong. I mean parent nodes not being found even though the code is proper xhtml? thats starker tobak.
[17:06]
........................................................ (idle for 4h37mn)
GuilainC1GuilainC1 understand nothing about using jqueryform...
any help should be appreciate...
[21:43]

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