Facebook Free

For those wondering where my Facebook presence is, it isn't anymore.

I don't know how people don't go crazy with all the stuff that comes through their feed. Self indulgent whining, lousy humor, politics, game requests, etc. etc. etc. Maybe its the general political times right now (call it economy if you prefer that word) For me it wasn't all that productive. So I left.

I do have a Google Plus presence, but that one is still working on making their own groove, and don't check in all that much, though I hold hope that it becomes something more worthwhile.

The one that fits me sees to be Tumblr lot less whining, no games and much more tagging and sharing of ideas, things and concepts (check out my follows to see what I mean. If you haven't tried it (and maybe are tiring of Facebook friendship overload) check it out and see if you like it. See something you like, most peoples pages you can click on it and see who else re-blogged it and check out their blog, when you find someone who is interesting you follow them, etc. Don't lie their stuff, don't follow - no harm.

So far I'm finding the positive/creative community I've been wanting from Facebook.. Though there seems to be a lack of Classic computing stuff (in English) will need to help contribute to that community - maybe I'll see you there. :-)


2012/04/06 23:16 · 0 Linkbacks

One CommVEx Peeve

Of all the things about CommVEx I have one “PET” peeve (well pet peeve, but couldn't stop thinking about the Commodore PET) that has bugged me (and from mutterings, a couple other folks share in the frustration). It is the doorprize program. I love the idea that the program is ran on the Commodore, I like that the computer randomly chooses… but.. I've noticed (like most random programs) it favors the center of the distribution and also can pick the same person twice… (unless you keep the program running… which isn't feasible).

So one of my self-inflicted projects is to make a 21st century doorprize drawing program for the 64.


Well that's the working name. This is about version .7 as not all the features or interface has been implemented, but enough where it could be put to work right now.

Let me go over the features so far:

  • You enter real names of the eligible participants
  • The program will not draw a name twice until either all the names have been previously chosen or the draw eligibilty tracking has been reset.
  • When you draw a name of someone not present, there is an option to draw another without consequence (so they are still eligible for next time)
  • When a prize is awarded RD will also record the prize, to keep track of who won what (stored in order of the draws).
  • You can SAVE and LOAD the current list and state of draw (whos eligible stil for the current round, who won what, etc.) to disk.
  • Disk error check is in place as well (so the program dosent error out due to disk problems) and a sanity check (will remind you to save if you try to quit and changes had been made since your last save)
  • oh, you can store multiple draw files (by name), and choose the disk device number… (more file stuff to come)
  • There are list options to see who is listed and who is eligible as well as who won what.
  • It is being written in a text editor formatted for conversion to Commodore BASIC with the C64List utility by Jeff Hoag. You can find the C64List utility on CommdoreServer.com download page http://www.commodoreserver.com/Downloads.asp BTW it is Windows based, but it runs great in Linux using WINE, you will have to install a VB lib but you can google how to do that when you get there, not hard at all.

Heres my code so far:

rem *** random draw ***
rem by larry anderson v.07 9/25/2011
rem designed to have a non-repeating random door prize draw
rem which includes tracking of winners
rem with the ability to save/load draws in progress
rem ==========
rem formatted for C64list by Jeff Hoag
rem conversion command:  C64List randomdraw.txt -prg:random.prg
poke 53280,15:poke 53281,0:print"{white}{clear}"
print "random drawing program - by larry anderson 9/2011"
gosub {:initvars}
    print "{rvrs on}draw menu---------{rvrs off}
    print " 1 - draw prize"
    print " 2 - list names"
    print " 3 - list winners"
    print " 4 - add names"
    print " 6 - load data"
    print " 7 - save data"
    print " 8 - produce report"
    print " 0 - reset draw stats"
    print " q - quit program"
    print "enter option:";:inputm$
    ifm$="1" then gosub {:drawprize}
    ifm$="2" then gosub {:listnames}
    ifm$="3" then gosub {:listwinners}
    ifm$="4" then gosub {:addnames}
    rem ifm$="5" then gosub
    ifm$="6" then gosub {:diskload}
    ifm$="7" then gosub {:disksave}
    ifm$="8" then gosub {:makereport}
    rem ifm$="9" then gosub
    ifm$="0" then gosub {:resetdraw}
    ifm$="q" then gosub {:endroutine}
goto {:mainmenu}

    ifdc%=0 then goto {:endroutine1}
    print "!!!!!data has not been saved, exit anyway? (y/n)";
    input q$
    if q$<>"y" then print "exit aborted.":return

rem *** initialize variables ***
    rem arrays - names, current draw status, prize names, prize winners, temp
    dim nm$(200), dr%(200), pz$(100), pw%(100), tp%(200)
    nn%=0: nw%=0: rem number of names, number of winners
    dv%=peek(186):fi$="namefile":rem default device and file name
    dc%=0:rem data change flag if 1, data has changed since last save.

    print "{rvrs on}draw for prize{rvrs off}"
    print "   options: yes/no/reset list/cancel"
    print "            (y/n/r/c)"
    if nn%=0 then print "!-no names in database":return
    gosub {:getdrawlist}:rem *** get draw list
    rem *** if all have been drawn, reset draw list
    if tc%=0 then rd%=1:gosub {:getdrawlist} 
    if tc%=0 then print "!-no eligible names to draw":return
    rem *** select randome winner ***
    wn% = int(rnd(1)*tc%)
    rem confirm winner?
    print "from "+str$(tc%)+" names; ";
    print "is "+nm$(tp%(wn%))+" present ";:input a$
    if a$="y" then goto {:drawprize2}
    if a$="r" then rd%=1:gosub getdrawlist:goto {:drawprize1}
    if a$="c" then return
    print "!-name not selected... redraw":goto {:drawprize1}
    print "enter prize won: ";:input pn$
    rem record changes

    print "participant list:"
    for x=0to nn%-1
        print str$(x+1)+" "+nm$(x);
        if dr%(x)=2 then print " {red}(win disabled){white}";
        if dr%(x)=1 then print " {yellow}(selected this round){white}";
    next x
    print "=========="

    print"{rvrs on}add new participants{rvrs off} enter zz to exit"
    print"enter name, short with no commas or quotes:"
    print"enter name: ";:input n$
    if n$="zz" then goto {:addnames3}
    ifnn%=0then goto {:addnames2}
    ne% = 0
    for x=0to nn%-1
      if nm$(x) = n$ then ne%=1
    next x
    if ne%=1 then print"!-name exists, enter a unique one.":goto {:addnames1}
    nm$(nn%) = n$:nn%=nn%+1:print"+-name "+str$(nn%)+" added":dc%=1
    print "=========="

    print "{rvrs on}winners list{rvrs off}"
    for x=0to nw%-1
        print str$(x+1)+" "+pz$(x)+"->"+nm$(pw%(x))
    next x
    print "=========="

print "report coming soon"

  print "{rvrs on}draw list has been reset{rvrs off} "+str$(tc%)+" names eligible.";

    tc%=0:rem *** reset draw list and get names not already drawn ***    
    for x=0 to nn%-1
      if dr%(x)=1 and rd%=1 then dr%(x)=0:
      if dr%(x)=0 then tp%(tc%)=x:tc%=tc%+1
    next x

    rem *** record data to disk ***
    print "device #:  "+str$(dv%)
    print "{up}{right:10}";:input dv%
    print "file name:   "+fi$
    print "{up}{right:11}";:input fi$
    open 15,dv%,15,"s0:rd-"+fi$:close15
    gosub {:errorcheck}
    open 2,dv%,2,"0:rd-"+fi$+",s,w"
    gosub {:errorcheck}
    if e%<>0 then goto {:disksave2}
    rem store number of names and names
    print#2, nn%
    for x=0 to nn%-1
    next x
    rem store number of winners list and name number
    print#2, nw%
    if nw%=0 then goto {:disksave1}
    for x=0 to nw%-1
    next x
    print#2,"" :rem  extra line for padding.
    gosub {:errorcheck}
    close 2
    if e%<>0 then print "!-device error "+e$: goto {:disksave3}
    print "data saved, no errors.":dc%=0

    print "device #:  "+str$(dv%)
    print "{up}{right:10}";:input dv%
    print "file name:   "+fi$
    print "{up}{right:11}";:input fi$
    rem *** load data from disk ***
    open 2,dv%,2,"0:rd-"+fi$+",s,r":gosub {:errorcheck}
    if e% <> 0 goto {:diskloaderror}
    rem number of names, names and thier current draw status
    input#2, nn%
    for x=0 to nn%-1
    next x
    rem number of winners and prizes, winner number if winners
    input#2, nw%
    if nw%=0 then goto {:diskload1}
    for x=0 to nw%-1
        input#2, pz$(x):input#2,pw%(x)
    next x
    gosub {:errorcheck}
    if e%<>0  then {:diskloaderror}
    print "data loaded sucessfully.":dc%=0
    close 2: return
    print "!-device error: "+e$
close 2:return

    open 15,dv%,15
    input#15, e%,e$,t%,s%
    print e%,e$,t%,s%

Nice thing about C64List is that I can do formatting for the non-commodore text version for readability, do search and replace (like when I hit a reserved variable) and scroll about quite easily. Also given that I have more stretching room I am working on saving variable space by using integers when possible, working on good naming and labeling, etc. This also gives me a better “big picture” view to reduce redundancy of common routines. Sill getting a handle on the pseudo op tokens (like changing colors, etc), its pretty straightforward.

Whats next? Better formatting, an option to skip over names (i.e. they were present on the first day, but not on the second, so we want them still listed in history but not considered for the later draws… you will notice I have some code to handle that circumstance already, but nothing to flag them yet). As well as a report producer suitable for printing or as text for a news article. Also it still uses Commodore BASIC's RND function which isn't optimal… that will be enhanced too.

Transfer from Linux to the 64 is via an SD card with a uIEC-SD drive http://store.go4retro.com/products/uIEC_SD.html on the 64 or testing locally in the VICE Commdore emulator http://www.viceteam.org/ in immediate mode.


2011/09/25 23:15 · 0 Linkbacks

PHP Below the Root - Part 3

(sorry if this is a bit nonsensical as I am working out my terminology still)

In order to access pages below the root we need to have the code collect a list of pages accessible

There is one main direct access rout via a ”?do=directname” parameter, as well as script-defined routes via a ”?go=#######” parameter.

The do parameters are stored in the /wanda/app/.. directories below the root in the info.php file, these also include the access group information as well as a user access menu list for building “go” lists… more or less the “drag and drop entry” for that application.

here is an example of a an info.php file,


INFO.PHP in (/wanda/app/calendar/)

  // group settings for application group 'calendar':
  // note application group is the same name as the directory...
  $wandagroup['calendar'] =
        'name'          =>  'Event Calendar'
        ,'description'  =>  ''
        ,'level'        =>  array(
            1   =>  'Guest  - Can view Calendars'
            ,2  =>  'User Access - Can see Email addresses'
            ,3  =>  'Data Access - Can add to Calendars within department'
            ,4  =>  'Manager Access - Can manage calendars'
            ,5  =>  'Admin - can do all administrative functions.' )
  // menu information for the application:
  // for group - Calendar
  $wandamenu['calendar'] =
    //main menu entry information, application name, menu description, and app icon (in public_html/wanda/icon/)
        'name'          =>  'Event Calendar'
        ,'description'  =>  'Event Tracking Calendar'
        ,'icon'         =>  'calendar.png'
        // the user access scripts in the menu
        // name, icon, link (init means they begin the page chain)
        // minimum user level to access.
        ,'submenu'      =>  array(
            'calendar'      =>  array(
                'name'          =>  'Calendar'
                ,'icon'         =>  'calendar.png'
                ,'link'         =>  'init'
                ,'level'        =>  1
            ,'search'      =>  array(
                'name'          =>  'Calendar Search'
                ,'icon'         =>  'calendar_edit.png'
                ,'link'         =>  'init'
                ,'level'        =>  1
            ,'report'   =>  array(
                'name'          =>  'Calendar Reports &amp; Tools'
                ,'icon'         =>  'page_white_text.png'
                ,'link'         =>  'init'
                ,'level'        =>  1
// direct-access entries via the go? parameter ( i.e. wanda.php?go=calendar)
$wandadirect['calendar'] = 'calendar/pubcal.php';

So to build a list of all the direct links we include in all the info.phps in all the subdirectories of /wanda/app:

PAGELIB.PHP (continued)

//if "do" read in direct links, then, if it exists, go to it.
if(isset($_GET['do']) || isset($_POST['do'])) {
    //read in app defaults...
    $wandagroup = array();
    $wandamenu = array();
    $wandadirdata = opendir( WANDA_APPS );
    while (false !== ($wandafile = readdir($wandadirdata))) {
        if ($wandafile != "." && $wandafile != "..") {
            $wandainfo = WANDA_APPS.$wandafile.'/info.php';
            if(is_file($wandainfo)) {
                include $wandainfo;
    $wandadocode = cleanValue((isset($_GET['do']) ? $_GET['do'] : $_POST['do'] ));
    if(isset($wandadirect[$wandadocode])) {
        include WANDA_APPS.$wandadirect[$wandadocode];

In older version of WANDA I had the menus and such in a database table, which would be prone to problems if the DB was damaged or could be compromised by another rouge script. This feels more sturdy as well as secure.

Scripts that are direct access with forms can just use (as an example) wanda.php?do=calendar for their form action, it will submit back to the same page (or use another direct page entry if that is your thing)

If we fail this part we will leave direct access (except at the end to force login), so in next part we will go to user access, using links with sessions, and all that other goodness.


2011/08/14 15:52 · 0 Linkbacks

PHP Below the Root - Part 2

In the last part I discussed the file structure. Everything will come from one main script, (i.e. index.php)

that script will have the minimum of code, everything else will be fed from deeper libraries.


ini_set('display_errors', 1);
// define base wanda path, below web root
$loc = explode('/',$home);
define('WANDA_BASE', implode('/',array_slice($loc,0,-2)).'/');
// Hand over to the page handler
require WANDA_BASE.'wanda/inc/pagelib.php';

Thats it. What it does is define the path WANDA_BASE to below web root, then goes and includes the pagelib.php file, which partly includes much of what is needed to get around in the directories.

pagelib.php part 1

//define directory constants
// home page
    define('WANDA_INDEX', $home);
// above root libraries
    define('WANDA_LIB', implode('/',array_slice($loc,0,-1)).'/wanda2/');
// above root icon images
    define('WANDA_ICON', 'wanda2/icon/');
// above root images
    define('WANDA_IMAGE', 'wanda2/image/');
// below root apps folder
    define('WANDA_APPS', WANDA_BASE.'wanda/app/');
// below root includes (function libraries) folder
    define('WANDA_INC', WANDA_BASE.'wanda/inc/');
// System configurations folder (db settings, etc.
    define('WANDA_CONF', WANDA_BASE.'wanda/conf/');

Where to go from here?

so to call different programs we will need to have a system to have the core script make available or access the programs that will not be browser accessible.

The big challenge was figuring out where to go from here. I've devised three modes:

  • Nothing specified - goes to a menu or log in screen.
  • Direct call to a page pre-set for direct access i.e: index.pho?do=claendar - these would be pages that do not require an access restriction, nor are dependent on data from other pages. Note the name such as “calendar” does not have anything to do with the path or the script name… more on that later.
  • Go to a page called by another page - these pages are from a list pre-generated by the menu or another page withn the system - only available when made available. The third mode actually works in two different ways:
    • Go to a series of sub pages in a chain of pages, and upon completion be able to return to the previous calling page (i.e. search → information → edit → sub-element search → confirm then be able to go back again…)
    • Or go to a report page - this would be a page not part of a chain of pages, but does not affect the chain in progress - like the direct page option but only accessible via the calling page. such as a pre-filled form or something that opens in a new window or tab. There could be a case of it having its own input form so it needs to have a semi static listing on the page list.


Next up I will go about highlighting some of the page access magic.


2011/07/16 21:55 · 0 Linkbacks

Taking PHP Below the Root

I'm sure most of us PHP guys have read all the security stuff about how we can best secure our code. Lots of quick sound bits that sound all that good but trying to implement them is another story.

One that I felt was a challenge is taking my PHP code below the webroot level. While many I am sure would be satisfied with getting the choice bits under, but I was thinking it would be best if you could get as much as possible. I could better control what scripts get accessed, etc.

I wanted to make it also so everything worked through one core script. This is for my framework WANDA, which is designed to host multiple programs, so another bit was to do some cleanup work on access and menus. to make the programs closer to plugin ready.


To start, the directory tree:


    the directory for all things WANDA below web root.
    • APP
      plug-in applications go there…
      • MAILLIST
        a WANDA application scripts directory is same as the access group name
        • INFO.PHP
          This is the application information script that contains this app's menu listing, submenu and access settings.
    • CONF
      WANDA configuration - database settings, etc.
    • INC
      Framework script libraries.


    this is the main program has minimal code to set the base directory for the bleow root page handler, then includes that.
  • WANDA (dir)
    above root data, thongs accessed by the browser and not by the server…
    • ICON
      Icons used in the appss
    • IMAGE
      images, PDFs, etc. that also accessed directly via browser
    • SCRIPT
      CSS, Javascript modules, etc.

Unless I need a temp files directory, this will cover it. In later posts I will go over the code I've developed to get everything working in their places.


2011/07/10 21:11 · 0 Linkbacks


Use the following URL for manually sending trackbacks: http://www.portcommodore.com/dokuwiki/lib/plugins/linkback/exe/trackback.php/blog:start
Last modified: 2012/04/06 23:17
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported