Re: State of the WebKit port
On 20 Jun 2017, at 04:39, Daniel Ferreira (theiostream) wrote: > At this point, I chose to disable the remote inspector WebKit > feature[1], since it relied on XPC and Darwin's notify functions for > IPC. While these two libraries could eventually be implemented in a > cross-platform manner, they currently rely on the Mach kernel's > messaging model, so getting it to run on Linux would be too much of a > hurdle for now. FYI: We’re currently working with Apple to try to get XPC open sourced for some work-related stuff that we’re doing in collaboration with them. I’ll let you know if we make any progress. > After this was done, the only issue that stopped WTF from working > seamlessly was the lack of some CoreBase functions: > CFLocaleCopyPreferredLanguages(); the CFPreferences* suite. (The > latter will become a bigger problem when it comes to WebCore, but > we'll get there.); and CFBridgingRetain/CFBridgingRelease, which is > already the subject of a thread here which hasn't yet been concluded. I think both of these can be implemented on top of user defaults (though it would be nice to use the DBus locale selection stuff). > Moving on, I started building JavaScriptCore. Building was done rather > simply after some header adjustments in libobjc2, Base and CoreBase. I > moved on to running the JSC tests, and as they failed I started fixing > some bugs in GNUstep. > > … > > The next issue was a little more complex. JSC's bridge with > Objective-C relies on a private extension Apple made to the > Objective-C ABI which is only integrated with its ObjC runtime. An > issue briefly documenting the matter was opened in libobjc2[3], and > changes will need to be done to both clang and libobjc2. At this > point, I chose to move on from the failing JSC tests and start > building WebCore. I’ll try to take a look at these. If nothing else, having JSC integration with GNUstep would be a great outcome for this project. Apple added JSC as an OSAScript back end a couple of years back and this would make it possible for GNUstep to implement the Foundation classes that are used by scripting *and* have them actually be useful. I considered porting DukTape for this purpose a while ago. The JavaScript to Objective-C bridge is also quite well designed and is usable for application development on macOS - it would be great to be able to advertise that you can write GNUstep apps with JavaScript as well as ObjC (JavaScript is pretty good for rapid prototyping, as well as being a lot more widely known than Objective-C). David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Newbie back again...
On 19 Jun 2017, at 23:43, Josh Freeman wrote: > > The segmentation fault happens after Base sets the value of an NSThread > ivar, because the memory location it writes to overlaps the area in memory > where GUI expects to find a different ivar, due to the mismatched layouts; > When GUI reads its ivar, it finds a nonzero value (garbage), and when the > garbage value is sent an objc message, it crashes. This sounds like a compiler bug. The ivar accesses should both be using the same offset variable. Are you sure that both are being compiled with the same ABI? If so, would it be possible for you to compile the relevant -gui file and NSThread.m with -S (produce assembly, don’t compile) and send me the resulting output? David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: State of the WebKit port
On Tue, Jun 20, 2017 at 4:40 AM Daniel Ferreira (theiostream) wrote: > > > WTF (the Web Template Framework) is a series of helpers for WebKit > which involves things as diverse as crypto, threading, text encoding, > low-level memory analysis and inter-process communication. Most work > here involved isolating (through preprocessor guards) code that had > been marked in WebKit as Cocoa-specific, but that was in fact > Darwin-specific — which will eventually constitute a patch to WebKit’s > upstream. This Darwin-specific code was seamlessly replaced with its > already-existing Linux-specific counterparts, and how to fit that into > WebKit is not the matter of this thread. Could you push some *preliminary* patches somewhere public? > > > It is as follows: > > 1) New Frameworks (mostly Carbon stuff that has not yet been deprecated) > * CoreServices: implement TEC* converters (from CarbonCore.framework) > * CoreServices: implement HITheme, HIEvents UI functions > * CoreServices: implement CarbonEvents for the keyboard (from > HIToolbox.framework) Having to do anything Carbon related is frustrating. Ugh. I hope you can minimize the need to implement Carbon stuff. I'd be happy if we had stubs that returned noops, especially related to HIEvents. Let's not dwell on having functioning input for your GSoC project. I found something about HITheme (for purposes of the project, I'd be happy if we started off with drawing a rectangle in place of a widget, and then figure out how to provide a correct implementation later), but can you share what HIEvents is? > > * ApplicationServices: implement UniversalAccess.framework > * ApplicationServices: define kAX* accessibility constants (from > HIServices.framework) > * ColorSync: define ColorSync types (no actual implementation is needed) > * Security.framework: implement Certificate Verification functions > > 2) Base (mostly new APIs introduced after OSX 10.4) > * base: considerable adjustments to NSURL > * +[NSURL fileURLWithPath:isDirectory:] (OSX 10.5, with some 10.6+ > auxiliaries) > * +[NSURL URLByResolvingAliasFileAtURL:options:error:] (OSX 10.10) > * -[NSURL getResourceValue:forKey:error:] (OSX 10.6) > * NSURL.fileURL > * NSURLBookmarkResolutionOptions enum > * base: minor changes to NSFileManager > * -[NSFileManager attributesOfFileSystemForPath:error:] (OSX 10.5) > * implement NSFileManagerDelegate (OSX 10.5) > * base: minor changes to NSProcessInfo > * -[NSProcessInfo disableSuddenTermination]; -[NSProcessInfo > enableSuddenTermination] (OSX 10.6) > * -[NSProcessInfo beginActivityWithOptions:reason:]; -[NSProcessInfo > endActivity:], NSActivityOptions enum (OSX 10.9) > * -[NSProcessInfo systemUptime] > * base: implement NSURLCredentialPersistenceSynchronizable > * base: implement new NSURLProtectionSpace authentication methods > * NSURLAuthenticationMethodNTLM > * NSURLAuthenticationMethodNegotiate > * NSURLAuthenticationMethodClientCertificate > * NSURLAuthenticationMethodServerTrust > * -[NSURLProtectionSpace distinguishedNames] > * base: implement new NSURLRequest cache policies > * base: major changes to NSURLConnection > * declare NSURLConnectionDelegate as a protocol > * -[NSURLConnection currentRequest] (OSX 10.8) > * -[NSURLConnection scheduleInRunLoop:forMode:] + unschedule (OSX 10.5) > * -[NSURLConnection start] (OSX 10.5) > * -[NSURLConnection setDelegateQueue:] (OSX 10.7) > * NSURLAuthenticationChallengeSender corrections > * base: update NSCoder to new APIs > * -[NSCoder decodeObjectOfClass:forKey:] (OSX 10.8) > * NSSecureCoding protocol and method (-[NSCoder requiresSecureCoding]) > * base: NSDate: NSSystemClockDidChangeNotification > * base: create NSMakeCollectable() as wrapper around CFMakeCollectable() > * base: create NSURLSession class > * base: create NSFileCoordinator, NSFilePresenter classes > * base: add NSFileWriteFileExistsError = 516 to FoundationErrors > * base: NSGeometry: create NSEdgeInsets, NSEdgeInsetsZero > * base: add new NSHTTPCookie properties > * NSHTTPCookie.HTTPOnly > * NSHTTPCookie.secure > * NSHTTPCookie.sessionOnly > * base: NSCalendar: NSCalendarUnitSecond etc. new enum values > * base: NSCalendar: NSCalendarIdentifier* enum Ouch. At least a lot of the stuff seems enums. That seems to be a low hanging fruit. No other comments. > > 3) CoreBase > * corebase: implement CFNotificationCenter functions > * corebase: implement CFStringTokenizer functions > * corebase: implement CFPreferences functions > * corebase/base: implement -[NSRunLoop getCFRunLoop] > > 4) CoreNetwork > For CoreNetwork we need to implement some further socket functions, > CFHTTPMessage and proxy support. However, I wonder why CoreNetwork was > started given CFNetwork's state. Is there any reason why we should > push for CN rather than just use CFNetwork? If we can actually use CFNetwork, we can use CFNetwork and evaluate the results afterwards. Lubos might need CoreNetwork as-is for Darling (+cc for
Re: State of the WebKit port
> Am 20.06.2017 um 12:56 schrieb Ivan Vučica : > >> * opalgraphics/gui: create interaction between NSColor and CGColor >> * opalgraphics/gui: create interaction between NSImage and CGImage > > > Since Opal does not currently depend on AppKit, these conversions > between NS/CG should be carefully done in an additional compat > library. > > Also, I think it's totally reasonable for your port to depend on the > 'opal' backend in gnustep-back. Sounds like we should just put the implementation of these in the opal part of gnustep-back. We will need the declarations in the guidelines headers of course. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: State of the WebKit port
On Tue, Jun 20, 2017 at 5:17 PM, Fred Kiefer wrote: > Sounds like we should just put the implementation of these in the opal part > of gnustep-back. We will need the declarations in the guidelines headers of > course. Presumably you meant 'gui', not 'guidelines' and you got autocorrected? Doesn't feel totally right, but I guess we can have 'unimplemented' stub in -gui, and only implement in -back. It does mean we have to somehow define CGColorRef and CGImageRef (presumably @class + typedef), and ensure we keep opal, gui and back in sync if that ever changes. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: State of the WebKit port
> Am 20.06.2017 um 18:22 schrieb Ivan Vučica : > > On Tue, Jun 20, 2017 at 5:17 PM, Fred Kiefer wrote: >> Sounds like we should just put the implementation of these in the opal part >> of gnustep-back. We will need the declarations in the guidelines headers of >> course. > > Presumably you meant 'gui', not 'guidelines' and you got autocorrected? Yep. > Doesn't feel totally right, but I guess we can have 'unimplemented' > stub in -gui, and only implement in -back. Yes it feels like a hack, but better than having a separate library just for that. > It does mean we have to somehow define CGColorRef and CGImageRef > (presumably @class + typedef), and ensure we keep opal, gui and back > in sync if that ever changes. No, we already have CGColorRef and CGImageRef in opal and if we don’t support toll free conversions we can just convert the AppKit object into the opal version by calling CGColorCreate and the like. We always have to keep gui and back in sync and the same is true for back and opal. So we loose nothing here. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: State of the WebKit port
I meant keeping in sync the fact that CGColorRef is a @class CGColor. I did not mean that we teach -gui (and I mean -gui, not -back) what @interface CGColor looks like :] To my knowledge, CGColor is not toll-free bridgable with NSColor. On Tue, Jun 20, 2017, 17:34 Fred Kiefer wrote: > > > Am 20.06.2017 um 18:22 schrieb Ivan Vučica : > > > > On Tue, Jun 20, 2017 at 5:17 PM, Fred Kiefer wrote: > >> Sounds like we should just put the implementation of these in the opal > part of gnustep-back. We will need the declarations in the guidelines > headers of course. > > > > Presumably you meant 'gui', not 'guidelines' and you got autocorrected? > > Yep. > > > Doesn't feel totally right, but I guess we can have 'unimplemented' > > stub in -gui, and only implement in -back. > > Yes it feels like a hack, but better than having a separate library just > for that. > > > It does mean we have to somehow define CGColorRef and CGImageRef > > (presumably @class + typedef), and ensure we keep opal, gui and back > > in sync if that ever changes. > > No, we already have CGColorRef and CGImageRef in opal and if we don’t > support toll free conversions we can just convert the AppKit object into > the opal version by calling CGColorCreate and the like. > We always have to keep gui and back in sync and the same is true for back > and opal. So we loose nothing here. > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Migration to Git
If you wish not to interact with Github through the web, you can use wget or curl to download the JSON descriptor of all our repos. You can use jq to process it further and get just the URLs to clone: for i in $(seq 1 3) ; do curl https://api.github.com/orgs/gnustep/repos?page=$i | jq -r .[].clone_url done (If you examine the JSON, you will notice there's also ssh_url and svn_url depending on what you need.) If you wish to avoid interacting with Google Groups through web UI, you can subscribe by sending an email to gnustep-commits+subscr...@googlegroups.com. You will receive an email requesting you to confirm your subscription. In its contents, it says that you can just reply to the email to subscribe. Do so (preserving subject). You should soon receive a confirmation of your subscription. This should limit your exposure to non-free software, in case this is important to you. Move to gnu.org-hosted mailing list has not happened yet, and there has not yet been work on moving primary hosting to self-hosted Gogs or Gitlab instance (or something else, should we discover something particularly compelling). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Migration to Git
I’d certainly be willing to help move to a self hosted GitLab instance if that’s the direction we want to go. > On Jun 20, 2017, at 15:49, Ivan Vučica wrote: > > Move to gnu.org-hosted mailing list has not happened yet, and there > has not yet been work on moving primary hosting to self-hosted Gogs or > Gitlab instance (or something else, should we discover something > particularly compelling). > > ___ > Discuss-gnustep mailing list > discuss-gnus...@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
History rewrite for corebase and gui
Hi, https://github.com/gnustep/gitsvn-scripts/issues/2 """ I've mistakenly created merges which work okay with local clients, but confuse Github and other web UIs which don't recognize replace refs. - gnustep/libs-gui@250d3ee0af7f2fc304ab735ada8b3238154d060f - gnustep/libs-gui@44dd9abab7db1aa3e0d41f2b7da55c788f795c8f - gnustep/libs-corebase@4d4fa0a5a38ff6fa4b529216d3cc3859765d9cbf This will require rewriting history, but it's better in the long run. """ I've just pushed rewritten libs-corebase (where I cherrypicked the contributions instead). I'm about to do the same for libs-gui. You *will* need to cherrypick (or rebase, though I have less faith that this will work) if you have changes locally. I suggest cherrypick. Exact procedure for how to do this is unfortunately out of scope for this mail, but basically this should work: git log # and note commit hashes for each of your changes git checkout origin/master git cherry-pick CHANGE1 git cherry-pick CHANGE2 # etc git log # and note commit hash of the new head echo "your-new-commit-hash-here" > .git/refs/heads/master # I don't know how else to change what the 'master' local branch points to, and this works for me. Thankfully you should be prevented from pushing if you don't do this correctly. You can also store your unsubmitted patches for safekeeping by using git format-patch correctly. Since I haven't used this much, how to do this correctly is also out of scope and can be found online. Sorry about this, but I messed up pretty badly doing these merges, so we ended up with doubled history in any client that doesn't recognize / doesn't have replace refs downloaded. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Migration to Git
Thanks for the offer -- it's appreciated. At this time no help is required, just time. On Tue, Jun 20, 2017 at 9:04 PM, Matt Butch wrote: > I’d certainly be willing to help move to a self hosted GitLab instance if > that’s the direction we want to go. > >> On Jun 20, 2017, at 15:49, Ivan Vučica wrote: >> >> Move to gnu.org-hosted mailing list has not happened yet, and there >> has not yet been work on moving primary hosting to self-hosted Gogs or >> Gitlab instance (or something else, should we discover something >> particularly compelling). >> >> ___ >> Discuss-gnustep mailing list >> discuss-gnus...@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnustep > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: History rewrite for corebase and gui
This is now complete. On Tue, Jun 20, 2017 at 9:10 PM, Ivan Vučica wrote: > Hi, > > https://github.com/gnustep/gitsvn-scripts/issues/2 > > """ > I've mistakenly created merges which work okay with local clients, but > confuse Github and other web UIs which don't recognize replace refs. > > - gnustep/libs-gui@250d3ee0af7f2fc304ab735ada8b3238154d060f > - gnustep/libs-gui@44dd9abab7db1aa3e0d41f2b7da55c788f795c8f > - gnustep/libs-corebase@4d4fa0a5a38ff6fa4b529216d3cc3859765d9cbf > > This will require rewriting history, but it's better in the long run. > """ > > I've just pushed rewritten libs-corebase (where I cherrypicked the > contributions instead). > > I'm about to do the same for libs-gui. > > You *will* need to cherrypick (or rebase, though I have less faith > that this will work) if you have changes locally. I suggest > cherrypick. Exact procedure for how to do this is unfortunately out of > scope for this mail, but basically this should work: > > git log # and note commit hashes for each of your changes > git checkout origin/master > git cherry-pick CHANGE1 > git cherry-pick CHANGE2 > # etc > git log # and note commit hash of the new head > echo "your-new-commit-hash-here" > .git/refs/heads/master # I don't > know how else to change what the 'master' local branch points to, and > this works for me. > > Thankfully you should be prevented from pushing if you don't do this > correctly. > > You can also store your unsubmitted patches for safekeeping by using > git format-patch correctly. Since I haven't used this much, how to do > this correctly is also out of scope and can be found online. > > Sorry about this, but I messed up pretty badly doing these merges, so > we ended up with doubled history in any client that doesn't recognize > / doesn't have replace refs downloaded. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
