I'm using P4COM to communicate with our perforce server. I have written an little utility to simplify our QA of what files have changed from one release to another. I have been using the P4COM interface from Delphi. So far so good.
I though it might be nice to allow users to view the diff between the two versions of the file from within my little utility rather than going back to p4v. So I print (get) the files at each revision using p4COM and the following command
print -o "E:\Development\TempProjects\p4Changes\temp\File_dispatch.pas#25" "//depot/mydepotpath/File_dispatch.pas"#25
and
print -o "E:\Development\TempProjects\p4Changes\temp\File_dispatch.pas#26" "//depot/mydepotpath/File_dispatch.pas"#26
However when I do this from my app using P4COM I seem to get random files (and they appear to be deleted ones). If I run the exact same command from the command line I get perfect results. Running both of these does return a file and correctly dumps it to disk where I want it, its just not the file I've asked for.
Any ideas?
Could it be a backslash issue in the command string? This would work fine at the command line, but a single backslash may be being interpreted as an escape code by whatever language compiler you are using (if C or C++, then this will definitely cause a problem, and that maybe happening under the hood on the P4COM side).
Try using double backslashes and see if that fixes it.
You're probably better of asking this to Perforce support itself, as this sounds like a bug in their software.
As a sidenote : Why do you use p4v? (I hugely prefer p4win myself)
Related
Since cocos2d-js is javascript, couldn't one easily extract the source code ?
I don't see this mentioned explicitly anywhere, but since javascript is interpreted, it seems like it would be.
Yes, you can use the command cocos -p web -m release and it makes a version a bit obfuscated (everything in a line) but still anyone can get your code.
There is other tools to obfuscate js but I have not tried them.
Edit: For completeness it is a bit better explained here at the end ->
http://www.cocos2d-x.org/docs/manual/framework/cocos2d-js/2-working-environment-and-workflow/2-2-cross-native-browser-game-with-cocos-console/en
I am configuring Ideaj to open an Erlang REPL by setting it up as and external tool, however the working directory param is ignored. Is there a way once the REPL is open to switch the working directory?
Within the shell use the command cd("some/path") and it will work pretty much the same way you would expect from an ordinary shell.
This means you can move around your project directories and run c(module_name) and be in the local loading path as well -- which can be pretty convenient when hand-tweaking/testing things.
As an aside... most folks don't use an IDE with Erlang, because the shell has so much stuff already built into it, and your OS itself already has whatever other tools you usually want. I've yet to see someone start with an IDE and stick with it in Erlang (usually wind up becoming either Emacs users or go the vim + coreutils route).
Also, pwd() and ls() work as you'd expect.
Regarding IDEs- I find the Erlang Intellij plugin (http://ignatov.github.io/intellij-erlang/) very usable, and when doing more than relatively short one-offs in vim (with Erlang plugin) the code completion and Find Usages kinds of IDE functionality to be useful.
Give it a shot - YMMV.
I have been asked to update a program written in 1987 in Delphi (I guess). I have no documentation about this program only a few side notes the programmer took that don't make too much sense to make.
The cd show this files:
Size | Filename
19956 VP.DTA
142300 VP.LEX
404 VP.NDX
126502 VP.RCS
131016 VP.SCR
150067 VP.XEL
101791 vp.exe
Is anyone of this files a database? If so can I access it's data?
I tried several code decompilers but they show a message saying it was not a Win32 compatible application.
The program run in MS-DOS.
Is it possible to obtain the source code? Can I use this code in any way to build a new application?
Update01: I can run the program in MS-DOS. The program conjugate verbs and shows an example sentence where the verb can be used. The GUI is a little bit confusing and there is no help menu so I can't see all the capabilities of the program.
Update02: In conversation with the owner of the program we found another solution. He ask me if it was possible to have the program in a server and the clients could login in with a user and a password and execute the program in a terminal. I have an account in my university server, which I can access throughout ssh and compile and execute c programs in it. The server is in linux so I couldn't try the program in it. If I set up a windows server, can I have multiple people accessing and executing the program in a terminal? The program is an exe. Doesn't this raise some security issues?
Delphi is from mid nineties, so that probably means Delphi's ancestor Turbo Pascal, not Delphi.
Some extensions sound familiar, as shortened versions of words:
ndx = index
dta = data
scr = screen (?)
lex = lexicon (list of words or deduped strings in general) (?)
Screen was sometimes used for e.g. helpscreens, a medieval form of helpfiles, they are typicall ansi screens that can be loaded directly into screen memory
There is a fair chance that this is something handcrafted, specially if that date of 1987 and the general assumption "pascal" is true, and not generated by some known database package at all.
Reverseengineering the fileformat might be a more worthwhile way than trying to reverseengineering the app.
A good start would to be to take a the unix "file" command to see if it can recognize the file types. (the file command searches for signatures inside files, and there are windows ports. I use Cygwin's)
A devel experienced in such matters can also see a lot from a hexdump (specially the first parts of a file)
Is it possible to obtain the source code?
Probably not, you may want to look at something like IDA Pro which can disassemble applications to C using something like Hex-Rays.
Do you know what the application is supposed to be?
If it's ms-dos, you're probably better off just drawing up new requirements and doing new development.
Look for DeDe to reverse engineering a delphi compiled program. But as far as i know, delphi is a real compiler. So there is no way to de-compiled it. If you are able to read assembler code then you can try de-compile it. Clipper and Foxpro (dos version) are another stories cause they not real compiler.
This is definitely not Delphi. It might be one of the database centric languages like Clipper 1. .SCR probably means "screen" and defines I/O masks. .NDX is a table index and .DTA means "data".
If it is clipper, you might actually be lucky, because as far as I remember these programs were P code, so it could be possible to decompile it.
It looks like CLipper (NDX and SCR). If you have a DBF file then it's Clipper for sure. But some people renamed the DBF to something like DAT. If it is Clipper, I believe there was a decompile named Valkyrie.
This question requires a bit of backstory... At my company, we produce a set of PDF and HTML files. A very large set. The current build process (which I designed, in haste) is a Perl script that reads a set of files, where each file contains a new ant command to execute.
It is designed terribly.
Now, I'm trying to shift the entire project over to using ant for the majority of the tasks. Within a target, I can construct a list of files that need to be built, as either PDF or HTML. However, when I call the ant command to build each file, after about three builds (of, say, five), the entire process crashes with an OutOfMemory error. Furthermore, my buildlog.xml ends up being something like 20 megs--it concatenates every ant command's output into one giant log, since they are being called from a single target. With the earlier Perl solution, I was able to get a buildlog.xml for each ant command--simply save and rename the buildlog to something else.
Even if I set ant or java heap sizes in my user.properties, I still fail with an OOM eventually. I wonder if an appropriate solution is to call <exec> to launch a script that does some of what I described and desire: namely, call ant, rename the buildlog, and die--theoretically allocating and freeing up space better than one "giant" ant call. I am worried that I am going to be heading down another "hacky" solution to a problem that's well-defined, and can be entirely confined to ant. Then again, <exec> does exist for a reason, so should I not feel bad for using it?
As with most corporate software (at least those which have deadlines and, if yours don't, please let me know where you work so I can try get a job there), the first step is to get it working.
Then, worry about getting it working well.
For that first step, you can use any tool at your disposal, no matter how ugly you think it looks.
But you might want to make sure that the powers-that-be know that you've had to do all sorts of kludgy things to get it working for them, so that they allow you to hopefully fix it up before maintenance has to start on it. You probably don't want to be maintaining a hideously ugly code base or design.
We've unleashed such wonders on the world as applications that shut themselves down nightly to avoid memory leaks (leaving the OS to restart them), putting "questionable" code at the other end of a TCP socket so their crashing doesn't bring down the main application and, I'm sure, many other horrors that my brain has decided to remove all trace of.
The title is a bit more specific than my actual goal:
I have a command-line program which uses GNU Readline, primarily for command history (i.e. retrieving previous commands using up-arrow) and some other niceties. Right now the program's output appears interspersed with the user's input, which sometimes is OK but the output is asynchronous (it comes via a network connection in response to the input commands), and that gets annoying sometimes (e.g. if lines are output when the user is typing new input).
I'd like to add a feature to this program: a separate "window" for the output. I thought about using ncurses for this. But it appears from the ncurses FAQ that the two libraries are not easy to use together.
I might consider using Editline or tecla instead of Readline, but it's not clear to me if either of those will solve my problem. I'd also consider using something other than ncurses, including a library which provides both kinds of functionality (text-mode windows and command history), but I don't know what might be best.
Oh, and support for colored text might get bonus points. I suspect I may be able to do that with Readline, so maybe it's a separate concern, but if a solution to my problem also makes it easy to add a bit of color to the output, so much the better.
I'm using Ubuntu Hardy (Linux 2.6).
I've now put together a simple example program on GitHub: https://github.com/ulfalizer/readline-and-ncurses.
It supports seamless and efficient terminal resizing and multibyte/combining/wide characters. The code has helpful comments.
Screenshot below:
I have done some searching, and it seems like you are out of luck.
For ncurses alternatives there are SLang, Newt and Turbo
Vision. Slang is much more than just screen handling and thus more
complex, but maybe it can be used for your purpose?. Newt uses the screen
handling and is much simpler, but too simple and single-threaded-mode
for your purpose I think.
Turbo vision is the text mode graphics library from Borland, used by
all their tools in the late 80s/early 90s. Borland released the source
code when the market for that kind of thing diminished, and there is
now a port for linux (side note, this project seems to have written
its own turbo vision implementation). That port is not dead (there have
been some cvs updates this year which compiled fine (the older releases
did not)), but none of the TV examples I found were up to date and I
did only got a few of them to compile before giving up on the rest.
This is a bit of a shame, because TV was a lovely environment to use.
TV is btw C++ (and I assume you are using C?).
For an alternative to readline, there is libkinput, which maybe works
together with ncurses (it says it can use ncurses' terminfo. but I am
not sure if that means that it can co-exists together with ncurses usage)?
Maybe one option is to run readline "externally" to your ncurses program
using rlwrap?
This had me banging my head for a few hours, so just to save people Googling some pain:
If you're using ncurses' builtin SIGWINCH handler with KEY_RESIZE, be aware that readline sets the LINES and COLUMNS environment variables by default. These override any dynamic size calculation (usually with ioctl() TIOCGWINSZ) that ncurses would otherwise do, meaning you'll keep getting the initial terminal size even after resizing the terminal.
This can be prevented by setting rl_change_environment to 0 before initializing readline.
Update:
Here's some additional information I gleaned from the readline sources:
readline's SIGWINCH handling code (which is used if rl_catch_sigwinch is 1) does update LINES and COLUMNS, which seems like it should be sufficient for ncurses. However, when using the alternate readline interface (which makes most sense when combining readline with ncurses), the signal handlers (including the one for SIGWINCH) will only be installed for the duration of each rl_callback_read_char() call, meaning any terminal resize between two calls to rl_callback_read_char() will not be seen by readline.
So it turns out that gdb uses both readline and ncurses. If you're interested in doing this, I recommend that you check out their implementation: http://sourceware.org/git/?p=gdb.git;a=blob;f=gdb/tui/tui-io.c
I've achieved what you've described in a program of mine:
http://dpc.ucore.info/lab:xmppconsole
The following is the file handling io:
http://github.com/dpc/xmppconsole/blob/master/src/io.c
I'm not sure which version you tried. As of today(2012.09.14) It is very simple, We just need to hook our custom function to following function pointers.
rl_getch_function
rl_redisplay_function
rl_completion_display_matches_hook
I did something reasonable here.