|
I have a very high tolerance for ugliness of generated code, so I can live with that. Is there any real information on calling ObjC from C? I guess messages turn into calls to the objc_msgSend() family of functions, but it'd be nice to read about someone else who already took a jaunt through this minefield.
|
#
?
Feb 19, 2020 09:21
|
|
|
|
| # ? Jun 6, 2024 10:13 |
|
|
idgaf about graphic APIs, but I would kill for a good CI option for OS X. Or I can just keep on not supporting it I guess 
|
|
#
?
Feb 19, 2020 10:34
|
|
|
Xarn posted:idgaf about graphic APIs, but I would kill for a good CI option for OS X. appveyor is about the best you're going to do for something that isn't self hosted
|
|
#
?
Feb 19, 2020 14:13
|
|
|
Athas posted:I have a very high tolerance for ugliness of generated code, so I can live with that. Is there any real information on calling ObjC from C? I guess messages turn into calls to the objc_msgSend() family of functions, but it'd be nice to read about someone else who already took a jaunt through this minefield. the associated c function type of an objc method “- (Result) foo: (Params...)” is “Result (*)(id, SEL, Params...)”. you cast objc_msgSend to that type and call it (yes, really), like “value = ((int (*)(id, SEL)) objc_msgSend)(receiver, selector);”. the selector is loaded from a global variable in a special section that’s initialized to a string literal. since you’re doing this in c, you can use any old pointer type for id and SEL. if you need to call a method that would return a struct result indirectly, you may have to call msgSend_stret, depending on the target. the other msgSend functions can be ignored if you don’t care about messaging nil, which you probably don’t. if you need to call a class method, you get the class pointer by loading from a global variable in a different special section initialized to the class symbol, kindof like the selectors. if you can read llvm ir, just compile some objc code to see the pattern the only subtle trick here is to put __attribute__((used)) on the global variables to stop the optimizer from thinking it can optimize loads from them
|
|
#
?
Feb 19, 2020 15:16
|
|
|
I know nothing about Objective-C. What makes this sendMsg thunk necessary, instead of name mangling for non virtual dispatch, and vtables for virtual?
|
|
#
?
Feb 19, 2020 17:19
|
|
|
it’s actually dynamic, so you can’t just directly link, and various goals make v-tables undesirable as an implementation mechanism
|
|
#
?
Feb 19, 2020 18:57
|
|
|
Suspicious Dish posted:I know nothing about Objective-C. What makes this sendMsg thunk necessary, instead of name mangling for non virtual dispatch, and vtables for virtual? you can create classes at runtime, add new methods to existing classes at runtime, have classes which respond to every selector (including ones which they don't know about at compile time) to implement things like proxies, etc. obj-c is smalltalk + c, so the OO part of it is much closer to ruby than c++
|
|
#
?
Feb 19, 2020 20:48
|
|
|
does anything actually use that stuff or is it mostly just a fun curiosity
|
|
#
?
Feb 19, 2020 21:16
|
|
|
that stuff is heavily used by the frameworks and anyone implementing things in the same style
|
|
#
?
Feb 19, 2020 21:18
|
|
|
welcome to obj-c com you can instantiate anything at obj-c com anything at all! hahahaha the only limit is your
|
|
#
?
Feb 19, 2020 21:24
|
|
|
even if you didn't have all the objc dynamism, v-tables perform really badly when there are near-universal root classes with hundreds of methods (usually added by class extensions), since that prefix has to be added to every v-table in the system. they also suffer a lot when you want to maintain a stable ABI and so aren't willing to just hard-code v-table offsets in every call site, since you have to assemble v-tables and load offsets dynamically swift primarily uses v-tables for its native class and protocol dispatch but mitigates these problems by (1) not using a (user-visible) root class, (2) not using v-table dispatch for class extension methods, and (3) actually knowing when something is your code vs. code that you need to allow to change
|
|
#
?
Feb 19, 2020 21:27
|
|
|
we’ve had protocols forever (since like 1991 or so) but had to add @optional in order to actually use them in the APIs instead of just id for example, it used to be that data sources and delegates were just described in our headers via categories-without-implementations on NSObject, as a way of informing you what methods you could implement in them which meant code completion for anything descended from NSObject would show allllll those methods, even though none of them had implementations in NSObject, and there was no enforcement of conformance at declaration or call sites of course now Swift comes along with protocols that don’t have optional methods… unless they’re imported from ObjC of course
|
|
#
?
Feb 19, 2020 21:28
|
|
|
Suspicious Dish posted:I know nothing about Objective-C. What makes this sendMsg thunk necessary, instead of name mangling for non virtual dispatch, and vtables for virtual?
|
|
#
?
Feb 19, 2020 21:32
|
|
|
Gazpacho posted:just fyi, there is no longer any reason to know anything about objc except if you want to call into the Metal API, as we were discussing
|
|
#
?
Feb 19, 2020 22:20
|
|
|
Gazpacho posted:just fyi, there is no longer any reason to know anything about objc looks like somebody forgot about gnustep
|
|
#
?
Feb 19, 2020 22:24
|
|
|
Lutha Mahtin posted:looks like somebody forgot about gnustep someone in tyool 2020 is actually writing a new NeXT-like window manager in objective-c called nextspace 
|
|
#
?
Feb 20, 2020 01:04
|
|
|
im the 1920x994 monitor
|
|
#
?
Feb 20, 2020 02:05
|
|
|
The_Franz posted:someone in tyool 2020 is actually writing a new NeXT-like window manager in objective-c called nextspace doesn’t this happen like every year?
|
|
#
?
Feb 20, 2020 02:12
|
|
|
2020 is the year of next on the desktop
|
|
#
?
Feb 20, 2020 02:33
|
|
|
NeXT stop the DeSK top
|
|
#
?
Feb 20, 2020 02:45
|
|
|
it's always next year somewhere
|
|
#
?
Feb 20, 2020 04:22
|
|
|
pokeyman posted:it's always next year somewhere
|
|
#
?
Feb 20, 2020 13:24
|
|
|
aw yeah, time to party like it's 1995
|
|
#
?
Feb 20, 2020 21:52
|
|
|
Lutha Mahtin posted:looks like somebody forgot about gnustep
|
|
#
?
Feb 21, 2020 02:09
|
|
|
some self-ownage going on in https://blog.golang.org/a-new-go-api-for-protocol-buffersquote:We also observed that a frequent source of problems was that the proto.Message interface, which identifies values of generated message types, does very little to describe the behavior of those types. When users create types that implement that interface (often inadvertently by embedding a message in another struct) and pass values of those types to functions expecting a generated message value, programs crash or behave unpredictably. quote:opts := fd.Options().(*descriptorpb.FieldOptions) quote:google.golang.org/protobuf@v1.20.0 is APIv2. This module depends upon github.com/golang/protobuf@v1.4.0, so any program which uses APIv2 will automatically pick a version of APIv1 which integrates with it. so they release a backwards incompatible v2 version but they don't want to bump the major version and put v2 in the url like the broken "you don't need version pinning if your none of your dependencies ever make breaking changes" go import system requires so they make it v1.20.0 for "clarity"
|
|
#
?
Mar 3, 2020 00:27
|
|
|
suffix posted:some self-ownage going on in https://blog.golang.org/a-new-go-api-for-protocol-buffers This is dumb but semantic versioning aside you buried the lede that v1 will be exclusively hosted at github.com/golang/protobuf and v2 at google.golang.org/protobuf
|
|
#
?
Mar 3, 2020 01:18
|
|
|
It is true that if nobody ever makes breaking changes its fine to always depend on HEAD. and when you think about it, isn't breaking stuff always bad?
|
|
#
?
Mar 3, 2020 02:21
|
|
|
you might even say that the first version of anything is the best because any change will introduce bugs
|
|
#
?
Mar 3, 2020 06:10
|
|
|
maybe just dont make bugs then??
|
|
#
?
Mar 3, 2020 08:52
|
|
|
Zlodo posted:maybe just dont make bugs then?? sound advice there
|
|
#
?
Mar 3, 2020 09:17
|
|
|
Nomnom Cookie posted:It is true that if nobody ever makes breaking changes its fine to always depend on HEAD. and when you think about it, isn't breaking stuff always bad? 
|
|
#
?
Mar 3, 2020 12:43
|
|
|
eschaton posted:you might even say that the first version of anything is the best because any change will introduce bugs I find in fact that my best code is that which I haven’t yet written, but that may not be a universal experience.
|
|
#
?
Mar 3, 2020 12:51
|
|
|
*thinks about a piece of unwritten code* "wow it's beautiful" *writes it* "aw man not again"
|
|
#
?
Mar 3, 2020 15:35
|
|
|
CPColin posted:*thinks about a piece of unwritten code* "wow it's beautiful"
|
|
#
?
Mar 3, 2020 15:55
|
|
|
e: gently caress double
|
|
#
?
Mar 3, 2020 15:56
|
|
|
all code is equally trash, some is more equal than others
|
|
#
?
Mar 3, 2020 17:57
|
|
|
CPColin posted:*thinks about a piece of unwritten code* "wow it's beautiful"
|
|
#
?
Mar 3, 2020 18:26
|
|
|
CPColin posted:*thinks about a piece of unwritten code* "wow it's beautiful" it’s like an autobiography right here
|
|
#
?
Mar 3, 2020 20:11
|
|
|
Subjunctive posted:it’s like an autobiography right here next time though
|
|
#
?
Mar 3, 2020 20:14
|
|
|
|
| # ? Jun 6, 2024 10:13 |
|
|
gonadic io posted:next time though law of large numbers says that I’m going to produce something at least mediocre any time now right?
|
|
#
?
Mar 3, 2020 20:17
|
|