> Am 04.07.2024 um 00:06 schrieb Riccardo Mottola :
>
>
> Fred Kiefer wrote:
>>> is NSWorkspace's launchApplication the best answer?
>> Yes, to me this sounds like the right way to go.
>
> indeed, it works for running. It didn't yesterday because
> Am 02.07.2024 um 22:15 schrieb Riccardo Mottola :
>
> Hi,
>
> is there a way to start an application - as in GNUstep or mac app bundle -
> natively from?
> Something that would be the equivalent of gopen/openapp essentially.
>
> To start a normal executable I can use NSTask.
> I see two
I generated the files that are needed for a GUI and back release. I don’t have
the means to generate the release itself. It would be creat if somebody
(Richard or Ivan) could do that right after the base release.
I ran into an issue with generating the NEWS and ANNOUNCE files for GUI (on
back
I am currently trying to join this meeting. Looks like there is no moderator
present. Has this meeting been cancelled or postponed? I will only be able to
attend for another half hour so if we don#t start soon, I will have to drop out.
Cheers,
Fred
> Am 08.02.2024 um 01:28 schrieb Gregory
I am no Windows expert but I remember that for some compilers we needed special
symbol handling there. We use the macro GS_EXPORT_CLASS there which boils down
to some __declspec(dllexport) declarations on classes. Not sure whether this
would also be needed for a class that is only locally used.
Sorry, I am completely lost here. Are you referring to line 301 or 351? I think
that you expect the code starting in line 351 will be able to update the
appIcon. This won’t work in GNUstep. When locking focus on an image we try to
draw a representation of the image on an NSCachedImageRep. Your
I am sorry, I won’t make it to FOSDEM this year. Seeing you would be great but
the German railway (DB) has all connections flagged as being unreliable und
during the last year we learned what that means.
I ope you have a great time there.
Cheers,
Fred
> Am 10.01.2023 um 14:30 schrieb Ivan
get this fixed within the next few hours, I will just mail you the
changes to the news files.
Sorry for the delay,
Fred
> Am 28.12.2022 um 14:35 schrieb Fred Kiefer :
>
> Merry Christmas to you too Richard!
>
> Great that you started to build releases of make and base. If it is
Merry Christmas to you too Richard!
Great that you started to build releases of make and base. If it isn’t too much
trouble for you, could you please release guidance and back as well? The last
release there was almost two years ago. I am willing to update the news.texi
file for these two
I will only be able to attend for an hour or so, as we have booked a table at a
restaurant at 19:30 that evening.
Cheers,
Fred
> Am 09.02.2022 um 16:38 schrieb greg.casame...@gmail.com:
>
> You have been invited to the following event.
> Discussion of GCC v. Clang -- redux of quarterly meeting
> Am 07.02.2022 um 18:47 schrieb Wolfgang Lux :
>
>> Am 06.02.2022 um 19:50 schrieb Fred Kiefer :
>>
>>> Am 06.02.2022 um 16:30 schrieb Wolfgang Lux :
>>>
>>>> There are bugs in GNUstep and probably there always will be. We don’t get
>>
Hi Wolfgang,
> Am 06.02.2022 um 16:30 schrieb Wolfgang Lux :
>
>> There are bugs in GNUstep and probably there always will be. We don’t get
>> enough testing, usage, for GNUstep gun applications, so many bugs may go
>> unnoticed for a long time. At least the first bug you mention below is
>>
HI Wolfgang,
it is sad to read about you being disappointed by GNUstep. Especially on the
one day where I was looking forward to join the GNUstep quarterly online
meeting.
There are bugs in GNUstep and probably there always will be. We don’t get
enough testing, usage, for GNUstep gun
For me merging that PR is fine. I did approve it some time ago. If nobody
objects I would merge it next week.
Fred
> Am 28.11.2021 um 10:27 schrieb Riccardo Canalicchio
> :
>
> hello,
> I'd like to follow up on this PR:
> https://github.com/gnustep/libs-back/pull/33
>
> I was thinking that
HI Ivan,
still waiting for the thumbs up? You definitely got one from me :-)
Riccardo and Richard fixed a few bugs in the meantime and there are surely a
few more to fix, but there always will be. We really should try to get a new
release out to the world. At the moment I am faced with a few
Thank you for finding this. I made a mistake when I changed the encoding to use
our new helper functions. For strange reasons an unsigned int had been used for
the maximum. Should be fixed now. Hopefully no Gorm file was created in the
meantime.
Cheers,
Fred
> Am 12.02.2021 um 14:08 schrieb
Great you did find this. This was my fault. I regenerated that fie and all
other language files just as I always do before a release. I was not aware that
this file (and the one for Esperanto) had been converted to UTF8 and the tool
we use to generate these files seems to ignore the old format.
> Am 20.01.2021 um 20:13 schrieb Riccardo Mottola :
>
> Hi,
>
> Fred Kiefer wrote:
>>> I will try to bisect - but I'd liek to track this down before a release,
>>> especially knowing it is something done these last months.
>> If this is really a recent
> Am 20.01.2021 um 17:08 schrieb Riccardo Mottola :
>
> Hi,
>
> Richard Frith-Macdonald wrote:
>> I think the base library is functionally OK, but I need to get ChangeLog
>> updated from the git logs, and it turns out there is no tool that does a
>> good job of this so it may take me a day
> Am 18.01.2021 um 16:46 schrieb Ivan Vučica :
>
> On Mon, Jan 18, 2021 at 10:55 AM Richard Frith-Macdonald
> wrote:
>>> On 16 Jan 2021, at 19:50, Fred Kiefer wrote:
>>>
>>> I updated the required files and also increased the version number in both
&
can cut releases next
> week.
>
> If a maintainer wishes me to release and upload anything that is not
> included in the usual batch of releases on ftp.gnu.org, let me know
> and I can try pushing that out as well.
>
> On Thu, Jan 14, 2021 at 6:27 PM Fred Kiefer wrote:
>>
>> Hi I
Hi Ivan,
great that you remind us! The problem at the moment is that there is a know
problem for 64bit big endian systems in gui (actually a rather long standing
issue) and even two suitable solutions for it. But we haven’t decided which
solution to prefer. Either we reach a consensus quickly
> Am 08.01.2021 um 01:23 schrieb Riccardo Mottola :
>
> Richard Frith-Macdonald wrote:
>> Changing the type of the masks from NSInteger to uint32_t would also fix the
>> encoding/decoding of course. Maybe that has other issues though.
>
> perhaps we should try a mixed approach: encode/decode
> Am 07.01.2021 um 14:33 schrieb Riccardo Mottola :
>
> Wolfgang Lux wrote:
>> Yes. Changing the type you pass to the {en,de}codeValueOfObjCType methods is
>> a, errm, not so bright idea. The types are included in the binary archives.
>> So, trying to decode a value with a different type
> Am 06.01.2021 um 22:57 schrieb Wolfgang Lux :
>
>> good catch. We have two differences here 32bit vs 64bit, but also signed vs
>> unsigned!
>
> the difference between signed and unsigned is irrelevant for encoding and
> decoding, as you pass a pointer to the memory being encoded or
> Am 06.01.2021 um 17:20 schrieb Wolfgang Lux :
>
>
>
>> Am 06.01.2021 um 17:15 schrieb Wolfgang Lux :
>>
>>
>>
>>> Am 06.01.2021 um 15:41 schrieb Fred Kiefer :
>>>
>>>
>>> The next step would be to compare thes
> Am 06.01.2021 um 15:32 schrieb Riccardo Mottola :
>
> Fred Kiefer wrote:
>>
>> You should concentrate on the _highlightByMask which gets decoded in line
>> 1905 (_showAltStateMask is handled just below).
>
> I put a log statement "after" and I al
> Am 06.01.2021 um 01:06 schrieb Riccardo Mottola :
>
> On 2021-01-05 08:07:59 +0000 Fred Kiefer wrote:
>
>>> line 1094, after the mask is calculated, do you expect it to be always 0,
>>> both for on and off state? It is always 0 for me.
>> As you can see
> Am 05.01.2021 um 01:28 schrieb Riccardo Mottola :
>
>
> Fred Kiefer wrote:
>> thank you for pointing out this issue. As I don’t have a Bigendian 64 bit
>> system you will have to do the testing to pin this down. First I would
>> propose that
Hi Riccardo,
thank you for pointing out this issue. As I don’t have a Bigendian 64 bit
system you will have to do the testing to pin this down. First I would propose
that you add a few NSLog statements in NSButtonCell.m after line 1773. Most
likely the data is not aligned in the unsigned int
The lines that the debugger reports look like this:
if ([[img image] size].width > 64
|| [[img image] size].height > 64)
The most likely reason for a crash here is [img image] being nil. Just add a
check for this condition a few lines above and see what happens.
Hope this helps,
Fred
> Am 23.11.2020 um 17:50 schrieb Richard Frith-Macdonald
> :
>
>> On 22 Nov 2020, at 22:09, Riccardo Mottola
>> wrote:
>>
>> Riccardo Mottola wrote:
>>> #0 0x772103ab in objc_msg_lookup () from
>>> /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/libobjc.so.4
>>> #1 0x77bf976c in
Dear GNUsteppers,
I will be away for two weeks of holidays with very limited internet access.
This may delay any pull request for gui and back for a few days. That shouldn’t
cause too much inconvenience.
Cheers,
Fred
I commited your patch to GNustep make.
Thank you,
Fred
Am 26.08.20 um 21:28 schrieb Ladislav Michl:
> Remove hack to fake OBJCXX checks as autoconf-2.65 (first one
> supporting Objective-C++) is over ten years old already.
> ---
> Hi,
>
> this is resend of a patch patch sent more than half a
t;
> Cheers,
>
> Josh
>
>
>
>
> [1] Earlier install problems were due to running the KDE Neon installer under
> BIOS; KDE Neon requires UEFI.
>
>
> On May 30, 2020, at 5:27 PM, Fred Kiefer wrote:
>
>> Thank you Josh for this excellent analysis. M
OpenSuse did just switch to gcc 10 and now I have issues with GNUstep
make. The gcc version gets detected as 1.0 which is obviously wrong. But
this is only partly our fault gcc actually behaves strange:
gcc --version
gcc (SUSE Linux) 10.1.1 20200507 [revision
Thank you Josh for this excellent analysis. My impression is that this is
somewhat of a Kubuntu bug, still it is better to fix it in our code especially
if this results in a speed up. Such a speed up is really needed for slower
machines.
I will look through the details of the patch tomorrow
> Am 29.05.2020 um 21:13 schrieb Riccardo Mottola :
>
> Hi Fred,
>
>
> Fred Kiefer wrote:
>> Turns out I was wrong here. Of course the bison grammar was wrong and needed
>> correction, but this was not what caused this issue. Here 1 is a valid
>> co
. This specific one
was important as it gets used a lot on the Mac.
Please give the new code a try,
Fred
> Am 26.05.2020 um 15:44 schrieb Fred Kiefer :
>
> Most likely I made an error in the rtfGrammer.y file on line 212. The
> statement "$$ = 3" should just re
Most likely I made an error in the rtfGrammer.y file on line 212. The statement
"$$ = 3" should just read "3". I will correct that and regenerate the dependent
files as soon as I am back home, that is sometimes next weekend. You could
check whether this is the case by looking at your RTF files,
> Am 25.05.2020 um 09:28 schrieb RIccardo Mottola :
>
> I noticed that on a totally fresh installation on intel 32bit, I get many
> warnings of the type "Lost information converting decoded value to in32_t"
> when starting GWorkspace.
>
> Putting a breakpoint, I noticed that this issue is
> Am 15.05.2020 um 12:02 schrieb David Chisnall :
>
> At some point, I'd like to move libobjc2 to requiring at least CMake 3.16.
> 3.15 gained support for driving the GCC-flavoured clang on Windows with the
> Visual Studio ABI (older versions have to use clang-cl, which takes Visual
>
Thank you Ivan for the great work you are doing here. And I promise to try to
lighten the work on the next release by making sure every pull request gets it
proper ChangeLog entry.
Fred
> Am 05.04.2020 um 22:42 schrieb Ivan Vučica :
>
> I have cut new releases:
> - gnustep-make 2.8.0
> -
:
> On Tue, Feb 11, 2020 at 8:09 AM Fred Kiefer
> wrote:
>> And most importantly, Ivan will you have time to cut all these
>> releases? Of course we could move that point around a week or two
>> if that date fits better
>
> I've only now seen this.
>
> T
> Am 28.02.2020 um 11:37 schrieb Riccardo Mottola :
> Sergii Stoian wrote:
>>
>>> On Feb 27, 2020, at 23:09, Riccardo Mottola
>>> wrote:
>>>
>>> before a release, I would like these issues to find a solution.
>>>
>>> - understand why we don't work properly on my ThinkPad T23 neither with
> Am 25.02.2020 um 17:25 schrieb Riccardo Mottola :
>
> Fred Kiefer wrote:
>> I still don’t know for sure what is going on here. Most likely we are
>> overriding some other data when copying the image. To prevent this I made
>> the pre conditio
Currently our build tests for GNUstep base and gut are broken. This render the
automatic validation of pull requests useless. I am rather sure that the issue
is again not in base but rather in changes build requirements of libobjc2,
caused by a change in GNUstep make or that strange linker
> Am 19.02.2020 um 00:37 schrieb Riccardo Mottola :
>
> Fred Kiefer wrote:
>> You won’t have to look up the WINGs documentation. In most cases we do not
>> use a separate Wraster library but have copies of the files in this
>> directory. The one you are looking for
> Am 18.02.2020 um 21:59 schrieb Riccardo Mottola :
>
> Fred Kiefer wrote:
>>
>> You may have to set these separately. I was hoping there was a way to
>> specify and array here, but did not check. So the easiest was is
>>
>> Ink —GNU-Debug=Dflt —GNU
> Am 17.02.2020 um 23:53 schrieb Riccardo Mottola :
>
> Fred Kiefer wrote:
>>
>>
>> With all the latest changes could you please try again and report the stack
>> trace you are getting? It would also help if you could find out which code
>> is crashi
Dear GNUsteppers,
I would like to schedule a shared new release for the core GNUstep packages
(make, base, gui, back) around the end of March. We have a lot of excellent new
features and it would be great to bring those out to more distributions and
users. We are a bit later than in previous
> Am 08.02.2020 um 12:50 schrieb Riccardo Mottola :
>
> On 07/02/2020 10:20, Fred Kiefer wrote:
>> I just committed a merge of the two approaches (plus a few compiler warning
>> fixes). I hope this should fix Riccardo's issues. It might also be slightly
>> faster a
> Am 08.02.2020 um 15:20 schrieb Riccardo Mottola :
>
> On 03/02/2020 21:15, Fred Kiefer wrote:
>> Sergii has written a great patch that will tremendously improve support for
>> multiple monitors in GNUstep by using the XRandR extension. There is a
>> downsi
> Am 04.02.2020 um 22:15 schrieb Sergii Stoian :
>
>> On Feb 4, 2020, at 20:43, Fred Kiefer wrote:
>> In general it is safer as the new code expects that the image is fully
>> packed. (You moved the comment with the conversion from unpacked to packed
>
Dear GNUstepper,
Sergii has written a great patch that will tremendously improve support for
multiple monitors in GNUstep by using the XRandR extension. There is a downside
to it though, this patch will also remove any multi screen support that was
there before without XRandR. So if you have a
> Am 03.02.2020 um 00:53 schrieb Sergii Stoian :
>
> On Mon, Feb 3, 2020 at 1:05 AM Fred Kiefer wrote:
>
> I just ran a quick scan with valgrind and this did not detect any obvious
> wrong memory access. Looking at the code once again I see that line 4276 may
>
> Am 02.02.2020 um 21:38 schrieb Riccardo Mottola :
>
> On 1/28/20 11:28 AM, Sergii Stoian wrote:
>>
>> I'm not sure, just an idea: this problem may have relation to enabled
>> multithreading in X11. Probably due to outdated X server.
>> Could you please try to comment out line in
Thank you for your patches. The first two are clear improvements. The third one
also looks good to me, but I must admit it is really hard to read through in a
patch mail (and I only read the configure.ac part. After the merge I would
regenerate configure locally). As far as I can tell you
First off, I tried to run GNUstep cross compilation ages ago and never
succeeded and I didn’t hear that things improved in between. But for your
specific problem it looks like you set „target“ when building make and later
when building base you set both „host“ and „target“. And what is more
Hi Adam,
thank you very much for providing this. It will cost me quite some time to look
through your changes but I am happy to do so. You could have saved me some
effort by providing these changes a bit earlier :-( Just a few days ago I took
over your XIB loading changes from a probably
From the error message I would suspect that you have an old plugin for
SystemPreferences lying around that still gets loaded causing this issue.
> Am 05.01.2020 um 23:01 schrieb RIccardo Mottola :
>
> I was able to compile most of GNUsteps apps with the options discussed in a
> previous mail,
You really had me in a short state of shock when coming back from jogging and
seeing this merge had happened. Thank you for cleaning up that quickly!
Fred
> Am 03.01.2020 um 13:50 schrieb Sergii Stoian :
>
> Fixed.
> I've used `git rebase -i` and `git push origin master --force`. Everything
ii
>
>> On 24 Dec 2019, at 17:32, Fred Kiefer wrote:
>>
>> Sorry for not being clear enough. Using rounded pull downs or different
>> edges is nothing a theme would do. This is official functionality that the
>> normal GNUstep drawing must support. We woul
gii
>
>> On 24 Dec 2019, at 15:15, Fred Kiefer wrote:
>>
>> In your images the only difference I see is the focus ring and even that I
>> see barely. But the real difference will be shown when using a rounded pull
>> down or as Wolfgang pointed out one that u
with current code, the second (PullDown-new.png) with my code.
> I hope you'll notice the difference.
>
>
>
>
> On Tue, Dec 24, 2019 at 12:06 PM Fred Kiefer wrote:
> HI Sergii,
>
> here is what a pull down NSPopUpButton looks like on Cocoa:
>
>
>
> Th
t 18:15, Wolfgang Lux wrote:
> >
> >
> >> Am 20.12.2019 um 16:11 schrieb Fred Kiefer :
> >> There you just describe that now the popup looks the same whether in pull
> >> down or in popup state. But what is the reason for this change? As I wrote
> >>
> Am 20.12.2019 um 15:20 schrieb Sergii Stoian :
>
> On Fri, Dec 20, 2019 at 2:24 PM Fred Kiefer wrote:
>
>
> > Am 20.12.2019 um 11:34 schrieb Sergii Stoian :
> >
> > I've moved discussion to mail list as Fred asked me.
> >
> > On Fri, Dec
> Am 20.12.2019 um 11:34 schrieb Sergii Stoian :
>
> I've moved discussion to mail list as Fred asked me.
>
> On Fri, Dec 20, 2019 at 12:18 PM Fred Kiefer wrote:
> Some of the changes of this pull request are obviously correct. What I doubt
> is the overall chan
> Am 16.12.2019 um 11:44 schrieb Riccardo Mottola :
>
> on a very plain Linux i386 32bit setup, configured with clang, libobjc2 and
> ng-gnu-gnu runtime I always had issues with almost everything crashing, this
> is months old (years?).
>
> What happens is this:
> Program received signal
find this useful,
Fred
> Am 09.12.2019 um 10:46 schrieb Fred Kiefer :
>
> I just want to let you know that I have started to integrate the
> Eggplant code for XIB document loading, that is the newer XIB format,
> into GNUstep gui. Over the weekend I managed to integrate a mi
I just want to let you know that I have started to integrate the
Eggplant code for XIB document loading, that is the newer XIB format,
into GNUstep gui. Over the weekend I managed to integrate a minimal
version of the code into a git branch and get it compile with gcc. The
next step is to clean up
First off before I explain why I am strongly against Gitflow let me restate
that I advocate feature branches and pull requests. But I will come back to
that in the end.
A software workflow should match the organisation and purpose of a project and
the people that defined Gitflow are well aware
I fixed these places. Bugs like this could easily be avoided by using branches
and pull requests and having the travis CI test the build on different
environments. But this did not happen. Looks like somebody wants to stop
compilation of GNUstep with gcc.
Fred
> Am 14.11.2019 um 21:55
> Am 24.08.2019 um 03:07 schrieb Patryk Laurent via Gnustep-dev
> :
>
> On Aug 22, 2019, at 22:30, Fred Kiefer wrote:
>
>> Could you please provide some details about your system?
>>
>> Am 23.08.2019 um 01:20 schrieb Patryk Laurent via Gnustep-dev
&
Could you please provide some details about your system? Which version of
GNUstep are you using, what graphic backend (Cairo is the default), which
compiler, OS and so on.
Even with those details I won’t be able to help you before next week as I am in
the middle of the Italian alpes but maybe
Hi Marcus,
the simplest thing to do until you get commit access is to fork the GNUstep
repository into yours and work with pull requests. I will be able to merge
these but won’t be able to add you as a member.
Fred
> Am 16.08.2019 um 17:57 schrieb Marcus Müller :
>
> Hi Devs,
>
> I have
Dear Madscientist,
perhaps we should start off differently. You could try to explain a bit more in
detail what you try to achieve and how you think that GNUstep could help you
with that task. Next you might be able to give us some details about you
background, which programming languages you
> Am 08.08.2019 um 21:39 schrieb Fred Kiefer :
>
>
>
>> Am 04.08.2019 um 23:48 schrieb Riccardo Mottola via Gnustep-dev
>> :
>>
>> On 8/2/19 6:06 PM, Fred Kiefer wrote:
>>> I would not like to revert this change even though I agree with
> Am 04.08.2019 um 23:48 schrieb Riccardo Mottola via Gnustep-dev
> :
>
> On 8/2/19 6:06 PM, Fred Kiefer wrote:
>> I would not like to revert this change even though I agree with you that
>> pull requests this big are bad. The overall changes here are good and
I would not like to revert this change even though I agree with you that pull
requests this big are bad. The overall changes here are good and in most cases
we see no issues with them. As for your specific setting, did you try to run
with the property "GSFontHinting" set to the value 17? This
events in an archive.
Pleas give this workaround a try,
Fred
> Am 24.07.2019 um 12:44 schrieb Gregory Casamento :
>
> Thanks Fred. I also may do some investigation myself. I may not be
> available for a couple of days.
>
> On Wed, Jul 24, 2019 at 02:38 Fred Kiefer w
> Am 23.07.2019 um 16:08 schrieb Gregory Casamento :
>
> I have tried editing classes and adding an NSSlider and connecting it with an
> NSTextField and it is, for some reason, not working properly. Also when
> selecting objects the classes do not appear correctly or at all. I am going
>
> Am 22.05.2019 um 08:53 schrieb Riccardo Mottola :
>
> Sergii Stoian wrote:
>> I've wrote tooltips for ProjectCenter PCButton's implementation. After that
>> someone has copied this implementation into NSView.
>> I looked into ProjectCenter sources long time ago. I was convinced that
>>
Very impressive list of improvements. Thank you very much David!
> Am 31.03.2019 um 13:58 schrieb David Chisnall :
>
> Hello the list,
>
> A kind volunteer gave me access to a BeagleBone Black running FreeBSD, so I
> have now been able to test the runtime with ARM (AArch32) and fixed a few
>
port of font packages (.nfont).
> I want to polish UI: some elements draw lines as gray instead of black (I
> know about half-pixel problem).
> I'd like to test and enhance NSBrowser behavior. I want to implement display
> resolution changes adoption at backend level. May high DPI some
Hi Sergii,
having a pull request to review and approve is always the nicer way to work
with patches. But if this is too much hassle for you feel free to do a direct
commit or even to send a patch file to the mailing list. Which area are you
planing to work on?
Cheers,
Fred
On the road
Am
> Am 02.01.2019 um 17:48 schrieb Ivan Vučica :
>
> In the meantime, if maintainers could help me out by updating the
> non-autogenerated news entries and such, that'd help a lot. Crawling
> through the ChangeLogs and VCS logs takes a lot of the time when
> cutting a release I could better spend
> Am 01.01.2019 um 12:44 schrieb Ivan Vučica :
>
> Hi maintainers,
>
> If you want, I can spend some time cutting a release. It has been a while
> since the last one. Do we need a one? Are there critical bugs we fixed? Are
> there critical bugs blocking the release?
There weren’t that many
> Am 18.12.2018 um 00:55 schrieb Riccardo Mottola :
> Wolfgang Lux wrote:
>> To be honest, no. The runtime.c file unconditionally includes objc-api.h, so
>> it's obviously not supposed to compiled with a compiler that lacks the
>> objc-api.h header file. So it doesn't really matter if the
I think you are correct here. Could you please fix this yourself? I am still
travelling and won’t be able to do it until next week.
Fred
Unterwegs
> Am 09.06.2018 um 07:17 schrieb Stjepan Brkić :
>
> Hello all,
>
> Couple of days ago I started getting errors while running make in
>
Starting today I will be away for a bit more than a week. I will have internet
connection but no computer to do actual work. As Richard is also travelling
others may have to stand in if urgent support tasks show up.
Cheers
Fred
___
Gnustep-dev mailing
Sorry, you seem to be using an unusual mail format that my Apple Mail isn’t
able to properly reply to.
> Am 27.05.2018 um 21:17 schrieb Ivan Vučica <i...@vucica.net>:
> On Sun, May 27, 2018 at 7:47 PM Fred Kiefer <fredkie...@gmx.de> wrote:
> I was already fully aware of
20:
>
> NSPoint point = {.x = 16.0, .y = 32.0};
> NSValue *pointV = [NSValue valueWithPoint: point];
>
> result = !strcmp(@encode(NSPoint), [pointV objCType]);
> PASS(result, "@encoding(NSPoint) == pointV objCType");
>
> result = strcmp(@encode(NSSi
um 16:02 schrieb Fred Kiefer <fredkie...@gmx.de>:
>
> I spend some time to understand this issue. But to be honest it took me more
> time to understand why this ever worked :-)
>
> The problem here is that base uses two different ways to provide concrete
> subclasses for
I spend some time to understand this issue. But to be honest it took me more
time to understand why this ever worked :-)
The problem here is that base uses two different ways to provide concrete
subclasses for NSValue. One being GSValue, which supports generic data and the
other mechanism is
> Am 08.04.2018 um 16:11 schrieb David Chisnall :
>
> On 8 Apr 2018, at 12:41, David Chisnall wrote:
>>
>> On 8 Apr 2018, at 10:55, Richard Frith-Macdonald
>> wrote:
>>>
>>>
>>>
On 6 Apr
> Am 07.04.2018 um 20:51 schrieb David Chisnall :
>
> I am testing out a new version of the compiler / runtime that is producing
> NSConstantString instances with UTF-16 data. I have currently disabled a lot
> of the NSConstantString optimisations, on the basis of
Am 01.04.2018 um 11:52 schrieb David Chisnall :
>
> Hello the list,
>
> I have nearly finished the ELF version of the new Objective-C ABI. It is
> able to pass the same tests that the previous one did in -base, with a
> smaller binary and better reflection metadata.
I tried to reproduce this error but failed. Either it is a local problem on
your machine or it was already fixed. Could you please try again?
Fred
> Am 30.03.2018 um 00:53 schrieb Riccardo Mottola :
>
> Hi All,
>
> After updating GNUstep on OpenBSD/i386 with gcc, I
> Am 26.03.2018 um 10:35 schrieb Stjepan Brkić :
>
>>
>> welcome to the GNUstep mailing list. I am you possible co-mentor if you get
>> accepted to the GSoC. As the time to apply is already running out I don’t
>> want to convince you of any specific task just choose
1 - 100 of 1102 matches
Mail list logo