Mozilla's offer of help to Perl 6 -- How about adding P6XPCOM to PyXPCOM in Gecko 1.9+ and Firefox 3?
In: Perl 6 Design Minutes for 23 August 2006 http://use.perl.org/articles/06/09/08/2238219.shtml I saw this intriguing news: Mozilla Foundation wants to know how they can help Perl 6 Of course supporting Larry would be incredibly valuable. But there is also something else that would also be great to get on top of that. In this context, consider this item: PyXPCOM has been integrated into the Mozilla build system for tighter integration with the main XPCOM project. http://aspn.activestate.com/ASPN/Downloads/Komodo/PyXPCOM/ I think it would be extremely valuable for Perl 6 to have this level of XPCOM integration out of the box. A few years from now I'd like to see a combination IDE + RCP based on a Perl 6 + XPCOM + XUL system that (among other things) featured something like Netbeans Matisse GUI builder that could be used for developing both standalone GUI applications or client-server applications that would work on any platform that installed Firefox 2. Of course there are a huge number of much less grandiose applications for a Perl 6 counterpart for the Python bindings--especially if P6XPCOM could be positioned in the same privileged position as PyXPCOM (in Gecko 1.9+ and Firefox 3). PS: A moderately insane musing: Maybe Parrot + Mozilla could someday become the preferred Linux desktop framework and overcome the infamously fractured world of Gnome / Qt, while also bridging the Mac and Win worlds. Best regards, Conrad Schneiker www.AthenaLab.com Nano-electron-beam and micro-neutron-beam technology. Check out the new Perl 6 Workplace Wiki: http://rakudo.org/perl6
Re: IO::Socket, or any IO
在 Sep 8, 2006 10:33 PM 時，Michael Snoyman 寫到：
Thanks Audrey. I actually found that after writing that post.
What I had wanted to do was write a threaded server, implemented in
Perl 6 only (ie, including Perl 6 regexs). I got that working
almost entirely, when I couldn't find any thread implementation. I
tried using fork() to get a same effect, but it seems that fork
also isn't available. Was I missing something, or are these just
features that I need to wait for?
async{} creates a thread:
my $thr = async { ... };
You can use the usual .join, .detach, .yield methods on it.
Thanks,
Audrey
Just dreaming ... (was: Re: Mozilla's offer of help to Perl 6 -- How about adding P6XPCOM to PyXPCOM in Gecko 1.9+ and Firefox 3?)
On 9/9/06, Conrad Schneiker [EMAIL PROTECTED] wrote: In: Perl 6 Design Minutes for 23 August 2006 http://use.perl.org/articles/06/09/08/2238219.shtml I saw this intriguing news: Mozilla Foundation wants to know how they can help Perl 6 Support for script type=text/perl6 in Firefox would be nice :) But I think I'm just dreaming... -- Markus Laire
Re: the CGI.pm in Perl 6
Darren Duncan wrote: P.S. I originally sent this to just Mark Stosberg yesterday, and he suggested I sent it to perl6-users for more exposure, so here it is, slightly edited. And here is my reply to Darren, slightly edited. I'm only interested in CGI.pm so much as it holds up my work on CGI::Application. As far as I'm aware, adding cookie support is all that's left to do that to meet my needs. So for the most part, I don't intend to be making design decisions for or against your arguments. I do share your sentiment that CGI.pm shouldn't be a clone of how P5 works. I'd like the HTML building methods to stay out, which wasn't even one of the differences you cared about yourself. On the other hand, there is a real benefit to in being similar enough so that porting from Perl 5 is easy. Radical differences can forked into Web.pm or something. I'll provide some comments on your suggestions below. Note that I will make these changes myself if someone else doesn't. Great! 1. ALWAYS gather all GET/query-string variables that exist, regardless of whether this is a POST or GET query. The Perl 5 version currently discards any GET vars that are included in a POST request and doesn't provide any workaround save to uncomment a code line in CGI.pm itself. Eg, say you want to submit a POST form to this url: http://foo.com/bar/?screen=baz Stuff like that should just work, but for CGI.pm in Perl 5 it doesn't. I have to parse the query string myself if I get a POST request, to make that work, and its inane that Perl 5's CGI.pm doesn't just work with it. I see both sides to this and don't feel strongly about it. 2. Keep 2 distinct sets of query parameters, one each for GET (query string) and POST (HTTP body) variables, that are both initialized and can be appropriately read from and updated. They must be separate because it is legitimate to have variables with the same names in both places that must be kept distinct. Combining these is like combining cookie or session variable with either; all 4 are distinct things. I suggest that all accessors for these contain the words http get var(s) or http post var(s) in them respectively. For backwards computability, you could also keep param named functions which accesses a union of the above and the post ones take precedence in a name conflict. But the key thing is it must be possible+easy to use them separately. Practically every other web environment's basic built-ins, including ASP and PHP, correctly keep these separate, and its time for Perl's basics to join them. I agree here. 3. ALWAYS retain any multiple values for get and post vars. For ease of use, your accessors could look like http_post_var() and http_post_var_multi() etc, which fetch either just the first item as a scalar or an array ref having all the items (even if just one) respectively. I think this is already working. We always store values as arrays internally, and I think because of how Perl 6 works, it does the right thing if you expect a single value or an array returned. 4. Make UTF-8 the default HTTP response character encoding, and the default declared charset for text/* MIME types, and explicitly declare that this is what the charset is. The only time that output should be anything else, even Latin-1, is if the programmer specifies such. 5. Similarly, default to trying to treat the HTTP request as UTF-8 if it doesn't specify a character encoding; fall back to Latin-1 only if the text parts of the HTTP request don't look like valid UTF-8. I am not knowledgeable enough about this to haven an opinion. Currently CGI.pm-p6 defaults to Latin-1, apparently as a port for Perl 5. Since the related function was broken as recently as a few days ago, I know no one is depending on that default now, including me. 6. I suggest ditching the functional globals-storing CGI.pm interface and using the OO version only; much simpler. I made that change myself. It's OO-only now. I look forward to your commits! Once you start making changes, I'll let you know if you break anything CGI::Application depends on. It sounds like you probably won't. Mark -- http://mark.stosberg.com/
Re: the CGI.pm in Perl 6
At 3:11 PM -0500 9/9/06, Mark Stosberg wrote: I do share your sentiment that CGI.pm shouldn't be a clone of how P5 works. I'd like the HTML building methods to stay out, which wasn't even one of the differences you cared about yourself. On the other hand, there is a real benefit to in being similar enough so that porting from Perl 5 is easy. Radical differences can forked into Web.pm or something. If you want to see something more radical, have a look at my first major CPAN modules from 2001ish. Mainly HTML::FormTemplate and CGI::Portable. Between those and their dependencies (HTML::EasyTags, Class::ParamParser, Data::MultiValuedHash, CGI::MultiValuedHash), was an entire and cleaner and more modular re-implementation of CGI.pm plus a few extras (and minus a few bits; I never implemented file upload handling). It is also more or less backwards compatible with CGI.pm where it makes sense. The combination is a bit large to be a CGI.pm replacement, but I think that a lot can be learned from this if one wants to make more significant CGI.pm improvements. Note that I am still using those modules of mine for my own personal web sites, but I'm not aware that they ever took off with other people in a big way. I also don't plan to straight-port them to Perl 6 since in large I don't know if they really offer anything people want that other web frameworks don't. I also don't have a big stake in them like I do with my current database-centric modules (where I'm more certain they can have a big impact). However, I'm sure the web modules can influence improvements to CGI.pm in Perl 6, and I will do so at an appropriate time. -- Darren Duncan
