John Meacham | 1 Aug 2003 02:08
Favicon

Re: feature suggestions: whatsnew for local/remote comparison

On Thu, Jul 31, 2003 at 08:22:01AM -0700, Zack Brown wrote:
> Just as we can do a 'darcs whatsnew' to see what we haven't 'recorded' yet,
> it would be cool to do something similar to see if a remote maintainer has
> applied something we've 'pushed' to their repository yet.
> 
> The feature I'm thinking of would be like a 'diff', but instead of being
> between different versions, it would be between one repo and another.
> Additionally, modifications made locally would display differently from
> modifications made remotely; and the user could give an option to
> suppress displaying one or the other.

yes. I want something like this. what I was thinking was something like:

darcs compare <repo1> <repo2> (where repos can be local or remote and if
only one is given, the other is assumed to be .)

what it will do is show:
<repo1> has the following patches <repo2> doesn't:
patch1         (just patch names)
patch2 ...
<repo2> has the following patches <repo1> doesn't:
patchA
patchB ...

repo1 has the following local changes:
(darcs whatsnew output for repo1)
repo2 has the following local changes:
(darcs whatsnew output for repo2)

        John
(Continue reading)

Zack Brown | 1 Aug 2003 07:16

Re: feature suggestions: whatsnew for local/remote comparison

On Thu, Jul 31, 2003 at 05:08:15PM -0700, John Meacham wrote:
> On Thu, Jul 31, 2003 at 08:22:01AM -0700, Zack Brown wrote:
> > Just as we can do a 'darcs whatsnew' to see what we haven't 'recorded' yet,
> > it would be cool to do something similar to see if a remote maintainer has
> > applied something we've 'pushed' to their repository yet.
> > 
> > The feature I'm thinking of would be like a 'diff', but instead of being
> > between different versions, it would be between one repo and another.
> > Additionally, modifications made locally would display differently from
> > modifications made remotely; and the user could give an option to
> > suppress displaying one or the other.
> 
> yes. I want something like this. what I was thinking was something like:
> 
> darcs compare <repo1> <repo2> (where repos can be local or remote and if
> only one is given, the other is assumed to be .)

Yes, and if none are given, they are assumed to be '.' and the default
remote repository.

Darcs should maybe also warn if it looks like it is about to try to
compare two repositories where one has not been pulled from the other,
i.e. if they are probably two completely different repositories. In that
case it should say something like "<repo1> is probably not related to
<repo2>. Continue (y/n)?"

> 
> what it will do is show:
> <repo1> has the following patches <repo2> doesn't:
> patch1         (just patch names)
(Continue reading)

Andres Loeh | 1 Aug 2003 11:54
Picon

Re: Re: 0.9.12 is out!

> David Roundy writes:
> 
>  > you get an error if use -optc with any flag that is
>  > recognized by ghc itself.
> 
> Are you certain about this? I have used the patch I pushed
> moments ago with a variety of $CFLAGS settings -- including '-O'
> and friends -- and I didn't get any errors with ghc 5.04.3.
> 
> As far as I can tell, just prefixing all flags in $CFLAGS with
> '-optc' works just fine.

That's my experience, too. However, I've heard from someone else
that he had problems with a "-O3" in CFLAGS. And I discovered that
there are subtle differences in the handling of "-optc" between
ghc-5.04.3 and ghc-6.0. For instance, in 5.04.3, this works for
me:

-optc"-march=pentium -O3 -pipe"

It does not work with ghc-6.0, though. Maybe this should be taken
to the GHC mailing list, as it's a general problem ...

Best,
  Andres
Donald Bruce Stewart | 1 Aug 2003 12:03
Picon
Picon
Favicon
Gravatar

Re: Re: 0.9.12 is out!

andres:
> > David Roundy writes:
> > 
> >  > you get an error if use -optc with any flag that is
> >  > recognized by ghc itself.
> > 
> > Are you certain about this? I have used the patch I pushed
> > moments ago with a variety of $CFLAGS settings -- including '-O'
> > and friends -- and I didn't get any errors with ghc 5.04.3.
> > 
> > As far as I can tell, just prefixing all flags in $CFLAGS with
> > '-optc' works just fine.
> 
> That's my experience, too. However, I've heard from someone else
> that he had problems with a "-O3" in CFLAGS. And I discovered that
> there are subtle differences in the handling of "-optc" between
> ghc-5.04.3 and ghc-6.0. For instance, in 5.04.3, this works for
> me:
> 
> -optc"-march=pentium -O3 -pipe"
> 
> It does not work with ghc-6.0, though. Maybe this should be taken
> to the GHC mailing list, as it's a general problem ...

This is news to me. On a Linux box:

    $ ghc-6.0 -optc "-march=pentium -O3 -pipe" Test.hs

    $ ghc-5.04.2 -optc "-march=pentium -O3 -pipe" Test.hs

(Continue reading)

Andres Loeh | 1 Aug 2003 12:14
Picon

Re: Re: 0.9.12 is out!

> > ghc-5.04.3 and ghc-6.0. For instance, in 5.04.3, this works for
> > me:
> > 
> > -optc"-march=pentium -O3 -pipe"
> > 
> > It does not work with ghc-6.0, though. Maybe this should be taken
> > to the GHC mailing list, as it's a general problem ...
> 
> This is news to me. On a Linux box:
> 
>     $ ghc-6.0 -optc "-march=pentium -O3 -pipe" Test.hs
> 
>     $ ghc-5.04.2 -optc "-march=pentium -O3 -pipe" Test.hs
> 
>     $ ghc-5.04 -optc "-march=pentium -O3 -pipe" Test.hs 
> 
> All worked fine. Quoting may have been the issue.

If you compile without -O, then no C compiler is involved, because
there also is a native code generator for Linux, AFAIK. Give either
-fvia-c or -O (which implies the former). Does it still work then?

Best,
  Andres
Donald Bruce Stewart | 1 Aug 2003 12:29
Picon
Picon
Favicon
Gravatar

Re: Re: 0.9.12 is out!

andres:
> > > ghc-5.04.3 and ghc-6.0. For instance, in 5.04.3, this works for
> > > me:
> > > 
> > > -optc"-march=pentium -O3 -pipe"
> > > 
> > > It does not work with ghc-6.0, though. Maybe this should be taken
> > > to the GHC mailing list, as it's a general problem ...
> > 
> > This is news to me. On a Linux box:
> > 
> >     $ ghc-6.0 -optc "-march=pentium -O3 -pipe" Test.hs
> > 
> >     $ ghc-5.04.2 -optc "-march=pentium -O3 -pipe" Test.hs
> > 
> >     $ ghc-5.04 -optc "-march=pentium -O3 -pipe" Test.hs 
> > 
> > All worked fine. Quoting may have been the issue.
> 
> If you compile without -O, then no C compiler is involved, because
> there also is a native code generator for Linux, AFAIK. Give either
> -fvia-c or -O (which implies the former). Does it still work then?

Sorry, a bit sleepy :)

Ah, yes! Look at this:

Doesn't work:
    $ ghc-6.0 -fvia-C -optc "-march=pentium -O3 -pipe" Test.hs
    cc1: bad value (pentium -O3 -pipe) for -march= switch
(Continue reading)

Peter Simons | 1 Aug 2003 13:38
Picon
Gravatar

Re: 0.9.12 is out!

Andres Loeh writes:

 > -optc"-march=pentium -O3 -pipe"

I was under the impression that the "correct" syntax in this case
would be:

    -optc-march=pentium -optc-O3 -optc-pipe

On my machine, the build works fine using this scheme.

Peter

Note to self: Think hard about how quoted flags in $CFLAGS would
affect the current build system.
David Roundy | 1 Aug 2003 14:42

Re: feature suggestions: whatsnew for local/remote comparison

On Thu, Jul 31, 2003 at 05:08:15PM -0700, John Meacham wrote:
> On Thu, Jul 31, 2003 at 08:22:01AM -0700, Zack Brown wrote:
> > Just as we can do a 'darcs whatsnew' to see what we haven't 'recorded' yet,
> > it would be cool to do something similar to see if a remote maintainer has
> > applied something we've 'pushed' to their repository yet.
> > 
> > The feature I'm thinking of would be like a 'diff', but instead of being
> > between different versions, it would be between one repo and another.
> > Additionally, modifications made locally would display differently from
> > modifications made remotely; and the user could give an option to
> > suppress displaying one or the other.
> 
> yes. I want something like this. what I was thinking was something like:
> 
> darcs compare <repo1> <repo2> (where repos can be local or remote and if
> only one is given, the other is assumed to be .)
> 
> what it will do is show:
> <repo1> has the following patches <repo2> doesn't:
> patch1         (just patch names)
> patch2 ...
> <repo2> has the following patches <repo1> doesn't:
> patchA
> patchB ...

This much would be easy... (and until I implement it, you can get the same
info in an inelegant way by doing a darcs pull -v and just hitting ctrl-C
after seeing the listing).

> repo1 has the following local changes:
(Continue reading)

David Roundy | 1 Aug 2003 15:01

Re: Re: 0.9.12 is out!

On Fri, Aug 01, 2003 at 01:38:44PM +0200, Peter Simons wrote:
> Andres Loeh writes:
> 
>  > -optc"-march=pentium -O3 -pipe"
> 
> I was under the impression that the "correct" syntax in this case
> would be:
> 
>     -optc-march=pentium -optc-O3 -optc-pipe
> 
> On my machine, the build works fine using this scheme.

Yep, your patch works for me, too.  The problem seems to be if you have a
space after the -optc, in which case it works for options like -g and
-march=pentium, but fails for -O, etc that are understood by ghc.
--

-- 
David Roundy
http://www.abridgegame.org
David Roundy | 1 Aug 2003 16:35
Picon

Whitespace in filenames

On Thu, Jul 31, 2003 at 12:26:00PM +1000, Donald Bruce Stewart wrote:
> This also revealed that darcs doesn't like whitespace in file
> names, this seems reasonably easy to fix (haven't done this yet,
> though).

When designing the patch formats, I thought about whitespace in file names,
and couldn't think of a good reason to allow it.  Since I couldn't see any
way to allow whitespace other than escaping it (which meant also escaping
the escape character--probably '\'. which has the advantage that you really
shouldn't be using '\' in your filenames if you want your code to be
portable), I decided against it, mostly because I didn't want to bother.

Is whitespace in filenames something that people tend to use? I think I've
seen it in kde once, but it seems like a silly thing to have... On the
other hand, I also thought it was silly to have filenames starting with
'.', and I just ran into all sorts of trouble tracking down a bug caused by
*that*.

I guess it's probably better to support whitespace in filenames just so we
don't have to worry about the issue.  It just takes writing three parsing
routines to parse filenames (one for direct from a Handle, one from String
and one from PackedString) and a couple printing routines (which could share
code), and making sure they are used throughout the parsing and patch
printing/showing code.

I guess it would be simplest to escape in the following way:
print_filename f = concat $ map escape f
  where escape '\\' = "\\\\"
        escape c = if Char.isWhiteSpace c
                   then "\\" ++ c
(Continue reading)


Gmane