Which version of Sun Studio do I have installed?

May 14th, 2010

Recipes for supported packaging formats

Sun Studio is available on three different packaging systems. Here are some examples that show you how to get information about the Sun Studio packages on each kind of system.

  • IPS packaging system – on OpenSolaris
  • SYSV packages – on Solaris 10
  • RPMs – on SuSE and RedHat Linux

If you want to know what version of a Studio component you’re using, the steps are shown below.  The compiler or tool you’re interested in might be on your search path (you can find the location with “which cc”) or you might already know the full path.  Once you have the full path, here are the things you might want to find out:

  1. Find out the name of the package containing that binary.
  2. Dump out information about that package.
  3. Optionally look for other packages from the same Studio release, to see what else is installed.

Generally the multiple packages that make up Sun Studio will use a similar naming convention.  In the currently available releases, these package names are cryptic.

Sun Studio 12 update 1 installed on Solaris 10

What version is built into the binary?

% /opt/sunstudio12.1/bin/cc -V
cc: Sun C 5.10 SunOS_sparc 2009/06/03
usage: cc [ options] files.  Use 'cc -flags' for details

Which package is that binary in?

% pkgchk -l -p '/opt/sunstudio12.1/bin/cc'
NOTE: Couldn't lock the package database.
Pathname: /opt/sunstudio12.1/bin/cc
Type: symbolic link
Source of link: ../prod/bin/cc
Referenced by the following packages:
SPROcc
Current status: installed

What other packages are installed?

% pkginfo | grep SPRO
application SPROatd                          Sun Studio 12 update 1 Advanced Tools Development Module
application SPROcc                           Sun Studio 12 update 1 C Compiler
application SPROcmpl                         Sun Studio 12 update 1 C++ Complex Library
application SPROcpl                          Sun Studio 12 update 1 C++ Compiler
application SPROcplx                         Sun Studio 12 update 1 C++ 64-bit Libraries
...

Sun Studio 12 update 1 installed on OpenSolaris

What version is built into the binary?

% /opt/sunstudio12.1/bin/cc -V
cc: Sun C 5.10 SunOS_i386 2009/06/03
usage: cc [ options] files.  Use 'cc -flags' for details% /opt/sunstudio12.1/bin/cc -V

Which package is that binary in?

% pkg search -lp /opt/sunstudio12.1/bin/cc
PACKAGE                                   PUBLISHER
pkg:/developer/sunstudio12u1@12.1.1-0.111

What other packages are installed?

% pkg list | grep -i studio
developer/sunstudio12u1                       12.1.1-0.111    installed  -----

Sun Studio 12 update 1 installed on SuSE 11 Linux

What version is built into the binary?

% /opt/sun/sunstudio12.1/bin/cc -V
cc: Sun C 5.10 Linux_i386 2009/06/03
usage: cc [ options] files.  Use 'cc -flags' for details

Which package is that binary in?

% rpm -qf /opt/sun/sunstudio12.1/bin/cc
sun-cc-12.1-1

What other packages are installed?

% rpm -qa | grep sun- | head
sun-lang-12.1-1
sun-idext-12.1-1
sun-mr3m-12.1-1
sun-prfan-12.1-1
sun-stl4h-12.1-1
sun-cplx-12.1-1
sun-dbxx-12.1-1
sun-pls-12.1-1
sun-dwrfs-12.1-1
sun-rtmx-12.1-1
...

Notes

The excessively terse naming convention is because of the ancient restrictions in AT&T System V UNIX that limited package names to 9 characters.   Sun also made an early decision to prefix packages names with 4 letters to mark the part of the company that was releasing the packages.  In all fairness, Sun was trying to invent a scheme where outside software vendors could reasonably choose package names without accidentally conflicting with any of the Sun packages.  That’s difficult to do in only 9 characters.  On OpenSolaris, you can see that we merged everything into one package.  Because the friendly new packaging system is one of the highlights of OpenSolaris, we didn’t want to confuse new users with the multitude of small packages we have for Sun Studio.

