#foswiki 2015-04-25,Sat

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

WhoWhatWhen
jomogac410: could you try please enter one character (e.g.: x) into the search field and press enter? [00:27]
gac410Could not perform search. Error was: Assertion failed! [00:28]
jomoi got error meesage: Could not perform search. Error was: Can't locate object method "pagesize" via package "Foswiki::Search::InfoCache" [00:28]
gac410hm yeah I can't search on anything fewer than 3 characters
Let me turn off asserts.
Yeah Can't locate object method "pagesize" via package "Foswiki::Search::InfoCache" fails if asserts are disabled.
Interesting Search on a dot, or #, and it works, but a or x fails.
[00:28]
jomoč is ok
e.g. unicode
[00:31]
gac410With asserts enabled, the failure is ASSERT( $infoCache->isa('Foswiki::Iterator::PagerIterator') ) if DEBUG; [00:35]
jomotask it or not to task? [00:36]
gac410The very next line attempts to access pagesize, So the root cause is for some reason the infoCache is not initialized. Task. Urgent. [00:36]
jomohttp://foswiki.org/Tasks/Item13383 [00:39]
gac410Okay thanks. This is really difficult code. [00:40]
On the crash in search, searching for a single letter that's okay on 1.1.9 so it's only trunk with the pagesize issue. The pager was redesigned for 1.2 [00:49]
...... (idle for 26mn)
***jomo has left [01:15]
jomoafter the bootstrap, e.g 1st save get saved into the LocalSite.cfg
$Foswiki::cfg{RCS}{asciiFileSuffixes} = '\.(txt|html|xml|pl)$';
e.g. ONE backslash - any subsequent save change it to
$Foswiki::cfg{RCS}{asciiFileSuffixes} = '\\.(txt|html|xml|pl)$';
e.g. for TWO backslashes. I don't know were this can cause problem - but sure isn't fully ok...
[01:25]
gac410That's actually okay I think. The Spec defines it as qr/\.(txt|html|xml|pl)$/;

