Re: Struggles with Trig

[Solomon Foster]

On Sun, Sep 6, 2009 at 3:08 PM, Moritz Lenz wrote:
> (This is a reply to "Struggles with Trig",
>  - I also write to
> perl6-compiler because parts of it might be of a bit broader interested,
> or others might want to comment on it too).
>
>> 1) Passing non-default $base value does not work for Num.sin / Num.cos
>> or Complex.sin / Complex.cos. As far as I can tell the code is fine,
>> and Num.sin("degrees") seems to work fine using p6eval, but the tests
>> fail for me in trig.t. I thought it was some weird interaction with
>> the fact sin is declared as an operator, but Rat.sin("degrees") works
>> just fine in the tests. I'm stumped on this, if anyone else can offer
>> some insight I'm all ears.
>
> Currently all the tests which are not fudged in trig.t pass here (amd64
> linux), if that's not the case for you, maybe you have some local
> modifications?

Apologies if I was not clear about this.  I have only checked in files
in a state where everything tests cleanly.  The problems I am
complaining about are exactly the ones that are fudged.  As far as I
know the code is implemented for every one of the sine tests, but the
weird problems I'm talking about forces all those skips.

>> 2) Equally weirdly, I've got working implementations of sin(Complex)
>> and sin(Complex, $base). But they only work if defined trig.t, moving
>> them to Complex.pm made those tests fail. Do they need "is export"
>> added or something like that? What is "is export" for, anyway?
>
> "is export" makes a method also a sub.
>
> So if you write
>
> # in Rakudo actually 'class Complex is also'
> augment class Complex {
>    multi method sin($base = 'degree') {
>
>    }
> }
>
> you only get the method form, (1+1i).sin(). If you write it as
>
> multi method sin(...) is export { ... }
>
> instead, you get the method form plus the sub form, ie a
>
> mutli sin(Complex $self, $base = 'degree') { ... }
>
> That said, I also had some troubles with multi dispatch related to
> Complex numbers when I tried to move stuff to the setting.
>
> It would be helpful if you could send a patch that adds these methods to
> the setting, so we can take a look at this together.

Let me know how you'd like this.  As I said, the functions are already
present in trig.t, so it would be easy enough to move them for you.

>> 3) In general, I'd love it if a few people could look over the new
>> tests for sine (cosine duplicates them). I'm not 100% comfortable with
>> how repetitive they are.
>
> I know that feeling, but I stopped bothering about it some time ago.
> Testing the basics just requires lots of repetition. Especially
> numerical stuff.
>
> Data driven testing promises an escape route, but it's rather hard to
> fudge it properly, and thus an option I try to avoid.

Actually data driven testing seems to work pretty well for the trig
functions.  Mostly if they work, they work for the entire data set, it
seems.

>> You could obviously change my little
>> AngleAndResult to have a method which allows you to select the base
>> and the numeric type to return, but I don't know how to make that
>> cleanly work with the very much needed SKIP directives.
>
> If you write the testing stuff as subs instead, it's much easier.
>
> Suppose you want to write a sub that executes three tests each time it's
> run:
>
> #?DOES 3
> sub that_executes_tests(...) {
>
> }
>
> #?rakudo skip 'NYI'
> that_executes_tests(...)
>
>
> (I hope that answers your question - if not, feel free to ask again).

Hmmm... it doesn't exactly answer my question, but it certainly
provides grounds for thought!

>> (BTW, these
>> changes I've made add over 1000 tests in trig.t, and they are only the
>> tip of the iceberg.)
>
> Since the visible tip of the iceberg is usually about 1/9 th of the
> volume, I'm looking forward to another 8k tests ;-)

Seriously, I wouldn't be surprised if it ends up being something like that.

> I don't worry if that skews any spectest statistics as long as it means
> that Perl 6 gets lots of good tests for the trigonometric functions.
>
> All in all I like these tests, but they need to get switched to the new
>  way of passing units (ie an enum instead of strings).

