http://permalink.gmane.org/gmane.comp.lang.scala hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.scala/13776 Scalads and lasses, Has anyone written an xsd processor (to check conformance of documents, generate documents, etc) in scala? Last night i did the most basic qa on jaxb you could imagine -- apply jaxb to the schema for schema . As you can guess, it failed. This would be like gcc failing to build gcc -- not acceptable. i'm hoping there's a higher quality offering somewhere in the functional arsenal. (Interestingly, the W3C-blessed XMLSchema.xsd doesn't conform to itself! At least you can fix this, though.) Best wishes, --greg Meredith Gregory 2008-10-07T16:46:51 http://permalink.gmane.org/gmane.comp.lang.scala/13774 Also, you can do "import scala.collections.mutable.jcl.Conversions._" in your file to scope a bunch of implicit conversions that automatically convert between Java and Scala collections. Sean On Tue, Oct 7, 2008 at 6:15 AM, Erik Engbrecht <erik.engbrecht< at >gmail.com> wrote: Sean McDirmid 2008-10-07T01:53:32 http://permalink.gmane.org/gmane.comp.lang.scala/13773 Mea culpa. I usually run what I post through the interpreter first to make sure I am posting the right code, but this time I took a short cut and just typed it in (incorrectly, as you point out) rather than pasting what I ran through the interpreter. One more experience to support the practice of full unit testing. In this case both Int and String are final classes, so I think specifying [I<:Int] should be the same as requiring an Int as in the first approach. I think the approach should work even for non-final classes, since the type parameter to Option is covariant, but I haven't tried it, so there may be some issue I am not aware of - or I may be getting my co and contra confused. I thought it was interesting that the first approach led to compiler error messages and the second did not, so the error is apparently not due solely to type erasure. -- Jim Jim McBeath 2008-10-06T23:20:38 http://permalink.gmane.org/gmane.comp.lang.scala/13772 What industry do you work in? "...the existence of this documentation seems inevitable" ??? Sorry...I couldn't help it... There's the scala.collections.mutable.jcl (or something like that) for wrapping Java collections to make them look like mutable Scala collections. I'm not aware of anything for the other way around, but it's been a while since I looked. On Mon, Oct 6, 2008 at 6:09 PM, Meredith Gregory <lgreg.meredith< at >gmail.com>wrote: Erik Engbrecht 2008-10-06T22:15:28 http://permalink.gmane.org/gmane.comp.lang.scala/13771 Scalads and lasses, Where is the documentation for the conversion idioms for the usual java collections collected? i've been grepping/searching/... for an hour now and cannot find a nicely collected set of documents describing the various ways to do this. Surely, surely, the vast majority of collections originate in Java and move toward Scala perhaps finally make it back to Java. So, the existence of this documentation seems inevitable. Best wishes, --greg Meredith Gregory 2008-10-06T22:09:13 http://permalink.gmane.org/gmane.comp.lang.scala/13770 FYI that's not what was originally posted, and those don't do what they might appear to do. The original versions had no type parameters: implicit def optIntToString(n:Option[Int]) = n.get.toString implicit def optStringToString(s:Option[String]) = s.get.toString The two methods up top each has a type parameter, the first calling it "Int", the second "String", and in reality they're the same method. I found a while ago that it's wise to always explicitly state return types in implicits, and in this case that would have shown the error because the type parameter String shadows java.lang.String. scala> implicit def optStringToString[String](s:Option[String]): String = s.get.toString <console>:4: error: type mismatch; found : java.lang.String required: String implicit def optStringToString[String](s:Option[String]): String = s.get.toString The method parameter lists still have the same erasure, but now the methods are polymorphic with different type bounds. Paul Phillips 2008-10-06T16:26:49 http://permalink.gmane.org/gmane.comp.lang.scala/13769 Based on this suggestion, I tried changing my implicits from this (as originally posted): implicit def optIntToString[Int](n:Option[Int]) = n.get.toString implicit def optStringToString[String](s:Option[String]) = s.get.toString to this: implicit def optIntToString[I<:Int](n:Option[I]) = n.get.toString implicit def optStringToString[S<:String](s:Option[S]) = s.get.toString With this slightly modified definition, the assignment that used to fail: val s2:String = Some(123) now works, although the erasures are still identical. -- Jim Jim McBeath 2008-10-06T00:56:11 http://permalink.gmane.org/gmane.comp.lang.scala/13768 On Sun, 05 Oct 2008 22:31:11 +0200, David MacIver <david.maciver< at >gmail.com> wrote: There seems to be some issues with implicits and higher-ordered types used together. I while ago, I reported http://lampsvn.epfl.ch/trac/scala/ticket/298, which still isn't solved. The issues are not identical, but they're probably related. / Rickard Rickard Nilsson 2008-10-05T21:48:24 http://permalink.gmane.org/gmane.comp.lang.scala/13767 The parameter lists for the two implicit methods have the same erasure. I feel like this is the root of the problem, but I can't explain it satisfactorily because type inference should take place before erasure. Since the error reports the type of Some(123) as Some[?A] it seems safe it's not Some[Int], which is what it is in the one which works. Notice it works if we approach the implicit differently: scala> val s2 = Some(123) + "b" s2: java.lang.String = 123b If you parameterize the implicit it works as you want: scala> implicit def optToString[T](s: Option[T]): String = s.get.toString optToString: [T](Option[T])String scala> val s2: String = Some(123) s2: String = 123 I also wonder about the later message: I don't think scala will be seeing that required "String with Int" anytime soon. Paul Phillips 2008-10-05T20:50:48 http://permalink.gmane.org/gmane.comp.lang.scala/13766 If you add a type parameter to Some then it works. i.e. val s2 : String = Some[Int](123) so I think what's happening here is that it's seeing that you have an Option[T], determining that this isn't a String and immediately trying to force an implicit conversion before attempting to resolve the type parameter of Option and discovering that it doesn't have enough information at that point. It looks like a bug to me, but I suspect it might be a difficult one to resolve (just guessing. I know very little about the type inferencer). Still worth filing. David MacIver 2008-10-05T20:31:11 http://permalink.gmane.org/gmane.comp.lang.scala/13765 Jorge, Yes, I know. The body of the implicit conversion is irrelevant to the example, I was trying to cut the code down to the minimum that would exhibit the issue. -- Jim On Sun, Oct 05, 2008 at 12:28:11PM -0700, Jorge Ortiz wrote: Jim McBeath 2008-10-05T20:21:35 http://permalink.gmane.org/gmane.comp.lang.scala/13764 I don't know about your particular error, but using an implicit conversion that calls "get" on an Option defeats the whole point of using Options. It works fine for Some, but when you have a None the implicit conversion will just throw an exception. This quickly becomes as bad as or worse than NullPointerExceptions. --j On Sun, Oct 5, 2008 at 12:11 PM, Jim McBeath <scala< at >j.jimmc.org> wrote: Jorge Ortiz 2008-10-05T19:28:11 http://permalink.gmane.org/gmane.comp.lang.scala/13763 //Set up two implicit conversions to Option[something] implicit def optIntToString(n:Option[Int]) = n.get.toString implicit def optStringToString(s:Option[String]) = s.get.toString val s1:String = { val opt = Some(123); opt } //OK, returns "123" val s2:String = Some(123) //compiler error, ambiguous implicit conversion I get this error for the s2 assignment: error: type mismatch; found : Some[?A] required: String Note that implicit conversions are not applicable because they are ambiguous: both method optStringToString in object $iw of type (Option[String])java.lang.String and method optIntToString in object $iw of type (Option[Int])java.lang.String are possible conversion functions from Some[?A] to String <console>:6: error: type mismatch; found : Int(123) required: String with Int val s2:String = Some(123) Why is the compiler able to figure out how to convert to s1 but not to s2? It seems to me that it has the same information available in b Jim McBeath 2008-10-05T19:11:04 http://permalink.gmane.org/gmane.comp.lang.scala/13762 Ok, after more thought, I guess filter would count as a leaf operation, because of the lazy projection. Anyway, in that case, I _did_ execute the leaf a 100 million times (10000 * 10000), in each benchmark. Harshad 2008-10-05T18:49:50 http://permalink.gmane.org/gmane.comp.lang.scala/13761 And in order to do something shocking and back an opinion with actual evidence, here's some code: trait IntAction{ def apply(i : Int) : Unit; } object IntLoop{ def times(size : Int, action : IntAction) { var i = 0; while(i < size){ action(i); i += 1; } } } object LoopBenchmark extends scalax.testing.SizedBenchmark{ var sum = 0; override val sizes = Array.range(0, 22).map(i => 1 << i) new Benchmark[Int]("while"){ def data(size : Int) = size; def test(size : Int) = { var i = 0; while (i < size){ i += 1; sum += i; } } } new Benchmark[Int]("IntLoop"){ def data(size : Int) = size; def test(size : Int) = { IntLoop.times(size, new IntAction(){ def apply(i : Int) { sum += i; } }) } } } And here are some numbers for running it on the Java 6 server VM (the client VM gives similar results): scala> LoopBenchmark.main(null) Size, while, IntLoop 1, 0.9288, 1.4625 2, 1.4897, 2.1465 4, 1.8854, 2.6 David MacIver 2008-10-05T15:06:06 http://permalink.gmane.org/gmane.comp.lang.scala/13760 Impressive! Thanx for the info. Respectfully yours, Christos. On Sun, Oct 5, 2008 at 4:58 PM, David Pollak <feeder.of.the.bears< at >gmail.com>wrote: Christos KK Loverdos 2008-10-05T14:43:24 http://permalink.gmane.org/gmane.comp.lang.scala/13759 It sound too general a statement to me. It only makes sense, when benchmarking leaf operations, and trying to find the asymptotic upper-bound of the operation. It doesn't make sense when, * trying to measure performances of non-leaf operations, and hence, * trying to compare the constant time factor in the operation. Yes, I didn't do a comprehensive benchmark. That said, we should see if the optimisation helps on any given JVM, regardless if different JVMs don't compare well to each other. My JVM is: (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_03) on a x86 (Core 2 Duo) Yes, and that resulted in: https://lampsvn.epfl.ch/trac/scala/ticket/1402 It is a good point. IMHO, possible solutions could be either * the (new) semantic meaning of for could be documented, or, * the semantic meaning of filter could be clarified (and needs to be adhered to) Either way, it means a semantic change and perhaps only doable in a major version bump. Harshad 2008-10-05T14:42:41 http://permalink.gmane.org/gmane.comp.lang.scala/13758 On Sun, Oct 5, 2008 at 3:02 PM, David Pollak <feeder.of.the.bears< at >gmail.com> wrote: And not improving something because making it better for non-broken code might break broken code is worse. Sorry, I don't know how to respond to an unbacked assertion which flies in the face of observed facts. Could you rephrase that as a useful sentence? David MacIver 2008-10-05T14:25:57 http://permalink.gmane.org/gmane.comp.lang.scala/13757 I don't see why we'd want to shut off inheritance, just put them in a separate tree and don't give them anyref by default. I guess one model that we could follow would be .NET with its separate inheritance tree for delegates, though delegates seem to be objects there. Sean On Sun, Oct 5, 2008 at 10:22 PM, David MacIver <david.maciver< at >gmail.com> wrote: Sean McDirmid 2008-10-05T14:27:46 http://permalink.gmane.org/gmane.comp.lang.scala/13756 I don't think that would be particularly beneficial. For example a lot of things extend Function, so many functions legitimately are AnyRefs. The only functions one should really be aggressively optimised are ones created locally as lambdas. David MacIver 2008-10-05T14:22:35 http://permalink.gmane.org/gmane.comp.lang.scala/13755 ======= On Sunday 05 October 2008, David Pollak wrote: ======= ... David, It is off topic, but about you and performance :-) Probably my memory is wrong, but AFAIR there was a mailing list thread in which you resolved some problem wrt performance of Scala combinators. Will you be so kind to point me that discussion? The thing is, I use the combinators for simple text templating, and they are bottleneck in all request-processing-response chain in my httpd service (say, 900 req/seq with simple template vs 7000 req/seq with direct the ~same stream writing). Andrew Andrew Gaydenko 2008-10-05T14:20:22 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.scala