Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 10:48
    dumblob opened #167
  • 10:43
    waruqi closed #605
  • Feb 24 23:50
    waruqi labeled #1149
  • Feb 24 23:49
    waruqi demilestoned #1247
  • Feb 24 23:49
    waruqi milestoned #1247
  • Feb 24 14:57
    waruqi closed #1240
  • Feb 24 14:56
    waruqi closed #1109
  • Feb 24 14:56
    waruqi closed #1104
  • Feb 24 14:54
    waruqi closed #1254
  • Feb 24 13:14
    waruqi edited #1254
  • Feb 24 13:14
    waruqi edited #1254
  • Feb 24 13:03
    waruqi labeled #1254
  • Feb 24 13:02
    waruqi milestoned #1254
  • Feb 24 13:02
    waruqi opened #1254
  • Feb 24 12:58
    waruqi milestoned #1253
  • Feb 24 09:29
    PucklaMotzer09 closed #1252
  • Feb 24 09:19
    PucklaMotzer09 opened #1252
  • Feb 24 05:50
    waruqi milestoned #605
  • Feb 24 05:50
    waruqi demilestoned #605
  • Feb 24 05:38
    waruqi milestoned #1251
tboox_bot
@warrny
OpportunityLiu: 据说比lua C函数还快
waruqi: 都在c里面 还用啥ffi。。
waruqi: 即使快 也就是快 接口调用上的那一些损耗,如果没啥特殊需求 没必要特地去整成ffi
tboox_bot
@warrny
OpportunityLiu: ffi比操作lua栈容易呗
OpportunityLiu: 关键好写啊,之前写io的API真的
tboox_bot
@warrny
waruqi: 目前c core里面的大部分接口 也仅仅取参和返回的时候稍微操作下lua栈 内部逻辑基本上都是纯c处理 很少处理lua栈的。。所以之前我没这个需求必须要用ffi io这块我也没见怎么太复杂的lua栈操作 也还好
tboox_bot
@warrny
CAROLYN: hi
tboox_bot
@warrny
PATRICIA: hi
tboox_bot
@warrny
David: hi
tboox_bot
@warrny
MARYBETH: MARYBETHZ
tboox_bot
@warrny
Mageia: dtawa
Mageia: hulkh
tboox_bot
@warrny
tboox_bot
@warrny
Paul:
Paul: ssz yrqmuqb sutdmrse
tboox_bot
@warrny
OpportunityLiu: 想重构一下xmake的面向对象那部分了
OpportunityLiu: table.inhert快看不下去了
tboox_bot
@warrny
waruqi: 这块涉及面太广,暂时不要去动了。。我后来新加的面向对象的框架,在core/base/object.lua,目前也就整个ui库 是基于新的对象框架。。 (re @OpportunityLiu: 想重构一下xmake的面向对象那部分了)
waruqi: table.inherit确实实现的不怎么样。。不过历史遗留问题了。。一下子改动太大 影响面太广了。。所以即使后来我整了新的 base/object.lua 也没有彻底在其他地方用起来。。
waruqi: ui库比较独立,也是后面才新整的。。我才整个用了新的object.lua 要是再整个新的。。就更乱了
tboox_bot
@warrny
OpportunityLiu: 这也没实现啥啊 (re @waruqi: 这块涉及面太广,暂时不要去动了。。我后来新加的面向对象的框架,在core/base/object.lua,目前也就整个ui库 是基于新的对象框架。。)
waruqi: 那你需要实现啥?
tboox_bot
@warrny
OpportunityLiu: dll一般咋处理?感觉这么搞不太对啊:
OpportunityLiu: 方法和继承之类的,object的那个根本没有, table那个把函数复制的到处都是 (re @waruqi: 那你需要实现啥?)
tboox_bot
@warrny
OpportunityLiu: 我试着用xmake package生成了一个dll,没啥特殊处理,不会“找不到se.dll”吗?:
tboox_bot
@warrny
OpportunityLiu: 还有一个问题,add_runenvs的实现vsxmake现在和xmake不太一样,感觉xmake无脑合并环境变量不太对,毕竟大部分环境变量并不支持用;/:分割的,是不是应该改成白名单,比如PATH之类的合并,其他的直接覆盖?这部分要在vsxmake插件实现很麻烦(覆盖的话倒是很简单),正在想怎么操作
waruqi: 继承 还是 成员初始化器 什么的 都有啊。 (re @OpportunityLiu: 方法和继承之类的,object的那个根本没有, table那个把函数复制的到处都是)
waruqi:
waruqi:
waruqi:
tboox_bot
@warrny
waruqi: add_runenvs追加合并,set_runenvs直接覆盖。。是否合并,用户自己选择add_runenvs/set_runenvs自己控制 (re @OpportunityLiu: 还有一个问题,add_runenvs的实现vsxmake现在和xmake不太一样,感觉xmake无脑合并环境变量不太对,毕竟大部分环境变量并不支持用;/:分割的,是不是应该改成白名单,比如PATH之类的合并,其他的直接覆盖?这部分要在vsxmake插件实现很麻烦(覆盖的话倒是很简单),正在想怎么操作)
OpportunityLiu: 感觉更像是record而不是class。。 (re @waruqi: 继承 还是 成员初始化器 什么的 都有啊。)
waruqi: 加个set_runenvs就好了
OpportunityLiu: 都是合并,没有覆盖:
waruqi: 那是因为只提供了 add_runenvs api,我是说 后面再加个 set_runenvs 就好了。。用来做覆盖
waruqi: on_run里面 还没改。。之前随手写的。。可以改进下
OpportunityLiu: 这里还能分得清 set和add?我vsxmake里怎么处理啊 (re @waruqi: 那是因为只提供了 add_runenvs api,我是说 后面再加个 set_runenvs 就好了。。用来做覆盖)
tboox_bot
@warrny
waruqi: 用set/add还不行,这个只是控制当前xmake.lua的envs值是否merge还是覆盖。。最终的run envs是否覆盖系统现有的。。还是得加个参数让用户自己控制 ...add_runenvs("", "", {override = true}) 类似这样。控制是否重写系统值。。这个脚本里面 有接口可以 快速获取到的。。target:extraconf("runenvs", "PATH", "override") 类似这样
OpportunityLiu: 所以回到前面那个问题,默认值是覆盖还是合并,或者白名单/黑名单?
OpportunityLiu: win上貌似除了PATH,就没有用;分割的,linux上好像也不多,我只知道PATH和LD_LIBRARY_PATH
waruqi: 我再想想,黑白名单 太繁琐隐晦了 不好维护
tboox_bot
@warrny
OpportunityLiu: 还有这个问题,前面两个是xmake的问题,这个是我的问题
OpportunityLiu: Forwarded from OpportunityLiu: dll一般咋处理?感觉这么搞不太对啊:
OpportunityLiu: Forwarded from OpportunityLiu: 我试着用xmake package生成了一个dll,没啥特殊处理,不会“找不到se.dll”吗?:
tboox_bot
@warrny
waruqi: dll目前还不能自动copy 对应的lib过去。。你需要在 after_package里面,copy dll对应的lib 。。 (re @OpportunityLiu: )
tboox_bot
@warrny
waruqi: 我觉得还是默认追加吧。。虽然merge的envs不多,但毕竟对于on_run ..PATH LD_LIBRARY_PATH这种常用路径的设置更加常用,即使用户要设置其他envs 不需要merge。。也可以通过 {override = true} 让用户自己控制
tboox_bot
@warrny
waruqi: 不了解record。。目前这样 我觉得够用了。没必要非得把class支持的很完善。虽然core里面 目前table.inherit确实不咋地。。但目前也够用了。。xmake不会去做复杂的继承链结构,大部分都是单层的。。关键是这块还是早期就有了。。历史负担比较重,该这块,全改的话涉及的代码改动太多了。。如果只改部分,代码风格就会很不一致 会很混乱。 (re @OpportunityLiu: 感觉更像是record而不是class。。)
tboox_bot
@warrny
OpportunityLiu: 或者加个runenvps? (re @waruqi: 我觉得还是默认追加吧。。虽然merge的envs不多,但毕竟对于on_run ..PATH LD_LIBRARY_PATH这种常用路径的设置更加常用,即使用户要设置其他envs 不需要merge。。也可以通过 {override = true} 让用户自己控制)
tboox_bot
@warrny
waruqi: 加个p看着只是可设置sep,按照目前的命名。。add_runenvs 就是对一个值env支持复数多值的追加,那么默认就应该支持 merge的。修改sep可以通过 add_runenvs("", "", {sep = ':'}) 来修改。。要么这样 add_runenvs还是默认追加,兼容已有的行为。。set_runenv 加个单数的设置。行为就是覆盖好了。。也就是只有两api 。。。add_runenvs/set_runenv
tboox_bot
@warrny
waruqi: runenvs 复数的就是 对系统envs的追加和merge。。runenv单数的就是对系统值的覆盖。。。而对于多值的 覆盖,像PATH这种的覆盖不常用,即使非要覆盖。。通过单值覆盖接口,也可以做到 set_runenv("PATH", "xxxx;yyy;yyyy")