Re: [RANT] Should we try to keep compatibility with old perl5s?
On Aug 17, 2018, at 10:26, Shlomi Fish wrote: > > On Fri, 17 Aug 2018 08:19:26 -0500 > Andy Lester wrote: >> >> I suggest that trying to optimize away complaining is a losing battle. You >> will never make everyone happy. > > Good advice, but see the first item of > https://www.joelonsoftware.com/2007/02/19/seven-steps-to-remarkable-customer-service/ > and the story at the bottom of http://linuxmafia.com/faq/Devtools/ides.html . "But when you think a little harder you can usually find a deeper solution: a way to prevent this particular problem from ever happening again." I agree that complaining is a significant problem. I look forward to hearing your final solution for it. -- Rocco Caputo
Re: The end of 5.6 is nigh!
On Nov 13, 2011, at 11:43, Zefram wrote: Reini Urban wrote: 5.6.2 still is the fastest perl around. Evidently it's important to you to get the wrong answer as quickly as possible. (Advice from Klortho #11912.) 4.036 would get you a wronger answer even faster! -- Rocco Caputo rcap...@pobox.com
Reflex extensions namespace?
Dear CPAN Oracle: CPAN has a de facto standard of appending X to make extensions namespaces. Does that make sense for namespaces that end in X already? If not, please suggest alternatives. Thank you! -- Rocco Caputo - rcap...@pobox.com
Re: publish/subcribe model via network
On Apr 14, 2008, at 02:41, Eric Wilhelm wrote: # from Scott Gifford # on Sunday 13 April 2008 19:14: You can simplify both of these by providing a network client that speaks a simple TCP-based protocol and relays messages to/from the IRC server/multicast network/Jabber server. Well, that's what I'm doing now -- sans the IRC relay. The repository now has a wx subscriber, which demonstrates what I'm getting at with all of this: http://scratchcomputing.com/svn/misc/pubsubserver [Stomp] [BEEP] [Spread] [PubSub] You could get a lot of mileage out of POE here. All these pieces interoperate due to the common POE substrate. http://search.cpan.org/dist/POE-Component-Server-IRC/ http://search.cpan.org/dist/POE-Component-MessageQueue/ (Stomp based) http://search.cpan.org/dist/POE-Component-Client-Stomp/ http://search.cpan.org/dist/POE-Filter-Stomp/ (Stomp wire protocol) http://search.cpan.org/dist/POE-Component-Spread/ http://search.cpan.org/dist/POE-Loop-Wx/ http://search.cpan.org/dist/POE-Component-Jabber/ (and XMPP) -- Rocco Caputo - [EMAIL PROTECTED]
Re: With the Macrame macro system, Perl may now be a Lisp.
On Dec 6, 2007, at 20:30, David Nicol wrote: I'm sort of stuck on how much records of line numbers of expanded rewrites to keep and how to encode them into the filename portion of the #line comment. In practice, debugging macros is maddening if you can't locate where the macro is being used and where it was defined. Sometimes the macro definition is at fault, and sometimes it's being used incorrectly. Filter::Template (source code filter for macros) does it this way: # line $line_number template $name (defined in $template_file at line $template_def_line) invoked from $filename Every line of the expanded template is preceded by a # line $invocation_line entry, which ensures that a warn() or die() messages are nice, but totally mucks with Perl's debugger. The problem there is that Perl stores the source code as an array using line numbers as offsets. Only the last line at a particular line number will display in the debugger. Around the time I wrote this, I kinda wished for non-integer line numbers. A 10-line expansion could have line numbers 14.1 through 14.10, with the original invocation as a comment on 14.0. -- Rocco Caputo - [EMAIL PROTECTED]
Re: line numbers with Filter::Simple
On Jun 1, 2007, at 13:13, David Nicol wrote: here's my line numbering code, from soon to be released Macrame.pm recursive and lexical macro system Like the name? I think its better than Macro::sweet, which was the runner-up in my fevered brain :) That's crazy, man! I think I'm going to need to see it in action... Did you like my warning format, though? I like and dislike the name. Macrame is one of those names that's clean, evocative, implies a really cool and symbolic logo... and doesn't actually say anything about the program's purpose. Does it have anything to do with OSX? :) -- Rocco Caputo - [EMAIL PROTECTED]
Re: line numbers with Filter::Simple
On May 30, 2007, at 16:38, David Nicol wrote:
We can declare a line number, in source code, like so
# perl foo
#line 54
die smiling
foo
smiling at - line 54.
#
and counting newlines within a Filter::Simple code block is easy
enough
but how do I find out what line to start at, so I can insert #line
comments
into my filter output that will match the input? I am about to
experiment with
caller(N) to see how many frames back to go, then I'll use that,
but I am asking
here in case anyone knows a better way.
caller() is a good solution. I use it, Filter::Util::Call, and some
involved #line magic to maintain sane line numbers in
Filter::Template. This short example defines a whatever template,
then expands it inline. The resulting error message follows. (Note
that #line directives seriously confuse perl -d. I half-jokingly
suggested floating-point line numbers so source filters could insert
lines 1.01 through 1.10 between lines 1 and 2 if necessary. But I
digress...)
#!/usr/bin/env perl
use Filter::Template;
template whatever (why) {
die whatever died: , why;
}
{% whatever stuff %}
__END__
whatever died: stuff at template whatever (defined in moo.perl at
line 6) invoked from moo.perl line 9.
--
Rocco Caputo - [EMAIL PROTECTED]
Re: How does Filter::Inline sound?
On Mar 11, 2006, at 21:42, A. Pagaltzis wrote: Hi Rocco, well `Inline` has other connotations in Perl-land, so I expected it was a module to do source filtering… but… inline? Somehow? I blinked for a bit when I started reading the description, and then I understood – “oh! he is using Inline with *that* meaning.” How about something like Filter::ExpandMacros? That's not bad. The source filter has a subclass, ::UseBytes, that evaluates to use bytes; if it's available in the current Perl. Does Filter::ExpandMacros::UseBytes seem awkward? How about something singular like: Filter::SourceTemplate ... Filter::SourceTemplate::UseBytes Filter::CodeTemplate ... Filter::CodeTemplate::UseBytes Filter::Template ... Filter::Template::UseBytes -- Rocco Caputo - [EMAIL PROTECTED]
How does Filter::Inline sound?
After years of threatening, I've finally spun POE::Preprocessor off
into a separate project. It just needs a good name before I upload
it. The current documentation is at http://search.cpan.org/~rcaputo/
POE/lib/POE/Preprocessor.pm.
Executive summary: This source filter (code named Filter::Inline)
adds syntax for inline code templates. Definitions look like named-
prototyped subs, using the macro keyword:
macro max (one,two) {
((one)(two)?(one):(two))
}
Invocations look rather template-like:
print {% max $one, $two %};
At load time, parameters are literally expanded into macro bodies,
which are then inserted into your code. The above example is
compiled as:
print (($one)($two)?($one):($two));
It supports some other syntax, but the macros are the main attraction.
--
Rocco Caputo - [EMAIL PROTECTED]
Re: Making RPMs out of CPAN Modules (namely XML::Feed) Automatically
On Aug 26, 2005, at 16:01, Ovid wrote: --- Shlomi Fish [EMAIL PROTECTED] wrote: 2. Ovid - http://search.cpan.org/dist/Ovid/ - Slightly less updated to handle all the latest CPAN technologies (Module::*, ExtUtils::*, etc.). But does recursion. FYI: Just as POE has nothing to do with me (Curtis Poe), Ovid also has nothing to do with me. I can't even claim that POE was here first. :) -- Rocco Caputo - http://poe.perl.org/
Re: What to name the baby? (module naming advice)
On Tue, Feb 08, 2005 at 10:32:07AM +1300, Sam Vilain wrote: Rocco Caputo wrote: I think it would be misleading to imply that this code only works with IRC. Even so, what you are doing is inherantly an IRC-ish thing to want to do. Wouldn't you still refer to non-IRC but IRC-like chatrooms as IRC? It's a concept beyond the protocol IMHO. With all due respect, I think Internet Relay Chat is better suited as a particular instance of the class of short-message systems rather than the archetype beneath which all manner of SM and IM systems should be lumped. I base this on simple taxonomy, and not merely because Net::IRC::AIM does not exist yet Net::AIM does. Even so, it seems misleading to imply that this code only works with a network. With the right parser, it could thread conversation in a teleplay as easily as that from a short-message system. Maybe Text::Chat::Threader? -- Rocco Caputo - http://poe.perl.org/
Re: What to name the baby? (module naming advice)
On Tue, Feb 08, 2005 at 10:32:07AM +1300, Sam Vilain wrote: Rocco Caputo wrote: I think it would be misleading to imply that this code only works with IRC. Even so, what you are doing is inherantly an IRC-ish thing to want to do. Wouldn't you still refer to non-IRC but IRC-like chatrooms as IRC? It's a concept beyond the protocol IMHO. This is an addendum to my previous message. Text::Conversation was also suggested. -- Rocco Caputo - http://poe.perl.org/
Re: What to name the baby? (module naming advice)
On Sun, Feb 06, 2005 at 11:30:04PM -0600, David Nicol wrote: there's an IRC top-level namespace, with IRC::Bot in it. On Sun, 6 Feb 2005 17:56:01 -0500, Rocco Caputo [EMAIL PROTECTED] wrote: I've written a module that threads chat messages, but I don't know what to name it. Chat::Threader comes to mind. http://cpan.org/modules/by-module/ doesn't list a top-level Chat namespace, though, and I'm loath to start one. Thanks for the reply. I think it would be misleading to imply that this code only works with IRC. True, I've been testing it in an IRC bot, but the module doesn't care where its information comes from. It's happy as long as you provide a user ID and some text. Here's the important line from my original post: my ($this_id, $referent_id) = $threader-observe($nick, $msg); $nick isn't required to be an IRC nickname. It might just as easily be an AIM or MSN ID. It could be a telephone number if you're threading SMS messages. It can even be an e-mail address, in which case $msg would probably be the message body. To be honest, I've only tested the module with relatively short messages. I've also considered the Chatbot:: namespace. The module doesn't actually say anything, and it's not designed for exclusive use by bots. The enigma of where to place this module remains. -- Rocco Caputo - http://poe.perl.org/
Re: Application framework namespaces
On Sun, May 16, 2004 at 02:17:12PM -0400, Lincoln A. Baxter wrote: Lets talk about POE. With POE we have a suite of packages whose scope and breath is not unlike what we have put together with GIP. Infact when we started originially, we looked at POE. At that point we considered it not quite what we were looking for. On reviewing it again recently, we find it's now got GREAT documentation, an impressive following, and much more maturity, but its still not suitable for some of the things we have been doing. For instance, core to the POE module at least for implementing servers is the interfaces must support unix select(). We needed MQSeries. Our Framework can be used to solve many the same kinds of problems that POE solves, but it is more generic in its use of interfaces. POE services assume that request interfaces implement IP socket semantics, supporting the use for the unix select() function. I'd be surprised if POE couldn't be made to play nicely with MQSeries. It's all kinds of flexible these days. POE doesn't rely on select() for its event dispatcher. It can use anything that multiplexes I/O and provides a timeout. The dispatcher interface is documented in POE::Loop, and the distribution already includes implementations for select(), IO::Poll, Event, Gtk, and Tk. It sounds like a low-level MQSeries event queue would be needed in addition to an event dispatcher. That's also possible. POE::Queue documents POE's generic event queue plugin interface. There is only one plugin so far, so the interface is still subject to change. What do you need? From my admittedly cursory readings on MQSeries, it sounds more appropriate for interprocess message passing than for low-level event queuing and dispatching. That is, a POE application might use its internal queue for local things and an MQSeries transport for passing messages to remote places. POE provides all the tools for interprocess message passing, but it doesn't enforce a standard method. At least one third-party transport, POE::Component::IKC, has been created to fill this void. Others are possible. Generally speaking, anything with an exposed filehandle can be plugged into a POE program using its low-level select_read() method. Even without an exposed filehandle, it is theoretically possible to wait for things in separate threads and inject incoming messages into POE's intraprocess queue. POE::Resource mixin classes can be created to manage these watchers and their threads, and POE::API mixins can expose the mechanics through friendly public interfaces. I say theoretically because these concepts are some of the newest introduced to POE, and their proofs haven't yet been implemented. They are desirable features, however, and POE developers would assist anyone wanting to add them. Logically atleast, existing Framesworks _could_ be migrated to Framework:: as well (although I don't really expect that to happen). Framework::POE (currently POE::) Framework::Wombat:: (currently Wombat::) Framework::POEST:: (currently POEST::) Framework::NetServer:: (currently NetServer::) etc As sensible as this is, I don't expect it to happen either. In fact, I would resist it. Revising, retesting, and redeploying POE based systems would cost thousands of man hours. A lot of people would be upset if they had to do it just for a name change. -- Rocco Caputo - http://poe.perl.org/
Re: IO::Epoll
On Mon, Mar 01, 2004 at 08:08:01PM -0800, Bruce J Keeler wrote: The epoll subsystem is a new, (currently) Linux-specific variant of poll(2). It is designed to offer O(1) scalability over large numbers of watched file descriptors. You need at least Linux 2.5.44 and a recent C library to use it. Have you considered a more portable solution like libevent? It's a single API for epoll (Linux), kqueue (BSD), poll(2), and select(2). Support for realtime signals and /dev/poll is also planned. Its home page is at http://monkey.org/~provos/libevent/ -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
Re: Finding the module you want (was: New module Mail::SendEasy)
On Sun, Feb 15, 2004 at 11:57:15PM +0100, A. Pagaltzis wrote: * Rocco Caputo [EMAIL PROTECTED] [2004-02-12 11:29]: Conveniently, I've written exactly the thing that provides the features I need, in a way that's most convenient for my purpose. Everything else pales by comparison, otherwise I would not have written it. Here, let me show you. Are you picking a bone with someone particular? :-) Where's the challenge in that?! I'm picking bones with lots of people! ;) -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
Re: Finding the module you want (was: New module Mail::SendEasy)
On Tue, Feb 10, 2004 at 09:03:27AM -0600, Dave Rolsky wrote: On Tue, 10 Feb 2004, A. Pagaltzis wrote: * It's better to have comparative articles than module centric reviews; they're also less susceptible to manipulation. I think these are great. The problem is they're a lot of work. I've written two (POOP and date/time) and I know Perrin wrote one for templating systems. They require you to look at _lots_ of modules and also to have a good understanding of all the problems that need to be solved in the area. Comparative articles are an incredible amount of work, especially for problem domains with a lot of options. They're even more work when the author has a vested interest in one of the modules being compared. He must take extra precautions to enforce objectivity. Anything less, and the conflict of interest will almost assuredly tip the scales in his module's favor. Consider comparative benchmarks as an example. It's a lot of work to negate bias towards modules the author is more familiar with. Maybe Open Source needs an objective reviewing organization like Consumer Union (http://www.consumerreports.org/). They could compare programming languages, text editors, and operating systems. A number of long-standing holy wars could be ended once and for all. :) -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
