http://permalink.gmane.org/gmane.comp.web.mojolicious hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.web.mojolicious/1245 <pre>Hi Guys, I wanted to add depth into the &lt; at &gt;urls with seperated by pipd '|' symbol, Is it possible to pass multiple arguments to the callback routine? I also want to pass $depth to get_callback? Is that possible? Thanks. Mojo::IOLoop-&gt;recurring( 0 =&gt; sub { for ($active + 1 .. $max_conn) { # Dequeue or halt if there are no active crawlers anymore return ($active or Mojo::IOLoop-&gt;stop or $totalPagesVisited &gt; $maxPages) unless my $url = shift &lt; at &gt;urls; # Fetch non-blocking just by adding # a callback and marking as active ++$active; say "getting link: $url"; ($depth, $myLink) = split ('\|', $url); $ua-&gt;get($myLink =&gt; \&amp;get_callback); } } ); sub get_callback { my (undef, $tx) = &lt; at &gt;_; ...... } </pre> perl_Is_Best 2013-05-23T16:00:38 http://permalink.gmane.org/gmane.comp.web.mojolicious/1244 <pre>Am Donnerstag, 23. Mai 2013 10:16:04 UTC+2 schrieb koorchik: That´s fine but sometimes doesn´t help you much. A major improvement would IMHO be, if a) the rationale behind a breaking change and b) especially the new solution that replaced the deprecated feature could be documented somewhere. </pre> Heiko Jansen 2013-05-23T15:31:47 http://permalink.gmane.org/gmane.comp.web.mojolicious/1243 <pre>2013/5/23 Sam Wong &lt;sam0737&lt; at &gt;gmail.com&gt;: As for changes list it can be found in "Changes" file - https://metacpan.org/source/SRI/Mojolicious-4.03/Changes -- Viktor Turskyi http://webbylab.com http://koorchik.blogspot.com </pre> Виктор Турский 2013-05-23T08:16:04 http://permalink.gmane.org/gmane.comp.web.mojolicious/1242 <pre>- Breaking changes can be found by running your app's test suite using the new release. - Previous releases can easily be accessed via http://backpan.perl.org/authors/id/S/SR/SRI and installed directly in moments with cpanm: cpanm http://backpan.perl.org/authors/id/S/SR/SRI/Mojolicious-3.97.tar.gz - Deltas can be accessed using the github diff tool. - You may want to look into something like http://search.cpan.org/~miyagawa/carton-v0.9_9/docs/carton.pod for managing apps. On May 22, 2013, at 8:52 PM, Sam Wong &lt;sam0737&lt; at &gt;gmail.com&gt; wrote: </pre> Glen 2013-05-23T03:21:02 http://permalink.gmane.org/gmane.comp.web.mojolicious/1241 <pre>Thank you for all the hard work from all the contributors. Mojolicious is a very nice piece that completes the perl web app development puzzle, but it could be even better if deprecation could be handled better. I am an application developer and have been staying with Mojolicious since 0.98 (or is it - I don't recall the exact ver number). Over the time, two breaking changes affected me - 1) introduction of Mojolicios::Command-&gt;start_app, 2) removal of render_json. To an app dev, there are two problems with the breaking changes - a) I don't know (not even a ballpark idea) what will be broken if I upgrade b) I don't know how to fix the app May I take this chance to voice out how I think it could be done better. * Communication channel - POD please. I don't usually subscribe mailing list or IRC of a module, because it won't be possible for me to following hundreds of mailing list of modules that I am using, and very often I don't find the need to. Say - I don't think it's expected for app dev to subs</pre> Sam Wong 2013-05-23T02:52:39 http://permalink.gmane.org/gmane.comp.web.mojolicious/1240 <pre>Hi all, FYR Perl5 deprecation policy&lt;http://perldoc.perl.org/perlpolicy.html#BACKWARD-COMPATIBILITY-AND-DEPRECATION&gt; </pre> Xiao Yafeng 2013-05-22T13:00:52 http://permalink.gmane.org/gmane.comp.web.mojolicious/1239 <pre>I'm building a Mojo app that serves both HTML and JSON. I make extensive use of 'respond_to' to tailor the results back in either JSON or HTML depending on the accept headers. respond_to is working as expected, but I've noticed render_exception always serves the HTML template even when exception.json.ep is defined, and the accept header is set to application/json. Something I'm missing? </pre> Adam McLean 2013-05-21T16:55:58 http://permalink.gmane.org/gmane.comp.web.mojolicious/1238 <pre>Hi, I don't seem to find the proper alternative for $at_dom-&gt;charset('windows-1255') when parsing a dom element. Can you help me out? On Saturday, May 11, 2013 6:24:18 AM UTC+3, sri wrote: </pre> Dommy 2013-05-21T09:01:18 http://permalink.gmane.org/gmane.comp.web.mojolicious/1237 <pre>In my opinion this doesn't really have that much to do with Mojolicious deprecation policy or release schedule. Application breakage going from 3.nn to 4.0 is completely understandable. I'd challenge anyone to migrate an application from say ExtJS 3.n to 4.n, or QT etc. I've been involved in several projects where entire teams were built to handle the migration of an application through a major library version change. But I do think that there exists a very real problem with regard to plugin maintenance expectations. I wish our plugin community in general was better documented, supported, promoted and maintained. I wish that we maintained a list of 'sanctioned' plugins, known to be examples of best practice and actively maintained. Perhaps this already exists and I've overlooked it; but to me our plugin community lacks a certain credibility (perhaps just a marketing problem). Anyway, to me this seems to be the real symptom and the deprecation policy of Mojolicious isn't the right direction for the cu</pre> Wes Cravens 2013-05-20T12:34:40 http://permalink.gmane.org/gmane.comp.web.mojolicious/1236 <pre> I have banned Bernhard and myself from this list. -- sebastian </pre> sri 2013-05-20T02:17:26 http://permalink.gmane.org/gmane.comp.web.mojolicious/1235 <pre>I'm not usually one to say this but can both of you either take this to private mail or shut up? Going at it like a bunch of kids in kindergarten isn't going to do any good. On 05/20/2013 05:47 AM, Bernhard Graf wrote: </pre> Ben van Staveren 2013-05-20T00:44:42 http://permalink.gmane.org/gmane.comp.web.mojolicious/1234 <pre>Am 20.05.2013 00:13, schrieb sri: Feel free to send me a patch. Since you seem to know every mediocre Mojolicous plugin inside out, does that mean, you broke them on purpose? My impression was, that esp. you care least about that issue. Bernhard </pre> Bernhard Graf 2013-05-19T22:47:23 http://permalink.gmane.org/gmane.comp.web.mojolicious/1233 <pre> You sir have been disqualified from this discussion for depending on Mojolicious internals in your plugins. https://metacpan.org/source/GRAF/Mojolicious-Plugin-MethodOverride-0.010/lib/Mojolicious/Plugin/MethodOverride.pm#L18 I would very much appreciate it if only those that really care about the issue participate, thank you. -- sebastian </pre> sri 2013-05-19T22:13:33 http://permalink.gmane.org/gmane.comp.web.mojolicious/1232 <pre>Am 19.05.2013 21:47, schrieb Joel Berger: That is simply not true. One of my own plugins (M:P:AccessLog) broke, because method is_dynamic has been removed from Mojo::Message. If anybody would have announced that breaking change for M4, I easily could have fixed that just before the M4 release by replacing $response-&gt;is_dynamic with $response-&gt;content-&gt;is_dynamic, which runs fine on M4 /and/ earlier versions (... something, that is not possible, if I got you right). Bernhard </pre> Bernhard Graf 2013-05-19T21:52:57 http://permalink.gmane.org/gmane.comp.web.mojolicious/1231 <pre>Ok. Minor releases are often and deprecation policy already works with minor releases because changes are not so fundamental. With major releases it is much harder to keep backwards compatibility. I agree with that. So my suggestions are 1. For minor releases leave deprecation policy as is. 2. For major releases use deprecation period(with deprecation warnings) where it possible and not very hard. Often renaming/removing methods can have deprecation period. It is not so critical to remove "sub render_text { shift-&gt;render(text =&gt; &lt; at &gt;_) }" without deprecation. This will add some stability. 3. Major releases are rare and it is possible to use short(2-3 weeks) stabilization period(no upload to CPAN). A major release could be announced everywhere with a note "Please, retest your code(especially plugins on the CPAN) with the new major release - X.0. After two weeks it will be released to CPAN"(or something like that). A developer takes the latest version from Github and has a chance to fix incompatilities. Optio</pre> Виктор Турский 2013-05-19T20:05:40 http://permalink.gmane.org/gmane.comp.web.mojolicious/1230 <pre>I've just been saying essentially the same thing on IRC. I like the fast pace for Mojolicious development, but its too bad that on a breaking release plugins will break. In truth nothing can be done about that. Even if a module author is ready for the major Mojo release, they have to wait until after Mojo goes out, so there MUST be a time in which their plugin is broken. I think that the best case is that the module authors be alerted with enough time to make changes. What is being discussed on IRC is a 1 week "freeze" prior to a major release. I suggest that that be concurrent with a posting to the world, perhaps on a blog or something more broadly visible than a list post or IRC message, saying, "We expect to release Mojolicious X.0 on day Y. There will be some breaking changes which module authors ought to consider and prepare for updating their plugins, we hope that no further breaking changes will be made from the current state of the repository. We reserve the right to push this date ba</pre> Joel Berger 2013-05-19T19:47:47 http://permalink.gmane.org/gmane.comp.web.mojolicious/1229 <pre> The problem goes even deeper than that, there will always be a period in which plugins are broken. Even if we give an advance warning and plugin authors update their modules before we release Mojolicious, those plugins would be broken with older versions of Mojolicious. That's what i mean when i talk about "clean deprecation path". -- Sebastian Riedel http://twitter.com/kraih http://mojolicio.us </pre> Sebastian Riedel 2013-05-19T19:45:14 http://permalink.gmane.org/gmane.comp.web.mojolicious/1228 <pre>For me, ultimately I agree with sri; but I am concerned about plugins. It does rather stink that should someone get into Mojolicious on, say, the day 4.0 was released and then attempts to use plugin X they would understandably be frustrated when this plugin does not work. It's extremely unreasonable to expect the plugin author to update the plugin instantly upon framework update. But what policy could really resolve this? What if the plugin author doesn't keep up with the times and a month or three goes by and the plugin is still not updated? I've understood two distinct perspectives in this discussion: app developers and plugin developers. App developers need to simply not update blindly. Plugin developers? I don't know... How can plugins be helped through the update cycle? Regardless of the update cycle, however, plugins are at risk of breakage. But can they at least be assisted some how? On May 19, 2013 8:53 AM, "Marty Tennison" &lt;marty.tennison&lt; at &gt;dripdepot.com&gt; wrote: current deprecation policy. My opini</pre> Stefan Adams 2013-05-19T19:35:30 http://permalink.gmane.org/gmane.comp.web.mojolicious/1227 <pre>I'd like to throw in my opinion. Personally, I have no problem with the current deprecation policy. My opinion is, and always will be "Let the current developers decide on the best policy that works for them". There is no perfect solution that will fit everyone but one thing for sure, a stagnate project due to developer disinterest or frustration serves nobody, and there are plenty of examples of that phenomenon. On Sun, May 19, 2013 at 11:26 AM, sri &lt;kraihx&lt; at &gt;googlemail.com&gt; wrote: </pre> Marty Tennison 2013-05-19T18:53:23 http://permalink.gmane.org/gmane.comp.web.mojolicious/1226 <pre>Lets move the discussion into a different direction, which Perl project do you think has a better deprecation policy/release cycle and why? -- sebastian </pre> sri 2013-05-19T18:26:43 http://permalink.gmane.org/gmane.comp.web.mojolicious/1225 <pre> And when i say "breaking changes" i specifically mean those that can't be phased out slowly with a deprecation warning in code. That sounds awkward, pretend i said "in 3 months" for both. -- sebastian </pre> sri 2013-05-19T18:13:48 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.web.mojolicious