myhdl-list

[myhdl-list] Keep hierarchy in VHDL conversion

[Oscar D. D. <osc...@gm...>]

Hi

I've been working in this for a long time ago, and I managed to hack
the converter to keep hierarchy as close as possible to MyHDL source
design. Now, after a lot of code cleaning and passing almost all the
tests I can release the code.

https://github.com/dargor0/myhdl-addons

check the "conversion" directory. 

Long threads and many words we have dedicated to this issue, but I want
to re-state my motivation and main rationale to propose this "modified
converter": It's very difficult to do floor-planning with a flat
single-file design, not to mention almost impossible to do partial
re-configuration (PR). With this converter, now I can generate a
top-module based on component instantiations that reflects as close as
possible the structural design from design source.

This converter pass almost all regression tests (I'm working to pass
all of them), but it is usable and works perfectly for its main
use-case: keeping top-module structural design.

Only VHDL conversion is supported for now, but I'm working on Verilog
converter too.

And finally, now that I propose this converter, I'd like to propose an
Idea to extend conversion process. Following this proposal, I'm
thinking of add custom "filter" functions to modify the extracted
internal data (ast tree), and doing some kind of optimizations. It only
needs one dummy function call in conversion code, then "custom
converters" only need to subclass them. This initially would help me to
avoid some monkey-patching I did to implement this converter, but I
think it can be a starting point to extend the convertible subset, and
also to ease testing of this "extensions".

Best regards,

-- 
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.fsf.org/campaigns/opendocument

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Angel E. <ang...@gm...>]

On Sun, Apr 14, 2013 at 3:54 AM, Oscar Daniel Diaz <osc...@gm...> wrote:
> Hi
>
> I've been working in this for a long time ago, and I managed to hack
> the converter to keep hierarchy as close as possible to MyHDL source
> design. Now, after a lot of code cleaning and passing almost all the
> tests I can release the code.
>
> https://github.com/dargor0/myhdl-addons
>
> check the "conversion" directory.
>
> Long threads and many words we have dedicated to this issue, but I want
> to re-state my motivation and main rationale to propose this "modified
> converter": It's very difficult to do floor-planning with a flat
> single-file design, not to mention almost impossible to do partial
> re-configuration (PR). With this converter, now I can generate a
> top-module based on component instantiations that reflects as close as
> possible the structural design from design source.
>
> This converter pass almost all regression tests (I'm working to pass
> all of them), but it is usable and works perfectly for its main
> use-case: keeping top-module structural design.
>
> Only VHDL conversion is supported for now, but I'm working on Verilog
> converter too.
>
> And finally, now that I propose this converter, I'd like to propose an
> Idea to extend conversion process. Following this proposal, I'm
> thinking of add custom "filter" functions to modify the extracted
> internal data (ast tree), and doing some kind of optimizations. It only
> needs one dummy function call in conversion code, then "custom
> converters" only need to subclass them. This initially would help me to
> avoid some monkey-patching I did to implement this converter, but I
> think it can be a starting point to extend the convertible subset, and
> also to ease testing of this "extensions".
>
> Best regards,
>
> --
> Oscar Díaz

Oscar, this is awesome!

This is something I have wanted pretty much since I discovered MyHDL.
I hope you can make all the tests pass soon and that you can implement
the Verilog side as well. I also hope Jan can have a look and
hopefully integrate it into the official MyHDL code base.

I went though the github readme file briefly, and it was not super
clear to me how you select the output file names and who you create
the corresponding entities. It would be nice if you had some example
so that it was easier to understand how the whole thing works.

Cheers,

Angel

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Oscar D. D. <osc...@gm...>]

El Sun, 14 Apr 2013 17:25:45 +0200
Angel Ezquerra <ang...@gm...> escribió:

> This is something I have wanted pretty much since I discovered MyHDL.
> I hope you can make all the tests pass soon and that you can implement
> the Verilog side as well. I also hope Jan can have a look and
> hopefully integrate it into the official MyHDL code base.

Well, my initial plan is to use it as a external module, and when it's
sufficiently stable (and proven useful to users), then merge with
default converters.

So I'm pursuing two approaches: the external module and patched
converters.

By the way, I know this should be in a MEP, I'll write it this week.

> 
> I went though the github readme file briefly, and it was not super
> clear to me how you select the output file names and who you create
> the corresponding entities. It would be nice if you had some example
> so that it was easier to understand how the whole thing works.

I uploaded a couple regression tests, but I think they can be used for
demonstration, also I attach another example (extracted from one of
the tests): convert_kh.py .

To answer your question: entity names are based on function names, and
each function call will generate an instance statement. However, it
checks argument values for each function call to decide how many
components to generate. That means any constants (analogous to generics
in VHDL) and bit-widths are hard-coded in components, but if you
instantiate many components with the same constants and bit-widths it
only generate one component.

>

Regarding existing regression tests, there's some tests that I cannot
pass due to VHDL errors (two of them fails with current snapshot):

1. some tests fails due to VHDL case-insensitive identifiers. What
should the correct procedure in this case? Either notify the user about
identifier conflicts, or change generated names to avoid them?

2. User-defined code cannot infer "inout" signals, and those tests
fails when attempt to read "out" signals. Here I don't know how to do
that without parsing user-defined code.

I also attach a summary with the problems I found
(regression_tests_summary.py) and test reports for the failed tests in
current snapshot.

> 
> Cheers,
> 
> Angel
> 

Best regards,
-- 
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.fsf.org/campaigns/opendocument

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Jan D. <ja...@ja...>]

On 04/14/2013 03:54 AM, Oscar Daniel Diaz wrote:
> Hi
>
> I've been working in this for a long time ago, and I managed to hack
> the converter to keep hierarchy as close as possible to MyHDL source
> design. Now, after a lot of code cleaning and passing almost all the
> tests I can release the code.

Oscar:

I will certainly look into this, but I have one practical question:
how do you keep track of MyHDL development given that you use
git and MyHDL development is currently in mercurial?

I am asking because I recently make a number of changes (crucial
for a customer of mine), still in 0.8 dev. (Chris and I have
been working on the documentation for a release, but it's
not finished yet.)

Jan


> https://github.com/dargor0/myhdl-addons
>
> check the "conversion" directory.
>
> Long threads and many words we have dedicated to this issue, but I want
> to re-state my motivation and main rationale to propose this "modified
> converter": It's very difficult to do floor-planning with a flat
> single-file design, not to mention almost impossible to do partial
> re-configuration (PR). With this converter, now I can generate a
> top-module based on component instantiations that reflects as close as
> possible the structural design from design source.
>
> This converter pass almost all regression tests (I'm working to pass
> all of them), but it is usable and works perfectly for its main
> use-case: keeping top-module structural design.
>
> Only VHDL conversion is supported for now, but I'm working on Verilog
> converter too.
>
> And finally, now that I propose this converter, I'd like to propose an
> Idea to extend conversion process. Following this proposal, I'm
> thinking of add custom "filter" functions to modify the extracted
> internal data (ast tree), and doing some kind of optimizations. It only
> needs one dummy function call in conversion code, then "custom
> converters" only need to subclass them. This initially would help me to
> avoid some monkey-patching I did to implement this converter, but I
> think it can be a starting point to extend the convertible subset, and
> also to ease testing of this "extensions".
>
> Best regards,
>
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Angel E. <ang...@gm...>]

On Sun, Apr 14, 2013 at 5:54 PM, Jan Decaluwe <ja...@ja...> wrote:
> On 04/14/2013 03:54 AM, Oscar Daniel Diaz wrote:
>>
>> Hi
>>
>> I've been working in this for a long time ago, and I managed to hack
>> the converter to keep hierarchy as close as possible to MyHDL source
>> design. Now, after a lot of code cleaning and passing almost all the
>> tests I can release the code.
>
>
> Oscar:
>
> I will certainly look into this, but I have one practical question:
> how do you keep track of MyHDL development given that you use
> git and MyHDL development is currently in mercurial?
>
> I am asking because I recently make a number of changes (crucial
> for a customer of mine), still in 0.8 dev. (Chris and I have
> been working on the documentation for a release, but it's
> not finished yet.)
>
> Jan

Oscar,

if you have never used mercurial and need some help drop me a line. I
am very active in TortoiseHg development (and a bit on mercurial as
well) so I think I could help bring you up to speed if you need it.

Cheers,

Angel

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Jan D. <ja...@ja...>]

On 04/14/2013 06:02 PM, Angel Ezquerra wrote:

> Oscar,
>
> if you have never used mercurial and need some help drop me a line. I
> am very active in TortoiseHg development (and a bit on mercurial as
> well) so I think I could help bring you up to speed if you need it

Interesting.

Perhaps I should ask a more general question: should we
consider to move MyHDL development to github?

This is not a technical question. Many Pythonistas probably
have a slight preference for Python-based mercurial.
Professionally, I use both and I am happy with either one.

The point is that "everyone" seems to be at github. So
perhaps this is good for visibility.

It may also be good for development. I like the way
Oscar presented his work: it shows commitment to
maintain the feature, and everyone can try/follow
it without requiring my assistance. Much better
than getting patches/bundles out of the blue that
I am supposed to review/check/integrate before others
can (easily) do so.

Of course, for this to work, all development should
be on the same system.

Jan



-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Angel E. <ang...@gm...>]

On Sun, Apr 14, 2013 at 9:28 PM, Jan Decaluwe <ja...@ja...> wrote:
> On 04/14/2013 06:02 PM, Angel Ezquerra wrote:
>
>> Oscar,
>>
>> if you have never used mercurial and need some help drop me a line. I
>> am very active in TortoiseHg development (and a bit on mercurial as
>> well) so I think I could help bring you up to speed if you need it
>
> Interesting.
>
> Perhaps I should ask a more general question: should we
> consider to move MyHDL development to github?
>
> This is not a technical question. Many Pythonistas probably
> have a slight preference for Python-based mercurial.
> Professionally, I use both and I am happy with either one.
>
> The point is that "everyone" seems to be at github. So
> perhaps this is good for visibility.
>
> It may also be good for development. I like the way
> Oscar presented his work: it shows commitment to
> maintain the feature, and everyone can try/follow
> it without requiring my assistance. Much better
> than getting patches/bundles out of the blue that
> I am supposed to review/check/integrate before others
> can (easily) do so.
>
> Of course, for this to work, all development should
> be on the same system.
>
> Jan


As you an imagine given my background I really like the fact that
MyHDL is developed using mercurial, which I greatly prefer over git.

This is a bit off topic but I personally find the fact that so many
technical people use and even advocate git rather than mercurial both
surprising and a little depressing, since (IMHO) mercurial is a much
better all around version control system (_much_ better UI, better
tools, better Windows support, better, simpler model, etc). I think
github is a big reason why git is more popular than mercurial (at the
time github was created, there was nothing quite like it, unless you
count SourceForge...) but the real reason is probably the fact that it
was created by Linus... I guess we technical people are as prone to
decide things based on non technical reasons as anybody else...

You are right however that moving to github may give some additional
visibility to the project. That being said I think the MyHDL audience
may not be as likely to be on github as other more "pure software"
projects.

As an alternative, I find that BitBucket works really well and is also
very popular. It has very good support for mercurial (and git). It is
where TortoiseHg is hosted and it works really well. I find that its
features are on par with github.

In any case, I have contributed little to MyHDL (a few patches some
time ago, which are still waiting to be reviewed or applied, *hint*,
*hint* :-) so take my opinion for what is worth to the project.

Cheers,

Angel

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Christopher F. <chr...@gm...>]

On 4/14/13 2:28 PM, Jan Decaluwe wrote:
> On 04/14/2013 06:02 PM, Angel Ezquerra wrote:
>
>> Oscar,
>>
>> if you have never used mercurial and need some help drop me a line. I
>> am very active in TortoiseHg development (and a bit on mercurial as
>> well) so I think I could help bring you up to speed if you need it
>
> Interesting.
>
> Perhaps I should ask a more general question: should we
> consider to move MyHDL development to github?
>
> This is not a technical question. Many Pythonistas probably
> have a slight preference for Python-based mercurial.
> Professionally, I use both and I am happy with either one.
>
> The point is that "everyone" seems to be at github. So
> perhaps this is good for visibility.
>
> It may also be good for development. I like the way
> Oscar presented his work: it shows commitment to
> maintain the feature, and everyone can try/follow
> it without requiring my assistance. Much better
> than getting patches/bundles out of the blue that
> I am supposed to review/check/integrate before others
> can (easily) do so.
>
> Of course, for this to work, all development should
> be on the same system.
>
> Jan
>

As Jan eluded, there are two features:

    1) Improved work-flow:
       a) pull requests (largest impact)
       b) simplified interfaces (click buttons on webpages)
       c) default public (mods not local on private machine)

    2) Visibility (popular social thing)

If we feel #2 holds a lot of weight then github is the answer. If
visibility is important but not the most important then I would
suggest we stay with hg and use bitbucket (like pypy, sphinx,
cherrpy, ...).

For me a move to git vs. hg would be disruptive.  Not because
of some huge technical short-coming but because all my work has
been with hg and bitbucket.  If we move to git and github my
work flow and existing projects will not be compatible with the
new work flow (i.e. git and github).

Other than not being as popular I don't know of any technical
limitations of bitbucket vs. github.

It will be interesting to here back from Oscar, why he chose
github over bitbucket being myhdl uses hg.

My vote is to stay with hg and utilize bitbucket but I am not
adamantly opposed to git and github.  I do think it is important
that we start using bitbucket or github and pull requests.

Regards,
Chris

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Oscar D. D. <osc...@gm...>]

El Sun, 14 Apr 2013 19:48:15 -0500
Christopher Felton <chr...@gm...> escribió:

> On 4/14/13 2:28 PM, Jan Decaluwe wrote:
> > On 04/14/2013 06:02 PM, Angel Ezquerra wrote:
> >
> >> Oscar,
> >>
> >> if you have never used mercurial and need some help drop me a
> >> line. I am very active in TortoiseHg development (and a bit on
> >> mercurial as well) so I think I could help bring you up to speed
> >> if you need it
> >
> > Interesting.
> >
> > Perhaps I should ask a more general question: should we
> > consider to move MyHDL development to github?
> >
> > This is not a technical question. Many Pythonistas probably
> > have a slight preference for Python-based mercurial.
> > Professionally, I use both and I am happy with either one.

Well, I used both git and mercurial, but I decided to use git for
non-technical reasons: 1. git was the VCS used in my work and 2. github
was (and still is) very popular at that time (I didn't know about
bitbucket yet).

I don't mind switching to hg again, but I was used to github, and I
didn't know about bitbucket until couple months ago (In fact I'll sign
up and check it right now). 

> > The point is that "everyone" seems to be at github. So
> > perhaps this is good for visibility.

You're right, I'd prefer github because of its popularity and its
social features, but I don't see them a valid reason to make a
migration. 

> > It may also be good for development. I like the way
> > Oscar presented his work: it shows commitment to
> > maintain the feature, and everyone can try/follow
> > it without requiring my assistance. Much better
> > than getting patches/bundles out of the blue that
> > I am supposed to review/check/integrate before others
> > can (easily) do so.

That's the way I decided to present my contributions. When I started
this discussion couple months ago, I was really desperate to have this
feature, so I boldly went for it and patched up to the point of have
practically forked MyHDL. Then I started to "de-fork" and refactor
it, so I can propose an external module that can use with
minimal changes on MyHDL base code.

Of course, I'd love to have it added to mainstream code, but this way
is easier to debug and prevent from breaking base code. Besides, this
is an additional feature, my intention wasn't to change the original
conversion functions.

> > Of course, for this to work, all development should
> > be on the same system.
> >
> > Jan
> >
> 
> As Jan eluded, there are two features:
> 
>     1) Improved work-flow:
>        a) pull requests (largest impact)
>        b) simplified interfaces (click buttons on webpages)
>        c) default public (mods not local on private machine)
> 
>     2) Visibility (popular social thing)
> 
> If we feel #2 holds a lot of weight then github is the answer. If
> visibility is important but not the most important then I would
> suggest we stay with hg and use bitbucket (like pypy, sphinx,
> cherrpy, ...).
> 
> For me a move to git vs. hg would be disruptive.  Not because
> of some huge technical short-coming but because all my work has
> been with hg and bitbucket.  If we move to git and github my
> work flow and existing projects will not be compatible with the
> new work flow (i.e. git and github).
> 
> Other than not being as popular I don't know of any technical
> limitations of bitbucket vs. github.
> 
> It will be interesting to here back from Oscar, why he chose
> github over bitbucket being myhdl uses hg.
> 
> My vote is to stay with hg and utilize bitbucket but I am not
> adamantly opposed to git and github.  I do think it is important
> that we start using bitbucket or github and pull requests.

And here I totally agree with Chris. It's easier for me to try
bitbucket than move everyone to github.

Best regards.

PD: Angel, thanks for your help, I appreciate it.

-- 
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.fsf.org/campaigns/opendocument

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Oscar D. D. <osc...@gm...>]

> El Sun, 14 Apr 2013 19:48:15 -0500
> Christopher Felton <chr...@gm...> escribió:
>
>> My vote is to stay with hg and utilize bitbucket but I am not
>> adamantly opposed to git and github.  I do think it is important
>> that we start using bitbucket or github and pull requests.  
>
> And here I totally agree with Chris. It's easier for me to try
> bitbucket than move everyone to github.

Definitely bitbucket is a good alternative to github, I don't see any
other reason to move to github other than its popularity. Besides,
it seems pretty easy to work with both accounts. 

However, for the time being, I'll stick with github while keeping
bitbucket repo in sync.

Best regards,

-- 
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.fsf.org/campaigns/opendocument

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Jan D. <ja...@ja...>]

All - thanks for the feedback.

I think a consensus is growing: stay with hg,
but move to bitbucket for development, because
it should improve the process: public forks
to demonstrate features, and pull requests
instead of patches and bundles.

I'm all for it - as a trial, I've imported
the main repo on bitbucket already and this
seems to work fine. (jandecaluwe/myhdl).

Jan


On 04/15/2013 02:48 AM, Christopher Felton wrote:
> On 4/14/13 2:28 PM, Jan Decaluwe wrote:
>> On 04/14/2013 06:02 PM, Angel Ezquerra wrote:
>>
>>> Oscar,
>>>
>>> if you have never used mercurial and need some help drop me a line. I
>>> am very active in TortoiseHg development (and a bit on mercurial as
>>> well) so I think I could help bring you up to speed if you need it
>>
>> Interesting.
>>
>> Perhaps I should ask a more general question: should we
>> consider to move MyHDL development to github?
>>
>> This is not a technical question. Many Pythonistas probably
>> have a slight preference for Python-based mercurial.
>> Professionally, I use both and I am happy with either one.
>>
>> The point is that "everyone" seems to be at github. So
>> perhaps this is good for visibility.
>>
>> It may also be good for development. I like the way
>> Oscar presented his work: it shows commitment to
>> maintain the feature, and everyone can try/follow
>> it without requiring my assistance. Much better
>> than getting patches/bundles out of the blue that
>> I am supposed to review/check/integrate before others
>> can (easily) do so.
>>
>> Of course, for this to work, all development should
>> be on the same system.
>>
>> Jan
>>
>
> As Jan eluded, there are two features:
>
>      1) Improved work-flow:
>         a) pull requests (largest impact)
>         b) simplified interfaces (click buttons on webpages)
>         c) default public (mods not local on private machine)
>
>      2) Visibility (popular social thing)
>
> If we feel #2 holds a lot of weight then github is the answer. If
> visibility is important but not the most important then I would
> suggest we stay with hg and use bitbucket (like pypy, sphinx,
> cherrpy, ...).
>
> For me a move to git vs. hg would be disruptive.  Not because
> of some huge technical short-coming but because all my work has
> been with hg and bitbucket.  If we move to git and github my
> work flow and existing projects will not be compatible with the
> new work flow (i.e. git and github).
>
> Other than not being as popular I don't know of any technical
> limitations of bitbucket vs. github.
>
> It will be interesting to here back from Oscar, why he chose
> github over bitbucket being myhdl uses hg.
>
> My vote is to stay with hg and utilize bitbucket but I am not
> adamantly opposed to git and github.  I do think it is important
> that we start using bitbucket or github and pull requests.
>
> Regards,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
>


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Christopher F. <chr...@gm...>]

On 4/14/13 2:48 PM, Angel Ezquerra wrote:
> On Sun, Apr 14, 2013 at 9:28 PM, Jan Decaluwe <ja...@ja...> wrote:
>> On 04/14/2013 06:02 PM, Angel Ezquerra wrote:
>>
>>> Oscar,
>>>
>>> if you have never used mercurial and need some help drop me a line. I
>>> am very active in TortoiseHg development (and a bit on mercurial as
>>> well) so I think I could help bring you up to speed if you need it
>>
>> Interesting.
>>
>> Perhaps I should ask a more general question: should we
>> consider to move MyHDL development to github?
>>
>> This is not a technical question. Many Pythonistas probably
>> have a slight preference for Python-based mercurial.
>> Professionally, I use both and I am happy with either one.
>>
>> The point is that "everyone" seems to be at github. So
>> perhaps this is good for visibility.
>>
>> It may also be good for development. I like the way
>> Oscar presented his work: it shows commitment to
>> maintain the feature, and everyone can try/follow
>> it without requiring my assistance. Much better
>> than getting patches/bundles out of the blue that
>> I am supposed to review/check/integrate before others
>> can (easily) do so.
>>
>> Of course, for this to work, all development should
>> be on the same system.
>>
>> Jan
>
>
> As you an imagine given my background I really like the fact that
> MyHDL is developed using mercurial, which I greatly prefer over git.
>
> This is a bit off topic but I personally find the fact that so many
> technical people use and even advocate git rather than mercurial both
> surprising and a little depressing, since (IMHO) mercurial is a much
> better all around version control system (_much_ better UI, better
> tools, better Windows support, better, simpler model, etc). I think
> github is a big reason why git is more popular than mercurial (at the
> time github was created, there was nothing quite like it, unless you
> count SourceForge...) but the real reason is probably the fact that it
> was created by Linus... I guess we technical people are as prone to
> decide things based on non technical reasons as anybody else...

