I have a question that pertains to scripting. For the sake of clarity I'll just start off with a bit of what I'm trying to do. We have a number of testing environments and projects going on in each environment that trying to keep track of what is where is becoming increasingly difficult.
In order to try and straighten this out I was going to create a script that would pull the comments/description (that is where our developers put the code branch,project name,and date of the build into. This is what we use for versioning) of the dll. Then I would dump this information into a simple table on an html page which would be pulled as a web part.
I was using VBS to perform this and I was able to successfully pull a version number and dump it into an HTML page. However, I have not been able to find any information on how to do this for the comments or description (using Server 2k3 and 2k8) fields.
So my question is if there is a way to pull this information using VBS, or would there be a better scripting language that would allow this to be done.
Thanks very much in advance.
I don't think exactly what you're asking for is possible, however this may be helpful:
http://www.activexperts.com/activmonitor/windowsmanagement/adminscripts/filesfolders/files/
Related
I need to drive a testbench with labview.
The test scenarios are written in a languages that can be automaticaly translated into labview diagrams.
Is this an API that allow to create "labview diagrams" from another software ? or with labview itself ?
I agree that LabVIEW scripting is one approach, but let me throw out another option.
If you are planning to do a one time migration from your test code to LabVIEW than scripting is great, but if you plan to regularly update your test code (because it's easier to use the "test" language than LabVIEW) than it could become quite painful to constantly perform the migration every time your test code has changed.
I've had great success with simply putting my state machine inside of a for loop and then reading in "commands" from a text file that was generated using my "test" language (see pic).
For example, to do an IV sweep my text file might say something like:
SourceV, 5
ReadI
Wait, 1
SourceV, 6
ReadI
This image is greatly simplified - I'm not using a state machine and I don't show how to use "parameters," but I can provide a more comprehensive example if needed. Again, I've had great success doing this with around 30 "commands" controlling multiple instruments and then I generated the text input using VBA or Python.
It's called LabVIEW scripting. You will need to enable an option in the VI Server page in the options dialog to see the relevant features.
A few things to note:
Scripting isn't complicated, but you do need to be aware of how LV code is built.
While scripting is public, it was initially created as an internal tool. There are still corners of it which are incomplete.
Scripting code can be tedious. If you can get away with it, try creating templates of code.
NI has something called CodeGen, which I believe are a series of functions which make some scripting easier, although I never really looked into it.
Where do you store your old classes and files, which you don't longer use in a current project?
I have quite a few classes and files, which are no longer required, but which I would like to keep somewhere in case I need to reuse some of the code later.
Currently, I am just copying and pasting the code in a tool called Code Collector Pro.
However, since this seems not to be the most elegant way of storing old code, I would like to ask you: How do you save your old code?
If you are talking about handy snippets of code that you might use often I store them in Xcode's Code Snippet Library (just drag selected code in to create a snippet.)
Generally though, I delete unused code. If I need it again it will be in my version control system.
I would definitely use a version control system (I'm most familiar with Subversion, but am getting into Git now). If this is code that's worth keeping around then it's code you'll likely use and modify in multiple projects over time. You'll want to be able to review the history of your changes, compare how you used it differently in project A vs. project B, and maintain notes to help refresh your memory and to help in keyword searching when you're trying to find that bit of code you remember using two years ago.
You can set up repositories however makes sense for your work - by project, by code type, etc.
I'm not familiar with Code Collector Pro - if it works as a GUI for a version control system, it may be fine for what you're doing.
Cloud App has this neat feature wherein it automatically uploads new screenshots as they are added to the Desktop. Any ideas how this is done?
You can do similar things yourself without much in the way of programming. In OSX, you can configure "Folder Actions" to run a script, for example, when a new item appears in a folder, including the Desktop. You can then use the script to do whatever you want with the new files.
This article at TUAW includes an example of uploading files to a web server when they hit a particular folder.
So, basically, the answer is "Folder Actions", or "something's keeping an eye on the folder and sending notifications", at some level. Whether Cloud App uses Folder Actions or watches the folder itself at a lower level, using FSEvents/NSWorkspace, or the kqueue mechanisms (for which there's a nice wrapper class called UKKQueue, if I remember correctly -- don't know how current my knowledge is on that one though!) is another matter...
You could implement this at several different levels, depending on the outcome you want, how you want to design whatever it is you're actually doing, and even what kind of filesystem you're targeting. Fundamentally, in Cocoa/Objective C, I think you probably want to start looking at FSEvents.
Once you've got notifications of the file changes, I'd probably use something like ConnectionKit to do the uploading -- any library at all, really, that means you don't have to bother with the sockets level yourself -- but again, there's a lot of different ways.
Depends, really, what level you're looking to solve the problem at, and whether you want to build something for other people or get something working for yourself. If I just wanted to bash something together for myself, I could probably have something cobbled together using Coda's Transmit app, and Folder Actions, or maybe Hazel, and a minimal bit of Applescript, in a half-hour at most, that would do the job well enough for me...
I am not sure what you are asking for exactly. If you are asking for a way to take a screenshot programmatically in MacOSX, I suggest you have a look at the "screencapture" command (in the terminal, type "man screencapture" for doc).
If you want to do it the "hard" way, you should look at this.
About 2 months ago I overtook building proccess in current company. Even though I don't have much knowledge of it, I was the only with enough time, so I didn't have much choice.
Situation is not that good, and I would like to do following:
Labeling files in SourceSafe with version (example ProjectName PV 1.2)
GetFiles from SourceSafe to specific directory
Build vb6/c++/c# projects(yes, there are all kinds of them)
Build InstallShield setups
This is for now partly done using batch scripts(one for labeling and getting, one for building, etc..). So when building start I pretty much have babysit it.
Good part of this code could be reused.
Any recommendations on how to do it better? One big problem is whole bunch of dependencies between projects. Also labeling has to increment version and if necessary change PV to EV.
I would like to minimize user interaction as much as possible. One click on one build script(Spolsky is god) and all is done, no need to increment version, to set where to get files and similar stuff.
Is the batch scripting best way to go? Should I do some functionality with msbuild. Are there any other options?
Specific code is not need, for now I just need a way how to improve it, even though it wouldn't hurt.
Tnx,
Marko
Since you already have a build system (even though some of it currently "manual"), whatever you do, don't start over from scratch.
(1) Make sure you have a test machine (or Virtual Machine) on which to work. Thus you can make changes and improvements without having to worry about breaking anything.
(2) Put all of your build scripts and tools in version control, not just the source code. Then as you make changes, see if they work. If they do, then save them to version control. If they don't, then roll them back.
(3) Choose one area to work on at a time. Don't try to do everything at once. Going from a lot of manual work to "one-click" will take time no matter what build system you're working with.
Sounds like you want a continuous integration solution, like CC.Net. It has configuration options to do all the things you want and a great community to answer questions.
Also, batch scripting is probably not a good option. Sophisticated build and integration tools will let you feed parameters into the build and create different builds for different environments (test, production, etc.). Batch scripting will involve a lot of hand-coding and glue.
The idea is that given a specific input to the program, somehow I want to automatically step-in through the complete program and dump its control flow along with all the data being used like classes and their variables. Is their a straightforward way to do this? Or can this be done by some scripting over gdb or does it require modification in gdb?
Ok the reason for this question is because of an idea regarding a debugging tool. What it does is this. Given two different inputs to a program, one causing an incorrect output and the other a correct one, it will tell what part of the control flow differ for them.
So What I think will be needed is a complete dump of these 2 control flows going into a diff engine. And if the two inputs are following similar control flows then their diff would (in many cases) give a good idea about why the bug exist.
This can be made into a very engaging tool with many features build on top of this.
Tell us a little more about the environment. dtrace, for example, will do a marvelous job of this in Solaris or Leopard. gprof is another possibility.
A bumpo version of this could be done with yes(1), or expect(1).
If you want to get fancy, GDB can be scripted with Python in some versions.
What you are describing sounds a bit like gdb's "tracepoint debugging".
See gdb's internal help "help tracepoint". You can also see a whitepaper
here: http://sourceware.org/gdb/talks/esc-west-1999/
Unfortunately, this functionality is not currently implemented for
native debugging, but I believe that CodeSourcery is doing some work
on it.
Check this out, unlike Coverity, Fenris is free and widly used..
How to print the next N executed lines automatically in GDB?