Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect / truncated vimscript upload #1

Closed
igrigorik opened this issue Dec 28, 2010 · 8 comments
Closed

Incorrect / truncated vimscript upload #1

igrigorik opened this issue Dec 28, 2010 · 8 comments

Comments

@igrigorik
Copy link
Owner

Entry _id: 4d1a3c30fa85f32065000037, created_at: 2010-12-28 19:36:16 UTC, script: "\x80\xFD5:g/", score: 6

Happening on: linux/1.9.2p0

Probably something to do with an escape sequence.. Grr. What's the vimscript?

@nrocy
Copy link

nrocy commented Dec 29, 2010

Also been looking into this one, as my scores seemed too high :-P

VimGolf's score log seems to get prefixed with 3 extra bytes if you have 'set nocompatible' in your .vimrc

You can check if you're affected by noting the filename shown when you run 'vimgolf put', then 'hexdump -C' that file after Vim quits. Mine gets prefixed \x80\xFD\x35.

Analysis:

Comments in lib/vimgolf/cli.rb:67 seem to imply that -u NONE is/should be used to launch Vim, but then isn't. I'm assuming this is to retain things like 'filetype indent on', tabstop, etc.

Hack/work-around:

Copy your .vimrc to .vimrcgolf, modify it to remove 'set nocompatible' (I also had to remove pathogen stuff to avoid errors)

Modify $GEM_HOME/gems/vimgolf-0.1.1/lib/vimgolf/cli.rb
Add '-c ~/.vimrcgolf' to the param list on line 70.

Scores should be accurate now, check as above.

  • Paul

@clvv
Copy link

clvv commented Dec 29, 2010

or can we just manually check and remove \x80\xFD5 as for now?

@lmarburger
Copy link

I removed my ~/.vimrc and ~/.viminfo files and ~/.vim directory completely and my submissions are still prefixed with "\x80\xFD5".

Running OS X 10.6.5 here.

@joshtriplett
Copy link

See http://bugs.debian.org/608242 and http://groups.google.com/group/vim_dev/browse_thread/thread/9770ea844cec3282 .

You can work around this in non-GUI vim by adding "set t_RV=" to your .vimrc.

The GTK+ vim, and possibly other vim GUIs, seem to have a similar problem, though since the keystrokes arise from a different source the t_RV workaround won't help.

@igrigorik
Copy link
Owner Author

TERM=linux - @jordanlewis / https://github.com/igrigorik/vimgolf/issues#issue/31

Do we have a conclusion on whether it's safe to set the TERM?

@igrigorik
Copy link
Owner Author

3edca2f

This should do the trick. 0.1.3 now initializes vimgolf's .vimrc which should address the issue.

@joshtriplett
Copy link

Looks like vim 7.3.091 will fix this problem: http://groups.google.com/group/vim_dev/browse_thread/thread/c91310951bf30cd1

@igrigorik
Copy link
Owner Author

Josh, great detective work on this one! :-)

purcell pushed a commit to purcell/vimgolf that referenced this issue Nov 9, 2011
Parse C-0 etc. in addition to M-<key> sequences encoded in hex
filbranden referenced this issue in filbranden/vimgolf Aug 10, 2020
So it can show you that you're "#1 / 170" or "igrigorik#350 / 941", etc.
filbranden referenced this issue in filbranden/vimgolf Aug 10, 2020
So it can show you that you're "#1 / 170" or "igrigorik#350 / 941", etc.
filbranden referenced this issue in filbranden/vimgolf Aug 11, 2020
So it can show you that you're "#1 / 170" or "igrigorik#350 / 941", etc.
filbranden referenced this issue in filbranden/vimgolf Sep 1, 2020
So it can show you that you're "#1 / 170" or "igrigorik#350 / 941", etc.
igrigorik pushed a commit that referenced this issue Sep 16, 2020
* Include position in ranking for each challenge in user page

Additionally to showing the best player score and the best score for the
challenge, include the actual position of the best user score in the
ranking for that particular challenge.

Benchmarking: Created db:setup with challenges=300 users=10000, patched
db/seeds.db to have most challenges have a random number of entries in
the range 100..2,000, but 2% of them in the range 5,000..40,000, to
provide a more realist test scenario. (Creating all challenges with
20,000 entries just made all queries too expensive from the start.)

With that setup, I measured the effects of loading a user page, for a
user with entries in 36 challenges, which included all 6 challenges with
over 5,000 entries. More specifically, the 6 top challenges ranged from
17,829 to 37,251 entries.

I then loaded this page 10 times, with and without the changes in this PR.
I took the average and standard deviation of the 10 measurements for
each situation.

  - Without this PR:  0.25547s ± 0.00663s
  - With this PR:     2.23918s ± 0.05312s

This is a roughly 9x increase, which is perhaps quite expensive to make
it acceptable, even though the feature itself is very nice.

* Also count total golfers and display that with the ranking

So it can show you that you're "#1 / 170" or "#350 / 941", etc.

* Make ranking display optional

Only display them if ?ranking=1 is passed to a user URL.

The expensive query is only used in that case.
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants