Mark, It is time for me to start learning about git. The bit I am struggling to understand right now is now to clone your repository to my personal space on github, can I do this from the web site?
Regards Rob > -----Original Message----- > From: Mark Pizzolato - Info Comm [mailto:[email protected]] > Sent: 27 May 2013 18:34 > To: Timothe Litt; Mark Pizzolato - Info Comm > Cc: Robert Jarratt; [email protected] > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > Hi Tim, > > On Monday, May 27, 2013 at 9:28 AM. Timothe Litt wrote: > > Hopefully, when the KDP is working Rob will merge (and if necessary > > debug) my changes & commit them to fix both problems. Ideally adding > > the page optimization, but beggars can't be choosers. If he doesn't > > I'll try to get to that later (if I have commit access to simh on github). > > You don't need commit access to the core repository on Github to get your > changes submitted and accepted. The github paradigm is: > 1) you create a personal account on github. > 2) you 'clone' the github simh/simh repository to your personal github > space. > 3) you clone either of these to your working environment and do your work > and check-in locally as desired/needed. > 4) you configure your local repo to have your personal github repo as the > primary push repo and the siimh/simh one as another remote repository. > Steps 2 and 3 can be in any order. > When you are ready to submit your changes, you: > 1) you pull from the simh/simh and merge to the latest codebase > 2) you push your local working repo to your personal github repo > 3) Using the github web UI you create a pull request for the github > simh/simh repo. This pull request will create an issue which will track the > details of what will happen. > I'll review the changes and either accept them as is and simply complete the > merge or I'll respond with some comments and/or suggestions and you can > make revisions until we're both happy and the merge will be completed. > Once the merge completes, each of your commits (with your name) will be > part of the repository/history. > > If you don't want to climb the learning curve of using git, I'll be glad to take > changes which I'd prefer be the complete files of any files you've changed > along with a description (as verbose as you may want) of the point of the > changes and I'll review and commit these using the description as the commit > message. I'll credit you in the commit comments, but the commit will have > my name on it. If you go down this path, you can send all of the files as > separate attachments or preferably bundle them in a zip file and send it via > email (there is no problem is you include extra files which you didn't actually > change since git will only notice the changed content anyway). > > Without regard to climbing the git learning curve, If you create a github > account and let me know you've done it, I'll add you as a contributor to the > project and assign issues to you where appropriate. If you create a github > account now, and create an issue at https://github.com/simh/simh/issues > describing the problems with Map_WriteW, I'll assign that issue to you and > when you ultimately submit fixes, the pull request you create can be the fix > to the issue... > > > I suppose I should see about building a current version, as I seem to > > be in the middle of debugging several things by Braille... (Or is > > this simply a memory test for me :-) > > Without jumping into git, you can always pickup the latest code at > https://github.com/simh/simh/archive/master.zip > > I look forward to anything you've got to offer. > > Thanks. > > - Mark > > > This communication may not represent my employer's views, if any, on > > the matters discussed. > > > > On 27-May-13 11:48, Mark Pizzolato - Info Comm wrote: > > > On Monday, May 27, 2013 at 6:19 AM, Timothe Litt wrote: > > >> This thread is getting far too messy. > > >> > > >> The increment problem found by Rob is NOT subtle. It's just plain > broken. > > > I agree 100%. > > > > > > The code, as written, would write twice as much simulated memory as > > intended which usually would crash things nicely (and did when Rob > > tried with the DMC). > > > > > > I found that the ONLY current use (prior to Rob's DMC) of this > > > routine was > > in the CD11 simulator and that use either might never actually get > > executed (if the CDCSR_V_PACK bit not been set), OR if it was actually > > executed it would have been with the constant byte count of 2 which > > should have written 1 16/18 bit word, but actually wrote 2 due to the > > bug. This may have never been exercised, OR writing the second word > > may have merely written the high bytes 18 bits of a word which was > > never referenced by the program... > > > > > >> The mishandling of the high bits is what I meant when I wrote 'subtle'. > > > Understood. > > > > > _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
