Project1

标题: 【未完成】RGSS3小探——面向编辑器 [打印本页]

作者: DeathKing    时间: 2012-1-25 20:42
标题: 【未完成】RGSS3小探——面向编辑器
本帖最后由 DeathKing 于 2015-5-2 16:31 编辑

--- DELETE BY POSTER --

fiber_sta.png (8.1 KB, 下载次数: 39)

fiber_sta.png

作者: orzfly    时间: 2012-1-25 22:55
不得不说,非常佩服DK的语言表达能力啊……例子真是太棒了。
作者: 逸豫    时间: 2012-1-25 23:18
本帖最后由 逸豫 于 2012-1-25 23:25 编辑

遇到Fiber.yield后跳出Fiber当下一次resume时将传入的数据当作上次中断的yield的值么……
老大哥……1984么= =
作者: 菜鸟飞呀飞    时间: 2012-1-26 07:07
提示: 作者被禁止或删除 内容自动屏蔽
作者: DeathKing    时间: 2012-1-26 09:51
菜鸟飞呀飞 发表于 2012-1-26 07:07
为啥resume2次就dead了?
难道第一次是Created 第二次是Running 第三次是Terminated
但为什么把yield包在lo ...

执行到代码尾才是Dead。否则就算被挂起也是Running,那个图只是想表达不可能不经过Running状态直接变为Dead。
作者: DeathKing    时间: 2012-1-26 09:52
逸豫 发表于 2012-1-25 23:18
遇到Fiber.yield后跳出Fiber当下一次resume时将传入的数据当作上次中断的yield的值么……
老大哥……1984么 ...

是这样的。   PDF档里面的尾注说明了老大哥的来历。
作者: 逸豫    时间: 2012-1-26 14:20
說起來RGSS還真是費盡一切心思迴避eval……連send都用上就是不用eval= =
貌似整個RGSS3也就出現過3次eval,而且都是處理用戶輸入腳本的時候才用= =
作者: orzfly    时间: 2012-1-26 14:53
逸豫 发表于 2012-1-26 14:20
說起來RGSS還真是費盡一切心思迴避eval……連send都用上就是不用eval= =
貌似整個RGSS3也就出現過3次eval, ...

看帮助文件里面的几个内部类定义,在计算伤害公式的地方也用到了。Kernel.eval

eval是能不用就不用,会不安全什么的吧。




看帮助文件里面的几个内部类定义,在计算伤害公式的地方也用到了。Kernel.eval

eval是能不用就不用,会不安全什么的吧。


──orzfly于2012-1-26 14:53补充以上内容’
作者: DeathKing    时间: 2012-1-26 19:06
@逸豫@orzfly

我认为不安全是其一,开销大算其二。具体是什么我就真不知道了。
作者: 忧雪の伤    时间: 2012-1-26 19:14
本帖最后由 忧雪の伤 于 2012-1-26 19:15 编辑

回避 eval 有什么不好的……
作者: yangff    时间: 2012-1-26 20:25
第二节呢?




凭良心说不喜欢Fiber这种严重破坏代码结构的东西……对编码者太不友好了= =,比线程还恶心


──yangff于2012-1-26 20:31补充以上内容’
作者: 第七水螰    时间: 2012-1-27 10:04
@orzfly
说到开销……ruby是解释型语言……那么的话eval好像并不会造成太大开销。难道它是先编译成一种过渡代码然后在执行?那样的话每次eval都要编译一次

純解釋器的運作在代碼生成階段以後才與編譯器有所區別,在此之前的詞法分析(tokenization 或  lexical analysis)、語法分析(parsing 或  syntactic analysis)階段都是解釋或編譯必須的過程,lexer 和 parser 都是解釋器、編譯器的組成部分。當 eval 拿到一段字符串後,它需要重新進行詞法分析和語法分析,所以是必然有額外開銷的。對於命令式語言來說,語法分析結束時,解釋器/編譯器將會構建出一個完整的抽象語法樹(AST, abstract syntax tree),而這個樹表示了整個程序的執行流程。此時編譯器將會進入代碼生成階段,抽象语法树會被一次性的轉換為本地彙編或機器代碼;而解釋器則會在整段程序生命週期中保留這棵樹,並通過遍曆這棵樹的節點執行對應該節點的代碼。通常動態語言的抽象語法樹由於具有某些動態性(比如 eval 這樣的元編程操作),都不可能一次性轉換為本地代碼,最多是通過分析 hotspot 進行即時編譯(JIT)。

不過,以上說的是純粹的解釋性實現。Ruby 1.8 及之前的實現是純解釋性實現,也就是所謂的 AST walker,在語法分析結束後直接在語法樹上進行解釋。從 Ruby 1.9 開始,官方的實現採用了 YARV(Ruby 的進程虛擬機),所以 Ruby 代碼會事先被編譯為 YARV 機器碼,之後直接交給虛擬機執行。但無論如何,eval 都逃不過詞法分析、語法分析這兩個階段。

順帶一提,「解释型语言」這樣的說法其實不夠嚴謹,因為語言可以被解釋也可以被編譯 [1],尤其是在進程虛擬機發展起來以後。編譯性或解釋性不是語言的特性,而是某一個特定的語言實現的特性。像 MRI 就是解釋性實現,YARV 就是帶編譯性的實現。

[1] 比如,C 語言既可以被 GCC 編譯,又可以被 Cint 解釋。Ruby 1.9 的 Ruby 代碼是被編譯為了 YARV 指令。




[@]逸豫[/@]
連send都用上就是不用eval

對於 1.9 來說,send 由於是直接向虛擬機發送消息,所以沒有 eval 的分析時開銷,基本可以看作一種虛擬機的原子操作。在像 Ruby 這種基於 Smalltalk 對象消息模型的語言中,一切方法調用都可以看作是對 send 的調用,只不過通過 send 間接調用時需要用實際傳遞的符號在方法分派表中匹配方法名,而直接用方法名調用則在編譯時就匹配好了。


──第七水螰于2012-1-27 10:16补充以上内容’
作者: orzfly    时间: 2012-1-27 11:31
真是奇怪,明明还有一页。我这水回复一删就看不到第二页了……奇怪的dz
作者: ♂雨    时间: 2012-1-31 10:32
看了实在有点头晕......
作者: eve592370698    时间: 2012-2-10 01:44
我还是按照百度百科解释,将纤程理解为面向用户的线程或进程,其重点在于面向用户毕竟Rgss重点是面向业余爱好者而非专业程序员,所以在编程思路上应更加人性化.但是对汉化脚本我特别讨厌纤程这个词因为在形式上一个线程可以包含多个纤程结果容易被人轻视,但实质上线程是才运行程序的最小单位,进一步划分出纤程仅仅是走形式,程序核心并不能识别纤程,一个纤程出现问题整个线程就瘫痪.随着脚本的逐渐复杂,特别是想重写一个脚本,纤程就给人一种特别松散的感觉.
作者: lixiao888    时间: 2012-2-24 16:38
顶下技术帝~~~~
作者: 咚小黑    时间: 2012-7-21 12:23
表示看不懂
作者: a1578032454    时间: 2012-8-7 19:15
感觉不是面向编辑器....而是面向天书..一点也看不懂




欢迎光临 Project1 (https://rpg.blue/) Powered by Discuz! X3.1