A. Pagaltzis (paga...@gmx.de)

* demerphq <demerphq@gmail.com> [2007-10-10 13:05]:
> Only thing that comes to mind while we microanalyse this little
> used piece of fallback code is that we should probably ALSO
> look at the code for blessed().

I did that, and it turned out to have a problem, but for a
different reason. (Pointlessly pollutes UNIVERSAL.)

> I bet you that blessed() is doing something very similar to
> what refaddr() is doing itself.

Not very, funnily enough.

But I didn’t realise that `blessed` returns the same thing as
`ref`, which allows even better micro-decoupling:

    sub refaddr($) {
      return undef unless ref($_[0]);

      my $addr;
      if (my $pkg = blessed($_[0])) {
        $addr .= bless $_[0], 'Scalar::Util::Fake';
        bless $_[0], $pkg;
      }
      else {
        $addr .= $_[0];
      }

      $addr =~ /0x(\w+)/;
      local $^W;
      hex $1;
    }

(Excuse the nitpickery; sweating the details to this extent is
routine for me.)

Regards,

* Yuval Kogman <nothingmuch@woobling.org> [2007-10-10 12:20]:
> I agree FWIW, but it should return ref($_[0]), not $_[0] in the
> true case.

Err, d’oh, yeah.

> Nice touch remembering local(), you++

Thanks, but I can’t claim credit; that was already there in the
original version. :-)

Regards,

Hi,

>     # Hope nobody defines a sub by this name
> sub UNIVERSAL::a_sub_not_likely_to_be_here { ref($_[0]) }
>
>     sub blessed ($) {
>       local($@, $SIG{__DIE__}, $SIG{__WARN__});
>       length(ref($_[0]))
> ? eval { $_[0]->a_sub_not_likely_to_be_here }
>         : undef
>     }

is there any reason to pollute UNIVERSAL here? Shouldn’t the
following work identically?

    sub blessed ($) {
      local($@, $SIG{__DIE__}, $SIG{__WARN__});
      length(ref($_[0]))
        ? eval { $_[0]->can('can') && $_[0] }
        : undef
    }

FWIW, having established that there’s no better way to write that
function, I really dislike the way that spreads the reblessing
logic around the function based on a flag. Is there any reason
not to write it this way?

    sub refaddr($) {
      my $pkg = ref($_[0]) or return undef;

      my $addr;
      if (blessed($_[0])) {
        $addr .= bless $_[0], 'Scalar::Util::Fake';
        bless $_[0], $pkg;
      }
      else {
        $addr .= $_[0];
      }

      $addr =~ /0x(\w+)/;
      local $^W;
      hex $1;
    }

It’s a minor thing, I know, but I do think it makes the code
better.

Hi Richard,

did you ever get this sorted? Quoting in full since you seem to
have been warnocked. I have no idea what to suggest but am
curious about this issue as a matter of personal interest.

* Richard Robinson <catalyst@beulah.qualmograph.org.uk> [2007-09-20 20:15]:
> I got my all-singing all-dancing Catalyst app onto a proper
> server a few days ago. It's all going much better than I
> thought it might, a couple of friendly guinea-pigs, a fine crop
> of helpful comments, glitches getting spotted & fixed, a
> thriving TODO list ... and one problem which worries me - I
> prefer bugs to be in my code, because then I can fix them and
> end of story, but I don't think this is.
>
> There is a point where I send data out as a variety of other
> mime-types. This is either text, in a small range of iso-8859
> encodings (I work in utf8 internally, "of course", so this is
> encoded specifically). or binary, generated from that text as a
> temporary file by external programs and read in from that. This
> is output with, eg,
>
> $c->res->content_type('application/pdf');
> $c->res->body($data);
>
> Developing & testing this on my machine at home, this works as
> it should. On the remote server, I can view the files directly,
> and they're as they should be; I can request the data through
> :3000 from script/appname_server.pl, and again, it's correct;
> but hand it out through script/appname_fastcgi.pl +
> mod_fastcgi/apache and it's broken; each single byte with the
> high bit set is replaced by a "0xC3 0xsomethingelse" pair -
> it's been recoded into utf8, with values that assume it was
> Latin 1 to start with (regardless of anything I put in the
> Content-Type). Workaround is to replace the code above with a
> redirect to the temporary file, which then goes out through
> Static::Simple and arrives uncorrupted.
>
> The data leaves my code with the utf8 flag unset, and is
> handled properly by C::P::Unicode. So I think it must be in the
> fastcgi conversation ? Has anybody else seen this, or have any
> ideas ? I can't see any changes in C::E::FastCGI.pm that offer
> any Clue, and I'm really not sure where to go next.
>
> System at home, where it doesn't happen, is Apache/2.0.54 with
> Catalyst modules from, I think, last January or thereabout (the
> new Debian stable caught me by suprise, bringing the home box
> up to date is going to be a big job & I have other things I'd
> rather be doing). Remote system, where it does happen, is
> Apache/2.2.3 with cpan upgrade a few days ago. mod_fastcgi is
> the same on both (2.4.2)

Regards,

* Rafael Garcia-Suarez <rgarciasuarez@gmail.com> [2007-10-05 10:15]:
> (after I figured out that your mailer doubles spaces that are
> at the beginning of a line. s/^ / / fixed that. Oh, and it
> wraps long lines too.)

