Re: Phalanx has started, and I need perl-qa's help
Andy Lester wrote: The Phalanx project has started its rampup to an official announcement. Phalanx is going to beef up the tests, coverage and docs on Perl and 100 heavily-used modules from CPAN. The project page is at http://qa.perl.org/phalanx/. Please take a look, tell me your thoughts, and if there are any serious ommissions from the Phalanx 100 module list... I'm turning to the perl-qa group for feedback BEFORE I announce to the world, so I appreciate any comments. Looks like a most excellent start to me. Thanks Andy. Here is the top 100 list sorted by most prolific author (just in case anyone is interested :-): 8 GAAS : HTML-Parser libwww-perl MIME-Base64 URI Digest-HMAC Digest-SHA1 Image-Info MD5 4 JWIED : DBD-mysql Msql-Mysql-modules Net-Daemon Text-CSV_XS 3 GBARR : Convert-ASN1 perl-ldap Scalar-List-Utils 3 INGY : CGI-Kwiki Inline YAML 2 ABW : Template-Toolkit AppConfig 2 DPARIS: Crypt-Blowfish Crypt-DES 2 DROLSKY : HTML-Mason Params-Validate 2 ERYQ : IO-stringy MIME-tools 2 KANE : CPANPLUS Archive-Tar 2 LDS : GD Crypt-CBC 2 MARKOV: MailTools Mail-Box 2 MSERGEANT : XML-SAX XML-XPath 2 MVERB : GDGraph GDTextUtil 2 RGIERSIG : Expect IO-Tty 2 SBURKE: HTML-Tagset HTML-Tree 2 STBEY : Date-Calc Bit-Vector 2 TIMB : DBI DBD-Oracle 1 ABH : Apache-DBI 1 ABIGAIL : Regexp-Common 1 AKSTE : Data-ShowTable 1 AREIBENS : PDF-API2 1 AUTRIJUS : PAR 1 BEHROOZI : IO-Socket-SSL 1 BIRNEY: bioperl 1 BTROTT: Net-SSH-Perl 1 CHAMAS: Crypt-SSLeay 1 CNANDOR : MP3-Info 1 COOPERCL : XML-Parser 1 CREIN : Net-DNS 1 CWINTERS : SPOPS 1 DCLINTON : Cache-Cache 1 DCONWAY : Parse-RecDescent 1 DMEGG : XML-Writer 1 DTOWN : Net-SNMP 1 GRANTM: XML-Simple 1 GSAR : libwin32 1 ILYAZ : Term-ReadLine-Perl 1 JBAKER: Apache-Session 1 JCRISTY : PerlMagick 1 JERLBAUM : CGI-Application 1 JESSE : DBIx-SearchBuilder 1 JMASON: Mail-SpamAssassin 1 JMCNAMARA : Spreadsheet-WriteExcel 1 JOESUF: libapreq 1 JROGERS : Net-Telnet 1 JURL : DBD-ODBC 1 JZUCKER : DBD-CSV 1 KGB : PDL 1 KJALB : TermReadKey 1 KMACLEOD : libxml-perl 1 KULCHENKO : SOAP-Lite 1 KWILLIAMS : Module-Build 1 KWITKNR : Spreadsheet-ParseExcel 1 MERGL : DBD-Pg 1 MIVKOVIC : Mail-Sendmail 1 MPIOTR: Text-Iconv 1 MUIR : Time-modules 1 NEDKONZ : Archive-Zip 1 PETDANCE : WWW-Mechanize 1 PHISH : XML-LibXML 1 PMQS : Compress-Zlib 1 RCAPUTO : POE 1 RJRAY : Image-Size 1 RSE : TimeDate 1 SAMPO : Net_SSLeay.pm 1 SAMTREGAR : HTML-Template 1 SBECK : DateManip 1 SHERZODR : CGI-Session 1 TJMATHER : XML-DOM 1 TMTM : Class-DBI 1 UARUN : Error 1 WADG : Config-IniFiles 1 YVES : MIME-Lite /-\ http://search.yahoo.com.au - Yahoo! Search - Looking for more? Try the new Yahoo! Search
Re: Phalanx has started, and I need perl-qa's help
On Thu, Aug 21, 2003 at 10:48:11PM -0500, Andy Lester wrote: The Phalanx project has started its rampup to an official announcement. Phalanx is going to beef up the tests, coverage and docs on Perl and 100 heavily-used modules from CPAN. I'll be interested to see how you handle non-Perl dependencies as in C libraries. The project page is at http://qa.perl.org/phalanx/. Please take a look, tell me your thoughts, and if there are any serious ommissions from the Phalanx 100 module list... If we do, then it won't be the Phalanx 100 anymore, will it. :) I'd highly recommend against a naming scheme that limits your implementation. Hard coded constants and all that. :) I'd also recommend you list by Module::Name rather than Distribution-Name. If nothing else the Module::Name is more consistent. Here's some Really Important modules you're missing. I'm using http://mungus.schwern.org/~schwern/cgi-bin/perl-qa-wiki.cgi?EssentialModules for reference. It looks like you've left off all CPAN modules which are also in the core, I suppose you're figuring they'll be handled by the core smokers. Except that the versions on CPAN are sometimes slightly different than the ones in the core. I recall a recent release of Filter::Simple that worked fine in the core but got the paths to its test libraries wrong when installed from CPAN. The smokers also don't check for backwards compat. Most I mention because they're important. Some I mention because they tend to break a lot and reveal subtle incompatibilities in Perl. Test Test::Harness Test::More IO Class::Date (simply because it seems to break every time Perl changes) File::Spec (now on CPAN) Cwd (will be on CPAN soon) ExtUtils::MakeMaker CPAN Date::Parse (not so sure about that one) IPC::Run (cross-platform process execution is important) Devel::Cover Devel::Peek Devel::DProf Devel::SmallProf Text::Template libnet (Net::FTP, et al) Pod::Parser Pod::Man Pod::Text Pod::Simple Time::HiRes Tk (very complex, very chummy with MakeMaker) WxPerl (ditto) Filter::Simple (if that breaks, think of all the Acme modules that go with it!) - Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Cottleston, Cottleston, Cottleston Pie. A fly can't bird, but a bird can fly. Ask me a riddle and I reply: Cottleston, Cottleston, Cottleston Pie.
Re: Phalanx has started, and I need perl-qa's help
On Fri 22 Aug 2003 11:16, Michael G Schwern [EMAIL PROTECTED] wrote:
On Thu, Aug 21, 2003 at 10:48:11PM -0500, Andy Lester wrote:
The Phalanx project has started its rampup to an official
announcement. Phalanx is going to beef up the tests, coverage and
docs on Perl and 100 heavily-used modules from CPAN.
I'll be interested to see how you handle non-Perl dependencies as in
C libraries.
The project page is at http://qa.perl.org/phalanx/. Please take a
look, tell me your thoughts, and if there are any serious ommissions
from the Phalanx 100 module list...
If we do, then it won't be the Phalanx 100 anymore, will it. :)
I'd highly recommend against a naming scheme that limits your implementation.
Hard coded constants and all that. :)
I'd also recommend you list by Module::Name rather than Distribution-Name.
If nothing else the Module::Name is more consistent.
Here's some Really Important modules you're missing. I'm using
http://mungus.schwern.org/~schwern/cgi-bin/perl-qa-wiki.cgi?EssentialModules
for reference.
It looks like you've left off all CPAN modules which are also in the core,
I suppose you're figuring they'll be handled by the core smokers. Except
that the versions on CPAN are sometimes slightly different than the ones
in the core. I recall a recent release of Filter::Simple that worked fine
in the core but got the paths to its test libraries wrong when installed
from CPAN. The smokers also don't check for backwards compat.
Most I mention because they're important. Some I mention because they
tend to break a lot and reveal subtle incompatibilities in Perl.
Test
Test::Harness
Test::More
IO
Class::Date (simply because it seems to break every time Perl changes)
File::Spec (now on CPAN)
Cwd (will be on CPAN soon)
ExtUtils::MakeMaker
CPAN
Date::Parse (not so sure about that one)
IPC::Run (cross-platform process execution is important)
Devel::Cover
Devel::Peek
Devel::DProf
Devel::SmallProf
Text::Template
libnet (Net::FTP, et al)
Pod::Parser
Pod::Man
Pod::Text
Pod::Simple
Time::HiRes
Tk (very complex, very chummy with MakeMaker)
WxPerl (ditto)
Filter::Simple (if that breaks, think of all the Acme modules that go with it!)
FWIW here's my list of `standard' modules I allways add or update to the
default installation, with the lastest version I use:
my @defmod = qw(
ExtUtils-MakeMaker-6.16
Test-1.24
Test-Harness-2.28
Test-Simple-0.47
Getopt-Long-2.33
Compress-Zlib-1.22
IO-Zlib-1.01
Archive-Tar-1.04
Archive-Zip-1.06
Data-Dumper-2.102
Heap-0.50
Graph-0.201
Storable-2.07
Scalar-List-Utils-1.12
Devel-Size-0.58
Debug-Trace-0.04
Bit-Vector-6.3
Date-Calc-5.3
DateManip-5.42a
Time-HiRes-1.50
Encode-1.97
Unicode-Collate-0.25
Text-CSV_XS-0.23
DB_File-1.806
DBI-1.37
DBD-Unify-0.26
DBD-Oracle-1.14
DBD-mysql-2.9002
SQL-Statement-1.005
DBD-CSV-0.2002
Digest-1.02
Digest-MD5-2.27
Digest-SHA1-2.04
PROCURA-1.23
Text-Balanced-1.95
Parse-RecDescent-1.94
Crypt-SSLeay-0.51
Crypt-Rot13-0.04
libnet-1.16
Net-Ping-2.31
Net-Rexec-0.12
Net-SNMP-3.65
NNTPClient-0.37
TermReadKey-2.21
Term-ReadLine-Perl-1.0203
Text-Soundex-3.02
Text-Format0.52+NWrap0.11
Tk800.024
Tk-Clock-0.07
Tk-TreeGraph-1.024
Devel-ptkdb-1.1086
MIME-Base64-2.20
Term-Size-0.2
Mail-Sendmail-0.79
Unix-Processors-2.014
);
if ($^O eq cygwin) {
push @defmod, qw(
IO-stringy-2.108
OLE-Storage_Lite-0.11
Spreadsheet-ParseExcel-0.2602
Spreadsheet-WriteExcel-0.41
DBD-Excel-0.06
DBD-ODBC-1.06
Win32-Sound-0.45_001
);
}
else {
push @defmod, qw(
Proc-ProcessTable-0.38
User-Utmp-1.6.1.1
Inline-0.44
X11-Protocol-0.51
);
--
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0, 5.9.x, and 806 on HP-UX 10.20 11.00, 11i,
AIX 4.3, SuSE 8.2, and Win2k. http://www.cmve.net/~merijn/
http://archives.develooper.com/[EMAIL PROTECTED]/ [EMAIL PROTECTED]
send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: Phalanx has started, and I need perl-qa's help
Hi!
On Thu, Aug 21, 2003 at 10:48:11PM -0500, Andy Lester wrote:
The Phalanx project has started its rampup to an official
announcement. Phalanx is going to beef up the tests, coverage and
docs on Perl and 100 heavily-used modules from CPAN.
Have you got an plans on combining Phalanx and CPANTS?
As far as I understand it, Phalanx is mainly a manual project. I.e. real
humans (with brains and all) will look at some modules, apply some tests
(as listed in http://qa.perl.org/phalanx/kwalitee.html) and improve those
modules
CPANTS on the other hand is 100% automatic and limited to dumb computing
power. One of the basic ideas of CPANTS (when I first heard about from
Schwern at YAPC::Europe 2001) was exactly what you're doing now: Improving
the quality of CPAN.
I guess that there could by some synergic effects (is this an English word?
Synergieffekte in German?).
Leon?
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Phalanx has started, and I need perl-qa's help
Net_SSLeay.pm Just noticed that's a kinda odd name for a distribution that contains the modules Net::SSLeay and Net::SSLeay::Handle. I wonder why is it not called Net-SSLeay? /-\ http://search.yahoo.com.au - Yahoo! Search - Looking for more? Try the new Yahoo! Search
Re: Phalanx has started, and I need perl-qa's help
I'll be interested to see how you handle non-Perl dependencies as in C libraries. Yeah, me too! :-) If we do, then it won't be the Phalanx 100 anymore, will it. :) I'd highly recommend against a naming scheme that limits your implementation. Hard coded constants and all that. :) How does it limit my implementation? Do you know for a fact that there are exactly 100 modules in the Phalanx 100? At one point, the count was 103, and that was fine by me. :-) I'd also recommend you list by Module::Name rather than Distribution-Name. If nothing else the Module::Name is more consistent. The basic work unit of Phalanx is going to be the distribution. A team will take a distribution and work on it. Now, I may expand the list to show the modules that are in the distribution, but I'm looking at this from the point of view of organizing the effort. Here's some Really Important modules you're missing. I'm using http://mungus.schwern.org/~schwern/cgi-bin/perl-qa-wiki.cgi?EssentialModules for reference. It looks like you've left off all CPAN modules which are also in the core, I suppose you're figuring they'll be handled by the core smokers. Core modules are phase two because of the Extra Excitement that will be caused by mucking with them and pumpking coordination and whatnot. Most I mention because they're important. Some I mention because they tend to break a lot and reveal subtle incompatibilities in Perl. Thanks for the list. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Testers PASS
http://search.cpan.org/author/LBROCARD/CPAN-WWW-Testers/ http://testers.astray.com/ I just see that testers.cpan.org now use your interface. Cl. Faaast. But some problems ... We use in CPANPLUS old interface, old url to fetch reports about a dist. So there is no longuer report from CPANPLUS testers since yesterday. Ok, I patch this for use the great yaml I found one the new site, but there is missing info into the yaml file: When reports are failed, we just know: this fail. I need another field like 'detailed_results' who is an url to detailed report (today http://nntp.x.perl.org/group/perl.cpan.testers/xxx). Can you add this ? Regards, -- Alain BARBET
Re: Phalanx has started, and I need perl-qa's help
On Friday 22 August 2003 15:08, Andy Lester wrote: Core modules are phase two because of the Extra Excitement that will be caused by mucking with them and pumpking coordination and whatnot. None of the phalanx 100 depend on any core modules? Or you just plan to deal with the bare minimum of core modules to get the 100 working? F
Re: Testers PASS
alian sent the following bits through the ether: I just see that testers.cpan.org now use your interface. Cl. Faaast. Indeed! But some problems ... We use in CPANPLUS old interface, old url to fetch reports about a dist. So there is no longuer report from CPANPLUS testers since yesterday. Which interface is this? We can probably fake it with a mod_rewrite rule if you tell me the details. Ok, I patch this for use the great yaml I found one the new site, but there is missing info into the yaml file: When reports are failed, we just know: this fail. I need another field like 'detailed_results' who is an url to detailed report (today http://nntp.x.perl.org/group/perl.cpan.testers/xxx). If you replace the xxx with the ID then you have the correct URL. The next release of CPAN testers will have a report_url key containing this. HTH, Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ ... Don't sweat it - it's only ones and zeros
RE: Phalanx has started, and I need perl-qa's help
When will all of this phalanxing start? I'm excited about it and I can't wait to get my hands dirty. Hopefully with school and all I will have time to help you guys out. BTW phalanxing - the action of testing and improving CPAN and Perl. (or something to that effect) :-p ~~Andrew -Original Message- From: Andy Lester [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2003 11:48 PM To: perl-qa Subject: Phalanx has started, and I need perl-qa's help The Phalanx project has started its rampup to an official announcement. Phalanx is going to beef up the tests, coverage and docs on Perl and 100 heavily-used modules from CPAN. The project page is at http://qa.perl.org/phalanx/. Please take a look, tell me your thoughts, and if there are any serious ommissions from the Phalanx 100 module list... I'm turning to the perl-qa group for feedback BEFORE I announce to the world, so I appreciate any comments. Thanks, xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Testers PASS
But some problems ... We use in CPANPLUS old interface, old url to fetch reports about a dist. So there is no longuer report from CPANPLUS testers since yesterday. Which interface is this? We can probably fake it with a mod_rewrite rule if you tell me the details. The patch is already done. But if there is others apps that use that: http://testers.cpan.org/search?request=distdist=$name who is now: http://testers.cpan.org/show/$name But as the format has change, I don't know if this is really needed. Ok, I patch this for use the great yaml I found one the new site, but there is missing info into the yaml file: When reports are failed, we just know: this fail. I need another field like 'detailed_results' who is an url to detailed report (today http://nntp.x.perl.org/group/perl.cpan.testers/xxx). If you replace the xxx with the ID then you have the correct URL. Great, I didn't see that. The next release of CPAN testers will have a report_url key containing this. Thank you, -- Alain BARBET
Re: Testers PASS
alian sent the following bits through the ether: The patch is already done. But if there is others apps that use that: http://testers.cpan.org/search?request=distdist=$name who is now: http://testers.cpan.org/show/$name Done that: http://testers.cpan.org/search?request=distdist=Acme-Colour Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ ... C program run. C program crash. C programmer quit
Re: Testers PASS
Ok, I patch this for use the great yaml I found one the new site, but there is missing info into the yaml file: Can't you include os name and os version that can be found in all reports: osname=solaris, osvers=2.8, archname=sun4-solaris This is displayed in the old interface with all result, now you only display archname, ok, as you want, but in the yaml file it would be great to find this info. Regards, -- Alain BARBET
Re: Phalanx has started, and I need perl-qa's help
On Fri, Aug 22, 2003 at 09:08:51AM -0500, Andy Lester wrote: If we do, then it won't be the Phalanx 100 anymore, will it. :) I'd highly recommend against a naming scheme that limits your implementation. Hard coded constants and all that. :) How does it limit my implementation? Do you know for a fact that there are exactly 100 modules in the Phalanx 100? At one point, the count was 103, and that was fine by me. :-) Fair nuff. Here's some Really Important modules you're missing. I'm using http://mungus.schwern.org/~schwern/cgi-bin/perl-qa-wiki.cgi?EssentialModules for reference. It looks like you've left off all CPAN modules which are also in the core, I suppose you're figuring they'll be handled by the core smokers. Core modules are phase two because of the Extra Excitement that will be caused by mucking with them and pumpking coordination and whatnot. How so? -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Let me check my notes. http://www.sluggy.com
Test modules in 5.6.2
Folks, I've added and integrated a bunch of Test::* modules from bleadperl to 5.6.2. I've also roughly modernized the scripts t/TEST and t/harness with the bleadperl version, so that all *.t files are found, etc. Now if you're aware of a difference between bleadperl and CPAN or something, or if you find that this isn't a good idea, comments welcome. (Next step is MakeMaker. I needed the Test modules for it...) Change 20849 on 2003/08/22 by [EMAIL PROTECTED] Integrate Test::More, Test::Builder and Test::Simple, from bleadperl. Pulling in dependencies, I had to integrate if.pm as well (it's used in some tests.) Change 20848 on 2003/08/22 by [EMAIL PROTECTED] Upgrade to Test 1.24 (from bleadperl) Change 20847 on 2003/08/22 by [EMAIL PROTECTED] Two tests were failing after the Test::Harness upgrade, because they use Test, that loads Test::Harness, that doesn't load FileHandle anymore. Change 20846 on 2003/08/22 by [EMAIL PROTECTED] Upgrade to Test::Harness 2.30, and get t/harness from bleadperl (more or less, due to the different set of directories to scan for tests) -- perl -sleprint -- -_='Just another Perl hacker,'
[perl #23552] Parrot on Win32! Where we will be able to compile IMCC?!
# New Ticket Created by Graciliano M. P. # Please include the string: [perl #23552] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=23552 Hy, Sorry for the !!!, but when we will be able to compile IMCC on Win32? I think that you are missing something here, since I'm trying to do that from version 0.0.9. Parrot always compile fine, but parrot without IMCC is nothing, and IMCC never compile on Win32. I already sent a bug report about this problem for Parrot 0.0.10, and nothing yet! I have teste MS VC++ 6 and mingw with Parrot 0.0.09 and 0.0.10. Other thing, why parrot, the brain, compile fine and IMCC not? I think that use a C code more portable for IMCC is important. There's no sence to have the C code portable for parrot and not for IMCC. Regards, Graciliano M. P.
Re: PerlHash.get_pmc_keyed of non existing key
On Thursday, August 21, 2003, at 11:50 , Leopold Toetsch wrote:
IMHO is
$a = \$h{a};
print $$a;
$$a = xxx\n;
$a = $h{a};
print $a;
the same as:
new P1, .PerlHash
set P0, P1[a]
print P0
set P0, xxx\n
set P2, P1[a]
print P2
end
(PMCs have reference semantics[1])
Shouldn't that print xxx as perl5 does? I.e. store the returned
PerlUndef in the hash. And PerlArray too.
Isn't that the job of Perl's \ operator?
perl 'EOT'
my %hash = ();
my $temp = $hash{key};
print 'after $temp = $hash{key}: ', exists $hash{key}? exists\n :
does not exist\n;
$temp = \$hash{key};
print 'after $temp = \$hash{key}: ', exists $hash{key}? exists\n :
does not exist\n;
EOT
Or, better, Perl's lvalue context...
Gordon Henriksen
[EMAIL PROTECTED]
Re: Should I target Parrot?
On Thu, 21 Aug 2003, Tom Locke wrote: (not sure who you're quoting here... dan I think) But Parrot has continuations. Doesn't this gives me (cooperative) microthreads? (with a little work on my part). Sure... So these would be real cheap right? Time and space overheads similar to regular procedure calls? Yes. This isn't working 100% (at least I couldn't get it working without tweaking the opcodes a bit) but you can see an example of some microthreads at http://pirate.tangentcode.com/ ) ... Microthreads is kind of a loose word for it because it's just a list of generators that increment at each tick. The bytecode I'm generating there is really really bad, so it runs pretty slow, but it definitely works. You might try playing around with that. Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: Should I target Parrot?
On Thu, 21 Aug 2003, Benjamin Goldberg wrote: I hope you aren't planning on serializing just a single isolated microthread... that wouldn't work well with what I've got in mind due to how much stuff comes along when you serialize a continuation -- you'd get almost the whole interpreter serialized. If you want, instead, to serialize interpreter-microthreads, however... well, you'd *still* get almost the whole interpreter serialized, but you're getting more bang for your buck :) Well how else are we going to implement squeak? :) Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: Should I target Parrot?
Benjamin Goldberg [EMAIL PROTECTED] wrote:
inline op mthread_create(inconst INT) {
opcode_t *dest = PTR2OPCODE_T(CUR_OPCODE + $1));
PMC * p = new_ret_continuation_pmc(interpreter, dest)
Please note that the ret_continuation is intended for returning only, not
for executing code on. (it just has pointers to the original interpreter
context that get swapped in on invoke() - no COW copies like the normal
Continuation class)
leo
Re: String API
Benjamin Goldberg [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: I have problems imaginating such kind of STRINGs. You lack sufficient imagination -- Larry's suggested that Perl6 strings may consist of a list of chunks. I can easily imagine each of those chunks being full-fledged STRING* objects. Did Larry speak of PerlString or STRING? A foolish question: can you imagine strings which are lazily read from a file? Sure. ... If we could have str-strstart as a pointer to a vector of STRING*s, we wouldn't need any PMC to contain the chunks. And the str-encoding api is (already) sufficient for doing the work. The only lack is a custom mark, to keep the sub-strings alive. So you have everything what a string *PMC* has: a list of chunks (hanging off some pointer), custom mark, one or 2 vtables (encoding stuff) ... If we have it in a PerlString derived class, and do not make it part of STRING*, then we cannot pass such strings to C functions defined to accept strings in STRING* parameters, Such C functions must be aware of the string API anyway, they can't assume to get a char * something, they have to call the iterator interface. Well, except that when a PerlInt loses magic going to an INTVAL, the resulting integer generally takes *less* memory than it did as a PMC, whereas losing magic by changing from a PMC to a STRING could very easily result in using *more* memory. (And doing lots of work, which we wouldn't need if our string kept it's magic). That's right. But your (or Larry's) proposed list of chunk with custom mark is a PMC effectively, if you call it STRING or not doesn't matter. Its a string PMC with a special vtable. The chunk list contains STRING* buffers. That's it. my str $slurp = File.new($filename).slurp(); # = File.slurp($filename)? Sure, we could have this read in the whole file, but wouldn't it be nicer if it would *lazily* fill in $slurp? Isn't there a big fat warning in $doc, to avoid such kind of code? Anyway either the string iterator calls the file iterator getting the string or above code is illegal as tie()ing an int. Do you really want to slow down all string access, just for one very special corner case? I don't believe that it *would* slow down all string access. 2 more indirections for the chunk buffer: its variable sized so its a buffer header + buffer memory. And we are creating new strings all over the place which really hurts already now. For the current string code, we already take O(n) to get a void* pointer into an appropriate part of a utf8 string, for each character-index. Dan said, we don't do operations on such kind of string encodings. OTOH if the chunks all have a character count, we can quickly locate a certain position inside such strings. leo
Re: PerlHash.get_pmc_keyed of non existing key
Benjamin Goldberg [EMAIL PROTECTED] wrote: (PMCs have reference semantics[1]) I should have started with [1]: new P1, .PerlHash # new P3, .PerlString # set P3, yyy\n # set P1[a], P3 set P0, P1[a] print P0 set P0, xxx\n set P2, P1[a] print P2 end When the hash entry exists (3 comments enabled), there is a different behavior compared to the non existing case. setting (assigning) the returned P0 changes the aggregate member or not. If you'd done: assign P0, xxx\n set P0, xx and assign P0, xx are the same. As already outlined, one of these opcodes is obsolete. set does assign for I,N,S registers. Instead of set, then yes. However, set Px, Py merely stores Py into the register Px, without touching the PMC that was in it. There is not set P, P in above code. So I assume, that the returned PerlUndef should be put into the aggregate, if there was none before access. leo
Re: PerlHash.get_pmc_keyed of non existing key
Gordon Henriksen wrote: (PMCs have reference semantics[1]) Isn't that the job of Perl's \ operator? Did you read on to [1] too? leo
Re: [PATCH 2]Build system
ITYM:
my @headers=(
sort
map { m{^$inc/(.*\.h)\z} }
keys %{maniread()}
);
Otherwise, someone might at some future date, write:
langauges/mylang/include/parrot/oops.txt
And that would get picked up ;)
Or he might even write:
include/parrot/my_header.H
and that woudn't get picked up (~:
Re: Registers vs. Stack
S. entry on Dan's blog: Registers vs stacks for interpreter design. It's on this page: http://www.sidhe.org/~dan/blog/archives/2003_05.html klaas-jan - Original Message - From: Brent Dax [EMAIL PROTECTED] To: 'Tom Locke' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, August 21, 2003 6:40 PM Subject: RE: Registers vs. Stack Dan should really be answering this, but I'll try... Tom Locke: # The FAQ briefly mentions: # # we're already running with a faster opcode dispatch # than [Perl, Python, and Ruby] are, and having registers just # decreases the amount of stack thrash we get. # # Can I for one ask for some more detail? Pushing and popping values off a stack--especially the fairly complicated stacks Parrot uses (and needs)--is an expensive operation; by having registers, we avoid the expense. The speed hit from the stack operations would negate much of our advantage over those other languages. That's pretty much all we're saying there. As I remember, the decision to use registers was based on a few things: 1. Speed. a. The above: Register accesses are faster than stack accesses, in several significant ways. b. Fewer opcodes: Using registers means less pushing/popping, which means that opcode dispatch is less critical and ops that actually *do* stuff will stay in the cache longer. 2. Less bytecode: Any way you slice it, print X is smaller on diskthan push X, print. 3. Optimization: Optimizing register-based code is a problem that's been heavily studied for decades. We can leverage all that knowledge to make Parrot bytecode run faster. 4. Ease of hand hacking: It's easier to hand-write and hand-debug register-based assembler than stack-based assembler. This isn't that big an issue, but it is a factor. Basically it comes down to this: Register architectures have some Hard Problems, but once they're overcome the code will run faster. Stack architectures have fewer Hard Problems, but run slower. All things considered, we'd rather tackle a few Hard Problems than run slower. --Brent Dax [EMAIL PROTECTED] Perl and Parrot hacker Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna set myself on fire to prove it.
Re: [perl #23552] Parrot on Win32! Where we will be able to compile IMCC?!
Graciliano M . P . [EMAIL PROTECTED] wrote: ... I already sent a bug report about this problem for Parrot 0.0.10, and nothing yet! And I did answer: Post error message(s). leo
[CVS ci] PackFile-15: print warning location
The debug segment (generated with -w or -d commandline options) has source file name and line number information. When now parrot is run with the slow core and warnings are enabled, the location of the warnings is printed. $ parrot -bw h.pasm #[1] Use of uninitialized value in string context at h.pasm line 7. Use of uninitialized value in string context at h.pasm line 10. Question is: Should -w automatically select the slow core? (This is currently the only core which tracks interpreter-cur_pc) Further: The Csetline and Csetfile opcodes are suboptimal, they impose runtime penalty on each run core, so they will go finally. The Cgetline and Cgetfile can map to the functionality used in warnings.c. And finally: Parrot will (again[2]) track HLL source line info like: #line 17 sourcefile.p6 So that warnings and errors can be located in HLL source too. Have fun leo [1] $ cat h.pasm new P1, .PerlHash # new P3, .PerlString # set P3, yyy\n # set P1[a], P3 set P0, P1[a] print P0 set P0, xxx\n set P2, P1[a] print P2 end [2] IIRC was that one of my first patches to imcc.
Re: Weak References?
Benjamin Goldberg [EMAIL PROTECTED] writes: I would like for Parrot to have some way of creating Weak References; I think that this is probably a vital feature. The way I envision this is as follows. The following typedef and new function would be added: typedef void (*pobject_died_cb)(INTERP, PMC* who_asked, Pobj* weakref, void *callback_info); void pobject_weakref(INTERP, pobject_died_cb callback, Pobj* weakref, void *callback_info); This might be sometimes useful. Keeping a container of active objects like filehandles or windows for example. In this case it can't mark the reference because this would make the object active forever. Inside of a PMC*'s mark method, it registers callbacks (using the above function) so that it will be informed about what to do if the object to which it weakly refers to is found to not be alive at the end of the DOD sweep. This does not need to go into the mark function. The weakref_callback code can be called inside the destroy function. Im not sure if it should be called befor or after the custom destroy-function is run. And is the order of the weakref_callbacks defined. The pobject_weakref function first checks if the 'weakref' argument has been marked as alive -- if so, nothing happens. Then, it adds the Pobj* to a lookup table, pointing from the Pobj*, to a list of registered callbacks for that Pobj*. This is far to complicated. Each object has a list of destroy-functions, one of them is the costom-destroy function the others are the weakref-callbacks. But one other thing, what happens if the object holding the weakref dies before the refrenced object? Then the callback-function will be called for a dead object. So pobject_weakref() needs to return a handle for the weakref and there needs to be a function weakref_destroy(weakref_handle *handle). Other issue is who owns the data_structure of the weakref? The referent, the referee, or will this be garbage-collected (which makes the weakref_handle a PObj* and weakref_destroy its custom destroy function. After DOD finishes, the lookup table is walked; for each entry whose Pobj* hasn't been marked as alive, the callbacks are called. The effect of this of course is that a WeakRef has no cost except during Dead Object Detection. It only has a cost at object destroy-time. (If the weakrefs are garbagecollected they have an effect on DOD in the way that there are more objects to trace) The first, perhaps most important use, would be to implement a string-interning table. You'd have a global (per-interpreter) pmc which contains a hashtable of cstrings to perlstrings; if the cstring is present, the corresponding perlstring is returned; otherwise a new perlstring would be created and added to the table, then returned. If any of the perlstrings go out of scope, then their hash entries should disappear from the table. Obivously, if the table contained normal references to the strings, then they won't ever go out of scope. And if the table simply doesn't mark them as alive, it wouldn't know when they're dead. But with weakrefs, this is easy. this is only useful if a hashlookup is fast compared with string_make. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [CVS ci] PackFile-15: print warning location
Leopold Toetsch [EMAIL PROTECTED] writes: Further: The Csetline and Csetfile opcodes are suboptimal, they impose runtime penalty on each run core, so they will go finally. The Cgetline and Cgetfile can map to the functionality used in warnings.c. Normal processors also don't have setline and setfile operations. They use an extra segment in the *.o file, which is only used by the debugger. This could also be done in parrot. We just need to settle on a format for the line-info bytecode segement. The only question is reinvent the wheel, or use an already establiched format (stabs or DWARF). And finally: Parrot will (again[2]) track HLL source line info like: #line 17 sourcefile.p6 So that warnings and errors can be located in HLL source too. It might be nice to have column information to. This would make debugging of Befunge programs a lot more easy. Also it would be nice to have blocks of code (many pasm-lines) with just one linenumber, and otherwise have a possiblity to increase the source-line with each line of pasmcode. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Registers vs. Stack
On 08/21/03 Tom Locke wrote: Note that I have *absolutely* no opinion on this (I lack the knowledge). It's just that with Perl, Python, Ruby, the JVM and the CLR all stack based, Parrot seems out on a limb. That's fine by me -- innovation is not about following the crowd, but I feel it does warrant stronger justification. A well-designed register-based interpreter can be faster than a stack-based interpreter (because of the reduced opcode dispatch overhead). Doing a simple JIT for it may be also easier, if you ignore some advanced optimizations. That seems to be the main reason for parrot to go for it. Perl/Python/Ruby don't have (opcode dispatch) speed as their main aim (they use coarse instructions) so they use a stack-based design because it's much simpler. The JVM and the CLR use a stack-based instruction representation, but they are intended for JIT compilation in the end and in that case a register-based representation doesn't buy you anything (and complicates things such as the calling convention). That said, it will be interesting to see how Parrot will turn out to be once it's reasonably feature complete: it may end up providing interesting research results (whether good or bad, we don't know yet:-). p.s. (and at the risk of being controversial :) Why did Miguel de Icaza say Parrot was based on religion? Was it realted to this issue? Why is he wrong? See his side of the story at: http://primates.ximian.com/~miguel/activity-log.php (22 July 2003). There are also a few short comments on some blogs. But the main point is: at the end of the day numbers are what count, though anyone is free to assign more weight to different numbers such as: * execution speed (in mini, macro and bogus benchmarks:-) * number of languages that can be reasonably run on the VM * number of langauges that _cannot_ reasonably run on the VM:-) * memory usage overhead * runtime safety features * number of platforms supported * number of developers working on the VM * number of users of (programmers for) the VM So, you can't really say someone is wrong, until you measure at least some of the above quantities and set your priorities for which ones you prefer. Alas, measuring is hard and someone's priorities may not match the priorities of whoever implements/designs the virtual machines:-) I guess some first reasonably good numbers will come out of the Python on Parrot pie-fest: can't wait a year for it, though:-) lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better
Re: [CVS ci] PackFile-15: print warning location
On Fri, Aug 22, 2003 at 02:30:13PM +0200, Juergen Boemmels wrote:
a format for the line-info bytecode segement. The only question is
reinvent the wheel, or use an already establiched format (stabs or
DWARF).
can they do the things below?
It might be nice to have column information to. This would make
debugging of Befunge programs a lot more easy. Also it would be nice
I think that it has practical uses for other, dimensionally inferior
languages. It would often be nice to know which bit of this line:
} elsif ($host =~ /([^.]+\.[^.]{3}$)/ || $host =~ /([^.]{4,}\.[^.]{2}$)/ ) {
generated the undefined warning
Also, to be general we should do arbitrary dimensions, else the trifunge
hackers will feel left out.
to have blocks of code (many pasm-lines) with just one linenumber, and
otherwise have a possiblity to increase the source-line with each line
of pasmcode.
Also it would be nice to be able to record debugging lines at several levels,
so that a macro invocation can be stepped through as one line, or as each
line of the macro definition. (recursively)
It's a right pain trying to follow the perl5 C source in a C debugger, or
C++ inline code in gdb. I think that we can learn from those pain sources.
Nicholas Clark
headers.pl
I just peeped in headers.pl and alighted on that you had forgotten to put ^ in front of $inc according to Benjamin's advice(if you had meant that advice, of course) . s/$inc/^$inc/;
Re: [CVS ci] PackFile-15: print warning location
Nicholas Clark [EMAIL PROTECTED] writes:
On Fri, Aug 22, 2003 at 02:30:13PM +0200, Juergen Boemmels wrote:
a format for the line-info bytecode segement. The only question is
reinvent the wheel, or use an already established format (stabs or
DWARF).
can they do the things below?
DWARF has column numbers.
It might be nice to have column information to. This would make
debugging of Befunge programs a lot more easy. Also it would be nice
I think that it has practical uses for other, dimensionally inferior
languages. It would often be nice to know which bit of this line:
} elsif ($host =~ /([^.]+\.[^.]{3}$)/ || $host =~ /([^.]{4,}\.[^.]{2}$)/ ) {
generated the undefined warning
Even in C this things happen.
Also, to be general we should do arbitrary dimensions, else the trifunge
hackers will feel left out.
But what file-format do they use? Definitifly no plain text file,
because these are normaly 2-dimensional. One can abuse the linenumber
(or the columnnumber) to create an offset in their special file.
If they use text-files there exsits already a mapping from planes to
line/columns, and we can use that.
to have blocks of code (many pasm-lines) with just one linenumber, and
otherwise have a possiblity to increase the source-line with each line
of pasmcode.
Also it would be nice to be able to record debugging lines at several levels,
so that a macro invocation can be stepped through as one line, or as each
line of the macro definition. (recursively)
This associates many source-lines to one instruction: The unexpanded
source-line, the first level of expansion, ...
Problem how to create and read out this multi-level
instruction-source-line mapping. A simple #line isn't sufficent any
more.
It's a right pain trying to follow the perl5 C source in a C debugger, or
C++ inline code in gdb. I think that we can learn from those pain sources.
Don't repeat errors; make your own errors.
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: PerlHash.get_pmc_keyed of non existing key
On Friday, August 22, 2003, at 02:52 , Leopold Toetsch wrote:
Gordon Henriksen wrote:
(PMCs have reference semantics[1])
Isn't that the job of Perl's \ operator?
Did you read on to [1] too?
I read
[1]
new P1, .PerlHash
new P3, .PerlString
set P3, yyy\n
set P1[a], P3
set P0, P1[a]
print P0
set P0, xxx\n
set P2, P1[a]
print P2
end
yyy
xxx
as equivalent to...
$hash{a} = yyy\n;
$y := $hash{a}; # Note :=lhs instead of =lhs or =\lhs.
print $y; # yyy
$y = xxx\n;
print $hash{a}; # xxx
Makes sense.
My point was only that element lookup in an rvalue (get) should be
explicitly non-modifyingonly element lookup in an lvalue context (put)
should auto-vivify. But indirect puts like this are also necessary. (The
rhs of := is an l-value. As is the operand to \.)
With that in mind, Perl could construct lvalue operations (those with
auto-vivify) from rvalue operations (without auto-vivify). But the
reverse isn't true. So the no-auto-vivify semantics are the one that
must be preserved. Which contradicts your point that set Pn, Pm[...]
should always auto-vivify to support reference semantics. But, really,
both are significantly needed$str = $hash{key} and $ref = \$hash{key}
and $str := $hash{key} and $hash{key} := $str and $hash{key} = $str and
$hashB{keyB}{keyC}{keyD} = $hash{key} should all come down to PIR simply
and behave as in Perl 5 (where the construct exists in Perl 5). Element
lookup in an rvalue context should return an anonymous PerlUndef,
probably? In an lvalue context, it should do what you're asking for.
But my reading of [1] is not at all the same as this...
$hash{a} = yyy\n;
$y = \$hash{a}; # = \ -- Brand new reference PMC!
print $$y; # yyy
$$y = xxx\n;
print $hash{a}; # xxx
Never mind that there's no PerlReference PMC for $$ to work on, or for \
to return. While Perl 6 could conceivably support reference copying
without a reference-type PMC (using :=), it would be pretty darn
fragileone = instead of := and the reference is broken. I would not
have translated your original Perl example (with its \) as you did
actually, I wouldn't be able to translate it at all\ wants to construct
a PerlReference PMC IMO.
Gordon Henriksen
[EMAIL PROTECTED]
Re: Registers vs. Stack
On Thursday 21 August 2003 21:40, Brent Dax wrote: # we're already running with a faster opcode dispatch Man I wish I had the time to keep up with parrot development. Though, as others have pointed out, the core archetecture is somewhat solidified by this point, I thought I'd put in my two cents worth. I completely agree that stack machines are for wimps ;) But I have a problem with some peoples representation of stack machines. When was the last modern real-CPU that actually performed push/pop operations for their stack? That entire argument is moot in my opinion. Look at the sparc chip as an example. You have a set of pre-defined directly mappable registers which are appended to the stack, then you have your input parameters, your worst-case output parameters, and your local spill variables; all of which are pre-calculated at compile time, then a single number is computed. At the entry and exit of each function call, that number is added to and subtracted from the stack. All subsequent stack operations are simply ld/st [sp + offset], reg. If you were balsy enough, you could do global variable allocation, but depending on whether you're performing relocatable-code, you might still have to add the address to your Instruction-Pointer. Thus short of always having enough registers, you have to perform offset calculations, which is not much different than stack pushes/pops. But the paradigm is different. But there's another issue that I've seen brought up. By statically allocating spill/input/output variables to an offset of the stack pointer, you rid yourself the issue of where was that variable in the mix of pushes and pops.. You're garunteed that a variable is at a specific address, albeit a relative address. There is no difference between performing add R1, 5 # R1 += 5 then add [SP+1], 5 Especially if at the opcode executing level, R1 is defined as SP+R1_OFFSET Taking the register-spill analogy back to JITing. We don't know how big the CPU register set is at parrot compile-time, so we don't know what a good register-set-size is. x86's are sadly still treated as accumulators (even with x86-64), there are just too many cool compiler techniques that don't work unless you have 32+ GPRs, so it's hardly worth the effort to test for possible optimizations with only 8. On the other hand, IA-64 with 100+ GPRs can unroll loops and map temporaries like there's no tomorrow. The end result is that a dynamically sized register-set is probably the ideal for a VM. If the compiler can assume that you have as many registers as you need, but is given the constraint of please try to not use any more than you absolutely need (a la generic chaitin or Chow (basic-block based)), then in the rare case that an Itanium is in use, a full register mapping can occur. If we need to resort to accumulatoring, then you can utilize a raw vmStackFrame + offset, wheren vmstack is register. It's also possible (albeit not as obvious) to have a hybrid of map first n variables to physical registers for the common case of 32reg machines. Now in the case of Parrot, our stack (last I checked) was not homogeneous, so this simplistic case wouldn't work well. But there are two solutions that immediately occur to me. Soln A) Treat the datatype as trusted-opaque, and large enough to handle the largest data-type. e.x. iadd R1 = R2, R3 sconcat R4 = R5, R6 etc.. We merely trust that the compiler won't mix and match data-types into offset assignments. We would still, of course need to properly handle gc-DOD through the stack, so we couldn't be completely opaque. Input parameters to functions would have to either be staticly sized, or there would have to be a special op-code to access dynamically-sized input parameters of unknown types. A simple opcode regAlloc(numInputRegs, numLocalRegs) would shift the frame pointer such that numInputRegs become regs 1..numInputRegs, and the locals become numInputRegs .. numInputRegs+numLocalRegs. This is somewhat similar to the Itanium register-allocating style. Soln B) Have a multitude of homogeneous stacks. This is identical to solution A, but trades complexity for performance. Namely, there would be: intStack fpStack strStack objStack The reg-allocation op-code would also require 4 pairs of sizes. Additionally, the compiler must maintain 4 seperate input/output/local variable-register mappings. The advantages are: * no problems with typecasting parameter problems * gcing is more efficient (garunteeded that all non-null refs found in str/obj stacks need DODing / dont need to test the stack-element-type on each iteration). * more properly maps to inter/floating point register sets.. The str/obj stacks need external referencing anyway. Well, again, just my $0.2. But I just felt the need to defend practical stack computing.
Re: Set vs. Assign..?
I sent something similar to this about 6 hours
ago but it never showed up so I think it
got spam filtered or something. :-/
Anyway, just to clear things up, here
is my take on 'set' and 'assign':
set: replace the reference in the
destination register
assign: don't change the reference in the
destination register; tell the currently
referenced object to assign itself a new
value.
You can think of integer and float registers
as holding references to objects whose values
cannot be changed (so it doesn't make
any sense to assign to integers or floats)
Things work out very nicely, this way.
Currently (as far as I am aware) IMCC uses the
= operator to mean both set and assign, which,
as I described above, are very different
operations. The rules for whether the =
operator implies set or assign semantics are
dependant on the semantics of the underlying
Parrot opcodes. Therefore, in order for the
programmer writing IMCC to know what their
P0 = P1 + P2 actually does, they must be very
familiar with the underlying opcodes. Not that
there's anything wrong with being familiar with
opcodes (you'd pretty much have to be to write
anything useful with IMCC), but for those operations
which IMCC has infix operators for, having to know
the rules for when = has set or assign semantics
defeats much of the purpose of using the infix
operators.
I have been proposing that there
be 2 separate = operators. One for set and one
for assign [1]. That way it is obvious
from looking at the code what the semantics are.
If there is no way to do what is written
('assign' a value to an integer, for instance)
then IMCC should exit with an error message
saying so, but what it shouldn't do is pretend
that the code says set-operator where the
author meant assign-operator.
I don't unferstand the logic of having one
operator having 2 different sets of semantics
depending on rules which are non-obvious
and very implementation-bound (P0 = P1 does
set, I0 = I1 + I2 does set, but P0 = P1 + P2
does assign. WTF?). As IMCC is meant to provide
a more abstract interface to Parrot, having
this (quite useless, as far as I can tell)
implementation-bound set/assign Semantic
Surprise(TM) business for = is a Bad Thing.
So far I have not heard any reason why there
shouldn't be 2 separate operators. I would be
MUCH more comfortable writing my compiler to
target IMCC if this change was made.
And so my question is:
Can anyone give me a good reason why things should
be kept the way they are? Or are there plans to
change IMCC to use 2 '=' operators?
[1] I don't really care what the operators look like,
but here are the 2 suggestions I've seen:
:= for set, = for assign
= for set, - for assign
Maybe a cross between these would be
even better, as = could then be depricated:
:= for set, - for assign
[2] Current code to proposed code, assuming
:= for set, - for assign
I0 = I1 + I2 ... I0 := I1 + I2 # set
P0 = P1 + P2 ... P0 - P1 + P2 # assign
I0 = P0 ... I0 := P0 # set
P0 = I0 ... P0 - I0 # assign
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
RE: [CVS ci] PackFile-15: print warning location
[EMAIL PROTECTED] writes:
Nicholas Clark [EMAIL PROTECTED] writes:
I think that it has practical uses for other, dimensionally inferior
languages. It would often be nice to know which bit of this line:
} elsif ($host =~ /([^.]+\.[^.]{3}$)/ || $host =~
/([^.]{4,}\.[^.]{2}$)/ ) {
generated the undefined warning
Even in C this things happen.
Could we get expression-level tagging by *character range* rather than
just line? Could be sweet for visual debuggers--hilight the expression
that's about to execute, even if the expression spans lines.
e.g., stepping through $x = 1 + f($y{z} + 3):
$x = 1 + f(%y{z} + 2)
^---^
^---^
^--^
^--^
^---^
Using just columns would get you this...
$x = 1 + f(%y{z} + 2)
^
^
^
^
^
And the question, Why'd the step button do nothing that first time?
Or maybe this...
$x = 1 + f(%y{z} + 2)
^
^
^
^
^
And the question, Huh?
Also good for setting breakpoints inside of behemoth Perl statements--I
have some function calls which are quite legitimately several pages
long--interpolations inside of heredocs, lots of parameters, etc. (I
consider it good style; the parameter comb much is clearer and more
succinct than building the equivalent parameter hash with multiple
statements. And it'll only get more attractive when P6's yummy new $()
makes interpolation even more convenient and powerful.) Not that a
debugger's ever worked worth snot with Perl 5, so anything's better than
what's going on now.
Speaking from some experience as a user: .NET does expression-level
hilighting, and it's WONDERFUL when it works. However, it seems to use
simple character offsets, which leads to it frequently going awry when I
make a change to the file. It's always seemingly either FABULOUS or
completely broken. Maybe character offsets from beginning of line would
be a less fragile. Or maybe stuff the whole of the source files into the
debugger segment--there's the fragility problem completely solved,
regardless of the use of line offset or file offset. (Of course, PIR
can't do that when just fed an IMCC assembly file...)
Seems straightforward for the compiler to emit character ranges as it
visits AST nodes. Would wind up with lots of line directives--but
there's no way around there, and it's not so hard.
$x = 1 + f(%y{z} + 3);
01234567890123456789012
0 1 2
TREE OP PIR
%y z
\ / #file -
{ } 2 { } #line 1[11] 1[16]
\ / set P3 = P2[z]
++ #line 1[11] 1[20]
|new P4, .PerlInt
|add P4, P3, 3
1 f() f() #line 1[9] 1[21]
\ / ... P5 - f(P4) ...
x + + #line 1[5] 1[21]
\ / new P5, .PerlInt
\ /add P5, 1, P5
= = #line 1[0] 1[22]
set P6, P5
This also gracefully degrades to simple line numbers, because #line n
would be trivially equivalent to #line n[0] (n+1)[0]. Good for lazy
compiler authors, or for distributing pbc files with debugging segments
someplace between NONE and 20-bytes per expression + source code.
(That's 20 bytes: { int bytecodeOffset, begLine, begChar, endLine,
endChar; }.)
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
P.S. - On column numbers, could we try to avoid having compilers be
aware of tab width settings?
Re: headers.pl
Vladimir Lipskiy [EMAIL PROTECTED] wrote: s/$inc/^$inc/; Thanks. leo
Re: Should I target Parrot?
Leopold Toetsch wrote:
Benjamin Goldberg [EMAIL PROTECTED] wrote:
inline op mthread_create(inconst INT) {
opcode_t *dest = PTR2OPCODE_T(CUR_OPCODE + $1));
PMC * p = new_ret_continuation_pmc(interpreter, dest)
Please note that the ret_continuation is intended for returning only,
not for executing code on. (it just has pointers to the original
interpreter context that get swapped in on invoke() - no COW copies like
the normal Continuation class)
Oops. I was writing this mostly by looking at core.ops, and I saw this
and thought that it was just a shortcut for creating a Continuation (one
line instead of two). Foolish me.
--
$a=24;split//,240513;s/\B/ = /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print [EMAIL PROTECTED]
]\n;((6=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))redo;}
Re: String API
On Thu, Aug 21, 2003 at 06:37:52PM -0400, Benjamin Goldberg wrote: Nicholas Clark wrote: Particularly when the regexp engine is written assuming O(1) random access. It doesn't *need* to assume O(1) random access; after all, it's never accessing *randomly*, it's always accessing just one character away from some other character that it's recently accessed. Sounds like a job for an iterator for me. With an iterator, it needs only assume that advancing the iterator a distance of 1, takes O(1) time. Probably true for the actual regexp engine. But I'm pretty sure that where perl wins (or won, historically - the world is catching up) was in the optimiser, which takes shortcuts and works out where things can't match. I suspect that that does think of things in terms of random character offsets, and independent of that I'm confident that thinking about one in O(1) is easier than thinking about one in O(n) But I've never written one, so who am I to say? Nicholas Clark
Re: Should I target Parrot?
Michal Wallace wrote:
On Thu, 21 Aug 2003, Benjamin Goldberg wrote:
I hope you aren't planning on serializing just a single isolated
microthread... that wouldn't work well with what I've got in mind due
to how much stuff comes along when you serialize a continuation --
you'd get almost the whole interpreter serialized.
If you want, instead, to serialize interpreter-microthreads,
however...
well, you'd *still* get almost the whole interpreter serialized, but
you're getting more bang for your buck :)
Well how else are we going to implement squeak? :)
Squeak uses synchronous communication channels, right? Writing blocks
until there's a reader, and reading blocks until there's a writer.
I just thought of a way of implementing such things for microthreads :)
Something like the following:
enum {
enum_state_none = 0,
enum_state_ready = 1,
enum_state_readers = 2,
enum_state_writers = 4,
};
pmclass SynchronousChannel {
void init() {
SELF-cache.int_val = enum_state_none;
PMC_data(SELF) = pmc_new(INTERP, enum_class_PerlArray);
PObj_custom_mark_SET(SELF);
}
void mark() {
pobject_lives(INTERP, PMC_data(SELF));
}
void push_pmc(PMC *the_val) {
if( SELF-cache.int_val enum_state_ready )
internal_exception(???, Illegal state\n);
SELF-cache.int_val |= enum_state_ready
VTABLE_push(INTERP, PMC_data(SELF), the_val);
}
PMC * shift_pmc() {
if( !(SELF-cache_int_val enum_state_ready) )
internal_exception(???, Illegal_state);
SELF-cache_int_val = ~enum_state_ready
return VTABLE_pop(INTERP, PMC_data(SELF));
}
void* invoke(void* next) {
PMC * data = (PMC*)PMC_data(SELF);
PMC * cont;
switch( SELF-cache.int_val ) {
case enum_state_ready:
case enum_state_ready|enum_state_writers:
case enum_state_ready|enum_state_readers:
case enum_state_none:
case enum_state_readers:
cont = pmc_new(INTERP, enum_class_Continuation);
VTABLE_set_integer_native(INTERP, cont, (INTVAL)next);
break;
}
switch( SELF-cache.int_val ) {
/* ready means we're trying to write data */
case enum_state_ready:
case enum_state_ready|enum_state_writers:
/* if there are no readers, suspend ourself */
SELF-cache.int_val = enum_state_writers;
VTABLE_push_pmc(INTERP, data, cont);
break;
case enum_state_ready|enum_state_readers:
/* otherwise, stay awake, and wake up */
/* (and switch to) a reader. */
VTABLE_push_pmc(INTERP, interpreter-microthreads, cont);
cont = VTABLE_shift(INTERP, data);
if( VTABLE_get_integer(INTERP, data) == 1 )
/* Remove _readers flag */
SELF-cache.int_val = enum_state_ready;
return VTABLE_invoke(INTERP, cont);
/* not-ready means we're trying to read data */
case enum_state_writers:
/* if data has been written, we stay awake, */
/* and we wake up the writer who wrote. */
SELF-cache.int_val = enum_state_ready;
VTABLE_push_pmc(INTERP, interpreter-microthreads,
VTABLE_shift(INTERP, data));
if( VTABLE_get_integer(INTERP, data) 1 )
SELF-cache.int_val |= enum_state_writers;
return next;
case enum_state_none:
SELF-cache.int_val = enum_state_readers;
/* fallthrough */
case enum_state_readers:
/* If no data has been written, we suspend ourself */
VTABLE_push_pmc(INTERP, data, cont);
break;
case enum_state_readers|enum_state_writers:
case enum_state_readers|enum_state_writers|enum_state_ready:
internal_exception(???, Illegal state);
break;
default:
internal_exception(???, Illegaller state);
break;
}
if(!VTABLE_get_integer(INTERP, interpreter-microthreads))
internal_exception(???, Deadlock!);
cont = VTABLE_shift(INTERP, interpreter-microthreads);
return VTABLE_invoke(INTERP, cont, next);
}
}
Writing to a channel is done with:
push $Pchannel, $Pdata
invoke $Pchannel
Reading from a channel is done with:
invoke $Pchannel
shift $Pchannel, $Pdata
We can detect when the whole system is deadlocked, since -microthreads
becomes empty.
A partial deadlock, though, is undetectable, since there's no way to
know whether or not one of the 'live' threads might happen to write to
one of the channels that the deadlocked threads are reading from, or
might happen to
Re: Weak References?
Juergen Boemmels wrote: Benjamin Goldberg [EMAIL PROTECTED] writes: I would like for Parrot to have some way of creating Weak References; I think that this is probably a vital feature. The way I envision this is as follows. The following typedef and new function would be added: typedef void (*pobject_died_cb)(INTERP, PMC* who_asked, Pobj* weakref, void *callback_info); void pobject_weakref(INTERP, pobject_died_cb callback, Pobj* weakref, void *callback_info); This might be sometimes useful. Keeping a container of active objects like filehandles or windows for example. In this case it can't mark the reference because this would make the object active forever. Inside of a PMC*'s mark method, it registers callbacks (using the above function) so that it will be informed about what to do if the object to which it weakly refers to is found to not be alive at the end of the DOD sweep.
Re: Weak References?
Juergen Boemmels wrote: Benjamin Goldberg [EMAIL PROTECTED] writes: I would like for Parrot to have some way of creating Weak References; I think that this is probably a vital feature. The way I envision this is as follows. The following typedef and new function would be added: typedef void (*pobject_died_cb)(INTERP, PMC* who_asked, Pobj* weakref, void *callback_info); void pobject_weakref(INTERP, pobject_died_cb callback, Pobj* weakref, void *callback_info); This might be sometimes useful. Keeping a container of active objects like filehandles or windows for example. In this case it can't mark the reference because this would make the object active forever. Inside of a PMC*'s mark method, it registers callbacks (using the above function) so that it will be informed about what to do if the object to which it weakly refers to is found to not be alive at the end of the DOD sweep. This does not need to go into the mark function. The weakref_callback code can be called inside the destroy function. Im not sure if it should be called befor or after the custom destroy-function is run. And is the order of the weakref_callbacks defined. The pobject_weakref function first checks if the 'weakref' argument has been marked as alive -- if so, nothing happens. Then, it adds the Pobj* to a lookup table, pointing from the Pobj*, to a list of registered callbacks for that Pobj*. This is far to complicated. Each object has a list of destroy-functions, one of them is the costom-destroy function the others are the weakref-callbacks. But suppose that at the end of DoD, the object we're weakly referring to gets marked as alive? Now, we would need to look through that object's list of destroy-functions, and remove all of the weakref-callbacks. But if the weakref-callbacks are stored in a seperate data structure, created during DoD, then there's no problem; this data structure will get re-created for each DoD pass, and thus always start empty. Also, by keeping them seperate, we can walk all the callback functions before destructing the dead objects. (But you're right -- it is too complicated to do a lookup table. A simple linked list should do fine.) But one other thing, what happens if the object holding the weakref dies before the refrenced object? Then the callback-function will be called for a dead object. Each callback-function belongs to a pmc. The DoD should be able to know this, and act on it. So if the pmc which registered the callback is dead, (or if the object weakly referred has since then come alive), then the callback isn't called. So pobject_weakref() needs to return a handle for the weakref and there needs to be a function weakref_destroy(weakref_handle *handle). Other issue is who owns the data_structure of the weakref? The referent, the referee, or will this be garbage-collected (which makes the weakref_handle a PObj* and weakref_destroy its custom destroy function. The garbage collector owns everything except for callback_info, which belongs to the pmc which registered the weakref-callback. After DOD finishes, the lookup table is walked; for each entry whose Pobj* hasn't been marked as alive, the callbacks are called. The effect of this of course is that a WeakRef has no cost except during Dead Object Detection. It only has a cost at object destroy-time. (If the weakrefs are garbagecollected they have an effect on DOD in the way that there are more objects to trace) *blink* More objects? Oh, you're assuming that pobject_weakref is returning a Pobj* handle. Keeping the callback data in a seperate list which only exists for the duration of the dod prevents this. Or rather, you do have to clean up the linked list, of course, but there's no extra bookkeeping. The first, perhaps most important use, would be to implement a string-interning table. You'd have a global (per-interpreter) pmc which contains a hashtable of cstrings to perlstrings; if the cstring is present, the corresponding perlstring is returned; otherwise a new perlstring would be created and added to the table, then returned. If any of the perlstrings go out of scope, then their hash entries should disappear from the table. Obivously, if the table contained normal references to the strings, then they won't ever go out of scope. And if the table simply doesn't mark them as alive, it wouldn't know when they're dead. But with weakrefs, this is easy. this is only useful if a hashlookup is fast compared with string_make. Well, it might be. Hashing can be quite fast, ya know. Here's a better idea, one you'll have more difficulty arguing with -- imagine a debugger, written in parrot. We are going to have one, right? Hmm, p6tkdb :) It needs to keep references to objects it's interested in, but if they're strong references, then we would have trouble debugging objects with custom destroys (or worse, objects
cancel 3F46B0AD.F217054@hotpop.com
This message was cancelled from within Mozilla.
Re: Weak References?
Benjamin Goldberg writes: Juergen Boemmels wrote: Benjamin Goldberg [EMAIL PROTECTED] writes: The pobject_weakref function first checks if the 'weakref' argument has been marked as alive -- if so, nothing happens. Then, it adds the Pobj* to a lookup table, pointing from the Pobj*, to a list of registered callbacks for that Pobj*. This is far to complicated. Each object has a list of destroy-functions, one of them is the costom-destroy function the others are the weakref-callbacks. But suppose that at the end of DoD, the object we're weakly referring to gets marked as alive? Now, we would need to look through that object's list of destroy-functions, and remove all of the weakref-callbacks. But if the weakref-callbacks are stored in a seperate data structure, created during DoD, then there's no problem; this data structure will get re-created for each DoD pass, and thus always start empty. Also, by keeping them seperate, we can walk all the callback functions before destructing the dead objects. (But you're right -- it is too complicated to do a lookup table. A simple linked list should do fine.) I may be missing the problem that you are talking about, but it seems to me that since we have PMCs which mark themselves instead of being automatically marked, a WeakRef PMC would be trivial... I don't think it needs to be any more fundamental than a PMC. Luke
Re: [CVS ci] PackFile-15: print warning location
Juergen Boemmels wrote:
Leopold Toetsch [EMAIL PROTECTED] writes:
Further:
The Csetline and Csetfile opcodes are suboptimal, they impose
runtime penalty on each run core, so they will go finally. The
Cgetline and Cgetfile can map to the functionality used in
warnings.c.
Normal processors also don't have setline and setfile operations. They
use an extra segment in the *.o file, which is only used by the
debugger. This could also be done in parrot.
In other words, setline and setfile ops in source don't translate to
actual ops in the bytecode, but instead translate to additions/changes
to the debugging segment?
We just need to settle on a format for the line-info bytecode segement.
The only question is reinvent the wheel, or use an already establiched
format (stabs or DWARF).
And finally: Parrot will (again[2]) track HLL source line info like:
#line 17 sourcefile.p6
So that warnings and errors can be located in HLL source too.
I don't like this syntax -- it sounds too easy for someone to write a
comment like:
#When this was in the original foobar language, it was on
#line 17
And have it interpreted as a directive, when the author meant for it to
be just a comment.
There's no reason not to have the directives look like ops (setline,
setfile).
Oh, and you could have get{line,file} directives, which end up
translated as being simple set ops, using the info generated by the
set{line,file} directives.
It might be nice to have column information to. This would make
debugging of Befunge programs a lot more easy. Also it would be nice
to have blocks of code (many pasm-lines) with just one linenumber, and
otherwise have a possiblity to increase the source-line with each line
of pasmcode.
I like the ideas of a range of characters, and of variable amount of
information. So, how about multiple setline variants?
setline Ix # all code from here to the next set{line,file} op is line
x
setline Ix, Iy # set line,col number from here to next set* op.
setline_i Ix # the next line is x, each succeeding line increases.
setlinerange Ix, Iy # the following represents lines x..y of hll
code.
setlinerange Ix, Iy, Iz, Iw # line x, col y .. line z, col w.
setfile Sx # sets filename from here to next setfile op.
There'd be a corresponding get* function for each of these except for
setline_i (for which it wouldn't make sense), which would get translated
at compile time to set Ix, 12 or whatever. There should be a C-code
level interface to go (at runtime) from a pointer to bytecode (or from a
bytecode offset) to a file, line, or range of lines, or ... with
columns; this would be useful for debuggers.
--
$a=24;split//,240513;s/\B/ = /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print [EMAIL PROTECTED]
]\n;((6=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))redo;}
Re: [CVS ci] PackFile-15: print warning location
According to Benjamin Goldberg: #line 17 sourcefile.p6 I don't like this syntax -- it sounds too easy for someone to write a comment like: #When this was in the original foobar language, it was on #line 17 Do you worry about Perl too? Because Perl already has this. Funny how we don't get complaints. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early. // MST3K
Re: [CVS ci] PackFile-15: print warning location
Benjamin Goldberg [EMAIL PROTECTED] writes:
I like the ideas of a range of characters, and of variable amount of
information. So, how about multiple setline variants?
setline Ix # all code from here to the next set{line,file} op is line
x
setline Ix, Iy # set line,col number from here to next set* op.
setline_i Ix # the next line is x, each succeeding line increases.
setlinerange Ix, Iy # the following represents lines x..y of hll
code.
setlinerange Ix, Iy, Iz, Iw # line x, col y .. line z, col w.
setdim Ix # sets number of dimensions for subsequent code
setvel Px # set code velocity (general setline_i; Px is an Array)
Just making sure Parrot debug info can support Jerome's trefunge
interpreter.
/s
RE: [CVS ci] PackFile-15: print warning location
Leopold Toetsch: # And finally: Parrot will (again[2]) track HLL source line info like: # ##line 17 sourcefile.p6 Why create a new directive syntax when we already have one? .line 17 sourcefile.p6 --Brent Dax [EMAIL PROTECTED] Perl and Parrot hacker Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna set myself on fire to prove it.
