No that is what I am saying. I don't want to publish yet On Feb 10, 2011 6:16 PM, "Jordan Wilberding" <[email protected]> wrote: > 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. >
-- 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.
