Re: [svn:parrot] r23307 - trunk/examples/sdl
On 02/12/2007, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > On Sun, Dec 02, 2007 at 10:44:08AM +0100, Paul Cochrane wrote: > > ... and I only > > needed to switch off the warnings about a lack of C > strict/warnings>. At present, this isn't a maintanence burden, but as > > soon as we get lots of nqp/perl6 files we will need to rethink how we > > handle them. I don't think it's worth worrying about just yet. > > I disagree. I think we'll quickly be accumulating a lot of Perl 6/NQP > files, and putting the nocritic lines in all of them is a bit of > a pain, as well as adjusting them all later. > > If it helps, we can start marking all such files with 'use v6;', and > then the critic (or its driver) can use that to decide if the file > should be checked. Or, if that's not good enough, then I'd at least > want to put the nocritic lines with the coda instead of at the head > of the file (if that's even possible). Unfortunately, putting the nocritic lines at the end of the file with the coda doesn't work. I think marking the files with C would be really good (this syntax isn't recognised yet though, is it?), then I could filter which files should be passed through the relevant policies of Perl::Critic. Paul
perl 6 grammar
I found some of the perl 6 new features really neat:
- creating your own type
- type casting
- junctions
- multidispatch
- :r:w:a shortcuts
- hyper operators
- some kind of oop keywords
But there are some changes in the grammar which
benefits aren't that obvious :
1- $str1 ~ $str2
2- $life = (!$monster) ?? 'safe' !! 'dead';
3- given $operator {
when '' {}
}
I do not really understand the new concatenation
style when most of the time it's '+' or '.'
I don't see how putting 2 questions marks and 2 exclamations marks
make things shorter and easier to understand.
The given ... when doesn't seem to bring that much from switch ... case
given ... if would make a little bit more sense.
And hashes require '=>' but it could be nice to switch to ':'
because then :(or perhaps we can use whatever separator we want?)
{
elems : {
deleting : {
ids : [1,2,3],
names : ['concatenation','ternary operator','switch']
},
replace : {
with : ['.','?:','switch...case']
}
};
And I know this may not sound that much but it could be sent to
javascript or actionscript or any ecmascript based languages.
This discussion has certainly be done a long time ago
but give it a try.
(any reference of functions include in perl6?)
Re: perl 6 grammar
Moritz Lenz wrote:
cdumont wrote:
1- $str1 ~ $str2
The '+' suggests numerical addition (and requires disambiguation in the
case of $str + $number - should $str be interpreted as a number, or
$number as a string?).
The . is already taken by method calls (used far more often), and is
easy to overlook when concatenating strings.
Yeah, that's what I thought about the use of the dot for hashes and objects
but hash or object :
$obj.method();
or
%hash.value();
which is visually different from :
$str.$str2
as the concatenation keeps the sigil.
I am not a huge fan of the + operator either but
well, why add a third type when the dot could be just fine ?
2 ways are already more than one.
2- $life = (!$monster) ?? 'safe' !! 'dead';
is it true??? really??? then you're safe. if not (! is not), you're
dead. PWND.
Again I think that a visually outstanding operator simplifies reading.
It's really easy to overlook a single ':', as it's used in p5.
You are right, that is outstanding but again, so many languages use
a standard ? :
To make it outstand a little bit more :
$life = (!$monster) ?? 'safe' |(^0^;)| 'dead';
But might take some time to get acoustumed to it...(just kidding)
But if we want to choose the visibility key then
$*IN
is not what I will call something especially visual even if
it's not that awful (well, depending on the keyboard this can be a reall
pain though)
3- given $operator {
when '' {}
}
...
The given ... when doesn't seem to bring that much from switch ... case
given ... if would make a little bit more sense.
I don't know the rationale about that, but perhaps it's to distinguish
given-when (which uses smartmatching) from other languages that just do
string or number comparison.
I am not native so I do not really know either but I don't feel comfortable
with profusions of different keywords in languages...
why not a :
pour $operator {
lorsque '' {}
}
And hashes require '=>' but it could be nice to switch to ':'
because then :(or perhaps we can use whatever separator we want?)
There is a :key(value) pair notation already.
And I know this may not sound that much but it could be sent to
javascript or actionscript or any ecmascript based languages.
I don't think it's a good idea to write files that can be interpreted
either as Perl 6 or as javascript. Perhaps a nice idea for an
obfuscation, though.
No, the aim is not really to write files like ECMAScript but
a very simple example is querying the db
and send the object to javascript or actionscript with a remote call
or the other way round.
The closer the basic structure is, the less manipulation will be needed.
JSON (which should be renamed ESON) is growing these days
and making interactions between languages easier is not that bad.
I have written the example so that to show the internal structure
but could be nice to just do :
my $imageGalleries = new ImgLoader($path);
print "Content-type:text/json¥n¥n";
print Dumper($imageGalleries);
Then whatever the third part, they will be able to handle the object.
it is just a kind of standard serialization to keep persistence.
Last time i used perl to connect to a DB, get the result then send it
into the php serialization format to a php program placed in an other
server.(the framework was in php so...)
Now, just dumping the result and using the json_decode function could work
and for many other languages too.
But that's not a vital point but a nice feature to have.
Anyway, I hope perl6 is going to get out soon!
I didn't really got all the oop keywords but that shouldn't be that bad.
(any reference of functions include in perl6?)
S29:
http://perlcabal.org/syn/S29.html
Thank you!
Cheers,
Moritz
--
シリル・デュモン（Cyrille Dumont）
[EMAIL PROTECTED]
our work is the portrait of ourselves
tel: 03-5690-0230 fax: 03-5690-7366
http://www.comquest.co.j
Re: perl 6 grammar
cdumont writes:
> there are some changes in the grammar which benefits aren't that
> obvious :
Hi there. For some of these the benefit is indirect: it isn't that it
makes the feature in question easier to use; instead it enables _other_
features.
> 1- $str1 ~ $str2
> I do not really understand the new concatenation style when most of
> the time it's '+' or '.'
It isn't great, but I'm sure we can live with it. It frees up dot for
other things. Anyway, because of interpolation Perl doesn't use
concatenation as much as many other langauges (and even less so in Perl
6 with method calls being interpolatable and braces for conveniently
interpolating any code at all).
It also has the advantage that tilde is consistently used in several
places in Perl 6 to indicate strings.
> 2- $life = (!$monster) ?? 'safe' !! 'dead';
> I don't see how putting 2 questions marks and 2 exclamations marks
> make things shorter and easier to understand.
Clearly it doesn't -- but then I don't think anybody is claiming that
that's the reason for the change!
Shortness isn't always a virtue; by using doubled characters they stand
out more, which makes it easier to spot when this operator is being used
-- something that's more important with this operator than most, since
it is split between two positions.
And it frees up some symbols for use in other operators.
> 3- given $operator {
> when '' {}
> }
>
>
> The given ... when doesn't seem to bring that much from switch ...
> case given ...
Surely it brings all of it? Plus much more as well. Much of the power
is in the smart-matching, which enables many different sorts of
comparisions, each naturally matching the appropriate thing. A big
advantage given has over C's switch construct is not having to include
break in the usual case (and get mysterious-yet-silent bugs if you
accidentally forget it).
> And hashes require '=>' but it could be nice to switch to ':'
Indeed it could be. But, unfortunately, the colon seemed to be top of
many people's most-wanted lists, with many different (and mutex)
suggestions for what it should do. (Remember, only a couple of
paragraphs ago you were wanting to keep it for the ? ... : operator!)
Possibly somebody could design a language in which the colon is the only
symbol used ...
> because then :(or perhaps we can use whatever separator we want?)
>
> {
> elems : {
> deleting : {
> ids : [1,2,3],
> names : ['concatenation','ternary operator','switch']
> },
> replace : {
> with : ['.','?:','switch...case']
> }
> };
> And I know this may not sound that much but it could be sent to
> javascript or actionscript or any ecmascript based languages.
The key bit of the above is your parentical comment about using whatever
separator you want -- which is exactly what Perl 6 provides the
flexibility to do. In Perl 6 it will be possible to do:
use Grammar::JSON;
and then within that file you can have the above syntax for complex
data-structures.
Or at least, it will if somebody writes the Grammar::JSON module -- but
the whole point of Perl 6's pluggable grammars is that it specifically
supports people who want to do this sort of thing: it recognizes that
not everybody is going to agree on the ideal syntax, so instead it
merely provides a 'default' syntax (which Larry judges to be the best
all-round) then provides a way of changing anything about it.
Hope that helps.
Smylers
[perl #48074] [PATCH] fix for pcre test if libpcre installed in non-standard location
# New Ticket Created by "Devin Heitmueller" # Please include the string: [perl #48074] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48074 > The attached patch will address a parrot test failure in the PCRE module (t/library/pcre.t) in the case where the libpcre library is installed in a nonstandard location. In my case, it occurs on OS X that Fink installed libpcre into /sw/lib, and so the test believes that PCRE is installed because the pcre-config utility returned zero, but it cannot find the library. The change runs pcre-config to get the location of the library, and then updates the PARROT_LIB_PATH_DYNEXT to contain the additional entry. -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller pcre.t.patch Description: Binary data
Re: perl 6 grammar
Smylers wrote:
cdumont writes:
there are some changes in the grammar which benefits aren't that
obvious :
Hi there. For some of these the benefit is indirect: it isn't that it
makes the feature in question easier to use; instead it enables _other_
features.
1- $str1 ~ $str2
I do not really understand the new concatenation style when most of
the time it's '+' or '.'
It isn't great, but I'm sure we can live with it. It frees up dot for
other things. Anyway, because of interpolation Perl doesn't use
concatenation as much as many other langauges (and even less so in Perl
6 with method calls being interpolatable and braces for conveniently
interpolating any code at all).
It also has the advantage that tilde is consistently used in several
places in Perl 6 to indicate strings.
2- $life = (!$monster) ?? 'safe' !! 'dead';
I don't see how putting 2 questions marks and 2 exclamations marks
make things shorter and easier to understand.
Clearly it doesn't -- but then I don't think anybody is claiming that
that's the reason for the change!
Shortness isn't always a virtue; by using doubled characters they stand
out more, which makes it easier to spot when this operator is being used
-- something that's more important with this operator than most, since
it is split between two positions.
And it frees up some symbols for use in other operators.
I think I can live with the ?? !! thing but ~...
3- given $operator {
when '' {}
}
The given ... when doesn't seem to bring that much from switch ...
case given ...
Surely it brings all of it? Plus much more as well. Much of the power
is in the smart-matching, which enables many different sorts of
comparisions, each naturally matching the appropriate thing. A big
advantage given has over C's switch construct is not having to include
break in the usual case (and get mysterious-yet-silent bugs if you
accidentally forget it).
I understand that given ... when is even more powerful than a simple
switch case
but why just don't say it this way : this is a switch case dopped with
hyper process and
keep the old switch ... case keywords.
I don't know why, this given... when sounds so 'English' without really
being that
English.
And hashes require '=>' but it could be nice to switch to ':'
Indeed it could be. But, unfortunately, the colon seemed to be top of
many people's most-wanted lists, with many different (and mutex)
suggestions for what it should do. (Remember, only a couple of
paragraphs ago you were wanting to keep it for the ? ... : operator!)
Possibly somebody could design a language in which the colon is the only
symbol used ...
I don't really think using the column in a ternary means that you cannot
use it
else where.
because then :(or perhaps we can use whatever separator we want?)
{
elems : {
deleting : {
ids : [1,2,3],
names : ['concatenation','ternary operator','switch']
},
replace : {
with : ['.','?:','switch...case']
}
};
And I know this may not sound that much but it could be sent to
javascript or actionscript or any ecmascript based languages.
The key bit of the above is your parentical comment about using whatever
separator you want -- which is exactly what Perl 6 provides the
flexibility to do. In Perl 6 it will be possible to do:
use Grammar::JSON;
and then within that file you can have the above syntax for complex
data-structures.
Or at least, it will if somebody writes the Grammar::JSON module -- but
the whole point of Perl 6's pluggable grammars is that it specifically
supports people who want to do this sort of thing: it recognizes that
not everybody is going to agree on the ideal syntax, so instead it
merely provides a 'default' syntax (which Larry judges to be the best
all-round) then provides a way of changing anything about it.
Hope that helps.
That's sweet !
But I wouldn't want to be most of the time on C6PAN downloading
grammars written in perl6 for perl6.
...
But being able to expand the perl6 grammar is a nice feature that
will be interesting as a learning process for me !
As for the functions, i didn't see that much for hashes and arrays which
was
a big disappointment.
Anyway, I think that perl6 has really nice features and I hope people are
going to use it a lot and that the community will be huge!!
The above points are the only things that kind of let me dubious.
Smylers
--
シリル・デュモン（Cyrille Dumont）
[EMAIL PROTECTED]
our work is the portrait of ourselves
tel: 03-5690-0230 fax: 03-5690-7366
http://www.comquest.co.j
Re: Standards bearers (was "Re: xml and perl 6")
On Fri, 30 Nov 2007 03:57:58 -0700, David Green wrote: > Part of a solution is search.cpan.org -- if you can figure out which > of the 870 XML modules will be useful to you. Another part is asking > on newsgroups or lists -- if you can figure out which of the 870 > opinions offered is knowledgeable. I think things like the CPAN > ratings and reviews will become increasingly important. Of course, > this is all a community issue (rather than a technical issue), and > questions about handling reputation are certainly not limited to Perl > or CPAN. > > Maybe some kind of "Advisory Board" would help, where people (who > might be experts in various ways) can offer informed recommendations > on what modules make a good fit for what circumstances. Ultimately, > if this is something we want, somebody needs to volunteer to organise > something. (Or volunteer to figure out exactly what it is that would > need organising) I do feel strongly that we need some sort of solution to this so that Perl 6 is not merely an outstanding framework that leaves all domain-specific extensions to the end user. Please note that I am not arguing for inclusion in the "core"; presumably I *am* arguing for some sort of standard flavors of P6 that are named and supported. If we can't solve that any better than Luke's assessment I fear we will have sold Perl 6 short to a large community. Part of the major attraction of Perl 4/5 was knowing how much was core/standard; you could write programs that did everything from DNS calls to shared memory access to database access and know that anyone anywhere with Perl could run them. But nowadays you need a slew of modules to write good programs. It would be a shame if we perpetuated in P6 the syndrome of having to be in the echo chamber [1] before you knew what those modules were. We ought to be able to spread that knowledge around a bit better. I'd just hate to see the same situation of "For good O-O, use Class::Accessor," "No, use Class::Struct," "That's ancient, use Class::Std," "No, the new standard is Object::InsideOut," "That's so 2006. All the best programmers are using Moose now." Okay, so we will have standard O-O in P6 so that scenario doesn't apply, but substitute CGI/DBI/XML/etc/etc and you have a picture that will. Does everyone who wants to know what to use to do those things properly in P6 have to be subscribed to TPR/perlmonks/clpm/perlbuzz/use.perl.org/arrgh? Can we find a way to make and maintain some recommendations in a way that people can find them easily from P6 itself? If I'm shopping for a car and I find a place that sells a fantastic drivetrain and says that they leave the choice of body, wheels, and seats to me I'm going to look somewhere else because I don't have the time to research auto component integration even though if I did I could end up with a car to die for. Maybe what we need is an editorial team. Developers tend more to want to include everything, like a Slashdot page where you have to wade through acres of dross to find something useful, because sitting in judgment on someone else's submission is distasteful. But editors are used to making judgments and dealing with the consequences. If we could find people who would do that job perhaps they could define a few standard bundles that end users and distro maintainers could choose if they don't want the core alone. Yes, it involves value judgments and we don't like to make those and people will argue about their decisions no matter what, but does that have to stop us? [1] http://groups.google.com/group/perl.perl5.porters/msg/74ecce32ff1ad845?dmode=source -- Peter Scott http://www.perlmedic.com/ http://www.perldebugged.com/
Re: Standards bearers (was "Re: xml and perl 6")
Peter Scott writes: > I do feel strongly that we need some sort of solution to this so that > Perl 6 is not merely an outstanding framework that leaves all > domain-specific extensions to the end user. OK. > Can we find a way to make and maintain some recommendations in a way > that people can find them easily from P6 itself ... Maybe what we need > is an editorial team. Build it, and they will come! This isn't something which needs to influence language design -- in the sense that it doesn't need to be sorted before the design can be final and Perl 6 released. It isn't really anything that needs to be agreed by central diktat (remember that search.cpan.org isn't in any way official -- it's 'just' a Cpan mirror which happens to have a web interface that many people find convenient). Nor is it something that needs to be got right the first time, or we need to be confident will last as long as Perl 6. (For example, ActivePerl has been the _de facto_ standard Windows Perl distribution for some time; it's possible that Strawberry Perl in time will take over that, but if so it'll just be because it gets momentum behind it and the community as a whole chooses it, not because somebody named it as such.) Smylers
Re: perl 6 grammar
cdumont writes: > Smylers wrote: > > > cdumont writes: > > > > The given ... when doesn't seem to bring that much from switch ... > > > case given ... > > > > Surely it brings all of it? Plus much more as well. Much of the > > power is in the smart-matching, which enables many different sorts > > of comparisions, each naturally matching the appropriate thing. A > > big advantage given has over C's switch construct is not having to > > include break in the usual case (and get mysterious-yet-silent bugs > > if you accidentally forget it). > > I understand that given ... when is even more powerful than a simple > switch case but why just don't say it this way : this is a switch case > dopped with hyper process Maybe the documentation will say it that way! > and keep the old switch ... case keywords. But "keeping" the "old" ones would require having them already -- which Perl doesn't. What would be the point in simultaneously introducing a flexible syntax which meets all switching needs and a less-powerful syntax (which is completely different, thereby making it more work than necessary if you outgrow its requirements and need to change to using the more flexible alternative; and which is error-prone)? > I don't know why, this given... when sounds so 'English' without > really being that English. I'm afraid you've lost me -- are you saying that given does sound English or that it doesn't? And why is it relevant either way? > > > And hashes require '=> ' but it could be nice to switch to ':' > > > > Indeed it could be. But, unfortunately, the colon seemed to be top > > of many people's most-wanted lists, with many different (and mutex) > > suggestions for what it should do. (Remember, only a couple of > > paragraphs ago you were wanting to keep it for the ? ... : > > operator!) Possibly somebody could design a language in which the > > colon is the only symbol used ... > > I don't really think using the column in a ternary means that you > cannot use it else where. We started off with that, and it was changed specifically because it was causing a problem; I can't remember exactly what, but it's in this list's archives somewhere. Remember that whatever expression you want to use the colon for is going to be valid between the ? and : parts of the ? ... : operator, and so you need to avoid the colon being confused for the : which marks the end of this part of the ? ... : operator. Also remember that we want Perl 6 to be able to complain about syntax errors -- that is, we want that when somebody makes a typo, there's a good chance of perl complaining about the source being invalid, rather than it being valid Perl 6 (but which silently does something else). > As for the functions, i didn't see that much for hashes and arrays > which was a big disappointment. What were you hoping for? Many things which were functions in Perl 5 are now also available as methods in Perl 6. If you post here with what you're disappointed to be missing, it may be that somebody can reply pointing out where the equivalent functionality is! Smylers
Re: perl 6 grammar
On Mon, Dec 03, 2007 at 12:20:02PM +, Smylers wrote: > cdumont writes: > > I don't really think using the column in a ternary means that you > > cannot use it else where. > > We started off with that, and it was changed specifically because it was > causing a problem; I can't remember exactly what, but it's in this > list's archives somewhere. > > Remember that whatever expression you want to use the colon for is going > to be valid between the ? and : parts of the ? ... : operator, and so > you need to avoid the colon being confused for the : which marks the end > of this part of the ? ... : operator. ...and it's not just the colon, but the ? also has the potential to be confusing here, because there's a prefix: operator that is used to coerce into boolean context. Which indirectly gets around to an even stronger reason for using C over C -- Perl 6 aims for a consistency in the use of the ? and ! characters to mean "boolean true" and "boolean not true". This is true not only for the operators, but also in regular expressions and other places. So, having something like $foo = $cond ?? ...if_true... !! ...if_not_true... ; achieves several important goals: - it frees up the ? and : characters for other purposes - it reinforces the convention of ? as "if true" and ! as "if false" - it is more visually distinctive, so that the ternary tokens don't get lost in the middle of other operands and expressions - it simplifies parsing (both compiler and human) and improves error reporting In my case, I've found the switch to ?? !! to be fairly natural, and that I don't use it often enough to worry about the extra characters. > > As for the functions, i didn't see that much for hashes and arrays > > which was a big disappointment. > > What were you hoping for? Many things which were functions in Perl 5 > are now also available as methods in Perl 6. If you post here with what > you're disappointed to be missing, it may be that somebody can reply > pointing out where the equivalent functionality is! As noted at the beginning of Synopsis 1: Another assumption has been that if we don't talk about something in these Synopses, it's the same as it is in Perl 5. Pm
Parrot Bug Summary
Parrot Bug Summary http://rt.perl.org/rt3/NoAuth/parrot/Overview.html Generated at Mon Dec 3 14:00:01 2007 GMT --- * Numbers * New Issues * Overview of Open Issues * Ticket Status By Version * Requestors with most open tickets --- Numbers Ticket Counts: 44 new + 731 open = 775 Created this week: 42 Closed this week: 31 --- New Issues New issues that have not been responded to yet 1 - 2 weeks old 47822 [Cola] - uses old 'float' type. 47764 [TODO] COW for one or all users of a modified string 2 - 3 weeks old 3 - 4 weeks old 4 - 5 weeks old 47153 [PATCH][Review] Proposed change from PMC_IS_NULL to PMC_is_null 47141 [PDD19] Line directive 47109 [CAGE] wrap macro args in parens inside macro bodies 5 - 6 weeks old 46971 [DEPRECATED] newfrom sub/method in PGE 46933 [PATCH] [RFE] Change behavior of Data::Dumper wrt Undef 46925 [TODO] [C] Call pmc slicing functions from PackFiles thaw() 46923 [TODO] [C] Check flags of parrot_range object in elements() method Slice PMC 46761 Dynpmcs and ParrotLibrary Global Destruction 46757 [BUG] Segfault in Parrot_TclString_nci_get_list 6 - 7 weeks old 46597 wrong NOTNULL in Parrot_init_arg_indexes_and_sig_pmc 46593 [PATCH] better documentation on parameter passing 46479 Remove rt.saved.search from tools/util/release.json? 46457 [BUG][IMCC] long sub invocation with named parameters 7 - 8 weeks old 46437 refactor interpreter cloning so it doesn't redundantly reinsert subs 46295 [CAGE] [pdd15oo] Review the docs w.r.t. the new OO implementation 8 - 9 weeks old 9 - 10 weeks old 45857 [IMCC][RFC] #line vs .line 10 - 11 weeks old 45659 Tcl - [string is double .1] returns wrong value 45503 one test in 't/op/string.t' is failling for jit runcore 11 - 12 weeks old 12 - 13 weeks old 13 - 14 weeks old 14 - 15 weeks old 44979 [BUG] TGE reports an error, but won't say which line it's on. 15 - 16 weeks old 44765 [PATCH] Don't reuse interpreter argument on stack 16 - 17 weeks old 44471 [PATCH] :vtable is ignored when :anon 17 - 18 weeks old 18 - 19 weeks old 44139 opcodes, warnings, and exceptions 19 - 20 weeks old 20 - 21 weeks old --- Overview of Open Issues PlatformSeverity Tag Lang aix0abandoned 0 5005threads 0 Amber0 All3fatal 3 bounce0 BASIC0 bsdos 0High 0 Bug 67 bc 0 cygwin 4low 1 compiler 0 befunge 0 cygwin_nt 0medium0 configure 0 bf 0 darwin 4none 1 core 0 cola 1 dec_osf0Normal1 dailybuild0 forth0 dgux 0unknown 0 docs 2 jako 0 dos0Wishlist 3 duplicate 0 Lisp 1 dynixptx 0 install 1 m4 0 freebsd8 library 0 ook 0 generic0 notabug 0 perl61 gnu0 notok 0 plot 0 HPUX 2 ok0 punie0 irix 0 Patch50 pynie2 irix64 0 regex 0 python 0 Linux 3 sendToCPAN0 ruby 0 lynxos 0 Todo453 scheme 0 mac0 unknown 0 tcl 72 machten0 utilities 0 urm 0 macos 0 wontfix 0 Zcode0 MacOS X2 mswin320 netbsd 1 next 0 openbsd2 os20 os390 0 other 0 powerux0 qnx0 riscos 0 sco0 Solaris4 sunos 1 svr4 0 svr5 0 sysv 0 unicos 0 unicosmk 0 unix 0 unknown0 uts0 vms0 VOS0 Win32 10 --- Ticket Status By Version New or OpenResolved --- Requestors with most open tickets Paul Cochrane 330 Will Coleda63 James Keenan 47 Jerry Gay 37 chromatic 28 jerry gay 22 Matt Diephouse 20 Bernhard Schmalhofer 15 Patrick R. Michaud 14 Leopold Toetsch13
[perl #48090] plumhead smoke test presents prompt
# New Ticket Created by "B. Estrade" # Please include the string: [perl #48090] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48090 > --- osname= freebsd osvers= 7.0-current arch= i386-freebsd-64int cc= cc --- Flags: category=languages severity=high ack=no --- Here is the snippet, the ">" is some sort of interactive prompt, which makes automated smoke testing a pain. I also don't know immediately how to get past it.: gmake -C plumhead gmake: Entering directory `/usr/home/estrabd/estrabd-at-gmail-dot-com/parrot/languages/plumhead' ../../parrot -o src/common/plumheadlib.pbc src/common/builtins.pir ../../parrot ../../compilers/pge/pgc.pir > --- Summary of my parrot 0.5.0 (r23318) configuration: configdate='Sun Dec 2 01:15:29 2007 GMT' Platform: osname=freebsd, archname=i386-freebsd-64int jitcapable=1, jitarchname=i386-freebsd, jitosname=FREEBSD, jitcpuarch=i386 execcapable=1 perl=perl Compiler: cc='gcc43', ccflags='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.8/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -pipe -Wdeclaration-after-statement -I/usr/local/include -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_FORMAT -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 -mno-accumulate-outgoing-args -W -Wall -Waggregate-return -Wbad-function-cast -Wc++-compat -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdeclaration-after-statement -Wdisabled-optimization -Wextra -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wimport -Winit-self -Winline -Winvalid-pch -Wlogical-op -Wmain -Wmissing-braces -Wmissing-declarations -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-include-dirs -Wmissing-prototypes -Wnested-externs -Wno-endif-labels -Wno-shadow -Wno-unu! sed -Wnonnull -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wvariadic-macros -Wwrite-strings', Linker and Libraries: ld='gcc43', ldflags=' -Wl,-E -L/usr/local/lib', cc_ldflags='', libs='-lm -lcrypt -lutil -pthread -lgmp -lreadline' Dynamic Linking: share_ext='.so', ld_share_flags='-shared -L/usr/local/lib', load_ext='.so', ld_load_flags='-shared -L/usr/local/lib' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=1234, nv=double, numvalsize=8, doublesize=8 --- Environment: HOME =/home/estrabd LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH =/usr/local/intel_cc_80/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/home/estrabd/bin SHELL =/bin/sh
Re: [perl #48090] plumhead smoke test presents prompt
B. Estrade (via RT) schrieb: # New Ticket Created by "B. Estrade" # Please include the string: [perl #48090] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48090 > --- osname= freebsd osvers= 7.0-current arch= i386-freebsd-64int cc= cc --- Flags: category=languages severity=high ack=no --- Here is the snippet, the ">" is some sort of interactive prompt, which makes automated smoke testing a pain. I also don't know immediately how to get past it.: Sorry I broke this when I reformated the template for languages/Plumhead/Makefile. I forgot to add a '\' for line continuation in that target. I should be fixed in r23354. Actually in SVN head 'pgc' isn't used at all, as I'm porting over to the new PCT. Thanks for the report, Bernhard
Re: perl 6 grammar
On Mon, Dec 03, 2007 at 07:30:53PM +0900, cdumont wrote: > Moritz Lenz wrote: > >> cdumont wrote: >> >>> 1- $str1 ~ $str2 >>> >> >> The '+' suggests numerical addition (and requires disambiguation in the >> case of $str + $number - should $str be interpreted as a number, or >> $number as a string?). >> >> The . is already taken by method calls (used far more often), and is >> easy to overlook when concatenating strings. >> > > Yeah, that's what I thought about the use of the dot for hashes and objects > but hash or object : > > $obj.method(); > or > %hash.value(); > > which is visually different from : > > $str.$str2 > > as the concatenation keeps the sigil. > > I am not a huge fan of the + operator either but > well, why add a third type when the dot could be just fine ? Because it wouldn't be just fine. Even in Perl 5 we have $obj->$method, so if you're going to allow indirect methods and use . for method calls, $a.$b has to be an indirect method call, not a concatenation. In general, one of the design principles of Perl 6 is that we never overload operators to do very different things, because even if we can think of a way to finesse it right now, it has a negative impact on both extensibility and readability. It impacts extensibility because you leave yourself no "wiggle room" in the grammar for future changes. It impacts readability because you have to stop to consider the context to decide which operation is going to happen. This is why Perl 5's x is now split into x and xx, for instance. Though Perl 5 got some things right, by this principle. We never made the mistake of confusing addition with concatenation. Not only is concatenation not numeric, it's not even commutative! > 2 ways are already more than one. If you're doing 3 very different things, then doing it 2 ways is suboptimal. Things that are different should look different. Also, keeping operators in 1::1 correspondence with operations gives the optimizer the most chance to figure things out at compile time without having to know types at run time. (An oversimplicifcation, I know, especially given how Perl 6 does multiple dispatch on operators at run time.) Nevertheless, most of the overloading of operators historically has been to avoid using up the ASCII sequences, and now that we allow users to define Unicode operators, that artificial pressure has mostly been removed. That being said, there's still contention for the short ASCII sequences, and you shouldn't assume that any Perl 6 operator is what it is for a single reason. Generally, most of these operators have four or five reasons for being what they are, and some of those reasons relate to what has already been taken by other more important operators. Plus there is consistency with the rest of the language, where ~ generally indicates some kind of string operation. >>> 2- $life = (!$monster) ?? 'safe' !! 'dead'; >>> >> >> is it true??? really??? then you're safe. if not (! is not), you're >> dead. PWND. >> >> Again I think that a visually outstanding operator simplifies reading. >> It's really easy to overlook a single ':', as it's used in p5. >> >> > > You are right, that is outstanding but again, so many languages use > a standard ? : Languages copy all sorts of suboptimal features from other languages. After all, that's how Perl 1 got ?: from C. That doesn't make it right or wrong, merely convenient to learn. Learnability has always been a secondary goal in Perl 5, compared to expressiveness, which is a primary goal. When a language is first starting out, it *must* copy a lot of bad constructs from other languages, or it will not easily be accepted (see Icon for a sad example of this). With the wide acceptance of Perl 5, we have the opportunity to use that as a cultural basis for change. It remains to be seen whether we can succeed with that, but most of the signs are positive. Most people only panic about once when making the mental switch from Perl 5 to Perl 6. But if you want to panic once per operator, that's okay too. :) > To make it outstand a little bit more : > > $life = (!$monster) ?? 'safe' |(^0^;)| 'dead'; > > But might take some time to get acoustumed to it...(just kidding) Sure, if we used |(^0^;)| elsewhere in Perl 6 to indicate false things, but we use ! elsewhere for that, along with ? for true things, so the ??!! falls out of that naturally. Also, it fits better with the other short-circuit/control-flow operators that are spelled || and &&. Plus ? and : are important short sequences that should not be wasted on something as unimportant as the conditional operator. Most of this reasoning is spelled out long ago in Apocalypse 3, though the switch from ??:: to ??!! came later. > But if we want to choose the visibility key then > > $*IN > > is not what I will call something especially visual even if > it's not that awful (well, depending on the keyboard this can be a reall > pain though) I don't understand your complain
Re: [perl #47011] [DEPRECATED] VTABLE entry 'new_from_string'
Will Coleda via RT wrote: Hunt down existing use of 'new_i_s' and either replace or remove the functionality. The FixedIntegerArray is an example of where 'new_from_string' is used. 'new_i_s' was experimental and can die. Any PMC's using the behavior can instead pass a hash argument to 'new'. Given the usage in compilers/imcc/pbc.c: _class = interp->vtables[r->pmc_type]->pmc_class; p = VTABLE_new_from_string(interp, _class, s, PObj_constant_FLAG); Is there a standard for passing the flags? In the old scheme, we had a specific argument to pass in the flags... There are a lot of cases where we pass in flags here; Do we now have to create a Hash PMC in each case? If it's a Hash, then we have to setup a convention to pass the flags... but doing this just as a convention seems to be ripe for mistakes; Clues welcome on how to proceed. It was already just a convention, and various different PMCs used the arguments passed to 'new_from_string' in different ways. To kick things off, let's convert the few PMCs that implement the 'new_from_string' vtable function to handle the behavior in 'init_pmc' using 'flags' and 'string_rep'. The 'flags' key in the init hash can be the integer flags, and 'string_rep' the string value for 'new_from_string'. Though, I suspect a bit of intelligence should be applied, with saner names for some of the PMCs. Creating a hash is expensive, but then new_from_string was also quite rare (only implemented on 4 PMCs), so isn't a huge target for optimization. Allison
Re: Pair notation for number radix
On Sat, Oct 06, 2007 at 04:00:18PM -0500, brian d foy wrote:
: This is basically the same question I had about file test operators
: earlier
: (http://www.nntp.perl.org/group/perl.perl6.language/2007/04/msg27415.htm
: l). I never got an answer on my syntax question and the discussion went
: off to talk about file tests instead of pair notation.
Sorry, keep meaning to answer things and then get distracted. It's only
been, what, two months since you sent this message... :)
: >From S02 "The general radix form of a number involves prefixing with
: the radix in adverbial form".
:
: This seems to say that there are non-general radix forms, and that
: those might involve a different radix form that's not adverbial.
Nope, anything else is just a function/method call.
: Later in the "Literals" section of S02, there's a chart of the
: corresponding forms for fat arrow, pair, and paren notation. It has
:
:a => 'foo' :a :a()
:
: That looks like it might mean that these are corresponding forms:
:
:8 => 377:8<377>:8(377)
The first is just a pair of 8 and 377, and has no special numeric
significance. The adverbial syntax is special in that, for ordinary
pairs, what follows the colon must be an identifier, so :8<377>
would ordinarily be illegal. And because it would be illegal, we
can just reuse that syntax for an easy way to write radix literals.
It happens to fall out from this that the parenthetical form (which
allows an arbitrary expression returning a string instead of a literal
string) gives us a way to get rid of the badly named "hex" and "oct"
functions, which are bass-ackwards from the usual conversion functions
in that they name the input rather than the output.
The :8(377) above is a bit wrong, by the way, and works only because
decimal 377 happens to stringify to something that looks like an
octal number. You couldn't, for instance, say :16(deadbeef) unless
deadbeef() was a 0-ary (or listop with no args) function returning
a hex string.
: Now, if I can do that, what happens to the pair form in a hash composer
: when I want the key of '8' and the value of :10<377>?
The situation doesn't arise, since you can't create a pair starting
with :8 anyway.
: Also, going a bit further, the table lists
:
:a => :a :a()
:
: So can I do things like
:
:255 => <10 1 0 6>; # hey, that looks like an IP address
That's just a pair equivalent to 255 => (10,1,0,6), which promotes
to 255 => [10,1,0,6] because => is scalar context on both sides.
The construct has no numeric significance in terms of radix.
::255<10 1 0 6>; # is that the same as :255[ 10,1,0,6 ] ?
Unspecced, but yes, that would probably be allowable if we force
:255{10,1,0,6} to mean the same as :255[10,1,0,6].
Except, if you were really trying to generate an IPv4 address, I'd
suggest using :256 instead. :)
: And, if that works, what might this do?
:
:q:w:255<10 1 0 6>
That would almost certainly be illegal syntactically on the face of it,
since the quote syntax doesn't know :255, and the quote syntax must
understand its options at compile time because that may influence how
the quoted string will be parsed.
If passed to an ordinary function where a term is expected, it's just
a literal number term. If passed adverbially where an operator is
expected, it's likely to fail at compile time as "two terms in a row",
and if somehow it got past that, it'd attempt to bind to an optional
parameter named 255, which you can't declare, so it fails. Anyway,
it's gonna blow up one way or another. I guarantee it. :)
Larry
Re: [perl #47011] [DEPRECATED] VTABLE entry 'new_from_string'
On Dec 3, 2007 11:25 AM, Allison Randal <[EMAIL PROTECTED]> wrote: > Creating a hash is expensive, but then new_from_string was also quite > rare (only implemented on 4 PMCs), so isn't a huge target for optimization. > careful... one of these PMCs is FixedIntegerArray. FIA is used to set the flags for parrot calling conventions, so it's constructed every time a subroutine is entered or exited. i'd prefer to see new_from_string go away, but it seems to me benchmarks are in order due to the amount of times this code is likely to be called in a typical program. ~jerry
Re: [perl #47998] r23293: Make smoke "invalid format" failure
Hey, I believe I've found it. There was an update to lib/Parrot/Revision.pm (#23179) to add "--xml" to the snv info request used to get the current Parrot checkedout revision. However, on svn v1.2 (1.2.1) that fails and you get a revision of zero which nobody likes. So, while upgrading svn here fixes the issue, I notice a google brings up a couple other folks who've run into this issue too. Thanks. a Andy Bach Systems Mangler Internet: [EMAIL PROTECTED] VOICE: (608) 261-5738 FAX 264-5932 Remember, the first rule of optimisation is: don't do it yet. :-) Brian Raven
Re: [perl #47011] [DEPRECATED] VTABLE entry 'new_from_string'
jerry gay wrote: careful... one of these PMCs is FixedIntegerArray. FIA is used to set the flags for parrot calling conventions, so it's constructed every time a subroutine is entered or exited. i'd prefer to see new_from_string go away, but it seems to me benchmarks are in order due to the amount of times this code is likely to be called in a typical program. Which raises the usual sort of questions: - Is FIA the best possible implementation solution for PCC flags? - Does that logic, parsing the signature string, really belong in the FIA PMC? It is specific to PCC, and would seem more appropriate as a routine someplace like src/inter_call.c. (That's true even if it ultimately creates a FIA.) Allison
Re: [perl #47011] [DEPRECATED] VTABLE entry 'new_from_string'
The logic was present in FIA, before PCC was written. It was reused in an attempt to "don't repeat yourself". Kevin Allison Randal wrote: jerry gay wrote: careful... one of these PMCs is FixedIntegerArray. FIA is used to set the flags for parrot calling conventions, so it's constructed every time a subroutine is entered or exited. i'd prefer to see new_from_string go away, but it seems to me benchmarks are in order due to the amount of times this code is likely to be called in a typical program. Which raises the usual sort of questions: - Is FIA the best possible implementation solution for PCC flags? - Does that logic, parsing the signature string, really belong in the FIA PMC? It is specific to PCC, and would seem more appropriate as a routine someplace like src/inter_call.c. (That's true even if it ultimately creates a FIA.) Allison
[svn:perl6-synopsis] r14470 - doc/trunk/design/syn
Author: larry Date: Mon Dec 3 15:55:10 2007 New Revision: 14470 Modified: doc/trunk/design/syn/S02.pod doc/trunk/design/syn/S05.pod Log: Mention that Int assumes 2's complement semantics when viewed via bitops. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podMon Dec 3 15:55:10 2007 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 10 Aug 2004 - Last Modified: 26 Sep 2007 + Last Modified: 3 Dec 2007 Number: 2 - Version: 119 + Version: 120 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -616,6 +616,10 @@ Perl 6 intrinsically supports big integers and rationals through its system of type declarations. C automatically supports promotion to arbitrary precision, as well as holding C and C values. +Note that C assumes 2's complement arithmetic, so C<+^1 == -2> +is guaranteed. (Native C operations need not support this on +machines that are not natively 2's complement. You must convert to +and from C to do portable bitops on such ancient hardware.) (C may support arbitrary-precision floating-point arithmetic, but is not required to unless we can do so portably and efficiently. C Modified: doc/trunk/design/syn/S05.pod == --- doc/trunk/design/syn/S05.pod(original) +++ doc/trunk/design/syn/S05.podMon Dec 3 15:55:10 2007 @@ -587,7 +587,7 @@ would allow any identifier (including any identifier containing "moose" as a substring) as long as the identifier as a whole is not -equal to "moose". (Note the anchors, which attach submatch to the +equal to "moose". (Note the anchors, which attach the submatch to the beginning and end of the identifier as if that were the entire match.) When used as part of a longer match, for clarity it might be good to use extra brackets:
Re: [perl #47998] r23293: Make smoke "invalid format" failure
Yes, up upgrading svn does it. I had noticed that the configure listing *wasn't* showing the revision number (D'oh!) and now it does Determining whether (exuberant) ctags is installed.yes. Running CPU specific stuffdone. Determining Parrot's revision...r23410. Determining whether ICU is installedno. Generating C headers..done. and make smoke works. Unless somebody wants to add a patch to check for svn versions, you can close this one as of my account. Andy Bach Systems Mangler Internet: [EMAIL PROTECTED] VOICE: (608) 261-5738 FAX 264-5932 Remember, the first rule of optimisation is: don't do it yet. :-) Brian Raven
[perl #43307] [TODO] config/auto/aio.pm: Write unit tests
I haven't completely sorted through the above issues, but here's a
somewhat refactored module and two test files. Because of issues
discussed in RT 48070, I'm suggesting the use of IO::CaptureOutput
rather than Parrot::IO::Capture::Mini for capturing verbose output.
I've enclosed the relevant tests in a SKIP block for those (many) of you
who do not have this module installed. Please let me know of any problems.
I will apply the patch in 2-3 days if no one objects. Thank you very much.
kid51
Index: MANIFEST
===
--- MANIFEST(revision 23423)
+++ MANIFEST(working copy)
@@ -1,7 +1,7 @@
# ex: set ro:
# $Id$
#
-# generated by tools/dev/mk_manifest_and_skip.pl Mon Dec 3 17:41:41 2007 UT
+# generated by tools/dev/mk_manifest_and_skip.pl Tue Dec 4 00:18:30 2007 UT
#
# See tools/dev/install_files.pl for documentation on the
# format of this file.
@@ -3115,7 +3115,8 @@
t/configure/141-auto_env-01.t []
t/configure/141-auto_env-02.t []
t/configure/141-auto_env-03.t []
-t/configure/142-auto_aio.t []
+t/configure/142-auto_aio-01.t []
+t/configure/142-auto_aio-02.t []
t/configure/143-auto_gmp-01.t []
t/configure/144-auto_readline.t []
t/configure/145-auto_gdbm-01.t []
Index: t/configure/142-auto_aio-01.t
===
--- t/configure/142-auto_aio-01.t (revision 0)
+++ t/configure/142-auto_aio-01.t (revision 0)
@@ -0,0 +1,85 @@
+#! perl
+# Copyright (C) 2007, The Perl Foundation.
+# $Id$
+# 142-auto_aio-01.t
+
+use strict;
+use warnings;
+use Test::More tests => 12;
+use Carp;
+use lib qw( lib t/configure/testlib );
+use_ok('config::init::defaults');
+use_ok('config::auto::aio');
+use Parrot::Configure;
+use Parrot::Configure::Options qw( process_options );
+use Parrot::Configure::Test qw( test_step_thru_runstep);
+
+my $args = process_options(
+{
+argv => [ ],
+mode => q{configure},
+}
+);
+
+my $conf = Parrot::Configure->new;
+
+test_step_thru_runstep( $conf, q{init::defaults}, $args );
+
+my $pkg = q{auto::aio};
+
+$conf->add_steps($pkg);
+$conf->options->set( %{$args} );
+
+my ( $task, $step_name, @step_params, $step);
+$task= $conf->steps->[1];
+$step_name = $task->step;
[EMAIL PROTECTED] = @{ $task->params };
+
+$step = $step_name->new();
+ok( defined $step, "$step_name constructor returned defined value" );
+isa_ok( $step, $step_name );
+ok( $step->description(), "$step_name has description" );
+
+my $ret = $step->runstep($conf);
+ok( $ret, "$step_name runstep() returned true value" );
+like(
+$step->result(),
+qr/^(yes|no)$/i,
+"One of two possible valid results was set"
+);
+
+pass("Completed all tests in $0");
+
+### DOCUMENTATION ###
+
+=head1 NAME
+
+142-auto_aio-01.t - test config::auto::aio
+
+=head1 SYNOPSIS
+
+% prove t/configure/142-auto_aio-01.t
+
+=head1 DESCRIPTION
+
+The files in this directory test functionality used by F.
+
+The tests in this file test methods found in configuration step class
+config::auto::aio.
+
+=head1 AUTHOR
+
+James E Keenan
+
+=head1 SEE ALSO
+
+config::auto::aio, F.
+
+=cut
+
+# Local Variables:
+# mode: cperl
+# cperl-indent-level: 4
+# fill-column: 100
+# End:
+# vim: expandtab shiftwidth=4:
Property changes on: t/configure/142-auto_aio-01.t
___
Name: svn:mime-type
+ text/plain
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native
Index: t/configure/142-auto_aio-02.t
===
--- t/configure/142-auto_aio-02.t (revision 0)
+++ t/configure/142-auto_aio-02.t (revision 0)
@@ -0,0 +1,97 @@
+#! perl
+# Copyright (C) 2007, The Perl Foundation.
+# $Id$
+# 142-auto_aio-02.t
+
+use strict;
+use warnings;
+use Test::More tests => 14;
+use Carp;
+use lib qw( lib t/configure/testlib );
+use_ok('config::init::defaults');
+use_ok('config::auto::aio');
+use Parrot::Configure;
+use Parrot::Configure::Options qw( process_options );
+use Parrot::Configure::Test qw( test_step_thru_runstep);
+
+my $args = process_options(
+{
+argv => [ q{--verbose} ],
+mode => q{configure},
+}
+);
+
+my $conf = Parrot::Configure->new;
+
+test_step_thru_runstep( $conf, q{init::defaults}, $args );
+
+my $pkg = q{auto::aio};
+
+$conf->add_steps($pkg);
+$conf->options->set( %{$args} );
+
+my ( $task, $step_name, @step_params, $step);
+$task= $conf->steps->[1];
+$step_name = $task->step;
[EMAIL PROTECTED] = @{ $task->params };
+
+$step = $step_name->new();
+ok( defined $step, "$step_name constructor returned defin
[perl #44171] [TODO] config/auto/attributes.pm: Write unit tests
Have heard no complaints; resolving ticket.
[perl #41597] [PATCH] replacing explicit access to $^O in Configure
Patches applied to trunk in r23427 Dec 03 2007.
[perl #47902] [PATCH] Confine calls to Perl 5 %Config to init::defaults
Patches applied to trunk in r23427 Dec 03 2007.
PDD16 details
I have been looking a bit inside PDDs and parrot source and find no way to
load a pointer to a function as a PMC inside the VM.
What I want to do is to embed parrot into a C program and make some of the
functions of this C program available via NCI to the vm.
I have achieved this by using the tip noted in docs/compiler_faq.pod (thanks
kjs!)
which says I need to pass a null string to loadlib and compile the parent C
program
with -export-dynamic which is GCC specific... So imho looks like an ugly system-
dependant 'hack'.
I have found some interesting funcs in src/inter_misc.c but seems not to fix
the problem,
can anybody give me an appoint? I know that the NCI part is not yet finished,
but IMHO
these functions should follow the Parrot_ name convention and make them
available from
the Parrot API.
Here's the source:
#include
void func()
{
printf("Hello World!\n");
}
int main(int argc, char **argv)
{
PMC *method;
Parrot_Interp pvm = Parrot_new(NULL);
register_nci_method(pvm, enum_class_NCI, &func, "func", "v");
Parrot_PackFile pf = Parrot_readbc(pvm, "hello.pbc");
if (pf == NULL) {
fprintf(stderr, "Oops. Cannot open hello.pbc\n");
return 1;
}
/* */
Parrot_loadbc(pvm, pf);
Parrot_runcode(pvm, argc, argv);
Parrot_destroy(pvm);
}
$ cat hello.pir
.sub main :main
func()
say "Hello World"
.end
$ cat Makefile
all:
parrot -o hello.pbc hello.pir
gcc main.c `pkg-config --cflags --libs parrot` -export-dynamic
Thanks!
--pancake
[perl #47313] [BUG] config/auto/va_ptr.pm delivering surprising result
No complaints heard; resolving ticket.
[perl #48036] [PATCH] Add --silent option to Parrot configuration
Patches committed to trunk in r23430 Dec 03 2007.
Re: perl 6 grammar
Patrick R. Michaud wrote: On Mon, Dec 03, 2007 at 12:20:02PM +, Smylers wrote: cdumont writes: I don't really think using the column in a ternary means that you cannot use it else where. We started off with that, and it was changed specifically because it was causing a problem; I can't remember exactly what, but it's in this list's archives somewhere. Remember that whatever expression you want to use the colon for is going to be valid between the ? and : parts of the ? ... : operator, and so you need to avoid the colon being confused for the : which marks the end of this part of the ? ... : operator. ...and it's not just the colon, but the ? also has the potential to be confusing here, because there's a prefix: operator that is used to coerce into boolean context. Which indirectly gets around to an even stronger reason for using C over C -- Perl 6 aims for a consistency in the use of the ? and ! characters to mean "boolean true" and "boolean not true". This is true not only for the operators, but also in regular expressions and other places. So, having something like $foo = $cond ?? ...if_true... !! ...if_not_true... ; achieves several important goals: - it frees up the ? and : characters for other purposes - it reinforces the convention of ? as "if true" and ! as "if false" - it is more visually distinctive, so that the ternary tokens don't get lost in the middle of other operands and expressions - it simplifies parsing (both compiler and human) and improves error reporting In my case, I've found the switch to ?? !! to be fairly natural, and that I don't use it often enough to worry about the extra characters. OK that explains the logic behind the conclusion. Thank you! I don't use it that much either but it was for the sake of coherence with other languages but Mr. Wall got the point in his response! -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.j
Re: perl 6 grammar
Smylers wrote: cdumont writes: Smylers wrote: cdumont writes: The given ... when doesn't seem to bring that much from switch ... case given ... Surely it brings all of it? Plus much more as well. Much of the power is in the smart-matching, which enables many different sorts of comparisions, each naturally matching the appropriate thing. A big advantage given has over C's switch construct is not having to include break in the usual case (and get mysterious-yet-silent bugs if you accidentally forget it). I understand that given ... when is even more powerful than a simple switch case but why just don't say it this way : this is a switch case dopped with hyper process Maybe the documentation will say it that way! Well, hope so... if we could talk about the doc too... and keep the old switch ... case keywords. But "keeping" the "old" ones would require having them already -- which Perl doesn't. What would be the point in simultaneously introducing a flexible syntax which meets all switching needs and a less-powerful syntax (which is completely different, thereby making it more work than necessary if you outgrow its requirements and need to change to using the more flexible alternative; and which is error-prone)? I am sorry, I meant : keep the old school switch ... case keywords that we inherited from other languages. I don't think the syntax should be the same exactly. I just want to avoid having to learn or expose people that are not native English speakers to too many keywords. I don't know why, this given... when sounds so 'English' without really being that English. I'm afraid you've lost me -- are you saying that given does sound English or that it doesn't? And why is it relevant either way? See above. And hashes require '=> ' but it could be nice to switch to ':' Indeed it could be. But, unfortunately, the colon seemed to be top of many people's most-wanted lists, with many different (and mutex) suggestions for what it should do. (Remember, only a couple of paragraphs ago you were wanting to keep it for the ? ... : operator!) Possibly somebody could design a language in which the colon is the only symbol used ... I don't really think using the column in a ternary means that you cannot use it else where. We started off with that, and it was changed specifically because it was causing a problem; I can't remember exactly what, but it's in this list's archives somewhere. Remember that whatever expression you want to use the colon for is going to be valid between the ? and : parts of the ? ... : operator, and so you need to avoid the colon being confused for the : which marks the end of this part of the ? ... : operator. Also remember that we want Perl 6 to be able to complain about syntax errors -- that is, we want that when somebody makes a typo, there's a good chance of perl complaining about the source being invalid, rather than it being valid Perl 6 (but which silently does something else). I can understand the idea. As for the functions, i didn't see that much for hashes and arrays which was a big disappointment. What were you hoping for? Many things which were functions in Perl 5 are now also available as methods in Perl 6. If you post here with what you're disappointed to be missing, it may be that somebody can reply pointing out where the equivalent functionality is! I am pretty much sure that I can rebuilt all the functions I will need for intersections and the like. But instead of reinventing the wheel or having to DL a module, it could be nice to have it as a built in. They are also other string related functions that are required when dealing with web but I guess this is not in the scope of perl anyway. Smylers -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.j
Re: perl 6 grammar
Larry Wall wrote: >On Mon, Dec 03, 2007 at 07:30:53PM +0900, cdumont wrote: > > >>Moritz Lenz wrote: >> >> >> >>>cdumont wrote: >>> >>> >>> 1- $str1 ~ $str2 >>>The '+' suggests numerical addition (and requires disambiguation in the >>>case of $str + $number - should $str be interpreted as a number, or >>>$number as a string?). >>> >>>The . is already taken by method calls (used far more often), and is >>>easy to overlook when concatenating strings. >>> >>> >>> >>Yeah, that's what I thought about the use of the dot for hashes and objects >>but hash or object : >> >>$obj.method(); >>or >>%hash.value(); >> >>which is visually different from : >> >>$str.$str2 >> >>as the concatenation keeps the sigil. >> >>I am not a huge fan of the + operator either but >>well, why add a third type when the dot could be just fine ? >> >> > >Because it wouldn't be just fine. Even in Perl 5 we have $obj->$method, >so if you're going to allow indirect methods and use . for method calls, >$a.$b has to be an indirect method call, not a concatenation. > > Oh! True! But ~... it's not has easy to type as '.' and not really visually nice (even if outstanding) >In general, one of the design principles of Perl 6 is that we never >overload operators to do very different things, because even if we can >think of a way to finesse it right now, it has a negative impact on >both extensibility and readability. It impacts extensibility because >you leave yourself no "wiggle room" in the grammar for future changes. >It impacts readability because you have to stop to consider the context >to decide which operation is going to happen. > >This is why Perl 5's x is now split into x and xx, for instance. Though >Perl 5 got some things right, by this principle. We never made the >mistake of confusing addition with concatenation. Not only is >concatenation not numeric, it's not even commutative! > > > >>2 ways are already more than one. >> >> > >If you're doing 3 very different things, then doing it 2 ways is >suboptimal. Things that are different should look different. > >Also, keeping operators in 1::1 correspondence with operations gives the >optimizer the most chance to figure things out at compile time without >having to know types at run time. (An oversimplicifcation, I know, >especially given how Perl 6 does multiple dispatch on operators at >run time.) > >Nevertheless, most of the overloading of operators historically has >been to avoid using up the ASCII sequences, and now that we allow >users to define Unicode operators, that artificial pressure has mostly >been removed. > >That being said, there's still contention for the short ASCII >sequences, and you shouldn't assume that any Perl 6 operator is >what it is for a single reason. Generally, most of these operators >have four or five reasons for being what they are, and some of those >reasons relate to what has already been taken by other more important >operators. Plus there is consistency with the rest of the language, >where ~ generally indicates some kind of string operation. > > > I guess there's a need to write some long programs in order to see. 2- $life = (!$monster) ?? 'safe' !! 'dead'; >>>is it true??? really??? then you're safe. if not (! is not), you're >>>dead. PWND. >>> >>>Again I think that a visually outstanding operator simplifies reading. >>>It's really easy to overlook a single ':', as it's used in p5. >>> >>> >>> >>> >>You are right, that is outstanding but again, so many languages use >>a standard ? : >> >> > >Languages copy all sorts of suboptimal features from other languages. >After all, that's how Perl 1 got ?: from C. That doesn't make it >right or wrong, merely convenient to learn. Learnability has always >been a secondary goal in Perl 5, compared to expressiveness, which is >a primary goal. > >When a language is first starting out, it *must* copy a lot of bad >constructs from other languages, or it will not easily be accepted (see >Icon for a sad example of this). With the wide acceptance of Perl 5, >we have the opportunity to use that as a cultural basis for change. >It remains to be seen whether we can succeed with that, but most of >the signs are positive. Most people only panic about once when making >the mental switch from Perl 5 to Perl 6. > >But if you want to panic once per operator, that's okay too. :) > > > Well I will rewrite all my little mvc framework in perl 6 with all the new oop features that should make my code cleaner. It is the best occasion to get dirty a little! But when you say that a language has to copy other languages at the beginning to get accepted, I really think it is true. On the other hand, even if perl 5 is widly accepted (unfortunately not that much in entreprise context due to CPAN phobia) and that perl 6 gains a lot from its ancestor, it is still a new language with a lot of new grammars If I were to start p
perl 6 and web open source projects
oh, it might not be relevant in many ways but : http://iamseb.com/seb/2007/12/perl-on-rails-why-the-bbc-fails-at-the-internet/ http://www.bbc.co.uk/blogs/radiolabs/2007/11/perl_on_rails.shtml There's one thing I would like perl6 to shine in, is web and open source. I know it's not the purpose of the language and that the above articles are placed in a particular context but I guess this can explain to some extends why both perl don't have a widespread use in entreprise and in open source project (I have looked for them but they are little and some of them like movable type moves to php at each upgrade) cdumont wrote: Patrick R. Michaud wrote: On Mon, Dec 03, 2007 at 12:20:02PM +, Smylers wrote: cdumont writes: I don't really think using the column in a ternary means that you cannot use it else where. We started off with that, and it was changed specifically because it was causing a problem; I can't remember exactly what, but it's in this list's archives somewhere. Remember that whatever expression you want to use the colon for is going to be valid between the ? and : parts of the ? ... : operator, and so you need to avoid the colon being confused for the : which marks the end of this part of the ? ... : operator. ...and it's not just the colon, but the ? also has the potential to be confusing here, because there's a prefix: operator that is used to coerce into boolean context. Which indirectly gets around to an even stronger reason for using C over C -- Perl 6 aims for a consistency in the use of the ? and ! characters to mean "boolean true" and "boolean not true". This is true not only for the operators, but also in regular expressions and other places. So, having something like $foo = $cond ?? ...if_true... !! ...if_not_true... ; achieves several important goals: - it frees up the ? and : characters for other purposes - it reinforces the convention of ? as "if true" and ! as "if false" - it is more visually distinctive, so that the ternary tokens don't get lost in the middle of other operands and expressions - it simplifies parsing (both compiler and human) and improves error reporting In my case, I've found the switch to ?? !! to be fairly natural, and that I don't use it often enough to worry about the extra characters. OK that explains the logic behind the conclusion. Thank you! I don't use it that much either but it was for the sake of coherence with other languages but Mr. Wall got the point in his response! -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.j
Re: perl 6 and web open source projects
In a message dated Tue, 4 Dec 2007, cdumont writes: oh, it might not be relevant in many ways but : http://iamseb.com/seb/2007/12/perl-on-rails-why-the-bbc-fails-at-the-internet/ http://www.bbc.co.uk/blogs/radiolabs/2007/11/perl_on_rails.shtml There's one thing I would like perl6 to shine in, is web and open source. I know it's not the purpose of the language and that the above articles are placed in a particular context but I guess this can explain to some extends why both perl don't have a widespread use in entreprise and in open source project (I have looked for them but they are little and some of them like movable type moves to php at each upgrade) May I divert from where this discussion would clearly go if your comment were directly responded to (into a massive flame-fest, that is) just to point out that this is not the purpose of the p6-l@ list? This list is to discuss the Perl 6 core language. The very notions of "enterprise" use and "open source" use and "web" use are so amorphous that it is hard to imagine core language features that would foster or discourage them. A language is an ecosystem, and it's hard to argue that Perl has done poorly in any of the three; the fact that other languages may currently have more forward momentum reflects, as much as anything else, that Perl reached saturation in these areas many years ago. If you want to make specific recommendations with regards to the language Perl 6, go ahead. But a free-for-all on Perl's successes and failures in particular arenas is not what this list is for. Trey
Re: perl 6 and web open source projects
Trey Harris wrote: In a message dated Tue, 4 Dec 2007, cdumont writes: oh, it might not be relevant in many ways but : http://iamseb.com/seb/2007/12/perl-on-rails-why-the-bbc-fails-at-the-internet/ http://www.bbc.co.uk/blogs/radiolabs/2007/11/perl_on_rails.shtml There's one thing I would like perl6 to shine in, is web and open source. I know it's not the purpose of the language and that the above articles are placed in a particular context but I guess this can explain to some extends why both perl don't have a widespread use in entreprise and in open source project (I have looked for them but they are little and some of them like movable type moves to php at each upgrade) May I divert from where this discussion would clearly go if your comment were directly responded to (into a massive flame-fest, that is) just to point out that this is not the purpose of the p6-l@ list? This list is to discuss the Perl 6 core language. The very notions of "enterprise" use and "open source" use and "web" use are so amorphous that it is hard to imagine core language features that would foster or discourage them. A language is an ecosystem, and it's hard to argue that Perl has done poorly in any of the three; the fact that other languages may currently have more forward momentum reflects, as much as anything else, that Perl reached saturation in these areas many years ago. If you want to make specific recommendations with regards to the language Perl 6, go ahead. But a free-for-all on Perl's successes and failures in particular arenas is not what this list is for. Trey Sorry. Where can I find a mailing list that is about Perl 6 in general then? Thank you. -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.j
Re: perl 6 and web open source projects
At 2:51 PM +0900 12/4/07, cdumont wrote: Sorry. Where can I find a mailing list that is about Perl 6 in general then? Thank you. I would recommend that [EMAIL PROTECTED] is the best place to talk about these things, out of the official Perl 6 lists that I know of. -- Darren Duncan
Re: perl 6 and web open source projects
Darren Duncan wrote: At 2:51 PM +0900 12/4/07, cdumont wrote: Sorry. Where can I find a mailing list that is about Perl 6 in general then? Thank you. I would recommend that [EMAIL PROTECTED] is the best place to talk about these things, out of the official Perl 6 lists that I know of. -- Darren Duncan Thank you (^^;) Just ignore my messages about this topic, all. I will copy and paste it for this mailing list. -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.j
Re: perl 6 and web open source projects
Trey Harris wrote: The very notions of "enterprise" use and "open source" use and "web" use are so amorphous that it is hard to imagine core language features that would foster or discourage them. A language is an ecosystem, and it's hard to argue that Perl has done poorly in any of the three; the fact that other languages may currently have more forward momentum reflects, as much as anything else, that Perl reached saturation in these areas many years ago. As for that point : in these areas many years ago. If other languages are now favoured for web development over Perl5 that is supposed to have reached saturation years ago, it means that it wasn't the optimum or even closed to be it. While perl6 is being implemented it is perhaps a good idea to evoluate perl 6 in regards to perl 5 at the language level but also cultural and environment level. I wanted to point out that offering an ecosystem, water, was perhaps good enough when perl went thru. But now, roads, high-way and plane are very common things in new languages. They do implement more than just a basic ecosystem. This offers coherence, standard and assurance that programm A will run in context Y and Z without having to rebuilt the road. For what I have seen, many people in this mailing list thinks that the ecosystem is good enough. But as somebody says in this mailing list, when you go buy a car you want everything in it. Not going in a, b,c ,d shops to get it to work. That's why open source projects favor php or ruby because the assurance the program will run in context is higher than in perl and it seems like it will in perl 6. So perhaps this shouldn't have to be discussed in a 'language' mailing list but I guess a language is built upon a certain context whether you want to hear about it or not. But don't get me wrong! I don't want to blame anything at all! I wanted to point out that CPAN was the sucess of perl. But C6PAN might be it failure. Like an other person said, having a web module, that will be part of the core documentation without even having to be in the core of perl 6 would be a very good solution. This will offer standard, assurance and allow wide spread use of perl 6 over predominant actual languages. In order to do so, the language has to take into account what are the most common actual needs and reflect them to some extends. French used to have many verbs and tricky grammar rules. It tends to disappear and in the same time English words, computer words are just getting in our everyday life more and more. Perhaps we won't be using them in 2 years but and so what? If we need them now. Don't you think this has to do with perl 6 language? now,now,now,it's all about now. as said Jeff Buckley... But this might not be the place and I will stop here. Thank you anyway for your kind reply. -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.j
Re: [perl #47011] [DEPRECATED] VTABLE entry 'new_from_string'
Will Coleda via RT wrote: On Mon Oct 29 11:11:03 2007, bernhard wrote: In pdd17_pmc.pod it is stated that 'new_from_string' is deprecated. The existing use of 'new_from_string' can probably be achieved with 'init' or 'set_string_native'. TODO: Hunt down existing use of 'new_i_s' and either replace or remove the functionality. The FixedIntegerArray is an example of where 'new_from_string' is used. Given the usage in compilers/imcc/pbc.c: _class = interp->vtables[r->pmc_type]->pmc_class; p = VTABLE_new_from_string(interp, _class, s, PObj_constant_FLAG); Is there a standard for passing the flags? In the old scheme, we had a specific argument to pass in the flags... There are a lot of cases where we pass in flags here; Do we now have to create a Hash PMC in each case? If it's a Hash, then we have to setup a convention to pass the flags... but doing this just as a convention seems to be ripe for mistakes; Clues welcome on how to proceed. 'new_from_string' is widely used by .const, for example : .const .String key_print = "print" or .const .Sub _create = 'create' What becomes this kind of constructor ? Francois.
