This might be useful... (thanks planetlisp!)
Chris Double
Wed Jun 30 17:22:09 2004
http://radio.weblogs.com/0102385/2004/07/01.html#a625
I came across a free portable arbitary precision integer and rational
arithmentic library called [1]IMath that looks useful. It is und
Alexey Trofimenko writes:
> if we really about to lose C-style comma, would we have something new
> instead?
>
> new C<,>,( as I've been told here by wise ones), doesn't guarantee order
> in which its operands will be evaluated, and even doesn't guarantee that
> they won't be optimised away before
On Wed, 2004-06-30 at 18:18, Alexey Trofimenko wrote:
> P.P.S. do we have a way to imply void context on function inside
> expression, something like C, C<+>, C<~>, C do?
Sort of a 'meh' operator?
I wonder (idly) in which circumstances the context determinator couldn't
determinate void context
if we really about to lose C-style comma, would we have something new
instead?
new C<,>,( as I've been told here by wise ones), doesn't guarantee order
in which its operands will be evaluated, and even doesn't guarantee that
they won't be optimised away before evaluating, if all expression is in
On 24 Jun 2004, at 21:49, Piers Cawley wrote:
Dan Sugalski wrote:
it's not exactly exciting watching two people hit return three times
in front of a roomful of people.
Although watching two people hit each other in the face with custard
pies three times in front of a roomful of people may be a lot
The Perl 6 Summary for the week ending 2004-06-27
What's this? No! It can't be! It's a *weekly* Perl 6 Summary. What is
the world coming to?
Sorry, I can't answer that one, so I'll tell you what's been happening
this week in perl6-internals.
Bignums, licenses, pie
As you are
On Jun 30, Steve Fink said:
>On Jun-27, Jeff 'japhy' Pinyan wrote:
>
>> It creates a tree structure, not identical but similar to the array of
>> nodes Perl uses internally.
>
>Ah, good. Then I am interested. When I manage to find some time for
>hacking again, I'll graft it onto languages/regex as
On Mon, 2004-06-28 at 06:25, Dan Sugalski wrote:
> While I'm off in this "real world" thing, it'd be in our best interests to
> go do some work on parrot's standard library. A good place to start is
> with the list of functions we'll need for the upcoming pie-thon contest
Is this list compiled any
On Wed, Jun 30, 2004 at 11:42:34AM -0400, Vsevolod (Simon) Ilyushchenko wrote:
> I have tried to run Devel::Cover on my tests that use Test::Unit, and I
> am getting this after the code is run:
>
> Deep recursion on subroutine "B::Deparse::find_scope" at
> /usr/lib/perl5/5.8.1/i386-linux-thread
On Wed, 2004-06-30 at 07:15, Dan Sugalski wrote:
> In all those cases you've got a binary-only distribution, and a valid
> one. (In fact, one that we want to encourage) Section 4, by my reading,
> means you've got to ship source to the LGPL component.
Well, "provide source" might be a better way o
On Jun-27, Jeff 'japhy' Pinyan wrote:
> On Jun 27, Steve Fink said:
>
> >On Jun-26, Jeff 'japhy' Pinyan wrote:
> >> I am currently completing work on an extensible regex-specific parsing
> >> module, Regexp::Parser. It should appear on CPAN by early July (hopefully
> >> under my *new* CPAN ID "JA
On Wed, 2004-06-30 at 07:17, Will Coleda via RT wrote:
> This patch was applied incorrectly - the pod closer =cut ended up
> outside the C comment. (as noted by Nick Kostirya)
Yep, that was me. It's fixed and compiles now.
-- c
Hi,
I have tried to run Devel::Cover on my tests that use Test::Unit, and I
am getting this after the code is run:
Deep recursion on subroutine "B::Deparse::find_scope" at
/usr/lib/perl5/5.8.1/i386-linux-thread-multi/B/Deparse.pm line 1317.
Deep recursion on subroutine "B::Deparse::dq" at
/usr/
This patch was applied incorrectly - the pod closer =cut ended up
outside the C comment. (as noted by Nick Kostirya)
> [EMAIL PROTECTED] - Tue Jun 29 10:23:42 2004]:
>
> On Mon, 2004-06-28 at 21:30, Will Coleda wrote:
>
> > Closes the pod inside the C comment for "pmcarray"
>
> Thanks, applied.
> Actually, it seems that some of the patches were applied. The problem is
> that is_deeply() delegates to ->is_eq() for non deep arguments but handles
> it's own string comparison once you descend into the structure.
yes, I figured it was something like that - who hasn't been bitten by this
kin
On Wed, Jun 30, 2004 at 09:59:15AM -0400, Geoffrey Young wrote:
> I found some stuff about is_deeply() and stringified references, but it
> doesn't look to me to be the same thing. the problem I am describing is the
> difference specifically between an empty string and undef.
>
> is_deeply(['']
On Tue, 29 Jun 2004, Scott Bronson wrote:
> ASSUMPTION
>
> Parrot will only link to the GMP library, right? Either static or
> shared, doesn't matter.
> 4: The Parrot project will be distributing source code, not object code,
> so this section does not apply.
Well...
The problem is distributin
Fergal Daly wrote:
> There are patches in the archives for this and a couple of other bugs but
> they were submitted along with another change that wasn't acceptable so they
> were never applied. A search for is_deeply should find the patches and a
> long argument,
I found some stuff about is_de
There are patches in the archives for this and a couple of other bugs but
they were submitted along with another change that wasn't acceptable so they
were never applied. A search for is_deeply should find the patches and a
long argument,
F
On Wed, Jun 30, 2004 at 09:12:45AM -0400, Geoffrey Young
Hello.
Please move =cut into C comment at classes/pmcarray.pmc file.
Nick.
hi all
I'm not sure if this is the proper forum for reporting Test::More bugs, but
I know some of the interested parties are listening :)
use Test::More tests => 2;
is(undef,undef);
is_deeply([undef],[undef]);
# both of these should fail
is('',undef);# this fails
i
Scott Bronson wrote:
On Wed, 2004-06-30 at 00:14, Ion Alexandru Morega wrote:
... there are advantages in including
the source code:
- GMP's compilation process is aware of the machine's hardware,
making optimisations accordingly. It should be compiled along with
parrot, for better perfor
On Wed, 2004-06-30 at 00:14, Ion Alexandru Morega wrote:
> ... there are advantages in including
> the source code:
> - We could trim down all the functionality we don't use (if there is
> any)
On modern architectures, I don't think that this will actually buy very
much. Shared libraries ar
I haven't read the LGPL carefully, but there is one point i'd like to make.
Scott Bronson wrote:
ASSUMPTION
Parrot will only link to the GMP library, right? Either static or
shared, doesn't matter.
It would certainly work that way, but there are advantages in including
the source code:
- We co
24 matches
Mail list logo
