in Codeigniter's Image Manipulation Class there's a preference called 'library_path' where you have to mention the path to the binary. this means its executing the binary. Does this take more ram than using the apache extension ?
is there a less process intensive class or a method that can be used with CI?
Related
What is the format of the class related information loaded in method area by the class loader of jvm? Does the class information loaded in method area by class loader is present in machine language(native instructions set)?
Actually as the JVM's execution engine converts the bytecode into native instructions set. So I wanted to know does the class related information loaded by classloaders in method area of jvm is already present in native instructions set or present in any other format and later gets converted to native instructions set by JVM's execution engine.
Why file.bufferedReader() is giving me NullPointerException here?
val file = mock<File>()
when(file.bufferedReader()).thenThrow(IOException::class.java)
According to this thread Unable to mock BufferedWriter class in junit
You can mock Java IO classes (including their constructors, so future
instances also get mocked) with the JMockit library, though you will
likely face difficulties such as a NullPointerException from the
Writer() constructor (depending on how the mocking was done, and which
IO classes were mocked).
However, note that the Java IO API contains many interacting classes
and deep inheritance hierarchies. In your example, the FileWriter
class would also probably need to be mocked, otherwise an actual file
would get created.
Also, usage of IO classes in application code is usually just an
implementation detail, which can easily be changed. You could switch
from IO streams to writers, from regular IO to NIO, or use the new
Java 8 utilities, for example. Or use a 3rd-party IO library.
Bottom line, it's just a terribly bad idea to try and mock IO classes.
It's even worse if (as suggested in another answer) you change the
client code to have Writers, etc. injected into the SUT. Dependency
injection is just not for this kind of thing.
Instead, use real files in the local file system, preferably from a
test directory which can be deleted after the test, and/or use fixed
resource files when only reading. Local files are fast and reliable,
and lead to more useful tests. Certain developers will say that "a
test is not a unit test if it touches the file system", but that's
just dogmatic advice.
I meet a question about the interview test:
When a dll is loaded into memory, which part(s) can be shared between processes?
A. code segment
B. static variable global variable
C. external difinitions and references for linking
D. BSS segment
who can give me an answer and a clear explation?
Processes are actually isolated programs running multiple threads in an OS. Generally operating system policy says, All processes are memory isolated from each other.
Code Segment : [NOT SHARED]
BSS and Static Fields : [NOT SHARED]
Reason is very simple, why a operating system allow process A to access process B's binary? that's security and memory protection violation. process A could corrupt (if write access is given) process B memory.
what about External Definitions?
Here comes the interesting part, External definitions could be statically or dynamically linked.
statically linked library implies definitions are linked at compiled time and programs binary contains It's machine code.
dynamically linked implies definitions are linked just after user commands to load any program in memory. OS calls dynamic library loader to resolve external dependencies of the program by providing shared object's path.
This shared object is cached by operating system in a different page frame, and every time when a program demands for this library, It simply copy It's page frame to process's virtual memory; and do required dynamic linking. This way multiple process have same binary of a single library.
It save RAM memory and time in loading library from disk, Also dynamic linking reduces binary size of the program.
It is also possible that the OS choose to load library again from disk, and thus make two copies of same library. This is a part of dynamic linking operation. I don't go into more depth, but if you are really interested https://en.wikipedia.org/wiki/Dynamic_linker or just ping me in comments section.
But regarding BSS and static fields, It is again not shared; Whenever a write operation is performed on such region (which is shared). Operating System create a new copy of that region for the other process. This makes sure that both process have their own copy of BSS and static fields.
I am curious about when the class side initialize messages are sent in Smalltalk (Pharo and Squeak particularly). Is there any specified order? Is it at least safe to assume all other classes packaged with it have already been loaded and compiled, or does the system eagerly initialize (send initialize before even finishing loading and compiling the other classes)?
The class-side initialize is never sent by the system. During development you do it manually (which is why many of these methods have a "self initialize" comment.
When exporting code of a class into a changeset, the exporter puts a send of initialize at the very end, so it gets executed when the class is loaded into another system.
This behavior is mimicked by Monticello. When loading a class for the first time, or when the code of the initialize method was changed, it is executed. That is because conceptually MC builds a changeset on-the-fly containing the difference of what is in the image already and what the package to be loaded contains. If that diff includes a class-side initialize method, it will be executed when loading that package version.
As you asked about loading and compiling, I'm assuming you mean when loading code...
When loading a package or changeset, class-side #initialize methods are called after all code is installed (1). While you can not count on a specific order, you can assume that all classes and methods from that package are loaded.
As Bert pointed out, if you were not loading but implementing class-side #initialize, you'd have to send the message yourself.
One way to know for sure, is to test it yourself. Smalltalk systems make this kind of thing a little more approachable than many other systems. Just define a your own MyTestClass, and then implement your own class side (that's important) initialize message so that you can discover for yourself when it fires, how often it fires, etc.
initialize
Transcript show: 'i have been INITIALIZED!!! Muwahahahah!!!'
Make sure it works by opening a Transcript and running
MyTestClass initialize
from a Workspace. Now you can play with filing it out and back in, Monticello loading, whatever and when it runs.
In an effort to create a sandbox for CoreGraphics development (which currently consists of performing multiple build and run attempts in order to achieve the desired effect), I was curious if there was a way to dynamically load a class file at runtime.
Much like Java's class-loader ability, I was hoping to use NSBundle or something similar to dynamically load a class into memory.
The idea would be to setup a sandbox project and only have to compile then dynamically reload the class, without having to stop and re-run the host application.
NSBundle can be used to load code dynamically. Have a look at -load.
I don't get why you want to reload such a bundle. (You can through -unload and -load.) It feels wrong, the only code that gets called again is +load and +initialize. You should just need to create a new instance of your class.