I'm looking for a STEP file parser for ruby that will spit out OBJ files or a model structure similar to OBJ files.
I also have found a make your own parser gem here but not quite sure how to properly set up the parser / lexer rules to use it.
I don't know if this is of any help, but I stumbled across the same problem a year ago. I had to get an IFC parser for C#. Although there are several solutions already, I decided so create my own. Therefore, I had to do the following:
Write a program (Generator), which reads an EXPRESS Schema (this EXPRESS file contains all the entities of the current IFC release defining their properties and the inheritance hierarchy) and creates all these entities as C# classes
This Generator further has to fit every so created class with the ability to write its objects to a STEP string
Put all the finished entities in a class library and use it in your main code
I also included an additional class in this class library, which can read IFC-files and then creates all the respective objects (this was really hard to do and I was not 100% successful, so it only works for certain classes for me. However, that was enough for my purpose)
So I reckon you could follow the same path just doing everything in Ruby. I hope this helped a little. Don't hesitate to ask, if you got any more questions.
I use late binding SDAI since I believe early binding (generation of C++/C# classes corresponding to STEP Entities) is not true way. I deal with AP242, AP209, AP238 (some problems were encountered, but I hope to resolve these problem), IFC. So, late binding is better way.
Related
I've discovered that I can split a class into multiple files by calling class <sameclassname>; <code> ;end from within each file. I've decided to divide up a very large class this way. The advantages I see:
I can have separate spec files called by guard to reduce spec time.
Forces me to organize and compartmentalize my code
Are there any pitfalls to this method? I can't find any information about people doing it.
I often do this in my gem files to manage documentation and avoid long files.
The only issues I found (which are solvable) are:
Initialization of class or module data should be thoughtfully managed. As each 'compartment' (file) is updated, the initialization data might need updating, but that data is often in a different file and we are (after all) fallible.
In my GReactor project (edit: deprecated), I wrote a different initialization method for each section and called all of them in the main initialization method.
Since each 'compartment' of the class or module is in a different file, it is easy to forget that they all share the same namespace, so more care should be taken when naming variables and methods.
The code in each file is executed in the order of the files being loaded (much like it would be if you were writing one long file)... but since you 'close' the class/module between each file, than your method declaration order might be important. Care should be taken when requiring the files, so that the desired order of the code execution is preserved.
The GReactor is a good example for managing a Mega-Module with a large API by compartmentalizing the different aspects of the module in different files.
There are no other pitfalls or issues that I have experienced.
Defining / reopening the same class in many different files makes it harder to locate the source of any given method, since there's no one clear place for it.
This also opens up the possibility of nasty loading sequence bugs, eg. file A is trying to call a method in file B, but file B has not loaded yet.
Having a very large class is a sign that the class is trying to do too much, and should be split up into smaller modules/subclasses. Sandi Metz's POODR recommends limiting classes to under 100 lines, among other guidelines.
In Ruby classes are never closed. What you call "splitting" is actually just reopening the class. You can reopen classes and add methods to them at any time. If you define a class in file A and include it in file B, even if you reopen the class in file B it'll still contain all the code from file A. I personally prefer only to reopen a class when I have to. It sounds like in your case, I would define my class in one file. I think this method is better organized and has a lower risk of interfering with previously defined methods. More on the subject at rubylearning.
Here's a good collection of Ruby design patters, or actually design pattern examples in Ruby: https://github.com/nslocum/design-patterns-in-ruby
Take a look at decorator as a good way to achieve modularity without a rigid parent<->child tree of classes.
The only pitfall is that your class is split in multiple files, that you need to menage. User of your class would only need to require the second file, so if your class is part of gem or some package, they probably wouldn't even be aware that it was ever reopened.
I'm beginning with the Ruby programming language and I'm interested in understanding it in depth before I start studding the Rails framework.
I'm currently a little disappointed because everybody seams to care only about the Rails framework, and other aspects of the language are just not discussed in depth, such as its class loading mechanism.
Considering that I'm starting by doing some desktop/console experiments, I would like to better understand the following matters:
Is it a good practice to place each Ruby class in a separate Ruby file? (*.rb)
If I have, let's say .. 10 classes .. and all of them reference each other, by instantiating one another and calling each other's methods, should I add a 'require' statement in each file to state which classes are required by the class in that file? (just like we do with 'import' statements in each Java class file?)
Is there a difference in placing a 'require' statement before or after (inside) a class declaration?
What could be considered a proper Ruby program's 'entry point'? It seams to me that any .rb script will suffice, since the language doesn't have a convention like C or Java where we always need a 'main' function of method.
Is class loading considered a 'phase' in the execution of a Ruby program? Are we supposed to load all the classes that are needed by the application right at the start?
Shouldn't the interpreter itself be responsible for finding and loading classes as we run the code that needs them? By searching the paths in the $LOAD_PATH variable, like Java does with its $CLASSPATH?
Thank you.
In general terms, it's a good practice to create a separate .rb file for each Ruby class unless the classes are of a utility nature and are too trivial to warrant separation. An instance of this would be a custom Exception derived class where putting it in a separate file would be more trouble than its worth.
Tradition holds that the name of the class and the filename are related. Where the class is called ExampleClass, the file is called example_class, the "underscored" version of same. There are occasions when you'll buck this convention, but so long as you're consistent about it there shouldn't be problems. The Rails ActiveSupport auto-loader will help you out a lot if you follow convention, so a lot of people follow this practice.
Likewise, you'll want to organize your application into folders like lib and bin to separate command-line scripts from back-end libraries. The command-line scripts do not usually have a .rb extension, whereas the libraries should.
When it comes to require, this should be used sparingly. If you structure your library files correctly they can all load automatically once you've called require on the top-level one. This is done with the autoload feature.
For example, lib/example_class.rb might look like:
class ExampleClass
class SpecialException < Exception
end
autoload(:Foo, 'example_class/foo')
# ...
end
You would organize other things under separate directories or files, like lib/example_class/foo.rb which could contain:
class ExampleClass::Foo
# ...
end
You can keep chaining autoloads all the way down. This has the advantage of only loading modules that are actually referenced.
Sometimes you'll want to defer a require to somewhere inside the class implementation. This is useful if you want to avoid loading in a heavy library unless a particular feature is used, where this feature is unlikely to be used under ordinary circumstances.
For example, you might not want to load the YAML library unless you're doing some debugging:
def debug_export_to_yaml
require 'yaml'
YAML.dump(some_stuff)
end
If you look at the structure of common Ruby gems, the "entry point" is often the top-level of your library or a utility script that includes this library. So for an example ExampleLibrary, your entry point would be lib/example_library.rb which would be structured to include the rest on demand. You might also have a script bin/library_tool that would do this for you.
As for when to load things, if there's a very high chance of something getting used, load it up front to pay the price early, so called "eager loading". If there's a low chance of it getting used, load it on demand, or leave it "lazy loaded" as it's called.
Have a look at the source of some simple but popular gems to get a sense of how most people structure their applications.
I'll try to help you with the first one:
Is it a good practice to place each Ruby class in a separate Ruby file? (*.rb)
It comes down to how closely related those classes are. Let's see a few examples. Look this class: https://github.com/resque/resque/blob/master/lib/resque.rb
, it "imports" the functionality of several classes that, although they work together, they are not closely related to be bundled together.
On the other hand, take a look at this module: https://github.com/resque/resque/blob/master/lib/resque/errors.rb. It bundles 5 different classes, but these do belong together since they are all essentially representing the same.
Additionally, from a design standpoint a good rule of thump could be asking yourself, who else is using this class/ functionality (meaning which other parts of the code base needs it)?
Let's say that you want to represent a Click and WheelScroll performed by a Mouse. It would make more sense in this trivial example, that those classes be bundled together:
module ComputerPart
class Mouse; end
class WheelScroll; end
class Click; end
end
Finally, I would recommend that you peruse the code of some of these popular projects to kind of get the feeling how the community usually make these decisions.
1.) I follow this practice, but it is not necessary, you can put a bunch of classes in one file if you want.
2.) If the classes are in the same file, no, they will all be accessible when you run the script. If they are in separate files then you should require them, you can also require the entire directory that the file(self) is in.
3.)Yes, it should be at the top of the file.
4.) In ruby everything descends from the Main object, the Interpreter just handles creating it for you. If you are writing OO ruby and not just scripts, then the entry point will be the init method of the first class you call.
5.) Yes, before the program runs it loads up all the dependencies.
6.) I think it does this, all you have to do is require the proper files at the top of the files, after that you can use them as you wish without having to implicitly load them again.
I would like to know if the following is possible in Scala (but I think the question can be applied also to Java):
Create a Scala file dynamically (ok, no problem here)
Compile it (I don't think this would be a real problem)
Load/Unload the new class dynamically
Aside from knowing if dynamic code loading/reloading is possible (it's possible in Java so I think it's feasible also in Scala) I would like also to know the implication of this in terms of performance degradation (I could have many many classes, with no name clash but really many of them!).
TIA!
P.S.: I know other questions about class loading in Scala exist, but I haven't been able to find an answer about performance!
Yes, everything you want to do is certainly possible. You might like to take a look at ScalaMock, which is an example of creating Scala source code dynamically. And at SBT which is an example of calling the compiler from code. And then there are many different systems that load classes dynamically - look at the documentation for loadLibrary as a starting point.
But, depending on what you want to achieve, you might like to look at Scala Macros instead. They provide the same kind of flexibility as you would get by generating source code and then compiling it, but without many of the downsides of that approach. The original version of ScalaMock used to work by generating source code, but I'm in the process of moving to using macros instead.
It's all possible in Scala, as is clearly demonstrated by the REPL. It's even going to be relatively easy with Scala 2.10.
I am writing a script that takes data from a database and creates GoogleChart URLs from the parsed data. I only need to create two type of charts, Pie and Bar, so is it wrong if I stick both of those classes in the same file just to keep the number of files I have low?
Thanks
If you're asking the "ruby" way, then it is to put your classes in separate files. As some others have alluded to, placing your classes in separate files scales better. If you place multiple classes in the same file and they start to grow, then you're going to need to separate them later.
So why not have them separate from the beginning?
UPDATE
I should also mention that autoload works by expecting classes to be in their own files. For instance, if you're in a Rails environment and you don't separate classes into different files, you'll have to require the file explicitly. The best place to do this would be in the application.rb file. I know you're not in a Rails environment, but for others who may find this answer, maybe this info will be helpful.
UPDATE2
By 'autoload', I meant Rails autoload. If you configure your own autoload, you can put classes in the same file; but again, why? The Ruby and Java communities usually expect classes to be in separate files. The only exception are nested classes, but that's for more advanced design patterns.
Usually more less-complex files are better than less more-complex ones. Specially if you need to share the code with others.
It's not wrong. If your code is simple enough* then by all means put all of it in one file.
On the other hand, if you think your code is going to get more complex later, or if you plan to use automated testing tools later, you will be doing yourself a big favour if you deal with the structure of all that now.
(* My personal rule of thumb: about 200 lines.)
In response to a previous question on how to achieve a certain effect with Swing, I was directed to JDesktopPane and JInternalFrame. Unfortunately, scala.swing doesn't seem to have any wrapper for either class, so I'm left with extending it.
What do I have to know and do to make minimally usable wrappers for these classes, to be used with and by scala.swing, and what would be the additional steps to make most of them?
Edit:
As suggested by someone, let me explain the effect I intend to achieve. My program controls (personal) lottery bets. So I have a number of different tickets, each of which can have a number of different bets, and varying validities.
The idea is displaying each of these tickets in a separate "space", and the JInternalFrames seems to be just what I want, and letting people create new tickets, load them from files, save them to files, and generally checking or editing the information in each.
Besides that, there needs to be a space to display the lottery results, and I intend to evolve the program to be able to control collective bets -- who contributed with how much, and how any winning should be split. I haven't considered the interface for that yet.
Please note that:
I can't "just use" the Java classes, and still take full advantage of Scala swing features. The answers in the previous question already tell me how to do what I want with the Java classes, and that is not what I'm asking here.
Reading the source code of existing scala.swing classes to learn how to do it is the work I'm trying to avoid with this question.
You might consider Scala's "implicit conversions" mechanism. You could do something like this:
implicit def enrichJInternalFrame(ji : JInternalFrame) =
new RichJInternalFrame(ji)
You now define a class RichJInternalFrame() which takes a JInternalFrame, and has whatever methods you'd like to extend JInternalFrame with, eg:
class RichJInternalFrame(wrapped : JInternalFrame) {
def showThis = {
wrapped.show()
}
}
This creates a new method showThis which just calls show on the JInternalFrame. You could now call this method on a JInternalFrame:
val jif = new JInternalFrame()
println(jif.showThis);
Scala will automatically convert jif into a RichJInternalFrame and let you call this method on it.
You can import all java libraries directly into your scala code.
Try the scala tutorial section: "interaction with Java".
Java in scala
You might be be able to use the scala.swing source as reference e.g. http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk/src/swing/scala/swing/Button.scala
What sort of scala features are you trying to use with it? That might help in coming up with with an answer. I.e. - what is it you're trying to do with it, potentially in Java? Then we can try to come up with a nicer way to do it with Scala and/or create a wrapper for the classes which would make what you're trying to do even easier.
In JRuby, you could mix in one (or more) traits into JDesktopPane or JInternalFrame instead of extending them. This way you wouldn't have to wrap the classes but just use the existing objects. As far as I know, this is not possible with Scala traits.
Luckily, there is a solution, almost as flexible as Ruby's: lexically open classes. This blog article gives an excellent introduction, IMHO.