Skip Menu |
 

This queue is for tickets about the CHI CPAN distribution.

Report information
The Basics
Id: 78227
Status: resolved
Priority: 0/
Queue: CHI

People
Owner: Nobody in particular
Requestors: dmuey [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Could it be redone without Moose?
Download (untitled) / with headers
text/plain 165b
I'd love to use this module, its a great idea, but it uses Moose which is really huge. If not I'll see about making a similar a mooseless version in a different NS.
Download (untitled) / with headers
text/plain 587b
CHI gets a ton of benefits from Moose. I tried to use Mouse in an old version, but I kept running into missing or broken features. What do you mean by "really huge"? Do you mean amount of memory, or amount of disk space, or number of dependencies, or it just feels big conceptually? Are you on a hosting provider with a very restricted amount of memory/disk space? On Thu Jul 05 14:04:13 2012, DMUEY wrote: Show quoted text
> I'd love to use this module, its a great idea, but it uses Moose which > is really huge. > > If not I'll see about making a similar a mooseless version in a > different NS.
Download (untitled) / with headers
text/plain 1.7k
Show quoted text
> CHI gets a ton of benefits from Moose.
And let me assure you, I'm not trying to start a Moose war, I just love the concept of CHI (I enjoyed your talk @ YAPC about it BTW) and have seen the same basic idea implemented wonderfully without moose (e.g. Log::Dispatch) Show quoted text
> What do you mean by "really huge"? Do you mean amount of memory,
yes, process RSS goes up almost 12MB just using it from a quick and dirty check: [dmuey@multivac ~]$ perl -e 'print `ps u -p $$`;' USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND dmuey 39922 0.0 0.0 2437344 1204 s000 R+ 1:46PM 0:00.04 perl -e print `ps u -p $$`; [dmuey@multivac ~]$ perl -MMoose -e 'print `ps u -p $$`;' USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND dmuey 39928 46.9 0.2 2444940 13124 s000 R+ 1:46PM 0:00.35 perl -MMoose -e print `ps u -p $$`; [dmuey@multivac ~]$ by comparison Log::Dispatch, that I noted earlier as a similar concept but for logging instead of caching, only adds about 2 MB to RSS even with quite a dependency chain itself. Show quoted text
> or amount of disk space,
not so much that Show quoted text
> or number of dependencies,
maybe a bit: it takes time to find all of them and load them and compile them, for what benefit exactly? a few less lines of code and MOPiness? Doesn't seem worth it to me for an abstract caching mechanism Show quoted text
> or it just feels big conceptually?
I suppose that fits a little, MOP is cool, I get that, its a great idea. Just not when its cost outweighs the benefit. Show quoted text
> Are you on a hosting provider with a very restricted > amount of memory/disk space?
no, I just don't want my personal servers bogged down for no reason and our customers demand reasonable memory use, thus Moose is out the door along w/ Java :)
Subject: Re: [rt.cpan.org #78227] Could it be redone without Moose?
Date: Thu, 5 Jul 2012 13:34:41 -0700
To: bug-CHI [...] rt.cpan.org
From: Jonathan Swartz <swartz [...] pobox.com>
On Jul 5, 2012, at 12:16 PM, Daniel Muey via RT wrote: Show quoted text
> Queue: CHI > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=78227 > >
>> CHI gets a ton of benefits from Moose.
> > And let me assure you, I'm not trying to start a Moose war, I just love the concept of CHI (I enjoyed your talk @ > YAPC about it BTW) and have seen the same basic idea implemented wonderfully without moose (e.g. > Log::Dispatch) >
Log::Dispatch was written long, long before Moose. I guarantee that Dave would not consider it wonderful today and that he would use Moose if he created it now. :) Show quoted text
>> What do you mean by "really huge"? Do you mean amount of memory,
> > yes, process RSS goes up almost 12MB just using it from a quick and dirty check: >
Ok, that helps quantify it. 12 MB is "big" when compared to raw Perl I suppose, but miniscule when considering amounts of memory on modern systems. Show quoted text
>
>> or number of dependencies,
> > maybe a bit: it takes time to find all of them and load them and compile them
about 1 minute on my system Show quoted text
> for what benefit exactly? a few less > lines of code and MOPiness? Doesn't seem worth it to me for an abstract caching mechanism
It is very much worth it, assuming that you don't consider 12 MB a significant cost on any modern system, which I don't. An incomplete list of benefits off the top of my head: * Default attribute values and lazily built attributes * Type checked attributes and type coercion * Strict constructor (dies if bad key is passed - not in CHI currently but will be shortly) * Optimized constructors * Roles, for things like size awareness and subcaches * Method modifiers, e.g. before, after, around You can see evidence of the first three in the first 50 lines of CHI/Driver.pm. For the last two see http://www.openswartz.com/2009/06/01/how-roles-pushed-me-over-to-the-moose-side/ Yes, it is possible to do all this without Moose, of course. Just a ton more code, tedium, testing, reinventing the wheel. I am living this now with Code::TidyAll (https://metacpan.org/module/tidyall), which I wrote without Moose because the common case is using a command-line script and I am sensitive to Moose's startup cost for this particular case. I am really missing Moose in the development of even this much smaller distribution, and if/when Moose startup time improves as it almost certainly will in the future (they are planning to embed the MOP into Perl), I will move this to Moose right away. Show quoted text
>> Are you on a hosting provider with a very restricted >> amount of memory/disk space?
> > no, I just don't want my personal servers bogged down for no reason and our customers demand reasonable > memory use, thus Moose is out the door along w/ Java :)
I'm shocked that 12 MB per process makes a difference, especially if you are using a web or other pre-forked app in which most of this would be shared memory. Does it really matter to your customers? Or is it mostly psychological/principle? Of course, you are free to write CHI::NoMoose or whatever. Just keep in mind the time/money trade-off and ask yourself how much it would cost to add a GB or whatever to your server instead. HTH, Jon
ok, thanks for your time and quick response.
From: dmaestro
On Thu Jul 05 16:34:54 2012, swartz@pobox.com wrote: Show quoted text
> > On Jul 5, 2012, at 12:16 PM, Daniel Muey via RT wrote: >
> > Queue: CHI > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=78227 > > >
> >> CHI gets a ton of benefits from Moose.
> > > > And let me assure you, I'm not trying to start a Moose war, I just
> love the concept of CHI (I enjoyed your talk @
> > YAPC about it BTW) ...
I echo Daniel's comments, especially those quoted above. With the recent buzz about Moo, [http://blogs.perl.org/users/sawyer_x/2012/07/anymoose-is-out-moo-is-in.html] I wonder if you would consider moving in that direction? What benefits does Moose provide that Moo doesn't and that prevent doing that implementation easily? (Wish I had more experience with both, I'd answer that question myself!) I am in a position where it will be some time before my company can migrate key applications to Moose (much as I would like to). And until MOP is in the core, I really would like to have the option of moving caching to CHI in the meantime. With the full Moose dependency, I simply don't. DLS
Subject: Re: [rt.cpan.org #78227] Could it be redone without Moose?
Date: Fri, 27 Jul 2012 15:23:35 -0700
To: bug-CHI [...] rt.cpan.org
From: Jonathan Swartz <swartz [...] pobox.com>
Download (untitled) / with headers
text/plain 1.4k
On Jul 27, 2012, at 11:12 AM, http://dmaestro12.myopenid.com/ via RT wrote: Show quoted text
> Queue: CHI > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=78227 > > > On Thu Jul 05 16:34:54 2012, swartz@pobox.com wrote:
>> >> On Jul 5, 2012, at 12:16 PM, Daniel Muey via RT wrote: >>
>>> Queue: CHI >>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=78227 > >>>
>>>> CHI gets a ton of benefits from Moose.
>>> >>> And let me assure you, I'm not trying to start a Moose war, I just
>> love the concept of CHI (I enjoyed your talk @
>>> YAPC about it BTW) ...
> > I echo Daniel's comments, especially those quoted above. > > With the recent buzz about Moo, > [http://blogs.perl.org/users/sawyer_x/2012/07/anymoose-is-out-moo-is-in.html] > I wonder if you would consider moving in that direction? What benefits > does Moose provide that Moo doesn't and that prevent doing that > implementation easily? > > (Wish I had more experience with both, I'd answer that question myself!) > > I am in a position where it will be some time before my company can > migrate key applications to Moose (much as I would like to). And until > MOP is in the core, I really would like to have the option of moving > caching to CHI in the meantime. With the full Moose dependency, I simply > don't.
Moo is certainly more likely than plain-old-objects, I'll consider it. I'd have to think about the feature gap. Likewise, can I ask what is preventing your company from using Moose? Is it memory usage? Startup time?
From: dmaestro
Download (untitled) / with headers
text/plain 2.3k
On Fri Jul 27 18:23:56 2012, swartz@pobox.com wrote: Show quoted text
> > On Jul 27, 2012, at 11:12 AM, http://dmaestro12.myopenid.com/ via RT > wrote: >
> > Queue: CHI > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=78227 > > > > > On Thu Jul 05 16:34:54 2012, swartz@pobox.com wrote:
> >> > >> On Jul 5, 2012, at 12:16 PM, Daniel Muey via RT wrote: > >>
> >>> Queue: CHI > >>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=78227 > > >>>
> >>>> CHI gets a ton of benefits from Moose.
> >>> > >>> And let me assure you, I'm not trying to start a Moose war, I just
> >> love the concept of CHI (I enjoyed your talk @
> >>> YAPC about it BTW) ...
> > > > I echo Daniel's comments, especially those quoted above. > > > > With the recent buzz about Moo, > > [http://blogs.perl.org/users/sawyer_x/2012/07/anymoose-is-out-moo-
> is-in.html]
> > I wonder if you would consider moving in that direction? What
> benefits
> > does Moose provide that Moo doesn't and that prevent doing that > > implementation easily? > > > > (Wish I had more experience with both, I'd answer that question
> myself!)
> > > > I am in a position where it will be some time before my company can > > migrate key applications to Moose (much as I would like to). And
> until
> > MOP is in the core, I really would like to have the option of moving > > caching to CHI in the meantime. With the full Moose dependency, I
> simply
> > don't.
> > Moo is certainly more likely than plain-old-objects, I'll consider it. > I'd have to think about the feature gap. > > Likewise, can I ask what is preventing your company from using Moose? > Is it memory usage? Startup time? >
We have a large, very important legacy application written about 8 years ago. I am still in the process of refactoring parts of it for maintainability. Although I would love it if I could replace all of the plain perl-OO with Moose, other priorities (like just moving from perl 5.8 to 5.10+) are higher. For new projects, the Moose dependencies would not be a problem. This is not a performance issue for me. It is entirely a maintenance issue. The work I am doing now will (I hope in the near future!) open the doors for using Modern Perl more extensively. I did look a little more closely at what the Moose dependencies are, and they are lighter than I thought, even though Moose itself is quite large. Thanks for the willingness to at least consider this! DLS
From: duvny [...] yopmail.com
Download (untitled) / with headers
text/plain 215b
On Fri Jul 27 18:23:56 2012, swartz@pobox.com wrote: Show quoted text
>
Show quoted text
> Moo is certainly more likely than plain-old-objects, I'll consider it. > I'd have to think about the feature gap.
Also echoing support for $Moo++; $Moose--
Subject: Re: [rt.cpan.org #78227] Could it be redone without Moose?
Date: Mon, 17 Sep 2012 10:57:31 -0700
To: bug-CHI [...] rt.cpan.org
From: Jonathan Swartz <swartz [...] pobox.com>
Download (untitled) / with headers
text/plain 441b
DuvNY: Reason? Memory usage, startup time, or number of dependencies? :) On Sep 15, 2012, at 10:35 AM, DuvNY via RT wrote: Show quoted text
> Queue: CHI > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=78227 > > > On Fri Jul 27 18:23:56 2012, swartz@pobox.com wrote:
>>
>
>> Moo is certainly more likely than plain-old-objects, I'll consider it. >> I'd have to think about the feature gap.
> > Also echoing support for $Moo++; $Moose--
Download (untitled) / with headers
text/plain 299b
I have a work in progress port of CHI to Moo. I have it passing all of its tests, and all of dependent CPAN modules still work with no changes. I still have a bit of cleanup I'd like to do, and I'd like to get some people testing it in the real world, but everything is looking pretty good so far.
Download (untitled) / with headers
text/plain 418b
Great to hear! Given the backward compatibility I'm in favor. On Thu Feb 28 22:12:43 2013, haarg wrote: Show quoted text
> I have a work in progress port of CHI to Moo. I have it passing all of > its tests, and all of dependent CPAN modules still work with no changes. > > I still have a bit of cleanup I'd like to do, and I'd like to get some > people testing it in the real world, but everything is looking pretty > good so far.
Subject: Re: [rt.cpan.org #78227] Could it be redone without Moose?
Date: Fri, 01 Mar 2013 12:53:46 -0800
To: bug-CHI [...] rt.cpan.org,Graham Knop via RT <bug-CHI [...] rt.cpan.org>,dmuey [...] cpan.org
From: Dan Muey <webmaster [...] simplemood.com>
Download (untitled) / with headers
text/plain 495b
Woot! Graham Knop via RT <bug-CHI@rt.cpan.org> wrote: Show quoted text
><URL: https://rt.cpan.org/Ticket/Display.html?id=78227 > > >I have a work in progress port of CHI to Moo. I have it passing all of >its tests, and all of dependent CPAN modules still work with no >changes. > >I still have a bit of cleanup I'd like to do, and I'd like to get some >people testing it in the real world, but everything is looking pretty >good so far.
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Download (untitled) / with headers
text/plain 172b
I have the Moo conversion of this ready to release, however it suffers from a bug in Moo. I have a fix for that issue and am working on getting a new Moo release out soon.
Download (untitled) / with headers
text/plain 231b
Huzzah! On Mon Jun 24 17:25:22 2013, haarg wrote: Show quoted text
> I have the Moo conversion of this ready to release, however it suffers > from a bug in Moo. I have a fix for that issue and am working on > getting a new Moo release out soon.
From: blue [...] thisisnotmyrealemail.com
Download (untitled) / with headers
text/plain 359b
On Mon Jun 24 17:35:45 2013, DMUEY wrote: Show quoted text
> Huzzah!
If it's ready, why not ship a trial version for the cpan testers to smoke? Show quoted text
> On Mon Jun 24 17:25:22 2013, haarg wrote:
> > I have the Moo conversion of this ready to release, however it suffers > > from a bug in Moo. I have a fix for that issue and am working on > > getting a new Moo release out soon.
Download (untitled) / with headers
text/plain 304b
On Mon Jun 24 17:25:22 2013, haarg wrote: Show quoted text
> I have the Moo conversion of this ready to release, however it suffers > from a bug in Moo. I have a fix for that issue and am working on > getting a new Moo release out soon.
It looks like CHI now uses Moo as of Monday. Shouldn't this ticket be closed now?
Right you are. CHI uses Moo as of 0.58
Download (untitled) / with headers
text/plain 106b
On Sat Jul 26 20:05:42 2014, JSWARTZ wrote: Show quoted text
> Right you are. CHI uses Moo as of 0.58
Awesome, thank you!


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.