I will see what I can do about that.  But notice that the new tests
only take four lines changed to get that working.  (The old tests, on
the other hand, will need a massive search and replace...)

Thanks,

-- 
Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com

[perl #65942] Missing %*ENV values are defined, but don't exist

[Carl Mäsak via RT]

This works now:

$ perl6 -e 'say %*ENV.exists()'
0
$ perl6 -e 'say defined %*ENV'
0

Resolving.

[perl #69052] Build error on Mac OS X

[via RT]

# New Ticket Created by  Alexander Temerev 
# Please include the string:  [perl #69052]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=69052 >


I tried to build today's Git version on Mac OS X Snow Leopard, and
here is what I got:

mbp:rakudo atemerev$ perl Configure.pl --gen-parrot
<...>
src/packout.c
src/pic_jit.c
src/pic.c
src/platform.c
config/gen/platform/generic/hires_timer.c: In function ‘Parrot_hires_get_time’:
config/gen/platform/generic/hires_timer.c:41: warning: implicit
declaration of function ‘clock_gettime’
config/gen/platform/generic/hires_timer.c:41: warning: nested extern
declaration of ‘clock_gettime’
config/gen/platform/generic/hires_timer.c:41: error: ‘CLOCK_PROF’
undeclared (first use in this function)
config/gen/platform/generic/hires_timer.c:41: error: (Each undeclared
identifier is reported only once
config/gen/platform/generic/hires_timer.c:41: error: for each function
it appears in.)
make: *** [src/platform.o] Error 1

Reading configuration information from parrot_config ...
===SORRY!===
Parrot revision r41083 required (currently r0)

To automatically checkout (svn) and build a copy of parrot r41083,
try re-running Configure.pl with the '--gen-parrot' option.
Or, use the '--parrot-config' option to explicitly specify
the location of parrot_config to be used to build Rakudo Perl.

===

mbp:rakudo atemerev$ perl -V
Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
  Platform:
osname=darwin, osvers=10.0, archname=darwin-thread-multi-2level
uname='darwin neige.apple.com 10.0 darwin kernel version 10.0.0d8:
tue may 5 19:29:59 pdt 2009; root:xnu-1437.2~2release_i386 i386 '
config_args='-ds -e -Dprefix=/usr -Dccflags=-g  -pipe  -Dldflags=
-Dman3ext=3pm -Duseithreads -Duseshrplib -Dinc_version_list=none
-Dcc=gcc-4.2'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
  Compiler:
cc='gcc-4.2', ccflags ='-arch x86_64 -arch i386 -arch ppc -g -pipe
-fno-common -DPERL_DARWIN -fno-strict-aliasing -I/usr/local/include',
optimize='-Os',
cppflags='-g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing
-I/usr/local/include'
ccversion='', gccversion='4.2.1 (Apple Inc. build 5646)', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
  Linker and Libraries:
ld='gcc-4.2 -mmacosx-version-min=10.6', ldflags ='-arch x86_64
-arch i386 -arch ppc -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib
libs=-ldbm -ldl -lm -lutil -lc
perllibs=-ldl -lm -lutil -lc
libc=/usr/lib/libc.dylib, so=dylib, useshrplib=true, libperl=libperl.dylib
gnulibc_version=''
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-arch x86_64 -arch i386 -arch ppc
-bundle -undefined dynamic_lookup -L/usr/local/lib'


Characteristics of this binary (from libperl):
  Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_64_BIT_ALL
USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES
USE_PERLIO USE_REENTRANT_API
  Locally applied patches:
/Library/Perl/Updates/ comes before system perl directories
installprivlib and installarchlib points to the Updates directory
  Built under darwin
  Compiled at Jun 24 2009 00:35:27
  @INC:
/Library/Perl/Updates/5.10.0
/System/Library/Perl/5.10.0/darwin-thread-multi-2level
/System/Library/Perl/5.10.0
/Library/Perl/5.10.0/darwin-thread-multi-2level
/Library/Perl/5.10.0
/Network/Library/Perl/5.10.0/darwin-thread-multi-2level
/Network/Library/Perl/5.10.0
/Network/Library/Perl
/System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level
/System/Library/Perl/Extras/5.10.0
.
mbp:rakudo atemerev$


  Cheers,
  Alexander Temerev

Re: S26 - The Next Generation

[Damian Conway]

Jon Lang elaborated:

> I don't think that there will be a problem.  First, #=> is easy enough
> to distinguish from #=; I don't foresee any confusion.

I'm not so sure. #=> is a lot more like #= that =alias is. And the one
character of difference is on the non-significant (right-hand) side.
Need to think about it and role-play it a little.


> With the ability to attach multiple declarator blocks to a single
> declarator, it should be trivial to replace any one of them with a
> declarator alias:
>
>    #=>
>    class Foo {
>        #= Class Foo
>        #= a sample class used to illustrate.
>        #= This particular class has nothing in it.
>    }

See that's precisely my problem. I don't think the #=> stands out at all
there as being an alias.


>    #= Class A
>    class Foo {
>        #= a sample class used to illustrate.
>        #= This particular class has nothing in it.
>        #=> X

And this illustrates my other qualm, that the two forms are just too similar.

And, yes, having the aliasing mechanism be something postfix(able) creates
issues of when the aliases come into existence.


> I tend to agree.  I only proposed numbering as a way of being able to
> access different declarators without having to explicitly label them.
> I can definitely understand if this option gets dropped as being too
> error-prone with regard to maintenance.

That's my plan.


>>    =alias
>>    class Database::Handle {
>>        =alias
>>        has IO $!handle;
>>
>>        =alias open
>>        my Bool method open ($filename) {...}
>>
>>        =alias close
>>        my Bool method close() {...}
>>
>>        =for para
>>            Note that the A method of class A
>>            stores the resulting low-level database handle
>>            in its private A attribute, while the A
>>            method closes that handle.
>>    }
>
> The problem with this example is that '=alias name' isn't a declarator
> alias; it's a block alias.

I'm proposing to change that and allow explicit names on declarator
aliases as well.
Or, rather, to unify the two into a "block-or-declarator" alias.

>        my Bool method open ($filename) {...} #=>[m1] #= Here's a
> block for A.
>        my Bool method close () {...}         #=>m2
>
> And given that brief names are going to be preferred, this could
> result in very compact, yet still readable, combinations of declarator
> aliases and blocks.

Yes, this is a definite advantage of the proposal. No question.
But I'm still concerned that the two syntaxes are just so similar.
I'll continue pondering the trade-off.

Damian

Re: S26 - The Next Generation

[Damian Conway]

Jon Lang huh'd:

> Huh.  Would you be able to do something like:
>
>    =begin pod
>    Welcome to $?FILE.
>
> ...and have it interpolate the file's name?  Or would you need some
> special markup for this, such as:
>
>    =begin pod
>    Welcome to A<$?FILE>.

The latter. Variables are just too common in documentation to
have (some of) them interpolate automagically.

> Or would you have to alias the variable and then refer to it?

No. I envisage that A<> would recognize an alias starting with a sigil,
and "auto-alias" it for you.

Damian

r28208 - docs/Perl6/Spec/S32-setting-library

[pugs-commits]

Author: ruoso
Date: 2009-09-09 04:26:50 +0200 (Wed, 09 Sep 2009)
New Revision: 28208

Modified:
   docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
[spec-S32-Temporal] Complete rewrite of Temporal.pod taking into account today 
IRC talks, TAI time, alternative calendars, time-zone information and, most 
importantly, the perl 5 DateTime API

Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod
===
--- docs/Perl6/Spec/S32-setting-library/Temporal.pod2009-09-08 16:22:13 UTC 
(rev 28207)
+++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2009-09-09 02:26:50 UTC 
(rev 28208)
@@ -21,8 +21,8 @@
 =head1 VERSION
 
 Created: 19 Mar 2009 extracted from S29-functions.pod and S16-IO.pod
-Last Modified: 23 Feb 2009
-Version: 3
+Last Modified: 8 Sep 2009
+Version: 4
 
 The document is a draft.
 
@@ -30,169 +30,216 @@
 repository under /docs/Perl6/Spec/S32-setting-library/Temporal.pod so edit it 
there in
 the SVN repository if you would like to make changes.
 
-=head2 Time
+=head1 Current Time
 
+The epoch used in Perl 6 to represent time instants is the
+International Atomic Time - TAI - which is independent of calendars,
+timezones as well as leap seconds. Of course Perl can't go beyond the
+machine to get a real TAI value, but it should perform any
+platform-specific transformation to give you the most precise value it
+can for the TAI.
+
+ our Rat sub time()
+
+Returns a TAI epoch value for the current time.
+
+=head1 Roles
+
+=head2 Calendar
+
+Every DateTime needs to follow the rules of a given calendar. The
+default is the Gregorian calendar, but several other calendars exist
+in the real world.
+
+The current default calendar is stored in $*CALENDAR.
+
 =over
 
-=item gmtime
+=item method calendartime($epoch = time(), *%options)
+=item multi calendartime($epoch = time(), $calendar = $*CALENDAR, *%options)
 
- our Temporal::DateTime multi gmtime ( Num $epoch )
- our Temporal::DateTime multi gmtime ( Rat $epoch = time() )
+Returns a DateTime object in the current calendar for the given TAI
+epoch time. Each calendar type might accept different options.
 
-Identical to:
+Note that simply changing the current calendar is not magically going
+to make any code portable to different calendars. The code using it
+should either use only the methods in the generic Calendar and
+DateTime roles, or special case for the known Calendars.
 
- Time::localtime(:$time,:tz)
+=item method formatter is rw
 
-=item localtime
+The default formatter object used for DateTime objects in this
+calendar.
 
- our Temporal::DateTime multi localtime ( Num $epoch )
- our Temporal::DateTime multi localtime ( Rat $epoch = time() )
+=back
 
-These functions take an epoch value and return a C
-object. For C the time zone is taken from the local
-system. For C the time zone is aways UTC.
+=head2 Calendar::TimeZoneObservant
 
-If no time is provided, the current time is used.
+This is a generic role used to identify all calendars that observe the
+time zones. Not all calendars are time-zone observants. One way or
+another, two multi subs will be available that depend on a time-zone
+observant calendar. They will fail if you try to call them with a
+non-tz calendar.
 
-=item time
+This role also implies that the calendartime method might receive a
+time-zone named parameter.
 
- our Rat time()
+=over
 
-Returns an epoch value for the current time.
+=item method gmtime($epoch = time(), *%options )
+=item multi gmtime($epoch = time(), $calendar = $*CALENDAR, *%options)
 
+Returns a DateTime object in the GMT timezone, considering $epoch to
+be TAI. Same as:
+
+ calendartime($epoch, $calendar, :time-zone('GMT'))
+
+=item method localtime($epoch = time(), *%options )
+=item multi localtime($epoch = time(), $calendar = $*CALENDAR, *%options)
+
+Returns a DateTime object in the local timezone taken from the system,
+considering $epoch to be TAI. Same as:
+
+ calendartime($epoch, $calendar, :time-zone('local'))
+
 =back
 
-=head1 Roles
+=head2 DateTime
 
-The intent behind these classes is to provide an absolutely minimal,
-but still useful, set of core behavior. The assumption is that the
-core will ship with a simple set of classes so that C and
-C have something to return.
+The generic DateTime role specifies the basic operations that should
+be possible independent of the Calendar being used, and are,
+therefore, considerably restricted.
 
-=head2 Temporal::Date
+In order to make it easier to deal with the most common scenario, the
+contructor of the bare DateTime type will delegate to
+Gregorian::DateTime.
 
-You probably want to use the Temporal::DateTime object instead.
+It defines the following attributes.
 
-role Temporal::Date {
-my subset Month of Int where { 1 <= $^a <= 12 };
-my subset Day of Int where { 1 <= $^a <= 31 };
-my subset DayOfWeek of Int where { 1 <= $^a <= 7 };
+=over
 
-has Int   $.year;
- 

r28209 - docs/Perl6/Spec/S32-setting-library

[pugs-commits]

Author: ruoso
Date: 2009-09-09 04:32:41 +0200 (Wed, 09 Sep 2009)
New Revision: 28209

Modified:
   docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
[spec-S32-Temporal] minor pod fixes

Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod
===
--- docs/Perl6/Spec/S32-setting-library/Temporal.pod2009-09-09 02:26:50 UTC 
(rev 28208)
+++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2009-09-09 02:32:41 UTC 
(rev 28209)
@@ -56,6 +56,7 @@
 =over
 
 =item method calendartime($epoch = time(), *%options)
+
 =item multi calendartime($epoch = time(), $calendar = $*CALENDAR, *%options)
 
 Returns a DateTime object in the current calendar for the given TAI
@@ -87,6 +88,7 @@
 =over
 
 =item method gmtime($epoch = time(), *%options )
+
 =item multi gmtime($epoch = time(), $calendar = $*CALENDAR, *%options)
 
 Returns a DateTime object in the GMT timezone, considering $epoch to
@@ -95,6 +97,7 @@
  calendartime($epoch, $calendar, :time-zone('GMT'))
 
 =item method localtime($epoch = time(), *%options )
+
 =item multi localtime($epoch = time(), $calendar = $*CALENDAR, *%options)
 
 Returns a DateTime object in the local timezone taken from the system,
@@ -150,6 +153,8 @@
 
 The following method is implemented by all Duration objects.
 
+=over
+
 =item tai
 
 Returns the amount of TAI seconds described in this duration. Note
@@ -158,6 +163,8 @@
 be an estimated value for Duration types that depend on an anchor date
 (i.e.: 1 month).
 
+=back
+
 =head2 TimeZone
 
 This is the base for the entire time-zone database with the complete
@@ -174,7 +181,9 @@
 =over
 
 =item Start and end DateTime
+
 =item Start DateTime and Duration
+
 =item Duration and end DateTime
 
 =back

r28210 - docs/Perl6/Spec/S32-setting-library

[pugs-commits]

Author: ruoso
Date: 2009-09-09 04:41:31 +0200 (Wed, 09 Sep 2009)
New Revision: 28210

Modified:
   docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
[spec-S32-Temporal] Gregorian::Duration doesnt have a time-zone.

Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod
===
--- docs/Perl6/Spec/S32-setting-library/Temporal.pod2009-09-09 02:32:41 UTC 
(rev 28209)
+++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2009-09-09 02:41:31 UTC 
(rev 28210)
@@ -244,8 +244,6 @@
 
 =item nanosecond
 
-=item time-zone
-
 =back
 
 

Re: r28208 - docs/Perl6/Spec/S32-setting-library

[Darren Duncan]

pugs-comm...@feather.perl6.nl wrote:

-=head2 Time
+=head1 Current Time
 
+The epoch used in Perl 6 to represent time instants is the

+International Atomic Time - TAI - which is independent of calendars,
+timezones as well as leap seconds. Of course Perl can't go beyond the
+machine to get a real TAI value, but it should perform any
+platform-specific transformation to give you the most precise value it
+can for the TAI.
+
+ our Rat sub time()
+
+Returns a TAI epoch value for the current time.


Shouldn't the result type of time() be an "Instant" object (Instant and Duration 
are defined in S02) rather than a "Rat"?


Temporal routines should always be using temporal types when talking about 
instants or durations, not more generic types like numbers or strings except 
when explicitly converting or extracting a temporal value into one of those 
types, such as when displaying it.


-- Darren Duncan