Re: Micro-articles on Perl 6 Operators
On 9/18/07, Adriano Ferreira [EMAIL PROTECTED] wrote: Join me. The drafts of the introduction and the first article are here: http://ferreira.nfshost.com/perl6/intro.html http://ferreira.nfshost.com/perl6/zip.html I see the following snippet in zip.html: # import num2en from Perl 6 Lingua::EN::Numbers module use :from perl5 Lingua::EN::Numbers num2en ; Maybe you meant Perl 5 in that comment? It looks inconsistent to me ;) Nice article, BTW :) Thanks, agentz
[svn:parrot-pdd] r21338 - trunk/docs/pdds
Author: paultcochrane Date: Tue Sep 18 00:59:04 2007 New Revision: 21338 Modified: trunk/docs/pdds/pdd03_calling_conventions.pod Log: [pdd] Removed deprecated opcode syntax as recommended by Allison Randal. This resolves RT#45363 Modified: trunk/docs/pdds/pdd03_calling_conventions.pod == --- trunk/docs/pdds/pdd03_calling_conventions.pod (original) +++ trunk/docs/pdds/pdd03_calling_conventions.pod Tue Sep 18 00:59:04 2007 @@ -54,17 +54,15 @@ The common syntax of these opcodes is: - set_opcode (flags0, flags1, ..., flagsN), VAL0, VAL1, ... VALN - get_opcode (flags0, flags1, ..., flagsN), REG0, REG1, ... REGN - get_opcode (..., 0x200, flags0, ...), ..., name, REG0, ... + set_opcode flags0, flags1, ..., flagsN, VAL0, VAL1, ... VALN + get_opcode flags0, flags1, ..., flagsN, REG0, REG1, ... REGN + get_opcode ..., 0x200, flags0, ..., ..., name, REG0, ... The flags string is a literal quoted string denoting a list of zero or more comma-separated integers. Integers may be specified either in decimal, or if prefixed with 0b/0x, in binary/hexadecimal. There must be exactly one integer for each value or register given. -(RT#45363 DEPRECATED: The list as a whole may be surrounded by parentheses.) - For documentation purposes we'll number the bits 0 (low) through 30 (high). Bit 31 (and higher, where available) will not be used.
Re: Parrot configuration system: weaknesses and strengths
On Sep 18, 2007, at 12:29 AM, Allison Randal wrote: For perspective, keep in mind that we will eventually be refactoring the Perl 5-based configure system anyway, to remove the dependency on an old install of Perl 5. So, the behavior of the current prototype configuration system is more important than the internal structure of the code. Agreed. But dare I ask: Is anyone beginning to plot out this transition? Quite a few months back I heard terms like 'autoconf' and 'miniparrot' mentioned -- but I haven't hear anything lately. It would be good to have some minimal preliminary discussion as to how we will do this, as that might have an impact on how we shape file-based configuration. kid51
Re: Parrot configuration system: weaknesses and strengths
On Sep 18, 2007, at 12:29 AM, Allison Randal wrote: I would like to have the option of making some configuration failures fatal. The lack of a working C compiler is a good example, but I imagine we will find others as we go along. I would also like the option of telling Configure to ignore failures that would usually be fatal and carry on through the process. Getting a full report of all failures is useful for automated smoke testing, or other cases when the build is running in a scripted way rather than an interactive way. It seems we can have the best of both worlds if runstep() reports success or failure, and the configuration harness (or a package variable for each step) keeps track of which steps should be fatal. I can think of two revisions which would be relatively simple to implement and which would move us in the direction you suggest. 1. Analogous to our current Configure.pl option '--verbose-step=', create an '--abort-step' option which permits the user to specify on the command-line *one* configuration step whose failure should, in that user's opinion, cause configuration as a whole fail. This would be of benefit to a Parrot developer who is refactoring a particular config step and wants immediate feedback on how the process works up through that step. (Once we have a file-based configuration system as an alternative to a command-line-option-based system, it will easy to check off the config steps which you want as either --verbose-step or --abort-step.) 2. The current configuration system is a harness, so let's make it perform as a slightly better harness. Let's have it keep a simple log of config steps which failed and then report those failures instead of the current ever-cheery message from that use Parrot::Configure::Messages::print_conclusion(). On which are fatal, I'm happy to start with just the C compiler check, and maybe the MANIFEST check, and then review the other steps on a case-by-case. The suggestions above would permit individual Parrot hackers to experiment with having overall configuration fail based on the result of one step. We could use reports on those experiments as data to decide in the future whether to make particular steps always mandatory. If these revisions seem reasonable I will open up RT tickets for each tonight, then begin working on them, probably first in the reconfigure/ branch before proposing for commit to trunk. kid51
Re: Micro-articles on Perl 6 Operators
On 9/18/07, Agent Zhang [EMAIL PROTECTED] wrote: On 9/18/07, Adriano Ferreira [EMAIL PROTECTED] wrote: Join me. The drafts of the introduction and the first article are here: http://ferreira.nfshost.com/perl6/intro.html http://ferreira.nfshost.com/perl6/zip.html I see the following snippet in zip.html: # import num2en from Perl 6 Lingua::EN::Numbers module use :from perl5 Lingua::EN::Numbers num2en ; Maybe you meant Perl 5 in that comment? It looks inconsistent to me ;) Yes. That's what I meant. Fixed by now. Thanks. Nice article, BTW :) Thanks, agentz
Re: Micro-articles on Perl 6 Operators
In article [EMAIL PROTECTED], Alberto Simões [EMAIL PROTECTED] wrote: Adriano Ferreira wrote: The plan is to write a series of blog entries discussing a Perl 6 operator at a time or a small group of closely related ones. I think the idea is cool. Also, I do not know how periodically that would be, but it might be a good idea to join some of them in turns and ask brian d foy to publish them in TPR as well. Yes, I'd publish them. :) However, I don't want to publish something that's already on Perl.com.
Re: Micro-articles on Perl 6 Operators
On 9/18/07, brian d foy [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Alberto Simões [EMAIL PROTECTED] wrote: Adriano Ferreira wrote: The plan is to write a series of blog entries discussing a Perl 6 operator at a time or a small group of closely related ones. I think the idea is cool. Also, I do not know how periodically that would be, but it might be a good idea to join some of them in turns and ask brian d foy to publish them in TPR as well. Yes, I'd publish them. :) However, I don't want to publish something that's already on Perl.com. brian is right. The blog entries in ONLamp will appear right away in perl.com. To tell the truth, they already are: * the introduction http://www.oreillynet.com/onlamp/blog/2007/09/yet_another_perl_6_operator_th.html * the zip article http://www.oreillynet.com/onlamp/blog/2007/09/yet_another_perl_6_operator_zi.html Thanks, folks. Adriano.
please stop converting FUNCDOC headings to POD.
On Sep 18, 2007, at 9:04 AM, [EMAIL PROTECTED] wrote: -FUNCDOC: mark_special +=item Cmark_special This is a perfect example of why I want us to use FUNCDOC and not POD. Who says that we are presenting functions as =item lists? Why is it presented in C? =item Cmark_special applies two levels of presentation of documentation when we simply don't know how we want it presented. Paul, please hold off on changing any more FUNCDOC. The only value in having embedded POD in C source code is the ability to say pod2html foo.c foo.html, and that's just not much of a benefit when you consider the amount of boilerplate we'd be re-adding. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: please stop converting FUNCDOC headings to POD.
On 18/09/2007, Andy Lester [EMAIL PROTECTED] wrote: On Sep 18, 2007, at 9:04 AM, [EMAIL PROTECTED] wrote: -FUNCDOC: mark_special +=item Cmark_special This is a perfect example of why I want us to use FUNCDOC and not POD. Who says that we are presenting functions as =item lists? Why is it presented in C? =item Cmark_special applies two levels of presentation of documentation when we simply don't know how we want it presented. Paul, please hold off on changing any more FUNCDOC. The only value in having embedded POD in C source code is the ability to say pod2html foo.c foo.html, and that's just not much of a benefit when you consider the amount of boilerplate we'd be re-adding. Ok. Consider the conversion held off. Allison had decided we should just use pod in the source and so to replace any other form of markup. Functions as =item C lists were written as what to do in the coding standards pod ages ago, hence the use of this markup here. Paul
[perl #45401] PROPOSAL: Remove :postcomp flag
On Wed Sep 12 08:28:27 2007, kjs wrote: Hello, From: http://www.parrotcode.org/docs/pdd/pdd06_pasm.html The following flags are available: :main to indicate that execution should start at the specified subroutine; :immediate or :postcomp to indicate that the sub should be run immediately after compilation; :load to indicate that the sub should be executed when its bytecode segment is loaded; :init to indicate the sub should be run when the file is run directly. THere are two flags, :immediate and :postcomp that have the same behaviour. IMO, it'd be nice to remove such redundancies from IMCC. My proposal is to remove either :immediate or :postcomp. I'd vote for keeping :immediate, thus removing :postcomp. regards, kjs As long as :postcomp has no meaning aside from what :immediate provides, I agree, it should be removed.
[perl #45403] [PROPOSAL] Remove - syntax from IMCC
On Wed Sep 12 08:33:04 2007, kjs wrote: Hi, IMCC currently allows for C++ style method invocation (using a pointer as invocant). So, while this works: .sub main $P0 = new 'Foo' $P0.'bar'() .end You could also write: .sub main $P0 = new 'Foo' $P0-bar() .end Or even: .sub main $P0 = new 'Foo' $P0-bar() .end (note that both bareword and quoted names work). This issue also touches upon the issue of bareword method names in general (using dot notation), but that's besides the topic at this point (but it /does/ need a decision sometime). The - syntax is not very well documented (if at all?) and is rarely used (maybe not at all?). In order to keep PIR syntax clean, I propose to remove the - syntax for method calls, as it is the same as the dot-notation. regards, kjs I agree and see no issue with '-' being deprecated.
Re: [perl #45403] [PROPOSAL] Remove - syntax from IMCC
On 9/18/07, Will Coleda via RT [EMAIL PROTECTED] wrote: On Wed Sep 12 08:33:04 2007, kjs wrote: Hi, IMCC currently allows for C++ style method invocation (using a pointer as invocant). So, while this works: .sub main $P0 = new 'Foo' $P0.'bar'() .end You could also write: .sub main $P0 = new 'Foo' $P0-bar() .end Or even: .sub main $P0 = new 'Foo' $P0-bar() .end (note that both bareword and quoted names work). This issue also touches upon the issue of bareword method names in general (using dot notation), but that's besides the topic at this point (but it /does/ need a decision sometime). The - syntax is not very well documented (if at all?) and is rarely used (maybe not at all?). In order to keep PIR syntax clean, I propose to remove the - syntax for method calls, as it is the same as the dot-notation. regards, kjs I agree and see no issue with '-' being deprecated. seconded. ~jerry
Re: [perl #45401] PROPOSAL: Remove :postcomp flag
On 9/18/07, Will Coleda via RT [EMAIL PROTECTED] wrote: On Wed Sep 12 08:28:27 2007, kjs wrote: Hello, From: http://www.parrotcode.org/docs/pdd/pdd06_pasm.html The following flags are available: :main to indicate that execution should start at the specified subroutine; :immediate or :postcomp to indicate that the sub should be run immediately after compilation; :load to indicate that the sub should be executed when its bytecode segment is loaded; :init to indicate the sub should be run when the file is run directly. THere are two flags, :immediate and :postcomp that have the same behaviour. IMO, it'd be nice to remove such redundancies from IMCC. My proposal is to remove either :immediate or :postcomp. I'd vote for keeping :immediate, thus removing :postcomp. regards, kjs As long as :postcomp has no meaning aside from what :immediate provides, I agree, it should be removed. yep, :postcomp and :immediate are the same, let's settle on :immediate and remove :postcomp. ~jerry
Re: [perl #45401] PROPOSAL: Remove :postcomp flag
attached is a testfile. file imm.pir contains: .sub main .end .sub foo :postcomp print postcomp\n .end .sub bar :immediate print immediate\n .end = and file main.pir contains: === .sub main2 :main load_bytecode imm.pir print ok\n .end === There are different options to run: parrot imm.pir outputs: immediate postcomp Now, in main.pir the file imm.pir is loaded, so something should happen when running main.pir: parrot main.pir outputs: immediate ok So, apparently the :postcomp tagged sub is not run when loaded by another file. My conclusion is (and please correct me if I'm wrong): 1. use :immediate if the sub must be run after compilation, no matter what the compilation caused (whether running the file containing that sub, or the file containing that sub was load_bytecode-ed. 2. use :postcomp if the sub must be run after compilation ONLY if the file in which the sub was defined is compiled explicitly (by running parrot file). The sub is NOT run when the sub is compiled due to a load_bytecode operation. I don't really see a use-case right now, but I guess there is /some/ use for it. regards, kjs On 9/18/07, jerry gay [EMAIL PROTECTED] wrote: On 9/18/07, Will Coleda via RT [EMAIL PROTECTED] wrote: On Wed Sep 12 08:28:27 2007, kjs wrote: Hello, From: http://www.parrotcode.org/docs/pdd/pdd06_pasm.html The following flags are available: :main to indicate that execution should start at the specified subroutine; :immediate or :postcomp to indicate that the sub should be run immediately after compilation; :load to indicate that the sub should be executed when its bytecode segment is loaded; :init to indicate the sub should be run when the file is run directly. THere are two flags, :immediate and :postcomp that have the same behaviour. IMO, it'd be nice to remove such redundancies from IMCC. My proposal is to remove either :immediate or :postcomp. I'd vote for keeping :immediate, thus removing :postcomp. regards, kjs As long as :postcomp has no meaning aside from what :immediate provides, I agree, it should be removed. yep, :postcomp and :immediate are the same, let's settle on :immediate and remove :postcomp. ~jerry imm.pir Description: Binary data main.pir Description: Binary data
Re: please stop converting FUNCDOC headings to POD.
Andy Lester wrote: On Sep 18, 2007, at 9:04 AM, [EMAIL PROTECTED] wrote: -FUNCDOC: mark_special +=item Cmark_special This is a perfect example of why I want us to use FUNCDOC and not POD. Who says that we are presenting functions as =item lists? Why is it presented in C? =item Cmark_special applies two levels of presentation of documentation when we simply don't know how we want it presented. Paul, please hold off on changing any more FUNCDOC. The only value in having embedded POD in C source code is the ability to say pod2html foo.c foo.html, and that's just not much of a benefit when you consider the amount of boilerplate we'd be re-adding. We decided to remove FUNCDOC in May soon after it appeared. At the time it only appeared in a couple of files, so I was surprised to it now scattered over a couple of dozen files. DRY is a good principle, but it's not the only principle to follow. Another good principles is YAGNI: don't invent a new system until you absolutely need it (your needs will change before you get there anyway), and don't invent it at all if you can avoid it. Another good principle is careful investment of developer resources: we will have to make the investment in developing Parrot-based Pod parsing and formatting tools for the bulk of the repository, so it doesn't make sense to duplicate the effort and produce another set of tools for a different documentation format. Back to DRY again, the biggest objection to using Pod is creating an exact duplicate of the function signature in the Pod. So, we won't do that. We'll just list the name of the function in the Pod. We'll also give some code examples of how to call the function (sane code examples can't be generated, they always require a human brain). And, when Perl 6 Pod or Parrot's Pod tools are far enough developed, we'll start automatically pulling in the full function signature from the code. Allison
Re: please stop converting FUNCDOC headings to POD.
On Tuesday 18 September 2007 12:38:49 Andy Lester wrote: We decided to remove FUNCDOC in May soon after it appeared. At the time it only appeared in a couple of files, so I was surprised to it now scattered over a couple of dozen files. Who is we? I was entirely unaware of it. I've yanked POD on every file that I've headerized, which is all of them. Funny; every time *I* came across FUNCDOC, I kept thinking What in the world is this old stuff doing here? and yanking it. Seems to me I don't recall ANY of this ever getting discussed. -- c
[perl #45507] Parrot Release October 2007
# New Ticket Created by Jerry Gay # Please include the string: [perl #45507] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45507 this ticket is a placeholder for the release scheduled for 16 October 2007
Gone for a while
The FUNCDOC hoohah points out something that has been bugging me for a while and that now is actionable: I don't know WTF is going on any more. I'm very out of touch, even though I sometimes sort of try to keep an eye on what's going on. It's no way to be involved in a project. So, I'm backing out of Parrot development for right now. If anyone needs me, you know where to find me. For that matter, if there's anything specifically that I can help with, please let me know. I just can't keep an eye on what's going on any more. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: please stop converting FUNCDOC headings to POD.
Andy Lester wrote: We decided to remove FUNCDOC in May soon after it appeared. At the time it only appeared in a couple of files, so I was surprised to it now scattered over a couple of dozen files. Who is we? I was entirely unaware of it. I've yanked POD on every file that I've headerized, which is all of them. These are the googlable references I found: http://www.parrotcode.org/misc/parrotsketch-logs/irclog.parrotsketch-200705/irclog.parrotsketch.20070501 and: http://www.mail-archive.com/[EMAIL PROTECTED]/msg35922.html Anyway, that's the past and not as important as the future. Back to DRY again, the biggest objection to using Pod is creating an exact duplicate of the function signature in the Pod. More than anything, I want boilerplate gone. =item Cfoo is boilerplate. At the VERY least, remove the C. The C is just standard Pod formatting for marking off code from plain text, so you can tell the difference between, say, a plain item named list and a function named 'list'. What I would like to see is something like: =item Cfoo (C, PASM, PIR) Saying where the routine can be called from, and then code examples of each context. Allison
Re: Gone for a while
Andy Lester wrote: The FUNCDOC hoohah points out something that has been bugging me for a while and that now is actionable: I don't know WTF is going on any more. I'm very out of touch, even though I sometimes sort of try to keep an eye on what's going on. It's no way to be involved in a project. So, I'm backing out of Parrot development for right now. If anyone needs me, you know where to find me. For that matter, if there's anything specifically that I can help with, please let me know. I just can't keep an eye on what's going on any more. I'm sorry to hear that. You're welcome back any time. All contributions are valuable, and isn't necessary to follow every detail of every aspect of the project to contribute. Thanks for your help, Allison
Re: Parrot configuration system: weaknesses and strengths
I am not sure what to quote so let me reply on a clean page. I would like to see invalid configuration options and values as being always fatal. They indicate some kind of user error, a typo or similar that would probably cause trouble to the Parrot developer as well as the Parrot user. In order to archive that I wonder if it would be possible to allow two methods: 1) The individual configuration step could report an error as a return value so the harness can decide if this particular failure is fatal or not. 2) In addition the individual configuration step could declare a fatal error (e.g. by die-ing) that would be respected by the harness and reported as fatal. Gabor
Parrot 0.4.16 Released
On behalf of the Parrot team, I'm proud to announce Parrot 0.4.16, A Farewell to Alex. Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. Parrot 0.4.16 can be obtained via CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion or SVK on the source code repository to get the latest and best Parrot code. Parrot 0.4.16 News: - Implementation: + Performed code review on every PMC + Modified PMC code generation to use Storable, reducing compile times + Added a makefile target to generate test coverage data of C sources - Languages: + NQP: added lists, for loops, operators, comparison and multiplicative operators + Announced Kea-CL, Kea Common Lisp, an ANSI Common Lisp implementation The repository is available at https://rgrjr.dyndns.org/svn/kea-cl/trunk/ - Documentation + PDD17 PMCs - draft approved, the design is complete + Added more PIR tutorials, see examples/tutorial/00_README.pod - Miscellaneous: + Many bugfixes, enhancements, documentation, and coding standard updates + Deprecated PMC constants and other crufty syntax, see DEPRECATED.pod + Improved icc compiler compatibility for error line reporting Thanks to all our contributors for making this possible, and our sponsors for supporting this project. Enjoy! ~jerry
Re: Gone for a while
I'm sorry to hear that. You're welcome back any time. All contributions are valuable, and isn't necessary to follow every detail of every aspect of the project to contribute. Understood. It's just clear that I'm way out the loop on things, and I don't have the time to talk about the things that I've been wanting to talk about for a while anyway. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
[perl #45525] [TODO] Configure.pl: permit an --abort-step option
See this non-RT thread on perl.perl6.internals for additional discussion of the issues raised in this ticket: http://tinyurl.com/3y7kgf
[perl #45525] [TODO] Configure.pl: permit an --abort-step option
# New Ticket Created by James Keenan # Please include the string: [perl #45525] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45525 A number of Parrot developers working on configuration steps (config/ */*.pm and config/*/*/*.pm) have indicated that they would benefit from better feedback when an individual configuration step fails. Since Configure.pl has for some time acted primarily as a harness for running a series of configuration steps, its objective has been to keep on going when an individual step fails. For the purpose of this RT, it is assumed that this is a good thing most of the time. But we need to make allowances for the Parrot developer who, needing to get to work quickly on a failing configuration step, wants the configuration process to come to a clean, complete halt when a particular step fails. Ideally, the user should be able to specify whether any of an indefinite number of configuration steps should have the property of being able to halt configuration as a whole upon failure. For that degree of flexibility we will probably have to evolve to a file-based configuration system as suggested by Jerry Gay in https://rt.perl.org/ rt3/Ticket/Display.html?id=44315. In the meantime, however, we can provide users with an --abort-step option to Configure.pl. This would work in a manner analogous to the current --verbose-step option, i.e., the user gets to name one and only one step whose failure causes Configure.pl to terminate with extreme prejudice. That naming would be done by configuration step number, formal name (e.g., inter::progs) or pattern match on the step's $description. Assignment: Provide an --abort-step option to Configure.pl. kid51
[perl #45523] [TODO] Have Configure.pl inform user of failed configuration steps
# New Ticket Created by James Keenan # Please include the string: [perl #45523] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45523 Configure.pl has long operated as a harness for the running of individual configuration steps, currently 58 in number. Just when Perl 5's Test::Harness module tries to run a series of individual test files even when one of those test files has died, so too does Parrot's Configure.pl attempt to run the whole series of individual configuration steps even when one or more steps has failed. Unlike Test::Harness, however, Configure.pl is not a very smart harness. It doesn't regularly inform the user of a failure in an individual configuration step. We need to change this, but because of the complexity of the configuration process and the fact that it works well for most Parrot developers most of the time, we need to make changes that are incremental in nature. This RT proposes an incremental change in Configure.pl's behavior. Currently, Configure.pl prints the following cheery message (from Parrot::Configure::Messages::print_conclusion()) to STDOUT whether all configuration steps have passed or not: # Okay, we're done! You can now use `$make' to build your Parrot. (NOTE: do not use `$make -j n'!) After that, you can use `$make test' to run the test suite. Happy Hacking, The Parrot Team # (Substitute the user's make-equivalent for $make.) At the very least, we should list any configuration steps that have failed and advise the user that 'make' is dubious. Assignment: Revise Configure.pl and its underlying modules to inform the user of configuration steps that have failed. kid51
[perl #45523] [TODO] Have Configure.pl inform user of failed configuration steps
See this non-RT thread on perl.perl6.internals for additional discussion of the issues raised in this ticket: http://tinyurl.com/3y7kgf
Re: Micro-articles on Perl 6 Operators
--- Adriano Ferreira [EMAIL PROTECTED] wrote: [[snips here and at end]] . . . I have one suggestion: you might want to mention the roundrobin function in the article on the zip function since the two are very closely related. Thanks, Joe and Alberto. Even though the roundrobin is very closely related to zip, I think that mentioning it and giving an explanation would add length and detail to the article. I already sacrificed the trick with (@x, *) to extend a list and the @@() for multidimensional context, which are fine but too much for this piece of text. It would certainly add length, but you could minimize the addition of detail by using them as hooks. Maybe embed them in a special section... e.g., hypothetical For the Gearheads We won't bore you with excess details, but for more info on the trick with (@x, *) to extend a list and the @@() for multidimensional context, c.f. . /hypothetical Sorry, not sure where to link off the top of my head, but if anyone thinks it's a good idea I'll look it up on request. Well, it's kind of hard to keep these articles small and interesting. Maybe this stuff can find their way in later articles. Personally, I'm a bit behind on my P6, but I think this is a good idea. I'd be happy to contribute something, and though my time is short like everyone's these days, please feel free to contact me here or offline with requests or suggestions. If you like, I could even try to ghost-write an article or three. I'll go look over the list and see if there's anything I feel competent to work with (but feel free to tell I'm a schmuck and I shouldn't bother if I don't post more. =o) === Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a thumb. Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545433
Re: Micro-articles on Perl 6 Operators
On 9/18/07, Paul Hodges [EMAIL PROTECTED] wrote: --- Adriano Ferreira [EMAIL PROTECTED] wrote: [[snips here and at end]] . . . I have one suggestion: you might want to mention the roundrobin function in the article on the zip function since the two are very closely related. Thanks, Joe and Alberto. Even though the roundrobin is very closely related to zip, I think that mentioning it and giving an explanation would add length and detail to the article. I already sacrificed the trick with (@x, *) to extend a list and the @@() for multidimensional context, which are fine but too much for this piece of text. It would certainly add length, but you could minimize the addition of detail by using them as hooks. Maybe embed them in a special section... e.g., hypothetical For the Gearheads We won't bore you with excess details, but for more info on the trick with (@x, *) to extend a list and the @@() for multidimensional context, c.f. . /hypothetical I am thinking about such hooks and good ways to do that. More on that later. Sorry, not sure where to link off the top of my head, but if anyone thinks it's a good idea I'll look it up on request. Well, it's kind of hard to keep these articles small and interesting. Maybe this stuff can find their way in later articles. Personally, I'm a bit behind on my P6, but I think this is a good idea. I'd be happy to contribute something, and though my time is short like everyone's these days, please feel free to contact me here or offline with requests or suggestions. If you like, I could even try to ghost-write an article or three. I'll go look over the list and see if there's anything I feel competent to work with (but feel free to tell I'm a schmuck and I shouldn't bother if I don't post more. =o) I salute every bit of help. I am trying to organize the production and will hopefully provide more details soon. By now, I think that I can handle suggestions and corrections to the articles. The next one is here: http://ferreira.nfshost.com/perl6/stitching6.html === Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a thumb. Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545433
Re: Micro-articles on Perl 6 Operators
Adriano Ferreira wrote: I salute every bit of help. I am trying to organize the production and will hopefully provide more details soon. By now, I think that I can handle suggestions and corrections to the articles. The next one is here: http://ferreira.nfshost.com/perl6/stitching6.html This one's very nice. One question: what's the ~+ operator you talk about in your discussion of prefix ~ ? I can't find any mention of it in Synopsis 3. Joe Gottman
Re: Micro-articles on Perl 6 Operators
Looks good . . . but how short do we want them?
For the non-Perl audience, I think it might be worth mentioning the
(to us) obvious automatic context manipulations. e.g.,
~ is stitching strings, and will make strings out of its arguments
if it can -- it's not adding, but has the same precedence, so:
$x = 1 ~ 2 + 3; # 15: is 12 + 3, string coerced to number
maybe even add
$y = (1 ~ 2) + 3; # 15: same as above, but explicit
$z = 1 ~ (2 + 3); # 15: 1 ~ 5, numbers coerced to strings
though I think that adds up to a bit too much clutter.
Or have I gone too long without sleep? It looks funny
The point is that we want these articles to play up both the old
perlishness that's retained for those fearful of change, and give a
good feel of what perlishness is all about to those used to C and
Java...or CoBOL and ForTran. We also want shell programmers to see that
the convenience factor of quick scripting is still there, but with
Perl's ramped-up capabilities -- it beats the hell out of ksh and awk,
after all, but isn't really so much harder to learn and use, either at
the low or the high end.
Maybe we should add a Making the easy things easy, and the hard things
possible tagline to all these articles. :)
Also -- is it out of the scope of these to have each perhaps present a
basic problem and a use of the operator to solve it? I think the zip
article does that, and the example helped, but this one seems like a
small but faintly operator-spicy example would help, even if a little
contrived.
sub page_ruler ( uint8 $len = 80 ) { # take int, max 256, default 80
my $ruler = ''; # declares a buffer
my $digit = 0; # starts with 0
$ruler ~= $digit++ % 10 # appends next digit
while length($ruler) $len; # till there's enough
return $ruler; # and returns the string
}
my $r = page_ruler(25); # 0123456789012345678901234
Again, PLEASE double-check my probably goofy syntax.
Paul
--- Adriano Ferreira [EMAIL PROTECTED] wrote:
On 9/18/07, Paul Hodges [EMAIL PROTECTED] wrote:
--- Adriano Ferreira [EMAIL PROTECTED] wrote:
[[snips here and at end]]
. . . I have one suggestion: you might want to mention
the roundrobin function in the article on the zip function
since
the two are very closely related.
Thanks, Joe and Alberto.
Even though the roundrobin is very closely related to zip, I
think
that mentioning it and giving an explanation would add length and
detail to the article. I already sacrificed the trick with (@x,
*) to
extend a list and the @@() for multidimensional context, which
are
fine but too much for this piece of text.
It would certainly add length, but you could minimize the addition
of
detail by using them as hooks. Maybe embed them in a special
section...
e.g.,
hypothetical
For the Gearheads
We won't bore you with excess details, but for more info on the
trick
with (@x, *) to extend a list and the @@() for multidimensional
context, c.f. .
/hypothetical
I am thinking about such hooks and good ways to do that. More on that
later.
Sorry, not sure where to link off the top of my head, but if anyone
thinks it's a good idea I'll look it up on request.
Well, it's kind of hard to keep these articles small and
interesting.
Maybe this stuff can find their way in later articles.
Personally, I'm a bit behind on my P6, but I think this is a good
idea.
I'd be happy to contribute something, and though my time is short
like
everyone's these days, please feel free to contact me here or
offline
with requests or suggestions. If you like, I could even try to
ghost-write an article or three. I'll go look over the list and see
if
there's anything I feel competent to work with (but feel free to
tell
I'm a schmuck and I shouldn't bother if I don't post more. =o)
I salute every bit of help. I am trying to organize the production
and
will hopefully provide more details soon. By now, I think that I can
handle suggestions and corrections to the articles. The next one is
here:
http://ferreira.nfshost.com/perl6/stitching6.html
===
Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a
thumb.
Check out the hottest 2008 models today at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html
Re: Micro-articles on Perl 6 Operators
On Tue, Sep 18, 2007 at 09:46:14PM -0400, Joe Gottman wrote: : Adriano Ferreira wrote: : I salute every bit of help. I am trying to organize the production and : will hopefully provide more details soon. By now, I think that I can : handle suggestions and corrections to the articles. The next one is : here: : : http://ferreira.nfshost.com/perl6/stitching6.html : : : This one's very nice. One question: what's the ~+ operator you : talk about in your discussion of prefix ~ ? I can't find any mention of : it in Synopsis 3. Is no such operator. We have ~, ~|, and ~^ though. Larry
Re: Micro-articles on Perl 6 Operators
On Tue, Sep 18, 2007 at 07:41:54PM -0700, Paul Hodges wrote: : while length($ruler) $len; # till there's enough There is no length function anymore. Larry
