Collectible Card Game Headquarters

slapshot5 wrote:could this be because Wall of Hope doesn't have a newline character at the end of it?

i sincerely doubt it. svn can be used for all sorts of files, text, binary, etc.

slapshot5 wrote:Seems like it's got all the files though, right?

unfortunately, appearances are deceiving. running <<svn status>> shows that the cardsfolder directory is locked. if i kill the svn checkout, the locks are left in a bad state. i haven't been able to clean up lock files with much success.

I was able to update the cardsfolder last night at home, but now I can't on my work pc...

edit - I let it sit there and went on to something else.. it eventually updated, and claimed it only took 0:1:30 to complete...

I used this procedure:

http://glob.bushi.net.nz/glob/2007/02/1 ... orkaround/

when I once had a checkout problem in another project. It should help at least for the locks, I think. in a nutshell, checkout only the desired dir plus its parent into an empty directory, and then copy the contents, including the .svn dir into your real working copy.

What made the checkout not work in the first place, I don't know, but maybe the problem has to do with your working copy...

silly freak wrote:in a nutshell, checkout only the desired dir plus its parent into an empty directory . . .

i have already reduced the problem to a single folder, res/cardsfolder and its contents. i and others have had problems checking out this simple case.

silly freak wrote:What made the checkout not work in the first place, I don't know, but maybe the problem has to do with your working copy...

i find that exceedingly unlikely. if the problem description has no preexisting working copy, then the problem itself cannot lie in something that does not exist.

i believe the problem is the large number of files that cardsfolder contains. it is unusual to have a single directory with so many files. i think svn gets overwhelmed or times out, because it has to lock the parent directory until it has locked and unlocked all of its children.

i would like to experiment with changing the structure of cardsfolder.

we could organize it by using subdirectories for the first two characters in the cards' names. for example,
res/cardsfolder/a/f/affa_guard_hound.txt
res/cardsfolder/a/f/afflict.txt
res/cardsfolder/a/f/afterlife.txt
res/cardsfolder/a/f/aftershock.txt

i am comfortable modifying ReadCard.java so that it loads the cards from the proper places. (i know the last time i touched ReadCard was a fiasco, but this would be a smaller change.)

i can write a shell script to automatically move cards into these subdirectories from res/cardsfolder. this script would be executable under Linux, MacOS, and Cygwin.

would this affect existing tools too much? i see a couple of Python scripts. i love how it highlights Python.

The ReadCard code should only need a slight modification to wrap the existing card iteration code with a folder iteration. Unless someone's already changed it, there's likely more "for-get(i)" stuff that would be better converted to for-each, while you're in there....

Notice ReadCard doesn't care at all what the filename is, and therefore should not care about the folder either. It's just for human comfort of finding what you're looking for.

edit- thinking about it, just go with the first letter... We never had any issues until recently, so we know a single folder is good for at least a few thousand files.

Oh, and friarsol's the python-head around here.... It's neat stuff and can parse webpages like there's no tomorrow... but those scripts were the only reason I would've ever considered installing it on my system.

Rob Cashwalker wrote:The ReadCard code should only need a slight modification to wrap the existing card iteration code with a folder iteration. Unless someone's already changed it, there's likely more "for-get(i)" stuff that would be better converted to for-each, while you're in there....

bundling changes? Rob, "I'm shocked, shocked to find that gambling is going on in here!"

seriously, i'll clean the code up first, commit, and then change it. i have to do something while my script runs.

Rob Cashwalker wrote:edit- thinking about it, just go with the first letter... We never had any issues until recently, so we know a single folder is good for at least a few thousand files.

ok, 26 folders it is. i'm updating my working copy of the trunk now.

Rob Cashwalker wrote:Oh, and friarsol's the python-head around here.... It's neat stuff and can parse webpages like there's no tomorrow... but those scripts were the only reason I would've ever considered installing it on my system.

Python is an interesting language, but i am a static typing kind of girl. i find its postmodernism unsettling. C++'s upcoming "auto" keyword looks neat. way off topic.

Python is an interesting language, but i am a static typing kind of girl. i find its postmodernism unsettling. C++'s upcoming "auto" keyword looks neat. way off topic.

... and way over my head...

I'm a VB-kinda-guy.

i think in upcoming versions of C++, one can use the first form instead of the second:

Code: Select all

auto var = new ReallyLongClassName();
ReallyLongClassName var = new ReallyLongClassName();


auto indicates the compiler should automatically infer the type of the variable.

Python-head? I'm probably more of a Monty Python head than a Python Language head. But it is a handy tool, to be able to script things. The three py scripts that live in the /res/ folder would all need some altering if there is going to be a cardsfolder structure change.

They can probably be changed to some sort of routine to just grab all files that don't start with '.' and end in '.txt' in a directory (and all subdirectories), so in the future if more structure changes occur the files won't need to.

Sol, can you go ahead and update the Python scripts? i'm about to check in the changes to ReadCard and to res/cardsfolder.

Braids wrote:Sol, can you go ahead and update the Python scripts? i'm about to check in the changes to ReadCard and to res/cardsfolder.

I'll try to make the changes tonight at some point. The three scripts all work slightly differently when dealing with files, so I'll have to actually test them separately.

Rob Cashwalker wrote:there's likely more "for-get(i)" stuff that would be better converted to for-each, while you're in there....

i didn't find anything using get(i), but there was some iteration over a large array. i updated that to not only use for-each, but also replaced the large array with a generator. this was all made possible by the python-yield java-yield library. without it, we would have to write methods that return iterators instead of collections. without the concept of yielding, this is very difficult for all but the simplest of operations.

python-yield java-yield provides a mechanism for converting generators to iterators, so they can then be used with foreach.

edit: fixed typos as shown.

See, there you go again... waaayy over my head. Though I'm not too sure we should keep adding more library requirements...

Braids wrote:

Rob Cashwalker wrote:there's likely more "for-get(i)" stuff that would be better converted to for-each, while you're in there....

i didn't find anything using get(i), but there was some iteration over a large array. i updated that to not only use for-each, but also replaced the large array with a generator. this was all made possible by the python-yield library. without it, we would have to write methods that return iterators instead of collections. without the concept of yielding, this is very difficult for all but the simplest of operations.

python-yield provides a mechanism for converting generators to iterators, so they can then be used with foreach.

It is true that the "yield" mechanism makes certain iteration functions much easier. My only concern is that the java-yield jar appears to be relatively unsupported. For the maven build, I added it to my repo (http://arcane.googlecode.com/svn/trunk/repository/) so the builds go smoothly.

If anyone adds a dep, please post a note to the forum so I can add it to the Maven build.

Thanks
Dave

Edit - I tried a dryRun of the release process and there is an issue with the jyield jar. since it is a "SNAPSHOT", Maven does not want to use it as part of release. There is a workaround, but it required more attention during the release build.

Chris H. - the release process will ask to "resolve SNAPSHOT dependencies (yes/no) :no" Note that it will default to "no" and then the build will fail. You will need to enter "yes" manually at this point. I will investigate to see if I can use a flag to skip that question.

I can re-jar it if you want