JSON compiler
Many moons ago, I added a JSON "dumper" like functionality to walk
PMCs and emit JSON strings for them. (http://www.json.org)
Finally got around to adding in a JSON "compiler" to take JSON
strings, and return a PMC. a PGE grammar is used, with a TGE backend
- unlike most other grammars, we go directly from PGE to PIR in one
transformation. (since we're only data, not code, there's not a lot
to transform.)
(from perldoc compilers/JSON/JSON.pir)
.local pmc JSON
JSON = compreg 'JSON'
$P0 = JSON("[1,2,3]")
Will create a pmc that "does" array, contains the values 1,
2, and 3,
and store it in register $P0.
There is a (terribly written!) sample in compilers/JSON called
"postalcodes.pir" that pulls JSON data from 'http://ws.geonames.org/
postalCodeSearchJSON', compiles the JSON response into PIR, and then
walks the PMC, dumping out results.
% ./parrot compilers/json/postalcodes.pir 06382
Place: Uncasville, US; Code: 06382
Many thanks to Jerry Gay for helping with the grammar - (esp. since
he had already written a grammar months ago that we had never
actually used anywhere! =-). Also thanks to Nuno Carvalho for writing
most of the tests (many of which caught bad behavior which I was
then able to fix easily. There are some more testings pending, so if
you find something odd, write a test and I'll fix it. =-)
Enjoy.
--
Will "Coke" Coleda
[EMAIL PROTECTED]
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
c99 parser (was: socket related constants)
Am Samstag, 9. September 2006 22:27 schrieb Kevin Tew: > check out the newly added languages/c99 > Its a start at a PGE grammar for C99 Whut? Whut? Whutzeesayin'? just 3 lines of svn log messages - and I've missed these ;-) ++tewk leo
[BUG] make html
Hi, make html (which is creating parrot docs/html) is a bit too dynamic, it happily uses editor "bak" files too and includes these in docs and index: l docs/html/runtime/parrot/library/HTTP/ ... -rw-r--r-- 1 lt users 2813 2006-09-09 22:19 Daemon.pir~.html -rw-r--r-- 1 lt users 2813 2006-09-09 22:19 Daemon.pir.html or e.g. from the html: runtime/parrot/library/Data/Dumper/Default.pir~ The default output module of Data::Dumper. I tried to fix that but got lost in the deep dir/module structure of lib/Parrot/Docs/* and related - is this all really needed? leo
Re: socket related constants
chromatic wrote: On Friday 08 September 2006 03:38, Leopold Toetsch wrote: typical socket ocde currently looks a bit unfriendly due to magic constants, e.g. socket sock, 2, 1, 6# PF_INET, SOCK_STREAM, tcp I'd like to have symbolic constants for all that stuff: socket sock .PF_INET, .SOCK_STREAM, .PROTO_tcp Appended is a C snippet, which produces such constants[1]. It's incomplete and not integegrated in Configure/make at all, but maybe it is a starting point. Q: is there a better option to generate these constants? It'd sure be nice to have a PGE/TGE parser that could understand C header files and generate static NCI code. (That is, don't make the FFI mistake of parsing the header files every time you run the program that uses them.) -- c check out the newly added languages/c99 Its a start at a PGE grammar for C99 Kevin
[perl #40313] [TODO] Tcl - full namespace support
# New Ticket Created by Matt Diephouse # Please include the string: [perl #40313] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40313 > This is a parent ticket to track all namespace-related tickets. -- Matt Diephouse
[perl #40312] [TODO] Tcl - support namespaces in [info commands]
# New Ticket Created by Matt Diephouse # Please include the string: [perl #40312] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40312 > [info commands] needs to support namespaces. -- Matt Diephouse
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/
the CGI.pm in Perl 6
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. To those of you working on (or wanting to use) the Perl 6 native CGI.pm, Concerning the work you've been doing lately in getting the Perl 6 version of CGI.pm to function, I would like to strongly suggest that you don't simply clone CGI.pm for Perl 5, but rather introduce some (possibly but not necessarily backwards-incompatible) improvements in the process, in particular to correct some stupid design issues. Note that I will make these changes myself if someone else doesn't. But since you're extensively working on CGI.pm now, I'm giving you these strong suggestions early on so that you can incorporate them using other design decisions of your own choosing (eg, different function names). To summarize: 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. 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 compatability, 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 invironment's basic built-ins, including ASP and PHP, correctly keep these separate, and its time for Perl's basics to join them. 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. 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; fallback to Latin-1 only if the text parts of the HTTP request don't look like valid UTF-8. So CGI.pm for Perl 6 can resemble the Perl 5 version, but in no way should we retain backwards designs just because that's they way they were before. So keep all input information and standardize on Unicode. Thank you in advance. -- Darren Duncan
[svn:parrot-pdd] r14510 - trunk/docs/pdds
Author: nicholas Date: Sat Sep 9 06:38:49 2006 New Revision: 14510 Modified: trunk/docs/pdds/pdd07_codingstd.pod Log: 1 grammar fix, 1 typo fix. Modified: trunk/docs/pdds/pdd07_codingstd.pod == --- trunk/docs/pdds/pdd07_codingstd.pod (original) +++ trunk/docs/pdds/pdd07_codingstd.pod Sat Sep 9 06:38:49 2006 @@ -649,7 +649,7 @@ =item Per-entity comments Every non-local named entity, be it a function, variable, structure, macro or -whatever, must have an accompanying comment explaining it's purpose. This +whatever, must have an accompanying comment explaining its purpose. This comment must be in the special format described below, in order to allow automatic extraction by tools - for example, to generate per API man pages, B style utilities and so on. @@ -886,7 +886,7 @@ And remember to document it. -Loosely speaking, Perl tends to optimism for speed rather than space, so you +Loosely speaking, Perl tends to optimize for speed rather than space, so you may want to code for speed first, then tweak to reclaim some space while not affecting performance.
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
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
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
