Setup a Smoke Tester
I mentioned this in a previous post. Even though I don't want to repeat myself generally, setting up an automatic smoke tester is really a great and easy way to get involved in Parrot and to be a huge immediate help for the community. Since my last post went out we've seen a few new IRC bots showing up to inform us automatically about build and test failures, and we've seen a few new platforms showing up in the smoke test results. I can't overstate how valuable this is, seriously!
Interprocess Communication
Know anything about IPC? More importantly, know anything about IPC on your rare system? Parrot has basic functionality built in to spawn new processes, and our first real pipes implementation should be landing into trunk this week. However, a lot could benefit from people with solid know-how getting to work on some of the nitty-gritty issues. Parrot has several tickets dealing with IPC, some of them are among the oldest tickets in RT.
Ticket #31144 has to do with the arguments to our spawn and exec functions, which need to be cleaned up and parsed in a platform-independent way.
Ticket #36619 likewise involves the return values from these two operations, which should be returned as platform-independent values so Parrot can make use of them at a higher level.
Files and Filesystems
Parrot has a special OS PMC, which is a singleton type that allows some interaction with the operating system. The most important among these operations are file interaction operations. Unix people may know a utility called "touch", and Perl 5 people may be familiar with the utime builtin. Parrot doesn't really have a way to update file times like this, and you're able we would love for you to add one. Ticket #38145 discusses this particular need.
Likewise, Ticket #38146 discusses the creation of a file copying utility, although discussion there has since degraded into a general discussion about what's the best architecture to use for implementing these kinds of functions. Input on that discussion, or a solution to the problem, would both be appreciated (and moving the ticket from RT to Trac where it can be even more visible would be a big plus!)
Are you a Win32 person? There are lots of tickets around that deal with some of the idiosyncracies of that platform. Ticket #39853 specifically deals with the way forward slashes and backslashes are used in Windows, and how they should be standarized in file names.
Libraries and Dynamic Loading
Parrot aims to be very dynamic and pluggable, and a number of items from PMC types to opcodes to libraries can be loaded in to Parrot at runtime. But for all this to work, Parrot needs to have a robust mechanism for finding and loading libraries, including installed system libraries and local libraries.
Ticket #37258 involves problems loading libraries with periods in the filename. It's a practice that's far more common on Linux then in Windows, but important to get right in a platform-agnostic way.
Compilers
Any good with Compilers? Parrot builds really well with GCC, but when you start talking about other compilers the situation isn't so rosy. We always need lots of help (including fixing errors/warnings and setting up automatic smoke testers) getting Parrot to build with other compilers. Here are some of the ones that we need more testing and work on, specifically:
- Microsoft C Compiler, 64bit systems
- LLVM and Clang, 32- and 64-bit systems
- Intel C Compiler, 32- and 64-bit versions
- G++
At whiteknight's suggestion, I have moved 4 of the 6 RT tickets mentioned in this post to Parrot's newer Trac system:
ReplyDeleteRT .......... TT
31144 -> 847
36619 -> 848
38145 -> 849
37258 -> 850
Example: https://trac.parrot.org/parrot/ticket/847