forks and threads (was: Re: META.yml how to declare the need for threaded perl?)
Christopher Brown schreef: I spent some time thinking about Dr. Ruud's reply over the past several days. Although I mostly share his views, I think that he has done a disservice to the discussion of the relative merits of threading and forking . Like most things in technology different approaches exploits different trade-offs. Usually not one approach is superior to all others in all situations. (cf. Python vs Perl vs Ruby, eg. ) Hello Christopher, thanks for your comments. Yes, I pulled harder on one side of the string than is practical. We haven't defined what we mean by threads versus forks, their differences and communalities. Some see threads as lightweight processes, other see the type of memory-space as the only signifcant difference. There is a hardware and a software oriented view on forks and threads. And then there is the Perl meaning of thread. (which might have been the one that was meant in the wrong question statement) Here is my opinion on the matter. Forking is a simpler and cleaner approach. By design the programmer does not have to worry about sharing of data and race conditions. When you algorithm is limited in memory requirements and completely compartamentalized, this is a good choice. And this is very often the case. Threading is not without its place, however. Notwithstanding, Dr. Ruud's argument: Most wishes for readily-shared memory result from (and to) bad design. This argument, stated without proof, makes a grand generalization. Yes, and I hope it was taken as that. Read also the arcticle The problem with threads, which is linked to on http://en.wikipedia.org/wiki/Thread_(computer_science) Deterministic ends should be accomplished with deterministic means. There are quite a few algorithms: sort, search, merge that greatily benefit from shared (or increased) memory. The simplest is using a very large shared hash to map values from a very, very large data stream. The ability of the shared memory will allow for more cooperative threads than forks where memory cannot be shared. Even for those cases there is often a good and less connected parallel solution available, where independent processes deal with considerable parts of the stream, and come together only at the end to sync and merge the results. Such a solution often means that double work is performed, and that significant more CPU cycles are used than would have been with readily-shared memory (but still the result can be achieved earlier and more reliable). It is possible to marshall, serialize, or use other IPC between forks, but then the balance of simpler, cleaner probably tilts toward a threading solution. Threads can run simultaneously in a multiprocessor system, but are susceptible to dead locks and to waste resources while polling. Forks share memory (code, read-only data, copy-on-write data) and files too. See also http://en.wikipedia.org/wiki/Non-blocking_synchronization about how to make multiprocessing more efficient. A lot of research is going on in that field. -- Affijn, Ruud Gewoon is een tijger.
Re: Integrating license related things of CPAN
Ricardo SIGNES schreef:
* Ken Williams [EMAIL PROTECTED] [2008-11-03T09:49:01]
What I would like to do next is make it more of a pure pass-through,
so that anything S::L knows about can be fed to M::B. That might
depend on having a registry in S::L, or it might mean an author could
specify a class name directly, possibly omitting the
Software::License:: prefix.
What I do in Dist::Zilla's license bit is rewrite '=Foo::Bar' to
'Foo::Bar' and 'Foo::Bar' to 'Software::License::Foo::Bar'
That allows people to specify a license class in the normal namespace
or, if they must, =MyCorp::License::MCPL.
I'd love to avoid having a registry, because it will allow people to
specify
their own internal license and have all the code generate the right
files.
They don't even need to bundle the library -- heck they don't even
NEED to
release it to CPAN, because M::B will create the right LICENSE file.
(...and
if they do release it, that's great too!)
Suggestion for a core license.pm:
package license;
$LICENSE = perl;
1;
sub import {
eval sprintf q/*%s::LICENSE=\\%s/,
scalar caller,
@_ == 2 ? $_[1] : join ,, @_[1..$#_];
1;
}
__END__
(and Cuse license ... ; should be compiled away unless at
distribution-time)
--
Affijn, Ruud
Gewoon is een tijger.
Re: META.yml how to declare the need for threaded perl?
David Cantrell schreef: eval use threads || exit(0); Alternatively written as: exit(0) unless eval use threads; (just because I wondered how strong the || was in there) -- Affijn, Ruud Gewoon is een tijger.
Re: META.yml how to declare the need for threaded perl?
Gabor Szabo schreef: I guess we can implement everything with fork but I think - maybe because of my lack of experience in threads - that it will be better to use them than to fork. I think it was Randal Schwartz who said something like: If the answer involves threads, then the question was wrong. -- Affijn, Ruud Gewoon is een tijger.
Re: The value of threads
Chris Dolan schreef: Dr.Ruud: Gabor Szabo: I guess we can implement everything with fork but I think - maybe because of my lack of experience in threads - that it will be better to use them than to fork. I think it was Randal Schwartz who said something like: If the answer involves threads, then the question was wrong. Most likely that quote comes from a year when multi-processor systems were not ubiquitous. I remember it in a context of choosing between forks and threads. Every UI framework I've ever used was indeed written with a single- threaded event loop, but even in an editor it sure is handy to have background threads to do asynchronous work (syntax checking, rebuilding call graphs, Perl::Critic, etc) without having to explicitly chunk the work or coordinate multiple processes. Cuse forks; :) -- Affijn, Ruud Gewoon is een tijger.
Re: Integrating license related things of CPAN
Gabor Szabo schreef:
I am trying to push forward simplifying and clarifying the
licensing issues on CPAN.
It would be nice to have a license pragma.
use license Perl;
use license AL/GPL;
use license qw{
Artistic_2 (and_up)
GPL_3 (and_up)
};
We already have
http://search.cpan.org/search?query=Software%3A%3ALicensemode=module
--
Affijn, Ruud
Gewoon is een tijger.
Re: Integrating license related things of CPAN
Ricardo SIGNES schreef: Dr.Ruud: Gabor Szabo: I am trying to push forward simplifying and clarifying the licensing issues on CPAN. It would be nice to have a license pragma. use license Perl; What would this do? That's up to the creator of the license pragma, but it would most probably be defined as standing for: This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. See http://www.perl.com/perl/misc/Artistic.html;. -- Affijn, Ruud Gewoon is een tijger.
Re: Date::Piece months and weeks
David Cantrell schreef: Right now, this Monday is 2008-01-07. It can be 2007-12-31 too, compare I went to town this Monday to I go to town this Monday. Taste also afternoon in stead of Monday. Natural languages are full of this. :-) -- Affijn, Ruud Gewoon is een tijger.
Re: With the Macrame macro system, Perl may now be a Lisp.
A. Pagaltzis schreef: Most of the modules that give me the heebie jeebies just never took off; I never had to install IO::All or Spiffy, say. I love those, so I am unable to understand any objections. -- Affijn, Ruud Gewoon is een tijger.
Re: relative.pm
Sébastien Aperghis-Tramoni schreef: package BigApp::Report; These would also be nice: package BigApp::__FROMFILE__; package BigApp::__FROMFILE__($RCSfile); -- Affijn, Ruud Gewoon is een tijger.
Re: peer review for first CPAN module? (JavaScript minification)
Joshua ben Jore schreef: Adriano Ferreira: Peter Michaux: I'm writing a new version of JavaScript::Minification on CPAN. This is my first CPAN module and first Perl project! If someone is willing to take a look to see if I've done something terribly wrong packaging the code I would greatly appreciate any feedback. Currently the new module is in a subversion repository. If you have subversion you should be able to check it out and test it with svn co http://dev.michaux.ca/svn/random/JavaScript-Minifier cd JavaScript-Minifier perl MakeFile.PL make test Some comments on packaging: * it may be a good idea to add a LICENSE parameter to Makefile.PL (supported by ExtUtils::MakeMaker = 6.31) * you might like to add POD and POD coverage tests (for CPANTS' sake) Some comments on code: * it does not look like Perl code, but C code translated literally to Perl. That's because this is a translation of the C program, jsmin. http://javascript.crockford.com/jsmin.html The code contains the strange '\000'. I see basically 3 steps: 1. respect strings 2. remove comments 3. compress everything else See also Javascript::Squish. http://search.cpan.org/perldoc?JavaScript::Squish -- Affijn, Ruud Gewoon is een tijger.
Re: peer review for first CPAN module? (JavaScript minification)
Joshua ben Jore schreef: Dr.Ruud: I see basically 3 steps: 1. respect strings 2. remove comments 3. compress everything else You may want want to convert from UTF16 to perl native strings, then convert back. JavaScript is defined as being stored in UTF16 but that's kind of unusual elsewhere. Isn't it? AFAIK, the UTF-16 of JavaScript is internal. So you can just put abc in your JavaScript code, there is no need to make that \0a\0b\0c. :) -- Affijn, Ruud Gewoon is een tijger.
Re: (Create a new ?) namespace for applications on CPAN
Andy Lester schreef: Dave Rolsky: ?: What's with all these ad hoc appending of x, like DBIx and RTx? Maybe the componenty parts should be Appx::* ? Well, DBIx is actually something Tim Bunce requested, since he didn't want people adding stuff to the DBI hierarchy. For Mason extensions, we asked people to use MasonX for similar reasons. That's fine. I'm not disagreeing with that. Point is that there's all sorts of stuff out there that doesn't even come close to being in a strict hierarchy. Such a strict hierarchy is not even possible. I wouldn't mind having code-less modules, just containing (future-proof) links to the real ones, something like application::SpamAssassin - Mail::SpamAssassin -- Affijn, Ruud Gewoon is een tijger.
Re: Net::DNS
A. Pagaltzis schreef: Dr.Ruud: On a Linux system: cpan2rpm etc. rpm -i /usr/src/redhat/RPMS/i386/perl-Net-DNS-0.59-1.i386.rpm error: Failed dependencies: perl(Win32::Registry) is needed by perl-Net-DNS-0.59-1 (still investigating) this is a list for discussion of issues and concerns while writing Perl modules. Bug reports for individual modules are not really on-topic here, and uf the maintainer of Net::DNS sees this message, it will be only by chance. You’ll more quickly get in touch with someone who knows what’s wrong if you report your problem via the bug tracker at http://rt.cpan.org/Public/Dist/Display.html?Name=Net-DNS. In fact, however, this looks like it might be purely a RedHat packaging issue (the folks at RedHat are known for doing weird things with Perl and Perl modules), in which case even the author of the module would be unlikely to be able to help. You might want to report this to RedHat via whatever means they provide for reporting problems in their distribution. Thank you, and sorry. Amavis/SpamAssassin are involved as well, so I can still first try to update one of those. But I also like to know what went wrong, will try to use the right channels if I find out. :) -- Affijn, Ruud Gewoon is een tijger.
Re: supporting older perls
Keith Ivey schreef:
Dr.Ruud:
Greg Matheson:
A. Pagaltzis:
Write the same thing without syntactic sugar from constant.pm.
sub C1 () { 'C1' }
Mmh. I see constant.pm does very little.
Well, it nicely sets things up for the compiler to optimize.
perl -MO=Deparse -e 'use constant PI = 3.1415; print PI'
use constant ('PI', 3.1415);
print 3.1415;
-e syntax OK
Greg's version gets optimized as well:
perl -MO=Deparse -e'sub PI () {3.1415} print PI'
sub PI () { 3.1415 }
print 3.1415;
-e syntax OK
Of course, because that is what constant basically does for you.
--
Affijn, Ruud
Gewoon is een tijger.
Re: supporting older perls
Greg Matheson schreef:
A. Pagaltzis:
Write the same thing without syntactic sugar from constant.pm.
sub C1 () { 'C1' }
Mmh. I see constant.pm does very little.
Well, it nicely sets things up for the compiler to optimize.
perl -MO=Deparse -e 'use constant PI = 3.1415; print PI'
use constant ('PI', 3.1415);
print 3.1415;
-e syntax OK
--
Affijn, Ruud
Gewoon is een tijger.
Re: Package::Unicorn
A. Pagaltzis schreef: (If I had a nickel for every time I've wished Perl had an s///-like function that returned a modified copy instead of modifying the original string in place.) Often this is good enough: (my $new = $old) =~ s/from/to/; But if $old is several GBs large, and the s/// would eliminate most of that, you would use a different approach, like a loop that involves index() and substr(). -- Affijn, Ruud Gewoon is een tijger.
Re: Delete hate speech module
Tim Maher schreef: I'm generally against the idea of censorship in all its forms This has nothing to do with censorship. Somebody is dropping garbage in our yard. If that person just wants to cause trouble and doesn't remove it, luckily somebody else will be so good. -- Affijn, Ruud Gewoon is een tijger.
