Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

speters (1787)

speters
  (email not shown publicly)
http://www.fisharerojo.org/
AOL IM: fisharerojo (Add Buddy, Send Message)

mmm...Perl

Journal of speters (1787)

Sunday April 01, 2007
02:26 PM

[Perl 6 Microgrant] Parrot compiling on C-64

I pretty much had to pull an all-nighter, but I finally got Parrot compiling and testing perfectly on my C-64. I'm guessing some people thought it was an "Impossible Mission", but I have that "M.U.L.E." off my back.

Saturday March 31, 2007
07:32 PM

[Perl 6 Microgrant] Week 1 ending status

The majority of this week has been to start understanding the lay of the land in the Parrot world. The first real obstacle seems to be the regular use of void pointers throughtout the code base. This can make the code difficult to understand since you don't really know what's coming. It also has the nasty side effect of preventing a true C++ compiler from compiling Parrot.

So, to begin, I created the following patches to begin the cleanup.

  • RT #42107 [PATCH] Intel C++ is not gcc
  • RT #42110 [PATCH] Returning values from void functions
  • RT #42151 [PATCH] Assorted casting cleanups - part I
  • RT #42156 [PATCH] Make invoke() return opcode_t*

All of the above were applied, although RT #42156 required some re-work on my part.

I also dug up the warnocked "RT #41837 [PATCH] integer overflow in include/parrot/sub.h" that had been submitted some time ago. It fixes some integer overflow issues that the Sun compilers on Solaris x86 complain loudly about.

For the upcoming week, I see the cleanup of void pointers continuing. I'm also looking into compiling on Borland C++ on Windows. Borland can be much more strict than other compilers causing it to choke on things other compilers let past. I should have an additional patch to help me out with Borland C++ tonight. I also need to take a look at the segmentation faults I'm seeing when I test Parrot on Solaris. I also need to test a couple of changes on HP-UX PA-RISC as well. Finally, there have been some reported success of compiling Parrot on Cygwin. I just need to work on those successes so that you don't have to be a regular on #parrot to compile successfully.

Monday March 26, 2007
03:15 PM

[Perl 6 Microgrant] First steps

So, now it's official. Time to go to work.

The first thing I want to look at is Intel C++ support for Parrot. I have to take this on somewhat carefully for a few reasons.

  • Like gcc, Intel C++ spans multiple operating systems including Windows and Mac OS X.
  • Compiler flags differ depending on the OS.
  • Most annoyingly, Intel C++ tries to look like gcc, but isn't anywhere near compatible.
  • Advice from Klortho #11912 applies to icc's math capabilities

I need to look Parrot's current processes for identifying Intel C++ so we do not have to repeat the logic for each operating system hint file where Intel C++ is supported. My thoughts now are to identify Intel C++ earlier in the Parrot configuration chain, but I haven't decided yet whether this should be when we check for gcc, or if this check should be done separately.

Tuesday August 01, 2006
09:24 PM

MadMongers Wednesday!

MadMongers, the Madison, WI, Perl Mongers group will be holding its first meeting tomorrow night. Please, come and join us to help get the group kicked off, or just come to have a beer and talk with a bunch of other Perl programmers. See you there!

Wednesday April 12, 2006
10:06 PM

Playing with fire

I’ve been lucky enough to recently get access to the Sun Fire T2000 that Ask and Robert have gotten from the Sun Test Drive program. I have to say that so far it has been quite fun to play with.

The architecture of the new UltraSparc chips is quite interesting. You can check out the OpenSparc website if you are really interested, but it allows each CPU to run four separate, autonomous threads, or strands, as Sun calls them. Because of this, an 8 CPU box, like the perl.org T2000, behaves like a 32 CPU box. I have to say that running gmake –j33 when developing Perl is a real time saver.

More importantly, of course, is that it has helped us to close out a few old bugs as well as help us find a few new ones. Nicholas fixed some parallel build issues that prevented the gmake gymnastics above. He is also playing with parallel testing with harness in the Perl distribution. With multiple CPU cores becoming more common (I’m expecting to see a good number of MacBooks at YAPC::NA) this will be helpful to a lot of Perl developers.

The new bugs involved a couple of additional build issues. First, Perl’s tests were making the assumption that the UNIX init proc had a pid of 1. That’s not necessarily the case on the T2000. Second, I found that the make used to build some of core modules switched from gmake to Sun make. This isn’t very helpful when you are trying to use gmake’s parallel make capabilities. I’ve got a patch that Nicholas suggested to fix this. Now, I just need to complete testing on before I commit it into the core.

Now, that we’ve kind of broken it in, I’m going to try to do some benchmarking on the box to try a few comparisons that have popped up on the perl5-porters mailing list in the recent past. One interesting one that Jim Cromie discussed was using Perlbench to compare multiple runs of a single Perl against itself. The idea is that Perl should perform with some regular consistency. One that I’m interested is comparing the performance of a big 16 CPU Itanium box against the T2000’s 8 CPUs that behave like 32 CPUs. I really want to see how the virtual CPUs compare against the real thing. Finally, I’m hoping that this platform will help point out the poor performing places in the Perl core so that I can help speed up Perl a bit in a few places. Hopefully, I won’t need a crash course in Sparc Assembly Language to do this. :)

Friday December 02, 2005
06:52 AM

The Cat That Ate Tuits

I was going to post this picture as a response to the dog who ate tuits. Unfortunately, Simba (the cat) has decided to eat tuits in a very bad way. Two evenings ago, he somehow got out of the house, and has disappeared. Being an inside cat all of his life, sneaking out is never a good thing. With Winter now here with snow and near zero F wind-chills, this has been made a lot worse. My hope right now is that he is in someone's garage and just hasn't had the chance to escape yet. I'll stick with that for now.

Update: Simba was found under a bush a block away from our house by a woman who was putting up her Christmas lights. I'll have to find out which house, since I thought I had looked through every pine tree and bush in a couple block range.

Tuesday July 12, 2005
10:00 PM

America's pastime?

I noticed an unusual visitor at Saturday's White Sox game. Take a good look at the top right corner.
Saturday February 19, 2005
01:17 PM

Perl Onion logo

Somewhere in the recent past, the perl.org sites switched to using an Onion logo, like this one.

Unfortunately, I haven't seen anything about the switch to these logos, any guidelines for use, or even what logos are available. It'd be great to have some of these questions answered somewhere.

Thursday March 04, 2004
01:48 PM

Reserved for future use

I have seen this in so many languages and systems for either keywords, table names, and class names. I have yet to see something reserved that was actually implemented though.
Saturday February 28, 2004
09:50 AM

RFC - Test::Reference

Either the Perl-QA mailing list is down, or it just doesn't like where I'm sending my mail from, because my emails just don't seem to the making the list.  Well, not seeing an obvious Test:: module that would work for me to make sure
that two references referred to the same thing, I wrote my own module.
Before sending it off to CPAN, I'd like to see what you all think of it.
Also, I have a couple of questions.  First, the module includes some XS,
which is unusual for Test:: modules.  Do you think I should split my code
into two modules (say Devel::References::Same and Test::References) or keep
it the way it is.  Second, I'm not particularly in love with the names
Test::Reference with the function "references_same".  I was thinking of
Test::References::Same as a possible name for the module, but then I at a
loss of what to call the function.  references_same_ok?  I'd appreciate your
thoughts.

NAME
       Test::Reference - Check to see if two references refer to the same
       variable

SYNOPSIS
           use Test::Reference;

           my $val1 = 5;
           my $val2 = 5;

           my $a = \$val1;
           my $b = \$val1;
           my $c = \$val2;

           references_same($a, $b, "Will return ok");
           references_same($a, $c, "Will return not ok");

DESCRIPTION
       This modules allows you to test to see if two references refer to the
       same variable or not.

FUNCTIONS
       "references_same( $ref1, $ref2, $mesg)"

       Checks to see that the two references are references and that they both
       refer to the same underlying variable.

SEE ALSO
       Extending and Embedding Perl - my main reference for learning XS

       Devel::Peek - my other main reference for learing XS

AUTHOR
       Steve Peters, <steve@XXXXXXXXXXX.XXX>

COPYRIGHT AND LICENSE
       Copyright (C) 2004 by Steve Peters

       This library is free software; you can redistribute it and/or modify it
       under the same terms as Perl itself, either Perl version 5.8.3 or, at
       your option, any later version of Perl 5 you may have available.