eclipsedarcs-develop

[eclipsedarcs-develop] Fix for Flyspray #11

[<rad...@gm...>]

Hi,
  I will rewrite what I have written in bug comment:

It turns out it is because usage of quote (") characters in darcs
invocation. If I use

createNameValueParam( PARAM_LOGFILE, logFile.toString() ) ;

instead of

createNameQuotedValueParam( PARAM_LOGFILE, logFile.toString() ) ;

everything works ok. Any ideas why? Is it safe to substitute it? Anyone?

Moreover I was surprised that record worked if patch short name
contained space. i.e. darcs invocation looked like this:

darcs record --repodir=/home/radekg/private/runtime-EclipseApplication/TestProject
--all --patch-name=Name with space --skip-long-comment aaaaaaa.java

and it worked. So it seems quotes are not necsessary.

I am attaching patch.

Cheers!
  Radek.

-- 
Galeria/Gallery: http://zdjecia.zuzia.homelinux.net/
Codeside: http://codeside.org/

Re: [eclipsedarcs-develop] Fix for Flyspray #11

[<rad...@gm...>]

> > darcs record
> --repodir=/home/radekg/private/runtime-EclipseApplication/TestProject
> > --all --patch-name=Name with space --skip-long-comment aaaaaaa.java
> >
> > and it worked. So it seems quotes are not necsessary.
> Perfect timing - as it happens, I have just written up a basic tutorial on
> handling command line options in Haskell. (Will post it to my blog during
> the next few hours.) So I don't know for sure, but I have an idea why this
> works.
>
> The getOpts mechanism in Haskell (which is presumably used by Darcs)
> recognizes options when they start, as usual, with a single or double dash.
> It may well be that the entire part between --patch-name and
> --skip-long-comment is just recognized as a single string and passed to the
> program as argument to --patch-name. The mechanism can know this because
> there is a defined option (namely, --skip-long-comment) after it, so it is
> known where the string ends. If, on the other hand, --patch-name were the
> last argument, then it would look as if only the first word, i.e. 'Name' is
> an argument to --patch-name, and the rest are individual other options.

That would be perfect explanation except it does not work from command
line. :) So I assume this different kind of magic.

Invocation from command line gives:

$ darcs record --repodir=/home/radekg/private/runtime-EclipseApplication/TestProject
--all --patch-name=Name with space --skip-long-comment aaaaaaa.java

Recording changes in "aaaaaaa.java":

Non existent files or directories: "space" "with"

Cheers!
  Radek.

Re: [eclipsedarcs-develop] Fix for Flyspray #11

[<rad...@gm...>]

Hi,

> > So I assume this different kind of magic.
> >
> > Invocation from command line gives:
> >
> > $ darcs record
> --repodir=/home/radekg/private/runtime-EclipseApplication/TestProject
> > --all --patch-name=Name with space --skip-long-comment aaaaaaa.java
> >
> > Recording changes in "aaaaaaa.java":
> >
> > Non existent files or directories: "space" "with"
> Strange. So this actually has to do with the difference between the
> invocation from the shell and the invocation from the Java process.
>
> I would have to check this, but don't we call Runtime.exec() with a string
> array instead of just one single string? That would also explain why 'Name
> with space' is treated as a single string and not parsed into different
> arguments, if we assume that our array looks like this:
>
> [ ..., "--all", "--patch-name=Name with space", "--skip-long-comment", ... ]

Bingo this time. :)

Cheers,
  Radek.

Re: [eclipsedarcs-develop] Fix for Flyspray #11

[<rad...@gm...>]

2007/3/18, Leif Frenzel <lei...@go...>:
> On 3/18/07, Leif Frenzel <lei...@go...> wrote:
> >
> >
> > > It turns out it is because usage of quote (") characters in darcs
> > > invocation. If I use
> > >
> > > createNameValueParam( PARAM_LOGFILE, logFile.toString() ) ;
> > >
> > > instead of
> > >
> > > createNameQuotedValueParam( PARAM_LOGFILE, logFile.toString() ) ;
> > >
> > > everything works ok. Any ideas why? Is it safe to substitute it? Anyone?
> >
> > I'd say so. But I will do some safety checks.
> Hm, looks good to me.
>
>
> >
> >
> > Btw: there is some other thing that I noticed: if one does a record with a
> long comment, at least under Windows, and one does _not_ do a line break at
> the end, the comment gets screwed up in the Darcs changes output. I'll have
> a look at that and perhaps get it fixed at the same time :-)
> Strange enough, this happens also if one _does_ enter a line break. Any long
> comment gets a '***DARCS***' appended. E.g.
>
> [snip]
> C:\temp\junk\edws\test>darcs changes --last=3
> Sun Mar 18 11:18:07 Westeurop[_\e4_]ische Normalzeit 2007  Leif Frenzel
> <lfr...@in...>
>   * 1174213086703
>
> Sun Mar 18 11:16:57 Westeurop[_\e4_]ische Normalzeit 2007  Leif Frenzel <
> lfr...@in...>
>   * 1174213013109
>   a
>   ***DARCS***
>
> Sun Mar 18 11:16:07 Westeurop[_\e4_]ische Normalzeit 2007  Leif Frenzel <
> lfr...@in...>
>   * test
>   test long comment
>
>   ***DARCS***
> [snap]
>
> This has not happened earlier, so it must have sneaked in somewhere in the
> past. Do you see the same effect on Linux?
>

The ***DARCS*** Line is explicitly added in
RecordOperation.prepareLogFile() method. I was about to remove it
anyway as I thought this was some kind of debug.

Cheers!
  Radek.

-- 
Galeria/Gallery: http://zdjecia.zuzia.homelinux.net/
Codeside: http://codeside.org/

Re: [eclipsedarcs-develop] Fix for Flyspray #11

[<rad...@gm...>]

Hi

> The ***DARCS*** Line is explicitly added in
> RecordOperation.prepareLogFile() method. I was about to remove it
> anyway as I thought this was some kind of debug.

Here comes the patch.

Thanks,
  Radek.

Re: [eclipsedarcs-develop] Fix for Flyspray #11

[<rad...@gm...>]

2007/3/18, Leif Frenzel <lei...@go...>:
>
> >
> >
> > >
> > > > The ***DARCS*** Line is explicitly added in
> > > > RecordOperation.prepareLogFile () method. I was about to remove it
> > > > anyway as I thought this was some kind of debug.
> >
> > If I remember correcty, it was deliberate. I was mimicking the thing that
> Darcs does when it calls an external editor for the long comment. But it
> seems that this works now different, or strictly speaking, they use now
> '***END OF DESCRIPTION***' instead of '***DARCS***'.
> >
> > Hm, I suspect that was a change between some earlier Darcs version and
> 1.0.8.
> >
> > But that would mean that we have to change our code to '***END OF
> DESCRIPTION***' and declare explicitely that Darcs 1.0.8 should be used with
> EclipseDarcs, right?
> Hm, I verified, with Darcs 1.0.2 it's '***DARCS***'. It's '***END OF
> DESCRIPTION***' with Darcs 1.0.5RC1, I haven't checked the versions in
> between.
>
> Wow, it's always a bit frightening how time flies ;-)
>
> So this means we don't have to worry. We should be able to simply use
> '***END OF DESCRIPTION***'.

Doesn't that mean that we should not worry about it at all? We don't
need to put any text at the end of the file. Or do we?

Time showed that putting there anything may in future result in
another changed comment. This is temp file, completly under our
command without user interaction with it, darcs accept it and
correctly parse it without any termination text.

Cheers!
  Radek.

Re: [eclipsedarcs-develop] Fix for Flyspray #11

[<rad...@gm...>]

2007/3/18, Leif Frenzel <lei...@go...>:
>
> > Doesn't that mean that we should not worry about it at all? We don't
> > need to put any text at the end of the file. Or do we?
> We had to, at that time at least. (I'm so lazy, I don't hink I would have
> added that line if it had worked without ;-).
>
>
> > Time showed that putting there anything may in future result in
> > another changed comment. This is temp file, completly under our
> > command without user interaction with it, darcs accept it and
> > correctly parse it without any termination text.
> I'm absolutely not opposed to that, if it works :-)
>
> Cool, so I'll run a few checks on that too, and push it through.


I forgot to add that someone (presumably you :) ) should check this
long comment fix on windows as I am checking it only on Linux right
now.