headers
Burak Emir | 1 Apr 2004 12:50
Picon
Picon
Favicon

servletHowTo update

Hi there,

I rearranged the distribution a bit, after receiving bug reports of 
weird behaviour when using outdated scala version.

You can download the 0.6 version of the tutorial AND my latest 
development version of the Scala runtime and try again.
You will need to edit the "ant.properties" file before 
building,deploying....

http://lamp.epfl.ch/~buraq/projects

BTW: Of course, you are not forced to use Tomcat as your servlet engine, 
every other should work as well... If you prefer some other servlet 
engine, you can adapt the build.xml such that it finds the right 
"servlet-apis.jar". The javax.servlet interfaces , and the Scala 
runtime, are the only outward dependencies of the howTo code.

cheers,
Burak
Permalink | Reply | 0 comments |
headers
Morgan Hankins | 1 Apr 2004 21:53

Iterator problem


Hi all,

I am having trouble defining my own Iterator.
I noticed that Scala Implementation Status issue #8 says that the source
must be available for all trait classes, so i tried
adding that to the scalac command line, but with no luck.
I checked scala.jar and there is no Iterator$$anon$2.
I am running 1.1.1.0.

Any Ideas?

thanks,
-m

output
---------
[m <at> h scala]$ scalac -sourcepath /apps/scala/src -d ~/lang/java/classes
src/mo/rejectCodes.scala
[m <at> h scala]$ scala mo.ReaderIteratorTest /tmp/y "|"
Exception in thread "main" java.lang.NoClassDefFoundError:
scala/Iterator$$anon$2
        at mo.JavaReaderIterator$class.filter(rejectCodes.scala:114)
        at mo.ReaderIteratorTest$.main(rejectCodes.scala:14)
        at mo.ReaderIteratorTest.main(rejectCodes.scala:10)

rejectCodes.scala
--------------------------
package mo;
import java.io._;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michel Schinz | 2 Apr 2004 14:22
Picon
Picon
Favicon

Re: Iterator problem

Morgan Hankins <mhankins <at> merchante-solutions.com> writes:

> Hi all,

Hello,

[...]

> I checked scala.jar and there is no Iterator$$anon$2.
> I am running 1.1.1.0.
>
> Any Ideas?

You unfortunately encountered a bug in the compiler, which can
sometimes give different names to anonymous classes in two successive
compilations.

Until we fix it (which we'll do quickly, hopefully) a workaround is to
extend the Iterator class instead of mixing it in. That is, change the
line which says

 class JavaReaderIterator(jreader: java.io.BufferedReader) with
   Iterator[String] {

with one saying

 class JavaReaderIterator(jreader: java.io.BufferedReader) extends
   Iterator[String] {

Sorry for that,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Morgan Hankins | 2 Apr 2004 20:05

state of scalaint


I am having trouble using scalaint. I can't seem to extend scala traits (ie
Iterator)
and use them from scalaint:

[m <at> h mo]$ scalaint
  __ __  _      _
 (_ /   /_||   /_|   INTERPRETER
___)\__/  ||__/  |   (c) 2002-04, LAMP/EPFL

 version: 1.1.1.0
 type :? to get a list of all interpreter commands

> import mo._

> var jai:Iterator[String] = new mo.JavaReaderIterator(null)
<console>:1: type mismatch;
 found   : mo.JavaReaderIterator
 required: scala.Iterator[java.lang.String]
var jai:Iterator[String] = new mo.JavaReaderIterator(null)
                           ^

JavaReaderIterator.scala
-----------------------
package mo;

import java.io._;

class JavaReaderIterator(jreader: java.io.BufferedReader) extends
Iterator[String] {
(Continue reading)

Permalink | Reply | 501 comments |
headers
Wayne Vucenic | 3 Apr 2004 08:56
Favicon

Windows installer problem

Scala is a really nice language, and I'm enjoying working with it.

I noticed a problem with the Windows installer.  The installer erases
whatever was in the user "path" environment variable (not the system
path environment variable) and replaces it with the string
"%PATH%;%SCALA_HOME%\bin".  This has the effect of setting the user
path to be the same as the system path, but with the Scala bin
directory appended to it.  (Of course, the original contents of the
user path is lost.)

Thanks,

Wayne
No Bugs Software
"Contract Programming in Silicon Valley"
Permalink | Reply | 1 comment |
headers
Jason Haslam | 3 Apr 2004 10:40

Question about references in scala

I'm sorry if this is a stupid question.  I have been trying to make a 
data structure with a cyclic reference to itself.  I thought that I 
could do something like:

object Test with Application {
	import scala.collection.mutable._;
	
	var xs:LinkedList[Int] = _;
	xs = new LinkedList[Int](1, xs);
	
	def unboundedPrint(xs: LinkedList[Int]): Unit = {
		Console.println(xs.elem);
		unboundedPrint(xs.next);
	}
	
	unboundedPrint(xs);
}

This code throws a null pointer exception the first time next is called 
on the list.  However, I have found that the following works as 
expected (i.e. continuously prints out 1).

object Test with Application {
	import scala.collection.mutable._;
	
	val xs:LinkedList[Int] = new LinkedList[Int](1, null);
	xs.next= xs;
	
	def unboundedPrint(xs: LinkedList[Int]): Unit = {
		Console.println(xs.elem);
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nikolay Mihaylov | 3 Apr 2004 13:57
Picon
Picon
Favicon

Re: Question about references in scala

On Saturday 03 April 2004 10:40, Jason Haslam wrote:
>  I thought that I could do something like:
>
>     ...
> 	var xs:LinkedList[Int] = _;
> 	xs = new LinkedList[Int](1, xs);

When you define the xs variable it gets initialized to null. Consequently, 
when the right-hand side of the assignment is being evaluated, the tail of 
the newly created LinkedList will be set to null. Only then will xs be 
assigned the object reference. When you later use your unboundedPrint 
function, the NullPointerException is thrown not when you apply xs.next, but 
rather when in the body of unboundedPrint you try to access xs.elem.

With respect to that, Scala is not much different than Java. That's why I 
don't really buy your claim that in Java it works both ways. What you would 
write in Java will be some equivalent of your working Scala example:

 val xs:LinkedList[Int] = new LinkedList[Int](1, null);
 xs.next= xs;

I guess you wrote it like that because the compiler wouldn't let you write it 
on one line:

 val xs:LinkedList[Int] = new LinkedList[Int](1, xs);

The reason is that you can not (or rather, should not, because the runtime 
initializes them with some predefined value, like null for reference types) 
use a value before you compute it. The Java compiler too will tell you that 
you can not do that.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Haslam | 4 Apr 2004 00:57

Re: Question about references in scala

On Apr 3, 2004, at 4:57 AM, Nikolay Mihaylov wrote:

>  ...
> With respect to that, Scala is not much different than Java. That's 
> why I
> don't really buy your claim that in Java it works both ways. ...

You're absolutely right.  I should have tested this claim before I made 
it.  After trying it in Java I even think that I understand why it 
doesn't work in either language.

> I guess you wrote it like that because the compiler wouldn't let you 
> write it
> on one line:
>
>  val xs:LinkedList[Int] = new LinkedList[Int](1, xs);

As a matter of fact I tried this and thought it a bit odd that the 
compiler did allow it, but it gave the same null pointer exception as 
my first example.

> If you want to implement self-referencing immutable datastructures, 
> you'll
> have to resort to lazy evaluation. Otherwise, you'll get into an
> initialization cycle that will raise StackOverflowError or 
> OutOfMemoryError.
> If what you need is a lazy list, you can use a stream. You contstruct a
> stream using the cons method of the scala.Stream object
>
>   def xs: Stream[Int] = Stream.cons(1, xs);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nikolay Mihaylov | 4 Apr 2004 01:06
Picon
Picon
Favicon

Re: Question about references in scala

On Saturday 03 April 2004 22:50, Jason Haslam wrote:

> >  val xs:LinkedList[Int] = new LinkedList[Int](1, xs);
>
> As a matter of fact I tried this and thought it a bit odd that the
> compiler did allow it, but it gave the same null pointer exception as
> my first example.

I'm really surprised to see this compiling without a hitch. I was so sure it 
wouldn't compile that I didn't even test it. Silly me!

> I hate to ask another, possibly stupid, question, but what would be the
> difference between def and val here.  Doesn't seem to make much
> difference to the compiler.  I had thought that def was for defining
> functions and val for values.  On the other hand, I guess that
> functions are values too so I don't know what to think.

The use of def isn't in fact necessary. While trying different possibilities 
spurred by your initial question, I couldn't compile

  val xs: Stream[Int] = Stream.cons(1, xs);

which was reject with "illegal forward reference" error message. Using def 
fixed it. However, I can now compile it so I guess I did sth wrong. In this 
particular case, val is what we need.

The difference between val and def definitions is that the right-hand side of 
a val definition is only evaluated once. For class-level val definitions 
thist happens during object creation, in the constructor. Then every 
reference to it is simply retrieving the initial value. For the example
(Continue reading)

Permalink | Reply | 1 comment |
headers
Miles Sabin | 4 Apr 2004 12:24
Gravatar

Member types in Scala

I've been trying to get a feel for Scala's type system by playing with 
some of the ideas in Matthias and Martin's paper "Independently 
Extensible Solutions to the Expression Problem". Unfortunately I've run 
into a problem with member types which suggests I haven't quite got it 
yet.

Here's an example which illustrates my problem,

  package com.milessabin.example;

  trait Base
  {
    trait TBase
    {
      def f = Console.println("Hello world");
    }
  }

  class Derived
    extends Base
  {
    class TDerived
      extends TBase;
  }

  object Example with Application
  {
    val d = new Derived;
    val v = new d.TDerived;
(Continue reading)

Permalink | Reply | 6 comments |

Gmane