#foswiki 2013-03-01,Fri

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

WhoWhatWhen
gac41046 downloads so far on sourcforge for 1.1.8. no complaints. I guess I'm good to go with an announcement. [00:02]
.... (idle for 16mn)
1.1.8 is now the default download on sourceforge. Update to freecode has been submitted.
Anyone... we really need some marketing help! I'll do an email to the announce list later tonight, but someone needs to pick this up and blog / tweet / and otherwise promote this release
Please help ....
[00:18]
.............. (idle for 1h5mn)
***ChanServ sets mode: +o pharvey [01:24]
............... (idle for 1h13mn)
RVP11when I want to copy over foswiki/data and foswiki/pub
do i avoid the System folders in them?
[02:37]
gac410Are you switching to a different release / or an installation with different extensions installed? [02:38]
RVP11i copied over /data/Main so far
i have a seperate server running 1.1.7
[02:38]
gac410You probably do not want to copy System, unless the installed extensions, etc. are identical [02:38]
RVP11the current one is running 1.1.5
yeah they aren't
[02:38]
gac410Then DEFINITELY don't copy System. [02:38]
RVP11roger
is _default and _empty needed to be copied?
[02:39]
gac410Not unless you've customized them.
See http://foswiki.org/System/UpgradeGuide it has details about copying between different versions.
You really need to know what was tailored on your 1.1.5 install. For ex, templates, skins, etc.
The working/ directory can be important to copy, especially some workareas like the MailerContrib record of the last email timestamps for webnotify
[02:39]
RVP11so stay away from copying locale, lib, and bin? [02:46]
gac410well those contain the strings and modules and code. If you copy them you won't have 1.1.7, you'll be back on 1.1.5. [02:47]
RVP11roger [02:48]
***ChanServ sets mode: +o pharvey [02:54]
...................................... (idle for 3h5mn)
EnriqueCadalso has left [05:59]
................ (idle for 1h18mn)
ChanServ sets mode: +o CDot [07:17]
CDotSvenDowideit: about? [07:27]
........... (idle for 53mn)
jastthe release announcement is on the blog now [08:20]
........... (idle for 51mn)
pharvey1boo [09:11]
jasthey
don't scare me like that
[09:15]
foswiki_irc7I just got the 1.1.8. upgrade and found the md5-file is missing on sourceforge. [09:27]
michalorOh, and the link above the chat targeting today's log is missing a trailing i :-) [09:28]
jasttoo bad I can't do anything about either of those
but I'll let folks know
[09:28]
michalorI've got a question regarding FormPlugin (and SendEmailPlugin) - I would like to save data from FormPlugin to a DataForm (which works) _and_ send an mail when submitting the data
Can this be done?
[09:33]
***ChanServ sets mode: +o MichaelDaum [09:41]
...... (idle for 27mn)
foswiki_irc1CDot or anyone who plays with ActionTrackerPlugin...
I've updated via debian apt-get
and ATP has stopped working completely
It seems that the update didn't set the ownership to www-date
so several templates were root:root and pub/System/ActionTrackerPlugin was all root:root too
Still doesn't work (atp code isn't interpreted) - where else can I look?
Also, how do I map version 130228 build 279 to the version numbering CDot has used?
[10:08]
pharvey1SvenDowideit: going RDF? w00t :) [10:12]
jastlook at working/logs/error.log for error messages related to plugins not loading [10:12]
foswiki_irc1Thanks. Same problem of ownership for lib/Foswiki/ActionTrackerPlugin.pm and the folder
But now I get a different error: Can't use an undefined value as a HASH reference at /var/lib/foswiki/lib/Foswiki/Plugins/ActionTrackerPlugin/Options.pm line 15
Which is: %options = %{ $Foswiki::cfg{Plugins}{ActionTrackerPlugin}{Options} };
Just checked - the plugin page in SystemWeb appears to be blank...
Also an ownership problem, but now I have fixed that, going to the plugin page generates the same HASH error.
[10:18]
jastyou may have to edit/save the ActionTrackerPlugin settings in /bin/configure once
btw, ownership shouldn't normally matter unless the file permissions are very restrictive, too
(except that wrong ownership in data/ and pub/ and possibly others spams warnings in /bin/configure
SvenDowideit: apparently there's some kind of file ownership issue in the debian packages built by your scripts; so far two people have pointed out issues
[10:24]
foswiki_irc1Ownership is set to 440 root:root! [10:28]
CDotfoswiki_irc1: to the best of my knowledge, nothing I did in the release process should affect permissions. Ownership is set by the installer and permissions by the MANIFEST, which AFAICT is correct. Suspect this may be an issue with the debian packager. [10:29]
foswiki_irc1I've unticked ActionTrackerPlugin in bin/configure, saved, then reticked and saved, no change [10:29]
foswiki_irc4Lost my connection. Does this tell you anything about what might be amiss with the ATP: http://pastebin.com/KFXcVPFz [10:31]
CDotfoswiki_irc4: yes, it tells me you need to run =configure= and save
there is a new option that needs to be added to your LocalSite.cfg, {Plugins}{ActionTrackerPlugin}{Options}
running configure will also execute the (required) configure checker
[10:33]
jastCDot: seems like Config.spec is missing in SVN [10:33]
CDothuh? /me checks [10:34]
jastthat would explain it, at least :) [10:34]
CDotgoddamit [10:34]
ok, it's there now
sorry about that
[10:39]
jastso I guess that means a re-release...? [10:39]
CDotit's been uploaded, if that's what you mean
dunno about the debian packages; don't they get generated automagically?
[10:40]
jastthey are [10:40]
foswiki_irc4With what sort of lead time? When should I check? [10:41]
CDotI think Sven builds them every 24 hours. Dunno when exactly, but probably his nighttime - guessing 21:00Z (ish?) [10:42]
foswiki_irc4Thanks. Is it possible for me to just add whatever is needed in the mean time to LocalSite.cfg? [10:44]
***ChanServ sets mode: +o MichaelDaum [10:48]
jastsure... look here for the defaults: http://trac.foswiki.org/browser/trunk/ActionTrackerPlugin/lib/Foswiki/Plugins/ActionTrackerPlugin/Config.spec [10:48]
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/HUmEdQ
foswiki/master affa217 CrawfordCurrie: Item12315: add missing Config.spec...
[10:52]
***GithubBot has left [10:52]
FoswikiBothttp://foswiki.org/Tasks/Item12315 [ Item12315: JQueryPlugin from Foswiki 1.1.6 breaks Shortcut in ActionTrackerPlugin ] [10:52]
foswiki_irc4Great. Thanks guys. I've created the Config.spec file, gone through a round of configure saves and everything is peachy :-) Plus I have got my pop-up action edit working and using the calendar doesn't force a save :-) [10:59]
CDotexcellent! :-) [11:00]
..... (idle for 20mn)
FloPrihello guys. I this formfield: %META:FIELD{name="Verantwortlich" attributes="M" title="[[KategorienVerantwortlicheListe][Verantwortlich]]" value="Main.GerlindeT"}% but at the bottom of the page in the formfield there is no Link just GerlindeT? which wants to create a page in Home.GerlindeT. Any guesses what went wrong? [11:20]
jastwhat's the definition for that field in the form? [11:22]
FloPri| [[KategorienVerantwortlicheListe][Verantwortlich]] | select+values | 1 | | | M | [11:23]
@jast: thx for your time. dont worry if you cant find the reason i will try myself again next week an post the solution here if its interesting. byebye [11:36]
michalorIs there a way to use FormPlugin to save the data to a topic _and_ send an mail to an address just entered into some field? [11:42]
............. (idle for 1h3mn)
***ChanServ sets mode: +o Lynnwood [12:45]
...................... (idle for 1h45mn)
ChanServ sets mode: +o gac410 [14:30]
gac410 changes topic to: Download Foswiki 1.1.8: http://foswiki.org/Download/FoswikiRelease01x01x08 -- Today's IRC Logs: http://irclogs.foswiki.org/bin/irclogger_log/foswiki [14:35]
gac410CDot: Once a task has been closed and published in release notes, please don't re-open for more fixes, make a new task. Otherwise release notes will be confused. Item11209 was fixed in 1.1.4 [14:39]
FoswikiBothttp://foswiki.org/Tasks/Item11209 [ Item11209: Store is returning wrong information in history ] [14:39]
CDotok, sorry. just trying to analyse unit test failures, of which there are a lot. Looks like someone made changes to the VC store that have fucked a lot of unit tests. :-( [14:40]
gac410I noticed that on trunk a while ago. We need the nightly tests to actually run. Hm... or PHarvey's WIP where he was going to auto-bisect each failing test to the commit that caused it. [14:41]
CDoterm, VarADDTOZONE is provided by the ZonePlugin, but the ADDTOZONE is a built-in macro in 1.2.0 core. So when you build the core without ZonePlugin installed, it barfs. [14:43]
gac410hm. build of a real release? which build? [14:44]
CDot1.2.0 [14:45]
gac410if you want I'll look at that one. more my speed than store :D [14:45]
CDotCDot is trying to understand why the tests are not running, without having access to the scripts [14:45]
gac410I think his server is badly ristricted on memory
iirc, Sven has a small vm with no swap space.
[14:45]
CDotok, Well, I haven't actually tried to build, so don;t know it the ADDTOZONE actually causes a fail, but it's deffo a problem [14:46]
gac410Intentional, so it can pick up on memory growth. [14:46]
CDotCDot spotted it in the pseudoinstall output [14:46]
gac410His release01x01 tests don't run either.
(or at least they weren't
I have made changes to the release01x01 "build" script, maybe it was me.
(mainly to switch to the new release numbering).
I thought his scripts were all in svn
yes... I think he runs tools/autoBuildFoswiki.pl
Well I don't think I broke it too badly. At least on 1.1.8, perl ../tools/build.pl release -auto seems to be properly building an auto-named release.
[14:46]
CDotn.m. about the ADDTOZONE - flase alarm. I have pseudoinstall -u all, so the ZonePlugin removal had stripped the VarADDTOZONE.txt [14:55]
gac410I don't have a svn checkout of trunk, only git. so autobuild needs some tweaking sometime to become more SCM agnostic
:P Well autobuild does a fresh checkout, into current directory.. I now have svn/Foswiki/Release01x01/core/tools/Release01x01/core/ ....
[14:56]
hm... Also a "todo" is to redo the pseudo-install, so that's not done. I wonder if these builds are useful. Don't we need to run pseudo-install to get clean compressed copies of the js / css [15:12]
Demosthenexany new skins to hide edit and present a clean look for biz sites? [15:17]
CDotDemosthenex: hide edit? why? If you want to present an uneditable site, generally best to use the PublishPlugin and serve static HTML to those who cannot edit
unless, of course, you need to present dynamic results (like search results) to those users
[15:20]
DemosthenexCDot: i'd rather foswiki than wordpress?
a static biz site... where only the admin makes edits.
i have a hacked up old rev of foswiki i run already with css edited to hide all the controls
noticed the security updates, thought it relevent
[15:22]
CDotok. Well, start with any skin and make the edit button conditional on the user being able to edit/save [15:23]
gac410There is a simple css change to disable the controls iirc
+.foswikiHasNoChangePermission.foswikiLoggedIn .foswikiRequiresChangePermission { display: none; } */
... in base.css
Been a long time since I looked at it though.
[15:23]
Demosthenexi asked on here before about designing custom css for a plain biz site.
been a while.
i'd still be opening to paying for a simple, quiet, controls hidden skin
[15:24]
gac410gac410 is really not a css wizard at any stretch. (And that change I posted was a nop here. I have no recollection of what it did :( ) [15:27]
Demosthenexegad, i may still be on an ancient twiki
http://www.adamsinfoserv.com/
[15:36]
gac410Yes indeed it sure looks that way. I could not get to the TWiki/WebHome (needed login) But TWiki/InstalledPlugins was visible. But no version information on that page [15:40]
Demosthenexyeah, i went through and locked it down from a navigation perspective
i have no interest in hand writing html, nor running some database backed abomination for a simple page... foswiki (and formerly twiki) are just enough, but a static browser needs no controls
edit, revisions, etc
[15:41]
gac410Well, that css change I posted at one time actually worked. But it seems to be totally non-functional now. probably something simple/stupid But ArthurClemens our css wizard is not around. [15:43]
CDotDemosthenex: why not just edit the templates and whack them? or it the look of the pattern skin wrong for you?
public or private site?
[15:43]
Demosthenexpublic viewing, private changes. [15:44]
gac410All of the controls have a style .foswikiRequiresChangePermission so a css style change to set display:none when no change permission should be possible. [15:44]
CDotpublic, as in wild internet? Any registration? [15:44]
Demosthenexyeah, i have quite a few things set to none
no registration, only one user login.
it's on the net, but admin only
i guess i use it as a small content server...
my website is a placeholder, it doesn't get me business.
[15:44]
CDotI hear you. So what sort of look do you want? [15:45]
Demosthenexclean and minimal. [15:45]
CDotsame L&F as you currently have? [15:46]
Demosthenexessentially [15:46]
CDotok. Well, I could do that for you. [15:46]
Demosthenexi can't pay a ton, but i figure what i want should be less than 4 hours for someone experienced with foswiki and the css system.
at the same time, i also don't mind if the resulting skin is kept open and contributed to foswiki for reuse by others
[15:46]
CDotCDot has pm'ed Demosthenex [15:48]
gac410:( At one point, the CSS and template for Foswiki:Development/EnableWikiEditingOfSystemTopics that ArthurClemens helped me build was working great. Looks like something broke it. [16:01]
FoswikiBothttp://foswiki.org/Development/EnableWikiEditingOfSystemTopics [ EnableWikiEditingOfSystemTopics ] [16:01]
gac410AH... it works. Provided I understood what it was doing in the first place. That code allows guest to attempt edit (triggering a login). It hides edit from logged in users who have no edit authorithy.
It was specifically intended to allow public editing of Foswiki System web by a controlled list of users. So rendering links for guests is reasonable.
gac410 really ought to get that change into our foswiki.org site, so we can allow developers to edit system topics. It is a wiki :) But we need the backend magic to merge edits into the SVN repo.
[16:08]
MichaelDaumanother great too for commenting is http://disqus.com/
^too^tool
public blogs use stuff like that so people don't have to register on that blog just for the purpose of leaving a comment
darn easy to integrate too
[16:19]
gac410CDot: We just got two registrations from 123.237.176.20 ... Main.RuchiSharma and Main.HairExperts
Honeypot doesn't find the IP suspicious ... :(
[16:29]
jastMichaelDaum: I simply don't comment on blogs if they require _any_ kind of account [16:30]
CDotgac410: yeah, I saw HairExperts - look s like a gen-yew-wine business in the Antipodes [16:31]
gac410The other registration from the same IP used a gmail address that was totally different from the wikiname. [16:31]
MichaelDaumjast, disqus has got an "allow trolls" mode as well, and moderation. [16:31]
CDotMichaelDaum: when you made the recent changes to the RCS store, did you run the unit tests? [16:31]
MichaelDaumCDot, of course. [16:32]
CDotwe're getting splattered with test failures, and they look related [16:32]
MichaelDaummost of the work I did was fixing tests [16:32]
CDotI noted you changed the VCStoreTests so that they assume a "broken" store. That's OK, but gave PlainFileSToreContrib wobblies for a while
until I realised what you had done
[16:33]
MichaelDaumI did not assume a "broken store"
only a bud pain slow one
[16:33]
CDota store in which the concept of "checked in" exists - which by the way Foswiki works, is broken
I don't have any problem with what you did, but any "non-broken" store cannot re-use those tests
[16:34]
MichaelDaumcould you explain more what you mean by "broken", please [16:34]
CDotok; Foswiki store has no concept of "checked out"; it assumes that the most recent rev of a topic is correctly numbered
your tests actually assume it will *not* be correctly numbered, because the store is "broken"
i.e. the rev info it returns is wrong in certain cases
[16:35]
MichaelDaumI don't think thats an accurate description of what I was aiming at
let me explain
[16:36]
CDotyou just built on what I had done with the "inconsistent topic" tests [16:37]
MichaelDaumwe have a massive performance problem in 1.1.x [16:37]
CDoty, I know why you did what you did, and I'm fine with it, except that those tests are now specific to RCS-based stores [16:37]
MichaelDaumthe performance problem stems from the fact that the external rcs tool is called far too often
the performance problem was not there a couple of releases ago, i.e. it is not there on TWiki
[16:37]
CDotno, because TWiki ignores the problem and hopes it will go away [16:38]
MichaelDaumPeter once explained why he invented META:TOPICINFO
he described it as a cache of the top rev info
[16:39]
CDotwhich it isn't [16:39]
MichaelDaumsorry: he was right. [16:39]
CDothe *should* have been right, but he didn;t plan for out-of-band changes
which result in the cache being written by other agents
and thus getting out of synch with the top rev
[16:40]
MichaelDaumthen you changed it in the hope to bring in more "correctness" which unfortunately resulted in the massive performance problem we have on the 1.1.x branch [16:40]
CDotcorrect [16:40]
MichaelDaumcorrect
the idea of my changes are now the following
trust META:TOPICINFO as much as possible
whenever possible and nothing odd has happened due to oob changes, read the rev number from there, instead of forking rcs.
thats it
there are however lots of implications coming with this
for one
before my changes, the store was not properly writing META:TOPICINFO in a reliable way at all
tests assumed that even after a proper save() cycle this info was not created necessarily
I changed this
so whenever something is stored, it gets a META:TOPICINFO record as things pass the store api
in 99% of all cases topics are _not_ changed oob
which means rcs and META:TOPICINFO are in sync
so in 99% of all cases it is save to read the top rev number from there
[16:40]
CDotthat's fine, but it doesn't change the fact that the tests assume the store will return incorrect info. Specifically, they assume that it is possible to create an inconsistent topic
in the case of the plainFileStore it isn't, because the meta-data is not stored in META:TOPICINFO
hence the test doesn;t work with that store impl.
[16:46]
MichaelDaumic [16:47]
CDotI'm not accusing you of any error; just pointing out that the test assumes it is possible to create an inconsistent topic [16:47]
MichaelDaumnot sure what you mean by that [16:48]
CDotso we need to reserve the VC tests to run *only* on Rcs-based stores [16:48]
MichaelDaumor you get back to storign META:TOPICINFO the normal way [16:48]
CDot? [16:49]
MichaelDaumplainfilestore creating a META:TOPICINFO record in the txt file as the rcs impl does. [16:50]
CDotPFS works by detecting damage to topics, by comparing file dates
if it finds damage, it fixes it immediately
[16:50]
MichaelDaumoha [16:50]
CDotit will rewriute META:TOPICINFO [16:50]
MichaelDaumMichaelDaum wished somebody would implement something simple and stupid [16:51]
CDotsomeone did: RCS :-) [16:51]
MichaelDaumnot funny [16:51]
***Demosthenex has left [16:51]
MichaelDaumI know you are smart and I know some of your code is too. [16:52]
CDotif you find that PFS has too high an overhead from saving damage, you can kill it, but my benchmarks show it's pretty damn fast [16:52]
MichaelDaumbut sometimes things are better when they don't become too baroque [16:52]
CDotbut it's one of the reasons I wanted other people to look at it
it's not baroque; it's very simple.
[16:52]
MichaelDaumso whats the idea of adding an autorepair feature to PFS? [16:53]
CDotbecause META:TOPICINFO must die. It is a hack to overcome a problem with the RCS implementation that has leaked into the core code [16:54]
MichaelDaumwait a sec [16:54]
CDotmost stores won't have this problem [16:54]
MichaelDaumisnt that preoptimization? [16:54]
CDotpreoptmization? In what way? [16:54]
MichaelDaumthe basic idea of pfs is brilliant [16:55]
CDotif META:TOPICINFO hadn't already existed in the core, PFS would have been a hell of a lot simpler
handling META:TOPICINFO was the most work of anything
$store->getRevisionInfo should have been enough
let the store work out the meta-data best it can
[16:55]
MichaelDaumagreeing
yet I wished things would be kiss
[16:56]
CDotdon't shoot the messenger :-) [16:57]
MichaelDaumwhy is it so hart to maintain META:TOPICINFO?
as part of the txt file?
[16:57]
CDotit isn't hard. But the RCS stores don't do it. [16:58]
MichaelDaumright it is done one level before [16:58]
CDotI said it was the most work; it was, but only because the rest of the PFS is so simple [16:58]
MichaelDaummind you I have exagerated hopes for PFS [16:59]
CDotif you're curious about it, see _saveDamage in the PFS. That fxes META:TOPICINFO during a save [16:59]
MichaelDaumthat magically all performance grief vanishes in a pink puff [16:59]
CDotah, still got search to deal with
but compared to RCS it is better, for sure, with large rev counts
[17:00]
MichaelDaumI am not sure there should be a _saveDamage as part of the lower store code. [17:00]
gac410the concept of META:TOPICINFO is questionable, in that topics and attachments have two different requirements. Can't stuff cache info into non-topic files. [17:00]
CDotagreed; it's onlythere because of f**king META:TOPICINFO
gac410: that's another excellent point
PFS stores the equivalent meta for attachments to META:TOPICINFO
it just can't give it to the core, because there's no API :-(
[17:01]
MichaelDaumthe "META:TOPICINFO" of attachments is called META:FILEATTACHMENT [17:01]
gac410I assume it only exists in the first place because rcs is so awful slow. [17:02]
CDotargh!
META:FILEATTACHMENT is sorta-like-TOPICINFO-only-not-quite
change fileattachment meta -> a rev of the topic! WTF!
[17:02]
gac410MichaelDaum: not really, since attachment revs don't necessarily stay in sync with topic revs. [17:02]
CDotBTW PFS does *ot* rewrite META:FILEATTACHMENT cockups. I did think about doing that, but decided it wasn't worth it [17:03]
gac410IMO the history of attachment rev's should be cachedk in a .AttachmentHistory file or the like, instead of being semi-overlaid / embedded into the owning topic history. [17:04]
MichaelDaumanyway, whatever.
I see now why PFS has got problems with trunk
[17:04]
gac410So you can move an attachment to another topic, and that *attachment*'s history is preserved.
And with that ... the peanut gallery here moves on :)
[17:04]
CDotMichaelDaum: my approach to fixing it is to just disable that test for non-VC stores [17:05]
MichaelDaumhm not enuf [17:05]
CDotthe biggest problem with that is that the test is mis-named :-(
gac410: attachment history does move with the attachment
[17:05]
MichaelDaumlots of api code is miss named i.e. in VC::Handler [17:06]
CDotthat's not API code
that's part of the RCS store impl
API is the methods declared in Store.pm
[17:06]
MichaelDaumerm VC::Handler is _calling_ the store impl
a store impl is derived from it
[17:07]
CDotno, it's part of a mixin assembly [17:08]
MichaelDaumassembler [17:08]
CDotbut perl doesn;t do mixins very well :-( [17:08]
MichaelDaumgetHandler(foo) gets you a store handler for foo
and foo is YASI (yet another store impl)
[17:08]
CDotgetHandler(foo) gets you a handler for a file called foo
the methods on the handler then allow you to interact with foo
[17:09]
MichaelDaumdid I say something different? [17:09]
CDotthat was Talintyre's original design
CDot never understood why it was so complex, but there you go
MichaelDaum: do your cache solutions assume the existance of ,v files?
[17:09]
MichaelDaumMichaelDaum constantly gets lost in this Store VC Handler jungle
which cache solution?
[17:11]
CDotSolrPlugin
etc?
[17:11]
MichaelDaumpage caching, dbcache, ... [17:11]
CDotdo they assume a ,v file, though? or work off .txt only? [17:12]
MichaelDaumthey us Func [17:12]
CDotok, that's fine then
so, the upshot is, we have to fix the unit tests for the current store impl
and work out how to stop the VC:: tests running on PFS
or at least that subset that works with "inconsistent" topics
[17:12]
MichaelDaumisnt that working on symptoms [17:13]
CDotI don't *think* so, though can't be certain without ploughing through by hand [17:14]
MichaelDaumthere are two ways how to resolve this mess
either relieve any store impl from META:TOPICINFO and let the layers above deal with it.
or move META:TOPICINFO one layer further down into the RcsWrappers
[17:14]
CDotzactly
I was hoping to to (2) one day
because the layers above don't have the info to deal with META:TOPICINFO completely
every time I look at it, though, I get lost in the VC::Handler maze, and give up :-(
[17:15]
MichaelDaumbasically I f*ing don't care which solution it is. both are fine with me more or less. [17:16]
CDotthere *is* another way to look at this specific problem [17:17]
MichaelDaumbut problem is with PFS that you are hanging in between [17:17]
CDotno, I''m doing it right; the Store is correctly handling META:TOPICINFO
it's the RCS stores that are getting it wrong
(IMHO)
[17:17]
MichaelDaumguys I gotta run
this is my last day before one week of spring holidays with my family
[17:18]
CDothave fun [17:18]
MichaelDaumone last thing
how is your kneee
[17:18]
CDotexcellent, thanks; should be back to fighting next week :-) [17:19]
MichaelDaum... wrecking the other one [17:19]
CDotprobably :-( [17:19]
MichaelDaumhave fun. take care. [17:20]
gac410and work out how to stop the VC:: tests running on PFS ... that should be simple with pharvey's changes [17:21]
.... (idle for 16mn)
CDotgac410: howso? I couldn't get my head round what he'd done [17:37]
gac410You define a routine that returns a list of what not to run under certain conditions.
hm. I think the LoggerTests has some fairly extensive examples
sub skip ... decided what test to run.
[17:38]
............... (idle for 1h12mn)
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/szi90A
foswiki/master 233e02e CrawfordCurrie: Item11209: extra grace period added to the file time checks broke the unit tests. Plus put in exception for running the tests on stores that don't have the RCS style 'pending checkin' complexity...
[18:51]
***GithubBot has left [18:51]
FoswikiBothttp://foswiki.org/Tasks/Item11209 [ Item11209: Store is returning wrong information in history ] [18:51]
.............. (idle for 1h8mn)
***ChanServ sets mode: +o Babar
ChanServ sets mode: +o Babar
[19:59]
gac410 has left [20:12]
.............. (idle for 1h8mn)
foswiki_irc0Hello @all
I have a question: I would like to install NatSkin for my new Foswiki 1.1.8. Where can I get an older version of DBCache?
[21:20]
...... (idle for 27mn)
BabarDBCache is bundled with Foswiki > 1.1
you do not need it
argh. he's gone
[21:47]
............. (idle for 1h4mn)
EnriqueCadalsoHello. I have an app in Foswiki-1.1.2 where %SEARCH( $formfield(SomeField) used to return the value of SomeField of the kind select+values. Now in Foswiki-1.1.7 $formfield is returning the "select" part of "select+value". Have something changed in the implementation of SEARCH $formfield? If so, is there a way to get back the old behaviour? [22:51]
jastyeah, we got bit by that, too
fwiw %QUERY% still returns the value
[22:57]
***ChanServ sets mode: +o gac410 [22:59]
jastI have no idea what makes the two different
%META{"formfield"}% returns the label, too
when it didn't in earlier version
s
[22:59]
gac410gac410 is about to pull all remaining hair out and consider stepping away from perl code.
1.1.9 will be soon.
[23:00]
jastoh, you mean the defined(@foo) thing?
that's not awesome
[23:00]
EnriqueCadalsojast: Thaks for confirming it. I wasn't sure if I was doing something wrong. [23:01]
gac410configure: defined(@array) is deprecated at /srv/www/htdocs/foswiki/lib/Foswiki/Net.pm line 596. [23:01]
EnriqueCadalsojast: I guess I will use QUERY then. [23:01]
gac410yup. I can't believe I missed that. Squarely my code. And nobody else caught it. [23:01]
jastEnriqueCadalso: to be strictly accurate, I didn't try $formfield in %SEARCH because we use Solr search... but the same thing happened in %META{"formfield"}% [23:01]
gac410stupid stupid. ... this is so annoying [23:02]
EnriqueCadalsojast: well, I am positive it is happening in SEARCH. I have being hours figuring out what was going on with my app. Never imagined that. There is no note in the docs about it. [23:02]
gac410I think I need to pull the release. [23:03]
jastgac410: I've been getting much less enchanted with Perl since I started working on Foswiki core
but there's no real alternative
I have high hopes for Rust... it's the only sanely-designed new language I've seen in a long time, though it's not exactly a scripting language
[23:03]
gac410gac410 fears nobody else is testing.
gac410 really liked IBM's REXx I used to use it a lot
[23:04]
jastI can do tests sponsored by my employer once the release is out, or if we're *really* invested in a change introduced by a new release
... I can do the same before the release, I suppose
(that was a continuation. forgot to finish the sentence on the first line...)
I'm a secret fan of object pascal, but the standard library is way behind the times
[23:05]
gac410Anyway, this is embarrassing and humiliating. Really a rookie mistake. Yet I asked repeatedly for someone to vet that change, since it is in such a critical place. [23:07]
jastthat was related to the SSL fix, right? [23:08]
gac410anyway, I need to run out for an hour or so. then I'll decide whether to pull the release. Anyone else, please jump in. But foswiki is totally broken on perl 5.15
er 5.16. Yes SSL fix, but since it's a compile error, now it's broken for everyone.
[23:09]
jastthe thing is, I've never used 5.16 in my life
I wouldn't have caught that issue
[23:10]
gac410perl becoming like java, write once, test everywhere. I've got 6 versions of perl installed on my system, and still missed it. [23:10]
jastand it wouldn't have occurred to me that perl starts complaining about stuff that used to be perfectly acceptable in previous versions [23:10]
gac410yeah, this one is really annoying, as it's a very reasonable question (IMHO) to ask, has that array (or hash) been defined yet. [23:11]
jastthat said, they did mess up locale+taint in 5.12 and until we looked into locales, *nobody* noticed
with 'mess up' = 'completely break'
[23:11]
gac410well, Given it's perl 5.16, which very few distributions ship by default, it's probably not quite as bad. [23:13]
Really annoying, perlcritic doesn't even complain about it. [23:18]
EnriqueCadalsojast: Thanks for your help again, I replaced $formfield with $percntQUERY{\"'$topic'/fields[name='MyFieldName'].value\"}$percnt and it works again. I share it here for somebody else in the same issue. [23:31]
jastyeah, chances are it'll be a bit slower, but what can you do
I believe there's a shorter syntax for that, by the way
it's either '$topic'/MyFieldName or '$topic'.MyFieldName... I'm not sure right now
[23:31]

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