#foswiki 2015-02-09,Mon

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

WhoWhatWhen
***ChanServ sets mode: +o Lynnwood [01:15]
.... (idle for 18mn)
GithubBot[distro] gac410 pushed 1 new commit to master: http://git.io/bFWN
distro/master aee1123 George Clark: Item9693: Update release documents, and gen process...
[01:33]
***GithubBot has left [01:33]
...................................... (idle for 3h7mn)
gac410 has left [04:40]
................................... (idle for 2h52mn)
ChanServ sets mode: +o CDot
ChanServ sets mode: +o MichaelDaum
[07:32]
............... (idle for 1h12mn)
CDotWhat was the conclusion in the discussion about taint mode?
MichaelDaum: ?
CDot notes that everything comes down in flames when UseLocale is true and taint mode is enabled
fixing it would require a lot of "Foswiki::Sandbox::untaintUnchecked($tainted) if ($Foswiki::cfg{UseLocale})"
CDot has read http://foswiki.org/Development/RemoveTaintCheckingFromFoswiki
ok, so taint mode will be disabled in the release.... I don't see anything that is doing that
[08:47]
jastpresumably it'll be part of building the release archive? [08:53]
CDotpresumably. http://foswiki.org/Tasks/Item13028 has a new proposal; control taint mode programatically [08:58]
jastfun... I didn't know that was possible [09:01]
CDotme neither. It's an XS module, and something only devs should install, but interesting
there's also https://metacpan.org/pod/tainting which adds a 'use tainting' pragma
it also uses Taint::Runtime under the hood. Both have debian packages :-)
[09:05]
MichaelDaumHi guys [09:10]
CDotMichaelDaum: http://foswiki.org/Tasks/Item13028 - I just implemented my proposal, works perfectly [09:13]
MichaelDaumnice. means we can do /usr/bin/env perl as well as the only reason to use /usr/bin/perl was -T [09:14]
CDotsounds good
ok, done
[09:19]
GithubBot[distro] cdot pushed 1 new commit to master: http://git.io/bbQ0
distro/master 0211836 Comment: Item13028: in DEBUG mode when locales are not in use, check for Taint::Runtime and use it to programmatically enable taint checking. Developers need to be recommended to install this module, but it doesn't need to be compulsory
[09:22]
***GithubBot has left [09:22]
................................. (idle for 2h42mn)
ChanServ sets mode: +o Lynnwood [12:04]
ChanServ sets mode: +o gac410 [12:10]
gac410Hello all... Release meeting in 10 minutes, #foswiki-release http://foswiki.org/Development/ReleaseMeeting01x02_20150209 [12:23]
***gac410 sets mode: +v WikiRingBot [12:26]
gac410Ping CDot: Jast, fsfs, gmc, Lynnwood .... anyone else ? Release Meeting? [12:29]
Anyone else... Release meeting starting now! #foswiki-release [12:34]
Lynnwoodmorning
maybe i missed it
[12:41]
CDotLynnwood: join #foswiki-release [12:42]
Lynnwoodjust did [12:42]
CDot:-) [12:42]
gac410jast: We've tabled weblate discussion, will pick it up when you get a break and join #foswiki-release [12:43]
................ (idle for 1h18mn)
fsfs: Are you around? [14:01]
JulianLevensCDot, jast, MichaelDaum: I've been looking at doing another FoswikiCamp in Amsterdam Wed March 25th thru to Fri 27th March, but that's only a little more than 6 weeks away. Is that a no go for any of you? Gotta set a date at some point but as you're the usual suspects, I'd really like your feedback, thanks [14:11]
gac410JulianLevens: I meant to ask. were you going to work on the .gitignore automation in pseudo-install
Every time I have to reset all the extension .gitignore files after pseudo-install I think of you :D
[14:13]
MichaelDaumJulianLevens, excellent. The date is fine for me atm. [14:13]
JulianLevensgac410: yes, I'll do that, ASAP [14:13]
gac410iirc, it's "No more updates of extension specific .gitignore files" and "per-extension blocks of ignore info" added to the .git/yadayada someplace file [14:15]
GithubBot[distro] gac410 pushed 1 new commit to master: http://git.io/bAEf
distro/master 0d59674 George Clark: Item13169: Add DEPENDENCIES to MANIFEST
[14:18]
***GithubBot has left [14:18]
fsfsgac410: I'm around but in a meeting; will have time in an hour or so [14:20]
gac410okay. I'll be here thx [14:20]
GithubBot[FastCGIEngineContrib] gac410 pushed 1 new commit to master: http://git.io/bAuK
FastCGIEngineContrib/master 6691648 George Clark: Item13169: Add DEPENDENCIES to MANIFEST...
[14:22]
***GithubBot has left [14:22]
GithubBot[ModPerlEngineContrib] gac410 pushed 2 new commits to master: http://git.io/bAzl
ModPerlEngineContrib/master c54ef60 George Clark: Item13253: Bump version to 1.00, remove $Rev
ModPerlEngineContrib/master 90daaef George Clark: Item13169: Add DEPENDENCIES to MANIFEST...
[14:24]
***GithubBot has left [14:24]
gac410Jast, interesting, weblate seems to do a lot more checking of translations. Differences in trailing spaces for ex. [14:26]
..... (idle for 24mn)
CDot: You made a bunch of Validation API changes earlier ... by any chance did they implement or obsolete http://foswiki.org/Development/InterfacingWithValidationMethods [14:50]
MichaelDaum_: Did http://foswiki.org/Development/RedoSmiliesPluginAsICON get fully implemented by http://foswiki.org/Tasks/Item12759
Or did it just update the icons without changing smiliesplugin to emit %ICON macros
Chili seems to be working okay. Anyone know if http://foswiki.org/Development/ReplacementForChili can be changed to a rejected proposal. The associated task is closed. Firefox fixed its regex library.
[14:58]
CDotthe validation changes don't eliminate the need for a Foswiki::Func interface, though it's pretty low priority TBH [15:02]
gac410okay. I'm just trying to finalize the features list for 1.2. Ex. Proposal for ConfigurePlugin was still "under investigation" I think that one is merged :D [15:03]
MichaelDaum_gac410, y
ah wait
[15:09]
gac410CDot, one for you to review in your copious free time: http://foswiki.org/Development/VarFORMFIELDMissingThirdDefaultParameter The task associated was closed in 1.0.6. You did some of the work. Is this feature merged, or rejected or parked? [15:11]
jastgac410: afaict weblate can update the .po files from the .pot file, but I haven't figured out how exactly yet [15:15]
gac410okay. Well our xgettext process works fine, so I'd make that really low on priority list.
Given we are in string freeze, there should not be much need to run tools/xgettext
Eventually "continuous translation" would be good to have. But I think we can live with the old catapult over-the-walls approach :)
I hate task / feature review. I don't believe that http://foswiki.org/Tasks/Item12177 actually implements http://foswiki.org/Development/MacroToListInstalledFormFieldTypes even though it claims it does and is waiting for release.
I don't see where it added a macro
er,... well maybe it does. It doesn't add a macro, it adds options to %QUERY
[15:16]
MichaelDaumMichaelDaum just finished a telco ... lets see now [15:22]
gac410MichaelDaum: so to add to your load. You partially reverted Item12177 ... can you comment, is the feature completed, merged, parked ???
Ah... it seems to be working: on http://trunk.foswiki.org/Development/MacroToListInstalledFormFieldTypes :
[15:23]
MichaelDaumI'd rather _not_ force users into typing %ICON just for a :) [15:24]
gac410MichaelDaum: I *think* the proposal was that :) was supposed to emit %ICON% so user types the smiliey and extension converts it to a icon. [15:25]
MichaelDaumso with regards to RedoSmiliesPluginAsICON ... no. not done. assigning Item12759 to it is actually wrong. [15:26]
gac410okay. I'll clear the task then and leave it under investigation. [15:26]
MichaelDaumI don't see an added value emiting %ICON other than causing problems when nesting it
%ICON does emit double quoted html ... and embedding it might break stuff
[15:27]
gac410MichaelDaum: I agree... I don't understand why we would need to add a layer of nesting. though ICON can emit either now. there is an option to specify type of quoting.
CDot and for you: The $Foswiki::cfg{Form} hash is populated a configure checker_
[15:28]
MichaelDaumSmiliesPlugin can be configured on its own just fine as far as I see.
you don't know in advance which layer and type of quoting would be required
[15:28]
gac410Did that get messed up with the new configure. Or did you catch that one. [15:28]
MichaelDaumit might be one and/or the other way around depending on the wiki app [15:29]
gac410MichaelDaum: I agree. My opinion is we should reject that proposal. [15:29]
MichaelDaumswitching it globally would hurt one of them in any case.
ya
smilies currfently emit <img class='smily' src='$url' alt='$tooltip' title='$tooltip' />
directly
too bad Sven never finished the DataForm wizard he is talking about in MacroToListInstalledFormFieldTypes
so work done there is a sort of loose end
[15:29]
gac410Actually it looks like it works.
See example down at bottom of http://trunk.foswiki.org/Development/MacroToListInstalledFormFieldTypes
[15:32]
MichaelDaumno doubt it can be used in some way [15:32]
gac410But it stated it depends on a Checker to update the config with the installed types. New configure won't support this. So Checker part may be broken. [15:33]
MichaelDaumthe demo there is just a technical example [15:33]
gac410Well it fails on release 1.1, with an error.
And populates the list on 1.2
[15:33]
MichaelDaumpopulates the list? what do you mean? [15:34]
gac4104th from last line on Trunk shows "radio,text,checkbox,checkbox+values,color,select,select+multi,select+values,select+multi+values,date,label,listfielddefinition,rating,fielddefinition,textarea,textboxlist "
and on Release11 shows QUERY{ "{FormTypes}[].type" }: Missing operator in '{FormTypes}[].type' at '.type'
[15:35]
MichaelDaumoh sure. there is no backport of this feature ... which would have spurred the use of a DataForm wizard for wiki applications
imho I'd rather use a dynamic way to list all formfield types instead of listing them in LSC
[15:38]
gac410So I *think* I can set this proposal to "Merged to Core" ... except maybe .. er... is it documented? I suppose that's needed for completeness. [15:39]
MichaelDaumfrankly speaking this feature will remained dormant for as long as nobody really creates a DataForm wizard [15:40]
gac410I changed Smilies as ICON to a parked proposal and removed the associated task. [15:40]
MichaelDaumand then we'd need a REST handler to return DataForm info rather than a server-side TML macro [15:40]
gac410Well at this point all I want to do is make sure that tasks / features with checkins into master are appropriately reflected in list of features [15:41]
MichaelDaumof course. thank you. [15:41]
gac410So my biggest concern is there anything we need to revert. otherwise, the feature proposal just needs to be in the list, and will serve as sufficient docs for now.
Humph... in MacroToListInstalledFormfieldTypes, sven claims "the FormTypes checker populates the array of hashes " But it does not, as far as I can tell. and reviewing history, I don't see that it ever did.
It should probably have been done in a "Pluggables"
I'm going to mark this merged to core. It seems to be partially functional, so should be in the features list :(
[15:47]
MichaelDaumSven plain lost interest [15:50]
.... (idle for 15mn)
gac410I've marked ConvertToModernPerlVersionStrings MergedToCore. [16:05]
***JulianLevens has left [16:18]
gac410MichaelDaum: I think this might be a NatEdit bug. If I "Preview" during edit, all of the %TOC% links in the preview actually open a new edit session,.
Edit http://trunk.foswiki.org/Sandbox/TestCaseSensitivity, preview it, and hover over the TOC links - they all go to edit
[16:19]
MichaelDaumMichaelDaum checking [16:21]
.... (idle for 16mn)
not a NatEdit bug, but one in UI::Preview not cleaning up links as we used to
try setting SKIN from natedit, pattern to bare pattern
a preview will generate links to save
[16:37]
gac410Okay. Do you want to open a task, or should I? I think that this is a blocker. [16:39]
MichaelDaumsee http://foswiki.org/Tasks/Item11902
this is part of http://foswiki.org/Development/LinksInPreview
[16:40]
gac410Crap... I'm the goat on this one :D [16:40]
MichaelDaumgac410, your code ;) [16:41]
gac410okay.... I'll work on it. [16:42]
MichaelDaumhow are you going to resolve it? [16:43]
gac410Almost 3 years ago. yeesh this has been a long time coming.
hm Not sure yet.
If you have brilliant ideas, don't let me stop you I was initially thinking brute force - change edit url's back to view. But I think it may be deeper - bad root location in the <body>
[16:43]
MichaelDaumwe always have the option to revert in lack of ideas
not brill but hey
[16:54]
gac410I'll look at it. Agreed.
I think that this is the issue: <base href="http://trunk.foswiki.org/bin/edit/Sandbox/TestCaseSensitivity" >
[16:54]
MichaelDaumall sorts of url params are picked up by preview ...
while rendering toc ...
gotta run. tomorrow.
[16:56]
CDot(15:56:48) gac410: CDot and for you: The $Foswiki::cfg{Form} hash is populated a configure checker_
I have no idea what that means.....
[17:08]
gac410There was a comment in the merged proposal ... that FormTypes is populated by the checker. Which is not allowed in the new configure .... but...
I've dug into history of that checker It never did that
So Never Mind .... I was wondering if you had run into an updating checker there, but looks like no.
[17:09]
CDot ... do you know, Is it possible / easy to override a built-in macro like SCRIPTNAME so that it lies to the templates.
gac410 trying to find an example to copy
[17:15]
CDottry it [17:16]
gac410:)
Seems to work from within a topic.
[17:16]
CDotIt should work for overriding templates too
templates are, after all, just text sources
[17:19]
gac410Yeah. I'm trying to find how to set a Pref from perl. And I'll see if I can change SCRIPTNAME from edit to view in UI::Preview [17:20]
CDotI did consider finalising macros to prevent that, but changed my mind [17:20]
gac410:P Well the easy fix doesn't work. Foswiki::Func::setPreferencesValue( 'SCRIPTNAME', 'view'); at top of UI::Preview, still expands %SCRIPTNAME% as "edit"
maybe the "HEAD" template is expanded earlier. yup. %SCRIPTNAME% in the previewed topic is "view" but rendered in the head is "edit"
[17:26]
CDotwhat are you trying to do? [17:34]
gac410The problem is that the Preview screen uses a <base of the edit script, so all of the relative links like %TOC% links take you to an edit
I just tried overriding the head template in preview, no joy with that either :(
Edit wikitext on any topic on trunk, click a TOC link, it opens a new edit winow
http://trunk.foswiki.org/Sandbox/TestCaseSensitivity has some headings as an example
Secondary issue once we get past that one, is all of the edit urlparams are also used in the preview. So we really need to preview with a clean queryparams as well.
gac410 takes the blame on this one. http://foswiki.org/Tasks/Item11902
[17:39]
***Slion1 has left [17:52]
gac410well it's expanding from the head:meta template. I've tried overriding head:meta in the preview template, but no luck [17:54]
***Slion2 has left [17:54]
...... (idle for 26mn)
gac410I've completely struck out with template overrides. Simple fix is to disarm %TOC by changing it to %<nop>TOC [18:20]
.......... (idle for 48mn)
CDot... I'm puzzled here. UI::Preview calls afterEditHandler, which runs HTML2TML. But this seems unnecessary now. Commenting it out seems to not hurt anything and fixes an issue ... <div>'s seem to be being removed during preview [19:08]
CDoty, horrible isn't it
mea culpa, I never worked that out. It's always been that way.
IMHO the afterEditHandler should only be called on a save, but someone might be depending on it
[19:09]
gac410Yeah i would think actually that using it in preview could be very bad. If someone assumes that afterEdit really means that an edit was completed. [19:10]
CDotblame Sven for that one (he's not here to defend himself) [19:10]
gac410:D
gac410 is tempted to just change %TOC to %<nop>%TOC and let someone else make it pretty :P
[19:10]
CDotCDot hates TOC, has always hated TOC. [19:14]
.... (idle for 19mn)
GithubBot[distro] gac410 pushed 2 new commits to master: http://git.io/bhGL
distro/master acf753c George Clark: Item13255: Don't expand TOC during preview...
distro/master d21fef3 George Clark: Item13252: xgettext run
[19:33]
***GithubBot has left [19:33]
gac410well in this case it's not really TOC's fault. preview is run by POST to save (blegh) and the <base for the topic is the save script.
So any relative links / anchors, are going to be completely wrong.
We I suspect that we really ought to preview by posting the text to view.
[19:37]
.......... (idle for 45mn)
***ChanServ sets mode: +o MichaelDaum [20:23]
MichaelDaumgac410, looking at your TOC patch in preview I see you are using foswikiBroadcastMessage
this class isn't usable for that kind of things
not that I have tested it yet
but foswikiBroadcastMessage is reserved as a container for %BROADCASTMESSAGE
displayed at the top of the viewport
see https://github.com/foswiki/distro/commit/acf753caa74b682087c77327b69063eb74f7c755#diff-a7087069046b44f9c0191afcf46e29e7R71
why disabling TOC? this is a step backwards compared to 1.1.9
[20:26]
....... (idle for 31mn)
gac410MichaelDaum... because I could not figure out how to make the head template render with scriptname view. And broadcast message ... 'cuz I was lazy and we don't have a class that I could find in the css that represents a disabled element. We'd needs a foswikiDisabled or something like that. [21:00]
.... (idle for 19mn)
GithubBot[distro] gac410 pushed 2 new commits to master: http://git.io/bjU9
distro/master 879b7f6 George Clark: Revert Item13255: Don't expand TOC during preview...
distro/master 73654fc George Clark: Item13255: Alternative to disabling TOC...
[21:19]
***GithubBot has left [21:19]
gac410Okay MichaelDaum, I came up with a (hopefully) better solution. Just disables topic relative links, and retargets remaining linsk. Removes bogus use of foswikiBroadcastMessage [21:19]
.......... (idle for 46mn)
***ChanServ sets mode: +o SvenDowideit [22:05]

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