Re: [Mojolicious] Is it possible to make Mojolicious::Plugin::DefaultHelpers::redirect_to method act same as nginx proxy_pass module?

[Stefan Adams]

Like this?

get '/:x' => sub ($c) {
  $c->redirect_to('http://172.22.0.6:80/') if $c->param('x') eq 'foo';
  $c->redirect_to('http://172.22.0.7:80/') if $c->param('x') eq 'bar';
};

On Mon, Feb 7, 2022 at 9:27 AM Pavel Serikov 
wrote:

> I need to redirect requests to particular IP address depending on
> requested url.
>
> E.g.
> example.com/foo -> 172.22.0.6:80
> example.com/bar -> 172.22.0.7:80
> etc.
>
> Is it possible with Mojolicious out-of-the-box?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/1d5193e0-c1a0-4989-bdc4-282245d7626an%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFQZbmLdLsX5597v%2BhCe5K7XPXHtREOiu7mKTHukAFmDqQ%40mail.gmail.com.

Re: [Mojolicious] Async/await in Mojolicious Full App

[Stefan Adams]

*form *and *json *are examples of "content generators
<https://mojolicious.org/perldoc/Mojo/UserAgent/Transactor#GENERATORS>".
You can think of them as request macros.  *form
<https://mojolicious.org/perldoc/Mojo/UserAgent/Transactor#form>*, for
example, "generates query string, application/x-www-form-urlencoded or
multipart/form-data content" while *json*, for example, "generates
application/json content with Mojo::JSON."

So, true, changing the content generator as I recommended changes how the
request is sent to the server.  But you can also create your own custom
generators if you need to, such as an application/x-www-form-urlencoded
content expecting a JSON value for a form parameter as yours seems to
expect.

Indeed, without knowing anything about your API, I recommended a change for
how you send your request, completely blindly and contrary to what the API
endpoint may be expecting.  I assumed the API endpoint would handle a JSON
request, but instead it seems to want a JSON string as the value to the
*periods* parameter of the form.

On Sat, Jun 6, 2020 at 5:50 AM Jeyaraj Durairaj 
wrote:

> Hi Stefan,
>
> Thanks for the appreciation and the ideas.
>
> I will surely do the following change in my code.
>
> changing to return *$tx->result->json*; from  return
> from_json($tx->result->body);
>
> However, following change has been tricky to me.
>
> changing to  *json* => { periods => *$c->session('cx_current_quarter')*
>  },  from  form => { periods => encode_json([ 
> $c->session('cx_current_quarter')
> ]) },
>
>  I, per se, tried *json* => { periods =>
> *$c->session('cx_current_quarter')* } at the outset. It did not work.
>
> The reason I found is the following:
>
> "json =>" works for the API call without "Authorization Header"
> my $tx = await $ua->post_p('http://' . $c->config->{API_IP} .
> '/api/token/refresh/' => json => { refresh => $refresh_token });
>
> only "form =>" works for the API call with Authorization Header"
> $tx = await $ua->post_p(
> 'http://' . $c->config->{API_IP} .
> '/api-app/analytics/summary/',
> { Authorization => 'Bearer ' . $access_token },
> *form *=> { periods => *$c->session('cx_current_quarter')* },
> );
>
> The difference between json and form in this context was intentional or
> accidental. More comments on this will be appreciated!
>
> Thanks.
> -- Jeyaraj
>
>
>
> On Saturday, 6 June 2020 02:55:04 UTC+5:30, Stefan Adams wrote:
>>
>> Great job pushing your application forward with Async/Await!  Looking at
>> your snippet, here's one small change you can probably make using the json()
>> method from Mojo::Message
>> <https://mojolicious.org/perldoc/Mojo/Message#json>:
>>
>> $app->helper(summary_data => async sub ($c, $access_token) {
>> my $ua = Mojo::UserAgent->new;
>>
>> my $tx = await $ua->post_p(
>> 'http://' . $c->config->{API_IP} .
>> '/api-app/analytics/summary/',
>> { Authorization => 'Bearer ' . $access_token },
>> *json* => { periods => *$c->session('cx_current_quarter')*
>> },
>> );
>> if ($tx->result->is_success) {
>> return *$tx->result->json*;
>> }
>> $c->flash(message_type => 'warning');
>> $c->flash(message => 'Could not get summary data');
>> return $c->redirect_to('cx-summary', status => 403);
>> });
>>
>>
>>
>> On Thu, Jun 4, 2020 at 2:31 AM Jeyaraj Durairaj 
>> wrote:
>>
>>> Hi,
>>>
>>> It works for *helpers* as well with the following declaration.
>>>
>>> $app->helper(summary_data => async sub ($c, $access_token) {
>>> my $ua = Mojo::UserAgent->new;
>>>
>>> my $tx = await $ua->post_p(
>>> 'http://' . $c->config->{API_IP} .
>>> '/api-app/analytics/summary/',
>>> { Authorization => 'Bearer ' . $access_token },
>>> form => { periods => encode_json([
>>> $c->session('cx_current_quarter') ]) },
>>> );
>>> if ($tx->result->is_success) {
>>> return from_json($tx->result->body);
>>> }
>>> $c->flash(message_type => 'warning');
>>> $c->flash(message => 'Could not get summary data');
>>> return $c->redirect_to('cx-summary', statu

Re: [Mojolicious] Async/await in Mojolicious Full App

[Stefan Adams]

Great job pushing your application forward with Async/Await!  Looking at
your snippet, here's one small change you can probably make using the json()
method from Mojo::Message
:

$app->helper(summary_data => async sub ($c, $access_token) {
my $ua = Mojo::UserAgent->new;

my $tx = await $ua->post_p(
'http://' . $c->config->{API_IP} .
'/api-app/analytics/summary/',
{ Authorization => 'Bearer ' . $access_token },
*json* => { periods => *$c->session('cx_current_quarter')* },
);
if ($tx->result->is_success) {
return *$tx->result->json*;
}
$c->flash(message_type => 'warning');
$c->flash(message => 'Could not get summary data');
return $c->redirect_to('cx-summary', status => 403);
});



On Thu, Jun 4, 2020 at 2:31 AM Jeyaraj Durairaj 
wrote:

> Hi,
>
> It works for *helpers* as well with the following declaration.
>
> $app->helper(summary_data => async sub ($c, $access_token) {
> my $ua = Mojo::UserAgent->new;
>
> my $tx = await $ua->post_p(
> 'http://' . $c->config->{API_IP} .
> '/api-app/analytics/summary/',
> { Authorization => 'Bearer ' . $access_token },
> form => { periods => encode_json([
> $c->session('cx_current_quarter') ]) },
> );
> if ($tx->result->is_success) {
> return from_json($tx->result->body);
> }
> $c->flash(message_type => 'warning');
> $c->flash(message => 'Could not get summary data');
> return $c->redirect_to('cx-summary', status => 403);
> });
>
>
>
>
> -- Jeyaraj
>
> On Thursday, 4 June 2020 12:06:01 UTC+5:30, Jeyaraj Durairaj wrote:
>>
>> Hi,
>>
>> Eureka! Eureka! It works!.
>>
>> The solution I found (because of my error) is that I uninstalled
>> Mojo::AsyncAwait and installed Future::AsyncAwait.
>> It just works!
>>
>> By June end, my business intelligence application will be live to serve
>> 100+ users with insights and analytics.
>>
>> (To apply icing on the cake, I have plugged in Moose also in to model
>> layer for my application)
>>
>> As Glen Hinkle said, it is really really a fun to work in Mojolicious. I
>> love Hypnotoad.
>>
>> BTW, I am doing a private project as well to help a home designer to
>> launch a web site for their small firm. Guess! what framework I am gonna
>> use.. *Mojolicious.*
>>
>> Thanks to Mojo group and special thanks to SRI as well.
>>
>> -- Jeyaraj
>>
>>
>>
>> On Thursday, 28 May 2020 14:15:04 UTC+5:30, Jeyaraj Durairaj wrote:
>>>
>>> any luck on the solutions?
>>>
>>> -- Jeyaraj
>>>
>>> On Thursday, 28 May 2020 00:10:48 UTC+5:30, Jeyaraj Durairaj wrote:

 However, the below code perfectly work for me outside Mojolicious App.


 use Modern::Perl;
 use Mojo::Base -strict, -signatures;
 use Mojo::UserAgent;
 use Mojo::Promise;
 use Mojo::IOLoop;
 use Mojo::Util 'trim';
 use Mojo::AsyncAwait;
 use LWP::UserAgent;
 use JSON;


 my $ua = Mojo::UserAgent->new;
 my $result = $ua->post('http://localhost:8000/api/token/' => json => {
 username => 'username', password => 'mypassword' })
 ->result
 ->json;
 my $access_token = $result->{access};
 my $refresh_token = $result->{refresh};
 print "Access Token: " . $result->{access}, "\n";
 print "Refresh Token: " . $result->{refresh}, "\n\n";


 $ua = Mojo::UserAgent->new;
 $result = $ua->post('http://' . 'localhost:8000' .
 '/api/token/refresh/' => json => { refresh => $refresh_token })
 ->result
 ->json;


 my $agent = Mojo::UserAgent->new;
 async post_user_p => sub ($url) {
 say "\n\n", $url;
 my $tx = await $agent->post_p(
 $url,
 {
 Authorization => 'Bearer ' . $result->{access},
 },
 form => {"username" => "username"},

 );
 return trim from_json($tx->result->body)->{first_name};
 };

 async main => sub (@urls) {
 my @promises = map { post_user_p($_) } @urls;
 my @names = await Mojo::Promise->all(@promises);
 say for map { $_->[0] } @names;
 };

 my @urls = (qw(
 http://localhost:8000/api-converge/auth/user/
 ));

 main(@urls)->wait;




 On Wednesday, 27 May 2020 23:41:27 UTC+5:30, Jeyaraj Durairaj wrote:
>
> I tried generating an example app and copied pasted the code segment
> you posted here and then tried.
>
> "Action not found!" error is shown.
>
> Should I reinstall Perl again and then try?
> Will it work under morbo or works only on Hypnotoad?
> I am using Windows for my development, wherein morbo is the only
> server I can test.
> Or can I test it on daemon mode and try>
> Please 

Re: [Mojolicious] Re: curl works, Mojo::UserAgent doesn't

[Stefan Adams]

On Thu, May 14, 2020 at 7:52 AM 'Michael Lackhoff' via Mojolicious <
mojolicious@googlegroups.com> wrote:

> When I change the sequence of the form parameters in curl, it fails in the
> same way. So I guess the sequence is important and my question now is:
>   Is there a way to pass the form parameters with fixed sequence in M::U
> (the form-hash of course has a random order)? Perhaps as an array?
>

Good question.  Probably what you want then is to override the built-in "
form "
generator.  You can either override (by simply redefining it), or you
can create
your own generator

and use it.

$ua->transactor->add_generator(fritz => sub {
  my ($t, $tx, $args) = @_;
  my ($sid, $pwd, $config) = @$args;
  my $sorted_parts = [...];
  $tx->req->content->parts($sorted_parts);
});
$ua->post('http://fritz.box/cgi-bin/firmwarecfg' => fritz => [$SID,
$BAKPWD, undef]);

You could use a hash instead of an array for your fritz args if you wanted
to, and still pull out the pieces you want to assemble the array as
desired.  It's very flexible.

But since you're currently using the "form" generator and learning a good
deal about it and have determined a solution using the form generator, you
might want to copy the form generator into your own fritz generator and
then do the differences you need to (as you wished).  Or you might be able
to simplify it and just do the content->parts as you alluded to.
TMTOWTDI!  :D

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFRSawHXv92ScBL8nc2U_dWVFWwD5KnLqwjCvtKdX8eaPg%40mail.gmail.com.

Re: [Mojolicious] curl works, Mojo::UserAgent doesn't

[Stefan Adams]

I'm certain you'll be able to accomplish this with M::UA. Can you share
what the HTML error produced is?

Can you share the output that you are comparing that you are noticing is so
similar between curl and M::UA? You're using -v for curl. Also set the
MOJO_CLIENT_DEBUG env variable to 1.

See how it works comparing curl to:

   $ env MOJO_CLIENT_DEBUG=1 mojo get -v -M POST -f sid=$SID -f
ImportExportPassword=$BAKPWD -f ConfigExport= http
://fritz.box/cgi-bin/firmwarecfg 

On Wed, May 13, 2020, 4:56 PM 'Michael Lackhoff' via Mojolicious <
mojolicious@googlegroups.com> wrote:

> I had quite a bit of success recently using Mojo::UserAgent so I tried to
> replace a curl command to do a backup of my Fritz.box router with M::U.
>
> Here is the curl command:
> curl -s -k -o $OUT --form sid=$SID --form ImportExportPassword=$BAKPWD \
> --form ConfigExport= http://fritz.box/cgi-bin/firmwarecfg
>
> It should be equivalent to this M::U request:
>
> my $tx = $ua->build_tx(
> POST => 'http://fritz.box/cgi-bin/firmwarecfg' =>
> {
> 'Accept'   => '*/*',
> 'Content-Type' => 'multipart/form-data',
> } => form => {
> sid  => $SID,
> ImportExportPassword => $BAKPWD,
> ConfigExport => '',
> }
> );
>
> # for debugging:
> print $tx->req->to_string;
>
> $tx = $ua->start($tx);
> $tx->res->save_to($OUT);
>
> As far as I can tell both the headers and the POST body is very much the
> same (except the boundary value to separate the form fields) but to my
> surprise the curl command works ($OUT is the backup file) but with the M::U
> version $OUT consists of some HTML output indicating an error.
>
> If I could see a difference I could try to better adjust my script but as
> I said, they look very much the same (I compared it with the -v and
> --trace-ascii output of curl), so I run out of ideas what could trigger the
> differnt response of my Fritz.box.
> Any ideas? At the moment I just solve it by using the curl command with
> "system" but I would prefer a Perl-only solution and what is even more
> important to me: I want to understand what is going on here.
>
> -Michael
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/14df452c-e7a4-4b7c-90a2-9e1f5e15becc%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFR1F7fqH3%3DFJCMftHuwH1rEKwyPZ%2BO0g7d%3DJcRaWYqDtw%40mail.gmail.com.

Re: [Mojolicious] Re: Testing internal method

[Stefan Adams]

I think Scott and Glen are both pointing out that your method in your
controller class that is not associated with a route ("filter") is not a
method of your controller, but instead in the "model" portion of MVC.  It
might help you to move that code outside of the controller class, and then
it'll make much more sense to test it normally with Test::More instead of
Test::Mojo.

# lib/App/Controller/This.pm
package App::Controller::This;
use Mojo::Base 'Mojolicious::Controller';
sub list {
  my $self = shift;
  my $model = App::Model->new;
  my $value = $self->req->json('/value');
  $self->render(json => {value => $model->filter(@$value)});
}

# lib/App/Model.pm
package App::Model;
use Mojo::Base -base;
sub filter {
  my $self = shift;
  my $final;
  /something/ and push @$final, $_ for @_;
  return $final;
}

And then you can test your filter method normally:

# t/basic.t
use Test::More;
use Test::Mojo;

# Test the controller / action and the use of any models
my $t = Test::Mojo->new('App');
$t->get_ok('/list' => json => {value => ['abc', 'def something ghi', 'jkl',
'mno something pqr']})
   ->status_is(200)
   ->json_is('/value', ['def something ghi', 'mno something pqr']);

# Test just the model
my $model = App::Model->new;
isa_ok $model, 'App::Model';
is_deeply $model->filter('abc', 'def something ghi', 'jkl', 'mno something
pqr'), ['def something ghi', 'mno something pqr'];

On Mon, Apr 27, 2020 at 10:46 PM Glen  wrote:

> He's implying that you wouldn't test this internal method with Test::Mojo; 
> Test::Mojo
> is for testing endpoints.
>
> If you want to test a specific method that is not an endpoint, load the
> module manually and test it with Test::More.
>
> On Apr 27, 2020, 11:32 PM -0400, Alberto Mijares ,
> wrote:
>
>
>
> On Mon, Apr 27, 2020, 7:09 PM Scott Wiersdorf 
> wrote:
>
>> Test::Mojo can help you test your views and controllers, as well as your
>> internal helpers:
>>
>>
>> https://metacpan.org/pod/distribution/Mojolicious/lib/Mojolicious/Guides/Testing.pod#Testing-application-helpers
>>
>
> Thank you Scott.
>
> I did read the documentation before writing this email and saw what you
> are pointing out. The thing is: it's not clear enough for me.
>
> Given the example in my original post, could you give me a more detailed
> explanation? I don't know how to trigger this specific method.
>
> Thanks in advance for your help.
>
> Alberto Mijares
>
>
>> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/CAGZBXN9VBvBFZdkmpaJOPHFJ5V5h98GdqmsqjH%2B7wN6bRNpAuQ%40mail.gmail.com
> 
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/985dbe91-4202-406e-9b28-dd44922933a7%40Spark
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFSRKsEpxnRvmP1MJ9mHpQVZq9SqhUUiywOS3zuROj5nDQ%40mail.gmail.com.

Re: [Mojolicious] Mojolicious::Plugin::Config and Test::Mojo

[Stefan Adams]

This worked very well, thanks again!!

On Tue, Apr 21, 2020 at 11:23 AM Stefan Adams  wrote:

> Very interesting approach to addressing the issue, thank you for sharing!
>
> On Tue, Apr 21, 2020 at 10:38 AM Илья  wrote:
>
>> I do it that way (pretty ugly, i know), but agree, it's annoying and I'll
>> be much happier if Mojolicious::Plugin::Config will do deep merge
>>
>> my $t = Test::Mojo->new('App');
>>
>> my $config = $t->app->config;
>>
>> ... do something with config;
>>
>> undef $t;
>>
>> $t = Test::Mojo->new('App', $config);
>>
>> ... do tests
>> 21.04.2020 17:37, Stefan Adams пишет:
>>
>> Test::Mojo allows setting the config at initialization, but the way
>> Mojolicious::Plugin::Config works, that doesn't allow the programmed
>> defaults to get picked up, which means that it is necessary to define a
>> complete configuration during testing.  Is that more desirable than
>> allowing the defaults to get picked up during testing?
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Mojolicious" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mojolicious+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFQzm63SW_9a0xDH_AkhQXaVBB3T-WRa77PaUgac2Q-6Pg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFQzm63SW_9a0xDH_AkhQXaVBB3T-WRa77PaUgac2Q-6Pg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Mojolicious" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mojolicious+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/mojolicious/3ba96f41-4a6e-c55c-907c-75bf0fcafdc6%40gmail.com
>> <https://groups.google.com/d/msgid/mojolicious/3ba96f41-4a6e-c55c-907c-75bf0fcafdc6%40gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFS8CRnfAV-y6eGipS5%3DrJ1U%3DyX3QDJ%2BfXZ_HzUcTBxxcA%40mail.gmail.com.

Re: [Mojolicious] Mojolicious::Plugin::Config and Test::Mojo

[Stefan Adams]

Very interesting approach to addressing the issue, thank you for sharing!

On Tue, Apr 21, 2020 at 10:38 AM Илья  wrote:

> I do it that way (pretty ugly, i know), but agree, it's annoying and I'll
> be much happier if Mojolicious::Plugin::Config will do deep merge
>
> my $t = Test::Mojo->new('App');
>
> my $config = $t->app->config;
>
> ... do something with config;
>
> undef $t;
>
> $t = Test::Mojo->new('App', $config);
>
> ... do tests
> 21.04.2020 17:37, Stefan Adams пишет:
>
> Test::Mojo allows setting the config at initialization, but the way
> Mojolicious::Plugin::Config works, that doesn't allow the programmed
> defaults to get picked up, which means that it is necessary to define a
> complete configuration during testing.  Is that more desirable than
> allowing the defaults to get picked up during testing?
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFQzm63SW_9a0xDH_AkhQXaVBB3T-WRa77PaUgac2Q-6Pg%40mail.gmail.com
> <https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFQzm63SW_9a0xDH_AkhQXaVBB3T-WRa77PaUgac2Q-6Pg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/3ba96f41-4a6e-c55c-907c-75bf0fcafdc6%40gmail.com
> <https://groups.google.com/d/msgid/mojolicious/3ba96f41-4a6e-c55c-907c-75bf0fcafdc6%40gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFRUzacNqx4V%2BNRkO-KT_GUQpFgHXrfXm%2BD-LX4WyKiayg%40mail.gmail.com.

[Mojolicious] Mojolicious::Plugin::Config and Test::Mojo

[Stefan Adams]

Test::Mojo allows setting the config at initialization, but the way
Mojolicious::Plugin::Config works, that doesn't allow the programmed
defaults to get picked up, which means that it is necessary to define a
complete configuration during testing.  Is that more desirable than
allowing the defaults to get picked up during testing?

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFQzm63SW_9a0xDH_AkhQXaVBB3T-WRa77PaUgac2Q-6Pg%40mail.gmail.com.

[Mojolicious] Mojo::Reactor

[Stefan Adams]

There's a current PR for addressing an issue regarding Mojo::Reactor. I
feel like I have a good understanding of all the parts of Mojolicious,
except Mojo::Reactor. I simply do not understand it at all. My confusion is
increased by the similarity with Mojo::IOLoop. Much of the docs make use of
IOLoop modules but I can't think of an example that uses Reactor.

Can anyone provide some insight into this module, what it's for, and how
and why it's different from IOLoop?

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFQPo67qOjjr7xuWSeTb%2BC8axQUVEqiHWg3_ryBE6Q8TQg%40mail.gmail.com.

Re: [Mojolicious] Re: $ ->has_error validation method in Mojolicious higher than 8.33 version

[Stefan Adams]

The conversation in the PR 
might provide some insight to Sebastian's pointer.  The change
 was made in 8.35.

On Sun, Apr 12, 2020 at 7:55 AM Ivan Kolisnyk  wrote:

> This is the code I use in my project:
>
> In helper:
> $app->helper(_validation => sub { my($c, $required_fields) = @_;
> my $v = $c->validation;
> foreach my $item($required_fields
> ->@*){
> $v->required($item);
> }
> return $v;
>  });
>
> and in controller:
> my $v = $app->_validation($ref_required_fields);
> if( $v->has_error ) { sub{ ... } }
>
> This code works correctly in Mojolicious versions lower than 8.34. You can
> see how it works at https://dev.mojoblog.me/authentication
>
>
> неділя, 12 квітня 2020 р. 14:57:55 UTC+3 користувач Sebastian Riedel
> написав:
>>
>> I have installed last version of Mojolicious and I found that the $
>>> ->has_error validation method was working with an error.
>>> When I send data form with empty field, which must be required full, I
>>> get empty value of $v->has_error. This method worked correctly in previous
>>> version of Mojolicious (8.28 and 8.33) I used.
>>> Please explain how to fix this bug.
>>>
>>
>> Your description is very vague, so i can only guess. But you probably
>> want to use the not_empty filter on the affected field.
>>
>> https://mojolicious.org/perldoc/Mojolicious/Validator#not_empty
>>
>> --
>> sebastian
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/2514dc71-e198-4277-8d2a-a170f943dca1%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFSbta9LcrCKZ_cmqsfX8YkVPSu4KfYDEVkzr_38xUz%2Bmw%40mail.gmail.com.

Re: [Mojolicious] $c->log

[Stefan Adams]

Ah excellent -- very clear explanation, thank you.  Do you have any
suggestions, or is there absolutely no way to do this without passing the
object to each method call on the model object?

On Thu, Apr 9, 2020 at 7:55 PM Dan Book  wrote:

> Oh I see, setting it in the model attribute. No, that won't work in an
> asynchronous application, because two requests may share a model object.
>
> -Dan
>
> On Thu, Apr 9, 2020 at 8:55 PM Dan Book  wrote:
>
>> Yes...? That is passing $c->log each time the helper is called, which is
>> what was suggested.
>>
>> -Dan
>>
>> On Thu, Apr 9, 2020 at 7:43 PM Stefan Adams  wrote:
>>
>>> Hmm...  But isn't this below including the context of the request ID for
>>> each request?
>>>
>>> $self->helper(model => sub {$model->log(shift->log)});
>>>
>>>
>>> Each request will have a different context.
>>>
>>> Using apachebench to concurrently send requests to the preforking
>>> application, we get this:
>>>
>>> $ perl script/my_app prefork & ab -n 100 -c 100 http://localhost:3000/
>>> [2020-04-09 23:28:01.39904] [12961] [debug] [3457c2a0] GET "/"
>>> [2020-04-09 23:28:01.39820] [12962] [debug] [c759c8bd] Routing to a
>>> callback
>>> [2020-04-09 23:28:01.39929] [12962] [debug] [c759c8bd] got: model logged
>>> with request id
>>> [2020-04-09 23:28:01.39940] [12959] [debug] [b0ba4af8] GET "/"
>>> [2020-04-09 23:28:01.39953] [12959] [debug] [b0ba4af8] Routing to a
>>> callback
>>> [2020-04-09 23:28:01.39959] [12959] [debug] [b0ba4af8] got: model logged
>>> with request id
>>> [2020-04-09 23:28:01.39967] [12962] [debug] [c759c8bd] 204 No Content
>>> (0.002487s, 402.091/s)
>>> [2020-04-09 23:28:01.39969] [12959] [debug] [b0ba4af8] 204 No Content
>>> (0.000277s, 3610.108/s)
>>> [2020-04-09 23:28:01.40082] [12962] [debug] [b38bd53f] GET "/"
>>> [2020-04-09 23:28:01.40088] [12960] [debug] [b0ba4af8] GET "/"
>>> [2020-04-09 23:28:01.40102] [12961] [debug] [3457c2a0] Routing to a
>>> callback
>>> [2020-04-09 23:28:01.40118] [12960] [debug] [b0ba4af8] Routing to a
>>> callback
>>> [2020-04-09 23:28:01.40118] [12961] [debug] [3457c2a0] got: model logged
>>> with request id
>>> [2020-04-09 23:28:01.40125] [12960] [debug] [b0ba4af8] got: model logged
>>> with request id
>>> [2020-04-09 23:28:01.40139] [12960] [debug] [b0ba4af8] 204 No Content
>>> (0.000497s, 2012.072/s)
>>> [2020-04-09 23:28:01.40148] [12961] [debug] [3457c2a0] 204 No Content
>>> (0.002434s, 410.846/s)
>>> [2020-04-09 23:28:01.40207] [12962] [debug] [b38bd53f] Routing to a
>>> callback
>>> [2020-04-09 23:28:01.40221] [12962] [debug] [b38bd53f] got: model logged
>>> with request id
>>> [2020-04-09 23:28:01.40239] [12962] [debug] [b38bd53f] 204 No Content
>>> (0.001559s, 641.437/s)
>>>
>>> It shows that the logging context used in the model's get method has the
>>> same context as in the routing action that renders the response.
>>>
>>>
>>> On Thu, Apr 9, 2020 at 6:19 PM Dan Book  wrote:
>>>
>>>> No, the purpose of passing the log from each request is that it
>>>> includes the context of the request ID (using the new context feature of
>>>> Mojo::Log).
>>>>
>>>> -Dan
>>>>
>>>> On Thu, Apr 9, 2020 at 7:12 PM Stefan Adams  wrote:
>>>>
>>>>> Excellent!  I'm not finding there to be any difference, either.  Thank
>>>>> you for the reply!
>>>>>
>>>>> As precise as the documentation is, I thought I would check to make
>>>>> sure there wasn't a good reason for it.
>>>>>
>>>>> The documentation shows that the controller log helper can be passed
>>>>> to a model in this way...  Rather than passing the log helper to
>>>>> *each* method as shown in the documentation, could we store it in the
>>>>> model object so that all methods would be able to use it and not need to
>>>>> have the log helper called explicitly each time?
>>>>>
>>>>> Here's an example gist
>>>>> <https://gist.github.com/s1037989/8993ddb90778befb51a4f334087a97ca>.
>>>>>
>>>>> On Thu, Apr 9, 2020 at 5:59 PM Dan Book  wrote:
>>>>>
>>>>>> I don't believe there would be any difference.
>>>>>>
>>

Re: [Mojolicious] $c->log

[Stefan Adams]

Hmm...  But isn't this below including the context of the request ID for
each request?

$self->helper(model => sub {$model->log(shift->log)});


Each request will have a different context.

Using apachebench to concurrently send requests to the preforking
application, we get this:

$ perl script/my_app prefork & ab -n 100 -c 100 http://localhost:3000/
[2020-04-09 23:28:01.39904] [12961] [debug] [3457c2a0] GET "/"
[2020-04-09 23:28:01.39820] [12962] [debug] [c759c8bd] Routing to a callback
[2020-04-09 23:28:01.39929] [12962] [debug] [c759c8bd] got: model logged
with request id
[2020-04-09 23:28:01.39940] [12959] [debug] [b0ba4af8] GET "/"
[2020-04-09 23:28:01.39953] [12959] [debug] [b0ba4af8] Routing to a callback
[2020-04-09 23:28:01.39959] [12959] [debug] [b0ba4af8] got: model logged
with request id
[2020-04-09 23:28:01.39967] [12962] [debug] [c759c8bd] 204 No Content
(0.002487s, 402.091/s)
[2020-04-09 23:28:01.39969] [12959] [debug] [b0ba4af8] 204 No Content
(0.000277s, 3610.108/s)
[2020-04-09 23:28:01.40082] [12962] [debug] [b38bd53f] GET "/"
[2020-04-09 23:28:01.40088] [12960] [debug] [b0ba4af8] GET "/"
[2020-04-09 23:28:01.40102] [12961] [debug] [3457c2a0] Routing to a callback
[2020-04-09 23:28:01.40118] [12960] [debug] [b0ba4af8] Routing to a callback
[2020-04-09 23:28:01.40118] [12961] [debug] [3457c2a0] got: model logged
with request id
[2020-04-09 23:28:01.40125] [12960] [debug] [b0ba4af8] got: model logged
with request id
[2020-04-09 23:28:01.40139] [12960] [debug] [b0ba4af8] 204 No Content
(0.000497s, 2012.072/s)
[2020-04-09 23:28:01.40148] [12961] [debug] [3457c2a0] 204 No Content
(0.002434s, 410.846/s)
[2020-04-09 23:28:01.40207] [12962] [debug] [b38bd53f] Routing to a callback
[2020-04-09 23:28:01.40221] [12962] [debug] [b38bd53f] got: model logged
with request id
[2020-04-09 23:28:01.40239] [12962] [debug] [b38bd53f] 204 No Content
(0.001559s, 641.437/s)

It shows that the logging context used in the model's get method has the
same context as in the routing action that renders the response.


On Thu, Apr 9, 2020 at 6:19 PM Dan Book  wrote:

> No, the purpose of passing the log from each request is that it includes
> the context of the request ID (using the new context feature of Mojo::Log).
>
> -Dan
>
> On Thu, Apr 9, 2020 at 7:12 PM Stefan Adams  wrote:
>
>> Excellent!  I'm not finding there to be any difference, either.  Thank
>> you for the reply!
>>
>> As precise as the documentation is, I thought I would check to make sure
>> there wasn't a good reason for it.
>>
>> The documentation shows that the controller log helper can be passed to a
>> model in this way...  Rather than passing the log helper to *each* method
>> as shown in the documentation, could we store it in the model object so
>> that all methods would be able to use it and not need to have the log
>> helper called explicitly each time?
>>
>> Here's an example gist
>> <https://gist.github.com/s1037989/8993ddb90778befb51a4f334087a97ca>.
>>
>> On Thu, Apr 9, 2020 at 5:59 PM Dan Book  wrote:
>>
>>> I don't believe there would be any difference.
>>>
>>> -Dan
>>>
>>> On Thu, Apr 9, 2020 at 6:13 PM Stefan Adams  wrote:
>>>
>>>> In Mojolicious::Plugin::DefaultHelpers#og
>>>> <https://mojolicious.org/perldoc/Mojolicious/Plugin/DefaultHelpers#log>
>>>>
>>>> I suspect there is a good, fundamental reason behind this decision in
>>>> the documents, but I'm not sure what it is.
>>>>
>>>> Why is $log passed to the model method
>>>>
>>>> # Pass logger with context to modelmy $log = $c->log;
>>>> $c->some_model->create({foo => $foo}, $log);
>>>>
>>>>
>>>> Instead of $c->log
>>>>
>>>> # Pass logger with context to model
>>>> $c->some_model->create({foo => $foo}, $c->log);
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Mojolicious" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to mojolicious+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFTSncQ%3D2ff9wf5Q6wOOH0RQp96-LPMbNyv2sGoJNri1eg%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFTSncQ%3D2ff9wf5Q6wOOH0RQp96-LPMbNyv2sGoJNri1eg%40mail.gmail.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>>> You received this message

Re: [Mojolicious] $c->log

[Stefan Adams]

Excellent!  I'm not finding there to be any difference, either.  Thank you
for the reply!

As precise as the documentation is, I thought I would check to make sure
there wasn't a good reason for it.

The documentation shows that the controller log helper can be passed to a
model in this way...  Rather than passing the log helper to *each* method
as shown in the documentation, could we store it in the model object so
that all methods would be able to use it and not need to have the log
helper called explicitly each time?

Here's an example gist
<https://gist.github.com/s1037989/8993ddb90778befb51a4f334087a97ca>.

On Thu, Apr 9, 2020 at 5:59 PM Dan Book  wrote:

> I don't believe there would be any difference.
>
> -Dan
>
> On Thu, Apr 9, 2020 at 6:13 PM Stefan Adams  wrote:
>
>> In Mojolicious::Plugin::DefaultHelpers#og
>> <https://mojolicious.org/perldoc/Mojolicious/Plugin/DefaultHelpers#log>
>>
>> I suspect there is a good, fundamental reason behind this decision in the
>> documents, but I'm not sure what it is.
>>
>> Why is $log passed to the model method
>>
>> # Pass logger with context to modelmy $log = $c->log;
>> $c->some_model->create({foo => $foo}, $log);
>>
>>
>> Instead of $c->log
>>
>> # Pass logger with context to model
>> $c->some_model->create({foo => $foo}, $c->log);
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Mojolicious" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mojolicious+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFTSncQ%3D2ff9wf5Q6wOOH0RQp96-LPMbNyv2sGoJNri1eg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFTSncQ%3D2ff9wf5Q6wOOH0RQp96-LPMbNyv2sGoJNri1eg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/CABMkAVV%2BOE7OERWzmc0-h7OhobvAteKqVAhWQJkK1kxyQY8ZqA%40mail.gmail.com
> <https://groups.google.com/d/msgid/mojolicious/CABMkAVV%2BOE7OERWzmc0-h7OhobvAteKqVAhWQJkK1kxyQY8ZqA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFTpazf5vzBE7wVr0tadTt%3DxXKTCBN5NvWMRFJv4Wi46Dg%40mail.gmail.com.

[Mojolicious] $c->log

[Stefan Adams]

In Mojolicious::Plugin::DefaultHelpers#og


I suspect there is a good, fundamental reason behind this decision in the
documents, but I'm not sure what it is.

Why is $log passed to the model method

# Pass logger with context to modelmy $log = $c->log;
$c->some_model->create({foo => $foo}, $log);


Instead of $c->log

# Pass logger with context to model
$c->some_model->create({foo => $foo}, $c->log);

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFTSncQ%3D2ff9wf5Q6wOOH0RQp96-LPMbNyv2sGoJNri1eg%40mail.gmail.com.

Re: [Mojolicious] Dynamically set the controller in "under"

[Stefan Adams]

Thanks, Dan! Does that mean, then, that what I provided as a solution is
actually a bad idea and may not always work as I'm anticipating?

On Sun, Mar 15, 2020, 9:41 PM Dan Book  wrote:

> Mojolicious does not support dynamic routing. Once a route has matched,
> the only thing an under can determine is if the dispatch chain continues or
> stops.
>
> -Dan
>
> On Sun, Mar 15, 2020 at 10:28 PM Stefan Adams  wrote:
>
>> I'm wanting to dynamically set the controller in, for example, an under
>>
>> my $admin = $self->routes->under('/admin' => sub { ... });
>>
>>
>> The only way I have found is like so
>>
>> my $admin = $self->routes->under('/admin' => sub {
>>   shift->match->stack->[-1]->{controller} = 'something';
>> });
>>
>>
>> Is this the right way?  The best way?  The only way?
>>
>> I could have sworn it was possible to set the controller in an under by
>> simply setting it in the stash, but that is not working for me.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Mojolicious" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mojolicious+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFTGpPNNfc5E9oPj-KzV6nD4-%3DBXQHyz-iJHwoeWCi3bjg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFTGpPNNfc5E9oPj-KzV6nD4-%3DBXQHyz-iJHwoeWCi3bjg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/CABMkAVUZDdegns3wRWojpXJX15vePVtY%3DvRkfh-RKyar88JPxw%40mail.gmail.com
> <https://groups.google.com/d/msgid/mojolicious/CABMkAVUZDdegns3wRWojpXJX15vePVtY%3DvRkfh-RKyar88JPxw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFRjaVzGikOFOAWuLX2%2BbGU5GjsD%3DDX3p_B4WEcS9WxOAg%40mail.gmail.com.

[Mojolicious] Dynamically set the controller in "under"

[Stefan Adams]

I'm wanting to dynamically set the controller in, for example, an under

my $admin = $self->routes->under('/admin' => sub { ... });


The only way I have found is like so

my $admin = $self->routes->under('/admin' => sub {
  shift->match->stack->[-1]->{controller} = 'something';
});


Is this the right way?  The best way?  The only way?

I could have sworn it was possible to set the controller in an under by
simply setting it in the stash, but that is not working for me.

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFTGpPNNfc5E9oPj-KzV6nD4-%3DBXQHyz-iJHwoeWCi3bjg%40mail.gmail.com.

Re: [Mojolicious] How to launch gvim reliably within a mojo app?

[Stefan Adams]

Would Mojo::IOLoop->subprocess

work for you?  Where the example shows sleep 5, put your system call to
gvim?  Not sure if that's a good solution if gvim is a long-running
process, tho.  Also, try it with `perl script daemon` as opposed to using
`morbo`, maybe?  Or try the systemd setup for hypnotoad
.
Is there any chance that Minion 
can help you here?  Minion is designed to handle long-running processes.

On Mon, Mar 9, 2020 at 8:24 PM Mike Lieman  wrote:

> I don't think you want to use Daemon::Control.   How about a nice, simple
> fork()?
>
> On Mon, Mar 9, 2020 at 8:46 PM Matthew Pressly 
> wrote:
>
>> From a mojolicious web app, I need to be able to launch gvim by clicking
>> a link or button to edit a particular file.
>>
>> Currently, I have this in the app:
>>
>> get '/edit' => sub {
>> my $c = shift;
>> my $result = `/usr/bin/gvim $filename 2>&1`;
>> $c->redirect_to('/');
>> };
>>
>> Sometimes it works, but other times, gvim runs twice when the link is
>> clicked and more frequently, gvim runs but hangs up in the background,
>> after which I end up killing the gvim process and killing and restarting
>> the web app to get it back to working.
>>
>> Is there a way to launch gvim (or other interactive programs) more
>> reliably?
>>
>> I'm using the following for a start script:
>>
>> #!/usr/bin/perl
>> use warnings;
>> use strict;
>> use Daemon::Control;
>>
>> exit Daemon::Control->new(
>> name=> "My Application",
>> lsb_start   => '$syslog $remote_fs',
>> lsb_stop=> '$syslog',
>> lsb_sdesc   => 'My App',
>> lsb_desc=> 'Controls the time tracker service.',
>> #path=> '/home/symkat/etc/init.d/program',
>>
>> program => '/usr/bin/morbo',
>> program_args => [ '/path/to/mojolicious/app.pl' ],
>>
>> pid_file=> '/tmp/myapp.pid',
>> stderr_file => '/var/log/myapp/myapp.log',
>> stdout_file => '/var/log/myapp/myapp.log',
>>
>> user=> 'myuser',
>> group=> 'myuser',
>>
>> fork=> 2,
>>
>> )->run;
>>
>>
>> Thank you,
>>
>> --
>> Matthew
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Mojolicious" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mojolicious+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/mojolicious/8930b24b-4e37-4b56-82ed-fad82031fe44%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/CAG2_C8CwMLwBXwVDdEicwpMYX1fvc3MHSo_CML_4Q7i%3DEHhwgg%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFTkKXBF2xyCH2MZpywMEiqW1mxK9FdpfK0DGapR%2B26pbw%40mail.gmail.com.

Re: [Mojolicious] DATA templates

[Stefan Adams]

On Sat, Feb 22, 2020 at 10:56 AM Dan Book  wrote:

> It is not well defined. __END__ and __DATA__ even serve the same purpose
> within the main script file (but not in module files). I recommend not
> combining them.
>

Interesting!  I did `mojo generate plugin` and it added perldoc after
__END__ so I didn't think to remove it, but I wanted to add __DATA__.  What
do you think about removing __END__ from the generator

?

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFRivNu1RtmhDG2kM_HtiTqUHN%3DhjSJrwHdQgB5DLYoSpQ%40mail.gmail.com.

Re: [Mojolicious] DATA templates

[Stefan Adams]

Thank you!  This link was very helpful and it provided a link to -- I think
-- a solid description explaining this behavior
<https://perldoc.perl.org/SelfLoader.html#The-__DATA__-token>.

but for other modules data after __END__
<https://perldoc.perl.org/functions/__END__.html> is not automatically
retrievable


@mojocore: What do you think about adding this tip to one or both of these
sections?

Mojo::Loader#data_section
Extract embedded file from the C section of a class, all files will be
cached once they have been accessed for the first time.
*C sections inclasses other than C should be placed before
C sections.*

Mojolicious::Guides##Renderer
All templates should be in the C directories of the application,
which can be customized with L, or one of the
the C sections from L.
*C sectionsin classes other than C should be placed before
C sections.*

Here's a Perl test demonstrating this behavior:

$ cat end_data.t
package EndData;
use Test::More;

{
  local $.;
  my $class = __PACKAGE__;
  my $handle = do { no strict 'refs'; \*{"${class}::DATA"} };
  my $fileno = ok !fileno($handle);
  SKIP: {
skip "DATA filehandle could not be opened", 2 if $fileno;
ok seek($handle, 0, 0);
like join('', <$handle>), qr(__END__.*?__DATA__);
  }
}

done_testing;

__END__
abc

__DATA__
def
$ cat data_end.t
package DataEnd;
use Test::More;

{
  local $.;
  my $class = __PACKAGE__;
  my $handle = do { no strict 'refs'; \*{"${class}::DATA"} };
  my $fileno = ok fileno($handle);
  SKIP: {
skip "DATA filehandle could not be opened", 2 unless $fileno;
ok seek($handle, 0, 0);
like join('', <$handle>), qr(__END__.*?__DATA__);
  }
}

done_testing;

__DATA__
def

__END__
abc
$ prove -v end_data.t data_end.t
end_data.t ..
ok 1
ok 2 # skip DATA filehandle could not be opened
ok 3 # skip DATA filehandle could not be opened
1..3
ok
data_end.t ..
ok 1
ok 2
ok 3
1..3
ok
All tests successful.
Files=2, Tests=6,  0 wallclock secs ( 0.01 usr  0.01 sys +  0.05 cusr  0.00
csys =  0.07 CPU)
Result: PASS

On Sat, Feb 22, 2020 at 9:41 AM Mike Lieman  wrote:

> >The two control characters ^D and ^Z, and the tokens __END__ and __DATA__
> may be used to indicate the logical end of the script before the actual end
> of file. * Any following text is ignored.*
>
> https://perldoc.perl.org/perldata.html#Special-Literals
>
> On Sat, Feb 22, 2020 at 10:12 AM Stefan Adams  wrote:
>
>> I just spent more time than I should admit about figuring this out.
>>
>> *Templates in the DATA section must come before the END section.*
>>
>> Is this common to all of Perl that DATA must come before END? Can anyone
>> point me to a document resource for this, so that I can read it and beat it
>> into my head? This is not the first time I've gotten tripped up on this.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Mojolicious" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mojolicious+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFQZykiSrmiFxoEdRYB-KdOw%3DeDPTQ86zC%3DNu428EuOJEA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFQZykiSrmiFxoEdRYB-KdOw%3DeDPTQ86zC%3DNu428EuOJEA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/CAG2_C8CWUeAvZ6fguaaADBqzDV4PZBhvrh%2ByUBsx8H5g%3D6_xoQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/mojolicious/CAG2_C8CWUeAvZ6fguaaADBqzDV4PZBhvrh%2ByUBsx8H5g%3D6_xoQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFQsU8KP%3D0Dp6DergHyjC5KQWBMnz1rLkUgxn91O0e-YUw%40mail.gmail.com.

[Mojolicious] DATA templates

[Stefan Adams]

I just spent more time than I should admit about figuring this out.

*Templates in the DATA section must come before the END section.*

Is this common to all of Perl that DATA must come before END? Can anyone
point me to a document resource for this, so that I can read it and beat it
into my head? This is not the first time I've gotten tripped up on this.

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFQZykiSrmiFxoEdRYB-KdOw%3DeDPTQ86zC%3DNu428EuOJEA%40mail.gmail.com.

Re: [Mojolicious] Re: New server status plugin

[Stefan Adams]

Fair enough! Thank you!

On Sun, Feb 16, 2020, 10:36 AM Sebastian Riedel  wrote:

> Just curious -- why did you choose to make Mojo::MemoryMap a part of
>> Mojolicious::Plugin::Status instead of its own stand alone?
>>
>
> For my convenience. Both are being developed together and coordinating
> multiple CPAN distributions costs time. Unfortunately spare time is a very
> limited resource for me these days, so i've got to cut some corners.
>
> --
> sebastian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/430da8f5-0d8b-47c7-9bda-d1eb9dc1b4e5%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFStnoqhv5jDhD_n1HGJbAcVgE-OcvZWAj8%3Dg%3Da30eVO3Q%40mail.gmail.com.

Re: [Mojolicious] Re: New server status plugin

[Stefan Adams]

This plugin is awesome!  And Mojo::MemoryMap looks like it will be so
useful in some projects!

Just curious -- why did you choose to make Mojo::MemoryMap a part of
Mojolicious::Plugin::Status instead of its own stand alone?

On Fri, Feb 14, 2020 at 10:46 AM Sebastian Riedel  wrote:

> Forgot to mention that it will now also show you the slowest requests,
> with a little smiley
> indicating the urgency of optimising that part of your code. :)
>
> --
> sebastian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/cc1a86c7-e6c9-4ef1-9fc3-7d7e85b11b8a%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFRqQ1_GWN%2B%3D%3DUWDxLeXeDTyzxMQx2s3yC9MuUjQyJz%3DNA%40mail.gmail.com.

Re: [Mojolicious] Stickers!

[Stefan Adams]

Are these stickers still available?

On Fri, Jan 15, 2016, 5:13 PM sri  wrote:

> We now have Mojolicious and Perl stickers over on Stickermule, enjoy! :)
>
> https://www.stickermule.com/user/1070707933/stickers
>
> --
> sebastian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFSX0Ls1qcVirXjh%3DS9_qm%3D3jyASUOD9Yy6_x9yzhQ3i-A%40mail.gmail.com.

Re: [Mojolicious] libcurl via Mojolicious

[Stefan Adams]

Hi, Felipe! Thanks for sharing this! What advantages does integrating with
libcurl have over using Mojo::UserAgent?

On Tue, Dec 10, 2019, 8:41 AM Felipe Gasper  wrote:

> Hi all,
>
> I’ve got a library called Net::Curl::Promiser that does the “dirty-work”
> of interfacing between different event loops and Net::Curl::Multi. I
> recently added a Mojo::IOLoop backend, so it should now be possible to
> integrate libcurl seamlessly into Mojolicious via Net::Curl::Promiser::Mojo.
>
> Hope it’s useful … enjoy!
>
> -FG
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/856af456-b0d4-4638-9eca-9661f02bb555%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFTQyKHHKe1OLaCkfxdN%2B-SgkKtbMq18q93w8FOFdKox0A%40mail.gmail.com.

[Mojolicious] Editing Mojolicious in Atom

[Stefan Adams]

I was just playing around with snippets in Atom, and got carried away
creating snippets for Mojolicious
.  For
now, I just go to "Edit > Snippets..." and paste it in there.  There might
be a dependency of atom-mojo .
It seems exceptionally useful to me for the hook* snippets, and using
autocomplete.

I've just been mostly grabbing awesome code snippets from the Mojolicious
Tutorials.  Any interest in this?  Comments or Suggestions?

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFSD7gA3dq4rVjTYp5X8irjGKgi0gTC7oZ1BcL0qiQb05g%40mail.gmail.com.

Re: [Mojolicious] Mojolicious::Plugin::Renderfile can't find a namespace

[Stefan Adams]

It should be a capital F

https://metacpan.org/pod/Mojolicious::Plugin::RenderFile

On Fri, Oct 18, 2019, 4:11 PM IVO I WELCH  wrote:

>
> New ubuntu 19.10 installation (perl 5.28.1):
>
> ```
> # cpan Mojolicious::Plugin::Renderfile
> Loading internal logger. Log::Log4perl recommended for better logging
> Reading '/root/.cpan/Metadata'
>   Database was generated on Fri, 18 Oct 2019 20:29:02 GMT
> >(error): Could not expand [Mojolicious::Plugin::Renderfile]. Check the
> module name.
> >(info): I can suggest names if you install one of Text::Levenshtein::XS,
> Text::Levenshtein::Damerau::XS, Text::Levenshtein, and
> Text::Levenshtein::Damerau::PP
> >(info): and you provide the -x option on invocation.
> >(error): Skipping Mojolicious::Plugin::Renderfile because I couldn't find
> a matching namespace.
> ```
>
> any advice?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/55778f5f-fb2d-4c2d-b2a3-de021e12a20d%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFSA6sy%3DWi%2BN--4wcXRKtkG-BbyYtudj9g-YUcwXwpj%2BxQ%40mail.gmail.com.

Re: [Mojolicious] Rendering templates question

[Stefan Adams]

Got it!  Your answer helped me to track down the code block I was looking
for: Mojo::Template::_wrap()
<https://github.com/mojolicious/mojo/blob/master/lib/Mojo/Template.pm#L259>.

I was just curious how it works.  Thank you!

On Fri, Oct 4, 2019 at 2:10 PM Dan Book  wrote:

> Mojolicious::Plugin::EPRenderer passes the stash as args to
> Mojo::Template, which has the vars option enabled and thus creates
> variables based on the passed hash.
>
> -Dan
>
> On Fri, Oct 4, 2019 at 1:33 PM Stefan Adams  wrote:
>
>> In Mojolicious::Guides::Render#Embedded-Perl
>> <https://mojolicious.org/perldoc/Mojolicious/Guides/Rendering#Embedded-Perl>,
>> it says:
>>
>> At the beginning of the template, stash values that don't have invalid
>> characters in their name get automatically initialized as normal variables,
>> and the controller object as both $self and $c.
>>
>>
>> How are stash values initialized as normal variables?  That is, what code
>> is responsible for making this happen?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Mojolicious" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mojolicious+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFSdKdJ15sPUTv19N3U7wc81O%3D7hv4i-kk%2BJ%3D_9Q%2BUd7Cw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFSdKdJ15sPUTv19N3U7wc81O%3D7hv4i-kk%2BJ%3D_9Q%2BUd7Cw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/CABMkAVWt%3DQhwzi-iDc7dQxxVf0whvWnG8_7bZpVEJC8om%3DSFCQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/mojolicious/CABMkAVWt%3DQhwzi-iDc7dQxxVf0whvWnG8_7bZpVEJC8om%3DSFCQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFTfjnSXNw9mqK3SDfU%3D2a5QMLJMs%2BnJgvLoSOXuCjAPxA%40mail.gmail.com.

[Mojolicious] Rendering templates question

[Stefan Adams]

In Mojolicious::Guides::Render#Embedded-Perl
,
it says:

At the beginning of the template, stash values that don't have invalid
characters in their name get automatically initialized as normal variables,
and the controller object as both $self and $c.


How are stash values initialized as normal variables?  That is, what code
is responsible for making this happen?

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFSdKdJ15sPUTv19N3U7wc81O%3D7hv4i-kk%2BJ%3D_9Q%2BUd7Cw%40mail.gmail.com.

Re: [Mojolicious] Workers/Clients Best Practices for good performance

[Stefan Adams]

As @kraih said on the GitHub issue, "The correct configuration depends
entirely on what the application does."

How you describe your issue sounds very similar to an issue I had.  For me,
the problem was blocking vs. non-blocking

code.  I had too much blocking code, to where practically no number of
workers was sufficient to handle heavy usage.  My biggest problem, IIRC,
was blocking code connecting to a database.  Now with Mojo::Pg, that's no
longer an issue for me.

On Thu, Sep 26, 2019 at 8:27 AM Michael Huys  wrote:

>
>- *Mojolicious version*: Unknown
>- *Perl version*: v5.16.3
>- *Operating system*: Red Hat Enterprise Linux Server release 7.6
>(Maipo)
>
>
>
>
> *Steps to reproduce the behavior*
>
> Currently our application is quite slow, surely if a lot of EU's (+- 100)
> are connected. Our application is loadbalanced over 2 servers with below
> specs:
>
>- 12vCPU
>- 48Gb Ram
>
> This is our Mojolicious configuration:
>
>
>
>
> *{ # # Logging #*
>
> *log => {
> path  => $app->home() . '/var/log/otrs.WebServer.log',
> level => 'warn',
> },
>
> #
> # Production Webserver ("Hypnotoad")
> #
>
> hypnotoad => {
>
> # Full path to the web server pid file. Don't change this, otherwise 
> automatic web server reloading
> #   from the application will not work any more.
> pid_file => $app->home() . '/var/run/otrs.WebServer.pid',
>
> # One or more locations/ports to listen on incoming connections. Examples:
> #
> # Listen on all IPv4 interfaces
> # listen => [ 'http://*:8080' ],
> #
> # Localhost and an IPv4 on port 8080
> # listen => [ 'http://localhost:8080 ', 
> 'http://192.168.1.1:8080 ' ],
> #
> # IPv6 on port 8080
> # listen => ['http://[::1]:8080'],
> #
> # HTTPS with custom certificate and key
> # listen => 
> ['https://*:8443?cert=/etc/ssl/cert/otrs.crt=/etc/ssl/private/otrs.key'],
> #
> listen => ['http://localhost:8080'],
>
> # The number of worker processes to serve incoming requests.
> workers => 25,
>
> # Number of temporarily spawned workers, which allows new workers to be 
> started while old ones are still
> # shutting down. This will reduce the performance costs of worker 
> restarts.
> spare => 10,
>
> # Maximum number of connections, which will be accepted by each worker 
> concurrently.
> clients => 20,
>
> # Maximum number of connections, which will be accepted by each worker, 
> before it will be stopped and
> # replaced by a new one.
> # Setting this value to 0 causes the server to never stop workers after a 
> certain amount of connections.
> accepts => 5000,
>
> # Maximum amount of time in seconds stopping a worker gracefully may take 
> before being forced.
> graceful_timeout => 120,
>
> # Maximum amount of time in seconds before a worker without a heartbeat 
> will be stopped gracefully.
> # Note that this value should usually be a little larger than the maximum 
> amount of time you
> #   expect any one operation to block the event loop.
> heartbeat_timeout => 120,
>
> # Maximum amount of time in seconds a connection can be inactive before 
> getting closed.
> inactivity_timeout => 120,
>
> # Activate support for operation behind a reverse proxy. This allows for 
> the X-Forwarded-For and
> #   X-Forwarded-Proto headers to be picked up automatically by the server 
> to identify the remote address.
> #
> # This should be set to 0 if using the Mojolicious web server directly 
> without a reverse proxy in front of it,
> #   for security reasons.
> proxy => 1,
> },
>
> #
> # Limits
> #
>
> max_request_size => 64 * 1024 * 1024,
>
> #
> # Websocket
> #
>
> websocket => {
> # Websocket heartbeat check settings in seconds.
> ping_interval  => 20,
> pong_timeout   => 10,
> inactivity_timeout => 30,
> },
>
> #
> # Debugging
> #
>
> enable_debugger_http_trace=> 0,
> enable_debugger_sql_trace => 0,
> enable_debugger_stderr_log=> 0,
> enable_debugger_perl_profiler => 0,
> *
>
>
> *}; *`
>
> *Expected behavior*
>
> Good performance
>
> *Actual behavior*
>
> Bad performance ;-)
> Any suggestions on the "Workers" and "Clients" setting? Like already said
> the application behaves performant if only 10 users are logged on. Once we
> go over 50 eu's application is going slower and slower.
> We were thinking of increasing the workers a little bit more (eg. 30?) and
> decrease the clients to 5?
> CPU usage on the servers are < 20%
> Memory usage on the servers are < 50%
>
> I know that this is dependent on your application, but the problem is that
> an external company has written this for us and they don't want to advice
> us on the best practice settings. :-(
>
> --
> You received this message because you are subscribed 

Re: [Mojolicious] Action is not allowed Template not found

[Stefan Adams]

Try an action name other than `tap`.  tap() is a method in Mojo::Base
 which just about every
class in Mojolicious inherits from.

In the Mojolicious::Lite app, you do not have a subroutine action named
`tap` -- you just have a callback.  In the full Mojolicious app, you have a
subroutine action named `tap`.  Specifically, these
 keywords are
hidden from the router.

On Fri, Sep 13, 2019 at 12:39 AM VadimN 
wrote:

> Hi,
>
> Using Websocket technology to periodically send new rows to the page.
>
> Under lite version all works fine.
>
> Server log for getting page, establishing WS connection, sending
> occasional new row to the page:
>
> at http://127.0.0.1:3000
> :44.91645] [4732] [debug] GET "/" (cd726066)
> :44.91768] [4732] [debug] Routing to a callback
> :45.10940] [4732] [debug] Rendering template "index.html.ep" from DATA
> section
> :45.11445] [4732] [debug] Rendering template "menu.html.ep" from DATA
> section
> :45.11736] [4732] [debug] Rendering template "datarows.html.ep" from DATA
> section
> :45.16243] [4732] [debug] 200 OK (0.245983s, 4.065/s)
> :46.35749] [4732] [debug] GET "/tap" (f0cc47e0)
> :46.36461] [4732] [debug] Routing to a callback
> :46.36624] [4732] [debug] 101 Switching Protocols (0.008739s, 114.430/s)
> :46.36646] [4732] [debug] WS for table append opened
> :58.41381] [4732] [debug] Rendering cached template "datarows.html.ep"
> from DATA section
> :58.41454] [4732] [debug] html sent; new id = 231378
>
>
> The problem occurred when switching from Mojolicious::Lite to the full
> version.
>
> Server log looks like this:
>
> at http://127.0.0.1:3000
> :17.64413] [6264] [debug] GET "/" (5b7cd6b9)
> :17.64681] [6264] [debug] Routing to controller
> "MyApp::Controller::FrontEnd" and action "index"
> :17.83067] [6264] [debug] Rendering template "front_end/index.html.ep"
> :17.83547] [6264] [debug] Rendering template "menu.html.ep"
> :17.83944] [6264] [debug] Rendering template "datarows.html.ep"
> :17.88862] [6264] [debug] Rendering template "layouts/default.html.ep"
> :17.89673] [6264] [debug] 200 OK (0.252574s, 3.959/s)
> :19.47888] [6264] [debug] GET "/tap" (2727832e)
> :19.48026] [6264] [debug] Action "tap" is not allowed
> :19.48132] [6264] [debug] Template "front_end/tap.html.ep" not found
> :19.48225] [6264] [debug] Template "not_found.development.html.ep" not
> found
> :19.48310] [6264] [debug] Template "not_found.html.ep" not found
> :19.48413] [6264] [debug] Rendering template "mojo/debug.html.ep"
> :19.53478] [6264] [debug] 404 Not Found (0.055844s, 17.907/s)
>
> In the Lite app theris function call
>
> websocket '/tap' => sub {
> my $c = shift;
>
> #get some data from outside
> #...
>
>
> # as the test showed, this is not necessary for lite app
> #$c->on(message => sub {
> #});
>
> my $id = Mojo::IOLoop->recurring(3 => sub {
>
> #check for the new data
> #...
>
> if (new data found) {
> ...
> my $html = $c->render_to_string('datarows');
> $c->send($html);
> $c->app->log->debug("html sent; new id = $max_id");
> }
> });
>
> $c->on(finish => sub {
> Mojo::IOLoop->remove($id);
> $c->app->log->debug("WS for table append closed");
> });
>
> $c->app->log->debug('WS for table append opened');
> };
>
>
> This is transforms to couple parts in full app code.
> In startup function
>
> $r->websocket('/tap')->to('front_end#tap');
>
> In the FrontEnd controller:
>
> sub tap {
> my $self = shift;
>
> # get some data
> #...
>
> my $id = Mojo::IOLoop->recurring(3 => sub {
>
> # check for data
>
> # if found
> if (...) {
> ...
> #all the same
> };
>
>
> Why was he asking about a nonexistent template?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/d6b383e5-b1d4-4cd2-bf4f-ef2fc0e99e71%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFSu5pV03eyDmVtr%2BPFtyVSSJYq%3DyNhMCAur7Dy0jXkX4Q%40mail.gmail.com.

Re: [Mojolicious] Reverse Proxy

[Stefan Adams]

Thank you both!  I see -- I did misread that bold.  I interpreted it as
several applications through the same *internal* IP/port.  I understand now
that it was referring to the same *visible from the outside* IP/port.

My question has been answered!

On Tue, Sep 10, 2019 at 1:23 AM Dan Book  wrote:

> Most commonly, different nginx servers (the nginx equivalent of Apache
> virtualhosts) will listen on different hostnames, and then proxy to
> different backend applications.
>
> -Dan
>
> On Tue, Sep 10, 2019 at 2:17 AM Stefan Adams  wrote:
>
>> From the Cookbook#Reverse Proxy
>> <https://mojolicious.org/perldoc/Mojolicious/Guides/Cookbook#Reverse-proxy>
>> :
>>
>> *[A reverse proxy] can provide a lot of benefits, like terminating SSL
>> connections from the outside, limiting the number of concurrent open
>> sockets towards the Mojolicious application (or even using Unix sockets),
>> balancing load across multiple instances, or supporting several
>> applications through the same IP/port.*
>>
>>
>> What steps are necessary to support several applications through the same
>> IP/port?
>>
>> I'm picturing having two separate Mojolicious applications running in two
>> separate system processes, each with their own Perl binary even.  What is
>> necessary to reverse proxy a connection to these two separate apps
>> listening on the same IP/port?  How does the reverse proxy (nginx) know
>> which process should get the request proxied to it?
>>
>> Or am I misunderstanding what is stated in bold above?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Mojolicious" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mojolicious+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFSkT_YXpnUbakT%3DO%2Bi1y99vVxpg8rVo%3D8V33LUtLhNfPQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFSkT_YXpnUbakT%3DO%2Bi1y99vVxpg8rVo%3D8V33LUtLhNfPQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/CABMkAVUec9he1116T6Mu%3Dd1ZdAR7Cj_UdaFTxSD%2BrC8wm7UvmQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/mojolicious/CABMkAVUec9he1116T6Mu%3Dd1ZdAR7Cj_UdaFTxSD%2BrC8wm7UvmQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFT9%2Ba6iLqbjYiym2QhMMXi07vrb9A0yBA1kKxYSc4%3DP3Q%40mail.gmail.com.

[Mojolicious] Reverse Proxy

[Stefan Adams]

>From the Cookbook#Reverse Proxy
:

*[A reverse proxy] can provide a lot of benefits, like terminating SSL
connections from the outside, limiting the number of concurrent open
sockets towards the Mojolicious application (or even using Unix sockets),
balancing load across multiple instances, or supporting several
applications through the same IP/port.*


What steps are necessary to support several applications through the same
IP/port?

I'm picturing having two separate Mojolicious applications running in two
separate system processes, each with their own Perl binary even.  What is
necessary to reverse proxy a connection to these two separate apps
listening on the same IP/port?  How does the reverse proxy (nginx) know
which process should get the request proxied to it?

Or am I misunderstanding what is stated in bold above?

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFSkT_YXpnUbakT%3DO%2Bi1y99vVxpg8rVo%3D8V33LUtLhNfPQ%40mail.gmail.com.

Re: [Mojolicious] 'Under' controller method called multiple times

[Stefan Adams]

On Fri, Jun 14, 2019 at 10:32 AM Dan Book  wrote:

> To just "establish a URL path", under is not needed, you can just use any
> which does not create a discrete action.
>

Wow, I didn't realize you could use 'any' for this purpose!

It makes sense that 'under' must return 1 to continue the chain, but how is
the Mojolicious::Lite example
<https://mojolicious.org/perldoc/Mojolicious/Guides/Tutorial#Under> doing
that?

# /foo
under '/foo';

Justin's full app example looks the same.

Thanks for your explanation, Dan!


> -Dan
>
> On Fri, Jun 14, 2019 at 11:32 AM Dan Book  wrote:
>
>> The explanation is that each 'under' route is a discrete action from the
>> endpoints, and must be defined and return 1 to continue the dispatch chain.
>>
>> -Dan
>>
>> On Fri, Jun 14, 2019 at 11:10 AM Stefan Adams  wrote:
>>
>>> I don't have an explanation for why this seems to be necessary for your
>>> situation, but after reading Mojolicious::Guides::Routing#Under
>>> <https://mojolicious.org/perldoc/Mojolicious/Guides/Routing#Under>, I
>>> found that this should work for you:
>>>
>>>   # REST interface
>>>   my $rest_v1 = $r->under('/rest/v1'* => sub{1}*);
>>>   $rest_v1->get('/')->to('example#welcome');
>>>
>>> On Thu, Jun 13, 2019 at 1:09 AM Justin Hawkins 
>>> wrote:
>>>
>>>> Hello all,
>>>>
>>>> I think there is a good chance this is a case of “holding it wrong”, so
>>>> I will first explain what I’m trying to achieve.
>>>>
>>>> Standard web app, multiple ways of establishing rights to privileged
>>>> routes.
>>>>
>>>> The first is standard username/password, establishing a session.
>>>>
>>>> The second is via an API key (supplied with a header).
>>>>
>>>> I use two separate controller methods, one to check the session, one to
>>>> check the header. Each one has the opportunity to set a stash variable
>>>> indicating that the user has a valid session (via either cookie session or
>>>> API key).
>>>>
>>>> So I use two “under” routes to call each method. So far so good, things
>>>> work ok.
>>>>
>>>> The problem I have is that I later have another under route, to
>>>> establish a new URL path for my REST interface.
>>>>
>>>> Any requests that go through routes derived from that third “under"
>>>> have a strange behaviour - they call the second ‘under’ controller twice!
>>>>
>>>> This is probably easiest to see with an example:
>>>>
>>>> package TestUnder;
>>>> use Mojo::Base 'Mojolicious';
>>>>
>>>> # This method will run once at server start
>>>> sub startup {
>>>>   my $self = shift;
>>>>
>>>>   # Load configuration from hash returned by config file
>>>>   my $config = $self->plugin('Config');
>>>>
>>>>   # Configure the application
>>>>   $self->secrets($config->{secrets});
>>>>
>>>>   # Router
>>>>   my $r = $self->routes;
>>>>
>>>>   # All requests should go through these two
>>>>   $r = $r->under()->to('example#under_one');
>>>>   $r = $r->under()->to('example#under_two');
>>>>   $r->get('/')->to('example#welcome');
>>>>
>>>>   # REST interface
>>>>   my $rest_v1 = $r->under('/rest/v1');
>>>>   $rest_v1->get('/')->to('example#welcome');
>>>>
>>>> }
>>>>
>>>> package TestUnder::Controller::Example;
>>>>
>>>> use Mojo::Base 'Mojolicious::Controller';
>>>>
>>>> sub under_one {
>>>>   my $self = shift;
>>>>   $self->app->log->info("under_one called");
>>>>   1;
>>>> }
>>>>
>>>> sub under_two {
>>>>   my $self = shift;
>>>>   $self->app->log->info("under_two called");
>>>>   1;
>>>> }
>>>>
>>>> sub welcome {
>>>>   my $self = shift;
>>>>   $self->render(text => 'hi');
>>>> }
>>>>
>>>> 1;
>>>>
>>>> Example below - you can easily see that for the “REST” route,
>>>> ‘under_two’ is called twice:
>>>>
>>>>
>>>>
>>>>
>>>> $ script/

Re: [Mojolicious] 'Under' controller method called multiple times

[Stefan Adams]

I don't have an explanation for why this seems to be necessary for your
situation, but after reading Mojolicious::Guides::Routing#Under
, I found
that this should work for you:

  # REST interface
  my $rest_v1 = $r->under('/rest/v1'* => sub{1}*);
  $rest_v1->get('/')->to('example#welcome');

On Thu, Jun 13, 2019 at 1:09 AM Justin Hawkins  wrote:

> Hello all,
>
> I think there is a good chance this is a case of “holding it wrong”, so I
> will first explain what I’m trying to achieve.
>
> Standard web app, multiple ways of establishing rights to privileged
> routes.
>
> The first is standard username/password, establishing a session.
>
> The second is via an API key (supplied with a header).
>
> I use two separate controller methods, one to check the session, one to
> check the header. Each one has the opportunity to set a stash variable
> indicating that the user has a valid session (via either cookie session or
> API key).
>
> So I use two “under” routes to call each method. So far so good, things
> work ok.
>
> The problem I have is that I later have another under route, to establish
> a new URL path for my REST interface.
>
> Any requests that go through routes derived from that third “under" have a
> strange behaviour - they call the second ‘under’ controller twice!
>
> This is probably easiest to see with an example:
>
> package TestUnder;
> use Mojo::Base 'Mojolicious';
>
> # This method will run once at server start
> sub startup {
>   my $self = shift;
>
>   # Load configuration from hash returned by config file
>   my $config = $self->plugin('Config');
>
>   # Configure the application
>   $self->secrets($config->{secrets});
>
>   # Router
>   my $r = $self->routes;
>
>   # All requests should go through these two
>   $r = $r->under()->to('example#under_one');
>   $r = $r->under()->to('example#under_two');
>   $r->get('/')->to('example#welcome');
>
>   # REST interface
>   my $rest_v1 = $r->under('/rest/v1');
>   $rest_v1->get('/')->to('example#welcome');
>
> }
>
> package TestUnder::Controller::Example;
>
> use Mojo::Base 'Mojolicious::Controller';
>
> sub under_one {
>   my $self = shift;
>   $self->app->log->info("under_one called");
>   1;
> }
>
> sub under_two {
>   my $self = shift;
>   $self->app->log->info("under_two called");
>   1;
> }
>
> sub welcome {
>   my $self = shift;
>   $self->render(text => 'hi');
> }
>
> 1;
>
> Example below - you can easily see that for the “REST” route, ‘under_two’
> is called twice:
>
>
>
>
> $ script/test_under get / >/dev/null
> [2019-06-13 15:28:30.55547] [44306] [debug] GET "/" (9ca39c7c)
> [2019-06-13 15:28:30.55627] [44306] [debug] Routing to controller
> "TestUnder::Controller::Example" and action "under_one"
> [2019-06-13 15:28:30.55637] [44306] [info] under_one called
> [2019-06-13 15:28:30.55651] [44306] [debug] Routing to controller
> "TestUnder::Controller::Example" and action "under_two"
> [2019-06-13 15:28:30.55661] [44306] [info] under_two called
> [2019-06-13 15:28:30.55675] [44306] [debug] Routing to controller
> "TestUnder::Controller::Example" and action "welcome"
> [2019-06-13 15:28:30.55704] [44306] [debug] 200 OK (0.001571s, 636.537/s)
>
> $ script/test_under get /rest/v1 >/dev/null
> [2019-06-13 15:28:34.95883] [44315] [debug] GET "/rest/v1" (6aad1c75)
> [2019-06-13 15:28:34.95975] [44315] [debug] Routing to controller
> "TestUnder::Controller::Example" and action "under_one"
> [2019-06-13 15:28:34.95984] [44315] [info] under_one called
> [2019-06-13 15:28:34.95997] [44315] [debug] Routing to controller
> "TestUnder::Controller::Example" and action "under_two"
> [2019-06-13 15:28:34.96005] [44315] [info] under_two called
> [2019-06-13 15:28:34.96020] [44315] [debug] Routing to controller
> "TestUnder::Controller::Example" and action "under_two"
> [2019-06-13 15:28:34.96031] [44315] [info] under_two called
> [2019-06-13 15:28:34.96044] [44315] [debug] Routing to controller
> "TestUnder::Controller::Example" and action "welcome"
> [2019-06-13 15:28:34.96083] [44315] [debug] 200 OK (0.001985s, 503.778/s)
>
> $ mojo version
> CORE
>   Perl(v5.26.1, darwin)
>   Mojolicious (8.17, Supervillain)
>
> OPTIONAL
>   Cpanel::JSON::XS 4.04+  (n/a)
>   EV 4.0+ (n/a)
>   IO::Socket::Socks 0.64+ (n/a)
>   IO::Socket::SSL 2.009+  (2.051)
>   Net::DNS::Native 0.15+  (n/a)
>   Role::Tiny 2.01+(2.05)
>
> This version is up to date, have fun!
>
> Regards,
>
> Justin
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/8EB007C9-0631-448B-B654-56C6D1EE0A5A%40hawkins.id.au
> 

Re: [Mojolicious] Mojolicious::Lite HTTPS / SSL / TLS not working

[Stefan Adams]

On Wed, May 22, 2019 at 7:20 AM Celejar  wrote:

> Make sure everything is up to snuff with IO::Socket::SSL
>>
>
> What would you suggest I do, specifically?
>

Unfortunately, I'll be of little help here.   Did listening on https for
your app ever work on this instance that is currently failing?  The latest
version of IO::Socket::SSL is 2.066 -- perhaps update?  I think
IO::Socket::SSL depends on Net::SSLeay, perhaps update it to the latest
version 1.88?  Of course, it's always a good idea to update Mojolicious to
the latest version.  Do those one at a time and test after each update.
What about updating your openssl library openssl, libssl1.0.0, and
libssl-dev?  I'm on Ubuntu 16.04 with openssl 1.0.2g.

Before doing any of that, I'm just curious: openssl, curl, and wget all
fail for you...  what about trying the mojo useragent?

$ mojo get -k https://127.0.0.1:3000
Your Mojo is working!

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFSo3DJuttjM07D-HDGqXnNTkVeKtrJk1uNiV%2BbzuXE4cg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Mojolicious::Lite HTTPS / SSL / TLS not working

[Stefan Adams]

Try your test out with a built-in HelloWorld app:

$ mojo daemon -l https://*:3000
Server available at https://127.0.0.1:3000
$ curl -k https://127.0.0.1:3000
Your Mojo is working!


I doubt there's a problem with Mojo's SSL implementation as it doesn't
really have one -- it relies on IO::Socket::SSL.

$ mojo version
CORE
  Perl(v5.22.1, linux)
  Mojolicious (8.12, Supervillain)

OPTIONAL
  Cpanel::JSON::XS 4.04+  (n/a)
  EV 4.0+ (n/a)
  IO::Socket::Socks 0.64+ (n/a)
*  IO::Socket::SSL 2.009+  (2.024)*
  Net::DNS::Native 0.15+  (n/a)
  Role::Tiny 2.01+(2.06)

You might want to update your Mojolicious to 8.16!


Make sure everything is up to snuff with IO::Socket::SSL.

On Tue, May 21, 2019 at 12:42 PM Celejar  wrote:

> Hi,
>
> I'm trying to access my Mojolicious::Lite web app via HTTPS, but it's not
> working: the SSL connection is apparently immediately reset by the server:
>
> ~$ perl/app.pl daemon -l https://*:3000
> [2019-05-21 13:40:24.49479] [10969] [info] Listening at "https://*:3000;
> Server available at https://127.0.0.1:3000
>
> ~$ curl -v -k https://127.0.0.1:3000
> * Expire in 0 ms for 6 (transfer 0x55d756de3dd0)
> *   Trying 127.0.0.1...
> * TCP_NODELAY set
> * Expire in 200 ms for 4 (transfer 0x55d756de3dd0)
> * Connected to 127.0.0.1 (127.0.0.1) port 3000 (#0)
> * ALPN, offering h2
> * ALPN, offering http/1.1
> * successfully set certificate verify locations:
> *   CAfile: none
>   CApath: /etc/ssl/certs
> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> * OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 127.0.0.1:3000
> * Closing connection 0
> curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to
> 127.0.0.1:3000
>
> ~$ openssl s_client  -connect localhost:3000
> CONNECTED(0003)
> write:errno=104
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 283 bytes
> Verification: OK
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> Early data was not sent
> Verify return code: 0 (ok)
> ---
>
> ~$ wget -v  https://localhost:3000
> --2019-05-21 11:17:27--  https://localhost:3000/
> Resolving localhost (localhost)... ::1, 127.0.0.1
> Connecting to localhost (localhost)|::1|:3000... failed: Connection
> refused.
> Connecting to localhost (localhost)|127.0.0.1|:3000... connected.
> GnuTLS: Error in the pull function.
> Unable to establish SSL connection.
>
> Am I doing something wrong, or is something wrong with Mojo's SSL
> implementation?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mojolicious/59b0dcdb-c5e2-47e9-9a61-72b9ee3bbd48%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mojolicious/CACyQ%2BFSeBpf9LWd95xyZWpB_aGwke0_mxkSqybFzfphdkyiEEw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] SSL options via UserAgent?

[Stefan Adams]

If you're ok with Mojo::UserAgent not requiring a valid TLS certificate,
just set insecure to a true value.

https://mojolicious.org/perldoc/Mojo/UserAgent#insecure

# Disable TLS certificate verification for testing
say $ua->insecure(1)->get('https://127.0.0.1:3000')->result->code;


On Mon, Apr 29, 2019, 6:46 PM  wrote:

> I'm running a web scraper against a large number of devices that use HTTPS
> for configuration and ran into an issue where some of the older devices
> select a cipher suite that causes the SSL client to dump out a 'dh key too
> short' error.
> I can get resolve it by changing the list of available ciphers by running
> perl in debug mode and adding $options{tls_ciphers} = 'DEFAULT:!DH' inside
> of UserAgent->_connect.
> I can't seem to find any way to get that value added to the IOLoop::TLS
> (other than manually breaking in and adding it)
> I'm admittedly a Mojo novice.  Am I missing something obvious here or am I
> resigned to have to forego the ease of UserAgent and roll my own IOLoop
> client?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Using Mojolicious::Lite Syntax in Modules to Add Routes

[Stefan Adams]

I don't have an answer for you, but I recommend checking out this related
talk, Mojolicious Gardening by Joel Berger
.

He has a sample lite-hybrid app

.

On Mon, Apr 29, 2019 at 1:15 PM Viktor Nacht  wrote:

> I have a fairly simple Mojo app where I just want to spin off the admin
> routes into a module but still use the Mojolicious::Lite syntax. I
> understand I could "grow" the app, but that would add a lot of extra files
> where I really just need to add one file.
>
> Is something like this possible? I tried the "obvious" approach but no
> luck.
>
> use Mojolicious::Lite;
> use MyApp::Admin;
>
> get '/public'
>
> app->start;
>
> package MyApp::Admin;
>
> use Mojolicious::Lite;
>
> get '/admin';
>
> The route /admin isn't added even though the module is found and processed
> (using FindBin). Any thoughts?
>
> Thank you!
>
> V
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] bypass authentication of static objects

[Stefan Adams]

The only hook

I see -- a before_dispatch -- can be disabled by not autoloading the user
data
.
before_dispatch
 is emitted
right before the static file server, so perhaps not autoloading the user
data could bypass involvement of authentication for objects under "public"?

On Tue, Apr 16, 2019 at 6:36 AM Rajesh Mallah 
wrote:

>
> Hi ,
>
> I am using Mojolicious::Plugin::Authentication
> is it possible to bypass the involvement of authentication
> for objects under "public" ?
>
>
> regd
> mallah.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Skipping code for a Minion worker

[Stefan Adams]

On Fri, Mar 29, 2019 at 9:27 AM Veesh Goldman  wrote:

> I have a mojolicious app which acts as a frontend to a resource, and
> requires a websocket connection to that resource. I would like to run some
> stuff in the background with Minion, but I don't want minion to also have
> that connection. How would I make only the server and not the worker run
> that code?
>
> #TODO- only run  this in the server, not the worker
> app->ua->websocket( 'ws://my.resource' => sub { ...  } ); #control things
>

You could inspect the command line arguments or environment.

I start my minion with `myapp.pl minion worker' so:
app->ua->websocket( 'ws://my.resource' => sub { ...  } ) unless grep {
/worker/ } @ARGV;

Or using env with `env MINION=1 myapp.pl minion worker`
app->ua->websocket( 'ws://my.resource' => sub { ...  } ) unless
$ENV{MINION};

There may be a more elegant way, but this at least demonstrates what might
be easily missed when it comes to figuring out how to solve that problem.

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Amazon S3?

[Stefan Adams]

I have't done S3 specifically yet, and I'm just getting into it, but from
what I'm seeing all that's really needed is to sign the requests.  From
there the API is just standard HTTP API through Mojo::UserAgent.  I worked
on Mojo::AWS::Signature4 ,
with much code taken from Signer:AWSv4, that signs all AWS requests.  I've
tested it with EC2 and Amazon Connect so far.  Works great.  See the tests.

I'm very close to releasing it to CPAN, but haven't done so yet.  I welcome
your feedback and contributions.

On Thu, Mar 28, 2019 at 3:26 PM Charlie Brady <
charlieb-m...@budge.apana.org.au> wrote:

>
> Have any of you developed code using Mojo::Base and Mojo::UserAgent to
> access S3 storage?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Legacy ? CRUD on an XML file within a webpage

[Stefan Adams]

On Fri, Mar 22, 2019 at 10:16 AM Luc Larochelle 
wrote:

> I've been thinking a lot about this lately. In a very simple and light
> application, the database is an XML file , around 1000 entries and very low
> IO.
>
> I haven't been orienting my work on XML, but I was wondering if it would
> be easier to CRUD on the XML directly instead of creating a web app +
> migrate the data to a db, etc ...
>

It sounds like the problem that I have is similar to yours.  I'm dealing
with a SOAP-based web API that delivers 500 records at a time.  I'm trying
hard -- probably too hard, but I'm stubborn -- to avoid converting the XML
results into a database.  The schema necessary to map this web service is
300 pages long, so no thanks.  Like you, I'm dealing with low IO and prefer
to handle my processing in-memory with Perl rather than crafting SQL
queries.  So, as I indicated in the thread you linked, I deserialize the
SOAP response into a complex Perl data structure and then I further shove
that into a Mojo::Collection so I can very easily chain methods for grep,
sort, map, each, etc.  I can also modify the data and then send it back to
the web service via SOAP.

I'm getting very close to releasing Mojo::Autotask

to
CPAN, but there's the development branch to review if you like.  This also
uses Mojo::Redis for memoizing results.  The included
Mojo::Collection::Role::Autotask expand method is the equivalent of an SQL
'join'.

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] nginx-unit and Mojolicious

