apr-1-config broken under Mavericks

2 Replies

UPDATE October 23 2013 As commenters point out below, simply installing Xcode 5.0.1 and its Command Line Tools is enough. I’ve finally got around to testing out the suggestion provided to me almost two weeks ago, and it worked.

The content below is preserved for posterity. Please just install Command Line Tools and see if that helps.

Is perhaps brew install serf or brew install subversion broken for you on Mavericks? Or generally apr-1-config seems to return spurious results referring to nonexistent locations in /usr/include or to OSX10.9.xctoolchain?

While Apple does not recommend touching any system file or folder as they may and will be overwritten during OS upgrade, consider editing the following lines:

-prefix="/usr"
+prefix="/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr"
-CC="/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.9.xctoolchain/usr/bin/cc"
-CPP="/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.9.xctoolchain/usr/bin/cc -E"
+CC="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc"
+CPP="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -E"

Now that I have serf package installed, all I have left to figure out (or get someone else to figure out!) is subversion. Only then I might have some hope of getting hgsubversion to work again and getting some work done without resorting to Subversion directly.

Spurious nonresponsive XMPP resource "Messaging XXXXXXX" under Google Talk/Hangouts

2 Replies

This information is prepared based on my understanding of XMPP systems, on the fact that Hangouts is not XMPP, and on the threads I linked to. I’ve sorted out the user-originating speculation that seems most useful. Hopefully I’ve given enough search-friendly keywords so someone saves time I’ve lost figuring out what’s the culprit.

By looking at XMPP resources (a fancy name for ‘connection identifiers’) using the most awesome XMPP client out there, Psi, and then digging around old Google Groups posts from late April and May 2013, all the way across the summer, I’ve identified the culprit of why my Google Talk account was appearing as “Away”.

If there is a resource connected to your gmail.com account called something similar to “MessagingXXXXXXX”, that’s the ‘new’ Google Hangouts (the one that doesn’t play nicely with XMPP). And quite possibly it’s the Android application for Google Hangouts.

That was hard to figure out because, among other things, the Hangouts service refuses to talk to my external non-Google XMPP accounts. So I was completely flabbergasted that I did not get a response to handcrafted request — not even an error — when, retrospectively obviously, that was Hangouts discriminating against my federated XMPP server. Oh well.

So yes, Google Hangouts stays connected even if the device you’ve logged into from is not. Apparently this is a connection that’s created internally, inside Google, from their Hangouts service to their Talk service — from the new IM tech to the XMPP tech. And if you try to trick the XMPP service to sign out Hangouts (for example, by creating a new connection with identical XMPP resource), the Hangouts will happily log back into XMPP in your name and present you as ‘away’. And messages intended to be stored offline will end up in Hangouts, never to be seen again unless you use Hangouts on other systems.

In threads I linked to, users claim clearing and reinstalling Hangouts might mean getting a new static per-device XMPP identifier. Others claim that clearing data for various subsystems (Google Play Services, Google Hangouts, etc), revoking two-factor codes, OAuth tokens and single-application-passwords might help.

Aside from turning on the device and logging out, the solution seems to be: wait for 30 days until the connection times out. So, do NOT wipe a device clean unless you’re ready to wait for 30 days to be signed off in front of your friends. Do NOT give the device out before you explicitly sign out of Hangouts (don’t just ‘restore’ it and wipe it).

Or it may just be easier to log out.

Which is what I did: I turned on the laptop, I fired up the VirtualBox machine where AndroVM was installed, and I signed out. (Imagine that: accidentally firing up Hangouts, force-shutting down the VM and then spending several night-time hours scratching your head and feeling miserable in all sorts of ways because technology is disobeying again. Ah.)

Loss of GSOC 2013 card – International Students

Leave a reply

This information is useful for participants in GSOC 2013 program. In future years, there may be changes to the program. It’s also completely unofficial information based primarily on the experience I just had with CitiCard; I obviously can’t make any guarantees for your experience. Hopefully, you won’t have ‘an experience’ because you’ll withdraw all the money, you’ll use the cash, and — most importantly — you won’t lose your wallet.

  1. Prepare your first and last name, including how you’ll spell it the operator in case spelling is not ‘second nature’ to you
  2. Prepare Google’s address (especially the zip code): 1600 Amphitheatre Parkway, Mountain View, California, since that’s what the card was registered to
  3. Have the last four digits of the card’s number prepared; this is one signal CitiCard uses to verify your identity
  4. Be mindful of the balance on the card; that is one signal CitiCard uses to verify your identity
  5. Be mindful of where and when the card was last used; that is one signal CitiCard uses to verify your identity
  6. Call CitiCard Lost and Stolen Card Services at +18778557201. Calls using Skype to this number are free.
  7. Have them ship the card to Google’s address. MAKE SURE to request they add “ATTN: Carol Smith” to the address.
  8. Optionally, ask the operator to increase the ATM limit again. (Yes, the limit has been reset.)
  9. Email Carol Smith with subject: “REPLACEMENT CARD – ”. In the email, state your address and thank Carol for all her great work 🙂

Points 2, 7 and 9 are listed in the very useful document about student payment cards, which you should have read already. Go through it once again before calling.

You will be given the last four digits of the new card.

According to CitiCard, the new card should be shipped or delivered to Google’s address (it was hard to catch that part) within 7-10 working days. There’s also a charge for losing your card, as stated in the document about student payment cards.

Not all security signals are necessary; for example, I was only able to approximate the transaction history and confirm the last transaction. (I did not have any information about the card apart from what was on the card itself — what a bad idea.)

GSoC 2013: Final post

1 Reply

So, this year’s GSoC 2013 has reached the hard deadlAnd tine at 19:00 UTC (21:00 CEST).

And, I’ve managed to fix some critical bugs in the Opal-based backend of GNUstep. Huzzah!

What we now have is doublebuffering support, image support, font support, blitting from a ‘gstate’ to a ‘gstate’ (actually between their backing surfaces while taking their respective transform matrices into account). We also have an an assortment of ‘DPS’ methods.

Everything is made possible thanks to great work of Opal’s authors, especially Eric Wasylishen who helped by fixing some outstanding bugs in Opal as well as with some text rendering code in the Opal backend. He was also of extreme assistance by keeping me great company over XMPP during late hours full of frustration 🙂

Thanks also go to everyone who ever worked or contributed on GNUstep — particularly on gnustep-gui. Especially Fred Kiefer, my last year’s mentor, whose advice always proves invaluable; perhaps initially cryptic, but always invaluable.

Thanks also go to David Chisnall, my this year’s GSOC mentor who kindly welcomed everyone to Cambridge on this year’s GNUstep meeting, and tolerated my rare status reports. 🙂

Programs running under GNUstep theme under Opal backend: Ink, TextEdit, SystemPreferences.

Programs running under GNUstep theme under Opal backend: Ink, TextEdit, SystemPreferences.

Aside from the various delays caused by job interviews, summer camps and sicknesses (as well as my overall suckiness 🙂 — the most confusing thing to me was the concept of ‘gstate’. As it turns out, GNUstep loves to keep a lot of graphics state in a class derived from GSGState. It loves to be able to switch between gstates at will. It likes resetting matrix to the identity matrix whenever it wants. It likes setting custom matrices. It likes resetting the clipping path. In short — it loves to do many things that Core Graphics doesn’t want to let you do.

Which is why I got so confused when Fred Kiefer suggested that getting rid of GState may not be so easy. Core Graphics looked so logical to me and methods that gnustep-back implemented looked like they matched them so closely. Why are things in gnustep-back so complicated?

Turns out there is a good reason — switching and copying of gstates, which DPS permits and GNUstep uses in large amounts.

So in the end, I dumped the branch related to cutting out OpalGState out of my backend. Classes in the gsc/ folder implement enough logic for it to be worth keeping them as base classes for context, gstate, etc. And Eric was kind enough to implement a way to get GState out of Opal so I can save it in OpalGState class in the backend and apply to a context when appropriate. Whew.

Programs running under Gtk theme under Opal backend: Ink, TextEdit. In background: GNUstep theme SystemPreferences.

Programs running under Gtk theme under Opal backend: Ink, TextEdit. In background: GNUstep theme SystemPreferences.

Next thing that caused a lot of problems for me was doublebuffering support. First, I got stuck with incorrectly understanding the CGContextDrawImage() API. I thought it specified the source and painted at 0,0; it turned out it specified destination. And the source was specified by creating a duplicate image. (Well, not a duplicate; same image is still used, just a different cropping argument is set.)

So I used that, and failed horribly. As much as I tried to get it to work (many hours wasted shuffling the code around) — nothing. Turns out Opal, unfortunately, did NOT make use of the cropping specifier in the ‘subimage’. When that was fixed, getting doublebuffering to work was trivial.

Images were fun. During initial sprint, I got them to work — only if they were 32bit RGBA images. And only after a lot of tries. And when context’s -isDrawingOnScreen returns YES, images break. Turns out they are drawn into an offscreen context, and then blitted onscreen using -compositeGState:....

As I didn’t figure out how exactly an offscreen context is created, right now -isDrawingOnScreen returns NO. It’s a shameless lie, but until I get some time to debug what’s going wrong, it’ll stay this way. At least we get icons in System Preferences this way!

Programs running under Gtk theme under Opal backend: Ink, TextEdit, SystemPreferences.

Programs running under Gtk theme under Opal backend: Ink, TextEdit, SystemPreferences.

Final issue that I struggled for a week or two was -compositeGState:... (and its buddy -drawGState:...). Figuring out how it’s called and from where and why was messy, and the fact that it works at all by the deadline is a small miracle. How does one debug why an image is not being correctly painted into an offscreen context — for example, one for images? How does one figure out what offsets does -gui imagine I’m applying? Did I forget to apply device offset or did I forget to update CTM? Should I flip the passed .y coordinate? Is -compositeGState:... incorrectly sourcing the image from NSImage‘s backing OpalGState, or is -DPSimage:... incorrectly painting the image into that OpalGState‘s backing surface’s backing CGContext? Does the surface exist at all when -DPSimage... is painting into it? Does the surface have the backing CGContext set up? Did I correctly apply all properties to the -copyWithZone:‘d OpalGState? Maybe code is trying to call -drawGState:...? And the most important question of them all: why the heck does it not draw?!

So right now we have a mostly functional -compositeGState:... and committed. Why mostly? Well, some images don’t seem to be drawn. And as long as you scroll the NSScrollView by grabbing the scrollbar, you’ll get a correctly scrolled scrollview. (You can also try clicking on the last visible item and pressing the down arrow: it’ll work.)

Then try clicking on an arrow button of the scrollbar. Heh — turns out -gui is scrolling it in a different way. What way? I did not try figuring out yet (as I hit the deadline).

What else is verified to be missing or broken? The blinking cursor in textviews (e.g. in Ink and TextEdit). Round buttons. I have a tableview that I can’t doubleclick on without crashing the app. (Curiously, outlineview version of the same test app does not crash.) Sometimes, pen is not lifted in appropriate places — to see this, launch SystemPreferences and open the Themes panel. Popup buttons with selection that happen to have an ‘arrow’ on the right side — in SystemPreferences, open the Font panel and look on the left — will not be correctly painted when clicked on.

Aside from being generally unhappy with performance, I’m also especially unhappy with font performance; it does seem to be a sad result of doublebuffering (everything is an image, so X11 is unhappy with that).

I’m not looking forward to fixing what remains broken, but I’ll try. I’ll try. After all — we can’t have Core Animation integration without the Opal backend 🙂

All in all, this is certainly not ‘release’ quality — but it’s close to being actually usable. I’m somewhat pleased that the backend actually works, considering how many issues I had along the way, largest of which being myself and (again) not being fanatically devoted to GSOC, which is what Google intended the students to be 🙂

GSoC 2013: Text, images, delays

2 Replies
image by ericwa

image by ericwa; please observe ‘textedit’ info window and its preferences on the right side

Given the delay since the last update, this should be a lengthy post. Since I’m writing this at a very late hour, it won’t be.

Shortly after the last update, I added painting of images, as long as they’re 32-bit. I finally began considering the ‘gstateless’ variant of the backend, where the OpalGState class would be removed, as well as the dependence on GSContext family of classes. The idea was that all state switching could be managed by Opal. Unfortunately, Fred explained how AppKit treats GState and the idea does not map well to Core Graphics’s one-graphics-state-stack-per-context model.

Then I went to Dublin for a job interview. When I got back, I was (shall we put it mildly) highly distracted by the experience of another travel to a foreign country. After that, a two week summer camp where I almost no progress was done. A place with no good internet connectivity (except several cafe bars) would be tolerable were there a place for me to unpack my laptop as permanently as possible. Unfortunately, any such place was a computer classroom, and my accommodation was anything but appropriate for the activity. Other distractions of a summer camp also came in play, such as ‘Hey, come here, let’s work on the movie.’

Would coming back home change things? Well, after a massive headache due to low amount of sleep during the last day of camp and during the return trip, after a cold, and after a toothache, I finally got to work.

Thanks to a lot of help with Eric on the Opal side (and even a bit on the backend side, because he’s cool like that), we now have font rendering! Hooray!

Unfortunately, you may notice that the above images feature rectangles again, instead of icons. This time they’re yellow rectangles instead of red ones. Why? -compositeGState:... method is being called after -DPSimage:... was called, so we end up with a ‘not-implemented’ marker for -compositeGState:....

What’s next? Well, wrapping up as many things as possible by the end of the week, when GSOC ends.

Yep, I could and should have done far better this year. Oh well.

GSoC 2013: App content now visible!

Leave a reply

I completely agree with you, dear reader — I don’t like it either that it took so long to get somewhere useful. 🙂

But, here’s two screenshots that are right now making me happy. (Aside from lunch, that is.)

GSoC 2013: first useful screenshot of SystemPreferences

GSoC 2013: first useful screenshot of Calculator

Red boxes are images. On the top left of SystemPreferences you can see the menu. The white blob in SystemPreferences is where WindowMaker drew its HUD to display window position while moving the window around; doublebuffering is disabled at the moment.

Calculator uses NSWindows95InterfaceStyle, so the menus are embedded inside the window. (A necessity under XQuartz.)

So, how did I get here?

Doublebuffering

I had no idea where to start from fixing the issues. So I turned to trying to write the backing image into a file. That’s easy to do with Core Graphics; but, there happened to be a small bug with Opal. Eric stepped in once again, and fixed saving to files. I’m really thankful to him for doing this so quickly.

Now that I could output files, I saw that backing images for menus were correctly drawn. What went wrong was sending things to the screen. Menus generally worked. Hooray! That was a big confirmation that something small was going wrong. Images painted on screen were incorrectly positioned, and when running under XQuartz on OS X, even sized incorrectly. (XQuartz forces a minimum window width even for menu windows.)

At some point, I figured out, what the hell – let’s check what CGContextDrawImage() specification says. Lo and behold: the argument specifies only the destination rectangle, and does not relate to the parent rectangle! The solution is to use CGImageCreateFromImageWithRect(). I ran into a small Opal bug here, which I reported to Eric; the new image still includes the original image (just like the documentation says it should), but under Opal, this means CGImageGetWidth()/Height() report original image’s values. Also, writing such a sub-image still writes out the entire image to disk.

Unfortunately, I didn’t get this to work yet. I’m still getting weird offsets, but now I’m on the right track. Currently committed version has doublebuffering disabled (which means moving anything over the window clears that part of the surface and does not cause correct redraw).

Saving and restoring graphics state

So… -DPSgsave and -DPSgrestore. Although I was aware that this is the thing to look at in case things mess up with matrices, and I spent hours and hours looking around for what went wrong (very small amount of code, but a lot of exploration), it didn’t occur to me that I, perhaps, did not implement the methods.

Eric pointed it out to me that I didn’t.

I checked, and indeed: I was going around in circles just because I did not push state to the stack where appropriate.

So I implemented these methods under names -DPSsavegstate and -DPSrestoregstate. When it didn’t help, I looked around for ideas about what else may have went wrong.

Then today, having run out of ideas, I triplechecked what I did, and the method names were incorrect. With Eric, I only discussed that state needs to be saved; I have absolutely no idea where I pulled the method names out from or why I even though they were correct.

Then, as I went to check what the method names should be, I found they were named -DPSgsave and -DPSgrestore. And they are in, for example, CairoContext — not in CairoGState. Which is perfectly reasonable: GState classes are exactly what these methods manipulate, wrappers for state of backends whose underlying libraries do not contain a state stack, or need to maintain additional state.

So having overridden these methods, called super and then passed them on to OpalGState, I finally got something sensible on screen. Hooray!

Next: Cleanup and moving DPS methods to OpalContext

Eric has suggested moving (nearly) all methods from OpalGState to OpalContext. This definitely makes sense; if there’s some state that happens not to be maintained by Opal, it probably makes sense to add the required functionality to Opal and not to the backend.

I’ll also be cleaning up the implementation before moving on to adding fonts et al. There’s leaks all over the place because I (intentionally) did not pay enough attention while researching what the problems are.

Mid-term self-evaluation for this year’s GSoC is between July 29th and August 2nd. I’ll be submitting relatively low scores for myself; I’m personally unsatisfied with the time it took me to reach this stage. I’m hoping that the worst is behind me. On the other hand, I still have to deal with fonts. sigh