mg514448 | 15 Jun 18:22 2016
Picon

Nested zips in Scala

Hi there, new to scala not new to coding. I can unzip files no problem but I'm having trouble with unzipping nested zip files with scala, has anyone here dealt with this problem and give some example of pointers? Thanks!

Original.zip contains
file1.txt
file2.txt
file3.zip contains
              file3.txt
file4.zip contains
              file4.txt

I want to be able to extract all the text files automatically/recursively

Thanks!
 

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
thomas weidner | 4 Jun 10:17 2016
Picon

Why is the method resolution order different from python,common lisp,...?

Hello,

I am just learning Scala, but have experience in several other languages. Reading "Programming in Scala 3rd edition", I am a bit confused about trait inheritance. Though the author claims trait inheritance are not multiple inheritance, he may be right when he has C++ in his mind, but compared to languages like Common Lisp or Python trait inheritance in Scala is just multiple inheritance in these languages.

Nevertheless, computing the method resolution order (or class precedence list) is done differently in Scala. In CL or Python classes are ordered using two principles:
  1. every class after it's superclasses (super traits)
  2. If two classes appear in the same superclass list, their order is this list has to be preserved in the final class precedence list.
If these two relations induce a partial order, a linearization of this order is used as class precedence list. Scala seems to pursue a different approach, In a recursive approach it concatenates the previously constructed linearizations of all super classes in order, and just does not add any class again, which are already present. While this approach preserves property 1 from above, property 2 may be violated, for example:
class Base
trait A extends Base
trait B extends A
class Test extends Base with B with A
This results in the order Test, B, A, Base. Note that B actually is after A, although A is written after B in the superclass list of Test. Let's compare this to the same example in Python (Note that in Python the first superclass is the most important not the last one as in Scala):
class Base:pass
class A(Base):pass
class B(A):pass
class Test(A,B):pass

Entering this in the Python interpreter yields an exception: Cannot create a consistent method resolution order (MRO) for bases A, B. This is expected since A has to come before B as A is a superclass of B, but B has to come before A as A is after B in the superclass list of Test. This cycle cannot be linearized.

In my opinion the Python result is more natural and error safe as the superclass order always respects the way I specify it, if this is not possible an error occurs. In Scala, on the other hand, if a supertrait does something weird, my superclass order can get mixed and become unexpected. If I rely on the order some stacked behaviour, my code can become wrong and the error is very subtle and hard to track. (Imagine I add behaviour as a trait another trait already implements, even worse imagine this changes in some library version).

Nevertheless, if my supeclasses can be linearized in the Python sense, the obtained order seems to match the order Scala obtains for the same hierarchy, but I am not quite sure about this, I would have to prove this on paper.

So my question is: Why is Scala more relaxed than Python or Common Lisp constructing the class precedence list? Is there a good reason or is it just the way someone implemented it once (maybe because he was unaware of the issue)? Will this algorithm change to the Python version in the future (2.12/13/...)?

Thanks for reading my post,
Thomas

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Guanpeng Xu | 21 May 08:25 2016
Picon

On inference of existential types

Dear group,

Suppose I have a Java class Q defined as this:

public class Q<T> {

    public Q() {}
    public Q(Q<T> q) {}

    public static <T> Q<T> f(Q<? extends T>[] qs) {
        throw new UnsupportedOperationException();
    }

    public static <T> Q<T> g(Q<? extends Q<? extends T>> q) {
        throw new UnsupportedOperationException();
    }
}

Now, the following Scala program cannot be compiled:

object C {

    val qs: Array[Q[_ <: Int]] = Array.fill(1)(new Q())
    val a = Q.f(qs)

    val q: Q[_ <: Q[_ <: Int]] = new Q(new Q())
    val b = Q.g(q)
}

The errors are

[error] Q.scala:6: no type parameters for method f: (x$1: Array[rxtest.Q[_ <: T]])rxtest.Q[T] exist so that it can be applied to arguments (Array[rxtest.Q[_ <: Int]])
[error]  --- because ---
[error] argument expression's type is not compatible with formal parameter type;
[error]  found   : Array[rxtest.Q[_ <: Int]]
[error]  required: Array[rxtest.Q[_ <: ?T]]
[error]     val a = Q.f(qs)
[error]               ^
[error] Q.scala:6: type mismatch;
[error]  found   : Array[rxtest.Q[_ <: Int]]
[error]  required: Array[rxtest.Q[_ <: T]]
[error]     val a = Q.f(qs)
[error]                 ^
[error] Q.scala:9: no type parameters for method g: (x$1: rxtest.Q[_ <: rxtest.Q[_ <: T]])rxtest.Q[T] exist so that it can be applied to arguments (rxtest.Q[_$2])
[error]  --- because ---
[error] argument expression's type is not compatible with formal parameter type;
[error]  found   : rxtest.Q[_$2] where type _$2 <: rxtest.Q[_ <: Int]
[error]  required: rxtest.Q[_ <: rxtest.Q[_ <: ?T]]
[error]     val b = Q.g(q)
[error]               ^
[error] Q.scala:9: type mismatch;
[error]  found   : rxtest.Q[_$2] where type _$2 <: rxtest.Q[_ <: Int]
[error]  required: rxtest.Q[_ <: rxtest.Q[_ <: T]]
[error]     val b = Q.g(q)
[error]                 ^
[error] four errors found

I expected T in the two calls to be inferred as Int, but something prevented that.  Is this due to a bad design of the Java program, or some limitation of the type inferer of Scala?

(The example above is simplified from the real world design of RxJava.  I asked a question on StackOverflow.  My intention was to understand the Scala language and I was not satisfied with the answer there.)

Best regards,
Guanpeng Xu

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Marc Arndt | 17 Apr 12:27 2016
Picon

Different behaviour from Option map in scala compared to Optional map in java

Hello,
while programming with java 8 and scala I discovered that both seem to have a different behaviour with the method map in the classes Option in scala and Optional in java.
In scala the method map in Option is implemented as followed:
  <at> inline final def map[B](f: A => B): Option[B] =
    if (isEmpty) None else Some(f(this.get))
This method requires, that f doesn't return null.

In java the method map in Optional is implemented as followed:
    public<U> Optional<U> map(Function<? super T, ? extends U> mapper) {
        Objects.requireNonNull(mapper);
        if (!isPresent())
            return empty();
        else {
            return Optional.ofNullable(mapper.apply(value));
        }
    }
This method does not require, that the given method returns a value not null, it is also accepted to return null.

I'm not sure if this behaviour is intended.

Many Greetings
Marc

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Piotr Tarsa | 13 Apr 13:02 2016
Picon

Reworking import statements (proposal)

Hi,

As of now relative imports (ie importing from something already imported) look exactly the same as absolute ones (ie where we're importing using full paths), except when explicitly starting from _root_. That is both confusing (where I have relative or absolute import? it's not immediately obvious) and ugly (the _root_ prefix is ugly).

My proposal is to change import statements semantics to make things obvious:

Current state:
import _root_.outer.inner.Member - for absolute imports (usually used when there are name clashes)
import outer.inner.Member - for absolute imports (usually used when there are no name clashes)
import inner.Member - for relative imports
import parameter.member - for importing from parameters

Proposal for next Scala version:
import _root_.outer.inner.Member - deprecate _root_ prefix
import outer.inner.Member - leave as it is
import inner.Member - deprecate this form of relative imports
import _.inner.Member - introduce this syntax for relative imports
import parameter.member - leave as it is

And a version after that:
import _root_.outer.inner.Member - drop support for _root_prefix
import outer.inner.Member - keep it
import inner.Member - drop support for this form of relative imports
import _.inner.Member - keep it
import parameter.member - keep it

What do you think about it?

Regards,
Piotr Tarsa

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
John Michael Lafayette | 11 Apr 05:05 2016
Picon

Scala Macro "context.internal.enclosingOwner" - Getting File And Line #

I was recently playing around with this library - https://github.com/lihaoyi/sourcecode

It lets me output the file location and line number like this: sourcecode.DebugFull.main Foo [arg]: 123

It seems to use this feature, c.emclosingPosition.source . scala.reflect.macros.Enclosures

I want to use it to improve my library, https://github.com/JohnReedLOL/scala-trace-debug

Instead of using Thread.currentThread.getStackTrace() to get the current position in the source code, I want to use "context.internal.enclosingOwner".

The problem with this is that for "context.internal.emclosingPosition.source" to work with stack trace highlighting in the IDE, the formatting must match the formatting produced by a real stack trace. lihaoyi's library does not do this, but if it did, the performance would be better than a regular stack trace and it could be used in place of a one line stack trace.

Is there any way to make macro source code position look like a real stack trace line so that stack trace highlighting would work?

Example: bootstrap.liftweb.Boot.<init>(Boot.scala:25)

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Rich Oliver | 7 Apr 14:45 2016
Picon

Seq :+ repeat parameter

I have created the following code and it seems to compile and run correctly:

val scaleButs = Seq(CanvButton("+", () => { scale = (scale * 1.5).min(scaleMax); repaintMap() }),
      CanvButton("-", () => { scale = (scale / 1.5).max(scaleMin); repaintMap() }))
   val mapButs = scaleButs :+ (     
      CanvButton("<=", () => { mapFocus = mapFocus.subX(moveInc); repaintMap() }),
      CanvButton("=>", () => { mapFocus = mapFocus.addX(moveInc); repaintMap() }),
      CanvButton("Up", () => { mapFocus = mapFocus.addY(moveInc); repaintMap() }),
      CanvButton("down", () => { mapFocus = mapFocus.subY(moveInc); repaintMap() })
   )

But in the API documentation the :+ doesn't have a repeat parameter. I've looked in SeqLike.scala https://github.com/scala/scala/blob/v2.11.8/src/library/scala/collection/SeqLike.scala#L1 and I can't see any repeat parameter for the :+ method there either.

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Philippe Suter | 5 Apr 20:14 2016
Picon
Gravatar

AnyVal makes private case class constructor public

I'm wondering if the observed behavior is intentional; in the attached file, I expect the three class construction calls to fail, but only the ones commented out do.

It seems that having a case class extends AnyVal renders its constructor public.

Maybe a special case of https://github.com/scala/scala/pull/2236 ?

Tested on Scala 2.11.8.

Best regards,
PS

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Attachment (Example.scala): application/octet-stream, 487 bytes
Samuele Pretini | 30 Mar 16:04 2016
Picon

Meaning of Element methods

Hi at all,

I'm new student of Scala.

During some test that I'm doing, I have seen the class scala.collection.IndexedSeqLike.Elements

In this class there is a method: aggregate

The signature of the method is the question: 
def aggregate[B](z: ⇒ B)(seqop: (BA) ⇒ Bcombop: (BB) ⇒ B)B

  1. What's mean of  z: => B ?
  2. What's mean of the 2 parenthesis: (z: ⇒ B)(seqop: (BA) ⇒ Bcombop: (BB) ⇒ B)
Can someone of us to explain to me?

Thanks a lot. :-)

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Nicola Contu | 29 Mar 14:53 2016
Picon

Open Source Forum in Scala

Hey There,
Is there any open source forum written in Scala?

Thanks a lot,
Nicola


--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Christopher Lee | 27 Mar 19:11 2016
Picon
Gravatar

Possible inconsistent error for "+=" shorthand while using immutable set

Hello,

I'm just starting to learn Scala, and I came across the following example in the "Programming in Scala" book.

var jetSet = Set("Boeing", "Airbus")
jetSet
+= "Lear"
println
(jetSet.contains("Cessna"))

One of the lesson points is that the default Set is immutable. So, I wanted to test that line 2 in the above actually reassigns a new immutable set with the element added to the jetSet variable.

I then changed the var to a val and expected to see a reassignment error. Instead I got the below error.

immutableSet.scala:2: error: value += is not a member of scala.collection.immutable.Set[String]
jetSet
+= "Lear"
       
^

While the error message is true, it's strange that the compiler didn't complain about "+=" before. "+=" is shorthand for `jetSet = jetSet + "Lear"`, so I would expect to see a reassignment error.

E.g. If I were to run the program with the long form, I get the expected error message.

val jetSet = Set("Boeing", "Airbus")
jetSet
= jetSet + "Lear"
println
(jetSet.contains("Cessna"))

immutableSet.scala:2: error: reassignment to val
jetSet
= jetSet + "Lear"
       
^

Am I missing something (very likely since I'm a newb) or does this seem inconsistent?

Thanks for reading!
Chris

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-language+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Gmane