对的
一般是 40 分钟左右,不过稍微拖拖(包含 QA)差不多就容易超时到 50 了,今年打算稍微削减一点点密度,太满容易累
置顶了
截图里的路径真的有这个文件?
李阿玲老师的 https://github.com/clerkma/ptex-ng Tex 排版项目也是用 mruby 做 DSL 层,可以参考 mruby 对于各种平台包括 windows 支持很好,如果是 Ruby 的话,考虑调用外部 Ruby 的 bin 也可以
开搞!
国内有西门子
棒!
是的,只要团队对代码风格有共识,坚持贯彻就好了。
可以脱离,参考我前年的帖子 https://ruby-china.org/topics/38214
@huacnlee 咱们 RubyChina 要不要做这个?
最大的问题是带 c 扩展的二进制 gem 假定 posix 编译套件,而且没人有动力搞 MSBuild(Python 和 PHP 是微软亲自搞的,所以前阵子微软宣布不再出力支持 PHP 8 还是个新闻),现在 Ruby for Win 和 git for windows 一样是建立在 mingw 上的,但 git 不需要再安装扩展了,Ruby 只有少量 gem 带了预编译的 C 扩展,为了能安装更多的 带 C 扩展的 Gem,你需要安装体积超过 1G 的 Posix 的编译套件,这对一般用户来说就不能忍受了,对于国内用户,mingw 的软件源被墙了很难获取
一个冷知识是,大半在日本的 MRI 的开发者(包括 ko1)是用 Windows 开发 Ruby 的,但 Ruby for win 搞得不好,也可以说是讽刺
当然了,现在有 WSL 2,在 Win 上几乎和在 Linux 上体验一致了,没必要再折腾 mingw 那套方案
肯定还是 C 快,他说的是这些 C 实现的驱动没有适配 Fiber Scheduler,等于使用的时候还是像现在一样在 IO 的时候空转
pg 我已经写好 poc pr 了,但是 puma 没适配,所以 rails 开了 fiber scheduler 会直接卡死
感觉 new magic 跟刚发的 react server component 几乎是一码事 react server component 是把 jsx 当成新 dom new magic 还是 html
浏览器端的 react/turbolinks+stimulus 来维持页面状态
精了,赞得好快
走起~
周一~
26 号去深圳的 RustCon
给我一个样本?我来帮你跑跑看
理论上 rails 的 rspec 测试,瓶颈在 IO 更多一些
从你的错误提示看,只有 postgresql 你装的时候指定要 x86 的了,下边依赖都是 arm64 的,那直接去掉 arch -x86_64
就应该可以了,如果你之前装一些 brew 的软件包混杂了两种架构的,编译时遇到错误,就用正确架构重装即可
这个跟安装路径无关,会不会编译成 x86 只看你是不是带了 arch -x86_64
或者是给终端设置用 Rosetta 运行的属性(这个是很多网站介绍的技巧),如果都没有做的话,默认就会是 arm64
的
此外 2.6.0 也没有正式支持 M1(所以我才说要手动安装 Homebrew,因为你直接用官网的安装命令在 arm64 模式下会直接报错停止安装),之所以提议改到 opt/Homebrew
是因为过去 Homebrew 的默认路径是 /usr/local
考虑 Rosetta 会至少长期存在若干年,两种不同架构的 brew 并存是大概率的,于是就得给 ARM 版的 brew 找个新位置避免冲突,其实就是解决你现在遇到的问题,就是不同 arch 的 brew 软件包不能混用
更具体的 M1 的支持进展可以看我帖子里引用的 https://github.com/Homebrew/brew/issues/7857 ,虽然 Homebrew 在 M1 Mac 上完全可以正常使用,但是官方故意宣称不支持的原因在里面有讲,关键原因还是官方不能保证有足够多的软件包在 M1 macOS 上正常编译和使用顺利,他们才刚刚配置起 M1 的 CI 环境来逐步验证所谓的核心软件包
Error: postgresql dependencies not built for the x86_64 CPU architecture: pkg-config was built for arm64 [email protected] was built for arm64 readline was built for arm64
这个错误已经说的很清楚了,你系统里的 pkg-config
和 openssl
都是 arm64 架构的,你用 arch -x86_64 brew install postgresql
指定装 x86 架构的,显然是不可能的,pg 支持 m1,所以你直接 brew install postgresql
就可以了
测试过了,可以安装,PG 编译需要的依赖太多,
我就用 Homebrew 来弄了,按官网教程手动安装后,再 brew install postgresql
Rails 这边就直接 bundle
就可以了
你可以这样试试
这样就是 Rosetta 转译了,涉及到动态链接的,x86 和 arm 不能混用
周末我来试试安装 PG 好啦~
不过你得记得 pg gem 需要动态链接 postgresql 的 so 文件(没记错的话),所以你必须 arm pg 配 arm ruby
更新了一下,顺便测试了了跑 Rails,没遇到什么大问题,干活差不多够用了。
回答不了,超肛了。。。
PHP 微软下场移植的,除了 Zend 这个亲爸爸,还有 M$ 这个干爸爸,爸爸多就是好。。。虽然现在干爸爸不要他了
Ruby 对于咱们一般人,现在只能仰赖 WSL 2 了
很讽刺的是,我在 RubyKaigi 上注意过,大多数日本的 Ruby Core 成员都是用 Windows 开发 Ruby 的(Mingw 环境),结果 Ruby 在 Win 上如此拉胯。。。对于国内还有一个问题是,mingw 的软件仓库被墙的,雪上加霜。。。
这跟是不是“瞎扯淡”无关,你说话嘴这么碎,我一定要好好教育你,直到你学会怎么好好说话为止。
ENV['RAILS_ENV'] ||= 'test'
的意思是,如果 ENV['RAILS_ENV'] ||= 'test'
没有值,则给一个默认值 test
不太清楚你所说的“重启 mysql 服务器后”是指什么,可能是说正式的服务器?看你的启动脚本,可能他是以 production
环境启动的。
rails console
如果不给 -e production
,默认是 development
环境
如果你启动的时候要指定环境需要 rails server
和 rails console
都提供了 -e
参数(你可以通过 rails s --help
`rails c --help
rails s
是 rails server
的缩写形式 rails c
是 rails console
的缩写形式),比如 rails s -e test
就会以 test
环境来启动了