But it's saved in the config as a string.
[01:29]
jomowhy the 1st save save it with 1 backslash and the second save with two? [01:30]
gac410So the \ has to be a single character, and NOT an escape. Oh... I didn't catch that. Hm...
Yeah this might be an issue. In a string \. is an escaped . while \\. is a backslash and a dot.
[01:30]
jomoi'm not using RCS store - only catched the change... when diffing two LocalSite.cfgs [01:32]
gac410Indeed I think you've found something. It looks like it might incorrectly init a ascii file as binary in the rcs system. I'm not sure the impact of it.
strange, the regex seems to match okay with either \. or \\. in the string.
[01:35]
jomohm.. thats really __IS__ strange.
What is the point of the Set WEBFORMS = in the preferences?
[01:40]
gac410It primes the select box when editing a topic, to assign a form to it.
You can still attach a form to a topic, but not via a dialog.
[01:43]
jomoand you can move between different webs with already attached form...
;)
[01:45]
gac410yes. afaik it's only there so the ui can present a list of available forms. [01:45]
jomook - just wondering... so the main point is doesn't show for attaching any topic what ends to Form [01:46]
gac410So on the SEARCH crash. SEARCH delegates down into Store for the query. In some cases it returns the wrong object type and I have no idea why.
jomo, right. We could search for *Form, but some of this dates back for forever. ... it just is. :)
well it returns as an error message, so it
it's not catastrophic, but right, it blocks beta2
nah... I can assure that all rather have a really solid 1.2. Every issue you find is one that we avoid later.
I kinda think I could create a hack that addresses the search crash, but it's really not right. We really need to determine why Store doesn't return a list iterator sometimes.
[01:47]
jomothe 1.2 is really huge step forward [01:51]
gac410yeah I'm sure I'm guilty of that as well. [01:54]
jomoretrun undef; in the list context mean an non-empty list with one (undef) element - what is usually wrong...
wouldn't be suprised abuout the search error.. ;)
[01:55]
.................................................... (idle for 4h16mn)
***ChanServ sets mode: +o CDot [06:12]
.............................................................................. (idle for 6h27mn)
ChanServ sets mode: +o Lynnwood [12:39]
................ (idle for 1h18mn)
timleggeLynnwood I wrote up my Ubuntu notes at http://foswiki.org/Sandbox/TimothyLeggeSandbox if its useful for you [13:57]
Lynnwoodmorning timlegge
i'll check it out. thanks!
[13:58]
timleggenp I am just on the way out feel free to use [13:58]
Lynnwoodwell just looking at it, i'm already learning things. (My knowledge is so shallow in many areas)
like -i with sudo...
or your use of sed in changing hosts.... i always fall back to just editing things with vi
otherwise... that's pretty much my process also. yours is very clean.
i notice you enable access_compat even though you use 2.4 access syntax
is there a reason for that? does access_compat provide something besides the permissions compatibility with old syntax
you're probably already on your way.
i should be.... bloody weedeater wouldn't start so i'm back in trying to figure that out.
[13:59]
.... (idle for 19mn)
timleggeLynnwood I have not looked in depth at the compat module so I likely don't need it. I had skimmed over the installation guide and noticed it
I will disable it and see.
Still a foot and half of snow in the middle of my lawn - no weed eater her
Lynnwood as for sed I like to spend 10 minutes figuring out how to save me 15 seconds in the future :-) - Making it possible to simply copy paste into a terminal save me some greiif
[14:24]
................................ (idle for 2h36mn)
timlegg3Lynnwood I just rand the directions through on Ubuntu 15.04 and it resulted in a working foswiki. I made minor changes apt-get -y and sed -i [17:04]
.................................... (idle for 2h56mn)
***ChanServ sets mode: +o gac410 [20:00]
............ (idle for 57mn)
gac410gac410 is concerned about the fixes to http://foswiki.org/Tasks/Item13378 ... If this is a major effort to support wide characters in utf8 foswiki, it's potentially delaying 1.2.0 significantly. [20:57]
jomogac410: what do you mean with "supporting wide characters" - currenty foswiki supprts utf8 encoded topics - so supports wide characters... (with owns bytestring way) :) [21:09]
gac410jomo, if I understand the bug, you are running into it because the Czech national characters you are testing with in one case is a 2-byte character (utf-16?) [21:22]
jomogac410: no, all characters are utf8 encoded (in the file). utf8 encoded mean theyre 1-6 bytes long (IIRC)... perl internally (when using correct decoding at the borders = uses 8-72 bits for storing a character...(code-point). Doesn't mix utf-16 (what is an different encoding method with the utf8 encoding)... [21:30]
gac410oh okay. [21:30]
jomoso, 1 char - for ascii, 2-chars for common latin planes and >2 for some others, like smiles klingonian and so... try "perl -E 'say length("á")' - e.g not czech character but common á (but utf8 encoded) the above prints 2 (if your terminal is utf8) - but the perl -Mutf8 -E 'say length("á")' prints 1. [21:30]
gac410okay, so if I followed that, the Mutf8 caused perl to count characters, where as without it, it counted bytes. [21:32]
jomoyes
the Mutf8 says - the code contains utf8 encoded characers - so the perl, when reading tge source code properly decodin them
this is the only meaning of the -Mutf8
[21:32]
gac410The only explicit "use utf8" statements in foswiki are in the Logger, and Event iterators (also part of the logger). [21:41]
jomowe don't need "use utf8" - it only says: the perl source code contaisn utf8 encoded text. It has nothing with the data, what reading from the file or network. for this enough use Encode::decode on teh borders... [21:42]
gac410yeah that's an issue. (why do you redact the logger?) yes, Perl 5.8.8 is minimum perl for 1.2.0. That's why the I18N / Locales support is deferred until 2.0
Your example earlier. perl -Mutf8 -E 'say length("á")' functions exactly the same as perl -E 'use utf8; say length("á")'
[21:43]
jomobecause the 'á' is in the source code...
another example
perl -MEncode=decode -lanE 'say length(decode(utf8 => $_))' <<< "á"
[21:45]
gac410got it. thanks.
gac410 wonders if it would make sense to have the configure checker WARN if {Site}{CharSet} is utf8 and perl version is < 5.14
[21:47]
jomovs
perl -MEncode=decode -lanE 'say length($_)' <<< "á"
or more precisely
perl -lanE 'say length($_)' <<< "á"
the 1st prints 1 the last 2 (doesn't decodes) prints 2
[21:55]
gac410so based upon that, I should remove the "use utf8" from the logging modules.
As there is no utf8 in the source.
[21:57]
jomoif they doesn't contains any utf8 in the source code - you could - but it doesn't harms... [21:57]
gac410A while back in 1.2 ... when I was planning to release LogDispatchContrib as the default logger, we decided to change all the logging & event iterator code to write / read in utf8
Because LogDispatch did utf8 native, and we kept running into wide print errrors when switching between loggers.
[21:58]
jomoas i told - i don't know foswiki's "logic" enough deeply to say something "wise" - how to do something when using octets.. ;( i simply not enough skilled with hacking - all my code encodes/decodes at the borders - so ... don't know... that's why i'm not very active in the current FW development... it is too )verally very) hackish for me .. ;( [22:02]
gac410Foswiki core is probably reasonably clean regarding "edge points" The huge problem will be the 300-400 extensions, many imported from TWiki with little ongoing maintenance. [22:04]
jomoyes - this is an REAL problem... some of doing the encoding things in their own way ... therefore the future 2.0 (correct unicode core) will be HARD change - not because the core - but because of the extensions... [22:06]
gac410I suppose there will be backwards compatibilty issues as well. Once an extension in updated for the 2.0 core, it will have issues on 1.1 / 1.2 [22:07]
jomohmm... not necessary - (of course - the custom plugins written by users - could have problems - regarding how much they using some encoding stuff. If theyre not using things like if( $c = 0xe1 ) for some iso-latin-2... the transition could be more-or-less painless.
The best is - the encoding of the FILES (e.g. the encoding of the *.txt files - could remain for exampel ISO-8859-2 - because we will (i hope) doing the proper encoding at the borders - when reading/writing...
[22:10]
gac410I hope nobody is doing that :D
hm I thought the recommendation with 1.2 will be for people to run the CharacterConverterContrib to consider migrating store to utf8
[22:11]
jomoso the clients who already has zilion ISO-8859-2 encoded topices could continue to use them... [22:11]
gac410http://foswiki.org/Extensions/CharsetConverterContrib can take an RCS store in any charset and convert it to UTF8
gac410 was wondering if we should be shipping that with 1.2 as well.
(It doesn't work with PlainFileStore though. So need to utf-8 older store before converting to PlainFile
[22:12]
jomonot need - see when reading a file we Encode::decode($Foswiki::cfg{Site}{CharSet}, $filecontent) - e.g. we converting the ISO-8859-2 into correct perl "internal format" (remember we don't need to know what format is it) :) :)
because we doens't doing the decoding right after the reading... :( just checked the new PlainFileStore...
[22:13]
gac410Is there an advantage then of defaulting to utf-8 store instead of iso-8859-1 as Foswiki 1.1 does [22:14]
jomoSee, when we will doing: open(my $fd, "<", $filename); $content = do{local $/; <>}; return Encode::decode($Foswiki::cfg{Site}{CharSet},$content); - we can have the files encoded in ANY encoding... doesn't matters - we can do the RIGHT encoding at the borders... [22:16]
gac410We need to have a discussion with Crawford (CDot) MichaelDaum, Jast, you and me... about this and decide what goes into 1.2. Would return Encode::decode($Foswiki::cfg{Site}{CharSet},$content) be safe to just add?
I assume the reverse is required when a file is written.
[22:20]
jomoyes
but not for 1.2
[22:20]
gac410There was a proposal at one point to add the encoding to the META:TOPICINFO but that was rejected as not a good idea. [22:21]
jomousing the internal unicode characters in the perl - need 5.14 (5.12 will work somewhat, but 5.14 is ok)... 5.16 the best.. ;)
IMHO it is a good proposal - but in the "democracy" the majority wins... ;) ;) :)
[22:21]
gac410that's a battle I've fought and lost :( All my "use version 0.77" code was reverted from extensions because version 0.77 came with perl 5.10.1 and caused issues on old "stable" installations. [22:23]
jomoso - for 1.2 we need somewhat HACK the problems - for 2.0 (with perl 5.14) we will have an easy way :) (of course at the price of the extensions - and like) :) [22:23]
gac410Thankfully we got agreement to "use 5.8.8" where as Foswiki 1.1 requires Perl 5.6 :P
gac410 ought to pull out all the perl 5.6 tests when I come across them.
UTF82SiteCharSet accommodated perl 5.6 yech.
[22:24]
jomowith this logic - we will have 5.10 up to 2018.... just checked Distrowatch - redhat 6.X has end of life in 2018 or like - and containing 5.10 - that's unacceptable - the perl.org supports only 2 stable versions e.g. currently the last supported is 5.16 - and soon when the 5.22 will be released the 5.18 will be the last supported... [22:26]
gac410preaching to the choir here ... [22:26]
jomo:) [22:26]
gac410If sites want stable, they can stay on Foswiki 1.1 I guess it's the extensions that cause issues, because Extensions web has no way to version them. You *always* get the newest version.
Nobody has figured out a clever way to handle them.
[22:27]
jomojomo needed to use google translate for the "preaching" :) :)
yes - this is another problem... don't know how - but the extensions should have some pairing with the working FW version...
[22:27]
gac410"preaching to the choir" is an idiom, that says you are "advocating" to the believers. [22:29]
jomoyeah - translated - understand ;) [22:30]
gac410We have a way for an extension to check the Foswiki API version, but that's about it.
http://foswiki.org/Development/FormallySupportMultipleExtensionVersions I tried, and objections were raised, and proposal stalled.
[22:30]
jomomy opinion - we need release somewhat soon as possible 1.2 (as much as possible utf8 ok - in the currect hackish form. It works (mostly) with utf8 texts - and some "border" issues could be "documented errors" - and start working on the FoswikiNG (next generation) :) :) [22:32]
gac410Yeah. I'm hoping that Crawford doesn't get "too enthusiastic" in his fix :D [22:33]
jomoagree ;) [22:33]
gac410Just like my Item13331 branch with CGI -> template ... it was too much for 1.2 [22:33]
jomounfortunately - but yes. ... same issue..
the 1.2 is (in the current form) HUGE step in usability...
really only few fixes remains (maybe some are complicated) - so i hope you will next wwwkend generate the beta2 :)
[22:34]
gac410y. I'm tempted to ignore the search \ issue. Its a TML design issue. \" is always an escaped quote in a macro. so any parameter cannot end with \" unless it's the last part of the macro. [22:37]
jomothis is one of the problems what we can safely ignore in 1.2 ;)
nobody cares from 1.1.9 - so ...
[22:37]
gac410yeah I saw your note last night. Only so many hours. :) [22:50]
jomogood apetite ;) [22:51]
..... (idle for 22mn)
gac410Yes. Look at System/PerlDoc
There is a special INCLUDE handler that knows how to process foswiki modules and extract / render the TML
It's been that way for a very long time. Before Foswiki certainly.
[23:13]
jomonice feature - but unfortunately - can't be cpanified... [23:15]
gac410So it's nothing to do with BuildContrib. it doesn't care. It's realtime rendering. [23:16]
jomoreading thru - really nice - never opened this Topic yet ;)
LOL - it detects my SMELL :) what i wrote to my hacking copy of FW :) :)
[23:19]

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