Hi Mathieu,
i have been following the latst cvs changes and it seems, you are
again beautifying the codebase.
Please identify the parts that you consider that I'm just
beautifying, apart from the files that don't belong to your part of
devel_0_39.
Actually, you should know what you
Hallo you 2 !
How about a desire branch?
Well, if you don't identify those specific parts that are a problem to
you, and instead just quote the whole 200k digest, there's not much
helping me to comply with your wishes, so I wouldn't have a choice, really.
please - not one more branch !!!
While i don't see what that feature might be in these code excerpts,
except the elimination of an unneeded variable and reformatting, i
normally don't spend my time proof-reading devel_0_39. Anyway, i hope
you know what i mean. Merging in 0.40 could be beneficial for all of
us, and i it
On Wed, 29 Nov 2006, Mathieu Bouchard wrote:
[...]
because they're patching a bug somewhere else in the code, the part
where the variable called newest is assigned the result of a
t_newmethod, _except_ for the builtin selectors.
I'm fixing the problem today.
I fixed the problem; we're back
On Wed, 2006-11-29 at 17:24 +0100, IOhannes m zmölnig wrote:
Tim Blechmann wrote:
On Tue, 2006-11-28 at 12:31 +0100, Thomas Grill wrote:
Hi all,
would it be possible to exclude the autobuild results from this
digest, like e.g. by making a separate mailing for that.
It's has become
On Wed, 29 Nov 2006, Georg Holzmann wrote:
Hallo you 2 !
Mathieu Bouchard wrote:
Well, if you don't identify those specific parts that are a problem to you,
and instead just quote the whole 200k digest, there's not much helping me
to comply with your wishes, so I wouldn't have a choice,
ive found the file src/ChangeLog on the devel_0_39 branch, which contains some
information on ImPd 0.37 through DesireData 0.39.
are the changes from the devel branch documented somewhere? things like the
scheduler, audio interfaces, SIMD/vectorization/memory-alignment, whatever else
may be
On Wed, 29 Nov 2006, Mathieu Bouchard wrote:
Most CVS branches ever made are not meant to be merged back in. (Which CVS
repositories have you used apart from CVS's ?)
typo. should've been:
Most CVS branches ever made are not meant to be merged back in. (Which CVS
repositories have you used
Bugs item #1601850, was opened at 2006-11-23 17:17
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=478070aid=1601850group_id=55736
Please note that this message will contain a full copy of the comment
Hallo!
We already have two devel_0_39, separated not by cvs but by #ifdef and
makefiles. Now it's getting somewhat cumbersome for me, but it seems
that in addition to that, it's getting somewhat cumbersome for the only
person (?) who still works on devel_0_39 outside of DesireData. Well,
First, i would be extremely cautious about making strange assumptions
about other people's problems.
Second, i think the whole case will solve itself shortly, because after
the merge a devel branch will probably not be called devel_0_39 any
more. It may also be a move back to more compatibility
Hi all,
trying to fix loading/saving of non-ASCII characters in pool files.
In the future, text files will still be saved in the native encoding,
but XML will be UTF-8.
Since i'm not very linux-savvy: I guess the default code table used for
PD patchers is the same as being used for the
Hallo!
Mathieu Bouchard schrieb:
[...]
1. I had the delusion that there were more developers working on
devel_0_39, but I hadn't counted. Turned out that it wasn't true.
yes, but when there are more and more branches every developer will have
it's own one and it's much more difficult
wonderful ...
matju/chun on desire, thomas on devel, miller on vanilla, me on pnpd ...
that makes 5 devs for 3 branches and one rewrite ... what a wonderful
waste of resources ...
no please cool down ... one thing, that you people need to realize: open
source software development doesn't work,
On Wed, 29 Nov 2006, Georg Holzmann wrote:
yes, but when there are more and more branches every developer will have
it's own one and it's much more difficult for new one to join (where?)
Right, right, but then, how do we get out of that situation? we can't. So
let's concentrate on things
On Thu, 30 Nov 2006, Tim Blechmann wrote:
matju/chun on desire, thomas on devel, miller on vanilla, me on pnpd ...
that makes 5 devs for 3 branches and one rewrite ...
You forgot to name MAX/MSP.
what a wonderful waste of resources ...
I don't feel guilty.
no please cool down ...
I
Here's Miller's ChangeLog:
http://crca.ucsd.edu/~msp/Pd_documentation/x5.htm#s1
You can also generate ChangeLogs from CVS using this handy script:
http://www.red-bean.com/cvs2cl/
.hc
On Nov 29, 2006, at 1:16 PM, carmen wrote:
ive found the file src/ChangeLog on the devel_0_39 branch, which
locales is the library and tool that handles that stuff, IIRC.
You'll want to look into the env vars LANG, LC_ALL, etc. I think
that's supposed to be system-wide, but with all those grabbag distros
based on the Linux kernel, you never know who implemented what and
how in their bit.
On Wed, 29 Nov 2006, Hans-Christoph Steiner wrote:
A CVS branch is just a tool to manage code. I don't think we need to take it
as any kind of social or political statement. We should use the tools to
reduce friction as much as possible.
You understand this.
_ _ __ ___ _
On Thu, 30 Nov 2006, Thomas Grill wrote:
So far, it was perfectly possible to coexist in the devel branch, at
least for my perception.
What I have in head is also future developments; my decision can seem
hasty and/or hotheaded if only looking at the past.
The last days i was wondering why
On Wed, 29 Nov 2006, Mathieu Bouchard wrote:
On Thu, 30 Nov 2006, Thomas Grill wrote:
The last days i was wondering why suddenly a lot of changes happen in many
parts of the devel branch,
There are many reasons for that, but especially,
Oh, and the feature that started this thread, is the
21 matches
Mail list logo
