#foswiki 2015-06-25,Thu

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

WhoWhatWhen
gac410Darn... opened a new Blocker for 1.2.0
The "modernized" ICON set for SmiliesPlugin removed some of the old markup that topics on foswiki.org were using.
:skull: for one. Need to put back any missing markup.
[04:11]
..... (idle for 22mn)
GithubBot[distro] gac410 pushed 1 new commit to master: http://git.io/vttfR
distro/master c021abb George Clark: Item13475: Restore :skull: smiliey markup...
[04:34]
***GithubBot has left [04:34]
FoswikiBothttp://foswiki.org/Tasks/Item13475 [ Item13475: Missing icons in latest version of SmiliesPlugin ] [04:34]
GithubBot[distro] gac410 pushed 1 new commit to master: http://git.io/vttJq
distro/master 4ddaf73 George Clark: Item13475: Bump version, update release notes.
[04:39]
***GithubBot has left
gac410 has left
[04:39]
cz99Hey guys, as an admin, can I unsubscribe a user from a topic? I've got a user whose mailbox is full and we keep getting bounce backs. I'd like to unsubscribe him until he returns.
fw 1.1.9
[04:42]
.......... (idle for 45mn)
***ChanServ sets mode: +o CDot [05:28]
....... (idle for 33mn)
GuilainCcz99, you can do it only modify WebNotify topic involved in his subscription
I don't know an "one button solution"
[06:01]
cz99sounds interesting - can you explain steps; I have admin access, but apart from cvt to new version of FW, almost never have to mess with it. its an old well established setup. thx [06:04]
GuilainCin each web
you can find WebNotify topic
where you will find the user subscription
I suppose you don't know in which web the user have subscribe something
So If I were you, I will make a search for finding him
for doing that, go in Main Web, on left bar you should have "search" link
clink on it, an go to advanced search tab
then, just put the wikiname of the user who makes some trouble
and search in all web
as admin, you will get access to all the web, so it's fine
then, at the end of the search result, you get the search code in a verbatim block
copy/paste this code (it's begin by %SEARCH{...}%
and juste add the following parameter : topic="WebNotify"
it will constraint search only to the WebNotify topic
so putting this code somewhere in a topic (your home topic, sandbox new topic, as you want) you will find all the topic where the user appears
and then... be patient, and click one by one on this topic, edit it, suppress/comment the line where the users appears... and should be done :)
[06:05]
***ChanServ sets mode: +o MichaelDaum [06:12]
GuilainCsorry need to go ! [06:13]
...... (idle for 25mn)
cz99Well, I do know the topic: 'MobileIP' & I've got the wiki page. viewed the wiki text; can't see user name anywhere [06:38]
....... (idle for 31mn)
***cz99 has left [07:09]
.......... (idle for 47mn)
rathier_afkcz99: every web hat a topic called WebNotify [07:56]
cz99: and for each topic a user wants to be informed if something chenges, he has to find the web of the topic and ad his name to the WebNotofy topic. [08:07]
.................... (idle for 1h36mn)
***ChanServ sets mode: +o CDot [09:43]
.................. (idle for 1h26mn)
ChanServ sets mode: +o Lynnwood [11:09]
............ (idle for 58mn)
KryoStof1erHi, I am testing on version Foswiki-1.2.0_Beta_2, but have some problem wiht attachemens being corupted when I download them, they are correct uploaded if I check in the pub dir. And by using viewfile CLI I also get the correct result, but downloadin via fcgi and nginx corrupts the file somehow. Any hints on how to troubleshoot?
I did also do a tcpdump of the traffic between fcgi and nginx. and the coruption shows up out of fcgi also.
[12:07]
jasthave you tried normal CGI, per chance?
just to narrow down potential causes
though it's fairly likely there will be no difference
[12:09]
KryoStof1eri did try just running the viewfile from the command line witch shoud be close to cgi. And on that there is no coruption. [12:13]
jastshould... but isn't necessarily ;)
and there's obviously something different *somewhere*
what kind of corruption do you get?
[12:14]
KryoStof1erOk i will try a different webserver with cgi support.
not sure coud be some newline issue.
[12:15]
jastdon't go through too much effort switching to a new web server... this is just a minor data point from what I can tell [12:16]
.... (idle for 19mn)
foswiki_irc9Hi, I've enabled Print Version for my topics, but the printed version has the site's foswiki footer at the bottom of the page. I'd like to take that off. I assumed it was a line in the view.print file, but can't find it. Anyone know what I should change? [12:35]
If anyone can think of where to look, please leave a message here and I'll pick it up in our morning. Thanks! [12:41]
...... (idle for 26mn)
***ChanServ sets mode: +o gac410 [13:07]
.... (idle for 15mn)
gac410Howdy CDot ... I've been changing some of your closed i18n tasks to waiting for release. though none from today. If it appears to really have been a bug that's fixed, it's nice to get it in the release notes.
I was even thinking that for 1.2, I might split out all the i18n tasks into a separate block, instead of just Fixed / Enhancements. It's such a major leap
[13:22]
CDoty, I saw that. The ones I closed were mostly duplicates, though you did catch a couple of uniques. [13:24]
gac410I was just looking at Item13476 ... I think it's a non-issue in 1.2. Really it's a wysiwyg issue preserving white space, and I couldn't recreate it. [13:24]
FoswikiBothttp://foswiki.org/Tasks/Item13476 [ Item13476: recognize smilies between html tags ] [13:24]
CDotthere's a big problemo with backlinks
there's no way to express /[[:alnum:]]/ in a %SEARCH
[13:24]
gac410Oh. I added a test case to http://trunk.foswiki.org/Sandbox/TestT%C3%B6pic And noticed that the %C3%B6 encoding is "sticking"
CDot: yeah the Backlinks search is a real mess.
[13:25]
CDotthere's also an issue with the javascript; it's not recognising unicode chars in wikinames/usernames/passwords
though the perl code fully supports it
CDot has a fix, just testing it
[13:25]
gac410Really? I successfully registered a user with a unicode name and it properly built the wikiname and didn't complain [13:26]
CDotin between having my new kitchen fitted :-)
unicode? you sure? You sure it wasn't just high-bit?
cos anything up to \xFF is "special"
[13:26]
gac410Ah. maybe I accidentally landed on high bits. There was a task for unable to register, and I tested and marked it waiting. [13:27]
CDotand I can assure you the JS coe is well stupid. [13:27]
gac410Okay. hm Need to find that task then, it's already there somewhere. [13:28]
jomobut just because we don't using "use CGI (:utf8). in such case nothing is special and the unicode is enforced. imho... [13:28]
gac410jomo I'm missing the context on your reply [13:29]
jomocos anything up to \xFF is "special" [13:29]
CDotduh... it appears that a redirect to any topic containing unicode (above \xFF) chars will fail [13:30]
gac410Okay It was Item9955 [13:30]
FoswikiBothttp://foswiki.org/Tasks/Item9955 [ Item9955: Problem in UserRegistration with generating a WikiName from FirstName and LastName when they include umlaute. ] [13:30]
CDotif you have a unicodeish wikiname, and you log out, the redirect blows up [13:30]
gac410CDot btw. Good find on the corrupted path in LSC. I beat my head silly trying to encode / decode the path to understand why the logger was failing, not realizing the field had been corrupted. [13:31]
CDoty, bit of a bugger to track that one down :-( [13:32]
jomogac410: you marked Item12569 as WatingToRelease but the sorting isn't (yet) solved... [13:33]
FoswikiBothttp://foswiki.org/Tasks/Item12569 [ Item12569: Sorting in tableplugin is wrong in german ] [13:33]
gac410I thought Data::Dumper was always saving the LSC as pure ascii using \x{..} type encoding so I never eve n looked
jomo, if you set a German locale on a perl that has working locales, does it work? All the code now has conditional use locales.
I thought sorting was a purely locale / perl issue now.
[13:33]
jomoregardless enable/disable locales in the Foswiki - it doesn't sort ok... (IMHO). [13:36]
gac410hm okay. Is it a perl issue or a foswiki issue? [13:36]
jomoi could sort correctly with perl... if you asing this... [13:37]
gac410I'll change the task back to confirmed.
Okay. hm. I wonder. We have two table sorts. Tables sorted by TablePlugin on the server side, and Tables sorted by the EditRowPlugin on the client side. Do either of them work?
[13:38]
jomoi don't care about the client side, because the sorting SHOULD work for exmple in the WebIndex too... so - the server-side sorting "is matter".. ;) [13:40]
gac410Okay. It's just that *specific* bug is about TablePlugin sorting. [13:41]
jomochek this: http://trunk.foswiki.org/Sandbox/WideCharTableSort [13:42]
gac410Yeah I just saw it. So server side is wrong on perl 5.18 without Locales enabled. [13:43]
jomothe users "usually" wants a sort as it is in the table as default.. when you resort it by the second column it is sorted wrong. IMHO [13:43]
gac410Yes I agree. Just trying to characterize. and, and decide if the proposed patch in the task fixes anything [13:44]
jomoit should not be locale dependent. the locale dependent sorting (called unicode collation) is much more complex - and IMHO out of the reach of the current foswiki.. [13:45]
gac410Okay. So you have just blown by my level of knowledge. But clearly it's still broken, so task is confirmed.
Client side sorting gets it wrong as well. That's a separate javascript library component of some sort :D
At least it's consistent.
[13:46]
jomothis is two different things: locale-dependent sorting (collation) is far-far-far more specific and harder to implement. because here are many differences between countries.
The simple "unicode sorting" is easy to implement and it could work "out of the box" - just CDot don't want use the NFKD on __every__ input and NFKC on every output. :D :D
[13:48]
gac410hm well reading about it, NFK* conversions are lossy. superscripts, etc. and other formatting would be lost.
From the unicode.org: Normalization Forms KC and KD must not be blindly applied to arbitrary text. Because they erase many formatting distinctions, they will prevent round-trip conversion to and from many legacy character sets, and unless supplanted by formatting markup, they may remove distinctions that are important to the semantics of the text.
So I suspect these forms would have to be applied as part of the sort compare, but not as a general rule.
[13:55]
GithubBot[distro] cdot pushed 1 new commit to master: http://git.io/vtmhz
distro/master 5b9b8c9 Crawford Currie: Item9955: Item3679: users now properly supporting unicode username, wikiname and password (and I guess cUID, though I didn't test that. Hmm, that might need to be checked
[13:59]
***GithubBot has left [13:59]
gac410jomo, on the TablePlugin, I suspect adding a NFKD conversion to the left & right of the sort cmp would work maybe?
$a->[$sortCol]->{sortText} cmp $b->[$sortCol]->{sortText}
[14:10]
jomoyes - with NFKD (or NFD) the sorting is __nearly__ as what the user usually wants...
and yes - you WANT clear the unicode formatting stupidities from the characters.... :)
the above cite isn't for the current foswiki (when we trying to make the simple sort to work) - and nor the case in the near future...
... just imho
[14:12]
gac410Okay very simple fix.
A couple of places inside TablePlugin/Core.pm
-                     $a->[$sortCol]->{sortText} cmp $b->[$sortCol]->{sortText}
+                     NFKD($a->[$sortCol]->{sortText}) cmp NFKD($b->[$sortCol]->{sortText})


Of course we'd need similar inside the search and any other place sorting occurs.
[14:15]
jomoomg, please don't DO IT inside the code... this is one of the cases what should be general - the same as for the Encode - 1000 times in the code in different places (before unicode) just because the bas approach - this is the same... [14:17]
gac410The unicode docs state very clearly that you should NOT do NFKD normalization to arbitrary text [14:18]
jomonormalisation should be done AT THE BORDERS... and NEVER somewhere middle-inside the code.... [14:18]
CDotCDot thinks this is minor, compared to the backlinks problem :-( [14:19]
gac410In which case, user enters a superscript character, and we strip it out.
Because NFKD of a superscript is the standard alphanum character
CDot: I'd be happy with documenting backlinks as broken. rather than delay our RC
[14:19]
CDotk [14:20]
gac410It seems this one is a huge issue to fix [14:20]
jomookay - as you wish. Imho here is a difference between a<sup>2</sup> (what is used generally in the web-apps and using teh superscript 2 (character) U+nnnn [14:20]
CDotCDot is happy with http://trunk.foswiki.org/Tasks/I18N [14:20]
gac410jomo, but it's more than just superscript. from reading the examples in http://www.unicode.org/reports/tr15/ applying NFKD is quite destructive. [14:21]
CDotsomewhat disturbed by the number of tasks in "Waiting for Feedback" [14:22]
jomookay, imho the normalozation should be done at the borders, exactly as like the Encode. If you decide to do it otherwise - okay, your decision. And using NFD or NFKD - it is the decision what do you want achieve. IMHO the NFKD (now for teh foswiki) is better as NFD - but ok.. ;) [14:22]
gac410unicode.org is mighty specific that you should never blindly apply NFK* forms. [14:23]
jomodon't want argue much here in the irc - if don't want NFKD use NFD :) - but USE IT at borders. not in the middle of the code...
omg gac410 you missed the main point
the question IS NOT NFKD or NFD - the question is DO or NOT TO DO normalisation at the borders...
[14:23]
gac410If normalization can be destructive ??? [14:25]
jomoagain - IMHO NFKD is better (for the foswiki) as NFD. BUT if you don't like NFKD - ok - just use NFD - but please use IT on the borders... [14:25]
gac410I'm not arguing I'm trying to understand. [14:25]
jastNFKD seems better for processing, but worse for presentation [14:27]
gac410We often have users pasting in text into wysiwyg. If *anything* we do somehow loses character formatting, then that's bad. yes for html <sup>..</sup> is the preferred format but.
if a user enters a unicode superscript, or one of many other characters, we cannot normalize them away.
[14:27]
jastIMO NFKD at the point of entry is simply not an option [14:29]
jomofoswiki is not a desktop-publishing system. So, we don't want to have deal with some stupidly unicode-formatted characters. Please note the unicode formatting HAS NOTHING with the CSS/html formatting... So, imho we should use NFKD. But if you for some reason want use the non-destructive NFD - so USE IT. But please, do the normalisation uniformly AT THE BORDERS - not somewhere ad-hoc middle of teh TablePlugin... [14:29]
jastand if we do want to use NFKD as a basis for collation etc., we'll have to perform it all over the place
NFKD can change the *meaning* of a piece of text
suppose you've put a formula in a wiki topic
x = 5² is quite different from x = 52
[14:29]
jomodamm - ok - forget the NFKD
use NFD
[14:30]
jastunfortunately NFD doesn't help that much for proper sorting, if I understand things correctly [14:30]
gac410will NFD always sort correctly and guarantee NEVER to change the meaning [14:30]
jomogiving up... [14:30]
jastNFD will never change the way the text looks, unless the font designers are crazy
but I doubt it'll help with sorting and stuff like that
though I don't know exactly how perl's sorting works if combining characters etc. are involved. my guess is it's stupid. :)
the only acceptable thing in terms of what gets output in the end: don't normalize, except transiently for influencing sorting etc.
which has the massive downside that it eats more CPU and makes for messier code
[14:30]
gac410At least in TablePlugin, the NFKD() was quite magic. Jomo's example table sorts perfectly [14:33]
jomookay - last try: check yourself - if you want... change the NFD to the NFC in the code and see the result...
perl -CSDA -MUnicode::Normalize=NFKD,NFC,NFD -MList::Util=shuffle -Mutf8 -E '$n="01"; say "| @{[$n++]} | $_ |" for( sort { $a cmp $b } shuffle(map{NFD($_)} split //,"aáäbcčdďeéěfghiíjkĺľmnňoóôöőpqrŕřsštťuúůüűvwxyýzž") )'
[14:33]
gac410But I'm not going to checkin for 1.2. Let's document that sorting in 1.2. is still an issue. [14:34]
jastokay, that answers my question about combining characters [14:34]
gac410As it needs addressing in too many places. [14:34]
jomono, many places - ONLY at the borders... [14:35]
jastthere are a *lot* of borders [14:35]
jomobut sure less than "middle-of-code" ad-hoc fixes... [14:36]
gac410gac410 doesn't understand that perl snippet. [14:36]
jomowe have network, files, cpan-moduled - done. no more...
s/moduled/modules/
[14:36]
jastgac410: basically it shows how NFD'd strings sort. replace the map{NFD with map{NFC and you see typical non-NFD (in this case, NFC) results [14:37]
jomonetwork - currently CGI ;( - files (iside the Store) - cpan-modules - yes, it is longer a bit... [14:37]
gac410thanks jast. [14:39]
jastand for sorting I tend to agree that NFKD is an even better choice
but we're in quite a bind here
we can't have it all
[14:39]
jomojast: please check the snipet. for the normal characters are not difference between NFD and NFKD - okay, use NFD - will sort OK - try the snipet and will see youself... ;( [14:40]
gac410Table sorting is fairly low overhead, and not a worry, but javascript being out of sync would be bad. So that needs work. [14:40]
jastyes, I know. I tried. [14:40]
jomo:D [14:40]
jastNFKD doesn't make a difference here, but it's a different story if you have, say, ligatures
have I mentioned that i18n is a nightmare?
[14:40]
jomoyes - yes - okay - forget NFKD - this is for longer discussion. Imho foswiki DONT want use in the line-oriented - TMCE - Wysiwig plugin architecture the NFD - but the core developers agree on the NFD and not NFKD ok - use the NFD :) :) [14:42]
jastdidn't I just say that I find NFKD better? for collating/processing purposes, anyway
but I see a lot of potential for nasty issues if we do *any* kind of normalization all over the place
[14:44]
***ChanServ sets mode: +o mtempest [14:45]
jomo:) - see, need a simplest as possible solution. imho the simples is: use one normalisation on the inputs and one on the outputs.. - in the Foswiki v 5.3 we could be more specific... :) :) [14:46]
JulianLevens1Can I throw Unicode::Collate into the mix? [14:47]
mtempestcdot: around? [14:47]
jomolol - cdot will kill you - this is IMHO for 2.0 and later... especiallu the Unicode::Collate::Locale
for now - the simplest possible solution (what gives the result what the user usually wants) is plain sort { $a cmp $b } on the NDK?D normalised strings...
[14:48]
jastright [14:49]
JulianLevens1OK, tbh I'm really not up to speed on this [14:50]
jastgreat material for bed-time stories [14:51]
jomo:) [14:51]
JulianLevens1great, I've been suffering insomnia recently [14:51]
jomojomo 's wife knows other normalization forms in the bed... :) [14:54]
gac410jomo, I think that sort need the "k" form. The example in the unicode docs. 2<sup>5 NFD is 2 chars, 0032 2075 NFKD is 0032 0035.
But since K is destructive, cannot just apply that globally
[14:56]
jomogac410 as i told above - sure, we could make differences when and where use different norm-forms. but (IMHO!!) foswiki in the current state should not makes differences. Simply because it is not ready for such "nitpicking".. so, if the NFKD isn't acceptable by you, okay use NFD... but using 2 different forms NFD and NFKD (on the input) and of course, on the output would be nice to do the reverse, e.g. the NFC (NFKC) - this is too much for the
foswiki now... but again, all this is pure IMHO... ;)
[15:00]
jastNFKD can't really be reversed [15:01]
jomoright ;)
but on the output would be nice to have NFC
agree? :)
e.g what foswiki send in to the network..
[15:02]
gac410Right. As RM, we won't be using K* anything for generic normalization. But from what I can tell, we need a K* for sorting. can't get away from it. [15:02]
jastwell, K* is a better than *, I guess, but not exactly _required_, either [15:03]
gac410as far as normalization for the network, I have no idea. Why is what we have today not good enough. [15:03]
jastin any case, we're moving this to post 1.2, right? so no need to spend too much time right now [15:04]
gac410Right. Except for minor fixes we live with what we have for Monday's RC
jomo, I still don't understand what going to NFC on general output buys us.
So known limitations of 1.2 include. 1) Sorting of i18n, 2) Backlinks of i18n
[15:05]
jomothe NFC is what is usually every SW what works overt the network, e.g. reads BYTES from the sockets and accepts them as utf8 - the NFC is the prefered (Im not sure about the "standardised") form. Also, it makes the response a bit smaller, because the NFC need few bytes as NFD... So, generally everything on the network are BYTES, but the encoding is generally used as UTF8/NFC... (maybe it is standardised too - need verify).
but if nothing more - NFC is smaller, so faster than NFD ;)
[15:09]
also, we will get requests (from the user's browsers as NFC) - on the other side, inside of the SW - is easier to work with NFD... (for example the "sort" problem)... :) e.g. the common practice: doing NFD on the input and NFC on the output.
The same is applying on the filenames too. In the Linux/Fbsd the filenames are "generally" NFC - so, therefore need normalize on the output to NFC...
uff... :)
[15:16]
CDotmtempest: in and out; middle of having a new kitchen fitted, so in turmoil :-) [15:21]
jastexcept OSX stores them in NFD [15:21]
mtempestcdot: good luck :-) [15:21]
CDotI need it; the poor kitchen fitter is running out of 4-letter anglo-saxon words... [15:22]
gac410:) [15:22]
jomoosx __enforces__ NFD (it is apples own nfd) - so, that is different from a linux what doesn't enforces anything... [15:23]
gac410when we did our kitchen, nothing was square. The floor had a 5+ cm difference from one corner to the other. [15:23]
jasttrue
our kitchen was fine... but did I mention what we discovered in the basement?
[15:23]
gac410no [15:24]
CDotjast: not *more* skeletons? [15:24]
jastno, just the trench of doom hidden under a wall cupboard
because who needs a bed-plate that doesn't have a moat in it
[15:24]
CDotheh; my kitchen floor (concrete) seems to have been poured during an earthquake [15:26]
jastfun
I kept some pictures of The Basement Discovery(tm), but I don't have them with me
[15:26]
CDotthere was a chap in London ..... http://www.theguardian.com/society/2006/aug/08/communities.uknews [15:28]
jomoLOL: I just have a big basement ... :D :D [15:29]
jastgood for him [15:30]
jomojomo wondering what says the local (slovak) law about the basement sizes... ;) [15:31]
CDotthey are trying to change UK law so you no longer own the ground under your house down to the centre of the earth (as at the moment)
they want the freedom to frack underour homes, without permission
[15:32]
gac410US has that issue. "mineral rights" vs your property. :P [15:33]
jastyeah, I read about that (for UK)
makes sense, too... I mean we all know fracking is completely non-invasive and has no measurable effects on anything
[15:33]
jomojust use a big hammer... ;) [15:34]
***mtempest has left [15:45]
.............................................................................. (idle for 6h27mn)
jesuisseHi. I've just installed Foswiki 1.2.0_Beta_2 and used /bin/configure to install NatSkin. When I try to attach a file to a topic using NatSkin, I get an HTTP Error (Internal Server Error on /bin/rest/TopicInteractionPlugin/upload). Anyone knows what might cause this? [22:12]
.............. (idle for 1h8mn)
GithubBot[distro] FoswikiBot pushed 1 new commit to master: http://git.io/vtGsh
distro/master 89f77d1 CH yang: Item13252: Translations updated using Weblate (Traditional Chinese)...
[23:20]
***GithubBot has left [23:20]
FoswikiBothttp://foswiki.org/Tasks/Item13252 [ Item13252: Translation work for Foswiki 1.2 ] [23:20]
........ (idle for 37mn)
gac410jesuisse: Hi, I've not tried NatSkin. Do you have any errors in your web server log. [23:57]
jesuisseNo, but I'm currently debugging TopicInterActionPlugin and I've traced the error to urlDecode in it's Core.pm...
Only now I don't know how to fix it.
The problem seems to stem from the following line:
[23:59]
gac410Ah. hm that could be related to the conversion to utf-8 internally [23:59]
jesuissemy $downgradedValue = $session->UTF82SiteCharSet($value); [23:59]

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