Thoughts on Oracle v Google stuff

Or more specifically after parsing this, thanks Noles ;).

Personally, I think under that context, Oracle will likely win.  I do not believe that a language /should/ be copyrighted but that they technically can be, think about how the types involved might mix for various copyrighted works.


I'll be the first to admit that our system for copyright, patents, intellectual property, trademarks, and the like is a maze with more than a few turns just full of bullshit. But let's think a moment: what is it really about? Money. It's not about fostering innovation (patents) or controlling your property (oi). It's about money. That's it, simple.


Java is a product and a creative work, sufficient to be copyrighted. So is the GNU Compiler Collection and that last book you read.


What is the jist of copyright? Wikipedia as of this writing, defines it as a sub class of Intellectual Property that is generally "the right to copy, but also gives the copyright holder the right to be credited for the work, to determine who may adapt the work to other forms, who may perform the work, who may financially benefit from it, and other related rights"


Java, as it applies to Android, is not very different than any other language applied to other systems. The devil is in the details as they say. An Android application is a collection of Dalvik bytecode, native code, and resources running under the Dalvik virtual machine: and Android provides a runtime.

The implementation is not "Java" as Oracle ships it. In fact, as Microsoft's various efforts to make a .NET dialect of C++ and projects like JRuby confirm: you can have a fair bit of abstraction between *concept* and implementation. Android developers typically write code in Java to an interface documented in Java. They could just as easily write in any language you can eventually wrangle into Dalvik bytecode! Android applications can and have been written in other JVM languages, and non JVM languages. The interface, well hell, many things in the .NET world are done in C# but you could just as easily use Visual Basic or F#. Really helps to be able to read C# though. Just like how on many systems, it helps to be able to read C and or C++.



That runtime part that Android applications depend on is quite "Java like". Many intrinsic components are provided. C programmer's should think of the stdio library. Because that is the sort of thing that has been "Copied" from "Java". Essential programming interfaces, not implementations but interfaces (as far as Oracle holds right to). GNU implements C's I/O library in their runtime. So does Microsoft in their own. They didn't have to supply crap like printf() and puts(), they could've supplied their own pf() and IoConsolePutLStr() functions! Nether group owes the other jack shit over that. But hey, printf() and puts() are what are widely used: even in other languages!!!!

A lot of things in Androids runtime are also unique. For example, the parts that make it Android specific rather than able to compile under Oracles development kits for PC. The implementation is not copied but the conceptual interface, yes.


So that's a problemo, how far does that level of control and ownership apply to derivatives? And what actually constitutes a derivative work?


Is copying the script of a movie scene for scene, line for line, and reshooting it for your own release and profit, an issue? Yeah. Obvious. Is doing a movie about a train, going to allow whoever owns copyright on some other movie with a train, to sue your ass for it? It shouldn't unless it's close enough to the former, or similarly having a legal problem of some other sort.


It's more of a question like, should Matz and Oracle be able to sue the developers of JRuby for copyright infridgement: because it provides an even stronger resemblance to both Ruby's and Java's programming interfaces than Android's runtime does to Java's. Things like C, C++, C#, Common Lisp, Scheme, and EmcaScript are formally standardized to some extent. Things like Java, Python, Perl, Ruby, and Lua are not. Could Niklaus Wirth (or Apple) have sued Boreland over Delphi?


I do not feel that it is responsible to exercise such strong-arm aggression against users. It's bad for Java, it's bad for business, it's bad for the continuing evolution of the industry, and it's bad for those who have already invested.


And as far as I am concerned, enough programming languages "Borrow" stuff that applications of copyright the way Oracle must be seeking, or not feasible—and may very well fuck up language development for the next decade. Now we have to worry what the fuck we name our classes? What next, companies are going to start exerting control over _our_ works made with their tools?


Thanks Oracle, hope your stock plummets and your employees find good jobs with businesses that offer better job security.

Thoughts on Android development *ON* Android

I'm crazy enough for it, after all BTEP+{bash,vim,coreutils,etc} on the TF101 is about as pleasant as on a netbook. The difference between BTEP and XTerm, makes something like Screen or TMUX a necessity IMHO and I favour the latter. Also copying and pasting from vim to Android apps is different. Without vim's X support, a temp file is the best solution until BTEP gains real support for text selections.

My point being, if you can use a netbook and a command line environment, doing it on Android is no different. Hell you could even SSH into a phone from a PC if you lack a Transformer or a tablet+Bluetooth keyboard setup. Only people that _require_ something like Eclipse or Visual Studio are seriously impacted, and emacs and vim are good tools when combined with GNU tools (BusyBox a bit less so).  I have the equal of Debian without X.Org running on my transformer, a decent terminal emulator, and a real keyboard. So I am well equipped.



Now, the sticky part is actually being able to compile and run Android Java programs. You can write the code on a napkin if you want but that doesn't work with your devices CPU quite so easily.


Android developers should already know the compilation model:

        *.java -> *.class -> *.dex -> classes.dex

A compiler is used to convert the source code into Java bytecode. This technically means that any language that you can get running on a JVM, and interface with Java code, you can probably use for Android development; in practice I'm sure there are more devils in the finer details.

After we get the Java bytecode, we have to convert it into a format for the Davlik VM to run. That's where the dx program comes in. It translates Java to Davlik.

Because applications are rarely composed of pure source code, especially Android ones, things get slightly more complicated to create a .apk file you can install. The packaging tool aapt, apkbuilder, and aidl programs join javac and dx in creating the .apk file, the end goal of our the toolchain. In practice: .apk is pretty much .jar, which is pretty much .zip. Only classes.dex is used instead of a .class file per class in your code, and something I wonder why Sun never thought of!


Now, the issue is obviously how to run all this shit on an Android device, like my Transformer.

Google only publishes SDKs for Windows, Linux, and OS X systems on x86, Linux+ARM isn't supported, sadly. Installing an x86 emulator and a mini distro with Java  and ssh is over kill, even for my Debian chroot loving self! BUT most of the SDK is in Java or BASH!

Java runs on Debian/ARM, so we can install a JDK and JRE, and thus get access to the Java side. Bash is already available for Android, let along Debian/ARM. So! The point of concern becomes x86 binaries. That seems to amount to most programs in platform-tools/ and tools, but what do we /actually/ need? Well guess what Jack, if we're doing development on device, we don't need the emulator! AFAIK the tools we do need are:  apkbuilder, dx, javac, probably jarsigner. The aapt and android programs being good to have, ditto for ant I'm sure.


aapt is a binary, so at best it would have to be natively or cross compiled, and much like make in C country, we can probably do it another way. The source is probably in the Android Open Source Project (AOSP) somewhere, which would make this easier.

android, apkbuilder, and dx are bash scripts.

android sets up an invocation of the Java VM (java) with tools/lib/sdkmanager.jar and a suitable SWT JAR and runs the program. I don't know if SWT needs to be in the classpath when running it in command line mode, but hell, Debian/ARM = SWT deb somewhere.

dx is similar but uses platform-tools/lib/dx.jar.

ditto for apkbuilder, but using tools/lib/sdklib.jar


In looking at the manifests, a suitable Java execution environment is all that is needed for the serious leg work. That surely can be done using the JRE and/or JDK debs. Hoorah! And obviously the point of the "platforms/android-*" stuff is for javac and the emulator to work, android.jar in particular is our interest.


One downside, dealing with Renderscript or NDK stuff is another delema as obviously those rely on binary stuffs that are not Java, and AFAIK the toolchain for Renderscript depends on an LLVM frontend, so idk how to deal with that yet, but I'm not worried about it -- most applications shouldn't be using renderscript, unless maybe you're making Modern Warfare 4 on Android >_<.



So I think, I is in business.


PostScript: I am aware of the Terminal IDE app but prefer to be closer to the official SDK and I would rather stick closer to my Debian chroot, especially because BTEP+tmux is a better place for using VIM with a real keyboard.

Humorous language comparison

Special thanks to Carpet Smoker of Daemon Forums.

Reflections on C#

Lately, I've been trying to use C#. No sense in learning a language and never using it, ever, lol. Over the years, I have generally skipped getting into C# - to much like Java for my tastes. Some months ago I picked up the lang' as just a way of passing time. Found it interesting to note that C# was also about 3-4 times more complex than Java, syntactically. By contrast most of the complexity in Java comes from APIs or hoops you have to jump through to do xyz.

In putting my C# knowledge into practice, I've found that most of my linguistic gripes against learning it have been solved in .NET 3.0 / 3.5, and making portable code that works under Winows and Unix is just as easy as expected: in fact I test everything against the compilers from Microsoft and Mono. I've not had any troubles, and I am using like last years Mono version.  Although, I must admit that I think of Monos setup as the "Novell implementation" and .NET as Microsoft's >_>. The portability of C# is every bit as good as Java and dynamic languages. In fact, if it wasn't for the Mobile version (Java ME), I would say C# is more portable than Java these days.

C# already have features that are expected in Java 7 and C++0x, but everyone will be damned if they will get to use any time soon. To top it off given the blasted prevalence of Windows machines, just about everyone will have a liveable version of the .NET runtime that you can program to in a pinch. Between actually using the computer, newer Windows versions, just about all of them will have a modern version. Plus several popular unix applications (and parts of the Gnome software stack) are written in C#, so the same goes for many Linux distributions. Alas the same can't be said of getting various C/C++ libraries compiled....

Compared to Java, C# is a mixture of what Java should have evolved into as a business language, and a bit of C++ style. C# also goes to lengths to make somethings more explicit, in a way that can only be viewed as Java or COBOL inspired. I'll try not to think about which. I think of professional Java and C# programming as our generations version of Common Business Oriented Language without the associated stigmatism.

The concept of "C++" style in C# however, is something of a moot point when we talk about Java too. Here's a short comparison to explain:

// C++ class
class Name : public OtherClass, public SomeInterface, public OtherInterface { /* contents */ };


// Java class
public class Name extends OtherClass implements SomeInterface, OtherInterface { /* contents */ }

// C# class
public class Name : OtherClass, SomeInterface, OtherInterface { /* contents */ }

It should be noted in the above example, that C++ trades the ease of control over class visibility for fine grained control over inheritance. AFAIK, Java/C# has no concept of private / protected / virtual {x} inheritance. Likewise C++ is multiple inheritance, while Java and C# are single inheritance. This all leads to a more verbose class syntax in C++. 

Now this one, is where you know how Java is run ;)

// C++ foreach, STL based
std::for_each(seq.end(), seq.begin(), func);

// C++ foreach, common technique
for (ClassName::iterator it = seq.begin(); it != seq.end(); ++it) /* contents */elementtype

// C++ foreach, to be added in the *future* standard (see below for disclaimer)
for (auto elem : seq) /* contents */

// Java foreach, <= 5.0
for (Iterator it = seq.iterator(); it.hasNext();) /* contents */

// Java foreach, >= 5.0
for (ElementType elem : seq) /* contents */

// C# foreach
for (var elem in seq) /* contents */

As you noticed, there's three different examples for C++. The first uses the for_each algorithm and leads to rather simple code; the second is the most common way; the third is being added in C++0x and I haven't bothered to read the details of it, since the version of GCC here doesn't support it.

C++ again gives very fine grained control here, the for_each algorithm and iterator methods are extremely useful once you learn how C++ really works. If you don't, than please don't program seriously in C++! The C++0x  syntax is +/- adding a foreach keyword, exactly what you would expect a foreach statement to look like, if C++ had one. Some things like Boost / Qt add a foreach macro that is mostly the same, but with a comma.

Java enhanced the for statement back in 2004, when Java 5 added a foreach like construct. Java hasn't changed much since then. When you compare the keyword happy syntax of Java to the punctuation happy syntax of C++, it becomes clear that Java's developers had decided doing it C++ style was worth more than adding any new keywords, like foreach and in. Guess they didn't think to steal perls foreach statement for ideas on how to naturally side step it.

C# on the other hand, uses the kind of foreach statement that a Java programmer would have 'expected', one that actually blends in with the language rather than sticking out like a haemorrhoid. I might take a moment to note, that javac can be so damn slow compared to C++/C# compilers, that the lack of type inference in Java is probably a good thing!

In terms of syntax, Java is like C among it's OO peers: it's about as small and minimalist a syntax as you can get without being useless. I wish I could say the same about Java in general. Some interesting parts of C#, include properties and the out and ref keywords. 

Here's a comparison of properties in Java and C#:

class Java {

    private PropType prop;

    public PropType getProp() {
        return this.prop;
    }

    public void setProp(PropType prop) {
        this.prop = prop;
    }

    public void sample() {
        PropType old = getProp();
        setProp(new PropType());
    }
}

class CSharp {

    public PropType prop { get; set; }

    public void sample() {
        PropType old = prop;
        prop = new PropType();
    }
}

C# has a very sexy way of doing getter/setter like methods for properties. Personally I prefer the more C++ like style of just having a public field, unless you need to hook it (with a getter) or use a private setter. I like how C# can make it look like a field, when it's actually a getter/setter method like construct. That means you don't have to remember which fields are accessed directly and which need member function calls when writing code. Java convention is getter/setter bloat; C# convention is to use properties for anything non-private. I hope C# 5.0 or 6.0 will replace { get; set; } with just add a property keyword alongside the access modifier.

C++ is just as lame as Java in doing getter/setter methods, except you can (ab)use the pre processor for creating such basic accessors as the above, as well as any similar methods you need but don't want to copy/paste+edit around. Java and C# always make you write your own, unless they are the basic kind. Tricks involving Java annotations and subclassing can kiss my hairy ass. It's also worth noting that some Java projects can use an insane amount of getter/setter code. Come on guys. Using an external tool is not the right solution.


When we compare the age of these languages: C++ => 27 years old; Java => 15 years old; C# => 9 years old. It becomes obvious that C# is the only one that doesn't suck at the concept of "Properties" and getter/setters in general. Perl made love constructs that respect the programmers time more than the compiler writers: you should too.

To anyone who wants to dare note that Java IDEs can often auto-generate getter/setters for you, and dares to call that better than language level support, I can only say this: you're a fucking moron. Go look up an Abraham Lincoln quote about silence. Now if someone wants to be constructive and create another Java example equal to the C# example in the above listing, I'll be happy to add it: rules must be shorter than existing Java example, uses: no subclassing, no beans, no external programs or libraries. Be sure to note what Java version it requies. Cheers.


The ref and out keywords in C#, are actually kind of oddities, if you come from another main stream language. In C it is not uncommon to pass a variable (perhaps more correctly a block of memory, if you think about it) to a function: and have the function modify the variables value instead of returning it.

    /* Common if not enjoyable idiom in C */
    if (!do_something("some", "params", pData) {
        /* handle failure */
   }
   /* use pData */

In this case, pData is a pointer to some data type, likely a structure, to be filled out by the do_something function. The point is, it's intended as a mutable parameter. In C/C++, it's trivial to do this for any data type because of how pointers work. Java passes by value just like C and C++ do: you can modify non-primitive types because a reference is used, not the 'actual' value. Making it more like a reference than a value type, in CS speak. C# does the same thing.

    // Java pass by value
    public void test() {
        int x=10;
        Java r = new Java();

        r.setProp(PropType.OldValue);
        mutate(x, r);
        // x = 10; r.prop = PropType.NewValue
    }

    public void mutate(int x, Java r) {
        x = 20;
        r.setProp(PropType.NewValue;
    }

Now a little fun with the self documenting ref keyword in C#:

    public void test() {
        int x = 10;
        var r = new CSharp;

        r.prop = PropType.OldValue;
        mutate(ref x, r);
        // x = 20; r = PropType.NewValue
    }

    public void mutate(ref int x, CSharp r) {
        x = 20;
        r.prop = PropType.NewValue;
    }

The out/ref keywords are similar, the difference has to do with assignment; RTFM. The important thing is that it is a compiler error to pass the data without the ref/out keywords at the call site.  I'm both enough of a Python and C++ programmer to enjoy that. This explicitness helps catch a few typos, and helps document that it's meant to be passed by reference, not value. That's good because a lot of programmers suck at documentation and some also blow at naming parameters. I think the contractual post/pre conditions in Spec# are a good thing: by removing writing the handlers form the programmer, and not having to make the programmer rewrite the flibbin' things in prose somewhere in the documentation. Not to mention the classic "Oops" just waiting to happen in less DbC oriented syntaxes. Hate to say it but the ref/out keywords presence in vanilla C# are likely due to Win32 API documentation conventions \o/.



Where C# really rocks is in the CLI. Java has something good going for it, over the past 15 years the Java Virtual Machine (JVM) has been heavily tuned for performance, Mono and Hotspot also present quite an interesting set of options (that .NET lacks afaik). I assume that Microsoft's implementation has also been battle tested for performance as well.

The thing of that is, the JVM was originally designed to run JAVA, first and foremost at the end of the day, that is what it had to do. The Common Language stuff on the other hand was intended to run several different languages. Although admittedly languages native to CLI tend to be similar, but so are most languages in general. The interoperability between CLI languages is wonderful, and at least in native .NET languages tends to be "Natural" enough. By contrast things crammed into JVM bytecode tend to become rather ugly IMHO, when it comes to interfacing with Java. I'm not sure if that's due to the JVM or the language implementations I've seen, the changes coming in Java 7 make me guess it's the former. The CLI is likely the next best thing to making a group of languages compile down to native code (for performance) and share some form of common ABI. Fat chance that will ever happen again. I'm sure I want to ponder about VMS, but the whole CLI thing tends to work quite nice in practice The performance cost is worth it for the reduction in headaches.



I'm sure that in terms of performance that Java mops the floor with Mono in some areas, because of how much hacking has gone into it making it a cash cow. That the C# compilers seems to run ring around the defacto standard Java compiler, is what really catches my interest performance wise. Using the mono 2.4.4 and Java 1.6.0_18 compilers, on my very modest system mcs processes a minimal program about 30% faster than javac. In real opeartion it tends to kick ass. When you consider that each compiler is also implemented in the target language, Java really gets blown away. O.K. maybe I care more about compile times than many people, it's the virtue of using an older machine :-P. Combine that with how many slow, buggy, monstrosities have been written in Java—I'll salute C# first.  Another plus is less "Our tools demand you do it THIS WAY" than what Sun threw at everyone. Piss on javac and company.


What has hurt C# in my opinion is the Microsoft connection. The thing with Novell doesn't help either. That Java is not exactly an insanely popular language among hackers, so much as enterprises, is another. The things that have hurt Java, being so closed and being academics choice for stupifying students.


What's the upside to using Java over C#? Easier access to Java libraries, (J2ME) mobile phones, and more finger exercise from all that needless typing! Beyond that it's essentially a win, win in favour of C#.

-1 for Java

Now this is just so damn funny (for me as a programmer), that it hurts!

Oracle's Java Company Change Breaks Eclipse


edit/postscript if you want to know why it does that, you should look at the first bug report, than RTFM and play Sherlock.

In looking closer at things, somehow I think that by cica GCC 5.0, either the GNU compiler will have imploded upon it's own weight :-o, or it will become an impressively powerful compiler, in place of an impressively portable one.

The feature set being grown, may even give old MSVCs optimization setup a good run for it's money someday, only the best tools with Visual C++ cost a few thousand dollars and GNUs is given away for free lol.

Me, I would just settle for a generally portable compiler that generates decent code, and complies with the bloody standards... So far I personally like pcc.

Days recap

Quite a full day, if not very productive :\


I was up to around 0500 last night, I dunno why but I never seem to get much sleep lately lol. The other day, I thought I was getting to bed early, and it was 0430'ish, well.. an hour early then the two days before I guess hahaha. Tried to sleep in today, since work didn't start until the afternoon --- not much luck. At least though, Tuesdays job is more time consuming then strenuous, tomorrows job on the other hand... Is more so a pain in the ass, then it is time consuming.


One thing odd, I heard Amanda kicked Adam out and that he's staying with his parents again. Not a good sign in my opinion. Especially since, as memory serves, in 2007 I've seen and heard of a lot more people getting divorced or dying. 2008, I had somewhat hopped would put that incremental stream of numbers to an end lol.



One of these days, I really ant to take some time to write up a review of Google Chrome --- I love that freaking thing!!! And whether the V8 JavaScript engine is really THAT fast or Google is taking advantage, gmail is so snappy on loading + the seperate process per tab thing, means no more browser-locks when launching gmail. Google Chrome is enough of an improvement over Firefox 2.x, that I might actually be able to re-take control of my inbox, if I ever get a linux binary package to use on my FreeBSD box... or better still, a native binary ;-). Perhaps it would be more fair to compare it to Firefox 3, but I use Flock 1.x most of the time, which is based on Firefox 2.x. And in all honesty, I hate Firefox 2 when compared to Firefox 1.0,x-1.5.x, it's just lost that feeling I guess... I just don't like the changes, and Firefox 3's alpha builds didn't look like an improvement. Although, I do have FF3 installed on SAL1600 just in case, but more so because it's a newer version.


Google Chrome, I think is perhaps the best thing since Lynx and HTTPS but who knows >_>



As far as my efforts to standardize myself around 1/2 languages + what we use on [SAS], has fallen back into deadlock. Every way I slice the pie, Python seems to be the best choice for all of my needs, hell... The only time I've had an interpreted language come out as to slow for jobs I've tried to use them on, is an oddity. A script had to invoke perl so many times to process text, that it was faster to invoke sed/awk instead, which could actually be considered interpreted languages I guess lol. Some of the things I've heard about Python 3000 alarm me in that regard, but I'm not very concerned. The real problem is, I prefer C, but I don't have *time* for C. When it comes to using C++ for tasks, I look at it as a two edge sword. More time savers then C but they all go out the window, in situations where they are not helpful.


That and working with gtkmm on Windows will probably be a pain in the royal hind quarters when it comes time to link against stuff. Although, I rather think a combination of Boost, Qt, and libs used in gnome is a good idea. The odd thing? C++ is not actually a language that I like a lot, but hey... beats Java I guess :\

Java would actually be a perfect tool for my needs, except I don't want to have to write in Java that much loooool.

Random thoughts

In the course of my web-surfing about, I found this interesting post by Joel Spolsky.

"The Perils of JavaSchools"


I've never been formally educated on a computing thing in my life :\. Having seen code by someone that was, whom I'd like to strangle... Some times I wonder if I should keep it that way >_>. I would still very much like to one day pursue a masters, an excuse to (hopefully) learn more then I can solo. But honestly, the odds of ever being free to do so are quite slim.


I still remember starting out in C++ for the first time, and having a problem handling the syntax for simple statements:

if (foo < bar)
    do_bar();

if (bar < foo) {
    do_foo();
    do_bar();
}

At the time, it was actually the most complex thing I'd ever had to learn. After figuring out that the curly brace was only required if there was more then one line, the rest was easy as pie. Once the simple logic was sorted out, I never had a problem like that learning another language.


But, that's why I've come to look on learning a language differently then learning to write programs. A language has a syntax, how do you express something in written form? Through the languages syntax. One of the things that I love about C, is that for better or worse. You can cram the entire language syntax into your head. It's really that small and light, that leaves a lot more room for working on a problem and not feeling: "Oh, I didn't know I could write it like that" later on.



Actually creating a workable program is a bit different, it's not a question of how you may write it (e.g. if (expr) { do; } or if expr: do), but how do you write it? One of the big joys of programming for me, is to sit back and try to figure out how to solve the problem. That's the fun thing (y).

My poor baby...

Installed Netbeans on my laptop to give it a test drive, and between top and the massive change in performance in flock, I can't help but think that my system is in pain as it fights with flock for system resources :\

last pid:  2235;  load averages:  2.04,  1.50,  1.00    up 0+01:08:22  03:52:09
86 processes:  4 running, 81 sleeping, 1 stopped
CPU: 83.8% user,  0.0% nice, 16.2% system,  0.0% interrupt,  0.0% idle
Mem: 298M Active, 18M Inact, 96M Wired, 12M Cache, 53M Buf, 1888K Free
Swap: 860M Total, 100M Used, 760M Free, 11% Inuse

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
 2195 Terry        30  44    0   387M   137M ucond    0:00 77.25% java
 1498 Terry         1  99    0   715M   139M RUN     25:43 13.87% flock-bin
 1358 root          1  44    0   119M 63776K select   1:56  0.00% Xorg
 1403 Terry         1  45    0 18616K  4796K select   0:51  0.00% gkrellm
 1504 Terry         1   0    0   715M   139M linuxf   0:19  0.00% flock-bin
 1500 Terry         1   0    0   715M   139M linuxf   0:04  0.00% flock-bin
 1499 Terry         1  44    0   715M   139M select   0:03  0.00% flock-bin
 1477 Terry         1  44    0 30940K  6832K select   0:03  0.00% Terminal
 1887 Terry         1  44    0 34752K  8020K select   0:02  0.00% xchat
 1174 root          1  44    0  3264K   564K select   0:02  0.00% moused
 1404 Terry         1  44    0 45900K  2944K select   0:01  0.00% pidgin
 1402 Terry         1  44    0 14280K  2256K select   0:00  0.00% fbpanel
 1509 Terry         1   0    0   715M   139M linuxf   0:00  0.00% flock-bin
 1405 Terry         1  44    0  9080K  1340K select   0:00  0.00% blackbox
 1515 Terry         1   0    0   715M   139M linuxf   0:00  0.00% flock-bin
 1481 Terry         1  20    0  4640K     0K pause    0:00  0.00% 
 1399 Terry         1  44    0  8172K   724K select   0:00  0.00% bbkeys

The fact that I've got flash7 running in one tab and only a small set of 5 tabs open in flock, ain't that bad I guess. It seems that my system has almost adapted to this load, because the stats in top have gotten even worse but FreeBSD has gotten almost as responsive as normal when running these programs.



I love my darlin' Dixie ;-)

Todo: Toolkit and Library madness

Examine for portability the following toolkits under these OSes: Windows NT, Mac OSX*, Unix-like.

*I sadly don't have a Mac, although I would really love one. So a OSX binary of some form will have to pass.



GTK+ -- C, C++, Perl, Python, Ruby, PHP, C#.NET (Java bindings also avail but seem to be gnome-centric)

Qt4 -- C++, Perl, Python, Ruby, Java (C#.NET and PHP bindings seem to be questionable and only C++/Python and possibly Java bindings can be depended on).

WxWidgets -- C++, Perl, Python, Ruby, Java, C#.NET

Swing and SWT would be considered if they were available under more languages !!!


Evaluate portable standard/add-on libraries to each language for the following capabilities:


String handling (they all do well in the language standard)
Regular Expressions (Only Perl and Ruby get this great imho)
XML Processing
Network programming -- both sockets based API and protocol support (IMAP, POP, HTTP/S, FTP)
Database handling -- must support MySQL, SQLite, and some form of flat file.
Basic compression and archive format support (e.g. tar; zip; gz; bz2; lzma)\
Inter-Process Communication (IPC) methods and related process control (e.g. fork(), exec(), signal(), kill() type routine-families).
Ease of use and deployment



Goals:

Build up a standard frame work of toolkits/libraries/etc that are portable across both my general operating environment and the various languages I use

Attempt to standardize myself on few languages rather then rubber banding between various programming languages + sh/awk/sed/friends

Ensure full development environments are available to me under FreeBSD 7 and Windows NT 5.1 (e.g. I can code from either machine and not change tools)

At least one language for scripting/prototyping and one for more efficient execution when implemented in that language (e.g. 1 interpreted + 1 compiled)




and try to stay sane along the way without writing a few libraries in the process >_>

Something that has been on my mind of late

DRAFT POST

I very much need to start standardizing myself on a smaller set of tools. Maybe tools is not the best choice of ord, o much as it is a question of languages and libraries. It's actually kind of ironic, I really would like to learn several more languages (Ada, Fortran, C#, Erlang, and I never did wrap my head around Scheme).


C++

Pro's:

can do low level stuff

can interface well with C code and libraries

Qt is natively C++ and supports everything I need it to run on (in Qt4 OSE hehe)

Fairly portable and standardized (at least much of the 1998 standard...) with several compilers available.

Mainly toolkits and frame works available, both native and from C.


Widely used and my first language


Con's:

having to dig into lower level interfaces is very error prone when doing it with a headache the size of California.


Often not my first choice for building a prototype *quickly* but good for final implementation.


Java

Pro's:

Inheritable portable between JVMs of the same implementation (e.g. Sun JVM for Win and Sun VM for Mac can run same code).


Simpler OOP syntax then C++, imho

The Swing GUI toolkit is fairly portable and SWT sufficiently supports the platforms I want to avoid skipping.

I like the way it handles exceptions, and usually like checked exceptions -- when a class is designed appropriately.


It's well defined if not perfectly standardized and compliant implementations are fairly common enough (Sun's)

Wildly used and my third language.

Well documented (if a bit boring)


Con's:


Everything is OOP....

I prefer native code to waiting on java to load

Requires a suitable runtime


Conventions expected by some tools can occasionally be irksome (to me)


C# (C Sharp)

Pro's:

It's not Java

It's similar to Java/C++

Core elements are standardized

Less resistance to shooting oneself in the foot / doing stupid things then Java but not as much as C++.


Gtk#, the binding of GTK+ to C# is available on the platforms I care about.

Con's:

Most C# applications are probably tied to Microsoft Windows implementation via .NET or through Gnome related interfaces

Requires a runtime (e.g. .NET, Mono, or Dot GNU)

Requires just enough learning of it's differences from Java, for me to use it.


PHP5

Pro's:


Portable and interpreted


Widely used across the WWW for server side scripting.


GTK+ bindings to PHP available and portable'ish


Simple language and member of the CBF.


The OOP increasingly resembles Java syntax and is just "enough" syntax to be useful without cramming.

Well documented

Con's:

Local php.ini files can cause problems (how much can you assume?)

Needs a run time (php) of the right version (5)

php4/php5 is less common off web servers or developers systems



Python

Pro's:


Great for writing prototypes

Several toolkits available that are fairly portable

Easy to work with and quit portable (and issues of portability well noted in the docs)

Large standard library

Implementations for the Java Virtual Machine and Microsoft .NET framework are available (if not as current as CPython) as well as the standard (C)Python implementation.

Con's:

Requires a run time

I *hate* it's handling of regular expressions after being so used to Perl...

It's slower then native code

Interfacing with C /or C++ code can, uhh... Get interesting, from a portability perspective.

The program is the source


Ruby

Pro's:

Handy pure OOP language

Great handling of regular expressions within the language itself, as opposed through importing an object oriented interface (i.e. as in Python/Java/C++)

Usually very "comfortable" to write.

Large standard library

Con's:

It requires a run time and alternative compilers (e.g. xruby, ironpython) may be lacking in reliability or cause some features to be unavailable

The program is the source

Wishing Ruby 2 would come sooner....

Documentation can be irksome at times

It's slower then native code and even slower then Python (Ruby 1.8.x)

JavaSwing.strange()

This is very funky. I downloaded a tutorial file from sun for Java's Swing toolkit and it compiles fine but can't find the main thread when compiled & run as directed.

I comment out the 'package start;' at the top, recompile and it runs fine >_>


To be honest, I think I'm sort of happy I've never written a lot of Java code... Especially because most encounters whereByPeopleWhoHaveTypeNames andVarNamesThisLong which kind of pisses me off lol.


I do have Qt Jambi installed on my desktop but the problem is family really makes it easier to write code off my laptop, since I get get further away from the line of fire... Which means without a fair bit of tinkering, it'll be easier to write the GUI in Javas Swing.


I did learn a little of AWT way back when but I doubt any of it is still good by now lol.

Brushing up with Java

It's been quite an interest of mine to brush up with Java and Perl for awhile now but time has never really allowed me to do so.


Java for me is a language to which a lot of knowledge is stored away in the ol'brain but little wisdom so to speak. Java was maybe my 3rd language but I've also done a pretty good job of writing almost no Java code over the years hehe. I'm used to the syntax though. One day the Library had a sale of old books and one was the Java Sourcebook by Ed Anuff.

This was maybe 2006 and the book was so old that some where in the interface I think it said that JDK 1.0 Beta would be released by the time people were buying the book. Until more recent aspects involving Python and C++ with Qt3 / Qt4 its introduction (unwritten) to Javas Abstract Window Toolkit (AWT) was the closest I ever got to GUI work.


It is a very good book IMHO but of course very dated, I don't know how much java.lang.applet and whatnot has changed over the years, I never really cared much for Java applets! But I am pretty sure that a lot is different with AWT and the newer Swing toolkit. One thing that I actually find interesting, the Java Sourcebook is maybe the only book I've seen that uses the same brace style I tend to use in C. Hmm, maybe it was an influence on my ways of doing things :\


Not to long ago I checked out a nice O'Reilly book on Java because I wanted to see how much the language had changed in the past ten years or so. Java indeed changed quite a lot, it is way more fatter then I remember but it is still just as sweet.


One thing I like about C, the syntax is small enough to cram in ones head easy and follow it up with a reference of the standard library for stuff you don't use often. Java OTOH is probably a few orders of magnitude larger then that for most people. With the things I noted, inner classes, generics, etc I was a little suprised that they were there but the language seems to have grown naturally. As I read though parts of the book I was constantly like "Oh, that works just like I expected" when comparing the detailed explanations of how things work along side the code listings.


C++ was my first language aye but I think I'm more comfortable with Java. Because in the fields where C++ differs from C, I tend to get a little more lost, while with Java most of it is already there.


Perl, my second language but probably the weakest in my skill set. I quickly got board and skipped a lot which gradually filtered through over the years. I respect Perl for its power and flexibility but I think it has gotten a little to big for its own good IMHO, although I wait to see what Perl 6 will bring us.


I remember in the Java Sourcebook there were several examples, such as an implementation for Lamp and LightBulb classes that interacted and various cat related ones that used a speak() method to examine how overloading methods and inheritance worked.

This is a reworking of it from memory, same basic idea though:


Jeez now that I think of it, those examples remind me of stuff from an UnrealScript tutorial I looked at a couple years back too. Who knows with how much UnrealScript feels like a customized Java they probably read the same book hehe.

/**
 * Feline.java, abstract representation of felines
 */
abstract class Feline {
    abstract void speak();
}


/**
 * HouseCat.java, implements a feline that meows
 */
class HouseCat extends Feline {
    HouseCat() {
    }
    HouseCat(String call) {
        this.speak(call);
    }
    void
    speak() {
        System.out.println("Meeeooowww!!!");
    }
    private void
    speak(String call) {
        System.out.println(call);
    }
    public static void
    main(String[] args) {
        HouseCat theCat,newCat;
        theCat = new HouseCat();    /* use default constructor */
        newCat = new HouseCat("I am a cat!");

        theCat.speak();
    }
}

The HouseCat class implements a Feline (abstract meaning you can subclass it but you can't create it directly). There is a simple constructor made to behave like a default constructor and one that invokes a private version of the speak() method using a supplied string.


I have the Java Development Kit and Run Time Environment installed from the packages on the FreeBSD Foundation website. Compiles fine with javac and gcj42, that is the GNU Compiler for Java ;-).


What I do like about Java, its fairly portable between systems running the same implementation (e.g. Suns JRE) as far as language features go. It also follows a largely logical behavior for many things from what I have seen.


And to top it all off, GCJ can compile to native machine code rather then Java Bytecode -- for me a huge plus. I do have Qt4 bindings for Java installed on my desktop so I am interested to see where that goes, as far as my laptop is concerned I would probably need to use Suns compiler for AWT/Swing apps though. Not sure if Qt Jambi is in FreeBSD ports yet either.


As much as I love C, there are just some things that I don't really want to have to implement in it. And as productive as I am in Python and Ruby I really need to cuddle up with some thing a bit closer to C's end of the spectrum. I don't really care a lot for C++, I can use it fine but don't see much point for it over C besides templates and exceptions. Java lacks pointers in the same light as C/C++ uses but the references should be fine enough for my general needs.

C++ is multiple inheritance and Java is single, I'm not really partial to either concept as long as nether takes to biting me often. I have long enjoyed the design of Java's classes and interfaces though, I love the interface thing in Java.


I don't exactly care much for Suns compiler though but hey, if it works (y).

Wasting time with the Euclidean Algorithm

The other night, I was very bored so... When I remembered reading about the Euclidean Algorithm on Wikipedia, which is a method of finding the greatest common denominator (gcd). I fed several implementations through ye ol'time(1) to get a rough idea of what differences they made.

At first I did it in Ruby and C for comparison, then I recompiled the *.c files with maximum optimization. Tonight I added a set of Java and Python files to the setup, I'll probably include Bourne Shell and Perl later for fun.


For any one interested,

C // no optimization
./iteration 0.00s user 0.00s system 50% cpu 0.003 total
./recursion 0.00s user 0.00s system 66% cpu 0.002 total
./original 0.00s user 0.00s system 57% cpu 0.003 total
Ruby
./iteration.rb 0.01s user 0.00s system 59% cpu 0.014 total
./recursion.rb 0.00s user 0.00s system 79% cpu 0.010 total
./original.rb 0.00s user 0.01s system 75% cpu 0.010 total
C // optimized, -O3
./iteration-o 0.00s user 0.00s system 48% cpu 0.003 total
./recursion-o 0.00s user 0.00s system 32% cpu 0.005 total
./original-o 0.00s user 0.00s system 37% cpu 0.004 total
Java
java EuclideanIteration 0.39s user 0.38s system 66% cpu 1.165 total
java EuclideanRecursion 0.48s user 0.30s system 72% cpu 1.066 total
java EuclideanOriginal 0.36s user 0.42s system 67% cpu 1.155 total
Python
./iteration.py 0.01s user 0.01s system 59% cpu 0.034 total
./recursion.py 0.01s user 0.01s system 65% cpu 0.032 total
./original.py 0.01s user 0.01s system 65% cpu 0.031 total

done with:

ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-freebsd6]
gcc version 3.4.6 [FreeBSD] 20060305
javac 1.5.0
Python 2.5.1

The C versions were the same sources but compiled with -O3 for the optimized
version.

I've assigned each outcome a score, 3 for what I feel is fastest, 2 for the intermediate (often close) and 1 for the worst and totalled it:

method  C RB C(-O3) Java Python Total
iteration 2 1 3 2 2 10
recursion 3 2 2 1 1 9
original 1 3 1 3 3 11

And the code, which I tried to keep similar. Also the gcd()/mygcd() routines were always implemented as a function because of the recursive version in the tests.

#include <stdio.h>

#define A 1071
#define B 1029

int
mygcd( int a, int b ) {
 int t = 0;
 while ( b != 0 ) {
  t = b;
  b = a % b;
  a = t;
 }
 return a;
}

int
main(void) {
 mygcd(A, B);
 return 0;
}


#include <stdio.h>

#define A 1071
#define B 1029

int
mygcd( int a, int b ) {
 if ( b == 0 ) {
  return a;
 } else {
  return mygcd( b, a%b );
 }
}

int
main(void) {
 mygcd(A, B);
 return 0;
}


#include <stdio.h>
#define A 1071
#define B 1029


int
mygcd( int a, int b ) {
 while ( b != 0 ) {
  if ( a > b ) {
   a = a-b;
  } else {
   b = b-a;
  }
 }
  return a;
}

int
main(void) {
 mygcd(A, B);
 return 0;
}

#!/usr/local/bin/ruby -w

def gcd(a, b)
  while b != 0
    t = b
    b = a % b
    a = t
  end
  return a

gcd( 1071, 1029 )
#!/usr/local/bin/ruby -w

def gcd(a,b)
  if b == 0
    return a
  else
    return gcd(b, a % b )
  end
end

gcd( 1071, 1029 )
#!/usr/local/bin/ruby -w

def gcd( a, b )
  while b != 0
    if a > b
      a = a - b
    else
      b = b - a
    end
  end
  return a
end

gcd( 1071, 1029 )

class EuclideanIteration {
 static final int A = 1071;
 static final int B = 1029;

 public static int
 mygcd( int a, int b ) {
  int t = 0;
  while ( b != 0 ) {
   t = b;
   b = a % b;
   a = t;
  }
  return a;
 }

 public static void
 main( String[] args ) {
  mygcd(A, B);
 }
}



class EuclideanRecursion {
 static final int A = 1071;
 static final int B = 1029;

 public static int
 mygcd( int a, int b ) {
  if ( b == 0 ) {
   return a;
  } else {
   return mygcd( b, a%b );
  }
 }


 public static void
 main( String[] args ) {
  mygcd(A, B);
 }
}


class EuclideanOriginal {
 static final int A = 1071;
 static final int B = 1029;

 public static int
 mygcd( int a, int b ) {
  while ( b != 0 ) {
   if ( a > b ) {
    a = a-b;
   } else {
    b = b-a;
   }
  }
   return a;
 }


 public static void
 main( String[] args ) {
  mygcd(A, B);
 }
}

#!/usr/local/bin/python

def mygcd(a, b):
    while b != 0:
        t = b
        b = a % b
        a = t
    return a


mygcd( 1071, 1029 )
#!/usr/local/bin/python

def mygcd( a, b ):
    if b == 0:
        return a
    else:
        return mygcd( b, a %b )


mygcd( 1071, 1029 )
#!/usr/local/bin/python

def mygcd( a, b ):
    while b != 0:
        if a > b:
            a = a-b
        else:
            b = b-a
    return a


mygcd( 1071, 1029 )

FreeBSD + Java?

How easy is it...


The JDK and JRE packages on the FreeBSD Foundation require the following to install and run correctly:

inputproto-1.4.2.1, javavmwrapper-2.3, kbproto-1.0.3, libICE-1.0.4,1, libSM-1.0.3,1, libX11-1.1.3,1, libXau-1.0.3_2, libXdmcp-1.0.2, libXext-1.0.3,1, libXi-1.1.3,1, libXp-1.0.0,1, libXt-1.0.5, libXtst-1.0.3, pkg-config-0.22, printproto-1.0.3, recordproto-1.13.2, xextproto-7.0.2, xproto-7.0.10_1, xtrans-1.0.4


If you run a Desktop based system with Xorg installed most of these are probably already there, on my laptop which has KDE 3.5.7 for the GUI all I had to do was install one package first:

pkg_add -r javavmwrapper

If you don't have a required package it will tell you what you need to install when you try to pkg_add Java. Most probably can be pkg_add -r'd unless you want to the ports.


I then went over to the FreeBSD Foundation website to download Java


If you only want to run Java programs, you will need the JRE (Java Runetime Environment) but if you wish to develop Java programs you'll require the JDK (Java Development Kit).


The packages currently are for FreeBSD 5.5/i386 and FreeBSD 6.1/i386 and amd64. Just download the one that matches your FreeBSD major branch and CPU Architecture. I fetched both JRE and JDK for FreeBSD 6.1/i386 which is about a 70MB download combined, my Laptop runs PC-BSD v1.4 so the underlaying system is FreeBSD 6.2-Stable, no problems so far.


You need to accept the license agreement to download and when you pkg_add, just scroll to the bottom and type 'yes' and press enter, you can probably use the shift+g command to jump to the bottom of the license.


I think because of the terms that the JRE/JDK were licensed for distro we've got to live with the manual download. Once you've got your packages downloaded, just do a :


pkg_add ./diablo-jdk-freebsd6.i386.1.5.0.07.01.tbz


of course replacing ./ with the path (if necessary) and the filename with the proper one. Tip: If you don't want to typo it, use tab completion in your shell. I usually just download things to /tmp and cd over to it. You also need to be root in order to run pkg_add with any possibility of success. Depending on ones shell a 'rehash' command might also be needed before the programs can be found in the command prompt.


which tells me that java and javac are working, and it passed the test of compiling a small test program and running it.