洛书 1.6.x STS版本规划与讨论

Losu 洛书
1

1.6.x STS版本规划与讨论

  • 此 贴 与 Issues 保持同步，您可以在任意一个下进行回复(更推荐Issues)
  • 我们将认真倾听并思考您的每一条合理意见
  • 即使您仅向我们提供意见而不是贡献代码，我们采纳您的意见后也会在注释中加以致敬

详细内容

概述

  • 经过 1.5.x的过渡与 1.6早期版本的不断试错，1.6.x 系列已经基本具备发布 STS 版本的能力

  • 在作者看来，一个合格的 STS 版本至少应该满足以下几个基本条件

      1. 完善、可靠的功能，可以通过全部 语法测试与功能测试样例
      1. 简单的获取、使用、升级(主要是拓展库)、开发(包括二次开发)体验
      1. 相对完整的文档支持，以及后期的教程支持

  • 1.6.x STS 版本的预期目标

    • 发布 Windows、Linux、MCU 安装包/固件
    • 发布 SDK-1.6.x 跨平台构建开发工具，方便拓展模块的开发与上传
    • 发布 包管理器，方便用户 安装/升级/卸载 的拓展包
    • 同步文档，并发布一些 教程/宣传 视频

发行方式

  • Windows 二进制安装包： zip压缩包，解压后运行install.bat，一键安装，只准备支持 x86/x64 之一
  • Linux 源码安装包: tar包，解压后运行 install.sh，一键 编译+安装
  • Linux 二进制安装包: tar包，解压后运行 install.sh，(默认不准备提供，Linux安装gcc不是很困难，源码发行可以减少打包成本)

SDK-1.6.x 跨平台构建开发工具

  • 用洛书编写
  • 可以在 Windows、Linux两个平台使用
  • 下载、配置内核、模块、库，生成可构建工程
  • 可以根据洛书代码生成C头文件，方便模块的制作
  • 【可选】支持模块上传与发布

包管理器

  • 用洛书编写，基于洛书的脚本机制，实现不同模块的差异化处理
  • 可以运行在 Windows、Linux平台使用
  • 安装、更新、卸载 拓展模块

模块标准

  • Windows： 二进制发布
  • Linux： 二进制/源码 发布 （很犹豫，源码发布需要用户构建二进制，二进制发布打包需要巨大精力，尤其是不同CPU与发行版的打包 :cold_sweat: ）
  • MCU ： els声明文件，如果可以标准C实现，附上C文件

感谢所有支持过我们的热心人，同时也欢迎更多的大佬来提出建议，广泛的建议有助于我们将洛书做的更好

3 个赞
2

不知现在主要的试用者在哪个系统平台下使用？
如果语言的主打方向是单片机，何不在短期内专注这一平台，对其他平台暂放一放？达到可实用、项目开始稳定迭代的程度再兼顾？

3

在issue里说到库建设的问题，想到 @pengzhen 在 我们做了一个能运行在单片机/嵌入式上的JavaScript引擎 已封装了相当多 API。也许可以复用以降低开发维护开销？

4

还是要解决问题为主，其实我们的引擎已经比较稳定了，但一直没有上线录视频商业化运作，我还是觉得目前太单薄了，即便是针对某一平台（或者说某一两款单片机产品）基础设施功能还是不够的。。。我觉得前期不要多平台发展，就针对某一两个产品（或者说单片机）深入挖掘就行了，多平台你搞不过传统语言生态

2 个赞
5

很赞同，单片机现在洛书在做的是w806，其实是个权宜之策，因为合适的stm32的开发者还没找到，后期准备利用stm32HAL实现stm32洛书stdhal库，这样可以减轻开发压力。

感觉在嵌入式方面，如果只依赖官方提供固件的话会很辛苦，更多的时候需要用户去裁剪、修改、编译固件，官方只提供一些标准，具体平台的实现与标准接口的开发分离可能更好

洛书单片机暂时只准备提供stdlib与stdhal作为标准库，剩下的全部以模块方式提供，stdhal只做一些 gpio之类的就行了，像lvgl之类的高级功能作为模块，交给开发者编译固件时添加。

目前我是采用一个小工具去扫描一个模块的脚本文件，去自动生成所有C文件的声明与接口，移植时只需根据平台无脑实现C/C++函数就行了

现在正在编写一个新的lsbuild模块，这个模块可以由包管理器安装，安装完成后可以根据洛书脚本来配置生成内核工程，方便为不同平台(先暂定为MCU ,Linux与windwos可以用模板工程一键编译)的编译解释器，这个模块的编写对于检查完善解释器中存在的问题也很有帮助

未来可能还是先在单片机与嵌入式领域先行发力，感觉这两个领域竞争压力更小一点，对标的对手也是micropython这种，比起python要轻松一些，但是我希望可以做成一套自包含的体系，可以使用洛书写的工具在不同平台上开发洛书的模块与解释器，所以现在在做多平台的相关支持

1 个赞
6

单片机确实是目前比较好的战场，只有几十KB小内存就让不少高级语言直接无法移植运行了，不过现在单片机在普及32位，有的32位单片机只有1块钱左右，配置越来越好，脚本语言上单片机是趋势，，，这里面很值得挖掘

7

赞同，32位发展前景挺大的，有些￥5左右的32位MCU ，flash甚至可以按兆算，而且IoT开发脚本更方便

8

如果目标平台一致，在生态方面除了库等可以合作，在IDE上也有很多机会。早先的设想 里的知识库搭建、交流平台和代码搜索/生成等功能都可以共同建设和使用。

2 个赞
9

参与国产语言的同学多了，总算看到一点可以自发形成合力的方向:+1:

1 个赞
10

新的lpt拓展管理器改进了拓展管理功能，这个功能可以从源中拉取包括源码在内的相关资源

同时提供编译模板工程，利用这二者可以方便地定制一份洛书解释器
个人认为提供方便的编译-移植支持应该会对多平台的推广发挥一定的作用

比如假设有开发者在为新平台编译解释器与模块，在理想的情况下只需要使用lpt拉取源码即可开始构建

lpt source [package] # 拉取模块源码
.....
build.bat # 构建脚本

演示

同时，这种开发模式也可以减少开发者的负担，实现自动化/半自动化的 开发-构建-发布流程

11

其实个人觉得直接研发通用语言尤其在没有背靠项目的情况下有些一步上三台阶的感觉。如果能基于实际项目，从 开发专用API或框架 等开始，风险会小一些，关键在过程中一直可以用于实际项目，在使用中迭代。

API 设计和语言设计实际上有相当多的相似性，尤其在前端部分。毕竟都是人机交互层面，如何易懂好读、反馈的时机和指导性、术语一致化等等都有相当挖掘空间。

1 个赞