Camelia, the Perl 6 bug

IRC log for #padre, 2009-12-20

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

All times shown according to UTC.

Time Nick Message
00:43 Getty i got the core problem of WxWidgets installation problem on debian
00:43 Getty its about Data::Dumper
00:43 Getty Wx doesnt require the right version of Data::Dumper it seems (and debians version doesnt have Dump which he wants to use
00:43 Getty but that just seems just one problem.. next one is on my screen <checking>
01:03 Getty ok wxwidgets
01:03 Getty seems to compile
01:03 Getty :D
01:08 Getty failed..
01:26 submersible joined #padre
01:44 kent\n joined #padre
01:48 kentnl joined #padre
04:42 Hyppolit svn: r9799 | szabgab++ | http://padre.perlide.org/trac/changeset/9799
04:42 Hyppolit move marker declarations to the editor class
04:42 Hyppolit trunk/Padre/lib/Padre/Task/ trunk/Padre/lib/Padre/Wx/
05:05 Hyppolit svn: r9800 | szabgab++ | http://padre.perlide.org/trac/changeset/9800
05:05 Hyppolit turn _prompt and _process_line into methods
05:05 Hyppolit trunk/Debug-Client/ trunk/Debug-Client/lib/Debug/ trunk/Debug-Client/t/
05:11 Hyppolit svn: r9801 | szabgab++ | http://padre.perlide.org/trac/changeset/9801
05:11 Hyppolit update version number to 0.10
05:11 Hyppolit trunk/Debug-Client/ trunk/Debug-Client/lib/Debug/
06:06 [1]awnstudio joined #padre
06:08 Hyppolit svn: r9802 | szabgab++ | http://padre.perlide.org/trac/changeset/9802
06:08 Hyppolit use the filename and row-number saved in the Debug::Client
06:08 Hyppolit add menu item to jum to current location
06:08 Hyppolit trunk/Padre/lib/Padre/Action/ trunk/Padre/lib/Padre/Wx/ trunk/Padre/lib/Padre/Wx/Menu/
06:32 awnstudio joined #padre
07:17 azawawi joined #padre
07:18 azawawi good morning
07:32 holli_ joined #padre
07:43 Hyppolit svn: r9803 | szabgab++ | http://padre.perlide.org/trac/changeset/9803
07:43 Hyppolit add some skipped tests
07:43 Hyppolit trunk/Debug-Client/lib/Debug/ trunk/Debug-Client/t/
07:44 szabgab azawawi, gm
07:48 azawawi hi szabgab
07:52 Hyppolit svn: r9804 | szabgab++ | http://padre.perlide.org/trac/changeset/9804
07:52 Hyppolit set/remove/list breakpoints
07:52 Hyppolit trunk/Padre/ trunk/Padre/lib/Padre/Action/ trunk/Padre/lib/Padre/Wx/ trunk/Padre/lib/Padre/Wx/Menu/
07:53 Hyppolit svn: r9805 | adamk++ | http://padre.perlide.org/trac/changeset/9805
07:53 Hyppolit Adding missing whitespace
07:53 Hyppolit trunk/Padre/lib/Padre/Wx/
07:53 Hyppolit svn: r9806 | adamk++ | http://padre.perlide.org/trac/changeset/9806
07:53 Hyppolit Another function list fix
07:53 Hyppolit trunk/Padre/lib/Padre/Document/
07:54 Hyppolit svn: r9807 | adamk++ | http://padre.perlide.org/trac/changeset/9807
07:54 Hyppolit Flush pending methods after they have been run
07:54 Hyppolit trunk/Padre/lib/Padre/
07:54 Astemd joined #padre
07:57 szabgab if someone wants to try the debugger, you will need the latest client:  pip http://perlide.org/download/so​urce/Debug-Client-0.10.tar.gz
07:57 * azawawi piping :)
08:04 waxhead joined #padre
08:05 Hyppolit svn: r9808 | szabgab++ | http://padre.perlide.org/trac/changeset/9808
08:05 Hyppolit quit the debugger when closing Padre
08:05 Hyppolit trunk/Padre/lib/Padre/Wx/
08:07 Hyppolit svn: r9809 | adamk++ | http://padre.perlide.org/trac/changeset/9809
08:07 Hyppolit Migrated no_refresh to the new refresh system
08:07 Hyppolit trunk/Padre/ trunk/Padre/lib/Padre/ trunk/Padre/lib/Padre/Wx/
08:30 szabgab Alias, tests fail
08:35 szabgab jq, ping
09:12 kaare joined #padre
09:21 tsee joined #padre
09:23 pece joined #padre
09:59 szabgab crap,
09:59 szabgab Alias broke Padre and now he left
10:05 Hyppolit svn: r9810 | szabgab++ | http://padre.perlide.org/trac/changeset/9810
10:05 Hyppolit use the real Locker object so at least Padre can run - or it seems that it can run
10:05 Hyppolit trunk/Padre/lib/Padre/Wx/
10:07 Hyppolit svn: r9811 | szabgab++ | http://padre.perlide.org/trac/changeset/9811
10:07 Hyppolit add another window to display variables during debugging
10:07 Hyppolit trunk/Padre/lib/Padre/Action/ trunk/Padre/lib/Padre/Wx/ trunk/Padre/lib/Padre/Wx/Menu/
11:14 Hyppolit svn: r9812 | szabgab++ | http://padre.perlide.org/trac/changeset/9812
11:14 Hyppolit remove some duplicate configurations in the actions
11:14 Hyppolit trunk/Padre/lib/Padre/Action/
11:17 szabgab I just noticed that we allow mixed boolean operators.   ProhibitMixedBooleanOperators why ?
11:18 szabgab and we have code like this:
11:18 szabgab $enabled = 0if $action->{need_editor} and ( !$editor );
11:21 awnstudio joined #padre
11:24 tsee szabgab, I saw you picked up working on Debug::Client again.
11:25 tsee Can I infer that this means you're working on Padre debugger integration?
11:34 tsee Actually. It's quite obvious when running Padre.
11:34 tsee Thanks for that!
12:15 szabgab tsee, have you tried it ?
12:16 tsee a tiny little bit
12:16 tsee "list breakpoints" just spews to the console
12:16 szabgab yes
12:16 tsee (also, marking breakpoints in the gui will be necessary)
12:16 tsee I know. Talk is cheap!
12:16 szabgab yes, that's in the todo
12:16 tsee Great stuff. We've been missing that on the feature list for a while.
12:17 szabgab now I try to add toolbar buttons
12:17 tsee That's an easy bit :)
12:17 szabgab then you might do it ?
12:17 szabgab and I'll try to add displaying complex data structures as well
12:17 tsee That's not what I was trying to say :)
12:17 szabgab ok :-)
12:18 tsee "displaying complex data structures"?
12:18 tsee Have you tried Wx::Perl::DataWalker?
12:18 Sewi joined #padre
12:18 Sewi_Ubuntu joined #padre
12:18 Sewi hi all
12:18 tsee And its Padre plugin.
12:18 tsee Hi.
12:18 tsee May have bit-rotted a bit.
12:18 szabgab I still need to figure out how to display it in the right hand window
12:18 tsee Ah.
12:18 tsee Wx::Perl::DataWalker may or may not be a widgety thing.
12:19 szabgab and I think it won't work as I need to parse the data as sent back by the debugger
12:19 tsee But it could be made one.
12:19 tsee Well, it only walks Perl data structures in memory.
12:19 szabgab I can do 2 things
12:19 szabgab 1) parse the output   of    x \@data
12:20 szabgab as printed by the debugger
12:20 tsee Hmm.
12:20 szabgab 2) load some existing serialization tool and serialize the data on the other side
12:21 szabgab I don't want to force the user to install any extra module on the target perl - if possible
12:21 szabgab which means Data::dumper
12:21 szabgab Data::Dumper
12:21 tsee Ah, it does?
12:21 tsee Then eval would do.
12:21 szabgab yes
12:21 tsee I mean. You're trusting the program you're debugging anyway.
12:21 szabgab but it is a bit of a security issue
12:22 tsee Is it?
12:22 tsee Not really.
12:22 szabgab it is possibly running on a remote machine
12:22 tsee Ah, right.
12:22 tsee But still.
12:22 tsee Actually, it may not be Data::Dumper.
12:22 tsee It's dumpvar.pl as far as I can see.
12:22 tsee Which is probably the precursor to DD.
12:22 szabgab yes, that's what the debugger does, that is case 1)
12:22 tsee (ancient shit)--
12:23 szabgab but do we have a parser for that ?
12:23 tsee DD?
12:23 tsee You mean aside from perl itself? No.
12:23 szabgab or can we eval that code
12:23 szabgab wait
12:23 tsee Well, I assume dumpvar.pl is something very similar to DD.
12:23 szabgab 1) used x (dumpvar.pl)   and I have no idea how to parse,   2) use DD and eval
12:23 szabgab it is not similar
12:23 tsee By the way. I think it doesn't guarantee dumping arbitrary levels of data structures.
12:23 tsee No, okay.
12:24 tsee (dumpvar.pl doesn't)(
12:24 tsee So you know how to hook into the debugger so that you can use an arbitrary serialization routine?
12:24 tsee If so, you could do something like this:
12:24 tsee a) Check whether YAML::XS or JSON::XS or some other fast, safe dumper is available.
12:24 tsee => if so, use it
12:25 tsee b) Fall back to DD&eval
12:25 tsee This *would* mean adding a dependency of Padre on whatever serializer was used.
12:25 tsee But I think that is acceptable.
12:25 tsee CPAN testers will tell whether a given module is portable and stable enough.
12:26 szabgab I might go with DD for now
12:26 tsee So this way, you can tell users "look, if you want *safe* remote debugging, install $something. If you just want remote debugging and don't care about such things, don't bother and it will *just work*"
12:26 szabgab so I won't need to force the users to install other modules on the remote perl
12:27 tsee Hence my suggestion.
12:27 szabgab tough as I think most of the people will use the same perl for both padre and the execution
12:27 tsee And then it doesn't matter much anyway.
12:28 Getty szabgab: the package worked, but its pointless if i cant install over it for example plugins, cant you include all padre plugins to it?
12:29 szabgab Getty, slowly!
12:29 szabgab tsee, http://www.pastebot.net/paste/scCB4JTBJJ4/
12:29 Getty btw under testing i have the same horror with Padre
12:29 Getty it seems like Padre doesnt like Debian or other around :-/
12:29 szabgab don't say that
12:30 Getty but its true
12:30 szabgab it is 1) not padre bu wxWidgets right ?
12:30 Getty yeah of course
12:30 tsee That's a big difference.
12:30 Getty lol :)
12:30 szabgab 2) Maybe that's only Ubuntu, but I did not have much problem
12:30 Getty cause of the release cycle!
12:30 Getty we had that discussion yesterday
12:30 Getty ;)
12:30 tsee Getty, this is out of our control, though.
12:30 tsee Apart from nudging Mattia a bit.
12:31 tsee szabgab, that's dumpvar.pl output, right?
12:31 Getty lets say: you can ignore it or not ;)
12:31 szabgab the best you can do is to help the Debian perl builders
12:31 tsee I'd suggest *not* trying to write a parser.
12:31 szabgab or setup and maintain! a .deb backport repo
12:31 Getty they just need to add ONE high version, debian testing still have 2.8.7
12:31 Getty but we still need 2.8.8
12:31 Getty head => wall
12:31 szabgab oh and I was showing a simple example only where the values did not contain newlines
12:32 szabgab which would make things really, really horrible
12:32 tsee No, it would require a proper parser :)
12:32 tsee It's possible but whittling out the edge case bugs would be annoying.
12:32 tsee And probably a waste of time.
12:33 szabgab so I inject Data::Dumper in the target code and then use that
12:33 tsee Yes.
12:33 tsee I'd suggest DD and adding optional $something::XS later if security is an issue.
12:33 szabgab I guess  -MData::Dumper calls import, right ?
12:33 Getty yes
12:33 tsee Yes.
12:33 szabgab less good,
12:34 Getty you cant prevent that ;)
12:34 tsee You want -m
12:34 tsee Yes, you can.
12:34 szabgab oh
12:34 Getty oh??
12:34 tsee perl -mData::Dumper -e1
12:34 tsee Won't call import.
12:34 Getty and what is the state then?
12:34 Getty i mean.. a module is supposed to get its import called, or?
12:34 szabgab -m  nice
12:34 szabgab I did not know about that
12:35 tsee Getty, not necessarily.
12:35 szabgab Getty, I don't want to inject extra subs in the code we are debugging
12:35 tsee You can require it, too.
12:35 tsee Using import() for setting up the module's internals is a bad idea.
12:35 tsee It can be called many times, too.
12:35 szabgab so basically even instead of    p $x   I 'll use Dumper $x
12:36 szabgab to make it easier to *not* parse it
12:36 tsee You can try that and see whether it's too slow or funny.
12:36 tsee The lexical scope of the module itself is exectuted.
12:36 tsee *executed.
12:36 tsee Thus setting up stuff in import() isn't necessary.
12:37 tsee You can always put a "system('rm -rf ~')" into the main scope of the file and it'll be executed when the module is loaded for the first time.
12:40 Getty so can we find out why we need exactly 2.8.8 and cant go with 2.8.7? ;)
12:40 szabgab we can add that as an easter egg ;-)
12:41 tsee Getty, ask wxperl-users
12:41 Getty even tho i think it doesnt help me at all, cause Alien-WxWidgets has his own wish for a version
12:41 tsee It's that Wx.pm requires wxWidgets 2.8.8
12:41 Getty tsee: mh....
12:41 tsee That's the exact reason why.
12:41 Getty thats horrible situation
12:41 tsee And A::wxWidgets is failing?
12:41 Getty i feel like in trouble land
12:41 Getty yes
12:41 tsee How exactly?
12:41 Getty totally
12:41 Getty lots of errors
12:41 Getty big tons of standard C compiler errors
12:41 tsee Can you nopaste the whole thing?
12:42 Getty yes sure, let me redo it and then pastebin it somewhere
12:42 tsee Okay.
12:42 tsee OTOH, I remember an old university machine which may or may not have a debian stable.
12:42 Getty the funny part is
12:42 Getty i killed my debian stable and upgraded to debian testing
12:42 Getty and both has still only wxwidgets 2.8.7 !!!!
12:42 Getty <= jackass
12:43 tsee lenny is stable?
12:43 Getty yes
12:43 Getty now i got squeeze
12:43 tsee Man, that sources list still has commented sarge entries.
12:43 Getty lol
12:43 tsee I remember adding those when I upgraded from woody.
12:43 tsee debian++ # rock solid.
12:43 Getty yeah of course debian rocks
12:43 Getty thats why i use it
12:43 Getty but now
12:43 Getty i got the standard problem of "to old"
12:44 Getty beside yesterday where i tested the "standalone version", i didnt saw padre for weeks
12:44 tsee I'll do some experimenting.
12:44 tsee Don't hold your breath.
12:44 Getty cpan is running... could take some minutes
12:44 Getty or more ;)
12:45 szabgab some time ago I tried to install Debian Stable on a VirtualBox but horribly failed and did not have the tuits to go on
12:45 Getty i dont get it with the Wx <=> Alien::WxWidgets
12:46 Getty do i see it right.. that Alien::WxWidgets just compiles the lib, that Wx then really use?
12:46 szabgab and I tried to build Padre on Ubuntu 6.06 and failed there too
12:46 Getty so if i would have the right Wxwidgets version on my system Wx works without Alien::Wxwidgets?
12:46 szabgab Alien::wxWdigets is the C library
12:46 Getty did i understood that right?
12:47 szabgab Wx is the wxPerl
12:47 szabgab yes
12:48 Getty paste.debian.net doesnt want my post, too big :D
12:48 Getty http://pastebin.com/m553906a1
12:48 Getty tsee: its sadly "not all of errors" there is something before, but i must increase console buffer to get it 8-)
12:49 Getty ah... unlimited scrollback.... excellent
12:49 tsee Getty: If your wxWidgets version is high enough, Alien::wxWidgets will simply install itself without compiling anything.
12:49 tsee I'm running "install Alien::wxWidgets" on lenny.
12:50 tsee Arg
12:50 tsee FAIL
12:50 tsee Missing some gtk stuff.
12:50 tsee But I can't just install that kind of thing on a production server.
12:50 tsee That would have been too easy.
12:51 tsee Getty, I'll need the full output.
12:51 Getty i'm on it
12:51 tsee Because usually, the first error is the important one.
12:51 Getty just pasted it
12:51 Getty browser hangs
12:51 tsee Takes a while to upload, probably :)
12:51 Getty <waiting>
12:51 Getty it was hardcore enough to "mark" it for copy
12:52 Getty i think i must 2> it to a file and upload it somewhere
12:52 tsee Make sure you put stderr and stdout in the same stream
12:52 Getty of course
12:53 Getty http://www.raudssus.de/wx_install_error.txt
12:53 Getty HA!
12:53 Getty "i win!" ;)
12:54 Getty i need 2-3 min. for a cigarette outside
12:56 tsee Umm.
12:56 tsee Alien::wxWidgets installed alright?
12:57 Getty yes it says so
12:57 tsee This is a clue: ../../cpp/wxapi.h:25:21: error: wx/defs.h: No such file or directory
12:57 tsee Okay. It did not compile anything?
12:57 tsee Alien::wxWidgets, I mean.
12:57 Getty i must say, i cant really remember.. but i think only wx widgets started to compile stuff
12:58 Getty aehm Wx
12:58 Getty not Alien::WxWidgets
12:58 Getty should i force it?
12:58 Getty (btw: just sidenote: that all happens in a local::lib env)
12:58 tsee waaait
12:58 tsee Let's separate bits.
12:58 Getty roger
12:58 tsee Wx.pm must be installed after Alien::wxWidgets.
12:58 Getty yeah
12:58 tsee It's the wxWidgets *Perl bindings*
12:58 Getty yeah
12:58 tsee It needs an installed Alien::wxWidgets
12:59 tsee And an installed wxWidgets (the C++ lib)
12:59 tsee And the wxWidgets headers.
12:59 Getty yeah, clear, but i only have 2.8.7, so then he (Wx) starts downloading newer wxwidgets, and starts compiling
12:59 tsee If A::wxW was installed, its job is simply to ensure that wxwidgets (the lib) and its headers are available.
12:59 tsee Wx.pm shouldn't be downloading anything.
12:59 tsee And what you pasted is not that.
13:00 tsee Wx.pm is just the XS wrapper.
13:00 tsee Alien::wxWidgets may be doing that.
13:00 tsee And probably should.
13:00 Getty then this one did
13:00 tsee If it starts compiling and finishes and then installed okay, then the Wx.pm error is strange.
13:01 Getty Alien::wxWidgets is up to date (0.47).
13:01 tsee Okay.
13:01 Getty (he says....)
13:01 Getty dont know what exactly is going on, if you want
13:01 Getty i can "kill" my local::lib
13:01 tsee Do you have the libwxbase2.8-dev package installed?
13:01 Getty and start over
13:01 Getty checking
13:01 Getty nope!
13:02 Getty installing it now
13:02 Getty done
13:02 Getty retrying cpan Wx
13:02 Getty same error
13:02 Getty reinstall Alien::wxWidgets?
13:02 tsee You can try that.
13:02 Getty install OK
13:03 tsee But that Wx.pm gives you the *same* error with- and without the wx headers available is very strange.
13:03 tsee I'm creating a local::lib repo on my laptop.
13:03 Getty same error :(
13:03 tsee To see whether that's the cause.
13:03 Getty tsee: if you try it out in a local::lib, directly install Data::Dumper new
13:03 tsee ?
13:03 Getty tsee: there are some libs on the "tree for padre" which use "Dump" and dont specify in the package that they need Data::Dumper with that function
13:04 Getty debian delivers a Data::Dumper which is so old that it doesnt have the "Dump" function
13:04 tsee This isn't debian.
13:04 Getty ah ok
13:04 Getty i just warn you before
13:04 tsee But seriously. 5.10.0 included an old DD that doesn't have Dump()?
13:04 Getty yes
13:04 Getty so it seems
13:05 Getty or debian delivers 5.10.1 with a wrong Data::Dumper
13:05 Getty but that is another theme, which can be farly easy tracked
13:05 Getty lets concentrate on the Wx stuff first
13:05 Getty so that i get my padre
13:05 tsee No, no. If debian ships 5.10.1, then DD *must* be current.
13:06 tsee Or else the royally screwed up the perl core package.
13:06 tsee Which I don't think. They're clueful.
13:06 Getty tsee: i will analyze that
13:06 Getty tsee: and give you decent report
13:06 Getty but first i need my Padre! :D
13:12 tsee a forced wxWidgets compilation is running now.
13:14 tsee Seems to be working just fine so far.
13:14 Getty it takes hours till the compile error occurs
13:14 Getty it compiled at first just fine
13:14 Getty i was happy that i finally get my padre
13:14 Getty and then... BAM
13:16 tsee hours!?
13:16 Getty hehe no idea i lost track of time
13:16 tsee My two-year old laptop is done in a few tens of minutes, if I remember correctly.
13:16 Getty i'm just working since 3-4 weeks in a row
13:45 tsee Getty, I'm getting the same error.
13:45 tsee It's a local::lib <-> Wx.pm issue.
13:45 tsee No idea what's going wrong.
13:45 tsee => wxperl-users
13:46 Getty arghl....
13:46 Getty :-(
13:48 Getty can i remove a specific lib from my local::lib install easy?
13:48 Getty ah no wait.. there is much more..
13:48 tsee Depends on the complexity of it.
13:48 Getty i just installed alien-wxwidgets via debian
13:48 Getty but this is 2.8.7
13:49 tsee Why not just a "sudo cpan Alien::wxWidgets"?
13:49 tsee Naturally, if the debian wxWidgets is old, so is Alien::wxWidgets
13:49 szabgab Getty, have you tried to build a brand new perl ?
13:50 szabgab and install in it everything?
13:50 szabgab no PERL5LIB, no local::lib
13:51 Getty what what?
13:51 Getty stop stop
13:51 Getty we talk about "the system"
13:51 Getty and we talk about userspace
13:51 Getty in a clean manner i dont want to violate the system install
13:51 tsee And right now, you're trying to mix the two.
13:51 Getty no!
13:51 Getty thats why i have local::lib
13:51 tsee szabgab, is suggesting you install your own user perl.
13:51 tsee local::lib is a cludge.
13:51 Getty anything outside my home is "standard debian"
13:51 Getty yes
13:51 Getty that i want my stuff in userspace is the problem now
13:52 Getty but i dont want to install libs that arent supposed to be there
13:52 Getty if you know what i mean
13:52 tsee Okay. The problem is that ll and Wx.pm don't like each other.
13:52 szabgab tsee,  I am not sure about that
13:52 tsee So either bring it up to their maintainers so something gets fixed, or do the full monty and don't use the system perl.
13:52 szabgab ate least I manage to build Wx with ll as well
13:52 Getty szabgab: you did? on the ubuntu?
13:52 szabgab yes on ubu
13:53 tsee szabgab, but you didn't use A::wxW to install wxWidgets then.
13:53 szabgab but Getty I'd really suggest to try to build your own perl and install everything in that perl
13:53 tsee It's that the wxWidgets headers aren't found by Wx.pm.
13:53 szabgab I think I did use Alien ..
13:53 szabgab but maybe it was mixing things up
13:53 szabgab I don't know
13:54 Getty szabgab: in userspace?
13:54 szabgab Getty, maybe try to use the XL builder
13:54 szabgab yes in userspace
13:54 Getty XL Builder? never heard
13:54 Getty but ok ok! its all clear then
13:54 szabgab the one that built the XL package
13:54 Getty i mean i have no choice
13:54 Getty but actually what we suggest other debian users then?
13:54 szabgab in our repository
13:54 szabgab Dist::Perl::XL
13:54 Getty ah ok, i do that then
13:54 Getty we must warn them or give them a solution
13:55 tsee szabgab, just because you instaleld Alien::wxW., that doesn't mean it did compile its own wxWidgets.
13:55 szabgab the whole idea behind the XL distribution is to give them a solution
13:55 tsee I had to force it sinca my system wxWidgets is new enough.
13:55 szabgab but you said it is useless, or some other derogatory word
14:05 szabgab Sewi, ping
14:05 Sewi szabgab: pong
14:06 szabgab oh, great you are here
14:06 szabgab do I remember correctly that you changed the toolbar code
14:06 szabgab to make it configurable?
14:06 Sewi yes.
14:07 szabgab so if I understand it is a bunch   of     action:icon;
14:07 szabgab strings, right ?
14:07 Sewi yes
14:07 szabgab do you know why are there two regexes in ToolBar.pm   new() to parse those ?
14:08 szabgab it seems sometimes ( ) is allowed ?
14:08 szabgab what for ?
14:09 * Sewi looking...
14:09 patspam joined #padre
14:11 Sewi () are used for arguments (if any action supports them), for example edit.paste(5):icons/paste may paste the clipboard 5 times. (Its a bad example, because paste doesn't support this.)
14:11 Sewi Don't know if it's used at all currently.
14:12 * Sewi adding comments
14:12 szabgab wait
14:12 szabgab I thought the whole thing coulde be refactored
14:12 szabgab that the path to the icon is part of the action definition
14:13 szabgab and configuration is just a list of actions
14:13 szabgab the Toolbar configuration, that is
14:14 Sewi It already is (could be), afair, but not all actions have icon definitions and you may want to add another icon than the default to the toolbar.
14:14 Sewi The syntax is "action:icon" where ":icon" is optional.
14:16 Sewi Hmm, is isn't that way.
14:17 Sewi szabgab, what do you think about leaving custom icons as an option but moving the default definitions into the actions (as you wrote)?
14:17 szabgab why would we want to allow replacing the icons ?
14:18 Getty tsee: just curious, how you realized that its an issue between them?
14:18 Getty tsee: was it a test, or was it some other specific hint?
14:18 tsee I tried it.
14:18 tsee It otherwise succeeds.
14:19 Sewi szabgab: You're probably right.
14:19 szabgab Sewi, in my question?
14:20 szabgab A question is always right
14:20 Sewi combined with arguments, a user could use actions for other purposes (like adding "file.open(mytemplates/foo.pm" as "Create new Catalyst view"
14:20 szabgab right?
14:20 szabgab I might understand the arguments thing
14:20 szabgab though I am not sure this is the way to solve it
14:21 szabgab anyway, the parsing could be made simpler by a second split on :
14:21 szabgab instead of regexes
14:21 Sewi Or "file.open(Changes)" for a "Update Changes" toolbar item.
14:21 szabgab and IMHO we don't need that either
14:22 Sewi But otherwise one could add a action using My.pm, define everything there and push that new custom action to the  toolbar
14:22 Hyppolit svn: r9813 | szabgab++ | http://padre.perlide.org/trac/changeset/9813
14:22 Hyppolit add toolbar items for the debugger
14:22 Hyppolit trunk/Padre/lib/Padre/ trunk/Padre/share/icons/gnome218/16x16/stock/ trunk/Padre/share/icons/gnome218/16x16/stock/code/
14:22 szabgab could you please try it now?
14:23 Getty tsee: ok, its my first time that something cause of local::lib fails
14:23 szabgab so Sewi is it ok with you if we don't let users replace the icons of an action ?
14:23 szabgab they can always create a new action with a new icon
14:23 szabgab but calling the same thing
14:23 Getty and i really use it massivly... this makes me sad ;)
14:23 szabgab Getty, you should be happy to find a bug!
14:23 szabgab Getty++
14:23 tsee Software has bugs. Report it and it'll be fixed. Probably.
14:24 Getty i think there is a third test possible
14:24 Getty doing it with local::lib as root
14:24 szabgab Getty, are you suisidical ?
14:24 Getty probably its just a security issue with installing wx, which would be very logical
14:24 tsee Getty, I don't think so.
14:24 tsee It's not finding the headers.
14:24 Sewi szabgab: We might think of something simpler than reading into Padre and creating a My.pm for customizing the toolbar. A sample in default My.pm should probably do the job.
14:25 tsee szabgab, feature request:
14:25 Sewi szabgab: Debug icons work.
14:25 tsee Yes, they do.
14:25 tsee When the debugger is already running.
14:25 tsee Then the "Start debugger" button should just be "continue"
14:25 tsee That just makes sense, I think.
14:25 tsee And is what users will expect.
14:25 Getty tsee: ah... so its just that Wx is not searchign at the place where the local::lib Alien::Wx has put them
14:25 tsee Getty, something like that, I recon.
14:25 szabgab am not sure we really need that "start debugger" at all
14:25 szabgab as a step-in will start the debugger
14:26 tsee szabgab, also, I'd like to be able to set break points before starting the run.
14:26 tsee If at all possible.
14:26 szabgab it probably should be just "Run"  which is  c  in -d
14:26 tsee I can see how that's difficult.
14:26 Getty i think that is a very very interesting point of a bug, cause if i now try (when i get the time next days) to analyze it totally down, then i understand the point about "linking in extra compiled libs" which massivly increase my possibilities....
14:27 szabgab once I know how save the breakpoints between runs, I will be able to do that as well
14:27 Getty always try to to learn from the bug ;)
14:27 Sewi szabgab: For debugging Padre, I usually set DB::single breakpoints to the interesting line and run Padre until it reaches the breakpoint
14:27 tsee Yes, I was going to suggest the saving-between-runs, too.
14:27 tsee I think the solution to that is storing the breakpoints info locally instead of using the debugger for state.
14:27 tsee That'll be useful for displaying the breakpoints in the GUI, too.
14:28 Sewi szabgab: Feature request: Show breakpoints as a (stop?) icon next to the line number
14:28 tsee Sewi, I was faster in reporting that :P
14:28 szabgab I'll set them as a red mark for now
14:28 Sewi tsee: yes, you won :-)
14:28 szabgab or at least I'll try
14:28 tsee szabgab, considering Sewi and my bickering. Please understand it as "This is great, please keep going" as opposed to... bickering :)
14:29 szabgab oh sure, I know :-) and I have to tell that I have all these in my TODO list already
14:29 szabgab way before you complained :-)
14:29 szabgab so I won
14:29 Sewi :-)
14:29 szabgab but I'd like to get an answer to my question
14:29 szabgab what about eliminating the run button
14:30 Sewi It's really really great, this will be the most important function for the upcoming release.
14:30 tsee Hmm.
14:30 szabgab as step-in would start the debugger anyway
14:30 tsee but you need the "continue until breakpoint" button
14:30 szabgab yes
14:30 tsee Which is (or can&should) be the same as the run buttno.
14:30 szabgab I'd use that icon for the (c) feature
14:30 tsee Right.
14:30 tsee But "continue" is conceptually compatible with "start".
14:30 szabgab not exactly
14:31 Sewi Would be ok to use one button for both
14:31 szabgab as if you can set breakpoints before running
14:31 szabgab then you should be able to say "run till breakpoint"
14:31 tsee How does that collide?
14:31 tsee You have two cases: a) debugger not running. Clicking the button will do "run until breakpoint".
14:32 szabgab then you need tw features on the same button when the code is not running
14:32 tsee b) debugger running. Clicking the button will do "continue until breakpoint".
14:32 szabgab oh that
14:32 szabgab that's the same
14:32 tsee I don't see the problem, but that could be just me.
14:32 tsee Okay.
14:32 szabgab right now it has a different meaning
14:33 szabgab now it means start the debugger and don't do anything
14:33 szabgab but step-in does exactly the same now
14:33 szabgab or should
14:34 szabgab so I think I'll just remove the "Run the debugger" menu item
14:34 szabgab and the button will be "run/continue till breakpoint"
14:34 tsee Perfect.
14:34 szabgab another Q:
14:34 szabgab I think I'd like to have a separate menu column for the debugger and the hot-keys should be the same as in the -d debugger
14:35 szabgab non-translatable
14:35 szabgab s = step-in, n=step-over ....
14:35 szabgab if for nothing else, for the educational value in it
14:35 szabgab so you can then Alt-D s
14:36 szabgab if you are not the mousy type
14:36 Sewi What about a text box at the bottom of the debugger panel? Focus it and each keypress will work like -d (without the need of pressing ENTER, if possible)
14:37 tsee What about adding a debugger panel to the lower panel.
14:37 tsee Which could have all the nice debugger buttons
14:37 tsee And a little window for the output
14:37 tsee It could (later) also include a Wx::Perl::DataWalker widget
14:37 tsee Just brainstorming, though.
14:37 szabgab that's too much for me now :-)
14:37 tsee :)
14:38 tsee By the way. Setting breakpoints on empty lines fails.
14:38 tsee It could instead set the break point on the next statement,.
14:38 szabgab can someone look at the warnings Alias added to padre?
14:38 szabgab Use of uninitialized value $_[1] in hash element at /home/gabor/work/padre/Padre/lib/Padre/Locker.pm line 113.
14:38 tsee And yes. Having the debugger in its own menu makes sense.
14:38 tsee I get those, too.
14:38 szabgab it is the last change of Alias
14:39 szabgab that totally broke padre
14:39 Sewi szabgab: Just opened Locker.pm because of them :)
14:39 szabgab I fixed the breakage but not the warnings
14:39 szabgab ok, I fetch a tea and get to those enhancements in the debugger
14:40 tsee I must say, I'm really quite excited about your debugger work.
14:41 El_Che_ hi
14:41 El_Che_ debugger?
14:41 El_Che_ nice
14:41 tsee El_Che_, try the trunk.
14:41 tsee It's awesome.
14:43 El_Che_ doing a svn update
14:43 El_Che_ it has been ages!
14:44 Hyppolit svn: r9814 | Sewi++ | http://padre.perlide.org/trac/changeset/9814
14:44 Hyppolit (Hopefully) fixed the use of uninitlized value in Locker.pm
14:44 Hyppolit trunk/Padre/lib/Padre/
14:45 Sewi szabgab: There are TERMINATED prints to the console, you know?
14:45 El_Che_ A whole new set of dependencies versions :)
14:48 El_Che_ so who is the alpha coder nowadays :)
14:49 tsee szabgab,
14:55 tsee Okay, I think I have a fix for the warning.
14:56 tsee szabgab, should I commit it?
14:56 Sewi tsee: Should be done by r9814
14:56 Hyppolit Changeset #9814 http://padre.perlide.org/trac/changeset/9814
14:57 tsee Ah, right. :)
14:58 El_Che_ szabgab: thx for the christmas present!
14:58 El_Che_ impressive
15:03 tsee szabgab, would you mind if I committed some doc fixes for Debug::Client?
15:06 tsee szabgab, also, when there's a serious perl5db.pl-side issue such as "apparently no clear success/error report for this (remove_breakpoint)". That stuff can be fixed in core perl.
15:06 tsee It'd take a while until it's seen in the wild.
15:10 tsee I can also take a shot at the serialization<->deserialization thing.
15:21 tsee szabgab? Ping?
15:23 tsee I'll just commit my minor changes.
15:23 tsee Assuming you're not *currently* working on it.
15:23 Hyppolit svn: r9815 | tsee++ | http://padre.perlide.org/trac/changeset/9815
15:23 Hyppolit Very minor documentation, whitespace and style nits
15:23 Hyppolit trunk/Debug-Client/lib/Debug/
15:37 tsee szabgab, okay, I have an initial cut of the dumping/undumping using DD.
15:37 tsee Not tested yet.
15:49 szabgab oh, I fell asleep
15:49 szabgab now back
15:50 szabgab tsee, tanks
15:50 tsee The dumping/undumping thing doesn't work yet.
15:51 szabgab do you mean complex data structures?
15:51 szabgab no, I have not touched that yet
15:51 tsee I have started.
15:52 szabgab oh great
15:52 szabgab tsee, what is that side issue you mentioned ?
15:53 szabgab oh I understand now
15:53 szabgab well, I don't think p5p can fix anything actually
15:53 szabgab or not much
15:53 szabgab as my hope is that we can use it against any older perls as well
15:53 tsee Umm. I'm suggesting you or we do that and submit a patch.
15:54 tsee Think forward.
15:54 tsee It'll make for better debugging *eventually*
15:54 szabgab yes forward maybe
15:54 tsee Yeah. perl5db.pl is unlikely to get dual-lived.
15:54 tsee Anyhow. debugger question:
15:54 tsee Is it STDOUT of the debugged process that gets sent to the debugging client?
15:57 szabgab nope
15:57 szabgab std* are not touched
15:57 szabgab err
15:58 szabgab a normal debugger client puts this info out to I think STDOUT yes
15:58 szabgab but if you ask about the normal STDOUT of the actual script it is left of STDOUT
15:59 szabgab hmm, I might not be totally awake yet
16:00 szabgab tsee, are working on the Debug::Client code?
16:01 szabgab I wanted to change it totally probably stopping the wantarray thing
16:01 szabgab just so you know
16:01 tsee Go ahead. I'll fix the conflict locally.
16:04 cognominal joined #padre
16:08 szabgab I am not there yet in time fram
16:08 szabgab e
16:09 szabgab just so that you don't invest time in replicating it in some code
16:09 tsee Yeah.
16:09 tsee Good to see wantarray going away.
16:09 szabgab there are already ->file  and ->row getters
16:09 tsee Anyway. execute_code doesn't seem to work :/
16:09 szabgab worked for me :-)
16:09 szabgab at least for variable assignment
16:12 tsee szabgab, ah, the problem seems to be that _get blocks if there was no output to STDOUT or somesuch.
16:13 szabgab pls try to write a unit test
16:13 tsee szabgab, strike that. It even waits for the next debugger prompt.
16:14 tsee Well, can't write tests against a work in progress, really.
16:14 szabgab that code is tested extebnsively
16:14 tsee Experimental work in progress, really.
16:15 Hyppolit svn: r9816 | szabgab++ | http://padre.perlide.org/trac/changeset/9816
16:15 Hyppolit move debugger menu items to new Debug menu
16:15 Hyppolit trunk/Padre/lib/Padre/ trunk/Padre/lib/Padre/Wx/ trunk/Padre/lib/Padre/Wx/Menu/
16:23 Hyppolit svn: r9817 | szabgab++ | http://padre.perlide.org/trac/changeset/9817
16:23 Hyppolit replace the Run button by a Run till breakpoint button, eliminate the Run action and menu item
16:23 Hyppolit trunk/Padre/lib/Padre/ trunk/Padre/lib/Padre/Action/ trunk/Padre/lib/Padre/Wx/Menu/
16:25 szabgab tsee, so before I start butchering Debug::Client, are you in the middle of sg, shall I wait or can I feel free to change it ?
16:25 tsee Can you give me another fifteen minutes for debugging?
16:25 szabgab sure
16:27 tsee szabgab, question. If I run ($buf, $res) = $s->execute_code("..."). What do I get back in $res?
16:29 szabgab I think that should be the STDOUT of it , though now I am not sure why
16:29 tsee Doesn't seem it is.
16:29 tsee I don't know how to return the Dumper(...) string to the client.
16:30 szabgab hmm, I'll look at it later
16:30 szabgab bbl
16:30 tsee :(
16:37 tsee szabgab, okay, I give up.
16:37 tsee I have no idea how I can pass a string from the debugged process back to the client.
16:37 tsee (from execute code)
16:39 szabgab maybe we cannot and the whole idea was wrong
16:39 szabgab but now dinner &
17:16 Hyppolit #803: Non-existant default_project_directory path is fatal at startup (new defect) [ http://padre.perlide.org/trac/ticket/803 ]
17:29 Hyppolit svn: r9818 | szabgab++ | http://padre.perlide.org/trac/changeset/9818
17:29 Hyppolit add non-translatable hot-keys to some of the Debug menu options
17:29 Hyppolit trunk/Padre/lib/Padre/Action/
17:30 szabgab tsee, when saving the debugger configuration (breakpoints, watches, variables to display) I guess this should be saved separately for each script, right?
17:31 tsee Hmm. Should be in Padre memory, no?
17:31 tsee I wouldn't save it to disk.
17:31 szabgab why not?
17:31 Sewi Saving on disk per script would be great.
17:31 szabgab I can start now by just keeping it in the memory and save to disk later
17:32 Sewi Stop work for today, continue tomorrow, survive Padre crashs, etc.
17:32 Sewi Append a debugging file to a trac ticket
17:34 szabgab btw I think Padre::Debug should be called Padre::Logger
17:35 tsee I agree
17:37 Sewi This might not be debugger related at all, but what about replaying a Devel::Trace file (step forward/back moving the cursor to the line within the open files)?
17:41 szabgab Sewi, no idea :-)
17:41 Sewi no idea if it's debugger related or if it's a good idea? :-)
17:51 Hyppolit svn: r9819 | szabgab++ | http://padre.perlide.org/trac/changeset/9819
17:51 Hyppolit rename Padre::Debug to Padre::Logger
17:51 Hyppolit trunk/Padre/ trunk/Padre/lib/Padre/ trunk/Padre/lib/Padre/Document/ trunk/Padre/lib/Padre/Document/Perl/ trunk/Padre/lib/Padre/HelpProvider/ trunk/Padre/lib/Padre/Wx/ trunk/Padre/lib/Padre/Wx/Dialog/ trunk/Padre/lib/Padre/Wx/Menu/
17:52 szabgab it can be an interesting idea
17:55 cognominal joined #padre
18:07 Hyppolit svn: r9820 | szabgab++ | http://padre.perlide.org/trac/changeset/9820
18:07 Hyppolit fix a warning in the logger
18:07 Hyppolit trunk/Padre/lib/Padre/
18:07 Hyppolit svn: r9821 | szabgab++ | http://padre.perlide.org/trac/changeset/9821
18:07 Hyppolit replace Padre::Debug by Padre::Logger in several plugins
18:07 Hyppolit trunk/Padre-Plugin-Parrot/lib/Padre/Document/ trunk/Padre-Plugin-Parrot/lib/Padre/HelpProvider/ trunk/Padre-Plugin-Perl6/lib/Padre/Plugin/Perl6/ trunk/Padre-Plugin-Swarm/lib/Padre/Swarm/Service/ trunk/Padre-Plugin-Swarm/lib/Padre/Wx/Swarm/ trunk/Padre-Plugin-WebGUI/​lib/Padre/Document/WebGUI/ trunk/Padre-Plugin-WebGUI/lib​/Padre/Document/WebGUI/Asset/ trunk/Padre-Plugin-WebGUI/lib/Padre/Plugin/ trunk/Padre-Plugin-WebGUI
18:08 Hyppolit svn: r9822 | szabgab++ | http://padre.perlide.org/trac/changeset/9822
18:08 Hyppolit add two more scripts for testing Debug::Client
18:08 Hyppolit trunk/Debug-Client/t/eg/
18:12 Hyppolit svn: r9823 | szabgab++ | http://padre.perlide.org/trac/changeset/9823
18:12 Hyppolit fix the --trace option of dev.pl to enable the logger
18:12 Hyppolit trunk/Padre/
18:52 virtualsue joined #padre
19:41 virtualsue joined #padre
19:58 Hyppolit svn: r9824 | szabgab++ | http://padre.perlide.org/trac/changeset/9824
19:58 Hyppolit rename Padre::Wx::Debugger to Padre::Wx::Debugger::View
19:58 Hyppolit trunk/Padre/lib/Padre/Wx/ trunk/Padre/lib/Padre/Wx/Debugger/
20:03 pece2 joined #padre
20:06 Sewi_Ubuntu joined #padre
20:23 Hyppolit svn: r9825 | szabgab++ | http://padre.perlide.org/trac/changeset/9825
20:23 Hyppolit move the interface to Debug::Client to Padre::Wx::Debugger
20:23 Hyppolit trunk/Padre/lib/Padre/Action/ trunk/Padre/lib/Padre/Wx/
20:24 virtualsue joined #padre
20:40 Hyppolit svn: r9826 | szabgab++ | http://padre.perlide.org/trac/changeset/9826
20:40 Hyppolit remove debugging printouts on the console, fix crash caused by moving the code to Padre::Wx::Debugger
20:40 Hyppolit trunk/Padre/lib/Padre/ trunk/Padre/lib/Padre/Wx/
20:58 Hyppolit svn: r9827 | szabgab++ | http://padre.perlide.org/trac/changeset/9827
20:58 Hyppolit try to cleanup some repetitive code in the Debugger interface, fix a crash due to missing _T in new module
20:58 Hyppolit trunk/Padre/lib/Padre/Wx/
21:13 Hyppolit svn: r9828 | szabgab++ | http://padre.perlide.org/trac/changeset/9828
21:13 Hyppolit save breakpoints in memory and set them up before running the script
21:13 Hyppolit trunk/Padre/lib/Padre/Wx/
21:14 virtualsue joined #padre
21:19 Hyppolit svn: r9829 | szabgab++ | http://padre.perlide.org/trac/changeset/9829
21:19 Hyppolit mark the breakpoints with blue square
21:19 Hyppolit trunk/Padre/lib/Padre/ trunk/Padre/lib/Padre/Wx/
21:36 tsee szabgab, in principle, the "show contents of variable" debugger hook could use the same code that I use for the context right click menu which grabs the name of the current variable from the document.
21:37 szabgab yes, I should look that up
21:37 tsee I'll be very busy in the coming days and then I'll be on (probably internet free) vacation.
21:37 tsee But *if* I manage, I can look at it.
21:37 tsee No promises.
21:37 szabgab no :-)
21:37 tsee I'm still so excited I had to try again before going to bed.
21:38 tsee Finally Padre has something vim totally doesn't do for me.
21:38 tsee AFAIK anyway.
21:38 tsee Not that I'd entirely switch. Most of the time, I don't write Perl anyway.
21:38 szabgab basically the debugger is the part that turns an editor into an IDE I think
21:38 tsee Yes. At least a big chunk of it.
21:39 tsee Code overview stuff and projects are another.
21:39 szabgab and I was planning to add it for more than a year now
21:39 tsee VCS integration is a third.
21:39 tsee It just took somebody capable who got off his butt.
21:39 tsee Thank you for it not being me :)
21:39 szabgab I hope I'll be able to improve it in the coming 2-3 days till the release
21:40 tsee Hmm. I'd suggest you try hard to make it stable.
21:40 tsee As opposed to adding many more features.
21:40 tsee The lure is strong.
21:40 szabgab I need a basic usability and then let people play with it
21:41 szabgab I hope the recent refactoring I did did not break it
21:41 tsee "Use of uninitialized value $module in string eq at /home/tsee/perl/padre/trunk/P​adre/lib/Padre/Wx/Debugger.pm line 299."
21:41 tsee And further of those.
21:41 tsee line 145, line 150, 158.
21:42 szabgab I don't get those
21:42 szabgab I might need sample scripts
21:43 szabgab that trigger the bugs
21:43 tsee The drag-n-drop example.
21:44 szabgab share/examples/wx/41-drag-image.pl ?
21:45 szabgab or which script?
21:46 tsee 42-drag-image-no-tail.pl
21:46 tsee I was stepping through it.
21:46 tsee And printing a few variables.
21:46 tsee And trying the "show contents" button without selecting a variable.
22:13 robn joined #padre
22:42 rindolf joined #padre
23:28 awnstudio joined #padre
23:34 kent\n joined #padre

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