I noticed in the g-wan User Manual pdf documentation as of 10/19/2012,
http://gwan.ch/download
that it says:
Updating servlets (C, C++, etc.)
When you need to add or update servlets located in the csp directory you can do so without stopping G-WAN (all cached files are updated in real-time).
Yet when I start gwan, it appears to compile everything in the csp directory. That would be down right ugly on a system with 1000's of .c files. Anyway, I tried updating the hello.c file just to see what happens. When I access it again, the changes do not take. I have to restart the server. Also, if I put in a new servlet, like hello2.c, I get "The requested URL was not found on this server." until I restart the server?
what gives?
G-WAN 3.3.28 64-bit (Mar 28 2012 11:24:16) - the latest version I saw in the download as of Oct 19th, 2012
This works for me. I'm running CentOS. The only issue I can find is with header files not updating.
I can't seem to replicate what you're experiencing. What OS are you on?
Gil found the answer. It was permissions. (for the linux newbie like myself) The csp directory must have the same owner/group as how the gwan server is started.
sudo ./gwan -d:www-data:www-data
If started as above, the csp directory must also be www-data as owner and group along with the actual servlet file. In my case it was the hello.c file.
Only applies to the next release which should be soon, version 3.10.x I believe. Search for the tag "g-wan" and you will see other threads where the new version is mentioned.
Related
I recently updated Jetbrains Team City to version 2020.2.2. I use it to build my project whenever I check code into my source repository. I use the TeamCity API to DownloadAll in order to retrieve an Artifacts.zip that contains all the files generated by the build.
The recent update has a bug in it which is corrupting the Artifacts.zip file that is downloaded.
I am now getting an InvalidDataException "A local file header is corrupt." when My program calls System.IO.Compression.ZipFile.ExtractToDirectory() on the Artifacts.zip file.
I am able to right click on this very same file and unzip it using the built in windows "Extract All" and also with 7-Zip extract to folder. No problems with those, but for some reason, my program throws the above exception.
I use the following command on the Team City API to get the file:
https://{myserver}/httpAuth/repository/downloadAll/{myrepository}/{buildId}:id/artifacts.zip
Does anybody know why this would have just started happening on February 1, 2021?
I wrote up a bug on the JetBrains Team City site describing the above problem. They responded this morning with a fix. This appears to have been introduced with TeamCity Enterprise 2020.2.2 (build 85899):
Please add an internal property: (Click blue link to the left for instructions on how)
teamcity.internal.artifacts.useZip64=false
We applied the above property, and the problem was immediately resolved. No reboot of TeamCity was necessary.
Here is a LINK to the bug/solution on the JetBrains TeamCity site.
A couple years ago I wrote a small utility program for my employer, which accessed a Couchbase cluster via the Couchbase C SDK. I've just returned to it to add some new features, installed the Couchbase C SDK on my Ubuntu 20.04 development system via the instructions found here, and tried to compile my code, and it complains that it can't find libcouchbase/n1ql.h. When I checked, sure enough, the file is nowhere to be found on my machine.
I've tried installing all of the packages provided by their repository, none of which seem to provide that file. I've also tried removing them all and installing libcouchbase from source, with no luck (the instructions seem completely out of date); searched it manually but that file isn't in there either. Even grepping for other items that I know have to be in there, like lcb_N1QLHANDLE, doesn't turn up anything.
There's obviously something I'm missing, but I can't even see the shape of it. Have they moved the N1QL code to a separate repository? Gotten rid of it entirely? Renamed it without updating the documentation?
The utility you wrote was probably built using an older version of libcouchbase than what's in the "master" branch on GitHub. If you check out the tag 2.10.7 you can see the n1ql.h header here:
https://github.com/couchbase/libcouchbase/tree/2.10.7/include/libcouchbase
Installation instructions and other documentation for version 2.10 are here:
https://docs.couchbase.com/c-sdk/2.10/start-using-sdk.html
We have a silverlight(5) project, the source in TFS (2010) and Continuous Integration build has been setup and working fine. However, we are now at the stage where we are trying to release it to some users to get them using it and give feedback. I've set up the code so that it checks for updates and if there are any it downloads the latest xap file. However this requires the xap file to be signed. No problem when doing this from our dev machines, but when it comes to the automated build it fails, with the message
Xap packaging failed. Cannot locate the signing tool SignTool.exe.
I've tried numerous things to get the signtool to be recoginised and can't. However, we don't actually need this on the CI build, so I've then tried a second tack which is to make the postbuild event conditional on being run in VisualStudio. Followed various suggestions here on SO but can't gett them to work.
The post build event is
if "$(BuildingInsideVisualStudio)" == "true" (
"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\signtool.exe" sign /f "$(SolutionDir)castle.pfx" "$(TargetDir)Castle.xap"
copy "$(TargetDir)Castle.xap" "$(SolutionDir)Castle.Web\ClientBin"
)
still no joy. Have tried multiple variations of this, but keep getting the same message from the automated build.
So can anyone help with either a) getting the signing tool to be recoginised on the build server or b) getting the automated build to skip the postbuild event?
Found the problem in the end...
I had been putting in place some features so the app would download and install the latest xap file. This requires it to be signed. As this wasn't working I followed some instructions on signing a xap file, not realising that one of the other developers here had put in place the code I described above in the post build event.
I had mistakenly thought that this was created as a result of me checking the 'Sign The Xap File' check box.
So first issue was that other developer had not shared his pfx file with us to add to our certificate stores.
Second, and main issue, was that we then had two attempts at signing going on. The one via the check box and the one via the post build event. I removed the check box and it worked fine.
The issue with the check box is that it expects the SignTool.exe to be in a particular location. On our development boxes with full VS it is where it is looking for it, but on the build server it wasn't. Think it may also have something to do with 64bit machines.
By using only the build event (once you have the correct certificates installed) you can specify explicitly the location that the signtool is going to be, and if necessary install the windows sdk to that location.
This is the top result in Google for this error so updating it with my steps to resolve.
The above didnt work for me but performing the steps below should fix it.
Install the Windows 8.1 SDK on the build server (Windows 2008 R2 for me)
Adding the Windows SDK BIN directory (that contains signtool.exe, on my server) to the Environment PATH variable - e.g. c:\program files (x86)\Windows Kits\8.1\bin - note: Do not add quotes around this
Restart all the Visual Studio Team Foundation services in services.msc after you add the file path to the PATH variable as it needs to reload these before building
When I modify hello.c included with g-wan to include a simple header with #define TEST_VALUE 50 and output it in the hello.c file I noticed that a change to the header file did not trigger an update for g-wan to update the servlet. So if I change the header file test value to 51, no change is noted in the output. If I make any change to the hello.c file, it causes g-wan to recompile the servlet including the dependencies and the change in the header is compiled. Is this the expected behavior? I'm curious because that would mean during development with many dependencies, you would need to update just one character in the main servlet file to trigger a re-compile if all the changes being made are in dependency files.
This behavior was noted by Tim Bolton so I decided to also test it, and pose it as a separate question from a previous thread.
Thanks for any input.
G-WAN 3.3.28 64-bit (Mar 28 2012 11:24:16) - the latest version I saw in the download as of Oct 19th, 2012
... running on Ubuntu Server 10.04.4 LTS - 64 bit
Is this the expected behavior?
Yes.
that would mean during development with many dependencies, you would need to update just one character in the main servlet file to trigger a re-compile if all the changes being made are in dependency files.
No. There's a better way used by programmers for (at least) the past 30 years.
The touch Unix command is updating the time stamp of a file without changing its contents.
Just touch the hello.c servlet when you change its headers.
Also note that C headers are supposed to be more 'stable' than C files. What is stored in headers is there to be shared by many C files so you should consider to use C files for defines that change often.
At least you know how to proceed in both cases now.
I am also having this issue so I created a servlet to help me solve it. Using this I don't need to update every file on my CSP folder. I posted the code on my blog.
Update servlet_dependencies
The script just runs touch command on all files under CSP folder.
I want to provide a URL such as "...mysite.com/my_installer.exe", but I want to be able to make it point to the latest version of my installer.
So if I create version 2 of the installer, the url will download "...my_installer_v2.exe".
I've looked at general URL redirection - 301 redirects, .htaccess etc - but they seem to be geared towards web pages, I'm not clear which, if any, would be appropriate, or if I should be approaching it differently.
If it's relevant, I'm on an apache server, using a PHP based CMS (Textpattern).
Must people have a copy that is "My_Installer_Latest.exe" which is replaced when a new version is released. So just point to that one and replace it when a new version comes.
You have the other versions as well "My_Installer_V2.exe", the only difference is the file that you replace each time a new version is uploaded. Very easy to do and fool proof
It migth be not the answer your looking for but when you write URL they need to have a meaning so the rigth thing to do, in my opinion, is your url should be something like mysite.com/last_version and then you can redirect that last_version to a php page (in your case) that is able to select the rigth download.
I mean I'm assuming you want to do it in a "smart way". You can always just replace the file everytime you update your software.
You could use Apache's mod_rewrite.
If you're using Apache, then perhaps you're also hosted on a unix system, and could simply use symbolic links: ln -fs my_installer_4496.exe my_installer.exe. Every upload, change the symbolic link to point to the new file.
On a unix system, you might start with "...mysite.com/my_installer_v1.exe" as a file and have served a link "...mysite.com/my_installer.exe" pointing to this version 1 file.
So if version 2 enters the stage or maybe a daily/nightly build with a timestamp as version,
you have the link updated on the filesystem and do not have to change the interface code in the CMS (html served to the client).
If there is a need to allow access via the web to older or unstable parallel versions, you can always refer to the real filename as href attribute in the a-element of the html.
In case you need it on the shell issue a command like ln -s my_installer_v1.exe my_installer.exe after having changed into the directory holding the file (the one being served as "...mysite.com/" in your example. The link in the html page would be something like my_installer.exe (latest version).
PS: ln -fs my_installer_v2.exe my_installer.exe would be the (f means force) next update in your scenario.