On 09/27/11 at 09:12pm, Jordan Wilberding wrote: > On Tue, Sep 27, 2011 at 9:03 PM, Eric Merritt <[email protected]>wrote: > > > On 09/27/11 at 08:38pm, Jordan Wilberding wrote: > > > On Tue, Sep 27, 2011 at 10:02 AM, Eric Merritt <[email protected] > > >wrote: > > > > > > > On 09/26/11 at 11:00pm, Jordan Wilberding wrote: > > > > > Sure man. I left it in a bit of a mess, so let me regroup and see > > exactly > > > > > what is left on the code. > > > > > > > > > > > > > No problem. We should be basing this probably off my latest master, > > > > with the move to term based configs and the split of config and state > > > > thats going to affect you quite a bit. You might want to take a look > > > > there. > > > > > > > > I am more then willing to take a look at the code. > > > > > > > > > > You can find where I left off here: > > > > > https://github.com/jwilberding/otp/commit/10747727369c0eef4a0ec78b38464c0da3a6870c > > > > > > As you can see I am trying to add a flag to ignore abstract errors. > > Whenever > > > you run dialyzer on a beam that wasn't compiled with debug info, it will > > > break the whole process. > > > > > > I have some print statements sprinkled in right now to figure out why my > > > code changes weren't working. My suggestion is to first get dialyzer to > > work > > > by testing it indexing two apps, one that was compiled with debug info > > and > > > one that was not. If you use the current version of dialyzer it will bomb > > > out once it hits the app that doesn't have debug info. My version is > > > supposed to catch that and continue working and just ignore when that > > > happens, but there is a bug or something in my code. > > > > > > Once you are able to fix and run dialyzer on that example, then we can > > work > > > on integrating it back into sinan, which I also have some code for. Keep > > in > > > mind, we will need to rebase this fix to dialyzer, as I haven't updated > > my > > > otp branch from canonical in a while. > > > > I think in the short term we have to discard the idea of modifying > > dializer itself. What do you think of adding to the build config the > > option to exclude applications from the dialyzer analysis. That is to > > simply give the user the option to not include apps that do not have > > debugging info compiled in? > > > > > Yeah, that would be the best short term solution.
You willing to take that task on? > > > > > > > > > > > On a side note, with the latest escript based distribution shell > > > > doesn't work (the model has changed quite a lot) we need to take a > > > > look at that. > > > > > > > > I also noticed that the test task isn't discovering tests for some > > > > reason. Thats an easy fix and I will get on that this afternoon. > > > > > > > > The escript stuff is the hardest fix, I am not actually sure how to > > > > resolve that. > > > > > > > > here are the issues > > > > - With escript we don't have access to the startup environment for > > > > erlang. That means we cannot pass remove the -noshell flag. In any > > > > case, escript shuts down when things are done running. > > > > - We can startup a shell internally like we used to, but we will loose > > > > the nice terminal features of the usual shell (this is probably the > > > > short term solution). > > > > - we can exec another erlang with the right paths, but there is a lot > > > > of ambiguity there around execing the right erlang with the right erts > > > > etc. > > > > > > > > I have short term solution, but no long term solution as yet. Ideas? > > > > > > > > > > > I say we go with the short term solution for now and look into exec'g > > > another erlang process for the shell. I am not sure I understand the > > > ambiguity you are talking about though? > > > > I agree, thats the way we should go. > > > > We can exec an 'erl' binary but without any real way of knowing which > > erl it is. That is the erl for which version of erts. That may not > > matter so much, though. Also there isnt any way to exec in erlang that > > I am aware of. Its something to think about in any case > > > > > Hmm, does anything like this exist still?: > http://www.sics.se/~joe/sae.html#esh No. Last I heard they where slowly working it back into erlang proper but I haven't seen any updates in a long long time. > > -- > You received this message because you are subscribed to the Google Groups > "erlware-dev" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/erlware-dev?hl=en. > -- You received this message because you are subscribed to the Google Groups "erlware-dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/erlware-dev?hl=en.
