[email protected]

unread,

Jul 5, 2010, 3:27:34 AM7/5/10

to [email protected]

Status: New Owner: Labels: Type-Defect Priority-Medium

New issue 175 by doghead: ForkException with applesdk branch on ios 4.0 http://code.google.com/p/mobileterminal/issues/detail?id=175

What steps will reproduce the problem? 1. SDK 3.2.3, IOS 4.0 device (no jailbreak) 2. Working profile Iphone Developer 3. mobileterminal appleSDk branch (rev 442) 4. Project set to iphone device 4.0 and target to os 4.0

What is the expected output? What do you see instead? a terminal prompt ;-) ForkException stating "Not allowed to fork from inside Sandbox"

What version of the product are you using? On what operating system? OSX 10.6.3 / SDK 3.2.3 / IOS4.0

Please provide any additional information below.

[email protected]

unread,

Jul 5, 2010, 8:32:21 AM7/5/10

to [email protected]

[email protected]

unread,

Jun 4, 2012, 3:35:05 PM6/4/12

to [email protected]

Comment

2 on issue 175 by [email protected]: ForkException with applesdk

(No comment was entered for this change.)

Attachments: iTunesArtwork 23.1 KB

[email protected]

unread,

Jul 3, 2012, 8:22:19 AM7/3/12

to [email protected]

Comment

3 on issue 175 by [email protected]: ForkException with applesdk

So there is no way.. to implement the forkpty() to work on non-jailbroken ?? I need to implement a terminal interface, I dont even need to access any restricted data out of sandbox I just need a terminal interface for my binary to run.

[email protected]

unread,

Jul 3, 2012, 8:40:21 AM7/3/12

to [email protected]

Comment

4 on issue 175 by [email protected]: ForkException with applesdk

(No comment was entered for this change.)

Attachments:

MobclixSessionTracking-667FDE95-9742-44AF-86BF-4981AA838873.plist 497 bytes

[email protected]

unread,

Apr 9, 2013, 5:47:38 PM4/9/13

to [email protected]

Comment

5 on issue 175 by [email protected]: ForkException with

thanx for this information ...will please tell me which binary file i have to add to run mobile terminal on iPhone Devise

-- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

[email protected]

unread,

Apr 11, 2013, 5:01:50 PM4/11/13

to [email protected]

Meson will always reserve the right to throw a warning at any time, regardless of what it used to do, for things which it never intended to support and which is non-idiomatic and considered to be wrong.

For things which it did intend to support and which are considered okay, it also reserves the right to start throwing warnings, however those warnings will traditionally be deprecation warnings and only emitted when the minimum required version of meson is sufficiently high to allow migration to whatever the nominated replacement is.

Please do not use "a new warning was added about this usage and that's bad because warnings bad" as an argument. Argue on the merit of the usage itself.

"Warnings are bad" -- this is such a C++ standards committee thing to say, and the reason why other new-fangled languages have become become reasonably successful at stealing nontrivial market share is in no small part to the fact that they don't bind themselves to the notion that a *non-fatal warning is a critical regression that must be avoided at all costs and reverted with prejudice. It doesn't even matter how bad those other languages are, this C++ idea that warnings are the devil is making people abandon ship on those grounds alone.

If there's a valid reason for the usage, then Meson should not warn, even if it always warned from day 1.

If there isn't a valid reason for the usage, then Meson shall warn, and the fact that it learned to warn on invalid usage is a feature not a bug. It is not like it's an error and broke existing usage in the wild. We are unlikely to drop support for deprecated stuff any time soon (perhaps we will do so for Meson 1.0 whenever that occurs).

Aside: I was fairly sure subprojects did not allow directly poking inside them since day 1, in fact, so I would have thought this warning would occur since day 1 too.