From toby.corkindale at strategicdata.com.au Sun Jul 11 21:36:12 2010 From: toby.corkindale at strategicdata.com.au (Toby Corkindale) Date: Mon, 12 Jul 2010 14:36:12 +1000 Subject: [Melbourne-pm] July Perlmongers meeting - Wednesday 14th In-Reply-To: <4C22C3DB.5080507@strategicdata.com.au> References: <4C22C3DB.5080507@strategicdata.com.au> Message-ID: <4C3A9BBC.5070900@strategicdata.com.au> On 24/06/10 12:32, Toby Corkindale wrote: > Hi, > The next Perlmongers meeting will be on Wednesday the 14th of July. > > I propose that we have a social meeting, and meanwhile try to gather > more talks for a tech meeting on the 11th of August. > > Do we have any suggestions for a venue for July? > > I'll propose the James Squire Brewhouse on Russell Street; we should be > able to book a big table in the dining section, even if not all of us > are eating. They have a range of nice beers and do food. No-one really objected or suggested alternatives, so let's go with this then. The next Perlmongers meeting is a social meet, and will be held this Wednesday, the 14th of July, from 6:30pm. The location will be the James Squire Brewhouse at 115-127 Russell Street, in the Melbourne CBD. The August Perlmongers meeting will be a technical meeting, and probably held at Strategic Data in Fitzroy, on the 11th of August. I'm still collecting talks for that one.. So far we have David's talk on building and deploying native win32 Perl apps using Wix. Does anyone else have a topic they would like to present? Anyone up for demonstrating Padre? Cheers, Toby From toby.corkindale at strategicdata.com.au Tue Jul 13 18:08:00 2010 From: toby.corkindale at strategicdata.com.au (Toby Corkindale) Date: Wed, 14 Jul 2010 11:08:00 +1000 Subject: [Melbourne-pm] Reminder - Melbourne.PM meeting TONIGHT Message-ID: <4C3D0DF0.5030708@strategicdata.com.au> The next Perlmongers meeting is a social meet, and will be held tonight, the 14th of July, from 6:30pm. The location will be the James Squire Brewhouse at 115-127 Russell Street, in the Melbourne CBD. From greg.george at orica.com Wed Jul 14 16:07:42 2010 From: greg.george at orica.com (greg.george at orica.com) Date: Thu, 15 Jul 2010 09:07:42 +1000 Subject: [Melbourne-pm] iPhone Apps Public Lecture - Swinburne Message-ID: http://www.swinburne.edu.au/ict/events/iphone/index.html for anyone interested Regards, Greg George IT Shared Services Phone: +613-9091-2492 3/100 Victoria Prd, Melbourne Please consider the environment before printing this e-mail *********************************************************************************************************************************************************************************************** Please consider the environment before printing this e-mail. This message is intended solely for the individual(s) and entity(s) addressed. It is confidential and may contain legally privileged information. The use, copying or distribution of this message or any information it contains, by anyone other than the addressee, is prohibited. If you have received this message in error, please notify postmaster at orica.com. The mailbox address from which this message has been sent is for business mail only. Mail sent to it may be subject to security scanning and delivery on non-business messages sent to this address may not occur. Thank you. *********************************************************************************************************************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From toby.corkindale at strategicdata.com.au Thu Jul 15 22:47:38 2010 From: toby.corkindale at strategicdata.com.au (Toby Corkindale) Date: Fri, 16 Jul 2010 15:47:38 +1000 Subject: [Melbourne-pm] Things to do at meetings Message-ID: <4C3FF27A.20404@strategicdata.com.au> Hi all, I'd like to query the community to find out what things would make tech and social meetings better for you. As such, perhaps we could discuss a few points. 1) Social meetings We don't seem to have enough new tech talks to run a tech meeting every month, and I personally like the model adopted by some other PM groups, where they alternate between tech and social meetings every other month. What do you think of this? Do you like social meetings? It would appear not, since the turn-out is usually much smaller than the tech ones. Is there something that could be done to improve them though? For instance, could we hold them at a restaurant instead of a pub? What about activities that aren't even related to drinking at all? (Perish the thought!) Such as, BBQ/picnics in a park on a weekend, kareoke, golf, hang-gliding.. 2) More than just talks at tech meetings Our tech talks have mostly been of the mini-lecture format (although there was also the Perl 5.10 bug triage session that I can think of). Are there other activities you'd like to have at them? Suggestions I can think of are: * Have a group software project to develop. * Coding-oriented games, along the lines of CoreWars, Robot Battle, etc. (if any such things exist for Perl?) Cheers, Toby From alec.clews at gmail.com Fri Jul 16 03:42:47 2010 From: alec.clews at gmail.com (Alec Clews) Date: Fri, 16 Jul 2010 20:42:47 +1000 Subject: [Melbourne-pm] Things to do at meetings In-Reply-To: <4C3FF27A.20404@strategicdata.com.au> References: <4C3FF27A.20404@strategicdata.com.au> Message-ID: <4C4037A7.5090604@gmail.com> On 16/07/10 15:47, Toby Corkindale wrote: > > I'd like to query the community to find out what things would make tech > and social meetings better for you. > > 1) Social meetings > > We don't seem to have enough new tech talks to run a tech meeting every > month, and I personally like the model adopted by some other PM groups, > where they alternate between tech and social meetings every other month. > What do you think of this? I would suggest social very 3-4 months? > 2) More than just talks at tech meetings > > Our tech talks have mostly been of the mini-lecture format (although > there was also the Perl 5.10 bug triage session that I can think of). > > Are there other activities you'd like to have at them? Suggestions I can > think of are: > * Have a group software project to develop. > * Coding-oriented games, along the lines of CoreWars, Robot Battle, > etc. (if any such things exist for Perl?) How about a "master" class and workshop as well. A three month cycle would be possible. i.e. a social night, a talk night and a practical night (projects, workshop, etc) Also perhaps we can extend talks to include things other development topics, with a with a Perl twist (e.g. TDD, Tools for Perl dev, architecture setup,...) -- that will depend on volunteers. -- Alec Clews Personal Melbourne, Australia. Jabber: alecclews at jabber.org.au PGPKey ID: 0x9BBBFC7C Blog http://alecthegeek.wordpress.com/ From melbourne-pm at mjch.net Tue Jul 20 18:05:23 2010 From: melbourne-pm at mjch.net (Malcolm Herbert) Date: Wed, 21 Jul 2010 11:05:23 +1000 Subject: [Melbourne-pm] good Mason tutorials? Message-ID: <1279674323.14839.1385882269@webmail.messagingengine.com> I'm trying to get my head around using Mason ... Firstly, I guess - is it still receiving much use? I know it's part of RT, but that's about the only Mason application I know of ... I have the Mason book but wondered whether there were any other step-by-step tutorials on Mason that people would recommend ... I can find a number with Google but they're either early 2000 era or pretty sketchy or both ... regards, Malcolm -- Malcolm Herbert This brain intentionally mjch at mjch.net left blank From alfiejohn at gmail.com Tue Jul 20 18:11:58 2010 From: alfiejohn at gmail.com (Alfie John) Date: Wed, 21 Jul 2010 11:11:58 +1000 Subject: [Melbourne-pm] good Mason tutorials? In-Reply-To: <1279674323.14839.1385882269@webmail.messagingengine.com> References: <1279674323.14839.1385882269@webmail.messagingengine.com> Message-ID: I meant to hit reply all :( -- 8< -- Hi Malcolm, On Wed, Jul 21, 2010 at 11:05 AM, Malcolm Herbert wrote: > Firstly, I guess - is it still receiving much use? I know it's part of > RT, but that's about the only Mason application I know of ... > Yes. Mason is pretty cool. Apache 2 can be a bit frustrating at times though :) There a number of companies in Melbourne that I know of that use Mason. If you're wondering if it's still in much use, check out their active mailing list. > I have the Mason book but wondered whether there were any other > step-by-step tutorials on Mason that people would recommend ... I can > find a number with Google but they're either early 2000 era or pretty > sketchy or both ... > The Mason book is pretty good and straight forward. Once you have that under your belt, you should be able to do anything in Mason. Also, if you're interested in seeing any code, here's something from a while back I created: http://rental-property.co.nz/source/ Have fun. Alfie -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at unisolve.com.au Tue Jul 20 18:25:21 2010 From: simon at unisolve.com.au (Simon Taylor) Date: Wed, 21 Jul 2010 11:25:21 +1000 Subject: [Melbourne-pm] good Mason tutorials? In-Reply-To: <1279674323.14839.1385882269@webmail.messagingengine.com> References: <1279674323.14839.1385882269@webmail.messagingengine.com> Message-ID: <4C464C81.5090002@unisolve.com.au> Hi Malcolm, > I'm trying to get my head around using Mason ... > > Firstly, I guess - is it still receiving much use? I know it's part of > RT, but that's about the only Mason application I know of ... > We use Mason a lot. It's dependable and scales really well. Cheers, Simon From jarich at perltraining.com.au Wed Jul 21 00:45:00 2010 From: jarich at perltraining.com.au (Jacinta Richardson) Date: Wed, 21 Jul 2010 17:45:00 +1000 Subject: [Melbourne-pm] good Mason tutorials? In-Reply-To: <1279674323.14839.1385882269@webmail.messagingengine.com> References: <1279674323.14839.1385882269@webmail.messagingengine.com> Message-ID: <4C46A57C.9080301@perltraining.com.au> Malcolm Herbert wrote: > I have the Mason book but wondered whether there were any other > step-by-step tutorials on Mason that people would recommend ... I can > find a number with Google but they're either early 2000 era or pretty > sketchy or both ... We cover HTML::Mason in our Web Development course. You can grab the course notes from our website. We haven't given the course much love for a couple of years though, so don't assume its all best practice. All the best, J From pat at patspam.com Wed Jul 21 07:46:18 2010 From: pat at patspam.com (Patrick Donelan) Date: Wed, 21 Jul 2010 10:46:18 -0400 Subject: [Melbourne-pm] good Mason tutorials? In-Reply-To: References: <1279674323.14839.1385882269@webmail.messagingengine.com> Message-ID: > > Yes. Mason is pretty cool. Apache 2 can be a bit frustrating at times > though :) > HTML::Mason::PSGIHandler to the rescue! Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfiejohn at gmail.com Wed Jul 21 14:59:54 2010 From: alfiejohn at gmail.com (Alfie John) Date: Thu, 22 Jul 2010 07:59:54 +1000 Subject: [Melbourne-pm] good Mason tutorials? In-Reply-To: References: <1279674323.14839.1385882269@webmail.messagingengine.com> Message-ID: Hey Patrick, On Thu, Jul 22, 2010 at 12:46 AM, Patrick Donelan wrote: > Yes. Mason is pretty cool. Apache 2 can be a bit frustrating at times >> though :) >> > > HTML::Mason::PSGIHandlerto the rescue! > Nice. The purist in me has always wanted to get rid of Apache and go down the pure Perl route. But everything I saw was too verbose for what I wanted. I've never heard of Plack or PSGI. Thanks for the link. BTW: I also saw your blog... Plack apps written in Perl, written in Javascript? There's got to be an Xzibit meme in there somewhere :) Alfie -------------- next part -------------- An HTML attachment was scrubbed... URL: From toby.corkindale at strategicdata.com.au Wed Jul 21 19:47:07 2010 From: toby.corkindale at strategicdata.com.au (Toby Corkindale) Date: Thu, 22 Jul 2010 12:47:07 +1000 Subject: [Melbourne-pm] Who manages the OSDC website and wiki? Message-ID: <4C47B12B.6000401@strategicdata.com.au> I notice the OSDC wiki is a bit spamarific at the moment: http://www.osdcon.org/wiki/ Not just the obvious links, but I note that various pages have links inserted mid-sentence too.. Quite clever in places, look at the Model Rules page for instance. Is there someone with more wiki experience than me who can sort those out automatically? Also, the main website, www.osdc.com.au, is rather out of date, apparently still being stuck in a point of time when the 2009 event was still way in the future.. I thought I'd heard rumours that 2010 was partially organised? Cheers, Toby From scottp at dd.com.au Wed Jul 21 20:20:52 2010 From: scottp at dd.com.au (Scott Penrose) Date: Thu, 22 Jul 2010 13:20:52 +1000 Subject: [Melbourne-pm] Who manages the OSDC website and wiki? In-Reply-To: <4C47B12B.6000401@strategicdata.com.au> References: <4C47B12B.6000401@strategicdata.com.au> Message-ID: <17649F6E-9A2F-485B-928E-10BB3CC90251@dd.com.au> Yeah I noticed that 2 days ago. Bum... and they have to enter Captcha too We are moving it to a new site, this may get me moving faster :-) Scooter On 22/07/2010, at 12:47 PM, Toby Corkindale wrote: > I notice the OSDC wiki is a bit spamarific at the moment: > http://www.osdcon.org/wiki/ > Not just the obvious links, but I note that various pages have links inserted mid-sentence too.. Quite clever in places, look at the Model Rules page for instance. > > Is there someone with more wiki experience than me who can sort those out automatically? > > Also, the main website, www.osdc.com.au, is rather out of date, apparently still being stuck in a point of time when the 2009 event was still way in the future.. I thought I'd heard rumours that 2010 was partially organised? > > Cheers, > Toby From mathew.blair.robertson at gmail.com Fri Jul 23 00:34:32 2010 From: mathew.blair.robertson at gmail.com (Mathew Robertson) Date: Fri, 23 Jul 2010 17:34:32 +1000 Subject: [Melbourne-pm] Bug in "B" Message-ID: Hi PM's, I have found a bug in B->walksymtable... Someone here is more likely to get a patch submitted than I ever will... :) walksymtable assumes that the object being walked, is derived from a hash, when in fact object can be blessed from anything. I have provided an example implementation which provides support for blessed arrays, but am unsure how to walk other blessed types... Anyone car to take up the challenge of support other blessed types and/or submitting a bug report. cheers, Mathew Robertson -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.pl Type: application/octet-stream Size: 2764 bytes Desc: not available URL: From alfiejohn at gmail.com Fri Jul 23 18:29:23 2010 From: alfiejohn at gmail.com (Alfie John) Date: Sat, 24 Jul 2010 11:29:23 +1000 Subject: [Melbourne-pm] Bug in "B" In-Reply-To: References: Message-ID: Hey Mathew, I have found a bug in B->walksymtable... Someone here is more likely to get > a patch submitted than I ever will... :) > Submit a patch if you have found a bug. Perl is a meritocracy, not a cabal. I have provided an example implementation which provides support for blessed > arrays, but am unsure how to walk other blessed types... > Your code looks correct, but I think that's not the purpose of walksymtable(). I was under the impression that *all* symbol tables were hashes. I've never seen array based symbol tables let alone scalars. I think if you want more info, discuss it on perl5-porters since they are the maintainers of the core modules. Alfie -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathew.blair.robertson at gmail.com Sat Jul 24 20:23:50 2010 From: mathew.blair.robertson at gmail.com (Mathew Robertson) Date: Sun, 25 Jul 2010 13:23:50 +1000 Subject: [Melbourne-pm] Bug in "B" In-Reply-To: References: Message-ID: > > > I have found a bug in B->walksymtable... Someone here is more likely to >> get a patch submitted than I ever will... :) >> > > Submit a patch if you have found a bug. Perl is a meritocracy, not a cabal. > Indeed. I have had good and bad experiences submitting patches to various free-software projects... so I'm a little weary of making an effort that get punished. Separate to that, the main issue is that I first need to subscribe to some list just to submit something, and have done so previously.... I just figured someone here might already be subscribed to an appropriate list. > > I have provided an example implementation which provides support for >> blessed arrays, but am unsure how to walk other blessed types... >> > > Your code looks correct, but I think that's not the purpose of > walksymtable(). I was under the impression that *all* symbol tables were > hashes. I've never seen array based symbol tables let alone scalars. > That is an interesting comment. Indeed a function name with "walksymtable" would imply some sort of key-value list, which is part of a symbol-table of an object. However, the perldoc for the function provides an example of its use and its implementation implies that to not be the case. ie: walksymtable takes a reference to something that has a symbol-table, such as a package or as implied by 'symref' (a reference to a symbol...) some random definition of whatever a symbol is... say a blessed object. But then it may just be my interpretation of the wording. So as you say, it may not be a bug in the sense that, as it does what it implements. I think if you want more info, discuss it on perl5-porters since they are > the maintainers of the core modules. > Which I'm unlikely to find time for that... Aside: For those interested, I came across this quirk as I was using a module I developed a few years ago... I call it "B::Symbols"... Due to the various implementations of inheritance, autoload, etc. it can be frustrating trying to find out what functions can be applied to a given object; I developed something that would return a list of all possible symbols on the object; once you have at least the function name, you can then look up the docs for that function. Using it just recently, I came across a case where it would die -> I eventually figured out that it couldn't handle non-hash based objects. Of course I dont really consider this module to be CPAN worthy just yet... sometimes it reports methods that dont exist, or methods are missing from the list. If anyone is interested, I can post it here. Also, its possible that something better exists, but I just dont know about it. thanks for the reply, Mathew > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfiejohn at gmail.com Sat Jul 24 23:05:01 2010 From: alfiejohn at gmail.com (Alfie John) Date: Sun, 25 Jul 2010 16:05:01 +1000 Subject: [Melbourne-pm] Bug in "B" In-Reply-To: References: Message-ID: Hey, On Sun, Jul 25, 2010 at 1:23 PM, Mathew Robertson < mathew.blair.robertson at gmail.com> wrote: > >> I have found a bug in B->walksymtable... Someone here is more likely to >>> get a patch submitted than I ever will... :) >>> >> >> Submit a patch if you have found a bug. Perl is a meritocracy, not a >> cabal. >> > > Indeed. I have had good and bad experiences submitting patches to various > free-software projects... so I'm a little weary of making an effort that get > punished. > Same here. However each time I've had a patch rejected, upon further reflection it did seem I assumed the wrong thing. In one case, it was a documentation bug which caused me to assume the wrong thing. The documentation was patched instead of the buggy code :) Separate to that, the main issue is that I first need to subscribe to some > list just to submit something, and have done so previously.... I just > figured someone here might already be subscribed to an appropriate list. > I think by doing so allows reasoning of the patch to ferment and hopefully lead to a discussion. Otherwise, little discussion and quick commits could lead to bad decisions such as backslashes being a nameseperator ;p I have provided an example implementation which provides support for >>> blessed arrays, but am unsure how to walk other blessed types... >>> >> >> Your code looks correct, but I think that's not the purpose of >> walksymtable(). I was under the impression that *all* symbol tables were >> hashes. I've never seen array based symbol tables let alone scalars. >> > > That is an interesting comment. Indeed a function name with "walksymtable" > would imply some sort of key-value list, which is part of a symbol-table of > an object. > I think that's where you understanding could be incorrect. I think when it talks about symbol tables, it doesn't talk about the generic idea of symbol tables. It's actually talking about Perl's definitive symbol table. In other words, the first param needs to be of the form "\%PACKAGE::". If you still want to use walksymtable() with objects such as array-based objects, inside-out objects etc, you could do something like the following: my $arrayob = ArrayOb->new(); walksymtable( \%{ (ref $arrayob ) . "::" }, sub { foreach ( @_ ) { print "\t", $_->NAME,"\n" } }, sub { 0 }, ref( $arrayob) ); Alfie -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarich at perltraining.com.au Mon Jul 26 22:59:41 2010 From: jarich at perltraining.com.au (jarich at perltraining.com.au) Date: Tue, 27 Jul 2010 15:59:41 +1000 (EST) Subject: [Melbourne-pm] OSDC 2010 Call for Presentations! Message-ID: <20100727055942.9DD0EA9EA0@teddybear.perltraining.com.au> In 2010, the Open Source Developers' Conference (OSDC) is back in Melbourne! Running Wednesday 24th - Friday 26th November 2010, OSDC is a great way to meet your peers, share your knowledge, and improve your skills. Be part of our 7th year of this fantastic conference, run by open source developers for open source developers. Submit a proposal on open source languages, technologies, tools and projects. http://2010.osdc.com.au/call-for-proposals Key dates: Call for Proposals Closes 23 August 2010 Proposal Acceptance 6 September 2010 OSDC 2010 Conference 24th to 26th November 2010 Please feel free to pass this on to any other people or groups you think might be interested in submitting a paper! Hope to see you there! OSDC 2010 committee From toby.corkindale at strategicdata.com.au Mon Jul 26 23:09:37 2010 From: toby.corkindale at strategicdata.com.au (Toby Corkindale) Date: Tue, 27 Jul 2010 16:09:37 +1000 Subject: [Melbourne-pm] OSDC 2010 Call for Presentations! In-Reply-To: <20100727055942.9DD0EA9EA0@teddybear.perltraining.com.au> References: <20100727055942.9DD0EA9EA0@teddybear.perltraining.com.au> Message-ID: <4C4E7821.7000604@strategicdata.com.au> May I suggest that the www.osdc.com.au website is updated? It still says "2009 is coming!" and goes on to talk about the 2009 conference in Brisbane. On 27/07/10 15:59, jarich at perltraining.com.au wrote: > In 2010, the Open Source Developers' Conference (OSDC) is back in > Melbourne! Running Wednesday 24th - Friday 26th November 2010, OSDC is a > great way to meet your peers, share your knowledge, and improve your > skills. > > Be part of our 7th year of this fantastic conference, run by open source > developers for open source developers. Submit a proposal on open source > languages, technologies, tools and projects. > http://2010.osdc.com.au/call-for-proposals > > Key dates: > > Call for Proposals Closes 23 August 2010 > Proposal Acceptance 6 September 2010 > OSDC 2010 Conference 24th to 26th November 2010 > > Please feel free to pass this on to any other people or groups > you think might be interested in submitting a paper! > > Hope to see you there! > > OSDC 2010 committee > _______________________________________________ > Melbourne-pm mailing list > Melbourne-pm at pm.org > http://mail.pm.org/mailman/listinfo/melbourne-pm -- Strategic Data Pty Ltd Ph: 03 9340 9000 From mathew.blair.robertson at gmail.com Tue Jul 27 17:39:06 2010 From: mathew.blair.robertson at gmail.com (Mathew Robertson) Date: Wed, 28 Jul 2010 10:39:06 +1000 Subject: [Melbourne-pm] Data::Dumper enhancement Message-ID: Hi PM, For years I have used Data::Dumper to help me debug my code, usually with the syntax: print Dumper(blah); It occurred to me that I could save some keystrokes... so went looking at Dumper.pm and found that 'wantarray' is being used to determine the calling context for list vs. scalar. But it isn't being used to detect void context... Would saving 6 keystrokes would be a useful enhancement? cheers, Mathew Robertson -------------- next part -------------- An HTML attachment was scrubbed... URL: From toby.corkindale at strategicdata.com.au Tue Jul 27 18:14:40 2010 From: toby.corkindale at strategicdata.com.au (Toby Corkindale) Date: Wed, 28 Jul 2010 11:14:40 +1000 Subject: [Melbourne-pm] Data::Dumper enhancement In-Reply-To: References: Message-ID: <4C4F8480.4070504@strategicdata.com.au> On 28/07/10 10:39, Mathew Robertson wrote: > Hi PM, > > For years I have used Data::Dumper to help me debug my code, usually > with the syntax: > > print Dumper(blah); > > It occurred to me that I could save some keystrokes... so went looking > at Dumper.pm and found that 'wantarray' is being used to determine the > calling context for list vs. scalar. But it isn't being used to detect > void context... > > Would saving 6 keystrokes would be a useful enhancement? I'm not really a fan of that sort of behaviour. Functions should be consistent in what they do, not have side-effects (like i/o) and should not import all sorts of functionality. -T From david.tulloh at AirservicesAustralia.com Tue Jul 27 18:15:11 2010 From: david.tulloh at AirservicesAustralia.com (Tulloh, David) Date: Wed, 28 Jul 2010 11:15:11 +1000 Subject: [Melbourne-pm] Data::Dumper enhancement In-Reply-To: References: Message-ID: For a while now I've been using Data::Dump as a replacement to Data::Dumper. The output is better, it adapts the output style depending on the amount of data. For example small arrays are printed horizontally, long arrays vertically. It also has a function dd, which displays the provided variable. So your full example becomes: dd blah; Thats ten less key strokes. David ________________________________ From: melbourne-pm-bounces+david.tulloh=airservicesaustralia.com at pm.org [mailto:melbourne-pm-bounces+david.tulloh=airservicesaustralia.com at pm.or g] On Behalf Of Mathew Robertson Sent: 28 July 2010 10:39 AM To: Melbourne Perl Mongers Subject: [Melbourne-pm] Data::Dumper enhancement Hi PM, For years I have used Data::Dumper to help me debug my code, usually with the syntax: print Dumper(blah); It occurred to me that I could save some keystrokes... so went looking at Dumper.pm and found that 'wantarray' is being used to determine the calling context for list vs. scalar. But it isn't being used to detect void context... Would saving 6 keystrokes would be a useful enhancement? cheers, Mathew Robertson -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfiejohn at gmail.com Tue Jul 27 18:24:53 2010 From: alfiejohn at gmail.com (Alfie John) Date: Wed, 28 Jul 2010 11:24:53 +1000 Subject: [Melbourne-pm] Data::Dumper enhancement In-Reply-To: References: Message-ID: Hey Mathew, I think if you want to change the behaviour of something that most people aren't going to agree but it still bugs you, maybe consider adding an expansion key binding to your editor e.g. iab in VIM. Alfie On Wed, Jul 28, 2010 at 11:15 AM, Tulloh, David < david.tulloh at airservicesaustralia.com> wrote: > For a while now I've been using Data::Dump as a replacement to > Data::Dumper. > > The output is better, it adapts the output style depending on the amount of > data. For example small arrays are printed horizontally, long arrays > vertically. > > It also has a function dd, which displays the provided variable. > So your full example becomes: dd blah; Thats ten less key strokes. > > > David > ------------------------------ > *From:* melbourne-pm-bounces+david.tulloh=airservicesaustralia.com at pm.org[mailto: > melbourne-pm-bounces+david.tulloh = > airservicesaustralia.com at pm.org] *On Behalf Of *Mathew Robertson > *Sent:* 28 July 2010 10:39 AM > *To:* Melbourne Perl Mongers > *Subject:* [Melbourne-pm] Data::Dumper enhancement > > Hi PM, > > For years I have used Data::Dumper to help me debug my code, usually with > the syntax: > > print Dumper(blah); > > It occurred to me that I could save some keystrokes... so went looking at > Dumper.pm and found that 'wantarray' is being used to determine the calling > context for list vs. scalar. But it isn't being used to detect void > context... > > Would saving 6 keystrokes would be a useful enhancement? > > cheers, > Mathew Robertson > > _______________________________________________ > Melbourne-pm mailing list > Melbourne-pm at pm.org > http://mail.pm.org/mailman/listinfo/melbourne-pm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.warring at gmail.com Tue Jul 27 18:37:29 2010 From: david.warring at gmail.com (David Warring) Date: Wed, 28 Jul 2010 11:37:29 +1000 Subject: [Melbourne-pm] Data::Dumper enhancement In-Reply-To: References: Message-ID: Mathew, I notice that Data::Dumper already has a Dumpp function that prints to STDOUT: use Data::Dumper; Data::Dumper::Dumpp([{apples => 10, oranges => 20}]); Would it suffice to make this exportable? - David On Wed, Jul 28, 2010 at 10:39 AM, Mathew Robertson < mathew.blair.robertson at gmail.com> wrote: > Hi PM, > > For years I have used Data::Dumper to help me debug my code, usually with > the syntax: > > print Dumper(blah); > > It occurred to me that I could save some keystrokes... so went looking at > Dumper.pm and found that 'wantarray' is being used to determine the calling > context for list vs. scalar. But it isn't being used to detect void > context... > > Would saving 6 keystrokes would be a useful enhancement? > > cheers, > Mathew Robertson > > _______________________________________________ > Melbourne-pm mailing list > Melbourne-pm at pm.org > http://mail.pm.org/mailman/listinfo/melbourne-pm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From toby.corkindale at strategicdata.com.au Tue Jul 27 20:27:56 2010 From: toby.corkindale at strategicdata.com.au (Toby Corkindale) Date: Wed, 28 Jul 2010 13:27:56 +1000 Subject: [Melbourne-pm] Closures and scope warnings Message-ID: <4C4FA3BC.5040108@strategicdata.com.au> Hmm, here's something that caught me out.. probably because it's not great practice. (But it is a common theme in using DBIx::Class transactions) my $thing; sub { my $thing = 'wibble' }->(); There is no warning emitted about the second "my $thing" overriding the scope of the former one, even though it is.. (Tested on perl 5.10.1 only, sorry) A warning would have been nice; it caught me out today when I did it by accident. From jarich at perltraining.com.au Tue Jul 27 20:30:17 2010 From: jarich at perltraining.com.au (Jacinta Richardson) Date: Wed, 28 Jul 2010 13:30:17 +1000 Subject: [Melbourne-pm] OSDC 2010 Call for Presentations! In-Reply-To: <4C4E7821.7000604@strategicdata.com.au> References: <20100727055942.9DD0EA9EA0@teddybear.perltraining.com.au> <4C4E7821.7000604@strategicdata.com.au> Message-ID: <4C4FA449.4000305@perltraining.com.au> Toby Corkindale wrote: > May I suggest that the www.osdc.com.au website is updated? > It still says "2009 is coming!" and goes on to talk about the 2009 > conference in Brisbane. Believe me, that was annoying both Ben, who is currently doing almost all of the organising singled-handed - volunteers appreciated, and myself. Petitions to the website owner hadn't gained access to change the main site, but fortunately we were able to work around this yesterday and you'll notice that both http://www.osdc.com.au/ and http://2010.osdc.com.au/ look a lot different now. A proper submissions system is only a day or so away, but submissions by emails are coming in just fine. :) All the best, Jacinta From tjc at wintrmute.net Tue Jul 27 20:32:11 2010 From: tjc at wintrmute.net (Toby Wintermute) Date: Wed, 28 Jul 2010 13:32:11 +1000 Subject: [Melbourne-pm] OSDC 2010 Call for Presentations! In-Reply-To: <4C4FA449.4000305@perltraining.com.au> References: <20100727055942.9DD0EA9EA0@teddybear.perltraining.com.au> <4C4E7821.7000604@strategicdata.com.au> <4C4FA449.4000305@perltraining.com.au> Message-ID: On 28 July 2010 13:30, Jacinta Richardson wrote: > Toby Corkindale wrote: >> >> May I suggest that the www.osdc.com.au website is updated? >> It still says "2009 is coming!" and goes on to talk about the 2009 >> conference in Brisbane. > > Believe me, that was annoying both Ben, who is currently doing almost all of > the organising singled-handed - volunteers appreciated, and myself. > ?Petitions to the website owner hadn't gained access to change the main > site, but fortunately we were able to work around this yesterday and you'll > notice that both http://www.osdc.com.au/ and http://2010.osdc.com.au/ look a > lot different now. Ah, excellent! Glad to hear it's sorted out now. From jarich at perltraining.com.au Tue Jul 27 20:34:26 2010 From: jarich at perltraining.com.au (Jacinta Richardson) Date: Wed, 28 Jul 2010 13:34:26 +1000 Subject: [Melbourne-pm] Closures and scope warnings In-Reply-To: <4C4FA3BC.5040108@strategicdata.com.au> References: <4C4FA3BC.5040108@strategicdata.com.au> Message-ID: <4C4FA542.5020708@perltraining.com.au> Toby Corkindale wrote: > Hmm, > here's something that caught me out.. probably because it's not great > practice. (But it is a common theme in using DBIx::Class transactions) > > my $thing; > sub { my $thing = 'wibble' }->(); This isn't just constrained to this circumstance, and is probably normally considered a feature. Consider: my $name = "Jacinta"; print_name($name); #### much later sub name { my $name = shift; print "$name\n"; return; } Would you *really* want every subroutine which creates variables which shadow top-level variables to warn about such? I don't think Perl distinguishes between your case and mine. J From toby.corkindale at strategicdata.com.au Tue Jul 27 20:48:34 2010 From: toby.corkindale at strategicdata.com.au (Toby Corkindale) Date: Wed, 28 Jul 2010 13:48:34 +1000 Subject: [Melbourne-pm] Closures and scope warnings In-Reply-To: <4C4FA542.5020708@perltraining.com.au> References: <4C4FA3BC.5040108@strategicdata.com.au> <4C4FA542.5020708@perltraining.com.au> Message-ID: <4C4FA892.4020202@strategicdata.com.au> On 28/07/10 13:34, Jacinta Richardson wrote: > Toby Corkindale wrote: >> Hmm, >> here's something that caught me out.. probably because it's not great >> practice. (But it is a common theme in using DBIx::Class transactions) >> >> my $thing; >> sub { my $thing = 'wibble' }->(); > > This isn't just constrained to this circumstance, and is probably > normally considered a feature. Consider: > > my $name = "Jacinta"; > > print_name($name); > > #### much later > > sub name { > my $name = shift; > > print "$name\n"; > return; > } > > > Would you *really* want every subroutine which creates variables which > shadow top-level variables to warn about such? I don't think Perl > distinguishes between your case and mine. No, but when the anonymous sub is used like a sort of single-use closure, like this? sub do_something { my $schema; #isa DBIx::Class::Schema my $user = $schema->resultset('Users')->find(1); my $new_role = "something"; my $old_role; $schema->txn_do(sub { $user->name("flooble"); $old_role = $user->role; # <-- accessing data outside $user->add_role($new_role); # <-- and again $user->update; }); } That's the "best practice" way to do transactions, I believe, but it does use a closure in a way that it wasn't really intended, I think? From scottp at dd.com.au Tue Jul 27 20:58:35 2010 From: scottp at dd.com.au (Scott Penrose) Date: Tue, 27 Jul 2010 22:58:35 -0500 (CDT) Subject: [Melbourne-pm] Closures and scope warnings In-Reply-To: <4C4FA542.5020708@perltraining.com.au> Message-ID: <1178032168.108695.1280289515586.JavaMail.root@mail-4.01.com> ----- Original Message ----- > Toby Corkindale wrote: > > Hmm, here's something that caught me out.. probably because it's not > > great practice. (But it is a common theme in using DBIx::Class > > transactions) > > > > my $thing; > > sub { my $thing = 'wibble' }->(); > > This isn't just constrained to this circumstance, and is probably > normally > considered a feature. Consider: > > my $name = "Jacinta"; > > print_name($name); > > #### much later > > sub name { > my $name = shift; > > print "$name\n"; > return; } > > > Would you *really* want every subroutine which creates variables which > shadow top-level variables to warn about such? I don't think Perl > distinguishes between your case and mine. I agree with Toby, it should. If I do: my $name = "Blah"; while (<>) { my $name = $_; print $name . "\n"; } It produces a warning, why is a sub block treated differently to a while loop. I know that it is, but from a warning perspective, if I overload a "global" (in Jacinta's example) variable with one in a sub, then yes, it should warn. Scott -- http://scott.dd.com.au/ scottp at dd.com.au From damian at conway.org Tue Jul 27 21:01:09 2010 From: damian at conway.org (Damian Conway) Date: Wed, 28 Jul 2010 14:01:09 +1000 Subject: [Melbourne-pm] Closures and scope warnings In-Reply-To: <4C4FA542.5020708@perltraining.com.au> References: <4C4FA3BC.5040108@strategicdata.com.au> <4C4FA542.5020708@perltraining.com.au> Message-ID: Jacinta observed: > Would you *really* want every subroutine which creates variables which > shadow top-level variables to warn about such? ?I don't think Perl > distinguishes between your case and mine. It doesn't even distinguish this case: my $name = "Jacinta"; { my $name = 'shift'; print "$name\n"; } The whole point of lexical scope is that variables declared inside a block hide identically named variables declared outside the block. It doesn't matter if the block is "raw" (as above) or is the body of a named subroutine (like Jacinta's example), or the body of an unnamed sub (like Toby's example). Of course, it is annoying if you're using an upscope variable within a closure and you accidentally shadow it with a lexical declaration. I use closures all the time, so I have a couple of techniques that make that mistake very unlikely. If the upscope variable is being used only as a value, I generally capitalize its name. For example: sub generate_prompter { my ($PROMPT) = @_; return sub { print $PROMPT; return readline; } } The capitals help me remember to treat it as a constant, and stop it from shadowing any in-scope lexicals (because they'll have lowercase names, like variables normally do). If the upscope variable is being modified downscope, I generally name it $outer_whatever or $shared_whatever. For example: my $shared_verbose; sub set_verbose { my $verbose = shift // 1; $shared_verbose = $verbose; } sub get_verbose { return $shared_verbose; } The longer name helps prevent name collisions with in-scope lexicals, which generally get shorter names. Thus, I'd write Toby's example something like: sub do_something { my $schema; #isa DBIx::Class::Schema my $user = $schema->resultset('Users')->find(1); my $NEW_ROLE = "something"; my $outer_old_role; $schema->txn_do(sub { $user->name("flooble"); $outer_old_role = $user->role; # <-- accessing data outside $user->add_role($NEW_ROLE); # <-- and again $user->update; }); } It's not fool-proof, but this approach does reduce the chance of name collisions significantly. Of course, there's no reason to adopt my particular naming scheme, but having *some* consistent naming scheme for these situations really is a good idea. Damian From scottp at dd.com.au Tue Jul 27 21:13:42 2010 From: scottp at dd.com.au (Scott Penrose) Date: Tue, 27 Jul 2010 23:13:42 -0500 (CDT) Subject: [Melbourne-pm] Closures and scope warnings In-Reply-To: Message-ID: <312509452.108977.1280290422602.JavaMail.root@mail-4.01.com> Dooh... Damian is right, I didn't actually test my code, and have made assumptions... probably for years :-) So... the rule is that warnings only happen within the same level of block? Scott ----- Original Message ----- > Jacinta observed: > > > Would you *really* want every subroutine which creates variables > > which shadow top-level variables to warn about such? I don't think > > Perl distinguishes between your case and mine. > > It doesn't even distinguish this case: > > my $name = "Jacinta"; > > { > my $name = 'shift'; > > print "$name\n"; > } > > The whole point of lexical scope is that variables declared inside a > block hide identically named variables declared outside the block. It > doesn't matter if the block is "raw" (as above) or is the body of a > named subroutine (like Jacinta's example), or the body of an unnamed > sub (like Toby's example). > > Of course, it is annoying if you're using an upscope variable within a > closure and you accidentally shadow it with a lexical declaration. I > use closures all the time, so I have a couple of techniques that make > that mistake very unlikely. > > If the upscope variable is being used only as a value, I generally > capitalize its name. For example: > > sub generate_prompter { > my ($PROMPT) = @_; > > return sub { > print $PROMPT; > return readline; > } } > > The capitals help me remember to treat it as a constant, and stop > it from shadowing any in-scope lexicals (because they'll have > lowercase names, like variables normally do). > > If the upscope variable is being modified downscope, I generally > name it $outer_whatever or $shared_whatever. For example: > > my $shared_verbose; > > sub set_verbose { > my $verbose = shift // 1; > > $shared_verbose = $verbose; > } > > sub get_verbose { > return $shared_verbose; > } > > The longer name helps prevent name collisions with in-scope lexicals, > which generally get shorter names. > > Thus, I'd write Toby's example something like: > > sub do_something { > my $schema; #isa DBIx::Class::Schema > my $user = $schema->resultset('Users')->find(1); > my $NEW_ROLE = "something"; > my $outer_old_role; > > $schema->txn_do(sub { > $user->name("flooble"); $outer_old_role = $user->role; # <-- accessing > data outside > $user->add_role($NEW_ROLE); # <-- and again > $user->update; }); > } > > It's not fool-proof, but this approach does reduce the chance of name > collisions significantly. Of course, there's no reason to adopt my > particular naming scheme, but having *some* consistent naming scheme > for these situations really is a good idea. > > Damian > _______________________________________________ Melbourne-pm mailing > list Melbourne-pm at pm.org > http://mail.pm.org/mailman/listinfo/melbourne-pm -- http://scott.dd.com.au/ scottp at dd.com.au From damian at conway.org Tue Jul 27 21:19:59 2010 From: damian at conway.org (Damian Conway) Date: Wed, 28 Jul 2010 14:19:59 +1000 Subject: [Melbourne-pm] Closures and scope warnings In-Reply-To: <312509452.108977.1280290422602.JavaMail.root@mail-4.01.com> References: <312509452.108977.1280290422602.JavaMail.root@mail-4.01.com> Message-ID: Scott asked: > So... the rule is that warnings only happen within the same level of block? Yes. The second declaration of a variable name at a given block level generates a warning. Two declarations in different blocks never has (and never will). Damian From alfiejohn at gmail.com Tue Jul 27 21:40:56 2010 From: alfiejohn at gmail.com (Alfie John) Date: Wed, 28 Jul 2010 14:40:56 +1000 Subject: [Melbourne-pm] Closures and scope warnings In-Reply-To: References: <312509452.108977.1280290422602.JavaMail.root@mail-4.01.com> Message-ID: On Wed, Jul 28, 2010 at 2:19 PM, Damian Conway wrote: > Scott asked: > > > So... the rule is that warnings only happen within the same level of > block? > > Yes. The second declaration of a variable name at a given block level > generates > a warning. Two declarations in different blocks never has (and never will). > It's funny because 'my' will warn, but 'local' is fine: perl -we 'use strict;our $f = 10; {my $f = 20; my $f = 30; print $f,"\n"} print $f,"\n"'; perl -we 'use strict;our $f = 10; {local $f = 20; local $f = 30; print $f,"\n"} print $f,"\n"'; The fact that 'local' doesn't warn makes it seem inconsistent to me. But it could be just the way how I think 'local' works ;p Alfie -------------- next part -------------- An HTML attachment was scrubbed... URL: From damian at conway.org Tue Jul 27 22:58:28 2010 From: damian at conway.org (Damian Conway) Date: Wed, 28 Jul 2010 15:58:28 +1000 Subject: [Melbourne-pm] Closures and scope warnings In-Reply-To: References: <312509452.108977.1280290422602.JavaMail.root@mail-4.01.com> Message-ID: Alfie mused: > It's funny because 'my' will warn, but 'local' is fine: That's because 'my' creates two separate variables that happen to have the same name; whereas 'local' creates two separate snapshots of what is intrinsically the same variable. Yeah, I know. It *is* mainly a *philosophical* difference. ;-) But in practical terms, repeatedly (and temporarily) modifying a particular package variable in a single scope is a fairly common technique (e.g. for input parsing tricks that require messing about with $/). In contrast, declaring two identically named lexicals in the same scope is almost always a thinko. Damian From hamish at hamishcarpenter.com Tue Jul 27 23:01:00 2010 From: hamish at hamishcarpenter.com (Hamish Carpenter) Date: Wed, 28 Jul 2010 16:01:00 +1000 Subject: [Melbourne-pm] Closures and scope warnings In-Reply-To: References: <312509452.108977.1280290422602.JavaMail.root@mail-4.01.com> Message-ID: I know its not compile time, but perlcritic can warn on these cases. See http://search.cpan.org/perldoc?Perl::Critic::Policy::Variables::ProhibitReusedNames Using Damian's exmaple of: my $name = "Jacinta"; { my $name = 'shift'; print "$name\n"; } Results in: Reused variable name in lexical scope: $name at line 6, column 8. Invent unique variable names. (Severity: 3) On Wed, Jul 28, 2010 at 2:40 PM, Alfie John wrote: > On Wed, Jul 28, 2010 at 2:19 PM, Damian Conway wrote: >> >> Scott asked: >> >> > So... the rule is that warnings only happen within the same level of >> > block? >> >> Yes. The second declaration of a variable name at a given block level >> generates >> a warning. Two declarations in different blocks never has (and never >> will). > > It's funny because 'my' will warn, but 'local' is fine: > > ? perl -we 'use strict;our $f = 10; {my $f = 20; my $f = 30; print $f,"\n"} > print $f,"\n"'; > ? perl -we 'use strict;our $f = 10; {local $f = 20; local $f = 30; print > $f,"\n"} print $f,"\n"'; > > The fact that 'local' doesn't warn makes it seem inconsistent to me. But it > could be just the way how I think 'local' works ;p > > Alfie > > _______________________________________________ > Melbourne-pm mailing list > Melbourne-pm at pm.org > http://mail.pm.org/mailman/listinfo/melbourne-pm > From toby.corkindale at strategicdata.com.au Wed Jul 28 01:01:27 2010 From: toby.corkindale at strategicdata.com.au (Toby Corkindale) Date: Wed, 28 Jul 2010 18:01:27 +1000 Subject: [Melbourne-pm] Closures and scope warnings In-Reply-To: References: <4C4FA3BC.5040108@strategicdata.com.au> <4C4FA542.5020708@perltraining.com.au> Message-ID: <4C4FE3D7.5050300@strategicdata.com.au> On 28/07/10 14:01, Damian Conway wrote: > Jacinta observed: > >> Would you *really* want every subroutine which creates variables which >> shadow top-level variables to warn about such? I don't think Perl >> distinguishes between your case and mine. > > It doesn't even distinguish this case: > > my $name = "Jacinta"; > > { > my $name = 'shift'; > > print "$name\n"; > } > > The whole point of lexical scope is that variables declared inside a > block hide identically named variables declared outside the block. It > doesn't matter if the block is "raw" (as above) or is the body of a > named subroutine (like Jacinta's example), or the body of an unnamed sub > (like Toby's example). Thinking about my example some more (the transaction block for DBIx::Class), I'm coming around to the opinion that it must be bad practice to alter external variables. The transaction could fail, which will rollback the changes to DB-tied objects, but not the external variables. Consider this somewhat contrived example: my $person = get_person_from_db(); my $new_salary = get_new_salary_from_api(); my $weekly_pay; #undef eval { $schema->txn_do(sub { $person->salary($new_salary); my $weekly_pay = $person->salary / 52; $external_payments_api->set_weekly_pay($person->id, $weekly_pay); $person->update; # Fails in DB for some reason }); }; if ($@) { say "Whoops, something went wrong." } say "Your salary is " . $person->salary . " with weekly pay of $weekly_pay." The problem being that the external factors weren't rolled back on an error, so the external payments API would still have been updated with the new salary here. Obviously, bad practice and you're an idiot if you do this.. but it makes me wonder if the whole thing of modifying external non-db stuff during the transaction is bad. (Another problem being if, say, the external_payments_api interface hangs for minutes, locking up the db for that user's record in the meantime.) From daniel at rimspace.net Wed Jul 28 21:43:18 2010 From: daniel at rimspace.net (Daniel Pittman) Date: Thu, 29 Jul 2010 14:43:18 +1000 Subject: [Melbourne-pm] Closures and scope warnings In-Reply-To: <4C4FA892.4020202@strategicdata.com.au> (Toby Corkindale's message of "Wed, 28 Jul 2010 13:48:34 +1000") References: <4C4FA3BC.5040108@strategicdata.com.au> <4C4FA542.5020708@perltraining.com.au> <4C4FA892.4020202@strategicdata.com.au> Message-ID: <871vam7va1.fsf@rimspace.net> Toby Corkindale writes: [...] > That's the "best practice" way to do transactions, I believe, but it does use > a closure in a way that it wasn't really intended, I think? I have no opinion on the wider discussion, but damn, what are they teaching in those schools these days? This is exactly what closures are for, up and up. :) Daniel -- ? Daniel Pittman ? daniel at rimspace.net ? +61 401 155 707 ? made with 100 percent post-consumer electrons From toby.corkindale at strategicdata.com.au Wed Jul 28 22:11:16 2010 From: toby.corkindale at strategicdata.com.au (Toby Corkindale) Date: Thu, 29 Jul 2010 15:11:16 +1000 Subject: [Melbourne-pm] Closures and scope warnings In-Reply-To: <871vam7va1.fsf@rimspace.net> References: <4C4FA3BC.5040108@strategicdata.com.au> <4C4FA542.5020708@perltraining.com.au> <4C4FA892.4020202@strategicdata.com.au> <871vam7va1.fsf@rimspace.net> Message-ID: <4C510D74.1060105@strategicdata.com.au> On 29/07/10 14:43, Daniel Pittman wrote: > Toby Corkindale writes: > > [...] > >> That's the "best practice" way to do transactions, I believe, but it does use >> a closure in a way that it wasn't really intended, I think? > > I have no opinion on the wider discussion, but damn, what are they teaching in > those schools these days? Search me, when I was at school they were still teaching ADA83 and COBOL! (I might even have the textbooks gathering dust in an attic somewhere) I don't think either language supported Closures? > This is exactly what closures are for, up and up. :) Hurrah! Good to know then :) They do strange things to my understanding and concepts of scoping though. Imagine if you called a recursive function, passing a closure around! Mmm, tastes obfuscatory! :) (But yeah, anything can be abused) In totally unrelated news: http://steve-yegge.blogspot.com/2010/07/wikileaks-to-leak-5000-open-source-java.html From daniel at rimspace.net Wed Jul 28 22:41:00 2010 From: daniel at rimspace.net (Daniel Pittman) Date: Thu, 29 Jul 2010 15:41:00 +1000 Subject: [Melbourne-pm] Closures and scope warnings In-Reply-To: <4C510D74.1060105@strategicdata.com.au> (Toby Corkindale's message of "Thu, 29 Jul 2010 15:11:16 +1000") References: <4C4FA3BC.5040108@strategicdata.com.au> <4C4FA542.5020708@perltraining.com.au> <4C4FA892.4020202@strategicdata.com.au> <871vam7va1.fsf@rimspace.net> <4C510D74.1060105@strategicdata.com.au> Message-ID: <87lj8u6e1f.fsf@rimspace.net> Toby Corkindale writes: > On 29/07/10 14:43, Daniel Pittman wrote: >> Toby Corkindale writes: >> >> [...] >> >>> That's the "best practice" way to do transactions, I believe, but it does use >>> a closure in a way that it wasn't really intended, I think? >> >> I have no opinion on the wider discussion, but damn, what are they teaching in >> those schools these days? > > Search me, when I was at school they were still teaching ADA83 and COBOL! (I > might even have the textbooks gathering dust in an attic somewhere) > I don't think either language supported Closures? > > >> This is exactly what closures are for, up and up. :) > > Hurrah! Good to know then :) Their original design was, basically, that you attach the code you write to a GUI button, not a database transaction, but that the ability to capture variables was (one of) the mechanisms recommended for external communication. > They do strange things to my understanding and concepts of scoping > though. Imagine if you called a recursive function, passing a closure > around! Mmm, tastes obfuscatory! :) Hah. Yeah, they make it necessary to regard the language as a graph of objects tied together by their references to each other, instantiated from the linear structure described in the source code.[1] For bonus fun, play around with implementations of the Y combinator: http://en.wikipedia.org/wiki/Y_combinator "Although fixed point combinators are the standard solution for allowing a function not bound to an identifier to call itself, some languages like Javascript provide a syntactical construct which allows anonymous functions to refer to themselves." Daniel Footnotes: [1] ...or, at least, to have a mental model that is some approximation of that reality, even if you express it differently. -- ? Daniel Pittman ? daniel at rimspace.net ? +61 401 155 707 ? made with 100 percent post-consumer electrons From melbourne.pm at joshheumann.com Thu Jul 29 16:57:42 2010 From: melbourne.pm at joshheumann.com (Josh Heumann) Date: Thu, 29 Jul 2010 16:57:42 -0700 Subject: [Melbourne-pm] Data::Dumper enhancement In-Reply-To: References: Message-ID: <20100729235742.GC13884@joshheumann.com> > I think if you want to change the behaviour of something that most people > aren't going to agree but it still bugs you, maybe consider adding an > expansion key binding to your editor e.g. iab in VIM. FWIW, I've been using these for a while in my .vimrc: " data::dumper abbr udd use Data::Dumper; abbr ddu die Dumper abbr pdu print Dumper abbr wdu warn Dumper abbr uddu use Data::Dumper;die Dumper abbr updu use Data::Dumper;print Dumper abbr uwdu use Data::Dumper;warn Dumper J