Blake's blog

I've been tinkering around with a few different Web 2.0 gadgets, and I've recently grown enamored with delicious -- the bookmarking network in which:

• Our bookmarks are available to myself on any workstation
• Our bookmarks are available to the public
• We can tag any bookmark for easy reference
• We can look at reports of all bookmarks that have been assigned certain tags from users across the globe!

So here's what we can do now. Say you're looking a blog entry that you're going to bookmark ANYWAYS and you'd also like to raise it to our attention. Simply go about your bookmarking business, then at the very end, add the tag mantle. I've added it to my reader to keep me posted on any delicious bookmarks with the mantle tag, so I'll pick it up. If you'd like to add any commentary in the bookmark description as well, that would be greeeeat.

Simple as that! Imagine: instead of writing an email, an IM, or any other form of communication, you simply add one word to the end of your delicious bookmark tag list, and we'll pick it up! You never have to leave the comfort of the web page you're currently on!

Though we may need some further categorization in the coming days, for now the bookmarks can be:

• Sites you think we'd be interested in
• Sites you'd like for us to consider for an ITM entry, youtube, or podcast topic
• Or a reminder to yourself for content you'd like to contribute!

Now..... a few rules......

• No spam. If everything under the sun starts getting the mantle tag on it, I'll unsubscribe, the fun (and an exciting feature) is in effect over.
• The tag itm is also permissable. I will subscribe to that one too just in case, though I'd prefer the mantle tag -- we are trying to create some buzz, you know.
• We'd like to reserve the tag intothemantle for official intothemantle content, so unless it's under the ITM umbrella, please refrain from using that tag.

Our delicious site is located at: (you guessed it...) http://delicious.com/intothemantle . Check out our bookmarks and feel free to subscribe and/or interact with us on the delicious site.

In other news, we've grown out our twitter presence and you're encouraged to direct any tweets our way: @intothemantle. And, feel free to treat the hashtags #itm #mantle #intothemantle the same way in which you would the delicious tags, they're in our radar as well.

Yes, there are other bookmarking services out there, we're accommodating them one-by-one. I happen to like delicious, so let's just start off with that, shall we? Of course, we'll send out updates for further compliances as we knock them down.

So... when you're bookmarking something for yourself and would like it to cross our desk, just add the following tags!
mantle
itm (if that's more convenient for you)

Along with many others, I have to add Chrome to the list of browsers in which to test. Unfortunately, the JavaScript debugger in Chrome is lacking the visual representation I've since been spoiled with in Firefox and Safari. What they have is a text area you can get to from the Page menu or pressing Alt+`. It pops up a window in which you can debug the javascript with text commands.

There's not a lot of documentation out there for it now. I had this one up. There are some text commands available at all times, then more available only in Pause mode. I won't go through all the commands, just the ones I found useful.

When not paused in debug, these commands are avre
help
help on its own displays the commands available:
$ help
Status: page is running
Available commands:
break [location] <condition>
break_info [breakpoint #]
clear <breakpoint #>
help [command]
print <expression>
scripts

help with a command after it provides information on that command:

$ help break
usage: break [location] <condition>
location is one of <function> | <script:function> | <script:line> | <script:line:pos>

break
Sets up a breakpoint. Supposedly, you can set up breakpoints for line numbers, line positions and function names. For me, only the function name worked. When I tried a line number, it actually set up a breakpoint in a different file. Maybe if you have only one javascript file, the line number is used, but I just use the function name. I tried to specify filename and line number, but to no avail.

$ break DesignHeaderDOM
set breakpoint #1

break_info
By itself, lists information on all breakpoints:

$ break_info
Num breakpoints: 1
id=1, hit_count=0, type=function, target=DesignHeaderDOM

With a number, gives information on a specific breakpoint. Not too useful since it doesn't give any more information than break_info with no arguments. I suppose if you have pages of breakpoints it could be useful, but by that your point, your brain is probably already fried.

$ break_info 1
id=1, hit_count=0, type=function, target=DesignHeaderDOM

clear
Clears a breakpoint for the number specified:

$ clear 1
cleared breakpoint #1

print
print is more useful in Pause mode, but can useful for global variables and to see what a function returns. It would be useful if you could drill into all properties for a variable easily, but you can print out individual properties:

$ print 'hey'
hey
$ print 'a' + 'b'
ab
$ print wysControl //string var
wysiwygIframe
$ print wysControl.length
13
$ print GetWysiwyg()
#<an HTMLDocument>
$ print GetWysiwyg().body.innerHTML
DDDDDDDDDDD<h1>CCCCCCCCCCCcc<br></h1><div>DDDDDDDDD</div>
$ print TrimString(' test ')
test
$ print IsIE()
false

PAUSE MODE
Once you have breakpoints setup, you can make the javascript run on the site. I'm doing this by pressing a button to turn text in a wysiwyg into a header. My breakpoint is set up for the method. When the breakpoint is hit, the debugger window gets focus and shows the current line:

311: var doc= GetWysiwyg();

In Pause mode, the help now shows all commands now available:

$ help
Status: page is paused
Available commands:
args
break [location] <condition>
break_info [breakpoint #]
backtrace [from frame #] [to frame #]
clear <breakpoint #>
continue
frame <frame #>
help [command]
locals
next
print <expression>
scripts
source [from line] | [<from line> <num lines>]
step
stepout

print works as before, only now it can take in local variables as well.

Other variable helper commands:
args
Lists all arguments a method took in. Displays nothing if the method has no arguments. (It doesn't give a message like "No arguments passed in", so when you hit Enter and nothing happens, it actually did do something)

$ args
html = "test text!"

locals
Prints out the value of all variables defined in the method. All start out as undefined.

$ locals
selHeaders = undefined
headerTags = undefined
headerRange = undefined

After stepping through a little....
$ locals
selHeaders = #<an Array>
headerTags = #<a NodeList>
headerRange = undefined

Stepping through the code methods:
step : The equivalent of "Step Over"
next : The equivalent of "Step Into"
stepout : Gets out of the current method, takes you to line on which that method is called.
continue : continues executing til the next breakpoint. If no more breakpoints, breaks out of Pause mode.

The guide I used seemed to give up on these, but they actually work well.

Lets say this is my code:

function RunStuff()
{
var num= fi(5);
}

function f1(i)
{
return f2(i + 1);
}

function f2(j)
{
return j*j;
}

If I have a breakpoint on f1, The code will stop at the first line inside it.
- If I run next, it will run the next line and not go inside f2. Continuing to type next will debug RunStuff and on until there's no more to javascript to run.
- If I'm in f1 and type step, it will go inside f2. At this point, stepout will take me back to f1. stepout again will take me to RunStuff.
- At any point, if I want to stop debugging, I can run continue and either go to the next breakpoint or stop debugging.

source
At any point, if you want to get a good idea of where you are in the code, you can run source to see a 10 line snapshot of the code. Note the >>>>> in the line numbers for what line the debugger is currently on:

$ source
555: return text;
556: }
557:
558: function f1(i)
559: {
>>>>> return f2(i+1);
561: }
562:
563: function f2(j)
564: {
565: return j*j;

That's all for now. I still have to investigate, but that's what I've found on the first run-through. There's definitely a few things that would make it easier (even before a full visual interface)....
1. An auto-focus on the command line.
2. Just hitting Enter repeatedly to step through the code (or F10!) instead of typing in "next" every time
3. Printing out every property of a variable.
4. If I clear breakpoint 1 and 2, the next one still starts at 3. Not sure if I like this yet or not.
.... but for they time being, we can make do.

Also, if you play around enough, you're bound to see these: