I put it at the erlware sinan project not mine
On Oct 15, 2011 12:01 PM, "Tristan Sloughter" <[email protected]>
wrote:
>
> Also, what happened to the sinan download on github?
>
>
> On Sat, Oct 15, 2011 at 10:01 AM, Tristan Sloughter <
[email protected]> wrote:
>>
>> Running 'sinan build' on a project is giving me the error below. Any
ideas?
>>
>> escript: exception error: undefined function
sin_fs_resolver:format_exception/1
>>   in function  sinan:do_task_full/3
>>   in call from sinan:do_task/3
>>   in call from sinan:do_build/2
>>   in call from escript:run/2
>>   in call from escript:start/1
>>   in call from init:start_it/1
>>   in call from init:start_em/1
>>
>>
>> On Thu, Oct 6, 2011 at 10:05 AM, Eric Merritt <[email protected]>
wrote:
>>>
>>> Ok. I just uploaded a version that does the printing I talked
>>> about. You can download it at your convenience.
>>>
>>> On 10/06/11 at 09:50am, Tristan Sloughter wrote:
>>> > Yup, I do have R14B03 through brew which is then under
/usr/local/Cellar and
>>> > linked to.
>>> >
>>> > On Thu, Oct 6, 2011 at 9:45 AM, Eric Merritt <[email protected]>
wrote:
>>> >
>>> > > Out of curiousty your /usr/local/lib/erlang wouldn't happen to be
>>> > > built up with symlinks would it? I just encountered your problem
>>> > > because i install R14B04 and I actually use stow to handle these
kinds
>>> > > of installs. so while /usr/local/lib/erlang/lib looks like it has
>>> > > everything in it sinan was actually resolving from
>>> > > /var/stow/otp_R14B04 while cucumberl and proper where in
>>> > > /var/stow/otp_R14B03. Just because of the way sinan was searching.
>>> > >
>>> > >
>>> > > On 10/05/11 at 01:27pm, Tristan Sloughter wrote:
>>> > > > Ok, thanks. I'll poke around tonight.
>>> > > >
>>> > > > On Wed, Oct 5, 2011 at 1:26 PM, Eric Merritt <
[email protected]>
>>> > > wrote:
>>> > > >
>>> > > > > Thats not sinan, Its escript. Sinan doesnt have any options
about
>>> > > > > doing things differently unfortunately. You can't actually start
a
>>> > > > > release in escript because escript is a release and its already
>>> > > > > started by the time you run your actual script. Right now
escript is a
>>> > > > > bit hacky for that reason.
>>> > > > >
>>> > > > > The long term fix is to finish up jeringa or the OTP guys finish
up
>>> > > > > stand alone erlang. In the short term you can use escript and
start
>>> > > > > the release manually. It sucks but its the only option.
>>> > > > >
>>> > > > > On Wed, Oct 5, 2011 at 1:23 PM, Tristan Sloughter
>>> > > > > <[email protected]> wrote:
>>> > > > > > Cool.
>>> > > > > > And so the 'sinan escript' feature relies on being able to
call a
>>> > > > > function:
>>> > > > > > project:main/1
>>> > > > > > Correct?
>>> > > > > > It would be great if instead it could just start the target
system :)
>>> > > > > > Tristan
>>> > > > > >
>>> > > > > > On Wed, Oct 5, 2011 at 1:15 PM, Eric Merritt <
[email protected]
>>> > > >
>>> > > > > wrote:
>>> > > > > >>
>>> > > > > >> Ok. thats really good to know. I think what is going on is
that
>>> > > > > >> because things are being distributed as an escript
code:lib_dir
>>> > > isn't
>>> > > > > >> actually returning the lib dir of erts. Its returning the lib
dir of
>>> > > > > >> the escript which isn't what we want at all.
>>> > > > > >>
>>> > > > > >> I need to think about that a little bit. To get it fixed. On
a side
>>> > > > > >> note, sinan now respects the ERL_LIBS env variable, and that
>>> > > dep_dirs
>>> > > > > >> thing you just saw.
>>> > > > > >>
>>> > > > > >> On Wed, Oct 5, 2011 at 1:12 PM, Tristan Sloughter
>>> > > > > >> <[email protected]> wrote:
>>> > > > > >> > Hah, that fixed it!
>>> > > > > >> >
>>> > > > > >> > 2011/10/5 Eric Merritt <[email protected]>
>>> > > > > >> >>
>>> > > > > >> >> Thats good and its bad. Its good in that the version
parser is
>>> > > not
>>> > > > > >> >> screwed up. Its bad in that its not finding proper as it
should.
>>> > > > > >> >>
>>> > > > > >> >> Hmm, this may be a pathing issue. I am not sure they we
can test
>>> > > > > that.
>>> > > > > >> >>
>>> > > > > >> >> add a piece to your config that looks as follows
>>> > > > > >> >>
>>> > > > > >> >> {dep_dirs, ["<path to where ever proper is>"]}.
>>> > > > > >> >>
>>> > > > > >> >> so if proper is in usr/local/lib/erlang/lib it would look
like
>>> > > > > >> >>
>>> > > > > >> >> {dep_dirs, ["/usr/local/lib/erlang/lib"]}.
>>> > > > > >> >>
>>> > > > > >> >> Lets see what that results in.
>>> > > > > >> >>
>>> > > > > >> >> On Wed, Oct 5, 2011 at 1:01 PM, Tristan Sloughter
>>> > > > > >> >> <[email protected]> wrote:
>>> > > > > >> >> > I got rid of the other proper and installed proper 1.0
from
>>> > > master,
>>> > > > > >> >> > same
>>> > > > > >> >> > thing:
>>> > > > > >> >> > starting: depends
>>> > > > > >> >> > Unable to resolve compile time dependencies, probably do
to the
>>> > > > > >> >> > following
>>> > > > > >> >> > constraints:
>>> > > > > >> >> >  application proper in the project
>>> > > > > >> >> >  constraint on proper with constraints [proper]
originating
>>> > > from
>>> > > > > >> >> > these
>>> > > > > >> >> > application(s) ['__top_level__']
>>> > > > > >> >> > build problem sin_task_depends:211 [{failed,
>>> > > > > >> >> >                           {possible_culprit,
>>> > > > > >> >> >                               [proper,
>>> > > > > >> >> >                                {proper,
>>> > > > > >> >> >                                    {set,1,16,16,8,80,48,
>>> > > > > >> >> >
>>> > > > > >> >> >  {[],[],[],[],[],[],[],[],[],[],[],[],
>>> > > > > >> >> >                                         [],[],[],[]},
>>> > > > > >> >> >                                        {{[],[],
>>> > > > > >> >> >                                          [proper],
>>> > > > > >> >> >
>>> > > > > >> >> >  [],[],[],[],[],[],[],[],[],[],[],[],
>>> > > > > >> >> >                                          []}}},
>>> > > > > >> >> >                                    {set,1,16,16,8,80,48,
>>> > > > > >> >> >
>>> > > > > >> >> >  {[],[],[],[],[],[],[],[],[],[],[],[],
>>> > > > > >> >> >                                         [],[],[],[]},
>>> > > > > >> >> >
>>> > > > > >> >> >  {{[],[],[],[],[],[],[],[],[],[],[],[],
>>> > > > > >> >> >                                          [],[],[],
>>> > > > > >> >> >
>>> > >  ['__top_level__']}}}}]}}]
>>> > > > > >> >> > On Wed, Oct 5, 2011 at 12:16 PM, Eric Merritt
>>> > > > > >> >> > <[email protected]>
>>> > > > > >> >> > wrote:
>>> > > > > >> >> >>
>>> > > > > >> >> >> This is the new dep solver stuff. I am actually happy
you are
>>> > > > > >> >> >> hitting
>>> > > > > >> >> >> this error. its going to help get the error messaging
right.
>>> > > > > >> >> >>
>>> > > > > >> >> >> So what its saying there is that there is a dependency
change
>>> > > > > >> >> >> starting
>>> > > > > >> >> >> at proper that is not being satisfied. So it might be
proper
>>> > > or
>>> > > > > >> >> >> something that proper depends on. (Its hard for the
system to
>>> > > know
>>> > > > > >> >> >> exactly in a back tracing search senario).
>>> > > > > >> >> >>
>>> > > > > >> >> >> Hmmm. I wonder if the 'alpha2' is the problem. That
could be a
>>> > > > > bug,
>>> > > > > >> >> >> I
>>> > > > > >> >> >> may have to do some better version parsing. In any
case,  Do
>>> > > me a
>>> > > > > >> >> >> favor. There is a 1.0 version of proper out. Try
installing
>>> > > that
>>> > > > > and
>>> > > > > >> >> >> lets see what happens
>>> > > > > >> >> >>
>>> > > > > >> >> >> https://github.com/manopapad/proper.git
>>> > > > > >> >> >>
>>> > > > > >> >> >> You should probably use that anyway, its quite a bit
more
>>> > > advanced
>>> > > > > >> >> >> then the version you have.
>>> > > > > >> >> >>
>>> > > > > >> >> >> Eventually I want to break these things out into
plugins so
>>> > > you if
>>> > > > > >> >> >> you
>>> > > > > >> >> >> dont need proper you dont have to have it.
>>> > > > > >> >> >>
>>> > > > > >> >> >> oh and nuke your old proper.
>>> > > > > >> >> >>
>>> > > > > >> >> >> Thanks for bearing with me in this. You are my first
non-me
>>> > > user
>>> > > > > of
>>> > > > > >> >> >> this version of sinan.
>>> > > > > >> >> >> On Wed, Oct 5, 2011 at 12:08 PM, Tristan Sloughter
>>> > > > > >> >> >> <[email protected]> wrote:
>>> > > > > >> >> >> > Note that the config file must be named sinan.config
and not
>>> > > > > >> >> >> > sinan.cfg.
>>> > > > > >> >> >> > Once I got that fixed I get what looks to be
complaining I
>>> > > don't
>>> > > > > >> >> >> > have
>>> > > > > >> >> >> > proper. But I do:
>>> > > > > >> >> >> > /usr/local/lib/erlang/lib/proper-0.0.1alpha2/
>>> > > > > >> >> >> > λ sinan build
>>> > > > > >> >> >> > starting: depends
>>> > > > > >> >> >> > Unable to resolve compile time dependencies, probably
do to
>>> > > the
>>> > > > > >> >> >> > following
>>> > > > > >> >> >> > constraints:
>>> > > > > >> >> >> >  application proper in the project
>>> > > > > >> >> >> >  constraint on proper with constraints [proper]
originating
>>> > > from
>>> > > > > >> >> >> > these
>>> > > > > >> >> >> > application(s) ['__top_level__']
>>> > > > > >> >> >> > build problem sin_task_depends:211 [{failed,
>>> > > > > >> >> >> >                           {possible_culprit,
>>> > > > > >> >> >> >                               [proper,
>>> > > > > >> >> >> >                                {proper,
>>> > > > > >> >> >> >
 {set,1,16,16,8,80,48,
>>> > > > > >> >> >> >
>>> > > > > >> >> >> >  {[],[],[],[],[],[],[],[],[],[],[],[],
>>> > > > > >> >> >> >                                         [],[],[],[]},
>>> > > > > >> >> >> >                                        {{[],[],
>>> > > > > >> >> >> >                                          [proper],
>>> > > > > >> >> >> >
>>> > > > > >> >> >> >  [],[],[],[],[],[],[],[],[],[],[],[],
>>> > > > > >> >> >> >

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

Reply via email to