Hi all, while i'm hanging out in Cambridge enjoying the business of geese and seagulls i finished the transfer of the online docs for flext and my flext-based externals to http://puredata.info/Members/thomas . The old addresses at http://grrrr.org/ext are redirected. All the accompanying sources are hosted on https://svn.grrrr.org/ext/trunk subpaths as denoted on the externals' pages - this also means that i'm not maintaining the contents on the puredata sf svn any longer.
I also made public three external object libraries that have been on my svn for a longer time:
- clk, which implements some objects for very flexible, syncable,
high-precision clocking objects
- hr, which implements all kinds of basic math operations, both for single
and double precision (the latter using lists of two floats) for messaging and dsp usage.
- zconf, which implements a number of objects for registering, browsing
and resolving network services by use of the zeroconf (aka bonjour) technology.
While there's not much written docs for those objects, the help files on svn should be sufficiently elaborate. Binaries for MacOS (pd and Max) can be found on http://grrrr.org/ext/beta .
have fun, Thomas
hi,
i think pd-dev people should remove externals/grill and like pdmtl / gridflow checkout your svn. it will avoid many questions about flext not being updated and such.
but i can't checkout your svn. i think you need to permit anonymous checkout. pat
I am not really a fan of svn:externals and before we start using them
a lot, we really need to look at the issues. Thomas' system has been
working for years. If it ain't broke, don't fix it :).
.hc
On Aug 23, 2008, at 3:18 PM, patrick wrote:
hi,
i think pd-dev people should remove externals/grill and like pdmtl / gridflow checkout your svn. it will avoid many questions about flext not being updated and such.
but i can't checkout your svn. i think you need to permit anonymous checkout. pat
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
There is no way to peace, peace is the way. -A.J. Muste
Am 27.08.2008 um 01:47 schrieb Hans-Christoph Steiner:
I am not really a fan of svn:externals and before we start using
them a lot, we really need to look at the issues. Thomas' system
has been working for years. If it ain't broke, don't fix it :).
Unfortunately is it broke, since it has only been working for svn and
since my own system has changed a lot the SF repo has not been
updated for months.
I know that this is unfortunate but there's not much that i can do
about it right now.
I'll try if svn:externals would work in my case - there could be an
issue with the SSL certificate as discussed before.
gr~~~
Quoting Thomas Grill gr@grrrr.org:
Am 27.08.2008 um 12:19 schrieb Thomas Grill:
Unfortunately is it broke, since it has only been working for svn
I meant cvs.... it has stopped working with the change to svn
you mean you cannot (semi-automatically) commit to puredata's cvs anymore?
that's true, it is a kind of safety belt, in order to not have to
different repositories that are slowly going out of sync. all
pure-data@sourceforge development should be done in the svn.
fgamsd IOhannes
This message was sent using IMP, the Internet Messaging Program.
Am 27.08.2008 um 17:32 schrieb zmoelnig@iem.at:
Quoting Thomas Grill gr@grrrr.org:
Am 27.08.2008 um 12:19 schrieb Thomas Grill:
Unfortunately is it broke, since it has only been working for svn
I meant cvs.... it has stopped working with the change to svn
you mean you cannot (semi-automatically) commit to puredata's cvs
anymore?
In principle i could transfer the old cvs sync scripts to my new server.
On the other i think you'll agree that it doesn't make much sense when
there's both an updated cvs and an outdated svn externals/grill folder.
Currently it's more consistent (both are outdated) since all new stuff
happens on https://svn.grrrr.org.
gr~~~
Quoting Thomas Grill gr@grrrr.org:
In principle i could transfer the old cvs sync scripts to my new server. On the other i think you'll agree that it doesn't make much sense when there's both an updated cvs and an outdated svn externals/grill folder.
totally.
Currently it's more consistent (both are outdated) since all new stuff
well,but if consisteny between the 2 revision control systems (that
is: the SVN and a (frozen) CVS) would have been the main target of the
switch, this would have effectively killed any new development.
this is a kind of stability i never really bothered with.
happens on https://svn.grrrr.org.
yes, we should find an upgrade procedure for such cases. once again, lacy consensus proves to be not the most effective means....
fgamsdr IOhannes
This message was sent using IMP, the Internet Messaging Program.
On Aug 27, 2008, at 2:04 PM, Thomas Grill wrote:
Am 27.08.2008 um 17:32 schrieb zmoelnig@iem.at:
Quoting Thomas Grill gr@grrrr.org:
Am 27.08.2008 um 12:19 schrieb Thomas Grill:
Unfortunately is it broke, since it has only been working for svn
I meant cvs.... it has stopped working with the change to svn
you mean you cannot (semi-automatically) commit to puredata's cvs
anymore?In principle i could transfer the old cvs sync scripts to my new
server. On the other i think you'll agree that it doesn't make much sense
when there's both an updated cvs and an outdated svn externals/ grill folder. Currently it's more consistent (both are outdated) since all new
stuff happens on https://svn.grrrr.org.
I think it would make more sense to only import release versions of
your code into the pure-data SVN. And IMHO, that would only make
sense if you are going to integrate your code into the common build
system there. If not, then it probably makes more sense for you to
just make your own releases.
.hc
gr~~~
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
kill your television
-
Hans-Christoph Steiner -
patrick -
Thomas Grill -
zmoelnig＠iem.at