darcs

Patch 1335 resolve issue 1721

Title resolve issue 1721
Superseder Nosy List alain91
Related Issues
Status in-discussion Assigned To
Milestone

Created on 2015-05-08.19:52:06 by alain91, last changed 2015-07-15.17:49:02 by alain91.

Files
File name Status Uploaded Type Edit Remove
Progress.diff alain91, 2015-07-15.17:49:01 application/octet-stream
progress.diff alain91, 2015-05-08.19:52:06 application/octet-stream
unnamed alain91, 2015-06-14.14:04:01 text/html
See mailing list archives for discussion on individual patches.
Messages
msg18402 (view) Author: ganesh Date: 2015-05-12.06:54:12
Thanks a lot for your patches!

Would it be possible to resubmit them as native Darcs patches? You can do this with the 'darcs 
send' command.

I haven't been through them in detail yet but I noticed one thing in this patch:

>      toobig :: Int -> [a] -> Bool
> -    toobig 0 _ = True
> -    toobig _ [] = False
> -    toobig n (_ : xs) = toobig (n - 1) xs
> +    toobig s v = ((length v) > s)

I think the existing code is the way it is for laziness: as soon as it sees that the list is 
longer than 'n' elements, it stops evaluating it further. With the change, the whole list would 
first have to be evaluated before we knew if it was too big or not.
msg18444 (view) Author: bf Date: 2015-06-11.16:58:38
I have been playing with this patch. The only difference I noted is that
progress reporting when I do e.g. darcs get http:/darcs.net is more
frequent than before.

Unfortunately, for reasons mysterious to me, it breaks the zsh
completion, even though the output of darcs --commands is the same when
i pipe it into a file. Hmm.

I'd also like to ask the author to explain what the patch does and in
which way it improves upon the existing progress handling.
msg18447 (view) Author: bf Date: 2015-06-11.17:22:44
I see now that this is supposed to resolve issue1721. Was the problem
that the background thread was killed off prematurely when darcs
finished and thus the new solution avoids creating a thread in the first
place?
msg18492 (view) Author: alain91 Date: 2015-06-14.14:04:01
Thank you for your time to analyze my patches

I'm starting to develop in Haskell and those patches are just tries to 
dive into a real application

The problem of issue 1721 is :

Several users have asked me "why did it stop at two out of three?  Did
something go wrong?"  This is a source of worry and confusion for new
users.  Either Darcs should ensure the last message (100% done) is
printed, or it should clear progress output when the operation is
finished.

My aim was to verify what could be wrong in the progress report.

_src/Darcs/Patch/Progress.hs_
To be consistent with other part of the code I have add {-# NOINLINE ... 
#-} for all functions with unsafePerformIO

_src/Darcs/UI/Commands.hs_
cosmetic: display message after the action is done (not before).
modifications for toobig must be removed. The  original code take into 
account a lazy evaluation, mine is eagger.

_src/Darcs/Util/Progress.hs_
The main part is to use modifyIORef' (with quote) => strict version of 
modifyIORef

Cosmetic: instead of a periodic display of progress, my aim was to 
display progress after each action.

Cosmetic: I modify printProgress to display a different message for each 
case.

To be consistent with other part of the code I have add {-# NOINLINE ... 
#-} for all functions with unsafePerformIO

Add handleProgressNew after each action is done (suppression of periodic 
testing).

As this was my first try to develop in Haskell, there could be mistakes.

best regards.

Alain91





Le 11/06/2015 18:58, Ben Franksen a écrit :
> Ben Franksen <benjamin.franksen@helmholtz-berlin.de> added the comment:
>
> I have been playing with this patch. The only difference I noted is that
> progress reporting when I do e.g. darcs get http:/darcs.net is more
> frequent than before.
>
> Unfortunately, for reasons mysterious to me, it breaks the zsh
> completion, even though the output of darcs --commands is the same when
> i pipe it into a file. Hmm.
>
> I'd also like to ask the author to explain what the patch does and in
> which way it improves upon the existing progress handling.
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/patch1335>
> __________________________________
Attachments
msg18690 (view) Author: alain91 Date: 2015-07-15.17:49:01
See another patch for Util/Progress.hs
- use strict function modifyIORef'
- adjust alternatives in printProgress
- modify handleMoreProgress to take into account multiple usage of 
tediousSize (only modify total)
- add showProgressData when modeDebug to show the contents of map
- add resetProgressData to be consistant with setProgressData and 
updateProgressData

Still some spurious behaviour:
when I add a guard (s > 0) within printProgress k (ProgressData 
{sofar=s, total=Nothing}), the messages are not displayed when I try 
multiple sequences beginTedious, tediousSize and endTedious.

I can feel the power of haskell, but as a beginner, haskell have  
some unpredictable behaviour. Any changes in syntaxe could raise an 
unpredictable result. I suppose the lazy evaluation is the main 
cause.
Attachments
History
Date User Action Args
2015-05-08 19:52:06alain91create
2015-05-09 20:24:37alain91setassignedto: alain91
nosy: + alain91
2015-05-09 20:25:28alain91setassignedto: alain91 ->
2015-05-12 06:54:13ganeshsetmessages: + msg18402
2015-06-11 16:58:38bfsetmessages: + msg18444
2015-06-11 17:22:44bfsetmessages: + msg18447
2015-06-12 16:51:53alain91settitle: resolve issue 1721 -> resolve issue1721
2015-06-13 13:33:21bfsetstatus: needs-screening -> in-discussion
2015-06-14 14:04:02alain91setfiles: + unnamed
messages: + msg18492
title: resolve issue1721 -> resolve issue 1721
2015-07-15 17:49:02alain91setfiles: + Progress.diff
messages: + msg18690