I looked up for similar topics on this website and could not really find a solution. The answers were always shallow and confusing for rookie like myself.
I have a task to create a C language program that will display how many processes were running on average in certain amount of time. As you can see, the stopwatch part of a program is piece of cake. The problem is I do not know how to get number of processes running.
The only condition I have is to use system calls to get the number.
While I was searching internet I found following code
struct kinfo kinfo;
int nr_tasks, nr_procs;
getsysinfo(PM_PROC_NR, SI_KINFO, &kinfo);
nr_procs = kinfo.nr_procs;
printf("Number of processes: %d", nr_procs);
When I write this code for example, I get a bunch of errors. As you can see there is plenty of undefined variables and no information about included libaries.
I could not even execute getsysinfo() function becouse I don't know how to include it in my c file.
I have to mention that program itself is working properly (I tested it with simple "hello world").
I would appreciate a little bit detailed advice on this problem since I do not have big knowledge at operative systems.
I maintain an old vb.net project that I didn't make and I was wondering if there's an easy way to determine which parts of the software is still used today by the staff where I work.
I would like to log all function calls without having to edit each one of them if possible.
The project has 27 forms and 6 modules.
Any ideas?
Thanks!
There is no way to 100% determine everything that is used by the system. Vb.Net supports dynamic invocation of methods / properties. Hence you can't even do tricks like delete some code and see if it recompiles. Even if it compiles it could be invoked dynamically.
One way to get a sense of what code is used is to profile the application. Start up the profiler, run the app and go through all of the ways in which the app is used. The resulting profile should give you a good sense of what parts are used. It's very possible though this approach will miss code though
I am using a .dll from Ingeardrivers.com. I realize this question would more appropriately be asked on that site and have posted to there as well but more people on here makes my chances of it getting answered better.
I am a novice programmer and this is my first experience with threading. Basically I have two main loops in my program, and when I run each loop as the 'main thread' by itself - they both work fine individually. The problem is when I am starting two threads and running the main loop inside these threads, at some point in the loop they both are trying to use the Ingear.net dll and when one loop already has created an instance of the class, the second loop just sits on the constructor and doesn't do anything.
Does anyone have any suggestions on how to resolve?
I'd recommend firstly that you check with the vendor to see if the library is thread safe.
But in the mean time you could try creating a single instance of the class and passing it to your two threads/loops as part of the constructor (or setting a property with it).
It'll most likely not work, but you won't know until you try.
The add-on is thread safe -
I was manually disconnecting the controller each time via 'controllername.disconnect()'
For some reason this didn't actually close the connection and I was maxed out on CIP connections. When I removed that, the controller somehow knew to disconnect by itself.
Strange but it works.
I'm working on a project which will entail multiple devices, each with an embedded (ARM) processor, communicating. One development approach which I have found useful in the past with projects that only entailed a single embedded processor was develop the code using Visual Studio, divided into three portions:
Main application code (in unmanaged C/C++ [see note])
I/O-simulating code (C/C++) that runs under Visual Studio
Embedded I/O code (C), which Visual Studio is instructed not to build, runs on the target system. Previously this code was for the PIC; for most future projects I'm migrating to the ARM.
Feeding the embedded compiler/linker the code from parts 1 and 3 yields a hex file that can run on the target system. Running parts 1 and 2 together yields code which can run on the PC, with the benefit of better debugging tools and more precise control over I/O behavior (e.g. I can make the simulation code introduce certain types of random hiccups more easily than I can induce controlled hiccups on real hardware).
Target code is written in C, but the simulation environment uses C++ so as to simulate I/O registers. For example, I have a PortArray data structure; the header file for the embedded compiler includes a line like unsigned char LATA # 0xF89; and my header file for simulation includes #define LATA _IOBIT(f89,1) which in turn invokes a macro that accesses a suitable property of an I/O object, so a statement like LATA |= 4; will read the simulated latch, "or" the read value with 4, and write the new value. To make this work, the target code has to compile under C++ as well as under C, but this mostly isn't a problem. The biggest annoyance is probably with enum types (which behave as integers in C, but have to be coaxed to do so in C++).
Previously, I've used two approaches to making the simulation interactive:
Compile and link a DLL with target-application and simulation code, and have VB code in the same project which interacts with it.
Compile the target-application code and some simulation code to an EXE with instance of Visual Studio, and use a second instance of Visual Studio for the simulation-UI. Have the two programs communicate via TCP, so nearly all "real" I/O logic is in the simulation program. For example, the aforementioned `LATA |= 4;` would send a "read port 0xF89" command to the TCP port, get the response, process the received value, and send a "write port 0xF89" command with the result.
I've found the latter approach to run a tiny bit slower than the former in some cases, but it seems much more convenient for debugging, since I can suspend execution of the unmanaged simulation code while the simulation UI remains responsive. Indeed, for simulating a single target device at a time, I think the latter approach works extremely well. My question is how I should best go about simulating a plurality of target devices (e.g. 16 of them).
The difficulty I have is figuring out how to make each simulated instance get its own set of global variables. If I were to compile to an EXE and run one instance of the EXE for each simulated target device, that would work, but I don't know any practical way to maintain debugger support while doing that. Another approach would be to arrange the target code so that everything would compile as one module joined together via #include. For simulation purposes, everything could then be wrapped into a single C++ class, with global variables turning into class-instance variables. That would be a bit more object-oriented, but I really don't like the idea of forcing all the application code to live in one compiled and linked module.
What would perhaps be ideal would be if the code could load multiple instances of the DLL, each with its own set of global variables. I have no idea how to do that, however, nor do I know how to make things interact with the debugger. I don't think it's really necessary that all simulated target devices actually execute code simultaneously; it would be perfectly acceptable for simulation instances to use cooperative multitasking. If there were some way of finding out what range of memory holds the global variables, it might be possible to have the 'task-switch' method swap out all of the global variables used by the previously-running instance and swap in the contents applicable to the instance being switched in. Although I'd know how to do that in an embedded context, though, I'd have no idea how to do that on the PC.
Edit
My questions would be:
Is there any nicer way to allow simulation logic to be paused and examined in VS2010 debugger, while keeping a responsive UI for the simulator front-end, than running the simulator front end and the simulator logic in separate instances of VS2010, if the simulation logic must be written in C and the simulation front end in managed code? For example, is there a way to tell the debugger that when a breakpoint is hit, some or all other threads should be allowed to keep running while the thread that had hit the breakpoint sits paused?
If the bulk of the simulation logic must be source-code compatible with an embedded system written in C (so that the same source files can be compiled and run for simulation purposes under VS2010, and then compiled by the embedded-systems compiler for use in real hardware), is there any way to have the VS2010 debugger interact with multiple simulated instances of the embedded device? Assume performance is not likely to be an issue, but the number of instances will be large enough that creating a separate project for each instance would be likely be annoying in the absence of any way to automate the process. I can think of three somewhat-workable approaches, but don't know how to make any of them work really nicely. There's also an approach which would be better if it's possible, but I don't know how to make it work.
Wrap all the simulation code within a single C++ class, such that what would be global variables in the target system become class members. I'm leaning toward this approach, but it would seem to require everything to be compiled as a single module, which would annoyingly affect the design of the target system code. Is there any nice way to have code access class instance members as though they were globals, without requiring all functions using such instances to be members of the same module?
Compile a separate DLL for each simulated instance (so that e.g. if I want to run up to 16 instances, I would include 16 DLL's in the project, all sharing the same source files). This could work, but every change to the project configuration would have to be repeated 16 times. Really ugly.
Compile the simulation logic to an EXE, and run an appropriate number of instances of that EXE. This could work, but I don't know of any convenient way to do things like set a breakpoint common to all instances. Is it possible to have multiple running instances of an EXE attached to a single debugger instance?
Load multiple instances of a DLL in such a way that each instance gets its own global variables, while still being accessible in the debugger. This would be nicest if it were possible, but I don't know any way to do so. Is it possible? How? I've never used AppDomains, but my intuition would suggest that might be useful here.
If I use one VS2010 instance for the front-end, and another for the simulation logic, is there any way to arrange things so that starting code in one will automatically launch the code in the other?
I'm not particularly committed to any single simulation approach; while it might be nice to know if there's some way of slightly improving the above, I'd also like to know of any other alternative approaches that could work even better.
I would think that you'd still have to run 16 copies of your main application code, but that your TCP-based I/O simulator could keep a different set of registers/state for each TCP connection that comes in.
Instead of a bunch of global variables, put them into a single structure that encompasses the I/O state of a single device. Either spawn off a new thread for each socket, or just keep a list of active sockets and dedicate a single instance of the state structure for each socket.
the simulators I have seen that handle multiple instances of the instruction set/processor are designed that way. There is a structure usually that contains a complete set of registers, and a new pointer or an array of these structures are used to multiply them into multiple instances of the processor.
I'm fairly new to VB.NET, and I'm working on a text editor with a tabbed interface. I deal with large text files, so I'm wondering what is the best way to go about this.
Should I have each tab / text document open up in a new thread or a process? I basically want the entire application to always run fast as the text editor is just one part of it. If I have several large text files open I don't want the rest of the application slowing down a bit.
If someone can help shed light on this and maybe point me to a URL with any relevant examples, I'd appreciate it!
Should I have each tab / text document open up in a new thread or a process?
No. Definitely not a new process. The amount of Win32 to put everything back together will make you hate yourself.
Not a new thread either. The Winforms UI runs in a single dispatch thread. Trying to touch the UI from different threads will make your program explode.
I would recommend simply using the tried, true, and boring background worker approach. This can be used with threads or just using asynchronous IO (.NET handles the threading for you). Depending upon your use case you may want to just lazy-load parts of files, you can use memory mapped or random access files (e.g. only read in a very small part of the file at a time). In any case the "data" should be separate from the visualization of said data.
(Emphasis added to search terms.)
Whether you have 1 or 10 tabs open, you will only be able to type/edit 1 file at a time, the other tabs will just be taking up memory in the data structure you define, so not sure how there would be an impact on performance.
As a side note, if you are doing a large amount of string manipulation use the stringbuilder class, far quicker and memory efficient.