jvilk

The author of micropolisJS is not the author of 3D City. In this case, 3D City needs to be licensed under the GPL, and I believe 3D City needs to include the copyright details for the original port.

In addition, micropolisJS has additional terms added to the GPL [0], which are clearly linked to from the top of every source file in micropolisJS [1], which need to be distributed with 3D City.

[0] http://micropolisjs.graememcc.co.uk/LICENSE

[1] https://github.com/graememcc/micropolisJS/blob/master/js/Blo...

> I wish we could move towards a model where browser vendors would expose low level APIs...

You might find this academic paper from James Mickens interesting, which explores this exact idea in detail:

http://sigops.org/sosp/sosp11/current/2011-Cascais/printable...

I like to think that my BrowserFS [0] codebase is a relatively well-designed TypeScript codebase, but I'm a bit biased. Not sure what you view as 'large', though.

[0] https://github.com/jvilk/BrowserFS

> you shouldn't have to encode that in the path, just some metadata in a file somewhere would have done the same job

There are two problems with this approach, from how I see it.

1) Now there is an extra build step: Produce the metadata that associates class names with files.

2) This mechanism also adds an extra level of indirection when the ClassLoader needs to resolve a class.

By using a file system, you can edit a single Java file in a project with many classes, and recompile only that single file to test your changes.

> All this code is ALREADY in a folder named gov.nasa.arc.spife.core.plan.editor.timeline

That's NASA's choice for organizing code into modules. Each of these look like individual libraries, and that's the full name of the package that the library supplies. Sounds practical, especially since they have the source code of other non-NASA libraries checked in (e.g. rhino).

They could have merged the source trees of the individual components, but that becomes cumbersome as some of the third party components are under different licenses, and it's likely that each of these packages are built and packaged into separate JAR files.

That folder name won't be in the final JAR file, which will only have the hierarchy past the src folder.

Note that the JVM has a robust mechanism for custom classloaders, so you could actually implement your metadata idea if you wanted to. What will happen at runtime is that the JVM will invoke your custom classloader with the full class name (e.g. java.lang.String), and then you have to give it the Class object associated with it (which you can construct dynamically, produce from a byte array loaded from somewhere, or request from the JVM's file-based classloader).

(Apologies in advance if I am misunderstanding the complaint -- I'm assuming 0 prior knowledge on your end, so my write-up below may sound obvious! Sidenote: I've written a JVM, so I've gained an appreciation for some aspects of the JVM, including class resolution [0].)

In Java/the JVM, file names unambiguously correspond to your package/module/class names. Given a full class name (e.g. java.lang.String) and the class path (a list of folders/JAR files), the JVM is able to locate the specific file with the implementation of that class. This feature is crucial to how the JVM performs dynamic classloading, as classes can reference other packages/classes with a simple string, and the JVM will fetch the relevant class dynamically at runtime.

For example, in the parent comment, gov.nasa.arc.spife.core.plan is the package name, which translates to the folder /src/gov/nasa/arc/spife/core/plan/. This package name, while verbose, makes sense for NASA, as it corresponds to that organization's hierarchy. gov.nasa corresponds to NASA, arc = NASA's Ames Research Center, spife is probably the project name, and then the rest correspond to packages in that project. This hierarchy makes it clear who has the right to modify particular hierarchies of the namespace, allowing employees to make new packages within their levels of the hierarchy without worrying about name collisions.

As a concrete example, it would be troublesome if every research lab decided to use the gov.nasa.util package name. Or worse -- just 'util'. If both of these are libraries, it's feasible that a client application might use both of them... but then the application will discover that it is unable to use both due to a simple naming conflict in library code!

I agree that it appears cumbersome and wasteful to those used to editing on the command line (as the files are scattered all over the file system), but it's less visible when using an IDE that coalesces empty folders together.

[0] https://github.com/plasma-umass/doppio

It is supposed to provide a unique identifier for all packages in all applications, allowing you to mix code from multiple packages without namespace collisions.

From http://docs.oracle.com/javase/specs/jls/se5.0/html/packages.... :

> The suggested convention for generating unique package names is merely a way to piggyback a package naming convention on top of an existing, widely known unique name registry instead of having to create a separate registry for package names.

I made a (very childish) bookmarklet to make it more fun :)

http://people.cs.umass.edu/~jvilk/bookmarklet.html (The "javascript:" link for the bookmarklet is on this page)

Click it when you're on a Git manpage, either legitimate or generated.

> Who Maintains Type Definitions?

Hi. As a user of TypeScript in all of my projects, if I find a typing bug or a deficiency in a typing, I commit a fix to DefinitelyTyped. Or if a library isn't typed, I create a typing myself and contribute it.

> Or, what if there are type definitions, but not for the particular version of the library you need to use?

Then you don't use type definitions, and you "fall back" to untyped interactions with the library -- just like JavaScript. Or, you write those type definitions yourself, and contribute them to DefinitelyTyped. They are very open to PRs.

> How can you be sure the definitions are correct?

You usually figure that out through testing, and you either contribute fixes upstream, use casting as a hackfix, or cease to use the typing. They are never going to be perfect, but they are a hell of a lot better than nothing.

And all definitions are required to have valid code associated with them that compiles properly. Usually this is grabbed from documentation, if available. Thus, it's likely that if a typing is broken, it's in a small subtle way that won't be encountered in common use-cases.

> If you love JavaScript, warts and all, but wish it had classes, modules, interfaces and static typing then TypeScript is the answer.

I hate JavaScript. But it's all we have to work with in the browser environment, and there are many wonderful libraries available that I like to use in my projects. So, I program in it.

TypeScript makes it much easier to write large projects with multiple contributors, and it makes it much easier for new contributors to have confidence in their changes, as a whole class of JavaScript runtime errors are automatically found by the compiler through type inference/type checking. And the Visual Studio tooling is just dandy, with up-and-coming support in Eclipse and WebStorm/IntelliJ.

TypeScript is the answer for me.

Not personally, but this article has stuck in my mind:

http://gigaom.com/2013/03/15/by-the-numbers-how-google-compu...

Note that this is a year-old article. It also doesn't address reliability; it focuses on common performance benchmarks. The article links to a GitHub repo with some performance benchmarks you can run yourself.

Hello, JSMESS developer here.

It should work on Chrome/Firefox/Opera/IE 10+/Safari/just about anything with typed arrays.

Chrome and Firefox have USB joypad support, but you need to activate it (by pushing a button on the joypad when the page loads) before the emulator starts.

Earlier versions of TypeScript had some significant typing issues in my experience, especially related to typechecking static fields on object instances (which you can't access through object instances -- you have to go through the class object).

Since the 0.9.5 release, I don't think I've had any particular issues with typechecking or the language. And as someone mentioned, if you use lambdas, the compiler will automatically handle performing the `var _this = this;` trick for you under-the-hood.

> we were trying to write TypeScript like we were writing C#

Yeah, you really need to approach writing TypeScript as if you are writing idiomatic JavaScript. I'm happy that I went through the JavaScript mill before discovering TypeScript, as it informed how I developed my project.

I think it's just syntax highlighting, like the current ST support [1]. There's notable vim support [2], but... I prefer GUI editors for IDE-style development.

[1] http://blogs.msdn.com/b/interoperability/archive/2012/10/01/...

[2] https://github.com/leafgarland/typescript-vim

It has improved in recent releases, but I think they are focusing mostly on incremental compilation via the -watch flag. My projects still take 5-7 seconds to build from scratch on my MacBook Air.

You probably know this, but just for others' information: Type inference is expensive, as it requires global information about the project. As a result, compiling one TypeScript file in a project results in the compiler recompiling all of the referenced modules and definitions to re-build up that inference information from scratch. Using the -watch flag keeps the compiler alive with that information in-tact in memory, enabling incremental recompilation.

I also switched two of my research projects over to TypeScript from CoffeeScript [1,2]. I'd like to state up-front that CoffeeScript still has its merits in certain scenarios; they are two very different projects, despite both providing convenient `Class` abstractions over prototype-based inheritance.

With that said, using TypeScript has vastly decreased the amount of mental state I need to keep in my head when I develop one of my projects. The compiler uses the type annotations to double-check my logic, and Visual Studio gives me the ability to easily refactor interfaces as if I were using a statically typed language [3]. I could go on... but I will spare you the blog post. :)

I really wish there was a free or cross-platform alternative to Visual Studio for TypeScript autocomplete and IntelliSense. The WebStorm IDE claims to support TypeScript, but it gives me tons of incorrect compilation errors in my current projects. I hope it matures so there is an alternative. Anyone working on TypeScript tooling that is comparable to VS for different editors (e.g. Sublime)?

EDIT: Whoa, I completely missed this in the blog post; palantir is developing an Eclipse plugin [4]. They also developed a tool that converts CoffeeScript projects to TypeScript; interesting [5].

[1] https://github.com/int3/doppio Doppio: A JVM in TypeScript

[2] https://github.com/jvilk/BrowserFS BrowserFS: A full-featured file-system in your browser that emulates the Node fs API

[3] I'm referring to trivial refactorings -- renaming function/variable names and such. Refactors that are more complex, such as changing the function signature, must be done manually at call sites, but the compiler will catch your errors if you mess up or forget one.

[4] https://github.com/palantir/eclipse-typescript

[5] https://github.com/palantir/coffeescript-to-typescript

Nice! Good to see others tackling this sort of problem.

I'm actually working on a similar project, but it instead uses the file system abstraction for storing and retrieving data. It's called BrowserFS [0], and it emulates the Node file system API.

I haven't written an IndexedDB or WebSQL backend yet, because I've been focusing on the architecture and other problems recently. But I'd appreciate any comments people have on it. :)

[0] https://github.com/jvilk/BrowserFS

Cool hack. Is the source code available somewhere?

> - Consistent performance.

> (not like the V8 engine pausing the whole application for GC)

But... you're still going to need garbage collection, unless you are only planning on supporting something like ASM.js. So there will still be application pauses for GC.

Also, you mention that you have support for JavaScript OO, but I notice the benchmarks don't exercise programmer-defined JavaScript objects/prototypes. Do you have numbers on its OO performance, or is that still something you're working on?

Finally, how do you handle type inference at the LLVM level? I assume you implemented some form of JIT compilation? I'd be interested to hear more!

Visual Studio has really nice TypeScript support. :)

Also, I never said the Windows developers were 'okay' with Cygwin... just that it wouldn't solve the problem. ;)

I used make for a long time on my JS codebases, and I agree that it is very useful. You can do a lot without needing to write a lot, and file targets usually 'make sense' for most build tasks.

I decided to switch to Grunt, though, to enable Windows developers to build my projects. This decision stems from the fact that Node does not run in Cygwin in Windows, so we weren't getting Windows build support 'for free'. The Grunt build files are much much more verbose, but I know that they work cross-platform as I no longer rely on CLI tools that may not be present, or may have different flags between the BSD and GNU variants.

If you don't care about Windows developer support, though, make is definitely worth investigating.

And now you can relive this classic computer in your browser, courtesy of JSMESS [1] (although, at the moment, it doesn't run at 100% speed).

Information on key bindings and how you can e.g. activate the FORTH interpreter can be found here [2], although I couldn't get the FORTH interpreter working (I'm not sure if the browser/Emscripten can properly distinguish between ALT keys).

[1] http://jsmess.textfiles.com/messloader.html?module=cat

[2] http://mamedev.org/source/src/mess/drivers/cat.c.html

Thanks!

We had an excellent Google Summer of Code student work on AWT support for half of the summer. We discovered that the OpenJDK AWT implementation betrays its own internal abstractions, making it impossible to implement a new backend without forking the Java Class Library and making nontrivial changes.

You can read more about the problem here: http://mail.openjdk.java.net/pipermail/challenge-discuss/200...

Unfortunately, the project described in the above link appears to be defunct and unmaintained. :( We don't have the resources to work further on the problem at the moment.

Regarding performance, we are about 20-40X slower than the HotSpot Interpreter in Google Chrome, with similar numbers in other browsers. There is a significant amount of work that we can and plan to do to make that much better, though.

Right now, http://codemoo.com/ by the University of Illinois uses it to teach Java. A few teachers have expressed interest in using it for similar purposes, but we need to make deployment easier.

It's too slow at the moment for production use, since it is an interpreter. But if we add JIT compilation support, I believe it will be fast enough for usably running legacy code/libraries in the browser.

Note that the demo is somewhat old; I do not know if it has park implemented. You'll want to build it from GitHub, which we've made relatively straightforward.

We are planning to update the demo (and perhaps post on HN) once I fix some IE issues (since we strive to be compatible with IE9).

In the Java Class Library, any function that needs to interact with the environment outside of the JVM itself (OS/file system/network/threading/etc.) is implemented in C and is marked as 'native'. Those are the functions that we explicitly implement for the JavaScript/browser environment.

You are right that we could extract more performance by mapping particular classes directly onto efficient browser functionality -- such as String. In the future, we could implement specific classes such as String directly in JavaScript for a performance boost. :)

As a side note, ASM.js itself does not have a String type, which leads me to believe that this particular optimization might not be beneficial if we switch to an efficient JIT strategy.

We have the ability to park threads and atomic CAS implemented, so we should support java.util.concurrent.

Granted, it's possible that it invokes a native function somewhere deep inside itself that we don't implement yet, but fixing those are usually very simple.

Interesting! It looks like you've reimplemented portions of the Java Class Library rather than use e.g the existing class files from OpenJDK.

My current research project, Doppio [1], implements the native portions of the OpenJDK Java Class Library so it can use an unmodified copy of the OpenJDK JCL. As a result, it can run a bunch of nontrivial programs (javac/javap/Rhino/Kawa-Scheme).

One issue you will run into is with multithreading. Since JavaScript has no true threading implementation with shared memory, you'll need to be able to suspend and resume virtual JVM threads. For this reason, Doppio maintains an explicit JVM stack representation.

Anyway, feel free to check out our code, reuse portions of it, or contribute if you're interested; it's MIT Licensed and under active development. :)

[1] Demo: http://doppiojvm.org/ Code: https://github.com/int3/doppio

My current research project, Doppio, can already run Rhino in the browser using JavaScript. :)

Demo: http://doppiojvm.org/

Code:https://github.com/int3/doppio