Following up on (True|False) vs Bool::$!
This is a Rakudo issue, which I found while following up on the p6l thread about literals. I'm not sure where the best place to ask about it is; I already said something on p2. I will be happy to open up an RT, but I'd like to understand what's happening so I'll have better luck making sure it's not a dupe. Maybe I'm just getting too far ahead of the development curve in terms of what I expect to work at this point. Basically, True and False are acting weird. I thought they were simply aliases for their fully-qualified brethren Bool::True and Bool::False. Is that supposed to be the case? It is true in pugs, FWTW. But in current Rakudo they seem to be distinct objects: $ perl6 -e 'say (True === Bool::True).perl' Bool::False ... and oddly lacking in identity and metadata: $ perl6 -e 'say True.WHAT' $ I thought the empty .WHAT was interesting, so I tried this, too: $ perl6 -e 'say True.WHAT.perl' $ I didn't think any .perl method would return nothing, but apparently Object.perl does, and nothing is overriding it in this case. The overall effect feels like an object-vs-primitive dichotomy, with broken/partial autoboxing. Also, as I said in the original message to p2, even though True.WHAT.perl succeeds in producing an empty string, this fails spectacularly: $ perl6 -e 'say True.perl' Method 'perl' not found for invocant of class '' current instr.: '_block11' pc 26 (EVAL_13:17) called from Sub 'parrot;PCT;HLLCompiler;eval' pc 892 (src/PCT/HLLCompiler.pir:508) called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1441 (src/PCT/HLLCompiler.pir:771) called from Sub 'parrot;Perl6;Compiler;main' pc 16573 (perl6.pir:166) perl6(37577) malloc: *** error for object 0x2f97160: Non-aligned pointer being freed (2) *** set a breakpoint in malloc_error_break to debug Segmentation fault Suggestions on next steps? Assuming I have the problem properly identified, I will be happy to submit an RT, write a test, dive into the PIR ... -- Mark J. Reed [EMAIL PROTECTED]
Re: Following up on (True|False) vs Bool::$1
The subject line should say Bool::$1 instead of Bool::$!, btw; I didn't let go of the shift key fast enough. This is what I get for trying to be clever. On Tue, Dec 9, 2008 at 9:50 AM, Mark J. Reed [EMAIL PROTECTED] wrote: This is a Rakudo issue, which I found while following up on the p6l thread about literals. I'm not sure where the best place to ask about it is; I already said something on p2. I will be happy to open up an RT, but I'd like to understand what's happening so I'll have better luck making sure it's not a dupe. Maybe I'm just getting too far ahead of the development curve in terms of what I expect to work at this point. Basically, True and False are acting weird. I thought they were simply aliases for their fully-qualified brethren Bool::True and Bool::False. Is that supposed to be the case? It is true in pugs, FWTW. But in current Rakudo they seem to be distinct objects: $ perl6 -e 'say (True === Bool::True).perl' Bool::False ... and oddly lacking in identity and metadata: $ perl6 -e 'say True.WHAT' $ I thought the empty .WHAT was interesting, so I tried this, too: $ perl6 -e 'say True.WHAT.perl' $ I didn't think any .perl method would return nothing, but apparently Object.perl does, and nothing is overriding it in this case. The overall effect feels like an object-vs-primitive dichotomy, with broken/partial autoboxing. Also, as I said in the original message to p2, even though True.WHAT.perl succeeds in producing an empty string, this fails spectacularly: $ perl6 -e 'say True.perl' Method 'perl' not found for invocant of class '' current instr.: '_block11' pc 26 (EVAL_13:17) called from Sub 'parrot;PCT;HLLCompiler;eval' pc 892 (src/PCT/HLLCompiler.pir:508) called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1441 (src/PCT/HLLCompiler.pir:771) called from Sub 'parrot;Perl6;Compiler;main' pc 16573 (perl6.pir:166) perl6(37577) malloc: *** error for object 0x2f97160: Non-aligned pointer being freed (2) *** set a breakpoint in malloc_error_break to debug Segmentation fault Suggestions on next steps? Assuming I have the problem properly identified, I will be happy to submit an RT, write a test, dive into the PIR ... -- Mark J. Reed [EMAIL PROTECTED] -- Mark J. Reed [EMAIL PROTECTED]
Boolean#perl
Prompted by the recent thread on literals... This is Rakudo Perl 6, revision 33618 built on parrot 0.8.1-devel This works: $ perl6 -e 'say Bool::True.perl' Bool::True This doesn't: $ perl6 -e 'say True.perl' Method 'perl' not found for invocant of class '' current instr.: '_block11' pc 26 (EVAL_13:17) called from Sub 'parrot;PCT;HLLCompiler;eval' pc 892 (src/PCT/HLLCompiler.pir:508) called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1441 (src/PCT/HLLCompiler.pir:771) called from Sub 'parrot;Perl6;Compiler;main' pc 16573 (perl6.pir:166) Likewise False. Shouldn't those be the same object? Why would qualifying the name give it a different set of methods? -- Mark J. Reed [EMAIL PROTECTED]
Re: Parrot doesn't build on OS X
Trunk or 0.8.0? Trunk builds fine on my iMac running the same Darwin version you report (leopard 10.5.5). On 11/1/08, Ovid [EMAIL PROTECTED] wrote: For the past few days, Parrot has failed to build on my MacBook. Today I moved my parrot directory and did a fresh svn checkout. perl Configure.pl ran fine without problem. make does fine until about here: $ make Compiling with: xx.c /usr/bin/gcc-4.0 loads of output skipped... make -C compilers/pge perl -MExtUtils::Command -e rm_f PGE.pbc ../../runtime/parrot/library/PGE.pbc perl -e PGE/builtins_gen.pir ../../parrot -o PGE.pbc --output-pbc PGE.pir ../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir --output=PGE/builtins_gen.pir PGE/builtins.pg make[1]: *** [PGE.pbc] Bus error make[1]: *** Deleting file `PGE.pbc' make: *** [compilers.dummy] Error 2 $ uname -a Darwin curtis-poes-computer-2.local 9.5.0 Darwin Kernel Version 9.5.0: Wed Sep 3 11:29:43 PDT 2008; root:xnu-1228.7.58~1/RELEASE_I386 i386 Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 -- Sent from Gmail for mobile | mobile.google.com Mark J. Reed [EMAIL PROTECTED]
Re: Known Bug in Rakudo?
On Thu, Oct 30, 2008 at 12:46 PM, Moritz Lenz
[EMAIL PROTECTED] wrote:
The correct way to define user-defined stringfication is either through
method Str { ... }
or
method prefix:~ ($self: ) { ... }
(afaict both are not implemented in Rakudo yet)
Yeah, I can't even declare a method that way (prefix:~), regardless
of whether or not Rakudo tries to call it to stringify. The $self:
isn't needed in this case, though, right? The body of the method just
uses $.x and $.y without going through a ref to the object.
As a point of comparison, Pugs accepts the operator overload
definition but doesn't honor it; ~$point still returns the generic
obj:Point.
--
Mark J. Reed [EMAIL PROTECTED]
Re: Parrot on mobile platforms?
On Fri, Oct 24, 2008 at 12:00 AM, Allison Randal [EMAIL PROTECTED] wrote: That being said, I can't imagine Apple would be terribly keen to endorse anything which requires jail breaking the phone. Don't we have contacts in Apple? Getting official approval for trying this out might be a nice thing. In fact, I already know an iPhone developer who would be a great fit for a challenge like this (if he's interested). Yes, but the mobile group is completely separate from the open source group. Still, it's worth asking. Depending on how they interpret the SDK policy: (an application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture…), any VM-based app might be verboten on the iPhone. -- Mark J. Reed [EMAIL PROTECTED]
Re: [perl #60044] [BUG?] rethrow just throwing?
On Fri, Oct 24, 2008 at 11:21 AM, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Thu, Oct 23, 2008 at 08:04:41PM -0700, Allison Randal wrote: I don't understand the problem. Is it that you expect 'rethrow' to keep the stack trace of the original 'die'? ...this is what I would expect. If I catch and then rethrow an exception, I'd expect the stack trace to continue to show the location of the original throw, not the location of the rethrow. I agree. Otherwise, what's the point of 'rethrow'? -- Mark J. Reed [EMAIL PROTECTED]
Re: Should the Length of string_substr() Ever Be Negative?
I'd say the fact that it has to do checking within the routine anyway is no reason not to add checks to catch errors earlier. Making the signature programmer-friendlier is like adding javascript validation to a web form - sure, the target of the submission still has to do its own validation, but it's still helpful for the user to do it up front. On 10/5/08, NotFound [EMAIL PROTECTED] wrote: (I'm making as many parameters and struct members unsigned as possible so that the compiler can warn us if we ever use signed values with them. This is one nice way to check some of our assumptions.) But sting_substr is called directly from opcodes, then the simpler way is that his arguments reflects directly those of the registers implied, and make all checks and conversions desired inside the function. -- Salu2 -- Sent from Gmail for mobile | mobile.google.com Mark J. Reed [EMAIL PROTECTED]
Re: Should the Length of string_substr() Ever Be Negative?
On Sun, Oct 5, 2008 at 10:10 AM, NotFound [EMAIL PROTECTED] wrote: But a fake signature makes errors harder to find and can make optimized builds works different as normal ones. I'm not sure how the signature is fake. An unsigned integer is a subset of integer. Parrot doesn't have a set of $U registers for unsigned ints, does it? I suppose the routine that's directly called from PIR could be wrapped by a separate one that gets called from Perl6 by way of the stricter signature. Although, for the record, on my part this is a purely philosophical debate about signatures vs implementation and where the constraints belong, etc. As far as substr() itself goes, I would rather see it be permissive and allow negative lengths. But unlike Perl 5, I'd prefer that it just return the empty string whenever the length is = 0. P5's weird nonnegative means length, negative means offset behavior is just way too counterintuitive IMO. -- Mark J. Reed [EMAIL PROTECTED]
Re: Dumb questions about array slicing...
Good point on the other special subscript values. The PIR as currently being generated couldn't work anyway, since the subscript is being put in an Int register instead of a PMC one. On 9/30/08, Moritz Lenz [EMAIL PROTECTED] wrote: Mark J. Reed wrote: I didn't see anything in the issue tracker, nor did any tests fail, There are failing (but TODOed) tests somewhere below t/spec/S02-builtin_data_types/ but am I correct in assuming that array slicing is simply not implemented yet in Rakudo? Correct. $ ./perl6 -e 'my @a = (1,2,3); say @a[0 .. 1];' 3 it takes the range in item context, which is the size of the range, and uses that as an index. The PIR is pretty straightforward: $I22 = infix:..($P20, $P21) ... set $P24, $P23[$I22] Is that supposed to work? Is the PIR subscript operation supposed to be smart enough to do the right thing with a subscript that happens to be a Range? Or does that onus fall on the Perl6 compiler to generate PIR that handles it more manually? I don't know that, but I know that Perl 6 needs some extra smartness for the subscript operation anyway, because it supports funky stuff with the Whatever star (@array[*-2] etc). Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/ -- Sent from Gmail for mobile | mobile.google.com Mark J. Reed [EMAIL PROTECTED]
Dumb questions about array slicing...
I didn't see anything in the issue tracker, nor did any tests fail, but am I correct in assuming that array slicing is simply not implemented yet in Rakudo? $ ./perl6 -e 'my @a = (1,2,3); say @a[0 .. 1];' 3 it takes the range in item context, which is the size of the range, and uses that as an index. The PIR is pretty straightforward: $I22 = infix:..($P20, $P21) ... set $P24, $P23[$I22] Is that supposed to work? Is the PIR subscript operation supposed to be smart enough to do the right thing with a subscript that happens to be a Range? Or does that onus fall on the Perl6 compiler to generate PIR that handles it more manually? -- Mark J. Reed [EMAIL PROTECTED]
Re: [perl #58726] [PATCH] add the option encoding to Configure.pl
If it's a single patch file, why did you still attach it as a tar? On 9/13/08, Gerd Pokorra [EMAIL PROTECTED] wrote: Hello, I am sorry for the late response. I was some days offline. The patch is now in a single patch file (generated with svn diff) and extended a little bit. Gerd Pokorra -- Sent from Gmail for mobile | mobile.google.com Mark J. Reed [EMAIL PROTECTED]
Re: encoding vs charset
unicode:\ab is illegal No way. Unicode \ab should represent U+00AB. I don't care what the byte-level representation is. In UTF-8, that's 0xc2 0xab; in UTF-16BE it's 0x00 00ab; in UTF-32LE it's 0xab 0x00 0x00 0x00. I think that there is still some confusion between the encoding of source code with the desired meaning in the charset and the internal encoding of parrot, which might be UCS2 or anything. IMESHO, the encoding of the source code should have no bearing on the interpretation of string literal escape sequences within that source code. \ab should mean U+00AB no matter whether the surrounding source code is UTF-8, ISO-8859-1, Big-5, whatever; if the source language wants to work differently, it's up to its parser to convert. -- Mark J. Reed [EMAIL PROTECTED]
Re: encoding vs charset
Uhm, by the fact that they didn't type \ab65 ? On 7/15/08, Leopold Toetsch [EMAIL PROTECTED] wrote: Am Dienstag, 15. Juli 2008 23:35 schrieb Patrick R. Michaud: On Tue, Jul 15, 2008 at 11:17:23PM +0200, Leopold Toetsch wrote: 21:51 pmichaud so unicode:« and unicode:\xab would produce exactly the same result. 21:51 pmichaud even down to being the same .pbc output. 21:51 allison pmichaud: exactly The former is a valid char in an UTF8/iso-8859-1 encoded source file and only there, while the latter is a single invalid UTF8 char part. How would you interpret unicode:\xab\x65 then? I'd want \xab and \x65 to represent two codepoints, not encoding bytes for a single codepoint. And that shall be the distinguished from: U+AB65: ꭥ by what? Pm leo -- Sent from Gmail for mobile | mobile.google.com Mark J. Reed [EMAIL PROTECTED]
Re: Renaming Plumhead
Nobody is claiming that Pharrot is a word, just that when pronouned aloud it sounds like ferret, and people are likely, with the plethora of animal project names floating around, to assume that it is in fact Ferret if they hear it before seeing it. On 6/14/08, Bob Rogers [EMAIL PROTECTED] wrote: From: Ron Blaschke [EMAIL PROTECTED] Date: Sat, 14 Jun 2008 21:45:26 +0200 Off the top of my head, I think Pharrot isn't a bad choice. Maybe written as Pherrot? As an alternative, maybe Phoebe or PHoePe? ;-) Ron Or Phoenix? Does this count as a resurrection from the ashes of Plumhead? ;-} -- Bob -- Sent from Gmail for mobile | mobile.google.com Mark J. Reed [EMAIL PROTECTED]
Re: Basic help navigating individual characters of a string
1) Wrong list. This list is for the folks who are currently implementing the new language Perl 6. You want [EMAIL PROTECTED] Send a message to [EMAIL PROTECTED] to subscribe, and please send any followups there rather than here. 2) Strings in Perl are not objects, and there is no String class - Perl 5 is simply not that object-oriented. You don't say $str = new String(blah) (which would be redundant even in Java and Javascript, since the literal already constructs an object); you just say $str = blah. Anyway, it looks like you already have a string variable in your example, namely $line[0]. 3) Since strings aren't objects, you don't call methods on them; you use functions instead. So it's not $str-length, but length($str). 4) There's no distinction between characters and strings in Perl; strings are not considered to be a collection of characters, but rather a fundamental type. So you can't index into the string. Instead, use the substr() function to pull out a substring of length 1: printf The first character of the string is '%s'\n, substr($str,0,1); Also, since print() takes multiple arguments and concatenates them, and you can interpolate variables in strings, you don't need printf most of the time: print The first character of the string is ', substr($str,0,1), '\n; ...although it is arguably clearer in this case. -- Mark J. Reed [EMAIL PROTECTED]
Re: [tutorial] pct tutorial language: Squaak implementation
If I may make a humble suggestion, it seems that using the English spelling squawk would, besides matching the English name parrot better, also avoid any confusion with Squeak, which is how I read this subject at first. (Smalltalk on Parrot?! Whoa!). But maybe that's just me. :) On 3/25/08, Klaas-Jan Stol [EMAIL PROTECTED] wrote: Hi, Attached are the 4 most important files of my implementation of the PCT tutorial language, Squaak. Ideally, these files would be accessible online through the tutorial (on parrotblog), but I don't know if that's possible. (I tried to send this earlier, having attached files separately; apparently that wasn't accepted maybe because it's executable code?, so now a zipped version) kjs -- Mark J. Reed [EMAIL PROTECTED]
Re: Character sets PDD ready for review
As a ref point, AppleScript 2.0 (not that I know if anyone wants to port that to Parrot) characters are defined as Unicode grapheme clusters, e.g. the base grapheme and its diacriticals... Is that similar to the concept of a Parrot_Rune? On 3/14/08, Leopold Toetsch [EMAIL PROTECTED] wrote: Am Samstag, 8. März 2008 13:59 schrieb Simon Cozens: Hi folks, I think I've finished doing what I can with docs/pdds/draft/pdd28_character_sets.pod for the time being. Please have a look at it, and let me know if there's anything wrong, anything unclear, anything missing or anything objectionable about it. Character set and encoding support is an absolute nightmare to get right, but I feel the stuff in this PDD gives us a good basis to work from. If there's no major problems with it, I'll pass it on to Allison for editing. 1) The Parrot internal character type «Strings in Parrot's native string format will probably be an array of Parrot_Runes.» or iso-8859-1 or UCS-2. Why: iso-8859-1 is an 1-byte-charset/encoding, where these 256 chars are matching unicode U+ - U+00FF codepoints. CPAN's BIO::folks and a lot more will like to have the speed and memory improvements of an 1-byte-encoding. UCS-2 is a fixed-width 16-bit charset, which includes the Basic Multilingual Plane [¹] of unicode. It is sufficient to represent some very high percentage of used codepoints. When Wikepedia [²] states ... cite UCS-2 (2-byte Universal Character Set) is an obsolete character encoding which is a predecessor to UTF-16. /cite ..., it's already mixing the concepts of charset and encoding. Anyway for efficiency reasons, I'd like to see this as an alternative. 2) the concept of Parrot_Rune or cite Unicode codepoint where values = 0x8000 are understood to be entries into the global Parrot_grapheme_table array. /cite seems to be implying that we are gonna starting to: a) rewrite / improve the now used ICU library b) inventing a new standard c) will do a lot of future hiring work to keep in sync with unicode folks ;-) Basically I have some concerns who will implement and maintain it. I wrote the one and only (AFAIK) test showing the ugliness of decomposed unicode [4] codepoints and I'd be glad if there would be a better solution. OTOH I don't know the impact of not having it. East European or other maybe involved folks should speak up now. Simon leo's 2¢ [1] http://en.wikipedia.org/wiki/Basic_Multilingual_Plane [2] http://en.wikipedia.org/wiki/UTF-16 [3] [EMAIL PROTECTED]:~/svn/parrot/leo find t -name '*.t' | xargs grep -w compose t/op/string_cs.t:compose S1, S1 t/pmc/object-mro.t:# ... now some tests which fail to compose the class [4] [EMAIL PROTECTED]:~/svn/parrot/leo ./parrot t/op/string_cs_46.pasm ___ǰ___ 7 8 8 7 -- Mark J. Reed [EMAIL PROTECTED]
Re: [perl #51478] PDD17PMC : argument doesn't array
On Sun, Mar 9, 2008 at 5:25 AM, chromatic [EMAIL PROTECTED] wrote:
On Saturday 08 March 2008 18:22:56 Will Coleda wrote:
No. {a b} is a string with no interpolation done.
Well, yeah, it's a string - but with a whole library of functions that
will treat it as a list. It's kind of like arguing that in Lisp, '(a
b) isn't a list - it's just a pair of cons cells where the first one's
cdr points to the second one.
At least originally, Tcl had nothing but strings, and the use of
braces as the equivalent of shell single quotes allowed for natural
control structures: when you define a proc or a loop, you're just
calling a command that takes as one of its arguments a block of code -
as a string - that it then evaluates at the appropriate time(s). Of
course, this wasn't necessarily great for performance. The modern C
implementation does store numbers as actual numbers, but I don't know
about blocks and lists and such.
--
Mark J. Reed [EMAIL PROTECTED]
Re: [PCT] PAST nodes for goto and friends, labels.
Sorry if I'm missing something here, since I haven't dived into the innards of Parrot, but I thought control flow in Parrot was based on continuations? Presumably 'control exceptions' are really just lexicaly-scoped exceptions, and exceptions are in turn just outgoing-only continuations. If you have first-class continuations, goto should be pretty straightforward to implement... Given which, since Perl6 also has first-class continuations at the HLL (albeit tucked off where some . . . what was it . . . benighted pilgrim won't run into them unexpectedly), goto might be implemented at that level instead, and come into Parrot already translated into continuation-speak (CPS, or not that far into la-la-lambda?)
Re: [svn:parrot-pdd] r25172 - trunk/docs/pdds/draft
On Jan 23, 2008 8:05 AM, [EMAIL PROTECTED] wrote: + So if you see the integer stream C0x69 0x30F, it +needs to be replaced by C0x30F. Typo - that second 0x30F should be 0x209. -- Mark J. Reed [EMAIL PROTECTED]
Re: Anyone has perl 1 docs?
On Jan 14, 2008 11:29 AM, Ron Blaschke [EMAIL PROTECTED] wrote: jesse wrote: I don't believe Perl 1 was ever ported to Windows. Well, actually it kinda was. ;-) http://www.nntp.perl.org/group/perl.perl1.porters/2005/11/msg46.html Cool! So where's that patch you mentioned? The attachment doesn't seem to have made it into the archive there... -- Mark J. Reed [EMAIL PROTECTED]
Re: [PATCH] fix for pcre test if libpcre installed in non-standard location
That output suggests that you dont have libpcre installed, which makes it not much of a test for the patch. :) On 12/19/07, James Keenan via RT [EMAIL PROTECTED] wrote: On Mon Dec 03 20:04:08 2007, [EMAIL PROTECTED] wrote: Uploading updated version of patch based on discussion with chromatic on perl6-internals mailing list. Devin: This is the result I got when I applied the 2nd version of your patch on Darwin and then ran the patched test file: [parrot] 516 $ prove -v t/library/pcre.t t/library/pcre1..1 ok 1 # skip no pcre-config ok 1/1 skipped: various reasons All tests successful, 1 subtest skipped. Files=1, Tests=1, 0 wallclock secs ( 0.13 cusr + 0.05 csys = 0.18 CPU) Is this output reasonable? Is it what I should expect? kid51 -- Mark J. Reed [EMAIL PROTECTED]
Re: Struct copying
On 6/21/07, Andy Lester [EMAIL PROTECTED] wrote: We now have STRUCT_COPY(dest,src) and STRUCT_COPY_N(dest,src,n) for all your struct-copying needs. Wait! Wait! It should be src, THEN dest! duck impending barrage of fruit -- Mark J. Reed [EMAIL PROTECTED]
Re: memcpy
On 6/20/07, Andy Lester [EMAIL PROTECTED] wrote: I guess I don't see the need to document a standard C behavior with a macro. We don't have #define inc(x) (x)++ do we? Incrementing a var is much less likely to have unpredictable effects due to modifying the wrong memory. Sure, x might be a pointer, and things might gang agley there, but pointers getting set to the wrong type of pointee is a pretty common problem, and one that I'm happy to have some runtime support in locating. -- Mark J. Reed [EMAIL PROTECTED]
Re: memcpy
On 6/20/07, Andy Lester [EMAIL PROTECTED] wrote: My point is that *d = *s; is no more a weird cryptic construct than n++; or while (*s) *d++ = *s++; for that matter. That's a very good point. As you said in the original message, all you need is *dest = *src; since the compiler will automatically complain if the two pointers don't point to the same type of object. AFAICT, the wrapping around the assignment in the macro just makes sure that there aren't any side effects - but the only reason side effects would be a problem is that it's a macro... -- Mark J. Reed [EMAIL PROTECTED]
Re: [perl #41168] graceful no compiler error message?
It's not a good assumption that the default result of a C compilation
is named a.out. On Cygwin, e.g., it's a.exe. Some compilers
default to filename.exe or bare filename (when compiling filename.c).
I think you may have to assume that it accepts the -o option and give
the tested-for executable an explicit name.
On 6/5/07, Andy Dougherty [EMAIL PROTECTED] wrote:
On Mon, 4 Jun 2007, James Keenan via RT wrote:
On Fri Jun 01 09:29:18 2007, chromatic !-- x -- at wgz.org wrote:
This patch is very close. Instead of handling compilation manually, I
recommend instead using cc_gen() and cc_build() from
Parrot::Configure::Step.
See config/auto/sizes.pm for an example.
Can you explain why using these functions would be the better course? In
particular, how
would this approach square with the criticism Andy Dougherty made earlier
in this thread on
March 21:
+ unless ( eval { cc_build(); 1 } ) {
+ warn Compilation failed with '$cc'\n;
+ exit 1;
+ }
This has two problems. First, it ignores the return value of cc_build().
That's understandable at the moment since cc_build doesn't seem to have
a
documented return value. It should, of course.
I agree with chromatic -- I'd simply add that the cc_build() function
should be improved to have a meaningful return value, not that it should
be avoided.
--
Andy Dougherty [EMAIL PROTECTED]
--
Mark J. Reed [EMAIL PROTECTED]
Re: [perl #43134] [TODO] Find a generalised way to determin location of Fink
I think with fink you can only locate it by looking for fink in the user's $PATH (assuming s/he has it set up for fink) and falling back to the default /sw otherwise. On 6/5/07, via RT Paul Cochrane [EMAIL PROTECTED] wrote: # New Ticket Created by Paul Cochrane # Please include the string: [perl #43134] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43134 In config/auto/gdbm.pm there is the following TODO item: Need a more generalized way for finding where Fink lives. this needs implementation. Is a system() call legit at that point of the config? Because I can think of no reliable, general way of looking for fink other than trying to run the fink command... -- Mark J. Reed [EMAIL PROTECTED]
Re: Coding Standard Questions
On 10/17/06, Kevin Tew [EMAIL PROTECTED] wrote:
1) *s should go right next to the type in function declarations and
definitions
I disagree; they should go right next to the name being declared,
since C declarations are designed to reflect the way the declared item
is later used: PMC *pmc, visit_info *info.
2) All structs should be typedefed
That seems reasonable. What about struct names? Around here we
require that all structs have both a struct name and a typedef, and
the two names match:
typedef struct foo {...} foo;
It's redundant except when you need to declare a self-referential
pointer, of course, but consistency for consistency's sake isn't
always bad. :)
3) Single line if and elses are acceptable
I personally don't like that. I'd rather go tthe other way and
require curlies always.
4) c89 allows declaration and initialization on the same line right?
INTVAL counter = 0;
Sure. Even pre-ANSI C allows that.
--
Mark J. Reed [EMAIL PROTECTED]
Re: [perl #40543] [NEW] Test for space after curly braces
On 10/16/06, chromatic [EMAIL PROTECTED] wrote: On Monday 16 October 2006 02:00, Paul Cochrane wrote: This patch adds a test to the coding standards which checks for space or tab characters after a curly brace when the curly is the last printable character on the line. The pumpking hasn't explicitly declared that this should be a coding standard, but particle mentioned that it was a pet peeve, and I thought I might as well write a test Is there any reason not to generalize this to report *any* whitespace character at the end of a line before the newline? That was exactly my thought when I read Paul's message Death to trailing whitespace! -- Mark J. Reed [EMAIL PROTECTED]
Re: [perl #40543] [NEW] Test for space after curly braces
On 10/16/06, jerry gay [EMAIL PROTECTED] wrote: for vim users, these settings may help find trailing spaces and leading tabs: set list set listchars=trail:-,tab:\.\ note in this case, the trailing space on the second line is intentional. ~jerry Note that :set list all by itself will reveal tabs and trailing space with the default settings; the custom listchars are optional. (Although if you ever do want hard tabs in your files, setting the tab: listchars setting is is advised, since otherwise the tabs collapse to ^I. With a custom value for tab:, the width of the tabstop is maintained in the display.) In this case, however, hard tabs seem to be taboo according to the coding standards. (And the crowd goes wild!) So another good thing to set in vim is 'expandtab', which automatically replaces tabs you type with however many spaces are needed to get to the next tabstop (whose spacing you can control with the appropriately-named 'tabstop' option). Once expandtab is on, you can issue a :retab command to replace any existing hard tabs with spaces. -- Mark J. Reed [EMAIL PROTECTED]
Proposed patch
Currently compilation fails on OS X with gcc/g++, because -bundle as the first argument gets interpreted as a request to run the undle version of the compiler. It works fine as a later argument, so there's no need to break compatibility with the Apple compiler: Index: config/init/hints/darwin.pm === --- config/init/hints/darwin.pm (revision 14355) +++ config/init/hints/darwin.pm (working copy) @@ -36,7 +36,7 @@ link= 'c++', ld = 'c++', ld_share_flags = '-dynamiclib -undefined suppress', -ld_load_flags = '-bundle -undefined suppress', +ld_load_flags = '-undefined suppress -bundle', memalign= 'some_memalign', has_dynamic_linking = 1, # XXX when built against a dynamic libparrot installable_parrot records -- Mark J. Reed [EMAIL PROTECTED]
Re: Proposed patch
Whups, sorry, I meant to say OS X 10.3, with its gcc (3.3). I agree that it seems to build fine on Tiger. On 8/30/06, Will Coleda [EMAIL PROTECTED] wrote: What version of OSX and gcc are you using? I haven't seen this problem on 10.4.7 PPC with gcc 4.0.1. Did it just break recently?? Not that I see any problem applying this patch, regardless. On Aug 30, 2006, at 4:55 PM, Mark J. Reed wrote: Currently compilation fails on OS X with gcc/g++, because -bundle as the first argument gets interpreted as a request to run the undle version of the compiler. It works fine as a later argument, so there's no need to break compatibility with the Apple compiler: Index: config/init/hints/darwin.pm === --- config/init/hints/darwin.pm (revision 14355) +++ config/init/hints/darwin.pm (working copy) @@ -36,7 +36,7 @@ link= 'c++', ld = 'c++', ld_share_flags = '-dynamiclib -undefined suppress', -ld_load_flags = '-bundle -undefined suppress', +ld_load_flags = '-undefined suppress -bundle', memalign= 'some_memalign', has_dynamic_linking = 1, # XXX when built against a dynamic libparrot installable_parrot records -- Mark J. Reed [EMAIL PROTECTED] -- Will Coke Coleda [EMAIL PROTECTED] -- Mark J. Reed [EMAIL PROTECTED]
Re: PMC Methods, Inheritance, and User-visible Classes
On 8/30/06, Luke Palmer [EMAIL PROTECTED] wrote: The problem with PHP is not that it has too much functionality, but that it is organized extremely poorly. Amen. PHP is the poster child for namespace pollution. And PHP5 actually has the tools to stop the madness; it's just a question of backward compatibility. I also really hate the HTML-multivalued-input-names-have-[] hack. And I'm not fond of the arrays are just hashes with numeric keys philosophy (which it shares with JavaScript). But other than that, I love PHP. ;-) -- Mark J. Reed [EMAIL PROTECTED]
Re: #ParrotSketch Meeting 29AUG06
OK, this is somewhat off topic, but any idea why that link gets me a I don't know what to do with this file type dialog in Firefox/Win, while all the earlier logs just come up fine as plain text? It's being served with Content-Type: text/plain, it comes up fine in IE and Firefox/Mac... and it's not just me... On 8/29/06, Will Coleda [EMAIL PROTECTED] wrote: Transcript now available at: http://www.parrotcode.org/misc/parrotsketch-logs/ irclog.parrotsketch-200608/irclog.parrotsketch.20060829 -- Will Coke Coleda [EMAIL PROTECTED] -- Mark J. Reed [EMAIL PROTECTED]
Re: #ParrotSketch Meeting 29AUG06
Ah, it's scanning the content and finding the control characters. There are a bunch of control-C's in that transcript. Cleaning those up would be helpful, although I consider this bad behavior on Firefox's part - especially since just display the [EMAIL PROTECTED] thing in the browser isn't an option in the resulting dialog. -- Mark J. Reed [EMAIL PROTECTED]
Dumb Configure.pl question
I'm trying to build parrot on OS X 10.3. It gets as afar as Determining if your C compiler is actually gcc... and then fails a link test. It turns out that it's failing because it is trying to use c++ to do the linking. Any idea why? It's using $link, not $cxx, and I haven't found an assignment $link = $cxx anywhere in config/init, but I haven't done any deep diving yet. I know that some things are built with C++ but using it for all the linking seems like bloat waiting to happen. There is no mention whatsoever of c++ in my Perl5 config, so it's not coming from there... Anyway, the reason C++ isn't linking is that it needs some libraries that aren't included in the Perl5 $libs, and I can't figure out how to get Configure.pl to add to that. I would expect it to honor LDFLAGS or LIBPATH or LD_LIBRARY_PATH or something... -- Mark J. Reed [EMAIL PROTECTED]
Re: Dumb Configure.pl question
Thanks! On 8/25/06, Will Coleda [EMAIL PROTECTED] wrote: I know C++ is needed for linking because of ICU. I can't address your concerns about using it for all the linking though. Whatever the actual program doing the linking is should still respect whatever env vars control its behavior, but you can override all these settings via arguments to Configure, if you're not using ICU. A snippet from perl Configure.pl --help: --cc=(compiler) Use the given compiler --ccflags=(flags)Use the given compiler flags --ccwarn=(flags) Use the given compiler warning flags --cxx=(compiler) Use the given C++ compiler --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=(lexer)Use the given lexical analyzer generator --yacc=(parser) Use the given parser generator Hope this helps. On Aug 25, 2006, at 10:40 AM, Mark J. Reed wrote: I'm trying to build parrot on OS X 10.3. It gets as afar as Determining if your C compiler is actually gcc... and then fails a link test. It turns out that it's failing because it is trying to use c++ to do the linking. Any idea why? It's using $link, not $cxx, and I haven't found an assignment $link = $cxx anywhere in config/init, but I haven't done any deep diving yet. I know that some things are built with C++ but using it for all the linking seems like bloat waiting to happen. There is no mention whatsoever of c++ in my Perl5 config, so it's not coming from there... Anyway, the reason C++ isn't linking is that it needs some libraries that aren't included in the Perl5 $libs, and I can't figure out how to get Configure.pl to add to that. I would expect it to honor LDFLAGS or LIBPATH or LD_LIBRARY_PATH or something... -- Mark J. Reed [EMAIL PROTECTED] -- Will Coke Coleda [EMAIL PROTECTED] -- Mark J. Reed [EMAIL PROTECTED]
Re: This week's summary
On 2004-07-28 at 20:55:28, Piers Cawley wrote: What's a math teacher? Oh, come now. You may refuse to *use* the Leftpondian short form, but pretending not to *recognize* it is a bit much. :) -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: This week's summary
On 2003-12-10 at 15:05:09, The Perl 6 Summarizer wrote: Oh yes, if you've not been following, ^op (ie, the vector operators) has become op which is, if nothing else, a right swine to write in a POD C escape. Eh, op is just a hack for people who can't type C»op«, like ANSI C trigraphs. :) Nope, still no link shortening. Noticed. Why is that? -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
