Re: [RfD] parrot run loops
I don't really know a whole lot about this area, but I remember I was surprised the first time I looked at this and discovered it was based on pointers instead of offsets. I assumed there was some good reason for it that I didn't know at the time (eg performance), but now I doubt that. Your way seems much better to me. (It makes debugging slightly easier too.) Have you tried it on a more RISC-y machine where any performance loss might be more noticeable? I tried the change you suggested on a PPC, and saw no speed difference.
Re: [RfD] parrot run loops
Steve Fink wrote: I don't really know a whole lot about this area, but I remember I was surprised the first time I looked at this and discovered it was based on pointers instead of offsets. I assumed there was some good reason for it that I didn't know at the time (eg performance), but now I doubt that. Your way seems much better to me. (It makes debugging slightly easier too.) Yep ... Have you tried it on a more RISC-y machine where any performance loss might be more noticeable? I tried the change you suggested on a PPC, and saw no speed difference. No, I just did this quick test on 2 machines (1 Athlon, 1 Pentium). On RISC machines with probably plenty registers I expect similar i.e. no effects. But even when there is a slight speed impact - which I doubt - then this speed impact would only harm the interpreted run loops and only, when the whole program is just looping like mops.pasm. But for such programs, timings like these hold (on Athlon 800): CGoto: 20 fast_core: 12 Prederef: 17 JIT: 800 C no opt 195 C -O3:277 So when the whole thing is run loop bound, you have already lost ;-) Real world programs are not run loop bound, so I don't see any harm in changing the run loops to take an offset. leo
Re: [RfD] parrot run loops
Leopold Toetsch wrote: [ mops timings ] C -O3:277 BTW, same (probably alignment caused) timing diffs (gcc 2.95.2): $ for i in $(seq 20); do ./mops; done 328.089625 M op/s 319.657445 M op/s 333.533456 M op/s 371.050336 M op/s 345.721672 M op/s 307.465496 M op/s 364.405245 M op/s 330.797305 M op/s 305.609485 M op/s 396.188487 M op/s < 343.082872 M op/s 304.868686 M op/s 325.303605 M op/s 337.969318 M op/s 341.722460 M op/s 371.781657 M op/s 266.488824 M op/s < 367.296091 M op/s 294.070148 M op/s 327.632312 M op/s leo
tinderbox troubles?
Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /tinderbox/bdshowbuild.cgi. Reason: Could not connect to remote machine: Operation timed out Apache/1.3.26 Server at tinderbox.perl.org Port 80 TIA, leo
Re: occasioanl CVS hickups?
Robert Spier wrote: Odd. There's not enough information in the logs to figure out what's going on. (And the code shouldn't have this kind of failure mode.) If it keeps happening, please keep me in the loop. Todays imcc commit didn't show up at cvs.perl.org. No error message - looked all good and code is in. leo
Re: tinderbox troubles?
Strange. I can ssh in, and apachectl claims that the webserver is running, but I'm getting that error too. Ask, Robert: any ideas? Zach On 1/31/03 4:09 AM, "Leopold Toetsch" <[EMAIL PROTECTED]> wrote: > Proxy Error > The proxy server received an invalid response from an upstream server. > > The proxy server could not handle the request GET > /tinderbox/bdshowbuild.cgi. > > Reason: Could not connect to remote machine: Operation timed out > > Apache/1.3.26 Server at tinderbox.perl.org Port 80 > > > TIA, > leo
Re: Parrot developer world map
An interactive SVG version is (temporarily) available at: http://www.focusresearch.com/gregor/map.html Regards, -- Gregor Leon Brocard <[EMAIL PROTECTED]> 01/28/2003 05:24 PM To: [EMAIL PROTECTED] cc: Subject:Parrot developer world map Last week I collected your data. This week I bring you pretty pictures: http://www.astray.com/parrot/worldmap/ So London would seem a good place for a Parrot developer day, as would California. I guess most people will be meeting up at Perl conferences anyway. What do people have in mind for such a thing? A room, at least one computer, an internet connection and a Plan? Are you looking to learn more about Parrot or do you have something more specific in mind? Leon ps feel free to send in your location if you've forgotten to: -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ ... Famous last words - Don't worry, I can handle it
Re: Parrot developer world map
Greg -- Thats the centroid. You can see its dual South of Australia. Regards, -- Gregor Greg Woodhouse <[EMAIL PROTECTED]> 01/31/2003 03:52 PM To: [EMAIL PROTECTED] cc: Subject:Re: Parrot developer world map So, what's the yellow dot in the middle of the Atlantic? --- [EMAIL PROTECTED] wrote: > An interactive SVG version is (temporarily) available at: > > http://www.focusresearch.com/gregor/map.html > > > Regards, > > -- Gregor > > > > > > Leon Brocard <[EMAIL PROTECTED]> > 01/28/2003 05:24 PM > > > To: [EMAIL PROTECTED] > cc: > Subject:Parrot developer world map > > > Last week I collected your data. This week I bring you pretty > pictures: > > http://www.astray.com/parrot/worldmap/ > > So London would seem a good place for a Parrot developer day, as > would > California. I guess most people will be meeting up at Perl > conferences > anyway. > > What do people have in mind for such a thing? A room, at least one > computer, an internet connection and a Plan? Are you looking to learn > more about Parrot or do you have something more specific in mind? > > Leon > > ps feel free to send in your location if you've forgotten to: > > -- > Leon Brocard.http://www.astray.com/ > scribot.http://www.scribot.com/ > > ... Famous last words - Don't worry, I can handle it > > > = Greg Woodhouse [EMAIL PROTECTED] It is better to be complex than complicated.
Re: What's core? (was Re: Arrays: is computed)
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote: > So, is it obvious that I'm a little discouraged lately? Don't > suppose anyone can come up with some numbingly inspirational > words to cheer us (well, me) up... Go us.
Re: Arrays: Default Values
Dave Mitchell wrote:
On Fri, Jan 31, 2003 at 05:59:46PM +0100, Leopold Toetsch wrote:
IMHO some sort of proxy could be passed here, saying: "if you write to
me, this will be at @a[0]". Or auto-vivify the entry.
This is what Perl 5 does at the moment:
$ perl5.8.0 -MDevel::Peek -e 'sub f{Dump($_[0])}; f($a[9])'
Ah, same idea ;-)
However, I think this is clumsy and overly complex; since Perl6 allows us
to declare parameters rw or whatever, I think it should always autovivify
unless we know the param is read-only (or in-only, or whatever the correct
terminology is).
It's probably not too complex, it's IMHO the same, what we would need to
implement the multi_keyed opcodes like:
@a[$x] = @b{$y} - @c[2;$i]
We can't implement all the opcodes per se, this would need ~64K ops, so
one of my proposals (some time ago) was, to split this operation in 3
keyed fetch ops and one plain subtraction. The LHS whould need - as I
can set it now - a very similar treatment like above's example.
To come back to the array example:
- when the sub param is ro, you said it, no autovifiy should happen
- for rw (the default?) there is always a chance, that no write will
occur, and for the case nothing gets written, we have a volatile PMC
(the proxy) collected with the next DOD run. With autovivification we
create an anchored value, that is more expensive.
A (of course) constructed example could check in a subroutine, if
one/some/all elements exist
sub e() {return exists shift;}
for ([EMAIL PROTECTED]) -> $i { do_some($i) if e($a[$i]); }
# modulo syntax, operator and other errs :)
And, from DWIM POV, autovivification was not the clearest things in the
docs, when it could happen or not. I would just expect: when I don't set
this very elememt in this array, why is something there.
leo
Re: Arrays: Default Values
Aaron Sherman wrote: On Tue, 2003-01-28 at 16:23, Leopold Toetsch wrote: Arrays (or hashes) don't grow on reading - never. But for less pure forms of reading: foo(@a[0]); auto-vivification will have to happen in some cases. e.g. if foo requires a lvalue parameter. A lvalue param is not strictly reading, but here has to happen something differently - yes: IMHO some sort of proxy could be passed here, saying: "if you write to me, this will be at @a[0]". Or auto-vivify the entry. leo
What's core? (was Re: Arrays: is computed)
On Thursday, January 30, 2003, at 10:44 PM, Leopold Toetsch wrote: Michael Lazzaro wrote: [EMAIL PROTECTED] wrote: Shouldn't access to 'is computed' arrays be read-only? In general, I would hope that 90% of them would be, but it's been stated that it won't be a requirement. If you want such 'is computed' thingy, then tie it or wrap it in your own - IMHO. Everyone seems to need different things, so the simplest and by far the safest way is to make this explicit in your code. Yep. Sigh. This is all quite frustrating, because everyone has different ideas on what's valuable enough to be a builtin, but it's the design team that finalizes that, and the information is sort of scattered piecemeal through the A's/E's/p6l. If you look around enough, there's a pile of builtin stuff that's obliquely referred to, but never quite spelled out. And even the simplest ones -- what "default" means, for example -- aren't necessarily obvious at first glance. All I want is a list of what the already-known builtins *are*, or what other things people *demand* should be there, and the gist of what they do. Even if I have to change it later. Even if they're not in core, but they're things that people are going to immediately build because they're so obvious. Something to make me feel that the precise behaviors have really been pinned down -- and can be reliably extrapolated from -- preferably *before* people spend a lot of time coding them. Lord, this is just *arrays*. Not even *hashes*, yet... So, is it obvious that I'm a little discouraged lately? Don't suppose anyone can come up with some numbingly inspirational words to cheer us (well, me) up... MikeL
summarizing the obvious (was: arrays, hashes unified ...)
From: Piers Cawley [mailto:[EMAIL PROTECTED]] > Garrett Goebel <[EMAIL PROTECTED]> writes: > > > > $idx_of_foo = $queue['foo']; # named lookup > > $nth_foo= $queue[600]; # ordered lookup > > > > One is SvPOK the other SvIOK... > > > > Can't we handle both and still have the ordered lookup be fast? [...] > YOU CAN'T USE THE TYPE OF THE 'INDEX' OBJECT TO DETERMINE > WHETHER YOU'RE DOING A HASHLIKE OR AN ARRAYLIKE LOOKUP. As > Dan pointed out ages ago. Got it. Conflating indexed and named lookups (creating a syntactic homonym), isn't desirable or reasonably feasible. If we went down that route, it'd wind up being more confusing, self-limiting, breed complexity in a response to resolve the over-simplification, and drag down performance. Or probably better left at "not desirable". Or for the extremely thick: GOOD: Separate syntax for indexed vs. named lookups BAD: Same syntax with >= 2 contextual meanings Apologies for revisiting the graveyard of bad ideas and contributing negatively to the signal to noise ratio. I too have great difficulty in keeping up with the list. For the most part, I tend to read the replies of the more enlightened to others' questions, comments, and proposals. How Damian, our most prolific, found the time to sift through so much I don't know. I'm disappointed that The Perl Foundation (TPF) has been so quiet and unresponsive on support for our core language designers and architects. I dropped a note to all the TPF contacts over a week ago, and have yet to receive a reply. It is a sad state of affairs when a language as prevalent as Perl and with such a strong sense of community can be so disorganized and lacking when it comes to financial sustenance.
Re: summarizing the obvious
On Friday, January 31, 2003, at 09:40 AM, Garrett Goebel wrote: Or for the extremely thick: GOOD: Separate syntax for indexed vs. named lookups BAD: Same syntax with >= 2 contextual meanings Seriously, everyone read Damian's "Seven Deadly Sins" thing, if ya haven't read/heard it already. It's quite short, and quite good at pointing out Things That Suck about programming languages. http://www.csse.monash.edu.au/~damian/papers/PDF/SevenDeadlySins.pdf I'm disappointed that The Perl Foundation (TPF) has been so quiet and unresponsive on support for our core language designers and architects. I dropped a note to all the TPF contacts over a week ago, and have yet to receive a reply. It is a sad state of affairs when a language as prevalent as Perl and with such a strong sense of community can be so disorganized and lacking when it comes to financial sustenance. It's worse than that, IMO. Think of all the businesses that benefit from Perl... it's bloody *everywhere*. It's the, what, fourth most popular language, after C/C++/Java, according to that monster-job-search-based-statistic on slashdot. And yet the entire population of the Perl-using planet can't support 4 or 5 full time designers/developers? Have we just not been effective in getting the word out, or are businesses truly that cheap? Does Perl need to be made into a commercially supported product, w/ venture capital, a'la other recent open source pkgs, in order to get funded? MikeL
Re: Arrays: Default Values
On Fri, Jan 31, 2003 at 05:59:46PM +0100, Leopold Toetsch wrote:
> A lvalue param is not strictly reading, but here has to happen something
> differently - yes:
>
> IMHO some sort of proxy could be passed here, saying: "if you write to
> me, this will be at @a[0]". Or auto-vivify the entry.
This is what Perl 5 does at the moment:
$ perl5.8.0 -MDevel::Peek -e 'sub f{Dump($_[0])}; f($a[9])'
SV = PVLV(0x8177118) at 0x8166a74
REFCNT = 1
FLAGS = (GMG,SMG)
IV = 0
NV = 0
PV = 0
MAGIC = 0x816e7e0
MG_VIRTUAL = &PL_vtbl_defelem
MG_TYPE = PERL_MAGIC_defelem(y)
TYPE = y
TARGOFF = 9
TARGLEN = 1
TARG = 0x817ad88
SV = PVAV(0x8183bd4) at 0x817ad88
REFCNT = 2
FLAGS = ()
IV = 0
NV = 0
ARRAY = 0x0
FILL = -1
MAX = -1
ARYLEN = 0x0
FLAGS = (REAL)
However, I think this is clumsy and overly complex; since Perl6 allows us
to declare parameters rw or whatever, I think it should always autovivify
unless we know the param is read-only (or in-only, or whatever the correct
terminology is).
--
"There's something wrong with our bloody ships today, Chatfield."
Admiral Beatty at the Battle of Jutland, 31st May 1916.
out-of-place-rant (was: summarizing the obvious)
Michael Lazzaro wrote: > On Friday, January 31, 2003, at 09:40 AM, Garrett Goebel wrote: > > > > > > I'm disappointed that The Perl Foundation (TPF) has been so > > quiet and unresponsive on support for our core language > > designers and architects. I dropped a note to all the TPF > > contacts over a week ago, and have yet to receive a reply. > > It is a sad state of affairs when a language as prevalent > > as Perl and with such a strong sense of community can be so > > disorganized and lacking when it comes to financial > > sustenance. > > > > It's worse than that, IMO. Think of all the businesses that benefit > from Perl... it's bloody *everywhere*. It's the, what, fourth most > popular language, after C/C++/Java, according to that > monster-job-search-based-statistic on slashdot. And yet the entire > population of the Perl-using planet can't support 4 or 5 full time > designers/developers? Have we just not been effective in getting the > word out, or are businesses truly that cheap? Does Perl need to be > made into a commercially supported product, w/ venture capital, a'la > other recent open source pkgs, in order to get funded? Don't forget giving credit where credit is due. YetAnother has accomplished a good deal. I don't understand the current relative silence, but they did setup and administer The Perl Foundation (TPF). Quite a number of companies and individual did fund TPF's 2002 grants (http://donate.perl-foundation.org/index.pl?node=Fund+Drive+Details&selfund= 2). O'Reilly and ActiveState have for a long time employeed a substantial number of people who spend a significant amount of time improving Perl. And don't forget the folks and hardware donations behind CPAN. There are doubtlessly many other organizations which support people like ValueClick has Ask. I just don't follow the lack of active and organized financial support for Perl6... I may not have the time, knowledge, and ability to contribute much to Perl6 language design or Parrot. But, point me where I can send a check that'll support Larry, Damian, and Dan. That for the moment, I can still manage... I'll shut up now. No need to mention that this belongs on advocacy. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: tinderbox troubles?
> Strange. I can ssh in, and apachectl claims that the webserver is running, > but I'm getting that error too. > > Ask, Robert: any ideas? Looks like the apache had hung somewhere. I shut it down and started it up, and it seems ok. -R
