Re: JS engine(s) provided by gnustep

[David Chisnall]

Hi,

As far as I know, no one has ported JavaScriptCore to GNUstep. It might not be 
a huge amount of work but that last time I looked at it (ten or so years ago) 
the build system for JSC conflated a lot of things in the Apple paths that 
would need disentangling if you want the Cocoa bits but ELF and the Linux 
calling conventions, for example.

If you don’t care about performance, there are a couple of small JavaScript 
interpreters (jsQuick and DukTape) that would be fairly easy to bridge to 
Objective-C. I played with using DukTape and GNUstep ages ago and it looked as 
if it would be quite easy to add an implementation of the APIs that JSC exposes 
on macOS, but it would give around 10% of the performance.

David

> On 9 Sep 2023, at 16:22, loserism  wrote:
> 
> 
> Hello friends.
> I'm trying to use JavaScriptCore through gnustep and found that gnustep 
> doesn't find JavaScriptCore, does anyone know how to fix it? I know I can use 
> other third party js engines, but I only want to use the interface provided 
> by Apple, does gnustep provide an implementation of this interface? Is there 
> an easy way to implement these interfaces that are not implemented or 
> provided in gnustep, other than implementing them myself?
> 
> Lastly, thanks for all the replies and help.
> Best regards.

Re: tools-windows-msvc runtime error

[David Chisnall]

Did you remember to disable incremental linking?

Last time I tested it, LINK.EXE did work, but if you had incremental linking 
enabled (I think it’s on by default?) then it inserts random padding into the 
Objective-C runtime’s metadata sections, which corrupt various things.

David

> On 18 Jul 2023, at 08:34, Frederik Seiffert  wrote:
> 
> Thanks, I reproduced the issue here. It turns out using the Microsoft linker 
> causes this issue, but using LLD works fine. I’m not sure why or since when 
> this is, as using link.exe definitely worked for me at one point, but now 
> using either VS 2019 or 2022 causes this crash as soon as objc_msgSend() is 
> called. Maybe David has an idea what could be going on here?
> 
> Anyway, passing -fuse-ld=lld should get you going. I would also add /Z7 to 
> produce debug symbols as well:
> 
> clang-cl -I C:\GNUstep\x64\Debug\include -fobjc-runtime=gnustep-2.0 -Xclang 
> -fexceptions -Xclang -fobjc-exceptions -fblocks -DGNUSTEP -DGNUSTEP_WITH_DLL 
> -DGNUSTEP_RUNTIME=1 -D_NONFRAGILE_ABI=1 -D_NATIVE_OBJC_EXCEPTIONS -DGSWARN 
> -DGSDIAGNOSE /MDd /Z7 /c test.m
> 
> clang-cl test.obj gnustep-base.lib objc.lib dispatch.lib -fuse-ld=lld /MDd 
> /Z7 -o test.exe /link /LIBPATH:C:\GNUstep\x64\Debug\lib
> 
> I’ve updated the toolchain readme to add this flag in the example.
> 
> Hope that helps.
> Frederik
> 
> 
>> Am 18.07.2023 um 03:00 schrieb loserist :
>> 
>> Sure! The following is it:
>> 
>> * thread #1, stop reason = Exception 0xc005 encountered at address 
>> 0x7ffcec4e1048: Access violation reading locatio
>> n 0x
>> * frame #0: 0x7ffcec4e1048 objc.dll`objc_msgSend + 40
>> frame #1: 0x7ff645cc1154 abc.exe
>> frame #2: 0x7ff645cc142c abc.exe
>> frame #3: 0x7ffcfb967614 kernel32.dll`BaseThreadInitThunk + 20
>> frame #4: 0x7ffcfc1826b1 ntdll.dll`RtlUserThreadStart + 33
>> Thanks!
> 
> 

Re: [ML] Hosting of gnustep.org

[David Chisnall]

On 19/01/2021 12:57, H. Nikolaus Schaller wrote:

  Given that this is searching from under a hundred things, all of which can be 
downloaded in a single HTTP request quite cheaply, you could do that client 
side in less than one network round trip time.

And you can click the "Anything wrong with this entry? Click here to fix it!" 
button at the end of the page allowing to propose new version or add screen shots. Tell 
me how that should work.


It would link to the source page on GitHub and ask people to raise a PR. 
 How many of these updates do you get currently?



How can you make pages that can be sorted/filtered dynamically on user-request?

Normally, with client-side JavaScript.

What is your norm?


I don't understand the question.


  I realise that some people dislike JavaScript, but in 2021 I think that 
battle is probably lost.

No I don't dislike it at all - but why do a new solution if one exists?


I think that's what I'm asking.  Jekyll lets you build something with 
the same user experience, with no requirements on anything other than a 
static web host.  A dynamic web host imposes a nontrivial administrative 
burden for maintaining security (especially something using PHP).



There are off-the-shelf JavaScript things for sortable / filterable / 
searchable tables, I quite like this one, which gives you a single .js file and 
falls back to a non-sortable table gracefully if JavaScript is disabled:

http://www.kryogenix.org/code/browser/sorttable/

Yes, I know - but why choose a new solution if one exists?


Yes, exactly.  Why roll your own when there are off-the-shelf things 
that do what you need?



I don't seem to be able to sort the table with the live version and the filter 
by OS and Model boxes let me filter by Any, with no other options in the 
drop-down.

Yes, that is because there is only a single category for these values.


Making the filter box work on the summary table is pretty trivial, just iterate 
over the table entries, hide (set the hidden property in the DOM) any table 
rows that don't match the search term.

That is exactly what the SQL select behind is also doing.


And requires someone to pay for host an SQL database and someone to be 
responsible for security updates.



Using a database or any server-side scripting seems massively overengineered 
for this.

No, it is not over engineered. It is already done! And is standard technology. 
Look for example at Joomla, MediaWiki, NextCloud etc. They all do the same. 
Some mix it with JavaScript to make some user interactions smoother.


These are all big CMS or web app systems, they are very different from a 
mostly static web page.



  If the software index grows to have thousands of entries, I'd change my mind, 
but the complete data for the summary table is likely to be a couple of K and 
so you're likely to need more network traffic for boilerplate on multiple page 
requests with the same template than you save by filtering the contents on the 
server.

That may be true, but is even a counter-argument against your ideas: if it is 
just some K (hence not wasting resources), why do a complete rewrite of it (not 
to forget debugging) a working solution? This would waste other resources, i.e. 
developer's time.


Because maintaining a dynamic web server that is backed by a database 
costs time and money over an unbounded time.





How can you make a page with user-generated change requests send out an e-mail 
to reviewers for approval?

I wouldn't.  Folks that want to update it can raise a GitHub PR that has their 
new Markdown file in it.  They can install the github-pages Ruby Gem and run 
jekyll-serve locally to test how their changes will look before submitting.  
GitHub automatically sends emails about PRs to all maintainers of a project.

I've seen this scale to projects with hundreds of contributors, I don't imagine 
GNUstep having problems with it.  Looking at that index, it appears as if it 
averages less than one update per month currently.

Ok, I see you want to invent something completely new instead of thinking about 
how to easily move the existing.
In my experience, such proposals will rarely be completed because it is 
possible to use the new technology, but it takes far more time than simply 
continuing to use the old.


The start point is that Gregory does not wish to continue paying for and 
maintaining the infrastructure.  I am 100% sympathetic with that, 
because it is doing nothing that cannot be done with zero-cost solutions 
that tens of thousands of other projects use.


The simplest solution is to turn off the GNUstep Software Index.  That's 
the zero-effort solution.  There are then two alternatives:


 - Someone volunteers to maintain the infrastructure.
 - Someone volunteers to rewrite it to use cheap instead infrastructure.

David

Re: [ML] Hosting of gnustep.org

[David Chisnall]

On 19/01/2021 13:09, H. Nikolaus Schaller wrote:

BTW: I forgot to mention that we already have a GNUstep way of storing all this 
metadata:

http://www.gnustep.org/softwareindex/plist.php

The idea behind this is the recently mentioned GAPstore.app which would allow 
to show
the same application list as a full app on the GNUstep desktop, filter out 
applications
already installed and notify about updates. Like you know from iOS or Google 
Play.


NSJSONSerialization was added to GNUstep ten years ago.  We don't need 
to have a custom format for this, we can use the same format that most 
web things use for interop.



If you think a little further there could be a mode to edit entries locally and 
send them
to the central database for doing announcements of new applications or versions.


And if you think about that more, now you need to either provide account 
management, authorisation, access control, and a load of other complex 
things such as handling spam (maybe not from GAPstore.app itself, but 
from other things where malicious folks decide to use the APIs that 
you've created for GAPstore.app).



All this becomes impossible or at least brain-twisting if there is not a 
central database
but static HTML+JS+CSS pages.


You are conflating a great many things here:

 - Storing in MySQL versus in flat files.
 - Generating the HTML once whenever the data store is modified, versus 
on every request.
 - Exposing a machine-readable version of the data versus generating 
only presentation HTML.

 - Providing a rich set of APIs for accessing the data store.

The first three are orthogonal and *nothing* about any of those choices 
prevents what you want to do.  I'm not even going to touch the last one, 
because doing it securely is such a massive engineering undertaking that 
I don't think anyone on this list is going to devote the effort required 
to do it.



So it completely breaks the philosophy and goals of the software index and 
stops it from
ever becoming something like the macOS app store or Google Play.


I feel like you're changing the problem a lot now.  The original problem 
was can we present a web interface listing the programs using GNUstep 
with a nice UI and expose the same data to other non-browser consumers 
in a useful way, with updates being easy for people to submit, with a 
free off-the-shelf static site generator.  The answer is 'yes, without 
too much effort'.


Now you're saying 'can we extend this to provide a solution that is 
equivalent to a commercial project that cost millions of dollars and 
needed incredibly careful security work (which both Google and Apple 
managed to get wrong at least a few times), oh, and while we're there, 
can we make it multi-platform please?'  The answer to that is, 'no, a 
static site generator can't do this, but given that it's a huge 
engineering project anyway, the JSON that it generates or the files in 
the git repo could easily be the canonical data source until something 
better comes along'.


David

Re: [ML] Hosting of gnustep.org

[David Chisnall]

On 19/01/2021 12:12, H. Nikolaus Schaller wrote:

How would all this work for dynamic content 
likehttp://www.gnustep.org/softwareindex/  ?


Can you be a bit more specific?  At first glance, that looks pretty 
static: There's a top-level index page and a load of child pages.  I'd 
put each of the entries in a Markdown file with the metadata in the YAML 
frontmatter.  Jekyll can load that as a collection, sort and index it, 
and generate the main page and each sub page from templates.  Each of 
the sub-indexes (Application, Developer Tool) and so on is just the 
top-level index filtered by things that match some key in the metadata.


The only dynamic thing that seems to work is the search box.  Given that 
this is searching from under a hundred things, all of which can be 
downloaded in a single HTTP request quite cheaply, you could do that 
client side in less than one network round trip time.



How can you make pages that can be sorted/filtered dynamically on user-request?


Normally, with client-side JavaScript.  I realise that some people 
dislike JavaScript, but in 2021 I think that battle is probably lost.


There are off-the-shelf JavaScript things for sortable / filterable / 
searchable tables, I quite like this one, which gives you a single .js 
file and falls back to a non-sortable table gracefully if JavaScript is 
disabled:


http://www.kryogenix.org/code/browser/sorttable/

I don't seem to be able to sort the table with the live version and the 
filter by OS and Model boxes let me filter by Any, with no other options 
in the drop-down.


Making the filter box work on the summary table is pretty trivial, just 
iterate over the table entries, hide (set the hidden property in the 
DOM) any table rows that don't match the search term.


Using a database or any server-side scripting seems massively 
overengineered for this.  If the software index grows to have thousands 
of entries, I'd change my mind, but the complete data for the summary 
table is likely to be a couple of K and so you're likely to need more 
network traffic for boilerplate on multiple page requests with the same 
template than you save by filtering the contents on the server.



How can you make a page with user-generated change requests send out an e-mail 
to reviewers for approval?


I wouldn't.  Folks that want to update it can raise a GitHub PR that has 
their new Markdown file in it.  They can install the github-pages Ruby 
Gem and run jekyll-serve locally to test how their changes will look 
before submitting.  GitHub automatically sends emails about PRs to all 
maintainers of a project.


I've seen this scale to projects with hundreds of contributors, I don't 
imagine GNUstep having problems with it.  Looking at that index, it 
appears as if it averages less than one update per month currently.


David

Re: [ML] Re: Hosting of gnustep.org

[David Chisnall]

Gregory,

On 19/01/2021 12:01, Gregory Casamento wrote:

Mhm AWS...
Not a fan of Amazon :P


Don't care


You floated the idea of a CoC over Christmas and this is the kind of 
exchange that makes me think that the project might need one.  I 
understand that you don't want to derail the thread with long 
discussions of the merits of different vendors but this kind of 
confrontational and dismissive reply is not what I'd expect from a 
leader of an inclusive free software or open source project.


David

Re: [ML] Re: Hosting of gnustep.org

[David Chisnall]

[ Disclaimer: I work for the company that owns GitHub, but these 
opinions are my own and not corporate policy ]


On 18/01/2021 23:36, Ivan Vučica wrote:

- Should we turn the index into a set of static pages generated from
MySQL data, which we then check in?
- If we turn each entry into a single .md file, we can perhaps
leveragehttps://github.com/allejo/jekyll-toc


There are two things you can do with GitHub Pages:

 - Run a GitHub Action that builds the branch that Pages uses from 
commits to another branch (using whatever static site generator you want).

 - Use GitHub's version of Jekyll to do this transparently.

I generally prefer the latter where possible.  There are some places 
where it doesn't work (for example, if you want to run Doxygen or 
similar to generate API docs on any commit to a header file), but it's 
generally pretty good.


The big downside of using GitHub Pages' version of Jekyll is that you 
can't run arbitrary Jekyll plugins unless they are shipped with the 
GitHub install.  That said, you don't need anything custom to do 
aggregation like this.  Jekyll's support for collections makes it very 
easy to write pages that have summaries and detail both generated from 
the same data (YAML file or Markdown files in a directory with YAML in 
their frontmatter).  I've used this, for example, for open student 
projects on my University web page: each project has a description in a 
.md file with who it's appropriate for, whether it was completed 
already, and so on and these are built into a family of pages with 
navigation links and summaries between them.


Jekyll has some rough corners, but it can generally be battered into the 
right shape for most things.


David

Re: What function sets up the GNUstep environment?

[David Chisnall]

On 05/11/2020 14:54, Gustavo Tavares wrote:

Throwing 0x1677ab8, in flight exception: (nil)
Exception caught by C++: 0


This bit looks as if I accidentally left some debugging code enabled in 
the runtime.  Did you build the trunk version of libobjc2?


David

Re: What function sets up the GNUstep environment?

[David Chisnall]

On 04/11/2020 18:54, Gregory Casamento wrote:
Just FYI, you still need a display server (whether that's X or Windows 
or whatever) to start a headless application.  Is this an issue?  If it 
is, then we would need something like the null backend.


I have worked around this issue in the past by running Xvnc and 
configuring the DISPLAY environment variable to look for the UNIX domain 
socket where Xvnc was listening.  Xvnc was configured to listen on a 
socket that no one had access to.


This is more overhead than a proper null back end (it's still rendering 
all of the things, its just sending them nowhere), but it's a quick hack 
that lets you run things on a headless machine.


David

Re: GNUstep web install script

[David Chisnall]

On 26 Aug 2020, at 17:23, H. Nikolaus Schaller  wrote:
> 
>> 
>> Am 26.08.2020 um 18:11 schrieb Gregory Casamento :
>> 
>> I am not sure if David Chisnall ever got libobjc2 working on MIPS. 
> 
> I also have no idea - I was just assuming that it works if not rejected by 
> the script or the build system...

It was working with the n64 ABI last time I tested it but I haven’t tested it 
recently and it isn’t tested in CI.  I don’t think I ever tested it with n32 or 
o32.

David

Re: GNUstep store... also, thinking of starting a foundation/503(c) for GNUstep...

[David Chisnall]

On 18/08/2020 02:19, Svetlana Tkachenko wrote:

What OS is the bst equipped to run GNUstep on it with minimal confusion to the 
novice user?


FreeBSD.  Ships with an Objective-C compiler and a C++ stack that 
interoperates well with Objective-C in Objective-C++.  Doesn't require 
jumping through hoops to handle conflicts between system packages that 
want to bring in ancient versions of Objective-C things.



What hardware does this OS run on?


Most x86 things, WiFi card compatibility can be a bit hit-and-miss.


Who would do the installs on new hardware and be the base shipping point(s)?


Not me.

David

Re: Debian Package Repository...

[David Chisnall]

Hi,

Having a custom VM seems like a high maintenance way of doing this.  For 
another project, we're using Azure Pipelines to generate an apt package 
repo directly from the CI pipeline.  There are pipeline actions for 
doing all of the required steps.


I'm already using Azure Pipelines for Linux and Windows CI of libobjc2, 
though I'm not building packages.  If we want package builds out of that 
flow, I'd be very happy to take a PR to add it (we'd probably want to 
only run that pipeline on releases).


David


On 29/07/2020 15:52, Gregory Casamento wrote:

Hey guys,

One of the things we have struggled with in the past is the fact that 
the Debian packages are, necessarily, way behind.   I would like to set 
up a repo that contains the needed packages (at first for deb, but then 
for rpm based repositories as well) for users to get their packages 
directly from us IF they choose to do so.  I am in no way saying we 
should not create packages for Debian, but this would allow us to have 
more control and also would allow us to create packages that use clang 
instead of GCC for Linux.


I am going to set this up on an AWS server.  I will let you guys know 
about my progress.  If anyone would like to help or has any advice, let 
me know.


Thanks, GC
--
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org  - 
http://heronsperch.blogspot.com 
https://www.patreon.com/bePatron?u=352392 
 - Become a Patron

https://gf.me/u/x8m3sx  - My GNUstep GoFundMe

Re: Segfault while building PikoPixel

[David Chisnall]

On 07/07/2020 20:13, Gregory Casamento wrote:


GNUstep, very much contrary to popular belief, neither maintains the 
objc portion of gcc nor does it maintain clang.  If you are getting a 
segfault while running clang the most expedient place to report any bugs 
with clang is on their website.


I am the maintainer of GNU-family Objective-C runtime support in clang 
and of the GNUstep runtime.  Unless you assign these bugs to me in the 
LLVM Bugzilla, I am unlikely to see them.  I am far more likely to see 
and be able to fix them if I see a post in this list, because it's much 
lower traffic.


If you add -### to the end of your clang invocation, it will show the 
clang -cc1 invocation that runs the actual compiler.  If you then run 
that in a debugger, you should be able to get a useful back trace.  Note 
that clang-7.0.1 is quite old.  There were quite a few fixes in the 7-8 
timeframe, so trying with clang-10 would also be helpful.


David

Re: Obj-C - Categories on Protocols

[David Chisnall]

Hi,

You don’t actually need anything new from the runtime to support this.  I 
implemented something equivalent in the EtoileFoundation framework around 2007 
and GNUstep also has something similar in -Base Additions.  

Categories are somewhat problematic in Objective-C because there is no defined 
composition order.  A lot of other languages have solved this in various ways.  
In Verona, we’re addressing it by allowing default methods on interfaces not 
allowing subclassing and getting most the benefits (and almost none of the 
overhead) that Smalltalk and Objective-C derive from this dynamic behaviour 
from a structural and algebraic type system.

Categories, in the runtime, are just a little bit of metadata with a list of 
methods and a class to apply them to.  You could make this entirely declarative 
by defining a protocol like GSConcreteProtocol (containing no methods) and then 
define a class that implements that protocol and another protocol with optional 
methods, so you’d write something like this:

@protocol Example
@required
- (void)mustBeImplemented;
@optional
- (void)hasDefaultImplementation;
@end

@interface ExampleConcreteProtocol : NSObject @end
@implementation ExampleConcreteProtocol
- (void)mustBeImplemented { /* Keep the compiler happy */ }
- (void)hasDefaultImplementation
{
// Some code goes here
}
@end


You’d then use the runtime’s introspection to get the list of all classes and 
first find all classes that conform to the GSConcreteProtocol protocol.  Then 
you’d probably do some sanity checking (e.g. that they inherit directly from 
NSObject and have no other ivars) and then, for each of these classes, you’d 
find the protocols that they conformed to.  

Next, you’d find all other classes that conformed to that protocol.  You’d then 
iterate over all of the optional methods in the protocol and find ones that are 
not implemented by the class, then copy the method from the concrete protocol 
class into the target.

The end result is that you provide a class that implements the optional methods 
in a protocol and then any class that adopts the protocol but does not define 
the methods gets the default implementation.

This requires that the runtime support protocol introspection to find optional 
methods.  This should all be working with both v1 and v2 GNUstep ABIs.

David


> On 20 Jun 2020, at 21:59, Derek Fawcus 
>  wrote:
> 
> I recently read the ACM article on the history of Obj-C [1],
> and noticed it indicated that the intended ability to create
> a category on a protocol as never having shipped as a feature,
> but that it did ship as a thing in Swift [2].
> 
> The references at the end of the ACM paper state:
> 
>  "Extensions on Protocols allow programmers to add methods and their
>   implementations to a protocol which all conforming classes will
>   automatically gain. We refer specifically to the section of the
>   website describing Extensions on Protocols in Swift to document
>   that this functionality originally proposed for Objective-C in 1995
>   but never shipped finally became available in the Swift successor
>   language in 2014."
> 
> 
> So I wonder, does this mean that the Apple Obj-C runtime happens to
> include this mechanism, despite it not being exposed to the language,
> or is it only provided by the Swift runtime?
> 
> DF
> 
> [1] https://dl.acm.org/doi/10.1145/3386332
>(The origins of Objective-C at PPI/Stepstone and its evolution at NeXT)
> 
> [2] https://docs.swift.org/swift-book/LanguageGuide/Protocols.html#ID521
> 

Re: Trying to build GNUstep from git repo and clang-9 on Raspbian Buster (10.4)

[David Chisnall]

On 18 Jun 2020, at 11:05, Johannes Brakensiek  wrote:
> 
> Thank you for your reply, David.
> 
> On 18 Jun 2020, at 10:46, David Chisnall wrote:
> 
>>> If you want to build libobjc2 on armhf you will have to use the older 
>>> version 1.9 of libobjc (which does not require clang >= 8, but works with 
>>> older versions of clang as well).
> 
>> The v2 and v1 ABIs do not use different assembly fast paths.
> 
> This is always a little bit confusing to me. Version 2.0 of libobjc2 supports 
> v2 and v1 ABI, ok. But compiling only worked using the version 1.9 of 
> libobjc2 (meaning the git tag/version, not the ABI version). Does that sound 
> correct to you?

No, that’s very confusing.  Please file bug reports.  The trunk version should 
build on ARM and I have not seen any bug reports about it other than a brief 
report when we fixed some EH things and didn’t update the ARM versions.

>>> Also, it would be very nice if anybody would like to do the missing 
>>> libobjc2 assembler implementation for armhf. I think this is a common use 
>>> case as long as the default arch for Raspbian is 32 bit. Even though this 
>>> arch will be running out of support at some time in the future, of course.
>> 
>> 
>> I did.  Five years ago.  Note that there was a bug until 15 months ago where 
>> the unwind info was not correctly set, so throwing an exception out of 
>> +initialize would potentially corrupt some floating point state.
> 
> That’s very good to read, thank you! Probably I read some outdated 
> documentation or was just using the 1.9 tag because Raspbian only had clang 7 
> available then. I will try again with 2.0 and clang 8 and report if I ran 
> into the same issue as Patrick.

Thanks,

David

Re: Trying to build GNUstep from git repo and clang-9 on Raspbian Buster (10.4)

[David Chisnall]

> On 15 Jun 2020, at 08:13, Johannes Brakensiek  
> wrote:
> 
> But afaik some parts of libobjc2 2.0 are built from assembler code. The 
> needed code for the armhf architecture does not exist yet. That architecture 
> is 32bit. If you try the 64bit variant (aarch64) it should work afaik.

I am really confused by this, because git blame tells me that I added those 
code paths 5 years ago.  As long as your compiler is defining __arm__ and 
__ARM_ARCH, but not defining __SOFT_FP__, we should be building the correct 
code paths.

> If you want to build libobjc2 on armhf you will have to use the older version 
> 1.9 of libobjc (which does not require clang >= 8, but works with older 
> versions of clang as well).

The v2 and v1 ABIs do not use different assembly fast paths.

> Also, it would be very nice if anybody would like to do the missing libobjc2 
> assembler implementation for armhf. I think this is a common use case as long 
> as the default arch for Raspbian is 32 bit. Even though this arch will be 
> running out of support at some time in the future, of course.

I did.  Five years ago.  Note that there was a bug until 15 months ago where 
the unwind info was not correctly set, so throwing an exception out of 
+initialize would potentially corrupt some floating point state.  

David

Re: catching exceptions

[David Chisnall]

On 12/06/2020 12:07, Andreas Fink wrote:

Does anyone know how I can catch these exceptions in lldb:

Throwing 0x7f2fa8004588, in flight exception: 0x7f2fa8004588
Exception caught by C++: 0

the usual

break set -S raise


I'm not sure what that does.  I set breakpoints on __cxa_throw and 
objc_exception_throw to get the debugger to tell me where exceptions are 
thrown.


David

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

[David Chisnall]

Hi,

I'm not sure where you get that from.  The only comment about 64-bit on 
that page is in reference to Apple's implementation, stating that the 
new ABI is the only option on 64-bit Apple platforms (Apple supported 
the old and new ABIs on 32-bit x86, only the new one on 64-bit Macs and 
only the new one on any iOS devices).


That said, the page is quite out of date.  The new runtime supports 
three ABIs:


 - The old GCC one.  Basically, don't use this, it doesn't support any 
post-2005 Objective-C features.
 - The GNUstep v1 ABI, which tried to be backwards compatible with the 
GCC runtime so you could mix code compiled with GCC.  This didn't work 
particularly well and, in hindsight, was a bad idea.  This is the 
minimum for using features like ARC.
 - The GNUstep v2 ABI, which is designed to use modern linker features. 
 This supports all modern Objective-C features.  This depends on some 
features specific to the binary format and so is supported on ELF and 
COFF platforms (not currently Mach-O or Wasm, though I'd be interested 
in adding them at some point).


ARC's memory model intrinsically requires an ABI with non-fragile 
instance variables (i.e. the generated code does not hard-code the 
offsets of instance variables, instead it looks the offsets up in a 
variable initialised by the runtime).


You control the runtime with the -fobjc-runtime= flag to clang.  The 
format is:


-fobjc-runtime={runtime name}-{version}

The options are:

gcc, any version, targets the old GCC ABI.

gnustep-1.{0-8} targets the GNUstep 1.x ABI, restricting itself to 
features supported by the corresponding runtime release, for example not 
using property accessor helpers that weren't added or only using 
objc_msgSend on architectures that have the right implementation.


gnustep-2.0 (currently the only 2.x version, any point release value is 
ignored).  This switches to the new ABI.  This should give smaller 
binaries and faster code, but is incompatible with code compiled with GCC.


ARMv7 has all of the assembly fast paths, so should work well with the 
new ABI, though I think there may still be a few corner cases in C++ 
exception interop that don't work with the ARM EH ABI.  Please try using 
libobjc2 trunk and file bug reports on GitHub as you find them!


David

On 11/06/2020 20:01, Patrick Cardona wrote:

Hi David,

I looked around to better understand how to use ARC and the new ABI as you 
suggested.
But according to your article on the wiki (1), I understood that only 64bits 
systems could be able to use the new ABI : is it right ?

And the RPI 3B+ I am using now is only 32 bits :
description: ARMv7 Processor rev 4 (v7l)
 product: Raspberry Pi 3 Model B Plus Rev 1.3
 ...
 bits: 32 bits


(1) The Wiki source :
  http://wiki.gnustep.org/index.php/ObjC2_FAQ,

Re: Objective-C Beginner's Guide

[David Chisnall]

On 10/06/2020 10:47, Umberto Cerrato wrote:

Hi Patrick,

About Discord?
If you can browse the web you can “have it” :)


If you can browse the web and are willing to agree to Discord's 
obnoxious 'privacy' policy then you can have it.  I got about half way 
down it before deciding that there is no way I would ever click the 'I 
agree' button.  You may choose differently.


David

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

[David Chisnall]

On 10/06/2020 10:42, Patrick Cardona via Discussion list for the GNUstep 
programming environment wrote:

Ref : First Steps in GNUstep GUI Programming (2) : NSWindow,  NSButton
Edition : First Edition: July 2000; Last Updated: January 2008
URL : http://www.gnustep.it/nicola/Tutorials/WindowsAndButtons/index.html

Hi Nicola (Pero),
Hi All,

I wish first to thank You, Nicola, for the great tutorials You made.
They helped Me to understand and begin my learning pretty well.

Trying to play and understand the final code in the Tutorial 'First 
Steps in GNUstep GUI Programming (2) : NSWindow,  NSButton', I was 
facing to some warnings and bugs. I think You should modify the final 
code listing at page 9, in the '@implementation' section like this :


(1) In the method 'dealloc' :

- (void) dealloc
{
   RELEASE (myWindow);
   /* According to a warning while making the app */
   [super dealloc];
}


Note that this -dealloc method is not required at all with ARC.


(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];

  /* Here, the contentView was obviously missing : I added it... */
[myWindow setContentView: myButton];
...
}


As Richard says, the semantics of init-family methods mean that this 
doesn't do what you think it does.


An init-family method consumes the receiver and returns a new owning 
reference to the return value.  In the common case, the the receiver 
will be the same as the return value and so this cancels out.  In the 
case of things like NSWindow, it is quite likely that they are 
different.  NSWindow +alloc is likely to return a singleton placeholder 
and do the real allocation when you call one of the init-family methods 
that


That is why it is considered good style to never assign the result of 
alloc to a variable and always chain the call as [[SomeClass alloc] 
initWithSomeInitFamilyMethod: ...].  For more information about method 
families, see this:


https://www.informit.com/articles/article.aspx?p=1745875&seqNum=4

Note that without ARC, your version may generate memory management 
errors.  With ARC, it will just have surprising behaviour: the newly 
created window created by the init-family method will be deallocated 
immediately and the value assigned to myWindow will point to the 
placeholder.



I Hope this could be helpful for other Beginners like Me. ;-)


I would *strongly* recommend any beginner use ARC from the outset. 
Thinking in terms of ownership and consume operations is a far better 
memory model than thinking in terms of reference count manipulation.


ARC also makes memory management work cleanly in Objective-C++, so 
things like std::vector work correctly (and will 
typically be faster than NSMutableArray).


David

Re: FYI Fwd: [plaurent/gnustep-build] I receive the following when compiling a hello world program (#17)

[David Chisnall]

On 25 May 2020, at 06:51, Patryk Laurent  wrote:
> 
> Indeed— thank you, I saw that discussion, it sounds like this is a libobjc2 
> message that needs to be guarded by a debug flag. 

FYI: This is now hidden behind an off-by-default CMake flag.

Note: It is still worth fixing most of the places in GNUstep that trigger the 
warning.

David

Re: strange new errors

[David Chisnall]

Hi Andreas,

These warnings are fine to ignore (they should be guarded by debug 
builds of libobjc2 or an environment variable, but they aren't 
currently).  You're seeing them now because Richard found and half fixed 
a bug in our detection of when to use the fast paths, and I finished and 
merged the patch about a week ago.


The warning is badly worded (my fault) and just means that the class 
will not use fast paths for ARC.  A few of these could easily be made to 
go away (NSNull, GSDateSingle, and a few others are singletons and 
implement -retain defensively to avoid retain calls.  The runtime now 
provides a better mechanism for doing this, but I haven't yet exposed 
it.  The ARC implementation has a notion of persistent objects [e.g. 
NSConstantString] for which it skips all ARC-related calls.  Opting in 
to this will let NSObject's -retain / -release become no-ops if they're 
every called).


Some of the others are implementing -retain to copy.  These are strictly 
wrong.  The spec for -retain requires that it returns self.  Code 
compiled with ARC may or may not do the right thing here (depending on 
your compilation flags, the compiler may use the return value of 
objc_retain, but it may ignore it.  objc_retain returns the argument so 
that the compiler can avoid spilling the value across calls - it's 
guaranteed to be in the return register).


I believe the small objects don't need to implement any of these 
methods.  The runtime should be hitting fast paths for them and not 
calling memory management methods and if you call NSObject's -retain / 
-release / -autorelease then these should be delegating to the runtime 
for any GNUstep build that targets a runtime that supports small objects.


David

On 20/05/2020 08:45, Andreas Fink wrote:


Hello all,

I recompiled the latest version of gnustep yesterday with clang-10 and now I 
see the following error messages at startup.


NSAutoreleasePool does not support ARC correctly (implements retain)
GSPlaceholderString does not support ARC correctly (implements retain)
GSMutableString does not support ARC correctly (implements retain)
NSConstantString does not support ARC correctly (implements retain)
GSTinyString does not support ARC correctly (implements retain)
GSPlaceholderValue does not support ARC correctly (implements retain)
GSMutableArray does not support ARC correctly (implements retain)
GSPlaceholderArray does not support ARC correctly (implements retain)
GSPlaceholderTimeZone does not support ARC correctly (implements retain)
NSLocalTimeZone does not support ARC correctly (implements retain)
_NSConcreteProcessInfo does not support ARC correctly (implements retain)
GSDateSingle does not support ARC correctly (implements retain)
GSDateFuture does not support ARC correctly (implements retain)
NSSmallInt does not support ARC correctly (implements retain)
NSBundle does not support ARC correctly (implements release)
NSNull does not support ARC correctly (implements retain)


all my code is compiled with ARC which shouldnt stop clang calling code which 
is non ARC.
why do we see these errors and whats the workaround?
And is there any memory management problem here really or can it be safely 
ignored.

Re: GNUstep Handheld

[David Chisnall]

On 07/05/2020 05:49, Gregory Casamento wrote:
Hey guys... I'd really like to start development on a (UIKit compatible 
or not) backend for Android which will allow the creation of GUI apps. 
Ideally what I would like is something that extends UIKit if possible. 
Since we are talking about this just my $0.02.


FYI: WinObjC has an MIT licensed UIKit and it's been used to port 
Android apps to Windows.  It isn't very actively maintained anymore, but 
it uses the GNUstep Objective-C runtime.  The code contains a load of 
Windowsisms, but it was originally very portable (it uses freetype for 
font rendering, for example, rather than anything Windowsy).  If you 
want an Android UIKit, this would probably be a good place to start.


Note that it's a modern Objective-C++ codebase.  I suspect that they'd 
be interested in accepting patches for non-Windows operating system 
support, if it kept the project alive.


David

Re: nm not finding __objc_class names Re: Loading bundle resources using GNUstep runtime 2.0

[David Chisnall]

On 22/02/2020 03:46, Patryk Laurent wrote:

I believe that there is (or at least was) already dl_iterate_phdr,
and that for some reason this was added to get the list of classes
without actually loading
the object file?  If that path still exists, its perhaps possible this
series of issues, is people using this API,
and calling frameworkClasses without causing the loading shared object.

It seems an important part of the process is to determine if the listed classes 
in are implemented elsewhere (eg., in a framework). These scripts determine 
this by checking the output for no for class names having a “U” next to them, 
in which case they are such “elsewhere” classes.

Do the methods you are proposing inform on whether classes are implemented “in 
this module” versus “elsewhere”?


Only classes defined in a given binary are listed in the __objc_classes 
section.  Classes that are referenced are listed in the 
__objc_class_refs section.  Enumerating the __objc_classes section will 
give a complete list of all of the classes in a given binary.


David

Re: nm not finding __objc_class names Re: Loading bundle resources using GNUstep runtime 2.0

[David Chisnall]

On 16/02/2020 20:42, Patryk Laurent wrote:

I see the list “frameworkClasses” is meant to be populated during the make 
process running “nm *.o -Pg” as part of EXTRACT_CLASS_NAMES_COMMAND. Defined in 
target.make, this command is used to look for lines output from nm starting 
with “__objc_class_name”.


I'm not sure why it would.  That's an implementation detail of the old 
ABI.  The v2 ABI[1] creates a `_OBJC_CLASS_{class name}` symbol for each 
class.  Note that this symbol should *never* be referenced directly, it 
exists solely for the indirection pointers in the `__objc_class_refs` 
section to point to to import the classes that are used.  The runtime is 
free to dynamically allocate a new class structure and to update 
pointers to reflect the new structure, giving forwards binary 
compatibility guarantees (a 2.2 ABI may add fields to the class 
structure and the runtime can then silently auto-update the 2.0 ABI 
requirements).


If all you want is to extract the names, that should be fine, just look 
for the new pattern.


Note that, if you want to enumerate all of the classes in a library, you 
can do so on ELF platforms by using dl_iterate_phdr to find the 
`__objc_classes` section in each loaded ELF image and collect the 
classes directly (this section is an array of pointers to classes 
declared in the ELF file).  This will work irrespective of build system goo.


On Windows, the corresponding section is `.objcrt$CLS` (though I believe 
the CLS part is a sub-section and is stripped during linkage).


David

[1] Documented here: 
https://github.com/gnustep/libobjc2/blob/master/ABIDoc/abi.tex

Re: plmerge core dumps...

[David Chisnall]

On 13/02/2020 16:51, Richard Frith-Macdonald wrote:

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.


Correct.  The v2 ABI depends on a couple of interesting features:

1. The linker creates __start_{section} and __stop_{section} symbols 
within each linked output that give the range of a section.
2. Some COMDAT merging so that the function that calls the Objective-C 
load function is deduplicated and so is the pointer to it in the .ctors 
or .init section (which causes the run-time linker to call it) and the 
data structure that it passes to the linker.



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


It appears as if BFD ld is resolving one or both of these too early, so 
the set of sections provided in the final link does not include the ones 
from the subproject.  I haven't looked too closely which part is failing.



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)?


If GNUstep Make had the conventional configure/build split, then I'd 
recommend adding a check that the linker was BFD and aborting if so.  I 
don't want to enforce gold, because LLD also works fine (as does 
LINK.EXE or LLD-LINK.EXE on Windows).  On many platforms, LLD is the 
default linker, it is only GNU/Linux where the default linker does not work.


David

Re: plmerge core dumps...

[David Chisnall]

-fuse-ld=gold (or -fuse-ld=lld for lld).

LLD is the system linker on most *NIX platforms (Android, *BSD).  On 
platforms where BFD is the default, gold has been part of the binutils 
package that installs BFD for quite a long time and so the -fuse-ld= 
flag will instruct gcc or clang to select it.


David

On 13/02/2020 14:31, Gregory Casamento wrote:
An observation.  I only see this on subsequent installs.  The first 
always goes ok.


Another question.  How do i switch to ld.gold?

On Thu, Feb 13, 2020, 9:16 AM David Chisnall <mailto:gnus...@theravensnest.org>> 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).

David

Re: plmerge core dumps...

[David Chisnall]

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).


David

Re: plmerge core dumps...

[David Chisnall]

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.

David

Re: rdynamic? Re: ProjectCenter running or building

[David Chisnall]

-rdynamic is fine.  This means put all symbols on the dynamic symbol table.  
The problem is -r, which means do a partial link.  Some linkers do too much of 
one and prevent the final link from correctly placing everything in the correct 
sections.

David

> On 13 Jan 2020, at 00:05, Patryk Laurent  wrote:
> 
> Hi,
> 
> On December 29, 2019 at 6:21 AM, David Chisnall  
> wrote:
> 
>> On 29 Dec 2019, at 13:16, Fred Kiefer  wrote:
>>> 
>>>> 2019-12-29 00:35:39.702 ProjectCenter[10666:10666] NSDocumentClass 
>>>> PCProjectDocument not found
>> 
>> Is this project using ld -r (I forget what GNUstep Make calls this - 
>> subprojects?)? If so, it may be the same issue as Base Additions, which 
>> can’t be linked with BFD LD.
>> 
>> David
> 
> On January 6, 2020 at 3:48 AM, David Chisnall  
> wrote:
> 
>> On 05/01/2020 16:15, Patryk Laurent wrote:
>>> Do you think the bug is also is in ld.gold? During build, we set 
>>> LD=/usr/bin/ld.gold (for 
>>> example,https://github.com/plaurent/gnustep-build/blob/master/ubuntu-19.10-clang-9.0-runtime-2.0/GNUstep-buildon-ubuntu1910.sh#L46)
>> 
>> Is $LD actually used to build? Most of the time, $CC is invoked as the 
>> linker, so you need -fuse-ld=gold in the LDFLAGS.
>> 
>> David
> 
> While building ProjectCenter I see the use of clang -rdynamic, it looks like 
> it's coming in from gnustep-config --objc-libs.  Is this the "-r" you were 
> mentioning before, and may be causing the problem with the 
> frameworks/subprojects and resource bundle loading?
> 
> Should we try to find some way to disable it?  What is the recommended way to 
> do this?
> 
> Best,
> Patryk
> 
> 
> clang  -shared -Wl,-soname,libProjectCenter.so.0  -rdynamic  
> -fuse-ld=/usr/bin/ld.gold -L/usr/local/lib  -pthread  -fexceptions -o 
> ./ProjectCenter.framework/Versions/0.6.2/./libProjectCenter.so.0.6.2 obj/ 
>ProjectCenter.obj/NSFramework_ProjectCenter.o 
> obj/ProjectCenter.obj/PCBundleManager.m.o 
> obj/ProjectCenter.obj/PCEditorManager.m.o 
> obj/ProjectCenter.obj/PCMakefileFactory.m.o 
> obj/ProjectCenter.obj/PCFileManager.m.o obj/  
> ProjectCenter.obj/PCAddFilesPanel.m.o obj/ProjectCenter.obj/PCFileCreator.m.o 
> obj/ProjectCenter.obj/  PCSaveModified.m.o 
> obj/ProjectCenter.obj/PCProjectManager.m.o 
> obj/ProjectCenter.obj/PCProject.m.o obj/
> ProjectCenter.obj/PCProjectWindow.m.o 
> obj/ProjectCenter.obj/PCProjectInspector.m.o obj/ProjectCenter.obj/ 
> PCProjectBuilder.m.o obj/ProjectCenter.obj/PCProjectBuilderOptions.m.o 
> obj/ProjectCenter.obj/ PCProjectBuilderPanel.m.o 
> obj/ProjectCenter.obj/PCProjectLauncher.m.o obj/ProjectCenter.obj/
>   PCProjectLauncherPanel.m.o obj/ProjectCenter.obj/PCProjectEditor.m.o 
> obj/ProjectCenter.obj/PCProjectBrowser.m.o 
> obj/ProjectCenter.obj/PCProjectLoadedFiles.m.o 
> obj/ProjectCenter.obj/PCProjectLoadedFilesPanel.m.o obj/ 
> ProjectCenter.obj/PCButton.m.o obj/ProjectCenter.obj/PCFileNameField.m.o 
> obj/ProjectCenter.obj/PCFileNameIcon.m.o 
> obj/ProjectCenter.obj/PCLogController.m.o 
> obj/ProjectCenter.obj/PCAuxiliaryWindow.m.o   -L../ 
> ProjectCenter/./obj-L/home/patryk/GNUstep/Library/Libraries 
> -L/usr/GNUstep/Local/Library/Libraries 
> -L/usr/GNUstep/System/Library/Libraries   -lobjc -lgnustep-base -lgnustep-gui
> 
> 
> clang -shared -rdynamic -fuse-ld=/usr/bin/ld.gold -L/usr/local/lib -pthread 
> -fexceptions -o ./ProjectCe
> nter.debugger/./ProjectCenter ./obj/ProjectCenter.obj/PCDebugger.m.o 
> ./obj/ProjectCenter.obj/PCDebuggerView.m.
> o ./obj/ProjectCenter.obj/PipeDelegate.m.o 
> -L../../../Framework/ProjectCenter.framework/. -L/home/patryk/
> GNUstep/Library/Libraries -L/usr/GNUstep/Local/Library/Libraries 
> -L/usr/GNUstep/System/Library/Libraries 
> -lgnustep-gui -lgnustep-base -lpthread -lobjc -lm
> 
> 
> clang -rdynamic -fuse-ld=/usr/bin/ld.gold -L/usr/local/lib -pthread 
> -fexceptions -fobjc-runtime=gnuste
> p-2.0 -fblocks -o ProjectCenter.app/./ProjectCenter \
> ./obj/ProjectCenter.obj/PCAppController.m.o 
> ./obj/ProjectCenter.obj/PCInfoController.m.o 
> ./obj/ProjectCenter.obj/PCMenuController.m.o 
> ./obj/ProjectCenter.obj/PCPrefController.m.o 
> ./obj/ProjectCenter.obj/ProjectCenter_main.m.o 
> -L./Framework/ProjectCenter.framework/. 
> -L/home/patryk/GNUstep/Library/Libraries 
> -L/usr/GNUstep/Local/Library/Libraries 
> -L/usr/GNUstep/System/Library/Libraries -lProjectCenter -lgnustep-gui 
> -lgnustep-base -lpthread -lobjc -lm
> 
> 
> 
>  

Re: ProjectCenter running or building

[David Chisnall]

On 06/01/2020 09:30, Riccaro Mottola wrote:
There is a bug in BFD LD.  Things that use ld -r in some situations (I 
have not been able to find a minimal test case, but base additions is 
one) have things stripped too early and so all of the Objective-C 
classes are removed.


On my working setup on OpenBSD I explictely set bfd and this "fixed" for 
me the c++ abi issues.


I used:
LDFLAGS=-fuse-ld=bfd


Interesting.  Is LLD the default linker on OpenBSD?  There are a couple 
of things on FreeBSD that I need to mark as LLD_UNSAFE and have them 
fall back to gold.  BFD may work for them.


At some point, I need to find reduced test cases for the LLD bugs: it 
works on almost everything and seems to fail on only some of the more 
complex cases (SOGo, for example), but I've not seen run-time failures, 
only link-time errors.


David

Re: ProjectCenter running or building

[David Chisnall]

On 05/01/2020 16:15, Patryk Laurent wrote:

Do you think the bug is also is in ld.gold? During build, we set 
LD=/usr/bin/ld.gold (for 
example,https://github.com/plaurent/gnustep-build/blob/master/ubuntu-19.10-clang-9.0-runtime-2.0/GNUstep-buildon-ubuntu1910.sh#L46)


Is $LD actually used to build?  Most of the time, $CC is invoked as the 
linker, so you need -fuse-ld=gold in the LDFLAGS.


David

Re: ProjectCenter running or building

[David Chisnall]

On 2 Jan 2020, at 20:50, Fred Kiefer  wrote:
> 
> from now on this is a clang issue and I am no longer of any help here. Maybe 
> David has an idea what is going on? It would help to know which version of 
> clang used to work and on which version it is failing. The next thing would 
> be to write a minimal framework and an application using this to reproduce 
> the issue.

There is a bug in BFD LD.  Things that use ld -r in some situations (I have not 
been able to find a minimal test case, but base additions is one) have things 
stripped too early and so all of the Objective-C classes are removed.

David

Re: ProjectCenter running or building

[David Chisnall]

On 29 Dec 2019, at 13:16, Fred Kiefer  wrote:
> 
>> 2019-12-29 00:35:39.702 ProjectCenter[10666:10666] NSDocumentClass 
>> PCProjectDocument not found

Is this project using ld -r (I forget what GNUstep Make calls this - 
subprojects?)?  If so, it may be the same issue as Base Additions, which can’t 
be linked with BFD LD.

David

Re: ProjectCenter running or building

[David Chisnall]

On 29 Dec 2019, at 03:01, Patryk Laurent  wrote:
> 
> ./Framework/ProjectCenter.framework/./libProjectCenter.so: error: undefined 
> reference to '__objc_ivar_offset_NSView._tracking_rects.'

It looks as if PC is using a private NSView ivar.  This will need to have to 
change to using reflection APIs that Gorm required.

David

Re: Instance variables overwritten by other assignments

[David Chisnall]

On 26 Dec 2019, at 01:32, Patryk Laurent  wrote:
> 
> 
> Hi David,
> 
>> On Dec 25, 2019, at 01:19, David Chisnall  wrote:
>> 
>> Hi,
>> 
>> This sounds like the issue with the Linux run-time linker and the 1.x 
>> non-fragile ABI.  This can be fixed by either:
>> 
>> 1. Using pretty much any non-Linux OS, or
>> 2. Using the 2.0 ABI and clang 8.0 or later.
>> 
> 
> Brilliant — that did it, thank you! Everything is running smoothly and 
> snappily on Aarch64 with clang9 and the 2.0 runtime. 

Yay!

David

Re: Instance variables overwritten by other assignments

[David Chisnall]

Hi,

This sounds like the issue with the Linux run-time linker and the 1.x 
non-fragile ABI.  This can be fixed by either:

1. Using pretty much any non-Linux OS, or
2. Using the 2.0 ABI and clang 8.0 or later.

David

> On 25 Dec 2019, at 04:02, Patryk Laurent  wrote:
> 
> Hi,
> 
> At Gorm startup I am seeing a problem where Boolean assignments in 
> -initDefaults are somehow overwriting memory for NSTableView.m’s 
> _numberOfColumns instance variable.  See the output of debug print statements 
> below. 
> 
> Does anyone know why this might be happening — and how to fix it?
> 
> This is under clang-6.0 on Aarch64. 
> 
> Thank you,
> Patryk
> 
> GNUstep-build/apps-gorm/Gorm.app$ ./Gorm 
> 2019-12-25 03:51:47.959 Gorm[4257:4257] Bad palette selection - -1
> 2019-12-25 03:51:48.002 Gorm[4257:4257] Bad palette selection - -1
> 2019-12-25 03:51:48.267 Gorm[4257:4257] Bad palette selection - -1
> 2019-12-25 03:51:48.314 Gorm[4257:4257] NSTableview.m:2012: _isValidating 
> = NO; // _numberOfColumns is 0
> 2019-12-25 03:51:48.315 Gorm[4257:4257] NSTableview.m:2013: _drawsGrid
> = YES; // _numberOfColumns is 0
> 2019-12-25 03:51:48.315 Gorm[4257:4257] NSTableview.m:2014: _rowHeight
> = 16.0;  // _numberOfColumns is 0
> 2019-12-25 03:51:48.315 Gorm[4257:4257] NSTableview.m:2015: _intercellSpacing 
> = NSMakeSize (5.0, 2.0); // _numberOfColumns is 0
> 2019-12-25 03:51:48.316 Gorm[4257:4257] NSTableview.m:2016; 
> ASSIGN(_selectedColumns, [NSMutableIndexSet indexSet]); // _numberOfColumns 
> is 0
> 2019-12-25 03:51:48.316 Gorm[4257:4257] NSTableview.m:2018: 
> _allowsEmptySelection = YES;  // _numberOfColumns is 256
> 2019-12-25 03:51:48.317 Gorm[4257:4257] NSTableview.m:2019: 
> _allowsMultipleSelection = NO; // _numberOfColumns is 256
> 2019-12-25 03:51:48.317 Gorm[4257:4257] NSTableview.m:2020: 
> _allowsColumnSelection = YES; // _numberOfColumns is 65792
> 2019-12-25 03:51:48.317 Gorm[4257:4257] NSTableview.m:2021: 
> _allowsColumnResizing = YES;  // _numberOfColumns is 16843008
> 2019-12-25 03:51:48.317 Gorm[4257:4257] NSTableview.m:2022: 
> _allowsColumnReordering = YES;  // _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.317 Gorm[4257:4257] NSTableview.m:2023: // 
> _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.317 Gorm[4257:4257] NSTableview.m:2024; _selectingColumns 
> = NO; // _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.317 Gorm[4257:4257] NSTableview.m:2025: 
> _verticalMotionDrag = NO; // _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.318 Gorm[4257:4257] NSTableview.m:2026:_editedColumn = 
> -1; _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.318 Gorm[4257:4257] NSTableview.m:2027: _editedRow = -1; 
> // _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.318 Gorm[4257:4257] NSTableview.m:2028: _clickedRow = -1; 
> // _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.318 Gorm[4257:4257] NSTableview.m:2029: _clickedColumn = 
> -1;  // _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.318 Gorm[4257:4257] NSTableview.m:2030: _selectedColumn = 
> -1; // _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.318 Gorm[4257:4257] NSTableview.m:2031:  _selectedRow = 
> -1;  // _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.319 Gorm[4257:4257] NSTableview.m:2032: 
> _highlightedTableColumn = nil; // _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.319 Gorm[4257:4257] NSTableview.m:2036: 
> ASSIGN(_sortDescriptors, [NSArray array]); // _numberOfColumns is 4311810304
> Segmentation fault
> 

Re: scaling, rotating, flipping subview

[David Chisnall]

Hi,

The problem that you identify (input and output coordinate spaces are 
different) is also a problem with CoreAnimation and with X11's XRENDER 
extension: in both you can apply an affine transform to the output, but 
input coordinates are not transformed.


This is something that you can work around by modifying the responder 
chain.  NSView is an NSResponder and is responsible for transforming 
input events into the child view's coordinate space before delegating 
them.  You can apply the inverse of the affine transform to the 
coordinates of the event (after determining which view actually handles 
them).


David

On 08/12/2019 19:17, H. Nikolaus Schaller wrote:

Hi,
I am currently working on some CAD tool for GNUstep/mySTEP
and for that I would need a NSView class that can become
the documentView of a NSClipView, embedded in some
NSScrollView. And the view class I am looking for should
allow to rotate, flip and scale a subview (where I do the
drawing).

There is no standard class which can do that in Cocoa or OpenSTEP.

I have experimented a little on Cocoa and got scaling work
(by setting the bounds of the drawing view scaled relative to
its frame) but flipping and rotation is difficult to achieve.

It partially works with setBoundsRotation or scaleUnitSquareToSize,
but as a side-effect that breaks operation of the scrollers of
the NSScrollView.

Scroller size and position seems to assume that the frame and
bounds are not rotated so that changing the bounds origin can
simply move around the view under the NSClipView.

The standard recommendation is to set a transform matrix in
drawRect: and by that I could make drawing work, but coordinate
transforms for mouse clicks do not take this into account.
And scrollers do not adjust for different scaling.

Finally, this is not a general approach which can rotate,
flip and scale an arbitrary subview.

Before I invest more time in this topic, I'd like to ask
if someone knows an open source implementation of such a
general NSView subclass.

Thanks,
Nikolaus

Re: libobjc2 build issue

[David Chisnall]

On 1 Dec 2019, at 10:17, Riccardo Mottola  wrote:
> 
> Right. Please do not distort things. While I make sure that everything is 
> "gcc clean" for my own use, I do test, run and build GNUstep with clang 
> almost daily. My main workstation is FreeBSD + Clang + GNUstep. Of course, it 
> means I do not use any features of this setup that would not work in the 
> equivalent GCC path, but it still gets used. All software I run or maintain 
> works in this setup.

That’s exactly my point.  If all of the core GNUstep developers are building 
things on top of GNUstep that work with the core OpenStep-era Objective-C 
language and runtime, then none of those things are going to stress test any of 
the bits of GNUstep that depend on the newer features.

There are lots of subtle corner cases in things like weak references in the 
presence of concurrency, C++ exception interop in Objective-C++, and so on that 
will only work reliably if people are testing them in ways that go 
significantly beyond easy unit testing (though many of them can subsequently be 
reduced to simple regression tests).

I have fixed a number of bugs in these issues over the last couple of years, 
but none of them were reported by core GNUstep developers.  Since I know that 
GNUstep developers are pretty good about filing bug reports when they encounter 
issues, this tells me that you are not seeing these issues, which tells me that 
you’re not hitting any of these code paths in anything that you are about.

NSMapTable with weak objects or keys is not an unusual pattern in Cocoa 
applications (GitHub finds almost 2K occurrences of weakToStrongObjectsMapTable 
in a quick search), but it has been broken in GNUstep since 2013.  How many of 
the people listed on this page[1] have written code that depended on correct 
functioning of weak references?  How many have written anything that uses ARC 
in a non-trivial way?  Or anything that tests Objective-C++?

I expect the OpenStep parts of GNUstep to work very well, because I expect that 
many people on that list are testing a large subset of them on a regular basis, 
but anything that depends on modern Objective-C or Objective-C++ will work only 
if someone downstream uses them, discovers that they’re broken, and engages 
with the project long enough for them to be fixed.

David

[1] https://github.com/orgs/gnustep/people

Re: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?)

[David Chisnall]

On 27 Nov 2019, at 18:29, Ivan Vučica  wrote:
> 
> I will intentionally not discuss this further, and I have
> intentionally not dug very deep. I don't want to be overly exposed to
> ideas beyond the APIs.

Apple wrote quite a lot publicly about how their fast rendering server (Quartz 
Extreme!!11eleventyone) worked, and it’s very similar to how most modern GUIs 
work.  XDAMAGE, XRENDER and XCOMPOSITE expose all of the things required to do 
the same on X11.  Their main innovation was that, for each font, they 
pre-rendered all of the glyphs and did server-side compositing.  This 
dramatically sped up text rendering: the previous bottleneck was rendering all 
of the bezier paths (Microsoft Research published a faster way for GPUs almost 
20 years ago, which involved turning each bezier into two triangles [one vertex 
and both control points] and then having a pixel shader that coloured in the 
triangles so that they only rendered the bezier path parts, but Apple’s 
approach is very fast anyway).

On a modern GPU, modifying a texture is very expensive, but compositing is 
basically free.  On a CPU, modifying a texture is cheap and compositing is 
relatively expensive.  The interface that you want from the GUI stack to the 
display server (X11 or whatever) should favour storing rendered things on the 
server and should provide the regions that need redrawing.  If you’re using a 
GPU, rendered things can be stored as textures and composited for free.  If you 
need to redraw something, you can render to texture and then cache the result 
and composite that.

This design also benefits CPUs and remote display over a network: on a CPU, you 
can cache pre-composited regions and only re-composite the necessary bits.  
Even that’s pretty cheap on a modern CPU (compositing is basically a zip 
operation on a pair of byte arrays): old 2D accelerators had fixed-function 
hardware for it but they don’t really exist anymore because 10-year-old CPUs 
are more than fast enough.

I haven’t looked at the Cairo back end, but from what I’ve seen of its 
behaviour, my guess as to some of the performance issues:

 - It is redrawing a lot more than it needs to.  There may still be the double 
buffering inherited from the ART back end, but I’ve seen the entire window 
flicker when only a small portion should be redrawn.

- There’s no CALayer support, so redrawing a view always involves redrawing all 
subviews, even ones that haven’t changed.  Pretty much all other modern 
toolkits have sone CALayer equivalent and so can cache expensive to render and 
just recomposite them.  This is particularly noticeable over remote X11, where 
those images are cached on the display server and only the redrawn bits need to 
be transferred over the network.

David

Re: libobjc2 build issue

[David Chisnall]

On 27/11/2019 08:37, Fred Kiefer wrote:

For me this reoccurring build issues are one of the reasons why I do not use 
clang and the new runtime. They both develop too fast for me. It is quite 
normal that things change and from time to time they are even broken. If I 
remember correctly most of the questions on the development mailing list in 
recent years where caused by this. I prefer to spend my little time on GNUstep 
itself and not on fixing the build infrastructure. (Resulting in a less than 
optimal GNUstep environment for me.) What we need to do is minimise the pain 
for people who choose the other way.


Fred, with respect, this is one of the main reasons the developer 
experience for GNUstep is so bad: the core developers are not eating 
their own dogfood.  If our message to people is 'sure, GNUstep works 
with the latest Clang and all of the features that someone who learned 
Objective-C in the last decade expects, but we can also compile it with 
GCC' and that really means 'we only test it with GCC, but we hope it all 
works with the new stuff' then we're really saying 'don't bother trying 
to use the new stuff, no one tests it so it's probably broken'.


I have CI for the runtime on:

 - Ubuntu
 - Windows
 - FreeBSD
 - macOS (though only the old ABI)

I fix bugs as they are filed and the CI scripts show how to build on any 
of these platforms.  It depends on a recent clang release, but this is 
available as a binary package on all of those platforms and then the 
build process is exactly the same as any other CMake.  A quick grep of 
the FreeBSD ports tree tells me that this is over 1615 packages and a 
look at the list shows that it's a lot of the very popular ones (e.g. 
KDE, LLVM), so this isn't some esoteric build system.  CMake is even 
supported out of the box by Visual Studio now.


Many of the issues that I've fixed over the last year or two were only 
apparent when people started using non-trivial things using ARC.


We shipped an ARC implementation in 2011.  Since then, how many of the 
active GNUstep developers have worked in a configuration where they were 
stress testing support for this configuration?


There were a total of 14 commits to the runtime's ARC code between 2012 
and 2017 inclusive, an average of under 3 a year.


There have been 23 commits to that code in 2018 and 2019 *because people 
have been using it and reporting bugs*.  The main bugs that were fixed, 
which were difficult or impossible to trigger in unit tests:


- Andreas found perf impacted on a 24-core machine by the fact that 
every object that was being deallocated acquired a mutex to serialise 
deallocation with respect to weak loads.  We now only do that for 
objects that have ever had a weak pointer taken to them.  We could 
improve it by sharding the locking if necessary.


- Frederik hit an issue with hash collisions that was triggered only 
when you had a lot of weak pointers in a program.


- Jordan reported an issue where weak pointers were seeing memory 
corruption as a result of reading uninitialised data.


Note the names of these people: none of them are core GNUstep 
contributors.  All of these issues would have been found earlier if 
GNUstep developers had started using ARC in 2012, when it was more or 
less stable.


The same is true for the NS{Hash,Map}Table bugs that I fixed over the 
weekend.  If core GNUstep developers were using weak object map tables 
(if, for example, NSNotificationCenter used one for the registered 
observers) then these issues would have been apparent years ago and 
would have been fixed.


I am no longer actively working on Foundation or AppKit, so I shouldn't 
get much of a say in what those projects do, but if GNUstep is going to 
be tested with only GCC then my advice would be:


 - Actively market GNUstep as only an OpenStep implementation, drop all 
Cocoa references.


 - Drop support for Clang.

Currently, the project is setting itself up to fail by advertising 
features that no one tests.


David

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

[David Chisnall]

On 26/11/2019 22:43, Fred Kiefer wrote:

If I understand you correctly your suggestion is that we try to add support in 
gcc for some of the basic ObjC 2.0 features. That should be doable although the 
last time I tried I gave up on it. That was right after the Dublin meeting 
where we had a similar discussion to this one. The gcc people at that time 
where open to accept patches, but we should not expect too much help coming 
from their side. The reason I gave up was that at least a new version of the 
meta information that the compiler creates for the ObjC meta information was 
needed and I could not figure out a place where to flag that difference.


Please can people stop saying 'Objective-C 2'?  It's a marketing term 
that Apple used briefly and then dropped and has no relationship to any 
real definition of what the language means and does not appear on the 
Apple developer web site at all anymore.


Ian Sandoe was going to work on a better runtime abstraction layer for 
Objective-C in GCC.  He said he'd work on this two years ago, but 
doesn't seem to have made much progress, though he has done a little bit 
of work on improving the state of Apple runtime support.  His plan was 
to delay the runtime-specific lowering to the back end, which would be 
very nice and let LTO do some more interesting things.


Supporting a new ABI is much harder in GCC than Clang because of the 
history.  In GCC, the initial implementation supported only the NeXT 
runtime.  NeXT was forced to release this code via the threat of legal 
action and GCC was forced to merge the code to avoid looking stupid 
after forcing NeXT to release the code.  It was horrible code and if 
NeXT had open sourced it without the threat of legal action, I doubt GCC 
would have accepted it upstream.


Because GCC had the NeXT compiler code but no runtime support, they 
wrote an almost-compatible runtime and littered the code with `if 
(gnu_runtime)` blocks (I think, it might be `if (next_runtime)`.  NeXT / 
Apple never pulled in those changes and so merging from Apple's branch 
was always painful.


In contrast, Clang had no IR generation support when I started working 
on it.  I added an abstract class representing the runtime interfaces 
and a concrete subclass for the GCC and GNUstep runtimes.  Apple then 
maintained this because they were supporting various different runtime 
versions by this point and found the abstraction helpful.


Adding a new GCC-like runtime in clang involved simply creating a new 
subclass of this and overriding the things that had changed.  For GCC, 
it will involve untangling a load of spaghetti code.


It's probably a few months of work for someone with GCC experience to 
add support for the 2.0 ABI, though it's quite tangled with ARC if you 
wan it to actually be useful (for example, ivar metadata contains ARC 
ownership metadata now, which allows various reflection APIs to work 
correctly with ARC).


This is one of the current problems with the 'GNUstep doesn't use ARC, 
but it's fine with other things that do' approach: if you don't use ARC, 
you don't get ARC metadata, so things that use reflection don't work 
quite right from ARC.  You can't use weak properties from GNUstep.  For 
several release on macOS, things like the delegate of various NSView 
subclasses have been weak properties.  This means that modern Cocoa apps 
don't worry about ensuring that the delegate is removed from the view, 
they just rely on the runtime to handle this for them.


In GNUstep, if we wanted to depend on an ARC-supporting runtime but not 
compiler, then we *could* manually write the -setDelegate: and -delegate 
methods to call the relevant ARC functions, but:


 - The ivar would not be __weak and so access via reflection would 
break it.


 - The property metadata would not exist, so anything that depends on 
property metadata would break.


Modern Cocoa APIs are written assuming ARC and involve sublcassing 
classes that are expected to be compiled with ARC.  Over time, the 
work-arounds for the fact that GCC fundamentally does not support the 
same language that Cocoa was designed to work with are increasingly creaky.


TL;DR: Even with support for the new ABI, you still can't implement a 
fully Apple-compatible NSTableView and compile it with GCC.


David

Re: libobjc2 build issue

[David Chisnall]

On 27/11/2019 10:49, Andreas Fink wrote:
Which cmake version did you use to get it built as the one coming with 
Debian10 is too old.


What error did you get?  The minimum required is 3.1[1], which is from 
some time around 2014.  I would be shocked if Debian included something 
that old.


David

[1] 
https://github.com/gnustep/libobjc2/blob/8249036318cc3be39e40e98cdf3e62b6f5aba36d/CMakeLists.txt#L1

Re: libobjc2 build issue

[David Chisnall]

On 27/11/2019 00:25, Andreas Fink wrote:

This is now under Debian10 with clang-10 from the llvm repo.
cmake is very cryptic here to tell us where it breaks. so go figure


I never use the makefile generator for CMake, but with ninja you can do 
ninja -v to see the build steps (and it automatically prints the command 
for the failing one, so you generally don't need to).


The runtime has CI for Ubuntu, with whatever version of CMake they have 
packaged:


https://github.com/gnustep/libobjc2/blob/8249036318cc3be39e40e98cdf3e62b6f5aba36d/azure-pipelines.yml#L2

It installs the ninja-build package from the Ubuntu repo and the clang-8 
package from the LLVM APT repo (which also includes packages for Debian).


David

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

[David Chisnall]

On 25 Nov 2019, at 14:07, H. Nikolaus Schaller  wrote:
> I am not sure that this is the only way to implement it.
> 
> First of all the callMethodOn returns some block which is a data structure 
> knowing that it should take the parameter x and do some function.
> Let's call it NSBlock. NSBlock can be an ordinary object like any other so 
> that it can follow the same memory management rules as used otherwise.

That’s shifting the goalposts somewhat.  It is not news that objects and 
closures are equivalent.  Smalltalk implemented blocks as BlockClosure objects, 
Ian Piumarta’s Composite Object-Lambda Architecture, and C++ lambdas (which are 
just shorthand for C++ objects that implement `operator()`).  You can always 
express anything that uses blocks with objects.

There are two issues:

1. If you want to be compatible with existing APIs that use blocks, you need to 
be ABI compatible with blocks.
2. The reason that most languages that have objects also have blocks is that 
the shorthand syntax is very convenient.

The following are roughly equivalent:

```
@interface Delegate : NSObject
- (void)invoke;
- (instancetype)initWithCapture: (id)someObject;
@end

@implementation Delegate
{
@private
id obj;
}
- (instancetype)initWithCapture: (id)someObject
{
if ((self = [super init]) == nil) return nil;
obj = [someObject retain];
return self;
}
- (void)invoke
{
[obj doSomething];
}
- (void)dealloc
{
[obj release];
[super dealloc];
}
@end

// At construction site:

[[Delegate alloc] initWithCapture: x];

// At use site:

[delegate invoke];
```

And this, with blocks:

```
// At construction site:

^() { [x doSomething]; };

// At use site:

delegate();
```

At use, these are similar complexity for the programmer.  At the point of 
construction, one is one line of code (two or three if you put lambda bodies on 
their own lines), the other is 26.  As a programmer, I don’t want to write 26 
lines of code for a one-line callback.

In C++98 you could probably template that and provide a generic class that took 
a struct containing the captures and a C function, so you’d get a lot less 
boilerplate.  Assuming you had fudged ARC like this (as above, this code is 
typed into a mail client and probably doesn’t compile):

```
template
struct ObjCObjectWrapper
{
ObjCObjectWrapper(T x) : obj(objc_retain(x)) {}
ObjCObjectWrapper(const ObjCObjectWrapper &other) : 
obj(objc_retain(other.obj) {}
ObjCObjectWrapper(ObjCObjectWrapper &&other) : obj(other.obj)
{
other.obj = nil;
}
ObjCObjectWrapper()
{
objc_release(obj);
}
operator=(T x)
{
objc_storeStrong(&obj, x);
}
T operator()
{
return obj;
}
private:
T obj;

};
```

You could then define a generic capture structure and invoke method like this:

```
template
struct BlockImpl
{
using invoke_t = Ret(*)(Capture &, Args...);
void operator()(Args... args)
{
inv(capture, std::forward(args)…);
}
Block(Capture &&c, invoke_t fn) : capture(c), inv(fn) {}
private:
Capture capture;
invoke_t inv;
};
```

This is then generic and you could use it as follows:

```
struct CaptureOneObject
{
ObjCObjectWrapper o;
};
void invoke(CaptureOneObject &c)
{
[(id)c.o doSomething];
}
// At construction site:
std::function block(BlockImpl({x}, invoke));
// At use site:
block();
```

I *think* you could get the same ABI as blocks if you worked on the generic 
templated boilerplate a bit.

Of course, if you were using C++ then you could also write it using lambdas as:

```
// At construction site
ObjCObjectWrapper capture(x);
auto block = [=capture]() { [(id)capture.o doSomething]; };
// At use site:
block();
```

And with this you don’t need the invoke function or the capture class.  Again, 
much less boiler plate for users, though we don’t have ABI compatibility with 
blocks.  

If you were using ARC and C++, then this reduces even further to:

```
auto block = [=]() { [x doSomething]; };
```

And now we’re back with different syntax for the same thing, though with a 
different ABI (I think Clang has support for implicitly converting C++ lambdas 
to blocks, but it’s been a few years since I tried)

David

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

[David Chisnall]

On 25 Nov 2019, at 17:07, Andreas Fink  wrote:
> (https://en.wikipedia.org/wiki/Debian#Architecture_ports)
> 
> As of the Stretch release, the official ports are:[157]

[ snip ]

>   • s390x: z/Architecture with 64-bit userland, intended to replace 
> s390[160]
> Lets see what clang-10 supports under Debian10

[ snip ] 

> # llc-10 --version

[ snip ]

> systemz- SystemZ

[ snip ]

> So the real question is: Are we ok to drop support for s390x  in exchange of 
> support of Objc2.0 support and much cleaner code in libobjc2 ?

FYI: systemz and s390x both refer to IBM’s Z-series mainframes.  IBM has put a 
lot of effort into supporting LLVM on these.  That said, the architecture is 
weird and I suspect that GNUstep (and possibly Clang’s Objective-C support in 
general) would not work.  I’m happy to help anyone who wants to contribute 
Z-series support to Clang’s Objective-C front end and libobjc2 though.  

David

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

[David Chisnall]

On 25 Nov 2019, at 15:08, Yavor Doganov  wrote:
> 
> David Chisnall wrote:
>> On 25 Nov 2019, at 13:37, Yavor Doganov  wrote:
>>> RISC-V is the newest GNU/Linux architecture and it's not yet
>>> supported by Clang.
>> 
>> Yavor, I appreciate that this is an emotional topic for you, but
>> please can you try to confine yourself to the truth?
> 
> The truth is that none of the llvm-toolchain-* packages ever built on
> Debian's ricv64 autobuilders.  Not even once.  Which means that if we
> are going to build GNUstep with Clang in Debian, it won't be available
> on riscv64.
> 
> This is likely to be fixed in the near future but I'm talking about
> the reality now.

The truth is that RISC-V is a supported architecture for LLVM and is capable of 
self hosting.

If Debian is unable to build the LLVM packages (which, on Debian, are built 
with GCC) then that says a lot more about Debian and GCC than it does about 
LLVM.  Saying that Debian is unable to build LLVM packages on RISC-V is very 
different from saying that RISC-V is not supported by LLVM and intentionally 
conflating the two is misleading.

Since I started writing this, I have read the next mail from you in this thread 
and I would strongly suggest that you take a little break from the computer and 
come back when you can manage to engage in the discussion without being 
offensive.

David

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

[David Chisnall]

On 25 Nov 2019, at 13:37, Yavor Doganov  wrote:
> 
> RISC-V is the newest GNU/Linux architecture and it's not yet supported
> by Clang.

Yavor, I appreciate that this is an emotional topic for you, but please can you 
try to confine yourself to the truth?  RISC-V is a supported architecture by 
LLVM and has been for quite a while.  The author of the LLVM Weekly blog series 
is the RISC-V LLVM maintainer and is employed to work on it full time by the 
lowRISC project.  At the last LLVM DevMeeting, there were representatives from 
half a dozen companies shipping RISC-V products, all investing in LLVM.

David

Re: NSHashTable with weak objects crashing

[David Chisnall]

Hi Fred,

I agree that the right solution would be to put something in 
NSConcretePointerFunctions.h.  There are basically two ways of fixing this:

The first option, which I chose, was to modify the consumers of GSIMap so that 
they did more or less the right thing.  This is fragile and prone to breakage, 
but it does at least make things work now.  I’m not really happy with this 
approach.

The second option is to rewrite GSIMap so that the operations all relate to 
storage locations and refer to loads and stores, rather than to retain and 
release.  The last time I tried modifying GSIMap, I broke it and it took RFM a 
while to fix it.  I would be very happy for someone to make these changes, but 
I am not motivated to fight an old version of Objective-C to try to force it to 
do something that a modern compiler will do automatically.

David

> On 24 Nov 2019, at 14:50, Fred Kiefer  wrote:
> 
> Thank you David for looking into this issue. I am rather not an expert on 
> this area but looking through the existing code I would have expected that a 
> fix should rather go into the NSConcretePointerFunctions.m or 
> NSConcretePointerFunctions..h file. There we seem to set up the matching 
> functions when working with the different pointer semantics. I understand 
> that this mechanism is a lot more clumsy than what is possible with C++ 
> templates and the compiler support that is offered there for weak pointers. 
> 
> But I may be completely off here.
> 
> Fred
> 
>> Am 24.11.2019 um 13:27 schrieb David Chisnall :
>> 
>> Hi,
>> 
>> I have spent some time looking at this issue.  It appears to be an issue in 
>> how the GSIMap macros are used in NSConcrete{Hash,Map}Table.  This is 
>> horribly complex code to try to fix, because:
>> 
>> - It is generic code that is using C macros rather than type-safe C++ 
>> templates, so has a load of casts and is very difficult to follow where any 
>> of the parts actually work.
>> 
>> - It is trying to implement ARC semantics, but the raw operations are retain 
>> and release (which doesn’t really match to the behaviour of weak 
>> references), rather than read / assign / delete.  At a high level, ARC 
>> defines operations in terms of ownership by variables, manual RR defines 
>> operations in terms of operations on objects.
>> 
>> One specific problem in this instance is that GSIMap was that GSIMap was 
>> passing node->key to the HASH macro, but in ARC mode a weak object pointer 
>> can’t just be loaded, you need to use the correct read barrier.  
>> 
>> There was a comment from 2013 from RFM saying that the old code caused 
>> double retains, but unfortunately his new code was also incorrect and did 
>> not use the weak read / write barriers at all in the weak reference case, 
>> completely breaking NSMapTable with weak keys or values.
>> 
>> I have now fixed it at least enough that the test passes and submitted a PR:
>> 
>> https://github.com/gnustep/libs-base/pull/84
>> 
>> If I were writing this code from scratch, I’d make a templated class that 
>> took C++ smart pointers as arguments and then have an Objective-C class 
>> cluster, one for each of the valid combinations of NSPointerFunctionOptions. 
>>  This would make it impossible for bugs like this to creep in, because any 
>> access would implicitly go via the smart pointer wrappers (if the compiler 
>> supports ARC, then the ObjC ones would be fairly trivial).  WinObjC uses a 
>> similar approach, though with run-time specialisation.
>> 
>> Note that, even when correct, the current code is quite dependent on the ARC 
>> optimiser for performance.  It will repeatedly call objc_loadWeak(), which 
>> returns an autoreleased object.  The ARC optimiser can hopefully transform 
>> some of these into objc_loadWeakRetained() calls followed by objc_release() 
>> calls and avoid filling up the autorelease pool, but I’m not convinced that 
>> it will for this code.  If someone were willing to rewrite GSIMap to expose 
>> an interface cleanly in terms of operations on variables that hold 
>> references rather than on objects, then it would be possible for the hash 
>> function, for example, to be defined as objc_loadWeakRetained(), -hash, 
>> objc_release() directly, which would avoid touching the autorelease pool.
>> 
>> For reference, a std::unordered_map with strong or weak object pointers Just 
>> Works™ with clang.  If we were using C++ and ARC in GNUstep, the NSMapTable 
>> and NSHashTable code would be a fraction of their current size and a lot 
>> more correct.  There are various reasons that I rarely contribute to GNUstep 
>> anymore, bu

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

[David Chisnall]

On 25 Nov 2019, at 10:18, H. Nikolaus Schaller  wrote:
> 
> Fred mentioned that it could be possible to define some block wrapper macros 
> if some time is invested.
> It that works out, we do not make our decisions depend on gcc *not* 
> implementing something.

Fred made this claim, but he also added the caveat that it would likely be 
limited to blocks with no captures.  In this, I believe that he’s right.  A 
stateless block is:

 - A function that’s used when you invoke the block.
 - A fixed structure describing the block, its type encoding and a couple of 
other things.

Stateful blocks also add a load of fields on the end that describe how to copy 
and destroy each of the captures.  For blocks to actually be useful, you need 
state.  You can’t, with C macros, implement something that defines a load of 
functions inline.  You probably could create a set of macros that would 
simplify the effort in building the block byval structures, but it’s still 
non-trivial.

Note that it is probably possible (though verbose) to implement this using C++ 
templates (though matching the ABI is tricky).  I think most people reading 
this have no idea how complex the block generation code is.  When I implemented 
Pragmatic Smalltalk, I write compiler support for a subset of the blocks ABI 
and that was a few hundred lines of code for the compiler.  Doing the same in 
metaprogramming (especially with C macros) would be incredibly hard.


Consider this trivial compilation unit:

```
@interface X
- (void)doSomething;
@end

typedef void(^block)(void);

block callMethodOn(id x)
{
return ^() { [x doSomething]; };
}
```

Now, when I run this through clang, this is what I get out as LLVM IR (eliding 
everything that isn’t directly related to blocks):

```
%struct.__block_descriptor = type { i64, i64 }

$__copy_helper_block_e8_32s = comdat any

$__destroy_helper_block_e8_32s = comdat any


@"__block_descriptor_40_e8_32s_e5_v8\01?0l" = linkonce_odr hidden unnamed_addr 
constant { i64, i64, i8*, i8*, i8*, i8* } { i64 0, i64 40, i8* bitcast (void 
(i8*, i8*)* @__copy_helper_block_e8_32s to i8*), i8* bitcast (void (i8*)* 
@__destroy_helper_block_e8_32s to i8*), i8* getelementptr inbounds ([6 x i8], 
[6 x i8]* @.str, i32 0, i32 0), i8* null }, align 8

; Function Attrs: nounwind uwtable
define dso_local void ()* @callMethodOn(i8*) local_unnamed_addr #0 {
  %2 = alloca <{ i8*, i32, i32, i8*, %struct.__block_descriptor*, i8* }>, align 
8
  %3 = tail call i8* @llvm.objc.retain(i8* %0) #1
  %4 = getelementptr inbounds <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>, <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>* %2, i64 0, i32 5
  %5 = getelementptr inbounds <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>, <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>* %2, i64 0, i32 0
  store i8* bitcast (i8** @_NSConcreteStackBlock to i8*), i8** %5, align 8
  %6 = getelementptr inbounds <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>, <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>* %2, i64 0, i32 1
  store i32 -1040187392, i32* %6, align 8
  %7 = getelementptr inbounds <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>, <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>* %2, i64 0, i32 2
  store i32 0, i32* %7, align 4
  %8 = getelementptr inbounds <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>, <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>* %2, i64 0, i32 3
  store i8* bitcast (void (i8*)* @__callMethodOn_block_invoke to i8*), i8** %8, 
align 8
  %9 = getelementptr inbounds <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>, <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>* %2, i64 0, i32 4
  store %struct.__block_descriptor* bitcast ({ i64, i64, i8*, i8*, i8*, i8* }* 
@"__block_descriptor_40_e8_32s_e5_v8\01?0l" to %struct.__block_descriptor*), 
%struct.__block_descriptor** %9, align 8
  store i8* %0, i8** %4, align 8, !tbaa !2
  %10 = bitcast <{ i8*, i32, i32, i8*, %struct.__block_descriptor*, i8* }>* %2 
to void ()*
  %11 = bitcast void ()* %10 to i8*
  %12 = tail call i8* @llvm.objc.retain(i8* %0) #1
  %13 = call i8* @llvm.objc.retainBlock(i8* nonnull %11) #1, 
!clang.arc.copy_on_escape !5
  %14 = bitcast i8* %13 to void ()*
  %15 = load i8*, i8** %4, align 8
  call void @llvm.objc.release(i8* %15) #1, !clang.imprecise_release !5
  call void @llvm.objc.release(i8* %0) #1, !clang.imprecise_release !5
  %16 = tail call i8* @llvm.objc.autoreleaseReturnValue(i8* %13) #1
  ret void ()* %14
}

; Function Attrs: nounwind
declare i8* @llvm.objc.retain(i8*) #1

; Function Attrs: uwtable
define internal void @__callMethodOn_block_invoke(i8* nocapture readonly) #2 {
  %2 = getelementptr inbounds i8, i8* %0, i64 32
  %3 = bitcast i8* %2 to i8**
  %4 = load i8*, i8** %3, align 8, !tbaa !2
  tail call void bitcast (i8* (i8*, ...)* @objc_msgSend to void (i8*, 
i8*)*)(i8* %4, i8* bitcast ({ i8*, i8* }* 
@".objc_se

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

[David Chisnall]

On 25 Nov 2019, at 09:37, Gregory Casamento  wrote:
> 
> * C++, while this is not exclusive to clang, gcc doesn't support the latest 
> version of C++.  Clang is extraordinarily good at optimization.

I don’t think this is true.  We have a C++17 project that we test in CI with 
GCC.  The only times that we experience problems are when we use some 
non-standard attributes that GCC doesn’t support (but we also build with Visual 
Studio, so we rarely find anything that we need that those two support but GCC 
doesn’t, it’s only when we have something ELF-specific that’s a problem).

I don’t know how good GCC’s Objective-C++ support is (as I recall, Objective-C 
and Objective-C++ in GCC aren’t just base-language + Objective-*, so it isn’t 
necessarily a given that you get full C++17 support in GCC’s Objective-C++), 
but using C++ smart pointers you can get a lot of ARC (at the very least - and 
prior to ARC support, I did - you can implement smart pointers that manage 
Objective-C retain / release and use them to hold Objective-C objects in 
collections.

David

Re: NSHashTable with weak objects crashing

[David Chisnall]

Hi,

I have spent some time looking at this issue.  It appears to be an issue in how 
the GSIMap macros are used in NSConcrete{Hash,Map}Table.  This is horribly 
complex code to try to fix, because:

 - It is generic code that is using C macros rather than type-safe C++ 
templates, so has a load of casts and is very difficult to follow where any of 
the parts actually work.

 - It is trying to implement ARC semantics, but the raw operations are retain 
and release (which doesn’t really match to the behaviour of weak references), 
rather than read / assign / delete.  At a high level, ARC defines operations in 
terms of ownership by variables, manual RR defines operations in terms of 
operations on objects.

One specific problem in this instance is that GSIMap was that GSIMap was 
passing node->key to the HASH macro, but in ARC mode a weak object pointer 
can’t just be loaded, you need to use the correct read barrier.  

There was a comment from 2013 from RFM saying that the old code caused double 
retains, but unfortunately his new code was also incorrect and did not use the 
weak read / write barriers at all in the weak reference case, completely 
breaking NSMapTable with weak keys or values.

I have now fixed it at least enough that the test passes and submitted a PR:

https://github.com/gnustep/libs-base/pull/84

If I were writing this code from scratch, I’d make a templated class that took 
C++ smart pointers as arguments and then have an Objective-C class cluster, one 
for each of the valid combinations of NSPointerFunctionOptions.  This would 
make it impossible for bugs like this to creep in, because any access would 
implicitly go via the smart pointer wrappers (if the compiler supports ARC, 
then the ObjC ones would be fairly trivial).  WinObjC uses a similar approach, 
though with run-time specialisation.

Note that, even when correct, the current code is quite dependent on the ARC 
optimiser for performance.  It will repeatedly call objc_loadWeak(), which 
returns an autoreleased object.  The ARC optimiser can hopefully transform some 
of these into objc_loadWeakRetained() calls followed by objc_release() calls 
and avoid filling up the autorelease pool, but I’m not convinced that it will 
for this code.  If someone were willing to rewrite GSIMap to expose an 
interface cleanly in terms of operations on variables that hold references 
rather than on objects, then it would be possible for the hash function, for 
example, to be defined as objc_loadWeakRetained(), -hash, objc_release() 
directly, which would avoid touching the autorelease pool.

For reference, a std::unordered_map with strong or weak object pointers Just 
Works™ with clang.  If we were using C++ and ARC in GNUstep, the NSMapTable and 
NSHashTable code would be a fraction of their current size and a lot more 
correct.  There are various reasons that I rarely contribute to GNUstep 
anymore, but the fact that the community actively prevents me from using tools 
that make my life easier was a significant one.

As a high-level observation, not using ARC within GNUstep itself means that we 
ship bugs.  This code has been broken since at least 2013, possibly earlier.  
If GNUstep developers are not using modern Objective-C features then anyone who 
tries to use them will find that things are broken.  

David

P.S. I spent about an hour of this debugging process fighting the tests suite.  
Please can someone who understands the test suite make it provide simple 
instructions for building a single test?  Or even doing a -j32 build of all of 
the tests, rather than waiting for each one to run before moving on to the next 
one.  It takes me about 10 seconds to compile -base and then a few minutes to 
wait for gmake check -j32 to build the test that I care about.  

> On 11 Nov 2019, at 22:16, Fred Kiefer  wrote:
> 
> Hi David,
> 
> you are aware that Frederik is talking about the travis CI system on Github 
> where his tests are failing? Either the whole build system is set up 
> incorrectly or we have a general issue for week pointers.
> We probably should not expect these tests to work with gcc, maybe there is a 
> way to disable them for this setup?
> 
> Fred
> 
>> Am 11.11.2019 um 18:36 schrieb David Chisnall :
>> 
>> 
>> Where do the tests fail currently?  These look sufficiently simple that they 
>> should just be calling a few of the ARC functions.  The implementation of 
>> these classes is in NSConcrete{PointerFunctions,HashTable}.m and their 
>> interaction with the runtime is defined here:
>> 
>> https://github.com/gnustep/libs-base/blob/3d77109fb634f11e5d51dd9b13002102ab419729/Source/NSConcretePointerFunctions.h#L33
>> 
>> From what you've said, I wonder if you're compiling GNUstep-base without 
>> access to the libobjc2 headers?  If so, then it will provide the old-runtime 
>> versions of these functions

Re: Package building

[David Chisnall]

On 23 Nov 2019, at 14:48, Riccardo Mottola  wrote:
> 
> Hi,
> 
> 
> On 11/20/19 12:28 PM, David Chisnall wrote:
>> 
>> I'm happy to take contributions for the assembly paths for other 
>> architectures.  We currently have:
>> 
>> - x86-32
>> - x86-64
>> - AArch32
>> - AArch64
>> - MIPS (at least n64 works, I think o32 and n32 are there but untested).
>> 
>> I passionately hate PowerPC assembly, so will definitely not write that 
>> myself, but anyone who wants to add it is very welcome to do so.  I will 
>> probably get around to adding RISC-V support at some point.
> 
> 
> this list only lacks in my interest:
> 
> - MIPS LittleEndian (as soon as I get the small project with Nikolaus 
> actually do something useful) or is your implementation already 
> endian-independent?

I’ve only tested it on BE, I think the logic that pulls bytes out of the 
selector index will need tweaking for LE, but that should be about it.

SPARC and POWER are completely missing, but I don’t see any fundamental problem 
with someone adding them.  POWER may be fun because of the function descriptor 
model.  I’m not sure how well LLVM’s SPARC back end works.  ESA did some work 
on it for LEON, so SPARC32 may be stable.

There’s also System/Z, which is supported by LLVM, if someone wants to run 
Objective-C on a mainframe...

My somewhat biased view is that if there aren’t enough engaged users for a 
platform that we can get around 100 lines of assembly written for that 
platform, then it’s hard to justify the investment in that platform.

David

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

[David Chisnall]

On 22 Nov 2019, at 05:31, H. Nikolaus Schaller  wrote:
> 
> And the first thing I turn off in a
> new Xcode project is ARC.

Why?  ARC generates smaller code, faster code, and code that is more likely to 
be correct.  I find it incredibly hard to understand why someone would actively 
choose to have to spend more time thinking about memory management so that they 
can end up with larger binaries that run more slowly.

David

Re: Package building

[David Chisnall]

On 20 Nov 2019, at 23:13, cobjective  wrote:
> 
> On 19 Nov 2019, at 13:42, David Chisnall  wrote:
>> 
>> On 19/11/2019 09:40, Johannes Brakensiek wrote:
>>>> I understand that the initial idea was to attract more users/developers, 
>>>> but… It’s not working.
>>> Hm, yes. I think developers don’t need a nice UI at first place (and I 
>>> think most of what developers need luckily is already provided by Apple as 
>>> of today). But developers need happy users (if you’re not developing only 
>>> for yourself) and I think happy users need a stable, solid and consistent 
>>> UX. That would be provided by a NextStep based UI guideline. But they also 
>>> need a pretty UI (which is not what you’d call that NextStep look nowadays, 
>>> imho).
>> 
>> I would add to that: most users will not be using a GNUstep DE.  This was 
>> one of the biggest mistakes that we made with Etoile: we did not have an 
>> incremental adoption story.
>> 
> How do you know about users? I tried Etoile some time ago. 

By looking at current DE usage.

> My thoughts were: “Cool thing. Not ready for everyday usage yet”.
> NEXTSPACE is. And it looks and feels familiar to Window Maker users.

And if you pick a random desktop Linux or *BSD user, there’s approximately a 0% 
chance that they are using NEXTSPACE.  If I write an application targeting 
NEXTSPACE users, I have a far smaller reach than if I write an application that 
integrates well with a GNOME, KDE, or even Windows desktop.  

I have first-hand experience of this from a couple of years ago, when I wrote 
an application in Objective-C++ for inspecting the (huge - 100GB+) traces that 
our processor generates.  Our group was roughly split between Mac and Ubuntu 
users.  The Mac users loved it, the Ubuntu users hated it.  Even after doing a 
load of theming to get the menu bar in the window and so on, they just about 
tolerated it.

If I were doing it again, I’d probably keep the core in C++ and use Electron 
for the GUI.

>> If you want GNUstep to be attractive to developers, you need to make it easy 
>> for them to ship apps that integrate with an existing *NIX DE and with 
>> Windows.  One of the biggest things that RedHat did for Linux desktop 
>> usability was teach the GTK+ and Qt theme engines to understand a shared 
>> format and unify shortcut keys between the two.  After that, it didn't 
>> matter (much) if you needed a mix of GNOME and KDE apps, your desktop still 
>> felt (approximately) cohesive.
> 
> Indeed. But keep in mind that GNOME and KDE apps share (with some minor 
> differences) the same style for desktop and applications (icons on desktop, 
> sys tray, in-window menus, scrollbars on the right and so on). That’s why it 
> was quite natural to make look of Qt/GTK+ apps consistent (cohesive). GNUstep 
> roots are in NeXT's OS (OpenStep specification appeared around 1997, NeXT and 
> Apple started merging these days). This legacy has it’s own charm not because 
> of look but mostly because of “feel” (style of doing things). That’s why I 
> like GNUstep.

You seem to be forgetting some of the heritage of the OpenStep specification 
(which was released in 1993, not 1997).  It was originally designed by NeXT and 
Sun (hence the NS prefix) to allow applications to be written once and then 
easily ported between Sun’s CDE desktop environment and NeXT’s NeXTSTEP / 
OPENSTEP environment.  CDE had a lot of the UI abstractions that KDE and GNOME 
share.

NeXT also released a version of OpenStep for Windows and Apple demoed an 
improved version that removed the DPS abstraction and used native drawing APIs 
(though they never shipped it).

The OpenStep specification is specifically written to abstract away a lot of 
the details.  It doesn’t say whether menus are in window, at the top of the 
screen, or floating.  It doesn’t say where scroll bars go.  It doesn’t say 
whether you have a dock or a task bar.  

Now, for a great cross-platform app, you may want to have different NIBs that 
completely reflect each platform’s HIGs, but you can have something that feels 
close without that and separate the platform porting effort from the rest.


>> 
>> At the moment, people with one GNUstep app feel that it sticks out and is 
>> difficult to use because it doesn't follow the same UI models as the rest of 
>> their system.  That means that they then don't want a second one.
> Sure. Let’s imagine that GNUstep application follows Qt/GTK+ UI model. I have 
> a question: Why average developer will want to write application using 
> GNUstep libraries instead of GNOME/KDE? What are the benefits?

Do you think that the OpenStep APIs are cleaner and easier to use than Qt or 
GTK+?  If so, then there’s your answer.  If not, then 

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

[David Chisnall]

> 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.

Apple and WinObjC both use C++ internally to implement a lot of the Objective-C 
classes.  Objective-C++ lets you use C++ features in the implementation and 
export Objective-C interfaces.  This gets you the best of both worlds.  A few 
years ago, I experimented with creating an NSMutableDictionary concrete 
subclass that used std::unordered_map in the implementation.  It was less code 
than the GSIMap-based version in GNUstep, with ARC all of the memory management 
was free, and it performed better.  I used a typedef for the concrete type that 
it used for the C++ map object and so I could switch between one of a dozen 
open source hash table implementations by changing two lines of code (the 
#include line for the map and the typedef line for picking which type to use).  
Try doing that in Objective-C...

In my own code, if I use Objective-C frameworks, I now use Objective-C++ 
exclusively.  NSDictionary lets my have a map from objects to objects, but what 
if I want a map from objects to selectors or integers to objects?  I can only 
do this with NSDictionary if I box the non-object version.  In contrast, I can 
write:

std::unordered_map foo;
std::unordered_map foo;

And both of these Just Work™.  I can also do things like:

std::unordered_map foo;

And get a map from integers to weak objects.  If I decide that this isn’t 
sufficiently efficient, I can replace it with something like llvm::DenseMap or 
tsl::robin_map with a trivial code change - but I can defer that optimisation 
until I’ve done some profiling and determined that it actually matters.

From the perspective of C++, Objective-C object pointers are objects that have 
a non-trivial copy constructor and destructor.  Anything that correctly handles 
C++ ownership correctly handles Objective-C memory management.  

Outside of the framework that I’m implementing, I can still expose Objective-C 
interfaces and benefit from all of the loose coupling that dynamic dispatch and 
non-fragile instance variables imply.

>>> How many developers are comfortable with C++?
>> 
>> I am comfortable with it, but not for the purposes of GNUstep.
>> I gave up on it a number of years ago, simply because IMO it was
>> too complex and fragile; basically I viewed it as an engineering
>> nightmare.
> 
> Gave up on what?  GCC or C++?

Most people that have this opinion about C++ have not looked at it since C++11 
became mainstream.  C++98 was a terrible language.  C++11 filed off most of the 
rough corners.  C++14 and C++17 both improved things and C++17 is now a nice 
language.

To give another data point, we have recently open sourced a memory allocator 
written in C++[1].  I am doing most of my development work in a FreeBSD VM that 
has replaced jemalloc in libc with it.  jemalloc is a usually the go-to 
allocator for when people want higher performance (FireFox uses it, for 
example, and it’s the default allocator on Android).  jemalloc is written in C. 
 The binary for snmalloc is about half the size, it performs better, and we 
have done several aggressive refactorings that improve performance (our 
allocation fast path - hit most of the time for allocations under 64KiB - is 15 
x86-64 instructions, our fast path for deallocation is 25). There’s nothing in 
snmalloc that we couldn’t have written in C, but we have a number of tables 
that are generated from a mixture of constexpr and templates that are easy to 
modify in our codebase and which are generated in Python scripts in other 
allocators that do similar things.

>  
>> Every project I've seen using it (either public, or commercial)
>> seem to use a different subset, and it can be difficult to spot
>> when a mechanism outwith that subset accidentally creeps in.
>> 
> ??? 

Again, this was completely true un

Re: Package building

[David Chisnall]

On 20/11/2019 11:07, Andreas Fink wrote:

is libobjc even supporting all these other platforms?


The GCC runtime is written in pure C and so should work everywhere that 
there's a C compiler.  The GNUstep runtime uses assembly to implement 
two features that can't be implemented in pure C:


objc_msgSend
imp_implementationWithBlock

Both of these need to modify the call frame and then pass all of the 
arguments unmodified, which C doesn't support.


In theory, you should be able to use the runtime without these features, 
but I'm not sure if it actually builds (happy to take patches to fix that).


KVO is *significantly* simpler to implement with 
imp_implementationWithBlock, so it would be nice if we could depend on 
that.  objc_msgSend is largely a performance optimisation (clang uses it 
only on platforms where it's supported).


I'm happy to take contributions for the assembly paths for other 
architectures.  We currently have:


- x86-32
- x86-64
- AArch32
- AArch64
- MIPS (at least n64 works, I think o32 and n32 are there but untested).

I passionately hate PowerPC assembly, so will definitely not write that 
myself, but anyone who wants to add it is very welcome to do so.  I will 
probably get around to adding RISC-V support at some point.


David

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

[David Chisnall]

On 19/11/2019 23:28, Ivan Vučica wrote:
On Tue, Nov 19, 2019 at 5:26 PM Jordan Schidlowsky 
mailto:jor...@noodlecake.com>> wrote:
 > Is this not the strongest argument to deprecate GCC, and just build 
on Clang/LLVM?  If feature parity with Apple's API is the goal, isn't 
this kind of a requirement at this point?

 >
 > There's other rather large projects moving purely to a llvm toolchain 
(android ndk), so it wouldn't be totally unheard of.  They've deprecated 
gcc and are removing it entirely in a future release.


Multiple compilers is still a good thing (even if one of them is worse 
than the others).


I agree in theory, but in effect the two compilers support entirely 
different languages.  The jump from the dialect of Objective-C that gcc 
supports to the dialect that Clang supports is similar in terms of user 
experience to the jump from C++98 to C++11.  All of the C++ projects 
that I work on have now switched (or are in the process of switching) to 
depending on C++17, because it's a significant productivity boost.


Supporting GCC is not free.  It adds cost to every single GNUstep 
commit.  You have to think about memory management, not just simple 
ownership rules.  You have to use macros instead of core language 
features (such as fast enumeration).  You can't use weak pointers.  You 
can't use blocks.


If GNUstep had a large army of developers, I'd have no objections to 
this.  At the moment, GNUstep is severely under-resourced and time spent 
supporting GCC is time not spent getting the core libraries up to parity 
with a vaguely recent version of macOS.


GCC users can accept that not all applications will be compatible, if we 
can't implement APIs that depend on the "new" features.


Again, GCC users are not the only ones that are paying the cost.  I did 
a run with the ARC migration tool a while ago and around 2/3 of the 
GNUstep source files could be automatically migrated, many of the 
remainder needed only minor tweaks.  Using modern Objective-C++ in the 
core of GNUstep could significantly improve productivity.  For example, 
GSIMap is an implementation of a hash table using C macros.  It is very 
difficult to modify (I think I have broken something every time that 
I've tried).  Replacing this with a C++ template would be fairly simple 
and would make it much easier to switch to other implementations as 
required (there are a bunch of well-optimised C++ hash table 
implementations with compatible interfaces tailored to different uses, 
we could just pull half a dozen of them into the codebase and use them, 
complete with type safety rather than a load of casts through void*) 
Oh, and with ARC, all of the C++ implementations have correct memory 
management for Objective-C, for free.



But perhaps dropping GCC fully is too drastic.

I have a similar opinion about some GUI backends; they're not very 
useful, but guide gnustep-gui and gnustep-back APIs to be more flexible 
and don't depend on just e.g. Cairo.


Again, this comes at a cost.  For a long time (I'm not sure if this is 
fixed now), Cairo was slow and flickery because it was being forced to 
go via a double-buffering mechanism that was designed for libart. 
Removing this without breaking the xlib and art back ends was nontrivial.


Even today, I believe the Cairo back end is still using the 'toy' font 
APIs and not the ones that integrate with Harfbuzz, so we get quite poor 
kerning with Cairo and miss some important features.


David

Re: Package building

[David Chisnall]

On 20/11/2019 09:55, Richard Frith-Macdonald wrote:

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.


ARC and non-ARC work well together, but ARC depends on the non-fragile 
ABI, so you can't mix ARC and GCC-compiled code reliably.


In theory, the GNUstep runtime 1.x ABI supports mixing GCC-compiled code 
and non-fragile ABI code and it should work as long as the older ABI 
classes are closer to the roots of the class hierarchy than the newer 
ones.  In practice, there's a bug in the Linux (glibc?) run-time linker 
that means that ivar offsets are sometime incorrect when you do this.


The GNUstep Runtime 2.0 ABI is not supported by GCC and is a backwards 
compatibility break.  In hindsight, I probably should have done this 
from the start because there's a lot of legacy in the GCC runtime ABI 
(which is a minor tweak to the NeXTSTEP runtime ABI) that makes 
supporting newer language features very difficult.


David

Re: GNUstep Discord Server

[David Chisnall]

On 19/11/2019 16:17, Liam Proven wrote:

On Tue, 19 Nov 2019 at 15:43, David Chisnall  wrote:


Their T&Cs are not some that I would ever consider agreeing to, or that
I would ever recommend for any free / open source software project and I
would strongly recommend that anyone considering using this service
reads their T&Cs carefully before deciding to accept them.


Interesting. Just gave them a quick look.

Bearing in mind that it's a gaming service, they looked fair enough.
What were your objections?


It's not a gaming service, it's a collaboration platform (originally one 
for gaming, but that's not how it's used in this context).  A few things:


1. They have a very broad commercial license to anything that people 
say, including in private chats.


2. You warrant that you own the copyright on everything you upload.  If 
you copy any GNUstep code into the chat, for example, you are breaking 
the T&Cs.


3. They are limited to non-commercial use, which is poorly defined but 
probably precludes anyone building products on GNUstep (at the very 
least) from using it to discuss GNUstep without violating the T&Cs.


David

Re: GNUstep Discord Server

[David Chisnall]

Hi,

Discourse came up in the discussion.  I've never used it, but Swift does 
and apparently it works well for them.


David


On 19/11/2019 14:59, Umberto Cerrato wrote:

Interesting timing too...

I’ll check immediately! Also because I have some Project chat on it... 
Unfortunately there seems there is nothing like it atm... I already heard some 
privacy issues with it...

That would be that kind of choice you have to make when you have a very good 
platform you would not leave but at the same time you care about these things 
and so... Yeah, I wrote this thought in the worse manner possible but that. I 
have to take action but seriously, It is very well made and there are no 
alternatives around...

(A little bit like e.g. Facebook...)

Anyway thank you


Il giorno 19 nov 2019, alle ore 15:43, David Chisnall 
 ha scritto:

Hi,

Interesting timing, Discord just came up in the context of LLVM yesterday and ass a 
result, I read their T&Cs and Privacy Policy.

Their T&Cs are not some that I would ever consider agreeing to, or that I would 
ever recommend for any free / open source software project and I would strongly 
recommend that anyone considering using this service reads their T&Cs carefully 
before deciding to accept them.

David



On 19/11/2019 14:35, Umberto Cerrato wrote:
Hello everyone,
Since I needed it, I created this Discord Server about GNUstep. You are very 
welcome to join!
And since I am new to GNUstep, but I really like it, I can’t wait to chat a 
little bit about it! And maybe getting some help in installing/using it!
Join link: https://discord.gg/DGPqt6B
Thank you,
Umberto

Re: GNUstep Discord Server

[David Chisnall]

Hi,

Interesting timing, Discord just came up in the context of LLVM 
yesterday and ass a result, I read their T&Cs and Privacy Policy.


Their T&Cs are not some that I would ever consider agreeing to, or that 
I would ever recommend for any free / open source software project and I 
would strongly recommend that anyone considering using this service 
reads their T&Cs carefully before deciding to accept them.


David


On 19/11/2019 14:35, Umberto Cerrato wrote:

Hello everyone,
Since I needed it, I created this Discord Server about GNUstep. You are very 
welcome to join!

And since I am new to GNUstep, but I really like it, I can’t wait to chat a 
little bit about it! And maybe getting some help in installing/using it!

Join link: https://discord.gg/DGPqt6B

Thank you,
Umberto

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

[David Chisnall]

On 18/11/2019 11:31, Gregory Casamento wrote:

Currently I know about the following missing functionality:

* ARC


These three letters hide a huge amount.  It isn't just inserting 
-retain/-release calls, the requirements for ARC are:


 - Add the concept of method families for controlling ownership.
 - Add syntax for the qualifiers and attributes for overriding 
autodetected method families.
 - Add a set of lifetime analyses in the front end to detect where to 
insert the ARC calls.  There are around 20 different calls inserted here 
depending on the analyses.
 - Add some non-trivial optimisations to elide most of the refcount 
manipulations (without these, ARC code has a lot of redundant refcount 
manipulation).
 - Support ownership metadata in the ivar reflection info so that the 
runtime can properly implement object_setIVar().


In Clang, this is about as much code (scattered throughout the codebase, 
interacting with other aspects of C and C++ language semantics in 
non-trivial ways, with a high testing overhead) as the entire 
Objective-C implementation in GCC.  The complexity of adding this to GCC 
is greater the complexity of adding Objective-C support to GCC from 
scratch was.



* block support


The Apple fork did have blocks support, but it was the old ABI and broke 
in exciting ways.  Blocks in modern Objective-C have some non-trivial 
interactions with ARC.



* template support (for collection objects like NSArray)


Note that these are not templates, they are type-erasing generics.  I 
believe GCC's Objective-C++ support is sufficient that you can use 
Objective-C classes as template parameters (which means you can 
implement smart pointers that wrap Objective-C objects, which gets you 
about half way to ARC in terms of usability).


Generics would probably be relatively easy to add, because they're just 
semantic analysis: they're gone by the time code generation occurs.




What else is currently missing?  


Apple stopped using Objective-C 2.0 over 10 years ago, so it's probably 
time that we stopped doing so as well.  There are a bunch of features 
that are a mix of language and runtime things and sometimes difficult to 
deconflate.  Here's a rough list of things that I know are missing on 
the language side:


 - GCC supports declared properties, but none of the newer modes (e.g. 
weak).

 - GCC does not support property introspection metadata.
 - GCC does not support class properties (I'm fairly convinced that 
these are a bad idea, so that's not a huge point against it).
 - GCC does not support the non-fragile ABI and so can't support ivars 
declared in an @implementation context or a class extension.
 - Objective-C literals.  Clang supports number, array, and dictionary 
literals.  I am in two minds about whether this is a good idea.  I don't 
like the clutter in the language, but I do find that they are very 
useful in practice.

 - Subscripting for collection classes.

GCC has, I believe, recently gained support for instancetype.  I think 
it also supports fast enumeration, but I'm not 100% sure (in 
Objective-C++, you can quite easily wrap NSFastEnumeration in a C++ 
iterator, so you can work around this and GNUstep has macros for using it).


There's also the new ABI, which provides a bunch of things that are not 
directly surfaced in the language, but which depend on compiler support, 
such as:


 - Using objc_msgSend on platforms where the runtime supports it (this 
has knock-on effects on some of the forwarding).

 - Selectors are deduplicated by the linker.
 - Protocols are deduplicated by the linker.
 - Constant strings contain a hash.
 - GSTinyString for 8-character ASCII strings on 64-bit platforms.
 - Richer ivar metadata (size, alignment, ARC ownership).
 - Methods have extended type info, allowing the JavaScriptCore bridge 
to work.

 - SEH-compatible exceptions on Windows.

These changes don't require modifying any of GCC other than the codegen 
layer.



Is anyone interested in helping to implement these features in gcc?


Iain Sandoe was interested in getting GCC to feature parity, but I don't 
think he's made much progress and I don't really see the value in 
sinking 2-3 developer years of work into a project to get GCC to support 
a language that the GCC developers don't care about and where the demand 
among users for a GCC implementation is negligible.


If someone has budget to employ a developer for 2-3 years to work on 
something to improve GNUstep, I can think of a few hundred things that 
would have a higher impact than adding modern Objective-C support to GCC.


David

Re: Package building

[David Chisnall]

On 19/11/2019 09:40, Johannes Brakensiek wrote:
I understand that the initial idea was to attract more 
users/developers, but… It’s not working.


Hm, yes. I think developers don’t need a nice UI at first place (and I 
think most of what developers need luckily is already provided by Apple 
as of today). But developers need happy users (if you’re not developing 
only for yourself) and I think happy users need a stable, solid and 
consistent UX. That would be provided by a NextStep based UI guideline. 
But they also need a pretty UI (which is not what you’d call that 
NextStep look nowadays, imho).


I would add to that: most users will not be using a GNUstep DE.  This 
was one of the biggest mistakes that we made with Etoile: we did not 
have an incremental adoption story.


If you want GNUstep to be attractive to developers, you need to make it 
easy for them to ship apps that integrate with an existing *NIX DE and 
with Windows.  One of the biggest things that RedHat did for Linux 
desktop usability was teach the GTK+ and Qt theme engines to understand 
a shared format and unify shortcut keys between the two.  After that, it 
didn't matter (much) if you needed a mix of GNOME and KDE apps, your 
desktop still felt (approximately) cohesive.


At the moment, people with one GNUstep app feel that it sticks out and 
is difficult to use because it doesn't follow the same UI models as the 
rest of their system.  That means that they then don't want a second one.


Qt on Mac has the same problem: the controls are all subtly different 
and it took them years to even have the same shortcuts for navigation in 
a text field, so everyone who ran a Qt application on Mac hated it and 
never wanted to use another one.  This didn't matter so much for Qt, 
because they did have good Windows and X11 support.


Currently, GNUstep apps look and feel like native apps on MacOS, when 
you don't use GNUstep.  They look and feel alien everywhere else.


David

Re: NSHashTable with weak objects crashing

[David Chisnall]

Hi,

Where do the tests fail currently?  These look sufficiently simple that 
they should just be calling a few of the ARC functions.  The 
implementation of these classes is in 
NSConcrete{PointerFunctions,HashTable}.m and their interaction with the 
runtime is defined here:


https://github.com/gnustep/libs-base/blob/3d77109fb634f11e5d51dd9b13002102ab419729/Source/NSConcretePointerFunctions.h#L33

From what you've said, I wonder if you're compiling GNUstep-base 
without access to the libobjc2 headers?  If so, then it will provide the 
old-runtime versions of these functions, where weak is a synonym for 
unsafe_unretained (these classes on macOS did this back in the 10.7 or 
so days).  Can you put a #error in NSConcretePointerFunctions.h on line 
33 and check that this breaks the build for you?  If the build still 
works, then you're building GNUstep in a configuration that does not 
provide weak pointer semantics.


It might be better, now, to have these methods error at run time if this 
support is not available, rather than give an unsafe version.


If you are compiling the correct version, the most likely cause is that 
we're using objc_storeWeak() on a location in memory that does not 
contain either 0 or a valid object pointer (e.g. if NSHashTable is 
getting unzeroed memory).  Please can you put a breakpoint on 
objc_storeWeak and see what happens?


David

On 11/11/2019 15:00, Frederik Seiffert wrote:

Hi all,

I’ve opened a pull request with some very simple tests for the 
NSHashTable/NSMapTable weak object support:

https://github.com/gnustep/libs-base/pull/80

Unfortunately they are failing on the CI, so it seems that the issues 
described below are not specific to our setup. I also confirmed the 
tests pass when run against Apple’s Foundation.


Does anyone have knowledge of the weak pointer support in GNUstep and 
could take a look at this?


Thanks!
Frederik


Am 07.10.2019 um 16:51 schrieb Frederik Seiffert 
mailto:frede...@algoriddim.com>>:


Hi David,

While replacing the hash table, I managed to turn it into a 
reproduceable fault on at least one machine.  The bug is quite subtle:


We have a map from objects to weak reference structures.
The weak reference structure points to the object.
When we delete the last weak reference, we delete the object from the 
map.

We delete the object from the map using the object as the key.
But by the time a weak reference is deallocated, its object pointer 
has been zeroed...
...so we always remove a random element from the map and leave a 
dangling pointer in the table.


Should this already be fixed on the latest libobjc2 master?

Going back to my original issue about NSHashTable with weak objects, 
I’m still seeing it crash with the latest libobjc2 master and also 
using the arc-cxx branch.


It reproduces quite easily with the following code (compiled with 
ARC), which crashes either directly in addObject: on the first 
invocation (when using weakObjectsHashTable), or in -allObjects on the 
second or third invocation (when using hashTableWithWeakObjects).


static __strong NSHashTable *_hashTable = nil;
static __strong NSObject *_test = nil;
- (void)testHashTable
{
 @autoreleasepool {
 if (!_hashTable) {
 _hashTable = [NSHashTable weakObjectsHashTable];// or 
hashTableWithWeakObjects
 _test = [NSObjectnew];
 [_hashTable addObject:_test];// crash 1
 }else {
 _test =nil;
 }

 NSLog(@"HashTable %@ (_test: %@)", _hashTable.allObjects, _test);// 
crash 2
 }
}

Similarly, NSMapTable crashes as well in the second invocation of the 
following function, although I’m not sure if this is the same root 
cause as the hash table crash:


static __strong NSMapTable *_mapTable = nil;
static __strong NSObject *_test = nil;
- (void)testMapTable
{
 @autoreleasepool {
 if (!_mapTable) {
 _mapTable = [NSMapTable strongToWeakObjectsMapTable];
 _test = [NSObjectnew];
 [_mapTable setObject:_test forKey:@"test"];
 }else {
 NSLog(@"obj pre: %@", [_mapTable objectForKey:@"test"]);// crash!!!
 _test =nil;
 NSLog(@"obj post: %@", [_mapTable objectForKey:@"test"]);
 }

 NSLog(@"MapTable %@ (_test: %@)", _mapTable.dictionaryRepresentation, 
_test);
 }
}

I’m pasting the stack traces below. I’d appreciate if anyone can shed 
some light on this.


Thanks!
Frederik



*NSHashTable crash using weakObjectsHashTable:*

  * frame #0: 0xeca8c1d0 libart.so`art_sigsegv_fault
    frame #1: 0xeca8c774 libart.so`art::FaultManager::HandleFault(int, 
siginfo*, void*) + 372
    frame #2: 0xeca8c49b libart.so`art::art_fault_handler(int, 
siginfo*, void*) (.llvm.650222801) + 43
    frame #3: 0x625bd6af 
app_process32`___lldb_unnamed_symbol22$$app_process32 + 623

    frame #4: 0xefee7c50 libc.so`___lldb_unnamed_symbol2$$libc.so + 1
    frame #5: 0xd1e56762 libobjc.so`objc_msgSend at 
objc_msgSend.x

Re: libs-corebase: NS/CFNumber bridging crashes with small objects

[David Chisnall]

Hi,

There are a few different representations of numbers in the small object 
representation.  On 32-bit platforms, there is only small int, which has 
the low bit set to 1 and stores a 32-bit integer in the remaining bits. 
On 64-bit platforms, the low 3 bits indicate the type, with the 
following values:


0: Object pointer
1: Small int (61-bit integer)
2: Small extended double (64-bit double, where the low bits of the 
mantissa are represented)
3: Small repeating double (64-bit double where the low bits are a short 
repeated pattern.

4: Unused
5: Tiny string (8 7-bit ASCI characters, plus length).
6: Unused
7: Unused

The numerical representations are defined in NSNumber:

https://github.com/gnustep/libs-base/blob/280b2cbe834007fa7945d783f3a538ecbaab52b5/Source/NSNumber.m#L374

https://github.com/gnustep/libs-base/blob/280b2cbe834007fa7945d783f3a538ecbaab52b5/Source/NSNumber.m#L436

The tiny string representation is defined in GSString.m:

https://github.com/gnustep/libs-base/blob/dd368559230c485b1234695673f21b2269caca09/Source/GSString.m#L778

Note that, with the 2.0 ABI, the GSTinyString representation is emitted 
by the compiler and so are considered part of the stable ABI.  The other 
number representations are not and are considered internal to the -base 
implementation and may change between versions.  I believe CoreBase is 
version locked to base, so that isn't a problem.


The code in CoreBase will need updating to check for the small number 
representation.  I'd be inclined to do this by moving some of the code 
from NSNumber.m and GSString.m into a private header that can be shared 
between base and CoreBase.


David

On 08/11/2019 11:18, Frederik Seiffert wrote:

Hi all,

I found that toll-free bridging of NSNumber to CFNumber crashes when 
using a "small object" (aka tagged pointer):


NSNumber *num = @(42);
NSLog(@"Type: %ld", (long)CFNumberGetType((__bridge CFNumberRef)num));

Crashes like this:

* thread #1: tid = 27602, 0x7fe328027ba0 
libgnustep-corebase.so.0`CFNumberGetType 
[inlined] CFNumberGetType_internal(num=0x0151) at 
CFNumber.c:204, name = 'test', stop reason = invalid address (fault 
address: 0x15b)
     frame #0: 0x7fe328027ba0 
libgnustep-corebase.so.0`CFNumberGetType 
[inlined] CFNumberGetType_internal(num=0x0151) at CFNumber.c:204

    201 CF_INLINE CFNumberType
    202 CFNumberGetType_internal(CFNumberRef num)
    203 {
-> 204   return (CFNumberType)num->_parent._flags.info ;
    205 }
    206
    207 CF_INLINE CFIndex


Note that 0x151 is a small int object for 42. Replacing 42 with e.g. 
INT_MAX (which doesn’t fit in a small object) makes the code work fine.


Could anyone with knowledge of the corebase / small objects internals 
take a look at this, or point me in the right direction how to fix this?


Related, there currently doesn’t seem to be a way to report bugs on 
corebase. Would it be possible to enable the bugtracker for the corebase 
GitHub project?


Thanks!
Frederik

Re: Savannah bug tracker disabled?

[David Chisnall]

On 04/11/2019 18:36, Jordan Schidlowsky wrote:
If people are really concerned about the bug/issue tracking being tied 
to github's platform, then just do in-repository tracking.  Pretty 
simple.  If you wanna take advantage of the GitHub platform for pull 
requests and issue tracking then do it.  If you are concerned about ANY 
part of the project being tied to a service/hosting provider then just 
add some process to track those things in-repository as well...   
  (include the wiki and the website as well?)


https://github.com/MichaelMure/git-bug  (GPL BTW)


I like the idea behind this.  It's sad that GitHub issue trackers are 
not git repos (GitHub wikis are, and it's a great feature).  This looks 
as if it imposes quite a high level of friction on the bug filing 
process though: how much effort is it for someone who is not already a 
GNUstep developer to file a bug with it, assuming that they already have 
a GitHub account?  From a cursory glance they need to:


1. Install git-bug.
2. Fork the repo.
3. Push a bug using `git bug`
4. Send a pull request.

This seems even more effort than creating an account on Savannah and 
vastly more than clicking on the 'new issue' button in the GitHub UI.


David

Re: Savannah bug tracker disabled?

[David Chisnall]

On 04/11/2019 10:26, Umberto Cerrato wrote:

Why don’t you self host your project in your own website? Something like a self 
hosted Savannah or similar (there are few around). Then you could: modify the 
UI to make it more GitHub-like and user friendly and leave some landing 
projects on GitHub, GitLab etc. that redirect to your e.g. subdomain with 
hosted files and bug tracker etc.


Because someone needs to do the work (and it costs money).  GNUstep 
barely has enough contributors to maintain the codebase, let alone 
diverting some of their effort to administering and maintaining a fork 
of Savannah.


And because that removes the *big* advantage of GitHub: network effects. 
 Since I moved the runtime to GitHub, I've had more drive-by issue 
reports and pull requests than I ever had when it was maintained on our 
infrastructure.  Most people already have a GitHub account, so filing an 
issue requires under a minute.  Once they've done it, they're invested 
enough to follow up with help debugging.  If they've cloned the code and 
have a small fix, it's easy for someone to send a PR.  The only way that 
self-hosted infrastructure to be close to this frictionless is if we use 
GitHub for authentication, and at that point why not just use GitHub?


David

Re: Savannah bug tracker disabled?

[David Chisnall]

On 04/11/2019 08:29, Fred Kiefer wrote:

Sorry, I have to disagree on this point. I was present in the Dublin meeting 
where we discussed the migration to GitHub and we explicitly decided to leave 
the bug tracking on savannah. There should be even some results from this 
meeting where these decisions should be documented. Ivan already gave the 
explanation for these decision in his reply. I still don’t see a technical need 
to revert the decision on hosting the bug tracker in savannah.
I also remember writing from time to time that GitHub is not our official bug 
system and pointing people over to savannah. Nobody disagreed with those mails.


I have an intense personal dislike of Savannah's bug tracker and would 
believe that having the issue tracker on GitHub makes it easier for 
occasional contributors to file bugs, but my recollection of this 
discussion is the same as Fred's: the majority view was to keep the bug 
tracker on Savannah.


David

Re: GWorkspace and new ABI

[David Chisnall]

On 04/11/2019 06:07, Svetlana Tkachenko wrote:

I think clang-8 is in backports.
Is that better than the external repository, or it does not matter?


I'm not sure what is considered best practice for Debian users, but the 
LLVM APT repo is officially maintained and I've read a lot of install 
guides that recommend using it for Ubuntu and Debian.  Our CI systems 
all pull clang from there.


David

Re: GWorkspace and new ABI

[David Chisnall]

On 15/10/2019 09:24, Johannes Brakensiek wrote:
Thank you for that hint. I searched through the GWorkspace makefiles for 
„protocol“ and „runtime_version“ but did not find any compiler setting 
concerning that. Maybe anyone having more insights into the make process 
could help here.


The flag is -fobjc-runtime=.  Can you check your build logs and see if 
it's the same value for all parts of gworkspace?


David

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

Re: GWorkspace and new ABI

[David Chisnall]

I'm not sure if it's the same problem, but I've had some issues in CI 
that I can't reproduce locally for gworkspace FreeBSD packages.  Either 
the core or the gworkspace extras appears not to be passing the correct 
runtime flags to the compiler, so I get an error when they are linked.


David

On 14/10/2019 10:01, Johannes Brakensiek wrote:

Hi Ivan,

thank you very much for your help! As I did not do any debugging of
GNUstep/ObjC before this really helps.

Am 11.10.19 um 16:06 schrieb Ivan Vučica:

1. Try using gdb to run GWorkspace (I'd guess gdb
/usr/GNUstep/Applications/GWorkspace.app/GWorkspace should do the
trick). Then when it inevitably calls abort(), you'll be dropped into
gdb's CLI. Type 'bt' to get the backtrace which will tell you which
library tried to access a bad protocol.

It still won't tell you which protocol is that, but it's a start.

2. If you haven't done things like that before and don't have
time/will to try it now, and if you previously had GNUstep on the
machine, I'd try to nuke /usr/GNUstep and possibly
~/GNUstep/Library/Libraries, then /etc/GNUstep.conf. Then reinstall
from scratch.


As I had installed 1.9 runtime to test if it works (it does) I tried
both. After reinstallation the error remains.

This is what gdb reports - not really helpful I think:

Starting program: /usr/GNUstep/Local/Tools/GWorkspace
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Unknown protocol version
Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: File not found.

I think the last error is raised after SIGABRT, so probably not the
cause of the issue?

So if anybody has a further hint I'll try again or otherwise just stick
to 1.9 for a while.

Johannes


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



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

Re: KVO Bindings

[David Chisnall]

Last time I checked:

KVO worked.  There is a cleaner way of implementing it on the GNUstep 
runtime (which WinObjC does, but GNUstep doesn't yet).


Some of the bindings work, but several of the NS*Controller classes are 
missing functionality.  Apple is quietly trying to forget Cocoa bindings 
were ever a thing (they're not supported by UIKit at all and no longer 
seem to be recommended by the AppKit tutorials), so I don't think anyone 
has been motivated to do it.  I don't think anything in implementing the 
missing parts is difficult, it's all just work.  Debugging bindings is 
basically impossible on macOS, I don't know whether debugging the 
implementation of bindings is easier...


David

On 14/08/2019 13:26, Johannes Brakensiek wrote:

Hello everyone,

just wanted to ask if anyone could give an update about this:

http://wiki.gnustep.org/index.php/KVO_Bindings_Project

Is there anybody who could implement this? What would be needed to let 
him/her do the work? ;-)


Thanks in advance
Johannes

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



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

Re: Categories not loaded from static library

[David Chisnall]

With the GCC ABI, each compilation unit contains a structure that 
contains a pointer to other structures that contain all classes, 
categories, selectors, and so on.  It also contains an initialiser that 
calls __objc_exec_class (in the runtime), passing this structure as an 
argument.


With the GNUstep v2 ABI, each compilation unit contains categories, 
selectors, and so on each in their own special section (allowing the 
linker to discard them if it finds duplicates, particularly useful for 
selectors).  It also a function that calls __objc_load with a struct 
initialised using the magic __start_{section} and __stop_{section} 
symbols that the linker will fill in.  Both this structure and this 
function have hidden visibility (so won't be exposed after linking) and 
a COMDAT (so duplicate versions linked together will be discarded).  As 
a result, after linking, we end up with a single .objc_load_v2 function 
that calls into the runtime.


When static linking on ELF platforms, by default, no symbols from a .a 
are pulled in unless they are referenced by something earlier on the 
command line.  A pure Objective-C .a file may not export any symbols, it 
just provides some data structures for registering things with the 
runtime.  As such, by default, the linker will ignore it.


David

On 07/08/2019 16:07, Frederik Seiffert wrote:

Perfect, thanks – that does the trick.

Frederik



Am 07.08.2019 um 12:29 schrieb David Chisnall :

Have you trued using --whole-archive?

David

On 07/08/2019 11:18, Frederik Seiffert wrote:

Hi all,
We have ObjC categories that are built into a static library, but these 
categories do not get linked into the final executable.
We tried the following linker options without any success:
-fuse-ld=gold -Wl,-force_load,
-fuse-ld=gold -ObjC
If we define a C function in the same category and reference that, then the 
categories are included.
Does anyone know if there are any linker flags we can use to fix this? This is 
using the Android toolchain.
Thanks,
Frederik
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep


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





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

Re: Categories not loaded from static library

[David Chisnall]

Have you trued using --whole-archive?

David

On 07/08/2019 11:18, Frederik Seiffert wrote:

Hi all,

We have ObjC categories that are built into a static library, but these 
categories do not get linked into the final executable.

We tried the following linker options without any success:

-fuse-ld=gold -Wl,-force_load,
-fuse-ld=gold -ObjC

If we define a C function in the same category and reference that, then the 
categories are included.

Does anyone know if there are any linker flags we can use to fix this? This is 
using the Android toolchain.

Thanks,
Frederik


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



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

Re: NSHashTable with weak objects crashing

[David Chisnall]

On 30/07/2019 09:17, David Chisnall wrote:
As I commented on the issue, I believe that one is caused by having too 
many hash collisions and the table being unable to resize.  I plan at 
some point to replace the hash table implementation, which should fix 
that issue.


If anyone has a test case for reproduceable segfaults, please file an 
issue on GitHub.


While replacing the hash table, I managed to turn it into a 
reproduceable fault on at least one machine.  The bug is quite subtle:


We have a map from objects to weak reference structures.
The weak reference structure points to the object.
When we delete the last weak reference, we delete the object from the map.
We delete the object from the map using the object as the key.
But by the time a weak reference is deallocated, its object pointer has 
been zeroed...
...so we always remove a random element from the map and leave a 
dangling pointer in the table.


David

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

Re: __has_attribute error compiling PictureFrame

[David Chisnall]

GCC doesn't support __has_attribute.  In one of the headers there should 
be something like this:


#ifndef __has_attribute
#define __has_attribute(x)
#endif

This header is apparently not being included in NSObjCRuntime.h - I 
guess no one has tried building PictureFrame with gcc and a recent 
GNUstep...


David

On 31/07/2019 09:35, mickb...@posteo.net wrote:

Hello.
I have just downloaded gap from github [1], and I am trying to compile 
them on a RHEL 7, with gcc 4.8.5 20150623 (Red Hat 4.8.5-36)


When I arrive to PictureFrame, compiling the source 
PreferencesController.m, I got the trange error:


In file included from /usr/local/include/Foundation/NSObject.h:30:0,
  from /usr/local/include/Foundation/FoundationErrors.h:29,
  from /usr/local/include/Foundation/Foundation.h:33,
  from /usr/local/include/Cocoa/Cocoa.h:33,
  from PreferencesController.h:5,
  from PreferencesController.m:6:
/usr/local/include/Foundation/NSObjCRuntime.h:187:20: error: missing 
binary operator before token "("

  #if __has_attribute(objc_designated_initializer)

"Strange" because it looks to be in a deep foundation header, and I have 
compiled quite a lot of program before, without any issue. Is it 
possible that header has never been included anywhere?


Any suggestion?

[1] https://github.com/gnustep/gap
--
Mick

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



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

Re: NSHashTable with weak objects crashing

[David Chisnall]

On 30/07/2019 09:12, Frederik Seiffert wrote:
Thanks for the suggestion Jordan. That’s certainly concerning to hear 
about the segfaults you’re experiencing with weak references. Is this on 
ARMv7 only and do you think it could be related to the WeakReferences 
test failing (https://github.com/gnustep/libobjc2/issues/107)?


As I commented on the issue, I believe that one is caused by having too 
many hash collisions and the table being unable to resize.  I plan at 
some point to replace the hash table implementation, which should fix 
that issue.


If anyone has a test case for reproduceable segfaults, please file an 
issue on GitHub.


David

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

Re: Crash in ___lldb_unnamed_symbol / cannot locate symbol "__start___objc_selectors" on Android

[David Chisnall]

Hi,


On 01/07/2019 15:38, Frederik Seiffert wrote:

Thanks for the explanation David.

I believe there was a bug in clang where I didn't add an empty symbol 
for compilation units that didn't contain any selectors.  If you then 
linked a program or a library that didn't contain any selectors then 
you'd see this error at link time.  This should now be fixed, but you 
can work around it by making sure that at least one of the 
Objective-C[++] files that you link includes at least one use of a 
selector.


After skimming CGObjCGNU.cpp in Clang I had the exact same thought, but 
I had only added ObjC code/selectors, not ObjC++. After adding both the 
app links fine. (Btw. I don’t think CGObjCGNU.cpp 
 currently 
emits empty symbols for selectors if none are found, only for protocols 
and classes).


It does:

https://github.com/llvm-mirror/clang/blob/44f7b2cea9a2ae54023740cf1a8c067d6b0e090a/lib/CodeGen/CGObjCGNU.cpp#L1603

Though I'm not sure if that has always been working.

However, now the Qt app also fails with the same backtrace as the one in 
Android Studio (issue #2 from my original email), but Qt’s debugger is 
showing me more info and think I have an idea about what’s going on now.


I think for some reason objc_send_initialize() is being called on 
classes before Objective C categories have been loaded. This causes 
various unrecognized selector calls because many internal functions in 
GNUstep are implemented in categories (e.g. NSObject (GNUstepBase)). In 
my specific stack trace, +[NSException raise:format:arguments:] was 
calling +[NSString stringWithFormat:arguments:] (implemented in the 
GNUstepBase NSString category), causing another exception ad infinitum. 
Replacing that NSString call in NSException with a non-category version 
causes it to crash in various other initializers calling category methods.


The way in which things are loaded is defined here (for the v2 ABI, the 
v1 ABI loads things one compilation unit at a time):


https://github.com/gnustep/libobjc2/blob/d16faeded958f94033092631b6988fb15654f995/loader.c#L189

For any binary, the runtime will:

1. Load all selectors and register them.
2. Load all protocols and register / unique them.
3. Load all references to protocols and update them to point to the 
canonical definition of the protocol.

4. Load all classes and resolve them.
5. Load all categories and resolve them.
5. Send +load to any classes that support them.
7. Register any class aliases.

The only ways that you can end up with a +initialize method being called 
before a category is resolved are:


- If it's in an __attribute__((constructor)) function or a C++ global 
initialiser that's called before Objective-C runtime init (except on 
Windows, where these are guaranteed to happen in the right order).

- If the code calling it is in a different library to the category.

I know on Apple platforms one must pass -all_load or -force_load to the 
linker to use categories in static libraries, but this doesn’t seem to 
be recognized by my linker (and doesn’t seem to be necessary for other 
ABIs). Is there anything else that might be going on here?


Apple's implementation is very different and is deeply coupled with 
their linker and loader.


Looking at your backtrace, it appears that you're seeing the bug in BFD 
ld.  With the -r option, it resolved the __start and __stop symbols 
early, then ended up with a .o file that caused everything declared in 
it to be dropped during final linkage.  This results in anything in the 
GNUstep Base Additions library being discarded.  Linking GNUstep Base 
(and -base Additions) with either lld or gold should fix this problem.


David

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

Re: Crash in ___lldb_unnamed_symbol / cannot locate symbol "__start___objc_selectors" on Android

[David Chisnall]

On 01/07/2019 13:14, Frederik Seiffert wrote:
1. When using Qt to build a simple test app with Objective C, I’m 
getting the following runtime error when launching the app:


java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol 
"__start___objc_selectors" referenced by 
"/data/app/org.qtproject.example.Qt_test-izIXM5mKlm3teJ8swIY-gQ==/lib/arm64/libQt-test.so"...


libQt-test here is the native library containing some basic C++ and 
Objective C code. This is linked against libobjc and libgnustep-base. 
What could be a reason for this symbol to be missing?


With the v2 ABI, all selectors are emitted as a symbol with hidden 
visibility and a name that is a mangling of their name and type encoding 
in the __objc_selectors section.  The linker can then see all selectors 
and deduplicate them (this is a big part of the binary size saving - 
which is usually 10-20% - relative to the GCC ABI, which forced the 
linker to keep a copy of every selector for every compilation unit that 
referenced it.  It also removes one or two instructions from the path to 
load each selector).


GNU-like linkers (lld, BFD ld, gold) provide magic __start_{section} and 
__stop_{section} symbol definitions for the start and end of any section 
with a name that is a valid C identifier.  The module initialisation 
structure for the v2 ABI contains pointers to __start___objc_selectors 
and __stop___objc_selectors, which the linker will fill in with the 
start and end of the __objc_selectors section.  This is then used by the 
runtime to iterate over all of the selectors in a library.


I believe there was a bug in clang where I didn't add an empty symbol 
for compilation units that didn't contain any selectors.  If you then 
linked a program or a library that didn't contain any selectors then 
you'd see this error at link time.  This should now be fixed, but you 
can work around it by making sure that at least one of the 
Objective-C[++] files that you link includes at least one use of a selector.


David

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

Re: Emacs.app

[David Chisnall]

GNUstep in general is very slow at scrolling.  There are various 
optimisations that made a huge performance improvement on '90s hardware 
and make things a lot slower now.


GNUstep's text rendering also leaves something to be desired.  It uses 
the Cairo 'toy' interface, which is intended for simple demos, and not 
the interface that connects to things like Harfbuzz.  I would love to 
see someone spend some time on this...


David

On 21/06/2019 11:15, Bertrand Dekoninck wrote:
After testing it  a little, Emacs.app is painful slow at scrolling text, 
much slower than the gtk version.


Bertrand


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



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

Re: Porting to 64Bit -descriptionForInstanceMethod:

[David Chisnall]

On 18/06/2019 16:20, Andreas Höschler wrote:

I wonder why I haven’t found that. Thanks!

          struct objc_method_description methodDesc = 
protocol_getMethodDescription(_protocol, aSelector, YES, YES);

          types = methodDesc.types;

  This works great as long as I build with -m32. But as soon as I switch to


This function is in the Apple headers, so the only explanation I can 
think of is that you're failing to #include  in the 
64-bit case.  You may be implicitly including it via some other header 
that has a conditional include based on pointer size?


David

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

Re: Porting to 64Bit -descriptionForInstanceMethod:

[David Chisnall]

On 18 Jun 2019, at 13:47, Andreas Höschler  wrote:
> 
> Hi David,
> 
>> - descriptionForInstanceMethod: is gone.  Don't use it, use the runtime 
>> functions instead.
> 
> Thanks for the hint. 
> 
> Where would I find a list (the declaration) of these runtime functions on 
> MacOSX and GNUstep? Are they even identically named? I guess no!?
> 

Here is the top hit for a DDG search for ‘Objective-C Runtime’:

https://developer.apple.com/documentation/objectivec/objective-c_runtime?language=objc

It provides you with the Objective-C Runtime API Reference.  The GNUstep 
runtime also implements this interface and is source compatible (it also 
implements some non-portable functions, which I would suggest that you avoid).  
You can find these all in objc/runtime.h.  

The method that you are probably looking for is protocol_getMethodDescription.

David


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

Re: Porting to 64Bit -descriptionForInstanceMethod:

[David Chisnall]

Wow, this is really old code!

On 18/06/2019 12:59, Andreas Höschler wrote:
*SRProxy.m:419:29: **warning: **instance method 
'-descriptionForInstanceMethod:' not found (return type defaults to 
'id') [-Wobjc-method-access]*
          types = [_protocol 
descriptionForInstanceMethod:aSelector]->types;

*                            ^~~~*
*/usr/include/objc/Protocol.h:45:12: note: *receiver is instance of 
class declared here

@interface Protocol : NSObject
*           ^*
*SRProxy.m:419:70: **error: **no member named 'types' in 'struct 
objc_object'*

*
*


With the 'Modern' Objective-C ABI (circa 2006) on Apple platforms, the 
only option on 64-bit and the default for a very long time on 32-bit, 
Protocol no longer has any methods exposed on it.  This means:


- descriptionForInstanceMethod: is gone.  Don't use it, use the runtime 
functions instead.  There is no point paying the overhead of an 
Objective-C message send for a function where all of the types are known 
at compile time.


- The compiler assumes that the nonexistent method 
-descriptionForInstanceMethod: returns id, which is a typedef for struct 
objc_object, which has no fields other than isa (probably not even isa, 
because direct access to isa is also deprecated).


David

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

Re: Compilation error in EOModeler.m

[David Chisnall]

When you build in Poudriere, it will install all of the dependencies 
that you specified as build dependencies in the jail, then build.  If 
you missed a build dependency, it will then be caught and so it won't 
bite anyone else (or the package builders).  It sounds as if you missed 
a depencency on renaissance.


I thought there was a package for Renaissance, but I can't find it, so 
there probably isn't.  You'll need to start by making sure that all of 
the depencencies are packaged before you package gsweb.  It looks as if 
you installed Renaissance yourself (sorry, I should have noticed that 
from the fact that it's installed in the Local domain - packages all 
install themselves in the System domain), so the first step is to create 
a port for Renaissance.  That should be fairly simple, because I don't 
think it needs anything complicated for the build.


David

On 17/06/2019 22:04, Edwin Ancaer wrote:

Hello,

what I wanted  to achieve is building binary packages for gsweb and gdl2 
with poudriere, and then install  these packages with pkg install.


I  already have  had problems with the versions of load libraries when 
directly compiling ports for FreeBSD, and wanted to avoid this mess.

Apparently, avoiding one mess got me into another.

For me problem is in the fact that poudriere is using  a jail to build 
the packages: when in the jail, the file Renaissance/Renaissaince.h is

not to be  found in usr/local/GNUstep/Local/Library/Headers.
I guess that, as long as I cannot build Renaissance with poudriere, I'm 
stuck.


The road is long

Op vr 14 jun. 2019 om 13:38 schreef Riccardo Mottola 
mailto:riccardo.mott...@libero.it>>:


Hi,

Edwin Ancaer wrote:
 >        -o obj/EOModeler.obj/EOMInspector.m.o
 > *EOMInspector.m:42:10: fatal error: 'Renaissance/Renaissance.h' file
 > not found*
 > #include 
 >          ^~~
 > 1 error generated.
 >
 > However, I find the file Renaissance.h in  the directory
 >
root@ottopedi:/usr/local/GNUstep/Local/Library/Headers/Renaissance on
 > my comupter:
 >
 > root@ottopedi:/usr/local/GNUstep/Local/Library/Headers/Renaissance #
 > ls -al
 > total 352
 > drwxr-xr-x  2 root  wheel   2560 Jun  4 23:22 .
 > drwxr-xr-x  7 root  wheel    512 Jun  8 00:24 ..
 > -rwxr-xr-x  1 root  wheel   2579 Jun  4 23:22 GNUstep.h
 > -rwxr-xr-x  1 root  wheel   4323 Jun  4 23:22 GSAutoLayoutBox.h
 > ...
 > ...
 > -rwxr-xr-x  1 root  wheel   1833 Jun  4 23:22 Renaissance.h
 >
 > Anybody an idea why  this is error occruing?

No... include paths look correct to me. but I propose two things to
check
1) no other versions of Renaissance on your disk? (shouldn't matter,
because you have Local includes before in your compile line)
2) what happens if you replace #include with #import ? sounds strange,
but sometimes it worked for me

Riccardo


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



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

Re: FreeBSD / libobj2 issue after update - all apps crash

[David Chisnall]

On 7 Jun 2019, at 18:27, Riccardo Mottola  wrote:
> 
> Hi,
> 
> 
> David Chisnall wrote:
>> It looks as if this protocol comes from NSDistributedNotificationCenter and 
>> is created with an @protocol directive.  With the gnustep-1.0 ABI, that is 
>> attached to the __ObjC_Protocol_Holder_Ugly_Hack class and upgraded by the 
>> runtime.  It looks as if you've compiled with the gcc ABI, so none of that 
>> works.
>> 
>> You can't use the GCC ABI with the 2.x runtime, you have to use the gnustep 
>> ABI.  That will work in pretty much any version of clang.
> 
> Given your explanation, I indeed I compiled with gnu-gnu-gnu, since I just 
> didn't gave any options and that is what gnustep-make always selected, now 
> when I upgraded libobjc2 packages from pkg, it broke. From what you tell me 
> it is not a "bug" that can be fixed, but a hack that no longer works :)
> 
> I reconfigured with explicit --with-library-combo=ng-gnu-gnu and it works 
> again.
> 
> So, essentially, one either knows that it has to be configured that way or 
> our configure should be "smart" and it should enable ng-gnu-gnu from a 
> certain libobjc release onwards?

I think it is a bug in -make.  If it detects clang as your Objective-C compiler 
then, at the very least, it should add -fobjc-runtime=gnustep-1.0 (ideally 
something like 1.7 or 1.6, which is probably the oldest that you’re practically 
likely to find).  

David


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

Re: FreeBSD / libobj2 issue after update - all apps crash

[David Chisnall]

On 05/06/2019 15:30, Riccardo Mottola wrote:

Hi David!

David Chisnall wrote:


Can you do a backtrace of where the crash is?  What is the protocol 
that it's inspecting while crashing?


of course... here it is:


Thanks.



Program received signal SIGABRT, Aborted.
0x0008028ca47a in thr_kill () from /lib/libc.so.7
(gdb) bt
#0  0x0008028ca47a in thr_kill () from /lib/libc.so.7
#1  0x0008028ca444 in raise () from /lib/libc.so.7
#2  0x0008028ca3b9 in abort () from /lib/libc.so.7
#3  0x0008029498e1 in __assert () from /lib/libc.so.7
#4  0x00080218fe18 in protocol_getMethodDescription () from 
/usr/local/lib/libobjc.so.4.6
#5  0x00080218fc9b in protocol_getMethodDescription () from 
/usr/local/lib/libobjc.so.4.6
#6  0x000801c9d532 in GSProtocolGetMethodDescriptionRecursive 
(aProtocol=0x8020a93d0, aSel=0x8020aa010,

     isRequired=1 '\001', isInstance=1 '\001') at GSObjCRuntime.m:827
#7  0x000801b80bd4 in -[NSDistantObject methodSignatureForSelector:] 
(self=0x80a98cf98,
     _cmd=, aSelector=0x8020aa010) at 
NSDistantObject.m:727
#8  0x000801c9b302 in GSFFIInvocationCallback (cif=0x80a9fff00, 
retp=0x7fffe420, args=0x7fffe2b0,

     user=0x80a86e4c8) at GSFFIInvocation.m:538
#9  0x0008057c62ad in ffi_closure_unix64_inner () from 
/usr/local/lib/libffi.so.6
#10 0x0008057c69d0 in ffi_closure_unix64 () from 
/usr/local/lib/libffi.so.6
#11 0x000801b82cb0 in -[NSDistributedNotificationCenter 
addObserver:selector:name:object:suspensionBehavior:] (
     self=, _cmd=, 
anObserver=0x80a740548, aSelector=,
     notificationName=0x0, anObject=, 
suspensionBehavior=2)

     at NSDistributedNotificationCenter.m:341
#12 0x000801b82999 in -[NSDistributedNotificationCenter 
addObserver:selector:name:object:] (self=0x80a841688,
     _cmd=, anObserver=, 
aSelector=,
     notificationName=, anObject=out>) at NSDistributedNotificationCenter.m:266
#13 0x000801187ca9 in -[_GSWorkspaceCenter init] (self=0x80a740548, 
_cmd=)

     at NSWorkspace.m:352
#14 0x000801189616 in -[NSWorkspace init] (self=0x80a7f8b98, 
_cmd=) at NSWorkspace.m:755
#15 0x000801189433 in +[NSWorkspace sharedWorkspace] (self=optimized out>, _cmd=)

     at NSWorkspace.m:703
#16 0x0008010076e2 in -[NSApplication finishLaunching] 
(self=0x8088174c8, _cmd=)

     at NSApplication.m:1104
#17 0x000801008e85 in -[NSApplication run] (self=0x8088174c8, 
_cmd=) at NSApplication.m:1561
#18 0x000800fecd24 in NSApplicationMain (argc=, 
argv=) at Functions.m:91

#19 0x00404985 in _start ()
#20 0x00080062f000 in ?? ()
#21 0x in ?? ()

it definitely has to do with distributed notifications, this is the 
protocol and its selector that are being looked up in frame #6


