#foswiki 2016-09-05,Mon

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

WhoWhatWhen
gac410Reminder ... Release Meeting Monday 1300Z #foswiki-release [04:54]
***gac410 has left [04:54]
.............. (idle for 1h6mn)
ChanServ sets mode: +o MichaelDaum [06:00]
ChanServ sets mode: +o CDot [06:09]
.......................................................................... (idle for 6h8mn)
ChanServ sets mode: +o gac410 [12:17]
gac410Hi all ... Release meeting in #foswiki-release starting in about 45 minutes. [12:17]
.............. (idle for 1h5mn)
MichaelDaumCDot, got a question wrt TinyMCE and WysiwygPlugin: in how far are they depending on each other and would it be straight ahead replacing tinymce with ckedit in a tml->html->tml loop? [13:22]
CDotWysiwygPlugin was designed to be entirely independent of TinyMCE
there may have been some hacks to massage the HTML so it works better for TMCE - gac410 did some work there
[13:23]
gac410CDot ... can you join #foswiki-release? [13:24]
CDotbut it should be pretty much stand-alone [13:24]
MichaelDaumCDot, awesome. [13:24]
gac410ping jast ... do you have some time [13:27]
***ChanServ sets mode: +o Lynnwood [13:27]
ChanServ sets mode: +o Lynnwood__ [13:36]
.......... (idle for 45mn)
foswiki_irc2Hello. When I authenticate using Kerberos and visit the configure-page, I see in "Security and Authentication" - "Access Control" a red exclamation mark.
"Current user not in this list, and is locked out, If you save the configuration, you'll lose access to configure! "
But my WikiUser is indeed written there.
When I enter my unix user there, which is mapped to my WikiUser, the error disappears. But then I cannot open the configure page anymore.
I assume this is a bug in the configure page?
The configuration parameter I am talking about is {FeatureAccess}{Configure}
[14:21]
gac410ugh. probably yes. Not in the configure page per se, but in the configure auth checker. [14:25]
foswiki_irc2Okay, so I can just ignore the error? [14:25]
gac410Unfortunately I don't have any kerberos or ldap servers available, so I have no way to test this.
You should also check access to the System.PerlDependencyReport and System.FoswikiServerInformation They are secured using the same code.
[14:26]
foswiki_irc2If I can, I will gladly try a fix or something if that is not too complicated. [14:27]
gac410The code is down in Foswiki::Configure::Auth::checkAccess ie lib/Foswiki/Configure/Auth.pm [14:28]
FoswikiBothttps://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Configure::Auth [14:28]
foswiki_irc2I can access both pages, so at least it works [14:29]
gac410Also making sure that people NOT on the {FeatureAccess}{Configure} list cannot access it is equally or more importatn [14:30]
foswiki_irc2Is it correct, that the default value for this parameter is 'AdminGroup' ?
It's not written anywhere, but that seems to be the case.
[14:30]
gac410The other way to access configure is to use the admin superuser login. If the admin password is set ... that also grants access. re AdminGroup. That is only used if the list is empty. [14:31]
foswiki_irc2yes, i.e. default value then
okay, so for now I just ignore the error
[14:31]
gac410Some sites might want to differentiate between "wiki" administrators and "server" administrators. So the {FeatureAccess}{Configure} list is used to break away from AdminGroup users being able to change the deep internals.
Please open a task against configure https://foswiki.org/Tasks/Configure and document the issues as best you can.
[14:32]
foswiki_irc2Is this correct and sufficient? https://foswiki.org/Tasks/Item14169 [14:42]
.... (idle for 16mn)
gac410Hi foswiki_irc2 that looks okay. thanks [14:58]
MichaelDaumapropos UserForm issues: a user just recently complained that even though he changed his email address does he still get mail notifications to his old address. turns out he was editing his user profile, the email field in there, and was expecting it to be of any relevance ... [15:01]
gac410foswiki_irc2: Could you add a debug print to Foswiki::Configure::Auth ... to display what user is being detected? [15:01]
FoswikiBothttps://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Configure::Auth [15:01]
gac410print STDERR " configure checkAccess:  Wikiname  $wikiname, user $session->{user}\n";

