Here's some pos js code that is /finally/ working:
http://www.spyderware.net/source/zk.js
[it's teh canvas layout impl, I mentioned before, hatter.]
Again, it's not much. Otoh, it's but one piece of teh puzzle. Most of which
are gen'd dynamically serverside (e.g., html, js, css, cats, dogs, etc). Oh
and look! No evals! Though, horror of horrors, there /are/ some globals.
Btw, zk stands for zodiac killer, and teh component is a ladle trinket I
threw together bc I'm too lazy to try to do it on paper (that and doing so
killz trees). It seems I'm not teh only one. Here's what one of my *cough*
fans had to say when I originally launched teh pre js app:
http://www.zodiackiller.com/discus/message...html?
"Tom had also cited http://www.spyderware.net/zodiac and I feel
that that is an indespensable tool"
Teh majority referrers are from teh above and one other link on teh same
site. And teh remaining referrers come from other zk sites (must be teh
lurkeel00s). And yeah, it's fugly, but oh well. It's functional and I get
return and new visitors on a regular basis.
/me wonders if I can bribe hatter for some of his graphics ideas
Oh and. One more thing. It is not xbrowser compat in teh least little bit.
At least, not any more (I haven't teh foggiest idea why). But anyway, just
thought So, should you decide to take a looksee, if you aren't using IE,
you're pretty much fux0red. But anyway, hace fun (or not)! ^_~
/me slaps hatter up teh side of teh head for reviving teh js chit
--
"When you are aspiring to the highest place, it is honorable to reach the
second or even the third rank." -- Cicero
Full Version: pN1g Richard C, Michael W, & OMH
On 12/07/2005 06:45, ^reaper^ wrote:
| QUOTE |
| Here's some pos js code that is /finally/ working: http://www.spyderware.net/source/zk.js |
No, it isn't. :p The first function call in the deleteCookie function is
missing a closing parenthesis.
Your data 'arrays' should be replaced by Object objects. Array objects
should generally be reserved for when you intend to use them as you
would in other languages like C. That is, if you don't intend to loop
through properties in the range [0, length), or use Array.prototype
methods, then you should probably be using an Object instance.
[snip]
| QUOTE |
| Though, horror of horrors, there /are/ some globals. |
They (well, pv really) could be removed easily enough, as well. You
appear to implementing a map object with serialisation capabilities, so
pv could just be assimilated as a private member.
If I'm way off there, I'd like to state now that I've been awake for
about 30 hours, and it's beginning to take its toll on my ability to
think straight. :-/
[snip]
| QUOTE |
| And yeah, it's fugly, but oh well. |
Yes. Yes, it is, though I'm commenting purely on the markup for the moment.
You could clean it up a little by making both grids TABLE elements and
using the image as a background. Much less need for absolute
positioning, that way which would simultaneously solve the problem of
Firefox bunching up the the INPUT elements. Another fix there is to give
the containing DIV elements explicit widths.
| QUOTE |
| Oh and. One more thing. It is not xbrowser compat in teh least little bit. |
The first port of call is:
15 document.getElementById(k).value=val;
from the updateFunction. Here, k is a string which represents the /name/
of a form control. IE has a bug where it will return an element with a
matching name attribute if it cannot find one with a matching id
attribute. You could reference the element via the form, or you could
pass a reference to it directly and use the name property to act as the
property name on lines 11 and 13. You should also move this line outside
the loop.
The same problem occurs in the save function on lines 29 and 32.
The second problem:
16 document.getElementById(lst[i]).innerText=val;
is that the innerText property is proprietary and, unlike innerHTML, has
very little support outside IE. You could either use the latter, or you
could alter the text node child of the DIV elements. For instance (and
lacking feature detection):
document.getElementById(lst[i]).firstChild.data = val;
[snip]
There are a few other niggling little problems:
1. Parts of your style sheet are invalid. The main issue is the
occurance of colour hex literals without the necessary
preceeding hash (#).
2. Continuing, you also make reference to properties that don't
exist anywhere (not even in IE). Examples are bgproperties and
decoration. The former shouldn't be necessary at all as you're
not using background images, and the latter would seem to be
font-weight as you provide a value of bold in one instance, but
text-decoration otherwise.
3. You really should use structure more often in your style sheets.
A lot of redundancy could be avoided with that large grid of
DIV elements by using:
#overlay div {
background-color: transparent;
color: #FF0000;
position: absolute;
z-index: 100;
}
4. Last in this vein: the cursor property must have keyword, such
as pointer, default or auto, as its last value.
5. If you're trying to advance a Date object by a year, it's
better to use the year-related methods:
var xpires = new Date();
xpires.setFullYear(xpires.getFullYear() + 1);
I'm sure there was something else, but I can't remember what it was.
*shrugs*
Mike
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
On Tue, 12 Jul 2005 14:17:25 GMT, Michael Winter
<[Email Removed]> wrote:
<snip>
<[Email Removed]> wrote:
<snip>
| QUOTE |
| You could clean it up a little by making both grids TABLE elements </snip |
While sipping absinthe, Michael Winter heard a loud sucking noise coming
from alt.2600, and hastily inscribed the following unintelligible Sanskrit
in <news:VhQAe.68163$[Email Removed]>:
[snip excellent and appreciated feedback]
Thanks for the input, Michael. I corrected teh 'buggy' js & css stuff. Wrt
to the other (globals, arrays, and bears, oh my!), making the changes you
suggested makes little sense in context of requiring more complex
serverside processing. Furhtermore, I'm not seeing where replacing the
canvas overlay divs with a table buys me anything. In both cases, I am
dealing with positioning. In the div case, it's a matter of setting fixed
positions over teh canvas that are easily computed. Whereas for teh table,
I would need to set row height and column width for each cell (which is, of
course also easily computed) to ensure the overlay aligned appropriately
with the cipher canvas. In fact, I did just such a thing for the menu
(e.g., using a table for teh overlay). As you can see, when viewing teh
page in firefox, the table ends up scrunched to the left (even with
explicitly stated table & column widths). Btw, on this latter bit, I could
always revert back to the original impl and place teh individual symbols in
teh table cells as well. This of course, would require dl'ing 50 individual
symbol graphics in teh case of teh 340 cipher as opposed to dl'ing a single
compressed menu canvas grapic.
That aside, here's a bit of background on the app.
1) There are four ciphers.
2) In addition to the shared base symbols each cipher has its own unique
symbols.
3) The ciphers do not share solutions (e.g., 408 keys and algorithms do not
apply to remaining ciphers).
4) The 408 cipher was a homophonic substitution cipher.
6) Pattern analysis suggests the 340 cipher is also a homophonic
substitution cipher (that may also involve pivots and anagrams).
To provide user input, pivoting, and potential anagram manip, the app is
fully dynamic. In other words, the output, to include the text freq, menu
background & cipher canvas graphics, along with the html, js & css, are
generated on teh fly based upon db data, cryptoanalysis rules, and user
input. For example, teh 408 canvas involves not only placement of teh
symbols on teh canvas, but painting teh plaintext solution as well. And teh
frequency graph computes symbol freq for visual correlation between teh 380
& 408 ciphers.
As for teh remaining pieces, the singleton/pair numbers that you see by
each symbol in the menu backgrounds are computationally derived. As are the
symbol to line frequency centiles on teh cipher canvas (which of course,
changes when you pivot teh canvas). What this does, is to provide clues for
solving the cipher (e.g., 'common' plaintext letter pairs such as e, t, o,
n, r, & s). So the second number by the menu symbol signifies those symbols
which are relationally paired on teh cipher canvas, whereas the first
number is the singleton freq. The line centiles provide a snapshot of the
interrelated symbol to line frequencies. Thereby lending a potential clue
wrt the type of cipher (e.g., homophonic substituion).
In addition, for the 340 cipher only, a mask is gen'd, which is based upon
singleton & paired letter frequency. In its present rendition, the user can
apply the mask, enter their guesses, and save the canvas state without
requiring they hit the sever. The pivot requires a server hit, simply bc
the canvas must be redrawn for that operation.
In short, the tradeoffs with this approach v its earlier rendition is using
a canvas and js (I tend to avoid using js due to inherent xbrowser
problems, security issues, etc) for updating the symbol overlays, as
opposed to requiring the user hit teh server for the overlay update. The
underlying app has not changed since its original creation a few years ago.
And unfortunately, I haven't had time to add the additional cryptoanalysis
features. No matter. The primary diff btwn v1 & v2 are the additional htm
(overlay divs), css (overlay placement), and the addition of js to teh mix
(overlay control fns). These changes required very little code (e.g., a
couple of lines to create the htm divs, css placement, & js arrays), along
with changes to the menu section, to include creating a single menu
background and updated menu controls to refer to teh js update fns in teh
zk.js file. The latter, which is btw, the only static piece of teh app.
In all, it's been an interesting challenge. While I have played around with
various algolrithms to computationally create/solve ciphers in teh past, in
this case, I happened to stumble upon teh zk site, and decided to create a
zk cipher sandbox, so to speak, for interested onlurkers. Thus was born teh
silly ladle page. ^_~
--
"The hardest victory is victory over self." -- Aristotle
from alt.2600, and hastily inscribed the following unintelligible Sanskrit
in <news:VhQAe.68163$[Email Removed]>:
[snip excellent and appreciated feedback]
Thanks for the input, Michael. I corrected teh 'buggy' js & css stuff. Wrt
to the other (globals, arrays, and bears, oh my!), making the changes you
suggested makes little sense in context of requiring more complex
serverside processing. Furhtermore, I'm not seeing where replacing the
canvas overlay divs with a table buys me anything. In both cases, I am
dealing with positioning. In the div case, it's a matter of setting fixed
positions over teh canvas that are easily computed. Whereas for teh table,
I would need to set row height and column width for each cell (which is, of
course also easily computed) to ensure the overlay aligned appropriately
with the cipher canvas. In fact, I did just such a thing for the menu
(e.g., using a table for teh overlay). As you can see, when viewing teh
page in firefox, the table ends up scrunched to the left (even with
explicitly stated table & column widths). Btw, on this latter bit, I could
always revert back to the original impl and place teh individual symbols in
teh table cells as well. This of course, would require dl'ing 50 individual
symbol graphics in teh case of teh 340 cipher as opposed to dl'ing a single
compressed menu canvas grapic.
That aside, here's a bit of background on the app.
1) There are four ciphers.
2) In addition to the shared base symbols each cipher has its own unique
symbols.
3) The ciphers do not share solutions (e.g., 408 keys and algorithms do not
apply to remaining ciphers).
4) The 408 cipher was a homophonic substitution cipher.
6) Pattern analysis suggests the 340 cipher is also a homophonic
substitution cipher (that may also involve pivots and anagrams).
To provide user input, pivoting, and potential anagram manip, the app is
fully dynamic. In other words, the output, to include the text freq, menu
background & cipher canvas graphics, along with the html, js & css, are
generated on teh fly based upon db data, cryptoanalysis rules, and user
input. For example, teh 408 canvas involves not only placement of teh
symbols on teh canvas, but painting teh plaintext solution as well. And teh
frequency graph computes symbol freq for visual correlation between teh 380
& 408 ciphers.
As for teh remaining pieces, the singleton/pair numbers that you see by
each symbol in the menu backgrounds are computationally derived. As are the
symbol to line frequency centiles on teh cipher canvas (which of course,
changes when you pivot teh canvas). What this does, is to provide clues for
solving the cipher (e.g., 'common' plaintext letter pairs such as e, t, o,
n, r, & s). So the second number by the menu symbol signifies those symbols
which are relationally paired on teh cipher canvas, whereas the first
number is the singleton freq. The line centiles provide a snapshot of the
interrelated symbol to line frequencies. Thereby lending a potential clue
wrt the type of cipher (e.g., homophonic substituion).
In addition, for the 340 cipher only, a mask is gen'd, which is based upon
singleton & paired letter frequency. In its present rendition, the user can
apply the mask, enter their guesses, and save the canvas state without
requiring they hit the sever. The pivot requires a server hit, simply bc
the canvas must be redrawn for that operation.
In short, the tradeoffs with this approach v its earlier rendition is using
a canvas and js (I tend to avoid using js due to inherent xbrowser
problems, security issues, etc) for updating the symbol overlays, as
opposed to requiring the user hit teh server for the overlay update. The
underlying app has not changed since its original creation a few years ago.
And unfortunately, I haven't had time to add the additional cryptoanalysis
features. No matter. The primary diff btwn v1 & v2 are the additional htm
(overlay divs), css (overlay placement), and the addition of js to teh mix
(overlay control fns). These changes required very little code (e.g., a
couple of lines to create the htm divs, css placement, & js arrays), along
with changes to the menu section, to include creating a single menu
background and updated menu controls to refer to teh js update fns in teh
zk.js file. The latter, which is btw, the only static piece of teh app.
In all, it's been an interesting challenge. While I have played around with
various algolrithms to computationally create/solve ciphers in teh past, in
this case, I happened to stumble upon teh zk site, and decided to create a
zk cipher sandbox, so to speak, for interested onlurkers. Thus was born teh
silly ladle page. ^_~
--
"The hardest victory is victory over self." -- Aristotle
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.