I think that is the current understanding. If it is, I completely agree with this being the official API.
Thanks! JW On Fri, Feb 11, 2011 at 7:24 AM, Eric Merritt <[email protected]>wrote: > Guys, > > > Just to follow up and have a good understanding of where we are. > > - Filter, if a filter function fails the entire filter fails. (I think > this is important behaviour) > - Map, There are to options/apis. If a map function fails the entire > map fails, and a second where tagged return values are returned, > exceptions become exceptions, good values are wrapped in ok. etc. > Where the user can choose the most correct option for his use case. > > Is this currently accurate? > Eric > > 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. > > -- 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.
