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? > > > > 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 > > -- > 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.
