Installing the latest PicoLisp on Ubuntu

While testing out The Quiet Learner‘s game, Dr. Theobold, a text based adventure game written in picolisp, I ran into several issues. As discussed previously, I added these issues to the bug tracker on Savannah. Come to find out, the distributed packages for Ubuntu are using version of picolisp, and The Quiet Learner wrote his program for version 16+. We needed to find out if the old version was the culprit, or if there truly were issues in the game.

So, I updated to version 17.7.6 (a rather interesting numbering, since I tried this the 4th of July week, but that is something else entirely).

As simple as the above statement was, my trek was not quite as simple. I am used to compiling programs. Typically, you start by unzipping the source, using ./configure, then make, and sudo make install. However, this was different.

Of course, I downloaded the source from the link in the PicoLisp Wiki. After that, I unzipped it with the standard

$ tar -xzvf ./picoLisp.tgz

and moved into the new director with

$ cd picoLisp

Once there my usual bag of tricks didn’t work, which is why it is always good to read the instructions. Ends up that I needed to cd into the src64 directory and run make. No ./configure first.

$ cd src64

$ make

And there was no option to make install. Instead I had to manually symbolically link the files, and that is where everything went wrong. You see, the INSTALL file had pre-typed instructions with all 3 links you could use, like so:

# ln -s /<installdir> /usr/lib/picolisp
# ln -s /usr/lib/picolisp/bin/picolisp /usr/bin
# ln -s /usr/lib/picolisp/bin/pil /usr/bin

But after doing that, it didn’t work. It didn’t work because I forgot that the directory was picoLisp, not picolisp. I chased my tail for a while, re-creating the same bad links over and over again until I realized my mistake. Since /<installdir> was not the directory (obviously) I was hand typing picolisp, and it wasn’t working. So, be smart and not like me. Do as I now say, not as I erroneously did!

After straightening it out, it worked great! Actually it cleared up 3 of the issues that I put on the tracker for the Dr. Theobold game. I guess it pays to have the latest and the greatest when it comes to PicoLisp!

Linux – keep it simple.

MechDome reaches out to open source app developers

MechDome, the new way to convert your Android application into an iOS app. While still somewhat in development, MechDome has been making great strides in the field of app converters. The best part is that MechDome doesn’t use your app source code, it uses your completed Android apk file to churn out a completed iOS application!

If you are interested in knowing more about the process involved in converting your Android app into an iOS one, you should read my previous article, where I gave it a go. I have to admit, it worked out rather nicely! I’ve converted two applications on their website, and so far, both worked great in the simulator!

Yesterday, MechDome sent out a newsletter informing everyone that they are starting an open source developer program! As an open source developer, I get really excited when I see companies supporting open source work. If you read my previous article, you can see where I made a few suggestions to MechDome in regards to open source development. Here’s a quote from that article:

  • Ideal: Give users the opportunity to create an open source developer account that can convert a limited number of open source apps per month, such as two or three, for free. No subscription costs, and if the account stays active, then it will not expire.

  • Less than ideal, but still helpful: Give users who already have paid subscriptions the ability to convert open source applications without counting against their monthly quota or subscription.

  • A one time setup cost: Another option might be a one time cost, rather than a subscription, for an open source account. E.g., a $25 setup fee for open source users to set up a developer account.

Based on their letter, it looks like they chose a slightly different direction, or perhaps a “modified” version of my third option. They decided on a flat fee of $25 to allow you to convert one open source app.


I think that MechDome is on the right track. I do appreciate how they are reaching out to open source developers, and although a one time fee per app of $25 isn’t free, it isn’t ridiculous, either. I could see how larger, community driven projects, or ones that accept donations might be able to foot the bill for app conversion, it just is not as convenient for small timers like me. I guess we will just have to wait and see.

Linux – keep it simple.

libGDX music and sound fail….

While finishing my Android app developer course, I ran into this error during game development:


——— beginning of crash
06-09 13:01:19.410 30345-30366/? E/AndroidRuntime: FATAL EXCEPTION: GLThread 758
Process: com.alaskalinuxuser.criticalvelocity, PID: 30345
com.badlogic.gdx.utils.GdxRuntimeException: Error loading audio file: data/spblk.mp3
Note: Internal audio files must be placed in the assets directory.
at com.alaskalinuxuser.criticalvelocity.criticalvelocity.create(
at android.opengl.GLSurfaceView$GLThread.guardedRun(
at android.opengl.GLSurfaceView$
Caused by: data/spblk.mp3
at android.content.res.AssetManager.openAssetFd(Native Method)
at android.content.res.AssetManager.openFd(
at com.alaskalinuxuser.criticalvelocity.criticalvelocity.create(
at android.opengl.GLSurfaceView$GLThread.guardedRun(
at android.opengl.GLSurfaceView$


It took a long time to figure out the issue, so I thought I would try to save someone else the trouble.

It hinges on this line from the libGDX wiki example:

Music music =“data/mymusic.mp3”));

Which my line looked like this:

bgMusic =“data/spblk.mp3”));

Should work right? But it didn’t. I had to change my line to this to make it work:

bgMusic =“spblk.mp3”));

And put the mp3 file in the “assets” folder.

Hopefully, this will save someone else a really long, frustrating search!

Linux – keep it simple.

Signing and installing your MechDome converted app on a simulated iPhone

In our last post, I talked about a really neat website: MechDome, which automatically converts your Android app into an iPhone application. If you haven’t read that article, I suggest you do to learn more about MechDome, which I think is going to be very big for Android developers in general. At the end of our last post, we had downloaded our converted app and run it in an iPhone simulator on our virtual Apple computer. In that post, though, I skipped all of the details of how we do that, and I would like to take a look at that question now.

So, get your Apple fired up (online, virtual, physical, etc.) and download your converted app from MechDome!

Now that you have your app downloaded, go ahead and launch Xcode. If you don’t have Xcode, it can be installed from the iStore. Once Xcode is open, go ahead and edit your preferences.

Xcode –> Preferences –> Accounts

If this is the first time you’ve been here, like it was for me, then it will be blank. press the “+” sign at the bottom and add your Apple ID account.

Once your Apple ID is added, you can now select it, and click on “View Details”. In the resulting popup, click “Create” for iOS developement. This will create the certificate you need for “signing” your test apps on your local simulator. There is not much to tell you how it went, but if the button to create disappears, it worked, so click “done”.

Now you are ready to launch the simulator. There is probably a better way to do this, but here is the simplest methode I found. Since you have Xcode open, go ahead and launch a new project. It will load fairly quickly with a default empty project. Now, press the play button at the top of the screen, which will automatically launch the simulator, boot the iPhone, and launch your empty app project.

Once that is open, you are litterally done with Xcode, so you can quite or close it, and the simulated iPhone will stay open.

Click on the iPhone window, and from the top menu, select Hardware –> Home to get back to the iPhone home screen.

Now open your OSX terminal. You can open it from the launcher by typing term and clicking on the terminal icon.

In your terminal, navigate to the downloaded zip file. For me, it was in “Downloads” and looked like an “app” but it was a directory.

$ cd Downloads

$ ls


Now, find your new certificate (key) to sign the app with:

$ security find-identity -p codesigning -v login.keychain

And set the default keychain:

$ security default-keychain -s login.keychain

And sign your “app”:

$ codesign -vfs “NAMEOFCERT: APPLEID@EMAIL (MOREALPHANUMERIC)” –keychain login.keychain ./

Now that it is signed, you can install it into the already running iPhone simulator with the following:

$ xcrun simctl install booted

You should see it show up on your iPhone home screen, but it may be on one of the other screens, so swipe left and right to find it. Once you found it, go ahead and click on it to launch the app! There you go! Barring any other issues, it should work as expected.


Apple – er, uh, wait! Linux – keep it simple!


Getting photos with intents on Android

During my class for app development, the instructor showed us how to get a photo from the phone’s gallery with intents. I wanted to take that one step farther, so I did. I also added getting a photo from the camera. To keep things small, I set the camera still to be returned as a thumbnail view, per the android instructions here:

Here is what I have:


package com.example.alaskalinuxuser.photohowto;

import android.content.Intent;
import android.provider.MediaStore;
import android.os.Bundle;
import android.view.View;
import android.widget.ImageView;

public class MainActivity extends AppCompatActivity {

    // Define our image view.
    ImageView myImage;

    @Override // On create, do this....
    protected void onCreate(Bundle savedInstanceState) {

        // Declare our image view.
        myImage = (ImageView)findViewById(;


    // If they click to choose a picture from the gallery....
    public void choosePic (View picView) {

        // Call the intent for the gallery.
        Intent i = new Intent(Intent.ACTION_PICK, MediaStore.Images.Media.EXTERNAL_CONTENT_URI);
        // And start that intent for the result number 1.
        startActivityForResult(i, 1);


    // If they click to take a picture button....
    public void takePic (View takeView) {

        // Call the intent for the camera.
        Intent takePictureIntent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);
        // And start that intent for the result number 2.
        if (takePictureIntent.resolveActivity(getPackageManager()) != null) {
            startActivityForResult(takePictureIntent, 2);


    @Override // Listen for the results from intents.
    protected void onActivityResult(int requestCode, int resultCode, Intent data) {
        super.onActivityResult(requestCode, resultCode, data);

        // If it is result number 1, and it was ok, and they chose something, then...
        if (requestCode == 1 && resultCode == RESULT_OK && data != null) {

            // Get the uri.
            Uri myChosenImage = data.getData();

            // Try in case it fails.
            try {

                // Make a bitmap from the uri.
                Bitmap myBitmap = MediaStore.Images.Media.getBitmap(this.getContentResolver(), myChosenImage);

                // Set our chosen image to the view.

                // Give a catch in case there is a problem.
            } catch (IOException e) {

            // But if it is result number 2, and it is okay, and there is data, then....
        } else if (requestCode == 2 && resultCode == RESULT_OK && data != null) {

            try { // In case it fails.

                // Get the extras (a small thumbnail in this case).
                Bundle extras = data.getExtras();
                // Set our bitmap to that extra.
                Bitmap camImage = (Bitmap) extras.get("data");
                // Set our image with that bitmap.
                // A catch in case it fails.
            } catch (Exception e) {





Pretty neat, huh? You can check this out on my GitHub under the small apps repository.

Linux – keep it simple.

AIDE: Building Android apps on your phone!

After spending a little bit of time with my Android Studio app development course, it occurred to me that there must be a way to build Android apps on your Android phone. Five minutes on Google gave me more choices then I could shake a stick at! So, I tried a few out and came to this conclusion: at this time AIDE is my favorite.

I like to hope that I make educated decisions, and below are my reasonings.

1. It is free. Well, there are in app purchases for more learning tools and perhaps more features, but for my basic skill level, it can do everything I need whilst being free.

2. I can load my Android Studio projects and run them. That’s right, I can save my files from my laptop and pick up right where I left off on my phone. While Android Studio does have a built in emulator, this takes it to a whole new level when you can hold your homemade app in your hands and really see how it feels.

3. Github integration. Do you want to fork a github project? Or need to download an open source app on github for a base? Perhaps your own app is on github, and you use that as a way to sync between your desktop and phone. Either way, it is great to punch in an URL, and start working on that app’s code!

4. A built in teaching program. Granted, the built in program does not compare with a Rob Percival course, but the free portion was fun, short, and interactive. I did not try the longer paid portion, as I am keeping my hobbies on a budget, but if it is as interactive as the free portion, then it will likely be a help to new comers like myself.

5. A simple user interface. The interface is very simple and to the point. That is nice these days, with so many “overcrowded” apps. The focus is on content, and there are all the basic tools, a design view, code view, file manager of sorts, etc.

If you are into dabbling with Android apps as a fellow nonprofessional like me, I recommend giving AIDE a try.

Linux – keep it simple.

Setting up Android Studio on a Debian Jessie HP Compaq 6715b AMD Turion X2 Processor

Setting up Android Studio on a HP Compaq 6715b AMD Turion X2 processor was far from simple. I followed numerous guides online, read dozens of articles on Stack Overflow, and yet, I was still stuck. Until I finally got it going (Praise God!). So, what made it so difficult? Well, let me tell you:

It all started when I bought a technical book from Amazon for kindle. Somehow, that book got me a reference to a course on Udemy called “The Complete Android Developer Course” By Rob Percival. Normally, the course was $200 plus, but for some reason it was on sale for a mere $17! The course said that it was designed for what I call “zero to hero” students, or those who knew little to nothing about the subject to train them to know enough to be dangerous, er, uh, useful. Needless to say, I purchased the online course.

In the course, which is a bit older now, Rob is using Android Studio 1.1 and suggests that students could use newer versions, but that they could also use AS 1.1 if they want everything to look and act the exact same way as in the course material. So, I downloaded AS 1.1. There were so many problems getting that to run, that I will not even discuss those here, for fear of nightmarish flashbacks.

So, I downloaded the latest version for Linux, 2.2. It launched first try. I followed instructions from a blog here:

Which worked to get Android Studio to start. However, after following along through the course, it was time to launch my first app, which did not launch. Instead I received the following error:

libGL error: unable to load driver:
libGL error: failed to load driver: swrast
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 155 (GLX)
Minor opcode of failed request: 24 (X_GLXCreateNewContext)
Value in failed request: 0x0
Serial number of failed request: 38
Current serial number in output stream: 39

This lead me on a painful search, from which I would like to save you similar users from doing and afflicting yourselves with. Here was what I did in the end:

I thought that for my model/make of processor, I could not use the x86 version of the emulator, so, when I set up a new device, or create a new virtual device, I needed to click on the “other” tab and choose an arm variant. This did not solve the issue, the same error happened when trying to launch my app.

Then I realized that I needed to install more dependencies. I used aptitude search and found that I also needed to install these:

[CODE]$ sudo apt-get install libgl1-mesa-swrast-dev libgl1-mesa-dev -y [/CODE]

Then, when I pressed launch, the android phone would appear, but it stayed blank. Finally, I found taht I had a graphics issue, which I could resolve by creating a new virtual device, and choosing “advanced features”. In those features is the option to use software graphics instead of hardware graphics. After selecting that, launching my app made the phone appear, AND it began to boot.

Now I can boot using the arm version or the x86 version. However, in the arm version, it is so slow that it is practically unusable. In the x86 version, it is also very slow, but usable, and I receive these errors:

WARNING: The Mesa software renderer is deprecated. Use Swiftshader (-gpu swiftshader) for software rendering.
emulator: WARNING: Host CPU is missing the following feature(s) required for x86 emulation: SSSE3
Hardware-accelerated emulation may not work properly!

The first start up took a while, but now, when I make changes to my app, from pressing launch to actually seeing my app on screen takes 2:27 (m:ss), which is a bit slow, but reasonable on an older laptop. Hopefully, this will help others trying to use Android Studio on older laptops running Debian 8 with a Turion X2 processor.

Linux – keep it simple.