(no commit message)
[libreriscv.git] / HDL_workflow.mdwn
index 3340665dafd0df0eef8ad2232f5ea815abd14759..ef9cdbd4c6e4a003fd8a6e3621c8d1faa8d9698e 100644 (file)
@@ -287,9 +287,9 @@ library.  In the meantime, sfpy can be built as follows:
     cd ..
 
     # install dependencies    
-    python -m venv .env
+    python3 -m venv .env
     . .env/bin/activate
-    pip install --upgrade -r requirements.txt
+    pip3 install --upgrade -r requirements.txt
 
     # build
     make lib -j8
@@ -299,11 +299,11 @@ library.  In the meantime, sfpy can be built as follows:
 
     # install
     deactivate # deactivates venv, optional 
-    pip install dist/sfpy*.whl
+    pip3 install dist/sfpy*.whl
 
 You can test your installation by doing the following:
 
-    python
+    python3
     >>> from sfpy import *
     >>> Posit8(1.3)
 
@@ -440,6 +440,7 @@ for actual code development:
   commits, and it actually becomes a nuisance).
 * prior to committing make sure that relevant unit tests pass, or that
   the change is a zero-impact addition (no unit tests fail at the minimum)
+* keep working code working **at all times**. find ways to ensure that this is the case. examples include writing alternative classes that replace existing functionality and adding runtime optiobs to select between old and new code.
 * commit no more than around 5 to 10 lines at a time, with a CLEAR message
   (no "added this" or "changed that").
 * if as you write you find that the commit message involves a *list* of
@@ -471,7 +472,8 @@ it (a large amount of code) is perfectly fine.
 
 as a general rule, however, do not use this an an excuse to write code
 first then write unit tests as an afterthought.  write *less* code *in
-conjunction* with its (more basic) unit tests, instead.
+conjunction* with its (more basic) unit tests, instead. then, folliw up with
+additions and improvements.
 
 the reason for separating out commits to single purpose only becomes
 obvious (and regretted if not followed) when, months later, a mistake