Re: [Mojolicious] Set correct rights to unix socket with Mojo::Server::Daemon

[Charlie Brady]

IMO you *never* want to use 777. Use user or group id of the socket file 
to control whether nginx can write to it.

On Wed, 24 Apr 2019, �~Xл�~L�~O Ра�~A�~Aадин wrote:

> Hi!
> 
> I want to run my mojo app with hypnotoad listening on unix socket. conf file
> looks like this
> 
> {
> 
>  ...
> 
>     hypnotoad => {
>     listen  => ['http+unix://%2Ftmp%2Fmy_app.sock'],
>     workers => 2,
>     proxy => 1,
>     },
> 
> }
> 
> And then file /tmp/my_app.sock has 755 rights (according to user umask).
> 
> But I need to change it to 777 to allow nginx to write queries to socket.
> 
> Is there a proper recommended way to achieve that goal?
> 
> --
> 
> Best Regards, Ilya 'elcamlost' Rassadin.
> 
> 

[Mojolicious] Amazon S3?

[Charlie Brady]

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

Re: [Mojolicious] Other processes hooked on Mojolicious HTTP port

[Charlie Brady]

Yes, I do mean the HTTP port, and yes, Mojo would be handling that. It's 
been noted before that FD_CLOEXEC doesn't seem to be working as expected 
with Mojo (if indeed it is set by default by perl, as I have seen 
asserted - it is disabled by default on sockets and fds in socket() and 
open()). So maybe my expectation that Mojo should set FD_CLOEXEC is 
misguided.

https://www.perlmonks.org/?node_id=1013743

On Wed, 6 Feb 2019, Nuno Mota wrote:


> After a lot of reading, I've managed to close all the sockets on the fork
> itself, after setsid(). That did the trick.
> 
> I'm assuming the fd you are talking is the HTTP port itself, because that's
> the one hooked on my daemon.
> That would be Mojo handling it, am I wrong?
> 
> Regards,
> Nuno Mota
> 
> 
> 
> Charlie Brady  escreveu no dia quarta,
> 6/02/2019 ??(s) 15:36:
> 
> >
> > You can find the file descriptor of the listen socket using 'fd' from
> > the daemon.
> >
> > https://mojolicious.org/perldoc/Mojo/Server/Daemon
> >
> > Make sure that the close-on-exec flag is set on that fd. That should be
> > the default on perl, but maybe it isn't on your platform, or maybe
> > Mojolicious for some reason clears it...
> >
> > https://perldoc.perl.org/Fcntl.html
> >
> > On Tue, 5 Feb 2019, Nuno Mota wrote:
> >
> > > Hi,
> > > I'm having an issue with port bindings from my Mojolicious perl daemon.
> > >
> > > The thing is, I issue a restart through Mojo, which then runs a bash
> > script
> > > that restarts a daemon.
> > > After this daemon starts, it's hooked on the Mojo HTTP port. Does this
> > make
> > > any sense?
> > >
> > > perl  8883 root   16u  IPv4  91544  0t0  TCP *:8080 (LISTEN)
> > > daemon   9053 root   16u  IPv4  91544  0t0  TCP *:8080 (LISTEN)
> > >
> > > I've tried exec, system, backticks and nothing seems to properly detach
> > the
> > > bash script from the Mojo port hooks.
> > >
> > > Regards,
> > > Nuno
> > >
> > >
> >
> 
> 

Re: [Mojolicious] Other processes hooked on Mojolicious HTTP port

[Charlie Brady]

You can find the file descriptor of the listen socket using 'fd' from 
the daemon.

https://mojolicious.org/perldoc/Mojo/Server/Daemon

Make sure that the close-on-exec flag is set on that fd. That should be 
the default on perl, but maybe it isn't on your platform, or maybe 
Mojolicious for some reason clears it...

https://perldoc.perl.org/Fcntl.html

On Tue, 5 Feb 2019, Nuno Mota wrote:

> Hi,
> I'm having an issue with port bindings from my Mojolicious perl daemon.
> 
> The thing is, I issue a restart through Mojo, which then runs a bash script 
> that restarts a daemon.
> After this daemon starts, it's hooked on the Mojo HTTP port. Does this make 
> any sense?
> 
> perl  8883 root   16u  IPv4  91544  0t0  TCP *:8080 (LISTEN)
> daemon   9053 root   16u  IPv4  91544  0t0  TCP *:8080 (LISTEN)
> 
> I've tried exec, system, backticks and nothing seems to properly detach the 
> bash script from the Mojo port hooks.
> 
> Regards,
> Nuno 
> 
> 

Re: [Mojolicious] Reducing daemon memory footprint?

[Charlie Brady]

On Wed, 26 Sep 2018, sri wrote:

> If that's the case, why not just fatpack your mojo app?

Um, because I didn't know about fatpack? :-)

Thanks, looks a good suggestion. The system will continue to be slow, but 
not as slow...

Re: [Mojolicious] Reducing daemon memory footprint?

[Charlie Brady]

This is why I need to run a persistent daemon rather than use CGI mode.

root@jy-cx:~# time perl -e exit

real0m0.035s
user0m0.000s
sys 0m0.030s
root@jy-cx:~# time perl -MMojolicious::Lite -e exit

real0m11.011s
user0m8.690s
sys 0m0.400s
root@jy-cx:~# 

Looking at an strace there doesn't seem to be a single culprit for the 
slow startup - there's just a lot of files to find, open, read, parse.

root@jy-cx:~# grep open ml.trace  | wc -l
211
root@jy-cx:~# 

...
root@jy-cx:~# grep open ml.trace | grep 12:21:26 | wc -l
16
root@jy-cx:~# grep open ml.trace | grep 12:21:27 | wc -l
28
root@jy-cx:~# grep open ml.trace | grep 12:21:28 | wc -l
16
root@jy-cx:~# grep open ml.trace | grep 12:21:29 | wc -l
19
root@jy-cx:~# grep open ml.trace | grep 12:21:30 | wc -l
13
root@jy-cx:~# grep open ml.trace | grep 12:21:31 | wc -l
2
root@jy-cx:~# grep open ml.trace | grep 12:21:32 | wc -l
15
root@jy-cx:~# grep open ml.trace | grep 12:21:33 | wc -l
8
root@jy-cx:~# grep open ml.trace | grep 12:21:34 | wc -l
18
root@jy-cx:~# grep open ml.trace | grep 12:21:35 | wc -l
24
root@jy-cx:~# grep open ml.trace | grep 12:21:36 | wc -l
8
root@jy-cx:~# grep open ml.trace | grep 12:21:37 | wc -l
19
root@jy-cx:~# grep open ml.trace | grep 12:21:38 | wc -l
11
root@jy-cx:~# grep open ml.trace | grep 12:21:39 | wc -l
14
root@jy-cx:~# grep open ml.trace | grep 12:21:40 | wc -l
0
root@jy-cx:~# 
...

Initialising Time::HiRes::HiRes seems to be the single individual 
parse/init step:

12:21:30.734184 open("/usr/lib/perl/5.22.0/Pod/Simple/BlackBox.pm", 
O_RDONLY|O_L
ARGEFILE) = 16
12:21:31.607709 open("/usr/lib/perl/5.22.0/Time/HiRes.pm", 
O_RDONLY|O_LARGEFILE) = 12
12:21:31.643254 open("/usr/lib/perl/5.22.0//auto/Time/HiRes/HiRes.so", 
O_RDONLY|O_CLOEXEC) = 12
12:21:32.356811 open("/usr/lib/perl/vendor_perl/5.22.0/Mojo/Log.pm", 
O_RDONLY|O_LARGEFILE) = 7



On Thu, 20 Sep 2018, Charlie Brady wrote:

> 
> On Thu, 20 Sep 2018, Stefan Adams wrote:
> 
> > 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!
> 
> Bear in mind this is one M::L program which has loaded (via the Mount 
> plugin) a few dozen other M::L programs and then run for a few months 
> (mostly idle).
> 
> FWIW, this is on a PPC processor (perl 5.22.0, Mojolicious 7.33).
> 
> > 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 hav

Re: [Mojolicious] Reducing daemon memory footprint?

[Charlie Brady]

On Thu, 20 Sep 2018, Stefan Adams wrote:

> 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!

Bear in mind this is one M::L program which has loaded (via the Mount 
plugin) a few dozen other M::L programs and then run for a few months 
(mostly idle).

FWIW, this is on a PPC processor (perl 5.22.0, Mojolicious 7.33).

> 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
> > > >
> > >
> > >
> >
> 
> 

Re: [Mojolicious] Reducing daemon memory footprint?

[Charlie Brady]

There's some good general advice from our friend Brian D Foy here:

https://stackoverflow.com/questions/9733146/tips-for-keeping-perl-memory-usage-low

To bring this more closely focussed on Mojolicious, my daemon is loading a 
ew dozen other Mojolicious::Lite applications using the Mount plugin. And 
all of those are using a common plugin. I'm wondering how much duplication 
there is within the sandboxing of each mounted application, and what might 
be possible to optimize the sharing of data/compiled code between the 
instances.

On Thu, 20 Sep 2018, Charlie Brady 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
> > >
> > 
> > 
> 

Re: [Mojolicious] Reducing daemon memory footprint?

[Charlie Brady]

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
> >
> 
> 

[Mojolicious] Reducing daemon memory footprint?

[Charlie Brady]

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

Re: [Mojolicious] List of All Optional Modules?

[Charlie Brady]

'mojo version' lists all the optional modules.

On Sat, 8 Sep 2018, Viktor Nacht wrote:

> Is there a singular list of all of the optional/suggested/recommended 
> modules for Mojolicious? I know they're listed in docs, but they (seem) to 
> be split between the relevant guide/command/module. I'd like to include all 
> of them as a kind of "complete" Mojolicious install. 
> 
> I searched the Mojo docs, Google and this group. I apologize if that has 
> been covered already.
> 
> V
> 
> 
> 

Re: [Mojolicious] How can I detect if a client closes socket without reading full response?

[Charlie Brady]

If I am reading this correctly, Mojo::IOLoop::Stream just ignores write 
errors (and continues attempting to write on the closed socket).

What are the "timing problems" which are avoided by not handling write 
errors? Is there a better way of avoiding those problems?

...
sub _write {
  my $self = shift;

  # Handle errors only when reading (to avoid timing problems)
  my $handle = $self->{handle};
  if (length $self->{buffer}) {
return unless defined(my $written = 
$handle->syswrite($self->{buffer}));
$self->emit(write => substr($self->{buffer}, 0, $written, 
''))->_again;
  }

  $self->emit('drain') unless length $self->{buffer};
  return if $self->is_writing;
  return $self->close if $self->{graceful};
  $self->reactor->watch($handle, !$self->{paused}, 0) if $self->{handle};
}
...

On Fri, 27 Apr 2018, Charlie Brady wrote:

> 
> I have a controller producing a response with a write_chunk() loop. I want 
> to take a different action if the client does not read the full response - 
> e.g. when a user hits Cancel in a file save dialog.
> 
> In a previous version of my code which ran in CGI mode SIGPIPE told me 
> that information. Is there anything in Mojolicious which will relay the 
> socket write error back to the controller?
> 
> Thanks
> 

[Mojolicious] How can I detect if a client closes socket without reading full response?

[Charlie Brady]

I have a controller producing a response with a write_chunk() loop. I want 
to take a different action if the client does not read the full response - 
e.g. when a user hits Cancel in a file save dialog.

In a previous version of my code which ran in CGI mode SIGPIPE told me 
that information. Is there anything in Mojolicious which will relay the 
socket write error back to the controller?

Thanks

Re: [Mojolicious] Can't locate object method "plugin" RenderFile via package ...

[Charlie Brady]

sri already answered your question - you cannot both render and 
redirect_to. And you have confirmed that to be the case.

On Tue, 13 Mar 2018, Caveman Pl wrote:

> Hi All,
> 
> Thank you for your help.
> 
> It works!! 
> When I remove last line from sub gatherCelMetadata... (below I have pasted 
> working gatherCelMetadata)
> I dont understand why is that.
> Maybe you can answer this question.
> 
> Thank you.
> tj
> 
> sub gatherCelMetadata{
> my $self = shift;
> $self->plugin('RenderFile');
> my $workbookWrite  = Excel::Writer::XLSX->new( 'celFileMetadata.xlsx' );
> my $worksheetWrite = $workbookWrite->add_worksheet();
> ...
> for my $token ( @fields ) {
> $worksheetWrite->write( $row, $col, $token );
> }
> 
> $self->render_file(filepath => 
> '/home/test/tmp/my_app/celFileMetadata.xlsx', 'filename' => 
> 'celFileMetadata.xlsx' );
> #$self->redirect_to('/');
> }
> 
> 

Re: [Mojolicious] Mojo::Base get all attributes names

[Charlie Brady]

On Mon, 5 Feb 2018, Dan Book wrote:

> Introspection capabilities are a feature of Moose.

Moose, however, adds many, many more dependencies than Mojo::Base...

> 
> On Mon, Feb 5, 2018 at 5:14 AM, Konstantin Cherednichenko <
> dshadowukra...@gmail.com> wrote:
> 
> > Hello!
> >
> > Is there any easy way to get all attributes names?
> >
> > I tried to get it via ISA but I also got methods names... I just want to
> > get "propA" and "propB"...
> > Could someone please help me?
> >
> > My example:
> >
> > #!/usr/bin/env perl
> >
> > package A;
> > use Mojo::Base -base;
> >
> > has propA => 123;
> > has propB => 'val';
> >
> > sub get_props_names
> > {
> > my $self = shift;
> >
> > my %names = ();
> >
> > {
> > my $base_class = ref($self);
> >
> > no strict 'refs';
> >
> > foreach my $class ($base_class, @{"${base_class}::ISA"})
> > {
> > foreach my $name (keys %{"${class}::"})
> > {
> > $names{$name} ||= 1;
> > }
> > }
> > };
> >
> > return [sort keys %names];
> > }
> >
> > package main;
> > use Mojo::Base -strict;
> > use Data::Dumper;
> >
> > my $obj = A->new;
> >
> > say Dumper($obj->get_props_names);
> >
> > --
> > 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 Sessions and IIS 8.5

[Charlie Brady]

On Tue, 18 Jul 2017, Brandon Woodson wrote:

> So to further help anyone interested in helping me solve this problem. I 
> put together a small Mojo::Lite app to help me troubleshoot. You can check 
> it out on Github .

You'll need to also provide information about the IIS configuration.

My guess is that browsers are not returning the cookies to the application 
(when the application is behind IIS) because of mismatched hostnames or 
cookie path.

Standard browser development tools should show you any cookies being set 
or returned in requests.

[Mojolicious] Re: A pair of processes using 8% of CPU each

[Charlie Brady]

On Mon, 10 Jul 2017, Jan Henning Thorsen wrote:

> The reason why you're seeing the polling is because of the implementation 
> in the CGI plugin. You can see it 
> here: 
> https://github.com/jhthorsen/mojolicious-plugin-cgi/blob/master/lib/Mojolicious/Plugin/CGI.pm#L35

There might be portability issues to non-POSIX environments, but you can 
avoid the polling by using "the selfpipe trick".  Install a proper 
SIGCHILD hander instead of using a polling loop to detect exiting child 
processes.

Your sigchild handler just needs to write a single byte into the pipe 
where your event loop poll can detect it and do whatever is required.

https://cr.yp.to/docs/selfpipe.html
https://www.sitepoint.com/the-self-pipe-trick-explained/
https://lwn.net/Articles/177897/

[Mojolicious] Re: A pair of processes using 8% of CPU each

[Charlie Brady]

On Mon, 10 Jul 2017, Jan Henning Thorsen wrote:

> Charlie,
> 
> I think I was tricked by the "ps" output you had. What is 
> "/etc/e-smith/web/functions/index.daemon.cgi" ? Is that the mojo app or the 
> cgi script?

That's the mojo app.

> Can you show some code?

Not easily.

> The reason why you're seeing the polling is because of the implementation 
> in the CGI plugin. You can see it 
> here: 
hfnnttps://github.com/jhthorsen/mojolicious-plugin-cgi/blob/master/lib/Mojolicious/Plugin/CGI.pm#L35

That's 404. But I think you are referring to:

...
use constant CHECK_CHILD_INTERVAL => $ENV{CHECK_CHILD_INTERVAL} || 0.01;
...
  $app->{'mojolicious_plugin_cgi.tid'}
||= Mojo::IOLoop->recurring(CHECK_CHILD_INTERVAL, sub { local ($?, 
$!); _waitpids($pids); });
...

> Btw: I'm the author of the CGI plugin. I have not had any issues with it 
> using a lot of CPU, even with that polling interval, but you can try to 

You probably aren't running code on a 32bit PPC CPU running at 400Mhz :-)

> tweak it if you like, by 
> setting 
> https://github.com/jhthorsen/mojolicious-plugin-cgi/blob/master/lib/Mojolicious/Plugin/CGI.pm#L13

I can try that, but I'm trying to avoid the CGI code by porting each 
sub-app to Mojolicious, and using the Mount plugin.

> It could probably be fixed by the same code I added to ReadWriteFork. I 
> will take a PR if anyone implements the change, where it uses EV::child(), 
> if 
> available: 
> https://github.com/jhthorsen/mojo-ioloop-readwritefork/commit/42a579d5b78eedb0d01b7db25036ca1726819f18
> 
> 
> On Friday, June 30, 2017 at 7:15:17 AM UTC+2, Henry Foolman wrote:
> >
> > Hi Charly,
> > missing some details.
> > 1.) OS Version
> > 2.) Kernel Version
> > 3.) mojo version.
> > 4.) Do you use cpan(m) to install the lastest version or are you using OS 
> > packages ?
> >
> > I had similar problems but switched to a new mojo version and latest EV. ( 
> > cpanm EV).
> > For EV it should be kernel > 4.5
> > It seems that you started your app via daemon.
> > Try to use hypnotoad and check if there are changes. (got to the base dir 
> > and enter hypnotoad -f script/yourscript).
> > Some hints about reading and writing to a process.
> > I use Mojo::IOLoop::ReadWriteFork togehter with the delay helper 
> > ($c->delay), which works perfectly.
> > Perhaps it's this your're looking for.
> >
> > Rgds.
> > Hans
> >
> >
> > Am Donnerstag, 29. Juni 2017 16:10:46 UTC+2 schrieb Charlie Brady:
> >>
> >>
> >> On Thu, 29 Jun 2017, Jan Henning Thorsen wrote: 
> >>
> >> > Hey, 
> >> > 
> >> > It doesn't look like "daemon" mode. It looks like you used "morbo" to 
> >> start 
> >> > the application. 
> >>
> >> I don't know what makes you say that. I definitely was using "daemon" 
> >> mode 
> >> and was not using "morbo". 
> >>
> >> I didn't track down exactly what code was making the difference in the 
> >> poll timeout, but worked out that it was somewhere in the CGI plugin. 
> >> I've 
> >> eliminated the CGI plugin and now find that the poll timeout is back to 
> >> 1000 ms, which a corresponding reduction in idle CPU. 
> >>
> >> I don't know exactly where the fork() was which lead to the pair of 
> >> processes. I did have some code with an open() reading from a pipe, but I 
> >> wouldn't expect to see poll() in the child process in that case. 
> >>
> >> Mystery not quite solved, but now that I am not using the CGI plugin I at 
> >> least don't have an ongoing problem. 
> >>
> >> Thanks for commenting. If you want to try to identify the problem with 
> >> the 
> >> CGI plugin I can re-insert that code. 
> >>
> >> > 
> >> > 
> >> > On Wednesday, June 14, 2017 at 11:11:31 PM UTC+2, Charlie Brady wrote: 
> >> > > 
> >> > > 
> >> > > I'm running a Mojolicious UI in daemon mode on a PowerPC embedded 
> >> system 
> >> > > (running Wind River Linux, perl 5.22.0, kernel 4.1.21) and notice 
> >> > > surprisingly high CPU usage on a totally idle UI. 
> >> > > 
> >> > > I can see that there are two processes. Each process is in a polling 
> >> loop 
> >> > > with 10ms timeout. I don't expect to see two processes here, so I 
> >> wonder 
> >> > > whe

Re: [Mojolicious] helper name

[Charlie Brady]

On Wed, 5 Jul 2017, Beginner wrote:

> Henry Foolman, thanks for your detailed reply about authoring plugins -- 
> appreciate it.  Unless I misunderstood your post completely, my question is 
> really how to figure out the name of the helper function from within the 
> helper, perhaps via some nested ref inside $self!?  I tried dumping it but 
> quickly got lost, so wanted to see if the community is aware of a trick.  
> Is that even possible?

See what caller() gives you:

https://stackoverflow.com/questions/2559792/how-can-i-get-the-name-of-the-current-subroutine-in-perl

[Mojolicious] Re: A pair of processes using 8% of CPU each

[Charlie Brady]

On Thu, 29 Jun 2017, Jan Henning Thorsen wrote:

> Hey,
> 
> It doesn't look like "daemon" mode. It looks like you used "morbo" to start 
> the application.

I don't know what makes you say that. I definitely was using "daemon" mode 
and was not using "morbo".

I didn't track down exactly what code was making the difference in the 
poll timeout, but worked out that it was somewhere in the CGI plugin. I've 
eliminated the CGI plugin and now find that the poll timeout is back to 
1000 ms, which a corresponding reduction in idle CPU.

I don't know exactly where the fork() was which lead to the pair of 
processes. I did have some code with an open() reading from a pipe, but I 
wouldn't expect to see poll() in the child process in that case.

Mystery not quite solved, but now that I am not using the CGI plugin I at 
least don't have an ongoing problem.

Thanks for commenting. If you want to try to identify the problem with the 
CGI plugin I can re-insert that code.

> 
> 
> On Wednesday, June 14, 2017 at 11:11:31 PM UTC+2, Charlie Brady wrote:
> >
> >
> > I'm running a Mojolicious UI in daemon mode on a PowerPC embedded system 
> > (running Wind River Linux, perl 5.22.0, kernel 4.1.21) and notice 
> > surprisingly high CPU usage on a totally idle UI. 
> >
> > I can see that there are two processes. Each process is in a polling loop 
> > with 10ms timeout. I don't expect to see two processes here, so I wonder 
> > whether this is normal or abnormal behaviour. If it is normal behaviour, 
> > can I tune down the 10ms timeout to something longer? I would like to see 
> > the process block until there is actual work to do. 
> >
> > root@10:/service# ps fax | grep index.daemon-5 
> >  1418 pts/1S+ 0:00  \_ grep index.daemon 
> > 19303 ?Ssl   24:24 /etc/e-smith/web/functions/index.daemon.cgi 
> > 24397 ?Ssl   20:54  \_ /etc/e-smith/web/functions/index.daemon.cgi 
> > root@10:/service# strace -p19303 -tt 2>&1 | head -5 
> > Process 19303 attached 
> > 17:05:08.095154 restart_syscall(<... resuming interrupted call ...>) = 0 
> > 17:05:08.104465 poll([{fd=21, events=POLLIN|POLLPRI|POLLOUT}], 1, 9) = 0 
> > (Timeout) 
> > 17:05:08.116478 poll([{fd=21, events=POLLIN|POLLPRI|POLLOUT}], 1, 10) = 0 
> > (Timeout) 
> > 17:05:08.130120 poll([{fd=21, events=POLLIN|POLLPRI|POLLOUT}], 1, 9) = 0 
> > (Timeout) 
> > root@10:/service# strace -p24397 -tt 2>&1 | head -5 
> > Process 24397 attached 
> > 17:05:12.888643 restart_syscall(<... resuming interrupted call ...>) = 0 
> > 17:05:12.894814 poll([{fd=21, events=POLLIN|POLLPRI|POLLOUT}], 1, 10) = 0 
> > (Timeout) 
> > 17:05:12.908082 poll([{fd=21, events=POLLIN|POLLPRI|POLLOUT}], 1, 10) = 0 
> > (Timeout) 
> > 17:05:12.920771 poll([{fd=21, events=POLLIN|POLLPRI|POLLOUT}], 1, 10) = 0 
> > (Timeout) 
> > root@10:/service# top | head -12 
> > top - 17:09:31 up 9 days,  7:59,  4 users,  load average: 0.73, 0.59, 0.60 
> > Tasks:  98 total,   1 running,  95 sleeping,   0 stopped,   2 zombie 
> > %Cpu(s): 12.9 us,  5.7 sy,  3.8 ni, 75.7 id,  1.8 wa,  0.0 hi,  0.1 si,   
> > 0.0 st 
> > KiB Mem :   995536 total, 5428 free,   317100 used,   673008 
> > buff/cache 
> > KiB Swap:65532 total,65448 free,   84 used.   594360 avail Mem 
> >
> >   PID USER  PR  NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 
> >   
> >  1440 root  20   03852   2280   1924 R 24.0  0.2   0:00.13 top 
> >   
> >   508 root  20   0  134908  69156  13896 S 12.0  6.9 465:50.05 
> > call_control 
> > 19303 root  20   0   87812  37720   4148 S  8.0  3.8  24:45.37 
> > /etc/e-smith/we   
> > 24397 root  20   0   87788  37184   3552 S  8.0  3.7  21:13.65 
> > /etc/e-smith/we   
> >   425 root  20   0   16068  10284   3640 S  4.0  1.0  33:32.22 snmpd   
> >   
> >
> 

[Mojolicious] A pair of processes using 8% of CPU each

[Charlie Brady]

I'm running a Mojolicious UI in daemon mode on a PowerPC embedded system 
(running Wind River Linux, perl 5.22.0, kernel 4.1.21) and notice 
surprisingly high CPU usage on a totally idle UI.

I can see that there are two processes. Each process is in a polling loop 
with 10ms timeout. I don't expect to see two processes here, so I wonder 
whether this is normal or abnormal behaviour. If it is normal behaviour, 
can I tune down the 10ms timeout to something longer? I would like to see 
the process block until there is actual work to do.

root@10:/service# ps fax | grep index.daemon-5
 1418 pts/1S+ 0:00  \_ grep index.daemon
19303 ?Ssl   24:24 /etc/e-smith/web/functions/index.daemon.cgi
24397 ?Ssl   20:54  \_ /etc/e-smith/web/functions/index.daemon.cgi
root@10:/service# strace -p19303 -tt 2>&1 | head -5
Process 19303 attached
17:05:08.095154 restart_syscall(<... resuming interrupted call ...>) = 0
17:05:08.104465 poll([{fd=21, events=POLLIN|POLLPRI|POLLOUT}], 1, 9) = 0 
(Timeout)
17:05:08.116478 poll([{fd=21, events=POLLIN|POLLPRI|POLLOUT}], 1, 10) = 0 
(Timeout)
17:05:08.130120 poll([{fd=21, events=POLLIN|POLLPRI|POLLOUT}], 1, 9) = 0 
(Timeout)
root@10:/service# strace -p24397 -tt 2>&1 | head -5
Process 24397 attached
17:05:12.888643 restart_syscall(<... resuming interrupted call ...>) = 0
17:05:12.894814 poll([{fd=21, events=POLLIN|POLLPRI|POLLOUT}], 1, 10) = 0 
(Timeout)
17:05:12.908082 poll([{fd=21, events=POLLIN|POLLPRI|POLLOUT}], 1, 10) = 0 
(Timeout)
17:05:12.920771 poll([{fd=21, events=POLLIN|POLLPRI|POLLOUT}], 1, 10) = 0 
(Timeout)
root@10:/service# top | head -12
top - 17:09:31 up 9 days,  7:59,  4 users,  load average: 0.73, 0.59, 0.60
Tasks:  98 total,   1 running,  95 sleeping,   0 stopped,   2 zombie
%Cpu(s): 12.9 us,  5.7 sy,  3.8 ni, 75.7 id,  1.8 wa,  0.0 hi,  0.1 si,  
0.0 st
KiB Mem :   995536 total, 5428 free,   317100 used,   673008 
buff/cache
KiB Swap:65532 total,65448 free,   84 used.   594360 avail Mem 

  PID USER  PR  NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND  

 1440 root  20   03852   2280   1924 R 24.0  0.2   0:00.13 top  

  508 root  20   0  134908  69156  13896 S 12.0  6.9 465:50.05 
call_control 
19303 root  20   0   87812  37720   4148 S  8.0  3.8  24:45.37 
/etc/e-smith/we  
24397 root  20   0   87788  37184   3552 S  8.0  3.7  21:13.65 
/etc/e-smith/we  
  425 root  20   0   16068  10284   3640 S  4.0  1.0  33:32.22 snmpd

Re: [Mojolicious] select_field tag helper - how to add 'selected'?

[Charlie Brady]

On Wed, 6 Feb 2013, Glen wrote:

> Set the parameter to what you want selected:
> 
>   param(name => 'audi');

I've discovered that there are some parameter names when that is not true. 
I think this might be a case of reserved words in the stash.

% param status => 'enabled';
%= select_field status => [['DISABLED' => 'disabled'], ['ENABLED' => 
'enabled']]

does not render

DISABLEDENABLED

as expected, but rather as:

DISABLEDENABLED

Changing the field name to something other than 'status' (or 'text', 
'json', 'inline', etc) makes it behave as expect..

The full list of reserved stash values is listed here:

http://mojolicious.org/perldoc/Mojolicious/Controller#stash

This is a real trap for the unwary. Should ->param() warn about use of 
reserved words?

> 
> 
> On Feb 6, 2013, at 11:29 AM, Charlie Brady  
> wrote:
> 
> > 
> > Documentation for the tag helpers is "by example only", and doesn't define 
> > valid syntax.
> > 
> > http://mojolicio.us/perldoc/Mojolicious/Plugin/TagHelpers#select_field
> > 
> > How do I set the boolean "selected", viz:
> > 
> > 
> >  Volvo
> >  Saab
> >  VW
> >  Audi
> >  
> > 
> > -- 
> > 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 http://groups.google.com/group/mojolicious?hl=en.
> > For more options, visit https://groups.google.com/groups/opt_out.
> > 
> > 
> 
> 

Re: [Mojolicious] Intermittent 400's using Mojo::UserAgent

[Charlie Brady]

On Tue, 14 Mar 2017, Joel Berger wrote:

> All that said, you don't even need to do this manually. If you add your 
> username and password to the request url Mojo::UserAgent will just build 
> this header for you. See the example 
> here: http://mojolicious.org/perldoc/Mojo/UserAgent#SYNOPSIS

Note however that you shouldn't do this:

my $value = 
$ua->get("https://$user:$p...@example.com/test.json";)->result->json;

if your password might contain @. You will find part of your password 
leaking out via DNS lookups.

I think:

Mojo::URL->new('https://example.com/test.json')->username($user)->password($pass)

is safe.

Re: [Mojolicious] Mounting Mojolicious::Lite apps under Mount plugin?

[Charlie Brady]

On Tue, 6 Dec 2016, Charlie Brady wrote:

> [root@dsfdsfd functions]# cat My/ML.pm 
> package My::ML;
> use Mojolicious::Lite;
> 
> plugin 'AppDefault';
> 
> 1;

Changing the callers to use the same code in-line works:

[root@dsfdsfd functions]# cat one
#!/usr/bin/perl

use Mojolicious::Lite;
plugin 'AppDefault';

get '/' => sub { shift->render(text => "one\n") }; 

app->start;
[root@dsfdsfd functions]# 

Re: [Mojolicious] Mounting Mojolicious::Lite apps under Mount plugin?

[Charlie Brady]

On Tue, 6 Dec 2016, Charlie Brady wrote:

> The reason for not using a namespace is that I want to use 'app' to set 
> some defaults. For instance, I want to do these:
> 
> app->defaults(layout => 'server_manager');
> app->log->level('warn');
> push @{app->renderer->paths}, '/etc/e-smith/web/panels/manager/templates';
...
> Perhaps I should be defining a 'ServerManager' plugin, and setting the 
> common defaults inside the register() method there.

That doesn't seem to work either:

[root@dsfdsfd functions]# cat My/ML.pm 
package My::ML;
use Mojolicious::Lite;

plugin 'AppDefault';

1;
[root@dsfdsfd functions]# cat Mojolicious/Plugin/AppDefault.pm 
package Mojolicious::Plugin::AppDefault;
use Mojo::Base 'Mojolicious::Plugin';

sub register {
  my ($self, $app, $conf) = @_;
  $app->log->level('warn');
  push @{$app->renderer->paths}, 
'/etc/e-smith/web/panels/manager/templates';
}
1;
[root@dsfdsfd functions]# perl -I. test.mount 
String found where operator expected at /etc/e-smith/web/functions/one 
line 9, near "get '/'"
(Do you need to predeclare get?)
Can't load application from file "/etc/e-smith/web/functions/one": syntax 
error at /etc/e-smith/web/functions/one line 9, near "get '/'"
Compilation failed in require at (eval 79) line 1.
[root@dsfdsfd functions]# 

Re: [Mojolicious] Mounting Mojolicious::Lite apps under Mount plugin?

[Charlie Brady]

On Mon, 5 Dec 2016, sri wrote:

> Make a minimal test case demonstrating the problem.

Problem occurs when I 'use' a module, which 'use's M::L, without declaring 
a namespace.

[root@dsfdsfd functions]# cat test.mount 
#!/usr/bin/perl

use Mojolicious::Lite;

plugin Mount => {'/one' => './one'};
plugin Mount => {'/two' => './two'};

app->start;

[root@dsfdsfd functions]# cat My/ML.pm 
use Mojolicious::Lite;
1;
[root@dsfdsfd functions]# cat one
#!/usr/bin/perl

use My::ML;

get '/' => sub { shift->render(text => 'one') }; 

app->start;
[root@dsfdsfd functions]# cat two
#!/usr/bin/perl

use My::ML;

get '/' => sub { shift->render(text => 'two') }; 

app->start;
[root@dsfdsfd functions]# 
[root@dsfdsfd functions]# perl -I. test.mount 
[Tue Dec  6 11:33:34 2016] [debug] Your secret passphrase needs to be 
changed
String found where operator expected at /etc/e-smith/web/functions/two 
line 5, near "get '/'"
(Do you need to predeclare get?)
Can't load application from file "/etc/e-smith/web/functions/two": syntax 
error at /etc/e-smith/web/functions/two line 5, near "get '/'"
Compilation failed in require at (eval 81) line 1.
[root@dsfdsfd functions]# 

The reason for not using a namespace is that I want to use 'app' to set 
some defaults. For instance, I want to do these:

app->defaults(layout => 'server_manager');
app->log->level('warn');
push @{app->renderer->paths}, '/etc/e-smith/web/panels/manager/templates';

in My::ML. I tried these, with none of them working:

 Mojolicious::Lite->app
 Mojolicious::Lite:app
 caller->app

Perhaps I should be defining a 'ServerManager' plugin, and setting the 
common defaults inside the register() method there.

Re: [Mojolicious] Mounting Mojolicious::Lite apps under Mount plugin?

[Charlie Brady]

On Mon, 5 Dec 2016, Stefan Adams wrote:

> Surely there's just something tiny that's being overlooked!  :O

Looks to be related to the class name which specializes M::L.

root@10:/etc/e-smith/web/functions# cat My/ML.pm 
use Mojolicious::Lite;

1;
root@10:/etc/e-smith/web/functions# diff -u test.mount test2.mount
--- test.mount  2016-12-05 23:17:58.485718918 +
+++ test2.mount 2016-12-05 23:18:17.425916545 +
@@ -1,6 +1,6 @@
 #!/usr/bin/perl
 
-use My::ML;
+use Mitel::MSL::Mojolicious::ServerManagerX;
 
 app->defaults(expires => 1);
 push @{app->static->paths}, '/etc/e-smith/web/common';
root@10:/etc/e-smith/web/functions# diff -u My/ML.pm 
/usr/lib/perl/vendor_perl/5.22.0/Mitel/MSL/Mojolicious/ServerManagerX.pm
root@10:/etc/e-smith/web/functions# diff -u test.mount test2.mount--- 
test.mount  2016-12-05 23:17:58.485718918 +
+++ test2.mount 2016-12-05 23:18:17.425916545 +
@@ -1,6 +1,6 @@
 #!/usr/bin/perl
 
-use My::ML;
+use Mitel::MSL::Mojolicious::ServerManagerX;
 
 app->defaults(expires => 1);
 push @{app->static->paths}, '/etc/e-smith/web/common';
root@10:/etc/e-smith/web/functions# perl -I. test.mount > /dev/null[Mon 
Dec  5 23:19:37 2016] [debug] Your secret passphrase needs to be changed
root@10:/etc/e-smith/web/functions# perl -I. test2.mount >/dev/nullString 
found where operator expected at /etc/e-smith/web/functions/mini.syslog 
line 11, near "get '/'"
(Do you need to predeclare get?)
Can't load application from file "/etc/e-smith/web/functions/mini.syslog": 
syntax error at /etc/e-smith/web/functions/mini.syslog line 6, near 
"helper syslog_enabled"
syntax error at /etc/e-smith/web/functions/mini.syslog line 9, near "}"
syntax error at /etc/e-smith/web/functions/mini.syslog line 15, near "}"
Compilation failed in require at (eval 75) line 1.
root@10:/etc/e-smith/web/functions# 

Re: [Mojolicious] Mounting Mojolicious::Lite apps under Mount plugin?

[Charlie Brady]

On Mon, 5 Dec 2016, sri wrote:

> Make a minimal test case demonstrating the problem.

I'll do my best.

Re: [Mojolicious] Mounting Mojolicious::Lite apps under Mount plugin?

[Charlie Brady]

On Mon, 5 Dec 2016, Warren Humphreys wrote:

> Is Jan Henning Thorsen's Toadfarm an option instead?

Thanks for the suggestion. Doesn't seem to make any difference to the 
compile errors.

Re: [Mojolicious] Mounting Mojolicious::Lite apps under Mount plugin?

[Charlie Brady]

On Mon, 5 Dec 2016, Stefan Adams wrote:

> On Mon, Dec 5, 2016 at 10:43 AM, Charlie Brady <
> charlieb-m...@budge.apana.org.au> wrote:

> > plugin Mount => {'/server-manager/cgi-bin/syslog' => './syslog'};
> > plugin Mount => {'/server-manager/cgi-bin/systeminformation' =>
> > './systeminformation'};
> >
> 
> It looks like all of the "syntax errors" are in syslog.  What if you
> comment that one out and let it just mount systeminformation?

I get a similar looking error:

root@10:/etc/e-smith/web/functions# ./index.mount daemon
String found where operator expected at 
/etc/e-smith/web/functions/systeminformation line 145, near "get '/'"
(Do you need to predeclare get?)
Can't load application from file 
"/etc/e-smith/web/functions/systeminformation": syntax error at 
/etc/e-smith/web/functions/systeminformation line 145, near "get '/'"
syntax error at /etc/e-smith/web/functions/systeminformation line 264, 
near "}"
Compilation failed in require at (eval 79) line 1.
root@10:/etc/e-smith/web/functions# 

> It sure is weird that syslog runs fine by itself but causes syntax errors
> when mounted.  I can't imagine how that could be!

I'm in the same boat, which is why I asked for help.

>  "my variable masks earlier declaration"...  Is it getting mounted more 
> than once?

Not as far as I know. However there might be re-declaration of the same 
helpers.

>  It has syntax errors with the Mojolicious methods get and 
> post and helper...

Which is why I suspected it was M::L related.

> Surely there's just something tiny that's being overlooked!  :O

I'm hopeful that is the case.

Re: [Mojolicious] Mounting Mojolicious::Lite apps under Mount plugin?

[Charlie Brady]

On Mon, 5 Dec 2016, Charlie Brady wrote:

> If I try to embed it within a top-level index application, like so:
> 
> ...
> use Mojolicious::Plugin::Mount;
> 
> plugin Mount => {'/server-manager/cgi-bin/syslog' => './syslog'};
> plugin Mount => {'/server-manager/cgi-bin/systeminformation' => 
> './systeminformation'};
> ...
> 
> Then I get scoping and syntax errors when I try to run it - but not with a 
> test compile - the line numbers suggest problems with helper declarations:

In case it is relevant:

root@10:/etc/e-smith/web/functions# mojo version
CORE
  Perl(v5.22.0, linux)
  Mojolicious (7.10, Doughnut)

OPTIONAL
  EV 4.0+ (n/a)
  IO::Socket::Socks 0.64+ (n/a)
  IO::Socket::SSL 1.94+   (1.997)
  Net::DNS::Native 0.15+  (0.15)

You might want to update your Mojolicious to 7.11!
root@10:/etc/e-smith/web/functions#

Re: [Mojolicious] Mounting Mojolicious::Lite apps under Mount plugin?

[Charlie Brady]

ons/syslog line 180.
"my" variable $destination_host masks earlier declaration in same scope at 
/etc/e-smith/web/functions/syslog line 181.
Can't load application from file "/etc/e-smith/web/functions/syslog": 
syntax error at /etc/e-smith/web/functions/syslog line 20, near "helper 
db"
syntax error at /etc/e-smith/web/functions/syslog line 30, near "}"
syntax error at /etc/e-smith/web/functions/syslog line 35, near "}"
syntax error at /etc/e-smith/web/functions/syslog line 40, near "}"
syntax error at /etc/e-smith/web/functions/syslog line 45, near "}"
syntax error at /etc/e-smith/web/functions/syslog line 51, near "}"
syntax error at /etc/e-smith/web/functions/syslog line 92, near "}"
syntax error at /etc/e-smith/web/functions/syslog line 101, near "}"
syntax error at /etc/e-smith/web/functions/syslog line 172, near "}"
syntax error at /etc/e-smith/web/functions/syslog line 192, near "}"
/etc/e-smith/web/functions/syslog has too many errors.
Compilation failed in require at (eval 78) line 1.
root@10:/etc/e-smith/web/functions# 



> 
> On Dec 2, 2016 6:03 PM, "Charlie Brady" 
> wrote:
> 
> 
> From some short testing it is not possible. I'd like some confirmation of
> that.
> 
> I have a significant collection of M::L programs, which are running under
> apache as CGI scripts. I'd much prefer to combine them to into a single
> app using Mojolicious::Plugin::Mount, but it looks each would need to be
> converted to a full Mojolicious app for that to be possible. Is that
> correct? Has anybody given any thought to what would need to be done to
> the Mount plugin to support M::L apps?
> 
> Thanks
> 
> 

[Mojolicious] Mounting Mojolicious::Lite apps under Mount plugin?

[Charlie Brady]

>From some short testing it is not possible. I'd like some confirmation of 
that.

I have a significant collection of M::L programs, which are running under 
apache as CGI scripts. I'd much prefer to combine them to into a single 
app using Mojolicious::Plugin::Mount, but it looks each would need to be 
converted to a full Mojolicious app for that to be possible. Is that 
correct? Has anybody given any thought to what would need to be done to 
the Mount plugin to support M::L apps?

Thanks

Re: [Mojolicious] Apache CGI deployment not serving static files from public directory

[Charlie Brady]

On Wed, 12 Oct 2016, StarX wrote:

> Thanks for the reply Charlie.  
> 
> Can you give me any pointers as to how I would set this up,

I see under https://github.com/kraih/mojo/wiki/Apache-deployment#apachecgi
some text:

"In this way you make Apache render static files from /public folder for 
you".

... which is what I am suggesting you should be doing.

> I don't have a lot of experience with Apache configuration

I am not sufficiently expert with apache configuration to tell you how to 
do it, but there do seem to be specific .htaccess instructions in the 
documentation which don't match what you are trying to use.

> - it's managed by our systems 
> admins so I'm currently stuck with CGI at the moment.
> 
> I managed to get it working by using:
> $ENV{SCRIPT_NAME} = "/dir/my_app/" in myApp.pm
> 
> Then in htaccess I have:
> AddHandler cgi-script .pl
> Options +ExecCGI
> 
> IndexIgnore *
> 
> RewriteEngine on
>  
> RewriteCond %{REQUEST_FILENAME} !-f
> RewriteCond %{REQUEST_FILENAME} !-l
> RewriteRule ^(.*)$ script/my_app.pl/$1 [L]
> 
> The code in my original question was based on the documentation in the 
> Apache Deployment info here: 
> https://github.com/kraih/mojo/wiki/Apache-deployment.  I really like 
> Mojolicious but I find that some of the documentation can be confusing for 
> someone that is relatively new to the framework.  I guess that this is what 
> this group is for though.  Thanks again.
> 
> On Tuesday, 11 October 2016 15:13:15 UTC+1, Charlie Brady wrote:
> >
> >
> > On Mon, 10 Oct 2016, StarX wrote: 
> >
> > > I've got a Mojolicious app running under CGI, but my css and js files 
> > are 
> > > not being served from the pubic directory. 
> > ... 
> > > My URLs appear correctly in the page source as /dir/my_app/css/file.css 
> > and 
> > > /dir/my_app/js/file.js but clicking them in the source just displays the 
> > > entire page content rather than the css/js.  I'm not quite sure how to 
> > > configure the rewrite correctly, can anyone help? 
> >
> > I think you should configure apache so that those files are served 
> > directly by apache, rather than attempt to have your application executed. 
> >
> 
> 

Re: [Mojolicious] Apache CGI deployment not serving static files from public directory

[Charlie Brady]

On Mon, 10 Oct 2016, StarX wrote:

> I've got a Mojolicious app running under CGI, but my css and js files are 
> not being served from the pubic directory.
...
> My URLs appear correctly in the page source as /dir/my_app/css/file.css and 
> /dir/my_app/js/file.js but clicking them in the source just displays the 
> entire page content rather than the css/js.  I'm not quite sure how to 
> configure the rewrite correctly, can anyone help?

I think you should configure apache so that those files are served 
directly by apache, rather than attempt to have your application executed.

Re: [Mojolicious] SSL when behind a proxy

[Charlie Brady]

On Thu, 11 Aug 2016, Stefan Adams wrote:

> Thank you, Dan and Sebastian!!  Thanks for the link to the code line, that
> helped me to understand that my nginx config file was missing this
> directive in the server {} container for my virtual host:
> 
> proxy_set_header X-Forwarded-Proto $scheme;

Note that RFC 7239 "Forwarded HTTP Extension" suggests "Forwarded: 
proto=https" (or rather "Forwarded: .*proto=https.*").

Re: [Mojolicious] IOLoop Connections

[Charlie Brady]

On Wed, 27 Jul 2016, Jan Henning Thorsen wrote:

> The list of events are right there in the 
> documentation: https://metacpan.org/pod/Mojo::IOLoop::Server#EVENTS

So, that gives 'accept' (directly) and 'error' (from Mojo::EventEmitter).

> 
> On Wednesday, July 13, 2016 at 2:11:44 AM UTC+2, Brian Shaw wrote:
> >
> > Thanks.  That worked well.  Do you know if there is a complete list of 
> > events?
> >
> > Brian
> >
> >
> > On Sunday, July 10, 2016 at 5:46:06 PM UTC-4, Alex Alex wrote:
> >>
> >> You could use Mojo::IOLoop::Server; accept event.
> >> https://metacpan.org/pod/Mojo::IOLoop::Server
> >>
> >>
> >>
> >>   Is there a way to tell when a client has completed the initial 
> >> connection to the server, as opposed to any other time in the life of the 
> >> connection?
> >>   With HTTP(S) you just sit and wait until the client says something like 
> >> "GET /".
> >>   I'm trying to write a mail server and the SMTP protocol specifies that 
> >> the server, not the client, starts the conversation once the client 
> >> connects.
> >>   If there is some way outside of IOLoop to do this, I'm okay with 
> >> changing directions.
> >>   Thanks for any suggestions or code snippets.
> >>
> >> Brian
> >> -- 
> >> 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...@googlegroups.com.
> >> To post to this group, send email to mojol...@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 as a non-HTTP server

[Charlie Brady]

On Tue, 5 Jul 2016, Charlie Brady wrote:

> On Mon, 4 Jul 2016, Dan Book wrote:
> 
> > Sure, Mojo::IOLoop::Server can be used for any TCP based protocol. You'll
> > have to implement a lot yourself of course.
> 
> But for SMTP you could use qpsmtpd to prove the bulk of the code.

s/prove/provide/.

Re: [Mojolicious] Mojolicious as a non-HTTP server

[Charlie Brady]

On Mon, 4 Jul 2016, Dan Book wrote:

> Sure, Mojo::IOLoop::Server can be used for any TCP based protocol. You'll
> have to implement a lot yourself of course.

But for SMTP you could use qpsmtpd to prove the bulk of the code.

[Mojolicious] Approach for pushing a series of file operations into non-blocking callback

[Charlie Brady]

I'm starting on the task of converting a preforking server into a 
non-blocking server for a small webservice. One of my handlers generates a 
data structure by reading the content of a subtree of files.

In essense, it does something like this:

...
my $data = {
 map { $_ => Mojo::Util::slurp("/path/to/files/$_" }
(qw(one two three four));
};
$c->render(json => $data);
};

Can someone give me some hints as to how to do that as a series of 
non-blocking callbacks, or do we just shrug and say "it's not going to 
block for too long".

Thanks

Re: [Mojolicious] Re: Hosting Mojolicious project in web Server

[Charlie Brady]

On Fri, 26 Feb 2016, mouleeshwara...@jothisoftware.com wrote:

> just add a look of above link (mod_proxy). How does the virtual host config 
> will get addressed to the project directory (Mojo App) ?

You need to run the mojo app on a different port  (e.g. by using 
hypnotoad). Then you configure mod_proxy to proxy the virtual host to 
localhost:.

The mod_proxy configuration doesn't need to know anything about the 
project directory - just what port () the application is bound to.

Read the docs that Luc provided a link to.

Re: [Mojolicious] Re: Mojo & SQLite

[Charlie Brady]

On Tue, 26 May 2015, Marlik wrote:

> Problem solved, I did everything as root. Thanks.

That's not "solving" the problem...

I guess you have a permission problem with your sqlite file, or the 
directory it is in...

[Mojolicious] Re: Route not found problem ("None of these routes could generate a response...")

[Charlie Brady]

On Fri, 22 May 2015, Vibhor bhardwaj wrote:

> Hi,
> 
> Have you find any solution of your problem?

Yes, as you would know if you had read to the end of the thread:

https://groups.google.com/forum/#!topic/mojolicious/7FDGtO-FV9k

"At any rate, I know what my error was .."

The problem IMO is that mojo reports back 404 when I think it should 
report 500. The same issue was noted by OmarOthman on IRC last week:

http://irclog.perlgeek.de/mojo/2015-05-11

> 
> Thanks
> 
> On Saturday, July 12, 2014 at 3:12:42 AM UTC+5:30, Charlie Brady wrote:
> >
> >
> > I hesitate to ask this, since I'm using apache/CGI, but I'm stumped, so 
> > need some help. 
> >
> > I'm getting a 404 page on form submission. But the route I'm using appears 
> > in the list shown in the default 404 page. Does anyone have a suggestion 
> > how I investigate this? 
> >
> >  
> >
> > Page not found... yet! 
> >
> > None of these routes could generate a response for your POST request for 
> > /register, maybe you need to add a new one? 
> >
> > Pattern Methods Name 
> >
> > /   GET 
> > /   POST 
> > /uploadLicense  POSTuploadLicense 
> > /register   POST"redirect_activate" 
> > /activate   GET activate 
> > /sync   POSTsync 
> > ... 
> >
> >

Re: [Mojolicious] Config options for standalone M::L application running under prefork?

[Charlie Brady]

On Mon, 27 Apr 2015, Dan Book wrote:

> What do you mean by "in-line"? I'm not sure I follow the question.
> 
> The prefork command takes command-line options:
> https://metacpan.org/pod/Mojolicious::Command::prefork

OK, and I can use those as args to app->start(). Like so:

...
#! /usr/bin/perl
use Mojolicious::Lite;

get '/' => {text => 'Hello Wor...ALL GLORY TO THE HYPNOTOAD!'};

app->start('prefork', '--listen' => 'http:/127.0.0.1:3004');
...

Well almost...