Must be your reader rather than Jos’ mailer; at least over here
in mutt the patch comes out perfectly correctly.

Regards,

Hi Richard,

did you ever get this sorted? Quoting in full since you seem to
have been warnocked. I have no idea what to suggest but am
curious about this issue as a matter of personal interest.

* Richard Robinson <catalyst@beulah.qualmograph.org.uk> [2007-09-20 20:15]:
> I got my all-singing all-dancing Catalyst app onto a proper
> server a few days ago. It's all going much better than I
> thought it might, a couple of friendly guinea-pigs, a fine crop
> of helpful comments, glitches getting spotted & fixed, a
> thriving TODO list ... and one problem which worries me - I
> prefer bugs to be in my code, because then I can fix them and
> end of story, but I don't think this is.
>
> There is a point where I send data out as a variety of other
> mime-types. This is either text, in a small range of iso-8859
> encodings (I work in utf8 internally, "of course", so this is
> encoded specifically). or binary, generated from that text as a
> temporary file by external programs and read in from that. This
> is output with, eg,
>
> $c->res->content_type('application/pdf');
> $c->res->body($data);
>
> Developing & testing this on my machine at home, this works as
> it should. On the remote server, I can view the files directly,
> and they're as they should be; I can request the data through
> :3000 from script/appname_server.pl, and again, it's correct;
> but hand it out through script/appname_fastcgi.pl +
> mod_fastcgi/apache and it's broken; each single byte with the
> high bit set is replaced by a "0xC3 0xsomethingelse" pair -
> it's been recoded into utf8, with values that assume it was
> Latin 1 to start with (regardless of anything I put in the
> Content-Type). Workaround is to replace the code above with a
> redirect to the temporary file, which then goes out through
> Static::Simple and arrives uncorrupted.
>
> The data leaves my code with the utf8 flag unset, and is
> handled properly by C::P::Unicode. So I think it must be in the
> fastcgi conversation ? Has anybody else seen this, or have any
> ideas ? I can't see any changes in C::E::FastCGI.pm that offer
> any Clue, and I'm really not sure where to go next.
>
> System at home, where it doesn't happen, is Apache/2.0.54 with
> Catalyst modules from, I think, last January or thereabout (the
> new Debian stable caught me by suprise, bringing the home box
> up to date is going to be a big job & I have other things I'd
> rather be doing). Remote system, where it does happen, is
> Apache/2.2.3 with cpan upgrade a few days ago. mod_fastcgi is
> the same on both (2.4.2)

Regards,

* Peter Karman <peter@peknet.com> [2007-10-03 16:55]:
> The main reason I used uri_for() for external URIs was for the
> nice uri-escaping features when dealing with params.

URI::FromHash

Regards,

* Bill Moseley <moseley@hank.org> [2007-10-03 16:15]:
> INSERT uses load() and from my quick look load() doesn't call
> _decode_unicode() and that's where the BOM and ENCODING checks
> happen.

I know I?m not very constructive here? but have I mentioned that
TT2 sucks?

Regards,

* Peter Karman <peter@peknet.com> [2007-10-03 16:55]:
> The main reason I used uri_for() for external URIs was for the
> nice uri-escaping features when dealing with params.

URI::FromHash

Regards,

* Bill Moseley <moseley@hank.org> [2007-10-03 16:15]:
> INSERT uses load() and from my quick look load() doesn't call
> _decode_unicode() and that's where the BOM and ENCODING checks
> happen.

I know I’m not very constructive here… but have I mentioned that
TT2 sucks?

Regards,

* Octavian Rasnita <orasnita@gmail.com> [2007-09-28 14:40]:
> I have a I18N module in my Catalyst application and I want to
> get the path to the home directory of the application. Is it
> possible to get it without hard codding it in that module?

See Catalst::Component::ACCEPT_CONTEXT.

Disregard the suggestions to use __FILE__ or FindBin.

Regards,

You’re asking the wrong question. Sessions are a bad idea in
general; application state should live on the client, not the
server. All state on the server should be resource state, ie it
should have a URI of its own.

I don’t use sessions *at all*[1], so my apps have all of the
properties you describe above without any effort on my part.
Basically the way you are designing your app goes against HTTP’s
grain. Work with HTTP rather than against it and you will get
simpler designs that work more robustly.

A context-free explanation of the design principles would take us
too far afield here; for that, I can warmly recommend O’Reilly’s
_RESTful Web Services_.

> Furtermore there are users who have access to other users'
> data. I'd like them to select them *once* which user's data
> they want to work on and keep this for the current browser
> window. Again I expect the user to use multiple browser windows
> (say for working with multiple users' data at the same time).

Bake the selection into the URI. That solves the problem without
any weird machinery on the server.

If you explain how your form interactions look like and what sort
of data you want to put into these subsessions, I could make some
suggestions for how to structure your URIs and the actions on
them to achieve the same goals without sessions.

> I've had no luck finding something similar for Catalyst.

Sometimes, no code has been written to solve a problem because no
code is necessary. :-)


[1] And my only use for cookies is to store an auth token.
    I’d prefer to avoid them entirely, but the HTTP auth
    implementation in browsers is atrocious even today.

Regards,