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