Rust playground from your own gist

The rust playground is awesome.

It allows playing with rust in the browser, without needing to install anything locally. These playgrounds / playpens are popular with newer languages. I've definitely seen with rust, go, kotlin, and others. Javascript ones allow script and css and other elements.

When editing a playground, the file can be modified, compiled, and run. The file can be exported as a direct link with the code (if it is short enough to fit in a get param). The code is also stored as a github gist under the "rust-play" user, and export links are provided to view the gist and to load a permalink to the playpen with that gist.

I haven't seen this documented anywhere, but we can use our own gist in the link!

Permalink looks like this:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=23727a722bff54fd20f44ef43b96466b

version, mode and edition options configure the settings for the playground.
The gist option specified the gist to load.

Advantages to using your own gist:

• Ownership and control
• Notification of comments
• Tracking of forks
• Updates of gist are reflected in the playground

Disadvantages:

• Edits made in the playground are lost.  The playground doesn't have update access to the gist.
• Unexpected experience for consumers?

Try out my Playground link for gist 23727a722bff54fd20f44ef43b96466b

Embedding a single file from a github gist

Embedding a github gist

Github has improved their gists by directly providing an embed script.

This is pretty handy. From the sharing dropdown on the gist, choose embed and then copy the script tag. Paste that directly into your html (say on your super minimal blogging platform, like blogger/blogspot).

The script will embed the gist with syntax highlighting and links to view the raw gist.

Format of the script tag:
<script src="https://gist.github.com/${username}/${gist_id}.js"></script>

username is optional and can be skipped:
<script src="https://gist.github.com/${gist_id}.js"></script>

Embedding a single file from a gist

When our gist contains multiple files, the default embed will include all of the files. (Sorted by filename, just like in the gist). You can embed just a single file by adding the filename to a file get param.

Format of the script tag:
<script src="https://gist.github.com/${username}/${gist_id}.js?file=${filename}"></script>

The username path can be skipped:

<script src="https://gist.github.com/${gist_id}.js?file=${filename}"></script>

Embedded file example

Embedding from file is_valid_sequence.rs from my gist 23727a722bff54fd20f44ef43b96466b

<script src="https://gist.github.com/23727a722bff54fd20f44ef43b96466b.js?file=is_valid_sequence.rs"></script> 

Dzil plugins: GitHub::Meta vs GithubMeta

"Dear lazyweb: how do I add a github repository link to my dist-zilla dist.ini?"

Curtis Poe (@ovidperl) via twitter

Ovid asked how to add git repo information to a dist.ini file. Both Dist::Zilla::Plugin::GitHub::Meta and Dist::Zilla::Plugin::GithubMeta were suggested, along with the old-school Dist::Zilla::Plugin::MetaResources.

I've used MetaResources to include repository information in my dist.ini files. Which plugin should I use now: GitHub::Meta GithubMeta?

My MetaResources usage is pretty simple: homepage + repository information. The GitHub::Meta and GithubMeta versions are nearly the same from the dist.ini side, both have the same format for manually overriding the default homepage:

#MetaResources Github example:
[MetaResources]
homepage        = http://lowlevelmanager.com/
repository.web  = http://github.com/spazm/app-pm-website
repository.url  = http://github.com/spazm/app-pm-website.git
repository.type = git

## GithubMeta version
[GithubMeta]
homepage = http://lowlevelmanager.com/

## GitHub::Meta version
[GitHub::Meta]
homepage = http://lowlevelmanager.com/

There are differences if we look inside the modules. GithubMeta makes a system call to git to get remote url(s). The plugin will only run if called from within a git repository and with git in $PATH. If it finds a github.com url, it uses that as the remote. This url is then parsed to get the github user name and project name.

Conversely, GitHub::Meta shells out to git to get the github.user entry from git config via git config github.user and then makes an API call to github to get the project name. It does have an interesting feature where it can check if the checkout is a fork and use the upstream information instead.

GitHub::Meta could be nice if you want to go all-in and auto-create the repository with GitHub::Create and push updates with GitHub::Update (actually, this just seems to change the homepage url?), all of them will require the github.user configuration set in git. The docs suggest using GitHub::Create with Git::Init. I must admit, I'm behind the DZil times, as I'm not even sure where to store the default plugin options to apply when running dzil new, to actually trigger these plugins.

GithubMeta does what you'd expect and does it with a minimum of fuss. No extra options to set in your git configuration, but you do have to have the github remote added to your repo by other means. This seems a much slimmer change for existing repositories.

migrate Subversion repository/dump to Git & Github, with tags and branches

A simple and complete method for migrating from subersion to git, bringing over past tags and branches.

I migrated a work repository from Subversion to Git last week. It went surprisingly smoothly. There were a more steps than I expected after reading various, selected, sources.

My repository was in "standard layout" containing only a single tree/project. I was sent a dump of the repository created with svndump. If you have direct access to your svn repository, skip step one. Similarly you can skip the github steps or replace them with your own "primary git server."

Note, if you don't want to maintain the svn tags and branches, then there is a simple single step solution using git-svn. This works if you don't have tags and branches to keep, or you just want a personal git checkout of a remote svn repository.
git svn clone --no-metadata --stdlayout --A users.txt http://svn/repo/here/ new_checkout_name/

Overview:

1. import svn dump into svn repository
2. create mapping file of svn committer to email address
3. create empty git repository
4. cd to git repository
5. import from svn repo to git repo
6. pull branch and tag information from svn to git
7. create github repository
8. add remote repository
9. push all tags and branches to github repository.

Steps:

1. import svn dump into svn repository from dump file svn_repo.dump

   % svnadmin create svnrepo
   % svnadmin load svnrepo < svn_repo.dump

2. create mapping file of svn committer to email address
   Create a file called authors.txt and fill it with line separated “svn-name = git-name ” pairs.

   #example:
   % cat authors.txt
   user_a = Alpha <alpha@example.com%gt;
   user_b = B Dawg <bdawg@github.example.com%gt;

3. create empty git repository

   % mkdir gitrepo
   % git init gitrepo

4. import from svn repo to git repo

   #   git svn clone file:///pathto/svnrepo /pathto/gitrepo –no-metadata -A authors.txt --stdlayout

   svn repo path must be an absolute path when using file://

   % git svn clone file://$(pwd)/svnrepo gitrepo/ --no-metadata -A authors.txt --stdlayout

5. cd to the git repository

   % cd gitrepo

6. pull branch and tag information from svn to git
   tags and branches are both viewed as remote branches, tags are prefixed with "tag/".
   For each branch you want to migrate, make a local branch.
   For each tag, make a local tag.

   % git svn fetch                          # fetch remote branches and tags from svn
   % git branch -r                          # view remote branches
   % git branch local_branch remote_branch  # for each branch to migrate
   % git tag local_tag tags/remote_tag      # for each tag to migrate
   % git branch                             # check work by viewing local branches and ...
   % git tag -l                             # ... local tags 

7. create github repository
   ( github repo ui, create yourrepo )
8. add remote repository

   % git remote add origin git@github.com:yourname/yourrepo

9. push all tags and branches to github repository.

   % git push origin --tags   # push all tags
   % git push origin --all    # push all branches 

using git-flow with github

We've decided to use nvie's "Git Branching Model" for a work project using github as a "central" repository (by convention). The gitflow documentation is aimed at people running their own local repositories and using the default git-flow settings for branch names.

I want to make some branch naming changes from the original model. First I was going to swap develop and master with master and production. I've gone a step further and done away with master. I want my branches to be develop, qa, and production.

First, how to initialize this in a new repo:

% mkdir fakerepo
% cd fakerepo
% git init fakerepo
Initialized empty Git repository in /Users/andrew/src/fakerepo/.git/

% git flow init
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master] production
Branch name for "next release" development: [develop] 

How to name your supporting branch prefixes?
Feature branches? [feature/] 
Release branches? [release/] qa
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? [] 

% git branch
* develop
  production

#git flow saves elements to the local repo configuration, .git/config
% git config -l | grep gitflow
gitflow.branch.master=production
gitflow.branch.develop=develop
gitflow.prefix.feature=feature/
gitflow.prefix.release=qa
gitflow.prefix.hotfix=hotfix/
gitflow.prefix.support=support/
gitflow.prefix.versiontag=

Now, how to push to the matching github repository, spazm/fakerepo? Normally I'd use:

 git remote add origin git@github.com:spazm/fakerepo.git
 git push -u origin master

But now I don't have a local master. Should I be using the publish features? #Add manually, rather than via git flow * publish

%  git remote add origin git@github.com:spazm/fakerepo.git

% git push --set-upstream origin develop
Counting objects: 2, done.
Writing objects: 100% (2/2), 173 bytes, done.
Total 2 (delta 0), reused 0 (delta 0)
To git@github.com:/spazm/fakerepo.git
 * [new branch]      develop -> develop
Branch develop set up to track remote branch develop from origin.

% git push --set-upstream origin production
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:/spazm/fakerepo.git
 * [new branch]      production -> production
Branch production set up to track remote branch production from origin.

% git branch
* develop
  production

% git branch -r
  origin/develop
  origin/production

Now, what does the next user need to do after he clones the remote repo?

% git clone git@github.com:spazm/fakerepo.git
% cd fakerepo
% git status
# On branch develop
nothing to commit (working directory clean)

% git branch
* develop

% git branch -r 
  origin/HEAD -> origin/develop
  origin/develop
  origin/production

% git config -l | grep gitflow

#blank, the gitflow configuration items aren't present in the checkout.
% git flow init

Which branch should be used for bringing forth production releases?
   - develop
Branch name for production releases: [] production
Local branch 'production' does not exist.

#manually bring over tracking branches
% git branch --track production origin/production
Branch production set up to track remote branch production from origin.

% git flow init
Which branch should be used for bringing forth production releases?
   - develop
   - production
Branch name for production releases: [production] 

Which branch should be used for integration of the "next release"?
   - develop
Branch name for "next release" development: [develop] 

How to name your supporting branch prefixes?
Feature branches? [feature/] 
Release branches? [release/] qa
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? [] 

% git config -l |grep gitflow
gitflow.branch.master=production
gitflow.branch.develop=develop
gitflow.prefix.feature=feature/
gitflow.prefix.release=qa
gitflow.prefix.hotfix=hotfix/
gitflow.prefix.support=support/
gitflow.prefix.versiontag=

Question: Do I really have to manually set up the tracking branches when I clone, prior to running git-init? That seems messy. I'll keep digging and let you know.

patching github projects

Wow, adding changes to projects on github is surprisingly easy, once you figure out the steps. I made a patch for vim-space earlier today, after I found an error in a comment that cost me an hour yesterday.

I nearly got the github flow correct on the first pass. Here's what I did:

1. fork the project (via UI on github)
2. clone locally
   git clone git@github.com/spazm/vim-space.git
3. make change to plugin.vim in my working directory, test:
   vim plugin.vim ...
4. create an issue for the original project (via UI on github)
5. commit change locally:
git add plugin.vim
git commit plugin.vim -m "[issue 7] ..."
6. push change to my cloned repo on github:
   git push origin master
7. create the patch file:
   git format-patch HEAD^..HEAD
8. upload the patch file to the issue. Nope, can't upload files to the issue tracker at github.
9. create pull request:
   git request-pull HEAD^ origin HEAD

   The following changes since commit 9640d4d1ee980e352abd96e2c0ef13372d1c14cd:
   
     Merge remote branch 'remotes/origin/master' (2010-04-13 16:22:27 +0200)
   
   are available in the git repository at:
     git@github.com:spazm/vim-space.git master
   
   Andrew Grangaard (1):
         [issue 8] correct loaded_space to space_loaded in plugin
   
    plugin/space.vim |    4 ++--
    1 files changed, 2 insertions(+), 2 deletions(-)

10. Copy and paste this pull request into issue 7.

This was close to the correct flow. While the issue tracker on github doesn't allow uploaded files in the comments, it does track pull requests. So the flow should look like:

Correct Flow

1. Clone Repo (github UI)
2. clone locally:
   git clone git@github.com/spazm/space-vim
3. Make Changes, test
   vim plugin.vim ...
4. commit locally:
git add plugin.vim
git commit -m "loaded_space fix"
5. push to github:
   git push origin master
6. issue pull request(github UI)
7. done. bask in the warm glow of improving an open source project.

The issue pull request stage will create a tracking issue. Slickness. The Clone and Pull Request are handled in the github UI. Check the Pull Requests as Github UI documentation for pretty pictures.

Proper form would be to create a topic branch in the cloned repository, this becomes more useful if you plan to make any further changes or modifications to the project. Make the upstream girl's job as easy as possible to enhance the likelihood of your changes being accepted.

Vroom - vim overrides and mapping for presentation remote

The second best thing about using Vroom (Formerly Vroom::Vroom ) for presentations is hearing, "I've never seen a presentation in vim before." The best thing is using vim as both the editing and display platform.

I realized yesterday while cramming to finish my "intro to git" presentation for work that my recently added vim plugin "magic space" (space.vim) interferes with the default Vroom vimrc bindings. Space.vim rebinds space in a variety of ways to repeat the previous movement commands (search, movement, etc).

Disabling the plugin took a couple of iterations because the documentation was incorrect -- it references loaded_space while the code was checking space_loaded. Actually, the documentation was correct, but the comments in the plugin code are incorrect. I opened a ticket, cloned the github repo, pushed the changes, and updated the ticket with a pull request via git request-pull. Not bad for 5 minutes.

This encouraged me to expand my Vroom knowledge. First, I found the syntax for adding a vimrc override to my presentation. Today, I created a user specific vroom vimrc override in $HOME/.vroom/vimrc to disable magic space when I'm running Vroom presentations.

Since I was already adding custom configuration, I dug out my nerdnite presentation remote and found that the buttons are mapped to PageUp, PageDown and b. These are what powerpoint use for previous page, next page and blank screen. They aren't particularly useful while presenting in vim, so I remapped them in the vroom override to previous and next file.

You think people are shocked by a presentation in vim? Wait until you pull out your laser pointer remote to advance the slides. priceless.

My Intro to Git vroom presentation

https://github.com/spazm/presentations/tree/master/open42-git-intro

Vroom vimrc override file:

https://github.com/spazm/config/blob/master/vroom/vimrc

vim-space

https://github.com/spiiph/vim-space

my fork with fix for issue 8

Issue 8

"" Custom .vimrc overrides for Vroom
"" These will be automatically added to all 
"" vroom autogenerated .vimrc files

" disable space.vim during Vroom presentations.
" in my version of space.vim the docs refer to
" g:loaded_space, but the code checks g:space_loaded
let g:space_loaded = 1

" My presentation remote has three buttons
" forward: sends PageDown
" back:    sends PageUp
" blank:   sends b
" Bind PageUp to previous doc and PageDown to next doc
map  :N:gg
map  :n:gg
" map b ???

github + cpan = gitpan

Gitpan is a clone of all the modules on cpan in git form, nearly twenty-two thousand public repositories. This is not a place for development of modules. Instead it is a place to easily pull the current source for a module to make a patch and send to the maintainer, without having to find where she maintains her golden copy.

I read about gitpan a while ago, but then when I wanted to find it last week, I couldn't find the correct search terms. [github cpan] produces a list that doesn't include gitpan in the first page, as it is crowded out by the many perl modules developed on github for release to cpan and of course things like Net::GitHub and GitHub::Import, and an interesting discussion at perlmonks on (informal) perl naming convention for github projects.

Now that I know the name, it is still hard to find information! From the FAQ section of the readme:

What is gitPAN?
---------------
gitPAN is a project to import the entire history of CPAN (known as BackPAN) into a set of git repositories, one per distribution.

Why is gitPAN?
--------------
CPAN (and thus BackPAN) is a pile of tarballs organized by author. It is difficult to get the complete history of a distribution, especially one that has changed authors or is released by multiple authors (for example, Moose). Because releases are regularly deleted from CPAN even sites like search.cpan.org provide an incomplete history. Having the complete history of each distrubtion in its own repository makes the full distribution history easy to access.

gitPAN also hopes to make patching CPAN modules easier. Ideally you simply clone the gitPAN repository and work. New releases can be pulled and merged from gitPAN.

gitPAN hopes to showcase using a repository as an archive format, rather than a pile of tarballs. A repository is far more useful than a pile of tarballs, and contrary to many people's expectations, the repository is turning out smaller.

Finally, gitPAN is being created in the hope that "if you build it they will come". Getting data out of CPAN in an automated fashion has traditionally been difficult.

Where is gitPAN?
----------------
The repositories are on github.com at http://github.com/gitpan (watch out, it may overload your browser).

Code, discussion, and issues can be had at http://github.com/schwern/gitpan.

[...]

How can I contact gitPAN?
-------------------------

Email:   schwern+gitpan@gmail.com
Web:     http://github.com/gitpan/
Dev:     http://github.com/schwern/gitpan
Issues:  http://github.com/schwern/gitpan/issues
Twitter: #gitpan

Links:

google search for [github cpan]

http://google.com/search?q=github+cpan

google search for [gitpan]

http://google.com/search?q=gitpan

gitpan at github -- 21,976 public repositories and counting!

Schwern's announcement of gitpan on his use.perl blog.

http://use.perl.org/~schwern/journal/39972

http://github.com/gitpan

discussion of gitpan and code:

http://github.com/schwern/gitpan

gitpan issues:

http://github.com/schwern/gitpan/issues

a page with 4 links at integra.net

http://gitpan.integra.net/

clone remote git to github

I've just made my first remote git repository at github. It's a clone of Matt Trout's Iron-Munger code. Looking back through my zsh history for git commands, this roughly what I did. Comments inline in my awesome 'pre' block.

Repository: http://github.com/spazm/Iron-Munger/tree/master

#setup get information from my new github repository
% git remote add origin git@github.com:spazm/Iron-Munger.git
% git config --global user.name "Your Name"
% git config --global user.name "Andrew Grangaard"
% git config --global user.email granny-github@XXXXXXX

#generated my ssh key, and added it via the github web interface.
% less ~/.ssh/github_dsa.pub

#added this key to my keyring.  This way I don't type my passphrase everytime, yet someone doesn't get access just by grabbing my key.*
% ssh-keygen -t dsa -f ~/.ssh/github_dsa
% ssh-add ~/.ssh/github_dsa

# get my area ready:
% git init
% git add README
#commit first commit locally.
% git commit -m "first commit"

#setup my remote repository, and push to it: (I wonder which of these worked)
% git remote add origin git@github.com:spazm/Iron-Munger.git
% git push origin master
% git remote add origin git@github:spazm/Iron-Munger.git
% git push origin master

#pull in the repository I want to clone:
% git remote add upstream http://hercule.scsys.co.uk/~matthewt/iron-munger/.git/
% git fetch upstream
% git push origin master

# pull in the repository
% git pull upstream master

# push it to my copy at github.
% git push origin master

#start making local changes
% git status
% git add IronMunger/Calculate.pm IronMunger/PlaggerLoader.pm
% git status
% git diff plagger_loader.t
% git add t/plagger_loader.t
% git status
% git add t/stats_saver.t

# commit locally
% git commit

# push to github
% git push origin master

#pull down any changes from the original master
% git pull upstream master