论坛首页 综合技术版

新的Scala for NetBeans提供测试

浏览 2567 次
精华帖 (11) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
时间:2008-04-18 关键字: netbeans scala
重新写过的Scala for NetBeans现在可以在NetBeans 6.1RC或者最新的Nightly Build上测试,你可以从NetBeans Update Center获得,方法是:
"Tools"->"Plugins", 检查"Setting"看"Last Development Build"是否在Update Centers列表中, url是: http://deadlock.netbeans.org/hudson/job/javadoc-nbms/lastSuccessfulBuild/artifact/nbbuild/nbms/updates.xml.gz

如果你用的是Beta/RC/Release NetBeans 6.1, 你需要手工添加上述"Last Development Build" Update Center。

支持的功能有:

    * Syntax highlighting
    * Auto-indentation
    * Brace completion
    * Formatter
    * Outline navigator
    * Occurrences mark for local variables and function
    * Instance rename for local variables and function
    * Go-to-declaration for local variables and function
    * Scala project
    * Basic debugger


已知的问题有:

    * Auto-completion it not full supported yet and not smart
    * There is no parsing errors recovering yet
    * Semantic errors are not checked on editing, but will be noticed when you build project
    * Due to the un-consistent of Scala's grammar reference document, there may be some syntax broken issues


另外,Fortress的编辑插件也可以以同样的方法获得和安装,不过,这个插件还很弱。

Erlang的插件现在也可以同时安装在同一个NetBeans 6.1RC和Nightly Build上,不需要另外下栽ErlyBird了,同时,Indexing的性能有了很大提高,在我的机器上大约5分钟就行了。

Erlang插件将来也会重写。
   
时间:2008-04-18
dcaoyuan 写道

已知的问题有:

    * Auto-completion it not full supported yet and not smart
    * There is no parsing errors recovering yet
    * Semantic errors are not checked on editing, but will be noticed when you build project
    * Due to the un-consistent of Scala's grammar reference document, there may be some syntax broken issues


另外,Fortress的编辑插件也可以以同样的方法获得和安装,不过,这个插件还很弱。

Erlang的插件现在也可以同时安装在同一个NetBeans 6.1RC和Nightly Build上,不需要另外下栽ErlyBird了,同时,Indexing的性能有了很大提高,在我的机器上大约5分钟就行了。

Erlang插件将来也会重写。


最近也在学习Scala,先前试了一下以前版本的Scala for NetBeans,
我用它来看scala-compiler-src.jar中的源码,有很多错误,马上换到新版本试试。

同时也要向dcaoyuan大叔--一位真正的实干家---学习。
   
0 请登录后投票
时间:2008-04-18
刚装完,试了一下,比前一个版本好多啦。


另外,

能否告知jline.dll的源码在哪里?
在scala网站上下了几10M文件下来都找不到源码,
compiler源码中有些import进来的包不在scala-compiler-src.jar也不在scala-library-src.jar

谢谢!
  • 1ad75a70-f3e0-36bd-9df1-c32fef686141-thumb
  • 描述: Scala for NetBeans
  • 大小: 146 KB
   
0 请登录后投票
时间:2008-04-18
支持一下
PS:LS现在是用什么资料学习Scala呢?
习惯了命令式的编程,代码风格很难改变~
   
0 请登录后投票
时间:2008-04-18
自言200801 写道

能否告知jline.dll的源码在哪里?

http://jline.sourceforge.net
   
0 请登录后投票
时间:2008-04-18
自言200801图中的错误刚改掉了,明天下午Update一下Scala Editing插件就行了。
   
0 请登录后投票
时间:2008-04-18
dcaoyuan 写道
自言200801 写道

能否告知jline.dll的源码在哪里?

http://jline.sourceforge.net


非常感谢!

刚下完下来,我还一直以为是在Scala官方网站提供的,找好久都没找到,
我还以为Martin Odersky把这当成核心技术不想开源呢,原来在sourceforge网站上,还只是个处理终端输入的软件。

另外以“/ch/epfl/”开头的包的源文件也还没找到,我再多找找。

Scala官方网站文档还是太少。
   
0 请登录后投票
时间:2008-04-18
dcaoyuan 写道
自言200801图中的错误刚改掉了,明天下午Update一下Scala Editing插件就行了。


呵呵,速度真快,还3小时不到就改好啦。


不过我有点好奇:

你为Scala、Erlang做NetBeans上的插件,上次你说这插件主体是语言的parser,
那这parser是要做到什么程度呢?只是完成语法错误检查就行了吗?
语义层次的错误能检查出来吗?

NetBeans是内置javac的,
我去年跟“歆渊”在javaEye里讨论过了,
NetBeans里内置的javac能检测到数据流分析层次的错误(比如一个final变量是否正确赋值都能在editor中提示出来),

Scala、Erlang都是编译型的语言,按理说也能做到NetBeans内置的javac一样,
如果只是一个语法层次的parser,是不是显得功能弱了点?
如果做得再往下深几层,又差不多实现大半个编译器了,这样的话你不借助官方编译器提供接口自己实现难度不小。
   
0 请登录后投票
时间:2008-04-18
Eastsun 写道
支持一下
PS:LS现在是用什么资料学习Scala呢?
习惯了命令式的编程,代码风格很难改变~


上次你说你之前没FP的经验,我也是的,不过我先学了3个星期Erlang,所以再看Scala有关FP的东西也不难的。
推荐你看看Erlang/OTP的文档
Getting Started With Erlang
Erlang Reference Manual
最多花个两天,就会知道FP有关的概念啦。

我现在主要看ScalaReference.pdf(也就是:The Scala Language Specification Version 2.7)

呵呵,可能我跟你学Scala的目的不一样。
   
0 请登录后投票
时间:2008-04-19
自言200801 写道
dcaoyuan 写道
自言200801图中的错误刚改掉了,明天下午Update一下Scala Editing插件就行了。


呵呵,速度真快,还3小时不到就改好啦。

不过我有点好奇:

你为Scala、Erlang做NetBeans上的插件,上次你说这插件主体是语言的parser,
那这parser是要做到什么程度呢?只是完成语法错误检查就行了吗?
语义层次的错误能检查出来吗?

NetBeans是内置javac的,
我去年跟“歆渊”在javaEye里讨论过了,
NetBeans里内置的javac能检测到数据流分析层次的错误(比如一个final变量是否正确赋值都能在editor中提示出来),

Scala、Erlang都是编译型的语言,按理说也能做到NetBeans内置的javac一样,
如果只是一个语法层次的parser,是不是显得功能弱了点?
如果做得再往下深几层,又差不多实现大半个编译器了,这样的话你不借助官方编译器提供接口自己实现难度不小。


Scala目前的official compiler对IDE的支持不行,eclipse的插件就是基于它的,可是连Type都不能检测出来。这个Official compiler对于IDE的主要问题在于:
1、它是一个global builder,就是说哪怕你只敲了一个字符,如果想得到现在的AST就要做一次Global builder,这对IDE来说,性能是无法接受的,所以eclipse的插件只好让你保存时才做解析;
2、很吃内存,恐怕500M内存的机器根本不能跑;
3、Lexer的结果好像不能单独得到,而对于IDE来说,很多操作最好能在lexer层次就完成,比如着色、缩进、括号匹配等,甚至lexer还最好是增量的,这样才有好的性能。

目前我自己写的lexer和parser有这样一些特点:
1、lexer是增量的,
2、Parser的性能基本与文件大小是线性的,这样即使打开很大的文件,性能也是可预测和线性的;
3、Parser的内存消耗非常小;
4、Parse后AST的位置信息只是一个参考,随后转换成lexer的对应Token,这是非常重要的,因为我可以在将来实现增量的Parser;
5、Parser是自动由语法定义文件产生,我可以很快跟上Scala语言的变化

自己写Parser的一个最大的好处就是我已经慢慢积累了一些可以重用的类,这样,支持一门新的语言非常容易,这些类可以逐渐成为一组API,为NetBeans提供更好的扩展。

至于以IDE为目的的Parser和以编译、运行为目的的Parser的区别,简单说,就是IDE的parser不需要最后编译成字节码或解释运行,其他的功能指向也全都是IDE,目标明确。以Scala为例,在Parser上之上,我首先实现了一个语义分析器,目前的功能在一周左右的业余时间完成,接下来是一个比较完整的类型分析和检查。

没错,语义分析和类型分析compiler本来都已经做得好好的,但就象前面说的,除非象javac一样与IDE的开发人员密切合作,否则,还是没多大用处,IDE开发人员还是需要一次、两次地遍历这些结构,来产生IDE需要的信息。

语义层次的错误检查和类型检查都需要Global的信息,但我自己的做的好处是顺便与IDE的索引功能一起完成,反正都要做,干脆自己来。

IDEA和Eclipse为Scala的插件都干了很久了(若干年了),但实际结果证明,我的途径不是比他们都快吗?有一点你说的没错,我就是个实干家,喜欢动手、马上动手,喜欢推翻自己,喜欢从头再来,这样总比等别人来推翻好吧:-),软件不是房子,没有几十年都屹立在那里的,甚至越久越古典,当然理论除外。
   
0 请登录后投票
论坛首页 综合技术版

跳转论坛: