Showing posts with label github. Show all posts
Showing posts with label github. Show all posts

Sunday, November 15, 2015

Searching for Flyweight


As part of Design Patterns in Dart, I would very much like to include examples of the various patterns in the wild. I have not quite figured out how to go about doing that, so if anyone knows where to find examples of the Flyweight pattern in the wild, I would appreciate it.

I know from the very excellent Game Programming Patterns (seriously, it's great, I just bought another copy so I could read it in epub) that graphics programming tries to make extensive use of the Flyweight pattern. I dug around a bit today, but it does not seem that WebGL supports it yet. Even if did, the Flyweight would be in the WebGL API, not in Dart, so that seems unlikely

Instead of playing around with forced examples in Three.dart, I change tact. I clone a bunch of Dart repositories that are trending on GitHub, then grep through them in the hope of finding a mention of the word "flyweight":
➜  trending-dart-repos  ack -i flyweight
➜  trending-dart-repos  echo $?
1
No luck there. Still, not a complete waste of time, as I expect to find other patterns in the top results:I will add to that list over time, but that seems a good start. I have looked through code in several of those already and know that there are plenty of pattern examples.

That does not help with my goal tonight. What does help, is the search interface on GitHub, which allows me to search all Dart projects by keyword:



Most of those results look to be from goofballs compiling examples of design patterns. One in the list, however, does include an actual Flyweight pattern. The Dart Web Toolkit, which is based on the same idea as GWT. The projects looks un/lightly maintained, so it's not a strong example, but the Flyweight pattern is definite present.

The idea is to cache event mappings between native and DWT events. The DomEvent class caches these in the private _registered map:
abstract class DomEvent extends DwtEvent implements HasNativeEvent {
  // ...
  static Map<String, DomEventType> _registered;
  // ...
}
Whenever a new type is created by the factory class, it registers the DWT / native event pair under the string description of the event:
class DomEventType<H> extends EventType<H> {
  String eventName;
  DomEvent flyweight;

  DomEventType(this.eventName, this.flyweight) {
    DomEvent.getRegistered()[eventName] = this;
  }
}
Every single event in the library then registers itself at runtime when the class is evaluated:
class TouchMoveEvent extends TouchEvent {
  /**
   * The event type.
   */
  static DomEventType<TouchMoveHandler> TYPE = new DomEventType<TouchMoveHandler>(BrowserEvents.TOUCHMOVE, new TouchMoveEvent());
  // ...
}
This way, whenever the framework needs a touch-move event, it can use the flyweight registered when the class assigns the TYPE variable. Nice!

As I said, I am unsure if the qualifies as a strong example. I suppose if I can find that folks are still using the library, then it qualifies. Regardless, I am happy to have rediscovered the GitHub language search. I have the feeling this will come in quite handy.


Day #4

Thursday, June 6, 2013

Deploying Dart Code to GitHub Pages

‹prev | My Chain | next›

There are still hundreds of things to do in the Dart version of the ICE Code Editor, but tonight I push to beta anyway.

But first, I am going to check one more time that the Dart version and the JavaScript version can co-exist. I start up the node.js server in the JavaScript version and take a look at the current list of projects in localStorage:



Then I shut down the node.js application server down and start the Dart server on the same port (3000) as the node.js server:
➜  example git:(master) PORT=3000 dart app.dart
Server started on port: 3000
The ports need to be the same so that both ICE versions have access to the same localStorage database.

I compile my Dart frontend app to JavaScript:
➜  public git:(master) dart2js -ofull.dart.js full.dart
And finally load the compiled Dart in Chrome:



Yay! The list of projects remains the same. For good measure, I perform a few updates in both versions and verify that I can see the changes between the two. Everything looks good, so I think that I am good for beta.

The generated JavaScript is quite large:
➜  public git:(master) ls -lh full.dart.js
-rw-r--r-- 1 chris chris 647K Jun  6 17:24 full.dart.js
It will be served with gzip compression, but the --minify option in dart2js should make the payload that much smaller:
➜  public git:(master) dart2js --minify -ofull.dart.js full.dart
➜  public git:(master) ls -lh full.dart.js                      
-rw-r--r-- 1 chris chris 283K Jun  6 20:00 full.dart.js
That is a nice savings. Except the code does not actually work. The ICE buttons show up. The menus seem to work. But the ACE code editor, which is accessed via js-interop does not show up. And, in the console, I see the following unhelpful exception:
Uncaught NoSuchMethodError : method not found: 'giR'
Receiver: Instance of 'pk'
Arguments: [] 
Bummer. I will try that with a newer version of Dart at some point in the future. I am using one from almost a month ago:
➜  public git:(master) dart --version
Dart VM version: 0.5.7.3_r22659 (Mon May 13 20:57:19 2013) on "linux_x64"
For now, I am going to deploy the un-minified version of the application.

The http://gamingjs.com site is published with GitHub pages (currently from a private repository). In my gh-pages branch, I create an ice-beta directory to hold the application. In there, I add a pubspec.yaml to describe my dependencies:
name: full_screen_ice
version: 0.0.1
description: Full screen ICE
author: Chris Strom <chris@eeecomputes.com>
homepage: https://github.com/eee-c/ice-code-editor
dependencies:
 ice_code_editor:
    git:
      url: https://github.com/eee-c/ice-code-editor.git
      ref: gamingjs-beta
I have not published the ICE Code Editor to Dart Pub, so I am using a git dependency. I am going to need the specified gamingjs-beta reference, so back in my ICE repository, I tag the current git HEAD:
➜  ice-code-editor git:(master) git tag -am "Mark beta point" gamingjs-beta
➜  ice-code-editor git:(master) gp origin --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 174 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:eee-c/ice-code-editor.git
 * [new tag]         gamingjs-beta -> gamingjs-beta
Next I pub install to get ICE and all of the other dependencies installed. Unfortunately, I hit a snag here. The packages install fine, but Dart's pub uses a system cache for packages. Normally this is pretty great, but GitHub pages do not support symbolic links:
➜  ice-beta git:(gh-pages) ✗ pub install
Resolving dependencies...
Dependencies installed!
➜  ice-beta git:(gh-pages) ✗ cd packages
➜  packages git:(gh-pages) ✗ ls -l
total 20
lrwxrwxrwx 1 chris chris 64 Jun  6 21:00 browser -> /home/chris/.pub-cache/hosted/pub.dartlang.org/browser-0.5.7/lib
lrwxrwxrwx 1 chris chris 87 Jun  6 21:00 ice_code_editor -> /home/chris/.pub-cache/git/ice_code_editor-f2f091bcf930ba4cb20528805c0dba0663fafe55/lib
lrwxrwxrwx 1 chris chris 60 Jun  6 21:00 js -> /home/chris/.pub-cache/hosted/pub.dartlang.org/js-0.0.22/lib
lrwxrwxrwx 1 chris chris 61 Jun  6 21:00 meta -> /home/chris/.pub-cache/hosted/pub.dartlang.org/meta-0.5.7/lib
lrwxrwxrwx 1 chris chris 65 Jun  6 21:00 unittest -> /home/chris/.pub-cache/hosted/pub.dartlang.org/unittest-0.5.7/lib
I cannot think of any other way to solve this than brute force, so I remove each of those symbolic links and copy the actual package source in their place:
rm browser; cp -r /home/chris/.pub-cache/hosted/pub.dartlang.org/browser-0.5.7/lib browser
rm ice_code_editor; cp -r /home/chris/.pub-cache/git/ice_code_editor-f2f091bcf930ba4cb20528805c0dba0663fafe55/lib ice_code_editor
rm js; cp -r /home/chris/.pub-cache/hosted/pub.dartlang.org/js-0.0.22/lib js
rm meta; cp -r /home/chris/.pub-cache/hosted/pub.dartlang.org/meta-0.5.7/lib meta
rm unittest; cp -r /home/chris/.pub-cache/hosted/pub.dartlang.org/unittest-0.5.7/lib unittest
That is a bit unfortunate. I wonder if a --no-cache option could make its way into pub at some point in the future? I will worry about that another day. For now, I create index.html in ice-beta with the following contents:
➜  ice-beta git:(gh-pages) ✗ cat index.html 
<head>
  <script src="packages/browser/dart.js"></script>
  <script src="main.dart" type="application/dart"></script>
</head>
I then add main.dart and the accompanying main.dart.js (both renamed from the full.dart equivalents from my example directory earlier):
➜  ice-beta git:(gh-pages) ✗ cat main.dart
import 'package:ice_code_editor/ice.dart' as ICE;

main()=> new ICE.Full();
➜  ice-beta git:(gh-pages) ✗ ls -lh main.dart.js 
-rw-r--r-- 1 chris chris 647K Jun  6 21:24 main.dart.js
That does it. I add the new ice-beta directory to my gh-pages branch and push it up to the GitHub repository. Then I load up http://gamingjs.com/ice-beta and…

It works!



The Dart version of the ICE code editor is officially in beta and is very definitely running my Dart code. There is still a ton to be done. In addition to missing features in the editor itself, I need to cut down on the size of everything. This will eventually reside in application cache so it is not a showstopper to be this large, but still, any little bit helps.

I am a little bummed about the non-working --minify option on dart2js. The system cache of pub packages was a nuisance as well. But all-in-all, this was pretty smooth. I am excited to have reached beta. Now to push for 1.0!


Day #774

Thursday, September 2, 2010

New Upstream Branch into My Fork

‹prev | My Chain | next›

Up today, I think I will have a look-see at what's new in fab.js land. I am working in my own fork of fabjs. There are a couple of tweaks in my fork that I need, but that Jed did not pull in, so my preference is to keep working in my fork, but tracking his changes.

So first up I'll try to remember how to sync up my fork with Jed's so that I can pull the new branch.

Hrm...

OK new plan. I'll look it up on help.github.com. Dunno if this will ever be something that I will just know or if it will always require a lookup. Anyhow...

Following along, I need to add the upstream repos:
cstrom@whitefall:~/repos/fab$ git remote add upstream git://github.com/jed/fab.git
cstrom@whitefall:~/repos/fab$ git fetch upstream
remote: Counting objects: 66, done.
remote: Compressing objects: 100% (57/57), done.
remote: Total 58 (delta 30), reused 0 (delta 0)
Unpacking objects: 100% (58/58), done.
From git://github.com/jed/fab
* [new branch] master -> upstream/master
* [new branch] v0.5 -> upstream/v0.5
cstrom@whitefall:~/repos/fab$ gba
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
remotes/upstream/master
remotes/upstream/v0.5
Next, I need to merge the upstream changes that Jed has made into my local repository:
cstrom@whitefall:~/repos/fab$ git merge upstream/master
Auto-merging apps/fab.nodejs.js
Merge made by recursive.
README.md | 2 +-
apps/fab.nodejs.js | 2 +-
package.json | 42 ++++++++++++++----------------------------
3 files changed, 16 insertions(+), 30 deletions(-)
Finally I push those changes to my github fork:
cstrom@whitefall:~/repos/fab$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 7 commits.
nothing added to commit but untracked files present (use "git add" to track)
cstrom@whitefall:~/repos/fab$ git push
Counting objects: 34, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (24/24), done.
Writing objects: 100% (24/24), 2.82 KiB, done.
Total 24 (delta 16), reused 0 (delta 0)
To git@github.com:eee-c/fab.git
72ec43b..31e4d6b master -> master
Easy enough, except... that only pushes the changes to master to my fork. How do I get the new branch pushed to my fork?

After looking around github a while, I fail to locate the copy-branch-from-a-fork button. My google-fu fails me as well. I suppose I could try to push my way through. It is a bit low-level, but I would guess that my first step ought to be creating a new, local branch. I can then merge in the upstream changes and then push that to my forked copy on github.

Sounds like a plan. Maybe.

Creating the new, local branch:
cstrom@whitefall:~/repos/fab$ git co -b v0.5
Switched to a new branch 'v0.5'
cstrom@whitefall:~/repos/fab$ gba
master
* v0.5
remotes/origin/HEAD -> origin/master
remotes/origin/master
remotes/upstream/master
remotes/upstream/v0.5
Now I merge in Jed's upstream changes:
cstrom@whitefall:~/repos/fab$ git merge upstream/v0.5
Removing LICENSE.txt
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Removing apps/fab.body.js
Removing apps/fab.capture.at.js
...
Automatic merge failed; fix conflicts and then commit the result.
Wha?!

Indeed, git-status confirms, I have conflicts:
cstrom@whitefall:~/repos/fab$ gst
# On branch v0.5
# Changes to be committed:
#
# deleted: LICENSE.txt
# deleted: apps/fab.body.js
# deleted: apps/fab.capture.at.js
...
# Unmerged paths:
# (use "git add/rm ..." as appropriate to mark resolution)
#
# both modified: README.md
# deleted by them: apps/fab.nodejs.js
Bah! That is not right. This is one of the very few cases that I know I want to git reset --hard. I have myself a merge conflict and I just want to restart. So:
cstrom@whitefall:~/repos/fab$ git reset --hard
HEAD is now at 31e4d6b Merge remote branch 'upstream/master'
Solid. I recovered from that little gaff. But what caused the gaff?

It takes me a bit, but I eventually realize that Jed has done work on master since he branched v0.5. But I made my local branch from HEAD in master. I should have branched at the same point that he did. Fortunately, that is not that difficult. He branched after a618ff9b73832e879161. To do the same, I simply need to supply that as the reference point for my local v0.5 branch:
cstrom@whitefall:~/repos/fab$ git co -b v0.5 a618ff9b73832e879161
Switched to a new branch 'v0.5'
Now, I can safely merge from upstream:
cstrom@whitefall:~/repos/fab$ git merge upstream/v0.5
Updating a618ff9..ebc9ef1
Fast-forward
LICENSE.txt | 20 ---
README.md | 145 ++++++++++++++++--
apps/fab.body.js | 39 -----
apps/fab.capture.at.js | 16 --
apps/fab.capture.js | 12 --
...
delete mode 100644 examples/date.js
delete mode 100644 examples/focus.js
delete mode 100644 examples/hello.js
delete mode 100644 examples/index.js
delete mode 100644 package.json
create mode 100644 server.js
delete mode 100644 utils/build.js
delete mode 100644 utils/test.js
And, finally push my changes to my fork on github:
cstrom@whitefall:~/repos/fab$ gp origin v0.5
Counting objects: 39, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (35/35), done.
Writing objects: 100% (36/36), 9.24 KiB, done.
Total 36 (delta 15), reused 0 (delta 0)
To git@github.com:eee-c/fab.git
* [new branch] v0.5 -> v0.5
Now I have my own nice, shiny fabjs v0.5 on my fork.

Nice. It was really cool to get through all that. I still feel as though I have a long way to go with git before I really understand it, but I was pleased to be able to work through that without getting hopelessly lost.

The basic flow:
  1. git remote add upstream git://github.com/jed/fab.git # insert your git repos here
  2. git fetch upstream
  3. git checkout -b v0.5 a618ff9b73832e879161 # insert branch name and SHA1 of forked-from branch point here
  4. git merge upstream/v0.5 # insert forked-from branch here
  5. gp origin v0.5 # use your branch here
Easy enough.

Still, there has to be a better way of pulling in a new branch from upstream. Right?


Day #214

Thursday, July 23, 2009

Conveniences

‹prev | My Chain | next›

First up today, I would like to clear the issues log that I have been compiling. These are mostly minor issues so I hope to be able to clear them quickly and move onto more interesting topics.

Indeed, the first issue, missing images on the meal pages is a simple omission from the view. I copy & paste the specs for the recipe images and use the same helpers for the meal image. Simple enough.

When I commit the fix, I include the following text in the commit message: "Closes #3". In many SCM solutions, there are post-commit hooks that update tickets. Trac, for instance, has a popular SVN post-commit hook that updates tickets including text like "References #123" or "Closes #123". Github's issue tracker does the same—without even needing to add post-commit software. Nice!

After pushing the fix to github, the issue is automatically closed for me:



The commit even includes a link to the issue:



The automatic issue updater is not quite as full featured as Trac's. It does include the ability to up-vote an issue / feature request. I make immediate use of that feature by up-voting the ability to reference (without closing) issues—in github's own issue tracker.

I have a go at fixing the links between recipes (the only other issue that I am currently tracking). I have to admit defeat, though. The links between records is hard-coded to work with meals, not recipes. My first attempt at fixing it is worth only a complete revert. In git, of course, this is done with:
git checkout .
The last thing I work on today is giving less CSS a try. I would like to see if I can get the rounded corners on the green headers from my legacy application into the new implementation. The existing view:



I create a public/stylesheets/style.less file to hold my minimal CSS definitions. The first thing that I add is color definitions. We use a dark green / light green color scheme (coupled with red in the logo) to give an Italian flavor to the site. The green colors in style.less:
@primary_color: #090;
@secondary_color: #7CCD7C;
Next I define a class for the rounded corners:
.rounded_header {
-moz-border-radius-bottomleft: 0;
-moz-border-radius-bottomright: 0;
-moz-border-radius-topleft: 4px;
-moz-border-radius-topright: 0;
}
I then use the color and the class in the definition of <h1> tags:
h1 {
background-color: @primary_color;
color: white;
font-size: 1.2em;
.rounded_header;
}
I generate the corresponding style.css with the lessc command:
cstrom@jaynestown:~/repos/eee-code$ lessc public/stylesheets/style.less
And I have my rounded colors:



That is a good stopping point for today. I may pick back up with more less CSS tomorrow. That last issue bothers me a bit so I may give that another try first.

Monday, March 2, 2009

Source Code Management

‹prev | My Chain | next›

No doubt to the chagrin of some of my co-workers, I'll use git to manage my code. Since I will be documenting everything, there is no sense in maintaining a private repository. I will use github as the public repository.

There is very little involved in creating a git/github repository. Github is nice enough to provide easy to follow instructions.

I already had a github account, so the next steps were (almost verbatim from github):
  mkdir eee-code
cd eee-code
git init
touch README.rdoc
git add README.rdoc
git commit -m 'first commit'
git remote add origin git@github.com:eee-c/eee-code.git
git push origin master


Only the last step is somewhat obscure in meaning (at least to me). According to the git-push documentation, "master" is the "refspec", which can be used to push to differently named remote locations. I am not clear why you would want to do this (apply commits to branches without having to checkout first?).

At any rate, I now have a repository for my chain: http://github.com/eee-c/eee-code/tree/master and the chain is unbroken on day 2.