Saturday, March 23, 2013
obj-c on debian7: success
Actually, I did try to use latest gcc version on debian 7 to compile command-line obj-c program, which I previously wrote on OS X and which makes use of certain Objective C 2 features.
This worked, with a few caveats:
This worked, with a few caveats:
- You need to install gobjc++ and gnustep-devel packages (might be an overkill, but...)
- If you plan to use GNUstep (that's the best way to guarantee compatibility with Apple tool chain), keep in mind that you'll need a special makefile (traditionally named GNUmakefile). Here is manual, and here is a basic example:
include $(GNUSTEP_MAKEFILES)/common.make TOOL_NAME = rat rat_OBJC_FILES = Rational.m Expression.m main.m parser.m rat_HEADER_FILES = Rational.h Expression.h parse.h -include GNUmakefile.preamble include $(GNUSTEP_MAKEFILES)/tool.make -include GNUmakefile.postamble
- For some reason, debian 7 version of GNUstep is missing definitions of TRUE and FALSE (though BOOL is defined?) and NS_REQUIRES_NIL_TERMINATION (see this recent patch). Therefore, I added this to one of the header files:
#ifdef GNUSTEP #define FALSE 0 #define TRUE 1 #define NS_REQUIRES_NIL_TERMINATION __attribute__((sentinel)) #endif /* GNUSTEP */ - Also, these makefiles as described above require some environment variables; you can use
source /usr/share/GNUstep/Makefiles/GNUstep.sh
to set it up - There are some mysterious problems with version of libgnustep-base.so ; you'll need to somehow convince your linked executable to load system version, e.g.:
pushd ~/GNUstep/Library/Libraries
ln -s /usr/lib/libgnustep-base.so.1.22.1 libgnustep-base.so.1.24 - Also, be mindful of 32/64-bit differences (since OS X is 64-bit only)
Friday, March 22, 2013
Submitted WebKit bug :)
https://bugs.webkit.org/show_bug.cgi?format=multiple&id=113001
P.S. Here is my first and only Firefox bug report (classified as duplicate, fixed eventually)
Bug 113001
| Summary: | Some Hebrew diacritics get messed up on form submission | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Konstantin <ikn@hotmail.com> | ||||
| Component: | Forms | Assignee: | Nobody <webkit-unassigned@lists.webkit.org> | ||||
| Status: | UNCONFIRMED | ||||||
| Severity: | Normal | ||||||
| Priority: | P3 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| URL: | http://zapad.org/~ignatiev/temp/w4.php | ||||||
| Attachments: |
| ||||||
P.S. Here is my first and only Firefox bug report (classified as duplicate, fixed eventually)
Monday, March 04, 2013
@property support in gcc
It looks like from version 4.6 onward gcc supports (some?) Objective-C 2.0 language extensions, including, among other things, @property keyword.
In the meantime, latest Debian 6.0 squeeze only includes gcc 4.3 and 4.4. How long till Debian 7?
BTW, there is also a project to support GTK+ bindings for objective-c, but it does not seem to be actively supported.
In the meantime, latest Debian 6.0 squeeze only includes gcc 4.3 and 4.4. How long till Debian 7?
BTW, there is also a project to support GTK+ bindings for objective-c, but it does not seem to be actively supported.
When I submit any form which has a text field which contains Hebrew diacritics U+05BC ("dagesh") and U+05B6 ("segol"), in this order, they get submitted to the server in the *opposite* order: U+05B6, U+05BC . While Hebrew word seems "same" visually, this "fixed" order is invalid (or at least non-standard), and regardless, browser obviously shouldn't change data entered into the form on its own, under any circumstances. To demonstrate this issue, I wrote a simple PHP script (attached, and available online at http://zapad.org/~ignatiev/temp/w4.php), which allows user to fill a text field and then upon form submission to compare user input with what was actually submitted (via simple hash sum JavaScript implementation). You can play with it and see that it works fine for almost any text in any language you can enter. If, however, you use button "initialize", script will initialize the text field to the string '\u05d1\u05bc\u05b5' (bet-dagesh-segol), and upon form submission the comparison test will FAIL; value submitted will be '\u05d1\u05b5\u05bc' bet-segol-dagesh. This problem is reproducible in any WebKit-based browser I tried (Chrome Windows/Mac, Safari Mac/Windows/iPhone, Debian 6 "Web browser", also on the latest "nightly build", compiled from source on Linux/GTK), while it works fine in IE, Firefox, and (Presto-based) Opera.