Discussion:
SharpFossil/WinFossil
(too old to reply)
Ingo Koch
2011-05-07 21:07:56 UTC
Permalink
Hi all,

for all those who are missing a Visual Studio integration of fossil, I started a
project to provide a C# wrapper around the fossil command line. The long term
goal is to provide a SccProvider for VS. As a prove of concept for the lib I've
also added a Windows application which uses SharpFossil to provide a graphical
interface for the fossil comands.

Neither SharpFossil (the wrapper library) nor WinFossil (the Windows UI for
fossil) are complete, but they already have some features which might be useful.
If you want to try it, please be aware of the fact that you need a slightly
modified version of fossil (reasons for this on the website mentioned below)
which is included into the repository and the distribution zip file.

I'd like to invite anyone who is interested in Windows/Visual Studio integration
to participate. Take a look and test it with your environment, submit bug
reports ore feature requests, be part of the development team (to be build ;-) ) ...

For details and download see
http://repository.mobile-developers.de/cgi-bin/ikoch/sharpfossil
Please clone and play with it. Any response is welcome.
Jeff Slutter
2011-05-08 00:31:10 UTC
Permalink
Post by Ingo Koch
For details and download see
http://repository.mobile-developers.de/cgi-bin/ikoch/sharpfossil
Please clone and play with it. Any response is welcome.
Great stuff, I'm definitely interested in something like this, I'll have
to take a look. Two things:

1) I was unable to run the WinFossil binary you made available for
download (Win7, x64). However, I also realized I wasn't able to run the
fossil.exe you provided also because it is dependent on zlib1.dll, which
I do not have on my system. Static link perhaps?

2) This is to the Fossil community, would it be possible to get into the
main branch of Fossil the minor change necessary for this project? That
is, placing a CR/LF at the end of request printfs so that processes that
spawn Fossil.exe programmatically can process over the stdout/stdin.
Perhaps some command line argument to enable this?

This reminds me of a neat feature Perforce has, and that is a command
line option to enable a formatted output, so a parent process has an
easier job to parse any output.

Thank you,
Jeff
Ingo Koch
2011-05-08 09:50:47 UTC
Permalink
Post by Jeff Slutter
Post by Ingo Koch
For details and download see
http://repository.mobile-developers.de/cgi-bin/ikoch/sharpfossil
Please clone and play with it. Any response is welcome.
Great stuff, I'm definitely interested in something like this, I'll have
1) I was unable to run the WinFossil binary you made available for
download (Win7, x64). However, I also realized I wasn't able to run the
fossil.exe you provided also because it is dependent on zlib1.dll, which
I do not have on my system. Static link perhaps?
I've included the zlib1.dll into the WinFossil.zip file.
What do you mean by "I was unable to run the WinFossil binary"?
I'm developing and using it on Win7 x64. Do you get any error message, exception
or something like that?
Post by Jeff Slutter
2) This is to the Fossil community, would it be possible to get into the
main branch of Fossil the minor change necessary for this project? That
is, placing a CR/LF at the end of request printfs so that processes that
spawn Fossil.exe programmatically can process over the stdout/stdin.
Perhaps some command line argument to enable this?
I already suggested the modification in a feature request some time ago:
http://www.fossil-scm.org/index.html/tktview?name=2857ab0995

Regards,

Ingo
Jeff Slutter
2011-05-08 14:54:10 UTC
Permalink
Post by Ingo Koch
I've included the zlib1.dll into the WinFossil.zip file.
What do you mean by "I was unable to run the WinFossil binary"?
I'm developing and using it on Win7 x64. Do you get any error message, exception
or something like that?
The Fossil.exe included in WinFossil.zip now works for me.

As for WinFossil.exe, as soon as I double click it, it crashes and I get
a standard Windows message box saying "WinFossil has stopped working.
Windows is checking for a solution to the problem...". Running the
executable via an instance of the MSVS2008 debugger reveals a
BadImageFormatException:

An unhandled exception of type 'System.BadImageFormatException' occurred
in WinFossil.exe
Additional information: Could not load file or assembly
'System.Data.SQLite, Version=1.0.66.0, Culture=neutral,
PublicKeyToken=db937bc2d44ff139' or one of its dependencies. An attempt
was made to load a program with an incorrect format.

I'm confused though why it would work for you, and not me. Other than,
perhaps, on your machine it is finding the x64 System.Data.SQLite behind
the scenes, perhaps from the GAC.

Seeing these errors in the past, and knowing that System.Data.SQLite is
a native assembly (it is either x86, or x64), to fix the error, you need
to explicitly set the "Platform target:" field to x86 (in the
Properties|Build tab of WinFossil's Project Properties), and then make
sure you distribute the System.Data.SQLite x86 assembly (as you already
are). Optionally, you could provide both x86 and x64 assemblies of
System.Data.SQLite and let the user choose the right one based on their
platform.

I went to http://sqlite.phxsoftware.com/ and downloaded the 1.0.66.0
binaries package, and replaced System.Data.SQLite.dll, of your
WinFossil.zip, with the x64 version from the binaries download zip, and
WinFossil started up.
Ingo Koch
2011-05-08 21:01:21 UTC
Permalink
Post by Jeff Slutter
Post by Ingo Koch
I've included the zlib1.dll into the WinFossil.zip file.
What do you mean by "I was unable to run the WinFossil binary"?
I'm developing and using it on Win7 x64. Do you get any error message, exception
or something like that?
The Fossil.exe included in WinFossil.zip now works for me.
As for WinFossil.exe, as soon as I double click it, it crashes and I get
a standard Windows message box saying "WinFossil has stopped working.
Windows is checking for a solution to the problem...". Running the
executable via an instance of the MSVS2008 debugger reveals a
An unhandled exception of type 'System.BadImageFormatException' occurred
in WinFossil.exe
Additional information: Could not load file or assembly
'System.Data.SQLite, Version=1.0.66.0, Culture=neutral,
PublicKeyToken=db937bc2d44ff139' or one of its dependencies. An attempt
was made to load a program with an incorrect format.
I'm confused though why it would work for you, and not me. Other than,
perhaps, on your machine it is finding the x64 System.Data.SQLite behind
the scenes, perhaps from the GAC.
Seeing these errors in the past, and knowing that System.Data.SQLite is
a native assembly (it is either x86, or x64), to fix the error, you need
to explicitly set the "Platform target:" field to x86 (in the
Properties|Build tab of WinFossil's Project Properties), and then make
sure you distribute the System.Data.SQLite x86 assembly (as you already
are). Optionally, you could provide both x86 and x64 assemblies of
System.Data.SQLite and let the user choose the right one based on their
platform.
That's what happens if you test and use software on the development system :-(
I got caught in that trap two years ago but I forgot it until you mentioned it.
I've uploaded a modified version which has been tested on a 32 bit Windows XP
VM too.

Ingo
Timothy Brown
2011-05-08 19:02:52 UTC
Permalink
I like this and will try to support or help if possible. Both are good ideas, a
Windows explorer extension would be a natural extension of this.

CR/LF - very windows specific
LF - is very common on other platforms (*nix)
CR - Mac specific I think

Without checking is it possible that you are receiving just the LF which you
should be able to parse on with stdout output. If there is no CR/LF,LF, or CR
then I think one of these would be considered a reasonable enhancement to
Fossil. It just may that the right choice isn't CR/LF.

Tim

When I am back home at my computer I will give the windows app a try.





________________________________

Date: Sat, 07 May 2011 23:07:56 +0200
From: Ingo Koch <***@ikoch.de>
Subject: [fossil-users] SharpFossil/WinFossil
To: fossil-***@lists.fossil-scm.org
Message-ID: <***@ikoch.de>
Content-Type: text/plain; charset=ISO-8859-15

Hi all,

for all those who are missing a Visual Studio integration of fossil, I started a
project to provide a C# wrapper around the fossil command line. The long term
goal is to provide a SccProvider for VS. As a prove of concept for the lib I've
also added a Windows application which uses SharpFossil to provide a graphical
interface for the fossil comands.

Neither SharpFossil (the wrapper library) nor WinFossil (the Windows UI for
fossil) are complete, but they already have some features which might be useful.
If you want to try it, please be aware of the fact that you need a slightly
modified version of fossil (reasons for this on the website mentioned below)
which is included into the repository and the distribution zip file.

I'd like to invite anyone who is interested in Windows/Visual Studio integration
to participate. Take a look and test it with your environment, submit bug
reports ore feature requests, be part of the development team (to be build ;-) )
...

For details and download see
http://repository.mobile-developers.de/cgi-bin/ikoch/sharpfossil
Please clone and play with it. Any response is welcome.
Will Duquette
2011-05-08 21:21:52 UTC
Permalink
OS X uses LF, like any another Unix variant. CR was the old Mac OS.

Will
I like this and will try to support or help if possible. Both are good ideas, a Windows explorer extension would be a natural extension of this.
CR/LF - very windows specific
LF - is very common on other platforms (*nix)
CR - Mac specific I think
Without checking is it possible that you are receiving just the LF which you should be able to parse on with stdout output. If there is no CR/LF,LF, or CR then I think one of these would be considered a reasonable enhancement to Fossil. It just may that the right choice isn't CR/LF.
Tim
When I am back home at my computer I will give the windows app a try.
Date: Sat, 07 May 2011 23:07:56 +0200
Subject: [fossil-users] SharpFossil/WinFossil
Content-Type: text/plain; charset=ISO-8859-15
Hi all,
for all those who are missing a Visual Studio integration of fossil, I started a
project to provide a C# wrapper around the fossil command line. The long term
goal is to provide a SccProvider for VS. As a prove of concept for the lib I've
also added a Windows application which uses SharpFossil to provide a graphical
interface for the fossil comands.
Neither SharpFossil (the wrapper library) nor WinFossil (the Windows UI for
fossil) are complete, but they already have some features which might be useful.
If you want to try it, please be aware of the fact that you need a slightly
modified version of fossil (reasons for this on the website mentioned below)
which is included into the repository and the distribution zip file.
I'd like to invite anyone who is interested in Windows/Visual Studio integration
to participate. Take a look and test it with your environment, submit bug
reports ore feature requests, be part of the development team (to be build ;-) ) ...
For details and download see
http://repository.mobile-developers.de/cgi-bin/ikoch/sharpfossil
Please clone and play with it. Any response is welcome.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Mr. Will Duquette, OP
will -at- wjduquette dot com
http://foothills.wjduquette.com/blog
Ingo Koch
2011-05-08 21:43:20 UTC
Permalink
Post by Timothy Brown
CR/LF - very windows specific
LF - is very common on other platforms (*nix)
CR - Mac specific I think
Without checking is it possible that you are receiving just the LF which you
should be able to parse on with stdout output. If there is no CR/LF,LF, or CR
then I think one of these would be considered a reasonable enhancement to
Fossil. It just may that the right choice isn't CR/LF.
The modification I've made is to add a '\n' to the prompt. So it is sufficient
to add a LF even on the Windows platform.

Ingo
Jeff Slutter
2011-05-08 22:33:58 UTC
Permalink
Post by Ingo Koch
Post by Timothy Brown
CR/LF - very windows specific
LF - is very common on other platforms (*nix)
CR - Mac specific I think
Without checking is it possible that you are receiving just the LF
which you should be able to parse on with stdout output. If there is
no CR/LF,LF, or CR then I think one of these would be considered a
reasonable enhancement to Fossil. It just may that the right choice
isn't CR/LF.
The modification I've made is to add a '\n' to the prompt. So it is
sufficient to add a LF even on the Windows platform.
Right, as Ingo said, just the '\n' should be sufficient, no need to
worry about CR/CRLF/LF platform specifics. The reason it is necessary, I
believe (I could be wrong), for a parent process, Windows doesn't
actually notify the parent process of the stdout data until a newline is
hit. So, if you spawn a process and monitor the child's stdout/stderr
streams, you don't get that data until a '\n' is sent by the child.
Which is why Ingo needs this change in Fossil in order to write a
wrapper around it.
Jeff Slutter
2011-05-08 22:42:44 UTC
Permalink
Actually, thinking about it, the '\n' probably just causes a flush.
Therefore, the easier change may be just adding calls to fflush with stderr
and stdout.
Timothy Brown
2011-05-09 00:55:53 UTC
Permalink
Jeff,

shrug, been a long time since I've done anything with a Mac, LOL.

Ingo,

This seems like a reasonable change to Fossil as long as adding it doesn't break
anything we don't understand (I can't believe it would).

Propose it as a change and get Richard Hipp's feedback. Maybe you should try to
become a Fossil contributor and make the change yourself so there doesn't have
to be a custom Fossil build.

Tim




________________________________
Ingo Koch
2011-05-09 22:26:17 UTC
Permalink
Post by Timothy Brown
Ingo,
This seems like a reasonable change to Fossil as long as adding it doesn't
break anything we don't understand (I can't believe it would).
No, it won't break anything. The only difference is that on the commandline the
users answer has to be entered on a new line and not on the same line as the prompt.
Post by Timothy Brown
Propose it as a change and get Richard Hipp's feedback. Maybe you should try
to become a Fossil contributor and make the change yourself so there doesn't
have to be a custom Fossil build.
I've already added a ticket as a feature request a while ago. I won't conjecture
about the reasons not to include this change. After all it is Richard's project.
I'll try to always include a modified Windows binary release of the latest
official Fossil release version into my project. Anyone who doesn't trust this
exe might compile it himself. ;-)

As I mentioned, SharpFossil and WinFossil are far away from beeing complete or
bug free. And as long as there is one user (me ;-) ) it doesn't make sense to
beg Richard again and again to change anything in Fossil to support SharpFossil.

The main purpose of my original post to the list was to encourage Windows users
of Fossil to try SharpFossil/WinFossil and to get feedback about it and may be
to get people involved in further development (for me, it is a spare time
project and unfortunately not evolving fast enough) .

Ingo
Matt Welland
2011-05-10 00:15:30 UTC
Permalink
Rather than changing the terminal user interface (it will be slightly
less nice IMHO due to the extra newline on a prompt) I suggest
considering the approach used on the monotone project. A separate
interface for automation. Make the human friendly interface friendly
to humans and make the automation interface friendly to automation.

Just my 0.02$
Post by Timothy Brown
Ingo,
This seems like a reasonable change to Fossil as long as adding it doesn't
break anything we don't understand (I can't believe it would).
No, it won't break anything. The only difference is that on the commandline
the users answer has to be entered on a new line and not on the same line as
the prompt.
Propose it as a change and get Richard Hipp's feedback.  Maybe you should
try to become a Fossil contributor and make the change yourself so there
doesn't have to be a custom Fossil build.
I've already added a ticket as a feature request a while ago. I won't
conjecture about the reasons not to include this change. After all it is
Richard's project.
I'll try to always include a modified Windows binary release of the latest
official Fossil release version into my project. Anyone who doesn't trust
this exe might compile it himself. ;-)
As I mentioned, SharpFossil and WinFossil are far away from beeing complete
or bug free. And as long as there is one user (me ;-) ) it doesn't make
sense to beg Richard again and again to change anything in Fossil to support
SharpFossil.
The main purpose of my original post to the list was to encourage Windows
users of Fossil to try SharpFossil/WinFossil and to get feedback about it
and may be to get people involved in further development (for me, it is a
spare time project and unfortunately not evolving fast enough) .
Ingo
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Jeff Slutter
2011-05-10 00:24:07 UTC
Permalink
Post by Matt Welland
Rather than changing the terminal user interface (it will be slightly
less nice IMHO due to the extra newline on a prompt) I suggest
considering the approach used on the monotone project. A separate
interface for automation. Make the human friendly interface friendly
to humans and make the automation interface friendly to automation.
I agree, you don't want to mess up the text for the normal command line
user. I suggest doing something similar to Perforce with it's tagged
text output ("-z tag") ripe for parsing, or, just testing to see if
adding fflush(stdout); fflush(stderr); instead of adding tacking on a
newline. This will hopefully cause the parent process to receive the
child output.
Ingo Koch
2011-05-10 21:02:19 UTC
Permalink
Post by Jeff Slutter
Post by Matt Welland
Rather than changing the terminal user interface (it will be slightly
less nice IMHO due to the extra newline on a prompt) I suggest
considering the approach used on the monotone project. A separate
interface for automation. Make the human friendly interface friendly
to humans and make the automation interface friendly to automation.
I agree, you don't want to mess up the text for the normal command line
user. I suggest doing something similar to Perforce with it's tagged
text output ("-z tag") ripe for parsing, or, just testing to see if
adding fflush(stdout); fflush(stderr); instead of adding tacking on a
newline. This will hopefully cause the parent process to receive the
child output.
Unfortunately fflush(stdout) doesn't help. It is part of the prompt_user
function since day one.
For now, I think I'll do it with my small change. It works and has near to no
impact on the fossil code base. The prompt_user function doesn't look like it
will be changed in the future. An additional flag for parsing friendly output
would require changes in a number of commands and IMHO is not an option until
there are more projects which require this.

Ingo

Continue reading on narkive:
Loading...