Re: OO benches
On Apr 16, 2004, at 9:29 AM, Leopold Toetsch wrote: With all current optimizations[1] I now have these timings: $ ./bench -b=^oo[234f] Numbers are relative to the first one. (lower is better) p-j-Oc perl-th perlpython ruby oo2 100%182%152%90% 132% oo3 100%276%256%333%383% oo4 100%137%128%171%292% oofib 100%303%261%157%161% Looks cool! BTW, I'm failing a bunch of tests now (Mac OS X); not sure if it's related: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/gc.t 1 256131 7.69% 11 t/pmc/dumper.t 13 332813 13 100.00% 1-13 t/pmc/object-meths.t1 256191 5.26% 9 t/pmc/objects.t 7 1792377 18.92% 23-26 28 35-36 The gc test is failing with: t/op/gc.NOK 11# Failed test (t/op/gc.t at line 219) # got: 'get_pmc_keyed_str() not implemented in class 'RetContinuation'' # expected: 'hello # hello # ' # '(cd . ./parrot -b --gc-debug /tmp/gc_11.pasm)' failed with exit code 2 and all of the dumper ones look like double-frees: t/pmc/dumperNOK 7# Failed test (t/pmc/dumper.t at line 359) # got: '*** malloc[9416]: Deallocation of a pointer not malloced: 0x200ee30; This could be a double free(), or free() called with the middle of an allocated block I'll poke a bit and see if I can figure out what's going on. - constant strings e.g. BUILD get a precomputed hash value from c2str.pl This isn't checked in yet, right? (Didn't see c2str.pl anywhere.) - use of _S(BUILD) and _S(CONSTRUCT) in objects.c Mac OS X doesn't like the _S()--it seems it may already be defined to something. How about something clearer (and less likely to conflict) instead, like STRING_LITERAL()? JEff
Re: OO benches
Aaron Sherman [EMAIL PROTECTED] wrote: On Fri, 2004-04-16 at 18:18, Leopold Toetsch wrote: Sorry, I gave the wrong impression. I meant it looks suspiciously like Python is doing a lazy construction on those objects, not that there is anything wrong with the benchmark. No, I don't think that this is happening. Parrot's slightly slower object instantiation is due to register preserving mainly. The __init code is run from inside the new PObj, IClass opcode. As its not known that a method call is happening here, we can't use register preserving operations that only save needed registers--we have to save all registers. These two memcpys are the most heavy part of the operation. Lazy construction is perhaps something Parrot should think about too, I can't imagine that lazy construction could be of any value. You have to construct it finally. Sum up the two parts. And 90% (or ~100 with gcc 3.3.3 on a Pentium) of Python's performance isn't that bad the more that Python AFAIK is constructing kind of a hash and we have a full fledged object. leo
Re: [perl #28868] [PATCH] signedness tweak for string.c:
Jarkko Hietaniemi [EMAIL PROTECTED] wrote: The attached patch lazily changes both offs and d to unsigned, which seems to fine by the Tru64 cc. Thanks, applied. leo
c2str.pl
Here is the updated version with hashvalue calculation. Please test it on different platforms: - $ perl c2str.pl src/objects.c src/objects.str - enable #include objects.str near the top of the file - $ make see also Constant strings - again from yesterday. Thanks, leo c2str.pl Description: Perl program
Re: OO benches
Jeff Clites [EMAIL PROTECTED] wrote: On Apr 16, 2004, at 9:29 AM, Leopold Toetsch wrote: $ ./bench -b=^oo[234f] Looks cool! Yep. BTW, I'm failing a bunch of tests now (Mac OS X); not sure if it's related: Strange. valgrind doesn't indicate any problem with these tests. I'll poke a bit and see if I can figure out what's going on. Yes please. - constant strings e.g. BUILD get a precomputed hash value from c2str.pl This isn't checked in yet, right? (Didn't see c2str.pl anywhere.) It was attached to yesterdays message Constant strings - again. But I'll resend it with my recent changes WRT hashvalue precalculation. - use of _S(BUILD) and _S(CONSTRUCT) in objects.c Mac OS X doesn't like the _S()--it seems it may already be defined to something. How about something clearer (and less likely to conflict) instead, like STRING_LITERAL()? We can undef it before using. STRING_LITERAL is more typing and doesn't assure uniqueness - so rather not. Maybe PSC() - Parrot String Constant. JEff leo
Re: OO benches
On Apr 16, 2004, at 11:19 PM, Jeff Clites wrote: BTW, I'm failing a bunch of tests now (Mac OS X); not sure if it's related: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/gc.t 1 256131 7.69% 11 t/pmc/dumper.t 13 332813 13 100.00% 1-13 t/pmc/object-meths.t1 256191 5.26% 9 t/pmc/objects.t 7 1792377 18.92% 23-26 28 35-36 And of those, only these 2 fail if run without --gc-debug, _or_ if configured with --optimize (seems like an odd correlation): Failed TestStat Wstat Total Fail Failed List of Failed --- t/op/gc.t 1 256131 7.69% 11 t/pmc/dumper.t1 256131 7.69% 12 JEff
Re: OO benches
Jeff Clites [EMAIL PROTECTED] wrote: BTW, I'm failing a bunch of tests now (Mac OS X); not sure if it's related: t/op/gc.NOK 11# Failed test (t/op/gc.t at line 219) # got: 'get_pmc_keyed_str() not implemented in class 'RetContinuation'' Have that now too - recompiled with ARENA_DOD_FLAGS turned off. The property hash got freed during DOD. I'm still searching why. leo
Re: OO benches
Jeff Clites [EMAIL PROTECTED] wrote: BTW, I'm failing a bunch of tests now (Mac OS X); not sure if it's related: Fixed. It was caused by the faster PMC creation code I've put in earlier in the week, if ARENA_DOD_FLAGS is off (e.g. due to missing memalign). Thanks for reporting, leo
Re: ICU data file location issues
On Apr-14, Jeff Clites wrote:
For Unix platforms at least, you should be able to do this:
executablePath = isAbsolute($0) ? dirname($0) : cwd().dirname($0)
Nope.
sub executablePath {
return dirname($0) if isAbsolute($0);
return cwd().dirname($0) if hasSlash($0);
foreach dir in $PATH {
return $dir if -x $dir/$0;
}
return bastard process;
}
which is why on Linux I give up on portability and say:
return readlink(/proc/self/exe);
(ok, to match that'd need to be dirname(readlink(...)))
[perl #28898] [PATCH] signedness police part 2: string_primitives.c
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #28898]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=28898
cc: Warning: src/string_primitives.c, line 149: In this statement, the
referenced type of the pointer value offset is unsigned int, which
is not compatible with int because they differ by signed/unsigned
attribute. (ptrmismatch1)
return u_unescapeAt(cb, offset, input_length, string);
^
--
Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special
biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
--- src/string_primitives.c.dist2004-04-17 12:35:50.0 +0300
+++ src/string_primitives.c 2004-04-17 12:44:53.0 +0300
@@ -146,7 +146,7 @@
string_unescape_one(Parrot_unescape_cb cb, Parrot_UInt4 *offset,
Parrot_UInt4 input_length, void *string)
{
-return u_unescapeAt(cb, offset, input_length, string);
+return u_unescapeAt(cb, (int32_t*) offset, input_length, string);
}
/*
[perl #28899] [PATCH] de-consting: objects.c
# New Ticket Created by Jarkko Hietaniemi # Please include the string: [perl #28899] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=28899 cc: Warning: src/objects.c, line 485: In this statement, the referenced type of the pointer value prop_str is const, but the referenced type of the target of this assignment is not. (notconstqual) (Hash*) PMC_struct_val(props), prop_str); ---^ -- Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen --- src/objects.c.dist 2004-04-17 12:34:29.0 +0300 +++ src/objects.c 2004-04-17 12:39:07.0 +0300 @@ -482,7 +482,7 @@ if ( !(props = PMC_metadata(class))) return NULL; b = hash_get_bucket(interpreter, -(Hash*) PMC_struct_val(props), prop_str); +(Hash*) PMC_struct_val(props), (STRING*) prop_str); if (!b) return NULL; meth = PMC_str_val((PMC*) b-value);
Re: OO benches
Leopold Toetsch [EMAIL PROTECTED] writes: Aaron Sherman [EMAIL PROTECTED] wrote: On Fri, 2004-04-16 at 18:18, Leopold Toetsch wrote: Sorry, I gave the wrong impression. I meant it looks suspiciously like Python is doing a lazy construction on those objects, not that there is anything wrong with the benchmark. No, I don't think that this is happening. Parrot's slightly slower object instantiation is due to register preserving mainly. The __init code is run from inside the new PObj, IClass opcode. As its not known that a method call is happening here, we can't use register preserving operations that only save needed registers--we have to save all registers. These two memcpys are the most heavy part of the operation. Maybe we should rethink that then and make allocation and initialization two different phases. Or dictate that new PObj, IClass should be treated as if it were a function call with all the caller saves implications that go with it.
Re: OO benches
Piers Cawley wrote: Leopold Toetsch [EMAIL PROTECTED] writes: These two memcpys are the most heavy part of the operation. Maybe we should rethink that then and make allocation and initialization two different phases. Or dictate that new PObj, IClass should be treated as if it were a function call with all the caller saves implications that go with it. Well, its not only object creation. While this is a bit special and could have a special syntax, the problem is with all delegate usage e.g. for tying. If we need some extra speed for object creation, we could define it as new PObj, IClass, BUILD # call sub in BUILD prop new PObj, IClass, CONSTRUCT # call sub in CONSTRUCT prop new PObj, IClass # no init call at all and just save needed registers, as we know, that a Sub is called (or not). But as said, it doesn't help here: $ time perl ff.pl 010 real0m3.287s $ time parrot -j ff.pasm 010 real0m2.334s leo :) ff.pl Description: Perl program newclass P1, FF addattribute P1, 'r' find_type I12, FF new P2, I12 set I10, 0 set I11, 50 loop: set I15, P2 inc I10 lt I10, I11, loop set I15, P2 print I15 set I15, P2 print I15 set I15, P2 print I15 print \n end .namespace [FF] .pcc_sub __init: classoffset I0, P2, 'FF' new P3, .PerlInt setattribute P2, I0, P3 invoke P1 .pcc_sub __get_integer: classoffset I0, P2, 'FF' getattribute P3, P2, I0 new P4, .PerlInt band P4, P3, 1 inc P3 if P4, r1 set I5, 0 invoke P1 r1: set I5, 1 invoke P1
Re: [perl #28898] [PATCH] signedness police part 2: string_primitives.c
Jarkko Hietaniemi [EMAIL PROTECTED] wrote: cc: Warning: src/string_primitives.c, line 149: Thanks, applied. leo
Re: [perl #28899] [PATCH] de-consting: objects.c
Jarkko Hietaniemi [EMAIL PROTECTED] wrote: -(Hash*) PMC_struct_val(props), prop_str); +(Hash*) PMC_struct_val(props), (STRING*) prop_str); That only helps certain compilers. I've put in a const_cast(). leo
Re: [perl #28907] [BUG] Can't make, src/objects.c
Will Coleda [EMAIL PROTECTED] wrote: just did a cvs update -dP, make realclean, perl Configure.pl, make, failed. Here's the error I get when I remake after that point. Should be fixed now. leo
Re: c2str.pl
Leopold Toetsch [EMAIL PROTECTED] wrote:
- $ perl c2str.pl src/objects.c src/objects.str
- enable #include objects.str near the top of the file
- $ make
To make it compile cleanly with gcc 2.95.2 some of the consts need to go
- or I'm to dumb to do it right ;)
So here is another version below + 2 Makefile snippets to automate
processinng:
%.str : %.c c2str.pl
perl c2str.pl $ $@
...
$(SRC)/objects$(O) : $(GENERAL_H_FILES) $(SRC)/objects.str
We really need these constant strings badly (10-30% performance
increase). So please test it with your compiler.
BTW the string header needs probably live in the data segment - else we
might get troubles during e.g. setting the live flag on such strings.
Nethertheless we need something like this.
see also Constant strings - again from yesterday.
Thanks,
leo
#! perl
use Text::Balanced qw(extract_bracketed);
use strict;
die $0: Usage $0 FILE.c unless $#ARGV == 0;
my $file = shift @ARGV;
$file =~ s/\.c$//;
my $infile = $file . '.c';
my $outfile = $file . '.str';
die $0: $infile: $! unless -e $infile;
print HEADER;
/*
* !!! DO NOT EDIT THIS FILE !!!
*
* This file is generated automatically from '$infile'
* by $0.
*
* Any changes made here will be lost!
*
*/
#define CONCAT(a,b) a##b
#define _S(name) (__PARROT_STATIC_STR(__LINE__))
#define __PARROT_STATIC_STR(line) CONCAT(static_string_, line)
#if ! DISABLE_GC_DEBUG
# define GC_DEBUG_VERSION ,0
#else
# define GC_DEBUG_VERSION
#endif
HEADER
my %known_strings = ();
use Math::BigInt;
sub hash_val {
my $s = substr shift, 1, -1;
my $h = new Math::BigInt-bzero();
for (my $i = 0; $i length($s); ++$i) {
$h += $h 5;
$h = 0x;
$h += ord substr($s, $i, 1);
$h = 0x;
}
return sprintf(0x%x, $h);
}
sub output_string {
my ($text, $line) = @_;
if (exists $known_strings{$text}) {
DATA;
#define static_string_${line} static_string_$known_strings{$text}
DATA
}
else {
$known_strings{$text} = $line;
my $h = hash_val($text);
DATA;
static /*const*/ char static_string_${line}_data\[\] = $text;
static const struct parrot_string_t static_string_${line} = {
{ /* pobj_t */
{{
static_string_${line}_data,
sizeof(static_string_${line}_data)
}},
(PObj_constant_FLAG|PObj_external_FLAG)
GC_DEBUG_VERSION
},
sizeof(static_string_${line}_data),
static_string_${line}_data,
sizeof(static_string_${line}_data) - 1,
1,
$h
};
DATA
}
}
open IN, $infile;
my $line = 0;
while (IN) {
$line++;
next if m/^\s*#/; # ignore preprocessor
next unless s/.*\b_S\b//;
my $str = extract_bracketed $_, '()';
print output_string (substr($str,1,-1), $line);
}
Re: Constant strings - again
Leopold Toetsch [EMAIL PROTECTED] wrote: [ blabla ] Sorry. This scheme with constant strings in constant memory doesn't work - at least not with ARENA_DOD_FLAGS enabled, which assumes *all* objects are coming from arenas. These string headers live outside of any arena. It could work w/o ARENA_DOD_FLAGS *if* these strings get additional flags set: - is_live ... would prohibit setting live bits - dont_touch_or_free_header ... might be needed for destruction But with ARENA_DOD_FLAGS enabled, I don't see much chance to get this running. This would need collecting all constant strings in an aligned memory segment, attach an arena header to it and set live bits in attached dod_flags - a lot of work for a preprocessor, albeit doable with a lot of effort. So what about a string cache. Could work similar to the method cache with lookup via some address bits. Should still be cheaper then constructing all these strings ever and ever. Brainstorming time... leo PS why I really like to have something like this: $ time parrot -jG ff.pasm 010 real0m1.728s# with _S(__get_integer) real0m2.148s# with const_string(...)
Re: backticks
Juerd wrote: Sean O'Rourke skribis 2004-04-15 8:55 (-0700): I find that there are still plenty of contexts in which `` is nice and security is irrelevant. This is the second time in this thread that I read about security being unimportant. I still don't know what to say about it, though I feel like ranting. Security is of course extremely important, but changing a language so that doing anything insecure becomes impossible or at least extremely difficult strikes me as a bit too much nannying. One should of course never accept user input without validating it first - especially stuff coming in over a network - but once you know what's in it, there's nowt wrong with interpolating that into a `` or qx// kind of structure. Well, other than the usual mistakes you can make by forgetting how it's going to interact with the shell, but this really doesn't bother me in the slightest. And as has been said, there's a vast amount of one-liners and short utility scripts out there which use backticks quite happily and safely. As with many things, they're only dangerous if you don't know what you're doing. Probably you know when you can use qx safely, but many, MANY people out there have no clue whatsoever and use qx with interpolation *because* it is easy. Which is exactly why I use it. I'm just not foolish enough to trust the variables I'm interpolating into it unless I've constructed them entirely myself and I know the code that constructs them is bug-free. Having said all that about lack of knowledge though, I'm sure everyone on this list knows about how to deal with tainted data and such things, but there are a lot of fresh Computer Science graduates and other people learning programming who never hear a thing about it. I don't see that as an excuse to turn Perl into a hand-holding nanny language though.
Re: backticks
John Williams skribis 2004-04-16 18:32 (-0600): You didn't answer his question, which is less complicated? Wasn't that a rhetociral question? Juerd
How to read and write files?
I think I have somesing missed: is it possible to open (that is read and write) files in perl6 programmes? Those programmes that can be run under current parrot release. Thanks.
RE: Apocalypse 12
From: chromatic [mailto:[EMAIL PROTECTED] Perl.com has just made A12 available: http://www.perl.com/pub/a/2004/04/16/a12.html Warning -- 20 pages, the first of which is a table of contents. Enjoy, -- c This week I've celebrated my birthday, had my jaw unwired, uncovered five job prospects, and finally got A12. When I do this year in review, this week will be hard to beat. Woo-hoo! =Austin
Re: backticks
In a message dated Fri, 16 Apr 2004, Juerd writes: Except for the shocking number of closed-minded people on this list. Stop it, stop it, STOP IT. I'm not asking you to stop voicing your opinion about the discussion at hand--that would be closed-minded, after all. I'm asking you to stop interpreting disagreement as censorship, prejudice, closed-mindedness, or whatever else. It's not. In any case, the argument in re 'what operator to access keywordishly-keyed hashes' is spinning out of control and not getting anywhere. This is precisely why we leave it to Larry (and @Larry) to exercise his benevolent dictatorship. Open issues in regards to what to do with qx() (I'll post my thoughts on that a bit later) and discussion thereof, or on a truly new syntax (other than the ones proposed by Larry and Juerd or a return to Perl 5 ambiguity) or some other brilliant unification in regards to hash keys would I think still be welcomed here. But the argument back and forth--which is prettier, which takes more keystrokes, what's a keystroke, isn't it too much like some-other-language-we-don't-like, no it's more like yet-another-language-we-do-like, etc. ad nauseam is just petty bickering at this point. Can we all just take a deep breath here and let the issue be resolved as time fulfills? No progress is being made at this point. Let it rest. (No, Juerd, I'm not being closed-minded or censoring you. This equally applies to everyone who just wants to restate some new wrinkle of a point already discussed to death.) Trey -- Trey Harris Vice President SAGE -- The System Administrators Guild (www.sage.org) Opinions above are not necessarily those of SAGE.
Re: backticks
Folks, this discussion seems to be spinning. All the points, on both sides, have been made and are being repeated with only slight variation. We've all made our cases--why don't we drop the issue for a while and let Larry ruminate? I think we can all agree that he will give the idea a fair hearing and make a good decision...and I know that I'll be glad if, tomorrow, I *don't* have 30 mails in my box about backticks. : --Dks
Re: Apocalypse 12
chromatic [EMAIL PROTECTED] writes: Perl.com has just made A12 available: http://www.perl.com/pub/a/2004/04/16/a12.html Warning -- 20 pages, the first of which is a table of contents. But it's all excellent good stuff. Well done Larry and Co. Now, if you could all just hold off with the questions 'til Monday you'll make a summary writer's life a good deal easier. -- Biologist: What's worse than being chased by a Velociraptor? Physicist: Being chased by an Acceloraptor -- Larry Wall in A12
Re: backticks
Trey Harris skribis 2004-04-16 12:05 (-0700): I'm asking you to stop interpreting disagreement as censorship, prejudice, closed-mindedness, or whatever else. It's not. I never did interpret disagreement as anything but disagreement, and never said that I think everyone who disagrees is closed-minded. Instead of asking me to stop interpreting disagreement as close-mindedness, ask yourself to stop interpreting closed-minded as disagreeing. There is no 'between the lines' in my messages. Stop looking for it. Juerd
Re: Apocalypse 12
On Fri, Apr 16, 2004 at 05:30:01PM -0700, chromatic wrote: Perl.com has just made A12 available: http://www.perl.com/pub/a/2004/04/16/a12.html Warning -- 20 pages, the first of which is a table of contents. Enjoy, -- c It's here, it's here, it's he!! *Ahem* Sorry. Will now go off and read quietly. --Dks
Re: Apocalypse 12
On 4/17/04 6:22 AM, Piers Cawley wrote: chromatic [EMAIL PROTECTED] writes: Warning -- 20 pages, the first of which is a table of contents. But it's all excellent good stuff. Well done Larry and Co. Now, if you could all just hold off with the questions 'til Monday you'll make a summary writer's life a good deal easier. Putting it off will only make things worse for you later! ;) I have many A12 questions and comments in the queue, but alas I am busy this weekend so you're safe for now... -John
A12 Q: Pointer-to-member-function behavior?
A12
The upshot of these rules is that a private method call is
essentially a subroutine call with a method-like syntax. But the
private method we're going to call can be determined at compile
time, just like a subroutine.
/A12
Is it permissible to use variable dispatch for private methods?
class Cerebellum {
method :think() {...}
method :ponder() {...}
method :cogitate() {...}
method some_method() {
...
$activity = «:think, :ponder, :cogitate».random;
$brain.$activity;
}
}
Or would the colons be on the invocation, not the name?
=Austin
PS: Sorry, Piers.
Re: Apocalypse 12
chromatic wrote: Perl.com has just made A12 available: I started reading it last night, and ended up going to bed before I was finished. But I just wanted to say that this: With this dispatcher you can continue by saying next METHOD. is the sort of genius that makes me glad Larry's designing this language. Well done! -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Apo 12: Space in method calls
I do not understand one of the examples in the Use of methods/the dot notation section: $obj.method ($x + $y) + $z From the earlier examples (like $obj.method +1), I got the impression that you look ahead until you find a term or an operator. In the example above, isn't ($x + $y) a full term, all by itself, and in that case would not this mean ($obj.method($x + $y)) + $z, the same as the other call it is contrasted with: $obj.method($x + $y) + $z What am I missing? --Abhijit Abhijit A. Mahabal http://www.cs.indiana.edu/~amahabal/
Re: Constant strings - again
On Apr 17, 2004, at 12:41 PM, Leopold Toetsch wrote: This scheme with constant strings in constant memory doesn't work - at least not with ARENA_DOD_FLAGS enabled, which assumes *all* objects are coming from arenas. These string headers live outside of any arena. Oh, yes--darn. It could work w/o ARENA_DOD_FLAGS *if* these strings get additional flags set: - is_live ... would prohibit setting live bits - dont_touch_or_free_header ... might be needed for destruction I wonder if it's possible to identify these at runtime as living in the C-constant region of memory? For instance, if we could tell their memory address is stack base, and use that to identify them as constant? But with ARENA_DOD_FLAGS enabled, I don't see much chance to get this running. This would need collecting all constant strings in an aligned memory segment, attach an arena header to it and set live bits in attached dod_flags - a lot of work for a preprocessor, albeit doable with a lot of effort. It should be possible to aggregate all of the constants into a single array (one include, rather than one-per-source-file), which would let us identify them by their memory location, as residing in this range. That seems pretty straightforward to do. So rather than compiling to static_string_532, instead _S(foo) would compile to static_strings[7], or something. Then the check is just whether (some_string = static_strings[0] some_string = static_strings[max])--if so, it was from a literal (and thus, is constant). PS why I really like to have something like this: $ time parrot -jG ff.pasm 010 real0m1.728s# with _S(__get_integer) real0m2.148s# with const_string(...) Yes, it seems like a good idea, in general terms; quite reasonable, as an extension of what C already does for C strings. (FWIW, ObjC has support for literal NSStrings--I'm not sure how much of the work is done at compile-time v. runtime, though the tricky part for us is really GC, which isn't a factor for ObjC. I wonder what Java does for string literals? Maybe something similar to the above.) JEff
