Hi,
As noted this week on #ps, some of the goals we have for 3.0 require
that some existing functionality be deprecated before they can be
complete. The 2.9 supported release next month is the last chance to
get these deprecations in time to allow our 3.0 goals to be met, so we
need to start think
On Fri, Sep 17, 2010 at 09:10:24AM +1000, Vasily Chekalkin wrote:
> Sorry guys. I already merged it few hours ago... I can revert it if it
> will cause Rakudo's breakage. But I prefer just fix it in trunk. We
> have 5 days more for it.
I couldn't find the 'string_gc_encapsulate' branch in the comm
On Fri, Sep 17, 2010 at 9:00 AM, Andrew Whitworth wrote:
> If we have to wait a few days to merge this, that won't be a huge
> problem. We can merge it into gc_massacre instead and continue the
> work of that branch.
Sorry guys. I already merged it few hours ago... I can revert it if it
will caus
At 9/16/2010 05:32 PM, Andrew Whitworth wrote:
>I'm not against creating ops like this, but I would suggest instead
>creating them as dynops. In fact, I would be happy to see all the trig
>and hyperbolic trig ops moved to dynops, if they aren't already.
The existing operations are dynops. We would
At 9/16/2010 06:40 PM, James E Keenan wrote:
>>Should we provide any of these? If so, what about the ones that are complex
>>over some range of arguments?
>
>
>This issue has come up before, see, e.g.,
>http://trac.parrot.org/parrot/ticket/943.
>
>I think Allison's recommendation was: dynops.
I
I submitted about 8 smoke tests this afternoon (Ubuntu 10.04 x86 with
gcc, g++, icc, and clang, all with and without --optimize). All smoke
tests passed. I'm starting a similar battery tonight on x86_64, and
maybe see what I can do on OpenSolaris. I would love to see some smoke
reports on this bran
Paul C. Anagnostopoulos wrote:
Folks,
We have a full compliment of trig, inverse trig, and hyperbolic operations,
except for:
acot
coth
acsc
csch
We are also missing the inverse hyperbolic operations:
asinh
acosh
atanh
acoth
asech
acsch
Should we provide any of these? If so, what about the
Vasily Chekalkin wrote:
Hello.
string_gc_encapsulate branch is ready for merging back to trunk. Main
purpose is to bring all STRING allocating/compacting together and
decouple from other sides of GC.
If no one will complain about it I'll merge it in about couple of days
(+-1 day).
Please do
I'm not against creating ops like this, but I would suggest instead
creating them as dynops. In fact, I would be happy to see all the trig
and hyperbolic trig ops moved to dynops, if they aren't already.
--Andrew Whitworth
On Thu, Sep 16, 2010 at 5:12 PM, Peter Lobsinger wrote:
> -1 to adding
-1 to adding such features to core without any prior demand from users
(none that I've heard anyways).
On Thu, Sep 16, 2010 at 1:35 PM, Paul C. Anagnostopoulos
wrote:
> Folks,
>
> We have a full compliment of trig, inverse trig, and hyperbolic operations,
> except for:
>
> acot
> coth
> acsc
> cs
Howdy,
I am +1 to throwing an exception when doing something funky to NaN/Inf.
Duke
On Thu, Sep 16, 2010 at 10:38 AM, Paul C. Anagnostopoulos wrote:
> At 9/16/2010 01:15 PM, Andrew Whitworth wrote:
>
> I personally don't like the idea of ever leaving anything undefined.
> The C language is a
At 9/16/2010 01:38 PM, Paul C. Anagnostopoulos wrote:
>At 9/16/2010 01:15 PM, Andrew Whitworth wrote:
>>I personally don't like the idea of ever leaving anything undefined.
>>The C language is at a disadvantage because it was created so many
>>years ago and because it's designed to run on so many d
At 9/16/2010 01:15 PM, Andrew Whitworth wrote:
>I personally don't like the idea of ever leaving anything undefined.
>The C language is at a disadvantage because it was created so many
>years ago and because it's designed to run on so many different
>platforms.
>
>Parrot doesn't really have either
Folks,
We have a full compliment of trig, inverse trig, and hyperbolic operations,
except for:
acot
coth
acsc
csch
We are also missing the inverse hyperbolic operations:
asinh
acosh
atanh
acoth
asech
acsch
Should we provide any of these? If so, what about the ones that are complex
over some
Folks,
Regarding this ticket: http://trac.parrot.org/parrot/ticket/370
The problem is not with rounding Inf or NaN. Instead, the problem concerns
converting Inf/NaN to an integer. The C reference states:
"The behavior of the conversion [from floating-point to integer] is undefined
if the floa
Heya,
A summary email would probably be good. I've imported the feed into
Google Reader, but I can see that being overwhelming when there's a
significant number of Smolder tests.
Kind Regards,
Brian Wisti
http://coolnamehere.com
On Wed, Sep 15, 2010 at 4:09 PM, Jonathan Leto wrote:
> Howdy,
>
On Thursday 16 September 2010 at 02:32, Jonathan Leto wrote:
> Looks like we have had a decent slow-down in stress_strings.pir since 2.7.0
Is it possible to track this down to a revision (or revision range) in the
past three days?
-- c
___
http://list
On Thursday 16 September 2010 at 01:22, tcurtis wrote:
> Log:
> Use Parrot_str_to_cstring instead of strstart when passing prompt to
> functions that expect C strings in FileHandle.readline_interactive.
> --- trunk/src/pmc/filehandle.pmc Thu Sep 16 08:18:24 2010(r49036)
> +++ trun
On Fri, Sep 17, 2010 at 12:13 AM, Andrew Whitworth
wrote:
> Vasily,
>
> I haven't looked at it yet, but how disruptive or dangerous is this
> branch? We're 5 days away from the release. I suggest the branch
> either go in soon (as soon as possible, pending testing) or wait until
> after the releas
Vasily,
I haven't looked at it yet, but how disruptive or dangerous is this
branch? We're 5 days away from the release. I suggest the branch
either go in soon (as soon as possible, pending testing) or wait until
after the release.
Is it just a rearrangement of existing code, or is it a bigger cha
Hello.
string_gc_encapsulate branch is ready for merging back to trunk. Main
purpose is to bring all STRING allocating/compacting together and
decouple from other sides of GC.
If no one will complain about it I'll merge it in about couple of days
(+-1 day).
--
Bacek.
___
That's an extremely good point, Peter. I do not think that Buffers are
user-visible and require a deprecation period.
--Andrew Whitworth
On Thu, Sep 16, 2010 at 3:29 AM, Peter Lobsinger wrote:
> -- Forwarded message --
> From: Peter Lobsinger
> Date: Thu, Sep 16, 2010 at 3:29
In five days is the release day of Parrot 2.8.0. The checkout and tag
for it will be at 2010-09-21 08:00 UTC. To convert UTC to your local
time execute:
$ date -d '2010-09-21 08:00 UTC'
So on Saturday is the time to stop committing non-release related code
to the trunk. For that I will send a se
Howdy,
I saw chromatic++ lament that I haven't done benchmarks recently, so I got
back on my horse.
I am only benchmarking from 2.0.0 forward, for now. Let me know if you want
to go further back.
Looks like trunk is just slightly slower on oofib.pir than 2.0.0, which was
the fastest :
$ ./bin/b
Am 16.09.2010 09:49, schrieb Jonathan Leto:
Compare two integer revisions to see if one is greater than the other.
This cannot be done in git.
It *is* possible to tell which of 2 git commits happened later,
chronologically, but that requires the git repo.
mor...@trudi:~/rakudo>git describe
Howdy,
Can we get a test for this?
Duke
On Wed, Sep 15, 2010 at 10:53 AM, wrote:
> Author: luben
> Date: Wed Sep 15 17:53:37 2010
> New Revision: 49022
> URL: https://trac.parrot.org/parrot/changeset/49022
>
> Log:
> fix bug in logical not on PMCs when dest == src
>
> Introduced in logical vt
Hello,
at the URL http://www.parrot.org/scratch/smolder-logo is a nice smolder
logo that I like. May be this can be added.
-- Gerd
Am Mittwoch, den 15.09.2010, 21:02 +0200 schrieb Jonathan Leto:
> Howdy,
>
> http://smolder.parrot.org/app/projects/smoke_reports/1
>
> Update to r49023 and type "
Howdy,
I am down to our last two build tools in the migration to git. They are
basically the same script:
mk_language_shell.pl creates a language that uses a Configure.pl and
Makefile, while create_language.pl makes a setup.pir .
They both have one operation that is totally dependent on Subvers
-- Forwarded message --
From: Peter Lobsinger
Date: Thu, Sep 16, 2010 at 3:29 AM
Subject: Re: Deprecate Buffers.
To: Vasily Chekalkin
Why do they even need deprecation? Are they user visible somehow?
On Wed, Sep 15, 2010 at 5:12 AM, Vasily Chekalkin wrote:
> Hello.
>
> Current
29 matches
Mail list logo
