So Pascal, Ramsey, and fellow members of the Wonder gang, If I were to teach a course and should need recommendations for the way to teach and learn Git; what packages, books, online references, etc would you recommend as a kind of training wheels for said students? Also, if I were to produce an iBook and its Android equivalent form of our WO book with clips from the the tutorials, what all would I need to do it?
V/R, Daniel Beatty, Ph.D. Computer Scientist, Detonation Sciences Branch Code 474300D 1 Administration Circle M/S 1109 China Lake, CA 93555 [email protected] (LandLine) (760)939-7097 (iPhone) (806)438-6620 On 4/1/13 11:27 AM, "Pascal Robert" <[email protected]> wrote: > Le 2013-04-01 à 13:02, Ramsey Gurley <[email protected]> a écrit : > I > merged the fix to the master and integration branches. As far as I can tell, > I've got everything done except pushing the tag on master. It just wasn't in > my push configuration. I can try again when I get home tonight. > > As for > releasing other integration changes, I tend to use eGit for everything. Is > there anything in that command line magic which wouldn't happen if I just make > a local branch at a9426 and merged that into master? I don't use eGit anymore > for commits or branching, I use it only to check the history in Eclipse or to > see the status of the files. For preparing a release of Wonder, I always did > it by command line. For everything else, I use SourceTree. > Ramsey > > On > Apr 1, 2013, at 9:44 AM, Pascal Robert wrote: > >> In that case, do a real > 6.0.3 release >> >> Switch into the master branch >> >> Check the Git > history of the integration branch and note the last commit that should be > integrated into master (a9426b5ed8a806b6a7292209f8783416bce1a046 is a good > candidate for 6.0.3). >> >> Do a merge with the commit id of the previous > step: git merge -s recursive -Xpatience -Xtheirs XXXXXX >> >> Push the > release candidate to GitHub: git push origin master >> >> Tag the merge > with a "wonder-6.x.x" tag: >> >> git tag -a wonder-6.x.x >> git push > --tags >> >>> And evidently, I didn't configure my push to push the new 6.0.3 > tag :P >>> >>> Anyway, try the latest master Freddie and see if your problem > goes away. >>> >>> Ramsey >>> >>> On Mar 30, 2013, at 3:17 PM, Ramsey Gurley > wrote: >>> >>>> >>>> On Mar 30, 2013, at 11:18 AM, Ramsey Gurley wrote: >>>> > >>>>> >>>>> On Mar 29, 2013, at 3:37 PM, Ramsey Gurley wrote: >>>>> >>>>>> > On Mar 29, 2013, at 2:27 PM, Freddie Tilley wrote: >>>>>> >>>>>>> at > er.modern.directtoweb.components.header.ERMD2WSimpleHeader.headerString(ERMD2W > SimpleHeader.java:25) >>>>>>> >>>>>> >>>>>> My wonder says that line > is: >>>>>> >>>>>> return > stringValueForBinding(Keys.displayNameForPageConfiguration); >>>>>> >>>>>> > What is your rule for displayNameForPageConfiguration? It doesn't look like > your stack trace goes through ERDDefaultDisplayNameAssignment. >>>>>> >>>>>> > Kieran, >>>>>> >>>>>> This also looks like a bug in wonder. ERXGenericRecord > doesn't handle a null editingContext() in handleQueryForUnboundKey(). That's > going to be the case on deleted objects. >>>>>> >>>>>> I think that should > just check entity().primaryKeyAttributeNames().contains(key) first. That > method is called a lot and there's no reason to be building pk dictionaries > every time. This shouldn't wait for the next integration merge. >>>>>> >>>>>> > Ramsey >>>>> >>>>> Hmm, even calling entity() repeatedly is going to add > overhead. Adding a private static >>>> >>>> er.. transient :P Can't be static > since every eo would share the same entity. >>>> >>>>> entity var may be > needed to cache the EOEntity and prevent constantly searching through the > models :-/ The other problem I see is that entity() may result in null when > there's no ec and the entity is not in the default model group. Not sure how > often that happens. >>>>> >>>>> I'm thinking this method should look > something like to prevent the NPE: >>>>> >>>>> public Object > handleQueryWithUnboundKey(String key) { >>>>> // Handles primary key > attribute values >>>>> if(entity().primaryKeyAttributeNames().contains(key)) > { >>>>> // Deleted object. Return null. >>>>> if(editingContext() == null) > { >>>>> return null; >>>>> } >>>>> NSDictionary pkDict = > EOUtilities.primaryKeyForObject(editingContext(), this); >>>>> // New > object. Return null. >>>>> if(pkDict == null) { >>>>> return null; >>>>> > } >>>>> // Return value for key >>>>> return > pkDict.objectForKey(key); >>>>> } >>>>> return > super.handleQueryWithUnboundKey(key); >>>>> } >>>>> >>>>> Alternately, is > this something that we could simply remove and put into an eogen template for > anyone who needs this? The more I look at this the less I like it. This method > is going to get called a ton for any ERD2W app that uses object.someKey in > rules. >>>>> >>>>> In my ERUsers framework I have >>>>> >>>>> 55 : > (pageConfiguration = 'CreateERUser' and propertyKey = 'clearPassword' and > object.password.length > 0) => componentName = "R2D2WPropertyMessage" > [com.webobjects.directtoweb.Assignment] >>>>> >>>>> Which means the current > method is called and creating a pkDict for every single property level > component on every single page that isn't an ERUser. I just tested it on a > ListMovie page. On a ten item page, handleQueryWithUnboundKey is called 960 > times. >>>> >>>> Also, I obviously need to change the way I'm doing > componentName here because even creating 960 UnknownKeyExceptions is just > excessive. >>>> >>>>> This is not good. This method needs to be very fast or > it needs to be removed. >>>>> >>>>> Ramsey >>>>> >>>> >>>> > _______________________________________________ >>>> Do not post admin > requests to the list. They will be ignored. >>>> Webobjects-dev mailing list > ([email protected]) >>>> Help/Unsubscribe/Update your > Subscription: >>>> > https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.c > om >>>> >>>> This email sent to [email protected] >>> >>> > _______________________________________________ >>> Do not post admin requests > to the list. They will be ignored. >>> Webobjects-dev mailing list > ([email protected]) >>> Help/Unsubscribe/Update your > Subscription: >>> > https://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca>>> > >>> This email sent to [email protected] >> > > _______________________________________________ Do not post admin requests to > the list. They will be ignored. Webobjects-dev mailing list > ([email protected]) Help/Unsubscribe/Update your > Subscription: https://lists.apple.com/mailman/options/webobjects-dev/daniel.be > atty%40navy.mil This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
