thewca / tnoodle Goto Github PK

Something distinctive, but reminiscent of the WCA logo. For the favicon and scrambler-interface.

Files are unpacked into tnoodle_resources right now. If someone runs a new version of tnoodle from the same folder (very likely, because of download folders in most operating systems), it might use old files and crash or use the wrong data.

Two recommendations:

1. Have each .jar build include some sort of unique ID. Maybe something like version + unix time. Write this value to a file in the tnoodle_resources folder and check it on start up.

2. If the detected ID doesn't match, nuke the entire folder and regenerate.

Ideally, tnoodle would also check the folder for integrity, e.g. by taking hashes of things. But it's probably okay to assume people won't meddle if they want tnoodle to keep working fine. Are there any subtle issues we need to worry about with durability, like the OS doing something silly to the folder?

[One other optino I can think of: have each build write to its own folder inside tnoodle_resources, or make its own folder entirely. I don't like this for a few reason, in particular because it would use a bunch of disk space.]

Replace slice turns like r with Rw R' to prevent the people who are scrambling from getting too confused.
This is only an issue with the 4x4x4 solver.

Note, this may result in move cancellations.

Visiting http://tnoodle.tk/scramble on Opera 11.64 on Windows 7 only displays the background color.
The javascript console displays:

[18/03/1970 15:40:52] JavaScript - http://tnoodle.tk/scramble/
Event thread: load
Uncaught exception: ReferenceError: Undefined variable: Request
Error thrown at line 299, column 1 in (callback, url, data) in http://tnoodle.tk/js/scramble.js:
var request = new Request.JSONP({
called from line 221, column 3 in (callback, url, data) in http://tnoodle.tk/js/scramble.js:
tnoodle.jsonp(callback, url, data);
called from line 96, column 2 in (callback, puzzle, seed, count) in http://tnoodle.tk/js/scramble.js:
var pendingLoadScrambles = tnoodle.ajax(function(scrambleRequests) {
called from line 101, column 4 in competitionChanged() in http://tnoodle.tk/scramble/:
scrambleServer.loadScrambles(scramblesLoaded.bind(null, puzzle), puzzle, seed, neededScrambles);
called from line 740, column 2 in () in http://tnoodle.tk/scrambler-interface/js/ui.js:
callbacks.competitionChanged();
called from line 602, column 2 in (name, canZip, callbacks_) in http://tnoodle.tk/scrambler-interface/js/ui.js:
updateHash();
called from line 117, column 2 in () in http://tnoodle.tk/scramble/:
var div = mark2.ui.initialize(tnoodleLink, canZip, callbacks);

We should be able to catch that encrypted PDFs are broken, so that this doesn't happen again.

This would make navigating way easier than trying to juggle a bunch of pdfs on the filesystem.

In addition, we could look into creating some sort of generated html inside of each zip.

As it is now, looks to be red on front, blue on bottom.
As Roman said on the gmail group, yellow on bottom, green on front would be more consistent with the rest.

As in, post on the forums, get back feedback before finalizing. The sooner, the better.

Specifically 2x2x2 and pyraminx. The argument that competitors might be able to see the scrambles doesn't hold any water with me, but it would prevent (illegal?) scramble filtering.

Right now, the bootstrap to increase memory results in two .jar files displaying in the dock in OSX.

While this is preferable to having no 4x4x4 scrambles, it might be confusing to someone who only expects one program to be running.

I thought the new process tries to kill the parent one. Did that not work?

The WRC seems to be coming to a consensus that scrambles should only be filtered to remove any random state that could be considered solved, possibly including penalties (i.e. you could start and stop the timer without turning, and not get a DNF).

Although perhaps the community will have very convincing arguments for something else, this seems to be the best tradeoff for now, so we should be ready to support it.

From @jfly:

ClockScrambler doesn't implement getDefaultFaceBoundaries(), which means it is impossible to configure its colorscheme.

From https://github.com/jfly/tnoodle/issues/6

Could we have a working version of tnoodle by sept 1st, along with the release of the new regulations ? It will still allow updates, we should write on the regulations to tnoodle version > x.y for example.

I found a couple of these at the last competition.
I think it was Uw2 Dw2, but you get the point.

As in, post on the forums, get back feedback before finalizing. The sooner, the better.

It might be nice to set the <title> tags to the first line (if it's a <h1>) for served Markdown pages.

Europeans are going to have lots of extra space. Is there a good way to handle this?

I would prefer not to introduce a UI option for something like this, unless we introduce an advanced options panel. But even that goes against the simplicity we have right now. Put this off until people actually bring it up to us?

I think this is what Pedro asked for.

I'd like to suggest changing the down pin color to #885500 (or something similar), to make it easier to tell them from the up pins.

Also, changing the back side color to #55ccff would make it look better than the current gray-ish color.

See www.cuber.com.br/clockScrambler.html for how it looks like (not the same front blue, but that one is good)

Top-part of the preview works if I start with middle-blue on front, on a mefferts color scheme. But the bottom doesn't.

Also, I don't like the preview shows no front face, but instead a B, RB, LB, LF and RF faces. Tilting the image some degrees might be good.

Chen Shuang has also written a 4x4 solver.
It has several advantages over mine:

• solutions end up with outer layer turns, while mine ends up with half layer turns
• solutions are a bit shorter (~45 moves), and more suitable for ftm metric (no inner slices moves to convert at the end)

The only problem I see is that it takes a bit more memory (~80 MB, mine is ~20 MB) and there is a big pruning table to generate.

This might be due to some mootools shuffling I just did.

For example, WRC documentation still says the 4x4x4 scrambler might take up to 10 minutes to initialize and use 75MB of disk space for prune tables.

Right now, 4x4 initialization + scramble time takes a while, and it looks like nothing's happening. Perhaps we should create some infrastructure to allow reporting back on status...

Starting a list:

• Block turns are now e.g. 3Rw.
• x, y, and z are still moves.

I get this when compiling:

utils/src/net/gnehzr/tnoodle/utils/Utils.java:23: warning: sun.reflect.Reflection is Sun proprietary API and may be removed in a future release
import sun.reflect.Reflection;

Is that important ?

There a few small loose ends to clean up. I think it's okay if the program still calls itself "tnoodle", but we should have a single stable .jar that's easy to run and use.

From https://github.com/jfly/tnoodle/issues/17

This occurs in all of the scramblers that can generate tables to disk. This isn't a pleasant message to see during a successful compile:

~/Dropbox/gitting/tnoodle @slaptop> ./tmt make -p twophase
utils is up to date, not recompiling
Compiling: twophase/src
javac -d twophase/.bin -classpath utils/bin:twophase/bin:utils/bin_tnoodle_resources:twophase/bin_tnoodle_resources:lib/gson-2.0.jar twophase/src/cs/min2phase/Util.java twophase/src/cs/min2phase/CubieCube.java twophase/src/cs/min2phase/Search.java twophase/src/cs/min2phase/Tools.java twophase/src/cs/min2phase/CoordCube.java twophase/src/cs/min2phase/MainProgram.java
Compiled successfully! Renaming twophase/.bin -> twophase/bin
Compiling: twophase/src_tnoodle_resources
Compiled successfully! Renaming twophase/.bin_tnoodle_resources -> twophase/bin_tnoodle_resources
Setting up symlink twophase/bin/tnoodle_resources -> ../bin_tnoodle_resources
Generating twophase/bin_tnoodle_resources/twophase_tables
java -ea -classpath utils/bin:twophase/bin:utils/bin_tnoodle_resources:twophase/bin_tnoodle_resources:lib/gson-2.0.jar cs.min2phase.Tools twophase/bin_tnoodle_resources/twophase_tables
[twophase/bin_tnoodle_resources/twophase_tables]
java.io.EOFException
    at java.io.DataInputStream.readChar(DataInputStream.java:348)
    at cs.min2phase.Tools.read(Tools.java:27)
    at cs.min2phase.Tools.initFrom(Tools.java:95)
    at cs.min2phase.Tools.init(Tools.java:82)
    at cs.min2phase.Tools.initTo(Tools.java:125)
    at cs.min2phase.Tools.main(Tools.java:179)
Successfully generated twophase/bin_tnoodle_resources/twophase_tables!
~/Dropbox/gitting/tnoodle @slaptop> 

So we know how large we're at. In particular, so we can notice if it's unexpectedly large.

22d6dbc helped significantly by taking bouncycastle from 2MB to 18KB. Perhaps we can trim out a bunch of iTextPDF for tnoodle releases?

This is to track stuff that needs to be done before releasing.

Right now, there is a FileNotFound exception on first run, when the prune tables are not found.

I'm also getting stream exceptions.

e.g. "Scrambles"

Otherwise, the .pdf in the .zip is a hidden file.

(OSX doesn't even treat it correctly as a .pdf even if you do open it.)

It's feasible now: https://github.com/ChenShuang/FiveStage444

From https://github.com/jfly/tnoodle/issues/4

Update fewest moves sheet to reflect the new regulations.
Change also "challenge" to "event", this is not a challenge :)

e.g. modify the .pdf pages to have the WCA logo and some official-looking stuff. Not critical.

From https://github.com/jfly/tnoodle/issues/20

The { roundTitle: roundDesc, ... } url parameter system just doesn't work, and should be replaced. This will involve modifying ScrambleRequest.java, tnt's tnoodleServer.js, and scramble.js.

Mersenne Twister is not cryptographically secure.

Not to self: make a speedsolving.com post about how seed space is a red herring.

Right now, there's no indication that we don't ever try again. The user will have to reload the page to try again.
Also, @lgarron says no alerts.

Right now, it's not explicitly listed in the classpath for the server or in lib/libraries.

Thinner lines would avoid interfering with small letters.
Assuming we're keeping the overall format.

Ron wanted this with old scramblers. This makes it possible to trace down which program generated a set of scrambles, in case of trouble.

This should be included in the PDF, and at least the .json.

While I have nothing against using -p timer for development, something like -p wca would be a nice distinction. It's semantically cleaner and more future-proof.

This makes it impossible to press the reset button, for example.

A simple fix would be to add this to #ajaxStatus:

height: 20%;
overflow: scroll

Right now, most variables and functions have a one-letter name.

Something like extract to temp dir, then move temp dir to tnoodle_resources.

UPDATE (jfly 6/15/2012): This issue is meant to track the 4x4 OOM problems @lgarron has been experiencing. Everything else mentioned in this thread is now fixed.

Was going to comment on d158e98, but that seems long. Mentioning @clementgallet here instead.

Random-state 4x4x4 would be awesome, but right now it's more :-(

./tmt make run -p timer gives this:

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at cg.fivestage444.PruningStage4.init(PruningStage4.java:24)
at cg.fivestage444.Tools.init(Tools.java:130)
at cg.fivestage444.Tools.initTo(Tools.java:203)
at cg.fivestage444.Tools.main(Tools.java:249)
Traceback (most recent call last):
File "./tmt", line 909, in
tmt._main()
File "./tmt", line 192, in _main
self.args.func()
File "./tmt", line 272, in _make
commandFunc()
File "./tmt", line 862, in run
tmt._make(projectName=self.name, command='compile')
File "./tmt", line 272, in _make
commandFunc()
File "fivephase/tmtproject.py", line 19, in compile
args=[ self.fivephase_tables ])
AssertionError

/Users/lgarron/Documents/git/GitHub/tnoodle/fivephase/tmtproject.py(19)compile()
-> args=[ self.fivephase_tables ])

Trying again:

scrambles/src_tnoodle_resources/scrambler/CubeScrambler.java:35: package cg.fivephase does not exist
private ThreadLocal<cg.fivephase.Search> fivePhaseSearcher = null;
^
scrambles/src_tnoodle_resources/scrambler/CubeScrambler.java:50: package cg.fivephase does not exist
fivePhaseSearcher = new ThreadLocal<cg.fivephase.Search>() {
^
scrambles/src_tnoodle_resources/scrambler/CubeScrambler.java:51: package cg.fivephase does not exist
protected cg.fivephase.Search initialValue() {
^
scrambles/src_tnoodle_resources/scrambler/CubeScrambler.java:52: package cg.fivephase does not exist
return new cg.fivephase.Search();
^
scrambles/src_tnoodle_resources/scrambler/CubeScrambler.java:78: package cg.fivephase does not exist
return fivePhaseSearcher.get().solve(cg.fivephase.Tools.randomCube(r), 500, true).trim();
^
5 errors
Traceback (most recent call last):
File "./tmt", line 909, in
tmt._main()
File "./tmt", line 192, in _main
self.args.func()
File "./tmt", line 272, in _make
commandFunc()
File "./tmt", line 795, in dist
tmt._make(projectName=self.name, command='compile')
File "./tmt", line 272, in _make
commandFunc()
File "./tmt", line 682, in compile
self._compile(self.srcResource, self.binResource)
File "./tmt", line 737, in _compile
assert p.wait() == 0, 'javac failed!'
AssertionError: javac failed!

/Users/lgarron/Documents/git/GitHub/tnoodle/tmt(737)_compile()
-> assert p.wait() == 0, 'javac failed!'

Threephase appears to be fast, and not too slow to initialize, which is awesome.

• Is initialization progress being reported properly? I see it update in three sections, the last of which takes the longest this might suggest to a user that something is wrong. (On the commandline, it updates with percents, so we could theoretically provide a very smooth progress bar in the UI, right?)
• Maybe cleanups to the project. After updating to cubing/master, I still had a an unstaged fivephase folder hanging around.
• I still seem to get runtime exceptions sometimes? If I try to generate a lot of 4x4x4 scrambles, things start crashing, where I see red errors in the UI and sometimes exceptions in the console. Memory leak?