Refocus on VS2015 .. continued FYI

Building and customizing Audacity from the source code.

If you require help using Audacity, please post on the forum board relevant to your operating system:
Windows
Mac OS X
GNU/Linux and Unix-like

Re: Refocus on VS2015 .. continued FYI

Permanent link to this post Posted by henric » Sun Apr 17, 2016 6:19 pm

rachalmers wrote:
Ok, great. Now - is this to become part of the main git repository? or will it stay on your branch? Could have saved me hours, days even ... if I"d known about it :-)
At the moment, I'm pulling directly from your git repos, via the VS2015 interface. I originally did a git clone, but now can use it directly - so if you make changes, I should see them directly. nice

Thanks for the heads up. Really appreciated.
Robert


You're welcome.

It seemed responsible to pursue upstream library changes before pushing things further in Audacity (which lead to the aforementioned wall dent). Also, since my goals at the outset were more focused on exploring VS2015's x64 than directly producing pull-request appropriate changes, there is a bit of work to disentangle required changes from unrelated or needless changes (one of the steps I took to identify x64 issues was have the compiler barf on every implicit integer conversion that involved a pointer and then fix them; some of those changes would fix trouble, but some would not). When I brought this stuff up before things got a bit sidetracked (also, Audacity 2.1.2 was pending and wxWidgets did not yet support VS2015).

The changes needed to get 32-bit VS2015 builds working should not be too hard to get into pull-request suitable form. If VS2013 provides stdint.h and inttypes.h, then deleting the local versions would be enough; if not, then moving them might be more appropriate than what the vs2015 branch does.

I've been merging/pushing Audacity master branch changes about once a week, but I'll avoid doing the "git rebase -X ignore-space-at-eol master" thing if others are tracking this. I'll hold off doing so again until travis is happy (I saw the same problem with Visual Studio).
henric
 
Posts: 28
Joined: Sun Jan 17, 2016 9:12 pm
Operating System: Windows 10

Re: Refocus on VS2015 .. continued FYI

Permanent link to this post Posted by rachalmers » Mon Apr 18, 2016 7:47 am

henric wrote:It seemed responsible to pursue upstream library changes before pushing things further in Audacity (which lead to the aforementioned wall dent). Also, since my goals at the outset were more focused on exploring VS2015's x64 than directly producing pull-request appropriate changes, there is a bit of work to disentangle required changes from unrelated or needless changes (one of the steps I took to identify x64 issues was have the compiler barf on every implicit integer conversion that involved a pointer and then fix them; some of those changes would fix trouble, but some would not). When I brought this stuff up before things got a bit sidetracked (also, Audacity 2.1.2 was pending and wxWidgets did not yet support VS2015).

The changes needed to get 32-bit VS2015 builds working should not be too hard to get into pull-request suitable form. If VS2013 provides stdint.h and inttypes.h, then deleting the local versions would be enough; if not, then moving them might be more appropriate than what the vs2015 branch does.

I've been merging/pushing Audacity master branch changes about once a week, but I'll avoid doing the "git rebase -X ignore-space-at-eol master" thing if others are tracking this. I'll hold off doing so again until travis is happy (I saw the same problem with Visual Studio).


It's looking good for 32bit VS2015. That's actually working here. Lots of "Warnings" to wade through - but if you are still making corrections/additions and plan on then merging it with the Audacity Master, then I won't pursue my version here much further. No point in us both doing the same thing and you are way way ahead of me on this. I only started looking at the code a week or so ago.
x64 builds will be nice, and it does that as well, although I initially forgot to build an x64 wxWidgets... Doing a 'git 'pull' on wxWidgets is showing quite a few changes too, which is interesting.
I'm not too sure how that relates to those early Audacity patches of wxWidgets-3.0 as I haven't had a look yet. I commented out the bit of code in Audacity and haven't got back to it. So a build just now for the x64 version shows 0 errors and 17 warnings. For the DLL Debug. For the DLL Release, x64, 0 errors, 18 warnings.

I like your ideas in paragraph 1 above. Good planning. So with 32bit VS2015 pretty much there then it's well on the way. A 64bit release will make a lot of people happy, and that too is as good as working.

Which leaves me to ask, as you merge with the master on a regular basis - I'm wondering if I should leave this VS2015 version alone for now, as you are obviously well ahead on it, and go back to working on the OSX 10.11.4/10.11SDK version, where I started .. hmmm. Although I'll still keep digging away at all those "warnings" that show up, but again at the risk of them being fixed in part by changes in the master anyway.

... and for what it's worth just now, a x64 build of Audacity Debug shows 0 errors, and 837 warnings :-)
and Audacity x64 runs - apparently - fine. Although I haven't done any testing at all on it ... but it runs. Nice one.

interesting stuff
Robert
rachalmers
 
Posts: 163
Joined: Wed Jan 06, 2016 10:53 am
Operating System: OS X 10.11 El Capitan or later (macOS)

Re: Refocus on VS2015 .. continued FYI

Permanent link to this post Posted by rachalmers » Tue Apr 19, 2016 7:07 am

Out of interest, yesterdays update/merge of henricj's repo to the Master, doesn't yet compile cleanly on VC2015. It's almost there. There are 101 Errors - every single one Error C1189, and found in 4 components. libnyquist, nibnyquist, libsndfile, lv2 and the last error a LINK error in Audacity because it can't find the others.
There are 769 Warnings. Some related to C1189, most not.
The details of compiling with VS2015 are to be found on henricj's github site.
But then I guess you all know this.
Robert
rachalmers
 
Posts: 163
Joined: Wed Jan 06, 2016 10:53 am
Operating System: OS X 10.11 El Capitan or later (macOS)

Re: Refocus on VS2015 .. continued FYI

Permanent link to this post Posted by henric » Tue Apr 19, 2016 8:17 pm

rachalmers wrote:Out of interest, yesterdays update/merge of henricj's repo to the Master, doesn't yet compile cleanly on VC2015. It's almost there. There are 101 Errors - every single one Error C1189, and found in 4 components. libnyquist, nibnyquist, libsndfile, lv2 and the last error a LINK error in Audacity because it can't find the others.
There are 769 Warnings. Some related to C1189, most not.
The details of compiling with VS2015 are to be found on henricj's github site.
But then I guess you all know this.
Robert


Errr... what errors? Are you talking about some of my repo's changes in your tree or my fork being borked (it compiles for me w/ VS2015 Update 2)?

Most of the warnings should be about possible integer truncation issues (e.g., a size_t assigned to an int).
henric
 
Posts: 28
Joined: Sun Jan 17, 2016 9:12 pm
Operating System: Windows 10

Re: Refocus on VS2015 .. continued FYI

Permanent link to this post Posted by henric » Tue Apr 19, 2016 9:14 pm

rachalmers wrote:Which leaves me to ask, as you merge with the master on a regular basis - I'm wondering if I should leave this VS2015 version alone for now, as you are obviously well ahead on it, and go back to working on the OSX 10.11.4/10.11SDK version, where I started .. hmmm. Although I'll still keep digging away at all those "warnings" that show up, but again at the risk of them being fixed in part by changes in the master anyway.


It seems reasonable to distinguish between warnings about things that are already present in the tree that are showing up with VS2015 because the warning defaults have changed (or because the new compiler is more capable of detecting things) and warnings related to what has actually changed. I'm not suggesting that warnings be ignored, but that they be triaged appropriately (the point is to fix the problems that cause the warnings, not to keep the build output short by using a compiler version or configuration that hides them). Well, within reason: mandating gcc with -Wall -Wextra -Wpedantic -Werror on an existing codebase can be used to encourage people to seek alternate employment.

For moving forwards, what will be the earliest supported version of Visual Studio? The way I made the changes in my tree, only VS2015 will work. To support building with both v120 and v140, it seems simplest to have separate v120 and v140 solution and project files. One can do that by hand or use CMake or such. Alternately, wxWidgets includes a file called "wx_config.props" from their .vcxproj files that sets the toolset to the latest version supported by the running Visual Studio:
Code: Select all
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup Label="Configuration">
    <UseOfMfc>false</UseOfMfc>
    <CharacterSet>Unicode</CharacterSet>
   <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
    <PlatformToolset Condition="'$(VisualStudioVersion)' == '10.0'">v100</PlatformToolset>
    <PlatformToolset Condition="'$(VisualStudioVersion)' == '11.0'">v110</PlatformToolset>
    <PlatformToolset Condition="'$(VisualStudioVersion)' == '12.0'">v120</PlatformToolset>
    <PlatformToolset Condition="'$(VisualStudioVersion)' == '14.0'">v140</PlatformToolset>
  </PropertyGroup>
</Project>

This avoids having duplicate project files and having to manually keep them in sync, but folks should probably be comfortable with VS project files that have non-default things in them. I've never had a problem with Visual Studio getting confused by customized project files, but developers can get thrown for a loop if Visual Studio doesn't behave the way they expect (e.g., in the case above, if a developer tries to set the character set or platform toolset in the project configuration UI, they may be in for a surprise).

rachalmers wrote:... and for what it's worth just now, a x64 build of Audacity Debug shows 0 errors, and 837 warnings :-)
and Audacity x64 runs - apparently - fine. Although I haven't done any testing at all on it ... but it runs. Nice one.

interesting stuff
Robert


It would have been much easier had Microsoft's 64-bit API used 64-bit longs like just about everybody else...
henric
 
Posts: 28
Joined: Sun Jan 17, 2016 9:12 pm
Operating System: Windows 10

Re: Refocus on VS2015 .. continued FYI

Permanent link to this post Posted by rachalmers » Wed Apr 20, 2016 8:33 am

I like the wxWidgets idea. vs10, vs11, 12 13 14 etc. Keeps it all together on the front end and makes it easy to manage. Anyone wanting to do a specific compile is going to look at what's needed. Or they should.
For moving forwards, what will be the earliest supported version of Visual Studio? The way I made the changes in my tree, only VS2015 will work. To support building with both v120 and v140, it seems simplest to have separate v120 and v140 solution and project files. One can do that by hand or use CMake or such. Alternately, wxWidgets includes a file called "wx_config.props" from their .vcxproj files that sets the toolset to the latest version supported by the running Visual Studio:


ah yes, the joys of using Microsoft for anything ...
It would have been much easier had Microsoft's 64-bit API used 64-bit longs like just about everybody else...
although Apple of course have their little crazies. As does just about everyone else. Standards are wonderful things. So many to choose from...

but that they be triaged appropriately (the point is to fix the problems that cause the warnings, not to keep the build output short by using a compiler version or configuration that hides them)

Totally agree, which is what I have started to do, but, see point 1. just below.

So interestingly, coming back to what to support in terms of versions used to build. The cleanest solution is probable the wxWidget method. That way, a person wanting to build, is going to have the same options in wxWidgets and Audacity, at the beginning. Simplifying the whole process really. I think anyway.
Of course the end result is a program with two builds ideally. One for x32 bit Windows systems, (rapidly fading from use), and one for x64 systems, now the defacto "standard" - there's those standards again! The END USER, lets not forget them, then has the choice. They don't care how it was built, so long as it runs on their system.
Now I have, myself, two possible directions of progress here.
1. Do I leave the VS2015 tree alone now, and leave it in your very capable hands. There's little point as I see it in me chasing out those Warnings, when your work will probably clear most of them anyway as you refine your own tree. Then any pull on my part will simple overwrite what I have done here. Not to mention the duplication of effort. So I will probably leave it alone now, as it works. Although if you tell me that pursuing the Warnings is not high on your list, I might crack on with it anyway?.
or
2. Do I go back to my first love, OSX, and continue the rather hopeless task of trying to make it all work in the XCode 10.11+10.11SDK - and try and ensure that it's transparent enough - if I get it that far, to transition smoothly to the next releases - coming soon to an Apple store near you.!
At present, it's build-able apparently with previous SDKs, a bit like Windows and earlier VSxxxx versions, but like the VS2015 exercise, I would like to see it come off the command line, nice and easy as it is, and onto the GUI, using the latest tools. I haven't spent a lot of time on it at the moment. The command line build is still failing using the latest SDK but I know about all that. and of course the XCode gui interface build is not even getting started, although it tries valiantly. So I'll probably continue pursuing that course just out of interest. Unless I discover of course, that someone on the actual team is/has doing/done it already.

Robert
rachalmers
 
Posts: 163
Joined: Wed Jan 06, 2016 10:53 am
Operating System: OS X 10.11 El Capitan or later (macOS)

Re: Refocus on VS2015 .. continued FYI

Permanent link to this post Posted by henric » Wed Apr 20, 2016 11:33 pm

rachalmers wrote:I like the wxWidgets idea. vs10, vs11, 12 13 14 etc. Keeps it all together on the front end and makes it easy to manage. Anyone wanting to do a specific compile is going to look at what's needed. Or they should.

The main complication here is testing multiple versions. I have VS2013 and VS2015 readily available. I can probably dig up VS2012 and perhaps even earlier to test with, but at some point one needs to decide what should be supported (and there is a limit to the Visual Studio bloat that will fit on my laptop's SSD). This ties into changes that may require #if _MSC_VER > x or #if _MSC_VER < y treatment as well. One can leave in unsupported cruft and hope that it works, but one also needs to have supported platforms so one knows what must be tested.

rachalmers wrote:
but that they be triaged appropriately (the point is to fix the problems that cause the warnings, not to keep the build output short by using a compiler version or configuration that hides them)

Totally agree, which is what I have started to do, but, see point 1. just below.

So interestingly, coming back to what to support in terms of versions used to build. The cleanest solution is probable the wxWidget method. That way, a person wanting to build, is going to have the same options in wxWidgets and Audacity, at the beginning. Simplifying the whole process really. I think anyway.
Of course the end result is a program with two builds ideally. One for x32 bit Windows systems, (rapidly fading from use), and one for x64 systems, now the defacto "standard" - there's those standards again!

Yes, an auto-configuring .props file is probably is the best way to handle this.

I'm not sure how fast 32-bit Windows is fading. Many of those low-cost 2-in-1 Windows systems are using 32-bit Windows 10; it saves disk space compared to x64 and they typically only have 32GB of storage. Besides, there are still plenty of 32-bit WinXP boxes out there (ouch...).

rachalmers wrote:The END USER, lets not forget them, then has the choice. They don't care how it was built, so long as it runs on their system.
Now I have, myself, two possible directions of progress here.
1. Do I leave the VS2015 tree alone now, and leave it in your very capable hands. There's little point as I see it in me chasing out those Warnings, when your work will probably clear most of them anyway as you refine your own tree. Then any pull on my part will simple overwrite what I have done here. Not to mention the duplication of effort. So I will probably leave it alone now, as it works. Although if you tell me that pursuing the Warnings is not high on your list, I might crack on with it anyway?.

My suggestion would be to support VS2013/v120 and VS2015/v140_xp for development. A 64-bit VS2015/v140 build would be a separate project after integrating 32-bit VS2015 support. Such a proposed audacity_config.props could already include a check for 64-bit builds, but putting all the other required changes into the same pull request would make for one monstrous pull request

I'd suggest breaking things down this way:

  1. Create a minimal pull request to add 32-bit VS2015 support using a .props file. The project files all get modified to include the new .props file and a VS2015 .sln file. stdint.h and inttypes.h need to be dealt with (the best way to do so is TBD). There would also be some #if changes, I think. (Do the portaudio-v19 project changes deserve their own pull request? This would replace the second compile/link batch file with MSBuild conditionals.)
  2. Create pull requests for fixing any new 32-bit VS2015 warnings (i.e., ones not produced by VS2013). Trivial ones would have been dealt with in the previous step.
  3. Create pull requests for resolving VS2015 issues in the code. This includes things like not using "long" to try to store pointers. This is "wrong" on all platforms and various compiler flag can probably be used to create warnings on all the platforms, but should only cause runtime trouble for x64 Windows builds. My preference is to use the standard types, and add compatibility gunk where required (e.g., an "intptr_t" is for storing a pointer in an integer, not some custom "audacity_intptr_t"). This would probably result in a number of pull requests along the lines of "Use intptr_t instead of long" and "Don't try to store size_t in an int", instead of a single massive "Make Windows x64 work".
  4. Create a pull request to add the x64 platform to the VS2015 solution and project files.

That is a bunch of work and while I can certainly start down that path, I'd like to have some "buy in" from the Audacity team that this is the way to go before wasting anyone's time. An official, "these will be the supported versions of Visual Studio," statement would be particularly desirable. Some of the changes in the second step will probably require non-trivial changes to some of the third-party libraries. That carrying such changes in the Audacity tree is worth it for Windows x64 support is not for me to decide (I did feed what I think are the minimal x64 changes to the nyquist maintainer a few weeks ago). Fixing "safe" warnings in the third-party libraries is another policy matter. One can live with such warnings, suppress them on a per-project basis, or fix them and carry the resulting diff while trying to get such changes integrated into the upstream distribution.

Removing compatibility gunk related to old versions of Visual Studio is another point where some guidance would be appreciated. Maintaining existing complex #if/#else trees around for the benefit of unsupported compilers while modifying those structures anyway seems undesirable. I'm not sure how much there is to worry about, but I know there are some. Making sure that VS2013 and VS2015 work is much simpler than adding support for a new MS compiler while trying to make sure that nothing changes for older, unsupported MS compilers. The former would be tested by the relevant compilers; the latter requires the programmer to correctly emulate the old preprocessors in his or her head.

rachalmers wrote:or
2. Do I go back to my first love, OSX, and continue the rather hopeless task of trying to make it all work in the XCode 10.11+10.11SDK - and try and ensure that it's transparent enough - if I get it that far, to transition smoothly to the next releases - coming soon to an Apple store near you.!
At present, it's build-able apparently with previous SDKs, a bit like Windows and earlier VSxxxx versions, but like the VS2015 exercise, I would like to see it come off the command line, nice and easy as it is, and onto the GUI, using the latest tools. I haven't spent a lot of time on it at the moment. The command line build is still failing using the latest SDK but I know about all that. and of course the XCode gui interface build is not even getting started, although it tries valiantly. So I'll probably continue pursuing that course just out of interest. Unless I discover of course, that someone on the actual team is/has doing/done it already.

Robert

I haven't had the "pleasure" of dealing with XCode myself. There have been some rants I've run into about their poor backward compatibility support. Is it really that bad? Most people seem to be complaining that one might accidentally use an API not present on an earlier platform, but it seems it should be pretty simple to examine the resulting binary for weak symbols ("objdump" shows them as "w" symbols, no?).

As for where you should focus your efforts, I would think that the next thing do would be to wait to get some feedback from the Audacity folks. I can add you as a committer to my GitHub fork if you want to take a stab at fixing warnings and such. I don't have a Mac to test on so I have no idea if my fork has broken anything there (I do occasionally test it on Ubuntu).

I think I can create a pull request for the minimal, 32-bit VS2015 support in a day or two along the lines describe above, if that is the direction the Audacity folks would like things to move.
henric
 
Posts: 28
Joined: Sun Jan 17, 2016 9:12 pm
Operating System: Windows 10

Re: Refocus on VS2015 .. continued FYI

Permanent link to this post Posted by rachalmers » Thu Apr 21, 2016 10:17 am

The points you make above, 1, 2, 3 and 4 are very valid. And yes, it's a bunch of work. That's for sure.
I'm beginning to think that the "supported compilers" could well be narrowed down a bit in any case.
As for this (our) focus area, probably reducing the list to VS2013, and VS2015 builds for Windows platforms would work as I think you suggest. That's practically everything working for the VS2013 and prior people - come on guys, upgrade even... - and the newer build dragging their feet into the 21st century with VS2015. Keeping in mind that VS2015 is actually VS2014 ??? Very strange. But I guess if you are going from Windows 8 to windows 10, a Release Number jump is now the new black... Who knows.

So long as a binary can be compiled for each of the (windows) platforms, users will be happy.
Win-32: Windows 98 up to Windows 10
Win-64: Windows 8 and above
I mean there has to be a cut off point somewhere, otherwise programmers are still trying to compile versions for the 6 Windows 98 users left...

and why would one stick with the old compilers when VS2015 Community is free, along with the SDK's etc. Free as. I fail to see the reasoning. Any programmer worth their salt will surely want to update to the latest gear. Maybe that's just me?
Especially considering as VS2015 builds for either 32 or 64.
So it's down to the source code again, to put in the switches.

Now, I had a look this morning. Pulled a fresh copy from your github repo, and build the x64 Debug version. I started at the top of the list of Warnings, and went hunting.
It's painstaking, but not difficult. I started by watching for the platform and inserting _int64 where it may work better. It certainly stops the warnings in those 2 sections.

Example.
Beginning line 36 in id3tag.h, for this one. Removed the first warnings. Using a couple of handy defines in case I need them later. (code from Stackexchange)

Code: Select all
typedef unsigned char id3_byte_t;
// Check windows
#if _WIN32 || _WIN64
#if _WIN64
#define ENVIRONMENT64
typedef __int64 id3_length_t;
#else
#define ENVIRONMENT32
typedef unsigned long id3_length_t;
#endif
#endif

// Check GCC
#if __GNUC__
#if __x86_64__ || __ppc64__
#define ENVIRONMENT64
typedef __int64 id3_length_t;
#else
#define ENVIRONMENT32
typedef unsigned long id3_length_t;
#endif
#endif

//typedef unsigned long id3_length_t;


... and because there are also declarations in the .c files - like as in file.c

Beginning line 213

Code: Select all
 /* check for duplication/overlap */
  {
     // Check windows
#if _WIN32 || _WIN64
#if _WIN64
#define ENVIRONMENT64
     _int64 begin1, end1, begin2, end2;
#else
#define ENVIRONMENT32
     unsigned long begin1, end1, begin2, end2;
#endif
#endif

     // Check GCC
#if __GNUC__
#if __x86_64__ || __ppc64__
#define ENVIRONMENT64
     _int64 begin1, end1, begin2, end2;
#else
#define ENVIRONMENT32
     unsigned long begin1, end1, begin2, end2;
#endif
#endif
    //unsigned long begin1, end1, begin2, end2;


So it looks like working through the .c files may be the big mission for this. I can't see any other way of getting around - globally in a .h file, the problem of declarations in the .c files. Maybe I'm wrong.
anyway, we'll see what happens. I am happy enough at the moment to just potter along here. I may put this all into my own repo, rather than get involved with commits to the master.

Robert
rachalmers
 
Posts: 163
Joined: Wed Jan 06, 2016 10:53 am
Operating System: OS X 10.11 El Capitan or later (macOS)

Re: Refocus on VS2015 .. continued FYI

Permanent link to this post Posted by steve » Thu Apr 21, 2016 3:31 pm

rachalmers wrote:So long as a binary can be compiled for each of the (windows) platforms, users will be happy.

What about Mac OS X and Linux?

rachalmers wrote:I mean there has to be a cut off point somewhere,

The next release will probably be the final release that officially supports Windows XP and Snow Leopard.
9/10 questions are answered in the FREQUENTLY ASKED QUESTIONS (FAQ)
steve
Senior Forum Staff
 
Posts: 43160
Joined: Sat Dec 01, 2007 11:43 am
Operating System: Linux Debian

Re: Refocus on VS2015 .. continued FYI

Permanent link to this post Posted by rachalmers » Thu Apr 21, 2016 4:00 pm

steve wrote:
rachalmers wrote:So long as a binary can be compiled for each of the (windows) platforms, users will be happy.

What about Mac OS X and Linux?

rachalmers wrote:I mean there has to be a cut off point somewhere,

The next release will probably be the final release that officially supports Windows XP and Snow Leopard.



Thanks Steve. Yes, I haven't forgotten OSX and Linux :-) I'm looking at OSX here as well. Just been working along on VS2015 and talking to henricj about it all. He has a good handle on the VS2015 stuff, and it compiles now for x32, and x64, both Debug and Release, on Windows 10. Well probably others as well, but that I don't know.. But, I don't think he is ready to commit it yet until he's talked to you guys. Although he may have done that already - given the time zone differences we are dealing with. Also there are a lot of Warning messages to deal with yet as well - 807 as I look at my monitor now. All of them clashes between various levels of C/C++ and what ever some of it is.

So actual development on OSX is interesting. The command line build although not working with 10.11.4 and 10.11SDK can probably be done. Building it in the XCode IDE/GUI is another matter, but I will keep exploring that option myself, just out of interest. If it can't be done, it'll take me a week or so, if it's absolutely impossible, perhaps then a month...

Nice to hear that XP and Snow Leopard are planning a retirement party -

Robert
rachalmers
 
Posts: 163
Joined: Wed Jan 06, 2016 10:53 am
Operating System: OS X 10.11 El Capitan or later (macOS)

PreviousNext

Return to Compiling Audacity



Who is online

Users browsing this forum: No registered users and 1 guest