ktakagaki / hayabaya Goto Github PK

Agreee on a standard / And/or Standard Operating Procedure/Protocol for how to collaborate on GitHub.

New branches have been created on my Hayabaya repository which are preventing me from pushing own changes unless I do a Git rebase.

To avoid such future collissions, we should come up with a standard procedure for how we work together on each others repositories besides using pull requests.

We have already established our branching strategy as using the most commonly used topic branches and then do pull requests against another persons master branches. After target accepts the pull request, merges the changes into his branch the sender will fetch upstream and merge the new changes into his own branch. This is following the common way of doing things

Collaboration workflows are outlined here in the Git SCM Book

Now we just need to agree on a workflow for when working directly on another persons repository.

@ktakagaki

Below I have shown the branches that I see when running git branch. To my knowledge, several of the branches are now no longer of any relevance and can be deleted, then I can run git prune to delete the dead references.

[cain@x51 hayabaya]$ (master) git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/TopicAugust05
  remotes/origin/caseclasses
  remotes/origin/dev
  remotes/origin/extra
  remotes/origin/kentaScala
  remotes/origin/kentatemp
  remotes/origin/master
  remotes/origin/meeting150522
  remotes/origin/simplifyLoopKenta
  remotes/origin/test190415
  remotes/origin/topic26
  remotes/upstream/TopicAugust05
  remotes/upstream/extra
  remotes/upstream/kentaScala
  remotes/upstream/kentaTestEnum160129
  remotes/upstream/kentatemp
  remotes/upstream/master
  remotes/upstream/meeting150522
  remotes/upstream/simplifyLoopKenta
  remotes/upstream/test190415
  remotes/upstream/topic26

We discussed reordering the structure of the results folder when saving the results from Hayabaya. The intention was to enable running the experiment multiple times without risking any files being overwritten.

What organization do you prefer of the tree hierachy?

Suggestions: ( "/" denotes a new level of folders, "<", ">" used for meta-naming)
/ / / / -.csv

With
rootFolder = Results
CPU / System Name = Intel-i7
Experiment started running at 14:34 and 22 seconds on May the 15th = 05-15-14-34-22

Results/Intel-i7/05-15-14-34-22/Integer_Boxed/MULTIPLY_04.csv

I'm looking for further reading material on Scala's type classes.
I've read Oderskys chapters on the topic, and the following video
https://www.youtube.com/watch?v=sVMES4RZF-8&feature=youtu.be

I am however not entirely sure what all of the applications of this feature is. The scala-lang.org website doesn't explicitly have any sections on typeclasses. What is another name for typeclasses, so I can Google for further information?

@slentzen

The fork isn't reattached yet, so manually pull the branch
https://github.com/ktakagaki/hayabaya/tree/kentaScala
from your local repo.

I debugged your sbt file, it had

mainClass in (Compile, packageBin) := Some("de.lin_magdeburg.HayabayaMain")

instead of

mainClass in (Compile, packageBin) := Some("de.lin_magdeburg.hayabaya.HayabayaMain")

Run as follows in sbt:

>run hello 10

which will give

[info] Running de.lin_magdeburg.hayabaya.HayabayaMain hello 10
[info] [In Scala] Welcome to the Hayabaya Microbenchmark project
[info] The value of aTPE is: DOUBLE
[info] Hi Soren! Don't get too fancy with tuples, and parsing will be fine. Parsed: hello, 10
[success] Total time: 3 s, completed Jan 25, 2016 4:23:37 PM

try also

>run hello

and

>run hello hello2

to see error messages