Building HTM Systems (WIP Document)

If anyone wants to work on this, now is a good time. I will not have time to work on it for several months.

2 Likes

Sad to read that, I was just going to ask if there where any plans on adding temporal memory and the rest that is covered in the HTM School videos

I got lots of plans, no time to implement them all. I will get back to this document after I’ve produced 2 more HTM School videos and a new conference talk.

4 Likes

Just to clarify, by ‘this’ do you mean the number encoder docs overall?

Sure or more if you want

1 Like

For some updates on this project, see our latest Hackers’ Hangout at 14:48:

My plans are to flesh this project out on my Twitch stream, starting Thursday. It is currently a webpack’ed static delivery system, so I’ll be immediately updating it to use ReactJS. We’re going to build a whole HTM implementation in JavaScript (maybe Coffeescript) live. It’s going to be fun. Stay tuned!

2 Likes

Continuing from your Twitter thread, why does it need to have a server side component at all? And do you have an idea of the source(s) of the streaming data?

I guess I don’t really have a good reason. Something I’ll have to think about.

My original plan was to have one server with one HTM running. The server would constantly run data through the HTM. All the web pages would visualize components of the running HTM in different ways. They could use the actual HTM input / output by tapping into the server’s streams.

But now that I think more about it, I really don’t need to have a server. I could have the entire thing running in JavaScript on each browser. The data I was planning on using would be programmatically generated anyway. In that case I could just continue use parcel like I’ve been with @codeallthethingz on the other JS project.

3 posts were merged into an existing topic: 2D Object Recognition Project

Not having a server side component would make it much easier to get started with. If there’s a need to save state (tutorial progress etc), you can always persist the react/redux state to local storage.

I’m fairly certain we’ll be building a React static app. I have done a bit of prep-work at https://github.com/rhyolight/building-htm-systems/tree/react. If anyone wants to follow along or help out, here is the planning board I am using. If you think you might help, create a Trello account and I’ll start a new team. Please join me on Thursday, I’ll be working on this all day long and live-streaming.

To run, checkout the react branch on my fork above and run:

npm run dev

You’ll need node.js and npm of course, and don’t forget to npm install.

I will be putting some of the more boring tasks (like LaTeX conversion and syntax highlighting) off until we get the major changes worked out. On Thursday I will be converting the first “simple scalar encoder” visualization into a React component.

Holy cow, Brev, this site is outstanding! Exactly the kind of thing I want! And he wrote an interactive tutorial on building interactive tutorials! This is super-useful…

2 Likes

@brev
Great find.
That is an amazing tutorial.

2 Likes

I am excited to start working on this tomorrow. I’ve already got a head start, so we will hit the ground running. I’ll lay out the big vision of the project, then we’ll dive right into the React architecture. Starting with the first visual, I’ll be converting them into React components while applying lessons from the interactive tutorial linked above. Pretty quickly we’ll need to get observable data stores working. Should be fun.

There will also be some low-hanging fruit that others can help out with. For example, we’ll need code syntax highlighting, LaTeX conversion, layout / styling. These are side-projects that other folks can help with.

PRs welcome!

If you do plan on helping, please join our Trello team. I’m using it for project planning, it is a really lightweight planning tool. I think it will be just enough for Twitch projects. (I switched to GH Projects.) I hope to see some of you online tomorrow morning at 9AM PDT.

1 Like

In the first part of today’s stream, I went over the big picture for this project:

Then my internet crashed. Once I recovered, there is another 3 hours where I got one d3js diagram rendered in React (no interactions or data updates yet).

Next week I am PTO, but I will be back on Apr 25 to add observable data and interactions.

1 Like

I will be streaming on this project Tuesday and Thursday this week 9AM PDT (for most of my work day, join any time). Keep up with my schedule on the Building HTM Systems events page.

Today, thanks to help from Vratislav (who I can’t find on the forum), we did the following:

  • updated simplehtm to install properly on npm
  • imported and used encoders defined in simplehtm for client-side scalar encoding diagram
  • installed LaTeX support
  • installed code syntax highlighting support

We also figured out how to allow code highlighting by watchers during my live-stream in VSCode, which is pretty darn cool. Whole session is available to watch now on YouTube here:

3 Likes

This is a response to the React or Not React video, I figured this would be a better place for discussion.

I created a fork that shows how you could create a static site that bundles a similar way as Next.js does (so you can use modern javascript).

I think not using React is the best decision. We used React for a year long project at my software consulting job, after that we used it for 6 month software engineering project and my team regretted it both times, despite fully embracing the React ideology. We fought it all the time when trying to do simple things, and it did not play nice with anything external. Most of all, it’s a black box when things go wrong. It’s great for giant companies because it forces modularity and prevents spaghetti code, but it comes at a heavy cost. In particular, the work you want to do (talking between components) is extremely painful in React.

I strongly recommend not even using functional components because of the way React handles the virtual DOM. React only updates when it thinks it needs to update. If you have an external library changing things, React isn’t going to see those changes and it is going to start screwing things up because it doesn’t have all the information. The other issue with the virtual DOM is that it often overwrites the real dom with new nodes. Meaning if you use JQuery to grab a real node, that real node will likely get deleted and replaced very quickly with React, and JQuery is left pointing to a deleted node, which just causes more broken behavior. When you code in React, you pretty much have to code everything in React.

It is really easy to write unmaintainable Javascript, but you can write maintainable Javascript if you plan it out and document it well, and that is what I personally prefer. I actually use JSX without React.

I do want to mention Vue.js though because it might actually be what you’re looking for. You don’t need to change your existing codebase, you could write a static HTML site, and then insert a Vue component for just one graph on one page. It has events/listeners like normal Javascript, so you can do something similar to:

let component1 = new Vue({
    // as soon as the component loads, set a timer for 1 second
    // then emit an event
    mounted: function() {
        setTimeout( ()=> this.$emit('its-been-1-second'), 1000 ) 
    }
})
let component2 = new Vue({
    // Just render a div with some text
    template: '<div>{{ test }}</div>'
    data: {
        text: 'hello'
    },
})
component1.on('its-been-1-second' , ()=>{ 
    component2.text = "It has been one second!"
})
// Attach them to the DOM
$('#whereever-you-want-this-component').appendChild(component2.$elem)
$('#whereever-you-want-this-component').appendChild(component1.$elem) 

Sadly Vue still uses a Virutal DOM within it’s components, but it won’t get in the way of everything like React does.

2 Likes

@jeff-hykin That’s very helpful, thank you. I am most afraid that React is going to mess up my workflow with D3js. All my pages are going to have lots of D3js, and even though I got past my issues setting up the parent/child components, I’m still have issues with page repaints:

cc @David_Duckworth

My team had similar slowness issues with input boxes. We wanted to run input box validation (phone number, email, etc) I had to go do special hacky optimizations just to get where you could type without it lagging.

You can try storing the value outside of the component state (in any regular variable, or on this) and then just manually update the D3 element onclick/ondrag instead of updating the state. It would defeat the entire purpose of React state, but it might get the correct behavior. To get the D3 element like you would with jquery though, you have to use a thing called React References.

You can also dive into the chrome performance tools (one of the tabs in the chrome debugge) and it’ll let you pick apart the code to see what is causing the slowdown.

Maybe tomorrow I’ll look at making a fork of the React version and port it to Vue and see if the slowness is still there. Vue will let you check on a sub-value in state, and put a custom handler on it. (e.g. state.counter.onUpdate() ) If it’s still slow then it’s pretty likely it is just a virtual Dom issue.

2 Likes