Tony Morris | 1 Apr 01:27 2008
Picon

Does the HEAD compile?


Maybe I am missing something (in the README? I couldn't find it), but
when I try to compile the HEAD:

[starr]
/tmp/scala/src/compiler/scala/tools/nsc/backend/msil/GenMSIL.scala:584:
error: value -- is not a member of List[GenMSIL.this.global.icodes.Local]
    [starr]         for (local <- m.locals -- m.params) {
    [starr]                                ^
    [starr]
/tmp/scala/src/compiler/scala/tools/nsc/backend/msil/GenMSIL.scala:864:
error: value - is not a member of
List[GenMSIL.this.global.icodes.BasicBlock]
    [starr]             val blocksToAdd = nextBlock :: (b - nextBlock)
    [starr]                                               ^
    [starr]
/tmp/scala/src/compiler/scala/tools/nsc/backend/msil/GenMSIL.scala:877:
error: value - is not a member of
List[GenMSIL.this.global.icodes.BasicBlock]
    [starr]                 blocksToPut = blocksToPut - x
    [starr]                                           ^
    [starr]
/tmp/scala/src/compiler/scala/tools/nsc/backend/msil/GenMSIL.scala:888:
error: value - is not a member of
List[GenMSIL.this.global.icodes.BasicBlock]
    [starr]                     blocksToPut = blocksToPut - x
    [starr]                                               ^
    [starr]
/tmp/scala/src/compiler/scala/tools/nsc/backend/msil/GenMSIL.scala:984:
error: value - is not a member of
(Continue reading)

Geoffrey Alan Washburn | 1 Apr 02:14 2008
Picon
Picon

Re: Does the HEAD compile?

Tony Morris wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Maybe I am missing something (in the README? I couldn't find it), but
> when I try to compile the HEAD:

The nightly build succeeded this morning and nothing has changed since 
yesterday, except that Ingo added some pending tests, so I would like to 
believe under the correct conditions it compiles.  Otherwise, there is 
something very wrong with the nightly build.  Perhaps you could clarify 
how you are trying to build it and on what platform.

Incidentally, speaking of correct conditions, I have never been able to 
build HEAD on my laptop running Ubuntu 7.10.  However, I get an entirely 
different failure than you are reporting.

Tony Morris | 1 Apr 02:28 2008
Picon

Re: Re: Does the HEAD compile?


Hi Geoffrey,
David MacIver confirmed that he can indeed compile the HEAD (Revision:
14472).

I am currently using Ubuntu 7.10 and I have tried various things such as
unsetting SCALA_HOME, removing /opt/scala/bin from PATH, performing a
clean check out, etc. I'm curious why you aren't able to compile either.

I'm not sure what more information I can provide, so I will just provide
everything I can think of (excuse the flood):

*delete delete delete* I just found the problem :)

I had set ANT_OPTS to contain scala.home=/opt/scala so that the <fsc>
ant task works properly (I am *so* over Ant). Removing it resolves the
issue.

Still, why can't you compile?

Tony Morris
http://tmorris.net/

Geoffrey Alan Washburn wrote:
> Tony Morris wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Maybe I am missing something (in the README? I couldn't find it), but
>> when I try to compile the HEAD:
(Continue reading)

Geoffrey Alan Washburn | 1 Apr 04:09 2008
Picon
Picon

Re: Does the HEAD compile?

Tony Morris wrote:

> I am currently using Ubuntu 7.10 and I have tried various things such as
> unsetting SCALA_HOME, removing /opt/scala/bin from PATH, performing a
> clean check out, etc. I'm curious why you aren't able to compile either.
> 
> I'm not sure what more information I can provide, so I will just provide
> everything I can think of (excuse the flood):
> 
> *delete delete delete* I just found the problem :)
> 
> I had set ANT_OPTS to contain scala.home=/opt/scala so that the <fsc>
> ant task works properly (I am *so* over Ant). Removing it resolves the
> issue.
> 
> Still, why can't you compile?

% cat /etc/issue 
                 Ubuntu 7.10 \n \l
% uname -a 
                 Linux nimrod 2.6.22-14-generic #1 SMP Tue Feb 12 
07:42:25 UTC 2008 i686 GNU/Linux
% echo $CLASSPATH 
                 zsh: CLASSPATH: parameter not set
% echo $SCALA_HOME 
                 zsh: SCALA_HOME: parameter not set
% echo $ANT_OPTS 
                 -Xmx1024M
% `which java` -version 
                 java version "1.6.0_03"
(Continue reading)

David Pollak | 1 Apr 04:48 2008
Picon

[lift] [ANN] lift developers abandon Scala in favor of Cobol

Folks,


It's with much excitement and enthusiasm that I'm announcing that the lift developers are abandoning lift development in Scala and instead turning our efforts to developing lift for Cobol, to be known as Heavy Lifting.

While lift development has been progressing well over the last 13 months, we've come to realize that the lift codebase is not growing very quickly, although lift's feature set and stability have both grown markedly.  This is wrong.

We've decided that we need a development environment where we can measure the value of the code base in lines of code rather than features and lack of defects.  Cobol with its extreme verbosity offers an ideal way to achieve this goal.

Further, we found that selling Scala into existing organizations is a challenge and got sick of hearing "Yeah, so Martin Odersky wrote javac 1.1-1.4 and designed the good parts of Java Generics, but what impressive thing has he done this year (other than being inducted to the ACM as a Fellow)?"  We found that hanging our hat on folks like Grace Hopper is just much easier because you can't argue with dead people.

Cobol offers a large "green-field" opportunity for developing a web framework and offers many lucrative consulting opportunities where we won't be hampered by an efficient language and an efficient framework, but can work to milk the clients for significantly larger fees while justifying the fees with the above mentioned "Lines of Code" metrics.

There are other factors influencing our decision.  They include the Scala community vs. the Cobol community.  No longer will we be mentally challenged by stimulating debates and discussions about language futures.  We'll not have to worry about parsing Tony's code or watching Jamie take a complex argument and distill to its very essence in the few short words.  No longer will we be shamed by Lex's warm approach to the community or Burak's tireless work to improve Scala.  No... we can say goodbye to all of that and instead mire in a community where they are still debating the best way to convert from ASCII to EBCDIC.

No, the lift committers are no longer worrying about language futures, the advantages of being pure and lazy.  Nope... not us.  We're worrying about formatting our comments and spewing forth 25 lines of code where 1 line of Scala would happily do the job.

Thanks Scala community for showing us the true light and allowing us to rise to the level where we belong: Cobol.  

David

PS -- April Fools

--
Scala lift off unconference, May 10th 2008, San Francisco http://scalaliftoff.com
lift, the secure, simple, powerful web framework http://liftweb.net
Collaborative Task Management http://much4.us

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "liftweb" group.
To post to this group, send email to liftweb-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to liftweb-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Andrew Gaydenko | 1 Apr 05:08 2008

Re: [ANN] lift developers abandon Scala in favor of Cobol

======= On Tuesday 01 April 2008, David Pollak wrote: =======
> Folks,
> It's with much excitement and enthusiasm that I'm announcing that the
> lift developers are abandoning lift development in Scala and instead
> turning our efforts to developing lift for Cobol, to be known as
> Heavy Lifting.
>
> While lift development has been progressing well over the last 13
> months, we've come to realize that the lift codebase is not growing
> very quickly, although lift's feature set and stability have both
> grown markedly.  This is wrong.
>
> We've decided that we need a development environment where we can
> measure the value of the code base in lines of code rather than
> features and lack of defects.  Cobol with its extreme verbosity
> offers an ideal way to achieve this goal.
>
> Further, we found that selling Scala into existing organizations is a
> challenge and got sick of hearing "Yeah, so Martin Odersky wrote
> javac 1.1-1.4 and designed the good parts of Java Generics, but what
> impressive thing has he done this year (other than being inducted to
> the ACM as a Fellow)?"  We found that hanging our hat on folks like
> Grace Hopper is just much easier because you can't argue with dead
> people.
>
> Cobol offers a large "green-field" opportunity for developing a web
> framework and offers many lucrative consulting opportunities where we
> won't be hampered by an efficient language and an efficient
> framework, but can work to milk the clients for significantly larger
> fees while justifying the fees with the above mentioned "Lines of
> Code" metrics.
>
> There are other factors influencing our decision.  They include the
> Scala community vs. the Cobol community.  No longer will we be
> mentally challenged by stimulating debates and discussions about
> language futures.  We'll not have to worry about parsing Tony's code
> or watching Jamie take a complex argument and distill to its very
> essence in the few short words.  No longer will we be shamed by Lex's
> warm approach to the community or Burak's tireless work to improve
> Scala.  No... we can say goodbye to all of that and instead mire in a
> community where they are still debating the best way to convert from
> ASCII to EBCDIC.
>
> No, the lift committers are no longer worrying about language
> futures, the advantages of being pure and lazy.  Nope... not us. 
> We're worrying about formatting our comments and spewing forth 25
> lines of code where 1 line of Scala would happily do the job.
>
> Thanks Scala community for showing us the true light and allowing us
> to rise to the level where we belong: Cobol.
>
> David

David, wrong decision! With assembler you'd reach much grandioser 
achievements and will get opportunity to please us with millions and 
millions LOC, not saying about registers optimization...

>
> PS -- April Fools

Russ Paielli | 1 Apr 05:43 2008
Picon

installing Scala on Solaris

I'm a Scala newbie, and I'm trying to install scala on Solaris. I am an aerospace engineer, not a system administrator. I have installed things before, but nothing very complicated.

I downloaded the 2.7 version, but I see no information on installing it. I realize that it's probably right in front of my face, but I'll be darned if I can find it. I have also searched the web, and I see all kinds of information on using scala, but very little about installing it.

I don't have root privilege, but I just want to install it for my own use for now. If anyone can lead me to some basic instructions on installing scala on Solaris, I will really appreciate it. Thanks.

--Russ

Daniel Green | 1 Apr 06:11 2008
Picon

Re: [ANN] lift developers abandon Scala in favor of Cobol

> David, wrong decision! With assembler you'd reach much grandioser
> achievements and will get opportunity to please us with millions and
> millions LOC, not saying about registers optimization...
>
On that note, what about, heaven forbid, Java? No, that's taking the
joke too far... ;-) *ducks and runs for cover*

On Mon, Mar 31, 2008 at 8:08 PM, Andrew Gaydenko <a <at> gaydenko.com> wrote:
> ======= On Tuesday 01 April 2008, David Pollak wrote: =======
>
> > Folks,
> > It's with much excitement and enthusiasm that I'm announcing that the
> > lift developers are abandoning lift development in Scala and instead
> > turning our efforts to developing lift for Cobol, to be known as
> > Heavy Lifting.
> >
> > While lift development has been progressing well over the last 13
> > months, we've come to realize that the lift codebase is not growing
> > very quickly, although lift's feature set and stability have both
> > grown markedly.  This is wrong.
> >
> > We've decided that we need a development environment where we can
> > measure the value of the code base in lines of code rather than
> > features and lack of defects.  Cobol with its extreme verbosity
> > offers an ideal way to achieve this goal.
> >
> > Further, we found that selling Scala into existing organizations is a
> > challenge and got sick of hearing "Yeah, so Martin Odersky wrote
> > javac 1.1-1.4 and designed the good parts of Java Generics, but what
> > impressive thing has he done this year (other than being inducted to
> > the ACM as a Fellow)?"  We found that hanging our hat on folks like
> > Grace Hopper is just much easier because you can't argue with dead
> > people.
> >
> > Cobol offers a large "green-field" opportunity for developing a web
> > framework and offers many lucrative consulting opportunities where we
> > won't be hampered by an efficient language and an efficient
> > framework, but can work to milk the clients for significantly larger
> > fees while justifying the fees with the above mentioned "Lines of
> > Code" metrics.
> >
> > There are other factors influencing our decision.  They include the
> > Scala community vs. the Cobol community.  No longer will we be
> > mentally challenged by stimulating debates and discussions about
> > language futures.  We'll not have to worry about parsing Tony's code
> > or watching Jamie take a complex argument and distill to its very
> > essence in the few short words.  No longer will we be shamed by Lex's
> > warm approach to the community or Burak's tireless work to improve
> > Scala.  No... we can say goodbye to all of that and instead mire in a
> > community where they are still debating the best way to convert from
> > ASCII to EBCDIC.
> >
> > No, the lift committers are no longer worrying about language
> > futures, the advantages of being pure and lazy.  Nope... not us.
> > We're worrying about formatting our comments and spewing forth 25
> > lines of code where 1 line of Scala would happily do the job.
> >
> > Thanks Scala community for showing us the true light and allowing us
> > to rise to the level where we belong: Cobol.
> >
> > David
>
> David, wrong decision! With assembler you'd reach much grandioser
> achievements and will get opportunity to please us with millions and
> millions LOC, not saying about registers optimization...
>
> >
> > PS -- April Fools
>

Zemian Deng | 1 Apr 06:33 2008
Picon

how to use BeanInfo?

Hi,
 
I tried following and I dont see setter and getter generated. Did I misused it?
 
//A.scala
<at> scala.reflect.BeanInfo
class A {
  var x:String = _
}
 
$ scalac A.scala
$ javap A
Compiled from "A.scala"
public class A extends java.lang.Object implements scala.ScalaObject{
    public A();
    public void x_$eq(java.lang.String);
    public java.lang.String x();
    public int $tag();
}


--
Thanks,
Zemian Deng
Windemuth Andreas | 1 Apr 07:21 2008
Picon

Re: Scala for scientific computing

I think this is a very important issue. There must be some optimization already going on, since array access
seems to be very fast. Something like the following:

    var n = 1
    var i = 1
    val arr = new Array[Int](100)
    while (n<10000000) {
      arr(i-1) = arr(i)
      i += 1
      if (i>=100) {
        i = 1
        n += 1
      }
    }

finishes far too quickly to be doing a billion object allocations or method calls. Yet, supposedly,
everything is an object, and some apply() and update() methods are being called on Array. I don't think so.

I tend to think that whatever makes the above so fast could also be extended to handle those small immutable
objects and a lot of other optimizations that are made possible by strong typing and controlled side effects.

Notnull types could make method calls faster by reducing null pointer checking. Range types could make
array access faster by reducing index bounds checking. Multidimensional arrays could be mapped over
vectors rather than as arrays of arrays to improve access times. Wrappers could be unwrapped. Most of all,
as the OP observed, objects could be inlined as "struct"s, particularly inside collections, as long as
dynamic method dispatch is not needed.

Scientists will say: Great, I can elegantly express myself with a mathematical style. I have a compiler to
do most of the debugging for me. I can easily create and maintain large libraries of reusable data
processing components. But can it run my algorithms fast enough?

Because of extensive JVM optimizations, Java can be quite as fast as C.Scala could do even better, I think,
and it would be a shame if thatpotential was not realized.

Andreas

----- Original Message ----
From: martin odersky <martin.odersky@...>
To: Martin Orr <martin@...>
Cc: Konrad Hinsen <konrad.hinsen@...>; scala-user@...
Sent: Monday, March 31, 2008 9:58:09 AM
Subject: Re: [scala-user] Scala for scientific computing

On Mon, Mar 31, 2008 at 3:50 PM, Martin Orr <martin@...> wrote:
> On 31/03/08 13:37, Konrad Hinsen wrote:
>
>  >>>  - Small immutable objects. Many scientific applications need number-
>  >>>  like types that are characterized by being small (in terms of
>  >>>  memory), immutable, and very frequently created in mathematical
>  >>>  expressions. Examples are complex numbers, points in 2D or 3D space,
>  > ...
>  >>>  functional programming, I wonder if Scala does better there.
>  >>
>  >> As far as I know, it doesn't. The JVM makes it pretty difficult to do
>  >> and Scala's semantics encourage but don't require immutability and a
>  >> lack of side effects.
>  >
>  > I don't see how the JVM could be an obstacle. In the situations I am
>  > thinking off, an optimizing compiler would optimize the whole class away
>  > and replace its methods by inlined code operating on basic data types.
>  > For example, arithmetic on complex numbers would be replaced by
>  > operations on the real and complex parts, represented by floats. The JVM
>  > would never see the original class, although it might be
>  > necessary/desirable to have a class version of "complex" around as well
>  > for specific situations.
>
>  Well the JVM is an obstacle in that methods can only return objects or
>  primitive values.  So as soon as you return the value from a function, you
>  have to construct the object.  And if you are programming in a functional
>  style, you will probably have lots of small functions.
>
I am fairly sure that recent JVM implementations do an escape analysis
to detect opportunities when objects can be allocated on the stack. In
that case the performance gain of rolling your own scheme would
probably be negative.

The one area where optimization might help is in specializing generic
types. For instance, replacing List[Int] by a special IntList would
avoid having to box all list elements. Optimizations like that might
be necessary to make generic multi-dimensional arrays efficient for
common cases (where the elements are primitive types).

Cheers

 -- Martin

      ____________________________________________________________________________________
Like movies? Here's a limited-time offer: Blockbuster Total Access for one month at no cost. 
http://tc.deals.yahoo.com/tc/blockbuster/text4.com


Gmane