[root@sdfsdfds netrestore_rest]# perl x
Use of uninitialized value in string eq at 
/usr/share/perl5/vendor_perl/Mojo/Server/Daemon.pm line 151.
Use of uninitialized value in string eq at 
/usr/share/perl5/vendor_perl/Mojo/Server/Daemon.pm line 175.
Server available at http:/127.0.0.1/*:3004.
^C[root@sdfsdfds netrestore_rest]#

That's with Mojolicious 5.50. I'll check again with most recent.

Re: [Mojolicious] Config options for standalone M::L application running under prefork?

[Charlie Brady]

On Mon, 27 Apr 2015, Dan Book wrote:

> What do you mean by "in-line"? I'm not sure I follow the question.

I would like to have a file called 'run', which I can start using './run', 
which will start up in prefork mode, using listen parameters which are 
specified within the file 'run'.

> The prefork command takes command-line options:
> https://metacpan.org/pod/Mojolicious::Command::prefork

Yes, I know, but I would rather have one file than two, so I don't need a 
shell script which just does:

#! /bin/sh
./my_command prefork -l http://127.0.0.1:3006 -w 10 -c 1 [etc]

With hypnotoad I can have one file with:

...
#! /usr/bin/hypnotoad -foreground
...
app->config(hypnotoad => {listen => ['http://127.0.0.1:3006'], workers 
=> 3});
...

> Otherwise if you just need hypnotoad to stay in the foreground (and you
> don't need hot-deployment) you can use hypnotoad -f.

As we've discussed recently on this list, hypnotoad doesn't play nicely 
under process supervisors such as runit, daemontools, etc. prefork was the 
recommended option.

https://groups.google.com/forum/#!msg/mojolicious/sgUj3obB6eU/HdTCgMhzrvYJ

> On Mon, Apr 27, 2015 at 4:11 PM, Charlie Brady <
> charlieb-m...@budge.apana.org.au> wrote:
> 
> >
> > I see in Cookbook this standalone M::L app running under hypnotoad.
> >
> > ...
> > use Mojolicious::Lite;
> >
> > app->config(hypnotoad => {listen => ['http://*:80']});
> >
> > get '/' => {text => 'Hello Wor...ALL GLORY TO THE HYPNOTOAD!'};
> >
> > app->start;
> > ...
> >
> > I want to do something very similar, but using prefork mode (to behave
> > nicely under runit supervision, where the parent process is expected to
> > survive until terminated).
> >
> > I can't find a way to configure mode and options in-line, rather than
> > provided via @ARGV.
> >
> > Thanks for your advice...
> >
> 
> 

[Mojolicious] Config options for standalone M::L application running under prefork?

[Charlie Brady]

I see in Cookbook this standalone M::L app running under hypnotoad.

...
use Mojolicious::Lite;

app->config(hypnotoad => {listen => ['http://*:80']});

get '/' => {text => 'Hello Wor...ALL GLORY TO THE HYPNOTOAD!'};

app->start;
...

I want to do something very similar, but using prefork mode (to behave 
nicely under runit supervision, where the parent process is expected to 
survive until terminated).

I can't find a way to configure mode and options in-line, rather than 
provided via @ARGV.

Thanks for your advice...

Re: [Mojolicious] How to have a non-blocking 'any' route, which proxies multiple method requests?

[Charlie Brady]

On Sun, 12 Apr 2015, Jan Henning Thorsen wrote:

> Are you building a proxy..? Maybe you want to have a look at either of 
> these:
> 
> https://metacpan.org/pod/Mojolicious::Plugin::Proxy

It looks to me that will proxy only get requests. It would be interesting 
to see that extended for post, etc.

> https://github.com/mojoconf/MCT/blob/master/lib/MCT/Plugin/ACT.pm

I can't quite tell what that does, and the pod isn't helpful :-)

> On Saturday, April 11, 2015 at 11:06:03 PM UTC+2, Charlie Brady wrote:
> >
> >
> > On Sat, 11 Apr 2015, Dan Book wrote: 
> >
> > > Perhaps this way: 
> > > my $tx = $ua->build_tx($method => ... normal get/post/etc args ...); 
> > > $ua->start($tx => sub { 
> > >   ... 
> > > }); 
> >
> > Thanks. I'll try that. 
> >
> > Next problem is what needs to be done to read the request body and 
> > transfer it to the ua. Would that happen automatigically if the req is 
> > cloned? In this case, would Mojo buffer the request? Does anyone have a 
> > gist which proxies a request without reading and caching the request body? 
> >
> > I've found this which deals with some of these issues: 
> >
> > https://larig.wordpress.com/2012/08/01/a-mini-proxy-via-mojolicious/ 
> >
> > Thanks all. 
> >
> > > 
> > > On Fri, Apr 10, 2015 at 4:01 PM, Charlie Brady < 
> > > charlieb-m...@budge.apana.org.au> wrote: 
> > > 
> > > > 
> > > > https://github.com/kraih/mojo/wiki/Blocking-vs-non-blocking-101 
> > > > 
> > > > I see I can do this to have a non-blocking get handler: 
> > > > 
> > > > ... 
> > > >   $self->render_later; 
> > > > 
> > > >   $self->ua->get('http://www.superhugepage.com/blah.html' => sub {}); 
> > > > ... 
> > > > 
> > > > But I don't understand how to use Mojo::UserAgent in an 'any' handler, 
> > > > where method might be 'get', 'put', 'delete', etc. Do I build a tx, 
> > attach 
> > > > the callback to 'finish', then start it? Or just do: 
> > > > 
> > > > $method = $self->req->method; 
> > > > $self->ua->$method() 
> > > > 
> > > > ? 
> > > > 
> > > > Thanks 
> > > > 
> > > 
> > > 
> >
> 

Re: [Mojolicious] How to have a non-blocking 'any' route, which proxies multiple method requests?

[Charlie Brady]

On Sat, 11 Apr 2015, Dan Book wrote:

> Perhaps this way:
> my $tx = $ua->build_tx($method => ... normal get/post/etc args ...);
> $ua->start($tx => sub {
>   ...
> });

Thanks. I'll try that.

Next problem is what needs to be done to read the request body and 
transfer it to the ua. Would that happen automatigically if the req is 
cloned? In this case, would Mojo buffer the request? Does anyone have a 
gist which proxies a request without reading and caching the request body?

I've found this which deals with some of these issues:

https://larig.wordpress.com/2012/08/01/a-mini-proxy-via-mojolicious/

Thanks all.

> 
> On Fri, Apr 10, 2015 at 4:01 PM, Charlie Brady <
> charlieb-m...@budge.apana.org.au> wrote:
> 
> >
> > https://github.com/kraih/mojo/wiki/Blocking-vs-non-blocking-101
> >
> > I see I can do this to have a non-blocking get handler:
> >
> > ...
> >   $self->render_later;
> >
> >   $self->ua->get('http://www.superhugepage.com/blah.html' => sub {});
> > ...
> >
> > But I don't understand how to use Mojo::UserAgent in an 'any' handler,
> > where method might be 'get', 'put', 'delete', etc. Do I build a tx, attach
> > the callback to 'finish', then start it? Or just do:
> >
> > $method = $self->req->method;
> > $self->ua->$method()
> >
> > ?
> >
> > Thanks
> >
> 
> 

[Mojolicious] How to have a non-blocking 'any' route, which proxies multiple method requests?

[Charlie Brady]

https://github.com/kraih/mojo/wiki/Blocking-vs-non-blocking-101

I see I can do this to have a non-blocking get handler:

...
  $self->render_later;

  $self->ua->get('http://www.superhugepage.com/blah.html' => sub {});
...

But I don't understand how to use Mojo::UserAgent in an 'any' handler, 
where method might be 'get', 'put', 'delete', etc. Do I build a tx, attach 
the callback to 'finish', then start it? Or just do:

$method = $self->req->method;
$self->ua->$method()

?

Thanks

[Mojolicious] Accessing response cookies by name?

[Charlie Brady]

I'm using Test::Mojo to verify cookie handling in some existing code. I 
don't see an elegant way to verify that cookies with the right value are 
being set in a response.

Is there a more elegant way to select particular cookies than grep of
@{$res->cookies}?

Thanks

Re: [Mojolicious] How to use string as a subroutine ref in Mojo?

[Charlie Brady]

On Wed, 17 Dec 2014, Jan Henning Thorsen wrote:

> Pavel, you can do this:
> 
> my $b = __PACKAGE__->can($a);
> $b->("stuff") if $code;

I guess you mean:

$b->("stuff") if $b;

Re: [Mojolicious] equivalent to django debug toolbar ?

[Charlie Brady]

On Thu, 9 Oct 2014, mjb152 wrote:

> is there an equivalent to djangos debug toolbar for mojolicious ?
> I'm interested in something to show me a little about the environment, but 
> more specifically for form development/debugging.  I'd like to easily see 
> what I've passed in,  the method etc

Maybe there's noone here who is a wizard with Mojolicous and also familiar 
with django's debug toolbar.

You could have a look at:

Mojolicious::Plugin::ConsoleLogger
Mojolicious::Plugin::JavaScript::Console

and see if that helps you.

> 
> anyone written anything nice I could use ?   what's normal practice here ?
> 
> 

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Fetching cdata content of tags with Mojo::DOM?

[Charlie Brady]

On Mon, 21 Jul 2014, sri wrote:

> It's nice that you want to share your solutions, but please don't spam the 
> list.

Sorry if you thought I did that. I thought I was asking for help. I'd 
still like some help if someone is able to provide it. 

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Fetching cdata content of tags with Mojo::DOM?

[Charlie Brady]

On Mon, 21 Jul 2014, Charlie Brady wrote:

> No, that doesn't work for me, because of whitespace.
> 
> cf.
> 
> $dom->parse('123')
> 
> and:
> 
> $dom->parse(' 123')
> 
> Can anybody suggest anything, should of using s/// and parsing a new 
> Mojo::DOM object? I can see Mojo::DOM::text, but dont see how I could use 
> it.

Sorry, everyone. I need more sleep. That should say:

.. short of using s/// and parsing a new Mojo::DOM object.

I have my code working that way now, but it seems excessive to parse those 
fragments all over again.

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Fetching cdata content of tags with Mojo::DOM?

[Charlie Brady]

On Mon, 21 Jul 2014, Charlie Brady wrote:

> On Mon, 21 Jul 2014, Charlie Brady wrote:
> 
> > So I can do:
> 
> Without the stupid c&p error:
> 
>   my %lexicon = map
>  { my $entry = $_ ; 
> $entry->base->content => 
>$entry->trans->contents->first->content
>  }
>   $dom->find('lexicon entry')->each;

No, that doesn't work for me, because of whitespace.

cf.

$dom->parse('123')

and:

$dom->parse(' 123')

Can anybody suggest anything, should of using s/// and parsing a new 
Mojo::DOM object? I can see Mojo::DOM::text, but dont see how I could use 
it.


-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Fetching cdata content of tags with Mojo::DOM?

[Charlie Brady]

On Mon, 21 Jul 2014, Charlie Brady wrote:

> So I can do:

Without the stupid c&p error:

  my %lexicon = map
 { my $entry = $_ ; 
$entry->base->content => 
   $entry->trans->contents->first->content
 }
  $dom->find('lexicon entry')->each;
 
 

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Fetching cdata content of tags with Mojo::DOM?

[Charlie Brady]

On Mon, 21 Jul 2014, Charlie Brady wrote:

> I'm trying to turn this into a hash from which I can look up the 
> translations:
> 
> my %lexicon = map
>{ $entry->base->content => $entry->trans->content} 
> $dom->find('lexicon entry')->each;
> 
> but then I find that $lexicon{UNREG_DESC} gives me '

[Mojolicious] Fetching cdata content of tags with Mojo::DOM?

[Charlie Brady]

I have some translation files which are XML documents, which contain some 
cdata elements:

...

ACTIVATE
Activate


UNREG_DESC




...

I'm trying to turn this into a hash from which I can look up the 
translations:

my %lexicon = map
   { $entry->base->content => $entry->trans->content} 
$dom->find('lexicon entry')->each;

but then I find that $lexicon{UNREG_DESC} gives me '

Re: [Mojolicious] Loading template from different directory

[Charlie Brady]

On Wed, 16 Jul 2014, Raunak Kathuria wrote:

> Thanks for the answer, just basic query regarding this
> 
> What is the best place to use this? Is it in Controller or Helpers or Hooks 
> or before every request to the layout? As i want it to be the default one 
> so as to use this all the time

You'll have to decide what is "best", but you can put it in your app like 
so:

use Mojolicious::Lite;

push @{app->renderer->paths}, '/path/to/your/templates';

...

app->start;


> 
> On Thursday, 17 July 2014 11:34:42 UTC+8, Jonathan O wrote:
> >
> > This is probably a good start:
> >
> > http://mojolicio.us/perldoc/Mojolicious/Renderer#paths
> >
> > Jonathan Otsuka
> > On Jul 16, 2014, at 10:00 PM, Raunak Kathuria  > > wrote:
> >
> > How can we load layout/templates from separate directory rather than the 
> > default template directory (on same hierarchy level of lib, public). I will 
> > explain the scenario
> > As of now we use to load it from default template directory but now we are 
> > going to open source our templates for white-labeling so the directory 
> > structure will change and templates will be moved to altogether different 
> > separate directory 
> >
> > For e.g say if earlier it was */home/git/parent/template* along with 
> > */home/git/parent/lib* at same level but now the templates will be moved 
> > to something like this */home/git/new_repo/template* but the lib will 
> > remain in same directory
> >
> > So how can we handle this scenario? Can we serve templates from different 
> > directory?
> >
> > -- 
> > 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...@googlegroups.com .
> > To post to this group, send email to mojol...@googlegroups.com 
> > .
> > Visit this group at http://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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Route not found problem ("None of these routes could generate a response...")

[Charlie Brady]

On Fri, 11 Jul 2014, Charlie Brady wrote:

> On Fri, 11 Jul 2014, sri wrote:
> 
> > If only there was debug information... something like log messages... we 
> > could show those at the bottom of the 404 page!
> 
> I don't know what you are getting at.

Ah, now I do. The debug log shows me:

[debug] POST "/register".
[debug] Routing to a callback.
[debug] Template "redirect_activate.html.ep" not found.

So instead of:

 None of these routes could generate a response for your POST request for
 "/register", maybe you need to add a new one?

it could say:

  None of these routes could generate a response for your POST request for
 "/register"; either a matching route was found and could not generate a
 response, or you need to add a new one?

... or some state could be saved in stash, and the 404 template could be 
more explicit about the problem - that a route was found, but it failed to 
generate a response.

At any rate, I know what my error was:

...
$self->render;
} => 'redirect_activate';
...

with no matching template.

Thanks for the hint.

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Route not found problem ("None of these routes could generate a response...")

[Charlie Brady]

On Fri, 11 Jul 2014, sri wrote:

> > I think it's a bug - nobody should get that. The helpful 404 page should 
> > be, well, helpful.

I think I should have been clearer.

The 404 page is generally helpful. However in this case, rather than 
helpful, it is confusing. It says:

...
None of these routes could generate a response for your POST request for 
"/register", maybe you need to add a new one?
...

But then it shows me that I have a route for POST requests to "/register":

...
/register   POST"redirect_activate"
...

So I find that confusing.

> If only there was debug information... something like log messages... we 
> could show those at the bottom of the 404 page!

I don't know what you are getting at.

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Route not found problem ("None of these routes could generate a response...")

[Charlie Brady]

On Fri, 11 Jul 2014, Stefan Adams wrote:

> I get that a lot too.

I think it's a bug - nobody should get that. The helpful 404 page should 
be, well, helpful.

> Could it be that the redirect_activate method
> couldn't be reached?

That's a "Name" in the table. I don't have the code accessible, but as I 
recall it's:

post "/register" => sub {
...
} => "redirect_activate";

So I don't really understand your comment. Is "redirect_activate" a 
method? What would "could not be reached" mean? Are "Names" used in route 
lookup?

Anyway, somethings wrong. In my code, no doubt, but I think also in Mojo, 
which should be able to provide a more useful diagnostic.

> On Jul 11, 2014 4:42 PM, "Charlie Brady" 
> wrote:
> 
> >
> > I hesitate to ask this, since I'm using apache/CGI, but I'm stumped, so
> > need some help.
> >
> > I'm getting a 404 page on form submission. But the route I'm using appears
> > in the list shown in the default 404 page. Does anyone have a suggestion
> > how I investigate this?
> >
> > 
> >
> > Page not found... yet!
> >
> > None of these routes could generate a response for your POST request for
> > /register, maybe you need to add a new one?
> >
> > Pattern Methods Name
> >
> > /   GET
> > /   POST
> > /uploadLicense  POSTuploadLicense
> > /register   POST"redirect_activate"
> > /activate   GET activate
> > /sync   POSTsync
> > ...
> >
> > --
> > 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 http://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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] Route not found problem ("None of these routes could generate a response...")

[Charlie Brady]

I hesitate to ask this, since I'm using apache/CGI, but I'm stumped, so 
need some help.

I'm getting a 404 page on form submission. But the route I'm using appears 
in the list shown in the default 404 page. Does anyone have a suggestion 
how I investigate this? 



Page not found... yet!

None of these routes could generate a response for your POST request for 
/register, maybe you need to add a new one?

Pattern Methods Name

/   GET
/   POST
/uploadLicense  POSTuploadLicense
/register   POST"redirect_activate"
/activate   GET activate
/sync   POSTsync
...

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] tag helpers and XML escaping

[Charlie Brady]

My reading of the docs suggests that 

%== tag td => $var

won't XML escape $var. But I'm find that not to be the case.

% my $nbsp = ' ';
%== tag td => b($nbsp)
%== tag td => $nbsp
%== tag td => begin
<%== $nbsp %>
% end

generates:

 
 

 


I find that exactly the same text is generated by:

% my $nbsp = ' ';
%= tag td => b($nbsp)
%= tag td => $nbsp
%= tag td => begin
<%== $nbsp %>
% end

So is this an error? If not, could someone point me to what I have 
misunderstood.

Is the (rather verbose) begin/end form of the tag the only way that I can 
embed ' ' in a table cell?

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Wishlist thread (second edition)

[Charlie Brady]

On Wed, 9 Jul 2014, Abhijit Menon-Sen wrote:

> At 2014-07-09 22:08:30 +0530, a...@toroid.org wrote:
> >
> > This isn't exactly what you wrote, but too far off:
> 
> Sorry, *not* too far off.

Yes, not too far off. But only for get requests, and it buffers responses. 
I need to proxy at least get/head/post/put/del. I'm sure a good solution 
could be built into Mojo, but Mojolicious::Plugin::Proxy is too 
simplistic.

See also:

http://marcus.nordaaker.com/my-first-mojolicious-plugin-proxy/

http://larig.wordpress.com/2012/08/01/a-mini-proxy-via-mojolicious/

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Wishlist thread (second edition)

[Charlie Brady]

On Sun, 6 Jul 2014, sri wrote:

> In this thread you can post changes or features you would like to see in 
> Mojolicious, no rules, just blurt away. :)

A plugin like Mount, but which proxies requests and responses, so instead 
of:

my $route = plugin Mount => {'/prefix' => '/home/sri/myapp.pl'};

I can do:

my $route = plugin Proxy => {'/tomcat' => 'http://localhost:8080/'};

cf ProxyPass and ProxyPassReverse in apache. This would help me to be rid 
of apache and CGI.

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Request URI not being parsed correctly in CGI mode

[Charlie Brady]

[BTW, the Subject is ironic - Request URI *is* being parsed correctly in 
CGI mode. OP had a broken suexec module in apache which didn't correctly 
implement CGI.]

On Sat, 14 Jun 2014, Abhijit Menon-Sen wrote:

> If you want to use the latest version of Mojolicious, then surely you
> can install Mojo::Server::CGI from a separate distribution.

If Mojo::Server::CGI becomes abandonware, then Mojo::Server::CGI may not 
actually work with the latest version of Mojolicious. With the current 
bundling, the test harnesses ensure that it will work.

> Or if you can't install new modules, then you probably shouldn't try to 
> upgrade Mojolicious either.

Continuing to use old versions of Mojolicious is deprecated. And also 
undesirable because lots of wonderful new stuff is coming with new 
versions of Mojolicious.

> I'm trying to understand why you're objecting. Help?

I can't speak for Michael Soulier, but I've tried to explain myself above. 

But I should shut up. I see from IRC logs that some people think it 
offensive for me to say "Please do not remove CGI - it is very useful to 
me". I'm sorry - no offense is intended. I just want to be able to use 
latest Mojolicious - within the constraints imposed upon me.

---
Charlie

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Request URI not being parsed correctly in CGI mode

[Charlie Brady]

On Fri, 13 Jun 2014, sri wrote:

>  That's rather ignorant of the actual situation. CGI is not going away, 
> just one of the two ways to deploy in CGI environments we currently support 
> would get moved into a separate distribution. The simple truth is that 
> nobody on the core team has actually used CGI in many years, know how is 
> dwindling and at some point we will be unable to react to problems that may 
> arise, this is an unacceptable situation.

CGI is a static target. It doesn't change. AFAICT it works just perfectly, 
and the test harnesses seem to say the same.

> I am well aware that there's a vocal minority that wants to keep 
> Mojo::Server::CGI in core, but at the same time nobody from this minority 
> has even attempted to solve our problems with better documentation. The 
> relevant wiki page for example has seen no major edits in a very long time.
> 
> https://github.com/kraih/mojo/wiki/Apache-deployment

If you or anyone else can identify deficiencies in the documentation I can 
try to fix them. That said, I'm not an apache expert. Nor expert on any 
other web server.

---
Charlie

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Request URI not being parsed correctly in CGI mode

[Charlie Brady]

On Fri, 13 Jun 2014, Helmut Wollmersdorfer wrote:

> Am Montag, 9. Juni 2014 17:19:56 UTC+2 schrieb Charlie Brady:
> >
> > No, RHEL does have a mechanism of resolving dependencies. 'yum' will do 
> > that. However many of the modules required by Plack are not included in 
> > the standard RHEL repositories. 
> 
> Then use another distribution. I always came back to Debian in the last 
> 16 years. Or use CPAN directly, or perlbrew+cpanm, or carton, or ...

That's great for you. If I were working alone, then perhaps I would do the 
same. But I am working in a corporate situation where those choices are 
not mine to make.

> IMHO users of Apache make the mistake to solve non-existing problems in 
> Apache, thinking CGI/PHP, doing url-rewrite, redirect and so on. And that's 
> harmful, where I can understand sri not willing to support or debug insane 
> configurations.

I am not asking sri to support or debug insane configurations. I am just 
asking that he not remove a perfectly good CGI implementation just because 
some people use insane apache configurations.

--
Charlie

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Routing issue.

[Charlie Brady]

On Tue, 3 Jun 2014, rdhdr...@gmail.com wrote:

> And sure enough all requests that dont begin with /cgi-bin are mapped to 
> cgi-bin/foo.cgi
> 
> foo.cgi contains this>
> use Mojolicious::Lite;
> 
> get '/login' => { text => ( 'login time' ) } ;
> get '/' => {text => ( 'Hello World! REQUEST_URI = ' .  
> $ENV{'REQUEST_URI'}   ) };
> app->start;
> 
> But requests for http://foo.bar/login 
>  
> Hello World! REQUEST_URI = /login
> 
> How does one build a route for /login ? 

Did you try 'login' rather than '/login'?

Printing $REQUEST_URI isn't useful to your troubleshooting, since it's not 
part of the COMMON GATEWAY INTERFACE and isn't used by Mojolicious for 
routing.

Try looking at PATH_INFO and SCRIPT_NAME if you still have problems.

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Request URI not being parsed correctly in CGI mode

[Charlie Brady]

On Mon, 9 Jun 2014, sri wrote:

> > [root@sdfdsf ~]# rpm -Uhv perl-Plack-0.9979-2.el6.rfx.noarch.rpm 
> > error: Failed dependencies: 
> > perl(Devel::StackTrace) >= 1.23 is needed by 
[snip]

> I'm having a very hard time following your argument here,

Sorry.

> are you implying that RHEL has no way of resolving the dependencies for 
> you?

No, RHEL does have a mechanism of resolving dependencies. 'yum' will do 
that. However many of the modules required by Plack are not included in 
the standard RHEL repositories.

...
--> Finished Dependency Resolution
Error: Package: perl-Plack-0.9979-2.el6.rfx.noarch 
(/perl-Plack-0.9979-2.el6.rfx.noarch)
   Requires: perl(Hash::MultiValue) >= 0.05
Error: Package: perl-Plack-0.9979-2.el6.rfx.noarch 
(/perl-Plack-0.9979-2.el6.rfx.noarch)
   Requires: perl(Devel::StackTrace::AsHTML) >= 0.11
Error: Package: perl-Plack-0.9979-2.el6.rfx.noarch 
(/perl-Plack-0.9979-2.el6.rfx.noarch)
   Requires: perl(Try::Tiny)
Error: Package: perl-Plack-0.9979-2.el6.rfx.noarch 
(/perl-Plack-0.9979-2.el6.rfx.noarch)
   Requires: perl(Devel::StackTrace) >= 1.23
   Available: 1:perl-Devel-StackTrace-1.22-4.el6.noarch (base)
   perl(Devel::StackTrace) = 1.22
Error: Package: perl-Plack-0.9979-2.el6.rfx.noarch 
(/perl-Plack-0.9979-2.el6.rfx.noarch)
   Requires: perl(Test::TCP) >= 0.11
Error: Package: perl-Plack-0.9979-2.el6.rfx.noarch 
(/perl-Plack-0.9979-2.el6.rfx.noarch)
   Requires: perl(File::ShareDir) >= 1.00
Error: Package: perl-Plack-0.9979-2.el6.rfx.noarch 
(/perl-Plack-0.9979-2.el6.rfx.noarch)
   Requires: perl(HTTP::Body) >= 1.06
Error: Package: perl-Plack-0.9979-2.el6.rfx.noarch 
(/perl-Plack-0.9979-2.el6.rfx.noarch)
   Requires: perl(Filesys::Notify::Simple)
...

Even with the addition of the epel repositories, there are still 
unresolved dependencies.

...
Error: Package: perl-Plack-0.9979-2.el6.rfx.noarch 
(/perl-Plack-0.9979-2.el6.rfx.noarch)
   Requires: perl(Devel::StackTrace) >= 1.23
   Available: 1:perl-Devel-StackTrace-1.22-4.el6.noarch (base)
   perl(Devel::StackTrace) = 1.22
Error: Package: perl-Plack-0.9979-2.el6.rfx.noarch 
(/perl-Plack-0.9979-2.el6.rfx.noarch)
   Requires: perl(Devel::StackTrace::AsHTML) >= 0.11
...

The only point I am making is that this assertion is false:

  Literally all you have to do is change the shebang line.

CGI "just works". It would be a shame to see it be removed.

>From what I can see, deployment using PSGI under apache is signficantly 
more complex than with CGI, and not necessarily less error prone:

https://groups.google.com/forum/#!topic/mojolicious/oXeCLxe6hIY

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Request URI not being parsed correctly in CGI mode

[Charlie Brady]

On Fri, 6 Jun 2014, sri wrote:

> > I'd consider it to be quite a headache to need to set up a PSGI on all my 
> > systems which currently run multiple CGIs just fine.
> 
> What is *a* PSGI?

Sorry, a typo - an important missing word - "a PSGI environment". Which, 
unfortunately, is not trivial. Unlike with Mojolicious, one soon enters 
dependency hell...

