Re: --session option to prove
On Tue, Dec 14, 2004 at 03:56:04PM +0200, Yuval Kogman ([EMAIL PROTECTED]) wrote: I've started prelimenary work on Test::Harness::Daemon, which is supposed to let you make various clients to testing. Some will report, others will schedule, some will do both. Unless it's a sub-part of Test::Harness, please don't call it that. Test::Daemon would be fine. It sounds like what you're describing would be a superset of Test::Harness. Thanks, xoox, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Q: scope exit
On Tue, Dec 14, 2004 at 10:49:31AM -0500, Dan Sugalski wrote: Yes. I'll presume that the first Perl6 compiler will just emit closures for each block. Ah, I hope not. I *really* hope not. (Paying attention Patrick? :) That'd be rather slower than necessary in most cases. Yup, I'm paying attention. :) While we might just emit closures for each block in the earliest development versions of the Perl6 compiler just to get things going, I wouldn't expect it to stay that way for very long. Certainly I don't think we'll be long past that by the time we reach a 6.0.0 release of the compiler. It is, I think, safe to assume that language compilers that want timely destruction will make sure to clean up after themselves sufficiently to make that timely destruction possible. It's our job to provide the mechanisms they need, and leave it to them to use them as needed. Agreed, with the caveat that we may discover we need some additional mechanisms as work progresses. But it's a little early to try to get it perfect right now -- we'll just cross our bridges when we get to them. The important thing will for the compiler writers and Parrot implementers to be able to adapt quickly when we find the things we all overlooked. Pm
Re: Uncle Bob on Coding Standards
On Tue 14 Dec 2004 15:15, [EMAIL PROTECTED] (Dominic Mitchell) wrote: On Tue, Dec 14, 2004 at 12:21:50PM +, Matt Sergeant wrote: On 14 Dec 2004, at 11:26, Clayton, Nik wrote: To be honest, I don't care if someone's house style is for TAB to indent 2, 4, or 8 characters; how much second level indentations are indented by; whether or not braces cuddle 'else'; and so on. That's something the editor can care about. When I hit the TAB key it should just do whatever the house style requires. But what about when I'm using notepad.exe??? Or an even more common example, my laser printer? Tabs are 8 spaces. Printers know this. Terminals know this. Even browsers know this. Do the world a favour and don't tell your editor otherwise. I /think/ he means what the tab key's effect is when typed in his editor of choice most vi clones have some knowledge about using the tab key on the start of a line, translating it to shiftwidth, which can be any number. That the editor replaces every amount of spaces (default 8) with a tab should not be the coders problem. Some editors also have the option to not use tabs at all and expand all leading whitespace to spaces. I /think/ that is what Nik meant. But we're adrift here. This was not the subject of the original post. [ If you're using notepad, you're not a real coder. vim/elvis is also available on winblows ] Kane has a sig that sais: real coders use cat a.out -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.5, 5.9.x, and 809 on HP-UX 10.20 11.00, 11i, AIX 4.3, AIX 5.2, SuSE 9.1, and Win2k. http://www.cmve.net/~merijn/ http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: mandelbrot
hm, works fine for others. maybe the weird port i'm using for that web server isn't agreeing with your firewall. -jeff On Tue, 14 Dec 2004, Michael Walter wrote: On Tue, 14 Dec 2004 10:07:43 -0500 (EST), Jeff Horwitz [EMAIL PROTECTED] wrote: is it useful? not really. does it help you waste 5 minutes of your day? certainly. :) Waiting for the request to time out indeed wasted some idle time :-) wink-ingly yours, Michael
Re: mandelbrot
On Tue, 14 Dec 2004 10:07:43 -0500 (EST), Jeff Horwitz [EMAIL PROTECTED] wrote: is it useful? not really. does it help you waste 5 minutes of your day? certainly. :) Waiting for the request to time out indeed wasted some idle time :-) wink-ingly yours, Michael
Re: Uncle Bob on Coding Standards
On Tue 14 Dec 2004 18:21, Ricardo SIGNES [EMAIL PROTECTED] wrote: * H.Merijn Brand [EMAIL PROTECTED] [2004-12-14T11:28:19] About spaces, another thing springs to mind, for which I would gladly kill the responsible people to allow it (I bet M$ was the first to push it): Spaces in database table and field names. DON'T! NEVER! Once you start it, you will never be able to escape the quicksands of (incompatible) quotation and unportability of your scripts, be that in sql, sh, perl/dbi, hli, or e/sql SELECT rsUniqueId FROM [SQL-ABCdatabase2K]..tblsTABLE as t JOIN [SQL-ABCdatabase2K]..tblwPRODUCT p ON p.ABC P/N = t.rsProductCode WHERE p.id IN (SELECT ItemIdentifier FROM tblSomeIds) Just only today I hit an M$Access database with a table named `./onderw`.`Bus; Taxi; Auto` Ahhrg! /me runs for cover! -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.5, 5.9.x, and 809 on HP-UX 10.20 11.00, 11i, AIX 4.3, AIX 5.2, SuSE 9.1, and Win2k. http://www.cmve.net/~merijn/ http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: Uncle Bob on Coding Standards
Here's all I have to say about tabs. I expect the source to look the same no matter whose editor, pager, printer or utility I run it through. Literal tabs violate this. The end. Here's what I have to say about clever bracing/spacing styles. Your bracing/spacing style should not be a detriment. It should not be a limitation. If common editors have trouble dealing with it, you've just limited your tool set. If programmers outside your project look at it and go Huh? you've just lost yourself a potential patch as they recoil. If its so different that looking at other common bracing styles is now odious to you, that's a communication problem. Part of easy communication is taking advantage of common idioms and conventions. Doesn't matter how clever it is, if its causing conflict with outsiders, dump it. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Schwern Unit: a positive but insignificant quantity
make parrot on win-xp needs wrong include file?
Hi all, I'm trying to compile Parrot on Win XP (with MS Visual C++ authoring edition installed) and - after cvs update, nmake realclean, perl Configure.pl - nmake works for a while and stops with: ... astlexer.c ast\astlexer.c(1433) : fatal error C1083: Include-Datei kann nicht geöffnet werden: 'unistd.h': No such file or directory NMAKE : fataler Fehler U1077: 'D:\Perl\bin\perl.exe' : Rueckgabe-Code '0x2' Stop. which means: it cannot find the include file 'unistd.h'. AFAIK, this is a unix include file, should this exist on Win32 platforms too? (But about 1-2 month ago I could compile and run make test with good results). Nicu Ionita
Re: Uncle Bob on Coding Standards
On Tue 14 Dec 2004 21:49, Michael G Schwern [EMAIL PROTECTED] wrote:
Here's all I have to say about tabs.
I expect the source to look the same no matter whose editor, pager, printer
or utility I run it through. Literal tabs violate this. The end.
Here's what I have to say about clever bracing/spacing styles.
Your bracing/spacing style should not be a detriment. It should not
be a limitation. If common editors have trouble dealing with it,
you've just limited your tool set.
Yes. Ditch emacs. It knows only the *wrong* styles.
If programmers outside your project look at it and go Huh? you've just
lost yourself a potential patch as they recoil.
Don't think so. spaces and bracing is hard to do it so bad as to other people
unable to be able to read it. It is merely easy to the eye if there is logic,
and maybe more important consistency in indents
if(expr)
{ func( args ) }else{
statement; }
func ( args);
if (expr)
statement;
wrong_indent;
and yet more misleading indent;
if (expr) {
foo (1);
}
That is *bad*
If its so different that looking at other common
bracing styles is now odious to you, that's a communication problem.
Part of easy communication is taking advantage of common idioms and
conventions. Doesn't matter how clever it is, if its causing conflict with
outsiders, dump it.
No way. Ever.
If I feel compelled enough to deal with other peoples code, I will adapt where
needed. The fact that I'm a perl5 commiter is a vivid proof of that. If I had
imposed my style on all patches I submitted or applied, I would have been
kicked a long time ago.
We have a small company, and if you like to work with us, you adapt to our
style. Not vise versa. Period.
I've also learned that over time, you can get used to (almost) any style,
given there is some logic about it. I've had to change a lot of my habits in
all the compromises we made, but got used to it.
--
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.5, 5.9.x, and 809 on HP-UX 10.20 11.00, 11i,
AIX 4.3, AIX 5.2, SuSE 9.1, and Win2k. http://www.cmve.net/~merijn/
http:[EMAIL PROTECTED]/ [EMAIL PROTECTED]
send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: Uncle Bob on Coding Standards
On Tue, Dec 14, 2004 at 11:10:51PM +0100, H.Merijn Brand wrote: If programmers outside your project look at it and go Huh? you've just lost yourself a potential patch as they recoil. Don't think so. spaces and bracing is hard to do it so bad as to other people unable to be able to read it. It is merely easy to the eye if there is logic, and maybe more important consistency in indents Keeping it within the set of sane bracing styles, ones that perform the basic functions of indentation and blocking and are not obviously broken (and yes, I'm including yours in this set :), and not drifting off into straw-men... Style is a matter of allowing rapid communcation without having to puzzle out the internal logic. Done right, good style allows one to skim code without having to study it. Any style can be learned, but want to have to do as little learning as possible to read somebody's code. Most everyone expects the closing brace to be at the indentation level on which the conditional started. Not at the level at which the code inside the block is written. There's really no quantifiable advantage to either way, its a matter of expectations. In such cases go with the one that violates the least number of potential worker's expectations and eliminates Yet Another thing they have to learn to work on your code. To put it in different terms I turn to industrial design. Donald Norman in Turn Signals Are The Facial Expressions Of Automobiles has a chapter entitled How Long Is Noon? in which he talks about our time formatting. In it he talks about AM, PM and now 12 noon and 12 midnight should be distinguished. One argument is this: AM is an abbreviation of Ante Meridiem, latin for before the middle of the day. PM is Post Meridiem, after midday. As they are abbreviations they are correctly written A.M. and P.M.. Noon is the meridiem therefore noon should be labeled 12 M. This is perfectly sensible logic... if you know latin, speak a romance language or know the history of modern terms. For your average English speaker who does not have any of this background it makes no sense whatsoever. Perfectly logic systems can make absolutely no sense if the reader does not have your frame of reference. Often the case. As programmers we love logically consistent systems and think that because something is logical it is usable. This ignores the frame of reference for the reader. If they do not have your background and know your logic your perfectly sensible system can become inscritable. This is why AM is AM, PM is PM, and 12 M is 12 midmnight. To most people AM and PM are just archaic symbols for before noon and after noon and it doesn't matter one wit that they happen to be abbreviations of latin phrases. We may lament the historical loss but that doesn't matter. What matters is clarity of communications. When there's no obvious improvement between one format or the other, go with the one that follows understoood conventions. That last bit is important. When there *is* a noticable improvement then consider going with it. In this example it would be 24 hour time. [1] Which I'm sure will now spark a nice, pointless debate between the Europeans and Americans. Donald Norman lays out the arguments for 24 hour time nicely. The book can be had for $4 used. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ AY! The ground beef, she is burning my groin! http://sluggy.com/d/990105.html
Re: [Maybe Spam] Coverage testing success story.
You may be interested in what I found on my journey to 100% coverage with D::C http://perlmonks.org/?node_id=378586 [EMAIL PROTECTED] wrote: So even when you approach 100% there's still bugs to be found with simple coverage analysis. I think this is the most valuable part of the exercise - the bugs you find when you think 'its got 98% coverage, there cant possibly be any bugs left...oh, look' -- Leif Eriksen Snr Developer http://www.hpa.com.au/ phone: +61 3 9217 5545 email: [EMAIL PROTECTED]
[patch] runops
Below is a rather straightforward patch, but as it represents an
interface change (albeit a fully backwards compatible one), I thought I
would post it for discussion.
Background on the proposed change: there apparently are two sets of
runops functions, I'd characterize Parrot_runops_fromc as a do it
yourself function in which you are responsible for all registers, and a
set of convenience functions which take care of marshalling arguments.
At the moment, there is one important way in which the convenience
functions are more functional: set_retval has access to the register set
which were active when the Sub was invoked.
This patch brings Parrot_runops_fromc to parity by providing access to
those registers.
- Sam Ruby
Index: include/parrot/interpreter.h
===
RCS file: /cvs/public/parrot/include/parrot/interpreter.h,v
retrieving revision 1.164
diff -u -r1.164 interpreter.h
--- include/parrot/interpreter.h24 Nov 2004 05:56:55 - 1.164
+++ include/parrot/interpreter.h15 Dec 2004 03:12:20 -
@@ -400,7 +400,7 @@
void runops(Interp *, size_t offset);
void runops_int(Interp *, size_t offset);
-void Parrot_runops_fromc(Interp *, PMC *sub);
+struct parrot_regs_t* Parrot_runops_fromc(Interp *, PMC *sub);
void* Parrot_runops_fromc_args(Interp *, PMC *sub, const char *sig, ...);
INTVAL Parrot_runops_fromc_args_reti(Interp *, PMC *, const char *, ...);
FLOATVAL Parrot_runops_fromc_args_retf(Interp *, PMC *, const char *, ...);
Index: src/inter_run.c
===
RCS file: /cvs/public/parrot/src/inter_run.c,v
retrieving revision 1.24
diff -u -r1.24 inter_run.c
--- src/inter_run.c 13 Dec 2004 21:51:00 - 1.24
+++ src/inter_run.c 15 Dec 2004 03:12:20 -
@@ -102,7 +102,7 @@
/*
-=item Cvoid
+=item Cstruct parrot_regs_t *
Parrot_runops_fromc(Parrot_Interp interpreter, PMC *sub)
Runs the Parrot ops, called from C code. The function arguments are
@@ -113,11 +113,12 @@
*/
-void
+struct parrot_regs_t *
Parrot_runops_fromc(Parrot_Interp interpreter, PMC *sub)
{
PMC *ret_c, *p1;
opcode_t offset, *dest;
+struct parrot_regs_t *bp;
/* we need one return continuation with a NULL offset */
p1 = REG_PMC(1);
@@ -130,11 +131,13 @@
* Passing a dummy true destination copies registers
*/
dest = VTABLE_invoke(interpreter, sub, (void*) 1);
+bp = interpreter-ctx.bp;
if (dest) {
offset = dest - interpreter-code-byte_code;
runops(interpreter, offset);
}
REG_PMC(1) = p1;
+return bp;
}
/*
Re: [Maybe Spam] Coverage testing success story.
On 12/14/2004 6:01 PM, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: So even when you approach 100% there's still bugs to be found with simple coverage analysis. I think this is the most valuable part of the exercise - the bugs you find when you think 'its got 98% coverage, there cant possibly be any bugs left...oh, look' With a little luck, that's when it finally sinks that coverage != correctness; it's just a tool to help achieve it. *That* is a valuable lesson. -mjc
Re: [perl #33031] Current object not in place at invoke time
Dan Sugalski [EMAIL PROTECTED] wrote: Currently parrot sets the current object for a method call *after* calliing invoke on the invokable thing. This is a bit problematic, since the invokable thing likely needs to have the object in place to invoke right. Fixed. leo
Re: [perl #32635] Parrot CVS help.
Will Coleda via RT [EMAIL PROTECTED] wrote: Loading platform and local hint files. Bad command or Rerunning perl Configure.pl --verbose=2 should reveal the failing program. leo
Re: Q: scope exit
Dan Sugalski [EMAIL PROTECTED] wrote: At 8:07 AM +0100 12/10/04, Leopold Toetsch wrote: * What is the intended usage of the action handler? * Specifically is this also ment for lazy DOD runs? * How is the relationship to the Cpop_pad opcode? The one thing that I figure *will* be done is that languages will push a sweep or collect op in their scope cleanup in those cases where the language knows that there's potentially easy temp cleanup that needs doing, for example filehandles that should be closed when the scope's exited if there are no outstanding references to them. That'll not be really easy: [ subroutine frame ] | | [ cleanup handler subroutine frame ] If the cleanup handler is a plain subroutine, the previous one, which should be cleaned, is alive. A lazy DOD will find the filehandle in the lexicals and likely in registers. It seems that we have to do kind of a tailcall to the cleanup handler and that we've to nullify PMC registers of the subroutine that called the cleanup handler. But that would make the cleanup handler useless for other tasks, like actively closing some resources. Doing this right needs a precise definition of the semantics of such a cleanup handler. leo
Re: overloaded operator calling conventions
Dan Sugalski [EMAIL PROTECTED] wrote: At 7:45 AM +0100 12/11/04, Leopold Toetsch wrote: Thinking more about that it seems that we don't have much chance to keep the current scheme that the destination is passed in. I fully expected this to be an issue. Perl 5 and perl 6 are going to have different conventions, (and I think there may well be at least two separate ones for perl 6, but I may be misrememebering) Ruby doesn't match, and neither do any of the other languages. [ ... ] Nothing much for it -- no matter what we choose it's going to be wrong for someone, so the sensible thing to do is choose the scheme that works best for the underlying model (which we have) and leave it to compilers and class libraries to translate to their own preferred form. I think we're likely to find that the scheme we have catches on reasonably well once we've hit release and start seeing widespread use. Shouldn't the underlying model be at least near the expectations of HLLs we want to support? It doesn't buy us anything, if we force all languages to create wrappers. And works best for the underlying model just means the code exists. Finally the current implementation can't handle singletons (like PyNone) as a return result from such opcodes. leo
Re: Objects, classes, metaclasses, and other things that go bump in the night
Dan Sugalski [EMAIL PROTECTED] wrote: subclass - To create a subclass of a class object Is existing and used. add_parent - To add a parent to the class this is invoked on become_parent - Called on the class passed as a parameter to add_parent What is the latter used for? class_type - returns some unique ID or other so all classes in one class family have the same ID What is a class family? instantiate - Called to create an object of the class Exists. add_method - called to add a method to the class remove_method - called to remove a method from a class These are the other two parts of the Cfetchmethod vtable I presume. When during packfile loading a Sub PMC constant is encountered and it's a method, Cadd_method should be called instead of CParrot_store_global? namespace_name - returns the name of this class' namespace Should we really separate the namespace name from the class name? get_anonymous_subclass - to put the object into a singleton anonymous subclass How is the singleton object created in the first place? leo
Re: [perl #33036] [BUG] python dynclasses build failure
Will Coleda via RT wrote: Sam's latest patch seems to have resolved this issue - dynclasses now build, and: perl t/harness t/dynclass/py* skips 1 test, passes everything else. What test is skipped? [EMAIL PROTECTED]:~/parrot/dynclasses$ make test cd .. ; perl -Ilib t/harness t/dynclass/*.t t/dynclass/pybuiltinok t/dynclass/pyclass..ok t/dynclass/pyfunc...ok t/dynclass/pyintok All tests successful. Files=4, Tests=37, 8 wallclock secs ( 7.59 cusr + 0.62 csys = 8.21 CPU) - Sam Ruby
Re: [perl #33032] Parameter fillin problem
At 8:48 AM -0500 12/14/04, Dan Sugalski wrote: At 9:08 AM + 12/14/04, Leopold Toetsch via RT wrote: Dan Sugalski [EMAIL PROTECTED] wrote: IMCC's doing odd things when moving PMCs into the appropriate spot when calling into functions with a large number of parameters. Here's a snip from a trace of one of the programs running. Note the lines from bytecode offset 78123, 78126, and 78130. P9 is set to P28 (which is right) then P9 is set to spill 64, which is then moved to register P10 (leaving the same PMC in P9 and P10, which isn't correct) I tried to reproduce it but failed. I've added more tests that all spill correctly. Are you using CVS head? Damn. No, I'm using a build from Nov 30th. Syncing up with CVS head breaks this code in other interesting ways. I'll go close this bug and track down the current problems. Or not. (I've got too many versions of parrot around at the moment) I see this bug happening against yesterday morning's parrot. imcc/CVS/Entries shows a date of Mon Dec 13 12:19:33 2004 for reg_alloc.c. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Uncle Bob on Coding Standards
On Tue 14 Dec 2004 17:10, Adam Turoff [EMAIL PROTECTED] wrote: On Tue, 14 Dec 2004 16:14:32 +0100, H.Merijn Brand [EMAIL PROTECTED] wrote: On Tue 14 Dec 2004 16:04, Clayton, Nik [EMAIL PROTECTED] wrote: I've normally got enough going on in my head when writing code, worrying about the house style should not be one of them. Wrong. It should be. You write, and someone else - or yourself - has to maintain the code later. This means that you have to write with style and maintainability in focus. All the time. Part of the problem is that coding style mixes a bunch of unrelated issues of varying importance. I'm with Nik that I don't care overmuch about how many spaces go around parens, whether curlys are cuddled or uncuddled, or tab expansion idiosyncracies. But there *are* issues of coding style that are of tremendous import, and can add or reduce friction on a project, especially as it grows. Things like line length, method length, naming conventions, file layout, idiomatic usage[*], etc. One example I've used in the past is from a project I worked on (in C) where we were dealing with real estate data numbers, commonly abbreviated 'rednum'. Except that they were also named, 'red', 'redno', 'rnum', 'red_num', 'red_no', 'r_num', and so on. In both variables and Ohhh, the horror. And so recognizable! functions. This was one of many sources of dissonance (and compiler errors) on the project, and was a continual drag on team productivity. Instead of just *knowing* what you needed, you often needed to grovel through half a dozen source files to figure out what you *should* have typed. This was underlighted in my example, but indeed evenly important. We've chosen to make default prefixes to veriables to reflect the (database) type: d_end All dates start with d_ (we use plain numeric 8 MMDD because none of the databases we work with have compatible date formats (fwiw we also have d_end_y, d_end_m, and d_end_d, which I now presume does not need any further explanation :)) c_city (key) code of a field that has a reference table s_city The string value for c_city and so on. But we all used the same brace placement and indenting styles. ;-) About spaces, another thing springs to mind, for which I would gladly kill the responsible people to allow it (I bet M$ was the first to push it): Spaces in database table and field names. DON'T! NEVER! Once you start it, you will never be able to escape the quicksands of (incompatible) quotation and unportability of your scripts, be that in sql, sh, perl/dbi, hli, or e/sql If you want to have portability in mind, adhere to the lowest level of available standards and don't be tempted to use archaic functions specific to a unique version of a database on a unique version of an operating system wich only runs on a specific architecture. FWIW the style I use was decided upon back in the 80's when we (me and 6 others) had to do a huge software project at school and we did discuss style before we started. The biggest argue was about the length of the variable names to use. This is where I think Uncle Bob is right -- the standards need to evolve. On this same project, there was a coding standard in place at the onset, but it standardized trivialities. Because we had a coding standard, we never saw the bigger issues of naming conventions as problems a coding standard could/should fix, so everyone improvised in their own special way with the stuff that wasn't standardized. At the onset, though, a lot of issues we had to deal with were completely unknown, since the project took three or four major course changes over the years. If all of this is true, I think we made marvellous decisions in our school days, because none of my coding standards have changed, but the decrease of an indent of 6 (very nice when programming PASCAL) to an indent of 4 (better suited for almost any other language, and since TAB is 8, much more efficient). Z. *: For example: design with closures and coderefs in mind, or with big modules with 17 optional features or 15 variations on the same method; are you intetionally using or avoiding map and grep?; what are the standard modules your project uses to write new classes? -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.5, 5.9.x, and 809 on HP-UX 10.20 11.00, 11i, AIX 4.3, AIX 5.2, SuSE 9.1, and Win2k. http://www.cmve.net/~merijn/ http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: mandelbrot
Ah yep, that surely is the reason. Too bad, have to wait until I get home ;-) - Michael On Tue, 14 Dec 2004 11:25:32 -0500 (EST), Jeff Horwitz [EMAIL PROTECTED] wrote: hm, works fine for others. maybe the weird port i'm using for that web server isn't agreeing with your firewall. -jeff On Tue, 14 Dec 2004, Michael Walter wrote: On Tue, 14 Dec 2004 10:07:43 -0500 (EST), Jeff Horwitz [EMAIL PROTECTED] wrote: is it useful? not really. does it help you waste 5 minutes of your day? certainly. :) Waiting for the request to time out indeed wasted some idle time :-) wink-ingly yours, Michael
Re: Objects, classes, metaclasses, and other things that go bump in the night
At 11:13 AM +0100 12/14/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: subclass - To create a subclass of a class object Is existing and used. Right. I was listing the things we need in the protocol. Some of them we've got, some we don't, and some of the stuff we have we probably need to toss out or redo. add_parent - To add a parent to the class this is invoked on become_parent - Called on the class passed as a parameter to add_parent What is the latter used for? To give the newly added parent class a chance to do some setup in the child class, if there's a need for it. There probably won't be in most cases, but when mixing in classes of different families I think we're going to need this. class_type - returns some unique ID or other so all classes in one class family have the same ID What is a class family? The metaclass's class. I think. This is meant to be an identifier that says what kind of class a class is, so code can make some assumptions about internal structure and such. Everything that's based on a ParrotClass PMC, for example, would have the same class_type ID. add_method - called to add a method to the class remove_method - called to remove a method from a class These are the other two parts of the Cfetchmethod vtable I presume. When during packfile loading a Sub PMC constant is encountered and it's a method, Cadd_method should be called instead of CParrot_store_global? Yeah, I think so. I'm not too happy about it, but I think that's the way things will end up. Most classes will then go and stuff the methods into the namespace, but I think it'll have to be up to the classes whether they use the namespaces for methods or not. namespace_name - returns the name of this class' namespace Should we really separate the namespace name from the class name? Yes. We're going to have cases where we've got multiple classes with the same name but different namespaces. (Generally classes masquerading as other classes, but I can see some other cases) get_anonymous_subclass - to put the object into a singleton anonymous subclass How is the singleton object created in the first place? For now, I think singletons will all be objects of a normal class that get pulled into a singleton class, most likely because code's added or changed methods on the object rather than to the class. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Uncle Bob on Coding Standards
* H.Merijn Brand [EMAIL PROTECTED] [2004-12-14T11:28:19] About spaces, another thing springs to mind, for which I would gladly kill the responsible people to allow it (I bet M$ was the first to push it): Spaces in database table and field names. DON'T! NEVER! Once you start it, you will never be able to escape the quicksands of (incompatible) quotation and unportability of your scripts, be that in sql, sh, perl/dbi, hli, or e/sql SELECT rsUniqueId FROM [SQL-ABCdatabase2K]..tblsTABLE as t JOIN [SQL-ABCdatabase2K]..tblwPRODUCT p ON p.ABC P/N = t.rsProductCode WHERE p.id IN (SELECT ItemIdentifier FROM tblSomeIds) Yup. -- rjbs pgpTjX4YpMvlh.pgp Description: PGP signature
Re: [Maybe Spam] Coverage testing success story.
On Tue, Dec 14, 2004 at 09:32:51PM -0600, Michael Carman wrote: I think this is the most valuable part of the exercise - the bugs you find when you think 'its got 98% coverage, there cant possibly be any bugs left...oh, look' With a little luck, that's when it finally sinks that coverage != correctness; it's just a tool to help achieve it. *That* is a valuable lesson. That's just a corallary to tests can't prove there are no bugs. But just in looking through the coverage for tiny points that I missed caused me to look at code that I've long ignored, like the failure diagnostic code for is_deeply(). Something I prefer not to look at. It caused me to tidy a few things up and yes, in covering the 4th possible outcome of an xor condition I found ANOTHER BUG. https://rt.cpan.org/NoAuth/Bug.html?id=8865 Minor, but still a bug. I even spotted a test that said this sort of outcome was ok. In the end, its a tool. Like all tools its not so much the tool but the hand that wields it. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Congratulations, you're a thieving bastard... Now give me back my pants. That's MISTER Pants! -- Ian's Adventures In Morrowind http://www.machall.com/morrowind/page3.html From jeff Wed Dec 15 03:47:23 2004 Return-Path: [EMAIL PROTECTED] Delivery-Date: Tue Dec 14 19:47:23 2004 Return-path: [EMAIL PROTECTED] Envelope-to: archive@mail-archive.com Delivery-date: Tue, 14 Dec 2004 19:47:23 -0800 Received: from exprod5mx127.postini.com ([64.18.0.41] helo=psmtp.com) by toko.jab.org with smtp (Exim 3.36 #1 (Debian)) id 1CeQ8J-0006fC-00 for archive@mail-archive.com; Tue, 14 Dec 2004 19:47:23 -0800 Received: from source ([64.62.137.213]) by exprod5mx127.postini.com ([64.18.4.10]) with SMTP; Tue, 14 Dec 2004 21:50:03 CST Received: (qmail 25258 invoked by uid 506); 15 Dec 2004 03:40:33 - Received: from [EMAIL PROTECTED]@[] by dns1.techscape11.com by uid 514 with powernet.co.id-antivirus-scanner (F-PROT: 3.12. Clear:0. Processed in 0.305467 secs); 15 Dec 2004 03:40:33 - Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Reply-To: [EMAIL PROTECTED] Precedence: bulk Delivered-To: mailing list [EMAIL PROTECTED] Received: (qmail 25227 invoked by uid 506); 15 Dec 2004 03:40:32 - DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=WfozWjXrOnBybSnqlbZJYjfvB98K3/zrQc8HJd3v2++mCIeQuIaF+wTrv1HJKHlI0/52LCxV4qvhPHlpgJqA+ouG0Tqe/hC40jwt2cZ7rs570+JkG9QIPasdISkD/xj6BDimF0XnKWguqwxpdNc+0TiNptbA0OTugnylwAsidaM= Message-ID: [EMAIL PROTECTED] Date: Wed, 15 Dec 2004 10:50:01 +0700 From: aBs [EMAIL PROTECTED] Reply-To: aBs [EMAIL PROTECTED] To: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: [GITARIS.COM] Jackson X-pstn-levels: (S:99.9/99.9 R:95.9108 P:95.9108 M:94.8624 C:98.9754 ) X-pstn-settings: 1 (0.1500:0.1500) gt3 gt2 gt1 r p m c X-pstn-addresses: from [EMAIL PROTECTED] [294/10] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on toko.jab.org X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=4.0 tests=BAYES_00 autolearn=ham version=2.64 wah ikutan ah... :) yg 500 rebu itu bagus apa jelek?? soalnya saya pengen ganti juga.. On Wed, 15 Dec 2004 10:47:08 +0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: seymour duncan 500 rebu-an di wijaya blok M ganti aja pick up nya biar lebih serem he he -- angga bangun subur | www.eekfactory.com - Ingin berhenti diskusi? e-mail: [EMAIL PROTECTED] Milis www.Gitaris.com didukung oleh Komunitas Gitar Indonesia. Lihat ARSIP MILIS ini via web di: http://milis.gitaris.com Brought to you by #1 DotCom Company: www.TechScape.co.id From jeff Wed Dec 15 03:47:27 2004 Return-Path: [EMAIL PROTECTED] Delivery-Date: Tue Dec 14 19:47:27 2004 Return-path: [EMAIL PROTECTED] Envelope-to: archive@mail-archive.com Delivery-date: Tue, 14 Dec 2004 19:47:27 -0800 Received: from exprod5mx120.postini.com ([64.18.0.34] helo=psmtp.com) by toko.jab.org with smtp (Exim 3.36 #1 (Debian)) id 1CeQ8N-0006fL-00 for archive@mail-archive.com; Tue, 14 Dec 2004 19:47:27 -0800 Received: from source ([194.109.24.22]) by exprod5mx120.postini.com ([64.18.4.10]) with SMTP; Tue, 14 Dec 2004 19:50:06 PST Received: from bag.python.org (bag.python.org [194.109.207.14]) by smtp-vbr2.xs4all.nl (8.12.11/8.12.11) with ESMTP id iBF3o6ah019379 for archive@mail-archive.com; Wed, 15 Dec 2004 04:50:06 +0100 (CET)
Re: Uncle Bob on Coding Standards
On Tue, Dec 14, 2004 at 11:15:13AM +, Ben Evans wrote: On Tue, Dec 14, 2004 at 05:35:53AM -0500, Michael G Schwern wrote: Tripped across this on WardsWiki just now. #5 is my favorite as its often forgotten in the noise. Oh, the noise! Oh, the noise! Noise! Noise! Noise! That's one thing he hated! The NOISE! NOISE! NOISE! NOISE! To repeat #5, coding style is about communication. The goal of style is not to enforce consistency. It is to make the code easier to read. They allow one programmer to talk to the other through the code without a lot of unnecessary in-the-head translation going on. Style should not get bogged down in syntactical issues, and we Perl programmers love our syntax. Thank you all for the demonstration. The tricker problems are the higher order problems. How are variables and methods named? When do we split something off into a method? Into its own file? When do we use OO when do we use functions? What's the preferred date handling module? What are the error handling conventions? What are the *abstractions*? -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ OH GOD!! It's LINUX! All you Linux fanboys go wild! It never crashes! It'll wash your underpants! It'll eat your dog for you, if you want your dog to be eaten! It'll make you attractive and smell good and... it'll... uh... uh. Man, I'm so sick of this shit. http://www.goats.com/archive/000602.html
