Доброго времени суток всем!
Не знаю, знаете ли вы о том, что сейчас идет активная разработка Source Pawn 2, но все-таки расскажу.
Хорошие новости для всех! Я победил buildbot, чтобы принести вам Source Pawn 2 экспериментальной сборки. Что такое Source Pawn 2 ?
Пока это не так много. Он содержит прототип нового двигателя сценариев Source Pawn 2. Вы можете переместить файлы .sp формата в папку plugins и это будет работать от исходного кода.
2 новых файла были добавлены в сборку:
Сейчас есть много отладочных сообщений, например, при загрузке "sample.sp", вы увидите что то на подобие:
Right now, a lot of the core language semantics such as operators and statements are supported. However, #include does not yet work, nor do callbacks. That means this prototype is extremely limited. Note that .sp plugins do not automatically refresh yet either. I will be implementing more language features and posting a new thread after each major milestone.
The shell is also quite limited. It supports one public function called "main" which takes no arguments (and any number of non-publics). For example:
Spoiler
Code:
dvander@linux32:$ cat test.sp public main() { new sum; for (new i = 0; i < 200; i++) sum += i; return sum; } dvander@linux32:$ ./spshell test.sp ... 19900
P.S. Я не переводил ничего, просто скопировал. Если надо - позже переведу.
Добавлено через 47 секунд
Часть 2:
Hi All,
You may remember me announcing a project called "Knight", with the intent of bringing a new language to SourceMod. After a long time not making any progress, two weeks ago I decided to ask a new question: "What if we just rewrote SourcePawn from scratch?"
It turns out, that's pretty easy to do. I have a working prototype of "SourcePawn 2", a brand new language engine for SourceMod. In a few days I will post a link where you can try new SourceMod Experimental snapshot builds.
Why?
The original SourcePawn compiler is extremely old. It was written by ITB CompuPhase in the 1990s and was originally based off a 1984 journal submission. It is nearly impossible to maintain. The binary format (".smx") is also archaic and inflexible, inhibiting almost any modern language feature or performance improvement.
When Borja and I decided to use Pawn, we rewrote the runtime, which is the thing that executes .smx files. That helped a lot, but even that is too restrictive. It provides a very rigid API and is ultimately limited by the .smx protocol.
My hope with SourcePawn 2 is a complete do-over. The compiler and runtime are tightly integrated as one unit, and the design will easily allow adding all sorts of new, modern language features.
Tell me more!
SourcePawn 2 runs plugins directly from source. That means you can drop ".sp" files in your plugins folder and they just work. Offline syntax and type checking is also supported. There are no plans to remove .smx support, however, .smx files will not be able to take advantage of SourcePawn 2.
My goal is to support enough SourcePawn language features that 70% of plugins on the forums will work. From there I'll evaluate what features are remaining and whether they're worth adding. In this initial prototype, enough features are working to write very simple plugins, though #include does not work so you must declare natives manually.
Here are the known language features I have not implemented, but will implement:
Eventually, if/as the language reaches maturity, I will start adding new language features that people have been requesting:
SourcePawn 2 includes garbage collection. I've implemented a very basic garbage collector that only runs on map changes. For most use cases I've managed to maintain SourcePawn's performance and memory guarantees surrounding arrays, which is great.
Aside from that, the entire architecture is much more amenable to high-powered performance optimizations than SourcePawn 1. Although the implementation right now is simple (GC is not realtime, and the execution mode is an interpreter), the entire architecture is geared toward making an advanced GC and an optimizing JIT very easy.
There are many language features I will not implement. They are either too difficult to support in a modern design, or they are inherently bad features that may impede progress. Next to each I've listed what the eventual replacement will be:
I'm happy to talk about why individual features will not be supported. Hopefully, SourcePawn 2 will eventually be compelling enough and people using these features will port to newer replacements.
Where do I get it?
Right now I have a bare-bones prototype where you can declare natives, forwards, and publics in a .sp file, and drop it into your plugins folder. It works but it's largely untested.
Later this week I will create a page where you can download snapshots, and I'll post a new thread about it here. For now, I'd just like to field any concerns/questions or discussions people might want to have.
Не знаю, знаете ли вы о том, что сейчас идет активная разработка Source Pawn 2, но все-таки расскажу.
Хорошие новости для всех! Я победил buildbot, чтобы принести вам Source Pawn 2 экспериментальной сборки. Что такое Source Pawn 2 ?
Пока это не так много. Он содержит прототип нового двигателя сценариев Source Pawn 2. Вы можете переместить файлы .sp формата в папку plugins и это будет работать от исходного кода.
2 новых файла были добавлены в сборку:
- plugins/sample.sp - Пример плагина, работающего на Source Pawn 2.
- scripting/spshell.exe - Командная строка Source Pawn 2.
Сейчас есть много отладочных сообщений, например, при загрузке "sample.sp", вы увидите что то на подобие:
PHP:
sm plugins load sample.sp [ FunctionStatement (PrintToServer) [ FunctionStatement (OnPluginStart) [ FunctionStatement (OnPluginStart) [ BlockStatement [ ExpressionStatement [ CallExpression [ NameProxy (PrintToServer) [ StringLiteral 0 object 0 5 callnative 0 1 14 pop 15 stop Safepoints: 5: 0 0 stop Safepoints: SourcePawn 2.0! [SM] Loaded plugin sample.sp successfully.
Right now, a lot of the core language semantics such as operators and statements are supported. However, #include does not yet work, nor do callbacks. That means this prototype is extremely limited. Note that .sp plugins do not automatically refresh yet either. I will be implementing more language features and posting a new thread after each major milestone.
The shell is also quite limited. It supports one public function called "main" which takes no arguments (and any number of non-publics). For example:
Spoiler
Code:
dvander@linux32:$ cat test.sp public main() { new sum; for (new i = 0; i < 200; i++) sum += i; return sum; } dvander@linux32:$ ./spshell test.sp ... 19900
P.S. Я не переводил ничего, просто скопировал. Если надо - позже переведу.
Добавлено через 47 секунд
Часть 2:
Hi All,
You may remember me announcing a project called "Knight", with the intent of bringing a new language to SourceMod. After a long time not making any progress, two weeks ago I decided to ask a new question: "What if we just rewrote SourcePawn from scratch?"
It turns out, that's pretty easy to do. I have a working prototype of "SourcePawn 2", a brand new language engine for SourceMod. In a few days I will post a link where you can try new SourceMod Experimental snapshot builds.
Why?
The original SourcePawn compiler is extremely old. It was written by ITB CompuPhase in the 1990s and was originally based off a 1984 journal submission. It is nearly impossible to maintain. The binary format (".smx") is also archaic and inflexible, inhibiting almost any modern language feature or performance improvement.
When Borja and I decided to use Pawn, we rewrote the runtime, which is the thing that executes .smx files. That helped a lot, but even that is too restrictive. It provides a very rigid API and is ultimately limited by the .smx protocol.
My hope with SourcePawn 2 is a complete do-over. The compiler and runtime are tightly integrated as one unit, and the design will easily allow adding all sorts of new, modern language features.
Tell me more!
SourcePawn 2 runs plugins directly from source. That means you can drop ".sp" files in your plugins folder and they just work. Offline syntax and type checking is also supported. There are no plans to remove .smx support, however, .smx files will not be able to take advantage of SourcePawn 2.
My goal is to support enough SourcePawn language features that 70% of plugins on the forums will work. From there I'll evaluate what features are remaining and whether they're worth adding. In this initial prototype, enough features are working to write very simple plugins, though #include does not work so you must declare natives manually.
Here are the known language features I have not implemented, but will implement:
- Const with non-refs
- Array literals
- Float comparison
- Non-branching comparison
- Global variables
- Dynamic arrays
- #include <>
- Array slicing
- Float comparisons
- Booleans
- The any: tag
- Optional semicolons
- Chained relational operators
- Ternary expressions
- Passing functions as variables/parameters
- SortCustom2D, SortStrings
- Very limited, specific uses of #if and #define
Eventually, if/as the language reaches maturity, I will start adding new language features that people have been requesting:
- Resizable arrays
- Global dynamic arrays
- Structs
- Classes
- Closures/nested functions
- Discriminated unions
- Dynamic types
- First-class FFI
SourcePawn 2 includes garbage collection. I've implemented a very basic garbage collector that only runs on map changes. For most use cases I've managed to maintain SourcePawn's performance and memory guarantees surrounding arrays, which is great.
Aside from that, the entire architecture is much more amenable to high-powered performance optimizations than SourcePawn 1. Although the implementation right now is simple (GC is not realtime, and the execution mode is an interpreter), the entire architecture is geared toward making an advanced GC and an optimizing JIT very easy.
There are many language features I will not implement. They are either too difficult to support in a modern design, or they are inherently bad features that may impede progress. Next to each I've listed what the eventual replacement will be:
- Enum structs (replacement: actual structs)
- #pragma semicolon (replacement: none, semicolons cannot be required)
- #define X Y (replacement: use "const" or "static const")
- #define X() ... (replacement: none, use functions)
- #pragma (none, #pragmas are unneeded and will be ignored)
- funcenum (replacement undecided)
- Anything in <functions.inc> (replacement: module system like Java/C#)
- Variadic arguments (replacement: alternate syntax I can talk about later)
- Using String: as a non-array tag (replacement: none)
- Tag mismatches as warnings (replacement: none, these are bugs)
- #include "" ("use" keyword)
- Enums with non-uniformly typed values (replacement: none, these are bugs)
- Naming enums "Float", "String", "bool", etc. (replacement: none, these are bugs)
I'm happy to talk about why individual features will not be supported. Hopefully, SourcePawn 2 will eventually be compelling enough and people using these features will port to newer replacements.
Where do I get it?
Right now I have a bare-bones prototype where you can declare natives, forwards, and publics in a .sp file, and drop it into your plugins folder. It works but it's largely untested.
Later this week I will create a page where you can download snapshots, and I'll post a new thread about it here. For now, I'd just like to field any concerns/questions or discussions people might want to have.
Последнее редактирование: