Thread B on Processor B sees isCreated = 1, but still has a stale
value (nil) for 'theInstance' in its L1/L2 memory cache
and returns the nil.
I can't imagine that this would ever happen - if processors in an SMP
system had independent caches such that they saw
if (0) [super dealloc];
doh! that simple! I didnt try that because I thiught the optimiser
would catch it. tried jumping through all kinds of other hoops.
Better would be a pragma to tell the compiler to suppress the
warning, but the person who added the warning to the compiler didn't
For instance, new versions of gcc added a warning about dealloc
implementations not calling [super dealloc], and I recently went
through the base library hacking in a perverse workaround to prevent
the compiler from issueing that warning. In every single one of the
Out of interest,
For me the GNUstep result is:
2006-02-27 16:52:59.048 affine[14464] Append NSAffineTransform
((1.00, 2.00) (3.00, 4.00) (15.00, 26.00))
2006-02-27 16:52:59.053 affine[14464] Prepend NSAffineTransform
((1.00, 2.00) (3.00, 4.00) (75.00, 106.00))
For me the GNUstep result is:
2006-02-27 16:52:59.048 affine[14464] Append NSAffineTransform
((1.00, 2.00) (3.00, 4.00) (15.00, 26.00))
2006-02-27 16:52:59.053 affine[14464] Prepend NSAffineTransform
((1.00, 2.00) (3.00, 4.00) (75.00, 106.00))
The real bug does indeed lie in the internal initialization process of the
FreeBSD libpthread library. In this case when libobjc is not excplitly linked
... this is probably the root cause of the issue I am seeing as well.
I'll leave it up to the -make maintainers to decide what to do. My
It is actually unclear to me why -base should try to work with pthreads
directly. I would expect it to strictly work with the objc_thread functions.
I believe the reason why it happens to work most of the time is because objc
is commonly configured to use pthreads.But maybe we need to
or not. Of course, we could behave exactly like MacOS-X and neither convert
nor warn ... just crash.
I know I might get shouted down for this, but some kind of define to enable
this behaviour (and anything else where OSX breaks) would be very useful too.
It helps catch things on GNUstep which
I would hope that a printed warninbg messsage would work as well for that
purpose as a crash ... perhaps not though, people do have a tendency of
ignoring anything which doesn't actually stop things running.
Heh, not me :-) It;s gotta compile -Wall and run silent or
else theres trouble...A
With xlib backend I've got this log message and nothing is displayed:
Bizzare number of bits per sample 16.
mea culpa. I wrote that error message - the code which habdles those
images doesnt deal with more than 8 bits per sample. It inherits
from some very old code I wrote under NextStep 3.3,
GSContext.m:851: warning: cast to pointer from integer of different size
There are a lot of these issues - I did start going through and trying to
fix a few of them under amd64, but got somewhat stymied by the state of
FreeBSD on amd64. They occur because the platform is one of the few where the
The list is right. BST is not a time zone, it is a mode of time. You said
it yourself, it's GMT+1 for the duration of the year that summer time is
in effect. This needs to be handled separately. When I set my time zone in
windows or OS X, I choose Pacific (GMT -8:00) and there is *ONE*
Here are the lists used on OpenStep and Apple. There is only a minor
difference between them (Apple added UTC and removed HDT).
That list cant be right - it's missing BST (British Summer Time = GMT+1) for
starters. But if I print [NSTimeZone localTimeZone] on the Mac in front of
me then it
That's what I got returned on Mac OS-X and OpenStep by
[NSTimeZone abbreviationDictionary]
Interesting - so it is actually using abbreviations internally that it is
not returning in that dictionary then ? I just tried it and I get
the same as you - yet asking for [[NSTimeZone localTimeZone]
Thanks. I applied it, but limited it to windows. Let me know if that's
Ok.
Should be fine - I dont currently have a windows platform to test though, but
as soon as I get one will do so. I had a lot of trouble egtting Renaissance to
work on Windows and never succeeded - someone else is also
The quick answer to the subject line is ... yes, they work on my apple
laptop (ppc, macosx) and my desktop machine (intel, debian).
Good, that is helpful to know.
Of course, the most likely problem is that there is bug in the 64-bit
support in gstep-guile, gstep-base, or guile,
Ahhh...
by: Pete French
On: Sun 08/29/2004 at 18:25
Category: Base/Foundation
Severity: 5 - Average
Item Group: Change Request
Resolution: None
Privacy: Public
Assigned to: None
Status: Open
Summary: Patch for GSXML under amd64
Original Submission: The attached patch changes the 'type' from an int
by: Pete French
On: Mon 08/23/2004 at 15:34
Category: Base/Foundation
Severity: 5 - Average
Item Group: Bug
Resolution: None
Privacy: Public
Assigned to: None
Status: Open
Summary: Patch for kvm_code on FreeBSD 5 to allow running without /proc
Original Submission: The KVM code used
by: Pete French
On: Wed 05/26/04 at 16:09
Category: Makefiles
Severity: 5 - Average
Item Group: Bug
Resolution: None
Assigned to: None
Status: Open
Summary: Renaissance makefile needs extra libraries to build under Windows
Original Submission: On Windows the final link of the renaissance
I only tested text rotation with Cenon, as I'm not aware of any other
application using rotated text.
I use rotated text a lot - I'll try and find some time to test these
patches (though I hadnt really had any problems with rotated text anyway)
cheers,
-bat.
We are encapsulating GNUstep (as DLL together with its resources) in the .app
folder of our applications on windows at present. So an application is
completely self containing, just doubleclick it and it starts. You can copy
Thats an excellent idea! I hadnt though of that as a way of getting
When is a screen device ever assumed to be 72 dpi? I don't assume that
Next black hardware ? Plus I thought 72 points per inch was the assumed
default resolution for PostScript. e.g. the following file should always
produce a 1inch black square should it not ?
%!PS-Adobe-3.0
0 setgray
72 72
When you have a 15 LCD with 1024 x 768, that makes: 85.3 dpi. If you
...but we arent talking about *real* DPI here are we ? We are (or at least
I am) talking about the assumed DPI which will affect the number of
pixels you get on the screen if you ask for a 100x100 window.
Currently I was
Is this OK? If so, I can update the existing code and implement it in
back-art.
This sounds great.
To those who want to use it, I want to warn that the results of this are
fairly device-dependent. Doing image manipulation this way is not a good
idea. Even just drawing an image to an
When the device is not 72 dpi.
O.K., rephrase the question - when is a screen device ever assumed
to be anything other than 72dpi ? Though I think the bit below answers
that... is this a GNUstep specific problem by the way ? I am sure
that under OpenStep it was stated that the screen was assumed
Thanks ... looked OK and seemed to work (not break my existing code)
so I applied it, though I don't have any testcases for what it's
supposed to do.
I've got some that I use for internal testing - but the most obvious is that
you should now be able to read any valid UTF-8 sequence into a
The one in NSString.m is used whenever anyone implements their own
subclass of NSString.
O.K., so I can test that by making an empty subclass of NSString then ?
-bat.
___
Bug-gnustep mailing list
[EMAIL PROTECTED]
In Gui...
gmake[2]: Entering directory `/home/pfrench/gnustep/core/gui/Source'
cp ../Documentation/Gui/Gui.gsdoc .
cp ../Documentation/GuiAdditions/GuiAdditions.gsdoc .
Making all for doc Gui...
Generating reference documentation...
Bus error (core dumped)
Running gdb on the coredump giuves
Having completed a build and install of thelatest CVS there is
a very fiundamental probelm on BSd systems. I am getting the following
error:
xyz: kvm_read: Bad address
xyz: cannot read IdlePTD
CANT OPEN KERNEL
when trying to run the simplest of command line tools. This looks to
me like an error
Sorry about this, please ignore the last UTF8/UTF16 patch, this one
has a slight change which makes it better (but got missed in the
original email). The addition is to consider the high word of the
surrogate pairs as non-spacing. That is a very convenient way for
the rest of the code which does
be fine for the conversion between UNICODE and UTF8, but what about all
the other conversions? If we change the internal storage of UNICODE from
UCS2 to UTF16 all the other conversions should know about this. No big
Thats an interesting point - I havent yet checked what happens on OSX,
but
[regarding UTF8 handling outside the BMP]
I hope that this would fix the problem, but without testing I cannot tell.
O.K. - can people please test the attached patch ? It is for Unicode.m
and adds support for the characters outside the BMP. These are converted into
paired surrgates internally,
First the good news: GNUstep now supports the INCR transfer for the X
selection (and a lot more smaller ICCCM stuff was added in the same go).
Excellent stuff.
But there is of course also a bit of bad news, which is that this
specific page still cannot be transfered, which is according to
I've done a complete 'cvs co' yesterday night and began to compile. For now,
I've only compiled 'make' and 'base'. First things I've seen :
- gdomap still uses almost 100% CPU
- gdnc can't register itself
This is not good - I think that its not your compiler, so downloading gcc32
is
The original SSL won't work with GNUstep. If you do not want to override
it, you must configure -base with --disable-openssl.
This is the second time I have seen someone say this, yet it appears to work
fine for me - or at least I dont get any crashes compiling and running
with the original
would you two mind to retest large cutpaste again? I did fix this
Still doesnt work for me here. Interestingly I am seeing an error on the
temrinal now:
2003-08-19 10:56:57.078 gpbs[35842] Unsupported data type from X selection.
2003-08-19 10:56:57.078 gpbs[35842] Unsupported data type from X
thing, I must always use 'cvs co' instead of 'cvs update'. If I use 'cvs
update', my Headers/Foundation directory is almost empty (I can't remember
That does not sound good. What happens if you delete everything, do a cvs co
from scratch and then a cvs update ? Does that work as expected ?
Well I've done a 'cvs co' few weeks ago and I do cvs update from that. I can't
tell you what is my CVS string because I'm at work and by the way, don't have
my computer with me.
I'm using CVSROOT=:pserver:[EMAIL PROTECTED]:/cvsroot/gnustep
if that helps...
?? I stay updated with cvsup for
thank you for this test. Could you please also test the latest CVS
version and report on this?
Just tried this usingmy standard tests. It seems to work fine - I can cut
and paste text in full Unicode between Mozilla and GNUstep apps happily,
and the charcaters are the same on the round trip
does this mean it works for him as well? It is so easy to give negative
feedback, but people tend to forget about the positive one.
Some positive feedback here - I'm still using the first version of
Kazu's patch and it works extremely well.
Copying of general unicode seems to work for me
So, here is my proposal: Would it be possible to revert back to
previous behaviour of gpbs?
Umm, but the previous behaviour was also a bug. Indeed it was pretty
much the same bug - i.e. unable to cut and paste between certain
X apps and GNustep. The new version fixes the apps which were
3. GNUstep apps used to freeze for a while (waiting for X selection) when pasting
from X apps.
Actually I see this. What seems to be happening is that the gpbs dies and
then gets restarted.
I am also sseeing an odd effect that the first cut and paaste doesnt work.
I needx to do acust and
Ooops, forgot the attachment...
Just tried to apply the patch - it seems to be relative to the ,v files in CVS
rather than the actual source files. How can I patch my source to try out
the patch (or do I need a local CVS repository to apply to ?).
-bat.
Can this be done for the bundle and left out of the link instruction for
code that merely uses the bundle?
I am not sure. One interesting thing is that I do not get this error
when building actual GNUstep applications - only when building Tools.
Not quite sure what the difference is there.
3. link bugs I didn't find in the gnustep code (and don't occur on my
debian system) ...
I think they are caused by the use of crypto functions but not
linking with -lcrypto. Add that in and it should be a lot quieter.
-bat.
___
Bug-gnustep
I interpret Alex' answer as
Because it's in glibc it's therefor 'correct' behaviour
(aka: another Linux'ism)
Ahhh... 'twas ever thus. When I started doing UNIX work we had to
put up with 'all the worlds a VAX', these days its 'all compliers are GCC'
and 'all the world is
Also ... the bundle is typically not even loaded unless your
code tries to access an https URL, so even if the linking of
libraries into bundles is going wrong somehow, it seems unlikely
that anything to do with this bundle is causing errors in the gui.
Linking these libraries is a bit odd on
some code
===
some more code
*doh!* ... this is the OSX machine on which I tested the no-precomp
stuff before submitting the patch for it ;-) that would explain it...
thanks,
-bat.
___
Bug-gnustep mailing list
[EMAIL PROTECTED]
Do you see a Severity field? It could only show up when you are logged
in or something like that, but I don't think so - there doesn't seem to
be any reason it would do this.
Nope. I am logged in and theres no field like that. I'm using Safari
so maybe its some Apple problem. I assume you
Attached patch changes the -tradional-cpp flag to -no-cpp-precomp. This
has been tested on all the versions of gcc shipping with OSX - gcc2,
gcc-3.1 and gcc-3.3 and works under all of them.
can someone commit please ?
cheers,
-bat.
*** target.make.origTue Jul 15 20:51:47 2003
---
Am trying to load a main menu file thus:
int main(int argc, const char *argv[])
{
NSAutoreleasePool *pool = [NSAutoreleasePool new];
[NSApplication sharedApplication];
[NSBundle loadGSMarkupNamed:@MainMenu owner:NSApp];
return NSApplicationMain(argc, argv);
}
The subject says it all really... doing a build I get:
bash-2.05a$ make messages=yes
Making all for app Rattatosk...
gcc Rattatosk_main.m -c \
-MMD -MP -DNeXT_Foundation_LIBRARY=1 -DNeXT_GUI_LIBRARY=1 -DNeXT_RUNTIME=1
-framework Foundation -framework AppKit -traditional-cpp -dynamic
Thanks! I was able to reproduce this, but only with some fonts. Turned
out to be a problem with finite precision arithmetic. NSStringDrawing
will use a really large text container to size text, and since the
string was right aligned, the extents were 1e8-~80 to 1e8. Subtracting
Ahhh... that
studying it. Why? Because I have to get some .nfonts for Asian
characters somewhere or to
Do you have TTF fonts for these Asian fonts ? theres a very good prgram
called 'mknfonts' which will take a TTF and turn it into an nfont for
use with the ART backend. I tried it on a few Unicode fonts
At first I forgot to set GSFontAntiAlias to YES and, naturally,
got the same result as that of the xlib backend. After setting
the environmental variable correctly, the trouble has disappeared!
Now thats interesting. I didnt even know about the GSFontAntiAlias setting
and I havent touched it
GSFontAntiAlias
A boolean value which defaults to NO. If set to YES and the X-Windows (sic)
system has the XFT extension, then the application will use anti-aliased fonts
as provided by the X-Windows (sigh) system.
...?!
but 'art' doesnt use the X-Windows fonts does it ? So how can this
xwd(1) and xwud(1) are the utilities accompanied with X11R6.
O.K. - just took a look at that. Ugh! Thats very wrong. Was that with
the ART backend or the XLIB one ?
I tried it with a few fonts of different sizes, and got the same results.
What is strange is that some applications display
The bug still exists with the xlib backend. I am going to try the art
backend,
but before it, it seems I have to get .nfont packages. I would be happy
if you could tell me how to get them.
I cant remember where the official download places are, but you can just
grab my set from
I applied this patch, but I left out the part that restricts it to
FreeBSD systems, just to see if anyone else complains :-) (i.e. I'd
heh. Thanks for the commit - though I ssuspect the other complaints wont
be long in comming somehow. Its a shame the /dev/null hack doesnt work
on other
The doc install still seems to be in gui. I;ve fixed autogsdoc now,
but when I su to root it looses the GNUstep paths (and rightly so) but then
cant find autogsdoc and thus stops. Would it be possible to code the
full path in to avoid this problem ?
-bat.
I added a check for libkvm in base/configure, if you can test it out.
Works excellently - can you drop in the new NSProcessInfo.m please ?
It would be nice to say something like
Please reconfigure gnustep-base with --enable-fake-main to avoid use of
kvm.
Sure, feel free to change the
I just ran tests on both OSX and OpenStep 4.2 - both of those
system draw the text with the point specifying the bottom left.
GNUstep (I have only tried with back-art) draws with the point specifying
the top left.
Somebody (whos email address I have lost!) mailed me a piece
from the spec which
So, finally, we have to decide: Do we need horizontal menus in GNUstep
library or not? There is 2 ways:
How does removing the code affect, for example, menus on a Windows
system ? I havent yet persuaded GNUstep to run under Windows I have
to admit (will give it yet another bash in the near
Actually, base includes md5.c/h and I was wondering whether it would be
better if we added a set of categories to base's NSData to return md5
digests of NSData. It seems that the c-api would be available but
nothing in base seems to use it yet. (At least I couldn't find it.) If
the
I don't think the issue right now is how to implement it (because with
yours we now seem to have three implementations) but rather where.
Well,my vote would be a category method on NSString which takes bytes. The
outcome is a string, not data, and strings should be retiurned by class
methods
thanks - the main reason I not applied this patch immediately was that ...
that I was confused, because 'configure' itself is using 'dirname', and I
can't fix that. :-)
I suspect configure is adapting itself to the fact that dirname is missing.
It definitlty runs fine under OpenStep, yet
Hi, could someone take a quick look at:
http://mail.gnu.org/pipermail/bug-gnustep/2002-December/002928.html
and fix it in CVS if it looks O.K. ? Its frutsrating to have to make this
change every time I try and do something under OpenStep 4.2
cheers,
-bat.
Just installing GNUstep on a nice clean system out of the box. Fresh from CVS,
and it seems that the gmodel bundle is not guilt for some reason. Has this
been removed from the makefile, or do I now need to add a configure option or
something ?
Following up my own post here, and copied to
Making all in gui/Model...
gmake[1]: Entering directory `/home/pete/gnustep/nib2gmodel/gui/Model'
/home/pete/gnustep/nib2gmodel//usr/local/System/Makefiles/rules.make:385: target
`/home/pete/gnustep/nib2gmodel//usr/local/System/Makefiles/' given more than once in
the same rule.
I suspect this
problem: make/create_domain_dir_tree.sh uses dirname which does not
exist under OpenStep 4.2
solution: as it is merely used to find the directory being run in then
it can be replaced with something like:
mybase=`basename $0`
mydir=`echo $0 | sed -e
I havent managed to track this one down and find a fix, sorry...
problem: running 'configure' creates the makefile in ./usr/System/Makefiles
but running 'gnumake' then tries to find the makefiles in
'./usr/GNUstep/System/Makefiles'.
OK, now I'm thinking the pattern was just done to make it look good on a
gray-scale monitor and perhaps if NeXT was written using the higher
resolution monitors of today it would have been solid.
That a very inetersting observation though - because it implies that the
PostScript being
Found a problem in the above method of NSString. If you have a string
which contains blank lines - i.e. the sequence \n\n somewhere in it - then
if you specify a range being the single '\n' character on the
line, then the method returs a range containing the whole of the following
ine, rather
Well you can try xgps again to see if it still works. It should mostly
work (at least you should get farther than you are now). The differences
between the backends isn't that great, but it could be a clue to what is
going on.
defaults write NSGlobalDomain GSBackend xgps
Hmm, that
that occurred to me too ... and well it is certainly caused by the fact
that gnustep-make has been modified to link bundles against all libraries
So does that mean that it staticly links bundles against available libraries
rather than using the shared libraries on startup ? I am somewhat
Ahh, I get it... was this change made to support Windows by any chance ? One of
the big problems with Bundles on the old OpenSTep forNT was that you
culdnt call anything from the main application that you needed to link
against - it all had to be linked into the bundle separately.
This might be
hmmm... can anyone tell me the magic invocation to GNUstep make
to get it to compile with -g turned on ? (and how to build
the base system this way too actually...)
anyway, got gdb going on my mysterious coredump and here is the
result:
(gdb) bt
#0 0x8057b87 in sel_register_typed_name ()
#1
(available at http://www.x.org/pub/contrib/libraries/xvertext.5.0.shar.Z,
as stated in the X FAQ) for text scaling and rotation. While they work
for me, I have not done extensive testing, and no testing at all
in drawing with alpha.
Excellent work though _ I'm just in the process of adding
I am seeing consistent memory problems when using a clipping path in
GNUstep. Sometimes this manifests itself as the clip working properly, but
then I get a Warning: free() called on already freed memory when the code
exits, but most of the time it manifests itself as a coredump when the
code
Seems to me that -_doPath::draw: was calling XIntersectRegion() without
creating the region, thus causing the crash. I've attached a patch that
fixes it. With the patch it works here.
Wow! That was fast! Excellent, thanks. I hope someone will put this into CVS.
One thing puzzles me though -
I just restarted gdnc and got a message about moving defaults from
old location to new location. Which I didnt save sadly - but the new
location was comething like ~pfrench/GNUstep.
Al well and good - except that what appears to have happened
is that the directory '~pfrench' has been created in
Once you have up to date packages installed, this problem should go away.
Actually, having installed make again, and the rest again the problem
did indeed go aaway. My mistake for thinking it was a big.sorry!
-bat.
___
Bug-gnustep mailing list
I seem to be finding that PSclip() is a reliable was to cause coredumps
in gnustep. I had previously assumed that it was a bug in my code causing
this, but now i am simply using:
PSnewpath();
PSmoveto(0,50);
PSlineto(50,0);
PSlineto(0,0);
PSclosepath();
In DPSimage at line 1758 the origin of the rectangle is set equal to
point. But the resulting rectangle is passed to viewRectToX: which
takes vew co-oridinates, and as DPSimage is called with the view translated
and scaled such that the image starts at 0,0 then this leads to the offset
being
As part of the new SOVERSION code in library.make line 157 reads:
SOVERSION = $(word 1,$(SUBST ., ,$(VERSION))
My gnumake kicks this out with an error as the brackets are unmatched. I
am not entirely sure what is going on here, but I suspect this is supposed to
be something like...
SOVERSION
See configure.in ... it tries to compile a tiny test program. Perhaps
it needs other includes rather than net/if.h on BSD?
This compiles fine
#include sys/types.h
#include sys/socket.h
#include net/if.h
main()
{
struct ifreq s;
O.K. I found the bug in gdomap that was causing me all my problems.
The code for line 1123 onwars assumes that the ifreq structures in the
data returned by SIOCGIFCONF all have the same size and that this
size is equal to sizeof(struct ifreq).
This is not the case as an ifreq structure contains
The patch below fixes a problem in gdomap which causes it to read an
incorrect list of interfaces under FreeBSD and other 4.4 BSD systems.
The bug is caused by the fact that SIOCGIFCONF returs a set of variable length
data structures rather than a set of sixed length struct ifconf's.
The patch
Thanks ... I added your patch with a slight modification and all the
associated autoconf stuff to decide whether the system has variable
Hmm, how did you do that ? It doesnt seem to work here (and I re-ran
the configure script). Is it supposed to set HAVE_SA_LEN if the
system has variable
89 matches
Mail list logo
