Re: Hyper-slices?
David Christensen wrote: I definitely like the hyper stuff how it is; maybe the answer is to just define an infix:[[]] operator which returns the crosswise slice of a nested list of lists. In any case it could be shunted aside to some package and certainly does not need to be in core. Didn't S09 take care of that w/ the [ ; ; ] syntax? -- Rod Adams
Re: [RFC] some doubtable MMDs?
Larry Wall [EMAIL PROTECTED] wrote: On Sun, Apr 17, 2005 at 09:50:28AM +0200, Leopold Toetsch wrote: : Larry Wall [EMAIL PROTECTED] wrote: : Is there a bitarray lookup by native int? : : Yes. All array lookups support a native int index. Good, good. Speaking of bitarrays (uint1 in the Perl panoply of types), is there any built-in support for arrays of tiny integers like uint2 or uint4? It'd be nice to have uint24 in there too. I can see two ways to do it: a) a general n-bit array Px = new NBitArray, 2 # or 4, 24 or 128, ... which would mean that this is just one type, i.e. no MM dispatch difference between C@a of int2 and C@a of int4. b) implement it as distinct array types. The former is probably slightly slower with the said dispatch problem, the latter uses more resources, more code, bigger type registry, bigger MMD caches and so on. An C@a of uint8 is definitely such a distinct type RSN. c) a mixture of a) and some commonly used sizes for b) Ehem three ways. : A Parrot Integer PMC (32bit for a 32bit sytem), which has a different : type number then a BigInt PMC. For simplicity Perl is probably just going to make a two-way distinction between int/Int, where the latter is assumed to have BigInt properties as necessary. Yep. The distinction between BigInt and Integer PMC is almost invisble to Perl6, except in something like: $i.isa # [Int] $i.__isa# [Integer] or [BigInt] ... We can probably use Parrot Integer PMCs for boxing native ints when we need to do that, but that's hopefully transparent to the user. Should be, yes. Thanks for all the info. Nice to know we're pushing the state of the art in spots. We'll just keep on pushing it till it falls over. Larry Welcome, leo
Re: [perl #35016] [BUG] t/pmc/timer.t
Will Coleda [EMAIL PROTECTED] wrote: t/pmc/timerNOK 7# Looks like you failed 1 tests of 8. Could it be that system load was too high when the test was run, so that it didn't finish in one second? leo
Re: [perl #35018] [PATCH] Recent ASCII changes, Tcl Breakage
Will Coleda [EMAIL PROTECTED] wrote: The recent conversion to mostly defaulting to ascii has broken Tcl (*again*). ./parrot languages/tcl/tcl.pbc languages/tcl/examples/hello.tcl No, I don't think so. $ ./parrot languages/tcl/tcl.pbc languages/tcl/examples/hello.tcl Hello World $ ./parrot -G languages/tcl/tcl.pbc languages/tcl/examples/hello.tcl Hello World $ ./parrot --gc-debug languages/tcl/tcl.pbc languages/tcl/examples/hello.tcl parrot: encodings/fixed_8.c:190: fixed8_set_position: \ Assertion `pos (iter-str)-obj.u._b._buflen' failed. Aborted I've already described the problem, but you might have missed it. So here it is again: In dynclasses/tclparser.pmc:class_init() you are creating strings like Cbs_nl, which are static globals in this file. These strings are not anchored on the stack nor registered with the Parrot DOD registry. All this strings created here vanish after the first DOD run. To fix it please try: - create an FixedStringArray with the size of the amount of strings - stuff all the strings into the array - Cdod_register_pmc() this array HTH, leo
Re: Kwalitee and has_test_*
Michael Graham wrote: If someone were to take over maintenance of your module, or they were to fork it, or they were submitting patches to you, then they would want these tools and tests, right? How would they get them? By asking for them? It is my experience that when someone takes over maintenance of a module it is usually with the blessing of the previous maintainer, so that shouldn't be difficult most of the time. -- David Cantrell
CGI.pm url_encoding problem
Hi!
This is the code:
use CGI;
set_url_encoding('utf-8');
The problem is that use CGI automagically initializes the parameters
*before* I set the encoding of them, so set_url_encoding will run too late.
Any idea?
Bye,
Andras
MMD roundup 1 - current state
Below inline/attached describes what's done until now. leo According to the proposed changes described in Subject: [PROPOSAL] infix MMD operators Subject: Again the infix ops the following is done: 1) Arithmetic infix opcodes add, sub, mul, div, fdiv, mod, cmod, pow are converted to use the new MMD function signature that returns the result PMC. 2) These opcodes aren't emitted as such but are converted like so: add Px, Py, Pz= infix .MMD_ADD, Px, Py, Pz which dispatches to PMC* add([INTERP, SELF], value, dest) 3) The new Cinfix opcodes (currently in experimental.ops) calls Cmmd_dispatch_* as usual. 4) The two argument opcodes forms call now distinct infix MMD functions add Px, Py= infix .MMD_ADD, Px, Py = void i_add([INTERP, SELF], value) Additionally, if result and self are identical in the 3-arg variant the opcode is onverted to the inplace variant: add Px, Px, Pz= i_add(Px, Pz) 5) Overloading of the 3 argument opcodes and the infix opcodes is now separated. We probably have to install fallback functions that call the 3-argument form for a missing inplace variant. Overloaded infix operations now have to return the result PMC. Px = __add(Py, Pz) If the result PMC should be reused, this can be achieved by passing it to the overloaded function: Px = __add(Py, Pz, Px) The inplace functions have an i_ prefix __i_add(Px, Py) (see also include/parrot/vtable.h:Parrot_mmd_func_names[] 6) Python and Tcl dynamic classes are changed to use the inherited functions of Parrot core scalar types where appropriate. leo
MMD roundup 2 - TODO and design items
Below is some stuff, which I'm unsure of how it should be implemented eventually. Input is highly welcome. Thanks, leo TODO items and design issues 1) bitwise or, and, xor We currently have two distinct sets of opcodes and MMD functions for numeric (i.e. integer) and string bitwise functionality. E.g. bor Px, Py# $x +|= $y bors Px, Py, Pz # $x = $y ~| $z It now depends on the Perl6 code generator how the Parrot implementation should behave (or vice versa :) a) just do MMD Px = Px.__as_number()# numeric context $P1 = Py.__as_number() bor Px, $P1 # MM dispatch on Int, Int $P0 = Py.__as_string() # string context $P1 = Pz.__as_string() bor Px, $P0, $P1 # MM dispatch on Str, Str b) use current distinct opcodes bor Px, Py # call get_integer() internally bors Px, Py, Pz # call get_string() internally If a) is true, we would have just one set of bitwise MMD functions. If b) is true, then there is no MMD needed as the functionality is always the same: make numeric/string and do the bitwise operation. This would be better implemented with a vtable method. 2) logical or, and, xor The functionality depends only on the truth value of the operands. That is e.g.: Px = Py or Pz # Px = Py.bool() ? Py : Pz For Perl5 we might need a different implementation that returns the boolean value instead of the value itself. But there is not much to MMD for this operations IMHO, a plain vtable would suffice. 3) logical (unsigned) and arithmetic shifts It's again the question, if there is much multi on the dispatch. The implementation for shl Px, Py, Pz is just something like: Px = Py Pz.get_integer() Folks could of course implement fancy stuff that doesn't resemble a shift operation at all by going full MMD. But it's not much reasonable to allow it IMHO. 4) Missing infix MMD (or vtable) methods - Clsr - unsigned shift right has no PMC equivalent - Crotl, Crotr - rotate opcodes and methods The latter was discussed some time ago. The problem with these operations is probably that there are too many possiblities: rotate how much of the bits and what happens with the other bits. We could design these opcodes like PPCs rlw* opcodes, which are said to be turing complete on their own :) But we probably need just a small subset as e.g. used in runtime/parrot/library/Digest/MD5.imc 5) new opcodes that return a new result: Px = n_add Py, Pz # new Px created These opcodes will be done RSN.
[BUG] cd issue in main Makefile
Hi, I've tracked down a Win32 build problem that I reported on IRC on Friday, but I'm not sure how to fix makefile generation so this doesn't happen. Hopefully someone with more knowledge/time can. :-) In the main makefile we have things like this:- subdirs :: $(NOECHO) cd ext\CGI $(MAKE) $(USEMAKEFILE) $(FIRST_MAKEFILE) all $(PASTHRU) cd .. The last line should actually be:- cd ..\.. Changing this in the generated Makefile itself leads to a successful build. Thanks, Jonathan
Re: MMD roundup 2 - TODO and design items
Leopold Toetsch [EMAIL PROTECTED] wrote: 5) new opcodes that return a new result: Px = n_add Py, Pz # new Px created These opcodes will be done RSN. RSN is now. There is one basic test in t/pmc/integer.t. Overloading is tested in mmd.t. More tests are welcome for other PMCs. Caveat: the n_ variants for the infix opcodes work only for the arithmetic operations: add, sub, mul, div, fdiv, mod, cmod, pow. leo
Re: CGI.pm url_encoding problem
Andras,
Well once we have a proper use, we should be able to set the encoding
at compile time. But until then, I see a few possible options:
- setting the url encoding forces a re-encoding of any parameters
already encoded.
This means extra work if you change the encoding, but it will only
happen once.
- moving the decoding process to be on demand when fetching the params
This would slow do the param() function, but would mean you only
decoded exactly what you needed and nothing more.
Either one is a simple change.
- Stevan
On Apr 18, 2005, at 5:16 AM, BÁRTHÁZI András wrote:
Hi!
This is the code:
use CGI;
set_url_encoding('utf-8');
The problem is that use CGI automagically initializes the parameters
*before* I set the encoding of them, so set_url_encoding will run too
late.
Any idea?
Bye,
Andras
Re: CGI.pm url_encoding problem
Stevan, Well once we have a proper use, we should be able to set the encoding at compile time. But until then, I see a few possible options: I think, it would be nice to find another solution. - setting the url encoding forces a re-encoding of any parameters already encoded. This means extra work if you change the encoding, but it will only happen once. It can't work (or with a big overhead), because POST parameters coming from the STDIN, and it's just readable once. If you would like to do it, then you have to store the whole input, which can be large. - moving the decoding process to be on demand when fetching the params This would slow do the param() function, but would mean you only decoded exactly what you needed and nothing more. It sounds good, and I have another idea. What, if the first param() function call would trigger the whole paramter decoding? It's not an overhead, because you have to do the process if you would like to get a parameter, but an improvement, because if you don't want to query a parameter (you just include the CGI.pm just for to print header(), etc.), then there won't be processing + decoding. Bye, Andras
Re: CGI.pm url_encoding problem
BÁRTHÁZI == BÁRTHÁZI András [EMAIL PROTECTED] writes:
BÁRTHÁZI use CGI;
BÁRTHÁZI set_url_encoding('utf-8');
BÁRTHÁZI The problem is that use CGI automagically initializes the parameters
BÁRTHÁZI *before* I set the encoding of them, so set_url_encoding will run too
BÁRTHÁZI late.
Did I miss the memo where anything outside the list of valid
URI characters needed to be hexified, hence there's no need
for such a URL encoding scheme? Where is this memo?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: patch for t/operators/hyper.t
On Sun, Apr 17, 2005 at 10:11:47AM -0500, David Christensen wrote: Enclosed is a patch for t/operators/hyper.t to test for some corner cases with list extension. Let me know if the unicode are coming through correctly; I am not seeing them as such in my email. Your mailer claims that your message is ISO-8859-1 + + @r = (1,2,3,4) ¬ª+¬´ (1,2); ./perl -Ilib -MEncode -wle '$m = ¬ª+¬´;print$u = Encoddeeemacroman, $m); print Encode::decode (utf8, $u)' »+« »+« What you're actually sending in the body is the utf8 bytes converted in a ISO-8859-1 = MacRoman translation. (I think) Did you cut and paste from (say) TextEdit into Mail? IIRC both TextEdit and carbonised Emacs have an annoying habit of assuming that by default files are in MacRoman. Nicholas Clark
Re: PugsBugs: Weird behavior of shift
On Mon, Apr 18, 2005 at 12:08:36AM -0400, Stevan Little wrote: : These examples: : : pugs -e 'say shift [1, 2, 3].shift' : pugs -e 'say shift([1, 2, 3].shift)' : pugs -e 'say shift([1, 2, 3]).shift' : : do not ever return, but yet does not seem to chew up the CPU either. I don't see how those can be semantically valid, even if they parse. I read them as shifting the return value of a shift, which would be an attempt to shift on a scalar. : Meanwhile, these examples: : : pugs -e 'say pop [1, 2, 3].pop' : pugs -e 'say pop([1, 2, 3].pop)' : pugs -e 'say pop([1, 2, 3]).pop' : : all print '3'. Same problem. 3.pop doesn't mean much. All I can figure is that it's following the list-in-scalar context rule to make [3].pop out of it. Larry
Re: CGI.pm url_encoding problem
Randal,
BÁRTHÁZI use CGI;
BÁRTHÁZI set_url_encoding('utf-8');
BÁRTHÁZI The problem is that use CGI automagically initializes the parameters
BÁRTHÁZI *before* I set the encoding of them, so set_url_encoding will run too
BÁRTHÁZI late.
Did I miss the memo where anything outside the list of valid
URI characters needed to be hexified, hence there's no need
for such a URL encoding scheme? Where is this memo?
Can you write it again with other words? Both Stevan and me are not
understand.
Bye,
Andras
Re: Push and Pop on Infinite lists
On Sun, Apr 17, 2005 at 11:33:45PM -0400, Stevan Little wrote: : I am working on edge cases and error cases for some of the t/builtin/ : tests. : : I know its a silly thing to do, but how should push and pop behave with : (0 .. Inf) lists? : : I read through this thread: : http://www.mail-archive.com/perl6-all@perl.org/msg39891.html : : But I did not see an answer, only various suggestions. : : Currently in Pugs these two examples: : : pugs -e 'my @p = (0 .. Inf); push @p, 10;' : pugs -e 'my @p = (0 .. Inf); pop(@p);' : : will go on forever (as you would expect it to do). Well, running forever could be construed as somewhat antisocial. : Is this the correct behavior? Or should it return Inf or somesuch? Or : even maybe error? An infinite list consists of two parts, the part we've generated, and the part we haven't yet generated. The first part acts just like an ordinary Perl 5 array and can be shifted, unshifted, or subscripted. If your shift or your subscript asks for something beyond the end of the generated section, then you have to look at your generator section to derive more generated values. However, push and pop are special cases, since they're not changing the front of the array, but they're not subscripting operations either, exactly. The generator section can presumably contain one or more generators. Those generators can each be set up to produce either finite or infinite lists. So it is meaningful to push 10 on the end--it adds a generator that returns 10..10 to the list of generators, after which @p[-1] could reasonably return 10, as could pop. Likewise you could push another 0..Inf. If the code is smart enough to return 10 if the final generator is 10..10, then it's probably also smart enough to return Inf for 0..Inf. The difference is that if you pop 10..10, it decrements it to 10..9, then notices it's a null generator and removes it. If you pop 0..Inf, it pops the final Inf, and decrements the 0..Inf to, er, 0..Inf. I think that's a reasonable set of semantics, and perhaps even vaguely useful. On the other hand, till someone implements it, it would be okay to fail(Not implemented). BTW, A6 claims the method to get from an array object to its underlying Lazy generator list is the .specs method. As far as I know that's still the case. Larry
Re: CGI.pm url_encoding problem
Hi, Randal L. Schwartz wrote: BÁRTHÁZI == BÁRTHÁZI András [EMAIL PROTECTED] writes: Did I miss the memo where anything outside the list of valid URI characters needed to be hexified, hence there's no need for such a URL encoding scheme? Where is this memo? BÁRTHÁZI Can you write it again with other words? Both Stevan and me are not BÁRTHÁZI understand. URLs are only 7 bit ASCII, according to the RFCs. Did I miss a new RFC where non-7-bit URLs are permitted? If so, please point to that. You are right, in URLs just 7 bit ASCII is allowed. But you can store any character in an URL, if you encode it with URL encoding. For example UTF-8 á is coded as %C3%A1. RFC 1738 [1], part 2.2 is writing about it (just about iso-8859-1 encoding). Or you can read a short tutorial about it at Blooberry[2]. Don't tell me, that you never heard this before. :) Anyway, it's not just about URL encoding (the URL and the GET parameters), but POST parameters working the same way. Bye, Andras [1] http://www.rfc-editor.org/rfc/rfc1738.txt [2] http://www.blooberry.com/indexdot/html/topics/urlencoding.htm
Re: CGI.pm url_encoding problem
Hi, I believe that the standard for URL's calls for always encoding in utf-8 but that all non-ascii bytes (bytes with the high bit set) are to be further encoded using %xx hex notation. So the URL is always transmitted as an ascii string, but is easily converted into a utf-8 string simply by converting the %xx codes back into binary bytes. Thus firewalls and proxies need only deal with ascii. You're right, except one thing: when the standard was created, there were no UTF-8 encoding, so it can't be the default. I think that the standard is not talking about how the non-ASCII characters are encoded (iso-8859-* or utf-8 or else). And I know and I'm sure in it, that browsers are sending back non-ASCII characters by the same encoding as the page of the form was coded - so no UTF-8 is the default, there is no default. Bye, Andras
Re: CGI.pm url_encoding problem
BÁRTHÁZI == BÁRTHÁZI András [EMAIL PROTECTED] writes: Did I miss the memo where anything outside the list of valid URI characters needed to be hexified, hence there's no need for such a URL encoding scheme? Where is this memo? BÁRTHÁZI Can you write it again with other words? Both Stevan and me are not BÁRTHÁZI understand. URLs are only 7 bit ASCII, according to the RFCs. Did I miss a new RFC where non-7-bit URLs are permitted? If so, please point to that. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: CGI.pm url_encoding problem
BÁRTHÁZI András wrote:
Randal,
BÁRTHÁZI use CGI;
BÁRTHÁZI set_url_encoding('utf-8');
BÁRTHÁZI The problem is that use CGI automagically initializes the
parameters
BÁRTHÁZI *before* I set the encoding of them, so set_url_encoding
will run too
BÁRTHÁZI late.
Did I miss the memo where anything outside the list of valid
URI characters needed to be hexified, hence there's no need
for such a URL encoding scheme? Where is this memo?
Can you write it again with other words? Both Stevan and me are not
understand.
I believe that the standard for URL's calls for always encoding in utf-8
but that all non-ascii bytes (bytes with the high bit set) are to be
further encoded using %xx hex notation. So the URL is always
transmitted as an ascii string, but is easily converted into a utf-8
string simply by converting the %xx codes back into binary bytes. Thus
firewalls and proxies need only deal with ascii.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: Hyper operator corner case?
Roger Hale wrote: One set of cases that doesn't seem to have come up in discussion: (1, 3, 2) - (83, 84, 81, 80, 85) Should this give (-82, -81, -79, -80, -85) From an arithmetic point of view it should be exactly that. The implementation might need to morph the code though, see below. as by hallucinating $neutral - $x == $x? This latter $neutral in fact doesn't exist among ordinary numbers, and I would call it algebraically unnatural: for all (other) $n, $n - ($a + $b) == ($n - $a) - $b or, as you increase $a by $b, $n - $a decreases by $b (a sort of contravariance), but $neutral - ($a + $b) == $a + $b == ($neutral - $a) + $b ! This violates algebraic relations I would prefer to rely on, both in my own reasoning and that of the compiler and other program-handling programs. Me too! The thing is that the field of the real numbers is build on the operators + and * which are associative and commutative. The neutral elements are 0 and 1 respectively. The non-associative operators - and / are defined in terms of the inverse elements. Thus $a - $b == $a + (-$b) and $a / $b == $a * (1/$b) if $b != 0. We could also bring in $b**-1 as another way to find the multiplicative inverse. But that just pulls in yet another operator and the question which axioms apply to it and how it is hyperated. For user-defined numerical types---that is ones that provide +, *, -, /, **, etc---I would hope that these axioms hold. Actually I hope that there is a set of roles that define the standard numerics and enforce sanity as far as that is possible via the class composition mechanics. So coming back to your example, operator - would call - on the RHS and call + with the result. But I've no idea to which extent operator is a special runtime operator versus a term re-writing at compile time. -- TSa (Thomas Sandla)
Re: [RFC] .local, .syn, etc.
William Coleda [EMAIL PROTECTED] wrote: Macros support labels, defined using B.local, that are local to a given macro expansion. The syntax looks something like this: .macro SpinForever (Count) .local $LOOP: dec .COUNT# .local $LOOP defines a local label. branch .$LOOP # Jump to said label. .endm Yep. As a first step, I'd redefine this to be C.label: .macro SpinForever (Count) .label $LOOP: dec .COUNT# .label $LOOP defines a local label. branch .$LOOP # Jump to said label. .endm Wouldn't break too much existing code, probably and, well, if it does, we are at version 0.1.2 and not 1.0. Comments? leo
[FYI] enhanced backtraces
Hi, the new backtrace code is in. If a parrot program aborts due to an error, a backtrace is shown. Examples: Null PMC access in invoke() current instr.: 'd' pc 149 (t/op/debuginfo_4.imc:24) called from Sub 'c' pc 116 (t/op/debuginfo_4.imc:18) called from Sub 'b' pc 85 (t/op/debuginfo_4.imc:13) called from Sub 'a' pc 54 (t/op/debuginfo_4.imc:8) called from Sub 'main' pc 23 (t/op/debuginfo_4.imc:3) Null PMC access in invoke() current instr.: 'rec' pc 111 (t/op/debuginfo_8.imc:12) called from Sub 'rec' pc 71 (t/op/debuginfo_8.imc:8) ... call repeated 90 times called from Sub 'main' pc 24 (t/op/debuginfo_8.imc:2) maximum recursion depth exceeded current instr.: 'main' pc 21 (t/op/debuginfo_7.imc:2) called from Sub 'main' pc 21 (t/op/debuginfo_7.imc:2) ... call repeated 999 times Lexical 'nosuchlex' not found current instr.: 'Test2 :: foo' pc 35 (t/op/debuginfo_6.imc:10) called from Sub 'Test2 :: main' pc 25 (t/op/debuginfo_6.imc:5) If you use debug 1, a backtrace is shown even for exceptions cought with an exception handler. jens PS: filenames are still wrong for included files, because only one filename is stored per bytecode segment (AFAIK). Cf. src/sub.c:615ff
Re: Kwalitee and has_test_*
On 17 Apr 2005, at 11:09, Tony Bowden wrote: On Sun, Apr 17, 2005 at 08:24:01AM +, Smylers wrote: Negative quality for anybody who includes a literal tab character anywhere in the distro's source! Negative quality for anyone whose files appear to have been edited in emacs! Ow! Coffee snorted down nose. Ouch. Adrian
Module and package version numbering
My apologies if this is the wrong place to ask, but it seems like the least-worst option of all the perlish lists I'm on :-) I'm not sure if I'm using version numbers properly. For example, I recently released a package Number-Phone-1.3004 to the CPAN. That number comes because it contains the third significant change to the code, and the fourth significant change in the accompanying data for that release of the code. Inside that package are the following modules: Number::Phone - version 1.2 Number::Phone::UK - version 1.3 Number::Phone::Country - version 0.5 Number::Phone::UK::Data - no version, this is where the .0004 comes from though. It has no version number because the entire file is generated from a *really* dumb script The version numbers for the three modules which have 'em are unchanged since the previous 1.3003 release. The imminent 1.3005 release, however, will bump Number::Phone::Country's version up a notch as I fiddle with the data embedded in it. So I have two questions: 1) Am I correct to seperate the package version (1.3004) from the versions of the several modules contained therein - and if not, where should the package version number come from? and 2) Am I breaking anything? -- David Cantrell
Re: Kwalitee and has_test_*
On 17 Apr 2005, at 13:47, David A. Golden wrote: [snip] 2) A metric to estimate the quality of a distribution for authors to compare their work against a subjective standard in the hopes that authors strive to improve their Kwalitee scores. In this model, faking Kwalitee is irrelevant, because even if some authors fake it, others will improve improve quality (as measured by Kwalitee) for real, thus making Kwalitee useful as a quality improvement tool. Actually, in #2, fakers can provide extra competitive pressure, as module authors who take Kwalitee seriously perceive a higher standard that they should be striving for. I think most of the Kwalitee debate has been around confusion between whether #1 or #2 is the goal, plus what the subjective standard should be. If #2 is the primary goal then one option might be to have a standard way of popping the information into the META.yml file? If we're assuming honesty on the module authors part... Adrian
rx/abc$/
On Sat, Apr 16, 2005 at 12:10:48PM -0700, Larry Wall wrote: I think I have to clarify what I mean by that last phrase. Trailing delimiters are hidden inside any token that has already been started, but not at the start of a token (where token is taken to be fairly restrictive). Therefore these are errors: qq. $foo.bar() . qq: @foo::bar[] : However qq/ foobar( $a / $b ) / is just fine, since (...) is looking for its own termination. Consider this: rx/abc$/ qq/abc$/ After roie's refactoring, both now breaks, whilst in Perl 5, only the latter break -- qr/abc$/ is just fine. Is it something we need to special-case for rx? Thanks, /Autrijus/ pgp1Rk0h2RDVs.pgp Description: PGP signature
Re: rx/abc$/
On Tue, Apr 19, 2005 at 01:31:12AM +0800, Autrijus Tang wrote:
: On Sat, Apr 16, 2005 at 12:10:48PM -0700, Larry Wall wrote:
: I think I have to clarify what I mean by that last phrase. Trailing
: delimiters are hidden inside any token that has already been started,
: but not at the start of a token (where token is taken to be fairly
: restrictive). Therefore these are errors:
:
: qq. $foo.bar() .
: qq: @foo::bar[] :
:
: However
:
: qq/ foobar( $a / $b ) /
:
: is just fine, since (...) is looking for its own termination.
:
: Consider this:
:
: rx/abc$/
: qq/abc$/
:
: After roie's refactoring, both now breaks, whilst in Perl 5, only
: the latter break -- qr/abc$/ is just fine. Is it something we need
: to special-case for rx?
Certainly. rx// does not do any kind of interpolation any more. It is
a language of its own, and $ is just a token in that language. On the
other hand, like Perl 5, that language does have variables in addition
to $, so we still have to distinguish whether the character after the $
indicates a variable. Perl 5's rule was that $ meant end-of-whatever
if it was followed by ), | or the end of the interpolated string.
(Or by # or whitespace in /x mode.) Otherwise it's a variable.
Since we're parsing left-to-right, we can't do exactly the same, but
I suspect we can check after the $ for ), ], |, #, whitespace, or the
terminator, which rules out direct use of $/ inside /.../. That's not
a great hardship, since we have the $1 and $foo shortcuts for
backrefs, and anything fancier probably wants to be in {...} anyway.
As for qq/abc$/, I think it's okay for that to notice that you're trying
to interpolate a variable that has the same name as the delimiter, and
blow up immediately. While we could let people interpolate such
variables by default, it's probably better to stop and make people
clarify what the mean in that case. There aren't that many puncuational
variables any more. Certainly we don't have $' and $ anymore, which
would be the usual ambiguous cases for normal quotes.
And yes, this is pretty much the opposite of what I said about
@foo.bar.baz[]
But in either case we're just trying to figure out what the user expects.
Or doesn't expect, in the case of qq/abc$/.
Larry
Re: Module and package version numbering
On Mon, Apr 18, 2005 at 05:03:42PM +0100, David Cantrell wrote: 1) Am I correct to seperate the package version (1.3004) from the versions of the several modules contained therein - and if not, where should the package version number come from? and There is no correct here. As long as each .pm file with a public interface has a version number and that number increases every time its changed you're fine. If you want to sync them... well Andreas is currently working out how to best do that and not break the indexer. 2) Am I breaking anything? Nope. Though I'd slap some sort of version on the Number::Phone::UK::Data. If you generate it from the Makefile.PL use the distribution number. If its generated somewhere else that can't easily get at the dist number use an ISO date (20040418) or read it from the META.yml.
Re: Module and package version numbering
On 18 Apr 2005, at 17:03, David Cantrell wrote: [snip] Number::Phone::UK::Data - no version, this is where the .0004 comes from though. It has no version number because the entire file is generated from a *really* dumb script [snip] I agree with Schwern that there is no correct :-) However, if it were me, I would generate a version number along with the module (seeded from the version number of the generating script.) Personally I prefer separate version numbers per-module, but some people don't. I've yet to read anything /really/ convincing for either side - so I'd do whatever you're comfortable with myself. Cheers, Adrian
alarm() and later()
Two things popped up while implementing a demo version of alarm() today. 1. In perl5 and in most underlying libraries, alarm() has 1 second granularity (and a possible 1 second error on top of that). Can we have the alarm builtin not assume the worst, and take a Num instead of an Int, so that on some systems at least we get higher resolution sleeps? 2. Since signals are so global and sometimes we want something else, how about a variation on the traditional u?alarm theme, in which you can pass an optional closure to alarm() that will get called back instead of having a SIGALRM raised? multi sub alarm(: Num ?$timeout = $CALLER::_, Num ?$interval, Code ?$callback) returns Int This should be reentrant and allow multiple uses. The Int return is an id on the future event so you can cancel it. (Which needs speccing. Possibly this could return a reference to some object instead of an id?) If the alarm builtin is getting too overloaded, I propose the closure version be named later. -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: Module and package version numbering
Michael G Schwern wrote in perl.qa : On Mon, Apr 18, 2005 at 05:03:42PM +0100, David Cantrell wrote: 1) Am I correct to seperate the package version (1.3004) from the A small correction -- 1.3004 would be the distribution version, (not mentioned as $...::VERSION in any package).
Re: [RFC] .local, .syn, etc.
On Mon, 2005-04-18 at 14:44 +0200, Leopold Toetsch wrote: Yep. As a first step, I'd redefine this to be C.label: .macro SpinForever (Count) .label $LOOP: dec .COUNT# .label $LOOP defines a local label. branch .$LOOP # Jump to said label. .endm Can you only use .label inside of macros? (I don't know how useful it is outside of macros, but it's a question.) -- c
Re: Module and package version numbering
On Apr 18, 2005, at 12:50 PM, Adrian Howard wrote: Personally I prefer separate version numbers per-module, but some people don't. I've yet to read anything /really/ convincing for either side - so I'd do whatever you're comfortable with myself. I used to do it per-module, but then I kept forgetting, between releases, which modules I had updated since the last one, or which ones I'd changed and needed to update again. So I switched to making all of my modules have the same version number, and I just use a script to update them all at once. http://www.justatheory.com/computers/programming/perl/ increment_version.html Regards, David
Re: Module and package version numbering
On Mon, Apr 18, 2005 at 02:00:23PM -0700, David Wheeler wrote: On Apr 18, 2005, at 12:50 PM, Adrian Howard wrote: Personally I prefer separate version numbers per-module, but some people don't. I've yet to read anything /really/ convincing for either side - so I'd do whatever you're comfortable with myself. I used to do it per-module, but then I kept forgetting, between releases, which modules I had updated since the last one, or which ones I'd changed and needed to update again. Ditto. And the old CVS per-file revision number trick doesn't work with modern versin control systems. Subversion revision numbers are project wide. Using SVK means revision numbers are different for everybody's checkout. darcs doesn't even have revision numbers. What I do now is run an svk diff -rrevision of last release -s | grep .pm before release to see what .pm files have changed since the last release and increment by hand. Its clunky and time consuming for large dists such as MakeMaker. What I'm moving towards is what SVK does. It has an SVK::Version module which simply defines $SVK::VERSION. Then in other modules you can write: use SVK::Version; our $VERSION = $SVK::VERSION; That way it will be picked up by most $VERSION scanners. The problem is the PAUSE/CPAN indexer will NOT run code. It just uses a regex. So it will not figure out the version above. The solution for this looks like duplicating the per .pm version information in the META.yml file which is what I think Module::Build already does via provides. I don't know what the state of the PAUSE indexer is in reading the META.yml.
Re: [RFC] .local, .syn, etc.
At 04:52 PM 4/18/2005, chromatic wrote: On Mon, 2005-04-18 at 14:44 +0200, Leopold Toetsch wrote: Yep. As a first step, I'd redefine this to be C.label: .macro SpinForever (Count) .label $LOOP: dec .COUNT# .label $LOOP defines a local label. branch .$LOOP # Jump to said label. .endm Can you only use .label inside of macros? (I don't know how useful it is outside of macros, but it's a question.) Currently yes (assuming you made .local = .label) because the macros are handled and expanded in the lexer only before the parser gets hold of it, so IF my memory serves, there is no token in the parser for anything inside a macro. I tried to yank macros out once and there was much screaming and wailing. :) -Melvin
Re: Context of hash slices; quotation adverbs
: But when you start interpolating, you get into a big mess:
: h\qq[$interpolated] = want(); # ???
: h$foo = want(); # ???
I think that, as with functions called in unknown context, we should
just force the RHS here to list context, and rely on the RHS to add
extra context as necessary if they really mean scalar. If something
really is always producing a scalar value, it doesn't matter if it's
called in list context.
That makes sense, but that would make
%num_of_linesfile = @file
not DWIM... of course that would translate into
%num_of_linesfile = scalar @file
so maybe that's OK.
Any bit of expression by default evaluates at ordinary run time, but can
be forced to evaluate earlier by surrounding context.
What you're saying is that
BEGIN { $c=1 }
$c=0;
q:c($c)/.../
interpolates, because the $c in line three is evaluated after the $c in line
one but before the $c in line two, right? If you don't obfuscate on purpose
(like I did), that makes sense.
--
-Roie
v2sw6+7CPhw5ln5pr4/6$ck2ma8+9u7/8LSw2l6Fi2e2+8t4TNDSb8/4Aen4+7g5Za22p7/8
[ http://www.hackerkey.com ]
Re: Context of hash slices; quotation adverbs
On Mon, Apr 18, 2005 at 11:23:34PM +0300, Roie Marianer wrote:
: : But when you start interpolating, you get into a big mess:
: : h\qq[$interpolated] = want(); # ???
: : h$foo = want(); # ???
:
: I think that, as with functions called in unknown context, we should
: just force the RHS here to list context, and rely on the RHS to add
: extra context as necessary if they really mean scalar. If something
: really is always producing a scalar value, it doesn't matter if it's
: called in list context.
:
: That makes sense, but that would make
: %num_of_linesfile = @file
: not DWIM... of course that would translate into
: %num_of_linesfile = scalar @file
: so maybe that's OK.
Eh, no, I wouldn't call that one unknown context. I'd call it scalar.
: Any bit of expression by default evaluates at ordinary run time, but can
: be forced to evaluate earlier by surrounding context.
: What you're saying is that
: BEGIN { $c=1 }
: $c=0;
: q:c($c)/.../
: interpolates, because the $c in line three is evaluated after the $c in line
: one but before the $c in line two, right? If you don't obfuscate on purpose
: (like I did), that makes sense.
Yes. The main problem is that you have to make sure the my $c isn't
hidden in an inner block. This wouldn't work:
BEGIN { my $c=1 }
$c=0;
q:c($c)/.../
Note that
my $c = BEGIN { 1 };
doesn't quite work either. However, we'll probably end up
my $c will begin { $_ = 1 };
or some such. Compile-time binding
my $c ::= 1;
probably also works, or maybe you have to write:
my $c ::= \1;
Larry
Re: rx/abc$/
LW = Larry Wall AT = Autrijus Tang LW I think I have to clarify what I mean by that last phrase. Trailing LW delimiters are hidden inside any token that has already been started, LW but not at the start of a token (where token is taken to be fairly LW restrictive). AT Consider this: AT AT rx/abc$/ AT qq/abc$/ AT After roie's refactoring, both now breaks, whilst in Perl 5, only Actually, it wasn't due to my refactoring. It was because I tried to implement the rule above, which meant getting rid of the special case (which was present in qqInterpolatorVar) of a variable whose name _ended_ with the delimiter. AT the latter break -- qr/abc$/ is just fine. Is it something we need AT to special-case for rx? LW Certainly. rx// does not do any kind of interpolation any more. It is LW a language of its own, and $ is just a token in that language. But rx:P5// should act like qr//, shouldn't it? LW I suspect we can check after the $ for ), ], |, #, whitespace, or the LW terminator, which rules out direct use of $/ inside /.../. I'll add a flag for that in rx:P5. In any case, I suspect that the code to parse rx which is not :P5 will be completely different from what we have now (rx:P5 is basically a not-so-glorified qq:b(0)) LW As for qq/abc$/, I think it's okay for that to notice that you're trying LW to interpolate a variable that has the same name as the delimiter, and LW blow up immediately. Makes sense, but what exactly do you mean by blow up? -- -Roie v2sw6+7CPhw5ln5pr4/6$ck2ma8+9u7/8LSw2l6Fi2e2+8t4TNDSb8/4Aen4+7g5Za22p7/8 [ http://www.hackerkey.com ]
Re: Context of hash slices; quotation adverbs
On Mon, Apr 18, 2005 at 11:23:34PM +0300, Roie Marianer wrote: That makes sense, but that would make %num_of_linesfile = @file not DWIM... of course that would translate into %num_of_linesfile = scalar @file so maybe that's OK. In order to promote proper syntactical thinking, note that this is now spelled: %num_of_linesfile = @file.elems; because the Perl 5 way would put a reference to @file in the hash. Scalar context always makes references now, from what I understand.
junctions as indicies
I'm looking in S09, and reading about junctions. It seems to me that
if we have a junction $j which we use to index into an array or a hash,
it should DWIM and return a junction of the corresponding values.
@ar=[1..10];
%hash=(a=1,b=4,c=7);
$j=1|2|3;
$k=a|c;
$u = @ar[$j]; # 2|3|4
$v = %hash{$k}; # 1|7
Does this make sense to others?
David
Re: junctions as indicies
David Christensen writes:
I'm looking in S09, and reading about junctions. It seems to me that
if we have a junction $j which we use to index into an array or a hash,
it should DWIM and return a junction of the corresponding values.
@ar=[1..10];
%hash=(a=1,b=4,c=7);
$j=1|2|3;
$k=a|c;
$u = @ar[$j]; # 2|3|4
$v = %hash{$k}; # 1|7
Does this make sense to others?
Well, if we replaced @ar[$j] with, say, @ar.get($j), what you're
proposing happens automatically. So I think that it's the right thing
to do.
Luke
Re: Context of hash slices; quotation adverbs
On Mon, Apr 18, 2005 at 06:44:55PM -0400, Kurt Hutchinson wrote: : On Mon, Apr 18, 2005 at 11:23:34PM +0300, Roie Marianer wrote: : That makes sense, but that would make : %num_of_linesfile = @file : not DWIM... of course that would translate into : %num_of_linesfile = scalar @file : so maybe that's OK. : : In order to promote proper syntactical thinking, note that this is now : spelled: : : %num_of_linesfile = @file.elems; Or more succinctly: %num_of_linesfile = [EMAIL PROTECTED]; : because the Perl 5 way would put a reference to @file in the hash. : Scalar context always makes references now, from what I understand. Interestingly, a stored reference would track the current number of lines rather than taking a snapshot. But you should definitely think of it as storing a reference rather than the number of lines, because the ref will certainly behave differently in string context. Larry
junction adverb: :except
Hypothetical here: If we want to calculate a set of values for a junction which map nicely to a range with a few outliers, would it be possibly to have a qualifier :except which allows us to make exceptions to our given range? I.e., (Ignore for the moment the inefficiency of the choice of this particular algorithm.) my $year = 1900; # or whatever my $leap_year = $year % 400 == any(0..400 :by(4) :except(100,200,300)); Here except would be a modifier on the range being generated for any(). I could also see except being used to strip choices from junctions: my $j = 1|2|3|4; my $k=$j :except(2); # 1|3|4 Let me know if I'm totally abusing junctions here... David
Re: junction adverb: :except
David Christensen writes: Hypothetical here: If we want to calculate a set of values for a junction which map nicely to a range with a few outliers, would it be possibly to have a qualifier :except which allows us to make exceptions to our given range? I.e., (Ignore for the moment the inefficiency of the choice of this particular algorithm.) my $year = 1900; # or whatever my $leap_year = $year % 400 == any(0..400 :by(4) :except(100,200,300)); Here except would be a modifier on the range being generated for any(). I could also see except being used to strip choices from junctions: my $j = 1|2|3|4; my $k=$j :except(2); # 1|3|4 Let me know if I'm totally abusing junctions here... No, you're abusing adverbs. You can't give an adverb to a variable (because adverbs don't modify actually nouns :-). I don't know if we've destroyed Damian's comparator semantic, but if not, then you can just do: my $k = ($j != 2); But if that no longer happens, it's best a method on the junction. Except every time we add a method to junction, we destroy the ability to automatically thread that method over the junction. I've proposed several solutions to this over the years (applying to autodelegating iterators as well). I still think it's something that that needs to be solved. Luke
Re: rx/abc$/
On Tue, Apr 19, 2005 at 12:02:45AM +0300, Roie Marianer wrote: : But rx:P5// should act like qr//, shouldn't it? Yes. : LW I suspect we can check after the $ for ), ], |, #, whitespace, or the : LW terminator, which rules out direct use of $/ inside /.../. : I'll add a flag for that in rx:P5. In any case, I suspect that the code to : parse rx which is not :P5 will be completely different from what we have now : (rx:P5 is basically a not-so-glorified qq:b(0)) More or less. For a number of the backslashes it doesn't matter whether they get interpolated in the first pass or the second, though you need to be really careful with things that regexen treat differently, and especially you mustn't lose track of your backwhacked backwhacks. It gets pretty messy, which is one of the reasons Perl 6 does it differently. : LW As for qq/abc$/, I think it's okay for that to notice that you're trying : LW to interpolate a variable that has the same name as the delimiter, and : LW blow up immediately. : Makes sense, but what exactly do you mean by blow up? I suppose that depends on whether you're programming a cruise missile or not. For most purposes, an appropriate parse failure message would suffice. Larry
Re: [perl #35018] [PATCH] Recent ASCII changes, Tcl Breakage
Leopold Toetsch wrote: Will Coleda [EMAIL PROTECTED] wrote: The recent conversion to mostly defaulting to ascii has broken Tcl (*again*). ./parrot languages/tcl/tcl.pbc languages/tcl/examples/hello.tcl No, I don't think so. $ ./parrot languages/tcl/tcl.pbc languages/tcl/examples/hello.tcl Hello World $ ./parrot -G languages/tcl/tcl.pbc languages/tcl/examples/hello.tcl Hello World $ ./parrot --gc-debug languages/tcl/tcl.pbc languages/tcl/examples/hello.tcl parrot: encodings/fixed_8.c:190: fixed8_set_position: \ Assertion `pos (iter-str)-obj.u._b._buflen' failed. Aborted I've already described the problem, but you might have missed it. So here it is again: In dynclasses/tclparser.pmc:class_init() you are creating strings like Cbs_nl, which are static globals in this file. These strings are not anchored on the stack nor registered with the Parrot DOD registry. All this strings created here vanish after the first DOD run. To fix it please try: - create an FixedStringArray with the size of the amount of strings - stuff all the strings into the array - Cdod_register_pmc() this array HTH, leo Two things: 1) Leo's suggestion fixes most of the issues I had with svn-current. 2) Bah! This code worked in my sandbox for quite some time. Adding --gc-debug to the tcl test suite to avoid introducing more gc-related bugs in the future.
Re: [FYI] enhanced backtraces
Cool. Can I co-opt this so I can get tcl-like backtraces when running tcl code? If so, how? =-) Jens Rieks wrote: Hi, the new backtrace code is in. If a parrot program aborts due to an error, a backtrace is shown. Examples: Null PMC access in invoke() current instr.: 'd' pc 149 (t/op/debuginfo_4.imc:24) called from Sub 'c' pc 116 (t/op/debuginfo_4.imc:18) called from Sub 'b' pc 85 (t/op/debuginfo_4.imc:13) called from Sub 'a' pc 54 (t/op/debuginfo_4.imc:8) called from Sub 'main' pc 23 (t/op/debuginfo_4.imc:3) Null PMC access in invoke() current instr.: 'rec' pc 111 (t/op/debuginfo_8.imc:12) called from Sub 'rec' pc 71 (t/op/debuginfo_8.imc:8) ... call repeated 90 times called from Sub 'main' pc 24 (t/op/debuginfo_8.imc:2) maximum recursion depth exceeded current instr.: 'main' pc 21 (t/op/debuginfo_7.imc:2) called from Sub 'main' pc 21 (t/op/debuginfo_7.imc:2) ... call repeated 999 times Lexical 'nosuchlex' not found current instr.: 'Test2 :: foo' pc 35 (t/op/debuginfo_6.imc:10) called from Sub 'Test2 :: main' pc 25 (t/op/debuginfo_6.imc:5) If you use debug 1, a backtrace is shown even for exceptions cought with an exception handler. jens PS: filenames are still wrong for included files, because only one filename is stored per bytecode segment (AFAIK). Cf. src/sub.c:615ff
Re: TestSimple/More/Builder in JavaScript
On Apr 17, 2005, at 5:05 PM, Michael G Schwern wrote: http://dynapi.sourceforge.net/dynapi/ Perhaps, But then the mail lists are simply hosted by SourceForge. Ick. Sorry, the point was more drag these guys into this as they have obviously thought about the problem of includes and library paths. Barbie on use.perl seems to know something about it. Okay. Does someone want to take the lead on this? I'm full up right now, I'm afraid... Regards, David
statement modifiers for setting variables
The following is legal perl: print $a $b $c if ($a,$b,$c)=(1,2,3); This prints 1 2 3, but the definitions obviously aren't scoped to the modified statement. And a Cmy in the modifier is a bit too late. Any reason to [not] add a Cwhere statement modifier which restricts the scope of the declarations? Sure its redundant, but so are all statement modifiers. Sometimes its good to factor things out and express them later, rather than earlier. It lets us focus on the important things first: print $a $b $c where ($a,$b,$c)=(1,2,3); (in this case, we could use printf to to the factoring, but that's not a general solution).
Re: TestSimple/More/Builder in JavaScript
FYI Begin forwarded message: From: Marshall Roch [EMAIL PROTECTED] Date: April 18, 2005 5:44:26 PM PDT To: Michael G Schwern [EMAIL PROTECTED] Cc: jesse [EMAIL PROTECTED], David Wheeler [EMAIL PROTECTED], Adam Kennedy [EMAIL PROTECTED], Sean M.Burke [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: TestSimple/More/Builder in JavaScript Michael G Schwern wrote: But getting some sort of hosting could be great if nothing else than to get this discussion off of perl-qa and use.perl and onto a proper mailing list. http://groups-beta.google.com/group/jsan Google Groups seems to be the quickest way to get fast, reliable mailing list hosting. However, if someone else has a server, that'd be fine by me as well. -- Marshall
State of the Tcl [r7870]
Ok. I was somewhat surprised to hear about the Tcl breakages recently. I expect that Tcl is going to work on all of Parrot's supported OSen. Here are some recent improvements. o fixed the most gratuitous GC errors that Leo diagnosed. o committed a patch so that PGE is built by default (per chip). This simplifies the Tcl build process. o add --gc-error to the default test build for Tcl. That leaves the following test failures: Failed Test Stat Wstat Total Fail Failed List of Failed --- cmd_expr.t 1 256401 2.50% 2 cmd_global.t 3 768 33 100.00% 1-3 cmd_join.t 6 1536 76 85.71% 2-7 cmd_linsert.t 4 1024 54 80.00% 1 3-5 cmd_llength.t 5 1280 55 100.00% 1-5 cmd_proc.t 3 768 53 60.00% 1-3 cmd_rename.t 2 512 22 100.00% 1-2 cmd_return.t 1 256 11 100.00% 1 cmd_string.t 1 256351 2.86% 27 tcl_command_subst.t1 256 81 12.50% 8 The [expr] failure is a result of recent MMD changes, I think. Many of the other failures seem to be more GC issues. Help tracking these down is appreciated. If anyone is seeing any test failures for Tcl that are NOT on this list, please open an RT ticket. (see: languages/tcl/README) Regards.
Re: regular expressions and parrot
On Sun, Apr 17, 2005 at 04:33:57PM +0200, BÁRTHÁZI András wrote: Just a short question I'm interested in: where will be, and how will work (I just asking for a general description about it) the regular expression / rules part of Parrot? On Sun, 2005-04-17 at 09:38 -0500, Patrick R. Michaud wrote: The regular expression / rules part of Parrot is called PGE, for Perl/Parrot Grammar Engine, and it's currently in the compilers/pge directory. The intent is that rules will be another compiler within Parrot (i.e., it can standalone somewhat outside of Perl). At the risk of advertising vaporware, I'd like to grab this opportunity to provide an update on my own work. Those of you with good memory may recall that I announced a preliminary Parrot Syntax Engine on this list back in the beginning of January. In essence, this gave the API and a basic implementation of a bottom-up GLR parser for dynamic grammars. As such, it has some bearing on the rules part of Parrot, although the interface is more generally intended for domain-specific languages where the language syntax is allowed to change at runtime. To make a short story short, Leo went directly for my throat by asking me about performance, which I had to admit was less than satisfactory. Since then, I've spent quite some time modifying the DParser layer to allow incremental grammar updates. The time needed to add a 340th rule to the grammar is now about 1/1000 of the original result, or 1 ms. Leo also asked the following, which I never really answered: On Fri, 2005-01-07 at 11:10, Leopold Toetsch wrote: - How fast is DParser compared to bison/flex? - What about memory usage compared to bison/flex? I have not tested the memory consumption for a fixed grammar, but the total memory used in building the 339-rule Python grammar was roughly 3.5 MB according to valgrind/massif. That's about 4 KB per LR state, which should not cause a big problem in the foreseeable future. Note that a lot of this memory can be released if the grammar is frozen! In order to test the parsing speed, I extracted the C grammar of gcc and constructed a yacc/lex and a PSE version of the parser. The idea was to run both parsers on files from the Linux kernel to get a real-world test of correctness and speed. As expected, yacc turned out to be faster :-) Unfortunately, the difference was almost two orders of magnitude, with DParser taking more than half a second to parse a 2000-line file. I am not completely happy with this result, so that is my current focus... From time to time, life interferes with progress, and I am not at this point ready to give an expected release date for version 0.2, mostly because the mysterious factor 3.14 has been creeping into all estimates I've attempted so far. I just wanted to give the information I have, in case someone wondered what happened to this little project :-| /Henrik
RT Cleanup
There are some potentially crufty tickets out there. Can the relevant experts verify if these can be closed before we get the next release out? Win32: (10 tickets) http://rt.perl.org/rt3/NoAuth/parrot/List.html?Field=PlatformValue=mswin32 http://rt.perl.org/rt3/NoAuth/parrot/List.html?Field=PlatformValue=Win32 Cygwin: (3 tickets) http://rt.perl.org/rt3/NoAuth/parrot/List.html?Field=PlatformValue=cygwin Linux: (one sparc, one fedora) http://rt.perl.org/rt3/NoAuth/parrot/List.html?Field=PlatformValue=Linux Freebsd: (2 tickets) http://rt.perl.org/rt3/NoAuth/parrot/List.html?Field=PlatformValue=freebsd Mac OS X: (1 ticket) http://rt.perl.org/rt3/Ticket/Display.html?id=24177 ICU: (3 tickets) http://rt.perl.org/rt3/Ticket/Display.html?id=28405 http://rt.perl.org/rt3/Ticket/Display.html?id=28473 https://rt.perl.org/rt3//Ticket/Display.html?id=30847
[perl #31148] [TODO] Documentation - out of date
This is a uselessly generic TODO that was cribbed from a file in the repository. It's covered by other, more specific documentation todos. If you know of documentation that needs to be added, please open a specific ticket.
Re: junctions as indicies
--- David Christensen [EMAIL PROTECTED] wrote:
I'm looking in S09, and reading about junctions. It seems to me
that if we have a junction $j which we use to index into an array
or a hash, it should DWIM and return a junction of the corresponding
values.
@ar=[1..10];
%hash=(a=1,b=4,c=7);
$j=1|2|3;
$k=a|c;
$u = @ar[$j]; # 2|3|4
$v = %hash{$k}; # 1|7
Does this make sense to others?
David
Maybe, but I don't like returning junctures in those cases unless you
*explicitly* ask for it. I'd rather the default be the arbitrary lists
returned, or whatever fits the context. How about
@ar=[a..z];
%hash=(a=1,b=4,c=7);
$j=1|2|3;
$k=a|c;
@u = @ar[$j];# (b..d)
%u = @ar[$j].kv; # (1='b',2='c',3='d')
$u = @ar[$j];# \(b..d)
$ju = juncture @ar[$j]; # 'b'|'c'|'d'
@v = %hash{$k}; # (1,7)
%v = %hash{$k}.kv; # (a=1,c=7)
$v = %hash{$k}; # \(1,7)
$jv = juncture %hash{$k}; # 1|7
Am I way off base here?
__
Do you Yahoo!?
Plan great trips with Yahoo! Travel: Now over 17,000 guides!
http://travel.yahoo.com/p-travelguide
Re: junctions as indicies
Paul Hodges writes: Maybe, but I don't like returning junctures in those cases unless you *explicitly* ask for it. I'd rather the default be the arbitrary lists returned, or whatever fits the context. How about @ar=[a..z]; %hash=(a=1,b=4,c=7); $j=1|2|3; @j = (1,2,3); $k=a|c; @k = a c; @u = @ar[$j];# (b..d) @u = @[EMAIL PROTECTED]; etc. Perl can indeed slice using ordinary lists. Another problem with using junctions for this is that they're unordered, and you're expecting ordered results back. Luke
Re: junctions as indicies
Paul Hodges wrote:
--- David Christensen [EMAIL PROTECTED] wrote:
I'm looking in S09, and reading about junctions. It seems to me
that if we have a junction $j which we use to index into an array
or a hash, it should DWIM and return a junction of the corresponding
values.
@ar=[1..10];
%hash=(a=1,b=4,c=7);
$j=1|2|3;
$k=a|c;
$u = @ar[$j]; # 2|3|4
$v = %hash{$k}; # 1|7
Does this make sense to others?
David
Maybe, but I don't like returning junctures in those cases unless you
*explicitly* ask for it. I'd rather the default be the arbitrary lists
returned, or whatever fits the context. How about
@ar=[a..z];
%hash=(a=1,b=4,c=7);
$j=1|2|3;
$k=a|c;
@u = @ar[$j];# (b..d)
%u = @ar[$j].kv; # (1='b',2='c',3='d')
$u = @ar[$j];# \(b..d)
$ju = juncture @ar[$j]; # 'b'|'c'|'d'
@v = %hash{$k}; # (1,7)
%v = %hash{$k}.kv; # (a=1,c=7)
$v = %hash{$k}; # \(1,7)
$jv = juncture %hash{$k}; # 1|7
Am I way off base here?
What would you propose
@v[all(any(4,5),one(1,2,3),none(7,8,9))]
return?
-- Rod Adams
