Need Help

[Waqas Toor]

Hello All,
Thanks,

I found 2 things reading this thread, let me explain what I did,
a) my activity directory was writable by world, why i did this was
becuase i was creating a config file and didnt know the user which
initiates my activity
b) the scripts which were executeable i.e. my Activity main script,
was only readable but still works ( can some one elaborate that for
me? i am a bit confused that how its readable but still executed )

1 thing more, when my activity is running, going to home view shows 2
icons, 1 is the activity icon that i created, 2nd is the black circle
in the right that is associated with my activity. can some body give
me a hint that where i am wrong ?
as i am using glade with gtk

Regards
-- 
Waqas Toor
member of OLPC Pakistan Team


On 3/5/08, Benjamin M. Schwartz <bmschwar at fas.harvard.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Stone wrote:
> | On Tue, Mar 04, 2008 at 08:22:31PM -0500, Benjamin M. Schwartz wrote:
> |> Michael Stone wrote:
> |> | My central error-handling goal has been to compactly express my
> |> | assumptions in a form that will prevent them from being violated in
> |> | ignorance. Should I have different goals?
> |>
> |> 1. I find Rainbow very impressive, and I am sure you are well aware of the
> |> various arguments made regarding error handling.
> |
> | Thank you. While it's true that I'm aware of some arguments regarding error
> | handling, I'm always interested in improving. It seems like one of the
> | most regularly failed challenges in the craft of programming.
> |
> |> In my view, restricting assertions to internal invariants provides an
> |> easy way of distinguishing problems in Rainbow from problems in
> |> Activities and other parts of the system.
> |
> | True, but the convention that I have established of separating error
> | messages into contract-violations and 'everything else', recorded in
> | per-activity logs and in a daemon-wide log (/var/log/rainbow) would seem
> | to accomplish similar goals.
>
> I have not read the relevant Rainbow source, so I cannot comment very
> intelligently on this.  However, if Rainbow wishes to log a contract
> violation, it should insert the phrase "contract violation" into the
> logfile.  Otherwise, how is a person reading the log to know this?
>
> |> 2. Among your goals, you might consider maximizing the ability of novice
> |> programmers to figure out what they've done wrong.
> |
> | It's not my primary goal, but I'll agree that it's worth considering.
> |
> |> The wiki page on translation even goes so far as to
> |> recommend using gettext for error strings, so that users and
> |> administrators may debug the system without knowing English.
>
> I used the phrase "debug the system".  That was a poor choice.  I should
> say "recognize bugs in the system", and additionally "distinguish between
> bugs in the system and bugs in the activities they're developing".
>
> |
> | I'm still not convinced. Wouldn't we be better served by translating the
> | source code itself, or an overview of the source code like my 'Taste the
> | Rainbow' pages?
> |
> | Consider: in my experience, debugging consists of searching the diff
> | between one's mental model and reality from which it follows that the
> | material which should be translated is the material which provides the
> | clearest, most accurate mental model of the problem.
>
> Your experience is extremely unusual and non-representative.  You are an
> expert computer scientist who frequently reads source code written by
> others.  You are familiar with the OLPC operating system details,
> including D-Bus and the Bitfrost requirements, perhaps moreso than anyone
> else in the world.
>
> The people who will be reading these logfiles will be developers who are
> trying to debug their activities.  The activity may have crashed because
> it attempted to violate a Bitfrost rule and was killed by Rainbow.  These
> developers (ideally mostly children) will likely be building their
> activities by making small modifications to existing activities.  That
> means most won't even understand their own code.  How could you possibly
> expect them to understand yours?
>
> | Also consider: had there been an actual bug in Rainbow, which would have
> | been more useful to Waqas in diagnosing and fixing the problem:
> | translated error messages or better written or documented source code?
>
> Not fixing.  It is absurd to imagine that any appreciable number of users
> will be able fix Rainbow bugs.  Rather, when Rainbow experiences an
> internal error, it should be extremely obvious that the problem is with
> Rainbow.  For example, an excellent type of behavior would be for Rainbow
> to print, in the logfile:
>
> RAINBOW BUG: Rainbow has encountered an internal error.  This indicates a
> bug in Rainbow.  The error code is 752.
>
> This line would be sufficient for activity developers to understand that
> the problem is not simply in their code. It also makes it possible for
> users to participate usefully in the development process, by reporting the
> bug in an unambiguous way.  Error codes are also important because they
> allow users to identify problems even when e-mailing logfiles is
> impossible due to software bugs or lack of connectivity.  This error line
> is also nice because it only needs to be translated once, with the error
> code number substituted programmatically.
>
> This output could be improved further by adding an additional sentence,
> such as:
>
> This error code indicates that Rainbow's directory permissions have
> reached an inconsistent state.
>
> This line, like a BSOD, serves mainly to make users feel like the system's
> designers want them to know what's going on in case of a failure.
> However, the implementation overhead is undeniably high, especially given
> the need for many translations.  On the plus side, these strings also
> serve as documentation when reading the source code.
>
> |
> | Put another way, doesn't this kind of error message uselessly duplicate
> | information that is best recorded in the failing assertion itself (and
> | in the name of the function containing it, in this case,
> |
> |   check_cwd(... [cwd=]/home/olpc/Activities/Qirat.activity)
> |       assert ck.negative(W_OK, 0)
> |
> | ?
>
> I have no idea what any of those names mean, despite having looked at the
> source.  I can now guess that "cwd" means "current working directory" and
> "ck" means "check", but I still have no idea what the code actually does.
> ~ Reading code is hard, and you should never expect anyone to do it unless
> they are planning on modifying that code.
>
> |
> |> 3.  Did this assertion failure result in the termination of the Rainbow
> |> daemon?
> |
> | The present implementation calls clone() before executing any
> | activity-launching code. Termination of the child by failure to handle
> | the AssertionError is a design goal.
> |
> |> Raising exceptions for input errors has the distinct
> |> advantage of allowing one to catch exceptions thrown further down the call
> |> stack, instead of exiting.  Note that when I say "specific exceptions", it
> |> would be perfectly reasonable to wrap up all errors due to permissions in
> |> a PermissionsException, etc.
> |
> | First, what can I reasonably expect to accomplish by catching such an
> | exception?
>
> You can print a sensible error message, such as "The current activity
> (Qirat) could not be launched because the permissions on its bundle
> directory are insecure."
>
> | Second, given that the exception is being raised in a child
> | process that may have been compromised by malicious data, I'm not
> | terribly interested in informing the main daemon to the particulars of
> | the failure; the log file is quite sufficient for my purposes.
>
> I agree; there is no need to send information up to the main daemon.  I
> think specialized exceptions make it easier to achieve informative logfiles.
>
> - --Ben
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHzhlqUJT6e6HFtqQRAk4pAJ9xab+6sXvc6RSOqBLFkalBo4UFtgCff5B6
> HJg89MaTolZ9rPryVhyzOAU=
> =DGoW
> -----END PGP SIGNATURE-----
>