too slow and more likely would just cause cataracts. I'd recommend.22 pellet gun > 900 fps & nail the little bastards in the head. I won't mention.22 short sound suppressed with plastic milk jug, might be illegal.
and I should have added that by all means "body" could be a list, perhaps implementated by array that could contain strings, numbers, and booleans...just as long as I made sure it would respond to the method eval by doing something like say invoking a LISP interpreter and modifying itself accordingly, and changing "condition"
Your macro is the core of a LISP computer, essentially. in my example, body would not HAVE to be a string, it could be ANYTHING that responds to the message "eval". Now by default, yes eval takes a string which contains ruby code. But I can override that to be, say, a LISP interpreter. And "body" could be a string, or a file, or anything else I wanted. Just as condition would likely be a flag that I set to false when I'm done doing evals & changing body. So what I really showed was a possible core of a LISP computer that looks exactly like a thing that could be an interpreter for any language.
Sure, if one wants to invent new syntax and grammar. But let's get back to the original idea of doing the least typing to get the most work done, and of someone who's maybe done LISP in last decade or two wanting to try something fun and interesting. Also, have to add that there are a few projects like RIPPER out there that directly manipulate (some even replace) the Ruby parser if you really must invent a new grammar or syntax, and of course the fun lexer/parser libraries like RACC for new languages.
Won't argue: LISP is great, macros in LISP are Great & Powerful.
Multiple inheritance? Ruby has something better called mixin methods, all the fun and usefulness of MI without being in the position of having to weld a fish to a bicycle. Could *i* implement a new Object System with MI in Ruby? If nothing else, Ruby is so very introspective one could take a list of classes and the methods from each that were of interest, and another list of proc (code with closure of environment state) objects that would modify or use each of those methods, and spit out a funky kind of dispatching class that could make objects of that funky class. and call that my MI thang.
Anything more than the really simple lamdas always seemed to need macros. the short answer to macros is they're not needed; Ruby method coding really is a type of macro building. the long answer is to spend say four hours and learn some Ruby, it's fun!
well, I for one think we need to immediately pass legislation to protect the Holos and the Extremos from the sick deviant predilections of these halophiles and extremophiles, and mandatory prison terms for those that pander to them with web and literature.
The "enterprise" grade distros are using kernel 2.4.x; and that is being maintained with the emphasis to stabilize and secure. Someday 2.6.x will be in that mode; maybe the problem is everyone wants to use the lastest/greatest, when in fact there are known stable solutions out there? I find my commercial 2.6 nice and stable on my desktop (though only patched 2.6.8), and for a living I deal with 2.4.x server which runs wonderfully.
hehe, and there's no weather where those things were made to go. Really, from the vehicle assembly building to sit maybe some weeks at most on launch pad, those things didn't have to take too much weather exposure.
heh, not to mention the escape tower that could pull the manned capsule away from the rest of the rocket in extreme emergency, or the little solid fuel rockets that fired in the weightlessness of space so the liquid fuel would then be at the bottom of the tanks at the pumps so the rocket could RESTART after coasting, or the control systems that made manual intervention in the operation possible. The V2 was like a bottle rocket in comparison, light it & point it!
no, COBOL is. It runs on even more platforms than java (a 30+ year old computer isn't going to run java) COBOL has objects, platform independence if you want it & code that way, GUI libraries for any gui there ever was, web libraries, networking libraries for any network there ever was, SQL and nonSQL DBMS libraries, bidirectional C API that can deal with any other langauge, compiles to assembler or machine code....heck, let's just make sure I also mention that unlike Java it's also one of the most painfully verbose and inconvenient languages to code in EVER. 8D
I used to program in LISP, but I find that Ruby takes alot less typing. Closures in LISP need macros so they don't look so complex & don't wear out one's fingers.
thanks for the reply, now of course I'm curious to build BRLCAD and get into code and see if it's possible or sensible to have a way to transform and link geometric entities with an external "paperspace" section view that has all the drafting type entities in it. A couple decades ago in school I did some coursework of numerical methods for computational geometry with various splines and surfaces, will be fun to poke around in there if nothing else.
I can see from replies by people who are involved in the project that BRLCAD is modelling for analysis, whereas in SolidWorks you have integrated tools for modelling to build, manufacture, document and QA: Bills of material, 2D drawing/perspective/views with dimensioning and tolerances, etc.
there are plenty of interesting places in the world that actually have computer geeks and web cafes, but also the average person doesn't have credit cards nor a bank account, it's all cash and carry.
Is there a preferred/traditional way to also make 2D drawings/paperspace views of the models with this system? Also, capabilities for multiuser environment? I come from AutoCAD/ProE/AutoTrol background
I hear the Underwear Gnomes are going to sue everyone who uses this technique, and the all the slashdotters who make such lists, as unlicensed derivatives of the Underwear Gnome Strategic Plan for Profit
too slow and more likely would just cause cataracts. I'd recommend .22 pellet gun > 900 fps & nail the little bastards in the head. I won't mention .22 short sound suppressed with plastic milk jug, might be illegal.
and I should have added that by all means "body" could be a list, perhaps implementated by array that could contain strings, numbers, and booleans...just as long as I made sure it would respond to the method eval by doing something like say invoking a LISP interpreter and modifying itself accordingly, and changing "condition"
Your macro is the core of a LISP computer, essentially. in my example, body would not HAVE to be a string, it could be ANYTHING that responds to the message "eval". Now by default, yes eval takes a string which contains ruby code. But I can override that to be, say, a LISP interpreter. And "body" could be a string, or a file, or anything else I wanted. Just as condition would likely be a flag that I set to false when I'm done doing evals & changing body. So what I really showed was a possible core of a LISP computer that looks exactly like a thing that could be an interpreter for any language.
heh, parenthesis optional, too: while condition eval body end
while (condition) eval(body) end
Sure, if one wants to invent new syntax and grammar. But let's get back to the original idea of doing the least typing to get the most work done, and of someone who's maybe done LISP in last decade or two wanting to try something fun and interesting. Also, have to add that there are a few projects like RIPPER out there that directly manipulate (some even replace) the Ruby parser if you really must invent a new grammar or syntax, and of course the fun lexer/parser libraries like RACC for new languages.
Won't argue: LISP is great, macros in LISP are Great & Powerful. Multiple inheritance? Ruby has something better called mixin methods, all the fun and usefulness of MI without being in the position of having to weld a fish to a bicycle. Could *i* implement a new Object System with MI in Ruby? If nothing else, Ruby is so very introspective one could take a list of classes and the methods from each that were of interest, and another list of proc (code with closure of environment state) objects that would modify or use each of those methods, and spit out a funky kind of dispatching class that could make objects of that funky class. and call that my MI thang.
you don't know nerds very well. No longer is it a beer gut, it's a 3'-6" redhead in the reverse cowgirl position.
ah, you've caught me at the bullcrap propagated by those too lazy to upgrade 8D
Anything more than the really simple lamdas always seemed to need macros. the short answer to macros is they're not needed; Ruby method coding really is a type of macro building. the long answer is to spend say four hours and learn some Ruby, it's fun!
which head?
well, I for one think we need to immediately pass legislation to protect the Holos and the Extremos from the sick deviant predilections of these halophiles and extremophiles, and mandatory prison terms for those that pander to them with web and literature.
The "enterprise" grade distros are using kernel 2.4.x; and that is being maintained with the emphasis to stabilize and secure. Someday 2.6.x will be in that mode; maybe the problem is everyone wants to use the lastest/greatest, when in fact there are known stable solutions out there? I find my commercial 2.6 nice and stable on my desktop (though only patched 2.6.8), and for a living I deal with 2.4.x server which runs wonderfully.
that's bullcrap that's propogated by people too lazy to even check. For the record sshd, fingerd, identd, and sendmail are enabled by default
hehe, and there's no weather where those things were made to go. Really, from the vehicle assembly building to sit maybe some weeks at most on launch pad, those things didn't have to take too much weather exposure.
heh, not to mention the escape tower that could pull the manned capsule away from the rest of the rocket in extreme emergency, or the little solid fuel rockets that fired in the weightlessness of space so the liquid fuel would then be at the bottom of the tanks at the pumps so the rocket could RESTART after coasting, or the control systems that made manual intervention in the operation possible. The V2 was like a bottle rocket in comparison, light it & point it!
no, COBOL is. It runs on even more platforms than java (a 30+ year old computer isn't going to run java) COBOL has objects, platform independence if you want it & code that way, GUI libraries for any gui there ever was, web libraries, networking libraries for any network there ever was, SQL and nonSQL DBMS libraries, bidirectional C API that can deal with any other langauge, compiles to assembler or machine code....heck, let's just make sure I also mention that unlike Java it's also one of the most painfully verbose and inconvenient languages to code in EVER. 8D
I used to program in LISP, but I find that Ruby takes alot less typing. Closures in LISP need macros so they don't look so complex & don't wear out one's fingers.
thanks for the reply, now of course I'm curious to build BRLCAD and get into code and see if it's possible or sensible to have a way to transform and link geometric entities with an external "paperspace" section view that has all the drafting type entities in it. A couple decades ago in school I did some coursework of numerical methods for computational geometry with various splines and surfaces, will be fun to poke around in there if nothing else.
I can see from replies by people who are involved in the project that BRLCAD is modelling for analysis, whereas in SolidWorks you have integrated tools for modelling to build, manufacture, document and QA: Bills of material, 2D drawing/perspective/views with dimensioning and tolerances, etc.
there are plenty of interesting places in the world that actually have computer geeks and web cafes, but also the average person doesn't have credit cards nor a bank account, it's all cash and carry.
Is there a preferred/traditional way to also make 2D drawings/paperspace views of the models with this system? Also, capabilities for multiuser environment? I come from AutoCAD/ProE/AutoTrol background
the 80186! I mean, the Z8000! no, the DEC Alpha! Wait, no, no, it's the Itanium!
thank goodness you didn't say "clippy", the worst invention the past 25 years.
I hear the Underwear Gnomes are going to sue everyone who uses this technique, and the all the slashdotters who make such lists, as unlicensed derivatives of the Underwear Gnome Strategic Plan for Profit