| ../irclogs/#mantishelp.2009-06-12.log | ||
| --- scribe started --- | 00:00 | |
| siebrand | how can I get the current user's name? (the one executing the script) | 00:11 |
|---|---|---|
| nuclear_eclipse | siebrand: user_get_name( auth_get_current_user_id() ) ? | 00:13 |
| siebrand | nuclear_eclipse: that's sounds precisely like what I am looking for :) | 00:14 |
| nuclear_eclipse | note that user_get_name() will return the user's realname if that's enabled | 00:14 |
| siebrand | that sounds fine. | 00:15 |
| siebrand | administrator has created an account for you with username "t5". In order to complete your registration, visit the following URL (make sure it is entered as the single line) and set your own access password: | 00:16 |
| siebrand | nuclear_eclipse: are you sure it does that? Looks like it does not, actually. | 00:18 |
| siebrand | nuclear_eclipse: ow, that's probably a config setting I am not using. | 00:18 |
| CIA-61 | Mantisbt: s.mazeland * r755a5de6ba57 / (4 files in 3 dirs): Fix: #0010578: Admin created user accounts should get different confirmation e-mail | 00:33 |
| CIA-61 | Mantisbt: s.mazeland * r3b0e73e47849 /plugins/MantisCoreFormatting/lang/strings_russian.txt: Follow-up to master 51e4567d : remove untranslated message from strings_russian.txt | 00:33 |
| nuclear_eclipse | siebrand: depends on $g_show_real_name iirc | 00:51 |
| * siebrand nods. | 00:51 | |
| devnet | hey everyone...how do I allow public viewing of my mantis install without authentication? I'd like to have everyone be able to browse and view but not report bugs | 02:45 |
| mantisbot | New bug: Bug 10585 - Kirill - open - new | 05:32 |
| mantisbot | New bug: string not found manage_import_issues_link - http://www.mantisbt.org/bugs/view.php?id=10585 | 05:32 |
| Ronald | What about plugin priority? I just added a dependency on jQuery from git.mantisforge to mu plugin; and unless I put my plugin at higher priority; its EVENT_REPORT_BUG_FORM output is not there? | 07:57 |
| [KK]Kirill | siebrand: lo | 08:07 |
| dhx_m | hey | 08:07 |
| [KK]Kirill | dhx_m: lo | 08:13 |
| dhx_m | [KK]Kirill: hi | 08:14 |
| [KK]Kirill | dhx_m: nice look mantisbt.org with national character support | 08:20 |
| [KK]Kirill | http://www.mantisbt.org/bugs/plugin.php?page=ManTweet/index.php | 08:20 |
| dhx_m | yep that shows well on my screen :) | 08:20 |
| dhx_m | I'm getting a patch ready for bug 4772 at the moment | 08:21 |
| mantisbot | Bug 4772 - hugopedersen - open - acknowledged | 08:21 |
| mantisbot | Changing username doesn't advice user - http://www.mantisbt.org/bugs/view.php?id=4772 | 08:21 |
| dhx_m | just picking random old small fixes to do :) | 08:21 |
| [KK]Kirill | it's good | 08:22 |
| [KK]Kirill | upload patch | 08:22 |
| [KK]Kirill | I include in my version | 08:22 |
| Ronald | hi; did you guys see my Q just before you became active? | 08:31 |
| [KK]Kirill | yes | 08:32 |
| [KK]Kirill | by I don't know | 08:32 |
| [KK]Kirill | but* | 08:32 |
| Ronald | Ah well thats a shame :) | 08:32 |
| [KK]Kirill | Ronald: try ask nuclear_eclipse after 5 hours | 08:33 |
| Ronald | Will do; doesn't currently hold me up | 08:33 |
| siebrand | mogge | 08:56 |
| siebrand | Can anyone tell me where the 'ManTweet' code is? It has some i18n issues. If I fix an issue, it will log in Dutch. That should be the tracker language. | 08:58 |
| [KK]Kirill | git.mantisbt.org | 09:00 |
| [KK]Kirill | http://git.mantisbt.org/?p=mantweet.git;a=summary | 09:00 |
| siebrand | Hmm, I guess the bug is already somewhere in core. | 09:04 |
| [KK]Kirill | siebrand: I upload new file. | 09:04 |
| [KK]Kirill | about core plugin | 09:05 |
| siebrand | [KK]Kirill: yep, saw that. | 09:05 |
| [KK]Kirill | Thanks | 09:06 |
| siebrand | Ronald: what question? | 09:08 |
| Ronald | was just before you entered; will repeat | 09:08 |
| Ronald | What about plugin priority? I just added a dependency on jQuery from git.mantisforge to mu plugin; and unless I put my plugin at higher priority; its EVENT_REPORT_BUG_FORM output is not there? | 09:08 |
| siebrand | Ronald: no idea. | 09:11 |
| siebrand | Ronald: I assume priority determines when it is processed, and if you process it too late, it may not be doing what you expect it to do... | 09:11 |
| Ronald | possibly, but jquery doesn't use that event; and it only went weird when jquery was actually added to my plugins dependencies (with jquery still loaded) | 09:12 |
| dhx_m | ok my patch for bug 4772 is complete and tested, will push it to mantisforge now :) | 09:41 |
| mantisbot | Bug 4772 - hugopedersen - open - acknowledged | 09:41 |
| mantisbot | Changing username doesn't advice user - http://www.mantisbt.org/bugs/view.php?id=4772 | 09:41 |
| giallu | uhm. is it possible to change the username??? | 09:50 |
| siebrand | giallu: manage_user_edit_page.php allows this. | 10:19 |
| siebrand | giallu: non-admins cannot do it. | 10:19 |
| siebrand | dhx_m: nothing pushed? http://git.mantisforge.org/w?o=age | 10:21 |
| dhx_m | will push it now sorry | 11:07 |
| dhx_m | just working out how to convert access levels to strings | 11:08 |
| dhx_m | ah get_enum_element | 11:09 |
| dhx_m | hmmm well this is a problem... | 11:17 |
| dhx_m | $g_enable_email_notifications in config_defaults.inc says that signup emails are turned off | 11:18 |
| dhx_m | in the documentation, it says they aren't turned off | 11:18 |
| dhx_m | http://git.mantisforge.org/w/mantisbt/dhx.git?a=shortlog;h=refs/heads/manage-user-email-notify | 11:38 |
| nuclear_eclipse | Ronald: a) is the jQuery plugin installed correctly in your Mantis install, and b) did you set an appropriate dependent version in your own plugin? | 12:36 |
| Ronald | nuclear_eclipse, manage plugin screens shows jquery as green/correct. | 12:37 |
| nuclear_eclipse | and what about your plugin? does it show that its dependencies are met? | 12:37 |
| Ronald | yes | 12:37 |
| Ronald | both mantis core ans jquery as green | 12:37 |
| nuclear_eclipse | Ronald: how many plugins do you have installed, and what are they? | 12:39 |
| Ronald | jquery, mantis formatting (came default) and core | 12:39 |
| Ronald | and my own obviously | 12:39 |
| [KK]Kirill | nuclear_eclipse: lo | 12:40 |
| nuclear_eclipse | can I see the source for your plugin? or at least the ->register(), ->hooks() and such setup? mantis.pastebin.com | 12:41 |
| nuclear_eclipse | hi [KK]Kirill | 12:41 |
| [KK]Kirill | nuclear_eclipse: http://git.mantisforge.org/w/mantisbt/dhx.git?a=commitdiff_plain;h=d62c08e3b6828c6f4a227f97e664528d1759eb67;hp=44719eb9f8d7043cb90c816ed8e345ca02634739 | 12:41 |
| [KK]Kirill | is it patch-file? | 12:41 |
| Ronald | nuclear_eclipse, http://mantis.pastebin.com/m33ff336a | 12:42 |
| nuclear_eclipse | [KK]Kirill: what about that? | 12:43 |
| [KK]Kirill | it's dhx_m modification | 12:43 |
| nuclear_eclipse | right | 12:44 |
| [KK]Kirill | ok | 12:44 |
| dhx_m | yep | 12:45 |
| nuclear_eclipse | Ronald: that all looks correct -- honestely I'm not sure what the priority would have to do with whether your plugin hook got executed... | 12:45 |
| dhx_m | [KK]Kirill: did you test it? | 12:45 |
| nuclear_eclipse | Ronald: are you running the official a3 release, or something from git? | 12:45 |
| Ronald | mantisbt-1.2.0a3-2009-06-10-master-d9978e5 | 12:46 |
| Ronald | from the nightly dir | 12:47 |
| nuclear_eclipse | hmm | 12:47 |
| Ronald | the jquery is git from tiday | 12:49 |
| Ronald | Just verified; either need to raise my plugin to priority 2; or drop depend on jquery. (keeping jquery loaded in mantis; AND its code shows up in page source) | 12:54 |
| Ronald | for all 3 pages (report, update, view bug) | 12:56 |
| nuclear_eclipse | actually, priority 2 is a lower priority =\ | 12:57 |
| Ronald | alright ;) all plugins are at 3; cept my own. needs to be 2 or 1 to work | 12:59 |
| Ronald | plugin order as listed on manage plugins: Mine, jquery, formatting, core | 13:00 |
| nuclear_eclipse | I'm still boggled as to how that could be happening -- I've got *lots* of plugins that depend on each other, and never had to change their priorities to make them work... | 13:02 |
| Ronald | I think i can give you the complete code; nothing in house yet in there | 13:02 |
| nuclear_eclipse | ok | 13:02 |
| Ronald | where do you want it? | 13:03 |
| nuclear_eclipse | on pastebin should be fine | 13:03 |
| Ronald | multiple files | 13:04 |
| nuclear_eclipse | ah, right | 13:04 |
| nuclear_eclipse | umm, email? | 13:04 |
| Ronald | sure | 13:04 |
| nuclear_eclipse | jreese@leetcode.net | 13:04 |
| Ronald | using lang and some small/light template engine(used to working with it) | 13:04 |
| mantisbot | New bug: Bug 10586 - rickb - open - new | 13:04 |
| mantisbot | New bug: Add burn-down charts to roadmap report - http://www.mantisbt.org/bugs/view.php?id=10586 | 13:04 |
| * nuclear_eclipse uninstalls on plugins on his test install.... | 13:05 | |
| Ronald | send 10K tar.bz2 your way | 13:06 |
| nuclear_eclipse | ok | 13:06 |
| dhx_m | 10kB? :o | 13:06 |
| Ronald | it does include jotti.org/openlibs/jtpl ;) | 13:07 |
| dhx_m | ah ok | 13:07 |
| Ronald | html inline got messy real quick, so pulled in the template thing I normally use | 13:08 |
| mantisbot | New bug: Bug 10587 - rickb - open - new | 13:09 |
| mantisbot | New bug: UI improvements to Roadmap report - http://www.mantisbt.org/bugs/view.php?id=10587 | 13:09 |
| nuclear_eclipse | wow, I can replicate the problem, but I have absolutely no clue why that's happening... | 13:15 |
| Ronald | There is only one thing worse then a problem you have no clue about | 13:16 |
| Ronald | a problem you cannot replicate AND have no clue about ;) | 13:16 |
| nuclear_eclipse | lol | 13:16 |
| Ronald | I have a few of those lingering, very hard to fix | 13:17 |
| mantisbot | New bug: Bug 10588 - rickb - open - new | 13:19 |
| mantisbot | New bug: Rename 'assigned' state as 'approved' or 'actioned' - http://www.mantisbt.org/bugs/view.php?id=10588 | 13:19 |
| paul_ | nuclear_eclipse: regex | 13:22 |
| nuclear_eclipse | I'm stumped; I'm gonna have to pull out the Eclipse PDT debugger and step through this thing, see what's going on; my only thought is that somehow your plugin is never getting past the dependency-check phase of initialization... | 13:22 |
| Ronald | take the time; i'm not blocked cus the priority workaround works | 13:23 |
| nuclear_eclipse | yeah | 13:23 |
| paul_ | Ronald: john's busy fixing regex | 13:25 |
| paul_ | :P | 13:25 |
| Ronald | ask the author of the template thing I use, he dreams in regex | 13:26 |
| * nuclear_eclipse smacks paul_ | 13:26 | |
| nuclear_eclipse | regexen are very wonderful :D | 13:26 |
| Ronald | regex have character! | 13:27 |
| Ronald | you either get along..... or /not/ | 13:28 |
| paul_ | nuclear_eclipse: i'm fixing mantis for 5.3 | 13:28 |
| paul_ | hence the regex query | 13:28 |
| nuclear_eclipse | paul_: so are ereg* going away in 5.3? | 13:30 |
| paul_ | deprecated | 13:30 |
| paul_ | as is split | 13:30 |
| paul_ | etc | 13:30 |
| paul_ | I might clone your utf8 branch and work on | 13:32 |
| nuclear_eclipse | paul_: I added work for mb_substr yesterday | 13:33 |
| paul_ | I saw | 13:33 |
| paul_ | but i'm still not sure about it | 13:34 |
| paul_ | substr is a function i've think i've got a utf8 version (using regex) of | 13:34 |
| paul_ | I partly wonder if we should add mb_* stuff as a performance add on once we're happy with our compat-versions | 13:35 |
| nuclear_eclipse | and I profiled utf8_substr vs other options, and for 40,000 calls on an ever-growing string, it was 0.7s for utf8 versus 0.3 for regular, so the performance cost is negligible to mantis | 13:35 |
| nuclear_eclipse | paul_: I'd rather add compat on top what I already have | 13:35 |
| paul_ | you can probably see my logic though i.e. | 13:36 |
| paul_ | if we drop strlen | 13:36 |
| paul_ | use mb_Strlen if available | 13:36 |
| paul_ | use custom_strlen if not available | 13:36 |
| paul_ | and use strlen if phpv6 | 13:37 |
| paul_ | we've got 2(3) different branches | 13:37 |
| paul_ | with out custom_strlen most likely to be incorrect | 13:37 |
| nuclear_eclipse | right, but the good part is that those branches only need to be evaluated once, at the time of defining our custom utf8_* functions | 13:37 |
| paul_ | yep | 13:38 |
| nuclear_eclipse | and utf8_strlen *will* be correct because it uses utf8_decode | 13:38 |
| paul_ | you'd hope so at least | 13:38 |
| nuclear_eclipse | well, I can't see why it wouldn't be... | 13:39 |
| paul_ | although I did wonder last night if we should call utf8_strlen when adding a BLOB to database (e.g. a file upload) | 13:39 |
| paul_ | btw, did you look at http://git.mantisforge.org/w/mantisbt/paul.git?a=shortlog;h=refs/heads/11June | 13:39 |
| paul_ | or more | 13:40 |
| paul_ | specifically: | 13:40 |
| paul_ | http://git.mantisforge.org/w/mantisbt/paul.git?a=commitdiff;h=34e2ecbd4660fd559e285d758bf7efb46d00e340 | 13:40 |
| paul_ | http://git.mantisforge.org/w/mantisbt/paul.git?a=commitdiff;h=8189a1ceb01bcae72798c4a0ea15030d265eabe1 | 13:40 |
| dhx_m | why is there a need for utf8_strlen? UTF8 is guaranteed not to have any 0x00 characters | 13:40 |
| dhx_m | unless you're trying to count actual characters (not buffer size) | 13:41 |
| nuclear_eclipse | Ronald: ah ha! | 13:43 |
| nuclear_eclipse | the logic in plugin_init_installed() for how many retries to perform is flawed - it doesn't make enough passes at initializing everything | 13:44 |
| Ronald | I guess the good thing about that is it negates the phase of cluelessness ;) | 13:45 |
| nuclear_eclipse | yep | 13:46 |
| CIA-61 | Mantisbt: jreese * rc40a83d192c5 /core/plugin_api.php: Fixed bug with plugin initialization retries. | 13:49 |
| nuclear_eclipse | Ronald: if you pull from latest git, or pull tonight's snapshot, you'll have the fix | 13:49 |
| Ronald | will do! | 13:49 |
| nuclear_eclipse | Ronald: if you don't mind, I have a couple tips | 13:49 |
| Ronald | sure, fire away | 13:49 |
| nuclear_eclipse | if you implement the class function ->init() and put your lib inclusion there, it will simplify your code so you don't have to load it in multiple places | 13:51 |
| nuclear_eclipse | also, if you use `config_get_global( 'plugin_path' ) . 'Fadiro/<lib>'` in your requires calls, it will work properly even if you later decide to put plugins elsewhere for some reason | 13:52 |
| nuclear_eclipse | and lastly, you don't need to explicitly require MantisPlugin.class.php -- the plugin system will have it loaded by the time it ever gets around to executing your code | 13:53 |
| nuclear_eclipse | now, all that said, it's just recemmendations, everything you did is still perfectly fine, so cheers :) | 13:54 |
| Ronald | Its welcome.... The mantisplugin require is from XmlImportExport (I copied that to have some guidance) | 13:55 |
| Ronald | if its not needed you may want to remove it there ;) | 13:57 |
| nuclear_eclipse | I honestly haven't really looked at that plugin, as it was created by giallu | 13:57 |
| Ronald | Ah well, seems he was unfamiliar too ;) | 13:58 |
| giallu | what's that? | 14:00 |
| Ronald | A assumed the db_prapare_* functions are there to sanitize untrusted input; so it becomes safe from exploits to the db? | 14:00 |
| nuclear_eclipse | Ronald: correct | 14:01 |
| giallu | Ronald, I believe that has changed lately with the query_bound stuff | 14:01 |
| nuclear_eclipse | giallu: XmlImportExport plugin | 14:01 |
| giallu | nuclear_eclipse, yeah what about it? | 14:01 |
| nuclear_eclipse | right, db_query_bound( $query, array( $param, ... ) ) is preferred | 14:02 |
| Ronald | I use that; but ALSO db_prepare_* | 14:02 |
| Ronald | you say the latter is not needed with the first? | 14:02 |
| nuclear_eclipse | giallu: it explicitly requires the MantisPlugin class file, which isn't necessary as the plugin system will include it before it ever starts including plugins themselves | 14:02 |
| nuclear_eclipse | Ronald: correct, it can actually result in double-escapes for strings | 14:03 |
| Ronald | very well, will clean up | 14:03 |
| giallu | ah ok | 14:03 |
| giallu | nuclear_eclipse, I think that was written because of "class XmlImportExportPlugin extends MantisPlugin" | 14:05 |
| giallu | I've the habit of including the base class file | 14:05 |
| nuclear_eclipse | right, it generally makes sense, but as plugin_api is guaranteed to load it first, each require_once after that is just a (very slight) performance hit, hence the reason I never put it in mine | 14:06 |
| nuclear_eclipse | but it's really a non-issue IMO | 14:06 |
| nuclear_eclipse | it makes so little difference that I wouldn't even devote a commit to it :P | 14:06 |
| Ronald | The only reason would be it sets an example for clueless people like me ;) | 14:07 |
| nuclear_eclipse | paul_: do you need me to replace any other ereg* calls in the code? | 14:46 |
| CIA-61 | Mantisbt: jreese * rf523d3c1372f /core/string_api.php: Migrate from ereg* to preg* for PHP 5.3 compat. | 15:35 |
| CIA-61 | Mantisbt: jreese * ra583c8a1d534 / (5 files in 2 dirs): Add events for including/excluding users from notification lists. | 15:35 |
| CIA-61 | Mantisbt: jreese * ra556dc0d55c5 / (4 files in 3 dirs): Fix #9744: Allow users to turn off session validation at login time. | 15:35 |
| CIA-61 | Mantisbt: jreese * r0ca1c657c0e5 / (9 files in 4 dirs): Merge branches 'preg', 'notify' and 'proxy-login' | 15:36 |
| paul_ | nuclear_eclipse: probably | 15:48 |
| nuclear_eclipse | paul_: `ack " ereg"` found four files with ereg* that aren't in /library | 15:51 |
| paul_ | 1-2 of them are trivial right? | 16:07 |
| vb123 | Good morning | 16:16 |
| vb123 | nuclear_eclipse: ? | 16:16 |
| vb123 | We should have associated issue #s for checkins like new plugin events and ereg->preg for 5.3 compatibility. | 16:17 |
| vb123 | This is to make such enhancements / fixes discoverable for the users and to make it easier for us to find / resolve duplicates in the future. | 16:18 |
| vb123 | Relating to the notification events, it would be useful to add an extra parameter. For example, in case of adding a note, include the note id. In case of adding a relationship include the relationship id. | 16:21 |
| vb123 | We could have this set to 0 in the initial implementation, but it will avoid us having to change the plugins when we add this in the future. | 16:21 |
| vb123 | I think we should eventually have a mode where MantisBT would craft the email with some basic issue info + the new note or the new relationship, rather than including all the issue details. | 16:22 |
| vb123 | This will also allow plugins to potentially react differently to add new private note vs. add new public note. | 16:23 |
| [KK]Kirill | vb123: vboctor? | 16:39 |
| nuclear_eclipse | hi vb123 | 16:51 |
| vb1234 | hi nuclear_eclipse | 16:51 |
| nuclear_eclipse | why would we want users to know what's in a new release? :P | 16:52 |
| vb1234 | :) | 16:52 |
| vb1234 | if we are to add an extra parameter to an event, does this break existing plugins? | 16:53 |
| nuclear_eclipse | no | 16:53 |
| nuclear_eclipse | the only way we break existing plugins is by changing or dropping existing parameters | 16:54 |
| vb123 | that's good. | 16:59 |
| vb123 | it would be useful to include in the documentation a sample for an implementation of each event. | 17:02 |
| nuclear_eclipse | vb123: how extensive are you thinking for the sample? | 17:04 |
| vb123 | just something to show the arguments, how to return the results. | 17:06 |
| vb123 | return an array vs a single element. What parameters to take in, etc. | 17:06 |
| nuclear_eclipse | isn't that what the documentation of parameters and return value is for? :P | 17:06 |
| vb123 | let me check again... | 17:06 |
| nuclear_eclipse | every event is documented with a list of parameters passed and return value expected | 17:07 |
| vb123 | for example, EVENT_MENU_MAIN_FRONT | 17:09 |
| vb123 | it is not clear whether to return <a href....> or http://.... --- | 17:09 |
| vb123 | it will be clearer if there is an example, or you can include the sample as part of the existing documentation. | 17:10 |
| nuclear_eclipse | ah, I think that portion might be a special case :P | 17:10 |
| vb123 | ok, I guess what we have may be OK, we should just make sure it is not ambiguous. | 17:13 |
| nuclear_eclipse | agreed | 17:13 |
| nuclear_eclipse | maybe I can take care of that before any final release of 1.2 | 17:13 |
| vb123 | sounds good. thanks. | 17:13 |
| vb123 | are we any closer to the rc? | 17:13 |
| nuclear_eclipse | I think so | 17:14 |
| nuclear_eclipse | afaik, all the dates stuff is solidified | 17:14 |
| vb123 | ok, are we able to do it this weekend? | 17:14 |
| nuclear_eclipse | although paul_ was wanting to get his bug object updates committed to master as well... | 17:15 |
| vb123 | isn't that a big change? DO we need it for 1.2? | 17:15 |
| vb123 | if we get it in, we have to wait to stabilize it. | 17:15 |
| * nuclear_eclipse looks for paul_'s link to the diff.. | 17:15 | |
| vb123 | also it wasn't one of the issues we thought was necessary a couple of weeks ago. | 17:15 |
| nuclear_eclipse | well, I could have sworn paul had pushed it in at the same time as his dates change, which is why I hadn't brought it up... = | 17:16 |
| nuclear_eclipse | hmm, can't find the likn | 17:20 |
| nuclear_eclipse | anyways, I don't even remember what it was that it was "fixing", so I'm assuming it wouldn't be too terrible to release without it, but the more stable our API is after making a plugin release, the better... | 17:21 |
| dhx_m | before 1.2, can rm-hardcoded-enum (bug 10330) be addressed? | 17:26 |
| mantisbot | Bug 10330 - dhx - open - assigned | 17:26 |
| mantisbot | Remove all hardcoded enum levels from within Mantis code - http://www.mantisbt.org/bugs/view.php?id=10330 | 17:26 |
| dhx_m | rm-hardcoded-enum is the branch I was working on | 17:26 |
| dhx_m | there are still a few hardcoded values left which I'm not 100% sure how to fix | 17:26 |
| nuclear_eclipse | right, that's one of the things I was gonna take care of today :) | 17:27 |
| dhx_m | this will close off a whole number of long standing bugs (5 years in some cases) | 17:27 |
| dhx_m | bug 3973 I'll fix soon (it is part of what 10330 aims to fix) | 17:27 |
| mantisbot | Bug 3973 - Wanderer - open - assigned | 17:27 |
| mantisbot | "Reporter effectiveness" on summary calculated wrongly in case of using custom-severity attributes - http://www.mantisbt.org/bugs/view.php?id=3973 | 17:28 |
| dhx_m | and the only other TODO that comes to mind with that bug is what to replace instances of the FEEDBACK constant with | 17:29 |
| dhx_m | I think it is only used in a few places... for example a preset filter that shows all bugs at feedback level | 17:30 |
| nuclear_eclipse | yeah, I noticed that | 17:31 |
| dhx_m | otherwise branches manage-user-email-notify and 10268 are 'ready'... with succint-html-buttons and 10274 also 'getting there' | 17:33 |
| dhx_m | if I get some time, I can try squashing some more old feature requests/bugs... but no point holding up 1.2 | 17:34 |
| dhx_m | it's already jam packed with new stuff :) | 17:34 |
| nuclear_eclipse | dhx_m: was rm-hardcoded-enum recently rebased onto master? | 17:55 |
| nuclear_eclipse | wait for it... | 18:23 |
| CIA-61 | Mantisbt: hickseydr * ra0525539884f / (11 files in 2 dirs): Replace CLOSED with $g_bug_closed_status_threshold | 18:23 |
| CIA-61 | Mantisbt: hickseydr * r5d3edf63aec0 /core/email_api.php: Replace RESOLVED with $g_bug_resolved_status_threshold | 18:23 |
| CIA-61 | Mantisbt: hickseydr * rc7ecb89dacb0 /bug_change_status_page.php: Replace ASSIGNED with $g_bug_assigned_status | 18:23 |
| CIA-61 | Mantisbt: hickseydr * r7b940ad5f931 / (5 files in 2 dirs): Replace NEW_ with $g_bug_submit_status | 18:23 |
| CIA-61 | Mantisbt: hickseydr * r313abf14e50c / (5 files in 3 dirs): Rename OPEN to $g_default_bug_resolution | 18:23 |
| CIA-61 | Mantisbt: hickseydr * rd162566dc287 / (8 files in 3 dirs): Remove hardcoded references to FIXED resolution | 18:23 |
| CIA-61 | Mantisbt: hickseydr * rc007dee836e2 / (3 files in 3 dirs): Custom priority & severity significance thresholds | 18:23 |
| CIA-61 | Mantisbt: hickseydr * rfd57267a10e0 /core/constant_inc.php: Add custom constants for projection and ETA fields | 18:23 |
| CIA-61 | Mantisbt: hickseydr * r7b57cd410f97 / (api/soap/mc_api.php api/soap/mc_issue_api.php bug_report.php): Fix instances of enum levels hardcoded to 10 | 18:23 |
| CIA-61 | Mantisbt: hickseydr * rf74dbc75bddf / (2 files in 2 dirs): Config options to set default projection & ETA | 18:23 |
| CIA-61 | Mantisbt: jreese * r16677b026002 / (23 files in 4 dirs): Merge commit 'dhx/rm-hardcoded-enum' into enums | 18:23 |
| CIA-61 | Mantisbt: jreese * r9531f78d316d /.gitignore: Updated .gitignore | 18:23 |
| CIA-61 | Mantisbt: hickseydr * rb51b4435dd7e / (bug_change_status_page.php manage_config_workflow_page.php): Replace REOPENED with $g_bug_reopen_resolution | 18:23 |
| vb123 | dhx_m: thanks for this nice patch. I specially like that the documentation was updated too :) Also a great quality work. | 18:39 |
| nuclear_eclipse | vb123: I think this might also make for a useful addition to 1.2: http://git.mantisforge.org/w/mantisbt/jreese.git?a=shortlog;h=refs/heads/utf8 | 18:41 |
| vb123 | what is this work about? | 18:43 |
| nuclear_eclipse | using utf8-capable string functions whenever possible, throughout the whole codebase | 18:43 |
| nuclear_eclipse | ie, there's a lot of places where we use non-utf8 string functions on strings that may or may not contain utf8 data | 18:44 |
| vb123 | on a high level it makes sense. | 18:45 |
| vb123 | Do we see the change as risky? | 18:45 |
| vb123 | is it just the top two checkins? | 18:45 |
| nuclear_eclipse | I don't -- it's really only adding an api that doesnnothing but call either the same function, or a multibyte version of the same function, depending on what's available | 18:46 |
| nuclear_eclipse | yeah, just the two right now | 18:46 |
| nuclear_eclipse | most of the real work is contained in core/utf8_api.php; the rest is more or less `sed` work to convert all usages to the new api | 18:47 |
| nuclear_eclipse | it's not yet a "complete" solution, because it needs to be further extended to cover things like str_pad(), but it's a first-step | 18:47 |
| nuclear_eclipse | and further work can easily by committed before a final release | 18:48 |
| vb123 | It looks like a good change. I have a couple of comments: | 18:50 |
| vb123 | 1. We should cover str_replace as well. Even if utf8_str_replace ends up being a direct mapping for str_replace. i.e. change all calls and just fix implemenations as appropriate. | 18:51 |
| vb123 | 2. Move the function_exists() inside the function definition rather than outside it. This gaurantees the function interface to not depend on functions being defined. | 18:52 |
| nuclear_eclipse | 2 is a very bad idea | 18:52 |
| vb123 | so I would add utf8_str_pad and utf8_str_replace, call it from everywhere, then fix the implementation later if necessary. | 18:52 |
| vb123 | This scopes the changes to be merged later to smaller changes. | 18:53 |
| nuclear_eclipse | a) performance, between branching and function_exists, b) php_api defines a random implementation of mb_substr that would interfere | 18:53 |
| vb123 | shoudn't we get rid of the str related stuff in php_api. | 18:56 |
| nuclear_eclipse | I believe it's there to work around problems in phpmailer/adodb | 18:56 |
| nuclear_eclipse | because one of them (can't remember which) makes a call to mb_substr without checking for its presence, which would break on any PHP without the mbstring extension (the whole reason we need utf8_api) | 18:57 |
| paul_ | nuclear_eclipse: erm | 18:57 |
| paul_ | how exactly did you merge dhx/rm-hardcoded enum ? | 18:58 |
| nuclear_eclipse | via `git merge dhx/rm-hardcoded-enum`, why? | 18:58 |
| paul_ | http://git.mantisbt.org/?p=mantisbt.git;a=shortlog;h=refs/heads/master | 19:00 |
| paul_ | doesn't show the changes | 19:00 |
| paul_ | http://git.mantisbt.org/?p=mantisbt.git;a=commitdiff;h=16677b02600202b5ebbb3fff9fe0d5c445bffa62 | 19:00 |
| nuclear_eclipse | yes it does | 19:00 |
| paul_ | it only modifies: | 19:01 |
| paul_ | bug_graph_bystatus.phpdiff1 |diff2 |blob | history | 19:01 |
| paul_ | core/email_api.phpdiff1 |diff2 |blob | history | 19:01 |
| paul_ | manage_config_workflow_page.phpdiff1 |diff2 |blob | history? | 19:01 |
| paul_ | ? | 19:01 |
| nuclear_eclipse | that's just the merge commit | 19:01 |
| nuclear_eclipse | the real commits are further down | 19:01 |
| nuclear_eclipse | eg, all the ones by "David Hicks" (dhx) | 19:01 |
| paul_ | that's a mess | 19:02 |
| nuclear_eclipse | what do you mean? | 19:03 |
| nuclear_eclipse | that's the way all DVCS systems work, including your beloved Hg | 19:03 |
| paul_ | so anyway, I'll push the bug objects stuff | 19:06 |
| nuclear_eclipse | ok | 19:06 |
| vb123 | paul_: what is the goal of the bug objects work? Was it reviewed? | 19:16 |
| paul_ | yes | 19:16 |
| paul_ | john iirc | 19:17 |
| vb123 | I would like to understand what we are aiming for and make sure that we at least get a couple of devs to review a big change. | 19:18 |
| paul_ | anyway, it's in branch on mantisforge | 19:19 |
| vb123 | I would just raise the awareness of this and send to mantisbt-dev | 19:22 |
| vb123 | Also we need to consider whether we want to do this for 1.2 or 1.3. | 19:22 |
| paul_ | 1.2 imo | 19:31 |
| paul_ | vb123: did you clarfiy if we prefer if( or if ( ? | 19:37 |
| nuclear_eclipse | vb123: no need to make a utf8_str_replace(); it's utf8 safe as it is | 19:47 |
| * paul_ slaps nuclear_eclipse | 19:48 | |
| paul_ | did you look over branch again? | 19:48 |
| nuclear_eclipse | paul_: no, it seemed like it had a lot of other stuff in it that wasn't related to bug objects... | 19:49 |
| paul_ | probably | 19:50 |
| paul_ | as it's now my local master ;p | 19:50 |
| nuclear_eclipse | paul_: you scare me... | 19:56 |
| paul_ | now what | 19:56 |
| nuclear_eclipse | 15:50 < paul_> as it's now my local master ;p | 19:57 |
| paul_ | ? :) | 19:57 |
| paul_ | erm | 20:00 |
| paul_ | you get asked about the session thing on logon???? | 20:00 |
| paul_ | if a user turns that off, not knowing what it means, that's a security risk ;/ | 20:00 |
| nuclear_eclipse | duh | 20:03 |
| nuclear_eclipse | that's why it's called "Secure Session" | 20:03 |
| paul_ | I thought you meant you'd put it uner user prefs to configures :P | 20:03 |
| paul_ | -s+d | 20:03 |
| nuclear_eclipse | how can you get into your preferences to disable it if your session won't validate after login? | 20:03 |
| nuclear_eclipse | besides, this is exactly how other sites/applications handle it; see sf.net | 20:05 |
| nuclear_eclipse | or at least they used to have that option | 20:05 |
| paul_ | so push? | 20:08 |
| nuclear_eclipse | sounded like vb123 wanted to review it first... | 20:09 |
| * paul_ sighs | 20:10 | |
| vb123 | nuclear_eclipse: relating to utf8_str_replace, I think ideally we should have a simple rule, any str related function we should use utf8_* rather than everyone considering whether the operation is safe or not. | 20:17 |
| paul_ | vb123: you wanted to review bugobject changes from a month ago? | 20:18 |
| nuclear_eclipse | vb123: I would generally agree, but I've actually found an external library that will be complete/stable/tested than rolling our own utf8 stuff; I'm in the middle of reworking what I have | 20:19 |
| nuclear_eclipse | s/be/be more/ | 20:19 |
| * paul_ sighs | 20:20 | |
| nuclear_eclipse | calm down paul_, it's an identical interface to what I would have implemented | 20:21 |
| paul_ | you know i've already said i've worked out utf8 compat functions for most things already? | 20:21 |
| nuclear_eclipse | http://sourceforge.net/projects/phputf8/ | 20:21 |
| paul_ | seen that | 20:21 |
| vb123 | we should make sure dependencies makes sense from linux distro's point of view. | 20:21 |
| paul_ | it's not been updated for 2 years iirc | 20:22 |
| nuclear_eclipse | well, no, but does it really need to be? it's not like utf-8 is a moving target... | 20:22 |
| paul_ | I looked at that a month ago and concluded no | 20:22 |
| vb123 | I think we should put together our utf8_api, then maybe in the future, change it to utilize a library. | 20:23 |
| vb123 | same like db_api | 20:23 |
| paul_ | nuclear_eclipse: iirc, the utf8_substr is the 3rd or 4th slowest of the 5 utf8_substr functions I tested | 20:24 |
| paul_ | in addition, iirc the licensing for that library is no good for us | 20:26 |
| nuclear_eclipse | it's LGPL, how is that no good? | 20:28 |
| paul_ | it's been a month since I looked at it :P | 20:28 |
| paul_ | I just concluded a month ago, not to touch it ;p | 20:29 |
| nuclear_eclipse | and why implement our own if the library is identical to what we would have created? | 20:29 |
| paul_ | less hassle :P | 20:29 |
| nuclear_eclipse | and why is raw performance the determining factor? | 20:29 |
| paul_ | a library that's not been updated for 3 years isn't a good choice of library | 20:30 |
| nuclear_eclipse | how is implementing everything ourself *less* hassle? | 20:30 |
| nuclear_eclipse | it doesnt need to be updated ! | 20:30 |
| nuclear_eclipse | its utf8 | 20:30 |
| paul_ | it needs to be updated to support improvements in php for example | 20:30 |
| nuclear_eclipse | besides? it's not like we couldnt maintain it ourselves just as well as maintaining our own utf8 lib? | 20:31 |
| paul_ | as then distributions whinge | 20:32 |
| paul_ | which means it's more hassle | 20:32 |
| paul_ | for example | 20:32 |
| paul_ | I plan to patch nusoap for php5.3 | 20:32 |
| nuclear_eclipse | why must we always reinvent the wheel every freakin time? | 20:33 |
| paul_ | it's fine to use a library that's kept up to date | 20:33 |
| paul_ | imo | 20:33 |
| paul_ | and is active | 20:33 |
| nuclear_eclipse | and btw, phputf8 is not packaged by debian/fedora, so it wouldn't matter | 20:33 |
| paul_ | yea, but they'll want to package it | 20:33 |
| nuclear_eclipse | if they haven't packaged it in the three/four years it's been used by lots of other apps, why would they all of sudden want to package it now that we use it? | 20:34 |
| paul_ | anyway most of phputf8 is from dokuwiki | 20:35 |
| nuclear_eclipse | and seriously why is rolling our own lib any better than just starting with an unsupported lib? we have to maintain both ourselves, why not use the one that's already implemented and has plenty of testcases against it? | 20:35 |
| nuclear_eclipse | the whole NIH syndrome makes me want to bash my head against the wall.... | 20:35 |
| paul_ | i've spent a chunk of time working out the best utf_* functions from various sources (e.g. mediawiki/dokuwiki and so forth over the last month | 20:35 |
| paul_ | which I plan to dump in | 20:36 |
| nuclear_eclipse | paul_: I still don't see how that's any better than a single documented library, just because the lib is unmaintained... | 20:36 |
| paul_ | because we've already spent a bunch of time comparing the functions in that library to other implementations of the functions | 20:37 |
| nuclear_eclipse | fine, whatever | 20:38 |
| vb123 | If the library is not bloated and does exactly what we need and we understand it, then we should use it. That is my opinion as well. However, I didn't look at it. This is just my 2c. | 20:38 |
| paul_ | you've just picked a topic where | 20:39 |
| paul_ | i've been through code base | 20:39 |
| paul_ | evaluated what str functions we have that dont support utf8 | 20:39 |
| paul_ | evaluted where we use them that requires utf8 | 20:39 |
| paul_ | and evaluated compatibility functions without requiring php extensions for those uses | 20:39 |
| paul_ | to come up with some possible solutions | 20:39 |
| nuclear_eclipse | paul_: I still you're taking the far too | 20:40 |
| nuclear_eclipse | oops | 20:40 |
| paul_ | nod, I agree | 20:40 |
| nuclear_eclipse | I think you're taking the route that costs a lot more time and effort | 20:40 |
| paul_ | for the most part, we probably want to use utf8_strlen or whatever | 20:40 |
| paul_ | however | 20:40 |
| paul_ | there are some functions we dont want/need to use it in (is_Blank an obvious one) | 20:40 |
| nuclear_eclipse | paul_: well, like I said, is_blank shouldn't be using *any* form of string function... | 20:41 |
| paul_ | there are some uses where we need to evaluate if we want to use utf8_strlen (i'm thinking functions where we upload files that could contain utf8 characters and insert them into a blob) | 20:41 |
| nuclear_eclipse | otherwise, I disagree with your plan to evaluate every single use of a string function to look for utf8 needs... | 20:41 |
| paul_ | nuclear_eclipse: i'd agree with you on is_blank, however, strlen seemed to give better results when profiling (strangly) | 20:42 |
| nuclear_eclipse | if anything, that may just be because strlen is part of the C implementation | 20:42 |
| nuclear_eclipse | what did you profile against? | 20:43 |
| paul_ | empty maybe | 20:43 |
| * paul_ can't recall | 20:43 | |
| nuclear_eclipse | and I still think that performance does not trump code consistency/maintainability | 20:43 |
| nuclear_eclipse | if empty() doesn't work right, then why are you testing against it? | 20:44 |
| paul_ | empty && foo != 0 | 20:44 |
| paul_ | is what i tried iirc | 20:44 |
| paul_ | or more | 20:44 |
| paul_ | empty && foo[0] == 0 | 20:44 |
| paul_ | I can't even see hwhere they define strlen | 20:50 |
| nuclear_eclipse | paul_: it depends on whether mbstring is enabled, if so, in mbstring/core.php, otherwise in native/strlen.php | 20:54 |
| paul_ | i mean in php source ;p | 20:54 |
| nuclear_eclipse | oh | 20:55 |
| paul_ | but anyway | 20:58 |
| paul_ | right now i just need to know if i'm pushing bugobject changes from a month ago :P | 20:59 |
| paul_ | incidently john | 20:59 |
| paul_ | can we use: | 20:59 |
| paul_ | .double a { | 20:59 |
| paul_ | border-bottom: 3px double; | 20:59 |
| paul_ | line-height: 1.7em; | 20:59 |
| paul_ | } | 20:59 |
| paul_ | to display the double underline in changelog/roadmap | 20:59 |
| paul_ | aka css? | 20:59 |
| nuclear_eclipse | not really | 21:00 |
| paul_ | why not? :) | 21:01 |
| paul_ | i mean, wouldn't that allow users to theme/style it | 21:01 |
| nuclear_eclipse | a big benefit of the <pre> output from that page is that it can go directly into a text file and look identical ;) | 21:01 |
| nuclear_eclipse | eg, mantisbt/docs/ChangeLog | 21:01 |
| paul_ | true | 21:01 |
| nuclear_eclipse | anywho, paul_ / vb123 : here's a branch with the phputf8 library implemented, for both substr and str_pad: http://git.mantisforge.org/w/mantisbt/jreese.git?a=shortlog;h=refs/heads/phputf8 | 21:02 |
| nuclear_eclipse | we could just push this right now, and then modify for performance later; it is an LGPL library, so we can modify it without issue | 21:03 |
| paul_ | I'd rather the old branch | 21:03 |
| nuclear_eclipse | I really don't understand why; it's basically identical to the old branch, just with a better implementation and a lot of tests | 21:04 |
| nuclear_eclipse | seriously, the only difference between this and the old branch is where the functionss come from | 21:04 |
| paul_ | I concluded a month ago that some of the function implementations aren't great | 21:05 |
| nuclear_eclipse | so we can "fix" them later | 21:05 |
| paul_ | as I looked at that library back in feb/march | 21:05 |
| paul_ | and concluded *not* to use it | 21:05 |
| nuclear_eclipse | we're not *stuck* with the implementations paul | 21:05 |
| nuclear_eclipse | but it gets us 100% for free, and under a license allowing us to change whatever the hell we feel like changing... | 21:06 |
| nuclear_eclipse | I really don't know what it is that you have against using a library that we didn't create... | 21:06 |
| nuclear_eclipse | anywho, time to head home | 21:11 |
| * paul_ smacks vb123 | 21:32 | |
| * paul_ smacks vb123 harder | 21:32 | |
| paul_ | nuclear_eclipse: when are we releasing 1.1 release? | 21:43 |
Generated by irclog2html.py