Task depends on many many settings

[Heiko Seeberger]

Hi,

Looks like I ran into the fact that there are is a upper limit to implicit conversions form TupleN of Initialize.

How can I define a task which depends on more than nine settings?

Thanks

Heiko

--

Heiko Seeberger
Twitter: hseeberger
Blog: heikoseeberger.name
Company: Typesafe - Enterprise-Grade Scala from the Experts
Author of Durchstarten mit Scala, a German tutorial-style Scala book

[Doug Tangren]

On Mon, Nov 28, 2011 at 12:16 PM, Heiko Seeberger <heiko.s...@googlemail.com> wrote:

Hi,

Looks like I ran into the fact that there are is a upper limit to implicit conversions form TupleN of Initialize.

How can I define a task which depends on more than nine settings?

I think this issue came up on the list before. It's the same as the magic number 22 in scala with case classes. You have to start composing related settings in to container objects. I think end result is a little more readable. 9 is an arbitrary number, but it encourages more composition.

[Gustavo Hexsel]

  I know this is the opposite of what the API was intended to do, but can't an alternative API be provided with a context that gets all available data?  I personally think anything more than 2 parameters is hard to read...  all data you want to access needs to be declared twice which is redundant by definition.

     []s Gus

--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
To post to this group, send email to simple-b...@googlegroups.com.
To unsubscribe from this group, send email to simple-build-t...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.

[Gerolf Seitz]

you can get the build state and fetch everything you need from there, something like the following:

mySetting <<= state map { s => 

  val extracted = Project.extract(s)

  val v = extracted.get(version)  // this is the regular SettingKey

  val (newS, deps) = extracted.runTask(libraryDependencies, s)

  val (newS1, ...) = extracted.runTask(..., newS)

 ...

}

Disclaimer: I didn't compile this and I probably got a method name wrong. But you get the point.

If you don't want to thread the state through all these method calls yourself, you can wrap State and make it

a ... Monad ... and you're good to go.

Hth,

  Gerolf

--

Gerolf Seitz

twitter: @gersei

code: github.com/gseitz

blog: www.gerolfseitz.com

[Gustavo Hexsel]

  Awesome!  Thanks a lot.

[Heiko Seeberger]

On Nov 28, 2011, at 10:56 PM, Doug Tangren wrote:

> I think this issue came up on the list before. It's the same as the magic number 22 in scala with case classes. You have to start composing related settings in to container objects. I think end result is a little more readable. 9 is an arbitrary number, but it encourages more composition.

Fair enough. That's what I am telling people, too ;-)
But in this case (OSGi headers) I haven't yet seen a good way to introduce meaningful containers. Will have to think harder …

Heiko

[Heiko Seeberger]

Awesome! 

Sorry, but that's *not* awesome: If settings on which other settings depend on are not defined, you don't get an error when sbt starts (or reloads), but only when you use such a dependent setting. Like at runtime instead of compile-time.

Heiko

[Gustavo Hexsel]

  Maybe there could be a way with less overhead?

[Mark Harrah]

On Tue, 29 Nov 2011 09:06:05 -0800
Gustavo Hexsel <ghe...@gmail.com> wrote:

> Maybe there could be a way with less overhead?

The situation hasn't changed since the last time it was brought up.

> On Tue, Nov 29, 2011 at 8:35 AM, Heiko Seeberger <
> heiko.s...@googlemail.com> wrote:
>
> > Awesome!
> >
> >
> > Sorry, but that's *not* awesome: If settings on which other settings
> > depend on are not defined, you don't get an error when sbt starts (or
> > reloads), but only when you use such a dependent setting. Like at runtime
> > instead of compile-time.

This is correct. Additionally,

1. runTask should only be used in a command. Otherwise, you have multiple task executions occurring simultaneously.

2. It is very inefficient, since you are executing the entire subgraph required by a task for each runTask.

-Mark

[Mark Harrah]

On Tue, 29 Nov 2011 21:17:50 +0530
Heiko Seeberger <heiko.s...@googlemail.com> wrote:

> On Nov 28, 2011, at 10:56 PM, Doug Tangren wrote:
>
>
> > I think this issue came up on the list before. It's the same as the magic number 22 in scala with case classes. You have to start composing related settings in to container objects. I think end result is a little more readable. 9 is an arbitrary number, but it encourages more composition.
>
> Fair enough. That's what I am telling people, too ;-)
> But in this case (OSGi headers) I haven't yet seen a good way to introduce meaningful containers. Will have to think harder …

The real problem is the compilation time due to the implicits and heterogenous lists behind the scenes. At least, that is what I remember as the reason for removing N=10-12.

-Mark

> Heiko

[Heiko Seeberger]

> The real problem is the compilation time due to the implicits and heterogenous lists behind the scenes. At least, that is what I remember as the reason for removing N=10-12.

Compilation time for sbt itself?

Heiko

[Mark Harrah]

Because sbt has a lot of setting definitions, it would affect both sbt and build definition compilation as well.

-Mark

[Jon-Anders Teigen]

access :^: the :^: klist :^: directly ;-)

https://gist.github.com/1435102

/j

[Heiko Seeberger]

On Dec 5, 2011, at 9:11 PM, Jon-Anders Teigen wrote:

access :^: the :^: klist :^: directly ;-)

https://gist.github.com/1435102

You are f… crazy ;-)

But yes, that looks like an excellent workaround. Will give it a try.

Heiko

[Doug Tangren]

On Tue, Dec 6, 2011 at 3:22 AM, Heiko Seeberger <heiko.s...@googlemail.com> wrote:

On Dec 5, 2011, at 9:11 PM, Jon-Anders Teigen wrote:

access :^: the :^: klist :^: directly ;-)

https://gist.github.com/1435102

Lol. I love this ^ ^

That's actually less syntactic overhead that I originally assumed if you wanted to be more explicit.