Actually the whole project is out there, only in pieces. I'm just stating what can be easily built. The tweaks to the JS engine, the only serious programming (I think) is something like a week of work, so I guess you better start porting already 0 the actual project is almost none of the work.;P BTW, thanks for the compliment. But the brings up the issue, what is supposed to go in a kernel? We've moved the hardware specific stuff in the compiler/runtime. I propose a library/object based self modifing/JIT Synthesis style kernel, using compiler based protection, instead of the usual hardware augmented kind.
Flew right outta my head. But it seems like it offers nothing the others don't. And I don't see a reason to not use a properly typed JS for systems. I mean, what's wrong with it? The event paradigm matches perfectly, you don't have to fiddle around with classes, and still get an object system, looks quite like C, all you need is a way to interface the actual hardware. That can be done by simply compiling Verilog RTL interface specs as a runtime environment. Interrupt.mask(false).Ethernet, anyone?
Well, does that installer work any old or new and/or obscure distro, regardless. Does the installer support all the compile time options? Honestly, if you are gonna beat Win, at least try to be better, not just as good. Because if you are gonna be just as good, most users might as well use Win. I think this is the place for an idea I've had for some time - source configuration aware compiler. Instead of #ifdef and #include, #pragma using declarations and code block annotations, as an extension to LLVM. That way, all the build time info goes into the.llvm end file. Anyone wanting to install, regardless of which *nix, just compiles with appropriate (autogenerated?) options. Heck, that might work for newer Wins, with Unix services built in.
Slashdot Mirror
Seconded. But you should see the zSeries. TCP checksum and CPU time instruction. Fused multiply add/sub. Not bad, eh?
...snarky comments...
Who would have anything against VAXen? I mean DEC knew their stuff.
Parse error: Unexpected VCS identifier.
Oh, and what is your idea for an object implementation? And do you have a better idea for closures?
Actually the whole project is out there, only in pieces. I'm just stating what can be easily built. The tweaks to the JS engine, the only serious programming (I think) is something like a week of work, so I guess you better start porting already 0 the actual project is almost none of the work. ;P
BTW, thanks for the compliment. But the brings up the issue, what is supposed to go in a kernel? We've moved the hardware specific stuff in the compiler/runtime. I propose a library/object based self modifing/JIT Synthesis style kernel, using compiler based protection, instead of the usual hardware augmented kind.
Because pure XML is a pain. They are supposed to make it easier. And seem a reasonable solution.
Do you work as a physicist, by chance? Seems like a LHC-esque solution. Good job.
I doubt it, that's a lot of energy going for muscle.
Ditto. Sorry for the AOL reply.
Now turn in yours. JS takes concepts from Self and Lisp, not C++.
That's why XQuery and XSLT exist.
How about using rational fractions, preferentially hardware accelerated? FPUs are too big and slow anyways.
Flew right outta my head. But it seems like it offers nothing the others don't. And I don't see a reason to not use a properly typed JS for systems. I mean, what's wrong with it? The event paradigm matches perfectly, you don't have to fiddle around with classes, and still get an object system, looks quite like C, all you need is a way to interface the actual hardware. That can be done by simply compiling Verilog RTL interface specs as a runtime environment. Interrupt.mask(false).Ethernet, anyone?
Oops. My bad. Sorry for being snarky.
Ada, Lisp, Strongtalk, strongly typed JS. Depending on application.
Here's someone who didn't google something. It's about as production ready as an fs can be.
When using assembly, are they part of the way you tell the machine what to do, or are they there for readability?
No problem.
Well, does that installer work any old or new and/or obscure distro, regardless. Does the installer support all the compile time options? Honestly, if you are gonna beat Win, at least try to be better, not just as good. Because if you are gonna be just as good, most users might as well use Win. I think this is the place for an idea I've had for some time - source configuration aware compiler. Instead of #ifdef and #include, #pragma using declarations and code block annotations, as an extension to LLVM. That way, all the build time info goes into the .llvm end file. Anyone wanting to install, regardless of which *nix, just compiles with appropriate (autogenerated?) options. Heck, that might work for newer Wins, with Unix services built in.
Anybody have an idea of why EFI didn't catch on? Seems a good solution to all driver issues, permanently.
The form factor is more focused on area, not thickness, so who said that you can't coat the bottom with battery packs?
Bigger screen, more HDD/RAM? />
This is kinda off-topic, but I really miss Transmeta. I'm sure they would have liked this.
<tear type='real'
WTH? Is that using a buggy curses implementation or something? Well, at least it is somewhat... fitting of Perl. In an ironic way.
Funny, the above sounds quite right about JS.