Hopefully, this information will be useful in a variety of circumstances. Inside the Studio team, we need to go back and forth between all three packaging systems, and it’s not easy to remember the right system commands to work with the packages on a given system. In the support team, one of the first things they ask a customer is which version of the Sun Studio software they are running. It’s also possible to install subsets of Sun Studio, so you may want to know which tools are currently installed.

Note: Studio will actually run fine on lots of different versions of Linux, including distributions that don’t use RPM as their native package format (like Ubuntu).  The tarball downloads are useful for those Linux distributions.

OpenSolaris VNC update

April 22nd, 2010

I use VNC connections as part of my regular daily routine, and I ran into another bug a few days ago, so I figured I’d post a summary of the current bugs that are currently afflicting me, and the workarounds for them.

First is a really interesting bug where the less-than-sign turns into a greater-than-sign.  Really.  I’m not joking. The comma and period work fine, it’s just the less-than-sign.  The public bugid for this is 14729. The workaround is to run xmodmap when you start your VNC session (I put it in ~/.vnc/xstartup).

xmodmap -e 'keycode 94 = comma less'

The second bug is that the server crashes whenever you turn OFF the capslock key.  The public bug for this one is 14397. The workaround I found for that is the following:

vncserver ... -RemapKeys 0xffe5->0x00

In other words, you try to disable the capslock key, and the result is a capslock key that works correctly.  I have no idea what the implementation is doing.

I’m using a Mac client these days as a desktop, so I’d be interested in hearing from anyone using windows VNC clients to see if they’ve hit these same bugs or not.  Of course, I do live on the bleeding edge of OpenSolaris.  The last few biweekly dev releases have been internal-only, but I think both of these bugs are in public OpenSolaris releases.

Code Bubbles

March 13th, 2010

This is the IDE for me.  They start talking about debugger functionality about 75% of the way through.  IDEs are all about navigating huge amounts of information. Code Bubbles (http://www.cs.brown.edu/people/acb/codebubbles_site.htm)

Types, Objects and Generic Types

February 24th, 2010

Assume the axiom that punctuation is evil.  Using multiple kinds of brackets for similar functionality in a language is unnecessarily complex.

The result is:

The relationship between a generic type and it’s concrete types should be expressed in the same way as for the relationship between a type and the objects that are instances of it.

In C++, constructors use: foo(object1, object2), but templates use Foo<Baz,Bar>

Can we unify the syntax for these similar concepts without making the language complex?

It’s completely clear to me why using different punctuation makes it easier to explain how the compiler is implemented, and easier to implement the compiler.  But I don’t think the distinction is necessary to make the source code easier to read and write.

Let’s say we only have “objects”. “Type” would be a role that on object plays with respect to another object. The compiler simply instantiates some objects at compile time, as part of the compilation process.  That seems like a clear concept for coders to understand.

The goal of a programming language is to facilitate the writing and maintaining of software.  It’s not to make the compiler’s job easier.

Sun Studio uninstall problems (Sun Studio 12 update 1)

December 21st, 2009

If you installed the initial release of Sun Studio 12 update 1 (around June of 2009) you might have some problems running the uninstall script that came with it.  Our installer guru came up with a “workaround” script which is now available for download on the Sun Download Center.  You can find a description of the problems and a link to the script on the Sun Studio web site’s Troubleshooting Page.  You may also find it useful to check the Sun Studio 12 update 1 installation guide.  Some of the failure modes may show you errors like this:

The local registry (/root/.nbi/registry.xml) could not be loaded, or was loaded partially.
The installer can continue to work normally, but doing so may result in a corrupted global registry.

As Sun moves towards using the IPS packaging system, we’ll be able to rely more on the packaging tools built in to Solaris, and we won’t have as many issues like these.  I’m looking forward to it.

OpenSolaris build 129 has problems with filemerge fonts

December 16th, 2009

I’ve been staying more up-to-date with Solaris dev builds since they started publishing builds nigh-biweekly. That means I get to experience all the joyful brokenness of a system in development.  Build 128 introduced a problem with VNC which can be worked around by disabling the “tight” encoding (bugid 6906660). And Build 129 introduced a problem with filemerge fonts (bugid 6909040).  Both have pretty easy workarounds described in the bug descriptions.  The release notes for opensolaris are not widely redistributed, so if you’re using the dev repository from outside Sun, make sure you’re on the osol-announce@opensolaris.org mail alias.

Downgrade OpenSolaris

November 13th, 2009

This is a fairly frequently asked question inside Sun, and now that the biweekly builds are available outside Sun, there are probably more people who are interested.  If you want to create a Boot Environment with a specific build (not the latest one) in OpenSolaris, here are the steps to use:

beadm create snv122
beadm mount snv122 /mnt
pkg -R /mnt install pkg:/entire@0.5.11-0.122
bootadm update-archive -R /mnt
beadm umount snv122
beadm activate snv122

Caveat Emptor and all that stuff.  This recipe comes with no warranty, but I’d be glad to make it more accurate or up-to-date if you let me know of improvements.

Facets of Programming

November 10th, 2009

I’ve been thinking recently about the fact that the average piece of software code includes instructions to the compiler mixed together with instructions that should be executed at runtime.  Type declarations are instructions to the compiler. Most of the general sequential code is instructions that should be executed at runtime.  It occurred to me these are just two of many facets of software.  It would be nice to enable all these facets to be mixed together into one document so that the author of the software can keep all the facets consistent.

Another facet is specifications or unit tests.  I group those together because the way they’re tied to software at the code level is very similar, and they serve similar purposes.  There is an approach to coding called “Test Driven Design” where unit tests are written simultaneously with individual chunks of code.  There is a variant of this called “Behavior Driven Design”.  I was exposed to BDD in the latest Scala book (Programming Scala) and that was when I realized the TDD is really about verifiable specification, not so much about testing.

I really don’t want to use something that’s just a “programming language”, I want to use a “Software Authoring System”.

So what are the facets that a good “Software Authoring System” needs?

Runtime instructions: The purest expression of this facet is in dynamically typed languages, because they omit static type declarations.

Compiler instructions: Static type declarations for variables are instructions to the compiler. Type definitions themselves (in static or dynamic languages) are partly for the benefit of the compiler, and partly for the specification of runtime behavior.  Explicit testing and runtime manipulation of types (metaprogramming) uses types as part of the runtime behavior of the program. Virtual dispatch uses type information to determine runtime behavior. But non-virtual dispatch is really just a hint to the compiler about what code is going to be associated with what data. The behavior of such code is wired down at compile time.  The compiler uses it to optimize, and report programming errors back to the user.

The way that instructions are provided to the compiler should be rethought.  The declarative style of such instructions should be retained, but the functionality should be extensible through code that’s integrated with the project code. If I don’t like the way the static type system works (as supplied by the environment), I should be able to write extensions to it that will be executed by the compiler when it compiles my code. Among other benefits, this would allow me to implement better Domain Specific Languages and add better support for static analysis tools.  Moving the language complexity associated with static typing into a user-extensible library would also streamline the core language specification. The implementation of this feature would be more natural in a language where the compiler could just as easily interpret code as compile it, like dynamic interpreted languages.

Documentation: Embedding chunks of documentation inside your source code is a good start, and extracting method signatures is also useful (ala javadoc).  But a truly integrated system could provide much more information about interface specifications, preconditions, postconditions, etc.

Interface specification: If a public function takes arguments including a list and an integer that must be less than or equal to the length of the list, how does the author encode that information into the source code?  They can put it in comments.  They can add an assert statement (which will likely be ignored by the compiler, optimizer, documentation system etc). They can use TDD to create a test case that ensures the module throws an exception if the precondition is violated.  None of that goes far enough.  This kind of specification needs to be supported directly by the programming language and tied into the other facets of programming.

Module definition: The source code structures used to create a piece of software (a reusable module) are often not the same structures that you want to use to control how that software is used by other components.  That’s why programming languages support Classes and instances for object oriented design, and also support some concept of modules or packages for controlling the import and export of software interfaces to other components.  In most cases, this module/package support is a very thin layer glued onto the outside of a programming language.  For example, when creating a shared library on UNIX, there are linker-specific ways to enumerate which symbols are visible to consumers of the library.  There are also platform-specific hooks to allow this information to be passed into the linker from the source code, but again, it’s not truly integrated into the programming language.

Optimization: The author of a component usually needs to concern themselves (at some level) with basic choices that affect performance.  In some cases this requires in-depth bit-twiddling and care selection of compiler options, but in some cases it just means choosing data structure implementations that are appropriate for the task at hand.  As an author, I don’t want to have to use the Makefile to assign different optimization levels to different source files. I’d like to declare that a particular chunk of code needs to be heavily optimized and have the compiler just do the right thing.

Binding: Two kinds of binding are important to me as an author. My component will need to bind to the implementations of the interfaces it needs to be complete. Also, other components will bind to my component. The way I facilitate external binding is really part of the “module definition” facet discussed above.  The binding facet concerns itself with how to control the way that a component binds to its own required components. In some cases you want this binding to be via copy inclusion (think of archive libraries or combining .class files into a .jar file). In some cases you want to bind to external component, and include a version dependency in your component’s binary representation. In my source code I can say “import webservices.securesocket”, should I really have to go over to the makefile or build.xml in order to specify which version of the package I need to depend on?  A lot of what currently needs to go in the build structures should be folded into a new style of “rich” source code.

Static analysis: There’s a very useful development cycle in statically typed languages where you iterate between the compiler and editor while the compiler tells you about static typing errors in your source code.  But there are other static analysis tools besides the compiler.  The “compiler instructions” programming facet that I described above should be extended to include giving instructions to multiple static analysis tools in a unified way. Alternatively, the compiler can be extended as a universal front-end to outside analysis tools. Either way, this facet of programming should be expanded.

With this understanding as a basis, the next exercise would be to define a streamlined language that could be used as the basis for this kind of modern authoring system.

The next big concurrent language

October 7th, 2009

Tim Bray has been writing his thoughts recently on the topic of the next big language for concurrency.

Let me start by saying I’m completely an arm-chair quarterback here, I’ve never used a functional language for a real project, but I’ve worked in the area of development tools and multi-threaded applications for many years. I’ve watched a lot of language extensions and libraries come and go over the years claiming to “solve” the problems of parallel coding.  I’ve also seen some pretty fancy analysis done by compilers, which seems like it could be better leveraged if the languages had better ways to communicate the intent of the code author.

Do we need a new language for concurrency?

My assumption is that the development of OO programming was the result of increasing software complexity, not a response to a particular change in the capabilities of computer hardware (like multi-core is hitting us today).

Over the last many years, distributed networks of computers have been a very popular platform for writing software.  There are many libraries and frameworks for dealing with distributed systems, but specific languages that address that need (I’m sure there are some) have not become popular in general.  Distributed programs are still written mostly in languages that don’t have any specific features to support distributed programming.

So I don’t think the need for concurrency itself will drive the adoption of a new language.  The compelling argument for me is the possibility that the needs of multi-core (and hence multi-threaded) programming may drive software complexity far enough that we need another big leap in programming technology.  I’m skeptical that’s the case, but it won’t stop me from theorizing about what the next leap in programming technology might be.  🙂

Eventually we’ll need a new language, what will it be like?

Global state makes multi-threaded programs difficult to write and maintain because it requires synchronization.  The problem is not the synchronization, the problem is the global state. That’s a lesson I take from functional languages. Previous attempts to address concurrent programming tended to focus on encapsulating the synchronization, instead of encapsulating (or abstracting away) the global state.  For example, a parallel language extension that allows you to specify a matrix operation without needing to name any iterator variables has abstracted away the global state (in this case, the iterator variable).  A language feature (like OpenMP) that tells the compiler where and how to synchronize, but still requires you to code the iteration yourself, is hiding the synchronization but not the the global state.

It’s tempting to look for a language that emphasizes functional programming in its design, but that’s not necessarily the right approach.  There are many difficult and complex aspects to writing software, and the problem of global state is just one more. The right response is to look for a language that makes it easy to encapsulate global state.  In general, functional languages don’t necessarily make it easy to encapsulate global state. I think the correct response is to look at languages that can abstract away the complexity of MT coding and global state in effective ways.

So here’s an analogy: A long time ago I took a course on the software APIs used to internationalize software.  My main take-away was the the best way to internationalize any sort of library was to remove all the messages from the library, and only return diagnostic codes.  In other words, the best way to internationalize code is not to have to.  Similarly, the best way to synchronize code is not to have to. You want to encapsulate it into a specialized module.

In a layered application that is concurrent, you want to focus on making the lowest layers of software completely reentrant (that is, side-effect free). It’s generally not a big deal if the very top layer has global state, as long as the top layer is sufficiently thin. You want a language that makes it easy to write side-effect free code, but there is still lots of code that needs to have side-effects that can’t be ignored.

So it seems to me that the key feature we should be looking for is a significantly increased ability to abstract away implementation details.  By the way, any functional language that requires coders to understand how/why/when to write a tail-recursive function loses out big time in the abstraction department.

I was recently inspired by a paper in IEEE Computer that talked about a research language called SequenceL. I discussed it in a previous blog. The benefits of SequenceL are described as the ability to write executable code that maps as directly as possible into a requirements specification in the jargon of the problem domain.  This meshes with the recent discussions of DSLs (domain specific languages) as a good way to encapsulate various concurrent implementations.

Check out my last blog entry about SequenceL, and read the paper, it’s very well written.  If you have a direct link for it, please let me know.

SequenceL : Declarative Language Design

September 16th, 2009

I faithfully scan the tables of contents for IEEE Computer every time it comes out, and every now and then there’s a paper that I find both interesting and well written.  Today I found one called: “Taking Parnas’s Principles to the Next Level: Declarative Language Design” by Daniel E. Cooke and J. Nelson Rushton, at Texas Tech University.  I’d never heard of Parnas, but the paper discusses a programming language called SequenceL, which addresses some of the issue I have with programming language design.  Specifically, both functional and procedural languages make it necessary to “wire down” an implementation too much, and don’t allow enough leeway for an intelligent compiler or an intelligent library to offer a generic software service.  The language discussed in the paper revolves around an increased reliance on declarative syntax to specify a richer set of functionality. You might also describe the approach as heavily polymorphic, but I don’t think that description really captures the elegance apparent in the examples.

The emphasis in the paper seems to be on the ability to create an algorithm implementation that is very close to a natural language specification of the requirements.  In fields where that’s an issue (space shuttle software, in the article) that seems like a good measure of success. But I think the increased level of data hiding and abstraction also lends itself to supporting much more freedom in the compiler, libraries and runtime system to choose implementation details that are best suited to executing the program on particular hardware or in a particular operating environment. Unsurprisingly, when I googled for SequenceL I also found papers with names like: “Automatic parallel control structures in SequenceL” and “Automatic Concurrency in SequenceL”.

Anyway, it was a very stimulating paper. Unfortunately, it’s a restricted download on the IEEE site. If you’re a Sun employee, you can access the IEEE site without a special login, the instructions are available on the Sun internal network at the Sun Learning Services web site. I assume you can also purchase it online from the IEEE site, but I didn’t verify that.

Update: Very interesting.  Two days after I read this paper, I scanned through some slides being presented at Sun by Kunle Stanford Pervasive Parallelism Laboratory.  He discussed the future of highly parallel app development, and his vision includes more emphasis on Domain Specific Languages, using Scala as a base platform for the DSLs.  More support for the idea that current programming languages require you to put too much implementation knowledge into the application level. You can find a set of slides very similar to what he presented on the Scala web site.