#foswiki 2013-06-04,Tue

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

WhoWhatWhen
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/66EDAA
foswiki/master a9d2bd2 SvenDowideit: Item12510: tiny doc change, and fix to error logged when running from command line...
[00:52]
***GithubBot has left [00:52]
FoswikiBothttp://foswiki.org/Tasks/Item12510 [ Item12510: IpBaseUserMappingContrib ] [00:52]
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/tYJV0w
foswiki/master 47d55ef SvenDowideit: Item12510: remove unwanted file from manifest...
[01:06]
***GithubBot has left [01:06]
..................................................... (idle for 4h20mn)
ChanServ sets mode: +o CDot [05:26]
.............. (idle for 1h8mn)
ChanServ sets mode: +o MichaelDaum [06:34]
.... (idle for 19mn)
ChanServ sets mode: +o MichaelDaum [06:53]
......... (idle for 42mn)
jast[[#stupid.anchor][hi]] interprets the anchor as a Web.Topic thing. any idea how to fix?
I'm not spectacularly familiar with the Render code
actually I guess it's [[#Stupid.Anchor][...]]
[07:35]
I think I've got a fix
but it breaks a test case :(
ah, right. $Foswiki::regex{anchorRegex} doesn't allow '.' characters in anchors, but Foswiki does generate that character in anchors for headings if the heading's text contains any
adding '.' to the allowed characters passes all FormattingTests and produces more appropriate behaviour IMO
[07:44]
they're technically legal in URI fragments, too [07:56]
technically the following characters are valid in fragments besides alphanumeric chars and percent-encoded chars: /?-._~!$&'()*+,;=:@
there might be some HTML-specific restrictions, but ._-: definitely stay valid
In XML applications, fragment identifiers in a certain syntax can be XPointers; for example, the fragment identifier in the URI http://www.example.org/foo.xml#xpointer(//Rube) refers to all XML elements named "Rube" in the document identified by the URI http://www.example.org/foo.xml.
crazy standards :)
[08:06]
............... (idle for 1h11mn)
***ChanServ sets mode: +o Lynnwood [09:21]
................... (idle for 1h33mn)
pharveyjast: I've wanted to tear apart Foswiki::Render for ages... [10:54]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Render [10:54]
............... (idle for 1h10mn)
***ChanServ sets mode: +o gac410 [12:04]
jastsubmitted as Item12526. if nobody objects, I'll commit a change to anchorRegex and a regression test. [12:12]
FoswikiBothttp://foswiki.org/Tasks/Item12526 [ Item12526: Bracketed links don't recognize all anchors generated for TML headings ] [12:12]
jastI don't think anchorRegex is used anywhere but in Render.pm and RedirectPlugin... [12:13]
CDotjast: Render.pm is *the* place. I wouldn't expect there to be any other, to the extend of regarding any other as an error.
Render.pm should (IMHO) be the one and only model of TML. Having said that, I *have* started to tear it apart e.g. Foswiki/Tables
[12:15]
MichaelDaumwould be great to have other renderers as well, in case the content isn't tml but pure html or xml
real content publishing is xml with xsl rendering into html or pdf or rtf
[12:18]
jastright then, I'm gonna commit this
ugh, I haven't updated my svn checkout in forever
[12:20]
MichaelDaumheh ... but your parallel git [12:21]
jastyeah, but it's not a direct git-svn clone so I couldn't commit back from there [12:22]
MichaelDaumbecause git-svn is a pita [12:22]
jastyep
so, what's the policy on fixes like these? commit them to the release branch without asking the release manager?
*this
Cc: gac410 :)
[12:23]
gac410jast. If it's a bug fix, of course. [12:27]
jastI have a tendency to be very careful with this stuff
sometimes bug fixes cause unforeseen interactions
but yeah, in this case it looks pretty safe
[12:28]
gac410I suppose i ought to work on 1.1.9. Passed electrical inspection yesterday. Yay. [12:29]
jastcongrats :) though to be honest, I'm not quite sure what that is
are there no distinct unit tests for trunk vs. Release01x01?
[12:29]
MichaelDaumgac410, would be great to crank out a 1119. [12:29]
jastor is it just conditionals in the test suite [12:30]
gac410jast, yes, unfortunately, trunk and release01x01 maintain their own unit test suites, in somewhat questionable parallel
There are some of us who would prefer a single suite with conditionals. Pharvey was working towards that.
MichaelDaum: yes indeed. Unfortunately I'll be tied up for at least a few more weeks.
[12:30]
jastoh, silly me. I tried to checkout 01x01's UnitTestContrib from a broken URL. [12:32]
GithubBot[foswiki] FoswikiBot pushed 2 new commits to master: http://git.io/oXoOUg
foswiki/master 2cbd434 JanKrueger: Item12526: update anchor regex to match Foswiki-generated anchors...
foswiki/master e3bba63 JanKrueger: Item12526: add regression test...
[12:38]
***GithubBot has left [12:38]
gac410jast, you might need to check the regexes in the WysiwygPlugin to make sure they are consistent. [12:44]
CDotgac410: washing dishes in the bathtub saves water (assuming you wash them at the same time as yourself). Just make sure to inspect for stray hairs after drying. [12:44]
gac410:D I am not making any attempt to save water ... thankfully. [12:46]
jastgac410: at a brief glance I can't find an anchor regex in WysiwygPlugin [12:46]
gac410okay. it was just a thought. [12:46]
jastit was a good thought
better safe than sorry
[12:46]
gac410It might not be a specific anchor regex, but matches for converting tml links into html and back. That code was a bit convoluted IIRC [12:47]
jastI was searching for \# -- no match [12:48]
gac410okay [12:48]
jastoutside of entity conversions, that is [12:48]
CDotjast: don't forget to check the javascript.... [12:49]
jastCDot: was there any specific JS you were thinking of? [12:51]
CDotthe extensions for sticking links into topics
in TinyMCEPlugin
CDot sees references in: Compatibility.pm, Render/Anchors.pm, Render.pm
[12:51]
jastthat would be convertLink, I suppose, which doesn't look at anchors at all
those references all look fine. plus the existing formatting unit tests still pass.
[12:53]
CDot:-)
ok; my exhaustive search of trunk hasn't turned up anything else
[12:59]
jastgood [12:59]
CDot(yet) [13:00]
jastso, is that TargetRelease = patch or TargetRelease = minor?
doesn't quite seem to match the way the version numbers are actually used :)
I'll leave it blank for now
[13:00]
CDotjast: please don't, blank is confusing
if you are fixing a bug, then target it at "patch"
(but only if you are checking into the release branch)#
otherwise target "minor"
[13:11]
jastokay
the label for TargetRelease says I should use 'patch' for 'urgent bugfixes and minor corrections only'
maybe that could be clarified a bit
[13:11]
CDotcorrections and bugfixes, as against enhancements
the clue is in the word "patch"
[13:20]
..... (idle for 21mn)
jastyeah, the 'urgent' and 'minor' is the confusing part
is 'patch' wrong for a non-urgent bugfix? etc.
[13:41]
gac410jast, If the target is the 3rd digit (1.1.*X*) then it is a patch. [13:41]
jastyeah, but as it is, the changes in 1.2 aren't really minor :) [13:41]
gac410The text is trying to say that enhancements or other non-bug-fix changes should NOT be submitted against the patch release.
(Which is mostly ignored :( )
The minor vs. major, I don't think we know :)
[13:42]
jastperhaps the text can say the same thing more clearly
just a minor tweak or two
[13:43]
gac410The important thing to me. is that IF you checkin into the Release01x01 branch, then you should set patch, or I miss the task in the release notes. [13:44]
jastyeah, got it. [13:45]
gac410As it is I manually cross-check every svn commit against the search for "patch" and/or "1.1.9" in the tasks. [13:45]
***Babar has quit IRC (Ping timeout: 260 seconds) [13:45]
gac410The biggest hassle to me is the "sync from trunk" task, which umbrella's a whole bunch of other tasks that don't have corresponding commits into the branch. So I have to compare code to figure out what tasks are actually included. :( :( [13:47]
***ChanServ sets mode: +o Babar
ChanServ sets mode: +o Babar
[13:48]
jastI'm updating the field's description
should I add a remark that it should always be set when someone commits to a release branch?
[13:49]
gac410hm... I'd have to go review in more detail One of them is for tasks that should Not be documented ( Tasks that fix other tasks, that have not yet been released)
Hang on
[13:50]
jastthat's what n/a is for, according to the description [13:51]
gac410okay. [13:51]
jastso, the field is used for the release notes essentially? [13:52]
gac410Yeah. n/a patch minor major, is mainly the release-notes selector.
The ReleasedIn is more historical, and planning. For ex. ReleasedIn for 1.1.9 should have a checkin in the release branch, even if target is n/a
But this is all sort of lose, as it doesn't often get set correctly.
[13:54]
jasthow does this read: http://foswiki.org/Tasks/TargetRelease [13:58]
gac410Gah... and they should never be reset after release. WTF is up with Item11209. Waiting for release 1.1.4 CDot reopened it. [13:58]
FoswikiBothttp://foswiki.org/Tasks/Item11209 [ Item11209: Store is returning wrong information in history ] [13:58]
jastI've tried to clarify the purpose there. [13:58]
gac410Reads fine to me. [13:59]
CDotIt *can* be closed. I only updated unit tests; does not affect the 1.1.4 release.
(phew)
[14:00]
gac410ok. Thanks. [14:01]
jastI added a short explanation to http://foswiki.org/Tasks/ReleasedIn too
(edited just now)
gac410: do you *prefer* it if people set ReleasedIn when committing to the release branch? or would you rather maintain that field yourself (for 1.1.x, that is)?
[14:03]
gac410I would prefer that it always be set. [14:06]
jastokay, then I'll change the description accordingly
the better people know what to do, the better the chance that you have to do less work :)
[14:06]
gac410I just tweaked it a bit as well. It only applies to core and core extensions. [14:06]
jastoh, right [14:06]
gac410That's the "Have we missed any urgent fixes" check. I'll search for 1.1.9 and review any targeted that have not been fixed, and either defer or fix/wait for fix.
An "Urgent - 1.1.9" would be a 1.1.9 blocker. A "Normal/Low 1.1.9" to me says we need to review, the submitter would really like the fix in 1.1.9, but it should not block the release.
[14:07]
jastmakes sense [14:09]
gac410But we can still choose to defer a 1.1.9 blocker if it's too big to fix. [14:09]
jastsure... the joys of release management :) [14:09]
...... (idle for 25mn)
CDotwe need to take a seriously jaundiced look at the remaining release blockers on a 1.1.9, and decide if they really do block. [14:34]
***ChanServ sets mode: +o MichaelDaum [14:40]
...... (idle for 25mn)
BurnOut has left "Leaving" [15:05]
ChanServ sets mode: +o MartinCleaver [15:11]
.......................... (idle for 2h9mn)
laenHey all!
I have a subset of a wiki hosted somewhere else, as read-only. However.. when a page has a link to another page which doesn't exist.. it still, like normal, gives it as a link to create the page. How can i disable that -- or, is it possible to have foswiki unlink it automatically and just display the text?
[17:20]
TarboxHow is that laid out, laen? Do you have two foswikis and one just points to the other? [17:32]
michel_MichaelDaum : good evening. I have set up the SolrPlugin from the trunk. I must be missing some dependencies, since I get the following when trying to access the WebHome of the ClassificationApp web :
Compilation failed in require at /home/data/www/doc.4next.ch/lib/Foswiki/Plugins/SolrPlugin.pm line 142
require Foswiki::Plugins::SolrPlugin::Search;
[17:39]
***danieru has quit IRC (Ping timeout: 256 seconds) [17:51]
michel_ has left [17:56]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Plugins::SolrPlugin::Search [17:59]
***ChanServ sets mode: +o Babar_ [18:00]
ChanServ sets mode: +o Babar
ChanServ sets mode: +o Babar
donbarry has quit IRC (*.net *.split)
Hardcore has quit IRC (*.net *.split)
[18:07]
...... (idle for 25mn)
laenTarbox: Sorry, still there?
Tarbox: it's just a wiki install, with the .txt files copied. So, they're linking to everything available internally.
[18:34]
TarboxHow have you marked them read only? It hides the page create if the logged in user lacks changerights
You should be able to put ALLOWWEBCHANGE = AdminUser in WebPreferences and it should knock it out.
[18:35]
laenI have, not sure if i completely did it correctly. Users don't even log in, they just read.
Ah okay, lemme go try the ALLOWWEBCHANGE on the work machine.
[18:38]
TarboxDENYWEBCHANGE = WikiGuest is another thought, but it's less inclusive. Could lead to someone getting around it. [18:38]
laenI just don't want the NonExisting? links to create pages for the Wikiguests indeed.
Getting around it, well, then i wish them fun ;p
[18:39]
TarboxThe final solution is to remove that option from the oops template for missing page. [18:40]
laenDon't care much for that as the directory the files are in is readonly as well.
Yeah they don't want an oops page ;p
[18:40]
TarboxIn a philosophical sense, they get an oops page, even if it's a 404.
the questions is what they want in the oops page
the default oops page checks change rights.
but you can remove that so it just goes "Oops. Now go away."
[18:40]
laenDoes it not remove the WikiWord link itself? [18:41]
Tarboxoh wait maybe there's a way to fix that part. Sorry, I'm new.
shoot
I'm going to have to take a walk and se eif it comes to me.
[18:42]
laenBasically, in short, if I watch a page that has a WikiWord (which is linked) to a nonexistant page.. i want thre to be no link at all on that WikiWord :) [18:42]
TarboxYou can disable autolinking completely
It is possible to turn off the auto-linking of WikiWords and to rely only on the bracket notation using the NOAUTOLINK preference setting.
http://foswiki.org/Home/WebPreferences
Prevent automatic linking of WikiWords and acronyms (if set to on); link WikiWords (if empty); can be overwritten by web preferences: #Set NOAUTOLINK = Note: You can still use the [[...][...]] syntax to link topics if you disabled WikiWord linking. The <noautolink> ... </noautolink> syntax can be used to prevents links within a block of text.
[18:47]
..... (idle for 21mn)
laenTarbox: omg, i found it in Render.pm
Comment out the few lines in the 621-635 range in http://trac.foswiki.org/browser/branches/Release01x01/core/lib/Foswiki/Render.pm?rev=12889
Lol.. if i had known it was this easy i wouldn't have worked around it so badly with the copy thing.
[19:09]
Tarboxhrm.
There are places where you could set $linkIsAbsent to false too for the same effect.
I suppose that cripples it nicely though.
don't have to hunt down all the places it could be called.
Maybe go one step further and cripple _renderNonExistingWikiWord for the same reason.
[19:12]
........ (idle for 36mn)
***card.freenode.net sets mode: +o MartinCleaver [19:49]
......... (idle for 42mn)
laenTarbox: could do, indeed :)
But that's for later i guess.
[20:31]
.................. (idle for 1h25mn)
***ChanServ sets mode: +o SvenDowideit [21:56]
....................... (idle for 1h53mn)
ChanServ sets mode: +o MartinCleaver [23:49]

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