Camelia, the Perl 6 bug

IRC log for #padre, 2011-02-10

| Channels | #padre index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:02 jfroebe left #padre
00:44 jazzanova joined #padre
00:47 pece2 joined #padre
00:49 pece left #padre
01:31 kyanardag joined #padre
02:02 Sewi joined #padre
02:18 Alias I discovered something interesting last night
02:18 Alias We're not actually using the thread master at the moment
02:18 Alias Which explains the DBI handle duplication exceptions
02:19 Alias We're allowing thread spawning during a database connection
02:32 Alias Also, damn Windows 7 flickers a lot more now
02:32 Alias It doesn't flicker for as long, but it flickers more
02:32 Alias We need to get double buffering for Windows working
02:37 GabrielVieira left #padre
02:44 Sewi left #padre
03:21 jnap joined #padre
03:22 jnap left #padre
04:22 itcharlie joined #padre
04:36 Hyppolit svn: r13662 | adamk++ | http://padre.perlide.org/trac/changeset/13662
04:36 Hyppolit trunk/Padre/lib/Padre/Wx/
04:42 Hyppolit svn: r13663 | adamk++ | http://padre.perlide.org/trac/changeset/13663
04:42 Hyppolit Fixing some badcode complaints
04:42 Hyppolit trunk/Padre/lib/Padre/
04:44 Hyppolit svn: r13664 | adamk++ | http://padre.perlide.org/trac/changeset/13664
04:44 Hyppolit Noting that ->config isn't the project-aware config
04:44 Hyppolit trunk/Padre/lib/Padre/Wx/Role/
04:53 Hyppolit svn: r13665 | adamk++ | http://padre.perlide.org/trac/changeset/13665
04:53 Hyppolit It appears that we aren't actually using the slave mastering any more (I must have disabled it some time during Task 2.0 to avoid bugs).
04:53 Hyppolit
04:53 Hyppolit This commit adds a flag in to let me start reimplementing it, and in the mean time it also restores the old mechanism which used to prevent DBI connection errors by preventing open database connections at the moment of threadspawn.
04:53 Hyppolit trunk/Padre/lib/Padre/
05:15 itcharlie how do I add plugins to padre
05:15 Hyppolit svn: r13666 | adamk++ | http://padre.perlide.org/trac/changeset/13666
05:15 Hyppolit Change the method order so the ones most likely to be called from the outside are higher up in the docs.
05:15 Hyppolit Changed ->step to ->run and dispatch in a loop now rather than recursive. It's marginally faster and has less risk of recursion induced issues.
05:15 Hyppolit trunk/Padre/lib/Padre/
05:16 itcharlie I am using a windows version of padre and don't know where the config file is located
05:19 Alias Help -> About Padre -> System Info
05:19 Alias Generally you shouldn't ever need to edit a config file by hand
05:20 Alias Tools -> Preferences has the basic, and Tools -> Preferences -> Advanced... gives you all the nitty gritty details, like Firefox's about:config
05:20 Alias Also, different parts of the configuration are stashed in different places
05:20 Alias Bits relating to your preferences are in the padre.yml file, bits that are only valid on the current system are stashed in to the SQLite database
05:21 Alias (It's done that way in anticipation of future half-implemented Padre Sync feature)
05:26 itcharlie I see thanks
05:27 itcharlie so if I want to change the editor style to vi
05:27 Alias There is a Vi plugin
05:27 itcharlie I would assign the value vi to the editor_style preference?
05:27 Alias I'm not sure if it's been changed in a long time though
05:28 Alias Might be stale at this point
05:28 Alias Wait, you want vi colours or something, or a workalike of vi
05:28 Alias With :wq! and so on
05:28 itcharlie Yes
05:28 itcharlie work like vi
05:29 Alias That would need the plugin, since it changes the behaviour of the editor significantly
05:29 itcharlie just trying to see if this feature exists
05:29 itcharlie Hmm
05:29 Alias You have to hit "i" to insert, etc
05:29 itcharlie Yes
05:29 Alias The plugin hijacks the entire editor panel
05:29 Alias Let me see if it still runs
05:29 itcharlie ok
05:30 Alias Hrm, it should at least load...
05:31 Alias It's compatibility versions fit within the current version
05:31 Alias (Although it's probably lying)
05:31 itcharlie :D
05:32 Alias I'm a little bemused that something that hacks the editor panels so heavily doesn't declare it's compatibility with Padre::Editor
05:33 itcharlie how does one add the plugin
05:34 Alias What version of Padre do you have
05:34 Alias Well, it works
05:34 Alias But it's RATHER primitive looking :)
05:35 Alias At least, it works on trunk
05:35 Alias hrm
05:35 Alias ok, try this
05:35 Alias Install Padre::Plugin::Vi with your normal cpan client
05:35 Alias Then restart Padre
05:35 Alias And go into Tools -> Plugin Manager to enable it
05:35 Alias (I really need to write that patch that prevents the need to restart Padre)
05:41 itcharlie padre version 0.63
05:44 itcharlie I don't think Padre::Plugin::Vi exists
05:47 itcharlie left #padre
05:54 Hyppolit svn: r13667 | adamk++ | http://padre.perlide.org/trac/changeset/13667
05:54 Hyppolit trunk/Padre/lib/Padre/Wx/
05:55 Alias itcharlie: You might need to install it from svn
06:02 asarch left #padre
06:09 thecrux left #padre
06:30 Alias ffs this is annoying
06:33 Sewi joined #padre
06:44 kaare joined #padre
06:49 eco left #padre
06:53 Hyppolit svn: r13668 | adamk++ | http://padre.perlide.org/trac/changeset/13668
06:53 Hyppolit trunk/Padre/lib/Padre/ trunk/Padre/lib/Padre/Wx/Role/
06:59 Alias left #padre
08:15 danlucraft joined #padre
08:28 waxhead_ is now known as waxhead
08:57 marcela joined #padre
09:09 waxhead szabgab, zenog.. did you guys see this? http://cubestuff.wordpress.com/2011/02/09/f​osdem-2k11-a-film-about-fosdem-the-free-and​-open-source-developers-european-meeting/
09:15 ispy_ left #padre
09:23 waxhead project road map: http://blogs.gnome.org/bolsh/20​11/02/07/drawing-up-a-roadmap/
09:26 El_Che perl camel at 0:55 :)
09:28 waxhead El_Che, and further along at the end..
09:28 waxhead someone wags it's tail
09:31 El_Che mist that
09:31 El_Che just got it
09:31 El_Che it's wendy
09:32 El_Che 0:59
09:33 daxim joined #padre
09:46 ispy_ joined #padre
09:50 Hyppolit svn: r13669 | szabgab++ | http://padre.perlide.org/trac/changeset/13669
09:50 Hyppolit error reporting in localization report
09:50 Hyppolit trunk/tools/
09:52 szabgab yeah, that video should be distributed on our channels as well :)
10:33 jazzanova left #padre
10:50 Alias_ Please let us not move to git
10:50 Alias_ Feature branches would be a good thing
10:51 Alias_ Having things like the experimental command line or this new file extension dialog in a branch would be good
10:51 Alias_ I did 90% of Task 2.0 in a feature branch
10:51 Alias_ If we bring in approvals for regular commits, all that will happen is nobody will commit
10:52 _Dave joined #padre
10:53 Alias_ A lot of the bugs just seem to be people not testing their changes before releases
10:53 _Dave -ENOGABOR?
10:53 Alias_ He's in email
10:53 Alias_ szabgab, wake up
10:53 _Dave bah
10:53 _Dave summon szabgab
10:53 szabgab here
10:53 waxhead ahh.. I just caught up with email...
10:54 _Dave padre's syntax highlighter doesn't like some 5.12 isms like "//"
10:54 _Dave i blame Trelane
10:54 waxhead pity it was my change that brought about this discussion.. :-/
10:54 szabgab _Dave: we know that
10:54 _Dave i didn't know you knew :)
10:54 szabgab it is a scintilla issue
10:54 _Dave i know you know now
10:54 Alias_ And a well known one
10:54 _Dave scintilla?
10:54 Alias_ We hate it
10:54 szabgab we love it
10:54 daxim / is a 5.9-ism
10:54 szabgab we just should use a more modern version of it :)
10:55 Alias_ scintilla is a "contrib" addition to Wx, not in the core
10:55 szabgab not one from 4 years ago
10:55 Alias_ And nobody is maintaining it
10:55 _Dave fork it!
10:55 waxhead I guess the issue that's been raised about managing commits etc is really just a sign that Padre is maturing and people have higher expectations of it
10:55 Alias_ Fork wx?
10:55 szabgab but azawawi will now create a bind
10:55 Alias_ waxhead: We had these same arguments at version 0.20
10:56 waxhead but I think Adam is right, the risk we have is that unlike netbeans and eclipse ide's we can't backed by corporations with people paid to code and manage...
10:56 Alias_ Some of this is just insufficient testing around big changes
10:56 waxhead I seem to recall...
10:56 szabgab Alias_: I think many of the issues are changing that are not discussed enough before they are made
10:56 waxhead the dialog change I added wasn't big...
10:56 Alias_ Of course it was
10:56 szabgab writing lots of tests would go a long way
10:56 Alias_ You put a new feature into the primary editing workflow of every user
10:56 waxhead just stupidly done and not tested enough... :(
10:57 Alias_ A feature impacting 100% of users, even if it did work
10:57 waxhead but that would be for anything in padre though... apart from the ones controlled by a config item
10:57 Alias_ Stuff that's off by default or hidden behind a feature_xxxx advanced config option (like most of azawawi's experimental stuff) I'm totally fine with
10:57 Alias_ I break the trunk all the time, but it's dramatic and short term, and I generally test things properly before the release goes out
10:58 waxhead sure
10:58 Alias_ directory tree, off by default
10:58 Alias_ outline right panel, off by default
10:58 Alias_ Default startup of Padre is a very minimalist view
10:59 Alias_ It was a reasonable feature
10:59 waxhead should something like the check be turned off then and only turned on when desired?
10:59 Alias_ But with such a high impact, it probably needed to be optional or something at first so people could play with it
10:59 szabgab to be clear, I was not picking on the pop-up that asks for an extension
10:59 waxhead or as you said, "Don't remind me again" as an option after first seeing it?
10:59 Alias_ Me either, although I'm taking it as a good example
11:00 waxhead no, I know that.. but it's a shop stopper for 0.80...
11:00 Sewi I'ld like "don't ask me again for this mime type"
11:00 Alias_ Something like that
11:00 szabgab I "shop stopper" ? :)
11:00 Alias_ Don't as for "Perl File" again
11:00 Alias_ etc
11:00 szabgab I thought it was "show stopper"
11:00 waxhead s/shop/show/
11:00 szabgab ok
11:00 Alias_ it is :)
11:00 waxhead it is.. I can't type..
11:00 szabgab but shop sound good too :)
11:01 Alias_ Finding a pasta packet full of weevils
11:01 Alias_ That's a shop stopper
11:01 waxhead good grief.. for each mimetype?  how many config items do you want in Padre?
11:01 Alias_ They don't need to be config items
11:01 Alias_ You're never going to turn that back on
11:01 waxhead speaking of which, is there a "user" config section to store information like this?
11:02 Alias_ I was thinking more like a "warnings" table in the database
11:02 Alias_ Stuff you supress once, and will never turn on again by choice
11:02 waxhead how so?  don't you need to hold state of the dialog someplace?
11:02 szabgab are we now back talking about the specific feature of the file extension pop-up?
11:03 waxhead szabgab, yeah, I guess so...
11:03 szabgab I think Alias means something like a single config option with several values,
11:03 waxhead might as well capture the feeling about where it should go...
11:04 szabgab with a hash table as a value
11:04 Alias_ no
11:04 Alias_ Database table
11:04 szabgab you see :)
11:04 waxhead the config database?
11:04 Alias_ I'm fine if those warnings are machine-local
11:04 Alias_ Different table perhaps
11:04 waxhead right...
11:04 Alias_ Or we do the Mozilla approach and just config them all
11:04 Alias_ We've already jammed key bindings into it
11:04 waxhead how do they do it?
11:04 Alias_ Got firefox handy?
11:05 Alias_ url bar, type "about:config"
11:05 szabgab IMHO there needs to be a way to turn this on even if I turned it off once
11:05 Alias_ You may recognise a certain similarity between about:config and Padre Advanced config
11:05 Alias_ :)
11:05 waxhead yeah, I've seen that, you get that with azawawi's advanced settings view
11:06 waxhead but it's stored somewhere, either xml or a binary file( database/sqlite )?
11:06 Alias_ Yup
11:06 Alias_ Same as us
11:06 szabgab so let's say we fix this issue, how are we going to improve the stability of padre?
11:06 Alias_ szabgab, I say we use the Toyota approach
11:06 szabgab both in terms of not breaking things
11:06 szabgab but also to make sure there are no features flip-flopping
11:07 Alias_ 1. Identify the immediate problem and fix it
11:07 szabgab Alias_: what would be that? Crash-test?
11:07 waxhead stabilitywise, we could do something like the postgres poeople, loooonnnnngggg  develoment cycles
11:07 Alias_ 2. Identify the immediate cause of the the problem happening and change that
11:07 waxhead and a feature freeze that goes on for ages...
11:07 Alias_ 3. Identify the cause of that cause and fix that
11:07 Alias_ 4. Repeat if possible
11:07 Alias_ 5. Repeat one final time if possible
11:07 Alias_ 6. Don't apply protection or fixes for problems that MIGHT happen but haven't yet
11:07 waxhead well, the mistake with the dialog really only slipped out because it was in just prior to the release....
11:08 szabgab so we have changes coming in that are contradicting previous changes or intentions
11:08 waxhead with very few of the normal hackers around...
11:08 szabgab that's the problem
11:08 szabgab what causes that?
11:08 waxhead it was Sewi that alerted me to the bug, and only days after it was released...
11:08 Alias_ The bug in the dialog was not caused by changes coming in that are contradicting previous changes or intentions
11:08 waxhead if it had gone in early in the dev cycle, enough people use ./dev to have noticed the error and it would have been fixed for the release
11:09 waxhead no it wasn't...
11:09 szabgab waxhead: it was a bug and it might have hurt people but I am not talking about it, maybe because I have not noticed the bug :)
11:10 Alias_ So 1. We've fixed the dialog?
11:10 waxhead sure.. but a longer period of time in the dev cycle may have highlighted the issue before a stable release...
11:10 szabgab right now, once we fixed the dialog we could take that specific change and release a new version with just that
11:10 Alias_ 2. Immediate cause of the bug?
11:11 Alias_ Why did the bug occur?
11:11 szabgab and then keep working on the trunkg
11:11 Alias_ Did you actually try the feature when you wrote it?
11:11 szabgab but I am not sure if we are ready for such small releases
11:11 Alias_ szabgab, we rarely have the trunk knowingly broken for long periods of time, so the branch isn't needed
11:12 Alias_ If we start intentionally breaking trunk, or impose formal freezes (which also breaks the trunk effectively) then branches are useful
11:12 szabgab right but we cannot release now
11:12 Alias_ release branches rather
11:12 waxhead as to the current crashiness of  Padre, I have no idea... I guess a lot of work has been done with the Task Manager, some refactoring on methods etc may introduce problems.. but then when Adam starts these somewhat "intrusive" the dev cycle runs as long as it needs to to resovle them to a stable state... look at Task 2.0
11:12 Alias_ Why can't you release now?
11:12 waxhead me? try it?
11:12 szabgab as there might be some other issues on trunk right?
11:13 Alias_ waxhead: Yes, when you made a gui change, did you test it at all?
11:13 szabgab and also the changes that were made to trunk are not tested
11:13 waxhead yes.. to death.. like I said in the ticket, over and over....
11:13 Alias_ So you tried saving it with a different extension and it worked?
11:13 waxhead but what happened though was that I cleaned up a lot of "debug" code prior to commiting
11:13 Alias_ So you commited without testing? :)
11:14 waxhead I some how removed the if( $msg == Wx::No ) or something..
11:14 Alias_ See, this is why I commit and break everything, then test it, then fix it :)
11:14 waxhead yes, that's the plain truth of it.
11:14 Alias_ I've seen a number of similar problems
11:15 Alias_ Whoever refactored the action system to include the menu node type (normal vs check vs radio) broke every single radio menu entry in Padre
11:15 waxhead I agonised over how I managed to do it as soon as I saw Sewi post something about it.. I checked the code.. it was clear I screwed up when cleaning up...
11:15 Alias_ One single cursory test before release would have caught that
11:15 Alias_ These are the bugs that get people the most upset I think
11:16 Alias_ Stuff that should have been blatantly obvious
11:16 Alias_ I've made a few myself
11:16 szabgab I did a large part of the action system refactoring based on the work of, I think azawawi
11:16 waxhead The dialog bug.. for sure... I guess though that my mind was at rest with the testing and I wasn't paying enough attention when cleaning up.
11:16 szabgab so that was some issue in the Middle East
11:16 Alias_ Maybe we need to introduce a gab between rolling the tarball and uploading it
11:17 waxhead Alias_, yes.. we do...
11:17 szabgab maybe we need a release branch?
11:17 szabgab otherwise we will never be able to release
11:17 waxhead in fact there was a big gap with 0.80 tar ball and uploading to cpan.. longer than normal
11:17 Alias_ We don't need a release branch unless we're going to ban feature development
11:17 waxhead like I said, no one was around... it was like yelling in a cave at the time..
11:18 Alias_ The release branch is the technical workaround for a workflow decision we should make first
11:18 waxhead I did the 0.80 release to let you get on  with your changes you wanted to do, which is when you hurt your wrist...
11:18 szabgab if you create a tarball and then wait 2 days with the upload, we don't want to freeze trunk during that time, right?
11:18 Alias_ waxhead: What if we'd done the full blown release announcement first
11:18 Alias_ Rather than after
11:18 szabgab so what happens if we find a show stopper in the release?
11:18 Alias_ It doesn't go to CPAN and only the smaller group of people pulling the tarball see it
11:19 Alias_ And we roll a new 0.80.tar.gz and upload THAT to CPAN
11:19 waxhead I had other things to do, so it wasn't until the next day that I looked at getting sorted out that I found Padre crashed badly on vista, which I then upgrade to the latest Strawberry to see if it was a problem there
11:19 waxhead which for me fixed the crashing I was seeing..
11:19 szabgab we fix it on trunk and release again? then it will include all the new changes in trunk
11:20 waxhead anyway... 0.80 was a bit of a dud release.. i put it down to everyone being busy and not enough eyes on the 'ball'... tar ball if you will. :)
11:20 Alias_ No, you make a branch late, once you know you really need it from the revision the original release was done off
11:20 Alias_ Release off the trunk, do emergency last minute changes on the branch
11:20 Alias_ waxhead: If it had been announced, more people would have installed the tarball, and there's a much better change it would get caught
11:21 Alias_ We give the keen and watchful 24 hours before the cpan upload
11:21 szabgab Alias_: sure that can work though a release branch would also allow the translators to catch up
11:21 waxhead announce what?  the "pre release tar ball"?
11:21 Alias_ No, you announce the release
11:21 waxhead in irc ?
11:21 Alias_ The release isn't the upload to cpan
11:21 Alias_ The release is the tarball
11:21 waxhead sitting on a server some place rather than cpan?
11:21 Alias_ CPAN is one distribution channel
11:21 Alias_ Seen how I do it?
11:22 szabgab I don't think we need to announce the release before we are sure it is good for distribution
11:22 waxhead I agree..
11:22 Alias_ We have two options
11:22 Alias_ 1. Ensure people adding features do basic gui testing before release
11:22 Alias_ 2. Ensure more people test for other people's mistakes before release
11:23 Alias_ Whether or not we do branches, those are your only workflow options
11:23 waxhead OK.. the way I've been doing it since taking on the job is to build and test, fix tests failures or ask about them, build and test, then when all tests pass, build test and create tarball.
11:23 szabgab we should expect both
11:23 szabgab they are not exclusive
11:23 waxhead I then ask poeple to check it out by giving a URL.. usually one or two people do that...
11:23 Alias_ We expect both now, but clearly they aren't happening
11:23 Alias_ And the more narcy you get, the more people won't bother
11:23 szabgab right, they are not happening enough
11:24 waxhead if we get agreement that it seems OK, I then run release with the --tag  which is what tags the release in svn.  It's THIS tar ball that gets uploaded to cpan, and then the announcement is written
11:24 szabgab narcy?
11:24 Alias_ Police'ish
11:24 waxhead cranky... annoyed.. "pissed off"..
11:24 Alias_ no
11:24 Alias_ forceful, rules'y, anal
11:25 waxhead oh.. sorry wrong context..
11:25 waxhead just reading back now
11:25 waxhead can't read and type
11:25 waxhead how many people actually run ./dev ?
11:25 waxhead from a current svn update?
11:26 waxhead I know I do....
11:26 szabgab I always use dev
11:26 szabgab except when I break it :)
11:26 Alias_ Depends if I'm working on Padre or not
11:26 Sewi Me too, but the question is: How many people report problems
11:26 Sewi (Me too working on trunk)
11:26 Alias_ It's not about reporting
11:26 Alias_ It's about looking
11:26 waxhead ironically though, the changes I made are in a built padre prior to the changes, so they actually don't make it into the running Padre (./dev) at the time..
11:27 waxhead sure.. it's dog fooding
11:28 waxhead OK.. for 0.82, shall we pull the dialog out and flesh out the requirements better?
11:28 szabgab so are we in agreement that after creating a release candidate we would like to provide some time for people to use that and report any problems?
11:28 Alias_ yes, pull it out
11:28 Alias_ szabgab, I agree
11:28 Alias_ Don't need a release branch automatically, but you want one if we find issues
11:28 waxhead Ideas on the length of time for this period to test?
11:29 waxhead the tar ball prior to release?
11:29 szabgab and in the meantime we want to allow people to work on trunk doing whatever regular stuff they want to?
11:29 Alias_ Yes
11:29 Alias_ Fixes to the release candidate are applied to both the branch and trunk, since it will be rare
11:29 waxhead why not?
11:29 szabgab and then, if a show stopper is found in the release, we create a branch from the tag and fix it there
11:29 Alias_ correct
11:29 waxhead the only issue will be KNOWING what revision you are at come the time to either tag or rebuild the final release
11:30 Alias_ That's what tags are for
11:30 Alias_ BTW, what do you mean "tag"
11:30 Alias_ svn is rather vague on the definition
11:30 waxhead tag the revision as a version in /tags
11:30 szabgab as we "tag" our releases
11:30 _Dave ok, so for the manglement here, did we reach a conclusion on the 5.12 hightlight breakage?
11:30 Alias_ szabgab, you're saying a 'tag' is a "tag" ?
11:31 Alias_ tag as in "svn copy" ?
11:31 Alias_ Or tag as in something less svn'like
11:31 szabgab _Dave: we know it is there and you can use the PPI highligher for small files
11:31 _Dave no fix ETA
11:31 szabgab _Dave: otherwise we need an upgraded scintilla that azawawi is working on
11:31 _Dave ok
11:31 Alias_ _Dave: The Perl 5.12 problem is unfortunately completely out of our control, no eta
11:32 szabgab _Dave: no ETA
11:32 waxhead anyone else not seeing Outline working on latest trunk?
11:32 Alias_ It's three projects upstream from us
11:32 _Dave ok
11:32 waxhead oh.. some one op me please?
11:32 _Dave i'll stop Trelane using 5.12 isms then :)
11:32 szabgab _Dave: or someone can write a fast highligher that we can actually fix
11:32 waxhead Alias_, svn copy
11:32 Alias_ We depend on Wx.pm, which depends on wxWidgets, which depends on a contrib subdir with scintilla
11:32 Alias_ waxhead: So we've already got a branch then
11:32 Alias_ Since there's no such thing as a tag in svn
11:32 waxhead sure.. it's convention
11:32 Alias_ A tag is a tag until you commit a change, then it's a branch
11:33 waxhead thanks
11:33 Alias_ szabgab, so the point is moot, we already do release branching
11:33 szabgab Alias_:  it is a conventions we do not commit changes to things in /tags/
11:33 Alias_ Since in svn a tag is a branch is a copy
11:34 _Dave ok, thanks
11:34 _Dave left #padre
11:34 szabgab that's the only speciality of that copy of the tree
11:34 Alias_ It's just "policy", the rule only exists in the heads of the project owners
11:34 szabgab yes, that's true
11:34 Alias_ We can change it
11:34 Alias_ So lets
11:34 szabgab but we should not
11:34 Alias_ Why not?
11:34 waxhead Alias_, Use of uninitialized value in numeric eq (==) at /home/pete/Programming/Perl/Padre/t​runk/Padre/lib/Padre/TaskManager.pm line 349.
11:35 szabgab do you have a better way to mark the exact tree that has been released in a package?
11:35 Alias_ It is the exact tree
11:35 Alias_ Since we'll be building a new tarball that matches the tag
11:36 waxhead with removing the dialog, shall I remove the code completely, or comment it out for now?
11:36 Alias_ waxhead: Comment out is fine
11:36 Alias_ I've still got .par archive support for plugins in there, commented out
11:36 Alias_ Just add some extra comments above to say WHY it's there commented out, and to not delete it
11:36 szabgab actually it would be enough just to save the revision number of the tree to know what was the exact set of files in the release
11:37 Alias_ Some people comment out individual lines instead of deleting, and it's handy to be able to distinguish
11:37 Alias_ szabgab, for our main $work project, we write a file into the root of the RPM packages called "SVN_INFO"
11:37 szabgab that would be fine
11:37 waxhead hmmm.. outline is updating an aweful lot.. seems that it was just "slow" to show things...
11:38 Alias_ Which is just svn info > SVN_INFO for the exact branch/revision we're packaging
11:38 szabgab and then we can stop "svn copy"-ing to tags
11:38 Alias_ Well, the SVN_INFO file only exists in the tarball
11:38 szabgab and do it only if we really need to make changes to a release package
11:38 Alias_ So you'd still need a repo mechanism as well
11:38 Alias_ $work we still do release branches
11:39 Alias_ It's just that the SVN_INFO file will refer to .../releases/49-indium
11:39 szabgab SVN_INFO could be checked back to SVN
11:39 Alias_ Bad idea
11:39 Alias_ That just means it could go wrong
11:39 Alias_ In fact, it would always be wrong
11:39 Alias_ Since the commit of the change to SVN_INFO would mean it was out of date :)
11:40 Alias_ Just move tags to branches/releases or something
11:40 Alias_ So it's clear they aren't tags
11:40 Alias_ They are really branches
11:40 Alias_ Or hell, /releases/
11:40 Alias_ svn doesn't care one bit
11:40 szabgab right
11:40 szabgab but then we can also call them tags
11:41 Alias_ Right
11:41 szabgab and but an explanation file in tags/README
11:41 Alias_ And they won't confuse any tools
11:41 Alias_ oh
11:41 Alias_ leave in tags?
11:41 Alias_ Sure
11:41 Alias_ You know what I do?
11:41 Alias_ In svn.ali.as, I have a releases directory
11:41 Alias_ Containing the tarballs
11:41 Alias_ The releases script commits them directly itself
11:42 szabgab http://svn.perlide.org/padre/README
11:42 Alias_ And then, you just look at the commit revision for the tarball, and you know EXACTLY which revision of the trunk it matches
11:42 Alias_ You subtract 1
11:42 szabgab that's what our release script does too, right?
11:42 Alias_ Does it commit the tarball to the repo?
11:42 szabgab not the tarball
11:42 Alias_ I've never checked it out since we added tags
11:43 Alias_ So then how do you know?
11:43 szabgab just the source opened, then I misunderstodd you
11:43 Alias_ svn info /releases/Config-Tiny-1.00.tar.gz
11:43 Alias_ Tells you exactly the revision it's from :)
11:43 szabgab unless someone commits in the middle of course
11:44 Alias_ true
11:44 Alias_ race conditions are rare though
11:44 szabgab but there could be a file in SVN with the release information that is committed by the release script
11:44 szabgab but we are sidestepping the main issue here
11:45 szabgab we wanted to see how we can ensure we have time to fix the code before uploading to CPAN
11:45 szabgab I'd say we could use the same mechanism to allow the translators to catch up
11:45 Alias_ agree
11:46 Alias_ Assuming they do
11:46 Alias_ I don't often see a lot of translators comitting
11:46 szabgab and that would require a release branch
11:46 Alias_ The state of French is horrible :)
11:46 Alias_ And there's a lot of french speakers
11:46 szabgab they asked for longer warning before releases
11:46 Alias_ Then again, I have the luxury of having no idea how much work is needed
11:47 Alias_ It's clearly non-trivial, since no American has bothered to learn yet
11:47 szabgab and that colours your vision?
11:47 Alias_ szabgab, I've travelled enough to be certain that it does
11:47 Alias_ There's a big naivety gap between single-language speakers and +1s
11:47 waxhead Alias_, weren't you doing something with the editor and document classes?
11:47 waxhead Alias_, Can't locate object method "editor" via package "Padre::Wx::Editor" at /home/pete/Programming/Perl/Padre/​trunk/Padre/lib/Padre/Wx/Editor.pm line 453.
11:47 Alias_ I'll check that
11:48 waxhead that's when I tried testing the removal of the dialog code
11:48 waxhead so saving isn't working
11:48 szabgab so then how dould we allow the translators to catch up?
11:48 Alias_ szabgab, I'm fine with your approach
11:48 szabgab on a branch or on trunk and then integrate?
11:48 Alias_ Well, merging is more problematic
11:49 Alias_ Although am I right in thinking that we could just freeze the .pot file?
11:49 szabgab we could I don't think it is an issue if we are only merging the specific translation files
11:49 szabgab so the .pot file is frozen on the branch
11:49 Alias_ frozen on trunk
11:49 Alias_ until the release/translation branch is merged
11:50 szabgab before release the .pot file is generated and then it can be frozen
11:50 Alias_ right
11:50 szabgab on both actually
11:50 Alias_ correct
11:50 Alias_ For last minute bugs we just live with double commit
11:50 szabgab for bugs it will be harder, double commit or merge
11:50 Alias_ I'm fine with double commit
11:51 Alias_ They should be rare, and it will act as punishment for the person that made the bug :)
11:51 szabgab but the translators usually work on their own individual files
11:51 szabgab or a punihment to the people fixing them :)
11:51 Alias_ Translation we can just merge down the entire translation directory and it should just merge clean
11:51 Alias_ So long as nobody changed .pot or language stuff on the trunk?
11:51 Alias_ Or even as long as there's no change to .pot?
11:52 szabgab so long as nobody changes languages stuff on trunk, pot can be changed
11:52 Alias_ Can you merge .po files if .pot is static?
11:52 szabgab those are just text files
11:52 szabgab you can merge them as you like
11:52 Alias_ But don't they have references to the original code?
11:52 Alias_ So if you change .pot, it changes lots of lines in the .po at once?
11:52 Alias_ lines numbers and the like?
11:53 szabgab but what I thought is that there is no need to change .pot on the branch as no code changes there
11:53 Alias_ right
11:53 Alias_ But someone might change a .po file on trunk to add something...
11:53 szabgab and no need to change the .po files on trunk
11:53 Alias_ I guess it's their responsibility, so the translators for each language can manage themselves as they wish
11:53 szabgab should not do it
11:53 szabgab exactly
11:53 Alias_ It's effectively a namespace
11:54 szabgab for each language the number of translators is small
11:54 szabgab usually smaller than 1
11:54 szabgab :(
11:54 szabgab and they usually have a common language
11:54 szabgab so I hope they can communicate and manage
11:54 Alias_ Solution to that is get more popular
11:55 szabgab so they won't be able to communicate any more :)_
11:55 szabgab ok, now I really need to go to have lunch
11:55 szabgab back later &
11:56 szabgab I'll write this down and send to the list so people can comment on it
11:56 waxhead thanks.. :)
11:56 Alias_ Wow, how did that editor bug get through
11:56 Alias_ I suck
11:56 waxhead szabgab++
11:57 Hyppolit svn: r13670 | adamk++ | http://padre.perlide.org/trac/changeset/13670
11:57 Hyppolit That should fix the editor thing
11:57 Hyppolit trunk/Padre/lib/Padre/Wx/
11:57 waxhead Alias_, I'm trying to step back to find where it got triggered, but haven't got past "Where is that method"
11:57 Alias_ I know what did it
11:58 Alias_ You have to save a file to a filename which causes a mimetype change
11:58 Alias_ I thought that method was called a lot more often, but apparently only if it needs to flush the colourisation and restart
11:58 Alias_ Tested and confirmed fixed for me
12:00 waxhead works here too.
12:00 waxhead dialog has also been removed...
12:00 Hyppolit svn: r13671 | waxhead++ | http://padre.perlide.org/trac/changeset/13671
12:00 Hyppolit Removing the file extension dialog until a better implimentation is thrashed out.
12:00 Hyppolit trunk/Padre/lib/Padre/Wx/
12:00 Hyppolit svn: r13672 | adamk++ | http://padre.perlide.org/trac/changeset/13672
12:00 Hyppolit Should fix the worker warnings, notwithstanding there's a horrible mistake in the design of the worker list I'll fix in a bit as well
12:00 Hyppolit trunk/Padre/lib/Padre/
12:01 Alias_ I forgot the golden rule of practical algorithm choice
12:01 Alias_ Don't contort your code for the sake of a better O() when N is 5 or less
12:02 Alias_ Since the choice is moot
12:02 Alias_ O(n^3) is only 25 times slower than O(logN)
12:02 Alias_ :)_
12:05 Hyppolit #1027: save file with .pl extension by default? (reopened enhancement) [ http://padre.perlide.org/t​rac/ticket/1027#comment:5 ]
12:06 waxhead I've forgotten what the big o notations mean... :(
12:06 * waxhead wikipedias
12:11 waxhead grep defined... I wouldn't have done that... didn't know you could do that...
12:11 waxhead things you learn...
12:11 waxhead ok I'm going to bed.. way too tired...
12:12 zenog waxhead: sleep well!
12:13 zenog We could have a 3-7 day "freeze" period before releases, why not.
12:13 zenog For testing, translations, and testing plug-ins so that, if necessary, they can be released together with the new Padre.
12:14 zenog Commit approvals would also  be okay, if we have enough people to approve things so that there is not a huge lag.
12:14 szabgab back
12:14 waxhead hmm.. you know after all this time, the crtl-tab to cycle through the tabs still doesn't work...
12:14 zenog I'd also be fine with git, even though I would not really push it right now ...
12:15 zenog waxhead: At least Ctrl-PageUp/Down works now.
12:15 waxhead it does?
12:15 zenog (at least in my setup, don't know whether that's the default)
12:15 waxhead what do you use that for?
12:16 zenog To cycle through the tabs.
12:16 waxhead funny... how come that works but crtl-tab doesn't?
12:17 szabgab so we might be able the release a bit in general but we need to improve our own communication in the development
12:17 waxhead it's almost like the crtl isn't being "seen" as being pressed, or down when crtl-tabbing
12:17 zenog waxhead: you can always use the key bindings editor to set it up.
12:17 szabgab and somehow to spot these regressions
12:17 waxhead which throws the focus out and the tabbing stops working
12:18 zenog szabgab: One thing we could do is having several check-lists.
12:18 zenog szabgab: Somehow manual tests for the user interfaces.
12:18 zenog szabgab: Could maybe even be automated using macros (depending on the system ...)
12:18 szabgab We could do that but we don't like manual testing
12:18 zenog szabgab: But manual would do and allow humans to spot other things.
12:18 szabgab for that we would need a lot more people
12:19 zenog szabgab: For the UI, before a release, it is fine.
12:19 zenog szabgab: Also not everything, but a list of actions you can do in 30 minutes.
12:19 szabgab zenog: would you be able to start such a document?
12:19 waxhead this is the tricky thing with these sorts of projects.... for all these rules and expectations, you need people to stick to them..
12:19 zenog szabgab: sure, I would also do the tests on Ubuntu for the next 10 releases ;-)
12:19 waxhead people are like water, they follow the path of least resistance.. unless you pay them and even that is no guarentee of anything...
12:19 szabgab I think we could send out a call for volunteers
12:20 szabgab for people who are perl developers and want to contribute to Padre but don't yet feel comfortable to write code
12:20 waxhead If you take a look at the 'who's who' of Padre a few names stand out, but primarily you have one "core guy" that gets into the guts of Padre.. there is another that does some neato "hard stuff", and then there's the rest of us...
12:21 szabgab zenog: let's start by you writing up use cases on the wiki that need to be tested
12:21 waxhead testing is hard... that's why the automated tests work so well.. they generally catch quite a few things.. I know, I see it fail often before a release..
12:22 szabgab they could go along specific features
12:22 szabgab they could be used as check lists for a testser
12:22 waxhead but testing all the GUI elements.. that needs a mouse clicker...
12:22 szabgab but could be also showcases of the features
12:22 waxhead and testing is grindingly hard work.. it's not interesting..
12:22 waxhead even games testers get paid to do their job.. :)
12:23 waxhead Look at the attempts we've made at doing documentation...
12:23 szabgab I don't think people will want to do 30 min manual testing sessions but if we can have 2-3 min sessions that might work
12:23 zenog waxhead: I did not mean to test all GUI elements, every mouse click etc.
12:24 zenog waxhead: but rather some main workflows and see whether there are big problems there
12:24 szabgab I think zenog can start with a few main things and then as we encouter issues we can write down tests "scripts" for them for manual testing
12:25 waxhead zenog, no, I know that.. but it's still a case of someone either building trunk, or installing a 'pre-release' tar ball to open a file, crtl-tab around, modify, save as, save with not ext.. etc...
12:25 waxhead and who would do this testing though?
12:25 waxhead most of us are quite time poor as it is...
12:25 zenog szabgab: So now this is a script in the real/old sense of the word ;-)
12:26 waxhead if releasing Padre become longer than it  is now, I'd have to give up the job...
12:26 waxhead zenog, yep.. :)
12:26 zenog waxhead: It is also that we can share the tests, if we maintain the checklist in the wiki ...
12:26 zenog waxhead: You already do a lot for release management, there shouldn't be any additional tasks for you, of course.
12:26 zenog waxhead: i.e. there must not be any.
12:27 waxhead sure.. but people have to do the tests... the question was raised earlier about reporting bugs or problems when running latest trunk with ./dev... people don't always say anyhting..
12:27 waxhead zenog, actually I don't do that much these days... the learning curve as flattened right out and it's quite simple
12:27 waxhead the hardest part is the release announcement...
12:28 waxhead even the failing tests, I can now usually spot the problem code and fix it.. whereas before it took me much longer and I'd need to wait on people...
12:29 waxhead the first few releases I did, I pestered szabgab a heck of a lot about failing tests - while privately panicing that I wasn't good enough to do the job...
12:29 waxhead it used to take me over 3 hours for  a  release from start to finish.. these days it's a much shorter time frame...
12:30 zenog waxhead: You do a really, really good job as a release manager.
12:30 zenog waxhead: If there a things you feel like delegating during the release, just write to the mailing list.
12:30 waxhead I think this is by far the biggest issue all projects like these have... keeping your people and keeping them motivated..
12:30 zenog waxhead: You can also say: "We won't release until this and that task is done, and I won't do it." That'd perfectly fine.
12:31 zenog waxhead: At FOSDEM, I was thinking about how we can attract more developers.
12:31 zenog waxhead: My conclusion: I should spend 50% of my time on writing developer documentation.
12:32 szabgab waxhead: I don't think it will be longer
12:32 szabgab it will be split in two
12:32 szabgab but let me write down the release process in mail and then see how that changes things?
12:32 waxhead zenog, that's fine.. really... it's not quite the point I'm making... if I am making one  it's along the lines of what we already do is based on what free time we have... filling it with what I'd call "low self gratification" tasks, like testing, writing documentation ( not that either of these aren't important ) doesn't match our desire for "instant gratification" when you see you've don't something "positive".. hence people ge
12:32 waxhead nerally don't take on the harder tasks..
12:34 szabgab zenog: I think a set of use cases would go a long way both in testability of PAdre
12:34 waxhead I actually find the process of writing code in padre frustrating, simply because I have to relearn wx stuff, or go hunting through the code base to see where things start and end and work out how they link together...
12:34 szabgab and in letting people know about features
12:35 waxhead but it's not a padre problem.. it's a "me" problem...
12:35 zenog szabgab: There is already http://padre.perlide.org/trac/wiki/Release in the wiki, which may need some updates.
12:35 waxhead I've updated bits of it when I've needed to..
12:36 szabgab zenog: yes I know :)
12:36 waxhead the problem is the "me" is taking longer and longer breaks from the codebase and Wx.. so I'm always relearning.. which takes up time....
12:36 szabgab waxhead: you do a great job with the release but I wonder if you would not want to do other stuff as well?
12:36 waxhead so a couple of hours allocated to spend time on Padre is spent googling code...
12:36 zenog waxhead: That's why I think some more developer documentation would help a lot to concentrate on actually implementing and fixing stuff instead of finding out where the stuff is.
12:36 szabgab and maybe also get someone else do the hard work :)
12:37 szabgab I am a bit worried that you will burn out and throw in the towel at one point :)
12:37 waxhead lately I've discovered Call of Duty Black Ops.. and play it heaps with my son.. so where once I'd code Padre stuff, now I just want to level up and get to the next prestige... because I'm prestiging!!
12:37 waxhead it's prestigeous!
12:37 waxhead :)
12:38 zenog waxhead: It is also something you can do with your son.
12:38 zenog So we have to ask ourselves: How can we make Padre development a thing that is a fun activity for Perl hacker parents _with_ their kids?
12:38 waxhead oh.. and then there's my garden, and the thing with my weather station that I've found some perl code that lets me down load data, so of course that needs to go into a database and I need to write charting stuff...
12:39 waxhead which I never find time to do.. because I'm also a great procrastinator...
12:39 waxhead zenog, the trick is really just about the itch to scratch...
12:39 dapatrick left #padre
12:39 waxhead take a look at all the work anyone has done on Padre... what drives them?
12:40 waxhead it's not that it's isn't fun in it's own way, it's just that we all have personal reasons for do it.  Adam because he believes in Padre and things in it aren't what he wants, so he spends a lot of time ripping things up and fixing it...
12:40 zenog I want to have a stable Perl editor with some refactoring features ... and I am not willing to give up on that dream ... ;-)
12:40 waxhead szabgab, was likely that he wanted what we all wanted, a perl ide, written in perl so we could all make a difference.. he made the start many others hadn't...
12:40 waxhead well sort of..
12:41 waxhead me.. I just came long with a strong desire to contribute to the Open source community..  i  knew enough perl to be dangerous and found Padre...
12:41 waxhead I loved it... I made a difference..
12:41 zenog argh, this Trac wiki syntax sucks ;-)
12:42 zenog waxhead: Yes you do make a difference.
12:42 waxhead there's acutally little in Padre that I don't like that I go hunting around the code to fix... for me it just works..
12:42 zenog What I like about Padre is actually the low entry barrier.
12:42 zenog At least when it comes to commit bits.
12:42 zenog The actual barrier is the complexity of the code base.
12:42 waxhead indeed... and for me, there was lots of low hanging fruit to pick from in trac... so I did...
12:42 waxhead now we are at a point where most things are a bit harder to do..
12:43 zenog waxhead: agreed
12:43 waxhead so the bar has inadvertantly been raised.. not a bad thing...
12:43 waxhead and with that expectations are being raised with Padre's quality...
12:43 zenog The next important things will be harder: a debugger, the scintilla upgrade
12:44 waxhead which is fair enough.. but it does mean our development and release management needs to mature a bit.. which means "more work"...
12:44 waxhead for sure.. and we only have Alias, one Azawawi and one szabgab...
12:44 waxhead I know there are others, but generally the really hard stuff falls to these main guys...
12:45 waxhead I tried working with nytprof to integrate that as a profiler.. the best I did was running it from within Padre and shelling out the browser to load the htlm it creates...
12:46 waxhead Tim Bunce was talking about a version of nytprof that saved the data to a database of sorts which would certainly work better with integrating the information into Padre.. but I'm not sure where that got to...
12:48 waxhead but I could have tried reverse engineering the "generate" script that does the html and use that to better integrate into padre, but it got all too hard too quick... and near enough was good enough...
12:48 waxhead which isn't good enough in an IDE really.. :)
12:48 waxhead ok, now I'm really going to bed..
12:49 waxhead left #padre
12:52 kyanardag left #padre
12:58 user_3229 joined #padre
12:58 user_3229 left #padre
13:06 zenog szabgab: Here is a start ... of course still very incomplete ... http://padre.perlide.org/tr​ac/wiki/PreReleaseChecklist
13:13 zenog okay, back to work &
13:15 fenderson joined #padre
13:15 fenderson hi :)
13:15 szabgab hi fenderson
13:16 fenderson hey, i found a way to get into irc's padre channel
13:16 szabgab congratulations :)
13:16 fenderson thanks
13:17 szabgab now you can type   /join #dancer and say hi to sawyer
13:18 Sewi zenog: Parts of that checklist can be tested automatically
13:18 szabgab Sewi: that's ok
13:19 szabgab I think it is better to have a manual list and then if we find items that can be automated we write the automation
13:19 szabgab and then link to it from the wiki
13:20 Sewi There's nothing wrong doing it manually but automated tests run more often and require less user time
13:21 zenog Sewi: Everything that can checked automatically should be, of course!
13:21 szabgab just let's not stop him now as he started to write the checklist :)
13:21 * Sewi is silent now :)
13:21 zenog hehe
13:21 zenog szabgab: Don't worry, nothing can stop me :-P
13:22 zenog btw, who made the find dialog modal?
13:22 szabgab zenog: I already wrote an e-mail calling people to help you
13:22 zenog It is kind of impractical when working on translations ...
13:23 szabgab I just have not sent it out, waiting for some more content on that page
13:23 zenog szabgab: Great. It's a wiki, so people can basically add whatever they think ...
13:23 zenog szabgab: OK
13:23 szabgab zenog: for example screenshots, sample code that need to be tried etc
13:23 szabgab hint hint :)
13:26 ispy_ left #padre
13:29 Hyppolit svn: r13673 | zenogantner++ | http://padre.perlide.org/trac/changeset/13673
13:29 Hyppolit update German translation
13:29 Hyppolit trunk/Padre/ trunk/Padre/share/locale/ trunk/Padre/share/styles/
13:30 zenog a fix for the current situation could be to take the 0.80 release and just remove the buggy code, and to release that as 0.82
13:30 zenog current trunk would be then released at 0.84 ...
13:31 zenog So, now really really back to work ...
13:49 szabgab someone needs to teach waxhead how to write dates in readable format
13:49 szabgab some needs to teach all the English speakers ....
13:49 szabgab YYYY.MM.DD
13:56 asarch joined #padre
14:13 daxim yo, ISO 8601 prescribes YYYY-MM-DD
14:14 danlucraft left #padre
14:16 szabgab daxim: that would be also acceptable :)
14:22 danlucraft joined #padre
14:29 jnap joined #padre
14:33 kaare left #padre
14:44 dandre joined #padre
14:45 dandre Hello
14:46 dandre I am just trying padre on my project. How can I set the perl include path for syntax checking?
14:46 szabgab the good old feature request :)
14:47 szabgab I think the only way now is to set it before you launch padre
14:47 szabgab set PERL5LIB
14:47 dandre I have tried ti set it as run_interpreter_args_default but this doesn't seem to be taken into account
14:47 szabgab I think we should write an FAQ with this or fix the issue
14:48 szabgab sorry I am not even sure what that parameter does
14:49 dandre I'll try PERL5LIB
14:49 szabgab let us know how it worked
14:49 szabgab and let's see if there is an open ticket with this
14:53 dandre ok with PERL5LIB it's ok
14:53 ispy_ joined #padre
14:54 dandre is there any "project" feature in padre?
14:55 dandre for instance I have a project that is in a sub folder in my file system and I want to open files relative to this top directory
14:56 szabgab sure
14:56 szabgab View/Show Projects...\
14:57 szabgab if you have a Makefile.PL it recognizes that as being in the root of your project
14:58 dandre I don't have makefile.pl
14:59 szabgab Build.PL ?
14:59 szabgab dist.ini ?
14:59 szabgab none?
14:59 dandre I also have version 0.63
14:59 szabgab I think this already worked back then
14:59 szabgab last resort, create a padre.yml file in the root of your project
14:59 dandre and I don't see the project feature
14:59 szabgab it can be empty
14:59 szabgab oh
15:00 szabgab oh, naybe back then it was marked as an experimental feature?
15:00 szabgab are you on windows or linux?
15:01 zenog dandre: You can also use Ctrl-Shift-R to open files in your project.
15:03 dandre ubuntu 10.10
15:05 szabgab dandre: so maybe you could upgrade padre?
15:05 dandre ok  I'll try
15:06 kaare joined #padre
15:07 szabgab dandre: the best probably is to use local::lib and install from CPAN
15:07 danlucraft1 joined #padre
15:07 szabgab upgrade from CPAN
15:12 danlucraft left #padre
15:13 kaare left #padre
15:16 dandre I am installong everything from cpan
15:19 kaare joined #padre
15:33 danlucraft joined #padre
15:38 danlucraft1 left #padre
15:40 El_Che for whoever fixed the save-crash bug of today: thanks!
15:52 szabgab do we have any documentation for the individual menu options or only their name?
15:52 szabgab sorry, not menu options
15:52 szabgab configuration options
15:57 dandre left #padre
16:09 kyanardag joined #padre
16:22 Alias_ left #padre
16:42 marcela left #padre
16:47 pece joined #padre
17:19 mj41 left #padre
17:36 danlucraft left #padre
17:38 daxim left #padre
17:43 mj41 joined #padre
17:50 droidica joined #padre
18:00 droidica left #padre
18:01 droidica joined #padre
18:46 katodroid joined #padre
18:49 droidica left #padre
19:07 toi left #padre
19:08 toi joined #padre
19:23 Hyppolit svn: r13674 | szabgab++ | http://padre.perlide.org/trac/changeset/13674
19:23 Hyppolit show the help fifield of the options in the advance configurator and add sample help entry
19:23 Hyppolit trunk/Padre/ trunk/Padre/lib/Padre/ trunk/Padre/lib/Padre/Config/ trunk/Padre/lib/Padre/Wx/Dialog/
20:10 ispy_ left #padre
20:14 zenog &
20:22 dj_goku joined #padre
20:31 pece left #padre
20:44 dodathome joined #padre
20:45 danlucraft joined #padre
20:46 danlucraft left #padre
20:56 Hyppolit svn: r13675 | szabgab++ | http://padre.perlide.org/trac/changeset/13675
20:56 Hyppolit test all the config elements if they have entries in the Preferences window and list the ones that don't have
20:56 Hyppolit trunk/Padre/t/
21:26 dj_goku left #padre
21:26 dj_goku joined #padre
21:49 dodathome left #padre
21:58 jnap left #padre
22:02 dapatrick joined #padre
22:04 Sewi left #padre
22:14 asarch left #padre
22:59 Di-ima left #padre
23:02 kaare left #padre
23:09 Di-ima joined #padre
23:39 Alias joined #padre
23:39 dj_goku left #padre
23:40 dj_goku joined #padre
23:58 jnap joined #padre

| Channels | #padre index | Today | | Search | Google Search | Plain-Text | summary