Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - RetroX

Pages: [1] 2 3 ... 70
1
Off-Topic / Brilliant.
« on: April 13, 2012, 09:00:34 PM »

2
Questions:
  • Can varargs contain zero values?
  • Can varargs be statically typed? (i.e., varargs<double> instead of varargs<var>) ?
  • Will varargs be a variable-storage type (i.e., std::vector) or static arrays?

3
Announcements / Re: Why does it look like nothing's happening?
« on: March 11, 2012, 11:32:08 AM »
We're pretty much all in agreement with regards to the jars. I'm not sure about wgetting them from the makefile though - it's not that simple. The jars update occasionally - maybe once every 5-10 revisions. This means that we might not want to fetch them every time the user invokes make, because that would add an additional download time that usually just results in the same jars. We obviously don't want to do it as a 1-time thing because sometimes the updates are critical. We'd probably want some sort of intermediary to determine if the jars should be updated. Fetch some small information that determines the latest version, and compares it to the user's current version.
Code: [Select]
wget lgm.md5
if md5sum -c --quiet lgm.md5; then
  wget lgm*.jar
fi
For the Linux version, anyway. The Linux version should be managed via the makefile, whereas the Windows version of LGM should just update itself.
(windows/linux "version" meaning when used on said platforms)

4
Announcements / Re: Why does it look like nothing's happening?
« on: March 08, 2012, 11:17:47 PM »
For the record, git apparently does have binary diffs, but compiled code is usually different enough that you might as well be dumping the entire file there. Dumping small things like images is okay, but dumping entire JARs is really what we want to avoid.

LGM and the like should be compiled from the repositories and zipped and uploaded somewhere on the site. I don't see what's wrong with wgetting them from a makefile.

5
Announcements / Re: Why does it look like nothing's happening?
« on: March 04, 2012, 10:34:03 AM »
I don't understand why Mercurial would even be brought up at all. Mercurial is worse with storing any kind of file (as size is concerned), and switching to it would be extremely counter-productive.

6
General ENIGMA / Re: ENIGMA IS A MAZE
« on: February 24, 2012, 08:39:25 PM »
Windows does WinMain because it differentiates between console and graphical applications. Linux doesn't. :P

You can technically still use main() with a Windows application, but it's usually messier.

7
Announcements / Re: Main Progress [Stalled because we can't Git]
« on: February 24, 2012, 08:38:10 PM »
I worded that terribly, but both of you pretty much understood what I meant. :P

8
Announcements / Re: Main Progress [Stalled because we can't Git]
« on: February 24, 2012, 12:30:01 PM »
Not sure why you guys insist on using Git. The company I work for makes me use git for source control, I hate it with a passion. To me, SVN simply works better (much less bull to deal with).
Why, exactly? Git acts almost like a subset of SVN; anything that can be done with SVN can be pretty much done with Git. The extra levels of complexity make things a lot easier, and it's far easier to compare revisions (which is what revision control is for).

9
Announcements / Re: Main Progress [Stalled because we can't Git]
« on: February 19, 2012, 09:47:15 AM »
For the record, I fixed the dependencies for the Install#Linux page. :V

10
Announcements / Re: Update
« on: February 04, 2012, 10:04:29 PM »
where do I start on this flow chart

11
Announcements / Re: New GitHub Repository
« on: January 16, 2012, 08:17:58 PM »
Random addition to the guide: git stash "stashes" existing changes whereas git stash pop will apply stashed changes. You can do git stash drop to just delete the stashed changes without applying them or git stash apply to apply stashed changes without dropping them. Stashes are stack-based, meaning that you can push several stashes onto the stack and pop them in a FILO (first-in, last-out) manner.

Also, fix the teletype tag. :(

12
Announcements / Re: New GitHub Repository
« on: January 07, 2012, 08:10:07 PM »
Notice: You'll probably all have to re-clone now that I've removed the versioned binaries from the commit history. The clone size is half what it was, now.

13
Announcements / Re: New GitHub Repository
« on: January 07, 2012, 06:16:41 PM »
Also, random thing that I found out the hard way:

If you're just interested in getting the latest revision (no version control), you can run:
Code: [Select]
git clone git://github.com/enigma-dev/enigma-dev.git --depth 1This will essentially download an unversioned copy of the latest revision.

This will prevent you from downloading all of the commits, which would be pretty big. It has a downside, however, of preventing you from pushing commits to the master repo.

14
Announcements / Re: New GitHub Repository
« on: January 07, 2012, 11:04:05 AM »
We will see how this goes. I didn't like that I will have problems committing conflicted data, or that I can't revert changes when I move everything in the destination repository, but maybe I just didn't quite clearly understand. It was easy for me to understand SVN as it has only one button - Commit. You choose the files you want to commit, write a description of the changes and sit back (takes a few seconds to finish). I don't really need new "features" in this process, so I was fine with it before.

I probably didn't explain that properly.

What I meant is that the git equivalent of "svn checkout" is really a complete clone of the repository. This means that you can check back older revisions without downloading any new stuff, and you can commit/uncommit/amend commits as much as you want before you push it back to the origin repo. The problem with this is that, for example, you clone the repo and then uncommit something that's already on the dest repo, it'll give you a bit of trouble. But in most cases, people won't want to (or even know how) to uncommit something or amend a commit.

In svn, the default is to commit ALL changes to the server, whereas in git, the default is to not commit any changes unless you specifically say so (allowing you to selectively commit files). If you just want to commit everything, git supports that, too.

The new features can be made transparent to most users, but can be made very useful to other users.

15
Announcements / Re: New GitHub Repository
« on: January 06, 2012, 09:09:27 PM »
Soo how exactly committing changes will work? In SVN it was extremely easy.. I suspect it will be as easy in GIT too? For example, I am on Win and want to have a GUI program (its just nicer) to commit a change to the repository. What steps would I use?
TortoiseGit is designed like TortoiseSVN with a very similar interface, intended for git instead. I don't quite know how either works, but I'll explain the main difference between git's committing and SVN's. Git has more options, but you can still commit in what's mostly the same way as SVN.

SVN commits are centralised, meaning that you have to send the commits to the central server for them to count. SVN only has one way of committing: you can add files that haven't yet been versioned (which will then make them versioned) and then commit, which will commit all modified or newly versioned files.

Git operates on a series of local repositories. This means that with Git, you "clone" the source repository, mess with it however that you want, and then push all of your changes to the destination repository. Through this process, you can make as many commits as you want, amend your commits, and even uncommit what you've done. However, once you move the changes to the destination repository, you're pretty much stuck with those commits. If you uncommit or amend things that are already on the destination repository, you'll have a hard time getting the repository to actually push new changes, because the changes don't match.

Git commits operate as staged and unstaged changes; essentially, anything that you've changed but haven't "staged" won't actually be committed. For example, if I modifed file1 and file2, which are versioned, adding a new commit won't commit those changes that I've made unless I explicitly ask for it (that's SVN's behaviour; you can still do this if you want). You also have to add new files, like SVN. Note that if you modify or delete a file after you stage it, those changes won't be applied until you stage it again. Once you commit something, you have to send it to the destination repository for it to actually be "committed" to the overall repository.

I'm assuming that things like TortoiseSVN and TortoiseGit already support a mechanism for "commit all," which will essentially just stage everything, commit, and push to the master repo, with a given commit message. Git largely replicates the functionality of SVN, although, it has a lot more features and operates slightly differently. It's also a lot faster and compresses things, making it easier and faster to pull from the remote repos.

Pages: [1] 2 3 ... 70