[Home] [Downloads] [Search] [Help/forum]

Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ MUSHclient ➜ Bug reports ➜ Windows 7: improvements and suggestions
Windows 7: improvements and suggestions

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1  2 

Posted by Nick Gammon   Australia  (23,046 posts)  Bio   Forum Administrator
Date Reply #15 on Mon 07 Dec 2009 11:23 PM (UTC)

Amended on Mon 07 Dec 2009 11:26 PM (UTC) by Nick Gammon

Message
Larkin said:

However, I'm moving MORE towards MFC and standardizing all the non-MFC stuff (Nick tends to lean toward STL these days) to use MFC classes instead.


MFC is very good to get things up quickly, like dialog boxes. The whole thing is fine if you don't mind being locked into a development platform you have to spend hundreds of dollars on every few years to upgrade, and only works on Windows, and not OS/X or Linux.

As for STL, you can of course intermix them. MUSHclient these days uses the MFC classes for lists, etc. for older stuff, and is moving towards using STL classes for more modern things.

Some of the list management in MFC is clunky, and it is hard to just convert to STL (they may have improved it). For example, when traversing a list you have to get the start position, *and* then the first item as two operations, like this:


    // tell each plugin what we have received
    for (pluginpos = m_PluginList.GetHeadPosition(); 
         pluginpos; )
      {
      CPlugin * pPlugin = m_PluginList.GetNext (pluginpos);


      // process plugin here (in pPlugin)

      }   // end of doing each plugin


Compare to STL:


      for (it = LuaFunctionsSet.begin ();
           it != LuaFunctionsSet.end (); 
           it++)

         {
          
         // process function here (in *it)

         }   // end of doing each Lua function


The difference is that in the MFC version you have to get the pointer to the data *and* move the position onwards at the start of the loop. So, if the data happens to be the one you want you can't "remember" the position because it has already been advanced.

And, I can't move the GetNext into the for statement, because that is processed at the end of each iteration, and the GetNext has to be done at the start of the iteration.

In my example, pluginpos is now pointing to the *next* entry, while I process pPlugin.

However in the STL version, it (the iterator) is pointing to the *current* entry while I process *it (the data it points to).

This difference makes it fiddly to change to/from STL/MFC list operations without carefully thinking about what happens if you want to leave the loop early.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Larkin   (278 posts)  Bio
Date Reply #16 on Fri 11 Dec 2009 08:10 PM (UTC)
Message
All good points, and I'm pretty well aware of the differences already, having used both for many years now. I still just find MFC easier for my own uses, and I don't mind being locked into the platform. (Cross-platform gets too messy too quickly for me to really even consider it when just coding my own stuff for fun.)

Microsoft has made some advancements with their use of ATL and WTL now, too.

I really like the MS coding practices, and I get a little sloppy when I start pulling in things like Boost or STL. It's just who I am.
Top
Posted by Dylnuge   (1 post)  Bio
Date Reply #17 on Mon 28 Dec 2009 09:05 PM (UTC)
Message
Twisol said:

EDIT: Also, it would be a LOT more conducive to the 'open source' nature of MUSHclient to have a public repository anyone could pull from to check out the current source. I especially love Git (and Github), and am using it for my widget framework development. Anyone can 'fork' the project, i.e. copy the repository (but retain versioning links), and you can merge branches, etc. I think it would fit MUSHclient perfectly... Maybe you should check it out?


That would be nice. Not sure if it has to be Git or Github though, since Bzr has Launchpad and SVN (if you don't want to use DVCS) has Sourceforge. Plus, there are alternatives to Github too, though I happen to like Github.

Is the project currently SVN? Switching to a DVCS isn't too challenging from SVN, though I've yet to transition a major project over.
Top
Posted by Nick Gammon   Australia  (23,046 posts)  Bio   Forum Administrator
Date Reply #18 on Mon 28 Dec 2009 09:58 PM (UTC)
Message
It's currently CVS, hosted on my inhouse private server. I don't want to open that server up to the world, however I don't mind uploading the current version to somewhere, and then committing further changes to that place instead.

So, if we just take a snapshot of the current source, whether it is CVS or anything else doesn't really matter. The only way it would matter would be if someone wanted to compare (say) version 4.45 to version 4.38.

For me to host the source somewhere public I would need a system that I can put on the gammon.com.au web server. David Haley previously put up a BZR repository, however my mind had a bit of a brain freeze when I tried to understand how to use it.

I prefer to keep control over the source in the sense that I would like it to be on a server (like this web page) over which I control to the extent that ads don't appear, and that if I keep paying the bills, it will stay active.

Now if anyone wants to recommend a system that I can install on the Futurequest server, that will be easy for me to upload future changes to, please do. It would need to use:


  • PHP for the web pages
  • MySQL for the database (if any)
  • Probably not require some other server running, as Futurequest may not permit that (although I could be wrong about that)

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #19 on Tue 29 Dec 2009 03:20 AM (UTC)
Message
All of the version control systems discussed so far have web interfaces that let you explore the repository, so you don't have to use GitHub, Launchpad, SourceForge, etc.
You could move your CVS repository as-is and use one of the web packages (might be perl, not PHP) for online browsing.

Personally I would recommend against SVN since its branching is (in my experience at least) still kind of nasty, while being far nicer than CVS. You can always use DVCS programs like plain old VCS, where you have a single master copy and only commit to that, and don't bother with branching etc.

That said, I'm not sure what the exact goal is here. Is it realistic to think that somebody will fork the code, and it will later get merged in as-is? I think it's more realistic that patches will be accepted (with modifications etc.) in which case it doesn't really matter what VCS everybody is using. I think people can use VCSs for their own work, of course, as it makes tracking patches far easier, but I'm not sure that the work-required to benefit-obtained ratio is a good one yet.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #20 on Tue 29 Dec 2009 06:31 AM (UTC)

Amended on Tue 29 Dec 2009 06:46 AM (UTC) by Twisol

Message
As a matter of opinion, I would like to mention that GitHub is (a) free for open-source projects, and (b) you can take down the repository if you really feel like it. Git itself is actually quite easy to use, and I'm surprised at how easily I got into it after reading a couple of the tutorials at GitHub. In relation to David's mention of SVN's branching, Git branches are really quite wonderful.

I'm just curious, but is there any particular reason you want to host the repository directly on gammon.com.au? Like I said, you have a pretty high degree of control over the repository's existence with GitHub hosting. And really, GitHub is just a public face - since git is decentralized, you really have a whole repository on your computer, which you can locally commit to, etc, etc, and only push upstream (to the public repository) when you're ready. (I'm planning on having two public branches for my framework, stable and development, and merging from development to stable to mark official changes and updates. The development branch would be visible so that anyone could still see and check out the source of what's coming. It's really, really simple.)

EDIT: I should note, the public repository on GitHub is public only for reading; only approved collaborators can directly push to it, such as yourself.


David: It's not that unrealistic to expect interested parties to fork the code. At the very least, you can pull a copy of the code down to look at, which is one great benefit. And if you decide to make your own changes to it, there's no reason not to make a public fork. It helps to share ideas and innovation, even if briefly; WillFa forked my widget framework a while back in order to make a fix to the source, which I incorporated afterwards.


Nick Gammon said:
So, if we just take a snapshot of the current source, whether it is CVS or anything else doesn't really matter. The only way it would matter would be if someone wanted to compare (say) version 4.45 to version 4.38.

Not exactly a huge issue, considering that nobody can do that easily now anyways except by going backwards through the released source downloads. (As an aside, another big reason I'd love a public repository is because I can actually see the source after every release. Most source releases currently skip several versions... and the diffs file for 4.45 hasn't been released, at any rate, so at the moment you couldn't keep a local up-to-date copy if you tried. ^_^;)

<this part is optional to read>
Here's an example of a typical workflow for me with Git:

1. Make changes, test, typical stuff...
2. git status - see what files I changed, and if there's anything I created that needs to be added to the repository.
3. git diff <filename> - see what exactly I changed, helps when I'm reviewing my changes and/or writing a commit summary
4. git commit -a - commit my changes straight to the local repository. The -a flag just skips the 'staging area', which I haven't had a need for yet.
5. Return to 1 if I'm not ready to push to GitHub just yet, say, if I just want to save my work.
6. git push origin development - Push my changes in the development branch up to 'origin', i.e. the GitHub repository.

Only really a handful of commands. It all feels very easy when I actually do it, and I haven't been using it that long at all. (SVN always confused me regularly.)
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,046 posts)  Bio   Forum Administrator
Date Reply #21 on Tue 29 Dec 2009 07:15 AM (UTC)
Message
Twisol said:

... and the diffs file for 4.45 hasn't been released, at any rate, so at the moment you couldn't keep a local up-to-date copy if you tried. ^_^;)


The various library changes meant the diff would have been megabytes long, so a full source release is probably required.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #22 on Tue 29 Dec 2009 07:17 AM (UTC)
Message
Makes sense, it was just an afterthought. My point being, a publicly accessible system would eliminate the need for either diffs or source releases.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #23 on Tue 29 Dec 2009 01:45 PM (UTC)
Message
Quote:
David: It's not that unrealistic to expect interested parties to fork the code.

Well, sure, except that that the last time we went through this and I started maintaining a public repository tracking the released diffs, interest level was basically zero after the initial statement of "it would be nice if ...". :-)

FWIW, I'm not arguing against the idea of repositories in general. I'm simply observing that the development pattern for MUSHclient thus far, where changes are quite localized, has not seemed to make the need for forking very high. You say it's not unrealistic to expect people to fork, but, well, in practical experience so far it actually is.

Frankly, if even just the cvs repository were publicly available, the (vast?) majority of these benefits would be available without needing to change anything for Nick other than simply making the repository available. MUSHclient is so mature in its core development that it's rather unlikely for forks to appear; empirically speaking, changes suggested to Nick so far tend to be captured in rather small patch files. Major changes have always been made by Nick himself in almost atomic units, and released shortly thereafter, where it doesn't really matter if changes are available the second he commits them internally. It's actually rather unsurprising to me that the widget framework was forked, as that is a far more dynamic project (in terms of heavy, active development).

Basically, I think that the benefits in this particular case might be being conflated a bit with the benefits in general.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Worstje   Netherlands  (899 posts)  Bio
Date Reply #24 on Tue 29 Dec 2009 03:24 PM (UTC)
Message
One big reason I haven't contributed other than downloading to glance through the code once in a while, is that getting it to a compiling state is a pain in the ass. If there were a public repository which was in a 'ready-to-go' state for a recent compiler (VS2005/VS2008/VS2010), I'd implement at least some of the features I've suggested over the years that Nick didn't feel were worth his time.
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

69,553 views.

This is page 2, subject is 2 pages long:  [Previous page]  1  2 

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]