# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #66252]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=66252 >
rakudo: my $x = "test"; given $x { say $_; m/(e.)/; say $/ }
rakudo c907d3: OUTPUT«
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #66272]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=66272 >
rakudo: sub infix:(*...@a) is assoc('list') { [*] @a
}; say 7 !+ 6 !+ 10
rakudo 77db80
Hi,
I think featurewise Rakudo is now at a point where it could already be
use for some serious work. Surely many things are missing, but (for me)
the two most important things - good OOP support and types - are already
in. And the syntax is just lovely :) (I think I have a syntax-fetish... :)
# New Ticket Created by Chris Fields
# Please include the string: [perl #66280]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=66280 >
This is a nasty one. Using a Range with a lexical in an inner for
block with nested p
Fagyal Csongor wrote:
I very much agree with Patrick: an order-of-magnitude speed difference
compared to Perl5 is kind of the point where many will just stop caring
about performance and start using Rakudo/Perl6. Actually I expect a
significant increase in the number of new Perl6ers at around <
On Wed, Jun 3, 2009 at 6:12 PM, Chris Mair wrote:
> Now, my problem is that perl6 code runs very slooow :(
>
> I understand this is all an early phase of development,
> but this is like 2 or 3 orders of magnitude slower than perl5 :(
>
> So, my question: is there something fundamentally
> fla
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #66270]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=66270 >
rakudo: my $match = Perl6::Grammar.parse("say ",
:action(Perl6::Grammar::Actions.new))
If you want to write a fast parser for XML, preventing backtracking is
going to be quite essential. I suspect the problem is your grammar,
not the grammar engine itself. You could post it to perl6-users and
ask for advice on it.
Leon
On Thu, Jun 4, 2009 at 7:25 AM, Richard Hainsworth wrote:
> Is
Pm (>):
> I don't know if this is more along the lines of what you were looking
> for. If so, close the ticket, if not, tell us what you expect. :-)
Well, I have no idea what to expect either, but issue I submitted the
ticket for has been fixed, and this .HOW.say things seems to be a very
differ
# New Ticket Created by Håkon Skaarud Karlsen
# Please include the string: [perl #66250]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=66250 >
This works:
grammar A { rule TOP { 'a ' 'b' {*} } }; my $m = A.parse('a b');
Hi,
Following my last reasoning on implicit threading and implicit
event-based programming[1], I came to two interesting realizations...
1 - Every object is potentially lazy, not only lists.
2 - Lazy doesn't mean "wait until I need the data", but "don't stall me
because of that data".
That bas
Hi,
thanks for the replies!
I have a better understanding of these performance issues now.
(sidenote: replacing $i++ with $i = $i + 1 in my original example
gives a 4 times speed up).
Hi Chris,
In addition to Patrick's excellent reply, I'd like to mention that
one way to help the project
On Wed Jun 03 06:08:46 2009, haakonsk wrote:
> This doesn't work:
> grammar A { rule TOP { 'a' ' b' {*} } }; my $m = A.parse('a b'); say $/;
> Result: Empty string
> Expected result: "a b"
Rakudo is correct here.
Whitespace in rules is metasyntactic -- it gets replaced by <.ws>.
So, the above r
Chris Mair wrote:
... I'm porting the benchmarks from the Debian language shootout
to Perl 6... why don't you help me? ...
Yes, why not?
I was planning to exercise a little bit, anyhow.
google gave me this:
http://daniel.carrera.bz/_2009/perl/shootout-perl6-2009.05.27.tgz
Do you keep an over
On Wed, Jun 3, 2009 at 9:01 PM, Daniel Carrera
wrote:
> Hi Chris,
>
> In addition to Patrick's excellent reply, I'd like to mention that one way
> to help the project is to just write code in Perl 6. This is a good way to
> find bugs, including performance bugs.
I have just sent off an email to P
Joshua Gatcomb wrote:
I know these benchmarks have their value, but I am more interested in
real practical code that I have previously written to solve a problem.
I know that the Rakudo code will be slower than the perl 5.
The point of the benchmark is not "oh look, it's slower than Perl 5".
T
On Thu, Jun 4, 2009 at 11:16 AM, Daniel Carrera
wrote:
>
> The point of the benchmark is not "oh look, it's slower than Perl 5". The
> benchmarks are good for testing a specific aspect of the language, so it is
> easier to isolate *where* the problem is. This is harder on a real
> application.
I
Now fixed in 9e2b9ad:
$ cat 66280
for 1,3 -> $i {
for $i..4 -> $j { say "$j,$i" };
$i.say;
}
$ ./perl6 66280
1,1
2,1
3,1
4,1
1
3,3
4,3
3
$
Test added to range.t. Closing ticket, thanks!
Pm
Joshua Gatcomb wrote:
I think you are confusing profiling with benchmarking. Profiling
helps you identify where a problem is. Benchmarking helps you compare
two different versions of the same routine.
Whatever. I have a series of programs that test the speed of various
aspects of the languag
HaloO,
Daniel Ruoso wrote:
So the questions are:
* Are there any imperative barriers in Perl 6?
I would think that at least every method call is a barrier.
An object's lifetime is a sequence of states and methods are either
returning information about the state or calculate a new state. The
On Thu, Jun 4, 2009 at 9:57 AM, TSa wrote:
> HaloO,
>
> Daniel Ruoso wrote:
>>
>> So the questions are:
>>
>> * Are there any imperative barriers in Perl 6?
>
> I would think that at least every method call is a barrier.
> An object's lifetime is a sequence of states and methods are either
> retu
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20090610T00Z
DTEND:20090610T03Z
DTSTAMP:20090605T035153Z
ORGANIZER;CN=jason switzer:mailto:jswit...@gmail.com
UID:g3rsts66avsaacp817n7ri1...@google.com
ATTEND
22 matches
Mail list logo
