David Chisnall schrieb:
On 16 Jul 2009, at 18:34, Riccardo Mottola wrote:
Sorry, I just haven't had a chance to look at installing a
new/different compiler and working with that yet, though it really IS
something I'd like to be playing with.
However, it doesn't really have any bearing on
Hi Fred,
On 18 Jul 2009, at 19:23, Fred Kiefer wrote:
your mail got me thinking, I wont switch to Clang and I don't hope
GNUstep as a project will. So the only option forward is to start
working on better Objective-C support in gcc. I surely wont have time
for this beside my maintainer task on
On Thu, Jul 16, 2009 at 10:37 AM, David Chisnallthera...@sucs.org wrote:
On 16 Jul 2009, at 14:23, Jamie Ramone wrote:
I'd like to chime in here and say that this approach IS actually a
good idea as :
1 ) it does solve the ABI change breakdown problem and
Except that it doesn't, it just
The discussion seems to have settled a little, so I'll go ahead and ask the
question... what approach should I be taking here? I really do not have the
know-how to chime in, and because of that will go with whatever is decided.
What Richard did with NSOperations seems easy enough, is that the
On 28 Jun 2009, at 19:14, Stefan Bidigaray wrote:
As promised, here's the latest code. Feel free to poke as many
holes in it as possible. I'm going to use this, almost completely
unchanged, for NSSound.m. The bundle/plug-in stuff will go in 100%
unchanged.
Sorry that I just haven't
On 16 Jul 2009, at 09:30, Richard Frith-Macdonald wrote:
But ... going back to the issue of avoiding changes to ivars
breaking ABI in future releases ... the approach I currently favor
is having a *single* ivar in the public class. This is a private id
variable referring to an instance of
I'd like to chime in here and say that this approach IS actually a
good idea as :
1 ) it does solve the ABI change breakdown problem and
2 ) it is actually much easier to read because it's a prime example of
encapsulation and abstraction, so complexity is hidden.
The use here of encapsulation
On 16 Jul 2009, at 14:23, Jamie Ramone wrote:
I'd like to chime in here and say that this approach IS actually a
good idea as :
1 ) it does solve the ABI change breakdown problem and
Except that it doesn't, it just hides it. Now people subclassing and
referencing variables in the
On 16 Jul 2009, at 11:24, David Chisnall wrote:
On 16 Jul 2009, at 09:30, Richard Frith-Macdonald wrote:
But ... going back to the issue of avoiding changes to ivars
breaking ABI in future releases ... the approach I currently favor
is having a *single* ivar in the public class. This is
On 16 Jul 2009, at 14:37, David Chisnall wrote:
On 16 Jul 2009, at 14:23, Jamie Ramone wrote:
I'd like to chime in here and say that this approach IS actually a
good idea as :
1 ) it does solve the ABI change breakdown problem and
Except that it doesn't, it just hides it. Now people
Am 16.07.2009 um 12:24 schrieb David Chisnall:
On 16 Jul 2009, at 09:30, Richard Frith-Macdonald wrote:
But ... going back to the issue of avoiding changes to ivars
breaking ABI in future releases ... the approach I currently favor
is having a *single* ivar in the public class. This is a
On 16 Jul 2009, at 14:53, Richard Frith-Macdonald wrote:
On 16 Jul 2009, at 14:37, David Chisnall wrote:
On 16 Jul 2009, at 14:23, Jamie Ramone wrote:
I'd like to chime in here and say that this approach IS actually a
good idea as :
1 ) it does solve the ABI change breakdown problem and
On 16 Jul 2009, at 17:41, Richard Frith-Macdonald wrote:
On 16 Jul 2009, at 14:53, Richard Frith-Macdonald wrote:
On 16 Jul 2009, at 14:37, David Chisnall wrote:
On 16 Jul 2009, at 14:23, Jamie Ramone wrote:
I'd like to chime in here and say that this approach IS actually a
good idea as
On 16 Jul 2009, at 17:26, Lars Sonchocky-Helldorf wrote:
Maybe it's not clear to everybody what benefits your patch
introduces. So maybe it would be a good idea to give a short
enumeration of all the gains to the broader public (I know you're
good at writing technical articles since I read
Hey,
But ... going back to the issue of avoiding changes to ivars breaking
ABI in future releases ... the approach I currently favor is having a
*single* ivar in the public class. This is a private id variable
referring to an instance of a private class which is used to hold the
real
Hi,
At the very least, we should just add an unused pointer for future
expansion so that we can add new ivars later and not use this for
ivars that are likely to remain stable for several releases.
Agreed.
--R
___
Gnustep-dev mailing list
Hi,
Sorry, I just haven't had a chance to look at installing a
new/different compiler and working with that yet, though it really IS
something I'd like to be playing with.
However, it doesn't really have any bearing on this issue because we
have to develop code for the existing compiler
On 16 Jul 2009, at 18:00, David Chisnall wrote:
On 16 Jul 2009, at 17:26, Lars Sonchocky-Helldorf wrote:
Maybe it's not clear to everybody what benefits your patch
introduces. So maybe it would be a good idea to give a short
enumeration of all the gains to the broader public (I know
On 16 Jul 2009, at 18:59, Richard Frith-Macdonald wrote:
One thing I don't understand about the whole issue of adding ivars
is how it is supposed to work with key value coding since, in KVC
you can get/set the value of an ivar by name, but with non-fragile
ivars you can presumably have
On 16 Jul 2009, at 18:34, Riccardo Mottola wrote:
Hi,
Sorry, I just haven't had a chance to look at installing a new/
different compiler and working with that yet, though it really IS
something I'd like to be playing with.
However, it doesn't really have any bearing on this issue
On 30 Jun 2009, at 07:36, Wolfgang Lux wrote:
There is a subtle difference between OS X and GNUstep: As far as I
understand the code, threadInfo-inputFd is not even checked if the
run loop has no event sources and no timer and it is just added
implicitly to the event sources in
On 28 Jun 2009, at 21:46, Wolfgang Lux wrote:
Stefan Bidigaray wrote:
I tried setting waitUntilDone to YES, still no luck! The -
_finished method still doesn't get called when calling -
performSelectorOnMainThread:..., for now I've just made that a -
performSelector:withObject:, which
On Mon, Jun 29, 2009 at 12:59 AM, Richard Frith-Macdonald
rich...@tiptree.demon.co.uk wrote:
Maybe the runloop is not running, or maybe it's running, but not in the
mode that was specified for the method to be performed in?
This would probably explain it! I don't have a run loop on that
I had a look at the code you posted yesterday and I've found two
dubious points in NSSound_test.m:
and here is a third, minor point:
In the -dealloc method of NSSound you check whether self is still an
element of the dictionary nameDict. This is completely unnecessary
since the dictionary
Thanks Wolfgang, this stuff really helps.
On Sat, Jun 27, 2009 at 4:32 PM, Wolfgang Lux wolfgang@gmail.comwrote:
I had a look at the code you posted yesterday and I've found two dubious
points in NSSound_test.m:
First, there is a retain/release error in NSSound's
As promised, here's the latest code. Feel free to poke as many holes in it
as possible. I'm going to use this, almost completely unchanged, for
NSSound.m. The bundle/plug-in stuff will go in 100% unchanged.
To build this, you'll need to go into the bundles/ directory to build and
install the 2
Stefan Bidigaray wrote:
I tried setting waitUntilDone to YES, still no luck! The -
_finished method still doesn't get called when calling -
performSelectorOnMainThread:..., for now I've just made that a -
performSelector:withObject:, which works, but is not what I want
done. I guess my
I know I'm replying a lot to my own posts, but that's just it's me.
Anyway, I've been doing some more testing and the
-performSelectorOnMainThread:withObject:waitUntilDone: call in -_stream is
not really getting executed, as far as I can tell. I moved the
DESTROY(lock) stuff into -_finished: and
Am 27.06.2009 um 18:06 schrieb Stefan Bidigaray:
I know I'm replying a lot to my own posts, but that's just it's me.
Anyway, I've been doing some more testing and the -
performSelectorOnMainThread:withObject:waitUntilDone: call in -
_stream is not really getting executed, as far as I can
In case you guys didn't know, my weekends start of Fridays (4 day a week
work schedule). I actually started testing last night and, to my suprise,
it worked pretty well (I've attached my test tool). It would be really
great to get some input on the code itself. It's missing quite a bit or
On 19 Jun 2009, at 08:05, Fred Kiefer wrote:
Stefan Bidigaray wrote:
It would really help if I attached the file...
I don't understand the general concept here, so just a few detail
comments on the code itself.
Hiding the implementation details in the header is a good thing, but
it
On Fri, Jun 19, 2009 at 2:05 AM, Fred Kiefer fredkie...@gmx.de wrote:
I don't understand the general concept here, so just a few detail
comments on the code itself.
I'll try to explain this the best I can, it might be a little long,
though...
As I explained on my previous e-mails, I'm
On Fri, Jun 19, 2009 at 4:26 AM, Richard Frith-Macdonald
rich...@tiptree.demon.co.uk wrote:
I would go further and ask what the point of the _private array is?
Well, the only reason I could come up with right now is that I didn't want
to have to include GSSoundSink.h and GSSoundSource.h. The
It would really help if I attached the file...
@interface NSSound : NSObject NSCoding, NSCopying
{
NSString *_name;
NSData *_data;
NSString *_playbackDeviceIdentifier; // Currently unused
NSArray *_channelMapping; // Currently unused
BOOL _onlyReference;
id
OK, I started working on the NSSound side of of the reimplementation
(already finished the Source and Sink protocols) today. I'm pretty much
implementing this in the manner I explained in my previous e-mails. I've
attached a text file with some excerpts from NSSound.h and NSSound.m. I'd
like
OK, this is the architecture design I've come up with...
FYI: I deviated slightly from what I was originally thinking. I'm going to
start a thread using NSThread's
-detachNewThreadWithSelector:toTarget:withObject: which will have a while
loop in it that streams the audio data. I figured the
OK, this has been out for almost a week now and I think it's time to start
responding to some of the comments/suggestions brought up.
CHOOSING INPUT/OUTPUT DEVICE
This is a pretty reasonable request, specially since it's part of the API
(check -setPlaybackDeviceIdentifier:), the problem here is
Am 11.06.2009 um 23:13 schrieb Stefan Bidigaray:
CHOOSING INPUT/OUTPUT DEVICE
This is a pretty reasonable request, specially since it's part of
the API (check -setPlaybackDeviceIdentifier:), the problem here is
that I'm not sure what to expect! I don't have a Mac, and the API
only
On 7 Jun 2009, at 02:10, Christopher Armstrong wrote:
Hi Stefan
I don't purport to be an expert on sound APIs, but I've played
around a lot with asynchronous APIs (marshalling in Java with Swing
and multithreaded APIs).
On 07/06/2009, at 2:01 AM, gnustep-dev-requ...@gnu.org wrote:
*
I guess I've been making a lot of noise about this lately, fact is I'm kind
of bored! Anyway, as most of you know, I've put some code out recently and
got quite a bit of feedback. Reading some of the comments I realized I
hadn't thought this through as much as I had initially thought. In this
Hi Stefan
I don't purport to be an expert on sound APIs, but I've played around
a lot with asynchronous APIs (marshalling in Java with Swing and
multithreaded APIs).
On 07/06/2009, at 2:01 AM, gnustep-dev-requ...@gnu.org wrote:
I guess I've been making a lot of noise about this lately,
41 matches
Mail list logo
