Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error out if sim:pack or sim:unpack argument missing #27

Open
chrisnappi opened this issue Jan 1, 2019 · 3 comments
Open

Error out if sim:pack or sim:unpack argument missing #27

chrisnappi opened this issue Jan 1, 2019 · 3 comments
Assignees

Comments

@chrisnappi
Copy link
Member

Currently if you do not give an argument for sim:pack or sim:unpack it makes/looks for '.tar.gz' . Error out on this instead and explain argument requirement.

@ginty
Copy link
Member

ginty commented Jan 4, 2019

Of course the elephant in the room here is that we have sim:ci/sim:co and sim:pack/sim:unpack which do basically the same thing.

Is now the time to converge on one of them?

@coreyeng
Copy link
Member

coreyeng commented Jan 6, 2019

Yeah, we can converge on one of these. I had pack/unpack originally in an app before ci/co was added but I had it in some instructions so I threw it into OrigenSim. I've moved on to ci/co for everything else though. What I used pack/unpack for are dead apps now anyway (@chrisnappi : aka: the greek-god apps. :p)

I'm not sure if there's value in keeping pack/unpack around and having ci/co calling pack/unpack to zip and unzip the snapshot, or just get rid of pack/unpack entirely. I could see pack/unpack maybe being useful from an open source perspective since not all users are guaranteed to have some sort of revision control and may just want a supported script to pack up a snapshot for small test verilog.

Example:, I downloaded Icarus verilog and gtk waveform over the break just to play with and wrote some dummy Verilog counter. I could see pack/unpack still being useful for me if I wanted to pack up the app and put it on my personal OneDrive or Google Drive or whatever, but anything serious and production worthy should be using ci/co.

If we want to keep it around I'll take on the task of converging the two. @chrisnappi I think we should be using ci/co internally though.

@ginty
Copy link
Member

ginty commented Jan 8, 2019

I can see the value in having independent access to pack/unpack and check in/out.

The way it is now though is confusing - e.g. do I have to run pack before I run ci?
The answer is no btw, because ci/co also includes its own implemention of pack/unpack.

I think we should therefore reconcile these to a single command, possibly with a completely new name.

e.g. the kind of thing I am thinking of is something like the current ci/co command but with a command option to inhibit the check in bit of (so it only packs).
That would be a bit weird though if the command itself was called ci (or pack).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants