Hi,
Looking through the latest set of developer docs from Apple, I see a
lot of things that say `Available on OS X 10.x or later.' It
occurred to me that, once these features exist on GNUstep, it might
be beneficial to release a framework that could be included with new
applications to
On 2005-11-17 17:02:41 + Adam Fedor [EMAIL PROTECTED] wrote:
I've always wanted something like that. But I don't know where to put
it
(without duplicating code and dependancies). Maybe a bundle in
gnustep-gui -
so you would have to install gui, but it would not link to the
library.
Hi Everyone,
I now have clang at the point where it can almost build GNUstep
Additions (two l-value cast expressions in GSXML.m don't yet work,
everything else does), however when I do:
./configure CC=ccc
gmake CC=ccc
It does not pass -lobjc to the linker. Adding LDFLAGS += lobjc to the
since it's around 130KB.
David
The files you/we need to look at are core/make/configure.ac and core/
base/configure.ac.
Thanks
-Original Message-
From: David Chisnall [EMAIL PROTECTED]
Sent: Saturday, May 10, 2008 6:56pm
To: gnustep-dev@gnu.org
Subject: Building GNUstep
Hi Everyone
Hi,
It seems that recent GNUstep does not supply the -lpthread flag to the
linker, just -pthread. The semantics of -pthread are really badly
defined - on some platforms it does nothing, on some it sets some
macros, on some it implies -lpthread, on others it does not.
The problem I am
If it helps, I am on FreeBSD, but I have had other users report the
same issue on Ubuntu.
David
On 3 Jun 2008, at 17:23, Richard Frith-Macdonald wrote:
On 2 Jun 2008, at 15:43, David Chisnall wrote:
Hi,
It seems that recent GNUstep does not supply the -lpthread flag to
the linker
Hi,
I'm trying to persuade GNUstep Make to build a project which includes
some C++ files. Apparently the ${TOOLNAME}_CXX_FILES variable is not
recognised, so can someone suggest the correct solution? The only
references I can find say you should set set CC=${CXX} but this is not
a good
On 6 Jun 2008, at 09:05, Fred Kiefer wrote:
Richard Frith-Macdonald wrote:
On 5 Jun 2008, at 20:11, [EMAIL PROTECTED] wrote:
Following on David's email, It's been over a year since we last
branched a stable release. Should we try to do another one soon?
I guess so.
I really wanted to get
Hubert Chathi wrote:
Until the LGPL3/GPL2 issue is resolved, those are the latest
versions that we can have in Debian, or else we'd have to get rid of
Terminal.app (and a few other packages) from Debian.
With regard to the license conflict, would it be acceptable to the FSF
for GNUstep to
Hi,
I have been looking at the NSRunLoop class and its helpers and the
documentation is a little bit spotty in places. There are three cases
I have come across recently:
1) Wanting to handle X11 events in an NSRunLoop
2) Wanting to handle events coming from a file descriptor.
3) Wanting
Native exceptions should have more overhead when they are used, and no
overhead when they are not used (which is why they are also called
'zero cost' exceptions). The other problem is that they break the ABI
- you can't mix setjmp/longjmp and native exceptions in the same
file. This is
On 28 Jun 2008, at 10:56, David Ayers wrote:
Richard Frith-Macdonald schrieb:
Author: rfm
Date: Sat Jun 28 07:13:47 2008
New Revision: 26723
URL: http://svn.gna.org/viewcvs/gnustep?rev=26723view=rev
Log:
Try to ensure that ffi uses executable memory and doesn't segfault
Ahh! Yes, mmap!
On 29 Jun 2008, at 10:38, Richard Frith-Macdonald wrote:
On 29 Jun 2008, at 08:54, David Ayers wrote:
Hello David
David Chisnall schrieb:
I think calling mmap directly is the wrong solution here. You
should be
using valloc() with the requested size rounded up to the nearest
page
I'm
On 30 Jun 2008, at 15:00, Richard Frith-Macdonald wrote:
On 30 Jun 2008, at 12:33, David Chisnall wrote:
My man page for vmalloc states:
The obsolete function valloc() allocates size bytes and
returns a pointer to the allocated memory. The memory address
will be a
multiple
For anyone who hasn't seen this yet, clang now includes a static
analysis tool that does a lot of nice things for Objective-C,
including leak detection and other sanity checks. If you're
interested, check out clang svn and run it. Instructions are here:
Hi,
I'm getting this warning from some of my code:
ERROR: Removing exception handler that is not on top of the stack.
(You probably called return in an NS_DURING block.)
I am not calling return in an NS_DURING block, but I am raising an
exception in one of these blocks (the parser throws
On 12 Jul 2008, at 14:03, Richard Frith-Macdonald wrote:
On 12 Jul 2008, at 13:35, David Chisnall wrote:
Hi,
I'm getting this warning from some of my code:
ERROR: Removing exception handler that is not on top of the stack.
(You probably called return in an NS_DURING block.)
I am
On 31 Jul 2008, at 12:47, Quentin Mathé wrote:
Hi Fred,
Le 30 juil. 08 à 20:51, Fred Morcos a écrit :
Making all for framework EtoileXML...
/usr/GNUstep/System/Library/Headers/AppKit/NSCell.h:500: error:
inline
function '_sizeForBorderType' declared but never defined
I suppose this is
Hi,
I've recently encountered a slightly strange problem with NSLog. It
seems to be doing a lot of initialisation stuff the first time it's
called. When NSLog is called first, simultaneously, from two
threads, one of them gets deadlocked in GSPrivateDefaultLocale(), the
other returns
On 4 Aug 2008, at 10:12, David Ayers wrote:
Am Freitag, den 01.08.2008, 12:06 +0100 schrieb David Chisnall:
It appears that GNUstep is using the ObjC runtime mutex, which tries
to emulate a recursive mutex using a non-recursive mutex. It looked
like there was a potential for deadlock in here
On 4 Aug 2008, at 12:46, David Ayers wrote:
Just to make my position clear. I personally have no issue if libobjc
required a working POSIX threads implementation and the legacy
threading
support is removed from libobjc [in fact it may already have been
deactivated]. But I do believe this
On 4 Aug 2008, at 13:29, David Ayers wrote:
Am Montag, den 04.08.2008, 12:56 +0100 schrieb David Chisnall:
I don't care whether libobjc uses its own threading implementation or
not, however there is no reason for GNUstep to be using an
inefficient and potentially (in this case, definitely
Hi Everyone,
I've done a bit more testing with GNUstep and remote X11 with the X
server running on PowerPC (little endian) and the apps running on x86
(big endian):
With the xlib back end, everything is fine.
With the art back end, almost everything is fine, but pixmaps have
their
Hi,
Since 10.5, OS X has used .xib files, which contain an XML format
which is similar in content to a .nib file. These are then
transformed in to .nib files when the project is compiled. The ibtool
program which performs this conversion can also translate them into
plist format, with
On 21 Nov 2008, at 09:29, Fred Kiefer wrote:
I don' want to make too much fuzz about Etoile people not posting
their
new release on the GNUstep mailing lists.
This one is entirely my fault - I completely forgot. Sorry!
Nor about not waiting for the
next GNUstep gui and base release,
Hi,
NSProcessInfo.m uses some KVM constants that, on FreeBSD, are defined
in headers that are not included. Specifically:
#include sys/sysctl.h
Is required to get NSProcessInfo to build on FreeBSD 7.
David
___
Gnustep-dev mailing list
There is one piece of Objective-C I passionately detest, and that is
that it allows you to trivially call methods with the wrong
(structural) types if you use the same selector name in two unrelated
bits of code.
Unlike Apple, we have the opportunity to do something about this,
since the
On 3 Jan 2009, at 10:02, Richard Frith-Macdonald wrote:
On 3 Jan 2009, at 09:51, Wolfgang Lux wrote:
Fred Kiefer wrote:
I would expect that we always have the menu as the topmost view in
the
window, then the toolbar and last the actual contents view.
Currently
the toolbar increases the
On 6 Jan 2009, at 18:31, Wolfgang Lux wrote:
Why not implement the real Mac OS X behavior, which AFAICT is to show
just the first lines that fit into NSTextField cell's visible frame
and
clip all further lines regardless of whether they are empty or not?
With 10.4, the behaviour was to
On 12 Jan 2009, at 14:30, Fred Kiefer wrote:
The ASSGIN macro is different,
that one is valuable in itself
Has anyone actually run a benchmark on the current ASSIGN() macro? It
contains three conditionals, in the current implementation. The first
one is very rare, and the second two are
On 13 Jan 2009, at 03:14, Adam Fedor wrote:
We had three. One dropped out before the start even, I think due to
family problems.
This one looked very promising at the start, but unfortunately someone
else thought so too and he was offered an internship that looked more
appealing than
Since we're likely to get a compiler that knows about fast enumeration
soon, I thought I'd start implementing the library support it needs.
This patch defines the protocol and implements it for NSEnumerator.
The collection classes will each need this implementing too. I'll do
this in
On 28 Jan 2009, at 12:08, Richard Frith-Macdonald wrote:
and remove the spurious change to NSProcessInfo.m which was also in
the patch.
Ah, I forgot that was in there. It's not entirely spurious - GNUStep-
base doesn't build on FreeBSD without it.
David
On 28 Jan 2009, at 12:08, Richard Frith-Macdonald wrote:
Your patch contains an additional line saying '#include sys/
sysctl.h' which looks like it should not be needed as a few lines
below we have the same include inside an '#ifdef HAVE_SYS_SYSCTL_H'
Did you need to add the include
This patch fixes a bug in the last one (I forgot to set the items
pointer) and adds enumeration support to GSArray and GSMutableArray.
GSArray just returns a pointer to its contents directly.
GSMutableArray has a _version ivar added. This is incremented every
time the collection is
Since my last svn update I got errors complaining that an NSZone-
related symbol was missing (what is the reason for this? Breaking the
ABI is not considered friendly.). As a result I've had to recompile
everything. This wouldn't be a major problem, except that plmerge
keeps crashing.
On 29 Jan 2009, at 08:14, Richard Frith-Macdonald wrote:
Changing the ABI even in svn trunk is sufficiently unusual that I
emailed the mailing list to highlight the issue at the point when
this change was made, but I guess you don't follow the gnustep lists?
I'm on gnustep-discuss and
:14, Richard Frith-Macdonald wrote:
On 29 Jan 2009, at 10:06, David Chisnall wrote:
On 29 Jan 2009, at 08:14, Richard Frith-Macdonald wrote:
Changing the ABI even in svn trunk is sufficiently unusual that I
emailed the mailing list to highlight the issue at the point when
this change
Since upgrading to the latest trunk, I've found redraws over remote
X11 to be a lot faster. The file browser, for example, is now
slightly laggy where previously it was totally unusable.
Unfortunately there are some serious issues.
When resizing a window, the old rectangle is redrawn,
Now I have a compiler that supports fast enumeration on the GNU
runtime (no one else does yet, but I hope to fix that soon) I am able
to actually test the implementation... and it's all wrong.
This diff fixes it. I've tested it with this program:
#import Foundation/Foundation.h
void
On 3 Feb 2009, at 21:12, David Chisnall wrote:
Now I have a compiler that supports fast enumeration on the GNU
runtime (no one else does yet, but I hope to fix that soon)
Much faster than I expected. Clang trunk now supports fast
enumeration with the GNU runtime.
Note that ccc
On 4 Feb 2009, at 18:53, Gregory Casamento wrote:
In some cases on Mac OS X I have observed that exceptions which are
not fatal on Mac sometimes ARE fatal on GNUstep. I believe we
should change the logic which deals with exceptions to add a
continue button and only show the panel when
On 8 Feb 2009, at 06:47, Richard Frith-Macdonald wrote:
Actually, I take it back ... maybe we can recover from an uncaught
exception.
Problem is ... if we are using native exceptions ... by the time the
uncaught handler is called we have unwound the stack entirely and
the program has no
On 22 Feb 2009, at 09:55, Richard Frith-Macdonald wrote:
Obviously that breaks binary compatibility on 64bit systesm, but
perhaps less obviously it also breaks source code compatibility in
quite a few places (wherever the API changes from passing a pointer
to a 32bit integer to now be
On 5 Mar 2009, at 16:10, Gregory Casamento wrote:
The last collective release was only two months ago.
As far as the ABI is concerned that is certainly an issue. The
last time we discussed it we came up with two solutions:
• Pad the ivar-structures in the classes out to give space to
On 7 Mar 2009, at 08:30, Riccardo Mottola wrote:
- I do not want any additional runtime overhead. Performance needs
to be
maximum. Always.
Don't use Objective-C then. The language compromises performance for
flexibility all of the time. How much in GNUstep is CPU-bound? Most
of the
On 22 Feb 2009, at 12:58, Richard Frith-Macdonald wrote:
On 22 Feb 2009, at 12:42, David Chisnall wrote:
It sounds like a good thing to have the option of resuming, even
though it's generally not advisable.
Do you have a patch for gcc/libobjc which would allow that?
It won't require
On 10 Mar 2009, at 10:28, Xavier Glattard wrote:
Riccardo Mottola a écrit :
(...)
David Chisnall wrote:
(...)
Yes, this appears to me the least hurting path. But I laready
dislike.
If we really need, this should be the road.
If you make private ivars into a structure and make a pointer
On 10 Mar 2009, at 14:27, Xavier Glattard wrote:
David Chisnall a écrit :
The extra bytes are allocated after the object, which would be
completely useless. Imagine:
(...)
Now you add another ivar to A and remove the extra bytes, and you
have this layout:
id isa;// offset 0
int
On 11 Mar 2009, at 08:26, Yavor Doganov wrote:
Glib/GTK+ have a stable API/ABI throughout the whole lifetime of the
GNOME 2 platform
It is very easy to have a stable ABI for a procedural API because
there is no notion of subclassing. Even with GObject this is not
really a problem, as it
On 19 Mar 2009, at 13:49, Adam Fedor wrote:
On Mar 18, 2009, at 8:50 PM, Jesse Ross wrote:
On Mar 18, 2009, at 4:15 PM, Eric Wasylishen wrote:
Unfortunately, it looks like GNUstep (and Étoilé) were not
accepted this year :(
http://socghop.appspot.com/program/accepted_orgs/google/gsoc2009
And one more thing...
Under packaging, you have:
• Package name, like GNUstep 1.0 for everything...
Since -base and -gui releases happen at the same time now, it would be
really great to synchronize their release numbers. Every time I'm
troubleshooting GNUstep problems, I end up wading
Elevating privileges is not something that an application should be
able to do, for obvious reasons. The standard way of implementing
this on UNIX systems is to use privilege separation and have a setuid
root program performs the operations that require elevated privilege
on behalf of the
Continuing my adventures in building GNUstep with clang, I'm finding
that the GNUstep log macros all generate warnings like this:
warning: format string is not a string literal (potentially insecure)
Looking at the code, I can see it is correct. There are a few (very
unlikely) corner cases
This patch moves some inner functions in mframe.m into static
functions. Inner functions are a horrible GNU extension, which
requires an executable stack (very bad). No idea why they were used
here, it seems just as a form of scoping since they are not being used
as closures.
David
Hi,
I'm looking at lines 1032--1038 of NSInvocation.m:
struct {
char x[size];
} dummy;
dummy = va_arg(ap, typeof(dummy));
memcpy(datum, dummy.x, size);
This will only work in cases where the arguments are all
Ooops, missed one:
static inline int retframe_int (void *rframe)
{
__builtin_return (rframe);
}
On 30 Mar 2009, at 14:34, David Chisnall wrote:
This patch moves some inner functions in mframe.m into static
functions. Inner functions are a horrible GNU extension, which
requires
On 31 Mar 2009, at 17:13, Richard Frith-Macdonald wrote:
On 30 Mar 2009, at 16:37, David Chisnall wrote:
NSInvocation.m provides default implementations in terms of
__builtin_apply() and friends that are not used when libffi or
ffcall is provided. Is it possible to move
On 1 Apr 2009, at 00:28, David Ayers wrote:
Am Dienstag, den 31.03.2009, 22:13 +0100 schrieb David Chisnall:
On 31 Mar 2009, at 20:00, David Ayers wrote:
If we can implement the argframe approach (ie. -forward::) via
libffi
then we could also resolve some long standing libobjc issues. Yet
On 1 Apr 2009, at 00:56, Pete French wrote:
My platform (FreeBSD/amd64) supports ffcall but not libffi (or
this was the case last time I compiled GNUstep about a month ago)
so please don't drop support :-)
The FreeBSD port for libffi is not marked as broken on amd64. I'd be
very surprised
On 1 Apr 2009, at 06:24, David Ayers wrote:
Indeed I believe this concern has just been addressed:
http://www.gnu.org/licenses/gcc-exception.html
http://gcc.gnu.org/ml/gcc/2009-04/msg5.html
Thanks for the clarification.
As I read it, this means that the exemption only applies to code
Okay, it's official:
I can't read[1].
Having reread that paragraph, I completely agree with your
interpretation, this is exactly the kind of exemption I wanted. Thank
you very much to the FSF. Absolutely perfect (when read with a fully-
awake brain).
Interestingly, this means that you
On 1 Apr 2009, at 01:51, Pete French wrote:
Apple has moved away from GCC so you can no longer depend on them.
This I did not know. Interesting. I assumed Xcode was still using
gcc.
XCode currently ships with gcc and llvm-gcc. Only llvm-gcc is
supported for iPhone developement (if you
On 1 Apr 2009, at 15:10, Pete French wrote:
Clang is a new front-end for LLVM, written completely from scratch,
which is more-or-less feature complete for C99 and Objective-C 2
(parsing anyway - code generation is only finished for the Apple
runtimes), and now working towards C++ support.
Is
Patch to fix this problem is here if you want to apply it to your
local tree:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-April/004759.html
As far as I know, you are the first person to test clang Objective-C
support on a 64-bit platform. Please keep sending me reports of
things that
The error seems to be in NSDecimal handling. I suspect that this
structure is just big enough to be split between registers and the
stack, which may cause problems. Has anyone tested this on Linux/
x86-64? If the test doesn't fail there, then something strange is
going on.
David
On 2
That's weird. I tested the asm in a separate file on i386/FreeBSD,
and it worked correctly, but now the change has been merged it appears
not to for me either. Revert it for now, and I'll take a look at it
when I get back. Alternatively, put the new version in #ifdef
__clang__ and leave
Ooops, this one is my fault.
Recent versions of GCC (and llvm-gcc / clang) support portable atomic
intrinsics. I've checked these on x86 and x86-64, and they generate
the same code that my inline asm uses. If you add this after the
Windows bit (it will probably work on Windows too, but
Hi Everyone,
I'd like to organise a couple of hours at the hackathon, probably on
Thursday afternoon, for giving talks that will be open to people in
the department (or anyone else who wanders in). I don't want to spend
too much of the time doing this, but if we could get four talks, 20
to link another library or convince gcc that this is
really a build in function.
Fred
David Chisnall wrote:
Ooops, this one is my fault.
Recent versions of GCC (and llvm-gcc / clang) support portable atomic
intrinsics. I've checked these on x86 and x86-64, and they
generate the
same code
for Fred.
David
On 3 May 2009, at 02:53, Stefan Bidigaray wrote:
On Sat, May 2, 2009 at 4:10 PM, David Chisnall thera...@sucs.org
wrote:
On i386, you need -march=i586 or higher for this to work. The
existing code will break at runtime, rather than link time, on an
80486 and earlier, and so I
On 3 May 2009, at 17:26, Riccardo Mottola wrote:
David Chisnall wrote:
On i386, you need -march=i586 or higher for this to work. The
existing code will break at runtime, rather than link time, on an
80486 and earlier, and so I assume (from the fact no one has
complained) that no one
On 4 May 2009, at 21:07, Fred Kiefer wrote:
And what if we are actually
on a i386? And what should we do when we are on a machine where gcc
does
not provide that new build in? Currently NSIncrementExtraRefCount
works
slowly on such machines, but it works.
Actually, it doesn't. If we are
On 4 May 2009, at 22:12, Fred Kiefer wrote:
Please keep in mind that my i586 is surely able to execute these
instructions, still I get a link error with your latest patch. I think
we agree that the aim is to get it to work out of the box on as much
environments as possible. The i486 assembler
for you - I've not had any
problems with it for a couple of years on FreeBSD, and I was under the
impression GCC supported Linux better than FreeBSD.
David
On 5 May 2009, at 08:46, Fred Kiefer wrote:
David Chisnall wrote:
I think it's important to work out why it is failing on your machine
Hi Everyone,
I'm currently working on adding exception handling support to clang,
but coming across some problems trying to understand the (completely
undocumented) ABI. It isn't quite the same as the NeXT/Apple ABI, so
I am wondering if anyone has any documentation about how it is
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 bug, or a known feature?
David
more thoroughly tested, push it upstream to the GNU runtime.
David
On 12 May 2009, at 06:46, David Ayers wrote:
Am Freitag, den 08.05.2009, 14:04 +0100 schrieb David Chisnall:
Is anyone using @synchronized with GNUstep? If
so, where do you get your implementations of the two functions which
Hi Everyone,
I now have clang correctly implementing all of Objective-C 2 on the
GNU runtime except for:
- Property introspection (properties work, but you can not introspect
them)
- Garbage collection (simple to do, but requires something similar to
Autozone to be available)
-
I forgot to include a little demonstration:
$ cat ivar.m
#import objc/Object.h
#include dlfcn.h
@interface B : Object
- (void)print;
@end
@interface A : B {
@public
int a;
float b;
}
@end
@implementation A
- (void)print
{
printf(a is %d\n, a);
[super
On 17 Mar 2009, at 10:28, Yavor Doganov wrote:
This is probably worth having in the (very) distant future, but has
little to do with the question at hand. My objection was that it's
absolutely useless to bump the soname 1.14 - 1.15 - 1.16 (just an
example) when there are only compatible
On 21 May 2009, at 10:34, Wolfgang Lux wrote:
Have you ever looked at what Apple is doing? I can use executables
compiled on Mac OS X 10.2 on Mac OS X 10.5 without any problems and
Mac OS X does ship with only a single instance of all its libraries/
frameworks
Only half of this is true.
On 3 Jun 2009, at 13:34, Stefan Bidigaray wrote:
I just wrote a really long list of stuff I dislike about having
gnustep_sndd and using OpenAL instead of portaudio, but I decided
not to send that. Really, I think the most compeling reason that I
went with OpenAL is for how simple it is,
On 4 Jun 2009, at 01:19, Stefan Bidigaray wrote:
OK, I've been staring at the structure of NSSound as I have it now
(not like the one in the tar.gz I sent out before) and I think I
need to take a step back and design this a little better. I need
some help! One thing to keep in mind is I
On 5 Jun 2009, at 16:45, Xavier Glattard wrote:
Stefan Bidigaray a écrit :
On Fri, Jun 5, 2009 at 3:29 AM, Xavier Glattard xavier.glatt...@online.fr
mailto:xavier.glatt...@online.fr wrote:
24-bits audio becomes very common.
What i mean is that most (all?) sound cards are now 24-bits /
On 5 Jun 2009, at 16:45, Xavier Glattard wrote:
Did you check portaudio ? (just fall on it) It is damn' small! (44Kio)
Portaudio just about works on Linux. On other platforms it may
occasionally work but is mostly just broken.
David
___
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:
*
FYI: Blocks are a new feature in Objective-C (and C) being introduced
as part of Snow Leopard, roughly equivalent to Smalltalk blocks (but a
bit less flexible).
We have an implementation of a blocks runtime (minus support for GC)
in Étoilé's ObjectiveC2.framework, but now Apple has
On 11 Jun 2009, at 12:25, Pete French wrote:
Very interesting - whait's this 'libgcc replacement' they are
talking about ? wil that include the Obj-C runtime too ? It
would seem odd to put the OPbj-C block code elsewhere from the
rest of the langauge runtime.
libgcc is the support library
On 11 Jun 2009, at 17:16, David Ayers wrote:
Am Donnerstag, den 11.06.2009, 12:36 +0100 schrieb David Chisnall:
Clang definitely needs more testing, but I've been using it recently
to compile some of the Étoilé frameworks and they seem to work
nicely. I've recently been playing with some
In case anyone hasn't seen this, Apple have published a few more
details about Grand Central:
http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090608.pdf
There is no API documentation yet, but it seems that it basically
spawns a set of threads at different priorities
On 14 Jun 2009, at 17:20, Dave MacLachlan wrote:
Sorry for the newbie question, but I want to make sure I get it
right ;-)
I've got a couple of patches that I'd like to submit to gnustep-
base. Google has signed off on having them submitted to the project,
so the legal steps are taken
On 15 Jun 2009, at 09:28, Jamie Ramone wrote:
This block thingy looks interesting. Oh, while we're on the topic of
multi-processors, I've invented an algorithm that allows parallel
lock-less insertions on a linked list. Could be useful for
NSConnections, as it's WAY more efficient than anything
On 29 Jun 2009, at 00:20, Adam Fedor wrote:
I don't get that problem, so it might be something with your
connectivity, or perhaps it is being blocked somehow.
You don't get this error because you have an ssh key registered with
GNA. The links in the svn tree refer to external resources
On 14 Jul 2009, at 23:44, Stefan Bidigaray wrote:
According to the apple docs whenever a sound is created using -
iniWithContentsOfFile:byReference: or a name is set using -setName:
I must be able to later find it using the +soundNamed: method, at
least that's how I understand it. Because
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
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 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
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
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
1 - 100 of 891 matches
Mail list logo
