Re: [MirageOS-devel] contributing best practices?

[Dave Scott <Dave.Scott@xxxxxxxxxx>]

> On Mar 26, 2014, at 9:02 AM, "Richard Mortier" 
> <Richard.Mortier@xxxxxxxxxxxxxxxx> wrote:
> 
> 
>> On 25 Mar 2014, at 22:49, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>> 
>> One quick trick that often helps in these sorts of situations is to wrap the 
>> offending code in a try/with and print the backtrace:
>> 
>> try
>> the_bad_code
>> with exn ->
>> Printf.printf "Exn: %s\n%!" (Printexc.to_string exn);
>> Printexc.print_backtrace stdout; 
>> raise exn
> 
> didn't i add something like this to the pre-refactoring mirage at some point? 
> did it get lost, or is it not possible to have now after all the refactoring? 
>  seems like dropping this to console before bailing out would be a useful 
> default behaviour...  should i add to the mirage cli tool maybe so that 
> main.ml is generated appropriately?
> 

Not sure about your change specifically, but my usual problem with a global 
try/with is that Lwt threads get in the way-- you end up with a boring stack 
with Lwt_main.run (ie the scheduler) on it and a frame for the current thunk 
you're running, without much clue as to how you got there. I'm not sure what 
the best fix for this would be -- possibly copying some ideas from core async?

Cheers,
Dave
> -- 
> Cheers,
> 
> R.
> 
> 
> 
> 
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel