Ok, I reviewed your code. It is technically correct and accepted. However, are we going to wait to hammer out the details of the api before we publish this? I would prefer that. However, if you can argue that we should publish now, I am willing to consider it.
Thanks! JW On Thu, Feb 10, 2011 at 5:18 PM, Martin Logan <[email protected]>wrote: > The tree is all set. But, I think more work needs to be done on the > function and its api. Basically filter and map need to return error > reports for practicalities sake for non application level events like > errors. I will also be exploring the map API and the option for > changing the behaviour from atomic to async. I will be doing this. > > On Thu, Feb 10, 2011 at 7:12 AM, Jordan Wilberding > <[email protected]> wrote: > > I'm not sure what you are doing, but your master is still out of sync. > Did > > you forget to push? > > diginux@heisenberg:~/code/erlware$ git cherry -v HEAD > martinjlogan/master > > + ea9a1567d0ff61270291b6c6d9c178f1c71e9ee7 added in remove and depricated > > delete_dir as well as refactored > > + b20b09d86246ca6658c84d80c4eb6c4b2d97e5c6 udpated version > > + a96f376e950bf1b835e848ce2aa68bd1f817cbf5 fixed indentation > > + 9d9cc2562b1e2883b8bb0803f2063850091cbf69 fixed use of record tuple > > + b2b2af682aac96903951be77d64f6fb23be8cc88 updated version > > + e4841d3c379c5d2faf06b23354a0d07896c8a634 refactoring of ewfile > functions > > and docs > > + b54badeb5dcf9838b25a6d96fdf785d8e3cc5dd5 updated plists to handle > > exceptions > > If you look at the commit log, you'll clearly see duplication of > > patches: https://github.com/erlware/erlware/commits/master > > The thing is, you already have those duplicated patches, they are just > under > > different commits: > https://github.com/martinjlogan/erlware/commits/master > > The best example from above is: +ea9a1567d0ff61270291b6c6d9c178f1c71e9ee7 > > added in remove and depricated delete_dir as well as refactored > > This exists both in your commit log as well as canonical as this > > commit: > https://github.com/erlware/erlware/commit/eb317801f159a87839d55ef42af9978c19980863 > , > > but yours > > is > https://github.com/martinjlogan/erlware/commit/ea9a1567d0ff61270291b6c6d9c178f1c71e9ee7 > > These need to be resolved before I will review. > > Thanks! > > Jordan Wilberding > > On Thu, Feb 10, 2011 at 8:03 AM, Jordan Wilberding < > [email protected]> > > wrote: > >> > >> In my opinion, if there is a timeout, the whole thing should fail. With > >> pmap, we are the ones adding the new avenue for error; therefore, I > think we > >> should mimic behavior of map as much as possible and completely bail on > >> errors that occur from additional processing that is done because of the > >> parallel nature. > >> As a compromise though, I think pmap should do that behavior. There is > no > >> reason why we can't have a pmap that takes the option of not failing on > >> timeouts. > >> I'll review your code, but I want to decide this issue before we publish > a > >> new version. > >> Thanks! > >> Jordan Wilberding > >> > >> On Wed, Feb 9, 2011 at 11:52 PM, Martin Logan <[email protected]> > >> wrote: > >>> > >>> I have updated pmaps for exceptions. I actually ended up useing the > >>> second approach of adding a return class to results to differentiate > >>> exceptions and normal flow so the code is different from yesterday. > >>> You can find this code in the master of my repo. It should now be a > >>> fast forward from the erlware/master head. There is something else I > >>> want to bring up in terms of the design of this module. > >>> > >>> The module currently handles timeout in two conflicting manners. In > >>> map a timeout is returned in the final mapped list as if it were > >>> application level. Filter, it treats timeout like false and excludes > >>> it from the returned list; which is not congruent with how map treats > >>> it. Why not treat timeout like true and include timeout in the list as > >>> further application level results like in map? The choice is not > >>> consistent in this module currently. > >>> > >>> If a process does not return a value perhaps it should be excluded > >>> from the results of map. A map presumes a map across all elements. If > >>> one does not work adding in 'timeout' as a substitute is not strictly > >>> correct. In any case it appears to me that there are two modes that > >>> seem correct: > >>> > >>> 1. asyncronous, excluding timeout and not treating it as an > >>> application level return value > >>> 2. atomic/syncronous such that all operations/processes must succeed > >>> in that they return an application level result or the whole plist > >>> operation fails. > >>> > >>> I will admit that having the timeouts is valuable but returning them > >>> simply as timeout, when that could actually be an valid return value > >>> from a process that does not timeout is not good practice. At the > >>> least, given erlangs lack of types which hurts in this case, returning > >>> something obscure like gen_server:cast does underneath makes sense; > >>> something like '$timeout$' as ugly as that is. > >>> > >>> Cheers, > >>> Martin > >>> > >>> > >>> -- > >>> Martin Logan > >>> Erlang & OTP in Action (Manning) http://manning.com/logan > >>> http://twitter.com/martinjlogan > >>> http://erlware.org > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > Groups > >>> "erlware-dev" group. > >>> To post to this group, send email to [email protected]. > >>> To unsubscribe from this group, send email to > >>> [email protected]. > >>> For more options, visit this group at > >>> http://groups.google.com/group/erlware-dev?hl=en. > >>> > >> > > > > -- > > You received this message because you are subscribed to the Google Groups > > "erlware-dev" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > > http://groups.google.com/group/erlware-dev?hl=en. > > > > > > -- > Martin Logan > Erlang & OTP in Action (Manning) http://manning.com/logan > http://twitter.com/martinjlogan > http://erlware.org > > -- > You received this message because you are subscribed to the Google Groups > "erlware-dev" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/erlware-dev?hl=en. > > -- You received this message because you are subscribed to the Google Groups "erlware-dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/erlware-dev?hl=en.