[Stefan Adams]

Thanks for the report, Alex!  Do you happen to know what change was made in
nginx-unit that allowed for it to now be compatible with Mojolicious?

On Mon, Mar 18, 2019 at 3:57 PM Alex Povolotsky  wrote:

> Hello
>
> I'm glad to tell that unit, starting from 1.8.0, works fine with
> Mojolicious. For 1.7.0 and 1.7.1, a patch is available.
>
> Yes, unit( http://unit.nginx.org) is THE app server made by the same
> group who made nginx.
> --
> Alex
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] MUA::Transactor::add_generator

[Stefan Adams]

Thanks for the great suggestion!  I thought about the Role method, but
couldn't understand how to make that work nice.  I got onto IRC and was
given the advice that I believe you inferred to use Role::Tiny 'around',
and that solves it very well!

Updated gist
<https://gist.github.com/s1037989/479087c752d7461d3499c12971636678> using
around
<https://gist.github.com/s1037989/479087c752d7461d3499c12971636678#file-mojo-useragent-role-awssignature4-pm-L17>
.

Thanks for the help, everyone!

On Wed, Mar 13, 2019 at 1:13 AM Илья Рассадин  wrote:

> Hi!
>
> name "add_generator" leads me to the idea, that there can be more than one
> aws sign generators. apply_generator or set_generator makes it clear, that
> there can be only one.
>
> And by the way, why don't you encapsulate generator logic inside role AWSSign
> role?
>
> So, code could be something like
>
> my $ua = Mojo::UserAgent->with_roles('+AWSSign')->new(max_redirects => 5);
>
> my $tx = $ua->build_tx(...);
> On 13/03/2019 01:18, Stefan Adams wrote:
>
> Thanks, Dan!  I updated the gist
> <https://gist.github.com/s1037989/479087c752d7461d3499c12971636678> with
> your recommendation, and my new synopsis is this:
>
> Mojo::AWS::Signature4->add_generator($ua => 'sign');
> my $tx = $ua->build_tx(GET => '...' => sign => {service => 'ec2'});
>
>
> Does add_generator feel like the right method name for this?  Maybe
> apply_generator, instead?
>
> On Tue, Mar 12, 2019 at 4:45 PM Dan Book  wrote:
>
>> That seems like the appropriate mechanism to me. If you want to provide a
>> convenience method, I would instead provide one that takes the $ua object
>> and an optional generator name, and calls ->add_generator itself. It would
>> also be subclassable since it could call a method on $self instead of
>> __PACKAGE__.
>> -Dan
>>
>> On Tue, Mar 12, 2019 at 5:22 PM Stefan Adams  wrote:
>>
>>> I built a generator for AWS Signature4 requests
>>> <https://gist.github.com/s1037989/479087c752d7461d3499c12971636678>.
>>> This generator calculates a signed Authorization header for the request.
>>> Is this a good use of the Transactor generator feature?
>>>
>>> As you can see from L13
>>> <https://gist.github.com/s1037989/479087c752d7461d3499c12971636678#file-ec2-t-L13>
>>> of the supplied test, I make my generator available this way:
>>>
>>> $ua->transactor->add_generator(Mojo::AWS::Signature4::generator);
>>>
>>>
>>> Is this the best mechanism available to share this generator, or is
>>> there a recommended standard convention?  When I go to document it for
>>> publishing, is that what I should have in the synopsis section?  It almost
>>> feels like there should be a plugin mechanism for Mojo::UserAgent.
>>>
>>> Thanks for any advice and comments you have!
>>>
>>> Stefan
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Mojolicious" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to mojolicious+unsubscr...@googlegroups.com.
>>> To post to this group, send email to mojolicious@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/mojolicious.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Mojolicious" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mojolicious+unsubscr...@googlegroups.com.
>> To post to this group, send email to mojolicious@googlegroups.com.
>> Visit this group at https://groups.google.com/group/mojolicious.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] MUA::Transactor::add_generator