Right after the line:     my $wikiname = Foswiki::Func::getWikiName( $session->{user} );
[15:02]
FoswikiBothttps://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Func [15:02]
MichaelDaumso UserForm does have some serious issue: it is by no means linked to the user mapping of the system underneath ... which stores its own version of an email addr
at a totally different location
[15:03]
gac410MichaelDaum: have you seen any issues with the configure access checking on your various ldap installations [15:03]
MichaelDaumyes
told em to use AdminUser
[15:03]
gac410MichaelDaum: yeah... UserForm email address is really obsolete ... [15:04]
MichaelDaumerm no. it should be right there.
thats what all other products do: edit your user profile to change settings
[15:04]
gac410But at the same time it's useful in that it allows a user to have a Public email address separate from the private address used during registration. [15:05]
MichaelDaumhow is that useful? [15:05]
gac410I for one don't want email addresses I use on various sites going public. I don't register if I can't keep some aspects of life private. [15:06]
MichaelDaumyes it should be private, of course. [15:06]
gac410But I might want to expose a public alias ... like my geonwiki address [15:06]
MichaelDaumyet still editing your user profile should be the right way to edit your settings [15:06]
gac410Er..... no Not if I have a public and a private address. The address in the mapper is only edited by using the mapper and it stays private. [15:07]
MichaelDaumthe way we hide this feature atm is broken in terms of user experience [15:07]
gac410Maybe it needs documentation.... [15:07]
MichaelDaumbetter would be to have all user related settings - hidden or not - in one place.
as part of the user profile page
[15:08]
gac410But I would very strenuously object to exposing the confidential email address in the user form.
If the editor somehow linked into the mapper to permit shadow maintenance of the internal email, that's fine. But never never in the user form itself.
Don't forget also the mapper supports M:N relationship. Multiple emails per user, and multiple users per email.
[15:08]
MichaelDaumI wonder who ever used this feature [15:10]
gac410I use the multip users per email all the time. I have 100's of registered users sharing the same email on my test system.
Just so I don't have to make up a new email for every registration test.
[15:10]
MichaelDaumthats all fine for your tests. but this is rather rare in real world. [15:11]
gac410But the other side, multiple emails per user. I've not used it. but I could see it being useful. I often see real life mailing lists with multiple emails. I want to receive notificatinos on both my work and my private email b [15:12]
foswiki_irc2@gac410: After adding the line you mentioned, I cannot access configure anymore [15:12]
gac410ugh... maybe I had a typo. let me try.
foswiki_irc2: are you getting anyting in the web server error log?
It's not crashing here.
[15:13]
foswiki_irc2yes, I get something... wait a sec
This is all printed in one single line... :(
[15:15]
gac410btw ... what OS / Server are you running on? [15:15]
foswiki_irc2RHEL7, with apache 2.4 [15:16]
gac410okay. just making sure it wasn't something really ususual like windows
What the print statement should have showed was the current user, and the wiki name it mapped to.
Everything in that example line I gave you is important. Even the trailing semicolon.
[15:17]
foswiki_irc2Got it... somehow I accidentally removed the # in the first line [15:21]
gac410Ah That would do it ;) [15:21]
foswiki_irc2Now, when and where is the message written? I assume in working/logs/error.log ? [15:24]
gac410No STDERR is sent to the apache error log.
probably /var/log/apache/error_log ... but that may vary with server configurations. Not sure what RHEL uses.
[15:24]
foswiki_irc2I know... ok
configure checkAccess: Wikiname MyWikiUser, user uniuser
unixuser
so, that seems to be correct
[15:25]
gac410Okay... so when you add "MyWikiUser" to the {FeatureAccess}{Configure} you get the warning from the checker. But Access control should probably be working fine. [15:26]
foswiki_irc2Yes, right now "MyWikiUser" is configured there, but the big red error is given [15:27]
gac410So I'm guessing that it's a checker issue, not the Auth code.
let me look at the checker code now.
[15:27]
foswiki_irc2Ok, thanks! I will gladly try out some more. [15:28]
gac410Could you make a small change to lib/Foswiki/Configure/Checkers/FeatureAccess/Configure.pm
In the error message: "Current user not in this list, and is locked out, If you save the configuration, you'll lose access to configure!"
Just add $curuser to the message. ie:
"Current user $curuser  not in this list, and is locked out, If you save the configuration, you'll lose access to configure!"
[15:29]
foswiki_irc2ok, the unixuser is written then
i.e. $curuser == unixuser
[15:31]
gac410Ah... okay.... So the bug is in the checker. The Auth code looks for the WikiUser but the checker is checking using the login user. :( [15:32]
foswiki_irc2Yes, I imagined that.
Is that difficult to fix?
[15:32]
gac410Try adding this line to the checker.
After the line:     my $curuser = Foswiki::Func::getCanonicalUserID();
[15:33]
FoswikiBothttps://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Func [15:34]
gac410Add:
   $curuser = Foswiki::Func::getWikiName($curuser);

hm no that's not helping.
[15:34]
foswiki_irc2I get "MyWikiUser" then in $curuser, just tried it. [15:36]
gac410Do you still get the error?
I think I'll have to dig into this a bit more. I'm getting unexpected errors as well. I get AdminUser is not on the list, even when I add it. :(
[15:36]
foswiki_irc2yes unfortunately. I see the result of the variable in the error message
Hmm... okay
But this is only a false error message, i.e. nothing is really wrong then?
[15:38]
gac410I believe that's true. But if you end up locked out... then I'm wrong. :D [15:39]
foswiki_irc2well... okay, no.
So far it works :)
[15:39]
gac410You've created the task... I'll have to try to set up some test cases and figure out what's going on.
It looks like the auth code is okay, and it's the checker that's being a problem
[15:40]
foswiki_irc2okay, I will look again in the next days, if there is something I can test just write it there.
Ah by the way: Can I do anything to make Newlines in comments working?
We always have the problem, that newlines are converted to <br/>
[15:41]
gac410Are you just hitting enter (start a new paragraph) or shift enter. That will insert at <br/> [15:44]
foswiki_irc2No just enter. But maybe this changed in the latest version, we are still on 1.1.2 [15:44]
gac4101.1.2 ??? that's really ancient
which doesn't sound right given you are using the new configure.
[15:44]
foswiki_irc21.1.2 is the productive version
I am just setting up a new version in a test environment with 2.1.2
the configure error appears in the 2.1.2 of course
[15:46]
gac410Ah... yeah things may be very different way back then. CommentPlugin is very different on 2.x [15:47]
foswiki_irc2ok, I will just try that out then again. Now we only have to get 2.1.2 working as smooth as possible [15:47]
gac410The migration will be a big effort. A lot has changed. Have you started the data migration using either CharsetConverter or the bulk_copy tools? [15:48]
***GuilainC has quit IRC (Ping timeout: 260 seconds) [15:48]
foswiki_irc2Yes I have tried bulk_copy on friday
so far that seems okay, although we have to decide which sites should keep the history and which not
there has been a lot experimenting and hacking in the past, resulting some pages to get over 1000 revisions :(
Another problem is, the machine does not have internet access, i.e. the extensions and upgrade options in configure all throw errors. I have to find a way to install several extensions manually.
And preferably reproducible using scripts
[15:49]
gac410y. Those can be a challenge. Sticking with RCS store instead of converting to PlainFile might be simpler. [15:50]
foswiki_irc2Maybe, but performance is a big issue here. Many are complaining because the wiki is slow... [15:51]
gac410For installing extensions, you can download the attachments for an extension into the install root (the _installer and the .tgz file) and then run the installer from the cli and tell it to use local files.
Foswiki 2.x will probably be slower :( Especially if you are using an older perl, which is common on RHEL. Perl unicode handling is really bad on older releases.
[15:51]
foswiki_irc2yes, I did that already. (installer and tgz) [15:52]
gac410Perl 5.22 can be a help if you can get there. [15:52]
foswiki_irc2RHEL7 has perl 5.16
Oh don't say it will be slower! :-(
[15:53]
gac410Yeah that's really old. regular expressions on unicode data are very expensive. [15:53]
***ChanServ sets mode: +o SvenDowideit_ [15:53]
foswiki_irc2I think the biggest problem here are many searches
We basically use the wiki as a big database with much information stored in fields of wiki pages
and then searches collect several other pages and its values in the fields are written there
[15:53]
gac410Any code that uses regular expressions to scan the data is going to be slower on perl 5.16. Perl 5.16 dates from 2012. That's very old Perl 5.24 is the current release. [15:54]
foswiki_irc2Hmm [15:55]
gac410Some of the "enterprise" distributions really lag in keeping up with modern perl. [15:55]
foswiki_irc2I will think about that. So Perl 5.22+ would be a vital aspect?
Maybe we can get that if it would help, I have to package that seperately then
[15:55]
gac410I'd say so. Each perl release has gotten better with regard to Unicode performance. And we've found and rewritten a number of places where we've found slowdowns we could address. [15:57]
foswiki_irc2ok, great. thanks for the help and the information. I will probably come sometimes again in the next weeks [15:58]
gac410What we did on foswiki.org is used "plenv" but personally I've used perlbrew. Or use a distribution that keeps up with perl. Ubuntu 16.04 LTS is on perl 5.22.
sure good luck with the migration. And thanks for the task.
[15:58]
foswiki_irc2I was even thinking about storing all of our data (meaning fields and their values of certain objects/wikipages) in a database. And then instead of writing so many SEARCHes in the pages some SQL-statements instead...
Would that be possible (without writing everything that is needed for that from scratch of course)
[15:59]
gac410Solr is one way to address search performance, as are the DBCacheContribs. But I'm not all that familiar with either of them. [16:00]
foswiki_irc2Solr ? [16:00]
gac410It's an indexing extension. [16:00]
foswiki_irc2Hm... okay, I will look into that. [16:01]
gac410https://foswiki.org/Extensions/SolrPlugin [16:01]
foswiki_irc2But at first we have to make the migration work. After this, I hope I can put some time into improvements like newer perl and Extensions. [16:02]
gac410People seem to be having good luck using the CharsetConverterContrib ... It's a lot faster in that it doesn't have to dig through all the revisions. [16:03]
foswiki_irc2Well... time is not an issue here... I will start the bulk tool on friday and hope to get the result then on monday :) [16:03]
gac410One big thing, if you have windows users ... is to consider the source character set as CP-1252, not ISO-8859...
Users who cut/paste from windows documents, will almost certainly have polluted your topics with CP-1252 windows special characters, that the converters will choke on.
Smart quotes emdash, etc.
[16:04]
foswiki_irc2Yes, I read the hint in the docs. I hope that is not happening too often. If there are only minor cases where some characters get broken, I think that will not bother anyone. It will be corrected afterwards if someone sees it.
And of course we well keep a backup ;)
[16:05]
gac410The other thing the charset converter can do is inspect and report on problem characters. [16:06]
foswiki_irc2Maybe I will try it later. There are just so many areas needed to be looked at. As I said, so many things have been hacked here and there.
I don't even know what that all is, that has to come up during the time.
For example for the GenPDF-Addon someone wrote a 'sendpdf' in addition to 'genpdf' which sends the pdf by mail
[16:08]
gac410Ah... yeah local changes are a real challenge, especially if not documented along the way.
Some of the extensions that work with the external world are a big challenge with 2.x because of the change to Unicode.
[16:10]
foswiki_irc2Unghh.... I will have to get some perl specialist then
There is no way to disable the "get-updates-from-foswiki" function in configure, is there? To get rid of the errors, when there is no internet access available.
[16:12]
gac410Extensions that play nicely with the Foswiki API, are probably safe. If they use topic data as part of filenames. etc. then Unicode needs to be encoded as utf-8
Hm You mean the banner at the top of the page?
Just disable / uninstall the UpdatesPlugin
But if you visit the Extension tabs and click the button to search for extensions, then you'll get errors. No way to turn that off that I know of.
[16:14]
foswiki_irc2Hmm... okay nevermind then
Do the extensions_installer script something else beside extracting the data and setting the first configuration parameters? Because if not, I would skip them and just extract the tgz files and finally copy our reference LocalSite.cfg
(...in which all the parameters are already set)
[16:17]
gac410I guess it depends upon your installatino. If you've renamed webs or topics, then the _installer can map topics to the new names. ie rename Main to Usersweb or rename Sandbox to Playground
It merges in the extensino Config.spec into LocalSite.cfg ... creates the Enable and Module keys
I'd say that we are gradually moving toward an environment where the installer is required. But not there yet.
If you just unzip. At minimum you should run bin/configure and click the button to merge in config specs
[16:20]
foswiki_irc2Hmm... okay, I will try to include the _installer script in our basic wiki-installer script then. [16:23]
gac410there is also a command you can run from the CLI tools/configure
Foswki 2.x can be fully conigured from the CLI.
[16:23]
foswiki_irc2Yes I read that and tried setting some parameters with that
The downside here was, that with every parameter set, another file was created :)
so, when setting 50 parameters with the CLI, I get 49 backup files :)
[16:24]
gac410You can stack the commands on one execution. [16:25]
foswiki_irc2oh?
okay...
[16:25]
gac410tools/configure -save -set {Cache}{DBI}{PostgreSQL}{Database}='foswiki_db' -set {Cache}{DBI}{PostgreSQL}{Password}='xxxxxxx' -set {Cache}{DBI}{Postg
reSQL}{Username}='foswiki' -set {Cache}{Implementation}='Foswiki::PageCache::DBI::PostgreSQL'
[16:25]
FoswikiBothttps://trunk.foswiki.org/System/PerlDoc?module=Foswiki::PageCache::DBI::PostgreSQL [16:25]
foswiki_irc2But I think I will just provide the final file, that should be more convenient [16:25]
gac410You can also run the checkers and wizards from the cli
tools/configure -check  tools/configure -check {DataDir} -method validate_permissions
er... That was supposed to be two lines
tools/configure -check checks the entire configuration
and tools/configure -check {DataDir} -method validate_permissions validates the permissions of a single directory ... that's a wizard.
[16:26]
foswiki_irc2When using the rcs-filestore, is there a rcs execution even when viewing a page, or only when editing/... it? [16:27]
gac410CDot ??? Can you answer that? I think the answer is that it depends. If the text file is newer than the rcs file, then history is examined. [16:29]
CDotdepends. If you view a historical version of the page, then there is an RCS op. [16:30]
foswiki_irc2no, I mean the latest default page [16:30]
gac410A risk with the PlainFile store is that the file system timestamps are *critical* So if you accidentally modify the file timestamps on disk you corrupt history. [16:30]
foswiki_irc2:-O
That's really bad
[16:30]
CDothey, that's what file datestamps are *for*
they tell you when a file was created/modified
[16:30]
gac410PlainFile was written to be *very fast* and trusting the file system data is a way to reduce overhead. So it's by design. [16:31]
CDot+1 [16:31]
foswiki_irc2Yes, but it can be, that the latest revision gets maybe modified by a script or something
That wouldn't break history, would it?
You mean to be careful to keep timestamps of older revisions?
[16:31]
gac410hm So RCS store can detect that I'm not sure about direct topic updates with PlainFile CDot??? (He's the author ;) )
but yes. If you modify the timestamps of older revisions you lose data.
[16:32]
foswiki_irc2maybe the timestamp could additionally be written as metadata into the history files? [16:33]
CDotthat's right. Your side scripts need to maintain the integrity of the modificatin time if they write to the history. However rewriting history if VERY VERY BAD!
and the mod time is indeed written as meta-data, so all is not lost.
[16:35]
gac410The topic history has the META so for topics, you could preserved. But for attachments... I'm not so sure. [16:35]
CDotattahcment meta has the mod time. [16:36]
gac410ah good [16:36]
foswiki_irc2okay, as I said: I don't think history files will be edited manually, but there will certainly be scripts which update the latest revision of wiki pages. [16:36]
CDotCDot was careful to ensure integrity didn't rely solely on file mod times. [16:36]
foswiki_irc2That should be safe then? [16:36]
CDotI even wrote a script to recover a store that had been corrupted. Somewhere. [16:36]
foswiki_irc2Yes: if accidentally a history file timestamp is changed, one could restore it using the timestamp in the metadata. [16:37]
CDotlatest revisions is fine. The system will recover and extend the history when it sees the new file. [16:37]
foswiki_irc2okay. then I think we will be good [16:37]
gac410gac410 writes all sorts of handy tools. forgets about them does a git clean, and looses them and months later, writes it again saying. hm this all feels familiar. :D [16:38]
foswiki_irc2Good exercise is always helpful as well ;) [16:38]
CDotgac410: I have a "bucket folder". Which is mostly full of dingo's kidneys. [16:38]
***JulianLevens has left [16:39]
gac410foswiki_irc2: I think I've figured out what is going on with the checker. I'll post a diff to your task to have you check it out. [16:40]
zak256@gac410: Wow, that was fast. Great!
Have you seen my latest comment there as well?
Maybe that's interesting
i.e. the resolution of WikiGroups is affected as well.
[16:41]
gac410No, we actually do not do any group checking. It is purely a list of users.
The challenge with groups, is that if you truly want to separate "Wiki" admins from "Server" admins, then anyone in the AdminGroup on the wiki side can change *any* group which would let them elevate themselves to server admin.
[16:43]
zak256But why is there *no* warning given, when no user at all is given in the parameter, but if you set it to 'AdminGroup' he complains that the current user is not listed?
(...even when the user is a member of AdminGroup)
That is confusing
But I see your point as well.
[16:44]
gac410I'll add a check for *Group ... and if an added name has the group suffix, will warn that groups are not active.
But I can't say for sure that BlahGroup isn't actually a person's name ;)
[16:45]
zak256No, I think you don't need to do that. At least not for me [16:46]
gac410Nah... it's a good point. [16:46]
zak256Maybe the warning could be removed completely, because it doesn't really cover all cases
Or at least be reduced to a warning, right now it is regarded as error.
[16:47]
gac410I guess I'd rather warn that there is a *chance* that the user has locked themselves out. make them think [16:48]
zak256I am thinking about adding a "ServerGroup" and add all people there, who should be able to access configure.
okay, that would be good I think
[16:48]
gac410Hm really it should be a warning if the admin {password} is set. the superuser always has access.
Again, regarding ServerGroup ... we don't to any group expansion in the Configure::Auth checker.
[16:48]
zak256Yes I understood. That's why I proposed to remove or at least adapt the warning.
I just updated the file with your patch
It seems to work, thanks.
[16:51]
gac410y. The checker needs some work. The more I look at it the more confused I'm getting ... And I wrote the code :( I need to step back and rethink it a bit.
My patch is fine .. .but I don't think it covers all the cases of users without wikinames, etc.
As long as there is some valid path to configure, you should not be getting errors or warnings.
[16:52]
zak256Yes maybe.
besides the warnings because of no internet access, yes
I leave {FeatureAccess}{Configure} empty for now
[16:54]
gac410Where are you getting those warnings. Which {config}}{Keys} [16:55]
zak256{ExtensionsRepositories}
foswiki.org is not a valid authority specifier (hostname). Lookup returned: Name or service not known foswiki.org is not a valid authority specifier (hostname). Lookup returned: Name or service not known
and: {Plugins}{UpdatesPlugin}{ReportUrl}
[16:56]
gac410Ah... ugh.. .okay [16:56]
zak256although I disabled the UpdatesPlugin [16:57]
gac410That's a generic checker that validates any URL to make sure that it would be functional. hard to say which ones that should be disabled. It's generic by type of field. If it's declared as a URL it is checked. :(
ReportURL should be disabled if the plugin is disabled. That's easy enough to fix.
[16:58]
zak256Yes... don't bother, it's not a wrong warning, so it's fine.
Well thank you again for your time and your help! I will probably be back sometime. Have a nice evening. (It's 7pm here in germany)
[16:59]
gac410you're welcome. g'night [17:02]
.... (idle for 18mn)
vrurggac410: What's the problem with oops? [17:20]
......... (idle for 44mn)
gac410Hi vrurg - It was giving me warnings about $app undefined, or something like that .. .I don't recall now. I think the calling has to change from some positional to all hash based.
gotta step away again.
[18:04]
vrurggac410: You're right. [18:04]
................ (idle for 1h18mn)
gac410I'm pretty sure I've seen error code of the old type in the core. But we won't find them until we hit a condition that exercises the code. Would be nice if the core could fall back to the old calling convention for those APIish calls. throwing exceptions, etc. Meta, etc.
But no idea if Moo code will be forgiving enough to allow the old calls
Another idea... could we have used a new name for the new APIs Foswiki3::blah and allow a plugin to install backwards compatible shims.
Anyway just thinking out loud. Without some way of parallel releases of old & new API based extensions, we're in a bit of a pickle.
[19:22]
..... (idle for 20mn)
vrurgI have so called @_newParameterers protocol support which actually maps old-style positional into key/value. But it has potential problems. For oops exception it was even more "fun
"
I just discovered that it has two BUILDARGS methods... That's something really crazy of me...
[19:45]
.... (idle for 18mn)
***ChanServ sets mode: +o Lynnwood [20:04]

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