#foswiki 2014-01-07,Tue

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

WhoWhatWhen
gac410Hm... MichaelDaum redesigned Tasks/WebHome. It is now useless.
It just duplicates all the links on the right bar onto the top of the page, The rest is a clone of WebChanges, and the handy Waiting for, Opened, and closed searches are all gone.
[01:43]
...... (idle for 28mn)
***ChanServ sets mode: +o Lynnwood [02:13]
LynnwoodDoes anyone know if it's possible to create a QUERYSEARCH that searches for a value in any of the fields? [02:14]
gac410no idea here Lynnwood [02:14]
LynnwoodIn the past, I've had to resort to FORMATLIST or similar to create a series of OR clauses.
Hey gac410 -
[02:15]
gac410howdy Lynnwood ... Staying warm? [02:15]
LynnwoodI'm looking at the QUERYSEARCH docs and it _seems_ like one cshould be able to.
trying to stay warm.
or more so, trying to keep plants in greenhouse from freezing and chickens from loosing their combs
(poor things)
[02:15]
gac410wow. Bit of a challenge. [02:16]
Lynnwoodit's -1 F and dropping
windchill takes it down to -20 or so...
but chickens and plant are at lease protected from the wind.
at least...
[02:16]
gac410Were still a toasty 26. This morning was 55+, supposed to be single digits by morning. [02:17]
Lynnwoodwhere are you at? [02:18]
gac410Just west of Boston.
You?
[02:18]
Lynnwoodwow - i would have thought it was colder there.
I've in western NC
in the mountains so we're use to pretty cold and strong winds
[02:18]
gac410Yea the weather has been really crazy, warmer to the north today [02:19]
Lynnwoodwe're getting gust outside right now up to 50mph [02:19]
gac410Worcester is gusting to 22, not too bad yet. [02:19]
[julian]We've had a heat wave here in auzzie land
happy to trade a few Fs here and there with you guys!
[02:20]
Lynnwoodsounds good... send them to my chicken coop
anyway... seems like i should be able to make a query like this work:
fields.[name~'*'].value=~'testing'
...meaning basically to search all the fields to see if they equal testing.
actually, that would be: fields.[name~'*'].value='testing'
but you get the idea
[02:24]
gac410cool. [02:27]
Lynnwoodbut i can't get it to work :-(
at least not yet.
if it could work, it would be excellent
[02:27]
Well how about that... it DOES work.
I had an extra period after fields
it should have been fields[name~'*'].value='testing'
that's most excellent.
[02:34]
........ (idle for 36mn)
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/zY5THg
foswiki/master 867837b GeorgeClark: Item12359: Refactor the DESTROY routines...
[03:11]
***GithubBot has left [03:11]
FoswikiBothttp://foswiki.org/Tasks/Item12359 [ Item12359: Func::eachEventSince can leak file descriptors ] [03:11]
.... (idle for 16mn)
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/o2nv-Q
foswiki/master 4381a17 GeorgeClark: Item12359: Wrong class name...
[03:27]
***GithubBot has left [03:27]
........................ (idle for 1h58mn)
gac410 has left [05:25]
ChanServ sets mode: +o SvenDowideit [05:36]
............. (idle for 1h1mn)
ChanServ sets mode: +o pharvey [06:37]
ChanServ sets mode: +o CDot [06:42]
..... (idle for 23mn)
ChanServ sets mode: +o MichaelDaum [07:05]
MichaelDaum> gac410: Hm... MichaelDaum redesigned Tasks/WebHome. It is now useless.
gac401, let me explain why it was in need of a redesign
first Tasks.WebHome wasn't useful for me at all and most probably for a lot of other people too. Why?
(1) It was much too expensive for a WebHome
(2) It took ages to load to compute a feature also available on a separate page Tasks.MyItems
(3) It computed MyItems even for WikiGuests ... which doesn't make sense
(4) Listing MyItems is not what you want from Tasks.WebHome in a lot of cases, eg. (a) create a new task or (b) look up another task not necessarily assigned to me or (c) see recent activities on the task tracker
I myself bookmarked Tasks.WebChanges as my personal entry page to Tasks.
I avoided Tasks.WebHome by all means as it took far too long to load as a hopping page.
yes, the sidebar should be hidden on Tasks.WebHome and all features there should be listed right in the content area ... not somewhere on the side.
I simply don't know how to hide the sidebar using PatternSkin.
Now, Tasks.WebHome loads a lot faster, even for WikiGuests ... which I find very important not to counteract any motivation for new-comers to report a bug.
All previous features have been moved one click further down the app. If there's one feature missing, please add it to the lists on the current Tasks.WebHome.
The current lists - Search, Development, Reports & Statistics - try to cover those routes a user could follow hitting that page.
Of course, Reports & Statistics sounds a lot more promising than what the Bugs app can currently provide. Normally, Task Trackers do much more here.
I still added the "Reports & Statistics" category here as that's what you see on most other bug tracker products.
It simply is what people would expect ... no matter whether BugsContrib can deliver in that area or not.
There are a lot more odd things in BugsContrib besides its frontpage.
I just felt the frontpage to hurt too much for too many people ... as well as the server itself.
A lot of other pages build too heavy searches on first hit: it would load easier if the user had a chance to make a selection first, e.g. http://foswiki.org/Tasks/AppliesToParts
it takes 18+ seconds to load; there is a small select box at the top which could narrow down the result set ... if the user didn't wander off before.
note that the server runs these 18+ seconds for every bloody crawler.
these are resources not spent for real users.
note also that AppliesToParts has no proper heading or an explanation what is displayed here. it looks like any other table found in the Tasks web.
[07:06]
***ChanServ sets mode: +o pharvey [07:25]
MichaelDaumnuf said [07:26]
btw http://foswiki.org/Tasks/RecentlyClosed takes a full 26 seconds to load...this is an eternity
as a rule of thumb, every pages needs at least one H1 ... a page title doesn't belong into H2 or H3.
Best is to use always exactly one H1.
[07:32]
....... (idle for 30mn)
and wtf is http://foswiki.org/Tasks/MyDetailedItems telling me [08:05]
......... (idle for 41mn)
CDotHmmm. I like the redesign. The only thing I can see that's missing is a link to "Tasks waiting for me", which is something i find very useful.
withdraw that; I logged in, and it appears :-)
nice job, MichaelDaum :-)
[08:46]
MichaelDaumthx
MyItems and WebHome were hitting the site even for WikiGuests ... and listing stuff ... which it shouldn't ... anyway.
[08:53]
.... (idle for 17mn)
jastI agree that WebHome was painfully slow before
jast now dares to open it again
yeah, much better
[09:11]
SvenDowideitMichaelDaum that top 'menu' really does ask for a proper menu
oh, and there are a number of ways to hide the pattern sidebar
there is even a hidden sidebar contrib i think i tossed into svn to show one or two
[09:23]
MichaelDaumthanks, found the cookbook entry and made the changes [09:25]
SvenDowideitsweet
cos i too used to hide it much of the time
[09:25]
MichaelDaumnot something Aunt Tiffy is going to do [09:27]
........... (idle for 50mn)
CDotwho is Aunt Tiffy? Can she code perl? [10:17]
........ (idle for 39mn)
***ChanServ sets mode: +o Lynnwood [10:56]
MichaelDaumAunt Tiffy is the person sitting next to your screen holding the mouse with both hands not to loose contact with the modern world. [11:01]
SvenDowideitmouse?
it took me years to learn to use a mouse
[11:03]
.......... (idle for 47mn)
***ChanServ sets mode: +o pharvey [11:50]
........................... (idle for 2h11mn)
ChanServ sets mode: +o gac410 [14:01]
foswiki_irc9Hello - I had an issue with LDAP users unable to login due to OU change of LDAP user. I've since resolved that but now when users log in they have 1 after their name. Is there something else I need to run? [14:11]
jastLdapContrib remembers a mapping from the user's DN (which includes the OU, of course) to the WikiName
the same mapping also makes sure that if two users have the same name (or whatever else you generate the WikiName from), they have stable different WikiNames
if you don't have any users that have the same name, you can just visit the wiki with a ?refreshldap=force parameter to have the mapping erased completely
[14:19]
gac410Heya jast. good morning. I updated Item12027. binmode is indeed used but it's a bit convoluted to follow. [14:22]
FoswikiBothttp://foswiki.org/Tasks/Item12027 [ Item12027: statistics/logfile iterator: not respecting SiteCharset ] [14:22]
jasthi gac410 -- that's a relief. I was rather confused about that. :)
btw, in case you didn't see, Michael replied to your comments about Tasks/WebHome (see the channel logs)
[14:23]
gac410F:L:LogDispatch.pm passes it to the Log::Dispatch->add. Log::Dispatch::_open_file() calls binmode against $fh after opening the file.
Yes I saw :D
I'll just change my landing page to MyTasks. What's 8 more characters to type in the url
[14:24]
foswiki_irc9Jast, How do I visit the wiki with that parameter? [14:26]
jastfoswiki_irc9: visit any topic in the wiki and append that to the URL [14:26]
foswiki_irc9ah
gotcha
[14:26]
jastyou may have to be logged in as admin, not sure [14:26]
foswiki_irc9So do all users have to do that?
Or just once?
[14:26]
jastjust once [14:26]
foswiki_irc9excellent - thank you! [14:26]
jastyou don't get any message of success or failure, but the names will be without 1 if it worked [14:27]
MichaelDaumgac410, MyItems that is. [14:27]
gac410I'd get there eventually ... still on first cuppa coffee :)
Starting off with a unicode / utf8 discussion has not helped my head :D
[14:27]
MichaelDaumMichaelDaum second can of the day in progress over here [14:28]
jastgetting back to Item​12027... what would be your approach to changing the binmode stuff? [14:29]
gac410I still think then I need to add a similar exception to the binmode in _flatten ... assuming your approach is correct. Just make sure that LogDispatch::binmode() can be set / reset on the fly.
What would a unit test look like. Is it eve possible. Hm. Set system to utf8. The log with a bytestring, log with a unicode string, and then read them back unmodified?
[14:30]
jastsomething like that, yeah
generally I think mixing Encode::encode and :encoding() layers is the wrong approach
both are doing the same thing really, just on different levels
[14:31]
gac410Is it sane to write to a log file, line 1 with encoding, line 2 without?
er by encoding I mean binmode
From your original task, log a view of a topic with plain ascii name, then log a view with a topic with utf8 name should trigger the issue?
[14:32]
jastno, a single log entry with a utf-8 topic is sufficient to trigger it
with {Site}{CharSet} set to utf-8
[14:35]
gac410On trunk, the proposal is to make LogDispatch the default logger for 1.2, which is why I want to get this right. I'm trying to finish off my outstanding tasks from 2013 and 2012 sigh. [14:35]
jastthe encoding written to the log file should be identical for all logger lines as long as {Site}{CharSet} does not change [14:36]
gac410And trigger "it" means reading log with eachEvent ends up with scrambled topic name? [14:36]
jastASCII is, of course, a subset of UTF-8
the topic name is actually scrambled while writing to the file, not while reading
I got that wrong in the initial description... I guess I should have updated it
that's also why I didn't initially manage to fix it :)
[14:36]
gac410Ah... .so you turn of binmode on write, because the string is already encoded, so you don't want to double encode? [14:37]
jastwell, the _log function doesn't use the {binmode} field you were talking about... it constructs its own [14:38]
gac410So one last dumb question. The test isUtf8 is okay to apply to the entire composed line, and isn't needed field-by-field as it's strng together. [14:38]
jasterr, the log function, I mean
yes
is_utf8 basically tells you whether the string is internally a byte string or a Unicode string
[14:39]
gac410ug. yeah, it's passed as a string when the logger is added, not as a callback. :(
So the same fix can't apply :(
[14:39]
jastis_utf8 returning false means it's a byte string (which may be a UTF-8 encoding of a Unicode string); returning true means it's a Unicode string (always UTF-8 internally but may be re-encoded by PerlIO :encoding() layers)
the bad case (which happened in this item) is when you have a byte string and push that through a :encoding()
with ISO-8859-1 charset it'll usually work for the most part; anything else will break
I should draw a picture to explain all this... :)
[14:40]
gac410Hm... The *only* fix is correclty setting binmode on the open file handle?
I'll get it eventually.
[14:42]
jastbasically, you need the right combination
byte string -> no :encoding() in binmode
Unicode string -> proper :encoding() in binmode, or convert to byte string before you write to the file
[14:43]
gac410So your fix is to adjust binmode on the fly. If I can't do that with Log::Dispatch, then other solution is to revers the string?
s/revers/revert/
[14:44]
jastthe real solution is to finish the big Unicode task
probably breaking a zillion plugins in the process
[14:45]
gac410yeah, I understand. And that's a non-starter to get 1.2 out the door I assume [14:46]
jastit might actually be feasible, really
as long as we keep the Locale thing out of that
Locale is more complicated, not least due to the incompatibilities with taint checks
[14:46]
gac410Well I'm willing to work on it. We sure have enough issues with it.
As far as taint checking, I'm thinking we should abandon it. My impression is perl powers that be have somewhat ignored it.
[14:46]
jastabandoning it would certainly make things easier [14:49]
.... (idle for 15mn)
gac410So for a really dumb question. ... let's make my ignorance certain. How would I code "string with unicode" vs "string with bytes" So I could make two calls to Logger->log( ...) that would demonstrate the problem.
If I understand the bug, with your current patch. After doing that, eachEventSince() should give different results when written by plainfile logger vs. compatibility logger.
gac410 is still very ignorant when it comes to utf8 and unicode.
[15:04]
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/aWBQjA
foswiki/master d54e0d3 MichaelDaum: Item12481:Item12713: new default design...
[15:11]
***GithubBot has left [15:11]
FoswikiBothttp://foswiki.org/Tasks/Item12481 [ Item12481: working towards 4.0 final ] http://foswiki.org/Tasks/Item12713 [ Item12713: new default design ] [15:11]
jastI'll try and write up a simple-to-understand explanation of the differences [15:12]
gac410I'm playing around now .... and still plenty to read on the net.
Don't go to too much trouble please.
[15:13]
jastwe're going to need to figure out a few things for Unicode-ifying Foswiki, anyway
so it's no wasted effort to do a write up IMO
[15:13]
gac410So If I use uff8, and then do a log of a $str = "\N{U+263A}"; That should put a smiley face into the log and not generate wide print errors, etc. if all is well. [15:14]
jasthere's how to make a UTF-8 byte string: print "\x{c3}\x{bc}";
actually, no, bad example
better to use a character that's not in ISO-8859-1
how about δ (lowercase delta, U+03B4)
as a byte string: "\xce\xb4"
as a Unicode string: "\x{3b4}"
the former is UTF-8 encoded but Perl considers it a byte string
[15:14]
gac410Okay. I'll play with that a bit. I'll add a simple verify_logAndReplayUnicode test for the loggers to try. [15:17]
jastthe latter is Unicode (and internally stored as UTF-8; what it's output as depends on Perl's I/O config or :encoding() and friends)
on a UTF-8 enabled system, both should render as δ
[15:17]
gac410So call log() twice, one with former, one with latter, and see what eachEventSince replays.
Yup that works as a byte string: δ ... Wide character in print at testunicode.pl line 8. ... as a Unicode string: δ
Now to write a test :)
[15:18]
MichaelDaumhow often does the cronjob forward checkins from svn to github? [15:23]
gac410hm.. 10 minutes? [15:23]
MichaelDaumseems to missing out some cycles [15:24]
GithubBot[foswiki] FoswikiBot pushed 2 new commits to master: http://git.io/_D9G4A
foswiki/master 8caf661 MichaelDaum: Item12713: new default design...
foswiki/master 53d99b7 MichaelDaum: Item12481: up'ing copyright year...
[15:25]
***GithubBot has left [15:25]
gac410NatSkin upgrade r17215 should have posted at 10:15 (about 15 minutes ago) I got an email [15:26]
MichaelDaumthere he is. thx, GithubBot [15:27]
jast"Wide character in print" indicates a missing :encoding() layer
and it can really only happen for Unicode strings
[15:27]
gac410jast: Yeah, that's just my perl with two print statements, just to see what happens. Not unexpected ;) [15:28]
jastso, something is converting the byte string to a Unicode string, apparently? and then not using a :encoding()
oh, right
I misunderstood your reproduction of the output :)
[15:28]
gac410Just confirming I did get two lower-case delta's ... I'm still dipping toe in this swamp.
gac410 thinks he's now seen *everything*. A wireless egg minder to track how old your eggs are, indicate the oldest egg, and alert you when you are running low. Yeesh...
Like I really need to spend $70 to get an alert to my cell phone when the eggs are getting old.
[15:29]
.... (idle for 17mn)
MichaelDaumnew foswiki design using the new logo at http://demo.michaeldaumconsulting.com ... feedback welcome [15:51]
gac410Very nice! Is that NatSkin?
Jast: SUCCESS ... LoggerTests::verify_logAndReplayUnicode_PlainFileLogger
lower delta as a byte string: δ
lower delta as a unicode string: δ
[15:54]
jastMichaelDaum: well, that's... colourful... ;) [15:55]
gac410Compatibility corrupts the string, and LogDispatch crashes with wide print
So definitely worth the test.
[15:55]
MichaelDaumjast, thats why it is called customato
gac410, yes
[15:57]
gac410Damn, our test framework has issues: $this->assert_str_equals( $data->[2], $unicode ) fails with wide print
where $unicode is the string with the unicode characters
[15:59]
...... (idle for 25mn)
jast: The eachEventSince() routine always returns a byte string regardless of whether it was logged as byte or utf8 string. Is that correct?
It prints correctly, so it's not corrupted, but its encoding has changed
[16:25]
jastit's not incorrect, I suppose
we haven't really defined "correct" semantics
it's correct if the user-visible result is correct :}
[16:31]
gac410Okay good. It is. And your patch also fixed Compat logger. LogDispatch though crashes in test runner - kills the whole suite.
$e->stringify() in the Catch Error clause has a wide print failure.
Fails in Log::Dispatch itself "Wide character in print at /var/www/foswiki/trunk/core/lib/CPAN/lib/Log/Dispatch/File.pm line 141
I wonder if this would make our test suite more reliable. I changed $e->stringify() to use Data::Dumper, and the suite survives with a readable error.
[16:32]
***gregg4567 has left [16:36]
jastwhere is the call in LogDispatch that makes Log::Dispatch die? [16:38]
gac410It dies when attempting to log a unicode string. The byte string makes it through. [16:39]
jastoh, right [16:40]
gac410Foswiki::Logger::LogDispatch::log [16:40]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Logger::LogDispatch [16:40]
jastso, the code that runs individual test cases should catch errors [16:40]
gac410Well, our error catch code dies as well due to stringify.
So either binmode was set incorrectly? Or _flatten didn't encode correctly?
[16:40]
jastyeah
I think that, since we're already littering Encode calls all over the place anyway, it makes no sense to start using :encoding(), too
either transition everything to Unicode for real, or stick to one approach, and Encode is much more prevalent in Foswiki's code base than anything else
this is what I've written up, by the way: http://jk.gs/perlunicode.html
I'd put it on foswiki.org but it really needs UTF-8 :)
I'm afraid the server is a bit flaky right now, so loading times may vary
no idea what's going on there
[16:41]
gac410So the encode call in _flatten is NOT being executed. I made the call to encode unconditional as a test, and everything passes.
Attempting to log bytestring
FLAT MESSAGE: (| 2014-01-07T16:52:19Z info | info | lower delta as a string: δ | | | |)
Attempting to log unicode
************* Message being encoded
FLAT MESSAGE: (| 2014-01-07T16:52:19Z info | info | lower delta as a string: δ | | | |)
Hm... maybe binmode is not being picked up by Log::Dispatch. Or LogDispatch has been initialized before the unit test gets control and sets the Character set to utf8.
yeah. Thats it. Changed CharSet to utf-8 in LocalSite.cfg, rather than letting unit test set it, and things fail again.
damn. so with CharSet set correctly in LSConfig, and encoding NOT happening, I'm back to character corruption.
[16:48]
.......... (idle for 47mn)
Jast: It appears as though, without some serious internal poking around, I can't easily change the encoding of Log::Dispatch "on the fly" It is going to just live with what is set in the Site CharSet.
If the Site CharSet is UTF8, then your fix-up works fine. But if the character set is NOT utf8, I'm not sure what to do to the message to make it survive uncorrupted.
gac410 is wondering if the solution is to just force LogDispatch to always use utf-8 as the file mode.
[17:43]
.... (idle for 15mn)
jast, your fix doesn't work if site charset is not set. The string is corrupted.
If I change it to Encode::encode ( 'utf-8' instead of iso-8859-1 it fixes the unit test.
[18:01]
***ChanServ sets mode: +o CDot [18:03]
............. (idle for 1h4mn)
gac410Okay, LoggerTest has been expanded to add two fixture groups - Site CharSet utf8 and Site CharSet iso-8859-1 So all logger tests run with both configurations now.
And I've added a test to log a bytestring and a unicode string and test for corruption.
So jast, that leaves us with a bit more work on the plainfile and compat loggers.
[19:07]
GithubBot[foswiki] FoswikiBot pushed 3 new commits to master: http://git.io/jh8W_g
foswiki/master 03e660e GeorgeClark: Item12027: Apply Plainfile fix to Compatibility...
foswiki/master 80ab61d GeorgeClark: Item12027: Expand logger tests for site CharSet...
foswiki/master c22e06e GeorgeClark: Item12027: Hard code LogDispatchContrib to utf8...
[19:10]
***GithubBot has left [19:10]
FoswikiBothttp://foswiki.org/Tasks/Item12027 [ Item12027: statistics/logfile iterator: not respecting SiteCharset ] [19:10]
gac4103 tests are failing. LoggerTests::verify_logAndReplayUnicode_CompatibilityLogger_Charset8859 along with PlainFileLogger and ObfuscatingLogger [19:12]
CDot: Did you see Item12705 ... That seems pretty urgent, and worth an interim release of WysiwygPlugin. Figure best for you to review, as it was your original changes [19:22]
FoswikiBothttp://foswiki.org/Tasks/Item12705 [ Item12705: Verbatim blocks are corrupted on save by Wysiwyg editor if $Foswiki::cfg{Site}{Locale} = 'utf-8'; (hotfix available) ] [19:22]
CDotI'm pretty confident that my change was correct. However I can't control for all variables.
and yes, unicode is a mess. The wrong decision was made a long, long time ago (viz. not to include the encoding in every topic)
[19:25]
gac410hm... if your change is correct, why is it reproducable that verbatim blocks are corrupted. [19:28]
CDotthe analysis is correct, by the way. That code is *specifically designed* to only ever be called on byte strings (which are the standard string representation used in the foswiki core for all data). To call it on a unicode string is an error. [19:29]
gac410Is Micha's proposed fix - deleting the encode, or Jast's Making it conditional - valid [19:29]
CDotMicha's change just re-breaks it. jast's is dangerous; utf8:is_utf8 simply inspects the utf8 flag on the string, and that flag can be set on a byte string which was the source of other problems. [19:30]
gac410so is there any valid fix, other than living with corruption?
;)
[19:31]
CDotI don't know where the problem arises; that requires detailed analysis. Since all incoming data from WYSIWYG is supposed to be encoded into the site charset (i.e. a utf8-encoded byte string) then it should never be called on a unicode string. [19:32]
gac410MichaelDaum: was able to reproduce it I think, so maybe he understands better.
Would utf8::is_utf8(STRING [, CHECK]) which checks for a well-formed utf8 string be safer to use rather than trusting the utf8 flag?
hm... that's only available in very new perl. Never mind.
[19:33]
CDotthat *does* check the utf8 flag
besides, I think in the case described the miscreant character is 0x160 or thereabouts, which *is* well formed.
that's an ongoing problem with trying to reverse-engineer the encoding from the string :-(
basically, you can't do it reliably. It has to be correct-by-construction.
I *suspect* that some part of the string - perhaps the hoisted verbatim? - is missing part of the decoding process. I tried to decode ASAP, but might have got it wrong somewhere.
aha; I think I'm starting to get a glimmering of a suspicion
it all hinges on the character code of Â
[19:39]
gac410So on a slightly different topic, any concerns of hard coding the characterset to utf8 for log records written by LogDispatchContrib Foswikirev:17220 [19:44]
FoswikiBothttp://trac.foswiki.org/changeset/17220 [ Changeset 17220 – Foswiki ] [19:44]
gac410Jast fixed compat to switch the binmode based upon the string contents, but I can't do that in LogDispatch [19:45]
CDotyour decision, but hardcoding it to utf8 is going to make importing the log into a topic a real PITA. That's the only concern I can think of. [19:47]
gac410What jast did (i think) is if someone creates a topic name with unicode in it, the logger switches and writes just that one line with utf8 encoding. [19:49]
CDotouch [19:52]
gac410LogDispatch won't let me do that. :) So log strings with unicode just die with a wide print in the file i/o. Hardcoding the i/o seemed to be all I could do.
Maybe 1.2 should be a "convert to utf8 or is that UTF-8 lax. vs strict and put this mess behind us.
[19:54]
CDotbottom line, you should always encode all incoming strings (including topic names) in the {Site}{CharSet} and then write the logs using that
there should be nothing other than byte strings (encoded using {Site}{CharSet}, but still byte strings) in the core.
[19:55]
gac410Is my unit test Foswikirev::17219 verify_logAndReplayUnicode bogus then?
Foswikirev:17219
[19:57]
FoswikiBothttp://trac.foswiki.org/changeset/17219 [ Changeset 17219 – Foswiki ] [19:58]
gac410gac410 figures I need to revert it all 'till I understand it ... possibly never :( [19:59]
CDotdunno, can't look, trying to understand verbatim problem (yes, I can reproduce it). [20:00]
gac410Ah... good. That's the more urgent issue for sure... topic corruption is nasty. [20:00]
CDotok, looks like that function is called twice, when it should only ever be called once :-(
hum, yes, well, I fixed it I think
Micha's fix was *almost* correct. Required a bit more smarts, but almost.
[20:04]
.... (idle for 16mn)
gac410: what's the semantics for WYSIWYG_STICKY? It seems to be handled the same way as verbatim.....
CDot doesn't recognise it
[20:25]
gac410It excludes the block from any munging by the editor. Verbatim while being edited, but saved as normal tml or whatever.
You can manually apply by using <sticky> ... </sticky> or automatic with stickybits which can detect html arguments and prevent wysiwyg from modifying.
[20:26]
CDothmm, ok, so it has to be handled differently to verbatim
argh, I have another failing test. I have to eat - will post the patch, and come back to this in future.
[20:27]
gac410okay. [20:28]
CDotpatch posted. If you could have a look at the sticky failure, and give me some idea what I should expect, I'd be grateful. [20:31]
gac410okay. Which tests - TranslatorTests? [20:31]
CDotCDot knowns the &nbsp; failure is genuine, but doesn't know how to fix it.
yes, TranslatorTests
[20:31]
gac410Okay ... I'll poke at them. [20:32]
CDotta [20:32]
....... (idle for 31mn)
gac410CDot: I get utterly totally lost in Node.pm. Sticky and Verbatim are processed through the _verbatim routine. I can fix 2 of the fails by making your change conditional, if ( $tag eq 'sticky') then do old stuff otherwise do your way.
But the nbsp's still disappear.
[21:03]
....... (idle for 31mn)
***ChanServ sets mode: +o pharvey [21:34]
gac410Hmm... 20 of the TranslatorTests fail just by changing {Site}{CharSet} to utf8. This shows even with the gazillion tests, our test coverage is still pretty weak. [21:47]

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