Can you outline some of the technical pros?  From what I have been
able to gather it is somewhat subjective.  It seems both projects
have been influence each other resulting in technical equals.

I have found some short coming with git and my work flow but I assume
that was me being less familiar with git than hg.

Regards,
Chris

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Angel E. <ang...@gm...>]

On Mon, Apr 15, 2013 at 2:52 AM, Christopher Felton
<chr...@gm...> wrote:
> On 4/14/13 2:48 PM, Angel Ezquerra wrote:
>> On Sun, Apr 14, 2013 at 9:28 PM, Jan Decaluwe <ja...@ja...> wrote:
>>> On 04/14/2013 06:02 PM, Angel Ezquerra wrote:
>>>
>>>> Oscar,
>>>>
>>>> if you have never used mercurial and need some help drop me a line. I
>>>> am very active in TortoiseHg development (and a bit on mercurial as
>>>> well) so I think I could help bring you up to speed if you need it
>>>
>>> Interesting.
>>>
>>> Perhaps I should ask a more general question: should we
>>> consider to move MyHDL development to github?
>>>
>>> This is not a technical question. Many Pythonistas probably
>>> have a slight preference for Python-based mercurial.
>>> Professionally, I use both and I am happy with either one.
>>>
>>> The point is that "everyone" seems to be at github. So
>>> perhaps this is good for visibility.
>>>
>>> It may also be good for development. I like the way
>>> Oscar presented his work: it shows commitment to
>>> maintain the feature, and everyone can try/follow
>>> it without requiring my assistance. Much better
>>> than getting patches/bundles out of the blue that
>>> I am supposed to review/check/integrate before others
>>> can (easily) do so.
>>>
>>> Of course, for this to work, all development should
>>> be on the same system.
>>>
>>> Jan
>>
>>
>> As you an imagine given my background I really like the fact that
>> MyHDL is developed using mercurial, which I greatly prefer over git.
>>
>> This is a bit off topic but I personally find the fact that so many
>> technical people use and even advocate git rather than mercurial both
>> surprising and a little depressing, since (IMHO) mercurial is a much
>> better all around version control system (_much_ better UI, better
>> tools, better Windows support, better, simpler model, etc). I think
>> github is a big reason why git is more popular than mercurial (at the
>> time github was created, there was nothing quite like it, unless you
>> count SourceForge...) but the real reason is probably the fact that it
>> was created by Linus... I guess we technical people are as prone to
>> decide things based on non technical reasons as anybody else...
>
> Can you outline some of the technical pros?  From what I have been
> able to gather it is somewhat subjective.  It seems both projects
> have been influence each other resulting in technical equals.

Before I start I want to first state that I am way more knowledgeable
about mercurial than about git. As I said I contribute to mercurial in
addition to using it everyday (for work and for my own stuff). I have
much less experience with git, but I believe I have enough to judge
both systems on their merits.

With that being said, and taking into account that everything I say
here is just my humble opinion and that my git-fu is not nearly as
good as my mercurial-fu...

/rant mode on :-)

In truth both systems are more similar than they are different. Both
are excellent distributed version control systems with a pretty
similar technical foundation. This makes sense since both were
originally designed to solve the same problem, notably, the
replacement of BitKeeper as the version control system for the Linux
kernel. Both had their first version publicly released pretty much
simultaneously (withing a couple of days I think) and both were
created by notable Linux kernel hackers (although obviously one of
them is the most notable and famous kernel hacker of them all :-) ).
Both handle and use pretty similar concepts, even though some of the
user facing names they use are not the same (e.g. git branches ˜
mercurial bookmarks).

However, precisely because they are so similar, the few differences
they have become very important. In particular:

1. Git's UI is atrocious: Tens of commands, some of which do pretty
much but not quite the same, some of which do 2, even 3 totally
different, almost unrelated things depending on the command line
arguments; commands which by default do the "wrong" thing (i.e. you
must always use a particular combination of command line parameters to
do the right thing), etc (Steve Losh recently made a funny and just
slightly togue in cheek blog post about this title "Git koans":
http://stevelosh.com/blog/2013/04/git-koans/).

Another thing which is a bit of putting and a symptom of a lack of
clear UI design (although in practice is not a big deal) is the fact
that most git's commands are in their own shells scripts or programs
(rather than a single stand alone command).

If you compare git's command line UI with mercurial's command line UI
the difference is like night and day. There are very few important
mercurial commands (init, clone, commit, update, pull and push) and
each of them does one main thing, and it does it by default (no extra
parameters needed in the usual case). There are other mercurial
commands (add, remove, revert, etc) and all commands have some options
but you do not usually need to use them.

In a funny, kind of perverse way I think this is one of the things
that made git so popular. Git is so hard to use that once people
finally manage to master it they feel a sense of accomplishment which
compels them to write / blog about it. Why are there so many git
tutorials? Is it because git is cool or because it is hard? People
seem to think that the huge number of git tutorials and git blog
postsare due to git being very popular. That is partly true, but I
think the real reason is because it is just hard.

Mercurial on the other hand is just easy (for a version control
system). People just learn to use it and get on with their work. There
is no need to brag about it because there is nothing to brag about.
This is also what makes (again, this is _all_ IMHO) many git users so
fiercely defensive when you criticize their tool of choice. To them
git's UI is not bad, it is just they way it is. If you don't like it
it is because you do not get it. The fact that you must understand
git's internals to get anything serious done is not bad, it is
awesome, etc, etc. It is as if they suffer from some sort of Helsinki
syndrome :->

2. I find that most git GUI tools are poor compared to mercurial's
equivalents (despite their developer's best efforts). This is a direct
consequence of the poor git command line UI. This is not due to a lack
of competence on the git GUI tool developers (which I respect and even
sympathize with). It is due to the fact that they must somehow map
git's command line UI concepts into a sane GUI, which is _very_ hard.
Basically they are between a rock and a hard place because they can
either expose all the rich git functionality at the cost of a complex
UI or they can have a simple UI but lose a lot of what makes git
powerful. I do not think that is as much the case for mercurial GUI
tools and for TortosieHg in particular. I cannot claim that TortoiseHg
is perfect (it is not) but I think the fact that the underlying
mercurial command line model is so clean makes our job of exposing all
of mercurial's power much easier.

3. Git is _very_ Unix-centric. This may improve in the future, given
that Microsoft Visual Studio will soon get built-in git support, but
even then git on Windows relies and will continue to rely on MinGW. A
lot of the things that make git fast are only true on Unix (specially
on Linux).

On the other hand, mercurial is truly cross platform and runs on
windows natively (thanks to it being mostly written in Python).

4. In mercurial, history is "sacred" and "append only" by _default_.
You can easily edit history, but this is discouraged in many subtle
ways, such as the need to manually edit the history editing extensions
(such as mq and rebase). In git, editing history, even _other people's
history_ is not only possible but almost encouraged. I find that is a
big red flag for a version control system. In addition, mercurial is
getting built-in and _safe_ history rewriting commands (this is still
a work in progress, but it is almost done) which add a way to create
new revisions that "replace" old revisions while still keeping the old
revisions around (for more info, check
http://hg-lab.logilab.org/doc/mutable-history/html/).

5. mercurial has cheaper branching that git. This may shock some
people because git users usually claim that that git's branches are
much cheaper than mercurial's. When they say so they often also
mention that mercurial branches are "clones". If you hear that then
you can stop listening to whoever says it because he has not used a
less than 3 year's old mercurial version. Mercurial now has 4 ways to
branch: clones, named branches, bookmarks and anonymous branches.
"mercurial bookmarks" are pretty much the same as "git branches"
although there are some small differences. There are no named branches
nor anonymous branches in git. Anonymous branches are the cheapest
branches of all because you do not need to create them explicitly.
They just happen and you can deal with them as you want. They are a
very powerful and simple concept which (as all in this rant) IMHO let
mercurial capture what really happen when two contributors do
different things based on the same point in history.

6. Mercurial is easier to extend. Its hook and extension system is
very easy to use and give you a lot of power. You can use external
programs but you can also use python and when you do so you have
access to all the mercurial's internals. This has the drawback that if
the mercurial internals change you may need to update your extension,
but in my experience this is rarely necessary.

This is not to say that mercurial is perfect or even better than git
in every way. Its "submodule" support (what mercurial calls
"subrepos") can be (and is being) improved for example. The way it
handles tags is perhaps a little confusing (although it makes sense
when you understand it), etc. Git's clones are often a bit smaller
than mercurial's and git is a bit faster than mercurial on Linux. I
don't think these small advantages are significant enough for most
users, and that mercurial is just the better overall tool.

I've personally had to introduce a lot of people to mercurial (several
tens of people, probably about one hundred). Many of these are
hardware and firmware engineers (the kind of people that MyHDL could
target) for whom a good version control system before learning
mercurial was zip + Skype. I had a very easy time helping them get up
to speed with mercurial. I shudder to think how hard it would have
been to help them reach the same level of proficiency with git.

/rant mode off

> I have found some short coming with git and my work flow but I assume
> that was me being less familiar with git than hg.

I'm curious to know about your experience. Care to share?

Cheers,

Angel

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Christopher F. <chr...@gm...>]

>> I have found some short coming with git and my work flow but I assume
>> that was me being less familiar with git than hg.
>
> I'm curious to know about your experience. Care to share?

I don't mind sharing but I do think I will embarrass
myself :)  I am sure, to a experienced git'er it is
basic or they would be appalled at my work flow.

I had created a MyHDL version for the fpgalink project[1]
but the module was embedded in another project I had on
bitbucket.  Since, fpgalink was on github I decided to
try and get a little more experience with git.  So I
created a project on github, cloned it to my pc and started
adding the files, commits, making modifications, etc.  Then
I had to travel or something and made a clone from my pc
to a laptop.  Made some changes, commits etc.

Now when I tried to push back to the pc it didn't work.
It said I could not push to a repo with modifications?  I
was confused.  I was unable to resolve the issue, I had to
do merge things manually.

I think the solution I would have been told would be to
push to github and then sync the pc with github.  But this
is not what I wanted to achieve.

Regards,
Chris

[1] https://groups.google.com/forum/#!topic/fpgalink-users/Oxh2Hu08J8A

Note the above post is outdated, I moved the code from the
original repo in the post to a github repo (or I tried,
still haven't gotten it pushed back).

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Angel E. <ang...@gm...>]

On Mon, Apr 15, 2013 at 2:52 AM, Christopher Felton
<chr...@gm...> wrote:
> On 4/14/13 2:48 PM, Angel Ezquerra wrote:
>> On Sun, Apr 14, 2013 at 9:28 PM, Jan Decaluwe <ja...@ja...> wrote:
>>> On 04/14/2013 06:02 PM, Angel Ezquerra wrote:
>>>
>>>> Oscar,
>>>>
>>>> if you have never used mercurial and need some help drop me a line. I
>>>> am very active in TortoiseHg development (and a bit on mercurial as
>>>> well) so I think I could help bring you up to speed if you need it
>>>
>>> Interesting.
>>>
>>> Perhaps I should ask a more general question: should we
>>> consider to move MyHDL development to github?
>>>
>>> This is not a technical question. Many Pythonistas probably
>>> have a slight preference for Python-based mercurial.
>>> Professionally, I use both and I am happy with either one.
>>>
>>> The point is that "everyone" seems to be at github. So
>>> perhaps this is good for visibility.
>>>
>>> It may also be good for development. I like the way
>>> Oscar presented his work: it shows commitment to
>>> maintain the feature, and everyone can try/follow
>>> it without requiring my assistance. Much better
>>> than getting patches/bundles out of the blue that
>>> I am supposed to review/check/integrate before others
>>> can (easily) do so.
>>>
>>> Of course, for this to work, all development should
>>> be on the same system.
>>>
>>> Jan
>>
>>
>> As you an imagine given my background I really like the fact that
>> MyHDL is developed using mercurial, which I greatly prefer over git.
>>
>> This is a bit off topic but I personally find the fact that so many
>> technical people use and even advocate git rather than mercurial both
>> surprising and a little depressing, since (IMHO) mercurial is a much
>> better all around version control system (_much_ better UI, better
>> tools, better Windows support, better, simpler model, etc). I think
>> github is a big reason why git is more popular than mercurial (at the
>> time github was created, there was nothing quite like it, unless you
>> count SourceForge...) but the real reason is probably the fact that it
>> was created by Linus... I guess we technical people are as prone to
>> decide things based on non technical reasons as anybody else...
>
> Can you outline some of the technical pros?  From what I have been
> able to gather it is somewhat subjective.  It seems both projects
> have been influence each other resulting in technical equals.
>
> I have found some short coming with git and my work flow but I assume
> that was me being less familiar with git than hg.

Sorry it took me a long time to reply to this. I've been quite busy as of late.

At their base, git and mercurial are quite similar. However they
differ in some important details, some of which make git the less
reliable tool. In particular:

1. mercurial supports anonymous branches (i.e. non linear branches).
This has the very good side effect of making the "pull" operation
completely safe, which is not the case in git I believe. Let me give
you an example:

Imagine a scenario were Alice and Bob are using git and they are
collaborating on the same feature. Both of them are working on the
same feature branch. Alice makes a few local commits but doesn't push
them yet. Bob colleague does a few commits on his own PC and pushes
them to master. When Allice pulls from master her local commits are
automatically rebased on top Bob's commits. Even assuming that the
rebase goes perfectly, Alice's  original commits are gone! That is,
the code that Alice originally committed is not the same code that she
has now. As far as I know there is no way to get the original commits
back. This is (IMHO) extremely unsafe.

Compare that with the same scenario in mercurial. When you Alice pulls
from the central repo (let's call it default) she just gets Bob's
commits as a new anonymous branch (with a new head). Then Alice can,
at her own leisure, just do a merge between her anonymous branch and
the one she got from Bob. Her old commits are still there and she can
come back to them whenever she wants to. She also has the option to do
a rebase, in which case the result would be the same as in git, but
that is just an option, and is not the default, and it would happen
_after_ the pull is done.

The key difference here is that mercurial, thanks to its support of
anonymous branches can reliably represent what really happened (that
Alice's and Bob's histories diverged), while git cannot (since it
requires all branches to be linear).

There are solutions to this problem in git (e.g. Alice and Bob could
work on separate branches), but they are not as natural as in
mercurial (IMHO!).

2. The ui's. Git's UI is famous for being inconsistent
(www.youtube.com/watch?v=CDeG4S-mJts), while mercurial's is very
consistent, uniform and carefully designed. It is not perfect (nothing
is!) but it is much better.

3. Extensibility: Mercurial's hook and extension system is very
powerful and easy to use because it is all python based. To extend git
people usually write shell scripts on top of the "plumbing commands"
(or whatever they are called). I've been told (I have no direct
experience extending git) that it is not nearly as easy nor as nice to
do that as it is to extend mercurial (which I've done and is really
easy).

4. Mercurial tracks the "phase" of revisions. Mercurial keeps track of
which revisions have been "shared" (pulled or pushed) and (by default)
will not let you perform history editing operation ond shared
revisions. As far as I know git dot not have this concept, and thus is
happy to let you shoot yourself on the foot if you are not extremely
careful.

5. Mercurial is safe (append only) by default. This is something that
not everybody agrees, but I really like that mercurial does not enable
any of the unsafe history editing operations by default. To use them
you must manually enable their corresponding extensions (i.e. you must
confirm that you know what you are doing).

That is not to say that mercurial is better in all regards to git. Git
is a very nice and powerful tool. But where it matters mercurial is
better (IMHO) .

I hope these answer your question. I'm curious what problems did you
find on your own?

Cheers,

Angel

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Jan D. <ja...@ja...>]

On 05/09/2013 08:49 AM, Angel Ezquerra wrote:

> 1. mercurial supports anonymous branches (i.e. non linear branches).
> This has the very good side effect of making the "pull" operation
> completely safe, which is not the case in git I believe. Let me give
> you an example:

> The key difference here is that mercurial, thanks to its support of
> anonymous branches can reliably represent what really happened (that
> Alice's and Bob's histories diverged), while git cannot (since it
> requires all branches to be linear).

I think you are wrong here. You seem to suggest that
git pull by default does a rebase, which is not true at all.

git pull by default is shorthand for git fetch; git merge.

This would be similar to hg pull; hg update or hg merge if history
has diverged.

In both git and mercurial, a merge commit will be created by default.

If you want rebase in git, you do git fetch; git rebase. In fact,
rebase is an alternative merging strategy, which I consider superior
for local commits, because it keeps the history as it will be pushed
out more linear.

But again, this is not the default in git. It seems hg now has
rebase as well, probably because more people realize it's actually
a good and "polite" strategy to rebase your local commits.

As I understand, hg makes rebase safer using phases, which I agree
is a good thing, as one should never rebase commits that have been
published already.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Angel E. <ang...@gm...>]

On Thu, May 9, 2013 at 12:14 PM, Jan Decaluwe <ja...@ja...> wrote:
> On 05/09/2013 08:49 AM, Angel Ezquerra wrote:
>
>> 1. mercurial supports anonymous branches (i.e. non linear branches).
>> This has the very good side effect of making the "pull" operation
>> completely safe, which is not the case in git I believe. Let me give
>> you an example:
>
>> The key difference here is that mercurial, thanks to its support of
>> anonymous branches can reliably represent what really happened (that
>> Alice's and Bob's histories diverged), while git cannot (since it
>> requires all branches to be linear).
>
> I think you are wrong here. You seem to suggest that
> git pull by default does a rebase, which is not true at all.
>
> git pull by default is shorthand for git fetch; git merge.

True, I was wrong. I thought that was the default behavior since I've
seen many git users do that. It is hard to tell what is the default
behavior of a given git command! A lot of git commands do many
different things depending on the flags they are provided. This means
that to get git to do some things you _must_ always call a git command
with a given set of flags (i.e. people always use some flags with some
commands, making them "default" behavior). I thought that was the case
for "git pull --rebase" (I think this is apropos:
http://stevelosh.com/blog/2013/04/git-koans/).

Note that I am a heavy mercurial user, but a very occasional git user,
so please take anything I say about git with a healthy dose of
skepticism, though :-)

> This would be similar to hg pull; hg update or hg merge if history
> has diverged.
>
> In both git and mercurial, a merge commit will be created by default.

That is not true, and probably is the key difference. In mercurial no
mew commit is ever created when you do hg pull and it is not done when
you do hg merge either. You must explicitly do hg commit to "confirm"
your merge (once you do it).

It is key that in mercurial the pull and merge steps are separate
commands. hg pull does not imply hg merge. Thus in mercurial you can
just pull some new revisions, inspect them, and when you want to can
do the merge (or a rebase if you are so inclined). Pulling new changes
is 100% safe, even if you have local, uncommitted changes.

If I understand how git works correctly, you could do the same thing
by doing git fetch. However I believe this is not what most people do?

So basically mercurial's default workflow makes it very easy to keep
both versions of history (Alice's and Bob's) "alive" until you are
ready to either merge them or rebase them. What I think (please
correct me if I am wrong) is git's default workflow (using "git pull"
rather than "git fetch") makes it harder, and if you use "git pull
--rebase" (as many people do) then it makes it impossible. So things
are notas as bad as I thought but still not nearly as safe as
Mercurial.

To sum up, I stand corrected, but I still think that mercurial is safer.

> If you want rebase in git, you do git fetch; git rebase. In fact,
> rebase is an alternative merging strategy, which I consider superior
> for local commits, because it keeps the history as it will be pushed
> out more linear.

I do rebase often, but I do so with the knowledge that it is a
dangerous, history destroying operation. That is why I don't think it
is such a good idea to encourage inexperienced users to use rebase.

That being said, mercurial is in the process of getting something
called "changeset evolution" which makes rebase and many other history
editing operations 100% safe (by hiding, rather than eliminating the
old, unrebased versions of the revisions). This is not ready yet, but
it should be ready in about 6 months.

> But again, this is not the default in git. It seems hg now has
> rebase as well, probably because more people realize it's actually
> a good and "polite" strategy to rebase your local commits.
>
> As I understand, hg makes rebase safer using phases, which I agree
> is a good thing, as one should never rebase commits that have been
> published already.

That is correct. Hopefully git will get the same functionality at some point.

Cheers,

Angel

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Jan D. <ja...@ja...>]

On 05/09/2013 02:09 PM, Angel Ezquerra wrote:
> On Thu, May 9, 2013 at 12:14 PM, Jan Decaluwe <ja...@ja...> wrote:

> That is not true, and probably is the key difference. In mercurial no
> mew commit is ever created when you do hg pull and it is not done when
> you do hg merge either. You must explicitly do hg commit to "confirm"
> your merge (once you do it).

What I meant is that in both cases in the "default" workflow,
a merge commit will eventually appear in the history, so that
you can clearly see how and where the diverged branches converge
(which was your original concern).

hg pull is more like git fetch; it is true that git pull tries
to do many things at once which is not necessarily what you want
on large projects. I prefer git fetch, no idea what most people
do.

Note that for MyHDL there is basically a consensus to stick
with mercurial - I have already put a repo on bitbucket that
I intend to use as the main repo.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Angel E. <ang...@gm...>]

On Thu, May 9, 2013 at 4:04 PM, Jan Decaluwe <ja...@ja...> wrote:
> On 05/09/2013 02:09 PM, Angel Ezquerra wrote:
>> On Thu, May 9, 2013 at 12:14 PM, Jan Decaluwe <ja...@ja...> wrote:
>
>> That is not true, and probably is the key difference. In mercurial no
>> mew commit is ever created when you do hg pull and it is not done when
>> you do hg merge either. You must explicitly do hg commit to "confirm"
>> your merge (once you do it).
>
> What I meant is that in both cases in the "default" workflow,
> a merge commit will eventually appear in the history, so that
> you can clearly see how and where the diverged branches converge
> (which was your original concern).

OK, I understand what you meant now.

> hg pull is more like git fetch; it is true that git pull tries
> to do many things at once which is not necessarily what you want
> on large projects. I prefer git fetch, no idea what most people
> do.

I also think using git fetch is the sensible thing to do, but it is
not what I've seen people use most of the time, which I find quite
weird.

> Note that for MyHDL there is basically a consensus to stick
> with mercurial - I have already put a repo on bitbucket that
> I intend to use as the main repo.

Yes, I know that. I was just trying to answer Chris Felton's question
about why I prefer mercurial to git.

Cheers,

Angel

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Keerthan jai.c <jck...@gm...>]

Since I am not an expert on either git or hg, I won't comment on the
technical aspects. However I think that github is a better place to host
the main myhdl repo.

Reasons why I think we should switch to github:
1) Hosting myhdl on github will improve the visibility of the project, and
more people will contribute.
see
http://eli.thegreenplace.net/2013/06/09/switching-my-open-source-projects-from-bitbucket-to-github/

2) Github is arguably a better/more poular platform.
For example, travis-ci(continuous integration) supports github but not
bitbucket. While there are alternatives to travis-ci, none of the free ones
are as good.
You can check out the UI of travis-ci here:
https://travis-ci.org/kennethreitz/requests

travis-ci is deeply integrated with github, this makes the process of pull
requests way simpler.
If travis is configured(a simple yml file in the repository root), travis
automatically runs tests on all commits and pull requests. From the github
pull requests page, you can see if tests passed/failed. And additionally,
get details about failed tests.
This is how it looks:
tests passed:
http://danlimerick.files.wordpress.com/2013/02/safetomergeprtravis.png
tests failed:
http://danlimerick.files.wordpress.com/2013/02/failedprtravis.png


Thanks to this, users can submit quick bugfixes as pull requests and the
repo owner can accept pull requests without worrying too much(or without
pulling changes and running tests) if tests pass.
I imagine bugs like these: (
https://bitbucket.org/jandecaluwe/myhdl/issue/3/always_seq-decorator-error-message-string)
would be handled much quicker.

Additionally, github's UI makes it easy to see what other contributors are
up to, this makes it easier to co-ordinate and might make some people more
confident about contributing.
see: https://github.com/blog/39-say-hello-to-the-network-graph-visualizer

3) git and hg workflows aren't too different. hg users will not have too
much trouble contributing to git repos. Additionally, there are tools like
hg-git which allow you to use hg locally while contributing to a git remote.
http://hg-git.github.io/





On Fri, May 10, 2013 at 6:50 PM, Angel Ezquerra <ang...@gm...>wrote:

> On Thu, May 9, 2013 at 4:04 PM, Jan Decaluwe <ja...@ja...> wrote:
> > On 05/09/2013 02:09 PM, Angel Ezquerra wrote:
> >> On Thu, May 9, 2013 at 12:14 PM, Jan Decaluwe <ja...@ja...>
> wrote:
> >
> >> That is not true, and probably is the key difference. In mercurial no
> >> mew commit is ever created when you do hg pull and it is not done when
> >> you do hg merge either. You must explicitly do hg commit to "confirm"
> >> your merge (once you do it).
> >
> > What I meant is that in both cases in the "default" workflow,
> > a merge commit will eventually appear in the history, so that
> > you can clearly see how and where the diverged branches converge
> > (which was your original concern).
>
> OK, I understand what you meant now.
>
> > hg pull is more like git fetch; it is true that git pull tries
> > to do many things at once which is not necessarily what you want
> > on large projects. I prefer git fetch, no idea what most people
> > do.
>
> I also think using git fetch is the sensible thing to do, but it is
> not what I've seen people use most of the time, which I find quite
> weird.
>
> > Note that for MyHDL there is basically a consensus to stick
> > with mercurial - I have already put a repo on bitbucket that
> > I intend to use as the main repo.
>
> Yes, I know that. I was just trying to answer Chris Felton's question
> about why I prefer mercurial to git.
>
> Cheers,
>
> Angel
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
have a nice day
-jck

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Keerthan jai.c <jck...@gm...>]

Additionally, travis runs tests using multiple python versions. So we can
make it run tests with 2.6,2.7 and pypy. I beleive this will be very useful
during the python3 migration process.


On Wed, Sep 4, 2013 at 3:12 PM, Keerthan jai.c <jck...@gm...> wrote:

> Since I am not an expert on either git or hg, I won't comment on the
> technical aspects. However I think that github is a better place to host
> the main myhdl repo.
>
> Reasons why I think we should switch to github:
> 1) Hosting myhdl on github will improve the visibility of the project, and
> more people will contribute.
> see
> http://eli.thegreenplace.net/2013/06/09/switching-my-open-source-projects-from-bitbucket-to-github/
>
> 2) Github is arguably a better/more poular platform.
> For example, travis-ci(continuous integration) supports github but not
> bitbucket. While there are alternatives to travis-ci, none of the free ones
> are as good.
> You can check out the UI of travis-ci here:
> https://travis-ci.org/kennethreitz/requests
>
> travis-ci is deeply integrated with github, this makes the process of pull
> requests way simpler.
> If travis is configured(a simple yml file in the repository root), travis
> automatically runs tests on all commits and pull requests. From the github
> pull requests page, you can see if tests passed/failed. And additionally,
> get details about failed tests.
> This is how it looks:
> tests passed:
> http://danlimerick.files.wordpress.com/2013/02/safetomergeprtravis.png
> tests failed:
> http://danlimerick.files.wordpress.com/2013/02/failedprtravis.png
>
>
> Thanks to this, users can submit quick bugfixes as pull requests and the
> repo owner can accept pull requests without worrying too much(or without
> pulling changes and running tests) if tests pass.
> I imagine bugs like these: (
> https://bitbucket.org/jandecaluwe/myhdl/issue/3/always_seq-decorator-error-message-string) would be handled much quicker.
>
> Additionally, github's UI makes it easy to see what other contributors are
> up to, this makes it easier to co-ordinate and might make some people more
> confident about contributing.
> see: https://github.com/blog/39-say-hello-to-the-network-graph-visualizer
>
> 3) git and hg workflows aren't too different. hg users will not have too
> much trouble contributing to git repos. Additionally, there are tools like
> hg-git which allow you to use hg locally while contributing to a git remote.
> http://hg-git.github.io/
>
>
>
>
>
> On Fri, May 10, 2013 at 6:50 PM, Angel Ezquerra <ang...@gm...>wrote:
>
>> On Thu, May 9, 2013 at 4:04 PM, Jan Decaluwe <ja...@ja...> wrote:
>> > On 05/09/2013 02:09 PM, Angel Ezquerra wrote:
>> >> On Thu, May 9, 2013 at 12:14 PM, Jan Decaluwe <ja...@ja...>
>> wrote:
>> >
>> >> That is not true, and probably is the key difference. In mercurial no
>> >> mew commit is ever created when you do hg pull and it is not done when
>> >> you do hg merge either. You must explicitly do hg commit to "confirm"
>> >> your merge (once you do it).
>> >
>> > What I meant is that in both cases in the "default" workflow,
>> > a merge commit will eventually appear in the history, so that
>> > you can clearly see how and where the diverged branches converge
>> > (which was your original concern).
>>
>> OK, I understand what you meant now.
>>
>> > hg pull is more like git fetch; it is true that git pull tries
>> > to do many things at once which is not necessarily what you want
>> > on large projects. I prefer git fetch, no idea what most people
>> > do.
>>
>> I also think using git fetch is the sensible thing to do, but it is
>> not what I've seen people use most of the time, which I find quite
>> weird.
>>
>> > Note that for MyHDL there is basically a consensus to stick
>> > with mercurial - I have already put a repo on bitbucket that
>> > I intend to use as the main repo.
>>
>> Yes, I know that. I was just trying to answer Chris Felton's question
>> about why I prefer mercurial to git.
>>
>> Cheers,
>>
>> Angel
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and
>> their applications. This 200-page book is written by three acclaimed
>> leaders in the field. The early access version is available now.
>> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>
>
>
> --
> have a nice day
> -jck
>



-- 
have a nice day
-jck

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Christopher F. <chr...@gm...>]

On 9/4/13 2:12 PM, Keerthan jai.c wrote:
> Since I am not an expert on either git or hg, I won't comment on the
> technical aspects. However I think that github is a better place to host
> the main myhdl repo.
>
> Reasons why I think we should switch to github:
> 1) Hosting myhdl on github will improve the visibility of the project,
> and more people will contribute.
> see
> http://eli.thegreenplace.net/2013/06/09/switching-my-open-source-projects-from-bitbucket-to-github/
>

My personal experience is: this is not true.  I have
projects on github and bitbucket.  Simply being on
github, I don't see any evidence of increased visibility,
etc.

There are counter anecdotes with pypy, sphinx, etc on
bitbucket - successful projects (high visibility).  I think
there are other factors, not simply being hosted on X or Y.

> 2) Github is arguably a better/more poular platform.
> For example, travis-ci(continuous integration) supports github but not
> bitbucket. While there are alternatives to travis-ci, none of the free
> ones are as good.
> You can check out the UI of travis-ci here:
> https://travis-ci.org/kennethreitz/requests
>
> travis-ci is deeply integrated with github, this makes the process of
> pull requests way simpler.
> If travis is configured(a simple yml file in the repository root),
> travis automatically runs tests on all commits and pull requests. From
> the github pull requests page, you can see if tests passed/failed. And
> additionally, get details about failed tests.
> This is how it looks:
> tests passed:
> http://danlimerick.files.wordpress.com/2013/02/safetomergeprtravis.png
> tests failed:
> http://danlimerick.files.wordpress.com/2013/02/failedprtravis.png
>

This is definitely a plus but it is only a partial plus
in MyHDL's case.  To do full regression-testing on any
pull requests you would need a verilog and vhdl simulators.

>
> Thanks to this, users can submit quick bugfixes as pull requests and the
> repo owner can accept pull requests without worrying too much(or without
> pulling changes and running tests) if tests pass.
> I imagine bugs like these: (
> https://bitbucket.org/jandecaluwe/myhdl/issue/3/always_seq-decorator-error-message-string
> ) would be handled much quicker.
>
> Additionally, github's UI makes it easy to see what other contributors
> are up to, this makes it easier to co-ordinate and might make some
> people more confident about contributing.
> see: https://github.com/blog/39-say-hello-to-the-network-graph-visualizer
>
> 3) git and hg workflows aren't too different. hg users will not have too
> much trouble contributing to git repos. Additionally, there are tools
> like hg-git which allow you to use hg locally while contributing to a
> git remote.
> http://hg-git.github.io/
>

If hg-git works nice, there could be a mirror on github
(note someone already created a mirror on github).  I have
not been able to get hg-git to work.  I am moving some of my
github projects to bitbucket because I don't see any benefit
of having them on github (exception travis-ci).

I think we have hashed through this topic, I don't know if the
travis-ci is enough to overturn the inertia.

Regards,
Chris

Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Keerthan jai.c <jck...@gm...>]

>This is definitely a plus but it is only a partial plus
>in MyHDL's case.  To do full regression-testing on any
>pull requests you would need a verilog and vhdl simulators.

We won't be able to use modelsim but we can certainly use icarus and ghdl
on travis.


On Wed, Sep 4, 2013 at 10:14 PM, Christopher Felton
<chr...@gm...>wrote:

> On 9/4/13 2:12 PM, Keerthan jai.c wrote:
> > Since I am not an expert on either git or hg, I won't comment on the
> > technical aspects. However I think that github is a better place to host
> > the main myhdl repo.
> >
> > Reasons why I think we should switch to github:
> > 1) Hosting myhdl on github will improve the visibility of the project,
> > and more people will contribute.
> > see
> >
> http://eli.thegreenplace.net/2013/06/09/switching-my-open-source-projects-from-bitbucket-to-github/
> >
>
> My personal experience is: this is not true.  I have
> projects on github and bitbucket.  Simply being on
> github, I don't see any evidence of increased visibility,
> etc.
>
> There are counter anecdotes with pypy, sphinx, etc on
> bitbucket - successful projects (high visibility).  I think
> there are other factors, not simply being hosted on X or Y.
>
> > 2) Github is arguably a better/more poular platform.
> > For example, travis-ci(continuous integration) supports github but not
> > bitbucket. While there are alternatives to travis-ci, none of the free
> > ones are as good.
> > You can check out the UI of travis-ci here:
> > https://travis-ci.org/kennethreitz/requests
> >
> > travis-ci is deeply integrated with github, this makes the process of
> > pull requests way simpler.
> > If travis is configured(a simple yml file in the repository root),
> > travis automatically runs tests on all commits and pull requests. From
> > the github pull requests page, you can see if tests passed/failed. And
> > additionally, get details about failed tests.
> > This is how it looks:
> > tests passed:
> > http://danlimerick.files.wordpress.com/2013/02/safetomergeprtravis.png
> > tests failed:
> > http://danlimerick.files.wordpress.com/2013/02/failedprtravis.png
> >
>
> This is definitely a plus but it is only a partial plus
> in MyHDL's case.  To do full regression-testing on any
> pull requests you would need a verilog and vhdl simulators.
>
> >
> > Thanks to this, users can submit quick bugfixes as pull requests and the
> > repo owner can accept pull requests without worrying too much(or without
> > pulling changes and running tests) if tests pass.
> > I imagine bugs like these: (
> >
> https://bitbucket.org/jandecaluwe/myhdl/issue/3/always_seq-decorator-error-message-string
> > ) would be handled much quicker.
> >
> > Additionally, github's UI makes it easy to see what other contributors
> > are up to, this makes it easier to co-ordinate and might make some
> > people more confident about contributing.
> > see:
> https://github.com/blog/39-say-hello-to-the-network-graph-visualizer
> >
> > 3) git and hg workflows aren't too different. hg users will not have too
> > much trouble contributing to git repos. Additionally, there are tools
> > like hg-git which allow you to use hg locally while contributing to a
> > git remote.
> > http://hg-git.github.io/
> >
>
> If hg-git works nice, there could be a mirror on github
> (note someone already created a mirror on github).  I have
> not been able to get hg-git to work.  I am moving some of my
> github projects to bitbucket because I don't see any benefit
> of having them on github (exception travis-ci).
>
> I think we have hashed through this topic, I don't know if the
> travis-ci is enough to overturn the inertia.
>
> Regards,
> Chris
>
>
>
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
have a nice day
-jck