Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla Chromeless 0.2

mozillalabs.com

Post reply on HN
Print view View original

51–60 of 72 posts

Re: Mozilla Chromeless 0.2

#51

Post by IanDrake »

bni wrote: post #22
mambodog wrote: post #19

Earlier quoted context omitted.

Appcelerator Titanium is another option in this category, and is focused on building applications using JS/web standards.

yes, but if im stil up to date on that, it has its own gui frameworks that your app is tied to forever. Might aswell write the app in Cocoa or Win32 then. Correct me if Im wrong, can you deploy your client side web app as a desktop application without using the Titanium framework stuff?

I believe you're correct about the framework. I think Titanium apps are packaged with the framework statically "linked", instead of installed separately.

The Titanium mobile API is basically JS bindings for Cocoa, but the desktop API is mostly OS agnostic.

In my opinion, Titanium was smart to make one version for mobile and one for desktops. Adobe should have done the same.

Re: Mozilla Chromeless 0.2

#52

Post by bzbarsky »

daeken wrote: post #49
bzbarsky wrote: post #47

Earlier quoted context omitted.

Well, for a start there's the problem that LLVM itself is architecture-dependent, last I checked. It's not as arhictecture-dependent as assembly but the last time I looked you couldn't generate the same LLVM on x86 and x86-64, say. Has that changed? It looks like PNaCl aims to "solve" this problem by using 32-bit-targeted LLVM... including 32-bit pointer alignment. It's not immediately obvious how portable this would…

> Well, for a start there's the problem that LLVM itself is architecture-dependent, last I checked. It's not as arhictecture-dependent as assembly but the last time I looked you couldn't generate the same LLVM on x86 and x86-64, say. Has that changed? LLVM bytecode is 100% architecture and platform independent, unless you call into platform-specific bits or into blobs of machine code.

OK, so in that case what http://llvm.org/docs/FAQ.html#platformindependent is telling me is that it's not possible to produce said LLVM bytecode from C or C++ code in general, right?

And if I read http://llvm.org/docs/LangRef.html correctly, some bitcode is "not supported by all targets". How is that reconciled with "100% platform and architecture independent"?

Re: Mozilla Chromeless 0.2

#53

Post by [deleted] »

daeken wrote: post #49
bzbarsky wrote: post #47

Earlier quoted context omitted.

Well, for a start there's the problem that LLVM itself is architecture-dependent, last I checked. It's not as arhictecture-dependent as assembly but the last time I looked you couldn't generate the same LLVM on x86 and x86-64, say. Has that changed? It looks like PNaCl aims to "solve" this problem by using 32-bit-targeted LLVM... including 32-bit pointer alignment. It's not immediately obvious how portable this would…

> Well, for a start there's the problem that LLVM itself is architecture-dependent, last I checked. It's not as arhictecture-dependent as assembly but the last time I looked you couldn't generate the same LLVM on x86 and x86-64, say. Has that changed? LLVM bytecode is 100% architecture and platform independent, unless you call into platform-specific bits or into blobs of machine code.

[deleted]

Re: Mozilla Chromeless 0.2

#55

Post by leoc »

bzbarsky wrote: post #47
leoc wrote: post #40

Earlier quoted context omitted.

So what remaining problems with NaCl's compile-once-per-each-architecture model do you believe can't be solved by the combination of multi-architecture compilers (llvm, gcc ...) on the developer/server end and PNaCl on the client? Obviously the implementation is incomplete and immature, but Mozilla and Opera aren't even pretending that their opposition to NaCl is based on the immaturity of the implementation. > And w…

Well, for a start there's the problem that LLVM itself is architecture-dependent, last I checked. It's not as arhictecture-dependent as assembly but the last time I looked you couldn't generate the same LLVM on x86 and x86-64, say. Has that changed? It looks like PNaCl aims to "solve" this problem by using 32-bit-targeted LLVM... including 32-bit pointer alignment. It's not immediately obvious how portable this would…

> Well, for a start there's the problem that LLVM itself is architecture-dependent, last I checked.

The idea is not to produce a single cross-platform binary using LLVM - let alone using GCC! - but to produce a set of NaCl binaries for common archs from your portable HLL code using a cross-platform compiler - like LLVM, or GCC - plus PNaCl (or whatever) as the wildcard. Content negotiation is your friend.

> It looks like PNaCl aims to "solve" this problem by using 32-bit-targeted LLVM... including 32-bit pointer alignment. It's not immediately obvious how portable this would be to some hardware,

shrug I haven't heard of any major problems in converting LLVM IR to decently-performing assembler in various archs, so I presume that PNaCl will be able to do okay, especially since the bar is not set very high: consistently world-beating performance is not a necessity in a backstop solution. And if you're on a new or obscure platform (or, er, IE/Windows/x86-64) you're not guaranteed the swiftest Javascript speeds either. The likely worst is that PNaCl will need a redesign: see below.

> and more importantly I'm not aware of any plans to support anything other than x86 and ARM initially (well, and x86-64 using its ability to run 32-bit code as far as I can tell). Am I just missing something on this front?

As I said in my previous post "Obviously the implementation is incomplete and immature, but Mozilla and Opera aren't even pretending that their opposition to NaCl is based on the immaturity of the implementation." Seriously, if the problem with NaCl is that it's not mature and widely ported enough yet, then there's an obvious solution to that.

Re: Mozilla Chromeless 0.2

#56

Post by lloydhilaiel »

glenjamin wrote: post #46

Their documentation system seems to be pretty cool. Does anyone know if this is spun off as a separate project somewhere? It looks pretty and seems to tie API functions straight to the equivalent github page - sounds like it would be pretty useful in lots of places.

it's homegrown. I spun off the docstract project which pulls docs outta .js and outputs them in json. From their you can render the docs however you want. Docstract itself is permissive open source you can use, here:

https://github.com/lloyd/docstract

Re: Mozilla Chromeless 0.2

#58

Post by lloydhilaiel »

ww520 wrote: post #28

This looks promising. Are there supports for native file system access, databases (SQLite?), and network access?

file system access, yeah! It should feel like node.js (on purpose): http://mozilla.github.com/chromeless/#guide/filesystem-acces...

databases, IndexedDB should "just work", and thinking exposing SQLlite is worthwhile.

only the most basic network libraries at the moment.

Re: Mozilla Chromeless 0.2

#59

Post by lloydhilaiel »

euroclydon wrote: post #5

I can't tell if this is an alternative to something like QtWebKit. There doesn't seem to be any emphases on native code integration.

one way you can do native code integration with chromeless is using JSCtypes: https://wiki.mozilla.org/JSctypes

I hacked up a trivial proof of concept on this branch: https://github.com/mozilla/chromeless/tree/jsctypes_play

Re: Mozilla Chromeless 0.2

#60

Post by bzbarsky »

leoc wrote: post #55
bzbarsky wrote: post #47

Earlier quoted context omitted.

Well, for a start there's the problem that LLVM itself is architecture-dependent, last I checked. It's not as arhictecture-dependent as assembly but the last time I looked you couldn't generate the same LLVM on x86 and x86-64, say. Has that changed? It looks like PNaCl aims to "solve" this problem by using 32-bit-targeted LLVM... including 32-bit pointer alignment. It's not immediately obvious how portable this would…

> Well, for a start there's the problem that LLVM itself is architecture-dependent, last I checked. The idea is not to produce a single cross-platform binary using LLVM - let alone using GCC! - but to produce a set of NaCl binaries for common archs from your portable HLL code using a cross-platform compiler - like LLVM, or GCC - plus PNaCl (or whatever) as the wildcard. Content negotiation is your friend. > It looks…

> I haven't heard of any major problems in converting LLVM IR to decently-performing assembler

But normally when you create LLVM IR you can choose what your pointer-size representation is, as I understand. Again, I could be completely off base here; I've just read some of the docs and talked to people who have worked with LLVM, not worked with it myself. Please tell me if I'm wrong!

The problem with PNaCl is not that it's not widely ported enough "yet", but rather that there are no plans for a way to run it on platforms what PNaCl hasn't been ported to. Compare this to JS, where you can get JS working on a new platform in fairly short order (e.g. by just compiling Spidermonkey, which is largely fairly portable C code and has a platform-independent interpreter). Now your new platform won't have a JIT yet at that point, so performance may not be great, but at least you'll have a fighting chance at using the web. You won't have that without a pretty large porting job if NaCl is in wide use.

Post reply on HN