#foswiki 2015-03-01,Sun

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

WhoWhatWhen
GuilainCuebera||, unfortunately not
I'm try to working on or for tell it better I hope to make one better and working on
[00:32]
........................................................... (idle for 4h51mn)
***gac410 has left [05:24]
.............................. (idle for 2h26mn)
ChanServ sets mode: +o CDot [07:50]
............................................................. (idle for 5h1mn)
ChanServ sets mode: +o Lynnwood [12:51]
.............. (idle for 1h5mn)
ChanServ sets mode: +o gac410 [13:56]
....... (idle for 31mn)
GuilainChi gac410 how are you ? [14:27]
simple question, does foswiki.org have enough free space for hosted a debian package repository ?
if not, i will take a free host account
[14:33]
jastgac410: I'm here now, for a little bit [14:48]
...... (idle for 28mn)
and now I'm gone again [15:16]
gac410Damn... I had my speaker muted
Hi GuilainC - Yes I believe that foswiki.org has plenty of space. Need to check with gmc though, as it's his server / hosting site.
If you come back jast ... I'm here. :)
[15:18]
GuilainCok gac410 thanks for the info [15:23]
gac410Heya CDot: Just thought I'd check in on the configure changes I made to regexes. It seems to work here okay, but you're the expert :) [15:24]
CDotdid you check any more in yesterday? [15:24]
gac410configure? no. I started some fixes to TinyMCE and the variable expansion. Found a couple of issues there.
The config changes were done on Friday
[15:25]
CDotok, good. I looked at your changes yesterday, and made quite a few more. Not checked in yet.
CDot is discouraging in .spec files
qr//
there are only two regexes in Foswiki.spec, so special treatment really is overkill
[15:26]
gac410gac410 is still utterly baffled by the NAMEFILE corruption in jQuery.expand() The corruption seems to happen very early and does not happen on 1.1.9
agreed. I left spec. alone mainly waiting for your feedback on the whole thing. Good to clean up and eliminate the qr/ / Though the conversion code probably needs to stay, in case extensions use qr/ / in their spec files.
[15:27]
CDotCDot would really like to check in this simplification of the plugin topic forms
CDot goes to gac410 on bended knee, and asks for the RM's droite de seigneur
[15:29]
gac410Do you have code to make a pass of the existing topics? If so can I extend it to add the repository. [15:30]
CDotall done [15:30]
gac410Adding the repo? or converting the topics? [15:30]
CDotI can generate a patch, if that's easiest?
converting the topics
just for core extensions
[15:30]
gac410Just check it in. [15:31]
CDotok, will do. Feel the power! 3-) [15:31]
gac410Though for the core extensions, they don't really need the repo. It's the non-core that have the need. Is the topic updater code generic enough to run on Extensions web?
MichaelDaum keeps asking why we need NAMEFILTER in the javascript. But I don't really understand that. It provides early feedback to the user typing in a new topic name. I don't get what's wrong with that.
He also asked why not use jQuery.wikiword() but not all topic names are wikiwords, and adding that restriction would not be appreciated I don't think.
jquery.wikiword has a hardcoded forbiddenRegex: new RegExp('[^a-zA-Z\\d]+', "g") Which essentially is NameFilter without any flexibility of configuraiton.
CDot: One thing I don't understand is why we expand %SCRIPTURL% (and 1/2 dozen other macros) in the link handling javascript in TinyMCEPlugin/foswiki_tiny.js That's where the [[link]] corruption is happening.
I've fixed some, and one more fix needed because short URLs causes script urls to be completely wiped out.
[15:31]
CDotthat code predated the other expansions by some time (and to a great extent drove it
duplication ought to be eliminated (probably)
[15:43]
gac410yeah. I was afraid to eliminate it, because I didn't understand it. but from a wysiwyg perspective, I'd rather know that a link has macros in it. I think part of it is so that image links can actually display the image.
So image links need macro expansion so images are fetchable, but [[]] links should not expand them. Anyway. I'll fix up the short url corruption. That happens in both foswiki_tiny.js and in WysiwygPlugin/Handlers.pm
[15:46]
CDotthat sounds vaguely familiar, though my involvement in that code (after the first pass) has been minimal [15:49]
gac410They assume that if someurl contains the view url, then it's safe to just strip it and treat it as a wikiword link.
So %SCRIPTURL%/bin/configure gets munged to [[bin.configure]]
Because with short URLs, the SCRIPTURL prefix for view is contained in the bin/configure link.
One other one I think I've found is that NOPs inside <pre> blocks get incorrectly handled and removed. But that's for another day :P
[15:49]
.... (idle for 19mn)
GithubBot[distro] cdot pushed 2 new commits to master: http://git.io/xW5o
distro/master 7027a86 Comment: Item13278: dump support for qr in Foswiki.spec. It'll still work, but is discouraged
distro/master 023e0e5 Comment: Item13285: admin: simplify extension forms but making a standard PackageForm (that can be overridden in Extensions web to add more good stuff)
[16:10]
***GithubBot has left [16:10]
CDotthe SHORTDESCRIPTION ought to move to the form as well. Oh well, another day for that one. [16:12]
gac410Damn. Fix to Handlers was simple. Check for the scripturl *before* the view url.
just ordering of the array of parameters that are reversed.
[16:15]
hm. CDot... I've been removing the "o" option whenever I come across it. It causes errors in unexpected ways, and iirc, doesn't actually do much in recent perls.
http://stackoverflow.com/questions/550258/does-the-o-modifier-for-perl-regular-expressions-still-provide-any-benefit
[16:20]
CDotI use it almost more as documentation than with any real intent behind it [16:22]
gac410Noted that in perl 5.20 docs it states: "o - pretend to optimize your code, but actually introduce bugs" [16:22]
CDotit may introcduce bugs if used incorrectly. We're not using it incorrectly (he asserts blithely) [16:23]
gac410I'm pretty sure I recall a nasty bug or two where an apparently unneeded o option in a regex without any variables (ie it should not have mattered) actually broke it. [16:23]
CDotif it's taht broken, then perl would have removed it, surely
I don;t care either way; if we want to drop it, then drop it everywhere
CDot hates things half done
[16:23]
gac410Yeah 269c2fa479de6bc51135138cace3ccbc64bbc33a
It was breaking SpreadSheetPlugin, so I removed it from there. but didn't go through and remove it from all places.
I don't remember the specifics any more, but it was really a difficult one to find... if I'm remembering a bug from 2011.
[16:25]
CDotJust been reading perlmonks. The advice is not to use /o, because of the marginal benefit. No indicatiob that there are any bugs with it, though. [16:28]
gac410https://github.com/foswiki/distro/commit/269c2fa479de
It clearly was causing issues in ssp with persistent perl. I recall really difficult debuging on this one.
http://irclogs.foswiki.org/bin/irclogger_log/foswiki?date=2011-10-20,Thu&sel=451#l447 and it was discussed on IRC. This was the original issues
[16:29]
CDotas I said, it will cause issues if used incorrectly; and expecting to be able to change an invariant over different FCGI processes is one of those cases [16:33]
gac410This was actually a unit test issue, and was exposed by changing ordering of tests. [16:33]
CDotfair enough [16:34]
gac410Babar reproduced it. [16:34]
CDotsure, and I understand it; but it's an edge case. We *could* avoid all such cases by never precompiling regexes [16:35]
gac410And agreed. it was a bug in perl 5.12.3 [16:35]
CDotand if you want to impose a "no /o" standard that's also fine
but if you do, please make sure it happens everywhere (in the core)
(which is risky this close to a release, isn't it?)
[16:35]
gac410Just as risky to add it back :P [16:36]
CDotnote that the NameFilter changes where I added /a were just normalising 1/2 of the cases - the other 1/2 already used it
I mean /o
[16:36]
gac410That's exactly why I didn't remove it from everywhere way back when. It was breaking %CALC but I didn't want to take the risk of removing it from everywhere. [16:37]
CDotso if there's a bug, it's already there (probably) [16:37]
gac410y. I just figure whever I touch a regex and will be testing it, I remove /o because 1) It's mostly useless, and 2) Caused me immense pain at one point in my life. [16:37]
CDotthinking about it, from a testing perspective, *no* regex that uses a $Foswiki:cfg interpolation should use /o. if it does, then that's a bug. [16:38]
gac410if you use /o, sites running perl 5.12.3 *might* run into issues. [16:38]
CDotno, i think you are right - for the case where it's a $Foswiki::cfg var, the /o *must* be removed [16:39]
gac410I don't fully understand qr/ / subtleties ... as guidance seems to suggest to use qr/ / instead of o to get pre-compile, does it have any similar issues. I assume not, since we use qr/ / all over the place but ...
back to wysiwyg. So my fix for the URL munging It will fall apart for sites running "shortest URLs" ie (http: //site.com/edit/Topic ... no bin in the url)
[16:42]
CDotbummer. [16:44]
gac410IN that case, %SCRIPTURL and %SCRIPTURL{view} are identical.
I think the solution is to make an exception for that expansion, and check if the "next part" is all lower case (a script) vs capitalized -- a web.
But this whole macro expansion / macro substitution round trip is really a bit dodgy
And I don't see where the Translator tests cover it.
CDot: What's the difference between TranslatorTests and ExtendedTranslatorTests Or is the latter just "more of the same"
[16:45]
CDotI think so. MichaelTempest added the Extended tests.
maybe the fixture is set up differently?
ok, I've looked at all the /o uses in core, and have spotted several bugs-waiting-to-happen
[16:54]
gac410okay. I found coverage for SCRIPTURL in TranslatorTests ... missed it before I guess, even a test for corrupted links. But the problem is we need to test this specific condition with various short url combinations.
cool. btw the bug on perl 5.12.3 didn't even involve variables. $sep =~ s/$(nop|empty)//go;
Actually looking at the original issue it was a bug using the /o optimized regex in split( .../o,
so I guess that's even a more corner case of corner cases.
[16:55]
CDotthe case I am thinking of is where a setting has been changed dynamically at run time. It may be random if a regex using /o has been encountered before, or after, the setting is changed. This is Not Good. The ONLY time /o should be used is where the regex involves static vars, such as constants-that-are-not-constant, and even there qr// might be a better choice.
CDot has only left a handful of active /o's in the code
[17:01]
gac410Looks like the /o behavior is actually documented in "perlop" not "perlre". perlop (5.20.1) summarizes 3 cases where /o is useful, but concludes with "The bottom line is that using "/o" is almost never a good idea."
3 useful cases. 1) Variable is 1000's of characters long and guaranteed not to change, 2) You want to ignore changes to the variables ... not recommended, 3) The pattern contains embedded code that you don't want to compile in each use.
[17:10]
CDoty, I had read that [17:13]
gac410okay. I'm done with beating up /o. Back to puzzling over %SCRIPTURL and %SCRIPTURLPATH and lamenting that the test can't iterate over short url configurations, :P [17:14]
................. (idle for 1h23mn)
GithubBot[distro] cdot pushed 1 new commit to master: http://git.io/xlMe
distro/master 060fcbc Comment: Item13287: remove ALL pointless and/or dangerous /o modifiers from regexes. They have very little performance impact, and in most cases were being used to freeze FW config vars, which is downright dangerous in a persistant environment and for unit tests
[18:37]
***GithubBot has left [18:37]
...................... (idle for 1h48mn)
jastI'll probably be back in an hour or two [20:25]
gac410okay. I'll be around ... getting another snowstorm [20:25]
.............. (idle for 1h7mn)
jastsounds like fun
of the "not quite as fun as other things" variety
[21:32]
........ (idle for 35mn)
gac410: btw I'm here :) [22:07]
gac410okay ... so am I. what's up? [22:07]
jasttrying to hold on to the last few minutes of the weekend :) [22:07]
gac410gac410 is pulling hair out over wysiwyg / tmce conversion of URL variables to URLs and back :P [22:08]
jastwysiwyg is the path of madness
honestly I've given up on ever fixing the current code
[22:08]
gac410yes indeed. ShortURLs really mess some things up. And minor tweaks cause the house of cards to fall [22:08]
jastmaybe in a hundred years I'll have time to write something new [22:09]
gac410:)
Any next steps on translate, Should I go ahead with larger solicitation to the foswiki-discuss group,
[22:09]
jasthave there been any issues? [22:10]
gac410Maybe even a one-time to foswiki-announce looking for translators.
No, Seems to be working okay. I tweaked the configuration a bit. Added links to the github browser, and a few other minor project settings.
[22:10]
jastokay... does it look at Foswiki.pot yet?
when I created the subprojects it said I wasn't allowed to set that in the config
[22:11]
gac410No, and I don't think it's supposed to. That is only used when creating a *new* .po file. It's the template for .po's as I am beginning to understand it. [22:11]
jastwell it has to know what new strings have appeared from _somewhere_ [22:12]
gac410That is our own tools/xgettext which we have to run and push on occasion I'm guessing.
We can't use the xgettext provided by translation toolkit in native form, since it doesn't support our %MAKETEXT{}% macros
[22:12]
jastyeah... seems like it would make sense for it to scan Foswiki.pot for new translatable strings, though
I'll look into that at some point
but if there are no issues in operation, I think letting more people know about it makes sense
make sure to let them know where to complain when things break ;)
[22:13]
gac410No... not that. tools/xgettext builds a new Foswiki.pot, and then merges it into all the po files [22:14]
jastwell, okay, if it's one step anyway, that seems fine [22:15]
gac410So Foswiki.pot is always built new and then merged.
We could probably have a cronjob that cd's to "distro" runs tools/xgettext, and then git pull --rebase && git push
But we generally go into a "string freeze" which means we really don't need to do that very often. "Continuous translation" says that it would be done much more frequently though.
jast, are there backups in place yet?
[22:15]
jastnot yet, no... I'm trying to get our sysadmin to do that because he knows that part of our infrastructure much better :)
if it turns out he's too busy I guess I'm going to have to do it myself some time
[22:20]
gac410Do you think we should hold a push for translations until backups, or do you feel comfortable if we push for more activity? [22:21]
jastbut at least it's on redundant storage :)
there isn't really much that can get lost...
[22:22]
gac410Okay. let's do a plea for translations then to the discuss and svn lists for now and see what shakes out.
BTW: From Weblate 2.1 FAQ: Weblate does not try to manipulate with the translation files in any other way than allowing translators to translate. So it also does not update the translatable files when the template or source code has been changed.
[22:23]
jastall right
in other words it's perfect
[22:23]
gac410So that says we just go along with our current xgettext implementation. We probably don't need to do it very frequently.
The only question I have is should we consider auto-commit / auto-push? or just stick with manual repository interactino for now. I'd lean towards leaving it manual.
[22:24]
jastwe can always change it later :) [22:25]
gac410yup.
looks like there have been no new users registered or translations since the Chinese translatinos the other day,
One user asked for github access. other than that it's been very quiet.
[22:26]
What a royal pain. To convert from href="some random url" back to %SCRIPTURL% or %PUBURL% or %SCRIPTURL{view}% .... it needs to be applied as longest match first.
current code uses a simple fixed list of macros. Need to sort it based on the *length* of the assigned match.
what awful ugly code. Rather than a hash it used an array of keys and a matching array of values, which are then both pushed into a hash as array references.
So I have to sort the key list based on the length of each value.
[22:34]

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