From darren at DarrenDuncan.net Tue Jan 1 00:22:38 2008 From: darren at DarrenDuncan.net (Darren Duncan) Date: Tue, 01 Jan 2008 00:22:38 -0800 Subject: [VPM] ANNOUNCE - Language::MuldisD v0.15.0 released Message-ID: All, I am pleased to announce the release of Language::MuldisD official/unembraced version 0.15.0 on CPAN. You can see it now, with nicely HTMLized documentation, at: http://search.cpan.org/dist/Language-MuldisD/ -------- All the important changes since release 0.14.0 were in the file Core.pod: 1. Added a heap of catalog data types, and updated a few existing ones, with the result that it is now possible to specify user-defined routines. To summarize, there are 3 kinds of user-defined routines, which are: functions, multi-update operators, and procedures. A function is pure functional, having zero or more read-only parameters and resulting in a value; it has zero side-effects; it can not see global variables. It is comprised entirely by a single value-expression, which is allowed to be self-referential/recursive. Higher-order functions are also supported, which can be passed as arguments and be defined in-line in other functions (in fact, some built-ins depend on this). A function is implicitly atomic, and implicitly auto-parallelizable for higher performance. A function may only invoke functions, not other routine types. A multi-update operator is like a glorified assignment operator, that can update 1..N target variables or pseudo|virtual-variables at once. It has 1..N subject-to-update parameters and 0..N read-only parameters. The collection of updates in a multi-update are implicitly atomic, and these updates conceptually happen concurrently. A multi-update operator consists of a single statement which updates its own subject-to-update parameters, and it otherwise consists of value-expressions as per a function. A multi-update operator has zero side-effects save for those that are a consequence of updating its parameters; it can not see global variables. A multi-update operator may only invoke its own kind and functions. Whole database constraints are immediate, and will apply between boundaries of multi-update-operator invocations, essentially being part of the invocation it follows. Note that a virtual variable (generalization of a SQL "view") is essentially an abstraction over a function when reading from it, and over an update operator when writing to it. Often the latter is implied by the former, assuming the DBMS is smart enough to invert the function (automatically updateable view), or you can write the update operator explicitly to help it along if necessary. A procedure is imperative, consisting of a sequence of 0..N statements that conceptually execute in sequence, one at a time. A procedure is the only kind of routine that has (non-parameter) variables, and it is the only kind that can see global variables. A procedure may invoke any kind of routine. A procedure is not implicitly atomic, and each of its statements will auto-commit on success. You use explicit lexical-scoped transactions when you want a sequence of actions courser-grained than an update operator call to be atomic, and explicit transactions can be nested. All routine kinds have named arguments only. Where applicable, routine definitions can be / are nested within other routine definitions, which is helpful for refactoring what is conceptually one routine. Generally speaking, when using a database, your main program always invokes a Muldis D procedure first (since only that can actually reference the global/database), and that in turn invokes multi-update/functional inner routines or routines of itself, where most of your actual code likely is. Functions are never invoked directly by procedures, but only indirectly by way of update operators. While functions and update operators don't have actual variables, they do have named expression nodes, analagous to "with" clauses in SQL and other languages, and in fact their use is mandatory due to a language design decision (the abstract syntax tree is actually fixed depth rather than N-depth, even if it is conceptually the latter), so it is very easy to reuse an expression result in multiple places, and so visually it is like you were using variables, but you aren't really any more than you use them in a functional langauge, and this makes lots of Muldis D code easy to auto-parallelize or otherwise optimize. Note as far as concurrency issues go, the database state should always implicitly be consistent during the execution of a multi-update operator (or function), but when there are multiple concurrent processes updating a database, any that commit successfully will have their changes visible to other processes as soon as the latter's current multi-update statement has finished. This is assuming no explicit locks are used to keep others off our lawn for a longer period. Put another way, Muldis D has serializable isolation within update operators and functions, but read-committed (?) isolation within procedures in general. Note that everything I just said in this paragraph is more of a brainstorm and is subject to revision. In fact, a lot of these details may be implementation-dependent for awhile, and not something I concern myself with too closely, except that isolation should be serializable in the general case. Here is a list of basically all the catalog data types used specifically to define routines, and 80-90% of them are new as of this release. Scalar types: sys.Core.Cat.E_ENK sys.Core.Cat.E_PSAK Tuple types: sys.Core.Cat.ExprNode sys.Core.Cat.InnerFunc sys.Core.Cat.Func sys.Core.Cat.UpdateStmt sys.Core.Cat.InnerUpdateOper sys.Core.Cat.UpdateOper sys.Core.Cat.ProcStmtArg sys.Core.Cat.ProcStmt sys.Core.Cat.InnerProc sys.Core.Cat.Proc Relation types: sys.Core.Cat.NameTypeMap sys.Core.Cat.NameExprMap sys.Core.Cat.ExprSet sys.Core.Cat.ExprTree sys.Core.Cat.InnerFuncSet sys.Core.Cat.InnerFuncTree sys.Core.Cat.MultiUpdateStmt sys.Core.Cat.InnerUpdateOperSet sys.Core.Cat.InnerUpdateOperTree sys.Core.Cat.ProcStmtArgSet sys.Core.Cat.InnerProcTree sys.Core.Cat.SetOfNameExprMap sys.Core.Cat.SetOfNameChain sys.Core.Cat.SeqOfProcStmt 2. Added a bunch of (ordered) sequence-specific operators. 3. Added generic 'reduce' functions, so now you too can easily make N-ary user-defined functions, such as group-by or aggregators. See the "Changes" file ( http://search.cpan.org/src/DUNCAND/Language-MuldisD-0.15.0/Changes ) for more details of what changed for this release. -------- Still to do: 1. Overhaul and expand the catalog types for defining data types. 2. Add catalog types for defining whole schemas, whole database constraints, views, triggers, etc. 3. Add relational operators for sorting and quota queries; that is, analogues to SQL's ORDER BY and LIMIT tasks, as well as order-significant aggregate operations on relation attributes (eg, catenate). 3. Define more flow control operators like IF/ELSE, GIVEN/WHEN, etc. 4. Define short-hand data definition operators analagous to CREATE, ALTER, DROP etc. 5. Flesh out and add system service operators like random numbers or current dates or simple generic I/O. -------- Thank you. -- Darren Duncan From Peter at PSDT.com Tue Jan 1 16:10:48 2008 From: Peter at PSDT.com (Peter Scott) Date: Tue, 01 Jan 2008 16:10:48 -0800 Subject: [VPM] January meeting contest Message-ID: <6.2.3.4.2.20080101150041.02fba2a0@mail.webquarry.com> So I thought that we could have a kind of contest associated with our January meeting. The meeting, if we hold it, would be on January 15. Now a small logistical hitch is, where to have the meeting. Mock, can we go to Enquisite again? I was thinking along the lines of, what's the most destructive script you can come up with in under a hundred characters, for whatever you consider 'destructive'. The key here is to be creative; this is not a quantitative measure. Obviously `/bin/rm -rf /` would win on a ratio of character count to chaos, but we're looking for something more entertaining than that. An alternative would be to create something that appears to be destructive but really isn't, in the vein of Frank Sheiness' entry in the Obfuscated Perl Contest at http://www.foo.be/docs/tpj/issues/vol2_3/tpj0203-0012.html . This type of program could be up to a thousand characters. The people who come up with entries would explain them at the meeting. Feel free to suggest alternative material for the meeting. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ http://www.perlmedic.com/ From darren at DarrenDuncan.net Thu Jan 3 16:33:02 2008 From: darren at DarrenDuncan.net (Darren Duncan) Date: Thu, 03 Jan 2008 16:33:02 -0800 Subject: [VPM] Fwd: [Discuss] Looking for Perl/Linux programmer/admin Message-ID: Forwarded from the VLUG list. --------- From: "Paul Wagorn" To: Date: Thu, 3 Jan 2008 15:58:38 -0800 Subject: [Discuss] Looking for Perl/Linux programmer/admin Reply-To: discuss at vlug.org List-Id: discuss.vlug.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces at vlug.org We are looking for a sysadmin/programmer. It's a permanent, work-from-home position that is full time or close to full time (we can discuss this). The company is www.worldbid.com & has been in business for 8 years. If anyone is interested (or knows someone who is looking for this type of thing), contact me at pw(at)worldbid.com, preferably with a resume and remuneration expectations. Here are the general things that you would need to know as requirements: Perl - Perl coding - Module install / maintainence - Regular expressions MySQL Linux Systems Admin - Multiple servers, RAID, switches - Linux and command line tools (awk , grep , sed etc ..) - CRON Scripts - System backup and restore using Tar and SSH - Writing general support scripts / System Health Scripts - Apache and modules - mod_rewrite in particular - secure certificates generation / installation - virtual hosting configuration - Installation / maintainence (OpenSSL , mod_ssl) - Qmail - Magicmail smtpd server - SMTP - configuration / maintenance for >100 domains - Multiple Instance management - DNS - BIND 9 Internet Security - Firewall - IPChains - IPTables - Portforwarding via SSH _______________________________________________ Discuss mailing list Discuss at vlug.org http://ladybug.vlug.org/cgi-bin/mailman/listinfo/discuss From Peter at PSDT.com Mon Jan 7 17:07:29 2008 From: Peter at PSDT.com (Peter Scott) Date: Mon, 07 Jan 2008 17:07:29 -0800 Subject: [VPM] January meeting? Message-ID: <6.2.3.4.2.20080107170621.03bf29b0@mail.webquarry.com> Er, did my message about a suggested topic for January get out there? If we're going to meet in January I need to advertise it starting tomorrow. If there's no critical mass we can leave it until February. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ http://www.perlmedic.com/ From darren at DarrenDuncan.net Mon Jan 7 18:13:32 2008 From: darren at DarrenDuncan.net (Darren Duncan) Date: Mon, 07 Jan 2008 18:13:32 -0800 Subject: [VPM] January meeting? In-Reply-To: <6.2.3.4.2.20080107170621.03bf29b0@mail.webquarry.com> References: <6.2.3.4.2.20080107170621.03bf29b0@mail.webquarry.com> Message-ID: At 5:07 PM -0800 1/7/08, Peter Scott wrote: >Er, did my message about a suggested topic for January get out >there? If we're going to meet in January I need to advertise it >starting tomorrow. If there's no critical mass we can leave it >until February. Yes, I saw it. But while I would be happy to attend and look at other people's submissions, I wouldn't be contributing. Doing destructive or obfuscated things on purpose is the opposite of how I think and I wouldn't know where to begin. Now, I have made further progress on my database stuff since last year and could talk about it, though I would prefer to have more time to prepare. It doesn't execute yet, though I'm further ahead in design and there could be a bit more example code to display. A presentation would be much better if done later than January though. In fact, I'll forward an example to the list in a few minutes for the curious, regardless of what happens with a meeting. Separately, the RCSS group is now bandying about having a later-January meeting (since Jan 1 was obviously off the table), and suggested the same week that VPM would be, but they are looking for content, so perhaps we could have a combined meeting again next week? -- Darren Duncan From darren at DarrenDuncan.net Mon Jan 7 18:24:09 2008 From: darren at DarrenDuncan.net (Darren Duncan) Date: Mon, 07 Jan 2008 18:24:09 -0800 Subject: [VPM] perhaps a combined January Meeting? In-Reply-To: References: Message-ID: At 4:45 PM -0800 1/7/08, Angela Norton wrote (to the RCSS list): >In light of the holidays and the fact that they've made it difficult >to find speakers for this month's meeting, would there be any >objections to postponing it a week and a day (to Wednesday January >15th)? January 15th is a tuesday. Did you mean then or wednesday January 16th? While it's not for certain that wednesday Jan 16th would be impacted, wednesdays in general have a high likelihood of conflict for me. Also, if Victoria.pm takes place, that would already be on tuesday the 15th. However, I just suggested to them that we might be able to have a combined meeting this month, and now I'm suggesting it to you. >Seriously, I can put together a short talk about embedded Linux on >consumer devices, with demonstrations, so if we can get one or two >other people to step up with something interesting, we will have a >total ruckus. A topic was suggested for the January VPM which would require some attendee participation, but so far no one announced stepping up to the plate. Here's the description of it: At 4:10 PM -0800 1/1/08, Peter Scott wrote: >So I thought that we could have a kind of contest associated with our >January meeting. The meeting, if we hold it, would be on January >15. Now a small logistical hitch is, where to have the meeting. Mock, >can we go to Enquisite again? > >I was thinking along the lines of, what's the most destructive script >you can come up with in under a hundred characters, for whatever you >consider 'destructive'. The key here is to be creative; this is not a >quantitative measure. Obviously > > `/bin/rm -rf /` > >would win on a ratio of character count to chaos, but we're looking for >something more entertaining than that. > >An alternative would be to create something that appears to be >destructive but really isn't, in the vein of Frank Sheiness' entry in >the Obfuscated Perl Contest at >http://www.foo.be/docs/tpj/issues/vol2_3/tpj0203-0012.html . This type >of program could be up to a thousand characters. > >The people who come up with entries would explain them at the >meeting. Feel free to suggest alternative material for the meeting. If we decide to combine meetings, then while there should at least be some Perl entries, we could open this up to entries in any language. In fact, the whole idea is probably right up the alley of RCSS in general. (Though ironically it would be the opposite of how I spend my time thinking, so I personally am unlikely to submit one.) -- Darren Duncan From darren at DarrenDuncan.net Mon Jan 7 18:33:42 2008 From: darren at DarrenDuncan.net (Darren Duncan) Date: Mon, 07 Jan 2008 18:33:42 -0800 Subject: [VPM] fyi, Muldis D core AST dialect example Message-ID: P.S. I originally posted the following to a couple other lists. ---------- As I have probably mentioned before, the Muldis D syntax examples I was giving in previous emails were representative rather than actual, and also that it is expected that multiple Muldis D dialects will be in use. FYI, following is a short Muldis D code snippit that is written in what is probably the least abstracted of all dialects, and would directly map to tuple|relation definitions that are composed into the actual system catalog relvars. First, this pseudo-code illustrates what the code snippit represents: function square returns Int (Int topic) { return topic ** 2; } And so here that code is (possibly having bugs) in the Perl-Hosted Muldis D (PHMD) format of the fundamental/core dialect of Muldis D; specifically, you should read this as if it were a relational tuple literal: [ 'Tuple', 'sys.Core.Cat.Func', { 'name' => [ 'Cat.Name', 'square' ], 'root_inner_func' => [ 'Cat.Name', '' ], 'inner_funcs' => [ 'Relation', 'sys.Core.Cat.InnerFuncTree', [ { 'name' => [ 'Cat.Name', '' ], 'result_tk' => [ 'Cat.E_TK', 'scalar' ], 'result_type' => [ 'Cat.NameChain', 'sys.Core.Int.UInt' ], 'is_recursive' => [ 'Bool', 'perl_any', 0 ], 'params' => [ 'Relation', 'sys.Core.Cat.NameTypeMap', [ { 'name' => [ 'Cat.Name', 'topic' ], 'type' => [ 'Cat.NameChain', 'sys.Core.Int.Int' ], }, ] ], 'root_expr' => [ 'Cat.Name', 'squared_topic' ], 'expr' => [ 'Relation', 'sys.Core.Cat.ExprTree', [ { 'name' => [ 'Cat.Name', 'squared_topic' ], 'tk' => [ 'Cat.E_TK', 'scalar' ], 'type' => [ 'Cat.NameChain', 'sys.Core.Int.UInt' ], 'kind' => [ 'Cat.E_ENK', 'func' ], 'scal_lit' => [ 'Bool', 'perl_any', 0 ], 'coll_lit' => [ 'Set', 'sys.Core.Cat.SetOfNameExprMap', [] ], 'param' => [ 'Cat.Name', '' ], 'func' => [ 'Cat.NameChain', 'sys.Core.Int.power' ], 'func_args' => [ 'Relation', 'sys.Core.Cat.NameExprMap', [ { 'name' => [ 'Cat.Name', 'radix' ], 'expr' => [ 'Cat.Name', 'arg_topic' ], }, { 'name' => [ 'Cat.Name', 'exponent' ], 'expr' => [ 'Cat.Name', 'lit_2' ], }, ] ], }, { 'name' => [ 'Cat.Name', 'arg_topic' ], 'tk' => [ 'Cat.E_TK', 'scalar' ], 'type' => [ 'Cat.NameChain', 'sys.Core.Int.Int' ], 'kind' => [ 'Cat.E_ENK', 'param' ], 'scal_lit' => [ 'Bool', 'perl_any', 0 ], 'coll_lit' => [ 'Set', 'sys.Core.Cat.SetOfNameExprMap', [] ], 'param' => [ 'Cat.Name', 'topic' ], 'func' => [ 'Cat.NameChain', '' ], 'func_args' => [ 'Relation', 'sys.Core.Cat.NameExprMap', [] ], }, { 'name' => [ 'Cat.Name', 'lit_2' ], 'tk' => [ 'Cat.E_TK', 'scalar' ], 'type' => [ 'Cat.NameChain', 'sys.Core.Int.PInt' ], 'kind' => [ 'Cat.E_ENK', 'scalar' ], 'scal_lit' => [ 'Int', 'perl_int', 2 ], 'coll_lit' => [ 'Set', 'sys.Core.Cat.SetOfNameExprMap', [] ], 'param' => [ 'Cat.Name', '' ], 'func' => [ 'Cat.NameChain', '' ], 'func_args' => [ 'Relation', 'sys.Core.Cat.NameExprMap', [] ], }, ] ], }, ] ], } ] All the detail info necessary to compose the above is in the 2 files Core.pod and PerlHosted.pod of the Muldis D spec. Possible bugs aside, that is what you would feed to Muldis DB for Perl as the user-definition of a stored function routine named 'square', which itself invokes the system-defined/built-in 'power' function; no user-defined types are used. The tuple that the above PHMD defines would be added to the appropriate catalog relvar, and an implementation can then be generated, whether as Perl code or as SQL for some other DBMS, or whatever. Although the above structure will scale to a function of arbitrary size and complexity, with expression trees of N levels deep, including quasi higher order functions, the actual node tree depth will never exceed the current maximum depth of 4 levels. (Note that in the process of writing the above, I realized a few details that were missing in the version 0.16.0 Muldis D spec and/or ought to be modified, and will be in version 0.17.0, but the above is over 90% to the current published spec.) Now, I'm sure the above example looks damningly verbose for code that one would write day to day, and indeed it is. Which is why the above is only recommended as an intermediate representation, and that alternate Muldis D dialects (most from third parties I suppose) that are a lot more DWIMmy and terse should be used instead for day to day writing in, which are then converted to/from the above when needed by some translator or wrapper module. Alternate dialects can look like whatever people want, even resemble Perl or Haskell or Tutorial D or SQL or what have you. And alternate dialects can add any features they want as long as those can be translated to/from the core dialect. Either way, hopefully the above PHMD example can give a better idea of why some of the language design aspects are the way they are, eg why parameters/arguments are always named in the core. -- Darren Duncan From Peter at PSDT.com Tue Jan 8 13:09:48 2008 From: Peter at PSDT.com (Peter Scott) Date: Tue, 08 Jan 2008 13:09:48 -0800 Subject: [VPM] perhaps a combined January Meeting? In-Reply-To: References: Message-ID: <6.2.3.4.2.20080108130855.030c7640@mail.webquarry.com> At 06:24 PM 1/7/2008, Darren Duncan wrote: >Also, if Victoria.pm takes place, that would already be on tuesday >the 15th. However, I just suggested to them that we might be able to >have a combined meeting this month, and now I'm suggesting it to you. I'm fine with the combined meeting. I don't need to beat my suggested meeting topic if it's a dead horse. Any other suggestions? -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ http://www.perlmedic.com/ From darren at DarrenDuncan.net Tue Jan 8 15:49:21 2008 From: darren at DarrenDuncan.net (Darren Duncan) Date: Tue, 08 Jan 2008 15:49:21 -0800 Subject: [VPM] [reccompsci] Re: perhaps a combined January Meeting? In-Reply-To: <20080108231917.GI11452@true> References: <6.2.3.4.2.20080108130855.030c7640@mail.webquarry.com> <20080108231917.GI11452@true> <6.2.3.4.2.20080108130855.030c7640@mail.webquarry.com> <20080108231917.GI11452@true> Message-ID: At 2:48 PM -0800 1/8/08, Angela Norton wrote: >Whoops, I had an off-by-one error on my calendar... Happens when it's >indexed from Monday instead of Sunday. I meant to write Wednesday the >16th. If the majority would be happier with a Tuesday meeting, that's >fine, but I won't be able to make it. Votes? At 3:19 PM -0800 1/8/08, noel at natnix.com wrote: >I can't make it next Tuesday or Wednesday, sorry. Here are some topics >I could present at future meetings: > >firewall hacking: getting through NAT routers with STUN, etc. e.g. How Skype >works. > >compression: pedictive coding, arithmetic coding, wavelet >transforms. At 3:36 PM -0800 1/8/08, Angela Norton wrote: >Noel, >What about Thursday next week? I'd be very interested in anything on >firewalls. That would be a great topic. > >I'm putting together a talk on embedded Linux (OpenWRT) on routers. >Perhaps the two talks would fit together nicely on the same night? I don't personally expect that thursday the 17th will be a conflict, so that's good. However, we'll need to see how many people can not come on thursday that could come on the other days. -- Darren Duncan From darren at DarrenDuncan.net Thu Jan 10 22:22:19 2008 From: darren at DarrenDuncan.net (Darren Duncan) Date: Thu, 10 Jan 2008 22:22:19 -0800 Subject: [VPM] [reccompsci] Re: perhaps a combined January Meeting? In-Reply-To: References: <6.2.3.4.2.20080108130855.030c7640@mail.webquarry.com> <20080108231917.GI11452@true> Message-ID: At 3:36 PM -0800 1/8/08, Angela Norton wrote: >What about Thursday next week? As an update to my earlier reply on this ... Something has come up such that it would work especially well for me if our meeting was on thursday, assuming 7pm at UVIC as per usual. Specifically, another (unrelated) group I'm involved in has just setup a meeting for 5pm on next thursday the 17th at 5pm, at UVIC. Assuming that doesn't go beyond 2 hours, I can then have that meeting and ours back to back, without conflict. This is good for me considering I travel by bus to Victoria each time I have a meeting from Deep cove, so I have at least 4-5 hours travel overhead per trip; the combination of 2 events saves me much time. That said, I'll still submit to coming an extra day if some other schedule would be best for the group as a whole. -- Darren Duncan From darren at DarrenDuncan.net Sun Jan 13 18:40:21 2008 From: darren at DarrenDuncan.net (Darren Duncan) Date: Sun, 13 Jan 2008 18:40:21 -0800 Subject: [VPM] fyi, official terse Muldis D dialect for daily work Message-ID: Note that this message is a follow-up to my 2008 January 8th post of subject "fyi, Muldis D core AST dialect example". I have now started work on defining another official dialect of Muldis D which should be within the level of terseness of most typical high-level programming languages, and which is the one that is intended for regular use by programmers in their day to day code writing, or for writing code examples in. Moreover, the Muldis DB Interface core API would take this new dialect natively, so even your wrapper modules could choose to ignore the verbose one if they want to. See http://search.cpan.org/dist/Language-MuldisD/lib/Language/MuldisD/Hierarchical.pod (a new file with release 0.17.0) for what information exists on this new dialect so far. That file just has a few paragraphs that outline the differences between that dialect, and the previous verbose Perl-Hosted Muldis D dialect that I previously gave an example in. The main new features are introduced, and it should be apparent enough as to how they make the code a lot more terse, while still being easy (in fact, easier) to understand and self-documenting. Here are a few bullet points abbreviated from Hierarchical.pod: - Speaking in analogy, the new dialect's alphabet has 100 characters rather than the 10 of the verbose dialect, so you can express all the possible ideas using a smaller number of characters. - Code is defined as trees of Perl Array|Hash, like PerlHosted. - Literals like numbers and strings are formatted the same way as in PerlHosted; each is an array ref having a Perl literal payload plus meta-data. - Expression trees are actually N-depth nested trees of nodes, rather than a flat list of named nodes (the tree isn't a fixed depth, but a variable depth). - There are more kinds of AST nodes, each having fewer attributes, and in particular you don't have to define attributes that aren't used (the verbose dialect does, so to make all nodes the same shape). There is a node kind each for function|procedure declaration et al, rather than a generic Tuple node kind. - System-defined types,routines,etc can be invoked using their unqualified names rather than fully qualified names, eg no 'sys.Core.' prefix needed. - A bunch of aliases are provided for built-in routines, including a full complement of the symbol-character usual suspects, like '=' for 'is_equal' or '<' for 'is_ascending'. - System-defined routine invocations can have positional arguments or named, your choice. - Note that the name abbreviations and positional arguments option only apply to built-ins, not user-defined routines, since it must be possible to resolve these to their full or named equivalents when any user-defined routine is taken in isolation, and there is no information about earlier defined user-def to work with; also, the core AST only tracks params/args by name not position anyway. I still have to work out the details of the new dialect, but here's an example of how Muldis D code in the terse dialect could look; compare this 'square' function with the other email: [ 'function', 'square', '', [ [ 'inner_function', '', { 'result_type' => 'UInt', 'params' => { 'topic' => 'Int', }, 'root_expr' => '', 'exprs' => { '' => [ 'sys_func', 'Int.power', { 'radix' => [ 'param', 'topic' ], 'exponent' => [ 'Int', 'perl_int', 2 ], } ], }, } ], ] ] That example did not use symbol-char aliases nor positional arg aliases, and is probably my preferred format; but if you want to use either of said options, the function could look like this instead: [ 'function', 'square', '', [ [ 'inner_function', '', { 'result_type' => 'UInt', 'params' => { 'topic' => 'Int', }, 'root_expr' => '', 'exprs' => { '' => [ 'sys_func', 'Int.**', [ [ 'param', 'topic' ], [ 'Int', 'perl_int', 2 ], ] ], }, } ], ] ] Now, this may still look a bit fat, but some of that is standard overhead for any function definition, and for more complicated functions, that part wouldn't be any larger / would be proportionally smaller. So fleshing out this new dialect is my current top priority in the language design, so hopefully the details will be published within 1-2 weeks. -- Darren Duncan P.S. In any event, those of you accustomed to Perl modules like SQL::Abstract should now find this Muldis D dialect a lot easier to translate to. If you don't see that yet, then maybe by the next language spec release you will. From darren at DarrenDuncan.net Tue Jan 15 18:17:43 2008 From: darren at DarrenDuncan.net (Darren Duncan) Date: Tue, 15 Jan 2008 18:17:43 -0800 Subject: [VPM] So, no January meeting at all then? Message-ID: What I heard discussed last week strongly suggests that there isn't really any rationale to hold a January meeting of RCSS or VPM, neither separate nor combined. Not enough content available. I move to just cancel any January 2008 meetings entirely and just move on afterwards to planning February 2008 meetings instead. The content discussed for RCSS so far could be done the first tuesday of February et al, and I anticipate new material for a February VPM will arrive in time for the third tuesday of February, from me if not someone else. If there is silence I'll take that as defacto agreement to cancel. So speak up if you think something should still happen this month. Thank you. -- Darren Duncan From darren at DarrenDuncan.net Wed Jan 16 15:58:40 2008 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed, 16 Jan 2008 15:58:40 -0800 Subject: [VPM] [reccompsci] Re: So, no January meeting at all then? In-Reply-To: References: Message-ID: Angela, I apologize now to the group and/or you if it looked like I was trying to take charge and unilaterally cancel the January meeting. Though I expressed it badly, what I really wanted was to confirm whether it was happening or not since it didn't look like any final decisions were made, but rather that only possibilities were raised, and no actual meeting announcement was yet made. I hoped from my language that it would come across that I was treating the matter like a democracy and was raising a motion/suggestion as a member for others to respond to. It wasn't just for my sake, but I was concerned that typically with no meeting announcement, usually made several days in advance people won't know whether it is happening or not, and won't know whether to go or not. Anyway, now that this matter is clarified, I do intend to be there at UVIC in ECS Room 130 tomorrow / thursday. I may arrive slightly late though, but I'll try to be on time. Meanwhile, if you want to post an actual meeting announcement soon, I'll forward it to some other mailing lists like I usually do to spread the word. -- Darren Duncan At 10:52 AM -0800 1/16/08, Angela Norton wrote: >Darren, >If you do not feel up to the arduous bus journey from Deep Cove to >UVic, that's ok. Attendance is voluntary and optional. > >However, I don't think it is appropriate for you to cancel a meeting >when there has been interest from several people. This is a community >group made possible by volunteer speakers and by UVic's donation of a >meeting room. Despite not having any official speakers this month, we >can still meet and discuss, on an informal basis, topics that the >people in attendance find interesting. > >So yes, there will be a January meeting at 7pm tomorrow evening in ECS >Room 130 @ UVic, for any and all who want to come. I can't guarantee a >snazzy presentation, but bring something interesting to discuss (a >paper you read recently, a new technology you found, etc.) and we'll >play it by ear. > >Regards, >Angela > >On Jan 15, 2008 6:17 PM, Darren Duncan wrote: >> >> What I heard discussed last week strongly suggests that there isn't >> really any rationale to hold a January meeting of RCSS or VPM, >> neither separate nor combined. Not enough content available. >> >> I move to just cancel any January 2008 meetings entirely and just >> move on afterwards to planning February 2008 meetings instead. >> >> The content discussed for RCSS so far could be done the first tuesday >> of February et al, and I anticipate new material for a February VPM >> will arrive in time for the third tuesday of February, from me if not >> someone else. >> >> If there is silence I'll take that as defacto agreement to cancel. >> >> So speak up if you think something should still happen this month. >> > > Thank you. -- Darren Duncan From darren at DarrenDuncan.net Thu Jan 17 12:46:32 2008 From: darren at DarrenDuncan.net (Darren Duncan) Date: Thu, 17 Jan 2008 12:46:32 -0800 Subject: [VPM] Thu, 2008 Jan 17th (tonight!), 7:00pm - January RCSS meeting Message-ID: This message is forwarded from the Recreational Computer Science Society mailing list. -- Darren Duncan ------------- Date: Thu, 17 Jan 2008 11:44:23 -0800 From: "Angela Norton" To: reccompsci at googlegroups.com Subject: [reccompsci] RCSS Meeting Announcement: Tonight! Mailing-List: list reccompsci at googlegroups.com; contact reccompsci-owner at googlegroups.com List-Id: List-Post: List-Help: List-Unsubscribe: , RCSS Meeting Thursday January 17th @ 1900 hours (7PM) University of Victoria, ECS Building Room 130 (the little room down the short hallway) There aren't any planned talks so it'll be an informal discussion. Hope to see you all there! --Angela --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Recreational Computer Science Society" group. To post to this group, send email to reccompsci at googlegroups.com To unsubscribe from this group, send email to reccompsci-unsubscribe at googlegroups.com For more options, visit this group at http://groups.google.com/group/reccompsci?hl=en -~----------~----~----~----~------~----~------~--~--- From darren at DarrenDuncan.net Fri Jan 18 20:40:19 2008 From: darren at DarrenDuncan.net (Darren Duncan) Date: Fri, 18 Jan 2008 20:40:19 -0800 Subject: [VPM] fyi, Qt adopts GPLv3 as license option Message-ID: FYI, Trolltech just announced today that they're now licensing Qt under the GPLv3. This is in addition to remaining under the licenses it was under before. See http://trolltech.com/company/newsroom/announcements/press.2008-01-18.1601592972 for the announcement. This is very welcome news for the large community of developers and free software users. Qt is used by a lot of projects, and those which want to combine QT with other code licensed under the GPLv3 have been unable to before; now they are compatible, opening the door to more work coming out under the preferred license of some developers, or coming out at all. That includes KDE, as a large example. -- Darren Duncan From darren at DarrenDuncan.net Sat Jan 19 02:38:33 2008 From: darren at DarrenDuncan.net (Darren Duncan) Date: Sat, 19 Jan 2008 02:38:33 -0800 Subject: [VPM] Rakudo is the Perl 6 implementation on Parrot Message-ID: As people have probably been aware from various sources, one big difference between the new Perl 6 and Perl 5- is that while for the older Perl, the sole implementation (called 'perl') was also the spec, Perl 6 has a separate spec and multiple implementations, which is a much better way to do things. The spec is called Perl 6, and apparently all of the implementations will come under names different from that, and no implementation will be the single official one. The first main implementation, over Haskell, was called Pugs. But now the big news for today is ... The Perl 6 implementation over Parrot (a C-based virtual machine for dynamic languages), which was intended originally and will probably end up being the most used, has now been given a name, "Rakudo". See http://rakudo.org/ , a central website for it, in particular http://www.rakudo.org/2008/01/the-compiler-formerly-known-as.html for an explanation of this naming decision. So in the future if people start referring to Rakudo, you'll know what it is. -- Darren Duncan From jeremygwa at hotmail.com Tue Jan 29 21:19:34 2008 From: jeremygwa at hotmail.com (Jer A) Date: Tue, 29 Jan 2008 21:19:34 -0800 Subject: [VPM] DProf In-Reply-To: References: Message-ID: hi all, I am in the process of trying to optimize a cgi script. what do the values mean and what should I monitor for improvements. -jeremy eg. #fOrTyTwO $hz=1000; $XS_VERSION='DProf 20050603.00'; # All values are given in HZ $over_utime=15; $over_stime=16; $over_rtime=31; $over_tests=10000; $rrun_utime=172; $rrun_stime=125; $rrun_rtime=297; $total_marks=440 _________________________________________________________________ From Peter at PSDT.com Wed Jan 30 09:42:59 2008 From: Peter at PSDT.com (Peter Scott) Date: Wed, 30 Jan 2008 09:42:59 -0800 Subject: [VPM] DProf In-Reply-To: References: Message-ID: <6.2.3.4.2.20080130094111.02fbd570@mail.webquarry.com> At 09:19 PM 1/29/2008, Jer A wrote: >hi all, > >I am in the process of trying to optimize a cgi script. what do the >values mean See http://search.cpan.org/~ilyaz/DProf-19990108/DProf.pm#PROFILE_FORMAT >and what should I monitor for improvements. Use the program dprofpp which comes with DProf to interpret this file for you. >-jeremy > >eg. > >#fOrTyTwO >$hz=1000; >$XS_VERSION='DProf 20050603.00'; ># All values are given in HZ >$over_utime=15; $over_stime=16; $over_rtime=31; >$over_tests=10000; >$rrun_utime=172; $rrun_stime=125; $rrun_rtime=297; >$total_marks=440 I find a number of problems with DProf (file gets huge rapidly, cannot be piped, trace only at subroutine level). I consider Devel::SmallProf much better. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ http://www.perlmedic.com/ From jeremygwa at hotmail.com Wed Jan 30 11:09:52 2008 From: jeremygwa at hotmail.com (Jer A) Date: Wed, 30 Jan 2008 11:09:52 -0800 Subject: [VPM] DProf - optimizing perl scripts In-Reply-To: References: Message-ID: hi all, Let me clarify: I do not understand the difference of "over" from "rrun", or "utime","stime","rtime", and what values are most important. I am trying to test using different logic, and notice that the "total_marks" may not change, even if the all other values are lower. thanks in advance for all your help. -Jer > hi all, > > I am in the process of trying to optimize a cgi script. what do the values mean and what should I monitor for improvements. > > -jeremy > > eg. > > #fOrTyTwO > $hz=1000; > $XS_VERSION='DProf 20050603.00'; > # All values are given in HZ > $over_utime=15; $over_stime=16; $over_rtime=31; > $over_tests=10000; > $rrun_utime=172; $rrun_stime=125; $rrun_rtime=297; > $total_marks=440 _________________________________________________________________ From Peter at PSDT.com Wed Jan 30 11:39:36 2008 From: Peter at PSDT.com (Peter Scott) Date: Wed, 30 Jan 2008 11:39:36 -0800 Subject: [VPM] DProf - optimizing perl scripts In-Reply-To: References: Message-ID: <6.2.3.4.2.20080130113759.02fab5c0@mail.webquarry.com> > >hi all, > >Let me clarify: > >I do not understand the difference of "over" from "rrun", or >"utime","stime","rtime", and what values are most important. > >I am trying to test using different logic, and notice that the >"total_marks" may not change, even if the all other values are lower. > >thanks in advance for all your help. Did you run the dprofpp program? It understands the output of DProf. You're not supposed to have to understand that output yourself. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ http://www.perlmedic.com/