(gdb) po NSStringFromProtocol(aProtocol)
GDNCProtocol
(gdb) po NSStringFromSelector(aSel)
registerClient:

does this help you?


It looks as if this protocol comes from NSDistributedNotificationCenter 
and is created with an @protocol directive.  With the gnustep-1.0 ABI, 
that is attached to the __ObjC_Protocol_Holder_Ugly_Hack class and 
upgraded by the runtime.  It looks as if you've compiled with the gcc 
ABI, so none of that works.


You can't use the GCC ABI with the 2.x runtime, you have to use the 
gnustep ABI.  That will work in pretty much any version of clang.


David

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

Re: FreeBSD / libobj2 issue after update - all apps crash

[David Chisnall]

On 05/06/2019 05:30, Riccardo Mottola wrote:

Hi,


David Chisnall wrote:

On 04/06/2019 09:46, Riccardo Mottola wrote:

Hi David,

David Chisnall wrote:
Thanks for the report.  Please can you file an issue on GitHub? This 
is a quite surprising error - it implies that either clang has a bug 
or that something is trying to manually create or modify protocols 
without calling through the runtime.  This might happen if you have 
a version of GNUstep compiled against the gcc runtime and using 
ObjectiveC2.framework instead of the runtime's public APIs, but that 
shouldn't be the case with the packaged versions.


clang and libobjc2 are packaged, however gnustep installation is 
compiled by my by current sources. I did not do anything special, I 
configured make with:


$ ./configure --prefix=/ --with-layout=gnustep 
CFLAGS=-I/usr/local/include


Are you using -make from packages, which will be configured to use the 
new ABI?



no, I am using everyghing from git HEAD of our repositories, including 
latest gnustep make.
Do you pass some special configuration parameters when packaging? I can 
attempt that.


All of the configuration parameters that I use for the packages are in 
the port Makefile(s).  I do build everything with the ng library combo 
though.








Okay, this is not one that will be used by -make from packages, 
because it doesn't support the 2.0 ABI.  Please use the clang from the 
llvm7 or lllv8 package, or from the base system in 12.  It looks as if 
you're using the old (GCC) ABI, which may mean that you've linked in 
the ObjectiveC2 framework and are explicitly constructing internal 
runtime data structures from an old version of the runtime.  Please 
can you check where the invalid protocol is coming from?  It may also 
be something that we're failing to correctly upgrade when using the 
legacy ABI.


Ok, so it is an older compiler, but should not the runtime support it? 
there are no two libobjc2 packages, or is libobjc2 no longer compatible 
with the GCC runtime?


How can I check for the protocol? It is coming "from inside GNUstep" 
since I just installed core packages and then am running Ink, so there 
is no custom code of mine.

Maybe we just have some issue in gnustep which we didn't discover.


Can you do a backtrace of where the crash is?  What is the protocol that 
it's inspecting while crashing?


When you say "upgrade" are you referring to FreeBSD package upgrade or 
GNUstep ?


The 2.x runtime series uses a new set of internal structures.  It 
transparently upgrades all old runtime structures to the new layout 
(there may be places where this fails, if so they are bugs - please 
report them with test cases in the GitHub issue tracker).  The runtime 
has not for a long time supported external code generating these 
structures, as the ObjectiveC2 framework does when used with an old 
runtime, and provides public APIs for creating and modifying them so 
that they can be opaque to user code.  With the 1.x series, this all 
probably mostly worked, because things were upgraded lazily where 
necessary, not on load.  That complicated the runtime internals a lot 
and the 2.x series is a lot cleaner, but will definitely break if used 
with code that expects to poke runtime data structures and expects them 
to have the GCC runtime layouts.


Indeed, on another computer where I am running FreeBSD 12 instead, 
everything worked out of the box.


Hopefully that's picking up the 8.x compiler and everything is the new ABI.

David

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

Re: FreeBSD / libobj2 issue after update - all apps crash

[David Chisnall]

On 04/06/2019 09:46, Riccardo Mottola wrote:

Hi David,

David Chisnall wrote:
Thanks for the report.  Please can you file an issue on GitHub?  This 
is a quite surprising error - it implies that either clang has a bug 
or that something is trying to manually create or modify protocols 
without calling through the runtime.  This might happen if you have a 
version of GNUstep compiled against the gcc runtime and using 
ObjectiveC2.framework instead of the runtime's public APIs, but that 
shouldn't be the case with the packaged versions.


clang and libobjc2 are packaged, however gnustep installation is 
compiled by my by current sources. I did not do anything special, I 
configured make with:


$ ./configure --prefix=/ --with-layout=gnustep CFLAGS=-I/usr/local/include


Are you using -make from packages, which will be configured to use the 
new ABI?



according to configure log, this is the compiler detected:

configure:4393: checking for C compiler version
configure:4402: cc --version >&5
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on 
LLVM 6.0.0)

Target: x86_64-unknown-freebsd11.2
Thread model: posix


Okay, this is not one that will be used by -make from packages, because 
it doesn't support the 2.0 ABI.  Please use the clang from the llvm7 or 
lllv8 package, or from the base system in 12.  It looks as if you're 
using the old (GCC) ABI, which may mean that you've linked in the 
ObjectiveC2 framework and are explicitly constructing internal runtime 
data structures from an old version of the runtime.  Please can you 
check where the invalid protocol is coming from?  It may also be 
something that we're failing to correctly upgrade when using the legacy ABI.


David

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

Re: FreeBSD / libobj2 issue after update - all apps crash

[David Chisnall]

On 04/06/2019 04:14, Riccardo Mottola wrote:

Hi,

I just upgraded all binary packages on FreeBSD  using clang and packaged
libobjc2:

11.2-RELEASE-p10 FreeBSD 11.2-RELEASE-p10 #0: Mon May 13 21:20:50 UTC 2019

installed libobjc2 is:
libobjc2-2.0_1 Replacement Objective-C runtime
supporting modern Objective-C features


I removed and reocmpiled all gnustep core, however all programs crash.
Actually, GUI programs appear to crash. I can launch plarse, plmerge...


The error I get is:


Assertion failed: (l->size >= sizeof(struct
objc_protocol_method_description)), function protocol_method_at_index,
file /wrkdirs/usr/ports/lang/libobjc2/work/libobjc2-0db500a/protocol.h,
line 85.
Abort (core dumped)

any idea if the issue is a borken package in FreeBSD with clang or
libobjc2.. or the issue is in GNUstep?

Riccardo

PS: I will run tests and see what happens


Thanks for the report.  Please can you file an issue on GitHub?  This is a 
quite surprising error - it implies that either clang has a bug or that 
something is trying to manually create or modify protocols without calling 
through the runtime.  This might happen if you have a version of GNUstep 
compiled against the gcc runtime and using ObjectiveC2.framework instead of the 
runtime's public APIs, but that shouldn't be the case with the packaged 
versions.

I have seen something odd with the FreeBSD package builder machines though.  
When I tried installing gnustep from them, I saw -gui compiled with the 1.8 
ABI, but everything else compiled with the 2.0 ABI, which caused everything 
other than plmerge to fail to start with a linker error.  I couldn't reproduce 
it building locally though.

David

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

Re: FreeBSD ports for GDL2 and GSWeb

[David Chisnall]

Hi,

That's quite an exciting error.  It looks as if the build is fine, the 
install is fine, the checks that the plist match the things in the stage 
directory are all fine, and then something is crashing while building 
the package.  I've never seen this before.  Can you add a -i flag to 
your poudriere testport command?  That should drop you in the jail 
environment - try running make package and see if you get any more 
information about what crashes.


David

On 29/05/2019 21:58, Edwin Ancaer wrote:

Hello guys,

one last request before I return to gardening: it seems that the above 
error only occurs with the poudriere port that I try to create. I can 
build all other gnustep ports without problems.


I attached the Makefile, pkg-descr, pkg-plist and distinfo for the port. 
If someone could have a look if the error occurs at their side also, it 
might just be a local problem.


Thans for the help you all provided,



Op wo 29 mei 2019 om 10:22 schreef Edwin Ancaer <mailto:eanc...@gmail.com>>:


Reading Davids answer, I realize I did not explain well what was the
problem. The error occurred during the at the execution of the
poudriere testport command, giving a following logfile:

===
=>> Recording filesystem state for prebuild... done
===  >

===>   renaissanc- depends on executable: gmake - found
===>   renaissanc- depends on file: /usr/local/bin/ld.gold - found
===>   renaissanc- depends on shared library: libgnustep-base.so -
found (/usr/local/GNUstep/System/Library/Libraries/libgnustep-base.so)
===>   renaissanc- depends on shared library: libgnustep-gui.so -
found (/usr/local/GNUstep/System/Library/Libraries/libgnustep-gui.so)
===>  Configuring for renaissanc-
===
===  >

===>  Building for renaissanc-
gmake[1]: Entering directory
'/wrkdirs/usr/ports/devel/renaissance/work/libs-renaissance-13bd630'
GNUmakefile:29:
GNUmakefile:30: Unable to obtain GNUSTEP_MAKEFILES setting from
gnustep-config!
GNUmakefile:31: Perhaps gnustep-make is not properly installed,
GNUmakefile:32: so gnustep-config is not in your PATH.
GNUmakefile:33:
GNUmakefile:34: Your PATH is currently

/wrkdirs/usr/ports/devel/renaissance/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/nonexistent/bin
GNUmakefile:35:
GNUmakefile:40: *** You need to set GNUSTEP_MAKEFILES before
compiling!.  Stop.
gmake[1]: Leaving directory
'/wrkdirs/usr/ports/devel/renaissance/work/libs-renaissance-13bd630'
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the
failure to
the maintainer.
*** Error code 1

That was solved by adding build to the line: USE_GNUSTEP=   base gui
*build.*

Now the next problem has occurred:

> Running Q/A tests (stage-qa)
Warning: 'GNUstep/System/Library/Libraries/libRenaissance.so.0.9.0'
is not stripped consider trying INSTALL_TARGET=install-strip or
using ${STRIP_CMD}
Warning:

'GNUstep/System/Applications/GSMarkupLocalizableStrings.app/GSMarkupLocalizableStrings'
is not stripped consider trying INSTALL_TARGET=install-strip or
using ${STRIP_CMD}
Warning:
'GNUstep/System/Applications/GSMarkupBrowser.app/GSMarkupBrowser' is
not stripped consider trying INSTALL_TARGET=install-strip or using
${STRIP_CMD}
> Checking for pkg-plist issues (check-plist)
===> Parsing plist
===> Checking for items in STAGEDIR missing from pkg-plist
===> Checking for items in pkg-plist which are not in STAGEDIR
===> No pkg-plist issues found (check-plist)
=>> Checking for staging violations... done
===  >

===>  Building package for renaissance-
Child process pid=66023 terminated abnormally: Bus error
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/renaissance
build of devel/renaissance | renaissance- ended at Wed May 29
09:39:04 CEST 2019
build time: 00:01:55
!!! build failure encountered !!!
[00:02:04] Error: Build failed in phase: package
[00:02:04] Cleaning up
[00:02:04] Unmounting file systems



If you're still not bored to death by this endless series of
problems, any clues on how to solve this are appreciated.


Kind regards,


Op ma 27 mei 2019 om 19:06 schreef David Chisnall
mailto:gnus...@theravensnest.org>>:

On 27 May 2019, at 12:07, Edwin Ancaer mailto:eanc...@gmail.com>> wrote:
 >
  

Re: FreeBSD ports for GDL2 and GSWeb

[David Chisnall]

On 27 May 2019, at 12:07, Edwin Ancaer  wrote:
> 
> 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, the GNUStep 
> environment is not defined.
> 

You have to run poudriere as root, but then it will source the relevant gnustep 
files in the jail that it uses for building if the port is marked as USES = 
gnustep.  You should then end up with a package repo somewhere inside 
/usr/local/poudriere.  The best thing to do is create a local config file in 
/usr/local/etc/pkg/repos/ pointing to that and install the package from there 
for testing.  You don’t have to do anything inside the poudriere-created jail 
other than check that things build, you can test on any system you like 
(including the host).

David


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

Re: FreeBSD ports for GDL2 and GSWeb

[David Chisnall]

On 23 May 2019, at 23:20, Edwin Ancaer  wrote:
> 
> Is this the linker problem David mentioned earlier, or is this something that 
> can be solved by changing the code? 
> 

Can you try setting LLD_UNSAFE (I think that’s the flag) in the port Makefile?  
There are a few Objective-C things that appear to be triggering bugs in lld, if 
you set this then they will link with gold instead.

David


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

Re: libdispatch types in a property declaration

[David Chisnall]

Hi,

I'd not looked at the Swift corelibs version of libdispatch.  Looking at 
its headers, there are some feature test macros that check if you have 
Objective-C support, which seem to only enable Objective-C interop on 
Apple platforms:


https://github.com/apple/swift-corelibs-libdispatch/blob/631821c2bfcf296995a8424f148a9365470c2210/os/object.h#L58

You could add some checks to there to enable them on non-Mac platforms 
and see what happens when you build them...


David

On 23/05/2019 15:13, Simon Gornall wrote:
[I posted this in gnu.gnustep.discuss, but then realised that the last 
post before mine was back in January. Posting here where there’s more 
traffic :)]


Hi all,

So I've just installed Debian (Sid) and got GNUstep installed with 
runtime 2.0 / clang-8 etc. by following 
http://wiki.gnustep.org/index.php/Building_GNUstep_under_Debian_FreeBSD#libdispatch 
 



As far as I can tell, it all worked fine. I got a few tests fail where 
the above link didn't mention, but they seemed to be to do with Objc++, 
and I'm not planning on using that. I put that down to running sid.


I have a project that compiles on my Mac, and I'm trying to port it over 
- part of it is a web-socket service, which uses libdispatch and blocks 
to process the data streams. On the Mac, there aren't any warnings. On 
the linux box, I get:


nano:~/src/b-leet.com/bleetd > make messages=yes
This is gnustep-make 2.7.0. Type 'make print-gnustep-make-help' for help.
Running in gnustep-make version 2 strict mode.
Making all for tool bleetd...
/usr/bin/clang-8 bleetd/classes/server/Server.m -c \
       -MMD -MP -Ibleetd/classes/server -Ibleetd/classes/websockets 
-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 -Wall -DGSWARN -DGSDIAGNOSE 
-Wno-import -g -O2 -fblocks -fobjc-runtime=gnustep-2.0 -fblocks 
-fconstant-string-class=NSConstantString -I. 
-I/home/simon/GNUstep/Library/Headers -I/usr/local/include \

        -o obj/bleetd.obj/bleetd/classes/server/Server.m.o
In file included from bleetd/classes/server/Server.m:10:
In file included from bleetd/classes/websockets/PSWebSocketServer.h:16:
bleetd/classes/websockets/PSWebSocket.h:69:1: error: property with 
'retain (or strong)' attribute must be of object type

@property (nonatomic, strong) dispatch_queue_t delegateQueue;
^
In file included from bleetd/classes/server/Server.m:10:
bleetd/classes/websockets/PSWebSocketServer.h:47:1: error: property with 
'retain (or strong)' attribute must be of object type

@property (nonatomic, strong) dispatch_queue_t delegateQueue;
^
2 errors generated.


The GNUmakefile I put together looks like:

---8<--8<--8<---  Cut Here  ---8<--8<--8<---

include $(GNUSTEP_MAKEFILES)/common.make

TOOL_NAME = bleetd
bleetd_CPPFLAGS = -Ibleetd/classes/server \
     -Ibleetd/classes/websockets
bleetd_OBJC_FILES = $(shell find bleetd -name '*.m')

include $(GNUSTEP_MAKEFILES)/tool.make

---8<--8<--8<---  Cut Here  ---8<--8<--8<---

So the question: Would I normally expect a 'dispatch_queue_t' to still 
be something that can be put into a property in GNUstep ? I'm really 
only familiar with the Mac side of things - I’m new to GNUstep, and in 
Mac-land they're reference-counted objects. I guess I’m asking: is this 
a bug, did I do something wrong during install, or is it expected 
behaviour ?


Cheers
    Simon


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



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

Re: FreeBSD ports for GDL2 and GSWeb

[David Chisnall]

That looks fine.  Don't forget to re-run make makesum, because now the 
size and hash of the upstream source have changed.


David

On 22/05/2019 17:42, Edwin Ancaer wrote:

Hello David,

thanks again for helping.  I changed GH_TAGNAME from gdl2-0_12_0 to 
d5f0d94, what I thought were the first 7 characters from the commit 
hash, but apparently I'm wrong, because I got an error:


root@ottopedi:/usr/local/poudriere/ports/head/databases/gdl2 # make makesum
=> gnustep-libs-gdl2--d5f0d94_GH0.tar.gz doesn't seem to exist in 
/usr/local/poudriere/ports/head/distfiles/.
=> Attempting to fetch 
https://codeload.github.com/gnustep/libs-gdl2/tar.gz/d5f0d94?dummy=/gnustep-libs-gdl2--d5f0d94_GH0.tar.gz
fetch: 
https://codeload.github.com/gnustep/libs-gdl2/tar.gz/d5f0d94?dummy=/gnustep-libs-gdl2--d5f0d94_GH0.tar.gz: 
size of remote file is not known
gnustep-libs-gdl2--d5f0d94_GH0.tar.gz                 1811 kB  527 kBps 
    03s


Problem is that I do not know how to consult the files that are in 
codeload.github.com <http://codeload.github.com>, so I cannot look there 
how to fill the parameters in the Makefile. There seems to be an api, so 
I'Ve got some research ahead, apparently.


Thanks,






Op wo 22 mei 2019 om 10:37 schreef David Chisnall 
mailto:thera...@theravensnest.org>>:


On 21/05/2019 20:32, Fred Kiefer wrote:
 > That would be 2009, ten years ago, yes this could fit to the
errors you are getting. In part this is our problem as no release
was done in the time in between. Still could you please switch to
the master branch  and only report issues for that branch?

If you update the GH_TAGNAME to the hash of the commit (truncated to 7
characters) at the tip of the master branch, the port will build that
instead.

David

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


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



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

Re: FreeBSD ports for GDL2 and GSWeb

[David Chisnall]

On 21/05/2019 20:32, Fred Kiefer wrote:

That would be 2009, ten years ago, yes this could fit to the errors you are 
getting. In part this is our problem as no release was done in the time in 
between. Still could you please switch to the master branch  and only report 
issues for that branch?


If you update the GH_TAGNAME to the hash of the commit (truncated to 7 
characters) at the tip of the master branch, the port will build that 
instead.


David

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

Re: FreeBSD ports for GDL2 and GSWeb

[David Chisnall]

The best thing to do is just send a PR on GitHub.  Once it's merged, the 
port can point to the git hash as a pre-release, even if no one gets 
around to pushing out a release.


David

On 21/05/2019 14:25, Edwin Ancaer wrote:

Hi,

I don't know the right procedures to handle this: obviously, someone 
will have to make the changes David propose in gnustep/libs-gdl2, and 
there probably will be more to come. Is there a maintainer for this 
repository I should contact? As the proposed changes are rather easy, I 
don't mind doing them myself, but then I would like some explanation on 
the  best way to do this. practcally.  Also, a warning, I'm just 'Joe 
the programmer', I have no computer science degree nor exceptional 
programming skills, so I might get stuck when things become more complex.


Kind regards,




Op di 21 mei 2019 om 10:13 schreef David Chisnall 
mailto:gnus...@theravensnest.org>>:


Ooops, hit sent too soon:

On 21/05/2019 08:26, Edwin Ancaer wrote:
 > In file included from ../EOControl/EOQualifier.h:36:
 > ../EOControl/EOKeyValueArchiver.h:84:3: error: unknown type name
 > 'NSMutableArray'
 >    NSMutableArray *_allUnarchivedObjects;
 >    ^

It looks as if EOKeyBalueArchiver.h is missing a #import


 > ../EOControl/EOQualifier.h:239:12: error: cannot define category for
 > undefined class 'NSArray'
 > @interface NSArray (EOQualifierExtras)
 >             ^
 >
/usr/local/GNUstep/System/Library/Headers/GNUstepBase/GSObjCRuntime.h:92:8:

 > note: forward declaration of class here
 > @class  NSArray;
 >          ^
 > In file included from EOKeyValueQualifier.m:57:
 > ../EOControl/EOQualifier.h:239:12: error: cannot define category for
 > undefined class 'NSArray'
 > @interface NSArray (EOQualifierExtras)
 >             ^
 >
/usr/local/GNUstep/System/Library/Headers/GNUstepBase/GSObjCRuntime.h:92:8:

 > note: forward declaration of class here
 > @class  NSArray;
 >          ^

And so is EOQualifier.h.  Old GNUstep code tends not to import all of
Foundation.h, which also means that it will be slower to build on a
modern compiler / build system that uses precompiled headers.  Just
sticking #import  at the top will fix most of
these issues.

 > EOKeyComparisonQualifier.m:190:7: warning: 'sel_eq' is deprecated
 > [-Wdeprecated-declarations]
 >    if (sel_eq(_selector, EOQualifierOperatorEqual) == YES)

This should be sel_isEqual.  It looks as if this code hasn't been
updated for at least 10 years, so getting it to build at all may be an
interesting experience.

David



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

Re: FreeBSD ports for GDL2 and GSWeb

[David Chisnall]

Ooops, hit sent too soon:

On 21/05/2019 08:26, Edwin Ancaer wrote:

In file included from ../EOControl/EOQualifier.h:36:
../EOControl/EOKeyValueArchiver.h:84:3: error: unknown type name 
'NSMutableArray'

   NSMutableArray *_allUnarchivedObjects;
   ^


It looks as if EOKeyBalueArchiver.h is missing a #import 



../EOControl/EOQualifier.h:239:12: error: cannot define category for 
undefined class 'NSArray'

@interface NSArray (EOQualifierExtras)
            ^
/usr/local/GNUstep/System/Library/Headers/GNUstepBase/GSObjCRuntime.h:92:8: 
note: forward declaration of class here

@class  NSArray;
         ^
In file included from EOKeyValueQualifier.m:57:
../EOControl/EOQualifier.h:239:12: error: cannot define category for 
undefined class 'NSArray'

@interface NSArray (EOQualifierExtras)
            ^
/usr/local/GNUstep/System/Library/Headers/GNUstepBase/GSObjCRuntime.h:92:8: 
note: forward declaration of class here

@class  NSArray;
         ^


And so is EOQualifier.h.  Old GNUstep code tends not to import all of 
Foundation.h, which also means that it will be slower to build on a 
modern compiler / build system that uses precompiled headers.  Just 
sticking #import  at the top will fix most of 
these issues.


EOKeyComparisonQualifier.m:190:7: warning: 'sel_eq' is deprecated 
[-Wdeprecated-declarations]

   if (sel_eq(_selector, EOQualifierOperatorEqual) == YES)


This should be sel_isEqual.  It looks as if this code hasn't been 
updated for at least 10 years, so getting it to build at all may be an 
interesting experience.


David

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

Re: FreeBSD ports for GDL2 and GSWeb

[David Chisnall]

Hi,

I'd strongly recommend that you only ever build ports using Poudriere. 
The makeplist target doesn't work reliably, but if you build with 
poudriere testport then it will tell you all of the things that are 
wrong in the plist and you can just copy and paste them to construct the 
pkg-plist file.


Building in poudriere will build the package in a clean jail with only 
the dependencies installed, which prevents you from accidentally picking 
up other stuff that you may have in your environment.


A few comments on the Makefile:

- You're missing a version.  This is a requirement, I'm a bit surprised 
the ports system builds at all without it.


- Please set yourself as the maintainer, not me.

- You've set GNU_CONFIGURE, does GDL actually use autoconf?

- Please don't put the libs- prefix in the ports name.  gdl2 is fine.

- The $FreeBSD$ tag at the top is incorrect (it looks as if you copied 
this file from SimpleAgenda), if you truncate it to $FreeBSD$ then svn 
will fix it for you on commit.


- Please add gnustep as a category.

David

On 21/05/2019 08:26, Edwin Ancaer wrote:

Hello all,

I do not want to look impatient, but as the best way to learn is to try 
it yourself, I tried to use the ports system, to locally create a port 
for gdl2 (Makefile is attached).


I generated the distinfo file with the makesum command  (result also 
attached), but then,  when using make makeplist to generate the list of 
installed files after the compiation, I got some compilation errors.


root@ottopedi:/usr/local/poudriere/ports/head/databases/gdl2 # make 
makeplist

===>  Building for libs-gdl2-
gmake[1]: Entering directory 
'/usr/local/poudriere/ports/head/databases/gdl2/work/libs-gdl2-gdl2-0_12_0'

This is gnustep-make 2.7.0. Type 'gmake print-gnustep-make-help' for help.
Running in gnustep-make version 2 strict mode.
Making all in EOControl ...
gmake[2]: Entering directory 
'/usr/local/poudriere/ports/head/databases/gdl2/work/libs-gdl2-gdl2-0_12_0/EOControl'

Making all for library EOControl...
/usr/local/bin/clang70 EOGenericRecord.m -c \
       -MMD -MP -DGNUSTEP_BASE_LIBRARY=1 -DGNUSTEP_RUNTIME=1 
-D_NONFRAGILE_ABI=1 -g -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 -Wall 
-DGSWARN -DGSDIAGNOSE -Wno-import -Wall -DGSWARN -DGSDIAGNOSE 
-Wno-import -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -Wall -DGSWARN 
-DGSDIAGNOSE -Wno-import -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -O2 
-pipe -fstack-protector -fno-strict-aliasing -O2 -pipe -fstack-protector 
-fno-strict-aliasing -Wno-import -I/usr/local/include 
-fobjc-runtime=gnustep-1.8 -fblocks 
-fconstant-string-class=NSConstantString -I./. -I.. -I. 
-I/usr/local/poudriere/ports/head/databases/gdl2/work/GNUstep/Library/Headers 
-I/usr/local/GNUstep/Local/Library/Headers 
-I/usr/local/GNUstep/System/Library/Headers -I/usr/local/include \

        -o obj/EOControl.obj/EOGenericRecord.m.o
/usr/local/bin/clang70 EOQualifier.m -c \
       -MMD -MP -DGNUSTEP_BASE_LIBRARY=1 -DGNUSTEP_RUNTIME=1 
-D_NONFRAGILE_ABI=1 -g -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 -Wall 
-DGSWARN -DGSDIAGNOSE -Wno-import -Wall -DGSWARN -DGSDIAGNOSE 
-Wno-import -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -Wall -DGSWARN 
-DGSDIAGNOSE -Wno-import -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -O2 
-pipe -fstack-protector -fno-strict-aliasing -O2 -pipe -fstack-protector 
-fno-strict-aliasing -Wno-import -I/usr/local/include 
-fobjc-runtime=gnustep-1.8 -fblocks 
-fconstant-string-class=NSConstantString -I./. -I.. -I. 
-I/usr/local/poudriere/ports/head/databases/gdl2/work/GNUstep/Library/Headers 
-I/usr/local/GNUstep/Local/Library/Headers 
-I/usr/local/GNUstep/System/Library/Headers -I/usr/local/include \

        -o obj/EOControl.obj/EOQualifier.m.o
/usr/local/bin/clang70 EOKeyValueQualifier.m -c \
       -MMD -MP -DGNUSTEP_BASE_LIBRARY=1 -DGNUSTEP_RUNTIME=1 
-D_NONFRAGILE_ABI=1 -g -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 -Wall 
-DGSWARN -DGSDIAGNOSE -Wno-import -Wall -DGSWARN -DGSDIAGNOSE 
-Wno-import -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -Wall -DGSWARN 
-DGSDIAGNOSE -Wno-import -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -O2 
-pipe -fstack-protector -fno-strict-aliasing -O2 -pipe -fstack-protector 
-fno-strict-aliasing -Wno-import -I/usr/local/include 
-fobjc-runtime=gnustep-1.8 -fblocks 
-fconstant-string-class=NSConstantString -I./. -I.. -I. 
-I/usr/local/poudriere/ports/head/databases/gdl2/work/GNUstep/Library/Headers 
-I/usr/local/GNUstep/Local/Library/Headers 
-I/usr/local/GNUstep/System/Library/

Re: FreeBSD ports for GDL2 and GSWeb

[David Chisnall]

I don’t think they’re there, but I’m happy to commit a port if you want to 
maintain one.  Last time I tried it (admittedly, around 15 years ago), it 
worked out of the box on FreeBSD, so it should just be a few lines of Makefile 
and a pkg-descr / pkg-plist.

That said, there’s something broken with the FreeBSD GNUstep ports at the 
moment that I haven’t had a chance to track down.  It looks as if something 
recent (change to the compiler maybe?) has caused -gui to build with the old 
ABI, but everything else to build with the new ABI, causing run-time linker 
errors.  I hope to have time to debug this today or later in the week.

David

> On 19 May 2019, at 08:22, Edwin Ancaer  wrote:
> 
>  Hello,
> 
> I've been searching for ports for GDL2 and GSWeb, but did not find them.
> 
> Can someone confirm they do not exist, or give the names of the ports 
> otherwise. I tried with gdl2, gsweb, gnustepweb.
> 
> If they don't exist, is this just because nobody has been interested? I ask 
> because there is not much reason in trying to port these applications  if 
> there are technical or other reasons that make it impossible  or very hard to 
> do.
> 
> Thanks,
> 
> Edwin Ancaer
> ___
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep


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