What is the output of gnustep-base's configure ?
While I was yesterday looking at config.log, I saw that:
a) _objc_unexpected_exception test passes.
b) All other unexpected exception tests fail.
This is surprising; the tests for the various options are really simple. For
example,
the test
We are not sure yet whether we want to use WebServer as a replacement
for Apache or whether we will try implement an Apache module to merely
pass us the application specific requests.
There is a third alternative, which is using Apache as a reverse proxy in front
of your Objective-C web
With ARC, the runtime needs to be able to find the reference count for the
fast path,
so this becomes part of the interface between the runtime and Foundation, and
so has
to be stable. If we keep the order refcount, zone, isa, then we can't remove
the zone
pointer without breaking the
It would be worth doing a 2.6.1 gnustep-make release with the code in trunk
... which
should fix building with clang. :-)
I think there's no point in waiting more ... it works with GCC (I tried GCC
4.7.0 prerelease)
and it was reported working with clang.
Adam, can you make a release ?
Has the regression with passing the linker flags correctly been fixed?
The code has been changed a month ago, but if nobody reports if it works
or not on their platform, it's hard to know! ;-)
After waiting for a month for feedback, I have to assume that people have
been using trunk and have no
On 30 May 2011, at 22:49, Riccardo Mottola wrote:
Hi,
I just reconfigured base on linux x86-64 and I get this after a clean and new
build:
Making all for subproject Additions...
Linking subproject Additions ...
gcc: @OBJ_MERGE_CMD_FLAG@: No such file or directory
I don't get this
I simply would like to have things in one place. Right now we're
spread between GNA and Savannah.
It sounds like a good idea - I support it.
But, I would recommend that:
* we put up extensive announcements on the web site, mailing list,
etc.
* we try to migrate over the open bugs. I
It would be worth doing a 2.6.1 gnustep-make release with the code in trunk ...
which
should fix building with clang. :-)
We probably need to test the future gnustep-make 2.6.1 using the latest
gnustep-base
release with a few different compilers to be sure that the latest iteration of
the
GCC 4.1 for example does have -mrelax on at least some targets on which
--relax does something, but not everywhere, so the portable version
would seem to be -Wl,--relax.
Yes, that would be solution if we were trying to pass --relax to the linker ;-)
But we need to do something different - we
Here is a nasty patch (against svn HEAD, but it may work for 1.21.1
too) to fix that issue: patch-ObjectiveC2-Makefile.preamble
FWIW, I have just committed this change to GNUstep-make where it
really belongs. Thus other projects that include the Objective-C
runtime headers in plain C
What about changing runtime.c to be runtime.m ?
And do the same for other projects as well (e.g., Jigs :-).
Yes, that would make sense. :-)
I think having this patch in GNUstep-make is better because many
people won't notice that they introduce a portability issue when they
include
If this works, then add -fblocks to CFLAGS and OBJCFLAGS (and maybe CXXFLAGS).
I implemented this in gnustep-make trunk (soon to be 2.6.0).
I do recommend testing.
Thanks
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
I can implement this, but I won't use it myself - is it something
that other people genuinely need or want ? If it helps, I'll do it.
It would help me :-)
I really would like to keep the old GNUstep file system layout and
currently I always have to remember to specify this when
It's probably the wrong way to do it but with the following patch the
icon path is set correctly and the desktop file recognized as such by
Nautilus.
Philippe,
thanks a lot for this patch. Well done, excellent suggestions! :-)
I reworked your code a bit, and applied it to trunk. Let me
Can we please spend the next few days testing base
but not making any changes other than documentation
and any fixes for serious bugs (and perhaps the one
number formatter bug reported by the testsuite).
I'd really like a new base release this month, and
there's not much of it left.
Sounds
I thought at FOSDEM we decided not to do the stable/unstable thing?
Distributions like Debian will only pick up the stable one, which means
that we end up with loads of people complaining that feature X doesn't
work with GNUstep, even though it's been supported for a year in trunk
and six
I started working through my list of TODOs for gnustep-make 2.6.0.
* make 'fhs' the default filesystem layout (so, by default everything is
installed in /usr/local/
using a Unix layout) (with the exception of apple-apple-apple because there
people are using
gnustep-make to compile
If you can provide the configure check, we can add it to gnustep-make's
configure.
Making it general, so that it may one day work with other compilers too, would
be
appreciated.
It should all be fairly easy, but if you provide me with the appropriate
configure check,
I can do the gnustep-make
I am no good at autoconf, but as a simple test, you can try this file:
[...]
Thanks
Did you take a look at the exception test I sent you a mail about?
It seems that the configure script is testing whether exceptions work,
then deciding that, even though they do, it won't let you use them
Support for attributes of Objective-C methods was added in GCC 4.6.0
(not released yet). Older GCCs
do not recognize them and will throw a parse error whenever they
encounter them. :-(
So, it's not just a matter of that specific attribute not being
recognized (that would normally generate
This was a change that accidentally slipped into David's bigger ICU change.
And I could convince David to revert that part. (Not visible in the ChangeLog
as David cannot be bothered by this old fashioned concept)
Just do an SVN update of base and recompile. Then everything should be fine
So, what can we do to make this disruptive behaviour stop ? It's
exasperating.
Having briefly looked at David's latest changes, it's worse than just missing
ChangeLog entries:
* FSF/LGPL copyright headers are missing in new files. I even wonder if the
copyright was
assigned to the FSF
So, what can we do to make this disruptive behaviour stop ? It's
exasperating.
Two options
1) Someone who cares about ChangeLogs can ...
2) Someone who cares about ChangeLogs can ...
It's not about caring about ChangeLogs - it's about coding standards.
If every contributor who
The only issue is with headers that are
removed from the source tree without updating Foundation.h, since the
old header still may be present in the installed location (I don't
know whether gnustep-make prunes the header directories upon make
install. Nicola?)
No, it doesn't prune
On 20 Nov 2010, at 12:44, David Chisnall wrote:
objc_malloc() and friends are GCC-runtime specific. They are not
supported by other runtimes. If there is a reason for avoiding
malloc(), using either NSZoneMalloc() or NSAllocateCollectable()
should be the preferred indirection.
Using
objc_malloc() and friends are GCC-runtime specific. They are not
supported by other runtimes. If there is a reason for avoiding
malloc(), using either NSZoneMalloc() or NSAllocateCollectable()
should be the preferred indirection.
Using malloc() is usually wrong as it can't work with
I'd replace 'usually' with 'sometimes' there. malloc() is
absolutely fine (and should be preferred) as long as it is not used
to store object pointers and it is matched with free() in -
finalize. I'd also add that it CAN be used with object pointers as
long as CFRetain() is called on
Hey,
I can revert the change if needed, sorry if it was premature. I made
the change based on David marking the objc_malloc and related
functions as deprecated in libobjc2
They are not deprecated in the GNU Objective-C runtime.
Thanks
___
It's not about buzzword or any b.s. like that. What it's about is
making it easy for developers who don't have any experience with
GNUstep so that this project can get a much needed boost.
Do I have any evidence that we will get that. No... I don't, but
I'm trying everything I can in order
by learning more about the FHS and GNUstep layout differencies, I
learned that even for the GNUstep layout we create links to the binary
executables of each applications inside the Tools dir. I think this is
dirty and it leaves garbage around. Application should be started using
openapp
but other projects which have attempted to implement Cocoa have used
the names Foundation and AppKit without any problems.
That is not a reason to feel safe.
I agree. And I personally don't like the idea of changing the names
to be identical to the Apple names. We need our own identity.
I like the idea that an application can be moved, around, installed by
untarring it, deleting by trashing it. Like you do in OpenStep or Cocoa.
You can still do that. :-)
The symlinks are only used for things that are installed using 'make install'.
These things are uninstalled using 'make
* if installing into /usr/local/, install GNUstep.conf into
/usr/local/etc/GNUstep/GNUstep.conf
instead of /etc/GNUstep/GNUstep.conf
Why only in this case? We could make it the default on all systems (but
my OpenSuse 11.3 doesn't have this directory by default) or find a
better
Summarizing the discussion, the changes that we want to make to gnustep-make
are:
* make 'fhs' the default filesystem layout (so, by default everything is
installed in /usr/local/
using a Unix layout) (with the exception of apple-apple-apple because there
people are using
gnustep-make
I'd suggest that libobjc2 could include a minimal Object implementation.
Having Object is handy to perform simple configure tests and both the Apple
and GNU runtime include a minimal implementation for that reason ... it would
make sense for libobjc2 to do so too ;-)
Else, if you have a patch to
Actually, this test will fail with Apple's Modern Runtime too - Object no
longer implements +new.
If you define __OBJC2__ (which recent Apple compilers do, you only get these
two methods on Object:
+class;
-(BOOL) isEqual:anObject;
+new is no longer allowed, so there is no defined way
I don't see a conflict between the two. LanguageKit loads
frameworks using NSBundle so that you can distribute a portable .app
bundle with the source code in the bundle and a plist describing the
frameworks that it needs. It loads the frameworks, JIT-compiles the
code, and then runs
I agree with this statement. It's a fact that GNUstep doesn't play
well with the FHS used by, pretty much, every single *nix variant.
FHS is a Linux 'standard', not a *NIX standard. Most *NIX variants
use something vaguely similar, but none use FHS. For example, on
*BSD, GNUstep's
I thought about this last night ...
IMO our default (of course we need to be able to choose other
alternatives easily, but I think you have already make gnustep-make
support that) should be to install things in native locations so
they work with no further effort.
As Truls Becken pointed
not to mention that this is a problem shared by ALL gnu software (on
systems that behave like you describe), and they all have a common
solution, where the gnustep solution is highly gnustep specific.
That is a good point. ;-)
Thanks
___
The public NSBundle API works fine with FHS. Usually things stop working
when you try to locate things manually
on disk instead of using the public API.
The problem seems to be that frameworks are no longer found in the frameworks
directory,
and are no longer bundles, meaning that you
Well, if /usr/local/lib is not in ld.so.conf (it isn't by default on most
Linux distributions), running ldconfig won't help.
Really? I would suggest that distributions which don't have /usr/local/lib
in ld.so.conf do not use/conform to the FHS ...
Eg, Linux RedHat/CentOS does not have
If you configure GNUstep using the FHS layout on *BSD, it puts stuff
in completely the wrong place (it puts GNUstep.conf in the wrong
place with any configuration, unfortunately).
For example ? (ignoring GNUstep.conf which we agree it's wrong on FHS
as well)
Thanks
If you configure GNUstep using the FHS layout on *BSD, it puts
stuff in completely the wrong place (it puts GNUstep.conf in the
wrong place with any configuration, unfortunately).
For example ? (ignoring GNUstep.conf which we agree it's wrong on
FHS as well)
Unless you explicitly set
It's worth noting that the last person we had on the list
with this problem was using Windows. Changing the default
FS layout in -make does absolutely nothing to help Windows
users.
Yes
Most new users who install GNUstep and can't do anything with it
seem to be using Debian/Ubuntu
Maybe the right thing to do is to do something similar to the
/etc/GNUstep/installation-domains.conf. Ie, we could have gnustep-make's
configure load
a new file,
/etc/GNUstep/default-filesystem-layout.conf
but only if it exists (it has to be created manually by an advanced user).
NB. The net result is that temporarily you need to specify --with-
layout=gnustep to get the gnustep layout ... until we can work out
a good mechanism for setting a preference for the layout to use.
Shouldn't gnustep-make reuse the existing layout when there is
already a GNUstep install?
GNU ObjC has so few users that it seems hardly worth the effort to upgrade
the
GNU ObjC front end to ObjC 2.0. And there are other issues:
Translation: The GNU project doesn't care about GNUstep.
The GNU project is a lot of people. One person on the GCC mailing list wasn't
interested in
I'm not condemning GCC for its stance. C and C++ are definitely much more
popular languages than Objective-C,
and I wouldn't blame them if they decided to completely drop Objective-C
support. No one's really worked on it
for around 7 years and the code that they inherited from NeXT is
Not to spark a flame war here, but I've had some serious questions in
my mind as to the GCC project's ability or willingness to help since
the project seems entirely focused on endlessly improving the C, C++
and Fortran front-ends and doesn't work on ObjC at all.
I think GCC has been really
They have entire testsuites that test the languages, and make no changes
that ever break it. It's remarkable how hard they support it given that
none of them uses it. ;-)
I'd like to see when that code was written
Ehm, actually I wrote the original GCC Objective-C testsuite myself. ;-)
Of
greg.casame...@gmail.com
Sent: Monday, 13 September, 2010 21:23
To: Nicola Pero nicola.p...@meta-innovation.com
Cc: David Chisnall thera...@sucs.org, gnustep-dev@gnu.org
Subject: Re: Interesting discussion on gcc about objc
Nicola,
I believe what you're saying here about David's libobjc2 runtime is
just
Nicola,
I believe the fundamental mistake you're making here lays in the claim
that it's derived in the first place
As the person making the assertion that it is, you do, in fact, need
to discuss this with David.
David started with libobjc and made changes. For me that is the definition
Well, according to David, he started its new runtime from scratch.
Quoting http://60gp.ovh.net/~dromasof/etoile/blog/ :
This, and the difficulty in supporting Objective-C 2.0 on the GNU
runtime caused me to write a new one from scratch.
The first subversion logs for libobjc2 states:
Added
The first subversion logs for libobjc2 states:
Added new runtime library, based on GCC 4.4 libobjc, libobjc_tr and
Objective2.framework.
You may also want to look at that revision, r28632, which shows that libobjc2
was initially
the libobjc runtime with a few minor tweaks.
Before you
If you're asking me I would say it's very unfair to make an assertion
regarding someones work, then back out of/refuse to participate in the
discussion which results.
I have nothing more to contribute than what is in the following comments --
The first subversion logs for libobjc2 states:
scripts (eg, /etc/profile) to have
it done automatically each time you login.
---
We could have a similar message for the fhs layout. How does that sound ?
Thanks
-Original Message-
From: Richard Frith-Macdonald r...@gnu.org
Sent: Friday, 10 September, 2010 23:29
To: Nicola Pero nicola.p
I think that patch should be reverted for the time being. Changing the default
choices
has a massive impact because most users never deviate from the default! ;-)
We can have a discussion about the patch, and I actually may be in favour
of making the change to use the native filesystem as
Thanks for this report ... please try again from trunk.
Thanks
On 6 Sep 2010, at 23:32, Riccardo Mottola wrote:
Hi,
when using latest make/base, when I configure make, I get:
checking for the flag to link libobjc... -lobjc
checking whether objc has thread support... yes: -pthread
checking
If I remember correctly, this file was removed by David or Richard.
(Most likely David as I could not find an entry in the ChangeLog file
stating the removal :-)
I thought writing a ChangeLog entry was still standard, required
practice
for the core libraries ... has this changed for
On 13 Aug 2010, at 02:50, asha murthy wrote:
Hi Nicola,
Thank you very much for your kind reply.
defaults write NSGlobalDomain NSLanguages (Language)
The above command works for me from command line!
Now, I would like to use this command from my application *.m file.
Is there any way to do
Can you give us more information on the issues you had ? I updated
the README.MinGW doc a couple of months ago or so. If it stopped
working (because of changes
in MinGW or somewhere else) I'd like to know, so I can update it
again :-)
Sorry for the late reply.
Here are the issues I
Hi,
So you see no legal impediements in proceeding? No patents, no
royalties, no rules in any agreement?
Would you say it is like coming up with a Java implementation 10 -
12 years ago? Did the rules for the Java technology, the JDK,
disallow reverse-engineering? If they did, we are
On 18 Jun 2010, at 16:30, Elim Qiu wrote:
I'm trying to figure out how img, js, css be compiled into
Resources/WebServer dir.
In GNUmakefile, list images etc like
PROJName_WEBSERVER_RESOURCE_FILES = 1.gif 2.png ...
is not practically maintainable for large proj
So I put all images in
On 17 Jun 2010, at 08:53, David Wetzel wrote:
Hi,
my makefile contains this currently and it works, but I am curious
if there is a
variable I could use.
PLATFORM = $(shell uname)
ifeq ($(findstring NetBSD,$(PLATFORM)), NetBSD)
ADDITIONAL_TOOL_LIBS += -lcrypt
endif
Hi David
you should
Look at the webpage source, the path differeces are relatively
addressed
correctly.
If I install the app's WebResources to apache
documentRoot/WebObjects/Appname.gswa/Resources/WebServer/img/...
And use deploy url, the images are displayed fine.
Great - in which case, if it all works, I
Hi David
I finally managed to look into your problem. It looks like a bug in
gnustep-gui to me.
I applied a fix to trunk, please try it out :-)
Thanks
On 4 Jun 2010, at 09:48, David Wetzel wrote:
Hi folks,
I tried this again and again, but it seems like there is a bug in
gui or back.
All,
Since we just did a major release of core
Was there an announcement of the actual release somewhere? I am
only aware about the discussion relating to an *upcoming* release.
I made an announcement on the info-gnustep list. It's also on the
GNUstep wiki.
It may be worth posting
yeah, I agree... originally i had intended to move the whole shebang
to renaissance and the inspectors turned out to be fairly difficult.
mainly because they are in a constrained space, and getting
the autolayout to work in that constrained space and look good
proved very difficult, you'd pretty
Thanks Chris
excellent contribution - we definitely want to support the .pch
extension for precompiled headers! :-)
I have applied to trunk a slight different patch (in attach for your
interest) which is simpler and supports any possible
extension for precompiled headers. In practice, I
Having many commits during a feature freeze is very good as it is
supposed to mean that a lots of bugs are being fixed. :-)
As far as I can tell none of the recent commits in gui or back is
related to any reported bug. [...]
Ok - thanks! - that clarifies the problem then :-)
I'm sure
A very very nice feature fix would be having the instalaltion domain
configuration working on windows like on linux! I bet Gregory
agrees...
I have already fixed it :-)
Thanks
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
Looks like we have more commit right now during code freeze then we
have
at normal times. I would suggest that we give up the idea of doing
more
tests. As long as people cannot stick to a code freeze even for a
week,
I thought we were in feature freeze - ie, all commits must be bug
But it appears to me that the code could be cleaned up and
simplified quite a bit if everyone agrees with my assertion that a
view should only have one (or zero) nextKeyView. To begin with, the
_nextKeyView ivar could be turned into a direct pointer to the next
key view rather than a
On 26 Mar 2010, at 20:55, Fred Kiefer wrote:
Before FOSDEM we were planing a coordinated release of the GNUstep
core
components. In the meantime a lot has happened. Base was completely
rewritten,
Is gnustep-base really ready for a release so shortly after a large
rewrite ?
I assume
Before FOSDEM we were planing a coordinated release of the GNUstep
core
components. In the meantime a lot has happened. Base was completely
rewritten,
Is gnustep-base really ready for a release so shortly after a large
rewrite ?
I assume we're talking of an unstable release ? ;-)
Most
And my final issue is about Install directory because everything is
installed in /GNUstep/Local ...
but I want it to be in /GNUstep/System.
HOW CAN I CHANGE THAT ?
You could use installation-domains.conf but it is currently broken on
Windows. I think I know
how to fix it but need a hour or
So I suppose you wanted to write:
./configure --with-installation-domain=SYSTEM
make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM
make install GNUSTEP_INSTALLATION_DOMAIN=SYSTEM
Yes. Apologies.
Actually I am asking to change default install dir because
this is how it's done with current windows
I think GSoC is probably a good idea, and I guess I could mentor for
it, but I doubt that I'd be very good at mentoring. People have
talked about having to chase students and try to get them to do the
work, and I'm just never able to do that sort of thing effectively.
The potential
We should not sacrifice new features or readability for the sake of
holding on to older architectures and compilers.
Also, the use of non-c99 standards does hinder contributions since we
constantly expect people who don't have access to c99 based compilers
to change their code to conform to
They did not select us last year and we failed to attract suitable
students in the years before that.
Is it possible to learn something from this experience? I mean, if
GNUstep isn't attractive to students it might be not attractive to
non-students as well.
I don't think we failed to
I'm not convinced by the other part of the argument (about
precompiled headers not being much faster),
I think the problem is there is a perception that precompiled headers
are much faster when used. I had that perception
too, until I tried them out :-)
Renaissance uses them, and I just
It's also worth noting that our Cocoa.h is a LOT smaller than
Apple's. The output from gcc -E on a simple .m file that just
contains the line #import Cocoa/Cocoa.h is around 800KB on GNUstep
and over 3MB with Cocoa.
How interesting. :-)
That suggests processing the headers in Cocoa
It has a small effect on how we should organize headers in base too:
I want to clearly separate out non-OSX stuff from OSX stuff, so that
our extensions would all be available to OSX users in the base-
additions library.
I was hoping to just have all the extensions headers collection in
Anyway, given that gnustep-make and recent compilers have supported
precompiled headers for some time now, I think gui/back should
probably simplified to just do
#import Foundation/Foundation.h
(assuming that 'startup' installs base before it builds gui ... so
the installed Foundation.h
Now the new feature is that you can specify headers that live in
subdirectories, as in
Beauty_HEADER_FILES = Beauty.h Vanity.h Pride/Pride.h
(note the last one, Pride/Pride.h) then your headers would be in
Beauty/Beauty.h
Beauty/Vanity.h
Beauty/Pride/Pride.h
and end up installed as in
I implemented having headers in sub-subdirectories.
For example, consider a framework called Beauty. Let's you have headers
Beauty_HEADER_FILES = Beauty.h Vanity.h
then your headers would be in
Beauty/Beauty.h
Beauty/Vanity.h
and end up installed as in
Also, A ChangeLog is easy to search. When something breaks I grep
in the changelog. Old habits.
Why is:
cat ChangeLog | grep
easier than:
svn log | grep
Because using a ChangeLog doesn't require internet access, and it is
*much* faster. :-)
And for people who get a source tarball,
ChangeLog has less information, in a less useful format, than the
svn logs and is a hold-over from CVS not storing repository-wide
change information sensibly. With svn log, you can get a log of
change messages at any granularity that you like.
I agree there is an overlap, but there are
It would be good to consider exactly how much (if any) information
we want to present in NEWS/ReleaseNotes ... my preference would be
for minimal information there, and a pointer to a generated
ChangeLog for details.
This would require a policy that svn log entries should be suitable
So I guess the solution to that would be instead to require
ChangeLog entries to be committed to svn log.
By the way, presumably we'd still include the author of the change in
the subversion commit message ?
Ie, we write a full ChangeLog entry including the author at the
beginning ?
The
I'd be in favour of ditching NEWS and ChangeLog.
ChangeLog has less information, in a less useful format, than the
svn logs and is a hold-over from CVS not storing repository-wide
change information sensibly. With svn log, you can get a log of
change messages at any granularity that you
On 17 Nov 2009, at 16:49, David Chisnall wrote:
Is there a sensible reason why GNUstep Make adds -lobjc to the end
of the linker flags for tools and apps (which already link against -
base, which links against libobjc)? In a number of projects I'm
experiencing problems with this because
Additionally I really dislike the coding style, not because it's not
mine, but because it fails to make the code more readable. On the
other hand, there was code by Fred which looked really ok, so maybe
it's just about using the coding style in a sane way All I
wanted to say is, that it's
By the way the GNU coding standards are not bad, in fact I
personally like
them (mostly because
my eyesight is really bad and whitespace is much more effective at
separating tokens than
brackets or commas). There are some details I'd change, but they
certainly
are not an unusual
or
It would undoubtedly be good to have some packager-specific
documentation, but obviously the target readership is a very small
group
We *do* have packager documentation, in
core/make/README.Packaging
Feel free to add a short section about what was discussed here. :-)
- How
On 8 May 2009, at 18:14, David Chisnall wrote:
Hi,
I'm trying to compile GNUstep projects with clang using 'gmake
CC=clang', but I'm now getting linker errors creating subproject.o
because CC is being used as the linker, even when LD is specified as
something else (e.g. gcc). Is this a
On 7 May 2009, at 15:26, Adam Fedor wrote:
I can make a release of the core libraries in the next day or two if
that's OK. This was my plan:
make 2.0.9
I was thinking of releasing trunk as make 2.2.0 (instead of 2.0.9).
The idea being that 2.0.x does not support parallel building (make
Fail Compile i386-unknown-freebsd7.1 Thu Apr 2 15:35:09 CST 2009
Btw, I had a quick look - this was due to
Compiling file NSObject.m ...
/var/tmp//cc968ivA.s: Assembler messages:
/var/tmp//cc968ivA.s:1437: Error: suffix or operands invalid for `fstcw'
/var/tmp//cc968ivA.s:1446: Error: suffix
On 25 Mar 2009, at 20:37, Gregory Casamento wrote:
I've updated the 1.0 Roadmap here:
http://wiki.gnustep.org/index.php/Roadmap
I'm throwing this out for discussion to find out where everyone
thinks we stand on some of these goals and what should be added/
changed on this.
I support you
1 - 100 of 312 matches
Mail list logo