[root@sdfdsf ~]# rpm -Uhv perl-Plack-0.9979-2.el6.rfx.noarch.rpm 
error: Failed dependencies:
perl(Devel::StackTrace) >= 1.23 is needed by 
perl-Plack-0.9979-2.el6.rfx.noarch
perl(Devel::StackTrace::AsHTML) >= 0.11 is needed by 
perl-Plack-0.9979-2.el6.rfx.noarch
perl(File::ShareDir) >= 1.00 is needed by 
perl-Plack-0.9979-2.el6.rfx.noarch
perl(Filesys::Notify::Simple) is needed by 
perl-Plack-0.9979-2.el6.rfx.noarch
perl(HTTP::Body) >= 1.06 is needed by perl-Plack-0.9979-2.el6.rfx.noarch
perl(Hash::MultiValue) >= 0.05 is needed by 
perl-Plack-0.9979-2.el6.rfx.noarch
perl(Test::TCP) >= 0.11 is needed by perl-Plack-0.9979-2.el6.rfx.noarch
perl(Try::Tiny) is needed by perl-Plack-0.9979-2.el6.rfx.noarch
perl(parent) is needed by perl-Plack-0.9979-2.el6.rfx.noarch
[root@sdfdsf ~]# 

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Request URI not being parsed correctly in CGI mode

[Charlie Brady]

On Fri, 6 Jun 2014, sri wrote:

> > I'm not sure of the apache version. I don't remember totally, but I 
> > wouldn't be surprised if it was a manual tweak to our suexec to increase 
> > security within our organization.
> 
> You bring up a very good point though, this shit really makes my blood 
> boil, the RFC for CGI is basically worthless, because everybody cooks up 
> their own little subset/superset.

Everybody?

A subset is just broken, and not your problem. A superset is irrelevant.

> This might be the strongest argument yet for getting rid of 
> Mojo::Server::CGI and leaving all legacy deployment to 
> Mojo::Server::PSGI, which has been much less of a headache.

I'd consider it to be quite a headache to need to set up a PSGI on all my 
systems which currently run multiple CGIs just fine.

There's barely any change in CGI.pm between 3.33 and 5.04 - is it really 
such a maintenance burden?

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Request URI not being parsed correctly in CGI mode

[Charlie Brady]

On Fri, 6 Jun 2014, Joel Martinez wrote:

> I'm not sure of the apache version. I don't remember totally, but I 
> wouldn't be surprised if it was a manual tweak to our suexec to increase 
> security within our organization.  

You said "I enabled these and everything is working splendidly". Can you 
verify that you edited suexec.c and rebuilt apache? Do you have before and 
after versions of the code?
 
> I would still recommend mentioning the requirement of these environment 
> variables to exist somewhere in the Mojolicious docs.

I don't think repeating the specification of the CGI belongs in the 
Mojolicious docs.

> On Friday, June 6, 2014 1:45:05 PM UTC-7, Charlie Brady wrote:
> >
> >
> > On Tue, 5 Feb 2013, Joel Martinez wrote: 
> >
> > >> But it appears Mojolicious needs PATH_INFO, HTTPS or SERVER_PROTOCOL, 
> > >> and SCRIPT_NAME in it's routine.  Do you have any clue why these might 
> > >> not be  set as environment variables correctly? 
> > > 
> > > SOLVED! 
> > > 
> > > It turns out an apache module "suexec" was blocking these (and many 
> > other) 
> > > environment variables from being set.  Turns out "suexec" has a 
> > whitelist 
> > > of environment variables that it allows.  I enabled these and everything 
> > is 
> > > working splendidly. 
> >
> > What version of apache were you using? I see PATH_INFO, HTTPS, 
> > SERVER_PROTOCOL and SCRIPT_NAME in safe_env_lst[] in suexec.c in apache 
> > 2.2.15 source code, so they are already whitelisted in that version. 
> >
> > > On a side note... to save others the frustration I went through, perhaps 
> > > you could add some sort of sanity check for these environment variables 
> > in 
> > > CGI mode.  Seeing as how this parse_env function depends on them, it 
> > would 
> > > be nice to see some sort of error if they couldn't be found instead of 
> > > silently failing. 
> >
> > If anyone knows of problems with request parsing/routing in CGI, please 
> > report via github issues. 
> >
> > > 
> > > Thanks for your help. 
> > > 
> > > On Tuesday, February 5, 2013 10:02:26 AM UTC-8, sri wrote: 
> > > > 
> > > > > If you want to work on this, all our test cases can be found here. 
> > > > > 
> > > > >https://github.com/kraih/mojo/blob/master/t/mojo/request_cgi.t 
> > > > 
> > > > And the actual parser is here. 
> > > > 
> > > > 
> > > > 
> > https://github.com/kraih/mojo/blob/master/lib/Mojo/Message/Request.pm#L203 
> > > > 
> > > > -- 
> > > > Sebastian Riedel 
> > > > http://twitter.com/kraih 
> > > > http://mojolicio.us 
> > > > 
> > > 
> > > 
> >
> 
> 

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Request URI not being parsed correctly in CGI mode

[Charlie Brady]

On Tue, 5 Feb 2013, Joel Martinez wrote:

>> But it appears Mojolicious needs PATH_INFO, HTTPS or SERVER_PROTOCOL, 
>> and SCRIPT_NAME in it's routine.  Do you have any clue why these might 
>> not be  set as environment variables correctly?
>
> SOLVED!
> 
> It turns out an apache module "suexec" was blocking these (and many other) 
> environment variables from being set.  Turns out "suexec" has a whitelist 
> of environment variables that it allows.  I enabled these and everything is 
> working splendidly.

What version of apache were you using? I see PATH_INFO, HTTPS, 
SERVER_PROTOCOL and SCRIPT_NAME in safe_env_lst[] in suexec.c in apache 
2.2.15 source code, so they are already whitelisted in that version.

> On a side note... to save others the frustration I went through, perhaps 
> you could add some sort of sanity check for these environment variables in 
> CGI mode.  Seeing as how this parse_env function depends on them, it would 
> be nice to see some sort of error if they couldn't be found instead of 
> silently failing.

If anyone knows of problems with request parsing/routing in CGI, please 
report via github issues.

> 
> Thanks for your help.
> 
> On Tuesday, February 5, 2013 10:02:26 AM UTC-8, sri wrote:
> >
> > > If you want to work on this, all our test cases can be found here. 
> > > 
> > >https://github.com/kraih/mojo/blob/master/t/mojo/request_cgi.t 
> >
> > And the actual parser is here. 
> >
> > 
> > https://github.com/kraih/mojo/blob/master/lib/Mojo/Message/Request.pm#L203 
> >
> > -- 
> > Sebastian Riedel 
> > http://twitter.com/kraih 
> > http://mojolicio.us 
> >
> 
> 

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Routing issue.

[Charlie Brady]

On Thu, 5 Jun 2014, rdhdr...@gmail.com wrote:

> Further tinkering confirms that the routing engine is clearly looking at 
> 'URL:" not REQUEST_URI  Is there a fix? 

$REQUEST_URI is not part of the Common Gateway Interface (version 1.1), 
defined by:

http://tools.ietf.org/html/rfc3875

Neither is 'URL:'.

I'm not sure what your issue is, but if you go here:

https://github.com/kraih/mojo/issues/new

and provide details of your issue I'll look into it.

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Routing issue.

[Charlie Brady]

On Fri, 6 Jun 2014, sri wrote:

> > Are there really so many such threads?
> 
> Yes, and now i'm going to turn this into an ultimatum, either some of our 
> CGI users step up to improve the situation, to the point where these 
> threads do not pop up again, or Mojo::Server::CGI will be going away in the 
> not so distant future.

Robin, please post your problem details to the issue tracker, and let's 
work on a solution there.

---
Charlie

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Routing issue.

[Charlie Brady]

On Thu, 5 Jun 2014, sri wrote:

> > The Apache config isn't complex, and wasn't difficult. 
> >
> > I don't use suexec so I haven't seen the problem which initiated this 
> > thread. Routing works properly for my CGIs.
> 
> What exactly is the point you're trying to make here? CGI is not a problem 
> for you and therefore can't be a problem for anyone else?

That's a strange conclusion for you to jump to. I was simply saying that I 
have no experience of the routing issue which OP reported - probably 
because I don't use suexec.

My point in posting here is that you pointed to a thread, which included a 
solution I posted - use a setuid script. I posted here an update to the 
patch required.

Why the hostility?

> I simply want these threads about Apache configurations and CGI 
> environments to stop.

Are there really so many such threads?

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Routing issue.

[Charlie Brady]

On Thu, 5 Jun 2014, Stefan Adams wrote:

> What I love about Mojolicious is that it does everything.  But I would
> certainly understand the case to not support the ancient CGI.  Mojolicious
> is a modern framework.  Why should it support CGI?

I have an apache config which supports a grab bag of named virtual hosts 
with different config, and various parts of the URL name space being 
static content, proxy-pass to different servers running on different 
ports, and many different CGIs, in different languages, supplied by 
different developer groups. I doubt that it would be easier done via a 
single Mojolicious server than by apache, and if it could be, it's not 
obvious to me how you would do it.

The Apache config isn't complex, and wasn't difficult.

I don't use suexec so I haven't seen the problem which initiated this 
thread. Routing works properly for my CGIs.

---
Charlie

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Re: Routing issue.

[Charlie Brady]

On Thu, 5 Jun 2014, sri wrote:

> And you've missed the actual solution which is mentioned later in that 
> thread.
> 
> https://groups.google.com/forum/#!msg/mojolicious/JBRLsmY72MU/EIIUcsoVmbkJ

This is the only patch I find I need with recent Mojolicious for use with 
setuid perl scripts:

--- Mojolicious-4.91/lib/Mojo/Template.pm.orig  2014-03-14 19:58:22.0 
-0400
+++ Mojolicious-4.91/lib/Mojo/Template.pm   2014-03-31 19:39:49.0 
-0400
@@ -93,6 +93,8 @@
 
   # Compile with line directive
   return undef unless my $code = $self->code;
+  # Workaround for use in taint check mode
+  use Taint::Util; untaint $code;
   my $compiled = eval $self->_wrap($code);
   $self->compiled($compiled) and return undef unless $@;
 

And the same could be done without the dependency using a regex untain.

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] Is there a good reason I can no longer have a helper called '_'?

[Charlie Brady]

In 4.50 and before, I could. With 4.51 I started to get a namespace 
problem. Perhaps this is a bug.

Undefined subroutine &main::_ called at template home.html.ep from DATA 
section line 2.

#!/usr/bin/perl -w

use Mojolicious::Lite;

helper localize => sub { "X" . $_[1] . "X" };
helper _ => sub { shift->localize(@_); };

get '/' => 'home';

app->start;

__DATA__

@@ home.html.ep
%= localize('FORM_TITLE')
%= _('FORM_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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Websocket scaling

[Charlie Brady]

On Wed, 19 Feb 2014, Cosimo Streppone wrote:

> On 02/19/2014 05:20 PM, John Dunlap wrote:
> 
> > 2) I work for a SAAS provider and we use Apache virtualhosts to sell our
> > software to our customers. As Mojolicious uses its own built in HTTP
> > server, how do I achieve virtualhost-like behavior?
> 
> You can run a Mojolicious app with Plack::Handler::Apache2
> under Apache + mod_perl.

Probably easier to run the apps standalone and access via apache using 
mod_proxy.

-- 
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 http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.