[Stefan Adams]

Thanks, Dan!  I updated the gist
<https://gist.github.com/s1037989/479087c752d7461d3499c12971636678> with
your recommendation, and my new synopsis is this:

Mojo::AWS::Signature4->add_generator($ua => 'sign');
my $tx = $ua->build_tx(GET => '...' => sign => {service => 'ec2'});


Does add_generator feel like the right method name for this?  Maybe
apply_generator, instead?

On Tue, Mar 12, 2019 at 4:45 PM Dan Book  wrote:

> That seems like the appropriate mechanism to me. If you want to provide a
> convenience method, I would instead provide one that takes the $ua object
> and an optional generator name, and calls ->add_generator itself. It would
> also be subclassable since it could call a method on $self instead of
> __PACKAGE__.
> -Dan
>
> On Tue, Mar 12, 2019 at 5:22 PM Stefan Adams  wrote:
>
>> I built a generator for AWS Signature4 requests
>> <https://gist.github.com/s1037989/479087c752d7461d3499c12971636678>.
>> This generator calculates a signed Authorization header for the request.
>> Is this a good use of the Transactor generator feature?
>>
>> As you can see from L13
>> <https://gist.github.com/s1037989/479087c752d7461d3499c12971636678#file-ec2-t-L13>
>> of the supplied test, I make my generator available this way:
>>
>> $ua->transactor->add_generator(Mojo::AWS::Signature4::generator);
>>
>>
>> Is this the best mechanism available to share this generator, or is there
>> a recommended standard convention?  When I go to document it for
>> publishing, is that what I should have in the synopsis section?  It almost
>> feels like there should be a plugin mechanism for Mojo::UserAgent.
>>
>> Thanks for any advice and comments you have!
>>
>> Stefan
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Mojolicious" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mojolicious+unsubscr...@googlegroups.com.
>> To post to this group, send email to mojolicious@googlegroups.com.
>> Visit this group at https://groups.google.com/group/mojolicious.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] MUA::Transactor::add_generator

[Stefan Adams]

I built a generator for AWS Signature4 requests
.  This
generator calculates a signed Authorization header for the request.  Is
this a good use of the Transactor generator feature?

As you can see from L13

of the supplied test, I make my generator available this way:

$ua->transactor->add_generator(Mojo::AWS::Signature4::generator);


Is this the best mechanism available to share this generator, or is there a
recommended standard convention?  When I go to document it for publishing,
is that what I should have in the synopsis section?  It almost feels like
there should be a plugin mechanism for Mojo::UserAgent.

Thanks for any advice and comments you have!

Stefan

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] Re: Convert XML to Perl data structure with Mojo::DOM

[Stefan Adams]

I'm dealing with SOAP data and found that this meets my needs:

$self->ua->post_p(@_)->then(sub {
  *SOAP::Deserializer->deserialize(shift->result->dom)->result*
});


That generates a complex Perl data structure -- exactly what I want.  I
reckon there's a way to re-implement this with Mojo?

On Sun, Feb 24, 2019 at 11:47 AM Stefan Adams  wrote:

> Is it possible to recursively convert an XML string into a Perl data
> structure with Mojo::DOM?
>
> Something like:
>
> 
> M1N1
> M2N2
> M3N3
> 
>
> Into:
>
> {a => {x => [{m => 'M1', n => 'N1'}, {m => 'M2', n => 'N2'}], y => [{m =>
> 'M3', n => 'N3'}]}
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] Convert XML to Perl data structure with Mojo::DOM

[Stefan Adams]

Is it possible to recursively convert an XML string into a Perl data
structure with Mojo::DOM?

Something like:


M1N1
M2N2
M3N3


Into:

{a => {x => [{m => 'M1', n => 'N1'}, {m => 'M2', n => 'N2'}], y => [{m =>
'M3', n => 'N3'}]}

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Mojo::URL encoding of space in query parameters

[Stefan Adams]

I'm not an RFC wizard, but I've seen this come up before and it's an
excellent question.

$ perl -MMojo::Parameters -E 'say Mojo::Parameters->new(var=>"a b")'
var=a+b
$ perl -MMojo::Parameters -E 'say Mojo::Parameters->new("a b")->to_string'
a%20b

This struck me as interesting, so I dug into RFC3986
 (as referenced by Mojo::Parameters
) and I see this from section
3.4 :

However, as query components are often used to carry identifying
information in the form of "key=value" pairs and one frequently used value
is a reference to another URI, *it is sometimes better for usability to
avoid percent- encoding those characters*.


So, given that bold, I take it to mean that Mojo::Parameters decided to go
for what's "sometimes better".  :)

On Wed, Feb 20, 2019 at 8:55 AM Lars Thegler  wrote:

> Hi,
>
> I would have expected
>
>   Mojo::URL->new(...)->query(var=>'a b')
>
> to return
>
>   ...?var=a%20b
>
> but instead it does
>
>   ...?var=a+b
>
> Is this as intended? It's not how RFC3986 specifies it, as far as I can
> tell.
>
> /Lars
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Time limit a slow process?

[Stefan Adams]

On Fri, Feb 8, 2019 at 7:36 AM Jason Crowther 
wrote:

> doSlowWork()  doesn't need to return anything (output is polled for
> elsewhere.)
>

Is Minion  an option for you?  By
default it depends on a Pg instance, but I'm pretty sure that there's at
least a SQLite backend available on CPAN as well.

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Need help with stashing data and retrieving it in the template

[Stefan Adams]

Take a look at this Advent Calendar blog post
.
Specifically, "Web Apps" at the bottom.

On Thu, Feb 7, 2019 at 11:57 AM Ron Bergin  wrote:

> Note: I cross posted this question on perlmonks
> https://perlmonks.org/?node_id=1229558
>
> On Thursday, February 7, 2019 at 9:48:20 AM UTC-8, Ron Bergin wrote:
>>
>> I'm brand new to Mojolicious and working on a lite script that goes to 75
>> urls and retrieves text in an h3 tag. I've worked up a working test script
>> that outputs to console and now I'm working on adjusting it to be a web app
>> but I can't seem to get the correct syntax to store/retrieve the data.
>> What am I doing wrong?
>>
>> #!/usr/bin/perl
>>
>> use Mojolicious::Lite;
>>
>> my @urls  = (
>> 'https://mojolicious.org',
>> 'https://metacpan.org',
>> 'https://perlmonks.org',
>> 'http://www.google.com',
>> );
>>
>> get '/titles' => sub {
>> my $ua= Mojo::UserAgent->new;
>> my $async = Mojo::IOLoop::Delay->new;
>>
>> $async->steps(
>> sub {
>> my $self = shift;
>> $ua->get($_, $self->begin) for @urls;
>> },
>> sub {
>> my ($self, @tx) = @_;
>> my $titles  = [];
>>
>> foreach (@tx) {
>> my $title  = '';
>> my $status = $_->res->is_success ? 'Connected' : $_->
>> error->{message};
>>
>> if ( $_->res->is_success ) {
>> $title = $_->res->dom->at('title')->text;
>> $title =~ s/^\s+|\s+$//g; # couldn't get Mojo::Util
>> trim function to work
>> }
>>
>> push @$titles, {host => $_->req->url->host, status =>
>> $status, title => $title};
>> }
>> $self->stash(titles => $titles);
>> }
>> );
>> } => 'titles';
>>
>> app->start;
>>
>> __DATA__
>>
>> @@ titles.html.ep
>> % layout 'titles';
>>
>> %= dumper stash('titles')
>>
>> 
>> 
>>   Host
>>   Status
>>   Title
>> 
>>
>> 
>> % for my $server ( stash('titles') ) {
>>   
>> <%= $server->{host} %>
>> <%= $server->{status} %>
>> <%= $server->{title} =%>
>>   
>> % }
>> 
>>
>> @@ layouts/titles.html.ep
>> 
>>
>> 
>>
>> 
>>   Titles
>> 
>>
>> 
>> Titles
>> <%= content =%>
>> 
>>
>> 
>>
>>
>> Here's the output:
>>
>>> $ ./titles_web.pl get /titles
>>> [Thu Feb  7 09:45:54 2019] [debug] GET "/titles" (fcf21ce8)
>>> [Thu Feb  7 09:45:54 2019] [debug] Routing to a callback
>>> [Thu Feb  7 09:45:54 2019] [debug] Rendering template "titles.html.ep"
>>> from DATA section
>>> [Thu Feb  7 09:45:54 2019] [debug] Rendering template
>>> "layouts/titles.html.ep" from DATA section
>>> [Thu Feb  7 09:45:54 2019] [debug] 200 OK (0.00267s, 374.532/s)
>>> 
>>>
>>> 
>>>
>>> 
>>>   Titles
>>> 
>>>
>>> 
>>> Titles
>>>
>>> undef
>>>
>>>
>>> 
>>> 
>>>   Host
>>>   Status
>>>   Title
>>> 
>>>
>>> 
>>>   
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>
>>> 
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Using Mojolicious::Sessions for Non-Session Cookies

[Stefan Adams]

Build a MyCookie module that works like Mojolicious::Sessions
, and a helper
"mycookie" that does what "session" does
,
but using MyCookie.

Here's my prototype attempt
 at it.
I think it should be crafted as a plugin and of course you'll want to
modify the logic so that it behaves as you intend.  But the prototype, at
least, demonstrates how it could be done completely independently from
Mojo's session cookie.

On Fri, Feb 1, 2019 at 5:04 PM Viktor Nacht  wrote:

> I really love the "it just works" interface of Mojo's session cookie, and
> I was disappointed that I can't use that same kind of approach to other
> cookies. I wrote a helper to de/serialize my non-session cookies
> automatically, but that's still a step away from the amazing awesomeness of
> sessions. Is there a way I haven't thought of yet to use
> a Mojolicious::Sessions object for a non-session cookie that won't
> interfere with the normal sessions' expiration and values, etc?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Mojolicious::Lite routes organization

[Stefan Adams]

Hi!  See this recent thread
 in
this Mailing List.

On Mon, Jan 28, 2019 at 3:08 AM mikem  wrote:

> Hi Guys,
>
> I'm using Mojolicious::Lite to build a simple API for a project. This is
> my code:
>
>
> -
> app.pl
>
> -
> use Mojolicious::Lite;
>
> push @{ app->routes->namespaces }, 'MyAPI';
>
> (get '/products/list')->to('Products#list');
> (get '/products/add')->to('Products#add');
>
> -
>
>
> -
> MyAPI::Products.pm
>
> -
> package MyAPI::Products;
>
> use Mojo::Base 'Mojolicious::Controller';
>
> sub list {
>   my $self = shift;
>   $self->render(json => { hello => 'list' });
> }
>
> sub add {
>   my $self = shift;
>   $self->render(json => { hello => 'add' });
> }
>
> 1;
>
> -
>
> This works great and let me split my routers into several different files
> (keeping the simplicity of Mojolicious::Lite. My question is:
>
> Instead of having to register all my routers in app.pl and map them into
> the .pm files, can't I use a wild card for that? Something like:
>
>
> -
> (any '/products/*url')->to(cb => sub {
>   my $c= shift;
>   my $url = $c->param('url');
>   print STDERR "### $url\n";
>
>   ??
> });
>
> -
>
> With this, I have on the $url vbl what I need for the routing, I just
> can't figure out how to translate that into the correct method on the
> controller (MyAPI::Products::list for example).
>
> Thanks for the help.
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Alternative layout Directories

[Stefan Adams]

Looks hard-coded to me:
https://github.com/mojolicious/mojo/blob/master/lib/Mojolicious/Renderer.pm#L212

sub _next {
  my $stash = shift;
  return delete $stash->{extends} if $stash->{extends};
  return undef unless my $layout = delete $stash->{layout};
  *return join '/', 'layouts', $layout;*
}

What about this?

templates
└── layouts
├── desktop
└── mobile

@@ home.html.ep
% layout 'desktop/default.html.ep';




On Fri, Jan 25, 2019 at 1:27 AM Viktor Nacht  wrote:

> Is it possible to specify alternative layout directories? Rather than put
> all my layouts in a single directory, I wanted to do something more like
> this:
>
> templates
> ├── desktop
> │   └── layouts
> └── mobile
> └── layouts
>
>
> This is just a very simplified example, not my literal application.
>
> V
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] unit, PSGI and Mojolicous

[Stefan Adams]

I don't know the first thing about PSGI, but Nginx Unit sounds really
interesting!  Thanks for bringing it up!

Try this from the cookbook Plack middleware

and PSGI/Plack
?

use Mojolicious::Lite;use Plack::Builder;
get '/welcome' => sub {
  my $c = shift;
  $c->render(text => 'Hello Mojo!');};

builder {
  enable 'Deflater';
  app->start;};


On Wed, Jan 23, 2019 at 9:48 AM Alex Povolotsky  wrote:

> Hello
>
> There is an app server, from nginx creators, named unit (
> https://unit.nginx.org/). It supports Perl via PSGI, but fails with
> Mojolicious::Lite app.
>
> 2019/01/23 09:41:23.029 [error] 26579#26579 [unit] #4: PSGI: Failed to run
> Perl Application:
> Undefined subroutine ::1 called.
>
> plack run the same app without problem, actually, I've tested a bare
> minimum one
>
> ===
> #!/usr/bin/env perl
> use Mojolicious::Lite;
> get '/' => sub {
> my $c = shift;
> $c->render(text=>'hello');
> };
>
> app->start;
> ===
>
> Basic Plack code runs ok.
>
> I don't have any idea on tracing that error, maybe someone could help?
>
> Alex
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Is there any way to send back result via websocket without waiting all done

[Stefan Adams]

Hi!

It seems to me that you should structure your code such that each command
emits a 'message' event; it appears that you have a single routine which
runs all of your commands and then emits a single message for all of the
output.  Impossible for me to say of course, but that's what I get out of
what I see from your snippet.

Alternatively, backend() needs to be non-blocking and there's a lot behind
the scenes there.

Sorry that's not any help, but I can at least reassure you that what you
are driving towards is definitely possible!  You can definitely send the
result back to the browser via websocket of just one command without
waiting for the others to finish.

This sounds like a project I'd be interested in contributing to if you can
make your code public.  I've worked on similar things in the past,
specifically for monitoring Linux boxes.

On Thu, Jan 17, 2019 at 11:30 PM Peter L  wrote:

> Hi,
>
> I have a network equipment which is similar to the Cisco L3 switch. I use
> mojo to setup a web server on a Linux PC. The browser can send some CLI
> commands via websocket to web server. The web server can run these commands
> on network equipment and send all the results back to the browser via
> websocket. It works. But, It need to take some time to wait for all results
> done. In this case, if I have many CLI commands, it will take a long time
> to wait all results done. I want to send the result back to the browser if
> one command is executed without waiting for the other commands executing.
> Is there any way to do it via websocket?
>
>
>
> websocket "/runcmd" => sub {
>
> $c->shift;
>
> ...
>
> $c->on(message => sub {
>  my ($c, @commands) = @_;
>
>  foreach ( @commands) {
>
>   # back-end to run commands via ssh/telnet session
>   my $ret = backend( $_);
>
>   $c->send( encode_json { result => $ret});
>  }
>
> });
>
> ...
> }
>
> Thanks,
> Peter
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: newbie question about routing

[Stefan Adams]

Seems like you understand your problem and have a well-thought out design
pattern!  I think what you are wanting to accomplish elegantly is exactly
what Mojolicious was built for
<https://mojolicious.org/perldoc/Mojolicious/Guides/Routing#BASICS>!

Your two sample routes can be condensed into one to handle any number of
customers, subclassed from a base class:

  $r->get('/api/v1/:controller/box/:id')->to('#open_box');

$ mojo generate app
   :
$ cat my_app/lib/MyApp.pm my_app/lib/MyApp/Controller/Customer.pm
my_app/lib/MyApp/Controller/Kwikemart.pm
my_app/lib/MyApp/Controller/Ezymart.pm
package MyApp;
use Mojo::Base 'Mojolicious';
sub startup {
  my $self = shift;
  my $r = $self->routes;
  $r->get('/api/v1/:controller/box/:id')->to('#open_box');
}
1;
package MyApp::Controller::Customer;
use Mojo::Base 'Mojolicious::Controller';
sub open_box { die "open_box method not implemented by subclass" }
1;
package MyApp::Controller::Kwikemart;
use Mojo::Base 'MyApp::Controller::Customer';
sub open_box {
  my $self = shift;
  $self->render(text => 'Hello, Kwikemart Customer!');
}
1;
package MyApp::Controller::Ezymart;
use Mojo::Base 'MyApp::Controller::Customer';
sub open_box {
  my $self = shift;
  $self->render(text => 'Welcome to Ezymart!');
}
1;
$ perl my_app/script/my_app routes
/api/v1/:controller/box/:id  GET  apiv1controllerboxid
*$ perl my_app/script/my_app get /api/v1/kwikemart/box/1*

*Hello, Kwikemart Customer!*
*$ perl my_app/script/my_app get /api/v1/ezymart/box/1*

*Welcome to Ezymart!*

On Wed, Jan 2, 2019 at 9:04 PM  wrote:

> Hey, no problem. Mojolicious so far, can do just about anything I can
> think of, without much difficulty, as most stuff just work out of the box,
> which is a pleasant surprise.
>
> If you don't mind, I'll take a step back, and describe my design and
> reason behind it, and see if you can maybe spot something that's wrong with
> my approach. Here's the hypothetical scenario:
>
> 1. Two customers, one Kwikemart, and one Ezymart, they both handle boxes,
> but in different ways, one open it with a cutter, say, and the other one
> insist on using bare hands.
> 2. So I build one Customer class, and extend it, to implement actual
> customer. Both Kwikemart and Ezymart are children of Customer class, and
> each has a open_box() method, but within it, they each do their own thing.
> 3. In order to expose the boxes' content as RESTful resource, the url to
> access them, will be something like /api/v1/:customer/box/:boxid
>
> Of course, I could just code the route explicitly, since there's only two
> customer, by having:
>
>
>  $r->get('/api/v1/kwikemart/box/:id')->to('Customer::Kwikemart#open_box');
>  $r->get('/api/v1/ezymart/box/:id')->to('Customer::Ezymart#open_box');
>
> However, it just feels not elegant. The name of the class, is the only
> difference between the two different routes, and it'll be great to
> generalize it within the dispatching process, so if I have hundreds
> customers to do tomorrow, each of their own variants of 'open_box()'
> action, can be routed with just one call, instead of hundreds, as long as
> the url conforms to the '/api/v1/:customer/box/:id' format.
>
> Maybe I am just trying to be too clever for my own good, but I really
> think there must be an easy and elegant way to do this?
>
>
>
>
> On Wednesday, January 2, 2019 at 4:27:44 PM UTC-6, Stefan Adams wrote:
>>
>> Hi!  I'm glad you were able to figure that out and even using the more
>> advanced hook feature, but if I'm understanding your objective correctly, I
>> would advise that you follow the references I shared.  In essence, if I'm
>> reading it correctly, you are using a framework and then solving problems
>> on your own which are already solved by the framework.
>>
>> I just want to make sure you get off to a good start with Mojolicious so
>> that you can reap the full benefits of the framework and not become
>> irritated that it's not doing things that you want easily -- essentially
>> questioning why you're using this framework in the first place.  :)
>>
>> I'd recommend starting with a Mojolicious::Lite app.
>>
>> Start with the Hello World
>> <https://mojolicious.org/perldoc/Mojolicious/Guides/Tutorial#Hello-World>
>> in the Tutorial.  And then expand it for your needs, perhaps like so:
>>
>> #!/usr/bin/env perluse Mojolicious::Lite;
>> get '/:customer' => sub {
>>   my $c = shift;
>>   $c->render(inline => 'Hello, <%= param "customer" %>!');};
>>
>> app->start;
>>
>>
>> Also, just to show some other equivalent ways to do the same thing:
>>
>> #!/usr/bin/env perluse Mojolicious::Lite;
>> get '/:custome

Re: [Mojolicious] newbie question about routing

[Stefan Adams]

Hi!  Welcome to the group and to Mojolicious!

For your specific question, see Mojolicious::Routes::Route->to
 and the
bottom part of the Optional Placeholders

section of the Routing Guide
, specifically:

# /   -> {controller => 'foo',   action => 'bar'}# /users
-> {controller => 'users', action => 'bar'}# /users/list ->
{controller => 'users', action => 'list'}
$r->get('/:controller/:action')->to('foo#bar');

Special stash values like controller and action can also be placeholders,
which is very convenient especially during development, but should only be
used very carefully, because every controller method becomes a potential
route. All uppercase methods as well as those starting with an underscore
are automatically hidden from the router and you can use "hide" in
Mojolicious::Routes
 to add additional
ones.

To know more, please definitely read the Tutorial
 and all of the Guides
.  But if you have any more
questions, please don't hesitate to ask for Support
.

On Wed, Jan 2, 2019 at 4:54 AM  wrote:

> Hi. I want to route a request to a controller that's dynamically
> constructed, base on a place holder in the url. To illustrate, I want do
> something like the following:
>
> use Mojo::Base 'Mojolicious';
>
> sub startup {
>
> my $r = $self->routes;
>
>my $route = $r->get('/:customer/boxs/:id');
>
>
> [ somehow, extract the :customer holder into a variable $customer, then ]
>
>$route->(
>
> controller => "$customer::boxs',
>
> action => 'get_list',
>
> );
>
> }
>
>
> I tried but can't seem to find way to this, and I'm not sure if this is
> possible?
> Some pointer is appreciated. Thanks.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] Mojo::ByteStream->split

[Stefan Adams]

Any chance the following update to Mojo::ByteStream->split would be
accepted?

sub split {
  my ($self, $pattern, $limit) = @_;
  return Mojo::Collection->new(map { $self->new($_) } split $pattern,
$$self, $limit//0);
}


My reason for needing this is that I need to parse a file into columns and
some of the columns at the end of a line are empty and being discarded.

$ perldoc -f split

If LIMIT is omitted (or, equivalently, zero), then it is usually
treated as if it were instead negative but with the exception
that
*trailing empty fields are stripped* (empty leading fields are
always preserved); if all fields are empty, then all fields are
considered to be trailing (and are thus stripped in this case).
Thus, the following:

print join(':', split(',', 'a,b,c,,,')), "\n";

produces the output 'a:b:c', but the following:

*print join(':', split(',', 'a,b,c,,,', -1)), "\n";*

*produces the output 'a:b:c:::'.*

I need to be able to get that last bold, and therefore need to pass -1 as
the limit.

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] plugin for scheduling Minion jobs (cron backend)

[Stefan Adams]

On Sat, Dec 15, 2018 at 12:31 PM sri  wrote:

> a) you can now just use cron to enqueue unique jobs for you, and
>>
>
Hmm...  I think you mean this command?

./myapp.pl minion job -e foo -P 10023 -P 10024 -p 5 -q important

So if I wanted the Mojolicious app to control the schedule, it would need
to maintain the Mojolicious app's running-user crontab file.

My app would need to do something along the lines of:

(crontab -l ; echo "0 * * * * /path/to/myapp.pl minion job -e foo -P 10023
-P 10024 -p 5 -q important") | crontab -


A plugin could be written to handle this with maybe the help of something
like Config::Crontab .  It could
also handle scheduling one-time jobs with `at`.

my $at = app->schedule->at(DateTime => 'job' => [@args]);
my $crontab = app->schedule->recurring('0 * * * *' => 'job' => [@args]);


And the Schedule plugin behind the scenes would execute `at` or `crontab`
accordingly.

You could delete the scheduled job with

app->schedule->remove($at, $contab, ...);


I'm thinking it would also be great to have a Mojo::Pg migrations-like
feature where it would make sure that the crontab has all of the necessary
jobs scheduled each time it launches.

app->schedule->migrations->name('clear_cache')->migrate(0)->migrate;


What do you think?  Does that sound reasonable?

>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Mojolicious - minion worker doesn't start automatically

[Stefan Adams]

OH MY GOSH PLEASE!!  :D

On a maybe related-ish note, it would also be great if there was a way for
a Mojolicious app (or maybe Minion job) to do recurring tasks (think cron)
-- for example, purge a cache every hour on the hour or something...  I
think this was talked about regarding Minion a while back.  It would make
sense for Minion to handle the jobs, and of course the Mojolicious app
would need to be able to queue the job at a specific time via the Minion
plugin.  I haven't been able to do it because my task always ends up
getting scheduled by all of the forked workers.

On Sat, Dec 15, 2018 at 11:45 AM sri  wrote:

> This is a planned feature.
>
> https://github.com/mojolicious/minion/issues/76
>
> --
> sebastian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Mojolicious - minion worker doesn't start automatically

[Stefan Adams]

Sachin, you said you haven't gotten any answer, but I see you and Corion
had an exchange on SO some time earlier than this email.  Grinnz has since
added a little extra as well.  What is currently commented on the
Stackoverflow question between Corion and Grinnz looks like the appropriate
response to me.  Is there anything else you are still needing help with?

On Fri, Dec 14, 2018 at 9:12 PM Sachin Dangol 
wrote:

> I have asked this question on stackoverflow. Haven't got any answer.
> Asking it here. Please help. I think I am missing something fundamental
> here.
>
> 
>
> https://stackoverflow.com/questions/53774276/mojolicious-minion-worker-doesnt-start-automatically
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Odd Behavior with Websocket

[Stefan Adams]

Awesome!  Thank you for sharing the update!

On Sun, Dec 2, 2018 at 9:35 AM john  wrote:

>
> On 11/27/18 12:24 PM, john wrote:
> >>
> >> I created an application which I feel reproduces the problem.   If I
> >> use Mojo::IOLoop::Subprocess in a specfic way it causes the Websocket
> >> code to behave erratically.   I feel like I am using the framework as
> >> intended but if not this will hopefully provide some insight into
> >> what I am doing wrong.
> >>
> >>
> This issue is now resolved based on feedback in this issue:
>
>  https://github.com/mojolicious/mojo/issues/1297
>
> Per that thread I changed my code by storing the Websocket's PID and
> then comparing it to the PID that emitted the on finish event.
>
> websocket '/ws' => sub {
>  my $self = shift;
>
>  my $me = $$;
>
>  app->log->debug(sprintf 'Client connected: %s', $self->tx);
>
>  $self->on(finish => sub {
>  return unless $$ == $me;
>  app->log->debug('Client disconnected');
>  });
> };
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Call for posts: Advent Calendar 2018!

[Stefan Adams]

Hi, Joel!  I'd be happy to submit this as a PR or whatever is most
preferred.  You added me to the mojoliciousio repo, but then when I clicked
on it, the invitation was gone -- not sure if that was intentional.

Anyway, attached in my article.  I don't want to call it done, because my
bonus sections aren't really done.  I either need to do a little better, or
remove them.  Also, I have some footnotes at the beginning where I should
put in some better information.  Last, I'm not sure if mermaid markdown is
going to render on the statocles site: but I thought it was a super cool
way to include a markdown flow chart for a visualization.  I edited my
document using StackEdit.io, and mermaid was a supported feature there.

So, I wanted to send this to you for a quick review for your feedback on
those points or any others.  Also, to show you that I was indeed serious
about writing an article and I have indeed done so, it's basically ready to
go today, I'd probably just want to remove the Bonuses if I were to do
nothing else.

I hope this is an article that can qualify well enough for the advent
calendar!  If it's the type of topic and writing that you had in mind, then
I have a couple more ideas that I could try to crank out if you needed a
few more slots filled.

On Sat, Nov 3, 2018 at 3:54 PM Joel Berger  wrote:

> Hello Everyone,
>
> As I mentioned at Mojoconf, I am hoping to run the advent calendar again
> this year, but I cannot do nearly as much work on it as last year, both for
> sanity and personal reasons. Therefore I'm looking to you to help me out
> with contributions. I've already gotten submissions from two authors, more
> ideas from another few of you. Well now's the time! If you want in, and if
> you want to be sure the calendar happens and is a success, start getting
> those posts to me. I don't have a firm deadline, but I need probably 10 or
> so in to me before the end of the month in order to go ahead, and probably
> at least 10 more by publishing date, whenever that is. I'll commit to 5.
>
> As to topics, I think we have promises covered, indeed I'm going to send
> out an email to those of you who want to do articles on promises so that we
> can coordinate. I myself am taking the Async/Await pattern and hopefully
> library announcement.
>
> Other topics can include anything from your library, your favorite
> library, your favorite pattern, something you use Mojo for, or whatever
> else you want to write about. Remember, even if what you do with
> Perl/Mojo/The Web seems ordinary, it isn't ordinary to everyone else. We
> all do different things and what seems mundane to you every day will be
> fascinating to others.
>
> I'll be taking submissions in markdown format. Please use 4 space
> indentation for code blocks as the markdown renderer hasn't caught up with
> github flavor code fences.
>
> Please include a short but engaging title and at least a few paragraphs of
> text.
>
> Every article should come either with an image or an idea for an image,
> for the top banner and other marketing (think twitter). If that image is
> included, I need to have a link to the source, which must be appropriately
> licensed. Searching on wikimedia is a great way to start or else searching
> on google images with the license filter on. See last year's calendar for
> how that looks.
>
> If you didn't contribute last year, please include your full name (or how
> you'd like to be credited), with a sentence or two about yourself, and a
> gravatar url or image (if desired).
>
> You may submit as PRs to the github repo (
> https://github.com/jberger/mojolicious.io) or emailed to me. Don't worry
> about getting the dates or metadata right, we'll figure that all out. And
> please contact me if you have any trouble or questions.
>
> Cheers,
>
> Joel Berger
>
> P.S. If authors submit articles but we don't get enough, they will still
> get published, it just may not be structured as a calendar. Don't worry,
> contributions will not be wasted either way.
>
> P.P.S. ... but calendars are more fun, submit something and help us get
> there!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

# Automating Mojo::ACME for continuous free 

Re: [Mojolicious] Odd Behavior with Websocket

[Stefan Adams]

Is it possible that the issue you are experiencing is related to this
 and which was assumed to
be solved by this , and
therefore possibly a direct consequence of that commit?  kraih intended to
deprecate pubsub and jberger swooped in to save the day, but it seems that
it was known to be not well tested (just my observation from the mailing
list / GitHub issues).

Are you experiencing these issues with Mojo::Pg 4.11?  Seems the answer to
that would shed a lot of light on the above.

On Mon, Nov 26, 2018 at 9:38 PM john  wrote:

> Hello,
>
> I have controller code that subscribes to Mojo::Pg::PubSub messages and
> sends messages via Websocket based on that subscription.  However, It
> appears to me that the Websocket on finish is getting hit when a
> Mojo::PubSub messages comes in to listen handler.  Even then the
> Websocket is not really closed. If I comment out the pubsub->unlisten
> more messages come in and get delivered to the client.
>
> Yeah, I am doing something wrong.   I have not distilled it down to a
> simple scenario so it could be my problem originates outside this code.
>
> The "output" sub is where I see this behavior:
>
>
> https://github.com/john-/telem_control/blob/084347f18bdfd69ae6b32b20fc7013786ac23bce/lib/TelemControl/Controller/Main.pm#L21
>
> Every time a message comes in the on finish for the Websocket is hit.
> Typical log pattern:
>
> [2018-11-26 21:27:57.82505] [2976] [debug] WebSocket for details closed
> in output handler(1006)
> [2018-11-26 21:27:59.07773] [2955] [debug] item to let client know about
> (pubsub): audio
>
> This same pattern repeats for every message that comes in via pubsub.
>
> Yes, there is probably more happening here than I am saying but that is
> what I understand at the moment.
>
> I am using Mojolicious-8.07 and Mojo-Pg-4.12.
>
> Thanks,
>
> John
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Pg::PubSub in full application

[Stefan Adams]

On Sat, Nov 24, 2018 at 11:09 AM sri  wrote:

> This might now be resolved with the 4.12 release.
>>
>
> https://metacpan.org/release/SRI/Mojo-Pg-4.12
>

Yay!!  I'm so glad this didn't get deprecated!!

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] What about an after_server_start hook?

[Stefan Adams]

"During startup your application is preloaded in the manager process, which
does not run an event loop"

So it looks like what I was hoping for is not possible.  :(

On Fri, Nov 23, 2018 at 8:13 PM Stefan Adams  wrote:

> Ah, shoot.  That kicks off for every worker process.  Any way to do
> something where it runs just in the manager process?
>
> On Fri, Nov 23, 2018 at 8:10 PM Stefan Adams  wrote:
>
>> Ah!  How cool!  Thank you for that!  That's gives me better context now
>> for understanding the purpose and value of next_tick.  :)
>>
>> On Fri, Nov 23, 2018 at 8:04 PM Dan Book  wrote:
>>
>>> You can set up code to be run whenever the ioloop is started, which
>>> happens in each worker process when it starts in a prefork server, by
>>> adding a next_tick callback as indicated here:
>>> https://metacpan.org/pod/Mojolicious::Guides::Cookbook#Pre-forking
>>>
>>> -Dan
>>>
>>> On Fri, Nov 23, 2018 at 6:24 PM Stefan Adams  wrote:
>>>
>>>> Sometimes it would be nice to have an event / hook for after the server
>>>> has started.  Specifically, I'd want to kick off an automated process with
>>>> Mojo::IOLoop->timer|recurring but only after the web server has started.
>>>>
>>>> Is this possible?  And if not, is it a Pull Request that would be
>>>> considered?
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Mojolicious" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to mojolicious+unsubscr...@googlegroups.com.
>>>> To post to this group, send email to mojolicious@googlegroups.com.
>>>> Visit this group at https://groups.google.com/group/mojolicious.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Mojolicious" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to mojolicious+unsubscr...@googlegroups.com.
>>> To post to this group, send email to mojolicious@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/mojolicious.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] What about an after_server_start hook?

[Stefan Adams]

Ah, shoot.  That kicks off for every worker process.  Any way to do
something where it runs just in the manager process?

On Fri, Nov 23, 2018 at 8:10 PM Stefan Adams  wrote:

> Ah!  How cool!  Thank you for that!  That's gives me better context now
> for understanding the purpose and value of next_tick.  :)
>
> On Fri, Nov 23, 2018 at 8:04 PM Dan Book  wrote:
>
>> You can set up code to be run whenever the ioloop is started, which
>> happens in each worker process when it starts in a prefork server, by
>> adding a next_tick callback as indicated here:
>> https://metacpan.org/pod/Mojolicious::Guides::Cookbook#Pre-forking
>>
>> -Dan
>>
>> On Fri, Nov 23, 2018 at 6:24 PM Stefan Adams  wrote:
>>
>>> Sometimes it would be nice to have an event / hook for after the server
>>> has started.  Specifically, I'd want to kick off an automated process with
>>> Mojo::IOLoop->timer|recurring but only after the web server has started.
>>>
>>> Is this possible?  And if not, is it a Pull Request that would be
>>> considered?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Mojolicious" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to mojolicious+unsubscr...@googlegroups.com.
>>> To post to this group, send email to mojolicious@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/mojolicious.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Mojolicious" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mojolicious+unsubscr...@googlegroups.com.
>> To post to this group, send email to mojolicious@googlegroups.com.
>> Visit this group at https://groups.google.com/group/mojolicious.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] What about an after_server_start hook?

[Stefan Adams]

Ah!  How cool!  Thank you for that!  That's gives me better context now for
understanding the purpose and value of next_tick.  :)

On Fri, Nov 23, 2018 at 8:04 PM Dan Book  wrote:

> You can set up code to be run whenever the ioloop is started, which
> happens in each worker process when it starts in a prefork server, by
> adding a next_tick callback as indicated here:
> https://metacpan.org/pod/Mojolicious::Guides::Cookbook#Pre-forking
>
> -Dan
>
> On Fri, Nov 23, 2018 at 6:24 PM Stefan Adams  wrote:
>
>> Sometimes it would be nice to have an event / hook for after the server
>> has started.  Specifically, I'd want to kick off an automated process with
>> Mojo::IOLoop->timer|recurring but only after the web server has started.
>>
>> Is this possible?  And if not, is it a Pull Request that would be
>> considered?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Mojolicious" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mojolicious+unsubscr...@googlegroups.com.
>> To post to this group, send email to mojolicious@googlegroups.com.
>> Visit this group at https://groups.google.com/group/mojolicious.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] What about an after_server_start hook?

[Stefan Adams]

Sometimes it would be nice to have an event / hook for after the server has
started.  Specifically, I'd want to kick off an automated process with
Mojo::IOLoop->timer|recurring but only after the web server has started.

Is this possible?  And if not, is it a Pull Request that would be
considered?

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] $c->req->env Empty

[Stefan Adams]

I would say, yes, this is normal.

>From Mojo::Message::Request#env
:

Direct access to the CGI or PSGI environment hash if available.


Sounds like you're probably not using CGI or PSGI.

On Fri, Nov 9, 2018 at 3:29 AM Viktor Nacht  wrote:

> In my Mojolicious::Lite app $c->req->env is completely empty under Morbo
> and under Hypnotoad behind an Apache reverse proxy. Is this normal or am I
> totally missing something?
>
> V
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Executing tasks in the backend ?

[Stefan Adams]

On Wed, Nov 7, 2018 at 1:18 PM Luc Larochelle  wrote:

> Hi Everyone,
>
> Given that application X is owned by it's generic user (userX) and that a
> Webapp is owned by another generic user(Y), what's the best way to share
> permissions between the users so that application X can be called by a a
> request to the WebApp ?
>

Is the primary question about the best way to handle permissions between
two users?  IMO, either put both users in the same group, or use extended
ACLs .  I used
to use them quite a bit when I managed file servers with Samba and it was
great!


> Also, is it a good thing to separate applications from the Webapp in
> distinct users , or should it all be part of a whole ?
>

I think the general rule of thumb is separations are good, but of course
you need something in place to allow exchange of information.  ACLs work.
Other things could work, too.  But ACLs proly easiest.  Best answer proly
depends on a lot...

The objective to what you're asking, of course, is if one of your systems
gets hacked, the other shouldn't be affected.  If the system A gets hacked
with user A, system B with user B will be "protected".  Is system A and
system B both use user C, a breach of system A *or* system B would effect
the other.

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Mojolicious::Plugin::JSUrlFor

[Stefan Adams]

I have (tho large is very relative :). I think the biggest specific concern
is that it may break with deprecations in Mojolicious.

I'd suggest reaching out to the author to see if they are still able to
maintain it if you submit a bug report or PR, or if they would be willing
to transfer it to you. Alternatively, you could fork it.

On Thu, Nov 1, 2018, 5:33 PM Viktor Nacht  Has anyone used this project in a larger project? It fits my philosophy
> perfectly, but I'm concerned it hasn't been updated recently. It definitely
> fills a niche for maximum freedom of route management. - V
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Mojo::UserAgent URL with caret '^' not encoded

[Stefan Adams]

On Wed, Oct 31, 2018 at 9:34 PM Sylvain Thibault 
wrote:

> As suggested, here is a working solution using a Role::Tiny role to
> modify/override Mojo::Parameters::to_string so that it does not escape the
> caret '^' character.
> Feel free to comment/criticize.
>

That looks terrific to me and pretty much exactly what I'd do!


> Thank you all for your valuable input, this was enlightening.
>

Heck yeah!  I learned an important lesson myself!  Thanks for your
question!

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Mojo::UserAgent URL with caret '^' not encoded

[Stefan Adams]

On Wed, Oct 31, 2018 at 12:19 PM Dan Book  wrote:

> Mojo::Collection and Mojo::File are not hash-based objects so they cannot
> use Mojo::Base, thus they implement with_roles themselves. Mojo::Base based
> objects all say "inherits all methods from Mojo::Base" or a subclass of
> that.
>

This is really helpful!  Thank you for clearing that up!

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Mojo::UserAgent URL with caret '^' not encoded

[Stefan Adams]

On Wed, Oct 31, 2018 at 10:48 AM sri  wrote:

> Poking into internals usually means one day you'll get what you asked for,
>> but if there is no other way...
>>
>
> Yes, that is a very dangerous hack, a more sane approach would be to use a
> Role::Tiny role modifying
> Mojo::Parameters::to_string
> ($tx->req->url->query->with_roles('+Unescaped')) or something similar.
>

Yes!  I love this strategy!  Existing packages like Mojo::Collection and
Mojo::File already have with_roles available, but Mojo::Parameters does
not.  Does it make sense to add that, or is it really that simple to just
add it independently and the reason why with_roles is available to these
other packages is just for convenience due to the overwhelming likelihood
that they will be used more frequently?

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Mojo::UserAgent URL with caret '^' not encoded

[Stefan Adams]

I see, you are building a client app, not a server app -- I missed that
detail.

And, I see that you want to pass the ^ *without* escaping it.

Your URL is getting parsed by Mojo::URL, whose parameters are getting
parsed by Mojo::Parameters, and when you get the parameters as a string
, url_escape
 is being applied:

Percent encode unsafe characters in string as described in RFC 3986
, the pattern used defaults to
^A-Za-z0-9\-._~.


Reading the code for to_string in Mojo::Parameters, I see no way around
this.  It would seem that Yahoo Finance is not RFC 3986 compliant.  The
question that needs to be asked then is, "Is it possible for Mojo::URL to
customize the characters that are considered unsafe?"  I don't know super
advanced Perl like this, but maybe it's possible to override a function and
make Mojo::Util::url_escape not actually escape the string?

There might be a more advanced way to build your transaction, one that
doesn't operate on a Mojo::URL object which will ultimately apply
url_escape without question -- but I wouldn't know it.

Anyway, from what I can see, there's not a solution to your problem.  :(


On Sun, Oct 28, 2018 at 11:49 AM Sylvain Thibault 
wrote:

> Thank you for your response Stefan.
> Here is the complete code.  Symbol SPY works, symbol ^GSPC returns not
> found.
>
> This curl command with the ^GSPC symbol works:
>
> curl -s -o - -N -v 'https://streamerapi.finance.yahoo.com/streamer/1.0?s=
> ^GSPC=l86,l84,p20=parent.yfs_u1f=parent.yfs_mktmcb=parent.yfs_gencb=1=en-US=US=0'
>
>
> #! /usr/bin/env perl
> use Mojo::UserAgent;
> use feature qw(say);
>
> $| = 1;
>
> # Accept responses of indefinite size
> my $ua = Mojo::UserAgent->new(max_response_size => 0);
> $ua->inactivity_timeout(0);
>
> my $url_raw
> # Symbol ^GSPC returns NOT FOUND
> #  = 'https://streamerapi.finance.yahoo.com/streamer/1.0?s=
> ^GSPC=l86,l84,p20=parent.yfs_u1f=parent.yfs_mktmcb=parent.yfs_gencb=1=en-US=US=0';
>   = '
> https://streamerapi.finance.yahoo.com/streamer/1.0?s=SPY=l86,l84,p20=parent.yfs_u1f=parent.yfs_mktmcb=parent.yfs_gencb=1=en-US=US=0
> ';
>
>
> # Build a normal transaction
> my $tx = $ua->build_tx(
>   GET => $url_raw,
>   => {Accept => '*/*'}
> );
>
> # Remove caret encoding... results is not found... ???
> say $tx->req->to_string;
>
> # Replace "read" events to disable default content parser
> $tx->res->content->unsubscribe('read')->on(
>   read => sub {
> my ($content, $bytes) = @_;
> say "Streaming: $bytes";
>   }
> );
>
> # Process transaction
> $tx = $ua->start($tx);
>
>
> say "done";
>
>
>
> On Saturday, October 27, 2018 at 5:38:43 PM UTC-6, Sylvain Thibault wrote:
>>
>> Given URL https://somehost.com.com/streamer/1.0?s=^GSPC
>>
>> When doing a GET, Mojo::UserAgent encodes the caret '^' as %5E
>> The server returns NOT FOUND.
>>
>> So this transaction from Mojo::UserAgent returns NOT FOUND:
>>
>> GET /streamer/1.0?s=%5EGSPC=l86,l84,p20 HTTP/1.1
>> Host: somehost.com
>> Accept: */*
>> User-Agent: Mojolicious (Perl)
>> Content-Length: 0
>>
>> This transaction using curl with the caret not encoded returns the
>> desired output:
>>
>> GET /streamer/1.0?s=^GSPC=l86,l84,p20 HTTP/1.1
>> Host: s omehost.com
>> User-Agent: curl/7.61.1
>> Accept: */*
>>
>> How does one send a caret '^' in a URL without encoding it to %5E ?
>>
>> Using a symbol without a caret works great in the Mojo::UserAgent version
>> of the code.
>>
>> Thanks,
>>
>> Sylvain Thibault
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Mojo::UserAgent URL with caret '^' not encoded

[Stefan Adams]

On Sat, Oct 27, 2018 at 6:38 PM Sylvain Thibault 
wrote:

> How does one send a caret '^' in a URL without encoding it to %5E ?
>
> Using a symbol without a caret works great in the Mojo::UserAgent version
> of the code.
>

Being that we're talking about a query parameter, it seems like we're not
dealing with a routing problem.  Can you see from the log if your action
handler is being processed?  Is so, add `warn $c->param('s')` right after
you set $c to the first parameter and then watch STDERR for what's
contained in the 's' parameter.  Do you have any code in your action
handler that returns a 404, such as $c->reply->not_found?

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Stable version to upgrade to

[Stefan Adams]

On Tue, Oct 23, 2018, 10:44 PM Ganesh Udupa  wrote:

> Thanks for the quick response. I appreciate. The reason I asked is that I
> saw multiple minor updates in 8.x in a short period. ( I dont know if this
> is how it was in older major versions )
>

In my experience this is very normal, and IMO exciting!

Is the last release of 7.x a better option  (thanks for that comment) or
> should I use 8.04?
>

IMO and based on the feedback that I see frequently from the core Dev team:
always run the latest release. However, maybe I've drawn that conclusion
too far. Perhaps they only expect that with respect to submitting bug
reports. i.e. if you are running the latest 7.x and want to report a bug,
first validate that it is still a bug in the latest 8.x release, because if
it isn't, the bug has already been identified and patched.

The last 7.x release is super stable, but it doesn't have and won't get
some of the awesome new features going into 8.x. But if you want "stable"
you won't want to use them yet anyway. However, security fixes and bug
fixes go into the current major release. There is no parallel code base
maintenance, it's just a continuous singular stream. Therefore, a "solid"
strategy to stand still at the last prior major version is probably a bad
idea: bugs won't get patched and worse security holes will forever be
security holes.

TL;DR I *think* everyone would agree to always use the most current release
of the current major. Just "follow the rules" and avoid experimental.

I would like to get clarification tho on mid-major deprecation removals. If
you keep your production systems always running the latest release and then
deprecations occur before your production code has had a chance to pass
through your org's process, that could be bad news.

On Wed, Oct 24, 2018 at 8:54 AM Stefan Adams  wrote:
>
>> Define "stable". The latest release is stable in that it works well and
>> passes all tests (thousands of them). It's not "stable" in the sense that
>> the 8.0 release is constantly changing and improving from minor release to
>> minor release, but that should be expected.
>>
>> The core team works very hard to not include any breaking changes within
>> a major version code base, and their excellent tests help validate that.
>> Watch the change log. They label new things that aren't "stable" in terms
>> of API or even longevity as experimental and production deployments are
>> encouraged to avoid those features. Things that will be removed in a future
>> major version are labeled as deprecated.
>>
>> Hmm... One thing: I think I recall that deprecations can occur within a
>> time frame (3 months IIRC) as opposed to being limited to at the next major
>> release. Don't quote me on that. If that were the case, using the last
>> release of the prior major release might be the most stable? If I made that
>> up, you should absolutely always be able to use the most recent release of
>> the current major -- just avoid experimental.
>>
>> Core team: my apologies if I added any unacceptable confusion.
>>
>> On Tue, Oct 23, 2018, 9:54 PM Ganesh Udupa  wrote:
>>
>>> Hi,
>>> We are currently at 5.28.  Can someone recommend a stable latest version
>>> to upgrade to?. Is 8.04 stable?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Mojolicious" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to mojolicious+unsubscr...@googlegroups.com.
>>> To post to this group, send email to mojolicious@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/mojolicious.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Mojolicious" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mojolicious+unsubscr...@googlegroups.com.
>> To post to this group, send email to mojolicious@googlegroups.com.
>> Visit this group at https://groups.google.com/group/mojolicious.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Stable version to upgrade to

[Stefan Adams]

Define "stable". The latest release is stable in that it works well and
passes all tests (thousands of them). It's not "stable" in the sense that
the 8.0 release is constantly changing and improving from minor release to
minor release, but that should be expected.

The core team works very hard to not include any breaking changes within a
major version code base, and their excellent tests help validate that.
Watch the change log. They label new things that aren't "stable" in terms
of API or even longevity as experimental and production deployments are
encouraged to avoid those features. Things that will be removed in a future
major version are labeled as deprecated.

Hmm... One thing: I think I recall that deprecations can occur within a
time frame (3 months IIRC) as opposed to being limited to at the next major
release. Don't quote me on that. If that were the case, using the last
release of the prior major release might be the most stable? If I made that
up, you should absolutely always be able to use the most recent release of
the current major -- just avoid experimental.

Core team: my apologies if I added any unacceptable confusion.

On Tue, Oct 23, 2018, 9:54 PM Ganesh Udupa  wrote:

> Hi,
> We are currently at 5.28.  Can someone recommend a stable latest version
> to upgrade to?. Is 8.04 stable?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Mojo::Pg support anyone?

[Stefan Adams]

Yes, absolutely! Mojolicious, Mojo::Pg, and Minion.

On Wed, Oct 17, 2018, 5:52 AM Alex Povolotsky  wrote:

> Hello!
>
> May I ask here about Mojo::Pg? If not, can anyone point me to the proper
> resource?
>
> Alex
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Reducing daemon memory footprint?

[Stefan Adams]

Wow!  That's fascinating!  Thanks for sharing!  I'm surprised by how much
the memory footprint grows for a minimal perl program to one running M::L!

On Thu, Sep 20, 2018 at 2:57 PM Charlie Brady <
charlieb-m...@budge.apana.org.au> wrote:

>
> Hi Stefan, thanks for trying to help.
>
> I know the perl executable will make some contribution to the memory
> footprint, but not much.
>
> I can measure that separately by running a minimum perl program and
> looking at its resource usage. If I run 'perl -e "<>"', I see this in
> /proc/$pid/status:
>
> ...
> VmPeak: 5476 kB
> VmSize: 5476 kB
> VmLck: 0 kB
> VmPin: 0 kB
> VmHWM:  3184 kB
> VmRSS:  3184 kB
> VmData:  468 kB
> VmStk:   132 kB
> VmExe: 4 kB
> VmLib:  4232 kB
> VmPTE:24 kB
> VmPMD: 0 kB
> VmSwap:0 kB
> Threads:1
> ...
>
> The same data from my M::L daemon is:
>
> ...
> VmPeak:   135548 kB
> VmSize:   133540 kB
> VmLck: 0 kB
> VmPin: 0 kB
> VmHWM: 67016 kB
> VmRSS: 65988 kB
> VmData:86940 kB
> VmStk:   176 kB
> VmExe: 4 kB
> VmLib: 31664 kB
> VmPTE:   132 kB
> VmPMD: 0 kB
> VmSwap:0 kB
> Threads:6
> ...
>
> CPAN has a few modules which might help gather some stats
> (Memory::Process, Memory::Stats, Memory::Usage). '-Dm' flag to perl might
> help too, if perl is compiled with DEBUG enabled.
>
> I notice that I can disable Mojolicious response cacheing; it'll be
> interesting to see what difference that makes.
>
> On Wed, 19 Sep 2018, Stefan Adams wrote:
>
> > I shouldn't involve myself in this topic because I haven't the knowledge,
> > but it sounds fascinating. Wouldn't the majority of the 50MB memory
> > footprint be from the Perl interpreter itself? Wouldn't the question be,
> > how to reduce the size of the Perl interpreter? Different compile
> options?
> > e.g. I remember once compiling a "minimal" perl that was 2MB. I imagine
> > that would probably be insufficient to run Mojolicious, though I really
> > haven't a clue, but it suggests to me that it's possible to reduce the
> size
> > of the perl interpreter and, therefore it seems, the size of the
> > Mojolicious daemon?
> >
> > On Wed, Sep 19, 2018, 8:19 PM Charlie Brady <
> > charlieb-m...@budge.apana.org.au> wrote:
> >
> > >
> > > Some Mojolicious::Lite code I've written has been adapted by another
> group
> > > in my company to run on their embedded controller (limited CPU and
> limited
> > > memory). They are now asking for my advice on how to reduce the memory
> > > footprint of their daemon. It's consuming about 50MB at the moment.
> > >
> > > Does anyone have some advice on where to start looking at where memory
> is
> > > being used and how to minimise it?
> > >
> > > Thanks
> > >
> >
> >
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Reducing daemon memory footprint?

[Stefan Adams]

I shouldn't involve myself in this topic because I haven't the knowledge,
but it sounds fascinating. Wouldn't the majority of the 50MB memory
footprint be from the Perl interpreter itself? Wouldn't the question be,
how to reduce the size of the Perl interpreter? Different compile options?
e.g. I remember once compiling a "minimal" perl that was 2MB. I imagine
that would probably be insufficient to run Mojolicious, though I really
haven't a clue, but it suggests to me that it's possible to reduce the size
of the perl interpreter and, therefore it seems, the size of the
Mojolicious daemon?

On Wed, Sep 19, 2018, 8:19 PM Charlie Brady <
charlieb-m...@budge.apana.org.au> wrote:

>
> Some Mojolicious::Lite code I've written has been adapted by another group
> in my company to run on their embedded controller (limited CPU and limited
> memory). They are now asking for my advice on how to reduce the memory
> footprint of their daemon. It's consuming about 50MB at the moment.
>
> Does anyone have some advice on where to start looking at where memory is
> being used and how to minimise it?
>
> Thanks
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] using mojolicious to make a batch request to google api

[Stefan Adams]

On Mon, Sep 17, 2018 at 9:56 PM Steve Dondley  wrote:

> My bad. Where it says $optional_data, that is actually the $options
> variable. That bit was pasted from a different function. Thanks for getting
> back.
>
> The Google API example shows a "boundary" in the "Content-Type" and a
> "Content-Length."
>

"boundary"...  that sounds like you should be using the multipart generator?

Sorry, I'm completely out of my league here...

I assume I can get rid of those and Mojolicious will handle that for me?


I generally find that I can assume anything with Mojolicious and it'll Do
The Right Thing.  ;D  No of course that's not true, just plugging how well
designed it is.  :D

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] using mojolicious to make a batch request to google api

[Stefan Adams]

On Mon, Sep 17, 2018 at 9:22 PM Steve Dondley  wrote:

> I'm trying to hack a perl module that uses mojolicious to make api calls
> to google's api so that it can make batch api call as documented here:
> https://developers.google.com/gmail/api/guides/batch
>
> I've made various attempts but no calls are resulting in a successful
> response. Here's what I'm currently trying.
>
>   my $options =
>   [
> {
>   content => 'GET /gmail/v1/users/
> m...@gmail.com/messages/165e91c27e4af0be',
>   'Content-Type' => 'application/http',
> },
> {
>   content => 'GET /gmail/v1/users/
> m...@gmail.com/messages/165e94ce49900df2',
>   'Content-Type' => 'application/http',
> }
>   ];
>
>
>
I don't see $options being used in your sample code.  Also it seems weird.
Admittedly, I haven't read (or even looked at) the api guide you referenced.
I personally have never seen content type application/http -- perhaps I
live under a rock.


>   my $path = 'https://www.googleapis.com/batch/' . $s->api . '/' . $s
> ->version;
>
>
>   my $headers = {'Authorization' => 'Bearer TOKEN_HERE'};
>
>
>
>
>   $tx = $self->ua->build_tx(
> uc $http_method => $path => $headers => json =>
> $optional_data );
>
>
What is $http_method and what is $optional_data?  These are used but
undefined, in your sample.

This results in a tranaction object that looks like this:
>

It may not be what you want, but the object looks assembled correctly to
me.  Can you point out anything in particular that doesn't look the way you
think it should?  Fishiest looking thing I see is the content body (req ->
content -> asset -> content).  I assume your intentionally removed your
bearer token for this extract.


> $VAR1 = bless( {
>  'req' => bless( {
>'content' => bless( {
>  'headers' =>
> bless( {
>
>  'headers' => {
>
> 'content-type' => [
>
> 'application/json'
>
>   ],
>
> 'authorization' => [
>
>  'Bearer TOKEN_HERE'
>
>],
>
> 'accept-encoding' => [
>
>'gzip'
>
>  ],
>
> 'user-agent' => [
>
>   'Mojolicious (Perl)'
>
> ]
>
>   }
>
>}, 'Mojo::Headers' ),
>  'events' => {
>
> 'read' => [
>
>  sub { "DUMMY" }
>
>]
>  },
>  'read' => $VAR1
> ->{'req'}{'content'}{'events'}{'read'}[0],
>  'asset' => bless(
> {
>
>'content' => '[{"Content-Type":"application\\/http","content":"GET
> \\/gmail\\/v1\\/u
> sers\\/m...@gmail.com\\/messages\\/165e91c27e4af0be"},{"Content-Type":"application\\/http","content":"GET
> \\/gmail\\/v1\\/users\\/m...@gmail.com\\/messag
> es\\/165e94ce49900df2"}]'
>
> }, 'Mojo::Asset::Memory' )
>},
> 'Mojo::Content::Single' ),
>'url' => bless( {
>  'scheme' => 'https',
>  'host' => '
> www.googleapis.com',
>  'path' => bless( {
>
> 'path' => '/batch/gmail/v1'
>   },
> 'Mojo::Path' )
>}, 'Mojo::URL' ),
>'method' => 'POST'
>  }, 'Mojo::Message::Request' )
>}, 'Mojo::Transaction::HTTP' );
>
>
>
> Trying anything other than json for the generator results in an error:
>  Use of uninitialized value $cb in method lookup
>

Is that because $optional_data isn't defined?


> Fiddling with the content type settings doesn't help make this go away.
>

content-type in $headers, or in $options?  The json generator is correctly
generating the correct application/json content type -- I assume (hope) you
are wanting json?  What's with the funny business of the content type in
$options?  It seems that would be a google api -specific thing, which I
can't comment on (didn't open the api spec).

I don't expect to be of any direct help, but hopefully I got you thinking.

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from 

[Mojolicious] Inserting JSON with Mojo::Pg

[Stefan Adams]

Can you *insert* a new record as JSON?  Updating seems to work, but I can't
seem to get the syntax for inserting.

Success:
$pg->db->update('cache', {record => {-json => {a => 2}}});

No success:
$pg->db->insert('cache', {record => {-json => {a => 2}}});

SQL::Abstract::Pg#JSON
 demonstrates that an
*update* can take a JSON structure, but does not demonstrate such for
*insert*.  If one can update a record to include JSON, why not allow to
insert it?  If you have a table with a json column, how is one to populate
the column on the initial insert?

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Render http status code + json ?

[Stefan Adams]

On Tue, Aug 28, 2018 at 8:47 AM Luc Larochelle 
wrote:

> What I mean is, how can I pass both types to the renderer ?
>
> $c->render(status => 404, json => {message => 'error'});
>
> Is that the proper way ?
>

Yep!  And FWIW, "Every ojo one-liner is also a Mojolicious::Lite
application. "  Therefore,
technically, the solution I presented meets your requirements.  :)  I just
put the Mojolicious::Lite app into a ojo one liner for brevity in showing
code and output!

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Render http status code + json ?

[Stefan Adams]

On Mon, Aug 27, 2018 at 9:39 PM Luc Larochelle 
wrote:

> Hi, what's the proper way to render a status code and a json message at
> the same time ?
>

*$ perl -Mojo -E 'a("/" => {status => 404, json => {error => "not
found"}})->start' get -v /*
GET / HTTP/1.1
User-Agent: Mojolicious (Perl)
Content-Length: 0
Host: 127.0.0.1:41463
Accept-Encoding: gzip

*HTTP/1.1 404 Not Found*
Server: Mojolicious (Perl)
Content-Type: application/json;charset=UTF-8
Content-Length: 21
Date: Tue, 28 Aug 2018 02:46:28 GMT

*{"error":"not found"}*

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] Re: Using Mojo::DOM to update

[Stefan Adams]

Sorry, I knew I should know better.

I was using the ojo#x <https://mojolicious.org/perldoc/ojo#x> example and I
just added on to it:

$ perl -Mojo -E 'say x(f("test.html")->slurp)->at("title")->content("NEW TEXT")'

I've lost access to the dom!  I needed to store the dom object in a
variable so I could get back to the dom after looping thru find:

$ perl -Mojo -E 'my $dom = x(f("test.html")->slurp);
$dom->at("title")->content("NEW TEXT"); say $dom'

There was a discussion recently about tap.  Is this a good use for tap?

$ perl -Mojo -E 'say
x(f("index.html")->slurp)->tap(sub{$_->at("title")->content("NEW
TEXT")})'

Now I have the full dom with my updated information!

On Fri, Aug 24, 2018 at 8:24 PM Stefan Adams  wrote:

> Can Mojo::DOM be used to update information in a tree? For example, if I
> want to strip the host from all links, I might ->find('a[href]') and then
> loop through the collection to do some updates. But unless I'm missing
> something, I can't then update the original dom with these changes.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] Using Mojo::DOM to update

[Stefan Adams]

Can Mojo::DOM be used to update information in a tree, or is it just used
to select information?

For example, how could I remove the https?://host from all links (e.g. src,
href)?

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] Re: Cannot allocate memory

[Stefan Adams]

FWIW: I have not been having this issue since upgrading to 7.92.  Fingers
crossed!!  :D

Is there any chance this was related to the fix that 7.92 brought?

On Sat, Aug 4, 2018 at 9:02 PM Stefan Adams  wrote:

> I've been getting this message recently:
>
> Server available at http://127.0.0.1:8080
> Can't fork: Cannot allocate memory at
> /usr/local/share/perl/5.22.1/Mojo/Server.pm line 31,  line 222.
>
>
> It seems hard to believe I'm low on memory:
>
> $ free -m
>   totalused*free*  shared  buff/cache
>  available
> Mem:990  65 *869* 123  56
>  869
> Swap: 0   0   0
>
>
> I'm sure that the problem is something in my application code, but being
> that it kicks back so quickly, I don't even know how I could begin to
> troubleshoot it.  Any advice?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] Sharing a Mojo::Log instance across modules

[Stefan Adams]

How can I ensure that all modules that support Mojo::Log within an app log
to the same log file in the same way (same attributes: same path, handle,
format, max_history...)?

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] Re: Cannot allocate memory

[Stefan Adams]

Additional info: I restarted the Ubuntu LXC container, and this time the
application was able to load.  :/

On Sat, Aug 4, 2018 at 9:02 PM Stefan Adams  wrote:

> I've been getting this message recently:
>
> Server available at http://127.0.0.1:8080
> Can't fork: Cannot allocate memory at
> /usr/local/share/perl/5.22.1/Mojo/Server.pm line 31,  line 222.
>
>
> It seems hard to believe I'm low on memory:
>
> $ free -m
>   totalused*free*  shared  buff/cache
>  available
> Mem:990  65 *869* 123  56
>  869
> Swap: 0   0   0
>
>
> I'm sure that the problem is something in my application code, but being
> that it kicks back so quickly, I don't even know how I could begin to
> troubleshoot it.  Any advice?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] Cannot allocate memory

[Stefan Adams]

I've been getting this message recently:

Server available at http://127.0.0.1:8080
Can't fork: Cannot allocate memory at
/usr/local/share/perl/5.22.1/Mojo/Server.pm line 31,  line 222.


It seems hard to believe I'm low on memory:

$ free -m
  totalused*free*  shared  buff/cache
 available
Mem:990  65 *869* 123  56
   869
Swap: 0   0   0


I'm sure that the problem is something in my application code, but being
that it kicks back so quickly, I don't even know how I could begin to
troubleshoot it.  Any advice?

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Grouping Mojo::Collection of hashes

[Stefan Adams]

Thank you, Jason and Dan!  These are both great solutions and help me to
achieve my goal.  Thank you for your suggestions!!

On Fri, Aug 3, 2018 at 11:12 AM Dan Book  wrote:

> An alternative using Mojo::Collection::Role::UtilsBy:
>
> use Mojo::Collection 'c';
> use Mojo::Util 'dumper';
>
> my $start = c({name => 'name1', total => 2}, {name => 'name1', total =>
> 3}, {name => 'name2', total => 7})->with_roles('+UtilsBy');
> my $end = c(map { $_->reduce(sub { $a->{total} += $b->{total}; $a }) }
> values %{$start->partition_by(sub { $_->{name} })});
> print dumper $end->to_array;
>
> -Dan
>
> On Fri, Aug 3, 2018 at 11:27 AM Jason Cooper 
> wrote:
>
>> You'd probably need to reduce it to a hash of name to total and then map
>> that back to a Mojo::Collection, e.g.:
>>
>> #!/usr/bin/env perl
>>
>> use strict;
>> use warnings;
>>
>> use Mojo::Collection;
>> use Data::Dumper;
>>
>> my $collection= Mojo::Collection->new({name=>"name1", total=>2},
>> {name=>"name1",total=>3}, {name=>"name2", total=>7});
>>
>>
>> my $firstPass = $collection->reduce( sub {
>> $a->{$b->{name}} += $b->{total};
>>
>> return $a;
>> }, {});
>>
>> my $newCollection = Mojo::Collection->new(
>> map {
>> { name => $_, total => $firstPass->{$_} }
>> } keys %{$firstPass}
>> );
>>
>> print Dumper($collection);
>> print Dumper($newCollection);
>>
>>
>>
>>
>> On Friday, 3 August 2018 13:50:19 UTC+1, Stefan Adams wrote:
>>>
>>> I have a Mojo::Collection of hashes and I'd like to reduce the
>>> collection similar to an SQL GROUP BY.
>>>
>>> Mojo::Collection->new({name=>"name1", total=>2},
>>> {name=>"name1",total=>3}, {name=>"name2", total=>7})
>>>
>>>
>>> This collection has three elements and the collection I'm looking for
>>> would have two:
>>>
>>> {name=>"name1", total=>*5*}, {name=>"name2",total=>7}
>>>
>>>
>>> I'm trying to group by name and then sum the totals within that group.
>>>
>>> It seems like I should use the reduce method of Mojo::Collection; if
>>> that's appropriate, how could I accomplish that?
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Mojolicious" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mojolicious+unsubscr...@googlegroups.com.
>> To post to this group, send email to mojolicious@googlegroups.com.
>> Visit this group at https://groups.google.com/group/mojolicious.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] Grouping Mojo::Collection of hashes

[Stefan Adams]

I have a Mojo::Collection of hashes and I'd like to reduce the collection
similar to an SQL GROUP BY.

Mojo::Collection->new({name=>"name1", total=>2}, {name=>"name1",total=>3},
{name=>"name2", total=>7})


This collection has three elements and the collection I'm looking for would
have two:

{name=>"name1", total=>*5*}, {name=>"name2",total=>7}


I'm trying to group by name and then sum the totals within that group.

It seems like I should use the reduce method of Mojo::Collection; if that's
appropriate, how could I accomplish that?

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Making Mojo::UserAgent secure by default

[Stefan Adams]

On Sat, May 19, 2018 at 6:23 AM sri  wrote:

> Personally, i think we should just replicate curl behaviour, since that
> seems to work for most
> people.
>

I like that.

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] Multiple SSL certs

[Stefan Adams]

I'm using Toadfarm to mount several apps into a single Mojolicious
instance. Is it possible for Mojolicious to handle different certs for each
of those mounted apps, or do I need to continue to run Nginx in front to
handle that?

Can I use Mojolicious as an alternative to Nginx for being a proxy to apps
behind a firewall?

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Nginx Unit 1.0 released

[Stefan Adams]

Is there anything in Nginx Unit that's worth replicating in Mojolicious?

On Sat, May 5, 2018, 8:41 AM sri  wrote:

> Recently (month ago) the stable version of nginx unit application server
>> was released https://www.nginx.com/blog/nginx-unit-1-0-released/
>>
>> Did anyone try to launch Mojolicious with nginx unit? What do you think,
>> is it worth trying to do it?
>>
>
> I believe nginx unit uses psgi, so it's not worth it.
>
> --
> sebastian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Mojolicious" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mojolicious+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mojolicious+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.