Re: Dearer POE (pt. 2)
On May 18, 2009, at 8:57 PM, Rocco Caputo wrote: Speaking of which, how about http://rt.cpan.org/Public/Bug/Display.html?id=12686 ? :) Hmm. Yeah. That was a long time ago. I vaguely recall there being some problem I found with it, and when my schedule got too full and the larger home automation project fell by the wayside, I never circled back and worked on it. In fact, I think I've at least once in the past year re-implemented that functionality without even realizing I'd already done it once before. I'll have to find that code and see what I can make of it. I have a few other POE-related modules I'm meaning to upload to CPAN, but I won't again make the mistake of telling you what they do, lest they wind up in RT! ++J
Re: Dearer POE (pt. 2)
On May 18, 2009, at 22:38, Jordan Coleman wrote: On May 18, 2009, at 5:52 PM, Georg Moritz wrote: If you want to slay dragons, slay them elsewhere. Mine need not be slayed, since they serve me and my user base. TMTOWTDI. CPAN embraces all of our creations. It's big enough for this idea and an infinity of others. So judge the value of your code on your scale and I'll judge mine on mine, and there's no need decide whose is better. Speaking of which, how about http://rt.cpan.org/Public/Bug/Display.html?id=12686 ? :) -- Rocco Caputo - [email protected]
Re: Dearer POE (pt. 2)
On May 18, 2009, at 5:52 PM, Georg Moritz wrote: If you want to slay dragons, slay them elsewhere. Mine need not be slayed, since they serve me and my user base. TMTOWTDI. CPAN embraces all of our creations. It's big enough for this idea and an infinity of others. So judge the value of your code on your scale and I'll judge mine on mine, and there's no need decide whose is better. ++J
Re: Dearer POE (pt. 2)
Dear Evan,
>From the keyboard of Evan Carroll [18.05.09,16:44]:
> Dear POE,
>
> I write this letter to announce my great triumphs in my quest to slay
> your dragons and send you to everlasting salvation in Moose-landville.
> You no longer have many things you'll probably miss -- do not be
> shocked for it was necessary:
it must be said, I'm afraid - I have to tell you the following:
I (POE) have been working for years, humbly doing my work as I have
been designed by my designers and users. I am open to enhancements,
given that there is no performance degradation and I'll be always in
sync with my user base.
There are plenty of dragons in perl version 5, dungeons and bloody
traps, but those dragons I have met in my live now service me, and
that is to both perl's benefit, my own and my users: there's no need
to slay my servants.
If you want to slay dragons, slay them elsewhere. Mine need not be
slayed, since they serve me and my user base.
What dragons, you might ask? Well, dragons have the power to bewilder
the unwary. And I suspect you have tread the trap. See, there are
some virtues programmers have when it comes to programs and their
features:
- Laziness
- Hubris
- Impatience
Be aware that those features are apt /to the programming realm only/,
i.e. programmers dealing with their own programs, but /not/ for any
interaction between programmers and their kin (programmers) or their
users. For here the /opposite/ of those virtues are needed. To wit:
Program- The World
---+-
Laziness - diligence
Hubris - humility
Impatience - patience
I'm afraid that you've fallen prey to the Mighty Dragon of Programming
which lured you into thinking: "I am the Master of Bits and Bytes! I am
the One which knows the True Path! I know how to express my ideas in my
programs, therefore I am right!". That dragon doesn't know better, but
you should. There's much more to programming than "the right method" or
"the right way" or such. Any operating system and their software stack
are the result of social interaction of their thinkers poured into bits
and bytes, the outcome of many a discussion and pondering. And dragons
have to be conquered, not slain, for they are mighty.
So be patient and work out a transition roadmap for me, my programmers
and users.
Be humble and tame the dragons within your self, to serve our community.
Your diligence is appreciated if you send patches and work on the former
points - on a transition - without impatience and hubris.
You might be a "biological descendant of Jesus" as you have postulated
elsewhere (http://perlmonks.org/?node=EvanCarroll), but you are no more
god-like than we all are. Find your place where you are, get real.
Now I have to go back to work.
yours,
POE
> - There are no more resources that pollute the POE::Kernel namespace.
> - Your warnings, and constants have been factored out into Helpers
> - Your kernel now bootstraps as a *hash*, and $poe_kernel is now an
> array. (both blessed into POE::Kernel)
> - Your Resources are losing their complexity, there are fewer things
> that write back to $poe_kernel explicitly
> - You pass all of the unit tests
> - Now debug takes environmental arguments, TRACE_FILENAME='error' perl
> ./poe_app.pl (old way still works too)
>
> ecarr...@x60s:~/code/poe$ prove -l ./t/10_units/03_base/*
> ./t/10_units/03_base/01_poe.t . ok
> ./t/10_units/03_base/03_component.t ... ok
> ./t/10_units/03_base/04_driver.t .. ok
> ./t/10_units/03_base/05_filter.t .. ok
> ./t/10_units/03_base/06_loop.t ok
> ./t/10_units/03_base/07_queue.t ... ok
> ./t/10_units/03_base/08_resource.t ok
> ./t/10_units/03_base/09_resources.t ... ok
> ./t/10_units/03_base/10_wheel.t ... ok
> ./t/10_units/03_base/11_assert_usage.t ok
> ./t/10_units/03_base/12_assert_retval.t ... ok
> ./t/10_units/03_base/13_assert_data.t . ok
> ./t/10_units/03_base/14_kernel.t .. ok
> ./t/10_units/03_base/15_kernel_internal.t . ok
> ./t/10_units/03_base/16_explicit_loop.t ... ok
> ./t/10_units/03_base/17_explicit_loop_fail.t .. ok
> ./t/10_units/03_base/18_nfa_usage.t ... ok
> All tests successful.
>
> There is still much more to do
> - Remove all things that reference (constants and functions)
> POE::Kernel from Loops and References
> - Move the Kernel to POE::KernelX, make the kernel a thin layer with
> AUTOLOAD that swaps out $self for the true POE::KernelX object.
> - Make aliases and SIDs FieldHashes
> - Begin the assault on Loops
> - Remove the need for core events to poll Time::HiRest just to sit in
> the front of queue.
> - Remove all but one BEGIN {} blocks
> - Remove all but the necessary parts of sub import
>
> More updates will follow as more evil dies, benchmarks will start to
> come after I seperate POE::KernelX / POE::Kernel.
>
>
--
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\/
Dearer POE (pt. 2)
Dear POE,
I write this letter to announce my great triumphs in my quest to slay
your dragons and send you to everlasting salvation in Moose-landville.
You no longer have many things you'll probably miss -- do not be
shocked for it was necessary:
- There are no more resources that pollute the POE::Kernel namespace.
- Your warnings, and constants have been factored out into Helpers
- Your kernel now bootstraps as a *hash*, and $poe_kernel is now an
array. (both blessed into POE::Kernel)
- Your Resources are losing their complexity, there are fewer things
that write back to $poe_kernel explicitly
- You pass all of the unit tests
- Now debug takes environmental arguments, TRACE_FILENAME='error' perl
./poe_app.pl (old way still works too)
ecarr...@x60s:~/code/poe$ prove -l ./t/10_units/03_base/*
./t/10_units/03_base/01_poe.t . ok
./t/10_units/03_base/03_component.t ... ok
./t/10_units/03_base/04_driver.t .. ok
./t/10_units/03_base/05_filter.t .. ok
./t/10_units/03_base/06_loop.t ok
./t/10_units/03_base/07_queue.t ... ok
./t/10_units/03_base/08_resource.t ok
./t/10_units/03_base/09_resources.t ... ok
./t/10_units/03_base/10_wheel.t ... ok
./t/10_units/03_base/11_assert_usage.t ok
./t/10_units/03_base/12_assert_retval.t ... ok
./t/10_units/03_base/13_assert_data.t . ok
./t/10_units/03_base/14_kernel.t .. ok
./t/10_units/03_base/15_kernel_internal.t . ok
./t/10_units/03_base/16_explicit_loop.t ... ok
./t/10_units/03_base/17_explicit_loop_fail.t .. ok
./t/10_units/03_base/18_nfa_usage.t ... ok
All tests successful.
There is still much more to do
- Remove all things that reference (constants and functions)
POE::Kernel from Loops and References
- Move the Kernel to POE::KernelX, make the kernel a thin layer with
AUTOLOAD that swaps out $self for the true POE::KernelX object.
- Make aliases and SIDs FieldHashes
- Begin the assault on Loops
- Remove the need for core events to poll Time::HiRest just to sit in
the front of queue.
- Remove all but one BEGIN {} blocks
- Remove all but the necessary parts of sub import
More updates will follow as more evil dies. Benchmarks will start to
come after I separate POE::KernelX / POE::Kernel.
--
Evan Carroll
System Lord of the Internets
Dearer POE (pt. 2)
Dear POE,
I write this letter to announce my great triumphs in my quest to slay
your dragons and send you to everlasting salvation in Moose-landville.
You no longer have many things you'll probably miss -- do not be
shocked for it was necessary:
- There are no more resources that pollute the POE::Kernel namespace.
- Your warnings, and constants have been factored out into Helpers
- Your kernel now bootstraps as a *hash*, and $poe_kernel is now an
array. (both blessed into POE::Kernel)
- Your Resources are losing their complexity, there are fewer things
that write back to $poe_kernel explicitly
- You pass all of the unit tests
- Now debug takes environmental arguments, TRACE_FILENAME='error' perl
./poe_app.pl (old way still works too)
ecarr...@x60s:~/code/poe$ prove -l ./t/10_units/03_base/*
./t/10_units/03_base/01_poe.t . ok
./t/10_units/03_base/03_component.t ... ok
./t/10_units/03_base/04_driver.t .. ok
./t/10_units/03_base/05_filter.t .. ok
./t/10_units/03_base/06_loop.t ok
./t/10_units/03_base/07_queue.t ... ok
./t/10_units/03_base/08_resource.t ok
./t/10_units/03_base/09_resources.t ... ok
./t/10_units/03_base/10_wheel.t ... ok
./t/10_units/03_base/11_assert_usage.t ok
./t/10_units/03_base/12_assert_retval.t ... ok
./t/10_units/03_base/13_assert_data.t . ok
./t/10_units/03_base/14_kernel.t .. ok
./t/10_units/03_base/15_kernel_internal.t . ok
./t/10_units/03_base/16_explicit_loop.t ... ok
./t/10_units/03_base/17_explicit_loop_fail.t .. ok
./t/10_units/03_base/18_nfa_usage.t ... ok
All tests successful.
There is still much more to do
- Remove all things that reference (constants and functions)
POE::Kernel from Loops and References
- Move the Kernel to POE::KernelX, make the kernel a thin layer with
AUTOLOAD that swaps out $self for the true POE::KernelX object.
- Make aliases and SIDs FieldHashes
- Begin the assault on Loops
- Remove the need for core events to poll Time::HiRest just to sit in
the front of queue.
- Remove all but one BEGIN {} blocks
- Remove all but the necessary parts of sub import
More updates will follow as more evil dies, benchmarks will start to
come after I seperate POE::KernelX / POE::Kernel.
--
Evan Carroll
System Lord of the Internets
