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.
