On 30/05/2013 17:50, Tiago Tresoldi wrote:
> 2013/5/30 Giulio Paci <giuliop...@gmail.com <mailto:giuliop...@gmail.com>>
>
> > I had suggested putting everything in /data just to reduce the
> number of
> > directories and to be consistent (/bin with binary files, /src with
> > source files, /data with user-experience files, etc.)
> >
> > But sub-modules for the actual language models, such the available
> > Italian and Danish, is a great idea; they could even include a wrapper
> > to the voting tagger which would automatically load the correct model
> > files (so that a user could do, say, "sudo apt-get install
> > acopost-english && echo "This is just an example." |
> acopost-english").
>
> If your goal is this, then /data is fine. I would keep them in a
> separated submodule anyway: mixing data and software is likely to create
> issues in the long term.
>
>
> I might have misunderstood you; I suggest we now refer to the default
> data (now in /examples) as "(default) rules" and the language models
> (now in /language-models) as "(language) models".
>
> Just to make sure, you mean that distributing the default rules with
> package 'acopost' would be acceptable but not recommended? I still think
> that installing them in /usr/share/acopost would be a good idea,
> especially because the ET and TBT taggers cannot run without a rule. I
> would think of them almost as a documentation.
If it is documentation and example, the right installation path should
be /usr/share/doc/acopost/examples/.
I also think those two files should be distributed with the source.
> Of course the discussion is completely different for the models.
But I was thinking about the models in my previous sentence.
> Summarizing I think that we basically agreed on these points:
> 1) moving /bin to /src/scripts
> 2) moving /example to /data
> 3) leave everything else as it is
> 4) eventually create /devel or /maintain or /experimental when we will
> need it
>
> Is it right?
>
>
> I think it is. Point 1 includes removing the .pl extensions.
And .py extension as well, right. As this will cause name collisions,
you should decide if you want to keep the perl version or the python
version of some scripts.
Choosing python will require one more dependency for the end-user, but
it is not a big issue anyway.
If you want to keep both the version of the scripts, just leave the one
that you do NOT want to install with the extension and be sure to not
install it.
Bests,
Giulio.
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
acopost-devel mailing list
acopost-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acopost-devel
