gmane.comp.lang.scala.debate

Re: Re: Code Coverage for Scala

Anjaiah Yamagani — 2013-05-17T19:00:53

Hi All,

I would like to ask couple of questions about the Scala Code Coverage and
Quality Metrics.

I have gone though the SCCT tool, It just tells about the JUnit Code
Coverage.

But I would like to see suitable tool for scala which will cover.

1. Unit Test case report.
2. Integration test cases
3. Functional test cases.
4. Load Test cases.
4. Code Quality metrics (like code complexity, design issues,package
triangle index)
5. Statics Analysis of the code.


As per my knowledge we have

1. Jacoco
2. Cobetura
3. SCCT
4. Sonar

Please advise me a best suitable tool for the above mentioned points.


Regards,
Anjaiah Y



On Sat, Apr 20, 2013 at 11:05 AM, Alexis Agahi <alexis.agahi< at >gmail.com>wrote:

Proposal for dollar semantics

Som Snytt — 2013-05-16T22:42:19

When you are new to a city, it helps the budget-conscious traveler to pick
up a Zagat guide and figure out where to find a meal.

It might help the performance-minded newcomer to Scala if the compiler
adopted the following conventions:

$    - cheap accommodation of nested entities
$$   - still reasonable artifact that won't bust your budget
$$$  - rather pricey computation, time- or space-wise
$$$$ - you must be wearing a tie to invoke this function

For example, I might invoke Partner$available$$$$diningOption$anon$1 if I
thought you might be the one, or maybe if I was just looking for something
anon.

How much time does paulp have left?

Som Snytt — 2013-05-12T03:23:47

imperative

For the record, I would wear this t-shirt every day (except for laundry
days), just to keep myself honest.

Also, scala-lang.org could display a counter in the corner with the "paulp
clock".

It would have to tie in with the jenkins PR validator, of course.

Love and care of artifacts

Som Snytt — 2013-05-12T03:08:16

Twitter sends me emails, like this one:

Carl Byström<https://twitter.com/i/redirect?url=https%3A%2F%2Ftwitter.com%2Fcgbystrom%2Fstatus%2F331783368725372928%3Frefsrc%3Demail&sig=22e23cbecb11cc7ed7caacb13dd15c6c469b75a0&uid=388517968&iid=fe75c683-cf94-4c16-9764-1c19b84cd374&nid=12+139+20130507&t=1>
< at >cgbystrom<https://twitter.com/i/redirect?url=https%3A%2F%2Ftwitter.com%2Fcgbystrom%2Fstatus%2F331783368725372928%3Frefsrc%3Demail&sig=22e23cbecb11cc7ed7caacb13dd15c6c469b75a0&uid=388517968&iid=fe75c683-cf94-4c16-9764-1c19b84cd374&nid=12+149+20130507&t=1>

If only developers wrote commit messages with same love and care as code.
This may be obvious to everyone, but s/code/paulp/.

paulp commits make archaeology fun again.

I thought maybe Carl was part of the Scala ecosystem on the Akka side
(because of the two dots), so I consulted his blog.

He riffs on David Pollak's view that Scala is a measure of something, like
taking calculus.  He adds that this is so important to the Scala ethos that
the spec should say, "

Re: How can we teach the utility of Try?

Julien Richard-Foy — 2013-05-06T10:33:37

I think Try gives you more control than try because it turns “computation 
attempts” into first class values.

Le mardi 30 avril 2013 00:58:45 UTC+2, Rex Kerr a écrit :

Re: propositions for scala that could increase reliability and controllability

Paul Phillips — 2013-05-03T23:55:01


I recently proposed that access should be done with annotations. Using type
bounds to articulate access restrictions would allow for that level of
granularity, and much more. Plus we could throw two keywords back into the
hopper.

propositions for scala that could increase reliability and controllability

arkantos — 2013-05-03T23:27:47

There are a few things I always missed in java:
1) design by contract (pre- and post condition, invariant ...)
2) class scoping like in eiffel:
   wouldn't it be handy to hide functions from other objects except from 
those we gave the permission to access
  
   ex: {A,B} class C extends D ...
      -> only A, B and C itselve may access the methods of C

  thus we could use a strict variation of the fascade pattern or do any other 
helpful things. It shouldn't be overused of course but we gain much more 
control of who  uses our classes.

This expansions wouldn't affect old code i guess, because there's no need 
to change anything about the scopes used so far (private, ...)

Moreover we could find many bugs at compile time. Debugging and Testing 
might get much easier.

Re: How can we teach the utility of Try?

marius a. eriksen — 2013-04-29T23:34:22

The initial idea behind com.twitter.util.Try -- from which
scala.util.Try is derived -- was to divorce exception handling from
the call stack. Where you can get away with normal exception handling,
consider using stack-based exception handling, otherwise use Try.

-marius

How can we teach the utility of Try?

Rex Kerr — 2013-04-29T22:58:45

I've noticed repeatedly on StackOverflow (and also scala-users) that even
some of the most sophisticated members of the Scala community write
suboptimal-clarity Try code.

When I use Try, I make heavy use of two patterns:

(1) Assume the best, prepare for the worst.

  val x = Try { ... }
  val y = Try { ... }
  val z = Try { ...; f(x.get, y.get); ... }

(This is/should be the answer to pretty much every question of the form "I
have Try inside and I want it outside".)

(2) Exceptions are classes, too.

  case class Net(fish: String) extends Exception
  Try { ...; throw Net("salmon"); ... } match {
     case Failure(Net(fish)) => println("Oh, it's just a "+fish)
     case Failure(t) => ...
     case Success(s) => ...
  }

(This is/should be the answer to pretty much every question of the form
"Sometimes I need to return some data along with a failure.")

I'm sure there are more.  But it seems--am I wrong?--that these sorts of
patterns are not really occurring naturally to people.

Why not, and what can we do

Re: Is the writing on the wall for client side JVM?

Rex Kerr — 2013-04-26T14:45:02



That's because we don't need Java 8 for anything.  Some features might give
a performance advantage, but until basically everyone is using 8, Scala
can't assume they're present.




Er, it's days are already over on the bulk of client side OSes, because
Windows is the bulk, and it doesn't install the JVM by default.



Security problems are a issue for servers too.  Maybe even a bigger issue,
since if you get server access you generally have a lot more exploitable
data available.  (Not so useful if you just want a botnet, though.)  I'm
not sure why you think the security issues are client/desktop-specific.




Can't argue with that.



I don't think this is realistic.  Dalvik and Avian already seem to be
beyond the reach of substantial efforts, and this is despite them opening
up the entire mobile/smartphone market.  Instead, people rely upon the
standard bytecode transformation toolchain to use Dalvik, and on Avian to
not require anything different.




People aren't buying a desktop/laptop becaues they

Is the writing on the wall for client side JVM?

Rich Oliver — 2013-04-26T14:20:58

The recent delay for Java 8 seems to have been almost completely unnoticed 
within the Scala community. It has been delayed in order to focus on 
security. The JVM is widely seen as a security nightmare. Could its days be 
numbered on the bulk of client side OSs. The JVM on the Server is going 
strong. So I wonder how much of the Scala community really cares about 
this? It seems that the bulk of commercial Scala is server side.

The very low priority that the Scala team put on GUI seems to confirm a 
lack of concern for client side Scala. I'm not saying this is wrong. The 
Scala team have limited resources. They must choose their priorities, but 
it would be nice to have a clearer statement of those priorities. If Scala 
is to have a long term client side future then it may need a different 
target. Mono, LLVM, full compilation are all possibilities but would all 
require large investments of resources.

No one would deny the client world is changing at a great pace. Scala has 
always had limits on the clie

Re: Proposal: DSL for math expressions

Robert Kohlenberger — 2013-04-24T03:40:59


Background


In Scala, numbers are objects, and infix expressions like "1 + 2", are 
compiled to "1.+(2)".  This has benefits and drawbacks.  The core language 
is simplified greatly by removing math operators to number objects.  On the 
other hand, an expression like "f + g", with expensive functions f and g, 
must first evaluate f to a number object, then pass the result of 
evaluating g to the + operator.  This serial evaluation is enforced even if 
f and g are independent and could be evaluated concurrently with no change 
in the result.  Furthermore, the concrete types f and g must be known to 
the compiler where + is used in the code, since there is no abstract 
super-type of numbers with the + operator.


As a partial fix to that concrete type requirement, Scala supplies trait 
Numeric.  If all you need is +, -, or * operators, then importing 
Numeric.Implicits._ makes implicit conversions available when calling 
methods with Numeric parameters, like "def doubleIt[A: Numeric](x: A) = x + 
x".


An a

Re: Proposal: DSL for math expressions

Robert Kohlenberger — 2013-04-24T03:34:06

2nd paragraph under "Solution?":
"without the bloat and compile-time overhead of serialization" <= should be 
"specialization"

Re: Proposal: DSL for math expressions

Robert Kohlenberger — 2013-04-24T03:31:38

"without the bloat and compile-time overhead of serialization" <-- meant 
"specialization"

On Tuesday, April 23, 2013 8:11:02 PM UTC-7, Robert Kohlenberger wrote:

Proposal: DSL for math expressions

Robert Kohlenberger — 2013-04-24T03:11:02


Proposed DSL for math expressions


Background


In Scala, numbers are objects, and infix expressions like "1 + 2", are 
compiled to "1.+(2)".  This has benefits and drawbacks.  The core language 
is simplified greatly by removing math operators to number objects.  On the 
other hand, an expression like "f + g", with expensive functions f and g, 
must first evaluate f to a number object, then pass the result of 
evaluating g to the + operator.  This serial evaluation is enforced even if 
f and g are independent and could be evaluated concurrently with no change 
in the result.  Furthermore, the concrete types f and g must be known to 
the compiler where + is used in the code, since there is no abstract 
super-type of numbers with the + operator.


As a partial fix to that concrete type requirement, Scala supplies trait 
Numeric.  If all you need is +, -, or * operators, then importing 
Numeric.Implicits._ makes implicit conversions available when calling 
methods with Numeric parameters, like "def doubleIt

Re: Re: Miniboxing vs. scratchpads for avoiding combinatorial explosion of specialization

Vlad Ureche — 2013-04-22T11:41:50

2013/4/22 Vlad Ureche <vlad.ureche< at >gmail.com>



And https://groups.google.com/d/msg/scala-internals/57ObhiTjP50/JDaxqHVnf_UJ

Vlad

Re: Re: Miniboxing vs. scratchpads for avoiding combinatorial explosion of specialization

Vlad Ureche — 2013-04-22T11:40:31

2013/4/15 Matthew Pocock <turingatemyhamster< at >gmail.com>


I remember proposing this some time ago, but gave up on it after I got the
idea of miniboxing:
https://groups.google.com/d/msg/scala-internals/57ObhiTjP50/HlNeI83T0qMJ
I guess we can always pick it up again.

I wonder if we should take a moment to be clear about what we want from

Yes, please, let's do so. It seems to me there's no one-size-fits-all
solution, so let's see what we're willing to trade off.

Cheers,
Vlad

Re: Re: Miniboxing vs. scratchpads for avoiding combinatorial explosion of specialization

Vlad Ureche — 2013-04-22T11:33:48

2013/4/14 Rex Kerr <ichoran< at >gmail.com>


The more I think of this the more I agree with you. It'll probably need a
double variant as well, or, as technically challenging as it is, to
integrate with specialization.
I'm looking forward to Miguel's findings on runtime code generation, if
that's not prohibitively expensive (which is what I found in my
exploration) then we may go down that path.

Cheers,
Vlad

PS: Rex, sorry for the duplicate message, I hit reply instead of reply to
all again.

Mailing list reminder: Scala-debate

Scala Mailing Lists — 2013-04-21T13:32:02

Welcome to the "Scala-debate" mailing list.

This automatic reminder is sent once a month to the list,
to keep subscribers up-to-date with the mailing list services,
and to help keeping the list on topic.

-------------------------------------------------------------------

The "Scala-debate" mailing list:

This list is a more relaxed forum for Scala discussions
that would probably be off-topic or too convoluted for
the other lists, but that may still be quite interesting
to follow for a selected readership.

In particular, the following are appropriate:

  * threads that evolved beyond their initial topic,
      and have become too long or convoluted to be
      of interest to most readers
  * threads discussing extremely specialized topics
  * threads that are mostly speculative in nature,
      out-of-the-box thinking, philosophical views
      (as long as they are still somehow related
      to Scala)
  * debates (of course)

The "Scala-debate" list is the natural destination of all
the threads that star

Re: Code Coverage for Scala

Alexis Agahi — 2013-04-20T18:05:51

We started playing sonar scala plugin few weeks ago and decided to go 
beyond and work on scala code analysis.
Our first experimentation was on static code analysis right now using 
compiler AST. We are also planning to work on dynamic analysis based on 
extensive random generated data and code instrumentation.
 
This is still early work and we expect to do a release asap and update the 
current sonar plugin accordingly.

In meantime you can try
http://mtkopone.github.io/scct/



On Friday, April 19, 2013 11:35:53 PM UTC+2, Srinivas wrote:

Code Coverage for Scala

Anjaiah Yamagani — 2013-04-19T21:35:53

Hi,

I'd like to see the code quality of the scala language.

earlier I have used the sonar, cobutura for JAVA language for the code
coverage.

could you please tell me, what is the suitable tool for code coverage for
scala?


Regards,
Srinivas