|
Yup.
|
# ? Oct 10, 2015 08:23 |
|
|
# ? May 13, 2024 11:28 |
|
Yeah, square brackets in scala are basically the same as angle brackets in java. asInstanceOf acts as a cast.
|
# ? Oct 16, 2015 06:37 |
|
Has anyone used Ammonite? What did you think of it?
|
# ? Oct 18, 2015 15:22 |
|
KernelSlanders posted:Has anyone used Ammonite? What did you think of it? The creator of it gave a (really good, entertaining) talk about it at Scala by the Bay a few months ago and I have been meaning to try it since then (the repl, not the shell), but haven't gotten around to it yet. Looks really promising. I'm on vacation for the rest of the month but plan to give it a shot afterwards; I will report back.
|
# ? Oct 18, 2015 16:57 |
|
I think the intentions of this are pretty clear; a case class (more just to convey the intention of immutability and for the free equals and hashCode than for pattern matching) that is only constructed from the companion's parameterless factories.code:
So my questions are 1) why? 2) is that how you implement what I'm trying to do? and 3) I guess whatever the convention is on factory methods that take no arguments and otherwise have no side effects, would you define and call otherFactory with parentheses just to match the apply version? I know it doesn't make a difference but it would bug me.
|
# ? Oct 27, 2015 05:43 |
|
KICK BAMA KICK posted:I think the intentions of this are pretty clear; a case class (more just to convey the intention of immutability and for the free equals and hashCode than for pattern matching) that is only constructed from the companion's parameterless factories. It's hard to know precisely what's going on, but I suspect you overloaded a factory method with the same number of arguments as the one created for you with the case keyword. This code works fine for me: code:
code:
|
# ? Oct 27, 2015 14:06 |
|
Didn't have any default arguments and I don't even know what the _* operator does. When I compile:code:
code:
|
# ? Oct 27, 2015 16:37 |
|
Foo() is short for Foo.apply(), but there's no function with that signature. There's a Foo.apply and a Foo.apply(Seq[Int]).
|
# ? Oct 27, 2015 16:41 |
|
Sedro posted:Foo() is short for Foo.apply(), but there's no function with that signature. There's a Foo.apply and a Foo.apply(Seq[Int]).
|
# ? Oct 28, 2015 03:42 |
|
KICK BAMA KICK posted:I don't even know what the _* operator does. When I compile: _* (the one-eyed man operator) is mildly useful: code:
code:
|
# ? Oct 31, 2015 20:19 |
|
Is Seq[] the Scala equivalent of C#'s IEnumerable<> or is there a more high-level interface for iterable things? VVV cool thanks Opulent Ceremony fucked around with this message at 18:46 on Nov 4, 2015 |
# ? Nov 4, 2015 17:13 |
|
The equivalent to IEnumerable<T> is probably TraversableOnce[T]. You generally don't deal with TraversableOnce though because collections APIs return the same type of collection (in C# you always get IEnumerable). If you want the lazy LINQ behavior from C# you can call .view on your collection. Seq[T] has an ordering and a length, and it might be mutable (unless you use immutable.Seq[T]). It's closer to IList<T>. Sedro fucked around with this message at 17:52 on Nov 4, 2015 |
# ? Nov 4, 2015 17:49 |
|
might be a coding horror, but is there a programmatic way to get the concrete parent class of an anonymous class? i.e. given val x = new Thing with SomeTraitAndNowImAnonymous is there a method on x I can call that will return Thing?
|
# ? Nov 5, 2015 00:36 |
|
Plain old Java reflection will work: x.getClass.getSuperclass
|
# ? Nov 5, 2015 01:26 |
|
FamDav posted:might be a coding horror, but is there a programmatic way to get the concrete parent class of an anonymous class? When I first started learning scala I found myself constantly at war with the type system. I've learned to really appreciate it's power since. In general if you find yourself fighting the type checker, you made a mistake earlier on in your design. It's hard to know what exactly the best solution for you is without the use case (implicit ClassTags?). That said, here is almost certainly something better than java reflection, especially given that once your class goes in a container, type erasure breaks reflection. Sedro posted:Plain old Java reflection will work: x.getClass.getSuperclass This works for the simple case FamDav described, but for an ad hoc anonymous class it's likely to be much less useful: code:
|
# ? Nov 5, 2015 03:13 |
|
it is for the dumbest of reasons - providing a className to a logger instance that is mixed in as a trait. edit: the logger trait isnt the trait being mixed in at instantiation time.
|
# ? Nov 5, 2015 17:36 |
|
FamDav posted:it is for the dumbest of reasons - providing a className to a logger instance that is mixed in as a trait. If whatever logging library you're using works the way I'd expect, it seems like the right thing to do is to just mix the logging trait in with the parent class. If you're using the class name as the identifier for the logger, any anonymous class that extends the parent class is going to use the same logger anyway. Instead of: code:
code:
|
# ? Nov 5, 2015 22:17 |
|
I'm working in an existing code base with a horrible method with 18 arguments, along the lines of:code:
code:
|
# ? Nov 10, 2015 18:05 |
|
Hughlander posted:I'm working in an existing code base with a horrible method with 18 arguments, along the lines of: I don't think there's a way to do that without either losing or repeating the default values of null.
|
# ? Nov 10, 2015 20:42 |
|
Right, you would have to repeat all the parameters. You baked in all the defaults as soon as you partially applied Foo. Only methods (Foo) can have default arguments; functions (myFoo) can't. I think you could write a macro.
|
# ? Nov 10, 2015 21:22 |
|
I wrote a small Scala app to try to find anagrams on Twitter. It uses Twitter4j to get a streaming sample of tweets and Slick with an embedded H2 database to save tweets and potential matches. It's using a lot more memory than I expected and I'd like to learn why, if that's good or bad, or if I should even care. I'm coming from .NET and don't have very much experience with the JVM or JVM memory usage. The code isn't special and is mostly copied from examples on the internet. However, after a few seconds the process starts using more than 2GB of memory. I didn't expect it to be that big. I used jmap to create a heap dump and jvisualvm to look at it. There's over a gig of just char[], byte[], and java.lang.String. From looking through the instances it looks like there are quite a few duplicates but otherwise there doesn't seem to be much out of the ordinary. Is this normal or expected? CPU usage starts out around 40% but then seems to drop to a steady state of 5%. I'm handling about 50 tweets a second and saving about 5% of them to the database. If I use -Xmx256m -Xms64m then the memory usage stays low but CPU usage stays high around 40% instead of 5%. Maybe this is due to all the extra garbage collecting it has to do for the heap to stay under 256MB? I had the thought of running this on a cheap Digital Ocean or Linode instance and maybe turning it into a bot but it seems to be a lot more resource-intensive than I imagined. Does anyone have any tips or resources for researching/minimizing memory usage in Scala apps? I'm kind of tempted to try the same thing in .NET or Python to see how the performance compares.
|
# ? Nov 18, 2015 19:43 |
|
Are you storing the database in memory? Try using H2 in persistent mode, or use sqlite.
|
# ? Nov 18, 2015 20:54 |
|
I am using it in persistent mode (db is about 225MB of candidate tweets and found matches now). I tried using SQLite in the beginning but had a lot of trouble getting Slick to generate the schema DDL for it so I switched to H2, but it wouldn't be too hard just to write it myself if I needed to switch. However I'm starting to get some actual anagrams so if I put this on a server and have multiple processes trying to access the database (like a Play application to manage which tweets get posted if I actually turn this into a bot) I'm worried SQLite wouldn't be a good choice since only one process can update SQLite at a time. H2 has a server mode so I figured it was a better choice if that happened. Maybe this isn't a concern at all.
|
# ? Nov 19, 2015 20:38 |
|
I'm an idiot. I was trying to perform a certain type of query about every 500ms to try to find anagrams and the query was taking over 1200ms. Since Slick is non-blocking and just returns futures, it was very easy to bombard the database with more queries than it could keep up with. I added an index on one column and my queries went from 1200ms to <20ms. There's no problem now and it uses <1% CPU and only 480MB of memory after running for over a day.
|
# ? Nov 27, 2015 05:10 |
|
O man a scala thread neat, I was a java programmer for about 4 years after graduating college and a scala dev for about a year at my current job which is a start up. Slick is awesome and terrible at the same time constantly!
|
# ? Nov 27, 2015 05:44 |
|
Cryolite posted:I'm an idiot. I was trying to perform a certain type of query about every 500ms to try to find anagrams and the query was taking over 1200ms. Since Slick is non-blocking and just returns futures, it was very easy to bombard the database with more queries than it could keep up with. If it's a read-heavy table, it's almost always worth creating an index for whatever high frequency queries you're running, provided you have the disk space. But yea, that moment when you realize the table never had an index...
|
# ? Nov 27, 2015 20:29 |
|
Has anyone here gotten Play projects in a multi-project SBT setup running in Intellij? I'm trying to build an Intellij project that has some common code shared between a Play project and some other executables, so to figure out how to do this I'm trying to run some activator templates that have multi-project SBT setups with one or more Play projects and some common code shared between them. For example, this one and this one. However whenever I try to run the Play apps through Intellij like shown here I get a "No main class detected." error. I can't seem to find a solution to this by googling. Doing sbt, project x, ~run through the command line works, but debugging seems like a pain that way. Does everyone do everything through the command line anyway? I really wish I could right-click and select "Run Play 2 App" but it only seems to work for the out-of-the-box single project template. Cryolite fucked around with this message at 07:04 on Dec 10, 2015 |
# ? Dec 10, 2015 06:54 |
|
You can do sbt x/run -jvm-debug 5005 then attach your remote debugger from Intellij.
|
# ? Dec 10, 2015 16:15 |
|
Sedro posted:You can do sbt x/run -jvm-debug 5005 then attach your remote debugger from Intellij. Thanks, I eventually got this working and it works great. I'm using Windows and had a lot of trouble initially getting it to listen. I ended up needing to do this to set SBT_OPTS before sbt myproject/run to get it to listen. Then connecting from Intellij was no problem. Now I can run and even debug multiple Play apps at a time. Neat!
|
# ? Dec 10, 2015 22:59 |
|
I commonly have to match on an Option of an instance of a sealed trait. It ends up being an awkward pattern and it really seems like there should be a cleaner way to do it. Supposed I have some code like:code:
code:
code:
|
# ? Dec 16, 2015 05:15 |
|
You can use @ to get the whole object for the thing matching the pattern-- the "have your cake and eat it too operator"code:
|
# ? Dec 16, 2015 05:22 |
|
edit: code:
|
# ? Dec 16, 2015 05:26 |
|
Ah of course. I've used @ but didn't realize you could nest it.
|
# ? Dec 16, 2015 06:07 |
|
After using scala for about a year... The good: 1. for comprehensions definitely can make using futures for async programming nice. The bad: 1. Linked List as the default data structure. 2. Implicits make reasoning about things hard. 3. Cake really should be called spaghetti. The ugly: 1. 'return' statement. 2. Collections libraries. Overall, my impression is that it's a nice research language that various people at big companies decided to use in production because it was cool rather than because it was ready.
|
# ? Dec 17, 2015 13:04 |
|
What's wrong with lists?
|
# ? Dec 17, 2015 16:28 |
|
Coming from C# where the List type is backed by an array (like ArrayList in Java) I know I was surprised to learn Scala's List is really a linked list. I expected a type named List to have the performance characteristics of an array-backed data structure. For idiomatic Scala (immutable and functional) I guess it makes sense for it to be a linked list. It's just different and I have to change my thinking when going back and forth.
|
# ? Dec 17, 2015 23:54 |
|
Tarion posted:After using scala for about a year... You mean linked lists as the default ordered collection. I don't see that as much of a negative. It's quite easy to use something different if need be, though there are a lot of warts (hidden or otherwise) in the collections library. I still prefer it to any other language's standard collections though. Implicits, if used excessively or improperly, can be tough, but it also enables some really great general patterns and simplifications if used well (see: typeclasses) I agree about the cake pattern. Gave it a try, do not like it. I much prefer the gradual and pragmatic approach outlined here: http://di-in-scala.github.io/ What about the return statement? You don't like that it exists? (I rarely use/encounter it) For what it is worth, I fully believe it is a production ready language, and use it as such. There are a lot of really high quality tools built with/for it. Finagle, in particular, I find to be excellent.
|
# ? Dec 18, 2015 04:59 |
|
Asymmetrikon posted:What's wrong with lists? This is ultimately a great summary: http://cglab.ca/~abeinges/blah/too-many-lists/book/#an-obligatory-public-service-announcement For me, it's mostly performance and the fact that working with non-linked sequences in scala just seems harder because every interface uses List, so I end up having to convert to a List anyways. Cryolite posted:Coming from C# where the List type is backed by an array (like ArrayList in Java) I know I was surprised to learn Scala's List is really a linked list. I expected a type named List to have the performance characteristics of an array-backed data structure. Idiomatic Scala is pseudo-functional. The fact that it's running on the JVM (and much of the time ends up needing to call Java code) and various other things make it way harder to actually benefit from the purity of functional programming, so I'm just left with poorly performing Lists everywhere. Steve French posted:You mean linked lists as the default ordered collection. I don't see that as much of a negative. It's quite easy to use something different if need be, though there are a lot of warts (hidden or otherwise) in the collections library. I still prefer it to any other language's standard collections though. I've never seen that di link before, but that's basically what I did for a codebase I'm working on that I got to write from scratch. Much nicer. And my point about production vs research language is more about the language than the tools and even more specifically about the design of the language and approach to it's design. The tools are fine.
|
# ? Dec 19, 2015 14:12 |
|
Where have you found that every interface uses lists? (what libraries, etc) That has not been my experience.
|
# ? Dec 19, 2015 17:29 |
|
|
# ? May 13, 2024 11:28 |
|
Most of the stuff I've seen uses Seq or F[_]: Whatever depending on whether it's functional or not. I wouldn't be enormously surprised though to discover that requiring lists had be come an idiom somewhere.
|
# ? Dec 20, 2015 05:40 |