Quote:
Java VMs actually have a compiler that is invoked at runtime on "hot" procedures to produce native, binary code. It is only done on hot procedures so as to maximize the benefits of doing a compile into native code while minimizing the overhead of compilation. Javac does compile Java source into bytecodes, which are, in most VMs initially interpreted (although IBM Research's Jikes/Jalapeno immediately did a fast translation to binary form) before being translated to native form. http://suif.stanford.edu/~jwhaley/p...avagrande99.pdf gives a good overview of the IBM Jikes/Jalapeno VM. (Just to confuse things, there is also a Jikes Java source to bytecode compiler that also originated at IBM Research.) Python (from my understanding) follows the example you give of compiling into a faster-to-interpret bytecode form, and not going any further. Sam |
The "C" languages should have been outlawed from college classes before they even started. It is one of the most convoluted pieces of crap I have ever seen. And it compiles 10 times bigger files than any language I've ever used.
I wouldn't doubt that is half the problem with newer versions of Windows. Never occurred to Microsoft (when trying to create a new OS) to go back to assembly code... |
Quote:
I apologize for the thread drift, and unless I encounter a moment of weakness this will be my last post on the subject. Time is better spent building rockets than talking about programming languages. :D C on a decent operating system has its place. As an instructional language, it offers the advantage and disadvantage of making students understand memory, addresses and pointers. As with everything real, there are trade-offs, and different compilers, linkers and OSes make different trade-offs and fill different needs. C was developed to implement Unix. In "The Mythical Man Month", Fred Brooks explains how OS/360, at around 6 million lines of assembly code, almost killed IBM. I started at IBM Research in the fall of 1991 after their first "one-time" billion plus charge. Sometime during the next two years as IBM flirted with bankruptcy, Fran Allen (who was my second line manager) explained to me that things had been much worse during the OS/360 days. In contrast, XP had 45 million plus lines of code, and while it was late, no one talked about Microsoft going under. In my opinion, the difference between the two was the use of modern languages (largely C and C++) and development tools that enabled a more distributed development model. Sam |
Quote:
Sam, Don't apologize! This is the right forum for this kind of discussion, even if the thread started out about OpenRocket. (And I can say that, since I'm the moderator of this section... :D ) If it gets too technical (this is a software thread in a computer section of a rocketry forum, after all...) we can always bump it to a new thread. But for now, I'm comfortable with it. :) I've enjoyed listening to your posts about the differences in Java (compared to what I remember from way back when it was the 'new kid on the block' in programming languages), and from your description, the language has changed a little over its life. Always something new to learn! I'm thrilled to see OpenRocket, even though it has a long way to go (and a short time to get there...). While I love RockSim and appreciate the power and flexibility it offers me, even so it has a few minor issues that I don't think have been properly ironed out. We've mentioned some of those issues around here from time to time. This new package might build a fire to get some additional action on the software front, whether that is from Apogee or even someone else. |
Thanks for comments. And competition is good - both in languages and rocket simulators!
Sam |
I've started playing with this..... anyone have any better idea for modeling the weight of a finish than just overriding the weight of the BT, fins and nose cone by some amount?
I modeled the BMS School Rocket and am getting plausible results from the simulations, though the deployment timing vs. apogee seems to be just a little off compared to actual flights. Too bad there's no weightless altimeter I could put on my rocket so as to compare results directly..... Maybe I'll have to model the Estes Star Stryker, for which I have altitude data via the How High. One other comment: there are the WECO (German) motors available it its motor menu, but they're not on Thrustcurve.org. It makes me wonder where the motor data really came from. WECO A8-3s are what I got when I ordered a bag of 25 A6-4s from Quest....and, except for the really dirty ejection charges, I like them better than the A6-4s. But that's the subject of another thread :). |
Quote:
This page at the NAR website provides a link to the CAR/NAR/TRA Certified Motor List, as well as a detailed listing of the motors that are currently certified by NAR's Standards and Testing (S&T) Committee. (The other two organizations have similar pages at their websites.) Scrolling down to the "A" motor section, you can find a listing for the Quest A8-3 motor, which is the WECO-made motor that you have, along with a convenient link to its certification document. Since your post was made so long ago, I suspect that you have by now found all of this information already, but I thought that I would add it here just in case. In all likelihood the author of Openrocket used the data from NAR's certification document to create the motor file for the Quest A8-3. (A listing of the raw data that was used to create the curve is usually included on the second page of the document, in case you want to plot your own curve. I use that data on very rare occasions to create motor definitions that aren't in my set of files for RockSim, using the EngEdit utility.) MarkII |
Mark,
Yes, I know of the NAR cert data and frankly have not delved into how that gets translated into something any simulator can use. I had poked both the NAR cert folks and Quest about these WECO motors since I had them in hand, and they bore the NAR-certified logo, but were not listed until a couple of months later. I still think it interesting that WECO motors are in the OpenRocket distribution and that they are identified as such (not as Quest motors). This was before the NAR data were available. I also see that Quest A8s, as certified by the NAR, are now on Thrustcurve.org..... |
The author of the software is from Finland so there's a good chance he saw those motors long before they came over here. He lists the source of the data and the WECO engine data came from a website in Germany.
I tried out OpenRocket and I like it. |
I've been using OpenRocket off and on. While a few additions would be nice, I can't complain about a free program!
|
All times are GMT -5. The time now is 02:13 AM. |
Powered by: vBulletin Version 3.0.7
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.