Re: [perl #24177] [PATCH] Make Parrot dlcompat aware on OS X
Sorry I was on holiday. Yes this can be closed.
On 21 Sep 2005, at 09:45, Joshua Hoblitt via RT wrote:
[mikescott - Thu Oct 09 11:49:45 2003]:
If someone happens to have dlcompat
http://www.opendarwin.org/projects/dlcompat/
installed on OS X then the following patch will let Parrot be
aware of
this and use it.
The following changes are made:
config/auto/headers.pl
Add dlfcn.h to @extra_headers so it will be detected even if
dlcompat
has been installed after Perl.
config/gen/platform/darwin.c
Add conditional code for PARROT_HAS_HEADER_DLFCN.
config/init/hints/darwin.pl
Add values for libs and so.
dynext.c
Replace SO_EXTENSION with PARROT_DLL_EXTENSION which is already
defined in config.h.
nci_test.c
Remove #include malloc.c because it is unused.
t/pmc/nci.t
Remove the $PConfig{jitcpuarch} eq 'i386' condition from the SKIP
conditional.
conf/gen/makefiles/root.in
Change libnci.so target to libnci and use $(SO).
Running
make libnci
perl t/harness --running-make-test --gc-debug t/pmc/nci.t
passes all tests with this patch applied.
Is this still an issue?
-J
Maybe I'm back
Hello all, Maybe some of you remember how I used to have endless hours in Berlin to fiddle with Parrot documentation. Then I got a job, moved back to London, and disappeared. I can't say I have been following the list closely, but I have read the occasional summary from time to time. I'm out of touch, but curious again. Now I know, promises are worthless, but I have been thinking of putting a Getting Started Guide together again. In the process of poking around in the subversion checkout I noticed that write_docs.pl was broken. I fixed it. (What is a .bundle file anyway?) Maybe some kind soul could shortcut me to how/where I check in the changes. Mike
Everything Parrot
I've had this list lying around for too long, but never seem to find time to make it all shiny and complete. I want to have another go at the html documentation. But before I start I'd prefer to have a good list of everything Parrot. That way I can build a proper subject view of the project. It would be nice if people just email me what I've missed. I'm hoping if folk just state what's obvious to them I'll get good coverage. I've put it on the wiki as well, so if you prefer to edit that, fine by me. http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/EverythingParrot =head1 Subsystems and Resources =head2 Memory Allocation Resource pools =head2 Registers and Stacks Register sets Frame stacks Int stack User stack Pad stack Control stack Regex stack =head2 PMC Internal structure (PObj, Buffer, PMC_EXT) Vtables PMC hierarchy and (multiple) inheritance Abstract PMCs Dynamic PMCs Serialization (Freeze/Thaw and Dumper library) Constant PMCs PMC template creation Loading and initialization sequence Descriptions of individual PMC types (probably discussed under separate subjects) How to create a specific type of PMC using Parrot Extensions interface Assignment in PASM/PIR C macros Null PMC Layering Morphing Properties =head2 Interpreter [...] =head2 Exec [...] =head2 Debugging [...] =head2 Big Number Arithmetic Decimal Arithmetic =head2 Namespaces Separators =head2 Dead Object Detection (DOD) and Garbage Collection (GC) Mark and sweep (?) Timely destruction (?) ARENA_DOD_FLAGS =head2 Copy on write (COW) [...] =head2 Parrot Operations (Ops) Call and return conventions Variable length parameter lists Opcode numbering =head2 Subroutines Closures Coroutines Continuations =head2 Multi-Method Dispatch Rules for method resolution =head2 Objects Classes and metaclasses =head2 Keys Keyed access =head2 Threads Thread safety =head2 IMCC and PIR [...] =head2 PASM [...] =head2 Events [...] =head2 Parrot Strings Unicode ICU =head2 Native Call Interface (NCI) [...] =head2 Just-in-time compilation (JIT) [...] =head2 Exceptions [...] =head2 Miniparrot [...] =head2 Extensions Interface [...] =head2 Embedding Interface [...] =head2 Bytecode Packfile format Metadata =head2 IO Asynchronous IO stat =head2 Lexical Scope and Scratchpads [...] =head2 Regular Expressions =head2 Libraries SDL ncurses Postgres PCRE Dynamic opcode libraries Includes =head2 Configuration Configure.pl Initialization User Dialogues System Tests File Creation =head2 Building and Installing make =head2 Editor plugins Emacs VIM Kate =head1 Subjects orthogonal to subsystems =head2 Platform Specifics PLATFORMS cygwin mingw =head2 Tests Writing tests Parrot::Test make arguments =head2 Benchmarks and Optimization [...] =head2 Examples [...] =head2 C source code Coding standards typedefs Macros =head2 Perl source code CPAN Modules =head2 Documentation Uppercase named text files POD General Documentation Specific Documentation Development Documentation PMC Documentation Perl Design Documents (PDD) Parrot::Docs modules =head1 Things outside the distribution =head2 CVS Parrot source code repository access CVS Monitor =head2 Related projects Ponie Pirate mod_parrot YAL OpenComal Russian documentation Perl 6 regular expressions Parrot on Windows (POW) =head2 Resources Perl6 internals mailing list and its weekly summary Tinderboxes Perl6 Essentials (O'Reilly) =head1 Languages which target Parrot =head2 How to target Parrot [...] =head2 Languages in the Parrot distribution Perl6 Jako BASIC Regex TCL Cola Scheme URM Ruby miniperl Befunge BF Ook! PLOT Python Forth PASM
Re: [perl #29302] [PATCH] Invalid HTML doc links for Win32 Firefox
I've checked in some changes which fix this. I would would like to close the ticket but I can't. For some reason when I log in to RT as mikescott I have zero visibility/permission. Logging in as guest solves the visibility but not the permission problem. I've raised this issue before but no one seems to pick it up. Mike On 1 May 2004, at 18:32, Philip Taylor (via RT) wrote: # New Ticket Created by Philip Taylor # Please include the string: [perl #29302] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=29302 On a Windows system, File::Spec returns paths with backslashes. The HTML documentation generator (write_docs.pl etc) uses these paths in the HTML code, resulting in links like a href= docs\pdds\pdd00_pdd.pod.html.../a IE handles these with no problems. Firefox (0.8) follows the link to the right place, but then refers to itself as something like file:///e:/parrot/cvs/parrot/docs/html/ docs%5Cpdds%5Cpdd00_pdd.pod.html (apparently forgetting that it used to think \ was a path delimiter and now considering it part of the filename) and so all the relative links in that page, like a href=..\..\../html/index.htmlContents/a (as well as all the images and stylesheets) are incorrect. All appears to work (in IE and Firefox) after changing relative_path() in lib/Parrot/IO/Directory.pm to replace backslashes with forward-slashes before returning. (The same can be achieved by altering the two link-generating bits in lib/Parrot/Docs/Item.pm, but I have no idea whether that would be a better place to do it.) -- Philip Taylor [EMAIL PROTECTED] Index: parrot/lib/Parrot/IO/Directory.pm === RCS file: /cvs/public/parrot/lib/Parrot/IO/Directory.pm,v retrieving revision 1.9 diff -u -b -r1.9 Directory.pm --- parrot/lib/Parrot/IO/Directory.pm 27 Mar 2004 22:22:54 - 1.9 +++ parrot/lib/Parrot/IO/Directory.pm 1 May 2004 17:00:40 - @@ -161,7 +161,9 @@ $path = $path-path if ref $path; - return File::Spec-abs2rel($path, $self-path); + my $rel_path = File::Spec-abs2rel($path, $self-path); + $rel_path =~ tr~\\~/~; + return $rel_path; } =item Cparent()
Re: Events (I think we need a new name)
On 12 May 2004, at 17:38, Brent 'Dax' Royal-Gordon wrote: It's Parrot telling you that something happened. Squawk? Mike
Re: writing PMCs (documentation)
I just moved from Berlin to London and started a new job, so haven't had time recently for Parrot documentation. Indeed there is plenty to be done. I should be back on the case in a week or two. Mike On 7 May 2004, at 17:13, Simon Glover wrote: No. The closest we have to something like this is probably the stuff written by Mike Scott for the Wiki: http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/ParrotDiagramsPMC
Re: Plans for string processing
On 14 Apr 2004, at 20:16, Larry Wall wrote: I think the idea of tagging complete strings with language is not terribly useful. If it's to be of much use at all, then it should be generalized to a metaproperty system for applying any property to any range of characters within a string, such that the properties float along with the characters they modify. The whole point of doing such properties is to be able to ignore them most of the time, and then later, after you've constructed your entire XML document, you can say, Oh, by the way, does this character have the toetsch property? There's no point in tagging text with language if 99% of it gets turned into Dunno, or English, but not really. It seems natural to associate language with utterances. When these utterances are written down - or as I'm doing here, skipping the speaking part and uttering straight to text - then the association still works. But once we start emitting written things (strings) in a less aural way, then the notion of an associated language can easily become forced or inaccurate. The process whereby we read a string like Is bthis/b string in Englisch? is generally a kind of lossy conversion to our language of preference for that particular string. It's very difficult for us to do otherwise. This natural generalization means that there will always be a demand for strings to have language associated with them, no matter how illogical it may seem to those who reflect upon it a bit. I think it is this user state that Dan is trying to support. And, in so far as it models natural and common perception, I think I agree with him. Lossy conversion is a kind of info-sin, especially when it should be avoided. There are circumstances where it would be more natural to read the above string as Is open-bold-tag this close-bold-tag string in the-German-word-for-English question mark i.e. when we are being more precise. It is for this more precise user state that we would be preserving information on substrings. There are plenty of strings which are simply never intended to be uttered, and therefore are effectively language-less. And many strings obviously in particular languages are often treated as if they weren't. It would be odd to submit the processing of such strings to a requirement of non or useless information preservation. Any sensible user would want to turn off language processing in such cases. So, we need to ask the user their state, and have the necessary level of support in place to be able to behave accordingly. Looking at this from an object-oriented perspective I can't help but wonder why we don't have a hierarchy of Parrot string types String LanguageString MultiLanguageString with a left wins rule for composition. Mike
Re: Plans for string processing
On 13 Apr 2004, at 23:43, Dan Sugalski wrote: I've been assuming it's a left-side wins, as you're tacking onto an existing string, so you'd get English in all cases. Alternately you could get an exception. The end result of a mixed-language operation could certainly be the Dunno language or the current default--both'd be reasonable. Would I be right in thinking that *language* in the context of Parrot strings is not necessarily an accurate description of the actual language of the string, but rather a means of specifying a particular set of idiosyncratic behavior normally associated with an actual language? An english string continues to behave in an English way regardless of what I append to or insert into it. Is there ever a situation where the contents of the appended/inserted strings are altered because of the change in *language*? In other words, are there any *language* (as distinct from character set) transforms? And, can new *languages* be defined? For example, will there be a way to define a *language* toetsch where 'ro' becomes '0r' in 'b0rken', and 'see' becomes 's.'? Mike
Re: Plans for string processing
On 12 Apr 2004, at 17:43, Dan Sugalski wrote: IW: Mush together (either concatenate or substr replacement) two strings of different languages but same charset TP: Checks to see if that's allowed. If not, an exception is thrown. If so, we do the operation. If one string is manipulated the language stays whatever that string was. If a new string is created either the left side wins or the default language is used, depending on the interpreter setting. Does that mean that a Parrot string will always have a specific language associated with it? Mike
Re: Plans for string processing
On 13 Apr 2004, at 22:48, Dan Sugalski wrote: Note that the language might be Dunno. :) There'll be a default that's assigned to input data and suchlike things, and the language markers in the strings can be overridden by code. Would this be right? English + English = English English + Chinese = Dunno English + Dunno = Dunno + being symmetric. How does a Dunno string know how to change case? Mike
Re: Plans for string processing
Just thought I'd mention that I'm in the process of trying to get strings.pod updated to reflect the current state of affairs. Mike
number.t not skipped on OS X
I notice that on OS X t/native_pbc/number.t is no longer skipped and is failing. I'm wondering if this is intentional? Looking into this I noticed that 'make pdump' fails because it needs ICU. Here's a patch for config/gen/makefiles/root.in. root_in.patch Description: Binary data Mike
Re: number.t not skipped on OS X
On 10 Apr 2004, at 15:04, Leopold Toetsch wrote: Not only pdump. All utils built by make world. I'd suggest to include an $(ALL_PARROT_LIBS) to each target. + $(LIBPARROT) $(LIBICUCORE) $(LIBICUDATA) $(C_LIBS) instead of that. Ok. I'll do that and commit it. Mike
[DOCS] submissions.pod
Thanks to Will Coleda, I finally added docs/submissions.pod - how to submit bug reports, patches and new files to Parrot. Mike
[DOCS] Ops parsing
I've updated the docs for the ops parsing system. make html-clean; make html You'll find it under Perl Modules/Operations and Ops/Tools. Mike
Re: OpsFile hints - one more (perlish) task
I've been all over the ops2c system recently filling in the
documentation (it'll get committed this weekend sometime) so number 2
is something I can certainly do.
BTW is there a reason for the colon at the start of the hints?
Mike
On 27 Mar 2004, at 08:15, Leopold Toetsch wrote:
Opcodes normally have a specifier that indicates, if a register is
written to or only used, e.g.
null (out PMC)
An Cout register gets a new value at that point, the register
allocator can reuse this register because the old contents got
discarded. This information is necessary for the register allocator.
Now we have some opcodes, that implicitely set new values on a range
of registers or silently use a register (it has to exist).
clearp # set P0..P31 to PMCNULL
poptopi # set I16..I31 from I register stack
callmethod # use existing P0, P2, S0
callmethodcc # use existing P0, P2, S0, create new P1
There are currently some hacks inside imcc[1], to handle some of these
opcodes but opcodes change faster then the code, so I'd rather have
this autogenerated from e.g.:
op clearp () :base_core,out=P0-P31
op callmethodcc :object_base,in=P0,P2,S0,I0-I4,out=P1,I0-I4
I'm not sure yet, if register stack store operations do need a hint:
pushbottomp# doesn't care if a register is valid or not
OTOH the equivalent pop definitely sets all P0..P15.
So that's part one - annotate the opsfiles.
2) is parse this information and generate bitmasks for the
Cop_info_t structure defined in Finclude/parrot/op.h.
That would be something like:
int {in,out}_{I,S,P,N}_argdir; # 1 bit per register per in/out
per kind
Thanks,
leo
[1] s. imcc/instructions.c: 87 ff
[DOCS] lib/Parrot
Just committed some new docs for the Parrot::* modules. make html-clean; make html Mike
ops2c
I'm trying to write some documentation for the ops2c system at the moment and have a question. In Parrot::OpsFile::read_ops() a Parrot::Op's type is set to 'inline' or 'function', yet in Parrot::Op type is expected to be 'auto' or 'manual'. Auto ops have a 'goto NEXT()' appended to their code. In src/op.h there is a comment which notes that op type is unused. Can anyone summarize the history/future of this? Mike
Manifest test failing
languages/tcl/.cvsignore is the only .cvsignore in the MANIFEST and a fresh checkout is failing with t/src/manifest..ok 2/4# Failed test (t/src/manifest.t at line 51) # Missing files in CVS: # languages/tcl/.cvsignore I assume this means languages/tcl/.cvsignore should not be in the MANIFEST. Mike
Re: Perldoc issues
On 16 Mar 2004, at 05:21, Will Coleda wrote: [...] If the =head3 is the culprit, then: ./Configure.pl ./docs/debug.pod ./docs/dev/dod.dev ./docs/ops/rx.pod ./docs/pdds/pdd11_extending.pod ./docs/pmc/subs.pod ./imcc/docs/calling_conventions.pod ./imcc/docs/imcfaq.pod ./languages/regex/docs/regex.pod ./ops/rx.ops Rejigging the pod a bit I have removed =head[34] from the above. Mike
Re: [DOCS] Documentation tools
On 6 Mar 2004, at 05:31, Robert Spier wrote: [...] The problem isn't today. It's the trend and next month, when someone decides they need to add some other module, and has a precedent to follow. Then, suddenly we end up with 30 different modules included in our distribution, each one changed slightly from the CPAN one. Dual-lifed modules that live with perl5 are hard enough. I shoved Pod::Simple in because I had problems with the Pod modules in the Perl distribution and the people on pod-people assured me Pod::Simple was the way to go. It was the soft option, i wanted people to be able to build the html docs easily, and I took the existence of the other modules in lib as examples of how to go about it. So, yes, precedent is the problem. Which is why I'd prefer if we could decide what the rule is and apply it to Pod::Simple etc* now, so that it sets the correct precedent. I have held off modifying it, so that it can be removed if necessary. Also, Dan, is it inherently bad to to install perl modules off the 'net, or, just bad for Parrot's config to do it? Would it be acceptable for write_docs.pl to do it? Or, do you mean that the distribution has to be complete in itself, so that it can be installed off a cd on a network-less box and run? Lastly, if we use Leo's prominent notes approach, is that note in the end not just going to be: To install the additional Perl modules required by Parrot run the following command in a shell: perl -MCPAN -e 'CPAN::Shell-install(Parrot::Bundle) Mike [*] Class::Struct has been patched to work with 5.005_03. Digest::Perl::MD5 is unmodified except where I changed the bang perl line. Parse::Parse::RecDescent has been modified for perl6. Pod::Simple unmodified. Test::More, only Test::Builder has been modified. Text::Balanced is unmodified.
[DOCS] hyperlinks
Fpath/file and CPerl::Module now become links in the HTML docs, if the target file contains POD. make html-clean make html Mike
Re: [DOCS] Documentation tools
On 7 Feb 2004, at 00:53, Michael Scott wrote: On 6 Feb 2004, at 22:32, Leopold Toetsch wrote: - icu - lib/Test/* - lib/Pod/* are all standard thingys. I'm not thinking that we are gonna reinventing wheels nor that we are gonna copying existing wheels, so I'd vote for just removing all that from CVS. yep All non-trivial packages have some preliminaries. Some prominent notes in README and INSTALL can provide the necessary steps, how to get that source. I'd like to see Configure.pl say what's needed, and do what it can to help if requested. I'd like to remove non-modified, non-parrot Perl modules from lib and install them via CPAN.pm. I have a version here which works, but I remember from experience it can be tricky to set up CPAN.pm to work behind firewalls, so I'm wondering what collective wisdom has to say. Should we run CPAN.pm from Configure.pl or rely on prominent notes? Mike
Re: [DOCS] Documentation tools
On 4 Mar 2004, at 15:51, Dan Sugalski wrote: [...] I'd like to remove non-modified, non-parrot Perl modules from lib and install them via CPAN.pm. No. Sorry, definitely not. Parrot's config isn't going to install perl modules off the 'net any more than it's going to run apt-get on systems that support it. We either provide it or do without. Which is how I originally looked at it when I added Pod::Simple. But then Robert asked why are we including CPAN modules that we are not likely to change into the parrot repository?, and Leo suggested the prominent notes approach, which left me with the impression that this was something that had to be dealt with. So, do I just leave Pod::Simple there? Mike
Re: www.parrotcode.org/ points to 0.0.10
I just reported this as a bug on Pod::Simple::HTML. The problem is in line 168-9 my $out = $to if defined $to and length $to; $out .= # . $section if defined $section and length $section; One of those Deprecated use of my() in conditional cases they've been talking about on perl5-porters. my $out; $out = $to if defined $to and length $to; $out .= # . $section if defined $section and length $section; fixes it. Looks like we'll be modifying Pod-Simple after all. Mike On 4 Mar 2004, at 20:33, Robert Spier wrote: In a similar(?) vein, www.parrotcode.org/faq/ currently has a number of broken links, including apocalypses, PDD6, and Java bytecode to Parrot bytecode. This is because the links are funny. The best way to get proper links is to do something like: LThis is CNN|http://www.cnn.com That's not great.. but it tends to render better. Our official Pod renderer is Pod::Simple::HTML, so you can test it out. I'm throwing this back to p6i, so somebody can fix it, and maybe take another pass through the FAQ, addming more F.. A... Q...s ;) -R
Re: [perl #27308] [PATCH] split entry for BASIC in LANGUAGES.STATUS
Applied. I would close the ticket but RT tells me I have no permission to view it. Mike On 2 Mar 2004, at 14:34, [EMAIL PROTECTED] (via RT) wrote: # New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #27308] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27308 This patch modifies ./languages/LANGUAGES.STATUS, breaking the current BASIC entry into separate BASIC/compiler and BASIC/interpreter entries. Why? The ./languages/BASIC directory has two independent subprojects, ./languages/BASIC/compiler and ./languages/BASIC/interpreter, with independent statuses. So LANGUAGES.STATUS needs independent entries for them. BASIC author Clint Pierce approved the change. Mitchell --- ./languages/LANGUAGES.STATUS Mon Jan 26 05:13:59 2004 +++ ./languages/LANGUAGES.STATUS.new Mon Mar 1 13:44:41 2004 @@ -5,7 +5,14 @@ description, (S) status, (M) maintained, (V) minimum Parrot version required. -N: BASIC +N: BASIC/compiler +A: Clint Pierce +D: BASIC Compiler +S: Functional, includes samples such as Eliza and Hunt the Wumpus +M: Yes +V: 0.0.11 + +N: BASIC/interpreter A: Clint Pierce D: BASIC Interpreter written in pure Parrot S: Functional, includes samples such as Eliza and Hunt the Wumpus
[DOCS] make html
I've added two targets to the Makefile. html: Generate HTML documentation from POD in the sources. html-clean: Remove the HTML documentation. Mike
Re: www.parrotcode.org
On 29 Feb 2004, at 03:07, Robert Spier wrote: [...] Someone else can take care of this for him. (And I know he'd love it if someone stepped forward to become official web content maintainer.) We'll provide that person with resources and support, and it'll be quite fun and easy for everyone. Well, I'd like to be able to integrate the autogenerated html docs that I've been working on with the website content, so it makes sense for me to volunteer. What next? Mike
Re: release preparation: odd file permissions, #!'s, ^M's, and README
On 26 Feb 2004, at 18:57, Mitchell N Charity wrote: A perl by any other name, may be a different perl. perl and /usr/bin/perl are both common in #!'s. I been changing them to #! perl -w when i find them, which is why your list covers the places I haven't visited. The good thing about the bang line is that it's parsed by perl and thus turns on warnings. I'll use your list to standardize the rest. Mike
Re: [CVS ci] PLATFORMS
Unfortunately until we get this solved those of us on dyslexic systems can't update our local copies. So I'm waving an URGENT flag here. After a bit of self-education on the CVS FAQ, I've come to the conclusion that renaming (delete/add) PLATFORMS to PLATFORMS.txt is the best way to solve this. Am I right or wrong? Let those with greater knowledge speak... Mike On 24 Feb 2004, at 01:31, Will Coleda wrote: my .cvsrc has update -dP, and I still get the same problem with the platforms directory. (OS X) On Monday, February 23, 2004, at 04:50 PM, Michael Scott wrote: I have this problem too. cvs [update aborted]: could not chdir to platforms: Not a directory Same problem even if I do a new check out. cvs [checkout aborted]: could not chdir to parrot/platforms: Not a directory There is no local platforms directory, yet CVS wants to go to it, so I assume the problem is coming from the server end. There is still a platforms directory on the server. http://cvs.perl.org/cvsweb/parrot/platforms/ Mike On 23 Feb 2004, at 19:56, Leopold Toetsch wrote: Jonathan Worthington [EMAIL PROTECTED] wrote: Leo, [did try to send off list, but it bounced] Please help me fill out the blanks by sending or committing patches. Please make sure to have the latest and best Parrot from CVS. Earlier today you popped a new file in CVS called PLATFORMS. Unfortunately, there is also a directory there called platforms. I don't have a directory named platforms in parrot root. You seem to be missing the -P switch to cvs update. $ find . -name platforms $ find . -iname platforms ./PLATFORMS Jonathan leo -- Will Coke Coledawill at coleda dot com
Re: [CVS ci] PLATFORMS
On 24 Feb 2004, at 15:06, Arvindh Rajesh Tamilmani wrote: Does the following command work? $ cvs co '!parrot/platforms' parrot # the order should be preserved. on tcsh it gives me cvs co '!parrot/platforms' parrot tcsh: parrot/platforms: Event not found. but on sh it did seem to do the trick. cvs co '!parrot/platforms' parrot ? parrot/docs/html U parrot/include/parrot/packfile.h U parrot/pf/pf_items.c U parrot/src/packfile.c M parrot/src/stack_common.c M parrot/types/bignum.c Many thanks. Mike
Re: [CVS ci] PLATFORMS
... and in tcsh (OS X) cvs co '\!parrot/platforms' parrot Mike
Re: [CVS ci] PLATFORMS
I have this problem too. cvs [update aborted]: could not chdir to platforms: Not a directory Same problem even if I do a new check out. cvs [checkout aborted]: could not chdir to parrot/platforms: Not a directory There is no local platforms directory, yet CVS wants to go to it, so I assume the problem is coming from the server end. There is still a platforms directory on the server. http://cvs.perl.org/cvsweb/parrot/platforms/ Mike On 23 Feb 2004, at 19:56, Leopold Toetsch wrote: Jonathan Worthington [EMAIL PROTECTED] wrote: Leo, [did try to send off list, but it bounced] Please help me fill out the blanks by sending or committing patches. Please make sure to have the latest and best Parrot from CVS. Earlier today you popped a new file in CVS called PLATFORMS. Unfortunately, there is also a directory there called platforms. I don't have a directory named platforms in parrot root. You seem to be missing the -P switch to cvs update. $ find . -name platforms $ find . -iname platforms ./PLATFORMS Jonathan leo
Re: CVS update warning
Done, thanks. On 22 Feb 2004, at 14:39, Arvindh Rajesh Tamilmani wrote: I didn't specify -kb when I added the images. I suppose that's it. $ cvs admin -kb file # corrects the repository $ cvs update -A file # updates the working copy should fix the problem. But I wonder how -kCOPY got into the repository in the first place. Is CVSROOT/cvswrappers wrong with something like: *.gif -k 'COPY' instead of *.gif -k 'b' Mike Arvindh __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools
Re: PDD status
All that metadata up front in the PDDs is a bit off-putting. I'm thinking of going through all of them and putting it at the end. Any objections? Also, throughout the distribution we use variously TITLE (aka TITEL) and NAME with and without the file path. I've been using =head1 NAME path/file - Short Description Any objections to standardizing on that? I'd cite (most of) Perl docs for precedent. In Perl modules path/file gets replaced by Package::Name. Mike On 21 Feb 2004, at 06:59, Simon Glover wrote: On Sat, 21 Feb 2004, Simon Glover wrote: OK, here's a rewritten version of PDD 0, which reflects my view of the role that the PDDs currently play in Parrot development. Comments welcome. Let's try that again, with the the PDD actually attached this time... Simon - =head1 TITLE Parrot Design Documents =head1 VERSION =head2 CURRENT Maintainer: Class: Meta PDD Number: 0 Version: 2 Status: Developing Last Modified: 20 February 2004 PDD Format: 1 Language: English =head2 HISTORY v2 substantially rewritten on 20 Feb 2004 by Simon Glover v1 created on 7 Dec 2000 by BCWarnock [EMAIL PROTECTED] v1 promoted to Developing as PDD 0 on 20 February 2001 by Dan Sugalski. =head1 CHANGES Substantially rewritten to reflect what the PDDs actually are (rather than what we hoped they would be 3+ years ago). =head1 ABSTRACT This document defines the standard format for the Parrot Design Documents (PDDs) - the basic descriptions/plans for the design of Parrot. =head1 DESCRIPTION The original intent of the Parrot Design Documents (which themselves were initially Perl Design Documents) was threefold: =over 4 =item 1 To provide a clear indication of the direction of current development (essentially, a road map from an abstract idea to a concrete implementation). =item 2 To act as a historical record of the rationale behind the decision, in order to provide context to future developers, who may not have been familiar with the original discussion. =item 3 To provide a historical, technical and cultural perspective for future development work. Re-implementation or even tangential tasks need only address what has changed since the original PDD. =back Needless to say, things didn't work out this way. Some of the context discussed above is now documented in the F*.dev documents (see the F/docs/dev directory); much of it remains undocumented. The portions that have wound up being documented as PDDs are the basic design of the Parrot interpreter. In other words, the PDDs describe the Bfeatures that the interpreter should implement. They Bshould not discuss the details of the actual implementation (unless they absolutely have to) or the choices leading to that particular implementation; these are details that should go in the relevant F*.dev file. On the other hand, they Bshould detail the trade-offs made in the actual design. =head1 IMPLEMENTATION All newly created PDDs will adhere to the PDD standard current as of the time of proposal. An example of the currently accepted layout is given in Fdocs/pdds/pdd_template.pod, which should be used as a template for any future PDDs. =head2 FORMAT All PDDs will be written in POD parseable by the current stable release of Perl. Although XML is a viable solution and has its vocal supporters, and although Parrot is intended to be used by many groups outside of the Perl community, we have chosen POD for its simplicity and ease of reading in plaintext form. Conversion to other formats (e.g. HTML) is encouraged, but the POD version should remain the master copy. All PDDs will be written in English. British, American, or Other is the choice of the author. Translation to other languages, like all Perl documentation, is encouraged. (See SLPDD TRANSLATIONS.) All PDDs will contain the following information: =over 4 =item TITLE: A short, general description of a specific part of the Parrot design. This may be a particular subsystem (e.g. the garbage collector), or a more general topic (e.g. basic Parrot datatypes). =item VERSION: Contains current and selected historical metadata on the PDD itself. =item CURRENT: Contains the following information, current as of the date of submission. =over 4 =item Maintainer Required. The name and current email address for the point of contact for the PDD. This is the person to whom questions, comments, and patches should generally be addressed. This need not be the author of the document. (In practice, non-trivial changes to the PDDs should probably be discussed on the perl6-internals mailing list before they take place). =item Class Required. The area of Parrot the PDD covers. This allows related PDDs to be logically grouped. The current list of valid classes is: Internals - on the design of the Parrot interpreter Documentation - on Parrot documentation Meta - on
Re: CVS update warning
My fault. I didn't specify -kb when I added the images. I suppose that's it. I'll hold off trying to fix it for the moment, in the hope that someone with more CVS knowledge will beat me to it. Mike On 21 Feb 2004, at 23:05, Steve Fink wrote: . . . P docs/pmc/subs.pod cvs server: internal error: unsupported substitution string -kCOPY U docs/resources/parrot.small.png U docs/resources/perl-styles.css cvs server: internal error: unsupported substitution string -kCOPY U docs/resources/up.gif . . . Should those perhaps be -kb or -ko? My version of CVS certainly doesn't know COPY, nor have I ever heard of it.
Re: Release doc tasks
Thanks, applied. On 20 Feb 2004, at 01:56, chromatic wrote: On Thu, 2004-02-19 at 16:34, Michael Scott wrote: One thing that would help is if people ran perl tools/docs/write_docs.pl -d -s on various platforms and told me if it works - or what they did to make it work - because I only have access to Mac OS X 10.3.2 here. It choked here on Linux with Failed to process lib/Parrot/Pmc.pm. teasingModern filesystems understand both upper and lower case./teasing Embarrassing isn't it. System Preferences needs a strict button. With the applied patch, there's only one warning: Use of uninitialized value in substitution (s///) at lib/Pod/Simple/HTML.pm line 344. Yep, this one is a trivial thing that will get squashed this weekend. -- c write_docs.patch
Re: Release doc tasks
On 19 Feb 2004, at 20:59, Simon Glover wrote: pdd12_assembly.pod -- what was the intent of this? (i.e. is there stuff that isn't covered in pdd06_pasm.pod that should go in here, or can we just dump this and recycle the number?) Yes it should go. It's just an earlier version of pdd06. I'm almost done with the PMCs, though what I'm doing is fairly minimal. I've had to take a sort of head-down approach to working on the docs. Building inline stuff up to a certain level, before moving on to integration and coherence (will not be for this release). What I do hope to achieve for the Extra Day release is to get hyperlinks working for the html docs. I'll work on that this weekend. Once that's done I'll join in the get-it-up-to-date frenzy. One thing that would help is if people ran perl tools/docs/write_docs.pl -d -s on various platforms and told me if it works - or what they did to make it work - because I only have access to Mac OS X 10.3.2 here. Run it after running make, because it will die looking for docs/packfile-c.pod otherwise. BTW on a personal note, my CFT expires on the 1st May - back to a job in London - so in my head that's deadline I'm working towards. I want to have a decent documentation system set up by then. Mike
Re: This week's summary
On 10 Feb 2004, at 14:09, The Perl 6 Summarizer wrote: I wonder how long it'll be before someone reimplements them in in PIR... or Perl6 perchance.
Re: cvs commit: parrot/docs/resources up.gif
On 9 Feb 2004, at 01:49, Nicholas Clark wrote: Have the LZW patents(*) expired everywhere yet google tells me there's one down and seven to go http://www.kuro5hin.org/story/2003/6/19/35919/4079 I just pinched it from parrotcode.org. Does that make me a felon? Mike
Perl tests
I have to write some unit tests for the Parrot::IO::* and Parrot::Docs::* modules and I'm wondering where to put them. How about creating t/perl and adding Parrot_IO_*.t etc? Or should I go for a t/perl/Parrot/IO/*.t approach? Someone help me make up my mind. No need for them to be run with make test, a perltest target can be added. Mike
Re: [DOCS] Documentation tools
Suppose I could make a few changes to Pod-Simple, then our problem would be solved. But, being serious, say I'd decided to use Template-Toolkit, it would never have occurred to me to shove all of that in CVS. It always surprised me a that ICU was there, rather than just what was needed to get it to work. So, it seems just to be a question of adding a prerequisites phase to the config. I would propose that we leave Pod-Simple in CVS until I have time to implement that, then we can delete it (promise). Mike On 6 Feb 2004, at 01:39, Robert Spier wrote: I can possibly help it, so it's ok by me to delete lib/Pod, if that's the consensus. I'm not sure what the consensus is. But we should probably come to one. -R
Re: [DOCS] Documentation tools
On 6 Feb 2004, at 22:32, Leopold Toetsch wrote: - icu - lib/Test/* - lib/Pod/* are all standard thingys. I'm not thinking that we are gonna reinventing wheels nor that we are gonna copying existing wheels, so I'd vote for just removing all that from CVS. yep All non-trivial packages have some preliminaries. Some prominent notes in README and INSTALL can provide the necessary steps, how to get that source. I'd like to see Configure.pl say what's needed, and do what it can to help if requested. Meanwhile, I've been adding some perl code of my own which should give a more parroty feel to the docs. http://homepage.mac.com/michael_scott/Parrot/docs/html/index.html There are some links to actual files in the distribution (READMEs etc) which will be broken because it's not up there, but they work ok locally. As you can see the structure is lifted from the wiki, this is because it saved me thinking while I got it working. The Item, Group and Section modules in Parrot::Docs will make it fairly easy to set up alternative subsystem-based views of the content instead. Eagle eyes will note that I put the parrotcode.org css and small parrot png in docs/resources so that they work without a network. Hope I haven't transgressed again. Oh, btw, while googling for parrot and leap I found this (indirectly): http://news.bbc.co.uk/2/hi/science/nature/3430481.stm Mike
Re: [DOCS] Documentation tools
Ah, ok, my bad then. I'd just assumed that, apart from any need for modification, the other things were there simply to save having to tell everyone to go off and get them. I don't intend to change Pod-Simple if I can possibly help it, so it's ok by me to delete lib/Pod, if that's the consensus. Mike On 5 Feb 2004, at 06:31, Robert Spier wrote: I've added the Perl modules for the docs tools to lib/Parrot/IO and lib/Parrot/Docs. I've also added Pod-Simple (2.05) and Pod-Escapes (1.03) which they use. I probably blinked.. but why are we including CPAN modules that we are not likely to change into the parrot repository? -R
[DOCS] Documentation tools
I've added the Perl modules for the docs tools to lib/Parrot/IO and lib/Parrot/Docs. I've also added Pod-Simple (2.05) and Pod-Escapes (1.03) which they use. Running perl tools/docs/write_docs.pl should build the html tree in docs/html. I'd be interested to know of any problems encountered. On the updating front, I finished examples and did the other *.c file directories (chartypes, encodings, io, pf, types). Now I think I'll look at classes. Mike
Re: [DOCS] Updated documentation in src
I haven't ruled out something like that in the long term, but what I'm trying achieve at the moment is just to see some pod everywhere. This has the merit that I visit every file and ensure that some basic information gets provided for the newbies - my target audience. In a sense I'm following the time honoured tradition of throwing one away, namely the Getting Started Guide on the wiki. I'm shifting pod from there into the files. At the moment I'm just building a big index.html list and using the default html formatting from Pod-Simple, but this will change soon. I think the trick is to model the project with perl modules so that it's straightforward to extract and compose information. I already have the basis for this, which I'll check in any day now. Mike On 30 Jan 2004, at 19:23, Tim Bunce wrote: Would doxygen be of use here? http://www.doxygen.org/ Here's an example use http://www.speex.org/API/refman/speex__bits_8h.html#a2 Follow the links, including to the annotated source file. Tim. On Thu, Jan 29, 2004 at 07:20:50PM +0100, Michael Scott wrote: I've add inline docs to everything in src (except for malloc.c and malloc-trace.c). At times I wondered whether this was the right thing to do. For example, in mmd.c, where Dan had already created a mmd.pod, I ended up duplicating information. At other times I reckoned that what was needed was an autodoc. Other times the best I could do was rephrase the function name. All issues to address in phase 2. Next I think, for a bit of light relief, I'll do the examples. For those who want to browse: http://homepage.mac.com/michael_scott/Parrot/docs/html/ Mike
[DOCS] Updated documentation in src
I've add inline docs to everything in src (except for malloc.c and malloc-trace.c). At times I wondered whether this was the right thing to do. For example, in mmd.c, where Dan had already created a mmd.pod, I ended up duplicating information. At other times I reckoned that what was needed was an autodoc. Other times the best I could do was rephrase the function name. All issues to address in phase 2. Next I think, for a bit of light relief, I'll do the examples. For those who want to browse: http://homepage.mac.com/michael_scott/Parrot/docs/html/ Mike
Re: [RESEND] Q: Array vs SArray
On 25 Jan 2004, at 00:50, Gordon Henriksen wrote: [...] Is there something so terribly wrong with English? How about a general scheme of adjective* noun? So, respectively, MixedArray Array FixedArray StringArray FixedStringArray Array is what Perl familiars will usually want. Did I miss something? What is Array here? General scheme: Need something more specific? Type more. Not sure on Fixed, but I like it more than FLen. Other option is to flip it around and tag Resizable, but that violates my previous pricipal of most useful = most convenient. I don't think MixedArray will see much use, so FixedMixedArray doesn't worry me too much. :) I would definitely avoid the words mutable/immutable, as that will certainly be read by many (me :) to pertain to the values contained within the array. Yes, I'm already anti-me on that. It should have been Resizable. And though that's more precise than Fixed, I agree with your principle. So, to go back to Dan's original list, does that give us: (FixedMixedArray - fixed-size, mixed-type array) MixedArray - variable-sized, mixed-type array FixedPMCArray - fixed-size, PMC array PMCArray - variable-sized, PMC array FixedStringArray - fixed-size, string array StringArray - variable-sized, string array FixedNumberArray - fixed-size, number array StringArray - variable-sized, number array FixedIntegerArray - fixed-size, integer array IntegerArray - variable-sized, integer array with fixedarray - abstract fixed-size array array - abstract variable-sized array for the common functionality. Mike
Re: Benchmark Suite
A few notes on the benchmarks can be found/added here http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/ ParrotDistributionExamples#benchmarking Mike On 26 Jan 2004, at 00:14, Luke Palmer wrote: Matt Fowles writes: All~ Of late it seems that everybody has been throwing around their own little homegrown benchmarks to support their points. But many people frequently point out that these benchmarks are flawed on one way or another. I suggest that we add a benchmark/ subdirectory and create a canonical suite of benchmarks that exercise things well (and hopefully fully). Then we can all post relative times for runs on this benchmark suite, and we will know exactly what is being tested and how valid it is. Like, for example, examples/benchmarks ? It's quite difficult to create benchmarks that test *everything*. But any time someone posts a good benchmark, it really should go in here. Hopefully with some documentation describing what it tests. Luke
Re: [RESEND] Q: Array vs SArray
Is there a reason why the names have to be so terse? Mutable is not a bad word for able-to-change. (Cribbed from Cocoa, though there the immutability is absolute). *) Array - fixed-size, mixed-type array *) MutablePArray - variable-sized PMC array *) PArray - Fixed-size PMC array *) MutableSArray - variable-sized string array *) SArray - fixed-size string array Mike On 22 Jan 2004, at 19:24, Dan Sugalski wrote: At 2:15 PM -0500 1/21/04, Matt Fowles wrote: All~ So, lets do the classes as: *) Array - fixed-size, mixed-type array *) vPArray - variable-sized PMC array *) PArray - Fixed-size PMC array *) vSArray - variable-sized string array *) SArray - fixed-size string array I suggest using Array to mean fixed size and Vector to mean variable size. I'd rather not. Vector, for me at least, has some specific connotations (from physics) that don't really match what we're talking about here. They're more vectors in the mathematical sense, but they won't behave like mathematical vectors so I don't think that's a good idea either. Array, while mundane (and a bit annoying with the prefix stuff tacked on) is at least accurate. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [DOCS] C code documentation
Yep. I bounced Sam's comment around in my head for a while until I saw that I was only putting them in for my own current convenience - makes it easier to see what I'm doing as I'm doing it - so they won't be there. Minimal is best. And anyway who wants to be SO 20th century. Mike On 22 Jan 2004, at 19:33, Dan Sugalski wrote: At 10:42 AM +0100 1/21/04, Michael Scott wrote: Perhaps the most controversial feature of all this is that I'm using rows of 80 '#'s as visual delimiters to distinguish documentation sections from code. Please don't. If you really, really must, chop it down to 60 or so characters. 80 may wrap in some editors under some situations, and anything bigger than 72 may trigger wrapping behaviour in mail programs. (I think I'd as soon you didn't put in delimiters like this at all, but I can live with it if I must) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [DOCS] CVS version $Id strings
Duh. Rereading that I can see I got my numbers in a twist. I've been adding them where missing. On 22 Jan 2004, at 19:39, Dan Sugalski wrote: At 2:06 PM +0100 1/19/04, Michael Scott wrote: Some files have CVS version $Id strings, some don't. While tidying up the documentation I'm visiting every file. I can either: 1) add them when missing 2) remove them when present 3) do nothing I was inclined to (1) until I reflected that it did preserve a relation between local and repository versions. Say one has a number of different check outs of the distribution, then the $Id strings might come in handy to distinguish between them. So in the end I incline to (2). Does anyone have strong feelings either way? Leave the CVS version strings in. They get automagically updated on checkin and it's a useful way to see which version of a file you have. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[DOCS] C code documentation
PDD 7 Conventions and Guidelines for Parrot Source Code has a section on Code Comments that has been followed for C code. I'm about to change this. The existing documentation headers will be replaced with pod headers contained within C multi-line comment delimiters. I'm going to stick to exactly the same style that I used in the Perl scripts. Functions will be proceeded with similarly formatted descriptions. No information will be lost. Perhaps the most controversial feature of all this is that I'm using rows of 80 '#'s as visual delimiters to distinguish documentation sections from code. This may seem like overkill to some. I'm basing it on what looks right to me in BBEdit and Xcode. If it turns out that it doesn't work for everyone, I'll change it. If anyone feels strongly about this then speak. Mike
[DOCS] Updated documentation in Perl scripts
I've committed updates to the documentation in the Perl scripts in build_tools, classes and tools/dev. http://homepage.mac.com/michael_scott/Parrot/docs/html All scripts now run with -w (turned up a harmless bug in Parrot::Vtables, which I fixed). CVS $Id and copyright notices were also added where necessary. Mike
[DOCS] CVS version $Id strings
Some files have CVS version $Id strings, some don't. While tidying up the documentation I'm visiting every file. I can either: 1) add them when missing 2) remove them when present 3) do nothing I was inclined to (1) until I reflected that it did preserve a relation between local and repository versions. Say one has a number of different check outs of the distribution, then the $Id strings might come in handy to distinguish between them. So in the end I incline to (2). Does anyone have strong feelings either way? Mike
Re: [PATCH] Fix imcpasm tests on Win32
On 17 Jan 2004, at 21:47, Leopold Toetsch wrote: [...] BTW don't we have some docs/*.pod with a summary of sending patches? Also the Fgettingingstarted.pod seems to be missing in the tree. I have a submissions.pod on the wiki which I'll put in. Problem is at the moment I can't see either the wiki or cvs.perl.org. Not certain where the problem is. Mike
Re: [DOCS] POD Errors
They're already commited. On 16 Jan 2004, at 00:21, chromatic wrote: On Thu, 2004-01-15 at 15:02, Michael Scott wrote: So, after migrating from Pod::Checker to Pod-Simple, I've cleared up all the pod errors and done a rudimentary html tree. Do you have patches to fix the errors in CVS or are they even necessary? -- c
Re: Unicode, internationalization, C++, and ICU
Maybe we can use someone else's solution... http://lists.ximian.com/archives/public/mono-list/2003-November/ 016731.html On 16 Jan 2004, at 00:33, Jonathan Worthington wrote: - Original Message - From: Dan Sugalski [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 15, 2004 8:09 PM Subject: Unicode, internationalization, C++, and ICU Now, assuming there's still anyone left reading this message... We've been threatening to build ICU into parrot, and it's time for that to start happening. Unfortunately there's a problem--it doesn't work right now. So, what we need is some brave soul to track ICU development and keep us reasonably up to date. What I'd really like is: 1) ICU building and working 2) ICU not needing any C++ I've done some testing, and I hate to be the bearer of bad news but I believe we have something of a problem. :-( The configure script turns out to be a shell script which, unless I'm mistaken, means we're currently unable to build ICU anywhere we don't have bash or similar. Win32 for starters, which is where I'm testing. A possible solution might be to re-write the configure script in Perl - though we'd have to keep it maintained as we do ICU updates. Another one, for Win32 at least, is that we *might* be able to use UNIX Services For Win32 and run configure under that, generate a Win32 makefile and just copy it in place with the configure script. Less portable to other places with the same problem, though, and again we have to maintain it as we update ICU. There is also a problem with the configure stage on Win32, but that's an aside until the above issue is sorted out. I also gave it a spin in cygwin, where the configure script for ICU runs OK, but there's no C++ compiler so it doesn't get built. Thoughts? Jonathan
Configure.pl --help
I'm attempting to update Configure.pl --help to include all the
options. I parsed the files in config so I reckon I have all the
options, I'd just be grateful if anyone can point out any
misunderstandings. The expnetwork option defines EXP_NETWORKING in
config.h, but this is unused. Should it be kept?
% perl ./Configure.pl --help
./Configure.pl - Parrot Configure 2.0
General Options:
--help Show this text
--versionShow version information
--verboseOutput extra information
--nomanicheckDon't check the MANIFEST
--maintainer Use this option if you are hacking Parrot.
This needs working lex/flex/yacc/bison programs.
--miniparrot Build parrot assuming only pure ANSI C is available
--buildicu Build Parrot and ICU
Parrot Configuration Options:
You can remove parts of a line with :rem{opt} and add options with
:add{opt}
e.g. :rem{-g} :add{-O2}
--askHave Configure ask for commonly-changed info
--debugging=0Disable debugging, default = 1
--optimize Optimized compile
--inline Compiler supports inline
--expnetwork Enable experimental networking (unused)
--cc=(compiler) Use the given compiler
--ccflags=(flags)Use the given compiler flags
--ccwarn=(flags) Use the given compiler warning flags
--libs=(libs)Use the given libraries
--link=(linker) Use the given linker
--linkflags=(flags) Use the given linker flags
--ld=(linker)Use the given loader for shared libraries
--ldflags=(flags)Use the given loader flags for shared libraries
--lex=(flags)Use the given lexical analyzer generator
--yacc=(flags) Use the given parser generator
--intval=(type) Use the given type for INTVAL
--floatval=(type)Use the given type for FLOATVAL
--opcode=(type) Use the given type for opcodes
--ops=(files)Use the given ops files
--pmc=(files)Use the given PMC files
--cgoto=0Don't build cgoto core - recommended when short of mem
--jitcapable Use JIT
--execcapableUse JIT to emit a native executable
--gc=(type) Determine the type of garbage collection
type=(gc|libc|malloc|malloc-trace) default is gc
Re: Numeric formatting
Is this relevant? http://oss.software.ibm.com/icu/userguide/formatNumbers.html I'm still not clear in my mind what the plan is with regard to ICU. Is it intended eventually to be: a) an always-there part of parrot, or b) just a sometimes-there thing that gets linked in if you mess with unicode? If (a) then can't we use their formatting stuff. If (b), then doesn't the need for formatted chinese numbers etc. mean that (a) should be the case? Mike On 15 Jan 2004, at 19:54, Dan Sugalski wrote: And now for something reasonably trivial... I'm going to start in on Parrot's COBOLish chunks, in this case numeric formatting. Now, I'm already painfully aware of some of the locale issues that are involved in formatting numbers and money. (What's the currency symbol, what's the decimal indicator, and what's the numeric grouping character) I've no doubt there are a vast number of them that I'm as yet blissfully unaware of. (I've no idea what one needs to do with numeric formatting in Chinse or Korean or Arabic... Does anyone, BTW? I'd love to know if we've folks fluent in one of those) But, in general, I'm thinking of something more or less akin to what SQL uses, since it's as much a standard as anything else. So, to steal directly from Postgres' manual (with things like roman numerals chopped out): Table 9-23. Template Patterns for Numeric Formatting Pattern Description 9 value with the specified number of digits 0 value with leading zeros . (period) decimal point , (comma) group (thousand) separator PR negative value in angle brackets S sign anchored to number (uses locale) L currency symbol (uses locale) D decimal point (uses locale) G group separator (uses locale) MI minus sign in specified position (if number 0) PL plus sign in specified position (if number 0) SG plus/minus sign in specified position -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Unicode, internationalization, C++, and ICU
Well I did originally have this in mind, but the more I looked into it the more I thought it needed someone with unicode experience. It seems to me that the unicode world is full of ah but in North Icelandic Yiddish aleph is considered to be an infinitely composite character and other such arcane exceptions that make the inexperienced the natural victims of their own rational assumptions. Also, given the icu-not-building problem (http://www.mail-archive.com/[EMAIL PROTECTED]/msg17477.html) maybe what we need is an icu person per platform. This might have the benefit of making the task seem less onerous. I did manage to get it building on OS X (still does, I just checked). I wonder on what systems is it actually failing? I'll include this wiki page again because it contains a few links that unicode-savvy lurkers might find useful. http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/ ParrotDistributionUnicodeSupport Mike On 15 Jan 2004, at 21:09, Dan Sugalski wrote: Now, assuming there's still anyone left reading this message... We've been threatening to build ICU into parrot, and it's time for that to start happening. Unfortunately there's a problem--it doesn't work right now. So, what we need is some brave soul to track ICU development and keep us reasonably up to date. What I'd really like is: 1) ICU building and working 2) ICU not needing any C++ I'd also like a pony, too, so I can live if we don't get #2, at least for a bit (as it means that we now require a C++ compiler to build parrot). Anyone care to volunteer? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [DOCS] POD Errors
So, after migrating from Pod::Checker to Pod-Simple, I've cleared up all the pod errors and done a rudimentary html tree. The state of parrot pod can be seen here http://homepage.mac.com/michael_scott/Parrot/docs/html/. That's every file that has pod in it. Obviously there are a few files such as imcc/t/syn/pod.t that contain pod that is not documentation. Just ignore them. I'll move on to phase 2 now, which is to normalize existing pod and add some minimal content to files that need it. The idle browser may notice that there are some links in the files, all broken. This is because Pod::Simple::HTML needs fixing. Mike
Re: [PATCH] PPC JIT fixes [re-send] (Modified by Jeff Clites)
$Config{archname} wasn't getting parsed quite right on OS X and so JIT
wasn't getting detected in some cases. I checked in a fix for that.
It's certainly nice to see the tests run faster.
make test
All tests successful, 49 subtests skipped.
Files=90, Tests=1289, 138 wallclock secs (47.38 cusr + 32.72 csys =
80.10 CPU)
make testj
All tests successful, 48 subtests skipped.
Files=81, Tests=1231, 58 wallclock secs (19.76 cusr + 16.86 csys =
36.62 CPU)
But, on looking closer at that, could someone demuddle my ignorance and
tell me why the t/src tests are not run under testj?
Mike
Re: Parrot String Doc
You'll find some diagrams here which might help. http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/ ParrotDiagramsString On 13 Jan 2004, at 22:06, Robert Eaglestone wrote: OK, I'm looking at the Parrot String documentation, and I've got questions. It's not like the docs are a total mess, they just need some fleshing out. Yeah, that's it. So here I go. Here's the page I'm looking at: http://www.parrotcode.org/docs/strings.pod.html And here are my questions. Or, rather, notes which have questions in them. * OK, I'm game, is 'String' a new thing that's been added to C in the last ten years? I can't find it defined anywhere; my brain must have gone to mush. * Does it help to mention that the source code for string functions is include/parrot/string.h and string.c? * Suppose I add some example code to the doc, creating a string and fooling around with it? Perhaps using code from a string test routine (hint, hint)? I'd do something like this, maybe: INTVAL encoding = where/what are the encoding values? /* is this legal? */ STRING* foo = string_make( pi, foobar, 6, encoding, 0, 0 ); /* foo is foobar */ /* It's a pity we don't have a shorter constructor. */ STRING* bar = string_chopn( foo, 3 ); /* bar is foo */ /* It's also sort-of a pity we don't have this one. */ STRING* baz = string_chop( foo ); /* baz is fo */ * Finally, at the bottom of the doc, I see all these undocumented functions. I think I ought to document them. Any new stuff since this page was last edited? -Rob
Re: Docs and releases
I'm currently building some docs related modules which will allow us to create an html tree from the pod, inline stuff included. I cleaned up all the pod errors last week and was going to report on that but got sidetracked when I realised that POD::Checker diverged somewhat from Perl's own pod standards, and that POD-Simple was the way to go. See http://www.nntp.perl.org/group/perl.pod-people/1092 for the details. Once we have an html tree, I'm expecting that problems with the content will be more apparent and hence quicker to identify and solve. For the moment the idea is just to build the html locally, though when it is respectable it would be good to have it also online. I'll aim to have something decent in place for next release, so we can toot toot about it. Mike On 12 Jan 2004, at 15:33, Dan Sugalski wrote: At 11:52 AM + 1/12/04, Tim Bunce wrote: Has a date been set for the next release? Nope. I suppose we could shoot for another holiday release, if someone's got a good february one. Are the docs (especially the PDDs) upto date on best practices? Alas not, no. If not, will that be a goal for the next release? Yeah, I think getting the docs better will be an aggressive goal for the next release. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[DOCS] POD Errors
For those of you who like perusing gobs of autogenerated info, take a look at http://homepage.mac.com/michael_scott/Parrot/pod_report.html where I've put up a list of Parrot POD errors as seen by podchecker. I've started to put together a bunch Perl modules which will allow us autogenerate HTML documentation from the inline POD. As a step in this direction, unless anyone has objections, I'm going to tidy up the POD. I'll do this a file at a time, and let you know when it's done. Mike
Conflicting types for `Sync'
I just downloaded and tried to build Parrot and make failed with
In file included from include/parrot/pmc.h:18,
from include/parrot/parrot.h:250,
from imcc/imc.h:18,
from imcc/main.c:17:
include/parrot/thread.h:103: error: conflicting types for `Sync'
include/parrot/config.h:104: error: previous declaration of `Sync'
make: *** [imcc/main.o] Error 1
In config.h we have
typedef void SYNC;
typedef SYNC Sync;
and in thread.h we have
typedef struct _Sync {
Parrot_Interp owner;/* that interpreter, that owns
the arena, where the PMC is
in */
Parrot_mutex pmc_lock; /* for wr access to PMCs
content */
} Sync;
Forgive me if this is already known. My old G3 PB died some weeks ago
and I've been somewhat disconnected. I just got the new one today, so
hope to start on documentation duties next week.
Mike
Re: Threads
On 22 Dec 2003, at 23:59, Elizabeth Mattijsen wrote: snip I think we need a change of mindset. Instead of seeing threaded programs as the special case, we would need to see that the single threaded program is the special case. See how many people use POE for event handling, and through what hoops (Perl) Tk needs to jump through to get proper event handling. Reading this brought to mind a command-line Perl tool on NT that began life as a quick hack and then grew and grew to the point where a quick Perl Tk user interface would have made it into a proper app but threading issues prevented it. I wouldn't be surprised if many significant single threaded scripts have remained so because they bumped against this ceiling. Mike
Parrot Documentation Review
1) What is Parrot documentation? It seems to me that the problem presented by information about Parrot is that it exists in different layers and contexts. The presence of the docs directory in CVS is deceptive. It suggests that it's contents are in some way definitive. But, in practice, the docs directory is really only there to provide basic information on a standalone machine equipped with nothing but a text editor. In fact, information about Parrot is in various places: On www.parrotcode.org there are FAQ, documents, links. In the distribution there are: - the various ALLCAPS files (plus ChangeLog) in the root directory - the POD documentation in the docs directory - the inline documentation in code files On the Wiki there is search, comment, explanation, suggestions. There's all the discussion on perl6.internals, searchable on Google. And, last but not least, there are the CVS checkin comments. 2) Who uses Parrot documentation? a) First time visitor A first time visitor needs an effective introductory experience with the minimum of frustration so that, hopefully, they will want to get involved with Parrot and become a regular contributor. What happens at the moment? - The new user visits www.parrotcode.org, downloads the latest distribution from CPAN, and reads the README. The README provides the necessary quick start, and seems to be complemented by NEWS, KNOWN_ISSUES, etc. But, these plain text files are prone to brevity and neglect, and the ALLCAPS naming convention doesn't really indicate a coherent category of documents. RELEASE_INSTRUCTIONS is of little relevance to a beginner. So, the user proceeds to the docs directory, armed with a simple text editor, and following the structure provided by parrot.pod and the various subdirectories, skips or reads through the various files according to their interest. There is, however, sufficient explicit mention of things being out-of-date that the authority of the documentation becomes tainted with doubt. Also, the text format prevents the inclusion of anything more visual than an ASCII diagram. Dissatisfied with this documentation the user resorts to inspecting the source code. Inline documentation is directly addressed to the developer but it is patchy. Often the only way to get a definitive answer is to search or post to the mailing list. Discovering the existence of the wiki, our potential Parrot contributor discovers editable hypertext with images. POD can be read reformated in HTML. A lot of additional information is provided. As one user put it: This is more like what I was after. All the docs in one location and with a decent interface for browsing through them. b) Regular user A regular user of the documentation is probably a contributing developer who needs the a speedy look-up for definitive information. What happens at the moment? - In the absence of comprehensive API documentation, the developer has to resort to searching, either by importing Parrot into a development environment, or by resorting to some form of grep. Repeated searching can be time consuming because of the guesswork involved. The wiki also provides search, but only usefully to those with good Internet connections. This is a problem for online documentation too. Therefore we need comprehensive API documentation in HTML in the distribution. Some of it can be autogenerated, not all of it need reside in CVS. All that is needed is for there to be a clearly defined process ensuring that each release one way or another has all the necessary documentation. 3) Where is the primary location for Parrot documentation? Ideally, version 1.0 will be released with complete and adequate documentation as part of the distribution. We should continue to improve the contents of docs until it provides the necessary minimal documentation for Parrot. But, each release is only a snapshot of a continuous process, and it is this real world process that the documentation primarily serves. Given the presence of www.parrotcode.org and the wiki (proposed by Robert to be wiki.parrotcode.org), the information included in a release is always really only relevant in the context of a standalone machine. The effective primary location for Parrot documentation will always be *.parrotcode.org. What goes into the distribution should therefore be derived from - or at least closely reflect - the content there. 4) Why would anyone volunteer to be responsible for Parrot documentation? I would not be involved in Parrot if it were not for Piers and his weekly summaries [1]. They gave me the sense that what seemed opaque could become clear with some attention and effort. How many potential contributors have been lost to Parrot simply because they lacked the time to get over the initial learning curve? Frustrated by the state of the documentation they lost interest. That's the problem I want to solve. 5) Parrot documentation person
Re: Word for the day: Undocumentation
snip ...too much undocumentation going on. One of the reasons I started putting stuff on the wiki was because I could see that updating documentation was not a high priority. On the wiki I neither have to have CVS checkin rights, nor do I have to wait for someone with those rights to act upon what I suggest. This has led to my own parallel documentation - I even document the state of the documentation. I know what I have put together is incomplete and inadequate, but do I move it forward, and I keep it up to date. When it comes to pointing out that parrot_assembly.pod is just an earlier version of PDD 6, or that the Per-entity comments section in PDD 7 needs some thought, or that a submissions.pod should be added, I get warnocked. I'm fine with that, I understand why - this is not a rant - but I do think that Parrot has a steep learning curve and that good documentation is essential if we want to lower it. The potential benefits seem obvious. I'd like to volunteer myself as official Parrot documentation person - a semi-autonomous process with clearly defined protocols and goals - and the necessary rights to achieve them. I'm happy to expand on what I mean by that - if I get a response. Mike
Strings PDD
In an attempt to understand what the plan is with regard to ICU and Parrot strings in general, I've been gathering together links to previous bits of discussion on: http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/ ParrotDistributionUnicodeSupport Obviously what is still needed is a Strings PDD. I wonder could we write it interactively on the wiki? Mike On 3 Nov 2003, at 11:17, Peter Gibbs wrote: Whilst attempting to implement DBCS encoding, I have discovered that skip_backward cannot be implemented for this encoding style, due to the mixture of 1-byte and 2-byte characters. Some of the available options: 1) Throw an exception if somebody tries to skip_backward in a DBCS string 2) Standardise on a single Unicode format for all internal string processing 3) Convert all strings in DBCS encoding to another format, either always or only when skip_backward is invoked 4) Pass additional context information to skip_backward, so it can fall back to counting forward when required 5) Remove skip_backward completely 6) Do not support DBCS encoding 7) Create an index for DBCS strings (i.e. a map of character offset versus byte offset) - this would also require that skip_backward receive additional data More options, preferences, comments, etc all welcome. Regards Peter Gibbs EmKel Systems
Re: [PS] open patches
Reeducation succeeded. I resolved #24030 and #24038 by changing the Status field and hitting Save Changes, then I noticed there was a Resolve option on the top righthand side which asks for details for a notification email. I'm wondering which is the approved way? I ask because I'll add a details to the ParrotSubmissions page on the wiki when I'm done. http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/ParrotSubmissions BTW I submitted a pod version of this page as #24103 with a suggestion for a [NEW] prefix convention for new files but it got warnocked. Mike On 31 Oct 2003, at 05:16, Robert Spier wrote: My account (mikescott) at http://auth.perl.org/auth/account shows the correct email. The RT page assures me that I'm signed in as mikescott. I go to the Modify ticket #24030 and set Status to resolved, click Save Changes and get Status: Permission Denied. RT had a different idea of what your email address was. (There is an issue with propagation.) I've reeducated it. Try now. -R
Re: [PS] open patches
On 30 Oct 2003, at 07:20, Robert Spier wrote: Some of patches on that list that are mine. #24030 Obsolete #24038 Obsolete #24043 Applied #24063 Applied #24177 Rejected #24188 Applied I tried to update the status of #24177 but got Permission Denied. Any chance of that being changed so I could update them myself? You have to log in with an account that uses the same email address, and then you should be able to. (If you have an account that uses a different email address, then I need to match things up.) My account (mikescott) at http://auth.perl.org/auth/account shows the correct email. The RT page assures me that I'm signed in as mikescott. I go to the Modify ticket #24030 and set Status to resolved, click Save Changes and get Status: Permission Denied.
Re: [PS] open patches
Some of patches on that list that are mine. #24030 Obsolete #24038 Obsolete #24043 Applied #24063 Applied #24177 Rejected #24188 Applied I tried to update the status of #24177 but got Permission Denied. Any chance of that being changed so I could update them myself? Mike On Wednesday, Oct 22, 2003, at 17:21 Europe/Berlin, Robert wrote: If anyone goes through that list and provides me with a list of needed updates (in a standardized format), I can do some bulk updates relatively easily. -R Leopold Toetsch wrote: http://www.parrotcode.org/openpatches/ shows a list of open patches ranging from #801 up to recent ones. Some of them are marked pending or applied but not closed. I'd be glad if someone could go through the list and update it so that the actual state is reflected at that site. I know, some of these patches got applied by myself, and I just forgot then. So lets please for the future try to not forget to mark patches applied/whatever and close after some time[1].
Re: [COMMIT] imcc moves out of languages
Shouldn't imcc/docs (eventually) be docs/imcc, and imcc/t be t/imcc? Mike On Thursday, Oct 23, 2003, at 04:29 Europe/Berlin, Melvin Smith wrote: IMCC has graduated from the parrot/languages/imcc directory to parrot/imcc. Please update your trees. We may still want to move the main up to the parrot directory and possibly do an include/imcc directory, but I'm not sure. Test builds on my machine, so I think everything is back to intact for now. -Melvin
Re: [COMMIT] imcc moves out of languages
Almost forgot: imcc/examples to be (eventually) examples/imcc. Mike
Re: [PS] obsolete files
docs/parrot_assembly.pod is just an earlier version of PDD 6. On Thursday, Oct 23, 2003, at 18:34 Europe/Berlin, Leopold Toetsch wrote: Simon Glover wrote: On Thu, 23 Oct 2003, Leopold Toetsch wrote: Here is a list of files that I consider to be unused: Can I also suggest: optimizer.pl lib/Parrot/Optimizer.pm They haven't been touched for 20 months / 16 months respectively, I don't know of anybody using them, and I think that IMCC makes them obsolete. Yep, that's right. BTW, what about the perl PackFile stuff, unused and outdated too? Simon Thanks, leo
Re: [perl #24177] [PATCH] Make Parrot dlcompat aware on OS X
On Friday, Oct 10, 2003, at 14:22 Europe/Berlin, Dan Sugalski wrote: On Fri, 10 Oct 2003, Leopold Toetsch wrote: Michael Scott [EMAIL PROTECTED] wrote: config/gen/platform/darwin.c Add conditional code for PARROT_HAS_HEADER_DLFCN. Could you please rediff the patch w/o the whitespace changes. An indent of 4 is ok, you seem to have 8 in place. Actually, I'd rather not do this. We linked against Fink under OS X originally, to get library loading, but ended up not doing it any more because too many people didn't have it, and it seemed to mess up some people's systems. I thought you might say that, which was why I made it a well-if-it's-there kind of thing. I really just wanted to see the ncurses life example working, but that died with the following dlcompat error anyway: unable to open this file with RTLD_LOCAL because it doesn't implement RTLD_LOCAL. I'll try and get the alternate dynaloader for OS X built this weekend. If I can be of any assistance with this let me know. Dan
parrot_assembly.pod
docs/parrot_assembly.pod is just an earlier version of PDD 6. An empowered person should remove it. Mike
Re: LANGUAGES.STATUS also for languages not in the tree?
If anyone has anything else, I have a page for this on the wiki. What's not in the Parrot distribution? http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/ParrotExtrasTOC On Wednesday, Oct 8, 2003, at 11:38 Europe/Berlin, Jos Visser wrote: Hi, Mightn't it be (is this English by the way? :-) a good idea to use LANGUAGES.STATUS also for maintaining track of parrot-generating compilers that are not in the main tree? If people agree that it's a good idea I would like to submit the following three liner: --- - OpenComal Compiler emiting parrot being added to interpreter Status: Under development; nowhere near anything yet URL: http://www.josvisser.nl/opencomal --- - ++Jos.nl -- ek is so lug jy vlieg deur my sonder jou is ek sonder patroon Breyten Breytenbach
Re: You too can direct the Attack of the Unicode Monster!
On Tuesday, Oct 7, 2003, at 17:51 Europe/Berlin, Dan Sugalski wrote: WHich ought ot be some sort of really bad '50s era black and white giant atomic monster movie. But anyway. ICU now configures and builds on at least some platforms. That means it's time to build an encoding and chartype library for it. This'd be a nice little project for someone looking to get their feet wet in the parrot source, so... I have been looking at the string stuff and icu with this in mind. I would have mentioned it earlier, except that the closer I get to the monster the less equipped I seem. At the moment the only weapon I possess is time. Also, I'm working on OS X, so there is the library loading issue to be solved too. Mike Takers? Dan
Re: [perl #24103] submissions.pod
leo -- appending myconfig to bug reports can't harm - never. Inspired by this bit of wisdom, (and my own earlier silliness with a useless backtrace), I've updated Aldo's patch faq to cover submissions to Parrot in general. I suggest it should go in docs. http://www.parrotcode.org/patchfaq can then be redirected there. You'll note I'm following the instructions for new files by submitting it to bugs-parrot without the [PATCH] prefix. Is this right? Should there be a [NEW] prefix as well? =item 7 Attach the patch and/or new file(s) that you're submitting. Double-check that you've done this, because it's really easy to forget. submissions.pod Description: application/applefile submissions.pod Description: application/text Mike
Re: Is anything using the source-embedded docs?
On Friday, Oct 3, 2003, at 16:12 Europe/Berlin, Dan Sugalski wrote: Do we currently have anything that looks at the /*=for foo bar baz docs embedded in the C code? I see it's in some (but not all) of the C files, and I wanted to double-check the rules as I'm starting the extension code stuff, but I can't find anything that processes the embedded docs. Dan I already got warnocked on this. See my Per-entity comments post. Mike
Re: Is anything using the source-embedded docs?
On Friday, Oct 3, 2003, at 16:58 Europe/Berlin, Dan Sugalski wrote: When (says the man with poor access to his mail archives at the moment :)? 21st Sept 2003
Re: [PATCH] Getting ICU to build on OS X
I just heard from Steven R. Loomis (ICU) about this. They have a better solution which will go into ICU 2.8. For those interested, it turns out that gcc -MMD writes out the dependency file by itself, therefore redirecting stdout, which contains preprocessed text, to the file was wrong. Here's the new patch. mh-darwin.patch Description: Binary data
Re: [perl #24080] [PATCH] parrot-build-1: Build parrot incl. imcc files take 1
On Thursday, Oct 2, 2003, at 04:48 Europe/Berlin, Robert Spier wrote: [snip] (We probably could simplify things by requiring GNU make.. but I'm not going to start that now.) Now that you mention it ... ICU requires GNU make. Mike
Re: PIO tests
On Tuesday, Sep 30, 2003, at 15:44 Europe/Berlin, Juergen Boemmels wrote: Michael Scott [EMAIL PROTECTED] writes: Here are some tests for the io.h API that should go in t/src/io.t. Ah yes. I know I submitted one too. I thought it got committed a long time ago but maybe it wasn't. I will try to merge it with your tests and commit a change. In one test you include ../io/io_private.h. I'm not sure if it's a good idea to test implementation details. On one side its better to test as many as you can, on the other side mainly the public API should be tested, the implementation should just work. I'm just including io_private.h to get the correct flags to test the return values of PIO_parse_open_flags() which is in the public API. I agree there are limits to what should be tested, but what embarked me on the tests in src/io.t was the failure of test 6 in pmc/io.t. I tried to fix it, but because there were no src/io.t tests I couldn't be sure whether the problem lay in the io.ops code or the io/* code. Needless to say, once I'd written src/io.t, I got sidetracked into the need for string C code tests, and never got back to pmc/io.t. It seems to me that there are at various levels of public in Parrot, and each one should be tested. Furthermore, the more tightly the testing is done at the lowest level, the more confident we can be about the higher level test results. PIO_parse_open_flags() is, I think, a good case in point. It makes sense to throw a bunch of invalid values at it in src/io.t, and then assume that it works in pmc/io.t. BTW those src/io.t tests should be rewritten to use the scheme Leo uses in the 3rd test in src/basic.t. I proposed a patch to simplify this in [PATCH] C code test header which if you could get into CVS I'd be grateful as my string tests will rely on it. Maybe some of the expected results are debatable. Should PIO_parse_open_flags think that is the same as ? No it shouldn't. Should PIO_fdopen open ok on stdout with invalid flags like ;-) or ? I think all invalid flags should be invalid. Also, successive calls to PIO_seek with SEEK_CUR seem to be broken. I will look at this. Mike 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: PIO tests
On Tuesday, Sep 30, 2003, at 19:20 Europe/Berlin, Juergen Boemmels wrote: Michael Scott [EMAIL PROTECTED] writes: On Tuesday, Sep 30, 2003, at 15:44 Europe/Berlin, Juergen Boemmels wrote: Michael Scott [EMAIL PROTECTED] writes: Here are some tests for the io.h API that should go in t/src/io.t. Ah yes. I know I submitted one too. I thought it got committed a long time ago but maybe it wasn't. I will try to merge it with your tests and commit a change. In one test you include ../io/io_private.h. I'm not sure if it's a good idea to test implementation details. On one side its better to test as many as you can, on the other side mainly the public API should be tested, the implementation should just work. I'm just including io_private.h to get the correct flags to test the return values of PIO_parse_open_flags() which is in the public API. Maybe PIO_parse_open_flags should also get moved to io_private.h. The private/public split of the io subsystem is far from complete. In fact io is the first subsystem that even tries to do so. I agree there are limits to what should be tested, but what embarked me on the tests in src/io.t was the failure of test 6 in pmc/io.t. I tried to fix it, but because there were no src/io.t tests I couldn't be sure whether the problem lay in the io.ops code or the io/* code. Needless to say, once I'd written src/io.t, I got sidetracked into the need for string C code tests, and never got back to pmc/io.t. It seems to me that there are at various levels of public in Parrot, and each one should be tested. Furthermore, the more tightly the testing is done at the lowest level, the more confident we can be about the higher level test results. Ok you convinced me, we need to test private implementation details. But this tests should be cleanly flagged as such. PIO_parse_open_flags() is, I think, a good case in point. It makes sense to throw a bunch of invalid values at it in src/io.t, and then assume that it works in pmc/io.t. BTW those src/io.t tests should be rewritten to use the scheme Leo uses in the 3rd test in src/basic.t. I proposed a patch to simplify this in [PATCH] C code test header which if you could get into CVS I'd be grateful as my string tests will rely on it. The whole c_output_is() tests are more or less a hack. Ideally there would be C-markos like OK(val, name), DIAG(text), IS(this, that, name), etc. and be able to check individual c-statements without recompiling and running a new file each time. Being more or less of a hack myself, I'm happy to persist with the existing scheme, in the absence of any imminent ideal. The main hassle with c_output_is() is, when developing the test, the C code dies and the Perl harness doesn't notice. That's why I stick a done at the end of every test. 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: PIO tests
On Tuesday, Sep 30, 2003, at 19:31 Europe/Berlin, Melvin Smith wrote: Since PIO_parse_open_flags just assists the IO code in fulfilling an API, but is not part of the published API, I would suggest that it be moved into the private, but before tests are written for it, there should be a spec written. Given how much code is already written, it's probably most efficient to write the spec as tests. When I wrote the code, there was not even a design for what sort of API we would implement. I chose supporting a stringified flags because I liked it, but there was never much discussion about whether this was the right way or not. It is a very Perlish way of doing it, but languages that have constant values would then have to translate back to the string version to run on top of Parrot. That, or there will need to be a second form of open() written to take numerical constants. When I was writing the PIO_parse_open_flags() test it did seem to me rather Perlish to have string flags in the first place. But I'm a new cockroach in town, so I kept my mouth shut, not wanting to get stomped on. If the PIO_F_* flags used by open() were moved up to io.h then they could be exported as .constants by config/gen/parrot_include.pl and used explicitly. Various composite flags could be added for convenience. PIO_F_WRITE_TRUNC () PIO_F_WRITE_APPEND () PIO_F_READ_WRITE(+, +) Also, add an INT flag version of open. inline op open(out PMC, in STR, in INT) In short, I think it should be discussed as to whether it is even the right way. It seemed right at the time, but now I'm having second thoughts. -Melvin
Re: [PATCH] Getting ICU to build on OS X
I had submitted this last month, but could neither find where I'd saved the bug number, nor see any reference to it on ICU, so I resubmitted it as bug 3287 and in the process came across the initial submission, bug 3211. No doubt this will get it patched twice as fast, eventually. Mike On Monday, Sep 29, 2003, at 03:02 Europe/Berlin, Robert wrote: Please also send a copy of this to the ICU developers. (See the ICU website/documentation.) We need to try and make as few changes as possible to ICU, or it will become a _nightmare_ to maintain. By making sure our local changes get sent upstreadm it will keep our life simpler in the future. -R Michael Scott (via RT) wrote: # New Ticket Created by Michael Scott # Please include the string: [perl #24043] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=24043 This patch gets ICU to build on Mac OS X. It works around a gcc -E -MMD bug. -- attachment 1 -- url: http://rt.perl.org/rt2/attach/65328/48724/2c2ce5/mh-darwin.patch
Re: [perl #24030] [PATCH] hash.t fails on OS X
On Friday, Sep 26, 2003, at 13:04 Europe/Berlin, Jeff Clites wrote:
I did a bit more digging on this test failure, and I think it's an
infant mortality case--it looks like creating the large string might
be triggering a DOD run which is freeing the hash. Just dumping the
hash before and after creating the string demonstrates (by crashing
during the second dump):
big = calloc(BIGLEN, sizeof(char));
big = memset(big, 'x', BIGLEN - 1);
new_hash(interpreter, hash);
dump_hash(interpreter, hash);
key = string_from_cstring(interpreter, big, NULL);
dump_hash(interpreter, hash);
Output:
Hashtable[0/16] Bucket 16: type(0) - type(0) - type(0) - type(0)
- type(0) - type(0) - type(0) - type(0) - type(0) - type(0) -
type(0) - type(0)
Hashtable[0/16] Bucket 16: type(524288) - Segmentation fault
If I allocate the string before creating the hash, the test passes.
hash_t.patch
Description: Binary data
What's the preferred way to prevent this in tests? I know there are
various approaches possible, but I don't know if there is a consensus
for how to deal with this in test cases--disabling DOD works but seems
a bit heavy handed.
This reminds me of those help-yourself hotel breakfasts where overeager
staff whisk your cup away as soon as they see it empty. If you're
planning on having seconds and want to keep the same cup, then you've
got to keep your eye on it.
Disabling empty cup collection - i.e. a big sign saying Don't take my
cup! - may seem a bit heavy handed, but it does have the advantage of
being explicit.
JEff
On Thursday, September 25, 2003, at 09:23 AM, Jeff Clites wrote:
Hi:
In case it helps, it looks like it's crashing at string.c:552,
because it's trying to call src-encoding-decode() but src-encoding
is NULL.
(gdb) f 0
#0 0x6104 in string_transcode (interpreter=0x616400,
src=0x623440, encoding=0x19e43c, type=0x19a6fc, dest_ptr=0x0) at
string.c:552
552 UINTVAL c = src-encoding-decode(srcstart);
(gdb) l
547 srcend = srcstart + src-bufused;
548 deststart = dest-strstart;
549 destend = deststart;
550
551 while (srcstart srcend) {
552 UINTVAL c = src-encoding-decode(srcstart);
553
554 if (transcoder1)
555 c = transcoder1(src-type, dest-type, c);
556 if (transcoder2)
(gdb) p encoding
$1 = (const struct parrot_encoding_t *) 0x19e43c
(gdb) p src
$2 = (struct parrot_string_t *) 0x623440
(gdb) p src-encoding
$3 = (const struct parrot_encoding_t *) 0x0
Here's another backtrace, with a little more info:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x6104 in string_transcode (interpreter=0x616400, src=0x623440,
encoding=0x19e43c, type=0x19a6fc, dest_ptr=0x0) at string.c:552
552 UINTVAL c = src-encoding-decode(srcstart);
(gdb) bt
#0 0x6104 in string_transcode (interpreter=0x616400,
src=0x623440, encoding=0x19e43c, type=0x19a6fc, dest_ptr=0x0) at
string.c:552
#1 0x6fbc in string_compare (interpreter=0x616400, s1=0x625cd8,
s2=0x623440) at string.c:949
#2 0x45b0 in find_bucket (interpreter=0x616400, hash=0x6223e0,
head=0, key=0x6816b0) at hash.c:281
#3 0x4a4c in hash_put (interpreter=0x616400, hash=0x6223e0,
key=0x6816b0, value=0xbb50) at hash.c:406
#4 0x2b5c in main (argc=1, argv=0xbc2c) at CrashingTest.c:36
#5 0x27f8 in _start (argc=1, argv=0xbc2c, envp=0xbc34)
at /SourceCache/Csu/Csu-45/crt.c:267
#6 0x2678 in start ()
JEff
On Thursday, September 25, 2003, at 08:22 AM, Michael Scott wrote:
On Thursday, Sep 25, 2003, at 16:06 Europe/Berlin, Michael Scott
wrote:
On Thursday, Sep 25, 2003, at 13:20 Europe/Berlin, Leopold Toetsch
wrote:
Michael Scott [EMAIL PROTECTED] wrote:
t/src/hash.t
test 7 fails on Mac OS X 10.2.6 (gcc 3.3) because BIGLEN is too
big:
9.
100_000 chars for the key doesn't seem to be very big.
Wher does it fail?
Can you debug/back-trace it?
(gdb) r
Starting program: /Users/mike/Developer/Parrot/Tests/mem_test
Reading symbols for shared libraries . done
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x5f30 in string_transcode ()
(gdb) bt
#0 0x5f30 in string_transcode ()
#1 0x6de8 in string_compare ()
#2 0x43e4 in find_bucket ()
#3 0x4880 in hash_put ()
#4 0x2998 in main ()
#5 0x25a4 in _start (argc=1, argv=0xbdd4, envp=0xbddc)
at /SourceCache/Csu/Csu-45/crt.c:267
#6 0x2424 in start ()
And just as I was going to get started on t/src/string.t too.
I'm running tests on string_compare and string_transcode with
999 byte strings without complaint.
I've made it a bit smaller: 65536.
This begs the questions:
What is the maximum hash key size?
What is the largest STRING?
There are no limits except those imposed by UINTVAL (2^32-1) AFAIK.
Mike
leo
[PATCH] C code test header
Given Leo's new scheme for C code tests, I suggest that we add a header
to be included in the test, and modify Parrot::Test so that it knows to
add the header's location to the command.
This patch puts the header in parrot/t/c_test_header.h.
The correct scheme for a C test can now be:
c_output_is('CODE', 'OUTPUT', C code test);
#include c_test_header.h
int do_test(Interp *interpreter)
{
...
}
CODE
...
OUTPUT
c_test_header.h
Description: application/applefile
#include stdio.h
#include parrot/parrot.h
#include parrot/embed.h
int do_test(Interp *interpreter);
int main(int argc, char* argv[]) {
Interp* interpreter;
interpreter = Parrot_new();
if ( interpreter == NULL ) return 1;
interpreter-lo_var_ptr = interpreter;
Parrot_init(interpreter);
return do_test(interpreter);
}
Test.pm
Description: application/text
Re: ICU suggestion
On Thursday, Sep 25, 2003, at 00:41 Europe/Berlin, Robert Spier wrote: Which version of ICU is in parrot/icu. Maybe 2.6 would be the most likely to build. As an update would probably best be done by delete and replace, perhaps it could coincide with the great renaming? Actually, it would be best to do the update by applying 2.6 over whatever is there and committing. (Unless 2.6 is significantly different than whats there.) Unless you meant remove from the repository, such that it never existed in the first place when you said delete. Yes, I meant that. Say we apply 2.6 over what is there and it doesn't build, we then have to ask ourselves if the applying-over's to blame. Just seemed like one uncertainty that could be avoided. -R (CVS timelord) Mike (CVS backseatdriver)
PIO tests
Here are some tests for the io.h API that should go in t/src/io.t. Maybe some of the expected results are debatable. Should PIO_parse_open_flags think that is the same as ? Should PIO_fdopen open ok on stdout with invalid flags like ;-) or ? Also, successive calls to PIO_seek with SEEK_CUR seem to be broken. Mike io.t Description: application/text
Re: [perl #24030] [PATCH] hash.t fails on OS X
On Thursday, Sep 25, 2003, at 13:20 Europe/Berlin, Leopold Toetsch wrote: Michael Scott [EMAIL PROTECTED] wrote: t/src/hash.t test 7 fails on Mac OS X 10.2.6 (gcc 3.3) because BIGLEN is too big: 9. 100_000 chars for the key doesn't seem to be very big. Wher does it fail? Can you debug/back-trace it? (gdb) r Starting program: /Users/mike/Developer/Parrot/Tests/mem_test Reading symbols for shared libraries . done Program received signal EXC_BAD_ACCESS, Could not access memory. 0x5f30 in string_transcode () (gdb) bt #0 0x5f30 in string_transcode () #1 0x6de8 in string_compare () #2 0x43e4 in find_bucket () #3 0x4880 in hash_put () #4 0x2998 in main () #5 0x25a4 in _start (argc=1, argv=0xbdd4, envp=0xbddc) at /SourceCache/Csu/Csu-45/crt.c:267 #6 0x2424 in start () And just as I was going to get started on t/src/string.t too. I've made it a bit smaller: 65536. This begs the questions: What is the maximum hash key size? What is the largest STRING? There are no limits except those imposed by UINTVAL (2^32-1) AFAIK. Mike leo
Re: [perl #24030] [PATCH] hash.t fails on OS X
On Thursday, Sep 25, 2003, at 16:06 Europe/Berlin, Michael Scott wrote: On Thursday, Sep 25, 2003, at 13:20 Europe/Berlin, Leopold Toetsch wrote: Michael Scott [EMAIL PROTECTED] wrote: t/src/hash.t test 7 fails on Mac OS X 10.2.6 (gcc 3.3) because BIGLEN is too big: 9. 100_000 chars for the key doesn't seem to be very big. Wher does it fail? Can you debug/back-trace it? (gdb) r Starting program: /Users/mike/Developer/Parrot/Tests/mem_test Reading symbols for shared libraries . done Program received signal EXC_BAD_ACCESS, Could not access memory. 0x5f30 in string_transcode () (gdb) bt #0 0x5f30 in string_transcode () #1 0x6de8 in string_compare () #2 0x43e4 in find_bucket () #3 0x4880 in hash_put () #4 0x2998 in main () #5 0x25a4 in _start (argc=1, argv=0xbdd4, envp=0xbddc) at /SourceCache/Csu/Csu-45/crt.c:267 #6 0x2424 in start () And just as I was going to get started on t/src/string.t too. I'm running tests on string_compare and string_transcode with 999 byte strings without complaint. I've made it a bit smaller: 65536. This begs the questions: What is the maximum hash key size? What is the largest STRING? There are no limits except those imposed by UINTVAL (2^32-1) AFAIK. Mike leo
ICU suggestion
I'm sitting here watching CVS download ICU and I'm wondering whether it wouldn't be better if it was removed from the repository? It could be replaced by parrot/icu/README to give some sense of continuity. Maybe this could be done during the great renaming? The appropriate version could then be added later when it gets used. Mike
Re: ICU suggestion
I managed to build ICU4C 2.6 on Mac OS X 10.2 by working around the gcc -E -MMD bug. See http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/ ParrotDistributionUnicodeSupport for details. Which version of ICU is in parrot/icu. Maybe 2.6 would be the most likely to build. As an update would probably best be done by delete and replace, perhaps it could coincide with the great renaming? Mike On Wednesday, Sep 24, 2003, at 15:30 Europe/Berlin, Dan Sugalski wrote: On Wed, 24 Sep 2003, Michael Scott wrote: I'm sitting here watching CVS download ICU and I'm wondering whether it wouldn't be better if it was removed from the repository? It'd be better if we got it building, really. Dan
NCI error during make
On OS X 10.2.6 (gcc 3.3) make dies with: perl build_nativecall.pl call_list.txt nci.c nci.c: In function `pcf_i_42p': nci.c:454: error: invalid lvalue in unary `'
parrot/t/src/hash.t
Here are some unit tests for the hash.h interface which are PerlHash free. It could be argued that they're superfluous, but given that there may well be other hash PMCs that use this code eventually, it might be worth testing it independently. Mike hash.t Description: application/text
