Re: [PATCH] Add .trim method
On Mon, Jan 12, 2009 at 9:01 AM, Ovid publiustemp-perl6langua...@yahoo.comwrote: - Original Message I could optionally make the following work: $string.trim(:leading0); $string.trim(:trailing0); Alternatively, those could be ltrim() and rtrim(). If you need to dynamically determine what you're going to trim, you'd couldn't just set variables to do it, though. You'd have to figure out which methods to call. Or all could be allowed and $string.trim(:leading0) could all $string.rtrim internally. If I were going to have ltrim() and rtrim(), I'd implement them in terms of trim() rather than the other way around. -Scott -- Jonathan Scott Duff perlpi...@gmail.com
Re: Perl 6 Microgrants. Now accepting proposals.
On 3/22/07, Tim Bunce [EMAIL PROTECTED] wrote: I'd like to suggest an idea for *someone else* to submit a proposal for: Heh, hoping for someone with tuits to bite, eh? :-) As part of the work on DBI2 I want to create a Perl API that closely matches the JDBC API. I need a tool that can parse the java .h files that that define the JDBC API, e.g., http://gcc.gnu.org/viewcvs/trunk/libjava/java/sql/Statement.h?revision=120621view=markup and generate roughly equivalent Perl 6 (roles etc). I notice that this file (and all of the others I looked at) say at the top: // DO NOT EDIT THIS FILE - it is machine generated -*- c++ -*- So, perhaps it's not the .h files we should be parsing, but whatever source files were used to generate them. Though, of course, some C++-to-Perl6 tool would be a good thing too. :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: FYI compiling PIR function calls
On Wed, Sep 27, 2006 at 11:38:10AM +0200, Leopold Toetsch wrote: Am Mittwoch, 27. September 2006 09:12 schrieb Allison Randal: The basic problem is inconsistency. For hand-written code the current PIR method call syntactic sugar is mildly annoying. (It'd be nice to safely get rid of the quotes around the method name.) Not easily: obj.'foo'() # a methodname constant .local string bar bar = get_some_meth() # or bar = 'get_some_meth'() obj.bar()# a method variable But: obj.foo()# still a methodname constant # unless there's a variable 'foo' To be on the safe side, method (and function) names *should* be quoted. I don't think that this is inconsistent. Is there a reason that you would want to conflate method names and variables used as a method name? If not, why not change the syntax slightly so that method names in a variable are uniquely identified? Here's a suggestion: obj.foo() # a methodname constant .local string bar bar = get_some_meth() obj.$bar() # a method variable The same could be used for ordinary subroutines: .local string mysub mysub = foo $mysub()# calls the foo subroutine -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: End the Hollerith Tyranny? (linelength.t)
On Mon, Aug 21, 2006 at 06:49:20PM -0400, Mr. Shawn H. Corey wrote: Chip Salzenberg wrote: On Mon, Aug 21, 2006 at 06:05:08PM -0400, Mr. Shawn H. Corey wrote: Don't forget that some programs, like mailers, wrap at 80 characters. I don't know of any mailer that is hard-coded at any given column width. Do you? Thunderbird, Evolution, just to name two. OK, they're not hard-coded; you can change the option (if you can find it). What I'm saying is that we still have the legacy of 80 columns and unless necessary, all ASCII files should fit within it. And yes, I realize that code seldom gets mailed but there may be other programs that have this artificial limit in them and if you're lazy (like me), you couldn't be bother changing their factory settings. In other words, don't exceed 80 columns unless you have a reason for it. The thing about mail programs is that even if you set you're limit to something large like 2048, the person who received your message may still have a limit of 80, which would make any message you send hard to read. Just keep in mind that we're stuck with the 80 column limit the same way we are stuck with the QWERTY keyboard. It's not the best there is, it's only what most expect. That's an interesting vantage point. Restated, there are still old systems out there, let's conform to them. I could be suffering a failure of imagination, but I don't see why we would do that. We'd just be perpetuating the tyranny rather than ending it. It seems to me that *if* the line length is ever a problem, we have or can create tools to deal with it (uuencode anyone?). Also by not keeping to 80 columns, we can weed out the modern tools that still have such limitations and encourage the authors to fix them. And if *that* turns out to be too big of an endeavour, we can always go back to 80 columns, but I'm guessing whatever problems there are will be small and localized. just my humble opinion, -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Pm's YAPC::NA talk online
I'm no expert, but I'll hazard some answers:
On Wed, Jun 28, 2006 at 04:26:45AM -0500, João Cruz Morais wrote:
I'm new to Parrot but reading from your slides if I understood correctly:
- PGE parses input according to a grammar and produces a derivation tree.
- TGE transforms the parse tree into an abstract syntax tree.
With that said I have some questions (i'm sorry if they were answered
already somewhere):
- Whats the point of using PGE+TGE over the good old LEX+YACC besides the
better regexps?
I think lex+yacc is approximately equivalent to PGE alone. TGE is
something different.
You can't really say besides the better regexps because that's part of
the point--having better tools with which to transform one language into
another. PGE lets you annotate how the source language fits together
(what's a token and what order the tokens may come in, etc.) while TGE
let's you take those annotations and turn them into alternate
(presumably more useful) representations.
- Can I use PGE skipping TGE?
I don't see why not. If you look at the bottom of grammar_rules.pg,
you'll see this:
token syntax_error { ?PGE::Util::die: Syntax error }
where PGE::Util::die is a PIR subroutine. IIUC, everywhere you want
some action to be performed (like code generation for instance) you
could put a PIR subroutine in the grammar just as above and, of
course, write the subroutine to do the action.
- PAST seems just fine as a concept but isn't it useless if I can target
directly to POST with minor fuss?
It may be uesless in that specific case, but I think it's highly
useful in the general case where the impedence mismatch between the
language you are parsing and the language you are generating may be
large (like say, between a very complex and rich language like Perl6 and
a much simpler language like PIR ;). TGE lets you factor out the
complexity of your source language in incremental steps (as small or as
large steps as you want).
Good luck for today's presentation :)
Yeah, good luck Pm :)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: HLL Debug Segments
On Mon, Nov 14, 2005 at 11:07:55PM -, Jonathan Worthington wrote: Leopold Toetsch [EMAIL PROTECTED] wrote: On Nov 14, 2005, at 0:02, Jonathan Worthington wrote: * I'm thinking of a PIR syntax along the lines of this:- The discussion goes forth and back, like all other discussion we already had WRT syntax, months and years ago. What syntax we parse now (and then do nothing with) isn't flexible enough. Aside from fixing that, the syntax doesn't really matter *that* much, since it's going to be generated by compilers anyway. I just read through the thread and here's my initial impressions. This information that get's squirrelled away seems to be lexical in nature as far as the PIR goes, i.e., #line 10 ... code that implements line 10 of the HLL ... #line 11 ... code that implements line 11 of the HLL ... #line 12 ... etc ... Also, it seems that mostly this is analogous to a hash. In the above example, line is a key, 10 is a value. So, in this respect using #name value Seems just fine :-) The interpretation of the property (just reusing the name from subversion) names is up to whoever generates/consumes them, so they could be anything #language perl #version 6 #file hello.p6 #line 1 #source say hello world\n; #chapter 4 #verse 7 #scoundrel Bill Sikes ... PIR that implements the HLL ... etc. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
[PATCH] split on strings
Here's a patch to implement the split opcode such that it splits on
strings rather than regular expressions. I've also added a test to
t/op/string.t
Files affected:
M ops/string.ops
M t/op/string.t
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
=== ops/string.ops
==
--- ops/string.ops (revision 63)
+++ ops/string.ops (local)
@@ -479,8 +479,10 @@
=item Bsplit(out PMC, in STR, in STR)
-Create a new Array PMC $1 by splitting the string $3 with
-regexp $2. Currently implemented only for the empty string $2.
+Create a new Array PMC $1 by splitting the string $3 into pieces
+delimited by the string $2. If $2 does not appear in $3, then return $3
+as the sole element of the Array PMC. Will return empty strings for
+delimiters at the beginning and end of $3
=cut
@@ -507,22 +509,43 @@
}
op split(out PMC, in STR, in STR) :base_core {
-PMC *res = $1 = pmc_new(interpreter, enum_class_Array);
-STRING *r = $2;
-STRING *s = $3;
-int slen = string_length(interpreter, s);
-int i;
+PMC *res = $1 = pmc_new(interpreter, enum_class_ResizableStringArray);
+STRING *delim = $2;
+STRING *str = $3;
+int dlen = string_length(interpreter, delim);
+int slen = string_length(interpreter, str);
+int ps,pe;
if (!slen)
goto NEXT();
-if (string_length(interpreter, r))
- internal_exception(1, Unimplemented split by regex);
-VTABLE_set_integer_native(interpreter, res, slen);
-for (i = 0; i slen; ++i) {
- STRING *p = string_substr(interpreter, s, i, 1, NULL, 0);
- /* TODO first set empty string, then replace */
- VTABLE_set_string_keyed_int(interpreter, res, i, p);
+
+if (dlen == 0) {
+int i;
+VTABLE_set_integer_native(interpreter, res, slen);
+for (i = 0; i slen; ++i) {
+ STRING *p = string_substr(interpreter, str, i, 1, NULL, 0);
+ VTABLE_set_string_keyed_int(interpreter, res, i, p);
+}
+ goto NEXT();
}
+
+ps = 0;
+pe = string_str_index(interpreter,str,delim,0);
+if (pe 0) {
+ VTABLE_push_string(interpreter,res,str);
+ goto NEXT();
+}
+while (ps = slen) {
+int pl = pe - ps;
+ STRING *tstr = string_substr(interpreter, str, ps, pl, NULL, 0);
+ VTABLE_push_string(interpreter,res,tstr);
+ ps = pe + string_length(interpreter,delim);
+ if (ps slen)
+ break;
+pe = string_str_index(interpreter,str,delim,ps);
+ if (pe 0)
+ pe = slen;
+}
goto NEXT();
}
=== t/op/string.t
==
--- t/op/string.t (revision 63)
+++ t/op/string.t (local)
@@ -16,7 +16,7 @@
=cut
-use Parrot::Test tests = 156;
+use Parrot::Test tests = 157;
use Test::More;
output_is( 'CODE', OUTPUT, set_s_s|sc );
@@ -2555,7 +2555,7 @@
return $rt;
}
-output_is( 'CODE', OUTPUT, split);
+output_is( 'CODE', 'OUTPUT', split on empty string);
_main:
split P1, ,
set I1, P1
@@ -2577,8 +2577,32 @@
ab
OUTPUT
-output_is( 'CODE', OUTPUT, join);
+output_is( 'CODE', 'OUTPUT', split on non-empty string);
_main:
+split P0, a, afooabara
+set I0, P0
+print I0
+print \n
+set I1, 0
+loop:
+set S0, P0[I1]
+print S0
+print \n
+inc I1
+sub I2, I1, I0
+if I2, loop
+end
+CODE
+5
+
+foo
+b
+r
+
+OUTPUT
+
+output_is( 'CODE', 'OUTPUT', join);
+_main:
new P0, .PerlArray
join S0, --, P0
print S0
runtime/parrot/library
Is there some reason that runtime/parrot/library isn't in the list of search paths for both include_paths and dynext_paths? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
getopt.macro
I'm fiddling around with parrot and created a getopt macro (inspired by the arg processing in Leon Brocard's uniq.pasm :-). This is my first attempt at something semi-useful in parrot. Anyway, here it is and looking for comments, -Scott 88 8 8- # getopt.macro # # Scans P0 for options. The options to scan for are given in str and # those options found are placed in P15 (as a PerlHash). Unknown options # are silently ignored. The scan stops at the first argument that # doesn't start with a '-' or when the special argument -- is seen (or # when we've run out of command line). # # Options mayn't be grouped, i.e., -a -b -c may NOT be written as -abc # # Like the standard getopt routine, a colon after a letter in the option # string signifies that the option takes an argument. # # When using the same option multiple times, only the last is # saved in the PerlHash # # Typical usage might look something like this: # # .include 'getopt.macro' # .getopt(ab:) # exists I1, P15[a] # exists I2, P15[b] # # print a = # print I1 # print \n # print b = # set S0, # unless I2, NOB # set S0, P15[b] #NOB: # print S0 # print \n # # set I0, I15 # first non-option arg #LOOP: # output the non-option args # set S0, P0[I0] # print S0 # print # inc I0 # le I0, I2, LOOP # # print \n # end # # # Note: Both P15 and I15 are clobbered by this routine. P15 will be a #PerlHash containing the options and their values and I15 will #contain the index of the first non-option arguement on the #comamnd line. .macro getopt (str) save S0 # Current command line arg save S1 # option char save S2 # scratch string save I1 # length of command line save I2 # scratch int set I1, P0 # get length of command line lt I1, 2, .$noargs # There aren't any args new P15, .PerlHash # create a place to store the options set I15, 0 .local $l0: # loop over command line inc I15 eq I15, I1, .$argsdone # no more args set S0, P0[I15] # S0 is the command line arg eq S0, --, .$argsdone # -- signifies end of options substr S1, S0, 0, 1 # get first char ne S1, -, .$argsdone # no -, then we're done substr S1, S0, 1, 1 # S1 holds the option char index I2, .str, S1 lt I2, 0, .$l0 # option not found, ignore set P15[S1], # rare case inc I2 substr S2, .str, I2, 1 # need a parameter? ne S2, :, .$l0# nope, get next option length I2, S0 # get the length of the arg sub I2, I2, 2 # subtract 2 for the - and option char eq I2, 0, .$getnextarg # no more chars in arg? substr S0, S0, 2, I2 set P15[S1], S0 branch .$l0 .local $getnextarg: # grab the next arg from the cmd line inc I15 set S0, P0[I15] set P15[S1], S0 branch .$l0 .local $argsdone: set I1, P15 eq I1, 0, .$done# no, we didn't really find any ne S0, --, .$done .local $noargs: inc I15 .local $done: # put things back restore I2 restore I1 restore S2 restore S1 restore S0 .endm
Re: parrot rx engine
On Wed, Jan 30, 2002 at 08:13:55AM -0800, Ashley Winters wrote: I think that's exactly what you should be doing! Neither parrot nor the rx engine should try to be a full compiler. The rx engine definitely should have opcodes in the virtual machine, but those opcodes should simply contain state-machine/backtracking info, not godly unicode info. So, basically, you just want to push Unicode onto the language that sits atop parrot. If that language were Perl, for instance, you'd advocate that everywhere the user had written /a/ be replaced (by the Perl compiler) with the big long given you described? Have I got that right? Excerpt from Apocalypse 2: Perl 6 programs are notionally written in Unicode, and assume Unicode semantics by default even when they happen to be processing other character sets behind the scenes. Note that when we say that Perl is written in Unicode, we're speaking of an abstract character set, not any particular encoding. (The typical program will likely be written in UTF-8 in the West, and in some 16-bit character set in the East.) It seems to me that in order for Perl 6 programs to be written in Unicode, Parrot needs to grok unicode (everwhere, including regular expressions). -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Comm. Unity - (was Re: CPP Namespace pollution)
On Fri, Jan 25, 2002 at 01:56:20PM -0500, Bryan C. Warnock wrote: [ rather interesting ramble about people, Perl, and personality ] Someone needs to add this stuff to http://dev.perl.org/perl6/people or perhaps start a Perl6-personality guidebook :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Moving string - number conversions to string libs
On Thu, Dec 06, 2001 at 02:17:31AM +, Alex Gough wrote: Also, for string - integer conversion I think we ought to be scanning for a float then turning the result into an integer (as 1234.56e2 is one). Does scanning for a float include 1234,56e2 or any other locale specific representation? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Parrot FAQ
On Wed, Dec 05, 2001 at 11:02:34AM -0500, Dan Sugalski wrote: Q: How do Dan and Simon have enough time to work on this? A: We don't--why do you think this is taking so long? A related FAQable question ... Q: Is it possible to buy Dan's and Simon's time to work on nothing but Parrot? If so, how? And for my own personal edification, has anyone tried to work a deal (through YAS perhaps) for Parrot like Damian Conway has for Perl? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Parrot FAQ
On Tue, Dec 04, 2001 at 04:11:58PM -0500, Dan Sugalski wrote: Seriously, there are real answers to a whole lot of design questions. Ask 'em and I'll get FAQable answers to 'em once and for all. Could the FAQ be made a wiki so that others can play too? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: parrot-nightly
On Mon, Sep 17, 2001 at 03:43:28PM +0100, Simon Cozens wrote:
Or you could install Digest::MD5. :) I'm not terribly amused by the dependency
on it, but I guess that for release versions of Parrot, the opcode header
and other autogenerated things will be generated before shipping; much like we
do with embed.pl in Perl 5.
Greetings. I'm new to whole parrot experience, so pardon my ignorance.
I was just looking at those files that use Digest::MD5 and the only one
that appears to really depend on it is Parrot/Opcode.pm. assemble.pm,
disassemble.pl, and build_interp_starter.pl all use it but none call
any of the subroutines defined therein.
Parrot/Opcode.pm only uses Digest::MD5 for fingerprinting the opcode
file which could be done without Digest::MD5 IMHO. For instance,
using unpack() to checksum the file.
I've attached a diff if anyone is interested.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
? diff.jsd
? diff.duff
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.24
diff -u -r1.24 assemble.pl
--- assemble.pl 2001/09/16 18:25:27 1.24
+++ assemble.pl 2001/09/17 15:36:27
@@ -5,7 +5,6 @@
# Brian Wheeler ([EMAIL PROTECTED])
use strict;
-use Digest::MD5 qw(md5_hex);
use Getopt::Long;
use Parrot::Opcode;
Index: build_interp_starter.pl
===
RCS file: /home/perlcvs/parrot/build_interp_starter.pl,v
retrieving revision 1.6
diff -u -r1.6 build_interp_starter.pl
--- build_interp_starter.pl 2001/09/15 16:05:40 1.6
+++ build_interp_starter.pl 2001/09/17 15:36:27
@@ -1,6 +1,5 @@
# !/usr/bin/perl -w
use strict;
-use Digest::MD5 qw(md5_hex);
use Parrot::Opcode;
open INTERP, interp_guts.h or die Can't open interp_guts.h, $!/$^E;
Index: disassemble.pl
===
RCS file: /home/perlcvs/parrot/disassemble.pl,v
retrieving revision 1.7
diff -u -r1.7 disassemble.pl
--- disassemble.pl 2001/09/14 18:06:10 1.7
+++ disassemble.pl 2001/09/17 15:36:27
@@ -5,7 +5,6 @@
# Turn a parrot bytecode file into text
use strict;
-use Digest::MD5 qw(md5_hex);
use Parrot::Opcode;
my %unpack_type = (i = 'l',
Index: Parrot/Opcode.pm
===
RCS file: /home/perlcvs/parrot/Parrot/Opcode.pm,v
retrieving revision 1.4
diff -u -r1.4 Opcode.pm
--- Parrot/Opcode.pm2001/09/16 22:05:22 1.4
+++ Parrot/Opcode.pm2001/09/17 15:36:27
@@ -2,7 +2,6 @@
use strict;
use Symbol;
-use Digest::MD5 qw(md5_hex);
my %opcode;
my $fingerprint;
@@ -13,10 +12,9 @@
my $fh = gensym;
open $fh, $file or die $file: $!\n;
-my $md5 = Digest::MD5-new;
my $count = 1;
while ($fh) {
- $md5-add($_);
+ $fingerprint += unpack('%32C*', $_);
s/#.*//;
s/^\s+//;
@@ -41,8 +39,6 @@
my $num_n = () = grep {/n/} @params;
$opcode{$name}{RETURN_OFFSET} = 1 + $num_i + $num_n * 2;
}
-
-$fingerprint = $md5-hexdigest;
}
sub read_ops {
Re: RFC 361 (v1) Simplifying split()
On Sat, Oct 07, 2000 at 10:38:21AM +0200, Bart Lateur wrote: On Fri, 6 Oct 2000 23:26:44 -0500, Jonathan Scott Duff wrote: @foo = split; # BECOMES @foo = split; pop @foo until $foo[-1]; That doesn't fly. What if that last field is "0"? @foo = split ' '; # BECOMES @foo = split /\s+/; shift @foo; What if there is no leading whitespace? You shift out a perfectly valid field. shift @foo if @foo and length $foo[0]; Yeah, you're right ... musta been my lack of sleep at the time. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
On Tue, Aug 15, 2000 at 08:44:48AM -0700, Nathan Wiger wrote: There seems to be a groundswell against this idea, which is fine by me (heck, just because it's my idea doesn't me it's a GOOD one!). Here's a different proposal, same vein: "Standardize all Perl platforms on the UNIX epoch". Sound better? Yep. Or more generally "Standardize Perl on all platforms to one common time epoch" and reccommend the Unix epoch since it's so widespread. :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
On Mon, Aug 14, 2000 at 08:40:32PM -0700, Nathan Wiger wrote: No, but currently Perl IS forcing Windows, Mac, and BeOS users to understand what the UNIX epoch is. So you're proposing that rather than give one platform (unix) an advantage, we force all platforms to use some other completely arbitrary date/time format? There's some other advantages to MJD beyond system-independence. Namely, it allows easy date arithmetic, meaning complex objects are not required to modify dates even down to the nanosecond level. Sorry, but date arithmetic is easy now: $then = time(); # time passes $now = time(); $difference = $now - $then; # How long was that? And as to modifying dates "down to the nanosecond", you're proposing that these MJD dates be floating point numbers. Why not ust make time() return a float and *bam* you've got 1 second precision as far as your floats or doubles can carry you. But make the core language easily accessible to everyone. Funny, that's the exact argument I would use *against* mjdate(). -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC Archive
On Wed, Aug 02, 2000 at 10:09:04PM -0600, Nathan Torkington wrote: I'm about to push the button that will send my private set of RFCs off to the archive and mail them to perl6-announce. Fingers crossed. Hooray!! If I've forgotten your RFC, please send it to [EMAIL PROTECTED] In the future, if you want to submit an RFC mail it to [EMAIL PROTECTED] only. http://tmtowtdi.perl.org/rfc/meta/ says that you should send your RFCs to [EMAIL PROTECTED] rather than [EMAIL PROTECTED] Thanks for getting the RFC repository up an running Nat. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: what will be in Perl6 ?
On Wed, Aug 02, 2000 at 10:57:27AM -0700, Larry Wall wrote: raptor writes: : http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html That's a good summary of what we've been thinking. Here's another article that talks about a lot of the things we *should* be thinking. In fact, it's possible this article should be required reading for anyone who aspires to be a Perl designer. http://windows.oreilly.com/news/hejlsberg_0800.html In reading this I noticed that documentation was listed as a first class language construct and that got me thinking about python's docstrings. It would be neat to have something similar in perl. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
