Re: Something has recently changed to break the build...

[Richard Frith-Macdonald]

> On 27 May 2024, at 15:41, Riccardo Mottola  wrote:
> 
> Hi,
> 
> Gregory Casamento wrote:
>> I was building on github.com .  RFM has fixed it... It 
>> builds fine on my machine, but just for the record...
>> 
>> Debian 12, clang 14
>> 
> 
> hmm... On old Debian with gcc all works.
> 
> However, I think this caused a regresion, a GCC build on NetBSD causes:
> Making all for subproject ObjectiveC2...
>  Compiling file blocks_runtime.m ...
>  Compiling file NSBlocks.m ...
> NSBlocks.m:6:2: warning: #warning Unable to build NSBlocks for this runtime. 
> [-Wcpp]
> 6 | #warning Unable to build NSBlocks for this runtime.
>   |  ^~~
> Making all for subproject Additions...
> gmake[5]: Nothing to be done for 'internal-subproject-compile'.
> gmake[3]: GNUmakefile: No such file or directory
> gmake[3]: *** No rule to make target 'GNUmakefile'.  Stop.
> gmake[2]: *** [/GNUstep/System/Library/Makefiles/Master/rules.make:297: 
> libgnustep-base.all.library.variables] Error 2
> gmake[1]: *** [/GNUstep/System/Library/Makefiles/Master/library.make:37: 
> internal-all] Error 2
> gmake: *** 
> [/GNUstep/System/Library/Makefiles/Master/serial-subdirectories.make:53: 
> internal-all] Error 2
> 
> 
> 
> something is misconfiguring here. This is a clean build on a clean computer...
> 
> Riccardo

I want to make a release ... is this going to block it?
Please could you re-check making sure that you are using current code from the 
repository and that you have re-run configure

Re: Reminder!!! GNUstep meeting 12:30-1:30est

[Richard Frith-Macdonald]

> On 12 Apr 2024, at 10:41, Fred Kiefer  wrote:
> 
> I cannot make it on Saturday. We have an invitation from friends and I won’t 
> be back in time.
> 
> My point for the discussion would be the same as last time, to prepare a 
> shared release of all core libraries. My contribution could be to write up 
> the news sections for gui and back but somebody else would have to cut the 
> releases. The first step should be to step a release date let#s say in a 
> months time.

I thught we we previously decided to aim for end April, but some time in May 
actually suits me better as I'll be away (possibly without a computer) for over 
a week bwtween now and the end of this month.

Re: Objective-C runtime via FFI

[Richard Frith-Macdonald]

> On 6 Mar 2024, at 04:02, Boris D.  wrote:
> 
> Hello, I am interested in interacting with the Objective-C runtime from other 
> languages through FFI bindings. 
> In particular, I need to be able to load Foundation or other classes 
> dynamically. What needs to be done to load these classes in the runtime? 
> Here's an example illustrating the issue I'm facing: 
> // clang `gnustep-config --objc-flags` `gnustep-config --objc-libs` simple.c 
> -o simple
> #import 
> int main (int argc, const char * argv[])
> {
> Class c = objc_getClass("NSObject");
> printf("Got a class: %s\n", c ? "pass" : "fail");
> return 0;
> }
> Currently it fails.

It may not be the only problem, but you are linking your program without 
NSObject, so you definitely wouldn't expect to be able to have 
objc_getClass("NSObject") return it.
NSObject is implemented in the base library, so any code that wants to use it 
would need to be linked with that library (see 'gnustep-config --base-libs).

I don't know if it's true nowadays, but I remember in the past the linker on 
some systems wouldn't actually 'pull in' a library unless your code used a 
symbol from the library, and since you are not cmpiling ObjectiveC code it 
won't be using the classes in the library, so linking with the base library may 
well not be enough.

If that's the case, then in theory you could use C dynamic library loading 
functions to exlicitly load the base library into your running program and 
register things with the runtime, but that's probably really complicated.

A simple solution would be to compile a small objective-C code fragment

eg
void setup_base()
{
  [NSObject class];
}

You could then have yur C code link with that and call the setup_base() 
function at the start.
That would ensure that the base library is linked into your code.
You could then use the NSBundle class to dynamically load other stuff.

Re: Installing GNUstep from FreeBSD ports, again

[Richard Frith-Macdonald]

> On 16 Feb 2024, at 11:05, Sergei Golovin via Discussion list for the GNUstep 
> programming environment  wrote:
> 
> By the way it is strange that Gorm was installed in the
> SYSTEM_DOMAIN. My installation goes into
> <...>/Local/Applications/Gorm.app (that is LOCAL_DOMAIN).

If this is the official FreeBSD package, then it should go in the system 
domain;  that's what the system domain is for.
Things you build for yourself typically get installed in the local domain (this 
is the default) ... unofficial but available to all users of the machine.
Things intended for your personal account only, you should install to the user 
domain.

Lookup to find software normally goes in the reverse order; so if you try to 
run Gorm,  your user's copy is preferred, but if there isn't one, the local 
copy is used, and if there isn't one of those, the system copy is used.

Re: Consider GtkCore as UI

[Richard Frith-Macdonald]

> On 20 Dec 2023, at 07:44, Albert Palacios  wrote:
> 
> Hi,
> 
> With the GitHub code, where the GSTheme.m file is 8 years old, I can't see 
> how to create a theme to my liking. Now I see that there have been 
> modifications three months ago to some files, I will have to look at the 
> differences to see in detail what it is about.

Please take a look at the documentation (or, since it is generated from mark in 
the heaqder files) GSTheme.h
Perhaps also look at Thematic.app,  since GSTheme and Thematic.app were 
developed together (so we would have an app to manage/build themes).  The app 
is far from complete (the hope being that theme developers woudl add missing 
functionality when they needed it), buteven so it  allows a lot of theme setup 
to be done using a GUI.
The documentation at the start of GSTheme.h describes how themes are meant to 
work overall,  a key feature being that themes can be dynamically switched in a 
running application (so in Thematic.app you can see the effects of changes made 
when editing a theme).

Simple themes use settings (user defaults) to control behaviors, color lists to 
control the colors of each GUI element, replacement bitmap images, and bitmap 
tiling ... stuff that can be built in the app using the GUI and no coding.
A substantial part of the theme code is dedicated to making those things simple 
to change, so in Thematic.app you can use the GUI to select settings, set 
colors for all the named interface elements etc, and even to specify tiles to 
be repeated to make up elements of the GUI without any need for coding.

More complex themes are implemented by having a subclass of GSTheme where you 
override some of the methods used to modify the behavior and to draw different 
control element.  There are a lot of those methods, grouped into categories by 
function.  However there's no guarantee that there will be a method to control 
everything you want.
There's also an ability to name individual objects so that your drawing code 
can treat particular objects differently from others (see 
-setName:forElement:temporary: and -nameForElement:).

The intended solution to that is that theme developers should reach out to the 
GNUstep developers and ask for a new theme method to be added to allow some 
specific behavior/drawing to be altered;  a new method would be added to 
GSTheme and the GUI class would be modified to call the new method from 
GSTheme.  The theme developer would then override this new method (in their 
GSTheme sbclass) to alter behavior/appearance when their theme is active.

But ... getting a new theming method in place (and waiting for a new release 
gof the GUI) is time consuming, so as an temporary solution the GSTheme code 
actually allows your GSTheme subclass to temporarily override methods in other 
classes in a way which still works with the theme switching mechanism (see the 
-overriddenMethod:for: method, which describes the naming convention for doing 
this).


> Also, in the documentation, I can't see anywhere how to properly make a 
> custom vector theme from scratch, and I haven't found any example either. 

I guess by 'vector theme' you mean one where you implement methods to do the 
drawing.  That's fundamentally a programming task (what I describe as 'More 
complex themes' above) rather than GUI based design.  As such you need to look 
at implementing/overriding the GSTheme methods in the various categories,  but 
to know which ones you want to change you also need to look at the GUI code to 
see which theme methods are used where.

Re: Consider GtkCore as UI

[Richard Frith-Macdonald]

> On 17 Dec 2023, at 14:20, Andreas Fink  wrote:
> 

> The only version which is not up to date on repo.gnustep.ch is currently 
> Ubuntu22 on Intel as I run into a strange error with configure of 
> gnustep-base as it does not want to detect my libiconv-1.17 version for some 
> reason. The same version I compiled and used under Ubuntu22 on arm64 and on 
> Debian worked just fine. (if anyone has a hint on how to convince ./configure 
> to just use my libiconv I pass, let me know. 
> --with-libiconv-library=/usr/local/lib/libiconv.a  was not enough).

I had a look at the documentation/comments in configure.ac
They suggest you may need to use  --with-libiconv-include= as well as 
--with-libiconv-library= if you have multiple versions of iconv with 
conflicting headers
If that fails, I guess you'd need to look at the config log to work out why.

Re: Debian12 repository.

[Richard Frith-Macdonald]

> On 24 Nov 2023, at 13:14, Andreas Fink  wrote:
> 
> see http://repo.gnustep.ch/
> 
> I am currently fighting with /usr/GNUstep/System/Tools/gnustep-config while 
> compiling my own libraries
> 
> After changing the layout to gnustep
> 
> the tool is not found in the path. a symlink to /usr/bin/gnustep-config fixes 
> this (or expanding the path)
> However  gnustep-config  --objc-flags  does not include  a 
> -I/usr/include/GNUStep  so  is not found
> 
> It's not strictly necessary for pure objc code but for gnustep-base code it 
> is. There is however no --base-flags but only --base-libs.
> 
> I could simply add -I /usr/include/GNUStep   to my Makefiles. But then why 
> have a config tool when it only does half of the work.
> 
> Suggestions?

> the tool is not found in the path

That means your path is wrong ... but that's easy to fix.

> But then why have a config tool when it only does half of the work.

The problem is not that the tool is doing 'half the work',  it's that your 
headers etc are in the wrong place because you misunderstood what this means:

> After changing the layout to gnustep

If your layout is 'gnustep' the resources are supposed to be found in the 
standard gnustep layout locations found from the root path you have set.
By default the root path is /usr/GNUstep (though you can configure the root of 
the layout to be somewhere other than /usr/GNUstep)

Most headers installed in the 'gnustep' layout will be in 
/usr/GNUstep/Local/Library/Headers and make will find them automatically.

It sounds like you have configured for the 'gnustep' layout, but are expecting 
to find resources in the old layout.  If you did, that would be bad (the two 
different installations would be interfering with each other;  not often 
obvious with headers, but when you have different versions of libraries built 
for different runtimes that's a real problem), so hacking flags to point to a 
different installation is a dangerous thing to do.

If you want the 'fhs' (headers in /usr/include) layout then that's the way you 
should configure gnustep-make.

Re: website & ftp downloads update

[Richard Frith-Macdonald]

> On 22 Oct 2023, at 15:16, Riccardo Mottola  wrote:
> 
> Hi Marco,
> 
> Marco Cawthorne wrote:
>> I was wondering about the download links on the page. They still use
>> the ftp:// protocol which has regrettably been phased out by every
>> major browser.
> 
> well, ftp support is intentional, since it is traditional. Every major 
> browser... you mean every chrome-clone, since Chrome dropped support for it? 
> If Google is too ignorant to distinguish between a hyper-text (transfer 
> protocol) and a file... I don't know...
> But I guess it is evil that spreads like URL part and protocol hiding, https 
> enforcement for pages that don't need it at all, etc, etc.

I think ftp is (like telnet) being dropped in most places because of it's lack 
of security, and in general I'm in favour of the trend to always use encrypted 
communications.

What seems regrettable is that browsers have dropped ftp:// without 
implementing sftp:// as a replacement, though to be fair, support for large 
file download over https:// is normally fine nowadays.
So I guess there's no compelling need for sftp://

Re: Our self-presentation, not just on our website. (Was: Re: GS based app release: djay by Algoriddim in Beta)

[Richard Frith-Macdonald]

> On 3 Sep 2023, at 10:30, Albert Palacios  wrote:

...

> Beyond the inability to develop a modern-looking theme, other issues urgently 
> need addressing:
> 
>• Having a GNUStep configuration folder in the 'home' directory is 
> unacceptable to anyone mildly organized (or with obsessive-compulsive 
> disorder). Can't you put a '.' before the name to make it hidden?

I can't address your other points directly/immediately, but the GNUstep folder 
in the home directory is merely a default (chosen so that people can easily 
find their stuff).
You can override it by setting a different value for GNUSTEP_USER_DIR in your 
.GNUstep.conf file

eg.

GNUSTEP_USER_DIR=.GNUstep

if you want to use the same name with a dot before it.
In fact you can individually override the various different folders for 
different kinds of personal resources, not just the main folder which 
conventionally contains them. 

In short, YES, you can put a '.' before the name to make it hidden.

Re: Object creation error

[Richard Frith-Macdonald]

> NSArray *justSaySay = [NSArray arrayWithObjects:
> @"there's NOBODY know CHINA than me",
> @"there's NOBODY know AMERICAN than me",
> @"there's ANYBODY know GNUSTEP than me"
> ];

This will often crash, so it is probably the cause of your problem.

The +arrayQWithObjects: method requires that the list of objects must be 
terminated.  Otherwise it will try to interpret the contents of the memory 
location after the last object in the list as an object, which will usually 
cause a crash.
The correct code is:


NSArray *justSaySay = [NSArray arrayWithObjects:
@"there's NOBODY know CHINA than me",
@"there's NOBODY know AMERICAN than me",
@"there's ANYBODY know GNUSTEP than me",
nil
];

Re: GNUstep make, linking to frameworks in the app wrapper

[Richard Frith-Macdonald]

> On 3 Mar 2023, at 17:11, Andreas Höschler  wrote:
> 



> Now that I have moved the framework I cannot even build the app anymore 
> because it can't find the header.
> 
> cd 
> make 
> 
> retina:TestApp3 ahoesch$ make install
> This is gnustep-make 2.4.0. Type 'make print-gnustep-make-help' for help.
> Making all for app TestApp3...
>  Compiling file DocumentController.m ...
> clang: warning: /Build/TestFW/TestFW.framework/Headers: 'linker' input unused
> DocumentController.m:2:9: fatal error: 'TestFW/Person.h' file not found
> #import 
> ^
> 1 error generated.
> 
> 
> I tinkered around with)
> 
>   ADDITIONAL_INCLUDE_DIRS += /Build/TestFW/TestFW.framework/Headers
>   ADDITIONAL_LIB_DIRS += /Build/TestApp3/TestApp3.app/Contents/Resources

I don't use frameworks (I think the gnustep-make documentation has always said 
to use bindles instead), and certainly not within an app wrapper, but you might 
try setting ADDITIONAL_FRAMEWORK_DIRS to point to the framework you want 
gnustep-make to use.


> One approach would certainly be to get rid of GNUstep make and use xCode 
> instead for this. But I would like to stick to GNUstep make if possible!? Is 
> there a way to make the app look into the app wrapper for libs and frameworks?

I think, since frameworks are essentially dynamic libraries, you probably need 
the load path to be specified by the LD_LIBRARY_PATH environment variable or 
similar, and that probably need to be done before the binary starts executing.

But putting things in the app wrapper seems similar to packaging an entire 
system standalone (in a single folder)  and gnustep-make already has a 
mechanism to do that ... the standalone filesystem layout  in conjunction with 
a GNUstep.conf file telling the software whwre to find everything.

This was for packaging gnustep applications for distribution on ms-windows, so 
it's documented in README.MinGW
It's not quite what you want, because it expects *everything* inside the app 
wrapper, and presumably you want some stuff in the normal locations,  but I 
expect you copuld simply adapt it by using a different filesystem layout where 
instead of the domains SYSTEM,NETWORK,LOCAL all pointing into the app wrapper, 
you just used one of them (eg NETWORK) to point there, and left the others 
pointing to the normal locations.

Re: Base 1.28.1 API/ABI break?

[Richard Frith-Macdonald]

1 Announcement
**

The GNUstep Base Library, version 1.29.0, is now available.

1.1 What is the GNUstep Base Library?
=

The GNUstep Base Library is a library of general-purpose, non-graphical
Objective C objects.  For example, it includes classes for strings,
object collections, byte streams, typed coders, invocations,
notifications, notification dispatchers, moments in time, network ports,
remote object messaging support (distributed objects), and event loops.

   It provides functionality that aims to implement the non-graphical
portion of the OpenStep standard (the Foundation library).

   There is more information available at the GNUstep homepage at
'http://www.gnustep.org'.

   This is a bugfix release increasing the library version number to
reflect ABI change that should have been included when the previous
release was made.

1.2 Noteworthy changes in version '1.29.0'
==

   * Library version changed from 1.28 to 1.29

1.3 Where can you get it? How can you compile it?
=

The gnustep-base-1.29.0.tar.gz distribution file has been placed at
.

   It is accompanied by gnustep-base-1.29.0.tar.gz.sig, a PGP signature
which you can validate by putting both files in the same directory and
using:

 gpg --verify gnustep-base-1.29.0.tar.gz.sig

   Signature has been created using the key with the following
fingerprint:

 83AA E47C E829 A414 6EF8  3420 CA86 8D4C 9914 9679

   Read the INSTALL file or the GNUstep-HOWTO for installation
instructions.

1.4 Where do I send bug reports?


Please log bug reports on the GNUstep project page
 or send bug reports to
.

Re: Base 1.28.1 API/ABI break?

[Richard Frith-Macdonald]

> On 7 Jan 2023, at 18:42, Yavor Doganov  wrote:
> 

Sorry about the change ... I had thought that the names were changed after 
1.28.0 and fixed.

> Usually, the correct course of action is to revert the upload to
> Debian and wait for upstream to make another release with a bumped
> SONAME.  But in this case we'll certainly miss the deadline and we'll
> end up with Base/1.28.0 and GUI/0.29.0 in the new Debian release.

How certainly?
I could bump the gnustep-base release version today (8 Jan).

Re: Suggestion for new website - GNUstepWeb

[Richard Frith-Macdonald]

> On 15 Dec 2022, at 23:08, Riccardo Mottola  wrote:
> 
> Hi,
> 
> 
> Gregory Casamento wrote:
>> Do you think we should have part of the website use WebObjects/GSWeb as a 
>> sort of demo of GNUstep itself?
> 
> as cool as it may sound and as nice it is to "eat your own dogfood" is, two 
> reasons come up to my mind of why not
> 
> 1) simplicity of maintaining a static website [*]: it is just easy to develop 
> it locally, test it... no need for a webserver. This is how I maintain(ed) 
> the GS website until its current fate. Very convenient and always available 
> "on the go" where I had a CVS checkout
> 2) independency on the infrastructure. Stati webpages can be hosted anywhere, 
> we could also just use a standard hosting service and it would fit.
> 
> So I would keep "www.gnustep.org" static, but we could have a subdomain 
> dedicated to it. Like wiki.gnustep.org runs on wiki software, we could have a 
> part running on GSWeb.
> 
> Some candidates come to my mind:
> 
> 1)  dynamic feature comparison, dynamic documentation or things like that 
> (e.g. the thing Hugo was thinking)
> 2) rewriting software index into GSWeb
> 
> similar things like that, which could be in subdomains on other servers and 
> if they go down, they wouldn't affect the "main" static website, which would 
> be www and ftp.
> 
> Just my two cents.

That sounds very reasonable to me.
Your elaboration is exactly what I interpreted Greg's suggestion of 'parts of 
the website' as meaning, and your suggestion of which specific mparts would 
make sense is good.

Re: Any news from Sergii Stoian ?

[Richard Frith-Macdonald]

> On 1 Mar 2022, at 13:20, Xavier Brochard  wrote:
> 
> Title says all. Sergii Stoian (ProjectManager, NextSpace) lives in Kiev.
> Does anyone knows if he is doing well ?
> 

I haven't heard anything.  It's all very worrying.

Re: Clang/LLVM migration roadmap

[Richard Frith-Macdonald]

> On 14 Feb 2022, at 16:38, Xavier Brochard  wrote:
> 
> Hi everyone
> 
> By reading this discussion, I was thinking there is a problem that no one 
> talk about. This email from Riccardo is a good starting point:
> 
> Le 14.02.2022 00:11, Riccardo Mottola a écrit :
>> But what is a user? I can think at least of two types.
>> 1) User of GNUstep libraries because user of GNUstep applications.
>> 2) User of GNUstep because he writes GNUstep applications,
> 
> I would say  "User of GNUstep because he writes GNUstep applications *because 
> there is users*.
> 
> This Clang/LLVM migration looks like a lot of work for a small team.

Yes, a migration sounds like a lot of work, but the use of the term 'migration' 
was accidentally misleading.

This is not talking about migrating code that exists, rather about changing 
what we target/prefer for adding new code/features.

So the actual work discussed is either contributing to GCC to give it the 
features we want or improving/widening portability of Clang/libobj2, which 
don't effect the existing code.

Even so, it *is* a lot of work, but either route improves things for gnustep 
users.


All that being said, I agree with most of your points about there being plenty 
of scope for non-coders to contribute other stuff, and like the idea of having 
road-maps for those sorts of things.

Re: Should we split the project into two branches?

[Richard Frith-Macdonald]

> On 15 Feb 2022, at 08:13, Max Chan  wrote:
> 
> 
> 
>> On Feb 15, 2022, at 2:54 AM, H. Nikolaus Schaller  wrote:
>> 
>>> Am 15.02.2022 um 08:36 schrieb Max Chan :
>>> 
>>> Come to think of it, if we do chase the latest feature especially Swift 
>>> compatibility, we get Swift Package Manager along with it which can be used 
>>> as a parallel build system bypassing gnustep-make.
>> 
>> Hm. To me it looks as two distinct projects. GNUstep and some Swift 
>> compatible thing (however it is called) using a different build system.
>> IMHO it is no problem hosting such elsewhere and from time to time 
>> cherry-picking components from GNUstep and vice versa.
>> It is the way my project mySTEP is run. Separate repositories and mutual 
>> exchange where it makes sense.
>> 
> 
> What I mean here is, using the parallel build scripts approach, core 
> libraries like base and gui can allow features written with new features like 
> ARC, Blocks and XPC to enter without affecting legacy support.
> The legacy build script is not even aware of the existence of those new 
> features which they can not support, while if you want to build those 
> features you need the new build environment which guarantees the support of 
> those.

My problem with this thread is that you keep writing things about GNUstep which 
are categorically false.

The current build system supports ARC and conditionally building clang specific 
code etc, and as far as allowing 'features written with new features like ARC, 
Blocks and XPC to enter without affecting legacy support.'  goes, such things 
have already entered GNUstep.
Contributors to GNUstep have spent their time and effort in making sure that it 
supports all this range of stuff in an easy to use and flexible manner, so 
false claims that all this stuff doesn't exist seem insulting to those 
contributors.

I think this thread should be called to a close since it is based on a false 
premise.  Conclusions and inferences from false premises are usually incorrect, 
and certainly need reevaluation before it makes sense to discuss them.

Why not try implementing some new feature Apple has added recently, to see what 
problems there *really* are, and ask how to overcome them?

Re: Should we split the project into two branches?

[Richard Frith-Macdonald]

> On 14 Feb 2022, at 17:39, Andreas Fink  wrote:
> 
> 
> 
> Richard Frith-Macdonald wrote on 14.02.22 17:43:
>> 
>>> On 14 Feb 2022, at 14:59, Max Chan  wrote:
>>> 
>>> 
>>>> On Feb 14, 2022, at 8:23 AM, Richard Frith-Macdonald 
>>>>  wrote:
>>>> 
>>>> 
>>>> 
>>>>> On 14 Feb 2022, at 11:43, Max Chan  wrote:
>>>>> 
>>>>> Dear List,
>>>>> 
>>>>> There are over and over again arguments on moving on to LLVM/clang for 
>>>>> latest language features versus maintaining compatibility with 
>>>>> old/uncommon platforms and GCC,
>>>> Really this is simply not the case among GNUstep developers.
>>>> Those of us who actually use the stuff just work with whatever we 
>>>> prefer/need, because GNUstep already works with both toolchains.
>>> The hard requirement of allowing building using GCC means we are restricted 
>>> to language features equivalent of OS X 10.6.8 or iOS 4.3.5,
>> Please don't spread such nonsense on the mailing lists.
>> 
>> The fact that we have a huge base of code that builds with both GCC and 
>> clang (and a small part that only functions when built with clang) in no way 
>> restricts us in the way we write new code.
>> 
>> Having highly portable code is a strong point, but that doesn't mean that 
>> *all* features are equally portable or that contributors are required to 
>> write perfect portable code.
>> 
>> It does the project a huge disservice to tell developers they 'have to use 
>> an ancient version of the language'. Please don't do it.
> 
> It does the project a huge reality check to tell developers they 'have to use 
> an ancient version of the language *IF THEY WANT TO CONTRIBUTE TO GNUSTEP*'.
> That's says it all.

It's YOU saying it, not GNUstep.
As far as reality is concerned, there is incontrovertable evidence that your 
statement is false, in the form of the sourcecode repository, which contains 
both lots of support for making portable code (usable with both compilers) as 
well as some code built only with clang.

Now, if what you wanted to say is that GNUstep has a very strong preference for 
portable code (and hence contributions of non-portable code are likely to be 
replaced at some point by portable versions), that would be fine and true.
If you wanted to say that GNUstep is *extremely* reluctant to break portability 
of existing code, that would also be fine and true.  it's also a non-issue in 
practice: who wants to rewrite working code to make it less portable?
There's also a coding style ... if you lay your code out differently, it's 
going to get reformatted.
None of this prevents contributions as you suggest, it just means some 
contributions are conditionally compiled, and some more likely to be altered by 
others to make them available to a wider audiance.

Re: Should we split the project into two branches?

[Richard Frith-Macdonald]

> On 14 Feb 2022, at 14:59, Max Chan  wrote:
> 
> 
>> On Feb 14, 2022, at 8:23 AM, Richard Frith-Macdonald 
>>  wrote:
>> 
>> 
>> 
>>> On 14 Feb 2022, at 11:43, Max Chan  wrote:
>>> 
>>> Dear List,
>>> 
>>> There are over and over again arguments on moving on to LLVM/clang for 
>>> latest language features versus maintaining compatibility with old/uncommon 
>>> platforms and GCC,
>> 
>> Really this is simply not the case among GNUstep developers.
>> Those of us who actually use the stuff just work with whatever we 
>> prefer/need, because GNUstep already works with both toolchains.
> 
> The hard requirement of allowing building using GCC means we are restricted 
> to language features equivalent of OS X 10.6.8 or iOS 4.3.5,

Please don't spread such nonsense on the mailing lists.

The fact that we have a huge base of code that builds with both GCC and clang 
(and a small part that only functions when built with clang) in no way 
restricts us in the way we write new code.

Having highly portable code is a strong point, but that doesn't mean that *all* 
features are equally portable or that contributors are required to write 
perfect portable code.

It does the project a huge disservice to tell developers they 'have to use an 
ancient version of the language'. Please don't do it.

Re: Should we split the project into two branches?

[Richard Frith-Macdonald]

> On 14 Feb 2022, at 11:43, Max Chan  wrote:
> 
> Dear List,
> 
> There are over and over again arguments on moving on to LLVM/clang for latest 
> language features versus maintaining compatibility with old/uncommon 
> platforms and GCC,

Really this is simply not the case among GNUstep developers.
Those of us who actually use the stuff just work with whatever we prefer/need, 
because GNUstep already works with both toolchains.

Re: Clang/LLVM migration roadmap

[Richard Frith-Macdonald]

> On 14 Feb 2022, at 08:54, Andreas Fink  wrote:
> 
> 
> 
> Daniel Boyd wrote on 14.02.22 08:54:
>> Riccardo,
>> 
>> Thanks for the response. I agree there is certainly a distinction between 
>> the user types and I, as a developer myself, was referring to #2. However, I 
>> disagree that catering to each group is equally important at this juncture 
>> for two reasons: 
>> 
>> 1) GNUstep doesn’t currently have enough quality apps to attract user #1. 
>> That is not to say, of course, that it has none, but I think it would be 
>> uncontroversial to say that it could benefit from having more—a lot more. 
>> 
>> 2) GNUstep’s utility comes not only from its general purpose end-user apps, 
>> but also from its facility as a framework for people writing narrow-purpose, 
>> highly customized apps. This is what I use GNUstep for primarily. My apps 
>> will only ever be used by a small number of people in my company because 
>> they are highly specialized to address a specific process or function unique 
>> to us. Indeed, going back to the early 90’s, this has always been a strength 
>> of the NEXTStep/OpenStep/GNUstep/Cocoa framework.
>> 
>> For these two reasons, I believe it is more
>> important for GNUstep to focus on attracting developers. And if you attract 
>> more developers—particularly developers writing quality, general purpose 
>> apps—that will, in turn, attract more end users. 
>> 
>> Lastly, to your point about people having freedom to choose which tools they 
>> want to use, I don’t disagree at all. This is FOSS and freedom is what makes 
>> FOSS great. However, in the long run, if we want users of any kind to be 
>> able to choose GNUstep at all, we need to grow the project now and that 
>> means attracting more developers, in my humble opinion. 
>> 
>> Cheers,
>> Daniel
>> 
>> Sent from my iPhone
>> 
> 
> I can only double that. If I look at myself, I use GNUstep because I
> need portable apps on MacOS and Linux and other Unixes. If I would be
> constrained to not using ARC, then basically, GNUstep would not be an
> option 


There is a danger in using mailing lists where people have different languages 
and backgrounds, promoting misunderstandings!

The moment you suggest a weired hypothetical like 'If I would be constrained to 
not using ARC', other people will think someone proposed it, which is 
definitely *not* the case.

Then we have to waste hours of time sending out emails to say that no, nobody 
is proposing removing ARC support.


However, I take your later points:

1. getting clang/linker working was initially tricky and the toolchain is 
fragile
2. a clang toolchain is available all for the platforms *you* are interested in
3. it works well and has features you want for your development

I think everyone I know agrees with much of those, and the discussion on 
improvement is about improving on that situation (widening portability and ease 
of use).

Re: GCC and Clang

[Richard Frith-Macdonald]

> On 11 Feb 2022, at 02:53, Po Lu  wrote:
> 
> Gregory Casamento  writes:
> 
>> The way I see it, we have two ways we can go. In each, I have outlined
>> what I believe needs to be done.  It may or may not be complete:
>> 
>> LLVM/Clang:
>> 1) Improve libobjc2 such that it can 
>>   a) function properly on a wider set of platforms.   This means 
>>  i) Correct build issues it has in on some environments. 
>>  ii) Simplifying the build of it on Windows 
>>   (i.e., don't require Visual Studio :))
> 
> Before dropping GCC support in GNUstep, 

As I understand it, the discussion is about the possibility of switching from 
GCC to Clang as the preferred compiler for new development.

That's a *very* different thing from what the phrase 'dropping GCC support' 
suggests.

There is no suggestion of rewriting all GNUstep code to require Clang; that 
would be silly.

Re: Clang/LLVM migration roadmap

[Richard Frith-Macdonald]

> On 6 Feb 2022, at 19:09, Fred Kiefer  wrote:
> 
> 
> 
>> Am 06.02.2022 um 01:14 schrieb Gregory Casamento :
>> 
>> There are a number of factors that are driving this:
>> --
>> 1) GCC lacks support for many memory management features that are commonly 
>> used today
>> 2) GCC's objective-c support is lagging behind and doesn't include support 
>> for @[], @{}, @autorelease, etc etc etc
>> 3) Lack of bug fixes in GCC's implementation of ObjC
>> 4) GCC team does not consider ObjC release critical and will and HAS 
>> released with broken support for building ObjC targets.  
>> All of these things are UNACCEPTABLE
> 
> Again I beg to differ. Of course the first two point are true and need to be 
> addressed. But I am not aware of any critical bug in gcc that is currently 
> hindering us. There are many missing features and this is really bad for 
> GNUstep and ObjC as a whole. As for the position of the gcc team on ObjC, 
> none of knows and we only may guess here. The one time where a gcc release 
> knowingly broke ObjC was ages ago. Maybe it could happen again, we just don’t 
> know. Stating something as a fact that is just a possibility is a rather 
> annoying habit of our times. Please don’t do so on the GNUstep mailing list.

Yes, I remember thinking (and should have said) that I know of no bugs in the 
GCC implementation (though of course there may be some), and that a bad release 
many years ago is not indicative of current or recent support.

However, I think it is fair enough to assume that, unless someone like us 
volunteers to add a major thing like ARC (or even something as simple as new 
syntactic sugar), it probably won't happen.

Re: Clang/LLVM migration roadmap

[Richard Frith-Macdonald]

> On 6 Feb 2022, at 09:35, Andreas Fink  wrote:
> 
> So to summarize up, we need to get libobjc2 properly working under MSYS2 and 
> we can continue with clang.
> What are the isuses with libobjc2 not working under MSYS2? From what I know 
> libobj2 should not have many dependencies on the operating system itself 
> (well memory management and multithreading but not much more I believe) but 
> more on the architecture. But thats a birds eye view...

I think general portability is an issue, not just MSYS.

Yes, there's the issue of architecture specific code in the runtime,  but 
additionally I have seen two problem areas:

1. building libobjc2
a. dependency on cmake and ninja ... easy to find packages for most systems, 
but definitely an annoyance
b. has failed to build with some compiler versions etc in the past, so we need 
to work out reliable toolchains for all platforms

2. runtime errors
I have had problems with getting things to run, the current one I am aware of 
is related to linker ... the runtime will fail with executable produced by 
common linkers under some conditions.  There also seems to be problems with C++ 
integration for exceptions and compiler bugs.

I do use clang/libobjc2 on a daily basis on gnu/linux amd64 with no problems at 
all, but it took a long time to get the right toolchain in place. We need this 
to be less fragile, so people can update parts of their toolchain without 
breakign things.

Re: failed tests in gnustep-gui

[Richard Frith-Macdonald]

> On 17 Jan 2022, at 21:15, Andreas Fink  wrote:
> 
> I get these failures while running gnustep-gui tests:
> 
> --
> gui/NSView/NSView_convertRect.m:
> Failed set:NSView_convertRect.m:100 ... problem in NView GNUstep
> converRect.
> 
> gui/NSView/NSView_frame_bounds.m:
> Failed set:NSView_frame_bounds.m:57 ... problem in NView GNUstep
> frame_bounds.
> 
> gui/NSView/NSView_frame_rotation.m:
> Failed set:NSView_frame_rotation.m:21 ... problem in NView
> GNUstep frame_rotation.
> 
> gui/NSView/scrollRectToVisible.m:
> Failed set:scrollRectToVisible.m:33 ... problem in NView GNUstep
> scrollRectToVisible.
> --- Running tests in gui/TextSystem ---
> 
> 967 Passed tests
>   8 Failed sets
>   3 Failed tests
> 
> 
> 
> They all fail in a line like this:
> 
> START_SET("NView GNUstep bounds_scale")
> 
> So in a macro somwhere.
> Any idea what this macro does?

You can just look in the header file (Testing.h) to see exactly what it does, 
but the summary is that it starts a region of code with an autorelease pool and 
exception handler and some bookkeeping to track things like the duration of 
tests.
Failed set generally means that an exception occurred somewhere in the region 
betwen the start and the end.  The full log may tell you where/what the 
exceptionb was.

Re: Dock app using distributed objects

[Richard Frith-Macdonald]

> On 7 Dec 2021, at 08:48, Gregory Casamento  wrote:
> 
> Riccardo,
> 
> Firstly, the dock is visually appealing, full marks. :)
> 
> 
> On Mon, Dec 6, 2021 at 3:03 PM Riccardo Canalicchio 
>  wrote:
> Hello,
> I have been thinking about how to have a live image representation of an app 
> for a dock application and I wanted to try with distributed objects.
> 
> But, secondly, I believe there is another, more lightweight, way that can be 
> used to do this aside from DO.  The issue I see here is requiring every app 
> to do it this way.  If you look in NSApplication you will see a reference to 
> NSIconView and NSIconWindow.  These classes display the changing icon in 
> WindowMaker (this is not an endorsement of wmaker, I would like a GS based 
> Dock outside of GWorkspace as well).  So, perhaps, it is possible to do this 
> without using Distributed Objects.   This is only a suggestion, I like where 
> you're going.

Yes ... I remmber from many, many years ago (way back when I was working on the 
GUI) I had this working as it worked in NeXTstep:  the miniwindow used to be a 
fully functional window that a NeXTstep app could write into while it is in the 
dock.  This was used to create visual indicators, in the dock, of the state of 
an application.

I also recall being annoyed because Apple removed this functionality from OSX 
and replaced it with a different mechanism (much more limited and less 
technically satisfying, but a simpler way to achieve a similar effect in 
practice), though I don't recall the details.  I'm pretty sure we moved to 
match the OSX implementation.  I expect this is what WindowMaker is working 
with.

Re: Swizzling Alloc

[Richard Frith-Macdonald]

> On 30 May 2021, at 17:59, Gustavo Tavares  wrote:
> 
> Hi All,
> 
> So—I am trying to use swizzling for my first ever and my goal is to swizzle 
> `alloc`. Why? I want to run a unqiued counter of where my objects are 
> allocated by analyzing the call stack symbols. Sort of like Valgrind so that 
> I can see where my program is leaking data—but I figured since I don't know 
> how to parse Valgrind Objective-C might be an easier way to get something 
> very similar.
> 
> Unfortunately when I follow this guide to swizzle the methods—I am getting a 
> segmentation fault. 
> https://newrelic.com/blog/best-practices/right-way-to-swizzle
> 
> He basically tell me to do: 
>> 
>> id gtkDebugAlloc(id self, SEL cmd) {  } 
>> 
>> {
>>  Method nsObjectAllocMethod = class_getClassMethod([NSObject 
>> class], @selector(alloc));
>>  IMP orginalAlloc = 
>> method_setImplementation(nsObjectAllocMethod,(IMP)gtkDebugAlloc);
>> }

That looks fine, and works for me.
So ... if you are getting a segmentation violation, it's probably 
occurring-in/caused-by your gtkDebugAlloc function (which must of course 
allocate and return suitable memory).

Try this:

static IMP originalAlloc;
static id gtkDebugAlloc(id self, SEL cmd)
{
  fprintf(stderr, "Here I am\n");
  return (*originalAlloc)(self, cmd);
}

// then later on 
{
 Method nsObjectAllocMethod = class_getClassMethod([NSObject class], 
@selector(alloc)); 
 originalAlloc = 
method_setImplementation(nsObjectAllocMethod,(IMP)gtkDebugAlloc);
}


You should see 'Here I am' printed whenever an object is allocated.

I suspect it's hard to beat valgrind at this (because parsing the stack and 
storing counts of allocations at particular locations is hard to do), but if 
you suceed in writing an efficient yool for that, it would be great.

Re: Bug in [NSScanner scanDouble:]

[Richard Frith-Macdonald]

> On 29 Dec 2020, at 09:32, Fred Kiefer  wrote:
> 
>  The code in NSScanner should have the correct implementation and 
> GSScanDouble should  just call that. This solution would require to allocate 
> and free an NSScanner object, and I am pretty sure that Richard wouldn’t like 
> the extra time spend on that.

Well I came to the conclusion that you were right to say that the -scanDouble: 
method of NSScanner needs the correct implementation.  This is mostly because a 
valid double can have a huge number of leading zeros, and can also have more 
precision digits than the double supports (OSX ignores excess precision and 
leading zeros).  It also means that everywhere the code was calling 
GSScanDouble() in NSString.m was incorrect (because the calling code was 
copying stuff into a buffer which might be too small).

So, I got rid of the function altogether, and added a private method that 
NSString can use to scan a double with less overhead (avoiding the 
creation/destruction of the NSScanner instance.  I hope performance is good 
enough: I think it should be, as I also made a small optimisation for scanning 
strings using the 8bit internal representation, which ought to speed up the 
most common case.

Re: Bug in [NSScanner scanDouble:]

[Richard Frith-Macdonald]

> On 29 Dec 2020, at 10:10, Richard Frith-Macdonald 
>  wrote:
> 
> 
> 
>> On 29 Dec 2020, at 09:32, Fred Kiefer  wrote:
>> 
>> Looks like the code of GSScanDouble and [NSScanner scanDouble:] differ a 
>> lot. Both are in the file NSScanner.m and it looks like the function has 
>> been corrected over the years to handle different cases a lot better. The 
>> NSScanner code is just a straight forward number scanning as you would 
>> expect.
>> 
>> The easiest solution would be to reuse GSScanDouble by scanning in a buffer 
>> all the characters for the double value and calling the function on that 
>> value (handling _decimal by replacing it with a dot). But somehow this feels 
>> like the wrong way around.
> 
> I think that probably *is* the way to go.  That way the NSScanner method 
> would be responsible for converting to a unicode character buffer from 
> whatever string representation it is handling (and finding the end of the 
> potential double), while the function would be responsible for ensuring that 
> the characters in the buffer actually represents a double.  We know the 
> maximum number of characters in a double, so we can use an on-stack buffer 
> and the whole thing would be reasonably efficient.

But having done that (having the method put data into a buffer and passing that 
buffer to the function), to the point where it builds/works,  I now think it's 
probably the wrong way to go.  The reason being that a string may contain a 
huge number of leading zeros (so requiring a very large buffer), and it would 
therefore make sense to have code which would read input character-by-character 
and discard leading zeros (and/or excess digits beyond the precision limits of 
a double) rather than buffering them all.

Re: Bug in [NSScanner scanDouble:]

[Richard Frith-Macdonald]

> On 29 Dec 2020, at 09:32, Fred Kiefer  wrote:
> 
> Looks like the code of GSScanDouble and [NSScanner scanDouble:] differ a lot. 
> Both are in the file NSScanner.m and it looks like the function has been 
> corrected over the years to handle different cases a lot better. The 
> NSScanner code is just a straight forward number scanning as you would expect.
> 
> The easiest solution would be to reuse GSScanDouble by scanning in a buffer 
> all the characters for the double value and calling the function on that 
> value (handling _decimal by replacing it with a dot). But somehow this feels 
> like the wrong way around.

I think that probably *is* the way to go.  That way the NSScanner method would 
be responsible for converting to a unicode character buffer from whatever 
string representation it is handling (and finding the end of the potential 
double), while the function would be responsible for ensuring that the 
characters in the buffer actually represents a double.  We know the maximum 
number of characters in a double, so we can use an on-stack buffer and the 
whole thing would be reasonably efficient.

Re: Can you compile a selection of files with ARC within a project as in OSX?

[Richard Frith-Macdonald]

> On 15 Nov 2020, at 15:55, Gustavo Tavares  wrote:
> 
> Hello!
> 
> Can you compile a selection of files with ARC within a project as in OSX?
> 
> Reading the docs it seems clear that this isn't possible.

The gnustep-make documentation tells you how you can use GS_WITH_ARC to control 
the use of ARC, globally for all your code, or on a per-project basis, with 
each more granular use taking precedence over a more generic use.

So it's not clear what you think isn't possible.  Please look at the 
gnustep-make documentation for details of how that interacts with other 
settings and for examples of how the behaviour for individual files can be 
overridden.

Re: Tutorials enhancement proposal : First Steps in GNUstep GUI Programming (2) : NSWindow, NSButton

[Richard Frith-Macdonald]

> On 10 Jun 2020, at 10:42, Patrick Cardona via Discussion list for the GNUstep 
> programming environment  wrote:
> 

> (2) In the method 'createWindow' :
> 
> - (void) createWindow
> {
> ...
> myWindow = [NSWindow alloc];
> 
>  /* Don't make a assignment of 'myWindow' again...
>  myWindow = */
>  /* So I kept only the message... */
>  [myWindow initWithContentRect: rect
>   styleMask: styleMask
>   backing: NSBackingStoreBuffered
>   defer: NO];

The correct code here is

myWindow = [NSWindow alloc];
myWindow = [myWindow initWithContentRect: rect
  styleMask: styleMask
  backing: NSBackingStoreBuffered
  defer: NO];

You *must* have the second assignment, because the initWithContentRect:... 
method may destroy the original window and return a new one.  maybe it would 
help for the tutorial to have a comment saying that.

If you find it aesthetically displeasing to have two assignments, you can write 
the code as

myWindow = [[NSWindow alloc] initWithContentRect: rect
  styleMask: styleMask
  backing: NSBackingStoreBuffered
  defer: NO];

Re: Objective-C Beginner's Guide

[Richard Frith-Macdonald]

> On 31 May 2020, at 20:52, Patrick Cardona via Discussion list for the GNUstep 
> programming environment  wrote:
> 
> Hi All experienced Objective-C Dev
> 
> I begun this Beginner Guide about Objective C :
> 
> http://gnustep.made-it.com/BG-objc/
> 
> But my beginning is not glorious...
> 
> pi@raspberrypi:~/CoursObjectiveC $ ls
> hello  hello.m
> pi@raspberrypi:~/CoursObjectiveC $ gcc -lobjc hello.m -o hello
> hello.m: In function ‘main’:
> hello.m:39:2: warning: ‘Greeter’ may not respond to ‘+new’
>  myGreeter=[Greeter new];
>  ^
> hello.m:39:2: warning: (Messages without a matching method signature
> hello.m:39:2: warning: will be assumed to return ‘id’ and accept
> hello.m:39:2: warning: ‘...’ as arguments.)
> hello.m:43:2: warning: no ‘-free’ method found
>  [myGreeter free];
>  ^
> pi@raspberrypi:~/CoursObjectiveC $ ./hello
> Erreur de segmentation
> 
> Is this Beginner's Guide up to date ?


It's old, but probably still OK.
You could also try the guide that comes with GNUstep-base; you should already 
have it on your system, but can also find it online at 
http://www.gnustep.org/resources/documentation/Developer/Base/ProgrammingManual/manual_1.html

Re: Apps don't load in GWorkspace

[Richard Frith-Macdonald]

> On 20 May 2020, at 19:59, Wolfgang Lux  wrote:
> 
> 
> 
>> Am 20.05.2020 um 18:24 schrieb Riccardo Mottola :
>> 
>> Hi,
>> 
>> Richard Frith-Macdonald wrote:
>>> I'm sure the install instructions say (or said) that make_services should 
>>> be in your .profile to run on login.
>>> When installing a new app, app developers should ensure it is run by the 
>>> install script.
>>> So the only time it would need to be run manually is when copying a new 
>>> application rather than installing it.
>> 
>> exactly - if you are building yourself "you should know", if you install a 
>> package, it should be in the "post install" of the respctive package 
>> installation tool
> 
> So you assume package maintainers are aware of this?

The standard documented mechanism of having it in the startup script is very 
well documented (similarly basic as sourcing GNUstep.sh for a developer), so 
it's not unreasonable to expect packagers to be aware.
If it's in .profile then the normal advice to log out and log in again works 
even if someone screws up when adding a new app.
This (presence in the shell login script) is really only needed for people not 
running a workspace manager though (ie if you want to use the command-line tool 
to launch apps).

> Either the current workspace application (so GWorkspace for the time being) 
> should update the services database a soon as it recognizes a new (or 
> updated) application,
In fact the workspace does that on startup, and -[NSWorkspace findApplications] 
does it on demand ... while the latter should never be necessary, it's a good 
to have failsafes.

> or, when there is no registered workspace manager, applications should do 
> that themselves.
This is of course impossible (catch 22) in order to have the app run 
make_services you must first have run make_services to be able to launch the 
app.
Unless you know the path to the app and launch it directly ... in which case it 
runs make_services if/when creating its shared NSWorkspace instance to andle 
interactions with the workspace application.

So, in order to *not* run make_services you need to:

have the environment set up by someone who has not read that you should run 
make_services in .profile
*and* not be running a workspace manager
*and* not have the app install script run it
Then, if you run it manually, it has to be an app that doesn't want to interact 
with the workspace and therefore doesn't create an NSWorkspace instance.

You can of course have a temporary issue if an app is just copied into place 
rather than being properly installed, but that should be automatically fixed as 
soon as you restart the desktop, log out/in, start any app which expects to 
interact with the desktop, or your desktop calls -findApplications.

I don't think this thread has anything to do with a problem with whether 
make_services has run, it sound more like an issue with having two incompatible 
configuration of the system in use (native system packages configured one way, 
new code built from source and configured another way).

Re: Apps don't load in GWorkspace

[Richard Frith-Macdonald]

> On 19 May 2020, at 00:45, Gregory Casamento  wrote:
> 
> We should change this so that make_services is run periodically.   
> Nevertheless this needs to be run anytime you add an application so that that 
> application's file mappings are added to the master list of mappings so that 
> NSWorkspace can open the appropriate application.
> 
> Alternatively you could add a periodic entry in crontab.  I have mine run 
> every 5 minutes.

I'm sure the install instructions say (or said) that make_services should be in 
your .profile to run on login.
When installing a new app, app developers should ensure it is run by the 
install script.
So the only time it would need to be run manually is when copying a new 
application rather than installing it.

Re: plmerge core dumps...

[Richard Frith-Macdonald]

> On 13 Feb 2020, at 14:15, David Chisnall  wrote:
> 
> On 13/02/2020 10:35, Richard Frith-Macdonald wrote:
>> Is it a bug in the linker?
> 
> It is, but it is a bug that shows up *only* with ld -r.  LLD did not support 
> ld -r for a long time and that made no difference to over 90% of the things 
> in the FreeBSD ports collection.  It is a very rarely used corner case for 
> the linker and so likely to be very poorly tested (it also has quite poorly 
> defined semantics, which is part of the problem).
> 
> GNUstep Make uses this for 'subprojects'.  We hit this early because -base 
> Additions is a subproject.  These are compiled as .o files and then linked to 
> form a single .o file using ld -r.  Most modern build systems would typically 
> just pass the list of .o files to the parent project to link, but GNUstep 
> Make tries to create a single subproject.o.
> 
> It is good that -base tests this corner case of -make, because it would 
> otherwise hit external users, but I am not convinced by the value of this 
> option in GNUstep Make overall (though, as I have said before, I am also not 
> convinced of the value of investing time and engineering resources in 
> maintaining a custom build system that does not compose well with any other 
> project's build system).

Thanks for that information.

My (limited) understanding of -r is that it's for incremental linking, where 
the file produced by the linker can itself be used to be linked into an 
executable. 

So is the problem then in the generation of the subproject rather than in the 
final linking?

If so, perhaps we could solve this by altering gnustep-make to add 
'-fuse-ld=gold' to the command line used to build a subproject (and perhaps 
when building a bundle)? 

Re: plmerge core dumps...

[Richard Frith-Macdonald]

> On 13 Feb 2020, at 09:44, Andreas Fink  wrote:
> 
> This is not a problem of gnustep but of objectiveC.
> Yes its a pain that the standard linker doesnt work. But it is what it is. 
> until someone fixes the standard linker we can't do much.

I'm not sure where the responsibility lies (maybe nobody knows and that's why 
it exists):
Is it a bug in the linker?
Is it a bug in clang for not invoking the linker correctly?
Is it a bug in gnustep-make for not passing some extra flag to clang to tell it 
how to invoke the linker correctly?

> This is mainly given by the fact that modern ObjC support in gcc is still 
> missing. clang does much better here but there where still some bugs in clang 
> before version 8 which can get you into trouble.
> 
> So golden rule is clang >= 8.0 and linker = ld.gold and it will work.

Yes, that works for me to build base/gui and quite a lot of other stuff, but 
not all my code by any means:  I find there are other libraries/tools that fail 
to link using ld.gold
Until I can figure out what to do about that, I can't migrate the codebase 
where I work to use the latest runtime :-(

Re: plmerge core dumps...

[Richard Frith-Macdonald]

> On 11 Feb 2020, at 13:47, David Chisnall  wrote:
> 
> On 11/02/2020 12:30, Richard Frith-Macdonald wrote:
>> clang -v reported that the normal, system linker was being used
> 
> FYI: On most GNU/Linux platforms, BFD is the 'normal, system linker'. For 
> example:
> 
> $ ld -v
> GNU ld (GNU Binutils for Debian) 2.31.1
> 
> This is the BFD linker on a Debian system.
> 
> $ ld.gold -v
> GNU gold (GNU Binutils for Debian 2.31.1) 1.16
> 
> This is gold on a Debian system.  It is installed by the binutils package, 
> but is not installed as the system linker.
> 
> $ ld -v
> LLD 8.0.1 (FreeBSD 366581-128) (compatible with GNU linkers)
> 
> This is LLD on a FreeBSD system.  It is the system linker.

Thanks.
Mine was a CentOS-7 system with 'alternatives' set to use ld.gold
I did have three toolchains installed (which may have confused thngs), but all 
three were set to use ld.gold
Only when I removed all copies of ld.bfd was I able to build gnustep-base to 
use the new ABI and have it not crash immediately on startup.
My best guess at an explanation is that I did something (in the distant past so 
I don't remember) that confused/broke the 'alternatives' system.

Something else worth noting wrt the core dump is that it's quite commonplace, 
when building/installing the core libraries, that if something is horribly 
broken in base it will show up as soon as you try to build gui and that runs 
plmerge: a plmerge segfault could have many causes, and I didn't mean to blame 
it on using the new ABI or the bfd linker.

Re: plmerge core dumps...

[Richard Frith-Macdonald]

> On 11 Feb 2020, at 11:46, Gregory Casamento  wrote:
> 
>  Linking service GSspell ...
> 3022 Creating GSspell.service/Resources...
> 3023 Creating GSspell.service/Resources/Info-gnustep.plist...
> 3024Segmentation fault (core dumped)
> 3025/home/travis/staging/share/GNUstep/Makefiles/Instance/service.make:141: 
> recipe for target 'GSspell.service/Resources/Info-gnustep.plist' failed
> 3026make[3]: *** [GSspell.service/Resou
> 
> -- 
> 
> I've been seeing this a lot locally and on CI.  Has there been a change which 
> is causing a segfault in plmerge?

This is where I first noticed a problem when using the new objc-2.0 ABI.
In my case David kindly let me know that the issue was that the bfd linker was 
failing to link the base additions library, causing a recursive exception 
initializing NSObject.
On my system it didn't *l,ook* like this was the case (clang -v reported that 
the normal, system linker was being used),  but rebuklding after removing all 
copies of the bfd linker from my system did solve the problem.

Re: Improving GNUstep tooling with Clang

[Richard Frith-Macdonald]

> On 28 Nov 2019, at 16:15, Frederik Seiffert  wrote:
> 
> Hi all,
> 
> In the wake of the recent discussions about GCC, Clang, and modern 
> Objective-C features, I wanted to share some observations and propose some 
> improvements.
> 
> As a recent newcomer to the GNUstep community, one of the things that made 
> building GNUstep difficult was understanding the various configuration 
> options and their implications and interdependencies, most notably the 
> different "library combos" and libobjc2 runtime versions, which e.g. depend 
> on the Clang version being used and affect which modern Objective-C language 
> features are supported.
> 
> With 2 language combos (gnu and ng) and 3 runtime versions (gcc, 1.9, 2.0), 
> this leaves Clang users with at least 5 different build variants, some of 
> which significantly differ in their abilities. In contrast, if I understand 
> it correctly GCC only supports one library combo and runtime. I could imagine 
> that this might also play a role in many people sticking to GCC with its 
> simplicity, and obviously it creates quite a large test surface that makes it 
> more likely for bugs to go unnoticed.

I think there's some confusion here.

gnu-gnu-gnu is the combo for classic objc (gcc and the old runtime)
ng-gnu-gnu is the combo for objc2 (clang and the new runtime)

We decided to adopt that simplified scheme a few years ago.  So while 
deveoplers are of course free to mess around with any combination of 
compilers/libraries/flags they like, there are really only those two variants 
supported for normal use.

With ng-gnu-gnu, gnustep-make lets you enable/disable ARC and you can 
experiment with the very latest runtime version using RUNTIME_VERSION. 

Yes the plan is to update the default runtime version for ng-gnu-gnu to be 2.0 
in the next release (though it would be good to have the 2.0 runtime build more 
easily/realiably first).
The reason ARC is not enabled by default is that it would break most existing 
software packages when building with ng-gnu-gnu, but maybe that could change in 
future.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Richard Frith-Macdonald]

> On 21 Nov 2019, at 08:32, David Chisnall  wrote:
> 
> 
>> On 20 Nov 2019, at 20:11, Gregory Casamento  wrote:
>> 
>> Derek
>> 
>> On Wed, Nov 20, 2019 at 1:44 PM Derek Fawcus 
>>  wrote:
>>> On Wed, Nov 20, 2019 at 10:52:36AM +, David Chisnall wrote:
 Oh, and with ARC, all of the C++ implementations have correct memory 
 management for Objective-C, for free.
>>> 
>>> While dropping support for GCC does not strike me as a problem,
>>> switching the core implementation to depend upon C++ may well do.
>> 
>> I'm not sure what to say to this other than LOL.  Given that C++ still 
>> doesn't have some of the dynamic features of even the original ObjC it seems 
>> quite impossible.  Also it contradicts the entire purpose of the 
>> framework...   moving on…
> 
> I think you are missing my point here.  C++ is a good language for low-level 
> abstractions, for abstract data types, and so on, with aggressive 
> compile-time specialisation and opportunities for optimisation at the low 
> level.  In contrast, Objective-C is a good language for providing stable 
> interfaces, for high levels of abstraction, and so on.

I strongly agree with this ... whie I detest C++ for general use, it is 
definitely great for extremely well defined low level stuff where you are never 
going to have to change/maintain the code because the requirements don't change.
I think it's dreadful for most higher level real-world projects where 
requirements change throughout the development process and beyond.
As far as I can see there's no reason it can't be used where clearly 
appropriate and banned everywhere else.

Re: Package building

[Richard Frith-Macdonald]

> On 20 Nov 2019, at 08:37, Andreas Fink  wrote:
> 
> 
> 
>> On 20 Nov 2019, at 08:59, Johannes Brakensiek  
>> wrote:
>> 
>> Hey Ivan,
>> 
>> thank you for your work and your explanations!
>> 
>> On 20 Nov 2019, at 3:10, Ivan Vučica wrote:
>> 
>>> Now... developers may need updated versions when developing their apps. I 
>>> remember Debian not shipping with NSViewController or NSWindowController 
>>> when I first came around -- but on the other hand, when I would cut a 
>>> release, an updated .deb would follow. (Not to mention our source code 
>>> became much more discoverable, so seeing if a class is missing is much 
>>> easier too.)
>>> 
>>> So when a developer needs a newer version so they can prepare a source 
>>> tarball for Debian to integrate... they can talk to us. We cut our release, 
>>> a Debian maintainer (e.g. Yavor) picks it up, the app gets picked up too, 
>>> everyone happy.
>>> 
>>> Yes, I would say developers are very welcome to advocate with maintainers 
>>> for a release if not cutting one blocks their app's release. :-)
>>> 
>>> And at this time, I am still here to help component maintainers with a 
>>> release. I may not do it on a tight schedule, but eventually I’ll find an 
>>> evening or two to tackle this kind of request.
>>> 
>>> Do you have a specific anecdote about something you wanted up to date, as a 
>>> binary, which wasn’t in your favorite distro?
>> 
>> The problem simply is that f.e. Debian ships libs that are build with GCC 
>> and thus are missing any of the new language features. I understand you are 
>> doing this for compatibility with other processor platforms. But this leads 
>> to the problem that any app developer who wants to build a new app based 
>> upon the clang ABI has to build and ship everything on his own. I really 
>> think this is a show blocker for attracting new developers (or even users). 
>> Or did I miss anything here?
>> 
>> Johannes
>> 
> 
> 
> I can completely agree on this statement. Due to modern code using ARC 
> everywhere, the gnustep coming with Debian (which is  my main deployment 
> platform) is usually a problem. I always have to make sure its not installed 
> and install my own packaged version. On the other hand I have not seen anyone 
> using ObjectiveC without ARC these days.. Its nice to have for nostalgia but 
> ARC has solved a million problems for me in my code over the last decades. So 
> today, I would not even think to do anything with gnustep without clang.
> 
> Having a gnustep which works with arc and without arc would be ok. but 
> shipping packaged versions with libraries which can not work with ARC is a 
> show stopper.
> 
> And when GNUStep wants to continue following the development of OSX's 
> platform, ARC is there since more than a decade and everyone depends on it. 
> So if anyone wants to port OS X code to Linux and considers GNUStep as a 
> logica platform, then ARC support is a must.

I have never used a mixed configuration, but from what David's said in the past 
(I expect he will correct me if I'm wrong),  for the libraries ARC should work 
whether or not GNUstep is built with clang.
The libraries do not need to use ARC internally in order to be used by software 
that is built for ARC, as long as they are built for the same runtime.
But if a distribution provides gnustep-make configured to use gcc, you would 
need to install/configure your own version to use clang.

Re: NSSecureCoding....

[Richard Frith-Macdonald]

> On 9 Nov 2019, at 13:04, Matt Rice  wrote:
> 
> On Sat, Nov 9, 2019 at 12:38 PM Richard Frith-Macdonald
>  wrote:
>> 
>> 
>> 
>>> On 9 Nov 2019, at 11:40, Gregory Casamento  wrote:
>>> 
>>> Does anyone have any clue how we are going to tackle NSSecureCoding?
>> 
>> I don't really understand it.
>> 
>> The basic principle of it is simple: make hacking of archives by an attacker 
>> harder by preventing the attacker from substituting different classes into 
>> the archive.
>> 
>> This uses a new -decodeObjectOfClass:forKey: method to decode objects of a 
>> specific class (easy to implement), plus a trivial method/property 
>> -supportsSecureCoding  to say whether a class does secure coding or not.
>> 
>> So the alterations are simple, but extensive and time consuming to implement 
>> (we'd need to retrofit/add this to decoding of most classes).
>> 
>> My problem with it is that it's hard to see how it can work when it comes to 
>> collections ... yet the Apple documentation says that (for instance) NSSet 
>> supports secure coding.
>> That should mean that an NSSet decodes its contents with 
>> -decodeObjectOfClass:forKey: specifying the class of each object the set 
>> holds.
>> However, a set holds arbitrary values (any class), so presumably it would 
>> have to decode its contents using NSObject as the class, effectively that's 
>> the same as using -decodeObjectForKey: and allows unconstrained alteration 
>> of the set contents by an attacker, defeating the whole point of secure 
>> coding.  It suggests to me that having arbitrary collection classes claim to 
>> implement NSSecureCoding would be misleading/wrong.
>> 
>> So presumably I'm missing/misunderstanding something about this.
> 
> Weird problem, but interesting I suppose,
> It looks like (according to this stack overflow)
> https://stackoverflow.com/questions/24376746/nssecurecoding-trouble-with-collections-of-custom-class
> 
> if you use decodeObjectOfClasses:forKey: and the set of Class objects
> passed to 'decodeObjectOfClasses:' contains *both* the collection
> class,
> and the classes of the objects which form the contents, it seems like
> you can limit it to a specific set of 'subject' classes...

Interesting.  I had missed seeing that method.  But it does look like that's 
how they intend it to work.

It seems a badly designed API to me (I'd have gone with something like 
-decodeContainerOfClass:withContentsOfClasses:forKey:).

I guess we'd need to reverse-engineer how it actually works. The immediate 
question for me is that, if the set of classes contains the class of the 
container, does that mean that the contents may also be of the same class as 
the container, or does it mean that the contents may be of any of the classes 
in the set apart from that of the container?
If the former, then you can't (for instance) securely decode an array of 
strings, because the array might contain arrays.
If the latter, then you can't decode an array containing both strings and 
arrays.

Re: NSSecureCoding....

[Richard Frith-Macdonald]

> On 9 Nov 2019, at 11:40, Gregory Casamento  wrote:
> 
> Does anyone have any clue how we are going to tackle NSSecureCoding?

I don't really understand it.

The basic principle of it is simple: make hacking of archives by an attacker 
harder by preventing the attacker from substituting different classes into the 
archive.

This uses a new -decodeObjectOfClass:forKey: method to decode objects of a 
specific class (easy to implement), plus a trivial method/property 
-supportsSecureCoding  to say whether a class does secure coding or not.

So the alterations are simple, but extensive and time consuming to implement 
(we'd need to retrofit/add this to decoding of most classes).

My problem with it is that it's hard to see how it can work when it comes to 
collections ... yet the Apple documentation says that (for instance) NSSet 
supports secure coding.
That should mean that an NSSet decodes its contents with 
-decodeObjectOfClass:forKey: specifying the class of each object the set holds.
However, a set holds arbitrary values (any class), so presumably it would have 
to decode its contents using NSObject as the class, effectively that's the same 
as using -decodeObjectForKey: and allows unconstrained alteration of the set 
contents by an attacker, defeating the whole point of secure coding.  It 
suggests to me that having arbitrary collection classes claim to implement 
NSSecureCoding would be misleading/wrong.

So presumably I'm missing/misunderstanding something about this.

Re: Problem with GNUtls 3.6.7

[Richard Frith-Macdonald]

> On 27 May 2019, at 11:11, Fred Kiefer  wrote:
> 
> I have GNUTLS 3.6.7 on my machine as well, but never had an issue with it. 
> Are you sure that you did reconfigure and recompile GNUstep base from 
> scratch? Perhaps give it another try and report back. (Remember to use „make 
> clean“ first!)
> 
> Hope this helps,
> Fred
> 
>> Am 27.05.2019 um 02:00 schrieb Germán Arias :
>> 
>> Some days ago my system (PCLinuxOS) update the GNUtls library to version
>> 3.6.7. And now the gnustep apps don't work. So, I try to recompile all,
>> but now I get the error:
>> 
>> Linking tool autogsdoc ...
>> /usr/bin/ld: ../Source/./obj/libgnustep-base.so: undefined reference to
>> `gnutls_anon_allocate_client_credentials@GNUTLS_3_4'
>> 
>> Is this a problem with the gnutls library? Or gnustep is not compatible
>> with this version of gnutls?
>> 

I'm going to guess that where the loader is complaining about a missing symbol 
containing GNUTLS_3_4 it's that the code was linked with version 3.4.? of the 
library and what is now installed is 3.6.7

That would mean that things have *not* been recompiled/rebuilt.  Since it's the 
base library that's linked with gnutles (unless other stuff is linked with it), 
My guess is that what's required in gnustep-base is a
make clean
make install
sequence.
 


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: FreeBSD ports for GDL2 and GSWeb

[Richard Frith-Macdonald]

> On 27 May 2019, at 12:07, Edwin Ancaer  wrote:
> 
> Hello,
> 
> the linker problem is solved as was described by David. But as my knowledge 
> of FreeBSD / Unix is limited, every new problem is taking lots of time to 
> investigate. 
> 
> The one haunting me now is the fact that I have to run the poudriere command  
> to test my port for renaissance as root  and that for root,


I think the 'proper' fix is to correct that so that it doesn't run as root, but 
runs as your normal account (since it's generally a bad idea to do things as 
root).
However, since I don't know your particular system setup, I'll assume that you 
have to be running as root and gnustep isn't set up for root:


> the GNUStep environment is not defined.
> 
> The GNUmakefile of libs-renaissance contains a test on the existence of a 
> variable named GNUSTEP-MAKEFILES:

So, you simply need to define the environment variable to contain the name of 
the correct directory.
If you don't know/can't remember where you installed gnustep. the simplest way 
to find the name of the directory is to log in as the account for which you 
installed it, and run

gnustep-config --variable=GNUSTEP_MAKEFILES

I suppose that might not work (if you didn't install the software at all, and 
gnustep-config can't be found).  In which case you need to find where you 
installed things some other way.
eg.
 find / -name GNUstep.conf -print

Then look in that file to see what GNUSTEP_MAKEFILES is configured to.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: How to add a defaults database to a theme ?

[Richard Frith-Macdonald]

As an example, the Resources/Info.plist might control window decorations with:

{
GSThemeDomain = {
GSBackHandlesWindowDecorations = NO;
};
}

and have the default theme colors (including transparency) archived into:

Resources/ThemeColors.clr
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: How to add a defaults database to a theme ?

[Richard Frith-Macdonald]

> On 10 May 2019, at 12:24, Bertrand Dekoninck  
> wrote:
> 
> On 2019-05-10 13:06:02 +0200 Fred Kiefer  wrote:
> 
>> Hi Bertrand,
>> 
>> I think you are misreading the compiler warning. This just complains that 
>> the 
>> class that this method is on already has an instance variable with the name 
>> „defaults“. You should just use a different name for your local variable 
>> instead. Maybe something like „user_defaults“?
>> 
>> Hope this helps,
>> Fred
> Thanks,
> 
> I can get rid of the warning in this way, but I think my problem is 
> different. 
> In the code hereafter, is standardUserDefaults the database of the theme, or 
> the database of the app using the theme ? If it's the theme 's one, how could 
> I write to it with the command line. Should I use the bundle identifier ?

NSUserDefaults has multiple databases (called 'domains') in a list which 
defines their order of precedence, so when you ask for a default, and multiple 
domains in the list contain the default name, you get the correct value 
returned (the one from the first domain that contains a value for the key).

The normal order of the important domains here is

Command line arguments,  Application, NSGlobalDomain, GSThemeDomain, 
Registration (hard coded and set on application startup)

GSThemeDomain is set up by your theme (information in a property list in the 
theme bundle) and changes whenever a new theme is made active in an app, so to 
get the behavior you want, you need zero coding, you just have to put the 
key/value pair into your GSThemeDomain and it will be used unless the user 
overrides it by setting a value in a higher precedence domain (eg on the cmmand 
line).
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: How to add a defaults database to a theme ?

[Richard Frith-Macdonald]

> On 10 May 2019, at 11:39, Bertrand Dekoninck  
> wrote:
> 
> Hi, everyone, I'd like to add some default values to the rik.theme, writable 
> with the "defaults" tool.
> I wanted to add a transparency level to the top menu bar, which would be 
> editable. I thought I could do something like this :
> 
> - (NSColor *) menuBackgroundColor
> {
>  float transparency = 1.0;
>  NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults]; 
>   if ([defaults floatForKey:@"menubartransparency"])
>{
>  transparency = [defaults floatForKey:@"menubartransparency"];
>  }
> 
>  NSColor *color = [NSColor colorWithCalibratedRed: 0.992 green: 0.992 blue: 
> 0.992 alpha: transparency];
>  return color;
> }

The GSTheme method -menuBackgroundColor already does everything you want, so 
there's no coding to do for this.
The correct way to set a default color that should be overridable in the 
defaults system, is to add it as a default in the GSThemeDomain.
If you use Thematic.app, you have a GUI to do that for you (it tets you define 
custom colors for all the elements of your theme).
Otherwise you need to edit your bundle resources to specify the color you want 
as the menuBackgroundColor default.

> I get then a warning :  "local declaration of ‘defaults’ hides instance 
> variable"

I imagine the rik theme already adds 'defaults' as an instance variable of the 
theme, and this is just warning you that your local variable will be used 
rather than the instance variable.

> And when I read the documentation, I see that [NSUserDefaults 
> standardUserDefaults] is for the current app and user.
> A theme is not an app but a bundle. rik dosn't have such thing as an app 
> controller to initiate the database at start-up. Can I create a defaults 
> database for it, and how ? 

The defaults are defined in the GSThemeDomain dictionary of your theme's 
Info.plist and colors are defined  in various other resource files in the theme 
bundle.
You can look at the GSTheme source code (GUI) and in the Thematic.app source 
code to see how it all works.
Alternatively, it might be easier to use Thematic.app to create a simple 
code-free theme where you change the color of the menus, then examine the 
resources inside that theme to see how it fits together.
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: clang versions for libobjc2

[Richard Frith-Macdonald]

> I have to say that the setup using gnustep-make is very problematic for me. 
> It's kind of impossible to figure out what kind of compiler options are being 
> set and to verify if it does build everything as it should.  Things are 
> spread over several make files in several directories, some config files, 
> some environmental variables. The output nicely tells you how many % is left 
> but you can't see what it compiles how if you need to verify if a parameter 
> is passed along correctly. At least I have not found any way.

'make messages=yes' prints out what make actually does (ie what the actual 
compiler/linker commands are).
This is covered in step 4 of the first minitutorial about using it.

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: FOSDEM

[Richard Frith-Macdonald]

> On 30 Jan 2019, at 17:52, Ivan Vučica  wrote:
> 
> It sounded like there will be only Lars and myself at FOSDEM. *shrug* We can 
> just meet ad-hoc.

I hope you enjoy it.
Sorry I can't make it this year (I hope to do so next year).


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: gui apps segfault on Linux/x86/clang/libobjc2

[Richard Frith-Macdonald]

> On 29 Nov 2018, at 23:45, Riccardo Mottola  wrote:
> 
> Hi,
> 
> on plain Linux/x86, using clang, a simple gui app like Ink fails to start:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0xb3ecb101 in xcb_writev () from /usr/lib/libxcb.so.1
> (gdb) bt
> #0  0xb3ecb101 in xcb_writev () from /usr/lib/libxcb.so.1
> #1  0xb40653ce in _XSend () from /usr/lib/libX11.so.6
> #2  0xb40659c1 in _XReply () from /usr/lib/libX11.so.6
> #3  0xb404b45e in XGetWindowProperty () from /usr/lib/libX11.so.6
> #4  0xb404a253 in XGetIconSizes () from /usr/lib/libX11.so.6
> #5  0xb443ba49 in -[XGServer(WindowOps) iconSize] (self=0x8434cd4, 
> _cmd=0xb7f74b18 <.objc_selector_list+64>)
>at XGServerWindow.m:4565
> #6  0xb7d418ce in GSGetIconSize () from 
> /System/Library/Libraries/libgnustep-gui.so.0.26
> #7  0xb7a56180 in +[NSAppIconView initialize] () from 
> /System/Library/Libraries/libgnustep-gui.so.0.26
> #8  0xb714015c in objc_send_initialize () from 
> /System/Library/Libraries/libobjc.so.4.6
> #9  0xb714c4d8 in slowMsgLookup () from 
> /System/Library/Libraries/libobjc.so.4.6
> #10 0xb71525e1 in objc_msgSend () from 
> /System/Library/Libraries/libobjc.so.4.6
> #11 0xb7a6243d in -[NSApplication(Private) _appIconInit] () from 
> /System/Library/Libraries/libgnustep-gui.so.0.26
> #12 0xb7a57e3b in -[NSApplication _init] () from 
> /System/Library/Libraries/libgnustep-gui.so.0.26
> #13 0xb74551a2 in -[NSObject performSelector:withObject:] () from 
> /System/Library/Libraries/libgnustep-base.so.1.25
> #14 0xb74eb575 in -[NSObject(NSThreadPerformAdditions) 
> performSelector:onThread:withObject:waitUntilDone:modes:] ()
>   from /System/Library/Libraries/libgnustep-base.so.1.25
> #15 0xb74eb1ef in -[NSObject(NSThreadPerformAdditions) 
> performSelectorOnMainThread:withObject:waitUntilDone:modes:] ()
>   from /System/Library/Libraries/libgnustep-base.so.1.25
> #16 0xb74eb294 in -[NSObject(NSThreadPerformAdditions) 
> performSelectorOnMainThread:withObject:waitUntilDone:] ()
>   from /System/Library/Libraries/libgnustep-base.so.1.25
> #17 0xb7a58220 in -[NSApplication init] () from 
> /System/Library/Libraries/libgnustep-gui.so.0.26
> #18 0xb7a579bf in +[NSApplication sharedApplication] () from 
> /System/Library/Libraries/libgnustep-gui.so.0.26
> #19 0xb7a2c6f5 in NSApplicationMain () from 
> /System/Library/Libraries/libgnustep-gui.so.0.26
> #20 0x0804aae0 in main (argc=, argv=, 
> env=) at main.m:33
> 
> I somehow have a de-ja-vu about iconsize, but it was fixed by Wolfgang Months 
> ago!
> 
> What's wrong??

Segmentation fault inside the X code. not in the GNUstep code.

That (assuming it's not an X bug), suggests corrupt memory or something like 
that.  Possibly a memory error in GNUstep code, possibly incorrect/multiple 
library versions linked in to the binary (eg the main executable and a bundle 
having different versions of the same library linked).

I'd suggest valgrind to look form emory corruption and looking at all the 
libraries linked to the executables/bindles in use (though rebuilding 
*everything* from scratrch will usually fix library version issues).
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Building 64-bit on Windows

[Richard Frith-Macdonald]

> On 29 Oct 2018, at 22:26, Fred Kiefer  wrote:
> 
> 
>> Am 29.10.2018 um 22:26 schrieb Sam Izzo :
>> Thanks for your reply. I had seen some posts in the archives of the mailing 
>> list that made it sound like it was possible but I guess based on what you 
>> and David have written it's currently not possible to generate a 64-bit 
>> executable/DLL. I think for our project we'll have to go down the more 
>> painful path which is to convert all the Obj-C code to C#!
> 
> 
> There is a script in the GNUstep repository to set up a WIn64 environment to 
> compile GNUstep 
> https://github.com/gnustep/tools-scripts/blob/master/install-dependencies-msys2-64bit
> But as I don’t use Windows myself I am unsure whether that actually works or 
> not.

It did last time I used it (many months ago).  Generally there should be no 
problem using a 64bit environment if you use gcc and the traditional ObjC 
runtime.
It's buildinga 'next gen' setup, using clang and the new libobjc2 runtime, 
that's not quite there yet.
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Trouble building base with clang

[Richard Frith-Macdonald]

> On 21 Oct 2018, at 23:46, Philip George  wrote:
> 
> Steppers,
> 
> I'm stuck trying to build GNUstep using clang on Raspbian 9 (Debian) running 
> on ARM 7.
> 
> Here is the guide I'm using (which even after a couple of years is still 
> pretty good, save for a couple of caveats due to changes since its 
> publication)...
> 
> http://wiki.gnustep.org/index.php/Building_GNUstep_with_Clang


I edited that obsolete page to reflect current instructions.
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: does method invocation involve a lock?

[Richard Frith-Macdonald]

> On 21 Sep 2018, at 15:49, Tom Sheffler  wrote:
> 
> This question is for my own research: I’m curious about whether invoking [obj 
> method] can block.  If obj is allocated, and method is simple, does method 
> invocation involve a lock.
> 
> I think the answer is YES.  But I looked at the source code for objc_msgSend 
> and didn’t see anything that looked like it acquired a lock.

The answer is usually NO, but the first time you send any method to a class the 
+initialize method of that class is implicitly called, and that operation is 
implicitly lock protected.  If you are worried about that, the simple solution 
is to make sure that classes you are concerned about are initialised at the 
start of your program (eg by calling the +class method) , so that code 
executing later can be confident that there won't be unexpected blocking.
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: segmentation failure plmerge / building libs back

[Richard Frith-Macdonald]

> On 10 Aug 2018, at 10:40, Riccardo Mottola  wrote:
> 
> Hi,
> 
> I just updated my Gentoo box (i386) with compiler, libraries, kernel, etc. So 
> I reconfigured and rebuilt all GNUstep.
> 
> make is configured with:
> ./configure --prefix=/ --with-layout=gnustep --with-library-combo=ng-gnu-gnu 
> CC=clang CXX=clang++
> 
> 
> Everything is compiled with clang6 and "ng runtime" is enabled (or we get 
> other porblems with libobjc2 which I did not get sorted out with David yet)
> 
> When building gnustep back I get:
> 
>  Creating libgnustep-back-026.bundle/Resources/Info-gnustep.plist...
> /bin/sh: line 2:  8299 Segmentation fault  plmerge 
> libgnustep-back-026.bundle/Resources/Info-gnustep.plist 
> libgnustep-back-026Info.plist
> 
> which can be reproduced on the command line:
> 
>  $ plmerge libgnustep-back-026.bundle/Resources/Info-gnustep.plist 
> libgnustep-back-026Info.plist
> Segmentation fault
> 
> the executable itself runs:
> 
>  $ plmerge
> Usage: plmerge [destination-file] [input-file ...]
> 
> 
> so it dies when acutally trying to do something :)
> 
> THis in the debugger:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 
> (gdb) bt
> #0  0xb7b76274 in GSPrivateFormat (s=0xbfffdc24, format=0xbfffe44c,
> ap=0xbfffecb0 " 
> \231\365\267,\231\365\267T\236\365\267\210\221\365\267\037\350\273\267\320\003\016\b@\032\275\267$\217\365\267\060\217\365\267T\236\365\267P\220\365\267D\220\365\267\024h\"\b.\a\324\267\030\217\365\267\360\217\365\267\344\217\365\267\330\217\365\267\314\217\365\267\300\217\365\267\264\217\365\267\f\217\365\267\250\217\365\267\234\217\365\267\220\217\365\267\204\217\365\267x\217\365\267`\217\365\267l\217\365\267T\217\365\267<\217\365\267\354\220\365\267\340\220\365\267\324\220\365\267\310\220\365\267\274\220\365\267\260\220\365\267\244\220\365\267\230\220\365\267\214\220\365\267
>  
> \220\365\267\200\220\365\267\024\220\365\267t\220\365\267h\220\365\267\070\220\365\267,\220\365\267\374\217\365\267\\\220\365\267\214\237\365\267"...,
>  locale=0x0) at GSFormat.m:1046
> #1  0xb7b8c53e in -[GSPlaceholderString initWithFormat:locale:arguments:] 
> (self=0x81722e4,
> _cmd=0xb7f90714 <.objc_selector_list+992>, format=0xb7f59194 
> <.objc_str.170>, locale=0x0,
> argList=0xbfffecb0 " 
> \231\365\267,\231\365\267T\236\365\267\210\221\365\267\037\350\273\267\320\003\016\b@\032\275\267$\217\365\267\060\217\365\267T\236\365\267P\220\365\267D\220\365\267\024h\"\b.\a\324\267\030\217\365\267\360\217\365\267\344\217\365\267\330\217\365\267\314\217\365\267\300\217\365\267\264\217\365\267\f\217\365\267\250\217\365\267\234\217\365\267\220\217\365\267\204\217\365\267x\217\365\267`\217\365\267l\217\365\267T\217\365\267<\217\365\267\354\220\365\267\340\220\365\267\324\220\365\267\310\220\365\267\274\220\365\267\260\220\365\267\244\220\365\267\230\220\365\267\214\220\365\267
>  
> \220\365\267\200\220\365\267\024\220\365\267t\220\365\267h\220\365\267\070\220\365\267,\220\365\267\374\217\365\267\\\220\365\267\214\237\365\267"...)
>  at GSString.m:1588
> #2  0xb7ca9482 in -[NSString initWithFormat:] (self=, 
> _cmd=, format=)
> at NSString.m:1366
> #3  0xb7bbf09c in +[NSBundle initialize] (self=, 
> _cmd=) at NSBundle.m:1180
> #4  0xb79da15c in objc_send_initialize () from 
> /System/Library/Libraries/libobjc.so.4.6
> #5  0xb79e64d8 in slowMsgLookup () from 
> /System/Library/Libraries/libobjc.so.4.6
> #6  0xb79ec5e1 in objc_msgSend () from 
> /System/Library/Libraries/libobjc.so.4.6
> #7  0xb7b665e0 in GSLanguageFromLocale (locale=) at 
> GSLocale.m:264
> #8  0xb7cdc44f in +[NSUserDefaults standardUserDefaults] (self= out>, _cmd=) at NSUserDefaults.m:995
> #9  0xb7c088e5 in -[NSDictionary writeToFile:atomically:] (self= out>, _cmd=, path=,
> useAuxiliaryFile=) at NSDictionary.m:1096
> 
> (gdb) p (size_t) nspecs_done
> $1 = 0
> (gdb) p nspecs
> $2 = 
> 
> 
> Any ideas? trying to understand if this is a base issue or a runtime/libobjc2 
> issue
> 
> It actually comes from libobjc which calls base..
> 
> I tried compiling with debug to get more information in the stacktrace, but 
> the problem"goes away" confirming some kind of memory issue!
> 
> Last thingI tried was running plmerge with valgrind and found:
> ==10969== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==10969== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
> ==10969== Command: plmerge 
> libgnustep-back-026.bundle/Resources/Info-gnustep.plist 
> libgnustep-back-026Info.plist
> ==10969==
> ==10969==
> ==10969== HEAP SUMMARY:
> ==10969== in use at exit: 2,237,034 bytes in 13,761 blocks
> ==10969==   total heap usage: 24,707 allocs, 10,946 frees, 5,072,188 bytes 
> allocated
> ==10969==
> ==10969== LEAK SUMMARY:
> ==10969==definitely lost: 90,396 bytes in 2,034 blocks
> ==10969==indirectly lost: 0 bytes in 0 blocks
> ==10969==  possibly lost: 582,205 bytes in 2,440 blocks
> ==10969==still reachable: 1,564,433 bytes in 9,287 blocks
> ==10969== 

Re: Crash on app start due to icon

[Richard Frith-Macdonald]

> On 1 Aug 2018, at 07:41, Riccardo Mottola  wrote:
> 
> Hi,
> 
> after having upgraded base, gui, back on Ubuntu I observe the followiing 
> crash when any GUI app is started.
> I am running windowmaker.
> 
> This smells to be related to the "app icon fix".given the trace below calling 
> the new method.
> 
> Riccardo
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7b3b1a6 in -[NSApplication setApplicationIconImage:] (
>self=0xb7b384f7 <-[NSApplication(Private) _loadAppIconImage]+503>,
>_cmd=0x81ba588, anImage=0xb7ed3238 <_OBJC_SELECTOR_TABLE+3256>)
>at NSApplication.m:2392

Of course my situation is probably wildly different, but when I read this email 
I checked Ink.app with the latest base from git, then with the latest gui, then 
with the latest back.
After each update from git Ink.app started up normally.
So at least on my system (CentOS-7, 64bit) the x11/cairo backend seems to be OK.
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: NSGenericException: lock

[Richard Frith-Macdonald]

> On 24 Jul 2018, at 21:15, bertrand.dekoni...@gmail.com wrote:
> 
> 
> 
>> Le 24 juil. 2018 à 19:29, Patrick CARDONA  a 
>> écrit :
>> 
>> Hi All,
>> 
>> Sometimes, this Exception is occurring :
>> 
>>> NSGenericException: lock 
>>> '/tmp/GNUstepSecure1000/GSLaunchedApplications.lock' already broken
>> 
>> Then, at the next attempt to run the app, nothing worse happen, and things 
>> seem to go on without errors.
>> Should I consider something is badly set ?
>> Where ?
>> 
>> Bye !
>> Patrick
>> 
>> 
> This is a known bug already fixed in current gnustep. This threading issue is 
> annoying but almost harmless.
> Bertrand 

It was being reported quite a bit a while back, and I'm pretty sure it's fixed 
now (I've seen no problems with it since the fix in June last year).
Using a release rather than trunk, you would need the gnustep-base-1.25.1 
bugfix release from last December.
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: signal SIGSEGV, Segmentation fault

[Richard Frith-Macdonald]

> On 22 May 2018, at 13:55, Andreas Höschler  wrote:
> 
> Hi Richard,
> 
>>> Aha, interesting. But this still rings no bell (no idea how this could be).
>> 
>> Well, anything that overwrite the memory location in which 'self' is stored 
>> could cause this.
>> The most common thing (as suggested by Wolfgang) would be if the object was 
>> deallocated and the memory re-used (a retain/release error),
> 
> The object is not deallocated as I have shown with a log message in -dealloc. 
> 
>> but buffer overruns could also corrupt the memory.
>> Fred's suggestion of running under valgrind should help find the problem in 
>> either case.
> 
> This gave me nothing (see below).
> 
> valgrind reports
> 
> 
> 2018-05-22 11:23:16.323 TimberNav[7685:7685] MapView drawRect {x = 0; y = 0; 
> width = 817; height = 334} ... _osmDrawing 0
> 2018-05-22 11:23:16.327 TimberNav[7685:7685] After super drawRect:rect
> 2018-05-22 11:23:16.328 TimberNav[7685:7685] bums
> ==7685== Use of uninitialised value of size 4
> ==7685==at 0x8064DC2: _i_MapView__drawRect_ (MapView.m:168)
> ==7685==by 0xBEAD8617: ???

Well it tells you that some uninitialised value is used at line 168 ... 

We already knew that, but I guess the fact that there's no problem reported 
preceding it means that there's no obvious memory management/corruption issue 
like a buffer overrun on the heap, and something is specifically setting that 
location in memory.

You might need to actively debug the program to find out what's going on ... 
use gdb to break at the start ofd the method and then step through, instruction 
by instruction, examining key values to see at what point things change.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: signal SIGSEGV, Segmentation fault

[Richard Frith-Macdonald]

> On 22 May 2018, at 13:09, Andreas Höschler  wrote:
> 
> Hi Wolfgang,
> 
>> From the self pointer in the call frame:
>>  self=0xb7ca746e <-[NSView displayRectIgnoringOpacity:inContext:]+318>
>> gdb resolves this address to an address in the code of the 
>> displayRectIgnoringOpacity:inContext: method from the NSView class. :-)
> 
> Aha, interesting. But this still rings no bell (no idea how this could be).

Well, anything that overwrite the memory location in which 'self' is stored 
could cause this.
The most common thing (as suggested by Wolfgang) would be if the object was 
deallocated and the memory re-used (a retain/release error), but buffer 
overruns could also corrupt the memory.
Fred's suggestion of running under valgrind should help find the problem in 
either case.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Linking frameworks does not work

[Richard Frith-Macdonald]

> On 2 May 2018, at 16:10, Andreas Höschler  wrote:
> 
> 
> Thanks a lot. I added
> 
>[SRMailDelivery sendMailFrom:@"asas" to:@"asas" subject:@"asas" 
> body:@"asas" attachmentsAndFilenames:nil];
> 
> to the code and this indeed forced SRFoundation to be linked in. The 
> execption happens now later when trying to call a category method of just 
> another framework. 
> 
> This is indeed painful and annoying and has not always been that way in the 
> past, not on Solaris with GNUstep make and also not on Debian and Kubuntu and 
> definitely not on MacOSX. 

I think it *has* always been the case on GNU/Linux (which includes Debian and 
Kubuntu) as it's a function of how the system tools resolve symbols, not a 
function of gnustep-make.
Certainly I recall having to explicitly reference classes to do that in the 
1990s

> Does this mean that I have to define a dummy class in each framework and 
> include calls to these dummy classes for every 12 frameworks I have in use at 
> app launch? How annoying and dirty is that? :-( There is no cleaner solution?

Lookingt at gnustep-make (frameword.make), it creates a dummy class in each 
framework anyway (to hold information needed by NSBundle).  Perhaps you could 
leverage that.
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Accessing array members without the use of objectAtIndex

[Richard Frith-Macdonald]

> On 14 Apr 2018, at 13:46, David Chisnall  wrote:
> 
> Hi Tyler,
> 
>> On 14 Apr 2018, at 00:03, tyler mclean  
>> wrote:
>> 
>> Greetings developers,
>> 
>> I want to preface this question by saying that this project is
>> impressive. My question is, is there a way to access members of
>> NSArray or NSMutableArray like an array with the GNUstep framework or
>> is that a function that currently only sits with the current Apple
>> architecture of the language/libraries?
>> 
>> e.g
>> NSMutableArray *myArray = [[NSMutableArray alloc] init]; //This will
>> be an array of NSStrings
>> . . .
>> NSLog(@"%@", myArray[0]);
>> 
>> instead of
>> 
>> NSLog(@"%@", [myArray objectAtIndex:0]);
>> 
>> while this particular example does not create much bloat, repeated
>> need to access members can make code substantially larger than that of
>> it's counterpart on Apple's end. If so, what do I need to do to start
>> using this feature. Else if not, is there a plan to add this in the
>> (hopefully near) future?
> 
> Your post reminds me why I hate the new syntax - it will generate exactly the 
> same amount of code as the traditional syntax, yet gives the superficial 
> impression of being more efficient.  As with the property accessor syntax, it 
> generates a message send using the same syntax that C uses for a simple 
> pointer arithmetic operation.

I agree with this ... the fact that we support this syntax does not mean that 
anyone should use it.

If you use the -objectAtIndex: method your code is clearer and more 
maintainable (minimising the chance of confusing C array variables and NSArray 
variables) as well as being marginally more efficient and substantially more 
portable.



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUstep + libobjc2 and powerpc ( was "libobjc2 on powerpc")

[Richard Frith-Macdonald]

> On 22 Mar 2018, at 13:49, bertrand  wrote:
> 
> 
>> 
>> That then, begins to look like a possible libobc2 bug.
>> 
>> The log file provides both the command used to build the test and the text 
>> of the test program (a load of defines, the tiny config/config.objc.m 
>> program, and the include of objc-common.g).
>> Using that you can reproduce the test executable that crashed.
>> You can then run it under gdb to find ot where and how the crash is 
>> occurring (look at the stack etc).
>> 
> 
> I've copied this into the attached conftest.c and tried to build it
> with 
> 
> clang -integrated-as -o conftest -g -O2
> -I/usr/GNUstep/Local/Library/Headers
> -I/usr/GNUstep/Local/Library/Headers
> -I/usr/GNUstep/System/Library/Headers  -shared-libgcc
> -L/usr/GNUstep/Local/Library/Libraries
> -L/usr/GNUstep/Local/Library/Libraries
> -L/usr/GNUstep/System/Library/Libraries conftest.c -lrt -ldl  -lpthread

Well in the log file you attached to your previous email it says the command to 
build it was:

clang -integrated-as -o conftest -g -O2  -I/usr/GNUstep/Local/Library/Headers 
-I/usr/GNUstep/Local/Library/Headers -I/usr/GNUstep/System/Library/Headers  -x 
objective-c  -shared-libgcc -L/usr/GNUstep/Local/Library/Libraries 
-L/usr/GNUstep/Local/Library/Libraries -L/usr/GNUstep/System/Library/Libraries 
conftest.c -lrt -ldl  -lpthread -rdynamic -shared-libgcc -pthread -fexceptions 
-fobjc-runtime=gnustep-1.8 -fblocks -L/home/bertrand/GNUstep/Library/Libraries 
-L/usr/GNUstep/Local/Library/Libraries -L/usr/GNUstep/System/Library/Libraries 
-lpthread -lobjc -fobjc-nonfragile-abi -lm   -lpthread

So the problem is that you didn't copyu the command used to build the test 
program.

I think the lack of the '-x objective-c' is causing at least some of your 
problems ... without ot the compiler will see the .c file extension and assume 
that it's supposed to be compiling C rather than Objective-C.
To reproduce the program exactly, you should reproduce the orgiinal compilation 
command exactly.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUstep + libobjc2 and powerpc ( was "libobjc2 on powerpc")

[Richard Frith-Macdonald]

> On 22 Mar 2018, at 11:58, bertrand  wrote:
> 
> But I've got another error now : a segfault in conftest
> 
> In file included from conftest.c:108:
> In file included from ././config/config.objc.m:2:
> ././config/objc-common.g:54:3: warning: assignment to Objective-C's isa
> is deprecated in favor of object_setClass()
> [-Wdeprecated-objc-isa-usage]
>  obj->isa = self;
>  ^  ~~~
>  object_setClass( , )
> ././config/objc-common.g:47:5: note: instance variable is declared here
> id isa;
>^
> 1 warning generated.
> configure:7834: $? = 0
> configure:7834: ./conftest
> ./configure: line 1875:  3111 Segmentation fault  ./conftest
> $ac_exeext
> configure:7834: $? = 139
> configure: program exited with status 139
> configure: failed program was:
> 
> Complete config.log attached

That then, begins to look like a possible libobc2 bug.

The log file provides both the command used to build the test and the text of 
the test program (a load of defines, the tiny config/config.objc.m program, and 
the include of objc-common.g).
Using that you can reproduce the test executable that crashed.
You can then run it under gdb to find ot where and how the crash is occurring 
(look at the stack etc).




___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUstep + libobjc2 and powerpc ( was "libobjc2 on powerpc")

[Richard Frith-Macdonald]

> On 22 Mar 2018, at 09:29, bertrand  wrote:
> 
> - building make twice or only once after libobjc2

Just to be clear ... building gnustep-make twice is just a simple workaround 
for libobjc2 being installed in the wrong place (so it wouldn't be found and an 
old runtime would be found/used later) ... the initial build of gnustep-make is 
done to define *where* you want things installed (in your case 
--with-layout=gnustep) and then libobjc can use information from the 
gnustep-make installation to install itself in the right place.  If you want 
libobjc to live outside your gnustep installation, that's fine but you will 
then need to tell gnustep where to find it (using appropriate environment 
variables) unless you put it in the default location on your system (eg /usr).

> - installing libobjc2 in /usr , /usr/local, or even
> in /usr/GNUstep/Local/Library/Libraries/ (I use GNUstep layout) by hand
> - building without gcc's gobjc-4.9.deb and gobjc++-4.9.deb (I thought
> they weren't mandatory) or with them.

Manually putting libobc2 in the correct place is a perfectly fine option 
(installing gnustep-make first just removes the chance of making a mistake 
putting things in place manually).

> I've even added --enable-install-ld-so-conf to gnustep-make configure.

That should be harmless.

> My configure options for make are : 
> 
> ./configure --enable-debug-by-default --with-layout=gnustep
> -enable-objc-nonfragile-abi -enable-objc-arc --enable-install-ld-so-conf

You shouldn't be using -enable-objc-nonfragile-abi -enable-objc-arc unless you 
are sure you want to override normal behavior and know exactly wehat you are 
doing.  Rather, if you want to use new features yoiu should be configuring the 
system to use the new runtime (and hence the compiler options associated with 
it).  That means using -with-library-combo=ng-gnu-gnu

> and I had set OBJCFLAGS="-fblocks -fobjc-runtime=gnustep-1.8.1" before
> the last install of make and run ldconfig just before configuring base.

Also not necessary (and perhaps not helpful).
Basically, if you attempt to use new ObjC features without using the new 
library combo, things may go wrong, and if you use the new library combo you 
should not need to specify any of those old options for enabling/disabling 
runtime related compiler features.
I would suggest './configure --enable-debug-by-default --with-layout=gnustep  
-with-library-combo=ng-gnu-gnu'

All that being said ... I don't actually think any of the configure options you 
aree using is actually the cause of your current problem (see below):

> Each time, the configure step of base fails with the well-known and
> infamous:
> 
>> checking whether objc really works... no
>> I don't seem to be able to use your Objective-C compiler to produce
>> working binaries!  Please check your Objective-C compiler installation.
>> If you are using gcc-3.x make sure that your compiler's libgcc_s and libobjc
>> can be found by the dynamic linker - usually that requires you to play
>> with LD_LIBRARY_PATH or /etc/ld.so.conf.
>> Please refer to your compiler installation instructions for more help.
>> configure: error: The Objective-C compiler does not work or is not installed 
>> properly.

The line in the config file that's important is the error immediately before it 
tests for a working objc:

./conftest: error while loading shared libraries: /usr/lib/libdispatch.so.0: 
R_PPC_REL24 relocation at 0x0fc83f40 for symbol `gettimeofday' out of range

So the problem is with libdispatch.  I'm not the sort of linker/compiler guru 
who can tell you why there's a relocation issue or what to do about it though.  
Possibly there are compiler flags (that you could put in CFLAGS before 
configuring) to deal with it, or possibly it's something wrong with the way 
libdispath itself was built.  



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUstep and valgrind

[Richard Frith-Macdonald]

> On 20 Mar 2018, at 06:31, amon  wrote:
> 
> Richard:
> 
> Thanks. I will look at that.
> 
> And btw, to the person who suggested @autorelease... I was
> certain it would not compile, but I tried it anyway. Needless
> to say, it did not compile.
> 
> I did try coding
> p=[NSAutoreleasePool new]; do something; [p release];
> and in some cases it seemed to help. In others it did not.
> I'll be digging deeper tomorrow and I will give the macros
> you suggested a try.

The macros are just a wrapper round the code you used, intended to make it 
easier to port to using garbage collection (no longer supported) or ARC.
So 'p=[NSAutoreleasePool new]; do something; [p release];' is fine.
Where it "doesn't help" you will be experiencing cases of 
caching/lazy-initialisation.  These are features designed to improve program 
performance and you should generally not worry about them.
That is to say, before worrying about the internals of the library code (which 
is certainly largely leak free), you need to debug your own code and ensure 
it's not leaking things itself.

Typically, if you have an event driver program the NSRunLoop implementation 
will create an autorelease pool before calling your event handler, and release 
that pool after calling your event handler.  This means that, unless you create 
vast quantities of autoreleased objects (enough to crash your program) handling 
a single event, you should not be worrying about autorelease!
If you aren't handling events within a callback from NSRunLoop and are using 
some other mechanism of your own, you should do the same thing ... create a 
pool before handlign each event and release it after handling the event.
NB . ignore the release/drain debate ... both methods do the same thing in your 
environment.

Your most likely cause of a problem (assuming handling each event is wrappen in 
pool create/release) is a retain/release error in your own code.  To avoid that 
it's safest not to use retain/release and always use methods that return 
autoreleased objects.
If you are writing classes, the two biggest areas for mistakes are
a. assignment to instance variables (to minimise errors, use the ASSIGN macro 
to assign an autorelease value to a variable)
b. object deallocation ... make sure that the -dealloc method releases all its 
instance variables (use the DESTROY macro to help

You can call the GSDebugAllocationList() function (one of many diagnostic 
features in NSDebug.h) before and after handling an event, to see what objects 
have been created/destroyed and spot leaks.

> If nothing else, I am getting a much better handle on how and
> when memory gets sucked up.

That's good knowledge to have.  Most likely long term leaks are not in the 
library (though, since you are using a very old version there's more of a 
chance of it), but you might find one, and more likely you might find a case 
where some feature caches more data than you are happy with (if your available 
memory is very tight) and you might want to investigate options to overcome 
that. 

> A question on NSHost then. If NSHost essentially returns a
> cache of something like what NeXT used to call Class Objects,
> like the old Printer Class that always returned the same
> object (A technique I still use for something btw) then that
> would be less troubling. But to be clear, If I create an NSHost
> for "10.0.0.1" in one place in the code, and then some entirely
> other area creates one with the same IP, I presume you are
> seeing that it will return a pointer to the same object? That
> there will never be two NSHosts with the same IP?

Correct (unless the cache is flushed ... in which case new objects after the 
flush will differ from old ones).



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUstep and valgrind

[Richard Frith-Macdonald]

> On 20 Mar 2018, at 09:38, Wolfgang Lux  wrote:
> 
> 
>> Am 20.03.2018 um 07:31 schrieb amon :
> 
>> I did try coding
>> p=[NSAutoreleasePool new]; do something; [p release];
>> and in some cases it seemed to help. In others it did not.
>> I'll be digging deeper tomorrow and I will give the macros
>> you suggested a try.
> 
> Just one word of warning. If you use this code (or the equivalent 
> CREATE_AUTORELEASE_POOL macro), be sure to catch any exception that is raised 
> in the "do something" code and make sure that the pool gets released, i.e., 
> use
>  p = [NSAutoreleasePool new];
>  @try {
>do something;
>  }
>  @finally {
>[p release];
>  }
> Otherwise, you'll leak a whole autorelease pool on every exception raised in 
> the do something part.

This is good advice, but only partly true.
If an exception occurs, so that a pool does not get released normally, objects 
autoreleased into that pool will live longer ... until the enclosing pool is 
released.
This is because autorelease pools vonceptually form a hierarchy with each newly 
created pool being conceptually inside the previous one, so if a 'shallower' 
level pool is emptied all the enclosed 'deeper' level pools are also emptied.
So whether objects in a 'deeper' pool are considered leaked or not is rather 
context dependent.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUstep and valgrind

[Richard Frith-Macdonald]

> On 19 Mar 2018, at 06:19, amon  wrote:
> 
> I hate to keep pointing it out, but the off the shelf embedded
> system we are using is an ARM processor running a circa 2012
> Ubuntu release. They have not changed it in years. We use a
> vanilla gcc tool chain. I will do the test compile tomorrow
> at work but I very much doubt @autoreleasepool{} exists.

I'm posting from a different email address since it seems that, for some 
reason, you aren't getting nay of my emails ... maybe using this one will help.
Use the CREATE_AUTORELEASE_POOL() macro to create an autorelease pool.
Use the DESTROY() macro to get rid of the pool you created.
Bracket any code which creates lots of autoreleased objects between calls to 
these two macros ... and you have great control over memory management.
That will work perfectly on your old system.


> Actually I posted that tidbit because it looks to me like the
> API violates the intent of the the NS foundation kit standards
> as I understand them. It was my impression that every Class
> should be instantiable via:
> 
>  [[Foo alloc] initMyDesignatedInitializer: vals]
> 
> NSHost lacks any reasonable -init: methods.

I think it's fair to say that's the correct way of writing classes which are 
intended to be subclassed.  However, not all classes are intended to be readily 
subclassed.


NSHost behaves unusually because it is designed as a cache of network 
information.
When you create an NSHost instance it does expensive DNS lookups which can slow 
your program, and the class is designed to make it harder for you to write 
inefficient code.
Apple has even deprecated the cache control methods (presumably they have 
decided that giving developers control over caching is a bad idea), but GNUstep 
policy is to carry on supporting methods indefinitely even if Apple removes 
them from their systems.



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUstep and valgrind

[Richard Frith-Macdonald]

> On 18 Mar 2018, at 10:23, Fred Kiefer  wrote:
> 
> 
> 
>> Am 18.03.2018 um 00:56 schrieb amon :
>> 
>> Calling internal, non-API methods is probably not a good solution
>> for me. I am going to put it in the back of my mind to percolate
>> awhile, but perhaps you could subclass and expand the API
>> somehow. At worst you use the internal methods in the subclass
>> only so that it does not spread; at best you find a way to do
>> it yourself.
>> 
>> I have not really thought about it yet, just tossing out my
>> thoughts.
> 
> Do you really think that the NSHost objects are causing serious trouble to 
> your application? How many different hosts is your application accessing? If 
> you are really worried about those, just store them in global variables and 
> reuse them.
> But is this class really the biggest problem? Did you use the per class 
> statistics to see, for which kind of objects the amount increases over the 
> live time?

In any case, NSHost objects should normally be cached ... so whether or not 
they are autoreleased is most likely a red herring.  If using lots of different 
hosts you might want to flush the cache more often.

However, I agree ... an obsessive worry about this kind of thing is probably 
evidence of premature optimisation.
Even in environments with tiny amounts of memory available autorelease is not 
likely to be a problem.
Leaks are a problem, but using autorelease properly helps you prevent leaks.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUstep and valgrind

[Richard Frith-Macdonald]

> On 16 Mar 2018, at 17:58, Fred Kiefer  wrote:
> 
> I think that now I see the flaw in my argument. I was under the impression 
> that an autorelease pool will only release contained objects if they have a 
> reference count of one. But that is nonsense. The autorelease pool will 
> release all contained objects and as usual the ones where the reference count 
> drops to zero will be deallocated. The autorelease pool itself doesn’t care 
> about the reference count. That way your example was correct, with the 
> autorelease pool around the object creation they will only be retained by the 
> array and go away when that is deallocated.

Exactly.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUstep and valgrind

[Richard Frith-Macdonald]

> On 16 Mar 2018, at 16:53, Richard Frith-Macdonald 
> <richard.frith-macdon...@theengagehub.com> wrote:
> 
> 
> 
>> On 16 Mar 2018, at 15:44, Fred Kiefer <fredkie...@gmx.de> wrote:
>> 
>> 
>> 
>>> Am 16.03.2018 um 16:32 schrieb Richard Frith-Macdonald 
>>> <richard.frith-macdon...@theengagehub.com>:
>>> 
>>> 
>>> 
>>>> On 16 Mar 2018, at 15:18, amon <a...@vnl.com> wrote:
>>>> 
>>>> 
>>>> [arglist release];
>>>> arglist = [[[NSMutableString stringWithCString: [cmdline cString]]
>>>>componentsSeparatedByString: DELIM] retain];
>>>> 
>>>> This happens inside an init. arglist is release by the dealloc
>>>> method. However, NSMutableString insists on making it autoreleased.
>>>> I want to make it not do that. 
>>> 
>>> Portable GNUstep code would look like this:
>>> 
>>> CREATE_AUTORELEASE_POOL(pool);
>>> ASSIGN(arglist, [[[NSMutableString stringWithCString: [cmdline cString]] 
>>> componentsSeparatedByString: DELIM]);
>>> DESTROY(pool);
>>> 
>>> with no wasted/leaked memory.
>> 
>> I have to disagree. This will get rid of the intermediate NSMutableString 
>> but later on when the surrounding Foo object gets released the arglist ivar 
>> will get released as well, but the component strings in that array will 
>> still remain in what ever autorelease pool is active at that time and will 
>> only get freed when that pool is cleaned up.
> 
> That's (almost always) wrong.  Releasing a container does not put its 
> contents into an autorelease pool, it releases them all. so the components 
> get released/deallocated at the point when the array is deallocated.
> 
> Of course you can never guarantee that a class will behave normally (if you 
> don't have access to its source code), but generally when an object is 
> deallocated it releases all its instance variables.
> 
> In this instance I think it's fair to assume we are talking about the GNUstep 
> NSMutableString class generating components in a GNUstep NSArray, so we know 
> that we don't have some perverse implementation and the above three-line 
> solution is all that's needed to ensure no leaked objects.
> 
> However, I agree that if someone had for instance re-implemented 
> -componentsSeparatedByString: in a category of NSMutableString, and their 
> re-implementation had created an NSArray subclass which, on deallocation, 
> would put the array contents into an autorelease pool rather than releasing 
> them, then you could get the situation you describe where the components 
> would be placed in a pool at the point when the array ivar is released.

Of course your example:

   // zone used = n bytes
   CREATE_AUTORELEASE_POOL(pool);
   obj = [Foo new];
   // zone used = n+m bytes
   [obj release];
   DESTROY(pool);
   // zone used = n bytes.

is perfect if what you care about the end result after finishing with the 
instance of Foo.

The other:

CREATE_AUTORELEASE_POOL(pool);
ASSIGN(arglist, [[[NSMutableString stringWithCString: [cmdline cString]] 
componentsSeparatedByString: DELIM]);
DESTROY(pool);

is what you'd do in a setter method of Foo, where the instance of Foo is 
long-lived and you want to ensure that you don't increase memory usage duriung 
that long life.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUstep and valgrind

[Richard Frith-Macdonald]

> On 16 Mar 2018, at 15:44, Fred Kiefer <fredkie...@gmx.de> wrote:
> 
> 
> 
>> Am 16.03.2018 um 16:32 schrieb Richard Frith-Macdonald 
>> <richard.frith-macdon...@theengagehub.com>:
>> 
>> 
>> 
>>> On 16 Mar 2018, at 15:18, amon <a...@vnl.com> wrote:
>>> 
>>> 
>>>  [arglist release];
>>> arglist = [[[NSMutableString stringWithCString: [cmdline cString]]
>>> componentsSeparatedByString: DELIM] retain];
>>> 
>>> This happens inside an init. arglist is release by the dealloc
>>> method. However, NSMutableString insists on making it autoreleased.
>>> I want to make it not do that. 
>> 
>> Portable GNUstep code would look like this:
>> 
>> CREATE_AUTORELEASE_POOL(pool);
>> ASSIGN(arglist, [[[NSMutableString stringWithCString: [cmdline cString]] 
>> componentsSeparatedByString: DELIM]);
>> DESTROY(pool);
>> 
>> with no wasted/leaked memory.
> 
> I have to disagree. This will get rid of the intermediate NSMutableString but 
> later on when the surrounding Foo object gets released the arglist ivar will 
> get released as well, but the component strings in that array will still 
> remain in what ever autorelease pool is active at that time and will only get 
> freed when that pool is cleaned up.

That's (almost always) wrong.  Releasing a container does not put its contents 
into an autorelease pool, it releases them all. so the components get 
released/deallocated at the point when the array is deallocated.

Of course you can never guarantee that a class will behave normally (if you 
don't have access to its source code), but generally when an object is 
deallocated it releases all its instance variables.

In this instance I think it's fair to assume we are talking about the GNUstep 
NSMutableString class generating components in a GNUstep NSArray, so we know 
that we don't have some perverse implementation and the above three-line 
solution is all that's needed to ensure no leaked objects.

However, I agree that if someone had for instance re-implemented 
-componentsSeparatedByString: in a category of NSMutableString, and their 
re-implementation had created an NSArray subclass which, on deallocation, would 
put the array contents into an autorelease pool rather than releasing them, 
then you could get the situation you describe where the components would be 
placed in a pool at the point when the array ivar is released.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUstep and valgrind

[Richard Frith-Macdonald]

> On 16 Mar 2018, at 15:18, amon  wrote:
> 
> 
>[arglist release];
>  arglist = [[[NSMutableString stringWithCString: [cmdline cString]]
>   componentsSeparatedByString: DELIM] retain];
> 
> This happens inside an init. arglist is release by the dealloc
> method. However, NSMutableString insists on making it autoreleased.
> I want to make it not do that. 

Portable GNUstep code would look like this:

CREATE_AUTORELEASE_POOL(pool);
ASSIGN(arglist, [[[NSMutableString stringWithCString: [cmdline cString]] 
componentsSeparatedByString: DELIM]);
DESTROY(pool);

with no wasted/leaked memory.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUstep error handling

[Richard Frith-Macdonald]

> On 13 Mar 2018, at 23:45, amon  wrote:
> 
>> NS_HANDLER is the *original* exception handler, which predates
>> @catch (it was the only exception handling mechanism for many
>> years).
>> If you are only using platforms with modern compilers, you don't
>> need it.
> 
> Thanks, that is good to know. It unfortunately still shows up
> in a lot of GNUstep documentation and the various documents
> on the web are also a mixed bag.

Sure, because it's the standard/traditional exception handling interface that's 
always been present in OpenStep/GNUstep and is available across all platforms.
If you want maximally portable code, you write it using NS_HANDLER, but as long 
as you are sticking to newer environments you don't need it.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUstep error handling

[Richard Frith-Macdonald]

> On 13 Mar 2018, at 01:52, amon  wrote:
> 
> I've run across documentation in GNUstep that talks of NS_HANDLER,
> etc, which I've never used. I presume this is something relatively
> new from the Apple world as I don't remember it (or any error
> handler) from NeXTstep and in fact I've pretty much always used
> @try/@catch/@finally for about as long as I can remember and I
> think before that I just rolled my own stack unwinder error
> handler.
> 
> Are they just macro covers over the original syntax or do they
> add some features?
> 
> I use a lot of @throw NSException's since daemon code is not
> allowed to not work. It has to punt to a level that can retry,
> no matter what goes wrong with the outside world. Hey, you never
> know... a solar flare might have taken out the server I'm
> taking data from!
> 
> Are there any overriding reasons to shift an old body of code
> over to the new method?

NS_HANDLER is the *original* exception handler, which predates @catch (it was 
the only exception handling mechanism for many years).
If you are only using platforms with modern compilers, you don't need it. 
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Use of NSZoneStat()

[Richard Frith-Macdonald]

> On 9 Mar 2018, at 17:08, amon  wrote:
> 
> It may be the case that the malloc scene is confused and lacks
> standards, but the ability to debug leaks with a simple test
> like this has been a long standing and very serious problem
> with Objective C, to the point that I have my doubts there is
> any significant size program written in the language that is not
> silently leaking like a sieve.

Very few ObjC programs have big issues with malloc/free since they simply don't 
use them directly very much ... heap memory is generally associated with 
objects and dealt with by the retain/release/autorelease mechanism.
There *are* lots of features for management and reporting of object lifetimes 
etc which provide much more detailed/useful information than NSZoneStat() about 
object allocation/deallocation.
But, I agree that having a nice report of malloc stats is really useful in the 
specific cases wher you are writing code that does lots of messing with heap 
memory not associated with objects.
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Use of NSZoneStat()

[Richard Frith-Macdonald]

> On 8 Mar 2018, at 16:15, amon  wrote:
> 
> I am trying to get a handle on storage leaks and NSZoneStat()
> would be ideal... except it doesn't work.
> 
>  NSZone *dftzone = NSDefaultMallocZone();
>  NSZone *curzone = NSZoneFromPointer ( (void *) arglist);
>  printf ("dft = %lx cur  = %lx\n",
> (long unsigned int) dftzone,
> (long unsigned int) curzone);
> 
>  struct NSZoneStats zs0 = NSZoneStats (dftzone);
>  printf ("Bytes Used %d Free %d\n",
> (int) zs0.bytes_used,
> (int) zs0.bytes_free);
> 
> dft = 7ffcfdf26200 cur  = 7ffcfdf26200
> bin/gpstest: Uncaught exception NSGenericException, reason: No statistics for 
> default zone

NSZoneStat is only supposed to work for special zones you have created, not for 
the default zone.  It's for cirecumstances where you are carefully isolating 
your work in one or more non-standard zones.

If you are looking for general memory management, the default zone is 
implemented using malloc/free and you can substitute a different malloc library 
(eg tcmalloc) which will provide its own diagnostics.  This is not GNUstep 
specific stuff an you are better off asking in general (or C) programming 
forums.

If you are interested in object allocation/deallocation (rather than total heap 
memory), gnustep-base has a rich set of extensions to help with that (see 
NSDebug.h) as well as some extra stuff to help deal with autorelease pools.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: FOSDEM

[Richard Frith-Macdonald]

> On 4 Feb 2018, at 11:05, Ivan Vučica  wrote:
> 
> 
> On Sun 4 Feb 2018 at 11:00 Tim Käck  wrote:
> Hi all
> 
> Is there any GNUstepper still around? Just wanted to catch up with the “State 
> of GNUstep”
> I'm still here


I will be in the cafeteria for another half hour.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: FOSDEM

[Richard Frith-Macdonald]

> On 3 Feb 2018, at 09:22, Ivan Vučica  wrote:
> 
> 
> 
> On Fri, Feb 2, 2018, 20:37 Ivan Vučica  wrote:
>> 
> 
> To expand a bit:
> 
> - My plan for tomorrow is unclear.
> - I will *probably* just hang around Jansen till after Liam’s talk, probably 
> leaving for lunch.
> - Go room is very tempting, but I will try not to attend talks like state of 
> Go (https://fosdem.org/2018/schedule/event/stateofgo/), computer vision in Go 
> (https://fosdem.org/2018/schedule/event/gocv/) or designing and profiling a 
> distributed data store in Go 
> (https://fosdem.org/2018/schedule/event/datastore/) — as tempting as it is...
> - I haven’t yet found other interesting stuff for Saturday.
> 
> During the day tomorrow, I’ll try to keep an eye on this thread in case 
> someone finds some hacking space. Or, in general, to arrange hacking time / 
> space.
> 
> Go room is ridiculously overflowing. I am heading to Janson. Let me know if 
> you are there. I will be there until after Liam's talk, excepting for lunch 
> and possibly if we meet for dev.

Fred and I are at the back of the cafeteria (northish end of site). If my phone 
is to be believed: 50.813795,4.382157
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: FOSDEM

[Richard Frith-Macdonald]

> On 1 Feb 2018, at 13:46, Ivan Vučica  wrote:
> 
> If anyone is attending FOSDEM, leave a note here.

I already said yes, but to confirm: I will be there.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: FOSDEM 2018 hotels?

[Richard Frith-Macdonald]

> On 8 Jan 2018, at 20:02, Richard Frith-Macdonald 
> <richard.frith-macdon...@theengagehub.com> wrote:
> 
> 
> 
>> On 8 Jan 2018, at 19:58, Gregory Casamento <greg.casame...@gmail.com> wrote:
>> 
>> My intention is to come this year.  GC
> 
> Have you a plan for when you will be in Brussels?  I haven't booked travel 
> and hotels yet, but I was planning to get there Friday evening, and leave 
> Sunday afternoon/evening, but I'm just wondering if it might be worth taking 
> Monday off work and staying the extra evening (no point if everyone else is 
> going home on Sunday though).

FYI, I have booked to stay at the hotel Aqua for three nights from Friday 2nd;  
it turned out to be hard to arrange travel back to Cornwall on Sunday, and even 
if nobody else is around Candida and I could enjoy going out for a meal on 
Sunday evening and travel home on Monday.



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: FOSDEM 2018 hotels?

[Richard Frith-Macdonald]

> On 8 Jan 2018, at 19:58, Gregory Casamento  wrote:
> 
> My intention is to come this year.  GC

Have you a plan for when you will be in Brussels?  I haven't booked travel and 
hotels yet, but I was planning to get there Friday evening, and leave Sunday 
afternoon/evening, but I'm just wondering if it might be worth taking Monday 
off work and staying the extra evening (no point if everyone else is going home 
on Sunday though).


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: FOSDEM 2018 hotels?

[Richard Frith-Macdonald]

> On 8 Jan 2018, at 14:18, Ivan Vučica <i...@vucica.net> wrote:
> 
> Same.
> 
> I will probably be using Airbnb for accommodation.
> 
> On Sat, Jan 6, 2018 at 10:34 AM, Fred Kiefer <fredkie...@gmx.de> wrote:
>> 
>> 
>>> Am 05.01.2018 um 21:09 schrieb Richard Frith-Macdonald <r...@gnu.org>:
>>> 
>>> It's about time I booked a hotel for FOSDEM, but it's years since I last 
>>> went and I can't remember where's good.
>>> Anyone have particular hotels planned?
>> 
>> I am still unsure whether I will attend. The only reason for me to come 
>> would be to see Greg. So if it isn’t 100% sure he is coming I am out.


Well I hope Greg is coming and both of you are coming; it would be good to see 
all of you (and anyone else interestedm in gnustep stuff).
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

FOSDEM 2018 hotels?

[Richard Frith-Macdonald]

It's about time I booked a hotel for FOSDEM, but it's years since I last went 
and I can't remember where's good.
Anyone have particular hotels planned?
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: crash upon startup in GWorkcenter, Recycler, ProjectCenter and Gorm

[Richard Frith-Macdonald]

> On 28 Dec 2017, at 14:00, Fred Kiefer <fredkie...@gmx.de> wrote:
> 
> 
> 
>> Am 23.12.2017 um 12:15 schrieb Richard Frith-Macdonald 
>> <richard.frith-macdon...@theengagehub.com>:
>>> On 23 Dec 2017, at 09:42, Richard Frith-Macdonald 
>>> <richard.frith-macdon...@theengagehub.com> wrote:
>>>> On 23 Dec 2017, at 09:32, Richard Frith-Macdonald 
>>>> <richard.frith-macdon...@theengagehub.com> wrote:
>>>> 
>>>> 
>>>> So the difference between the offsets in the runtime (correct) and the 
>>>> compiler (wrong) was 16 bytes, with the runtime thinking the strruct size 
>>>> was 32 and trhe compiler thinking it was 16;
>>>> 
>>>> It seems the compiler is sizing the structure as if it contained a pointer 
>>>> and two integers when it should actually be two pointers and three 
>>>> integers;
>>> 
>>> No, my mistake, that's rubbish ... on a 64bit processor the fieldds only 
>>> occupy 28 bytes, so the 32 byte offset is produced by alignment rules 
>>> rounding up to a 16byte boundery.
>>> In that case, the offsets calculated by the compiler would be consistent 
>>> with it ignoring the two __unsafe_unretained pointers.  Perhaps that is a 
>>> clue?
>> 
>> It occurs to me that this is not anything like that simple :-(
>> 
>> While the compiler is getting the offset to _gcontext wrong, it's still 
>> getting the offset to the next ivar (_runLoopInfo) correct, so it can't just 
>> be that it's calcularing the size of the struct incorrectly.
> 
> 
> First a thank you to both Josh and Richard for gathering so much information 
> on this issue and to Richard for the quick workaround. I hope this lets 
> simple GNUstep applications run on systems with non-fragile ivars. But it is 
> definitely not the final solution for the issue. I was hoping for David to 
> provide more insight into the working of the non-fragile code. When ever a 
> class gets loaded the compiler or the runtime have to provide information 
> about the ivar layout and this seems to be off for the case where the class 
> comes from a different compilation unit and has a structure within. (or at 
> least this is what the current findings suggest) Most likely this information 
> comes from the compiler, as the runtime itself seems to have the correct 
> information. But according to Josh’s finding this information isn’t just hard 
> coded, it seems to change even without changes to the compilation unit.
> 
> The decision we now have to make is whether this unresolved issue is bad 
> enough to block a GNUstep base release? I would suggest to go ahead with 
> that, but if anybody has a different view I am fine with that.

Yes, I forgot to mention;  when using Josh Freeman's debug outpupt (priinting 
ivar offsets as returned by the runtime and as produced by the compiler), I 
tried running a pure base tool as well as a gui test.
The behavior was consistently different in those two cases:  using a pure base 
tool, the offest given by the compiler for th->_gcontext matches that produced 
by the funtime functions, but from a gui tool it didn't.
In both cases, this is definitely with the code that prints the debug compiled 
into the base library, so it seems something about linking the gui library is 
causing the compiler generated code to misbehave.  Unfortunately I don't know 
how to figure out what might be making the difference.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: crash upon startup in GWorkcenter, Recycler, ProjectCenter and Gorm

[Richard Frith-Macdonald]

> On 23 Dec 2017, at 09:42, Richard Frith-Macdonald 
> <richard.frith-macdon...@theengagehub.com> wrote:
> 
> 
> 
>> On 23 Dec 2017, at 09:32, Richard Frith-Macdonald 
>> <richard.frith-macdon...@theengagehub.com> wrote:
>> 
>> 
>> So the difference between the offsets in the runtime (correct) and the 
>> compiler (wrong) was 16 bytes, with the runtime thinking the strruct size 
>> was 32 and trhe compiler thinking it was 16;
>> 
>> It seems the compiler is sizing the structure as if it contained a pointer 
>> and two integers when it should actually be two pointers and three integers;
> 
> No, my mistake, that's rubbish ... on a 64bit processor the fieldds only 
> occupy 28 bytes, so the 32 byte offset is produced by alignment rules 
> rounding up to a 16byte boundery.
> In that case, the offsets calculated by the compiler would be consistent with 
> it ignoring the two __unsafe_unretained pointers.  Perhaps that is a clue?

It occurs to me that this is not anything like that simple :-(

While the compiler is getting the offset to _gcontext wrong, it's still getting 
the offset to the next ivar (_runLoopInfo) correct, so it can't just be that 
it's calcularing the size of the struct incorrectly.
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: crash upon startup in GWorkcenter, Recycler, ProjectCenter and Gorm

[Richard Frith-Macdonald]

> On 23 Dec 2017, at 09:32, Richard Frith-Macdonald 
> <richard.frith-macdon...@theengagehub.com> wrote:
> 
> 
> So the difference between the offsets in the runtime (correct) and the 
> compiler (wrong) was 16 bytes, with the runtime thinking the strruct size was 
> 32 and trhe compiler thinking it was 16;
> 
> It seems the compiler is sizing the structure as if it contained a pointer 
> and two integers when it should actually be two pointers and three integers;

No, my mistake, that's rubbish ... on a 64bit processor the fieldds only occupy 
28 bytes, so the 32 byte offset is produced by alignment rules rounding up to a 
16byte boundery.
In that case, the offsets calculated by the compiler would be consistent with 
it ignoring the two __unsafe_unretained pointers.  Perhaps that is a clue?



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: crash upon startup in GWorkcenter, Recycler, ProjectCenter and Gorm

[Richard Frith-Macdonald]

> On 23 Dec 2017, at 05:19, Josh Freeman <gnustep_li...@twilightedge.com> wrote:
> 
> On Dec 22, 2017, at 10:05 AM, Richard Frith-Macdonald wrote:
> 
>> I think that's a possible indication of a bug in the compiler/runtime 
>> nonfragile API support;  it looks as if there may be an inconsistency in 
>> calculating the size of a structure used as an ivar.
> 
> 
> 
>   After more testing, here's some additional info that might be useful:
> 
> -- Hardware (virtual):
>   Clean, up-to-date Ubuntu 16.04 VM, 32bit
> 
> -- GNUstep install:   Used the current Ubuntu script from the wiki, with two 
> changes:
> - Removed the script's workaround for the ivar-offset issue (so it builds 
> using the current version of gnustep-make instead of an old version).
> - Built a version of gnustep-base from a couple days ago (Dec. 19) which 
> still used the obsolete -fobjc-nonfragile-abi build flag. (As previously 
> mentioned, the current version of base won't build with the Ubuntu script if 
> the script's ivar-offset workaround is removed).
> 
> -- Attachments:
>   Attached are 2 patches that print info about NSThread ivars at runtime, and 
> 2 debugging-session outputs that were run with patches installed. The patches 
> assume that the libs-base & libs-gui directories are in the same parent 
> directory as the libobjc2 directory (as they are when running the Ubuntu 
> script), because the patches add an #import "../../libobjc2/ivar.h" in order 
> to use the runtime's ivar & ivar_list types.
> 
>   The patches - one for base, and one for gui - each add a static C function 
> that prints out the objc-runtime's NSThread ivar layout, obtained using the 
> runtime API function, class_getIvarLayout(). The patch function also prints 
> the locations in memory of the current thread's instance members, obtained 
> using statements like: >_gcontext.
> 
>   The base patch adds the diagnostic function to NSAutoreleasePool.m, & calls 
> it from -[NSAutorelease dealloc] before the NSThread's _autorelease_vars is 
> modified (which will leave a garbage value in _gcontext). The gui patch adds 
> a matching function to NSGraphicsContext.m & calls it from 
> -[NSGraphicsContext setCurrentContext:] before it frees the garbage value in 
> _gcontext & segfaults.
> 
>   The first output file, patched_base_session_output.txt, is the result of 
> installing only the base patch & running a debug session.
> 
>   The second output file, patched_base_and_gui_session_output.txt, is a 
> followup session after also installing the gui patch. In this session, 
> gnustep-base (previously patched) was not rebuilt, so base is the same binary 
> as the first session.
> 
> 
> -- Output summary:
>   In the first session (patched_base_session_output.txt), the diagnostic 
> output shows most of the NSThread members' addresses line up with the 
> runtime's ivar layout - up until the first member after the _autorelease_vars 
> struct, _gcontext.
> 
>   The runtime's ivar-layout offset for NSThread's _autorelease_vars member is 
> 44, and _gcontext's is 64. The 20-byte space for _autorelease_vars is the 
> smallest possible size for that struct on 32bit, as the struct is made up of 
> 5 members, each of which is 4 bytes (3 ints & 2 pointers - see struct 
> autorelease_thread_vars definition in NSAutoreleasePool.h).
> 
>   However, the memory address of thread->_gcontext is offset from the thread 
> instance's address by 56 - not the 64 listed by the runtime API - which is 
> only 12 bytes away from thread->_autorelease_vars. At that offset value, 
> _gcontext occupies the same memory location as the _autorelease_vars struct 
> member, pool_cache_size; When pool_cache_size is set in NSAutoreleasePool.m 
> (base), the same value will be accessed later in NSGraphicsContext.m (gui) as 
> _gcontext, causing a crash due to sending an objc message to a non-nil 
> garbage value.
> 
>   In the second session (patched_base_and_gui_session_output.txt), the 
> NSThread ivar diagnostics are also printed from within gui. Two notes:
> 
> 1) I had thought the "ivar-offset" issue was due to a mismatch between gui & 
> base ivar offsets (gui using a different offset to _gcontext than base), but 
> the output shows that this is not the case: gui & base actually match each 
> other's objc2-runtime ivar layouts and also have matching memory addresses 
> returned from >member statements; The mismatch is between the 
> runtime's ivar layout and the memory addresses returned by >member 
> statements.
> 
> 2) NSThread's ivar layout (obtained from the runtime API) was the same 
> between the first & second sessions. This was expected, bec

Re: crash upon startup in GWorkcenter, Recycler, ProjectCenter and Gorm

[Richard Frith-Macdonald]

> On 22 Dec 2017, at 15:05, Richard Frith-Macdonald 
> <richard.frith-macdon...@theengagehub.com> wrote:
> 
> 
> I then checked that both NSThread.m and NSGraphicsContext.m were compiled by 
> clang with  -D_NONFRAGILE_ABI=1 and -fobjc-runtime=gnustep-1.8
> 
> On a hunch, I looked at the ivar layout in NSThread and swapped the order of 
> _gcontext and _autorelease_vars  ... after rebuilding with the id before the 
> struct rather than after it, the GUI testcases passed.
> Reverting to the original order of ivars and rebuilding again ... the 
> testcases failed again.
> 
> I think that's a possible indication of a bug in the compiler/runtime 
> nonfragile API support;  it looks as if there may be an inconsistency in 
> calculating the size of a structure used as an ivar.

I tried a look at libobc2 ... starting with 'make test':

The following tests FAILED:
  9 - BlockImpTest (SEGFAULT)
 10 - BlockImpTest_optimised (SEGFAULT)
 39 - WeakReferences_arc (OTHER_FAULT)
 40 - WeakReferences_arc_optimised (OTHER_FAULT)

Now, none of those sound like they would be relevant, but it does make me 
wonder if there's something with the build of the runtime that migth be causing 
this.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: crash upon startup in GWorkcenter, Recycler, ProjectCenter and Gorm

[Richard Frith-Macdonald]

> On 21 Dec 2017, at 23:01, Ivan Vučica <i...@vucica.net> wrote:
> 
> On Thu, Dec 21, 2017 at 7:53 PM, Richard Frith-Macdonald 
> <richard.frith-macdon...@theengagehub.com> wrote:
> >>> gnustep-make has been using -fobjc-runtime= rather than 
> >>> -fobjc-nonfragile-abi for quita long time, but I just found that the 
> >>> gnustep-base configure script was still adding the obsolete 
> >>> -fobjc-nonfragile-abi flag when building nonfragile
> >>> I've just removed that addition of  -fobjc-nonfragile-abi from the 
> >>> current gnustep-base in git, so if gnustep is built for the new runtime 
> >>> with clang (the ng-gnu-gnu library combo) neither make nor base should 
> >>> add ther old flag.
> >>>
> >>
> >>   Just tried the Ubuntu script from the wiki on a clean, up-to-date Ubuntu 
> >> 16.04 VM (32bit), but changed the script to use the current gnustep-make 
> >> instead of the old version (removed the workaround for the ivar-offset 
> >> issue). Gnustep-base now fails to build, with the following error(s):
> >>
> >> Compiling file GSConcreteValue.m ...
> >> In file included from In file included from In file included from 
> >> GSBlocks.m:23:
> >> In file included from ../Headers/Foundation/NSObject.h:30:
> >> In file included from ../Headers/Foundation/NSObjCRuntime.h:38:
> >> ../Headers/GNUstepBase/GSVersionMacros.h:290:10: error: "You are building 
> >> gnustep-base using the objc-nonfragile-abi but your
> >>  gnustep-base was not configured to use it."
> >> #error "You are building gnustep-base using the 
> >> objc-nonfragile-abi but your gnustep-base was not configured to use it."
> >
> > That would seem to suggest you have gnustep-make trying to use clang and 
> > the new runtime but gnustep-base expecting to use gcc and the gnu runtime.
> > Could it be that you forgot to set the library combo for the modern 
> > compiler/runtime rather than the traditional one?
> > The gnustep-base configure script should recognise the library combo (from 
> > the environment or from gnustep-make) when figuring out how to configure 
> > itself;
> > traditional (gnu runtime in the library combo) implies traditional abi
> > modern, next-generation (ng runtime in the library combo) implies the 
> > nonfragile abi
> 
> I am able to reproduce this on clang 3.8.0, using latest versions of 
> everything from Git.
> 
> Steps:
> - libobjc2 configured with cmake -DCMAKE_INSTALL_PREFIX=/GNUstep ..
>   - for some reason that now ends up in 
> /GNUstep/Local/Library/{Headers,Libraries} instead of /GNUstep/include and 
> /GNUstep/lib like it did when I wrote my old scripts for building everything 
> from scratch; either way I now need to teach the rest of the environment how 
> to find it
> 
> - export CFLAGS=-I/GNUstep/Local/Library/Headers 
> CXXFLAGS=-I/GNUstep/Local/Library/Headers 
> OBJCFLAGS=-I/GNUstep/Local/Library/Headers 
> LDFLAGS=-L/GNUstep/Local/Library/Libraries 
> LD_LIBRARY_PATH=-L/GNUstep/Local/Library/Libraries:$LD_LIBRARY_PATH
> 
> - configure make with: CC=clang CXX=clang++ OBJC=clang ./configure  
> --with-layout=gnustep --enable-debug-by-default 
> --with-library-combo=ng-gnu-gnu --prefix=/GNUstep 
> --with-config-file=/etc/GNUstep/GNUstep.conf
>   - my understanding is that ng-gnu-gnu should correctly use the nonfragile 
> abi, that it should disable mixed abi and all else, so I omitted all that
> 
> - install base into system domain after configuring it with: ./configure 
> --with-ffi-include=/usr/include/`gcc -dumpmachine`
> 
> - install gui into system domain after configuring it with: ./configure 
> --disable-cups
> 
> - install back into system domain after configuring it with: ./configure 
> --enable-graphics=cairo
> 
> A bunch of -gui tests fail, and Zcode is failing to start with identical 
> backtrace.
> 
> Sample -base build command:
> clang NSPropertyList+GNUstepBase.m -c \
>   -MMD -MP -Wall -Wdeclaration-after-statement -DNO_GNUSTEP=1 -DGNUSTEP 
> -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNUSTEP_RUNTIME=1 
> -D_NONFRAGILE_ABI=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing 
> -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -g 
> -DDEBUG -fno-omit-frame-pointer -Wall -DGSWARN -DGSDIAGNOSE -Wno-import 
> -I/GNUstep/Local/Library/Headers -I/GNUstep/Local/Library/Headers 
> -I/GNUstep/Local/Library/Headers -fobjc-runtime=gnustep-1.8 -fblocks 
> -fconstant-string-class=NSConstantString -I../. -I../ -I../../Headers -I. 
> -I/home/ivucica/G

Re: crash upon startup in GWorkcenter, Recycler, ProjectCenter and Gorm

[Richard Frith-Macdonald]

> On 21 Dec 2017, at 19:03, Josh Freeman <gnustep_li...@twilightedge.com> wrote:
> 
> 
> On Dec 20, 2017, at 9:16 AM, Richard Frith-Macdonald wrote:
> 
>>> On 19 Dec 2017, at 20:33, Josh Freeman <gnustep_li...@twilightedge.com> 
>>> wrote:
>>> 
>>> Hi Tom,
>>> 
>>> This appears to be the same issue as the Base/GUI ivar-offset mismatch that 
>>> was discussed back in April [1] & June [2].
>>> 
>>> While the issue still hasn't been fixed, there is a workaround, which is to 
>>> use an older version of GNUstep Make.
>>> 
>>> However, the workaround is already included in the "16.04, 16.10, & 17.04" 
>>> install script at 
>>> http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux , so did you 
>>> happen to make any changes to the script before running it, or perhaps run 
>>> it on a machine that already had an earlier GNUstep install? (I just tried 
>>> the wiki script on a clean, up-to-date Ubuntu 16.04 VM (32bit) - the only 
>>> script change was to set the PROMPT var to 'false' to avoid having to press 
>>>  after each build - and the built apps seem to run OK).
>>> 
>>> Cheers,
>>> 
>>> Josh
>>> 
>>> 
>>> [1] http://lists.gnu.org/archive/html/discuss-gnustep/2017-04/msg00070.html
>>> [2] http://lists.gnu.org/archive/html/discuss-gnustep/2017-06/msg00026.html
>> 
>> gnustep-make has been using -fobjc-runtime= rather than 
>> -fobjc-nonfragile-abi for quita long time, but I just found that the 
>> gnustep-base configure script was still adding the obsolete 
>> -fobjc-nonfragile-abi flag when building nonfragile
>> I've just removed that addition of  -fobjc-nonfragile-abi from the current 
>> gnustep-base in git, so if gnustep is built for the new runtime with clang 
>> (the ng-gnu-gnu library combo) neither make nor base should add ther old 
>> flag.
>> 
> 
>   Just tried the Ubuntu script from the wiki on a clean, up-to-date Ubuntu 
> 16.04 VM (32bit), but changed the script to use the current gnustep-make 
> instead of the old version (removed the workaround for the ivar-offset 
> issue). Gnustep-base now fails to build, with the following error(s):
> 
> Compiling file GSConcreteValue.m ...
> In file included from In file included from In file included from 
> GSBlocks.m:23:
> In file included from ../Headers/Foundation/NSObject.h:30:
> In file included from ../Headers/Foundation/NSObjCRuntime.h:38:
> ../Headers/GNUstepBase/GSVersionMacros.h:290:10: error: "You are building 
> gnustep-base using the objc-nonfragile-abi but your
>  gnustep-base was not configured to use it."
> #error "You are building gnustep-base using the objc-nonfragile-abi 
> but your gnustep-base was not configured to use it."

That would seem to suggest you have gnustep-make trying to use clang and the 
new runtime but gnustep-base expecting to use gcc and the gnu runtime.
Could it be that you forgot to set the library combo for the modern 
compiler/runtime rather than the traditional one? 
The gnustep-base configure script should recognise the library combo (from the 
environment or from gnustep-make) when figuring out how to configure itself;
traditional (gnu runtime in the library combo) implies traditional abi
modern, next-generation (ng runtime in the library combo) implies the 
nonfragile abi


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: crash upon startup in GWorkcenter, Recycler, ProjectCenter and Gorm

[Richard Frith-Macdonald]

> On 19 Dec 2017, at 20:33, Josh Freeman  wrote:
> 
> Hi Tom,
> 
>   This appears to be the same issue as the Base/GUI ivar-offset mismatch that 
> was discussed back in April [1] & June [2].
> 
>   While the issue still hasn't been fixed, there is a workaround, which is to 
> use an older version of GNUstep Make.
> 
>   However, the workaround is already included in the "16.04, 16.10, & 17.04" 
> install script at 
> http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux , so did you 
> happen to make any changes to the script before running it, or perhaps run it 
> on a machine that already had an earlier GNUstep install? (I just tried the 
> wiki script on a clean, up-to-date Ubuntu 16.04 VM (32bit) - the only script 
> change was to set the PROMPT var to 'false' to avoid having to press  
> after each build - and the built apps seem to run OK).
> 
> Cheers,
> 
> Josh
> 
> 
> [1] http://lists.gnu.org/archive/html/discuss-gnustep/2017-04/msg00070.html
> [2] http://lists.gnu.org/archive/html/discuss-gnustep/2017-06/msg00026.html

gnustep-make has been using -fobjc-runtime= rather than -fobjc-nonfragile-abi 
for quita long time, but I just found that the gnustep-base configure script 
was still adding the obsolete -fobjc-nonfragile-abi flag when building 
nonfragile
I've just removed that addition of  -fobjc-nonfragile-abi from the current 
gnustep-base in git, so if gnustep is built for the new runtime with clang (the 
ng-gnu-gnu library combo) neither make nor base should add ther old flag.
 
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Crash occurs when catching std::exception in Objective-C++ code compiled with clang on Linux and using libobjc2

[Richard Frith-Macdonald]

> On 30 Nov 2017, at 20:23, Lobron, David  wrote:
> 
> 
 The -fgnu-runtime is for using the runtime that comes with the GNU 
 compiler (gcc).
>>> 
>>> More specifically, it is for telling GCC to use the runtime that comes with 
>>> GCC.  If you wish to use the GCC runtime with clang, the correct flag is 
>>> -fobjc-runtime=gcc (optionally with a version, though clang currently 
>>> ignores the version because it doesn’t know of any changes to the GCC 
>>> runtime ABI since clang shipped - I don’t think there are any). 
>> 
>> That's interesting ...I don't think gnustep-make really knows about/supports 
>> the option of using clang with the gcc runtime.
>> If you use gnu-gnu-gnu as the library combo, it's expecting gcc and the gnu 
>> runtime
>> If you use ng-gnu-gnu as the library combo, it's expecting clang and the 
>> gnustep/objc2 runtime
>> If someone is really determined they can override compiler/flags, but I 
>> don't trust my ability to get wierd combination right, so I never try that.
>> Perhaps gnustep-make should try to detect those sorts of override and 
>> protect us from our own mistakes, but there's a limit to how far that can be 
>> taken and we should probably just trust that if people override cimpiler and 
>> flags specifications they know what they are doing.
> 
> Many thanks for your help, guys.
> 
> I updated gnustep-make to set the library combo to ng-gnu-gnu.  This is 
> picked up by the configure script in gnustep-base:
> 
> checking the Objective-C runtime... Next Gen
> 
> However, the next few lines in the configure output of gnustep-base are 
> suspicious:
> 
> checking for custom shared objc library... NONE
> checking objc/runtime.h usability... yes
> checking objc/runtime.h presence... no
> configure: WARNING: objc/runtime.h: accepted by the compiler, rejected by the 
> preprocessor!
> configure: WARNING: objc/runtime.h: proceeding with the compiler's result
> 
> The configure tool fails a few lines later, stating that it can't use clang 
> to compile an ObjC program:
> 
> checking whether objc really works... no
> I don't seem to be able to use your Objective-C compiler to produce
> working binaries!  Please check your Objective-C compiler installation.
> 
> My clang compiler has not changed, so I know the compiler is in fact able to 
> compile ObjC.
> 
> Are there additional flags needed for clang to work with gnustep-base when 
> gnustep-make is using ng-gnu-gnu as the library combo?  My current configure 
> flags for gnustep-base are:
> 
> ./configure 
> CC=/home/dlobron/build/clangport/akamai/llvm/llvm-5.0.0.install/bin/clang 
> CXX=/home/dlobron/build/clangport/akamai/llvm/llvm-5.0.0.install/bin/clang 
> CFLAGS="-m64 -march=opteron -mno-3dnow -ggdb -O2 -Wall -fPIC -fPIC -I 
> /home/dlobron/build/clangport/akamai/common/include" CXXFLAGS="-m64 
> -march=opteron -mno-3dnow -ggdb -O2 -fPIC -fPIC -I 
> /home/dlobron/build/clangport/akamai/common/include" LDFLAGS="-m64  -rdynamic 
> -L/home/dlobron/build/clangport/akamai/common/lib" 
> LD_LIBRARY_PATH=/home/dlobron/build/clangport/akamai/common/lib 
> OBJC2RUNTIME=1 HAVE_BLOCKS=1 BASE_NATIVE_OBJC_EXCEPTIONS=1 
> LIBRARY_COMBO=ng-gnu-gnu \
>   --target=x86_64-unknown-linux-gnu \
>   --with-config-file=/usr/local/akamai/GNUstep/GNUstep.conf \
>   
> --with-ffi-include=/home/dlobron/build/clangport/akamai/common/include \
>   
> --with-ffi-library=/home/dlobron/build/clangport/akamai/common/lib \
>   --enable-icu \
>   --disable-tls \
>   --disable-xml \
>   --disable-zeroconf \
>   --with-gmp-include

:-(
.
You should not need any compiler related configure flags for gnustep-base 
(since it should get those from gnustep-make), just any enable/disable options 
you want and apparently also the ones to say your ffi library is in a 
non-standard location.
From the warning messages, it looks like you have two runtimes installed and 
it's seeing the wrong one.
Possibly you have multiple versions of clang and it's using the wrong one?
If you want to send me the gnustep-make and gnustep-base config logs I could 
look and see if I can spot anything.



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Icons (was Re: [INFO] NEXTSPACE)

[Richard Frith-Macdonald]

> On 30 Nov 2017, at 11:18, Ivan Vučica  wrote:
> 
> On Thu, Nov 30, 2017 at 10:06 AM, Xavier Brochard  
> wrote:
>> He post on his blog about these icons
>> http://galgot.free.fr/wordpress/?p=1380
>> "Feel free to redistribute, but if so, please leave the set complete together
>> with this Readme. Thanks.
>> For non-commercial and only personal use of course."
> 
> That sounds like it conflicts with FSF's freedom 0[1] and Open Source
> Definition's section 6[2] -- it restrics use in a business.
> 
> It indeed sounds like these icons are non-free. NEXTSPACE can use
> whatever icons the author wants, but potential users should be aware
> of this restriction. :-)
> 
> [1]: https://www.gnu.org/philosophy/free-sw.en.html
> [2]: https://opensource.org/osd-annotated

The icons are lovely ... why not contact the owner, say so, and asknicely if 
they could release them under a free license for use in conjunction with 
NEXTSPACE?
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: NSDecrementExtraRefCountWasZero

[Richard Frith-Macdonald]

> On 29 Nov 2017, at 12:43, David Chisnall  wrote:
> 
> Hello the list,
> 
> In trying to reduce lock contention for deallocation, I took a bit from the 
> reference count to indicate that weak references exist to an object (and 
> therefore avoid any serialisation on deallocation).  Unfortunately, when 
> Andreas tried testing it, he discovered that this broke 
> NSDecrementExtraRefCountWasZero (and, in theory, NSIncrementExtraRefCount, 
> though not in a way that’s likely to be observable).
> 
> On OS X, this function is unavailable in ARC mode and comes with a warning 
> that if any code uses ARC then it may give surprising results.
> 
> Looking in GNUstep, it appears that this is called in only a small number of 
> places:
> 
> - NSObject is using it, but probably should just be calling objc_retain() / 
> objc_release() / objc_autorelease() (the runtime will call these directly 
> instead of retain / release anyway).  NSProxy, similarly, should simply be 
> calling the relevant functions.
> 
> - A few classes are calling it to avoid deallocation of objects that are in a 
> table for reuse.It’s also not clear whether this is still a win: we’ll get 
> more cache contention from refcount manipulations if the objects are small, 
> such as NSIndexPath (though it is required for correctness in a few cases, 
> such as NSConnection).  In these cases, if the runtime supports ARC then we 
> can simply use a strong-to-weak NSHashTable and get rid of most of this logic.

That would be good ... at some point it would be great if the core libraries 
could make use of ARC.

> I’d like to start making these changes, and expose some new libobjc2 
> functions that can provide the functionality of 
> NSDecrementExtraRefCountWasZero (NSIncrementExtraRefCount can be a trivial 
> wrapper around objc_retain().  Currently, the only way I can see of 
> implementing NSDecrementExtraRefCountWasZero on top of the ARC APIs that I 
> can see is to take a weak reference to the object, release it, and then see 
> if the reference is 0.  

Presumably the downside of that is fairly severe inefficiency, but since thew 
functions are rarely used that's probably not a big issue; if it turns out a 
class using the reference count functions has a major performance impace when 
used with ARC, I guess that class could be rerwritten.

> It’s also worth noting that both NSDecrementExtraRefCountWasZero and 
> NSIncrementExtraRefCount are currently broken (and will cause memory 
> corruption) if called on blocks (or classes, constant strings, and so on).

I don't think that's a practical issue since it's always been clear that those 
functions are provided for classes to manage their own reference counting.   I 
wouldn't worry about trying to make them work for any/all args.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Crash occurs when catching std::exception in Objective-C++ code compiled with clang on Linux and using libobjc2

[Richard Frith-Macdonald]

> On 29 Nov 2017, at 10:52, David Chisnall <thera...@sucs.org> wrote:
> 
> On 29 Nov 2017, at 10:30, Richard Frith-Macdonald 
> <richard.frith-macdon...@theengagehub.com> wrote:
>> 
>> The -fgnu-runtime is for using the runtime that comes with the GNU compiler 
>> (gcc).
> 
> More specifically, it is for telling GCC to use the runtime that comes with 
> GCC.  If you wish to use the GCC runtime with clang, the correct flag is 
> -fobjc-runtime=gcc (optionally with a version, though clang currently ignores 
> the version because it doesn’t know of any changes to the GCC runtime ABI 
> since clang shipped - I don’t think there are any). 

That's interesting ...I don't think gnustep-make really knows about/supports 
the option of using clang with the gcc runtime.
If you use gnu-gnu-gnu as the library combo, it's expecting gcc and the gnu 
runtime
If you use ng-gnu-gnu as the library combo, it's expecting clang and the 
gnustep/objc2 runtime
If someone is really determined they can override compiler/flags, but I don't 
trust my ability to get wierd combination right, so I never try that.
Perhaps gnustep-make should try to detect those sorts of override and protect 
us from our own mistakes, but there's a limit to how far that can be taken and 
we should probably just trust that if people override cimpiler and flags 
specifications they know what they are doing.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Crash occurs when catching std::exception in Objective-C++ code compiled with clang on Linux and using libobjc2

[Richard Frith-Macdonald]

> On 28 Nov 2017, at 21:38, Lobron, David  wrote:
> 
> Hey All-
> 
> I've been continuing to dig into the phenomenon of code crashing when 
> catching a C++ exception in a .mm file.  I'm finding that even though my test 
> passes when it's included in the libobjc2 test bundle, it fails when I 
> compile it from the command line.  I narrowed down the compilation command, 
> and found that the seg fault stops happening if I remove -fgnu-runtime from 
> the compile command (I've copied the commands and the program below).
> 
> Should I not be compiling with -fgnu-runtime when I'm using the libobjc2 
> runtime?

The -fgnu-runtime is for using the runtime that comes with the GNU compiler 
(gcc).  You definitely don't want it if you are using the objc2 runtime.
Are you configuring/building gnustep to use the new features (ie configuring 
gnustep-make --with-library-combo=ng-gnu-gnu) ?
If configured to use new features (ie runtime is 'ng' rather than 'apple' or 
'gnu')  the make system should not be adding  -fgnu-runtime
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: FOSDEM 2018 - Distributions Devroom Call for Participation

[Richard Frith-Macdonald]

> On 4 Nov 2017, at 22:06, Gregory Casamento  wrote:
> 
> I will come.  Now that I have my passport (since the trip to England) I 
> should be just fine. 

In that case I will be there ... if you can make it from the US, I can make it 
from the UK.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Hello World not getting off the ground

[Richard Frith-Macdonald]

> On 1 Jul 2017, at 18:45, Jay Versluis  wrote:
> 
> Dear friends,
> 
> I’m a new GNUstep user with a decent amount of Objective-C experience through 
> Xcode on the Mac. I thought I could put my knowledge to good use for 
> developing cross platform applications, and thought GNUstep might be the 
> answer. However, after a week of trying every available tip I could find on 
> the web, I still can’t get a simple Hello World project to compile without 
> errors. I present to you my case.
> 
> My code is as simple as this:
> 
> #import 
> 
> int main(int argc, const char * argv[]) {
> @autoreleasepool {
> // insert code here...
> NSLog(@"Hello, World!\n");
> NSLog(@"Made with Objective-C\n");
> }
> return 0;
> }
> 
> I’m trying to compile this with gcc `gnustep-config —objc-flags` 
> `gnustep-config —base-libs` -o hello *.m
> 
> The compiler throws an error related to @autorelease, something that Xcode 
> likes adding when creating from a template. No trouble, I’ll take that 
> statement out, so we’re left with this:
> 
> #import 
> 
> int main(int argc, const char * argv[]) {
>
>   NSLog(@"Hello, World!\n");
>   NSLog(@"Made with Objective-C\n");
> 
> return 0;
> }
> 
> Compiling with the same statements yields no errors. I’d say “hurra”, however 
> when I run the app, I get what feels like several hundred lines or errors, 
> all beginning with “autorelease pool called for object”, followed by a 
> variety of NSObjects such as NSUserDefaults, NSDateMalloc, NSCalendarDate as 
> well as stuff like GSDictionary, GSInlineString, GSAbsoluteTime - in short, 
> nothing that I’ve called here. And it only happens at runtime. Another 
> variation on the code was to make the main method a (void) method, but that 
> didn’t make a difference.
> 
> Why is this happening? What am I doing wrong here?
> 
> What’s perhaps interesting is that I’m getting the exact same problem under 
> CentOS 7, Ubuntu 16, as well as Windows 10. Yes indeed, I’ve tried them all! 
> On Windows I’ve also tried compiling with a GNUmakefile. The compilation 
> works without a hitch, however I still get the above errors by the dozen. I 
> did try clang on CentOS too, but not knowing the right flags didn’t get me 
> anywhere. I wish everything was as easy as pressing that button in Xcode… but 
> alas it is not. 
> 
> For the makefile I’ve loosely followed this guide: 
> http://www.gnustep.org/resources/documentation/Developer/Base/ProgrammingManual/manual_1.html#Building-Your-First-Objective_002dC-Program
>  I’ve even tried to compile the source code in the example, but the standard 
> C library can’t be found on Windows. On that note, both Gorm and Project 
> Center refuse to start and quit with a Runtime Error. Perhaps it’s a sign. 
> Maybe I’m just not meant to use GNUstep.
> 
> But before giving up, I thought I’d ask you experienced folks for help. 
> aeruder was very kind yesterday on IRC already, with his help at least 
> something compiles on my systems.
> 
> Any tips to guides are welcome! I’d love to use GNUstep, even if GNUstep 
> doesn’t want to be used :-) 

Your copy of gnustep is not built to use the 'next generation' runtime, so the 
'@autoreleasepool' syntax is not understood.  You can write code using the 
original form:

int main(int argc, const char * argv[]) {
NSAutoreleasePool   *pool = [NSAutoreleasePool new];
// insert code here...
NSLog(@"Hello, World!\n");
NSLog(@"Made with Objective-C\n");
   [pool release];
return 0;
}

or, perhaps better, you could use the GNUstep macros which aim at making it 
esier to write portable code (to work in both the classic and the next 
generation environments:

int main(int argc, const char * argv[]) {
CREATE_AUTORELEASE_POOL(pool);
// insert code here...
NSLog(@"Hello, World!\n");
NSLog(@"Made with Objective-C\n");
   RELEASE(pool);
return 0;
}

In any case, the reason you are getting a lot of warnings uising
int main(int argc, const char * argv[]) {
// insert code here...
NSLog(@"Hello, World!\n");
NSLog(@"Made with Objective-C\n");
return 0;
}
is that the two NSLog() calls are being executed outside of an autorelease 
pool, so any temporary objects those functions create are leaked memory.  On a 
simple test program that leaked memorym is not an issue and the program will 
still run perfectly well, but on a larger program that is intended to keep 
running for a long time, memory leaks are a major issue (so you do need to 
ensure that autorelease pools are created and destroyed when the objects in the 
pools are no longer needed.



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Program occasionally crashes on startup due to GNUstepDefaults.lck error

[Richard Frith-Macdonald]

> On 19 Jun 2017, at 17:56, Fred Kiefer <fredkie...@gmx.de> wrote:
> 
> 
>> Am 18.06.2017 um 10:20 schrieb Richard Frith-Macdonald 
>> <richard.frith-macdon...@theengagehub.com>:
>> 
>>> 
>>> On 17 Jun 2017, at 15:40, Wolfgang Lux <wolfgang@gmail.com> wrote:
>>> Thanks for committing the change for me, I was still in the process of 
>>> switching my local checkout to git.
>>> However, it looks like you got my comment slightly wrong. I didn't mean to 
>>> say that using the 
>>> createDirectoryAtPath:withIntermediateDirectories:attributes:error: method 
>>> is wrong or that that method is broken in any way. It's just that calling 
>>> it with the withIntermediateDirectories: argument set to YES is wrong 
>>> because in that case the method return YES even if the directory already 
>>> exists. Calling the method with NO for the second parameter would have been 
>>> perfectly okay (unless the create method would indeed contain a bug).
>> 
>> I had looked at the code and seen that it counted creation as having 
>> succeeded irrespective of the flag (which is why I opted to use the O/S 
>> function directly).
>> The documented behavior of the methods was not 100% clear on the point, so I 
>> wrote a couple of testcases to check the actual behavior on OSX, and confirm 
>> it is as you had thought.
>> I've now altered the GNUstep behavior to match the OSX behavior and altered 
>> the documentation to explicitly state what happens if the directory already 
>> exists.
> 
> With that change in place, couldn’t we switch back to the old implementation 
> for NSDistributedLock? I hate to see OS specific code scattered around in 
> different places :-)

Good point.  I just comitted a change to do that.
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep