本文档用于日程记录与编程相关的杂货;
notepad++精美主题&字体 - longzhankunlun - 博客园 20190522
假定lnName是一个软链接,
rm -rf lnName/
这个最后带了斜杠的命令会删除软链接所链接的真实目录,而不是删除软链接其本身;
rm -rf lnName
这个最后不带斜杠的命令才会删除软链接其本身;
可以使用pip intall xxxx.whl
命令对下载下来的.whl
库包文件进行安装
终端操作时,如果路径名中有空格,需用“\ ”代替;
使用参考:
安装完 Git 之后,要做的第一件事就是设置你的用户名和邮件地址。 这一点很重要,因为每一个 Git 提交都会使用这些信息,它们会写入到你的每一次提交中,不可更改:
git config --global user.name "xxx" # 设置用户名
git config --global user.email "[email protected]" # 设置用户邮箱
git config --list # 检查配置信息
lu@Lenovo-PC MINGW64 /e/WorkSpace/Server_WorkSpace
$ git status
fatal: not a git repository (or any of the parent directories): .git
# mkdir tutorial # 在当前路径下创建一个文件夹, 用于后续创建一个repository
# cd tutorial/
# git --version
# git status # 查看当前工作状态
# git init # Git仓库的初始化, 创建了一个repository
记录一些git相关命令
git status
# git add . 添加当前路径下的所有文件到缓存区
git add xxx.py yyy.py # 添加一个或多个文件到缓存区
git status
git commit -m "First initial commit" # 提交至Git本地版仓库,并附上提交描述
git status
# 在GitHub上create a new repository
# set a new remote
git remote add origin https://github.com/user/repo.git
# verify new remote
git remote -v
> origin https://github.com/user/repo.git (fetch)
> origin https://github.com/user/repo.git (push)
git branch # 查看分支
git push origin master # 提交到远程仓库
此前,在PyCharm中由于"File | Open… | Open File or Project"选中的是"OpenSourcePlatform"文件夹,因此通过"VCS | Enable Version Control Integration"来初始化Git仓库,会在当前的项目路径Server_WorkSpace/OpenSourcePlatform下创建一个名为.git
的子目录,而我期望的是对Server_WorkSpace/OpenSourcePlatform/mmdetection进行版本控制,故需要先删除已经创建的本地仓库OpenSourcePlatform,才能在Server_WorkSpace/OpenSourcePlatform/mmdetection路径下创建本地仓库mmdetection;
此时,创建本地仓库mmdetection,有两种方式:
方式一:在Git Bash中,通过执行cd /e/WorkSpace/Server_WorkSpace/OpenSourcePlatform/mmdetection
和git init
命令,创建一个名为.git
的子目录;
方式二:在PyCharm中"File | Open… | Open File or Project"选中mmdetection,通过"VCS | Enable Version Control Integration"操作。如果此前 在当前的项目路径Server_WorkSpace/OpenSourcePlatform/mmdetection下没有一个名为.git
的子目录,则该操作会在当前的项目路径Server_WorkSpace/OpenSourcePlatform/mmdetection下创建一个名为.git
的子目录;如果此前 在当前的项目路径Server_WorkSpace/OpenSourcePlatform/mmdetection下已经存在一个名为.git
的子目录,则该操作启用了版本控制集成功能;
MMDet_Deployment_Configuration_Connection设置.jpg
MMDet_Deployment_Configuration_Mappings设置.jpg
MMDet_Deployment_Configuration_Excluded Paths设置.jpg
MMDet_初始化Git仓库.jpg
MMDet_VCS_Enable Version Control Integration之前.jpg # File | Settings | Version Control | Directory设置-->Apply
MMDet_VCS_Enable Version Control Integration设置.jpg
在执行"VCS | Enable Version Control Integration"操作之前,此处显示的是"Unregistered roots";
MMDet_VCS_Enable Version Control Integration之后.jpg
在执行"VCS | Enable Version Control Integration"操作之后,此处不再显示"Unregistered roots";
MMDet_VCS_执行首次commit操作001.jpg
# 红色,表示在工作区;
# 绿色,表示在暂存区;
# 蓝色,表示文件有修改,位于暂存区;
# 文件名无颜色,表示文件位于本地仓库区或已经提交到远程仓库区;
MMDet_VCS_执行首次commit操作002.jpg # 勾选了所有文件,并附上提交描述"the initial project version"
MMDet_VCS_执行首次commit操作003.jpg # 执行commit操作时出现的1个弹窗提示,看来当时应该取消勾选"Check TODO";对于该弹窗提示,点击"Commit";
MMDet_VCS_执行首次commit操作004.jpg # 文件commit之后,文件的颜色变成了无颜色;修改了此文件后,此文件的颜色变成了蓝色;
PR是Pull Request缩写,Git/svn之类用的。比如GitHub上的项目,你pull下来,修改了部分代码之后再提交PR,然后管理员觉得你改的代码没毛病,管理员确认之后,这个项目某部分代码就改成你的了;在GitLab中,MR(Merge Request)好像是类似的意思;
团队合作的时候,由于远程端的更改多余你的本地端,你应该 先pull 然后合并远程端后 再push。如果直接强制push会让远程端的代码跟你本地的保持一致,远程端多的部分就不见了。
CRLF line separators CRLF行分隔符
CRLF abbr. 回车换行符(carriage return/line feed)
expand upon详细叙述
expand up展开,扩大
git clone https://github.com/user/repo_name.git
之前会在当前目录下创建一个文件夹,名字就是项目的名字repo_name。然后 git 会先拉取元信息,放在.git 这个目录里;然后拉取对应的object,同样放在.git 里;最后根据元信息和 obj这些信息建立整个代码。在最后一步开始之前终止,相当于所有拉取的东西都在.git 里。如果git clone
中途终止,直接删掉.git这个文件夹重新拉取就行,看样子你是 clone 不是 pull,讲道理可以把第一步创建的项目文件夹repo_name直接删除,不影响什么。
一般情况下,git clone
传输失败都会自动删除临时文件的,存储库目录也会被自动删除的。
Geforce GPU 显存(GPU RAM) > 6 GB
问题描述:
开始
原因分析:
开始
解决方案:
开始
问题描述:
Python Console中的python环境。
原因分析:
通过PyCharm自带的Terminal进入的python环境 和 Python Console中的python环境 是不同的,得看它们各自使用的是哪条路径下的python.exe解释器。
创建一个PyCharm项目时,可以根据需要自行选择确定“Project Interpreter”,以避免相关依赖包的版本冲突。
解决方案:
在PyCharm中安装依赖包时可以采用以下方式:a.进入"File | Settings | Project Interpreter"里面,点击右边“+”号,搜索“Available Packages”并安装;b.在PyCharm自带的Terminal中,使用命令安装;
问题描述:
PyCharm中,Debug模式下,Debugger | Variables无法显示"frame variables",Console | Show Python Prompt也无法打印输出"frame variables"的相关信息。
原因分析:
无
解决方案:
在PyCharm中打开File | Settings | Build, Execution, Deployment | Python Debugger, 勾选Gevent compatible;
debugging - Why does PyCharm say “Unable to display frame variables” in debug mode? - Stack Overflow 20161129
API Documentation Guide | Simple API Documentation & APIs Document Tutorials
API docs, or API description documents, are the collection of references, tutorials, and examples that help developers use your API.
Your API’s documentation is the primary resource for explaining what is possible with your API and how to get started. It also serves as a place for developers to return with questions about syntax or functionality. The best API docs have these answers hence why it is so important to document your API.
Your API documentation will have several types of content. Some is meant to show what’s possible to a developer considering an integration. Others will get those developers started quickly. And yet, good & simple API documentation should remain useful when that developer is deep into their work.
Your documentation must completely describe the API’s functionality, be accurate, educational, and inspire usage. It’s a big job that can roughly be broken down into three types:
We’ll discuss these in detail, but you can think of them as moving on a continuum of facts to context. A reference describes the endpoints of an API, it lays out all the pieces. Guides take some of those pieces and start to put them together, explaining why you’d use those parts. Finally, examples offer up a very specific solution, solving a common problem.
As you’ll see, the best API documentation nails all three of these types of content.
Now that we know what types of documentation to look for, let’s look at some examples of great REST API documentation. For many years, two names continue to come up when discussing API docs: Stripe and Twilio.
Stripe’s API reference, Twilio’s guides, Heroku’s examples;
One of the most important jobs of documentation is to help someone completely unfamiliar with your API. At the same time, you want it to remain useful for the developer who has already used your API. Of the three types of documentation, the reference most needs to remain relevant throughout a developer’s interaction with your API.
数学公式粗体 \textbf{} 或者 m e m o r y {\bf memory} memory
数学公式粗斜体 \bm{}
摘录自“bookname_author”
此文系转载,原文链接:名称 20200505
高亮颜色说明:突出重点
个人觉得,:待核准个人观点是否有误
分割线
分割线
问题描述:
原因分析:
解决方案: