Re: GNUstep on Hackernews
On Thu, 23 Dec 2021 at 00:07, Gregory Casamento wrote: > > Excellent article, but I have to say that saying GNUstep as an > implementation of NeXTSTEP is half our issue. It would be better to say it > is an implementation of Cocoa. Thank you! It was only a brief mention and the piece was getting over-long anyway. I feel that the term Cocoa is not well-enough known, nor would something like "Yellow Box" or something be either. I had just talked about how macOS bundles apps into special folders, how it had inherited this from its ancestor NeXTstep, so I thought it was fair to continue that line by saying that there's a FOSS re-implementation of that stuff. Is the .app folder bundle format part of Cocoa, the API, anyway? -- Liam Proven ~ Profile: https://about.me/liamproven Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
Re: People think we are for nostalgics or dead.
It’s funny. I originally got into GNUStep because I’m a history buff and the NeXT era of Steve Job’s career fascinates me. I was and still am fascinated by how modern it is, despite most of the concepts dating back to like 1990. I expected GNUStep to be a window into the early days of software development. What I found is that it’s just as vital and usable as ever and that I just straight up prefer it to other—much newer—frameworks. It’s just awesome. The OOP approach in ObjC is just right. It doesn’t bludgeon your over the head like Java or C#. And if there’s some additional functionality you need, you can go grab any C library and just use it. I’m not sure what this concept is called, but I love how e.g. NSTableViewDataSource works. The API just asks you, “what does the cell at col X and row Y look like?” So much better than other implementations. I was writing an Android app in Java several years ago and I was so appalled by their list view that I wrote a Cocoa-inspired list data source class. Sent from my iPhone > On Dec 23, 2021, at 8:12 AM, H. Nikolaus Schaller wrote: > > > >> Am 23.12.2021 um 14:44 schrieb Gustavo Tavares : >> >> What do I love most about Cocoa? > > [note: here I read "Cocoa" more precisely as "Objective-C + > Base/GUI-Frameworks". There was a JAVA binding for Apple Cocoa long time ago > which I did not love equally well.] > >> You can actually read your code 6 months laters. > > Not only that. You can easily read code written by someone else 60 or even > more months later. > > I randomly picked some 5 years old code from github: > https://github.com/nicklockwood/iCarousel/blob/master/iCarousel/iCarousel.m > >> The parameters are labeled appropriately—and many `selectors` are English >> phrases. > > exactly. > >> Concepts are more important than saving a character here and there. > > I agree that I don't like the abbreviationism of some other languages which > has the wrong focus of saving characters during typing... > >> I would go as far as to say that Cocoa is the most readable API of all. > > And if you avoid the . notation for calling methods it is even more readable. > Brad Cox: everything in [ ] is a method call - except for C arrays. If you > avoid . method calls even the opposite holds true. > > In my experience the savings by @synthesisze for building getters/setters > automatically saves only some minutes during coding. Where coding is just a > small fraction of total project time. Most is debugging and refactoring code. > Then it is important that the code is readable without deciphering symbolic > operators. > >> >> So...what do you love about Cocoa? > > > See above :) > > BR, > Nikolaus
Re: People think we are for nostalgics or dead.
> Am 23.12.2021 um 14:44 schrieb Gustavo Tavares : > > What do I love most about Cocoa? [note: here I read "Cocoa" more precisely as "Objective-C + Base/GUI-Frameworks". There was a JAVA binding for Apple Cocoa long time ago which I did not love equally well.] > You can actually read your code 6 months laters. Not only that. You can easily read code written by someone else 60 or even more months later. I randomly picked some 5 years old code from github: https://github.com/nicklockwood/iCarousel/blob/master/iCarousel/iCarousel.m > The parameters are labeled appropriately—and many `selectors` are English > phrases. exactly. > Concepts are more important than saving a character here and there. I agree that I don't like the abbreviationism of some other languages which has the wrong focus of saving characters during typing... > I would go as far as to say that Cocoa is the most readable API of all. And if you avoid the . notation for calling methods it is even more readable. Brad Cox: everything in [ ] is a method call - except for C arrays. If you avoid . method calls even the opposite holds true. In my experience the savings by @synthesisze for building getters/setters automatically saves only some minutes during coding. Where coding is just a small fraction of total project time. Most is debugging and refactoring code. Then it is important that the code is readable without deciphering symbolic operators. > > So...what do you love about Cocoa? See above :) BR, Nikolaus
Re: People think we are for nostalgics or dead.
So GNUstep makes it pretty clear "The framework closely follows Apple's Cocoa APIs and is portable to a variety of platforms and architectures." But what I would love—more than trying to play "catch-up" is to also sell people on the idea of Cocoa. "Switch from Apple" is a feature—not the reason to exist. Like—why should you consider Cocoa when making an app? What is it that makes the framework great? Apple seems to longer care about Cocoa. At some point, Cocoa may even cease to exist. (e.g Swift / SwiftUI) I think there is a case to be made for Cocoa—and that GNUstep could lead the charge in making people fall in love with Cocoa again. What do I love most about Cocoa? You can actually read your code 6 months laters. The parameters are labeled appropriately—and many `selectors` are English phrases. Concepts are more important than saving a character here and there. I would go as far as to say that Cocoa is the most readable API of all. So...what do you love about Cocoa? Personally, I would love a section on the front page that makes it clear to Cnew devs (many of whom never have used Objectice-C or Cocoa) that "Hey, Cocoa is amazing. Try it. You'll want to use it forever." And we could make a separate page just rattling off the benefits. The framework needs and can be sold on its merits. Apple be dammed. Ideas - It is a faster building GUI toolset relative to C++ - It is easier to read - You can drop down to C if needed - You can stay in memory-safe Smalltalk as desired - Any more?? PS — So...what do you love about Cocoa? On Wed, Dec 22, 2021, at 7:52 AM, Gregory Casamento wrote: > Liam, > > On Wed, Dec 22, 2021 at 6:43 AM Liam Proven wrote: >> On Wed, 22 Dec 2021 at 12:21, Gregory Casamento >> wrote: >> > >> > I have updated the website recently to show the themes. >> > >> > I am also posting, pretty much daily, about progress with GNUstep on >> > twitter. The best we can do is to try to put ourselves out there the way >> > we really are. Looking at GNUstep's stats on github tells the story that >> > we are not dead. >> > >> > Also, the discussion on hackernews showed that a lot of people are turning >> > around their opinions. We will not change the general impression of the >> > project in a day (or even a month or a year) but if we persist in making >> > it known that we are not a bunch of Luddites, then people will, >> > eventually, pick up on that. >> > >> > We must strive to change people's opinions. >> >> What is the best way to suggest text changes, new content, new links >> etc. for the website? >> > > Right now the website is still hosted on CVS on savannah.org... (I know)... I > am going to change this, but at the moment I need some assistance since there > are some things in the hosting (at gandi.net) which complicate moving the > site. More on that in another email. > > A strong argument for moving the site is that it is currently hosted on a > very old machine. > > There is a duplicate of the site at > g...@github.com:gnustep/gnustep-github-io.git (https://gnustep.github.io). > So, for now the best thing to do is to make suggestions here. Once I get it > moved, you can submit PRs. > >> Greg, since I note you now have your own Twitter account – @bheron >> (and may I ask why that? Just curious) – then I suggest you, or the >> community, or something, take your name off @gnustep and try to post >> something on there every day. > > That's a good idea. Originally that was my intention, but it just became > easier to post on @bheron. > >> www.bufferapp.com may be useful for this. I use a free account there >> myself. You can put a load of stuff in, every day, and schedule when >> it gets posted. > > Ah, cool, I will check it out. > >> -- >> Liam Proven ~ Profile: https://about.me/liamproven >> Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com >> Twitter/LinkedIn: lproven ~ Skype: liamproven >> UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) >> 702-829-053 >> > > > -- > 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 > https://teespring.com/stores/gnustep - Store
Re: linking with mold
H. Nikolaus Schaller wrote on 23.12.21 09:33: > >> Am 22.12.2021 um 12:57 schrieb Andreas Fink : >> >> I'm happy in terms of functionality with gold linker but linking my >> projects is quite slow. My projects has around five thousands source >> files. All very small but still lots of them. So linking is taking most >> of the time when I modify and run something. > Hm. > > Couldn't you group those 5000 files into a hierarchy of libraries/frameworks? They are already. But I have two big libraries. ulibgsmmap (1046 .m files) and ulibdiameter (654 .m files). They can't be split further because underlying protocol standards they implement. > And re-link only a small modified portion of the full dependency tree? to build the final binary it still has to link everything together. Either at build time or at start time by the dynamic linker. > Current Linux kernel has ca. 32911 .c files but links (not compiles) within > seconds by such a hierarchy if I change a single source file. Linux kernel is pure C and is mostly modules which are not recompiled if you change a single source file I'm not complaining about my current setup. I just think it could be improved. So far a full rebuilt on a Debian 10 vm on a 28 core MacPro takes 6 minutes. (on a M1 mac it takes 5minutes 40 sec). Most of the time I don't need a full rebuilt but I can see the linking part taking a lot of time. Having the option to use a linker which runs on many cores could drastically improve that. using "mold" would thus nice. But I wanted to be sure i don't run into any issues like with ld or lld. Hence my question if anyone tried. If not, I will investigate and test myself.
Re: GNUstep on Hackernews
Hugo, Yes, I know this. The point is that between Foundation and AppKit, almost all of the classes and methods which were missing (up to 10.15) have been written by myself and others over the last few years. We have a CoreData, and CoreGraphics (Opal) implementation, granted the last two are less complete. Yours, GC On Thu, Dec 23, 2021 at 3:59 AM Hugo Melder wrote: > Cocoa is not only AppKit but also the CoreGraphics and CoreData > Integration. We have no upstream Integration for the newer frameworks. > > On December 23, 2021 1:01:43 AM GMT+01:00, Gregory Casamento < > greg.casame...@gmail.com> wrote: >> >> >> >> On Wed, Dec 22, 2021 at 18:13 Ivan Vučica wrote: >> >>> Well, some parts of. >> >> >> Apparently you haven’t looked lately. >> >> >>> >>> On Wed, Dec 22, 2021 at 11:07 PM Gregory Casamento >>> wrote: >>> > >>> > “Ironically, Linux could easily have had much the same because all the >>> functionality already exists in GNUstep, the venerable FOSS rewrite of >>> NeXTstep's core libraries.“ >>> > >>> > Liam, >>> > >>> > Excellent article, but I have to say that saying GNUstep as an >>> implementation of NeXTSTEP is half our issue. It would be better to say >>> it is an implementation of Cocoa. >>> > >>> > GC >>> > >>> > >>> > >>> > >>> > >>> > On Wed, Dec 22, 2021 at 17:15 Liam Proven wrote: >>> >> >>> >> On Wed, 22 Dec 2021 at 23:01, Ivan Vučica wrote: >>> >> > >>> >> > >>> >> > I'm unaware of a packaging system in GNUstep; I admit not to know of >>> >> > everything or keeping up with everything in GNUstep, however. >>> >> > >>> >> > I'm also unaware of the article being referred to; I admit not to >>> >> > reading the entire (excessively long) thread. Could you kindly share >>> >> > the link again? >>> >> >>> >> To my piece? Sure. >>> >> >>> >> https://www.theregister.com/2021/11/26/linux_software_installation/ >>> >> >>> >> It is not about GNUstep; it merely mentions it. >>> >> >>> >> Re your other points, all very well-argued, I think, and thanks for >>> the info. >>> >> >>> >> >>> >> -- >>> >> Liam Proven ~ Profile: https://about.me/liamproven >>> >> Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com >>> >> Twitter/LinkedIn: lproven ~ Skype: liamproven >>> >> UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) >>> 702-829-053 >>> >> >>> > -- >>> > 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 >>> > https://teespring.com/stores/gnustep - Store >>> >> -- >> 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 >> https://teespring.com/stores/gnustep - Store >> > -- 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 https://teespring.com/stores/gnustep - Store
Re: GNUstep on Hackernews
Le 22.12.2021 23:00, Ivan Vučica a écrit : I mean here's a realistic wishlist: - A desktop session - ship a package that contains /usr/share/xsessions/gnustep-desktop.desktop e.g. 'gnustep-session' or 'gnustep-desktop-session' - have it start our chosen WM, gworkspace with dock, a global dbusmenu compatible menu, etc If GNUStep wants to delegate the desktop to other projects, the best gnustep-desktop-session would be one of those projects. Curently a pure GNUStep session doesn't demonstrate its power, quite the opposite. Have a look at Serjii's work: building NextSpace was/is a lot of work, and required changes to WM and GSWorkspace. --- Librement, Xavier Brochard xav...@alternatif.org La liberté est à l'homme ce que les ailes sont à l'oiseau (Jean-Pierre Rosnay)
Re: GNUstep on Hackernews
Cocoa is not only AppKit but also the CoreGraphics and CoreData Integration. We have no upstream Integration for the newer frameworks. On December 23, 2021 1:01:43 AM GMT+01:00, Gregory Casamento wrote: >On Wed, Dec 22, 2021 at 18:13 Ivan Vučica wrote: > >> Well, some parts of. > > >Apparently you haven’t looked lately. > > >> >> On Wed, Dec 22, 2021 at 11:07 PM Gregory Casamento >> wrote: >> > >> > “Ironically, Linux could easily have had much the same because all the >> functionality already exists in GNUstep, the venerable FOSS rewrite of >> NeXTstep's core libraries.“ >> > >> > Liam, >> > >> > Excellent article, but I have to say that saying GNUstep as an >> implementation of NeXTSTEP is half our issue. It would be better to say >> it is an implementation of Cocoa. >> > >> > GC >> > >> > >> > >> > >> > >> > On Wed, Dec 22, 2021 at 17:15 Liam Proven wrote: >> >> >> >> On Wed, 22 Dec 2021 at 23:01, Ivan Vučica wrote: >> >> > >> >> > >> >> > I'm unaware of a packaging system in GNUstep; I admit not to know of >> >> > everything or keeping up with everything in GNUstep, however. >> >> > >> >> > I'm also unaware of the article being referred to; I admit not to >> >> > reading the entire (excessively long) thread. Could you kindly share >> >> > the link again? >> >> >> >> To my piece? Sure. >> >> >> >> https://www.theregister.com/2021/11/26/linux_software_installation/ >> >> >> >> It is not about GNUstep; it merely mentions it. >> >> >> >> Re your other points, all very well-argued, I think, and thanks for the >> info. >> >> >> >> >> >> -- >> >> Liam Proven ~ Profile: https://about.me/liamproven >> >> Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com >> >> Twitter/LinkedIn: lproven ~ Skype: liamproven >> >> UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) >> 702-829-053 >> >> >> > -- >> > 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 >> > https://teespring.com/stores/gnustep - Store >> >-- >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 >https://teespring.com/stores/gnustep - Store
Re: linking with mold
> Am 22.12.2021 um 12:57 schrieb Andreas Fink : > > I'm happy in terms of functionality with gold linker but linking my > projects is quite slow. My projects has around five thousands source > files. All very small but still lots of them. So linking is taking most > of the time when I modify and run something. Hm. Couldn't you group those 5000 files into a hierarchy of libraries/frameworks? And re-link only a small modified portion of the full dependency tree? Current Linux kernel has ca. 32911 .c files but links (not compiles) within seconds by such a hierarchy if I change a single source file. -- hns
