There's a desire to reboot the Nodes project, but in fact that desire is somewhat unfounded.

Windows enumerate USB devices -- list usb: USBView

• https://msdn.microsoft.com/en-us/library/windows/hardware/ff560019(v=vs.85).aspx 
• https://dev.windows.com/en-us/downloads/sdk-archive 
• and install only the "debugging tools for Windows".

Install path is
C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x86\usbview.exe

There's also an x64 one but it's still under Program Files x86:
C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\usbview.exe

Note on DigiX:
https://digistump.com/wiki/digix/tutorials/programming
Bootloader is SAM-BA with VID/PID 03EB/6124
Native USB mode is VID/PID 2341/003E

However DigiX appears with VID 0x16D0 and PID 0x078A

From http://digistump.com/board/index.php?topic=1185.20
VID : PID
03EB:6124   Atmel: SAM-BA activated device
2341:003E   Arduino DUE native PORT selected, sketch is running
16d0:078a   DigiX board selected, sketch is running

Now open Device Manager > Ports (COM & LPT).

It shows "Digistump DigiX (COM6)".

But since the Arduino IDE expects COM3, change it: device manager > Ports > DigiX (COM6) > Properties > Port Settings > Advanced > … won't do COM3 says "in use" (by whom).

Nevermind, change IDE to match COM6: Arduino 1.6.5 > Tools > Port > COM6.

Note by default the Arduino IDE expects 9600 bauds so make sure the sketch inits with this as early as possible:  Serial.begin(9600);

How to currently install/build go 1.5 from source on Linux:

$ cd ~

$ git clone https://go.googlesource.com/go

$ cd go

# create the go 1.4 bootstrap using gcc

$ git checkout go1.4

$ ( cd src ; ./make.bash )

$ mkdir ~/go1.4

$ cp -rv bin pkg src ~/go1.4

$ (cd src ; ./clean.bash )

# build latest version

$ git checkout go1.5

$ ( cd src ; ./all.bash )

$ export GOROOT=~/go

I've added a new idea/research page for BX07.

I just realized the scope exactly covers Ikaria v2 and more or less  v1:

• Both are "skeleton" apps, destined to be reused for future projects; some kind of framework/sample to avoid re-writing the same thing all the time.
• Both are supposed to be rather horizontal and cover a lot of areas, namely server-vs-app, remote sync/cloud, IAB & licensing.
• Both are supposed to be "validated" by extensive testing rather than actual implementation.
• Both will not happen for exactly that reason.

The realization is that I have lots of ideas and thus I'll tend to focus on the actual results rather than the theoretical ones -- which will best remain as doc write ups.

There's also the mythical idea that they don't get implementation because writing software is hard and time consuming and thus if I had a framework to work upon, it would make everything more smoother.

The former realization seems valid, the latter is a load of BS. Frameworks don't make things easier -- they canalize in one direction and make it harder to be flexible and do things outside of their scope. Since my ideas are generally quite broad and volatile, attempts at frameworks don't help -- e.g. RLib for example.

Once again I have too many projects going on. Here's a summary of the current projects with a quick summary state, more or less in the order in which I would like to prioritize them:

• The Cleaner -- ongoing. Slowly put on pause after vacation, should go back to it.
• NovaScript v1 -- pending. Taking too much time to write tests, not clear of the direction; I had realized that v1 was not what I wanted; since it's still embryonic and experimental, modifying the concept to fit my needs is part of the project goals.
• Google Code cleanup -- not started. Got overall idea, need to follow through.
• Train stuff -- ongoing. Several things: exploring ideas right now, nothing concrete.
• Got the JMRI server part setup so I don't need to make my own.
• Next step is arduino control of one turnout + integrate in JMRI.
• Next step is front panel tablet / wooden console + expand to all layouts.
• This is a long term overall project with many small projects.

I also need to pipeline things better. E.g. for The Cleaner I can finish the widget part and a prototypal customizable UI, then it will be waiting on DK's side. During that time I can focus on train/arduino stuff.

For NS, I need to rethink the whole thing.

The initial design was for an experimental v1 that would not be too useful yet would give me some directions. That's good and the v1 implementation proved interesting and showed some issues, which I addressed as I went, but I need to speed this up if I want to see the rest of the unforeseen issues -- it just takes too much damn time to do it properly.

Since I don't think of v1 has being ultimately so useful, should I probably not focus on "doing it right" and instead cut corners and implement it faster? One issue with that is once I specify a v2 as addressing all the issues found in v1, it will also take forever to do it right unless I can make it an evolution. So whilst I need to speed up v1's implementation, I should not ruin it because I might want it for later.

Another approach: scratch v1 and specify v2 directly, then rework v1 as a subset of v2. Then implement v2, with the optional parts left out at first.

The problem is that the current implementation of v1 has focused on the parser, but that's only a minor part of it. No work has been done on the runtime and the text vs graphical editor and then there's the larger cat-in-the-bag issue of which underlying language to use.

Google Code transition:

• Google Code will close, with enough time to migrate projects.
• GitHub sounds like a logical choice.
• Price model is based on number of private repos, with unlimited collaborators.
• BitBucket is the other choice.
• Part of the Atlassian group.
• Private repos are unlimited even in the free plan.
• Price model is based on the number of users, with unlimited repos.
• A users is "someone with r/w access to your private repositories"
• Free model is up to 5 users.

Pros/cons:

• GitHub is more suited for high visibility + trivial project cloning.
• BitBucket is better for my personal stuff -- I want low visibility including private repos which I do not have right now.
• I don't need users (just me, maybe an rdrrlabs repo)
• With BitBucket, I might want to try to mirror my home repos as backups.

List of Google Code repos and migration path:

• Most of my GC repos are here to "reserve" a namespace and project name.
• Most of my GC repos are here to serve as an online backup. Many of them I do not wish to expose so I jungle around to only publish "public" stuff in them.
• This isn't needed in the GH or BB model since each project is under the user's namespace.
• I'd suggest going with BB because I mostly want private repos.
• Most repos would go into private mode for pure archival purposes, no activity.
• Check whether a repo can be changed from private to public at any time or is fixed.
• Only expose a minimal set of "useful" repos.

I'd like to do a parallel research document on language design.

Right now I have some ideas for Hint, which is still very vague and not well formalized. It's a bit of a catch-all. So instead I did a subset with NovaScript, whose version NS1 is really limited -- the main purpose is to remember how to implement a language and interpreter, then have a more useful NS2 version. This isn't Hint at all, although hopefully some things could be reused.

Hint discussion suffered from being both a language discussion and a platform discussion but I believe I cleared that one out, or did I?

Anyhow, the point of this snippet is to remember that, in an ideal version, Hint would have elements of:

• Actor model: each "class" or module is independent and calls are considered RPCs.
• Distributed vs non-distributed and "mobile" actors. There can be several VMs distributed on different hosts and then freeze/move runtime modules around.
• Behavior Driven Development -- in the very very early Hint discussion one of the ideas was to make it trivial to add testing.
• One way is the classic unit test where each function has its associated test, but in practice this is seldom useful and unit tests quickly turn into larger behavior tests that encompass a set of functions.
• Small functions can be treated as mathematical functions, with some inputs and output automatically compared.
• More often what needs to be described is the behavior of a whole or part of a system, but it gets tricky with side effects and generally the test itself is costly and confusing to write. Not to mention that all corner cases are hard to predict and test.
• Still the idea is that this is highly valuable and ideally would be part of the source and not an on-the-side after-thought.
• Continuations built into the language, either like a call/cc.
• Coroutines, iterators and generators.
• Various levels of implementation using extensions to a unified language. That's the point of the hint levels (0=assembly, 1=C/java like, 2=interpreted). Similarly some of the concepts like distributed actors are not mandatory.

Whenever possible I should look up definitions in c2 and match their name patterns.

So part of this impacts both the platform and the language (e.g. BDD, mobile/distributed actors.)

Some of these are things I have absolutely no idea about them except they seem like good ideas.

I've never used call/cc -- although goroutines and closures are familiar. I certainly have no idea how to implement them, which makes it much more interesting to even think about.

BDD and testing are in a slightly different category -- there are many languages that have support for unit tests and such. The question is whether I can make it attractive and efficient for me to use a-priori rather than a-posteriori. My current attempts at using UT are more hindering my development style than enhancing it.

I have been playing Pokemon Yellow on an Android GameBoy Color emulator lately. Thoughts about these apps and their model.

• First started with this one: "Gameboy Color A.D"
• Simple app. Easy to use.
• Free with ads in the home screen, not during play time. Ads not shown when in airplane mode.
• All features available in free mode.
• One of them (Fast Forward) wants you to watch a movie before activating it ⇒ skipped in airplane mode.
• Lacks a couple features (Link Mode) + crappy zoom quality (too blurry)
• Tried this alternative: "My Old Boy! Free (GBC)"
• Better quality game.
• Unfortunately many essential features are blocked by a "Only in paid version".
• Load: you can save but cannot reload!
• Link Remote: only in paid.
• ⇒ That was enough of a kill-it-and-uninstall. I think the pure block is not a good strategy as I could not even evaluate the feature. The ability to save without reload is a total non-sense and feels like a bad bait-and-switch.
• There are many many other Android apps for GBC emulation, most of them looking exactly like each other.
• ⇒ My feeling is there are 1 or 2 engines out there and everyone is just repackaging the same thing.
• There is one open source Android version: "Gameboid"
• It seems the original project was open-source and then the original app went paid/closed on Android.
• This uses an NDK z80/gbc emulator source + code around to handle inputs and display and stuff.
• Doesn't seem to support the Link Cable feature which I want.
• I could rebuild an app around this, but is it worth my time? Probably not.
• So for a second I thought about whether I could rewrite the NDK gbc emu in Java.
• ⇒ But surely someone has done it, hasn't it?
• What do I know about z80 assembly code & emulation? ⇒ Nothing.
• What do I know about GBC hardware emulation? ⇒ Nothing.
• ⇒ Again, worth my time trying? Not really.
• "JavaBoy" is one such emulator rewritten in Java.
• Tried it and it builds and run as a Java App in IJ with no problem.
• Source is clean and instructive.
• Most interesting there's a one-file z80 emulator right in there.
• The rest is handling peripherals and magic GBC-specific constants.
• Mentions passes some kind of emulation test + a list of games compatibles.
• ⇒ All this clearly shows I know little on the subject, nor do I really care.

So bottom line:

• Reading the JavaBoy source code, I did learn a couple interesting things on how ROMs & save files are handled (basically they are 8k or 32k memory chunks) and they all tend to load a blah.zip or blah.gb with a side blah.sav for the 32k chunk so that means pretty much all these emulators are cross-compatible if you give them the right files.

Went with the paid version of "My Old Boy!".

• It's disappointing that the Free version can't properly act as good test app.
• Just suck it up and use the 15-min window for trying it out.
• The Link Remote feature worked over wifi + over BT. It's a bit flaky (works fine initially when it goes bad.)
• The app is $4.

It's not worth my time rebuilding my own emu for that price yet I had a fun time looking at the emulator sources and their implementations.

State of Nova script :

• Lack of interest for spec 1 of the language
• Not convinced about antlr4
• Pro : not writing lexer myself. Simple to understand, as it just generates a lexer tree. No mixing ast instructions + code in grammar file. Visitor pattern easy to work with.
• Cons: doesn't do much. No automatic ast generation. Lots of boring template code to generate internal ast. Lack of non-free documentation.
• Results in unfinished project so didn't tackle the hard parts yet such as execution.
• Should I continue on something I won't use for the sake of it, or redesign directly for 'what I want' (and what) without knowing if I can really implement it?
• Logic dictates I finish v1 as a proof of concept but don't stop there.

Same issue again : too many projects going on.

• Work stuff. Main project going nowhere, maintenance takes most of the time. ==> Cut side things.
• Home focus should be NovaScript.
• Got a plan, should stick to it.
• Fixed Comics2, good.
• Learning Ember JS can wait.
• Using it for Comics3 is overkill yet a simple way to start. Can wait though.
• RPi + PiFace : stick to a quick test so that I can demo it. Come back to it later.
• Digispark : stick to the demo. Chances are he won't use it.

[...]

That little hardware hack should preempt NovaScript.