Re: [naviserver-devel] scheduler thread getting stuck
On 03-Jun-20 23:41, Andrew Piskorski wrote: Is nsproxy supposed to work correctly on Windows? I had to make extensive changes in the nsproxy code to make it work on Windows. The code is Unix-centric and makes some false assumptions w.r.t. to Windows handles v.s. unix file descriptors and therefore cannot run in Windows - at least not with native MSDN libraries. I didn't push my changes back into the repository yet, since the changes need to possibly be readjusted and retested for Unix. I will ask Zoran to peer-review, adjust and push my changes, however this will not be before next week. Cheers, Ibrahim ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
[naviserver-devel] Code Quality
Hello everybody, First of all, I'd like to thank Gustaf and Andrew who are currently investing a lot of effort into cleaning up the code. Since Gustaf seems to have some time that he is dedicating into our cause right now, an idea struck me, that could bring us and the code up to the next level: I have been monitoring Coverity and their development for years http://www.coverity.com/products/coverity-save/ Even tough they target high end and high profile software and companies, they have been quite supportive of the open community. So I thought we might also ask them to allow us to run Naviserver and Tcl through their static code analysis suite. To be able to do so, someone must invest the time and the effort. Both Zoran and I are up to our necks in work. However, if Gustaf would be willing to do so, given the time he is already investing, that would be great. It might even speed up and simplify the work he is currently doing. @Gustav, what do you think? Cheers, Ibrahim -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] naviserver usage
Congrats. Me proud of us ;) Thanks for the ongoing efforts Gustav, Stephen, Vlad Zoran. -- Ibrahim On 04-Dec-13 14:22, Gustaf Neumann wrote: Dear friends, not sure, where this is coming from, but the growth rate on the naviserver statistics at w3techs [1] looks nice: -g [1]: http://w3techs.com/technologies/details/ws-naviserver/all/all Historical trends in the usage of NaviServer -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] [AOLSERVER] Naviserver Win-64 Sources
Hi everybody,
For those who don't know me, I'm Zoran's partner and am involved
with compiling the Windows version of Tcl and Naviserver at our
company.
As Zoran mentioned in one of his posts, I was reluctant to
release our (my) changes and the VC project files, since those
are quite specific to our development and I haven't in the many
years that I have been involved yet found the time to clean them
up and make them suitable for public use. However, many of my
changes and fixes have been released through Zoran as our
representative in the community.
Just to comment Maurizio's changes related to variable names - I
suppose he has done so due to conflicts with reserved words that
MS VC++ doesn't tolerate.
To mention a couple of other problems that I have discovered over
the years and resolved rather dirtily in my compilation: The
memory and DLL model of compilation must be the same for TCL and
the Naviserver libs and must fit with the Microsoft
redistributable package. This is why I compile everything with
the same model and have made sure (through defines) that all the
packages use the TCL memory allocator. Otherwise different MS
memory allocators get involved and you get all kinds of strange
effects and memory corruptions. Furthermore, the environment
variable handling is affected. If the packages are compiled with
different models, the vars will be visible in one package, but
not in the other.
Another problem is the interchangeable use of Windows Handles and
ANSI file descriptors in the code, which does not work
consistently in Windows. We have made some adaptions here,
especially regarding the nx_proxy package in association with the
remaining nsd code. However, AFAIK, Zoran has not yet had the
time to release this yet.
Lastly, if not compiled through VC, one is not able to use the VC
debugger to debug the code. That is why I have avoided creating
make files, using the existing configure/make files and mingw.
I hope these tips may be valuable to Maurizio (and others). I
have not yet inspected his project files and tried out the
compilation, but I've seen that many have to do with casts to
silence the warning during compilation and some with avoiding
using reserved words.
I hope to find the time in the future to get more involved.
Regards,
Ibrahim
On 16-Oct-12 11:33, Gustaf Neumann wrote:
Dear Maurizio,
First of all, many thanks for your efforts! These are very welcome!
I am as well somewhat surprised, that there are still pieces of
KR style around.
There is really no need to keep these. i'll commit an updated
version of tclxkeylist.c
to mercurial. As for the other changes, i am not really convinced
that changing
all variables named new to mm_new helps to improve the code...
for the other changes, your archive file is the full kitchen
sink, going though
the changes will take a while.
We should move the discussion to the naviserver-devel list
Best regards
-gustaf neumann
On 16.10.12 00:36, Maurizio Martignano wrote:
To facilitate the discussion, I put in here some examples of
the changes I made:
*2.a.*
From
mapPtr = ns_malloc(sizeof(Map));
To
mapPtr = (Map*) ns_malloc(sizeof(Map));
*2.b.*
From
int
TclX_WrongArgs (interp, commandNameObj, string)
Tcl_Interp* interp;
Tcl_Obj* commandNameObj;
char * string;
{
To
int
TclX_WrongArgs (Tcl_Interp* interp, Tcl_Obj* commandNameObj,
char* string)
{
*2.c*
From
if(new) {
To
if(mm_new) {
All these changes have been applied everywhere.
Dear all,
While the tests seem to go rather well but are
not finished yet (and it will take quite some time), I have
decided to make available anyhow the result of my activity.
The sources (and Visual Studio 2012 project files) are
available at:
http://www.spazioit.com/software/naviserver-4.99.4-Win64.zip
There are two categories of changes:
1.The ones required to have the system compiled by Visual
Studio 2012 using as target Windows 64. They are identified by
the #ifdef _WIN64 clause.
2.A set of necessary cosmetics/make up changes to the overall
code base to make it more compliant with nowadays C STDs, and
therefore more “acceptable” to nowadays C compilers, they are:
a.I have made explicit all type conversions (with explicit casts)
b.I have modified all functions defined in KR C STD, changing
them into ANSI C STD
c.I have removed from the code base all reserved words, e.g.:
new, delete, bool …
These changes make the entire codebase less “old-style” and
more maintainable in the future.
Hope it helps,
Maurizio
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
Re: [naviserver-devel] nsproxy module: change comm to sockets instead of pipes?
Hello Everybody, According to Microsoft's documentation: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365141%28v=vs.85%29.aspx Asynchronous (overlapped) read and write operations are not supported by anonymous pipes. This means that you cannot use the ReadFileEx and WriteFileEx functions with anonymous pipes. In addition, the lpOverlapped parameter of ReadFile and WriteFile is ignored when these functions are used with anonymous pipes. That's why Zoran and I ruled out using unnamed pipes. Named pipes don't seem a good alternative either for several reasons, the least of them being the need to create a name on the fly. However, the entire asynchronous IO in Windows is really messy business, since the entire mechanism of processing IO notifications is tied to a window. -- Ibrahim On 28-Jan-12 19:03, Stephen Deasey wrote: On Sat, Jan 28, 2012 at 1:26 PM, Zoran Vasiljevicz...@archiware.com wrote: On Windows there are some limitations as how you can do non-blocking operations... In particular, there seems to be a problem with non-blocking reads/writes on unnamed pipes... They simply do not work on windows, at least as to our knowledge. I don't know anything about Windows, but i t looks like PIPE_NOWAIT switches to non-blocking mode but is a legacy of ye olde lan manager, and instead you should use overlapped IO with the FILE_FLAG_OVERLAPPED flag: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365788%28v=vs.85%29.aspx This is all with named pipes. But it says the followinf about anon pipes: Anonymous pipes are implemented using a named pipe with a unique name. Therefore, you can often pass a handle to an anonymous pipe to a function that requires a handle to a named pipe. So maybe you can substitute a named pipe with the appropriate flags for the anon pipe? -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] drop CVS
FWIW, to let my paranoia out: I don't like SVN because it obscures and packs the whole repository into one big file, which IMHO overshadows all its benifits. I've been able in tha past to resolve the consequences of quite a few CVS bugs, due to the open structure of its repository. OTOH, if we're to continue using the services of SourceForge for the Naviserver project and Vlad, Stephen and Zoran who do most of the work are dissatisfied with CVS... I think at some point, there were contemplations to move the project to some local machines. Vlad was offering to host it, wasn't he? We (Zoran and I) at ARCHIWARE could offer a mirror too. In that case, we can consider going for other source control systems (GIT?) etc. and away from both CVS and SVN. Ibrahim Vasiljevic Zoran wrote: On 06.05.2008, at 01:56, Stephen Deasey wrote: I am too lazy to write that essay. You should try it out to see what you're missing out on. Here's a starter: That _was_ the essay! Thanks for going to such extent to show me what SVN can do. I recall watching a video on YouTube with Linus Thorvalds http://www.youtube.com/watch?v=4XpnKHJAok8 where he takes both CVS and SVN under heavy barrage, advocating for his GIT solution. As we are in the process of considering a repository change, I thought everybody should be at least informed about the other possibilities. Personally, if you guys think we will benefit from such a change, I will be the last one to oppose. It is just that I do not have much time learning something new if it isn't really bringing me immediate benefits (life is short and internet is large). Cheers Zoran - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] Win32 build problems
Hi Jamie, Have you taken a look at the Visual Studio projects (files *.sln, *.dsp, *.dsw). Although we do compile for Windows, I haven't had the time to go through all the build files and variants (especially not the command line Makefiles and stuff). I currently use the VS 2003 .NET and the naviserver.sln project. This works and build fine for us (at least for the parts of the naviserver and libs we employ). Ibrahim Zoran Vasiljevic wrote: Am 13.01.2006 um 09:29 schrieb Jamie Rasmussen: I took a look at the NaviServer HEAD and the Win32 build is broken in several places. Hm... we regulary build NS on Windows... I will pass this to my collegue who is attending this part. Perhaps he didn't checkin the latest updates... Zoran
Re: [naviserver-devel] NS_GNUC_NONNULL on Windows?
Zoran Vasiljevic wrote: Am 30.06.2005 um 00:47 schrieb Stephen Deasey: NS_GNUC_NONNULL is only used in the nscheck.h header because I haven't had time to sprinkle it anywhere else :-) I think it's a pretty useful feature, so I'd like to keep it. Macro varargs are not supported by any Microsoft compiler? No. I checked again. No. Neiter does the manual mention it nor does the latest compiler accept it. If you really can't find another solution, then redefining NS_GNUC_NONNULL to take a single arg should work. It can be called multiple times, one for each non-null function argument. But this is ugly, so prefer to keep the varargs if you can. Ugly or not, this is what we have and must stick to it. But, this would mean if you start to utilize the macro in generic code, you'd have to use it with only one arg, right? There is this old trick - using double parenthesis - to cope with this problem in the code, e.g. #define MYPRINTF(x) printf x MYPRINTF((stderr, %s\n, abc)); Zoran Ibrahim
Re: [naviserver-devel] NS_GNUC_NONNULL on Windows?
Hello everybody, Please excuse my ignorance in the netickette and use of SF and the naviserver project - and please bear with me - I'm still learning. To Zoran's request (motivated by myself): Since NS_GNUC_NONNULL is not used anywhere else but in nscheck.h itself and only with GNUC, it suffices to remove it from the non-GNUC part to make it compilable for Windows. Is it OK with you if I do so? Greetings, Ibrahim Zoran Vasiljevic wrote: Hi frieds, There seems to be a problem with NS_GNUC_NONNULL macro definition when compiling the code on Windows. This is how/where this beast is defined: #if __GNUC_PREREQ(3,3) # define NS_GNUC_NONNULL(...) __attribute__((__nonnull__(__VA_ARGS__))) # define NS_GNUC_WARN_UNUSED_RESULT __attribute__ ((__warn_unused_result__)) # define NS_GNUC_MAYALIAS __attribute__((__may_alias__)) #else # define NS_GNUC_NONNULL(...) # define NS_GNUC_WARN_UNUSED_RESULT # define NS_GNUC_MAYALIAS #endif Unfortunately, the # define NS_GNUC_NONNULL(...) will not be accepted by the Microsoft compilers since it is a varargs macro. They do not support varargs macros. Well. Now, idea is to just scrap the NS_GNUC_NONNULL entirely when compiling with non-gcc compilers. Why? Because this macro is really only used IF gcc, and, as far as I can see it is used only here: #if __GNUC_PREREQ(2,7) # define NS_GNUC_UNUSED __attribute__((__unused__)) # define NS_GNUC_NORETURN __attribute__((__noreturn__)) # define NS_GNUC_PRINTF(m, n) __attribute__((__format__ (__printf__, m, n))) NS_GNUC_NONNULL(m) # define NS_GNUC_SCANF(m, n) __attribute__((__format__ (__scanf__, m, n))) NS_GNUC_NONNULL(m) #else # define NS_GNUC_UNUSED # define NS_GNUC_NORETURN # define NS_GNUC_PRINTF(fmtarg, firstvararg) # define NS_GNUC_SCANF(fmtarg, firstvararg) #endif Are there any objections to remove the NS_GNUC_NONNULL? Are there any better ideas? Cheers Zoran
