text:
Stepped Tracker

### Tasks
- [ ] #1866
- [ ] #1869
- [ ] #1867
- [ ] #2395

### Enhancements
- [ ] https://github.com/jpmorganchase/salt-ds/issues/3309

Pepper requirements include 'warning', 'error' (TBD 'deadend'), small breakpoint as per Pepper pattern, Salt to allow no label on step

Zazu Goal: M(5)

merge to RC, a known state
stakeholder review required
draft docs/design ready to publish

Outstanding Questions:
Icon size, are they too small ?

New approach to icon sizing (1.5x for all steps, 1x for sub-steps) signed-off.
Still to finish in code: icon sizing implementation and accordion-mechanic for nested steps

#3584 ready for dev review
Icon sizing and accordion-mechanic should be ready for review by COP Monday

accordion mechanic taking longer than expected. New ETA for "ready to review": Wednesday

Icon size changes ready for design review.
Accordion still in-progress, expect to be ready for design review by EOW.

Size and spacing adjustments required following design review.
Had catchup with James Sol to ensure we're all in sync with requirements.
Expecting to be ready for dev review by Friday

Slider work has pushed this back a little. Expecting dev work complete by the middle of next week

Goal: finish accordion mechanic for nested steps
Design and dev signoff by EOS

Dev work on functionality complete.
Adding tests and example stories while waiting for design review.

Fine-tuning based on design feedback (mostly typography and spacing tweaks)

Cortado Goal :
Merge to Labs and docs published
Third Party feedback before merge to Core

Final dev tweaks to pass design review (plus discussion about right-hand spacing for sub-steps)
Expect to be ready for dev review by EOD Friday

Aug 12 - Adding test, closing to get team review

@tomhazledine thank you for the updates. I just re-ran design review. There are still some details to be addressed. Please see unresolved challenges to the bottom of the Design review in Figma. Please feel free to schedule a call if required considering that we are mid-sprint and you still required code reviews in the coming days. TY!

Aug 14 - Design sign-off
Aug 16 - Site example and QA stories added. Ready for dev review

Possible a11y review - label / announcement around nested (expand / collapse)

Jacob to do accessibility review during Espresso

Sent Tom the a11y review for stepped tracker 9/11/24. Can setup a call to review the report if needed.

Frappe Goal:
James Sol to review and PR raised to Labs
Invite more feedback and a plan to move to Core

Have reviewed a11y feedback at will start implementing tomorrow (18th)

Should have a11y updates complete by next standup

Validation of a11y changes in-progress

Tom is working on remaning feedback but we should answer the question above
Galao Goal: dev complete and backlog updated with any future design tasks (@bhoppers2008)

@tomhazledine do we have an update on this ?

@tomhazledine @mark-tate any update on this from a dev perspective?
@ivan-calderon @jake-costa are working on step as a link and that is captured in another ticket

Requires Stakeholder feedback and link support to be added to Labs.
Dev capacity required to complete links work.
Will be prioritised once dev capacity is available.

Lungo: Design complete, Figma guide by EOS (characteristic updates)

Macc Goal:
QA Kris updates, push a copy to James for approval
Decision on Core sprint/date by EOS

Mocha: release to lab, get stakeholder feedback on code

End to end tests to be written. Meeting with Jake/ Ivan end of day to review accessibility. Code in review. On track for labs release goal.

red eye: merged to labs

authors: bhoppers2008 dplsek ivan-calderon jake-costa joshwooding mark-tate origami-z tomhazledine


text:
Input Static adornments

V1 of FormFieldNext includes static InputNext adornments.

Do we call startAdornment prop composition as well? (v.s. strictly children)

source: gharchive/pull-request

authors: libertymayc origami-z

repo: jpmorganchase/salt-ds

license_type: permissive

license_source: github-api


text:
Option to use theme colour when not focused

When the SpinBox is not focused the button colour defaults to grey, clicking inside the textfield will focus the widget and change the buttons colours to use the theme colours.
Is the a possibility of adding an option to always use theme colours when enabled?
unfocused

focused

Thanks

Hi, I just wanted to leave a comment that the proposal sounds good, but I've been busy with other things recently. Would this be something you could help with, perhaps?

@jpnurmi
No problem, I will look into it

@jpnurmi I just wanted to use this option so I submitted a PR. #39

source: gharchive/issue

authors: ConcenTech gerardo-m jpnurmi

license: MIT


text:
Uncaught TypeError: e.indexOf is not a function

Exception in inline.js line 240 of commit: 98d5c660c2d899f4242ac68230a4c2fa0e7850ef
export function extractInlineStyle(editorState) {
  if(editorState) {
    const styleList = editorState.getCurrentContent().getBlockMap().map(block => block.get('characterList')).toList().flatten();
    styleList.forEach(style => {
      if (style && style.indexOf('color-') === 0) {
        addToCustomStyleMap('color', 'color', style.substr(6));
      } else if (style && style.indexOf('bgcolor-') === 0) {
        addToCustomStyleMap('bgcolor', 'backgroundColor', style.substr(8));
      } else if (style && style.indexOf('fontsize-') === 0) {
        addToCustomStyleMap('fontSize', 'fontSize', style.substr(9));
      } else if (style && style.indexOf('fontfamily-') === 0) {
        addToCustomStyleMap('fontFamily', 'fontFamily', style.substr(11));
      }
    });
  }
}

does
editorState.getCurrentContent().getBlockMap().map(block => block.get('characterList')).toList().flatten();
return Array<string> ?
I am a newbie.

Hi @huadong : it will return an array of inline styles like ['color', 'bgcolor', ...]
I hope I understood your question correctly 😄

Ah also note that now immutableJS is a peer dependency for draftjs-utils. Ensure its present in your project.

Fixed. Maybe the external modules fire this exception, After I update all the dependence modules base on draftjs-utils, it works fine.
Thanks a lot @jpuri .

authors: huadong jpuri

repo: jpuri/draftjs-utils


text:
体验优化建议

当没有更多历史消息时，可禁用下拉刷新
图片框的圆角大小可调节
头像支持圆角，并可调节大小，方便实现圆形头像
消息的气泡是否可以默认稍微好看些，比如参照微信的气泡颜色，我理解大多数情况下对改气泡都没有需求（还能怎么优化呢...）

这个蓝色太辣眼睛了...

输入框支持自动增高，可配置最大行数
下面的四个按钮，支持修改图标（用图片也行，只要能修改...）

谢谢这个库带来的方便~

下拉刷新可配置提示文字，如“正在获取更早的消息...”

1、3、5 这几个建议可以考虑
第 7 个建议，后期可以加入配置项（下拉刷新的提示文字）
6 输入组件暂时不会提供自定义功能（后期可以考虑出一套 js 版的输入组件，毕竟这个组件不是简单提供配置项能够满足所有需求的）
2、4 这两项可以使用自定义消息泡泡来实现自定义(默认 UI 暂时不会变动)

如果图片颜色和背景色一样就这样了，是否可以显示边框呢？

输入框文字颜色、大小、行高可配置，并且可配置 padding

消息是否能支持 tooltip，方便实现诸如 复制、删除 等功能

@musicode a3251fa6b4e8be8434aebbb323f6c47ae192aa38 完成了建议2

目前所有的资源，如图片，音频，视频，头像，都必须用本地路径，因此每加载一页（比如10条消息），有两种选择，且每一种都有问题：1. 确保所有资源都下载到本地之后，再能加入消息列表，这样的等待时间有时候很长；2.下载好一个就 append 一个，这样无法保证顺序。

所有图片目前都不是正常的图片扩展名，是否可以修改 jpg、png、jpeg 呢

播放音频消息需要提供暂停接口，以便退出聊天时可以暂停音频
音频播放是否可以做一点动画，现在声音小一点完全看不出在播音频...
RN 的 AuroraIMUIModule 是否可以提供加载完成后的回调，方便加载完成时插入历史消息，现在没有这个回调，是否插入成功全靠人品...

16.为了解决 11 条，我尝试收到一个消息先插入，并显示 loading，当资源下载完成后，updateMessage，但这样有个问题，图片（如头像和图片消息）可以显示本地 loading 图，对于音频和视频怎么表现正在加载呢？

视频是否可以像音频一样，返回 duration 给回调呢？虽然视频消息自动会识别并显示 duration，但对于数据库来说，我希望存储一下 duration 字段。

18. 当只有一天消息时，timeString 距离顶部导航栏太近了

只有文本消息的 timeString 会显示出来，其他消息类型貌似无效

20: timeString 可以配置文字颜色和大小，是否可以配置背景色呢，方便实现类似微信那样的灰底白字

聊天列表设置了 showDisplayName 为 true，但昵称没有显示出来

相邻消息之间的间距是否可以设置？

文本消息是否可以设置 line height？调大字体时，不能设置 line height 会导致文本贴在一起...

语音消息是否可以设置扬声器（大声）或电话模式（小声）？

感谢建议。
19、21 这两个问题，这边看看情况。
24 是个不错的建议。
UI 方面会做些优化。

@musicode 网络头像怎么处理的能说明下吗

@Percy0016 下载到本地，再用本地路径显示

@musicode 图片如何下载到本地，还有语音消息如何下载到本地

我用的是 react-native-fs 下载

@musicode 好的谢谢，上传语音也是 react-native-fs吗，这个上传只支持iOS好像

@musicode  确保所有资源都下载到本地之后，再能加入消息列表，这样的等待时间有时候很长；2.下载好一个就 append 一个，这样无法保证顺序。这个问题你们最后怎么处理的

语音消息，在录制时，如果选择试听，再点发送，duration 为 0

加载远程图片（包括头像）和音视频，是否能内置此功能，而不要外面先下载，再传本地路径。理由是，按照目前的做法，先用默认资源占位（图片还好说，音视频怎么默认），再去下载，下载成功后更新消息，如果下载时间很短，会有闪烁的效果（从默认图->本地图），如果下载时间很长，没有 loading 效果，体验较差

事件消息，貌似顶部有一条颜色稍暗的线，是否可参考微信的样式呢，看着更舒服

聊天列表底部没有 padding

@musicode 26 加载图片，完全是你可以在 ImageLoader 里自定义的。如果你使用了第三方库如 Picasso，Glide 都是支持加载远程图片的。

@musicode

我这边是没有黑线的，是不是你自己设置问题。padding 下个版本加上。

@KenChoi1992 是 ios 的问题，已修复了

@huangminlinux @KenChoi1992 event 消息的灰色背景上下 padding 是不是太大了啊

@musicode 5dp

目前比较影响体验的问题还有如下几个：

输入框自动增高，并可配置最多显示几行
拍照和拍视频后，可预览，并根据预览的结果选择丢弃或发送
单条消息的复制和删除
下拉刷新可配置提示文字，如“正在获取更早的消息...”
连续输入表情导致表情换行后，行间距太小

@musicode 输入框的确实有待优化。第2，3个问题你可以在回调的接口里自己实现。下拉刷新可以自己实现 Header。Android 的话，参考 https://github.com/liaohuqiu/android-Ultra-Pull-To-Refresh，只要替换 Header 就可以实现了。

@KenChoi1992 我只会 RN，你说的实现方式对我来说不现实。。。

@musicode 好，下个版本计划支持，搞个 demo 看看。

@musicode 原生的输入框优化了，rn 版的试试 dev 代码。ChatInput 新增了一个方法 onLineChanged 可以参考 sample 下的 app.js 。iOS 尚未支持输入框适配。

@KenChoi1992 谢谢

messageList.setShowSenderDisplayName(0);
messageList.setShowReceiverDisplayName(0);
好像都没用额

@santa-cat  可以参考 demo 用法。

@santa-cat 1 表示显示名字，0 表示不显示啊

目前比较影响体验的问题还有如下几个：

拍照和拍视频后，可预览，并根据预览的结果选择丢弃或发送
单条消息的复制和删除
下拉刷新可配置提示文字，如“正在获取更早的消息...”
连续输入表情导致表情换行后，行间距太小

你们还有计划继续优化吗？

使用发图片、录音、拍视频等需要授权的功能，在第一次询问权限时如果用户选择否，当用户之后再次点开这些功能时，是否可以提示用户去开启权限呢，现在的情况是底部一片白，一脸懵逼。。。

下个版本处理权限问题。之后版本支持拍照视频预览。

下个版本这周会发么？

下周发。

Bug:

【IOS】scaleImage 压缩出来的图片比例错误
【IOS】点击图片按钮，选一张图片，收起 feature view，点发送按钮，发送按钮旁的数字未清零
【IOS】表情乱码，大小不一致，表情气泡 padding 不一致
【IOS】 inputLineHeight 无法设置，且默认值偏大

建议：

输入框支持圆角配置
是否可以发相册里的视频？
聊天气泡支持最大宽度配置
iphonex 适配，包括 featureView 非展开状态，录音预览状态下的取消发送按钮，拍照全屏时右上角按钮偏上、底部三个按钮偏下

[如发现新问题，继续更新]

@musicode  给你个赞.  文档还是挺坑的, 很多没说明, 比如iOS下图片和头像是不支持网络加载.

可以参考这样做菜单吗，我发现录音那个怎么左右两边的图标不能点（不知道干嘛的），若是我自定义一个更多的菜单参考上图，怎么添加上面的菜单的子菜单的点击事件。

拍照功能为什么是缩在下面，而不是全屏的？能否提供选项使用全屏模式

初始化列表时，有什么方法可以直接定位到底部，而不是先在顶部再滚动到底部吗

请问这个问题有优化解决吗？原生修改源码能不能解决这个问题？

authors: Geocld HHuiHao KenChoi1992 PeterLocas huangminlinux istarvip musicode santa-cat spidersq

repo: jpush/aurora-imui

license: mit

license_source: bigquery


text:
Weird layout when combining multiple long events and multiple short events

Do you want to request a feature or report a bug?
Bug
What's the current behavior?
For 15 min intervals, when you combine long and short events together, the short events truncate and start a weird ladder. The top pic is from react-big-calendar and the bottom picture is from google calendar.

I've tried #1530 's solution of setting dayLayoutAlgorithm but it didn't fix this issue either.
Setup:
step=15 and timeslots = 4 for 15 min intervals
You can also replicate this using the dnd calendar on the official site

What's the expected behavior?
There's no ladder when displaying shorter events alongside longer events. The successive short events should be aligned in the center fo the long event

I have the same problem. With settings: step=30 and timeSlots=2. The problem does not occur when the two events overlap, but there is a problem with the third. Same problem for day, week and workWeek view.
Correct behavior when two events overlap:

Bug when I add the "Test8" event, which is the third overlap:

Any suggestions on how to fix this?

I read some bugs here and tried to use their solution, but nothing helped. It's a bug.
Previously, the same problem manifested itself in the second level, where it is now fixed. The same fix is needed for the third level of events.

I had this issue and it seems like using the hidden property dayLayoutAlgorithm='no-overlap' solved the problem for me.

Bump on this! Has anyone come up with a solution or workaround?

authors: JakubSirek juangrases mikeyyyzhao milkman4

repo: jquense/react-big-calendar


text:
Core: guard against null & undefined values in required method

Ref #2049

I don't think there is a way to test it without using the normalizer. But the normalizer will not return undefined or null until #2054 was merged.
I will update the tests of the other PR and merge it and then update this one to use the normalizer.
For now, I added a description to the commit describing the needs for this fix.

Merged the other pr, we can add the tests here

We are good to go.

I'm going to merge this for now.
Thanks for the review and for merging the other PR.

Awesome that our normalizer layer also turned out to be a good value-mocking test utility 😸

Yes, and also I see (from Stackoverflow and here) that a lot of folks are using it and found it useful too.
Thanks :)

authors: Arkni staabm

repo: jquery-validation/jquery-validation


text:
"Unexpected token" with import statements

Running the following gives an "Unexpected token" error:
esprima.parse('import foo from "bar"');

esprima 2.5.0
node 0.12.7
npm 3.2.0
The online parser demo at http://esprima.org/demo/parse.html also gives this error.
Is import/export syntax not supported yet?

You need to specify that it is a module that is being parsed (vs a script):
esprima.parse('import foo from "bar"', { sourceType: 'module'} );

Thanks, figures I was missing something simple :)

@nebrius Glad to know it's working for you :-)

Use like below.
esprima.parseModule('import foo from "bar"');

authors: ariya nebrius ramsunvtech

repo: jquery/esprima


text:
Apply Torque Constraints from URDF in Controller

Dear @gergondet and @arntanguy,
I am currently working on applying torque constraints to the robot joints using the effort limits specified in the URDF file. Initially, I expected that the effort limits would be automatically applied by the system, similar to position and velocity limits. However, it appears that a dynamics constraint needs to be explicitly added to the controller to enforce the torque constraints.
To address this, I declared an object of the DynamicsConstraint class in the controller header as follows:
mc_solver::DynamicsConstraint robotTorqueConstraint = mc_solver::DynamicsConstraint(this->robots(), 0, this->timeStep, {0.01, 0.001, 0.05}, 1.0, false);
In declaration, I used the one with the damper and velocityPercent since the other one would cause a QP failure once it is called.
Then, I added this constraint to the solver in the controller:
robotTorqueConstraint.addToSolver(solver());
Additionally, I adjusted the default minimum and maximum torque values in Robot.cpp from zero to infinity to allow the robot to walk:
fill_bound(mb, "lower torque", bounds.at(4), &rbd::Joint::dof, -INFINITY, -INFINITY),
fill_bound(mb, "upper torque", bounds.at(5), &rbd::Joint::dof, INFINITY, INFINITY)
Without these adjustments, the robot exhibits sudden, erratic movements and is unable to walk.
At this point, the robot walks without any issues, but it seems that the torque constraints specified in the URDF file are not being applied to the system.

The above image shows that the robot walked a few steps with the effort limit set to 100 for all joints. The joint torques and limits are shown only for L_HIP_R and R_HIP_R for clarity, but the same issue is observed for the other joints. Despite this, it is evident that the joint torques exceed these limits. I have double-checked the torque limits in the controller, and they match the URDF.
Could you please advise if there are any additional modifications or steps required to ensure that the torque constraints are correctly enforced?
Thank you for your assistance.

Hi @gergondet, @arntanguy, @mmurooka, @antodld,
I am following up on the issue I opened earlier and was hoping someone from your team could respond.
As an update, in the meantime, I have tried to apply this tutorial, which suggests that torque constraints can be applied by simply changing kinematicsConstraint to dynamicsConstraint. I made this change and added the following lines to establish contacts between the robot's feet and the ground:
addContact({robot().name(), "ground", "LeftFoot", "AllGround"});
addContact({robot().name(), "ground", "RightFoot", "AllGround"});

However, the output is unsatisfactory, as it shows a strange motion of the robot attempting to walk without the contacts being properly updated.
Could someone provide guidance on resolving this issue?
Thank you.

@antodld
Thanks for your response.

Can you specify the robot you are using and if you are making your test with a custom controller ?

I am working on a custom biped robot, and the controller is similar to this one.

To verify this, could you please add the following lines to the controller constructor function:

I already have that part of the code you provided. It’s actually available in mc_rtc as tauOut. I also have access to tauIn, which comes from the Choreonoid simulation.
I have analyzed the difference between them based on this issue. I can confirm that tauOut considers the URDF effort limits in the QP solver, but I'm seeing a noticeable difference between tauOut (computed by the QP solver), and tauIn (measured from sensor/Choreonoid). I’ve attached a comparison for knee and ankle pitch below:

It seems that tauIn is more accurate since the joint torque values make more sense.
I have a few clear questions based on my findings:

What is the main reason for the discrepancies between tauIn and tauOut? Do you also see this discrepancy in your robot?

Are we only able to set the limits on tauOut? Is there a way to apply limits on tauIn? This seems to be the primary goal of having a torque constraint. Otherwise, setting torque limits in the QP solver, which produces torques significantly different from what we actually measure, does not seem to make sense.

I would appreciate any insights from other contributors as well@arntanguy @gergondet @mehdi-benallegue

What is the main reason for the discrepancies between tauIn and tauOut? Do you also see this discrepancy in your robot?

The QP is formulated having the joint accelerations as the decision variables. Those variables are then integrated twice and fed to the simulation environment. Choreonoid then simulate a PD behavior on each joints. This is why you have no guarantee to obtain similar torque as choreonoid does not directly use the joints torques information.
Moreover, if your controller is similar to lipm_walking controller, it means that you are using a stabilizer. The stabilizer computes a wrench distribution on the contacts that is not linked to the one computed by the QP. This discrepancy can then be seen in the torque measurements.
Keep in mind that in a position control loop, the QP state is open loop which means that any discrepancies in the robot state such as oscillation are not considered. The stabilizer is an exception but the desired forces being applied through admittance tasks, the discrepancies remains.

Are we only able to set the limits on tauOut? Is there a way to apply limits on tauIn?

tauIn is a measurement and therefore cannot be bound direclty. Ensuring a bounded tauIn imply that the real robot has a torque control loop, that way the tauOut will be directly fed as reference with their set boundaries
Otherwise, to bound the joints torques on the real robot, the PD control outputted desired torque should be bounded but this can result in poor tracking of the joint values

authors: Ahmadreza-Shahrokhshahi antodld


text:
Respond to https://hypothes.is/a/3xjy2nXeEemwIgfyufEq4A

Respond to hypothes.is annotation 3xjy2nXeEemwIgfyufEq4A on https://jrnold.github.io/r4ds-exercise-solutions/transform.html (user: acct:cfgauss@hypothes.is, created: 2019-05-14T00:26:09.687908+00:00, updated: 2019-05-14T00:26:09.687908+00:00)

below the

Link: https://hyp.is/3xjy2nXeEemwIgfyufEq4A/jrnold.github.io/r4ds-exercise-solutions/transform.html

duplicate


text:
Potential issue with array

From my understanding, the following rule should trigger the associated action. But it does not with the current code.
Is this allowed by the current framework?
d.ruleset('test', function() {
        whenAll: m.array.anyItem(item.field2 == m.field1)
        run: console.log("ok", JSON.stringify(m))
});

d.post('test',{field1: 8, array: [{field2 : 8}]});

Thanks for reporting this issue. This case should work. I have pushed a fix. Please use version 2.0.20

your fix works properly, thanks

authors: hea-lab jruizgit

repo: jruizgit/rules


text:
[python] returning a list in c.s.field possibly causing the subsequent rules throw: MessageNotHandledException

Hi again,
While I was making my code more complex I've come across a weird issue which I can't tackle.
I'm using durable_rules in a way I described in #302
I'm calling a few rulesets on the same JSON/dict with post() in a sequence (looped).
Taking the same example:
with ruleset('is_color'):
    @when_all(m.source_object.Obj_color != None)
    def is_color(c):
        value = str(c.m.source_object.Obj_color)
        c.s.wrt = {'path': 'target_obj.sub_obj.target_field',
                       'value': value}

Will do what I expect
Rule: is_color
        value: Blue
        Done.
Rule: is_shape
        value: Cylindrical
        Done.
Rule: is_weight
        value: 0.1
        Done.
Rule: is_height
        value: 2.0
        Done.

But when changing the "return value" to be a list of objects
c.s.wrt = [{'path': 'target_obj.sub_obj.target_field',
                       'value': value}]

does break the subsequent rules and they won't execute anymore
Rule: is_color
        value: Blue
        Done.
Rule: is_shape
        Undefined rule in ruleset: is_shape  (MessageNotHandledException)
Rule: is_weight
        Undefined rule in ruleset: is_weight (MessageNotHandledException)
Rule: is_height
        Undefined rule in ruleset: is_height (MessageNotHandledException)

These messages are the product of my looped post() calls in a try/except block like
rule_set = ['is_shape', 'is_color', 'is_weight', 'is_height']

for rule_ in rule_set:
    print(f'Rule: {rule_}')
    meta = None
    try:
        answer = post(rule_, obj)
        if answer.get('wrt'):    # update m_json
            meta = answer.get('wrt')
            if isinstance(meta, dict):
                _set_do(m_json, meta['path'], meta['value'])
            else:
                for obj in meta:
                    _set_do(m_json, obj['path'], obj['value'])
        if answer.get('lap'):    # append to a list in the json
            meta = answer.get('lap')
            if isinstance(meta, dict):
                _append_do(m_json, meta['path'], meta['value'])
            else:
                for obj in meta:
                    _append_dot(m_json, obj['path'], obj['value'])
        if answer.get('msg'):   # message/log
            meta = answer.get('msg')
            print(f"{meta['type']}: while processing {meta['name']}; "
                  f"{meta['msg']} ({meta['field']}:{meta['value']})")

        print('\tDone.')
    except MessageNotHandledException:
        print(f'\tUndefined rule in ruleset: {rule_} (MessageNotHandledException)')
    except MessageObservedException:
        print(f'\tMessageObservedException in rule: {rule_}')
    except Exception as e:
        raise

The list of objects is essential to make multiple inject to the target JSON/dict based on one rule.
Do you have any suggestion/idea to solve this?
I'm sorry for the silly examples but I can't share any of the actual data.

Well, I've tried pretty much everything I could come up with to make durable_rules 2.0.19 accept a list() as dictionary value. No avail, it ends up messing up the subsequent rulesets.
Through, I have a workaround. Defining the list of objects as a nested object, like:
c.s.wrt = {
            1: {'path': 'path1', 'value': True},
            2: {'path': fpath2.{up}.flags', 'value': {}},
            3: {'path': f'path3.{down}.flags', 'value': {}},
            4: {'path': f'path4.{up}.state', 'value': {}},
            5: {'path': f'path5.{down}.state', 'value': {}}
        }

can be iterated - with some restrictions - like:
if answer.get('lap'):    # append to a list in the json
    meta = answer.get('lap')
    if isinstance(meta, dict) and 'path' in meta.keys():
        _append_do(... )
    else:
        for idx in meta.keys():
            _append_do(m_json, meta[idx]['path'], meta[idx]['value'])

the keys of the container-dict are completely arbitrary, could be anything, except
the keys of the container-dict must be different from the keys in the nested (repeated) dict
never use list()/[]as value

Hi, thanks for asking the question. Returning a list actually works fine:
For this code:
from durable.lang import *

with ruleset('is_color'):
    @when_all(m.source_object.Obj_color != None)
    def is_color(c):
        value = str(c.m.source_object.Obj_color)
        c.s.wrt = [{'path': 'target_obj.sub_obj.target_field',
                       'value': value}]

print(post('is_color', {'source_object': {'Obj_color': 1 }}))

The output is:
{'sid': '0', 'id': 'sid-0', '$s': 1, 'wrt': [{'path': 'target_obj.sub_obj.target_field', 'value': '1'}]}
Which is what I expected. Looking closely at the code you pasted:
# removed code for clarity
    try:
        answer = post(rule_, obj)

# removed code for clarity

             if isinstance(meta, dict):
                _set_do(m_json, meta['path'], meta['value'])
            else:
                for obj in meta:
                    _set_do(m_json, obj['path'], obj['value'])

It seems the value of obj changes each iteration when the value of wrt is not a dictionary.

You made me think. I wrote a long explanation of my code when I noticed what's the issue...
I think you point at the silly mistake calling two distinct things to obj in the same block.
It's embarrassing wasting your time with such a mistake.
Thanks a lot!

authors: GergelyMolnar jruizgit


text:
Add test for background property

Test fails but it shows that background property doesn't work for positions.
It seems shorthandParser doesn't fit well for background property.

Closing stale PR. If this is still needed, please reopen a PR.

repo: jsakas/CSSStyleDeclaration


text:
Tracking Conditions

I noticed looking through there is nothing on the character sheet for tracking conditions. Even if they don't automatically apply their effects that would be a really great QoL feature for this system as the conditions are very important to play. Thanks for your work on it so far!

This is still on the todo list.  I use status icons to track it on the tokens currently.
I've a sizable update in the works that includes more control over combat teams, that will include condition tracking as well

Are you open to contributions? If so, getting that list into Issues would help me get my bearings - I wrote my own Foundry system using many of your same techniques, though I haven't used Svelte. (I wrote mine with TypeScript + React.)

I am open to contributions, but this system is a bit of a mess at the moment.  I was in process of a major combat overhaul and v11 broke some of my work. I just haven't had time to fix everything.  I am hoping to have some time to dedicate to things mid july

I am nearly finished with the next update that includes some major system updates and v11 support.  Here are the icons for tracking conditions

outputStatus.webm
Video Sample of Status tracking

authors: Crabe9 jsavko mdekrey

repo: jsavko/mouseguard


text:
🛑 Linus-Wordpress is down

In ca18662, Linus-Wordpress ($SERVER_BASE/wordpress/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Linus-Wordpress is back up in 65a8ea1 after 10 minutes.

repo: jscmidt/upptime


text:
🛑 Grafana is down

In 18c625d, Grafana ($SERVER_BASE/grafana/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Grafana is back up in a8559ab after 20 minutes.


text:
🛑 Nextcloud is down

In cddbe68, Nextcloud ($SERVER_BASE/nextcloud/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Nextcloud is back up in e2c1c9d after 31 minutes.


text:
Add ability to declare acceptable values for the rules

Now this responsibility falls on the configure method, but it would much easier if this method would be replaced by some declaration like:
values: [{
    type: "object",
    value: {
        type: "string",
        value: "allExcept"
    }
}, {
    type: "boolean",
    value: true
}];

we couldn't fully dispose from the configure method, but it will simplify a lot of things
/cc @mdevils

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/7625533-add-ability-to-declare-acceptable-values-for-the-rules?utm_campaign=plugin&utm_content=tracker%2F281640&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F281640&utm_medium=issues&utm_source=github).

It can be replaced with a function({Conf} conf) with some conf.registerRuleValue inside.
Also one rule could handle several rules and values. And also one rule could have aliases (for modern configuration).
But fully declarative version (yours) will also be good.

As I can remember, @mikesherov wanted to do something about it.

As I can remember, @mikesherov wanted to do something about it.

Yeah, i remember something like that, although no one responded when i repeatedly ask about this, hence the ticket

Looks good and manageable. Nice work, Oleg.
Who will implement the validation using this? I can help port some rules
once the validator is in master.
We just have to make sure no rule currently overrides this.values in its
configure. If none do, the validator can just check for the existence of
values on a rule and run the validator then configure, or just run
configure. Hence, the validator can be shipped quickly without being used.
On Jan 9, 2015 4:02 PM, "Oleg Gaidarenko" notifications@github.com wrote:

Now this responsibility falls on the configure method, but it would much
easier if this method would be replaced by some declaration like:
values: [{
type: "object",
value: {
type: "string",
value: "allExcept"
}
}, {
type: "boolean",
value: true
}];
we couldn't fully dispose from the configure method, but it will simplify
a lot of things
/cc @mdevils https://github.com/mdevils
—
Reply to this email directly or view it on GitHub
https://github.com/jscs-dev/node-jscs/issues/895.

Who will implement the validation using this?

Whoever is capable and have time to do this :-), after 1.10 my next item is jquery tasks, there is a lot them accumulated out there.

We just have to make sure no rule currently overrides this.values

configure method usually set only private properties (style which @mdevils set long time ago, nice going btw :-) i.e. with "_" prefix, so we should be good there.

Hence, the validator can be shipped quickly without being used.

That is my thought exactly.

I think I still have an open issue about this somewhere...
My thoughts were to make rule values declarative rather than having functions. This would also make documentation auto generate able.

We can try to use here https://github.com/molnarg/js-schema/ or analogue. But it's 24Kb. Probably we can find more lighten solution.

Came across

https://github.com/arasatasaygin/is.js
https://github.com/philbooth/check-types.js
https://facebook.github.io/react/docs/reusable-components.html#prop-validation - maybe even React.propTypes?

Some ideas on a declarative format:
values: [
    // true,
    // number,
    // string
    // one of the strings in an array
    // object with properties 'beforeOpeningRoundBrace' and 'beforeOpeningCurlyBrace' which are both true
];

values: [{
    type: "boolean",
    value: true
}, {
    type: "number" // maybe no value?
}, {
    type: "string"
}, {
    type: "string",
    value: ['a', 'b', 'c']
}, {
    type: "object",
    value: [ // not sure how this would work
        {
            type: "string",
            value: "beforeOpeningCurlyBrace"
        },
        {
            type: "string",
            value: "beforeOpeningRoundBrace"
        },
    ]
}, ];

// use constructor functions?
values: [
    true,
    Number,
    ['a', 'b', 'c'],
    {
        beforeOpeningCurlyBrace: [String]
        beforeOpeningRoundBrace: [String]
    }
];

// react type (namespaces to represent things)
values: [
    Types.true,
    Types.number,
    Types.oneOf(['a', 'b', 'c']),
    Types.object({
        beforeOpeningCurlyBrace: Types.arrayOf(Types.String)
        beforeOpeningRoundBrace: Types.arrayOf(Types.String)
    })
];

I like the 2nd one if something like that is possible.

Nice stuff. Thanks! ;-)
About 2nd one: https://github.com/molnarg/js-schema/ — 25Kb, can be used in browser. Is it fine for us?

Looks like ESLint has an issue about notifying on config options using a declarative approach too! There's also https://github.com/mafintosh/is-my-json-valid and https://github.com/hapijs/joi.

Do we know if we're going to use another tool to validate or make our own?

Looking to use one of the suggested tools. The proposed schema would change
to fit the tool. Experimenting with the options for now.
On May 19, 2015 8:14 AM, "Henry Zhu" notifications@github.com wrote:

Do we know if we're going to use another tool to validate or make our own?
—
Reply to this email directly or view it on GitHub
https://github.com/jscs-dev/node-jscs/issues/895#issuecomment-103463956.

What options do we have on the table?

I've been looking at the ones suggested in this thread mostly. @hzoo's suggestion of https://github.com/mafintosh/is-my-json-valid feels like the best one so far. I'm in the middle of a prototype with it, so no guarantees that it'll work just yet.

Yeah that's the one ESLint is planning on using as well - https://github.com/eslint/eslint/pull/2179

authors: hzoo markelog mdevils mikesherov mrjoelkemp zxqfox

repo: jscs-dev/node-jscs


text:
New rule: disallowCurlyBraces

#726
The same as requireCurlyBraces except addError on === 'BlockStatement' instead of on !== 'BlockStatement'.

Coverage increased (+0.08%) when pulling 934678b60b626171dc89e647e999c4465d8c6afe on hzoo:disallow-curly-braces into f53e30ab92e5d2a2d0ef0c70e823344d66ccfabd on jscs-dev:master.

@mikesherov, @mrjoelkemp please check it out

@mikesherov I didn't change much from requireCurlyBraces but it's a good time to refactor/use the new functions we added if possible. I'l also fix the stuff you noted.

Should we get rid of Curly in name? Braces are { and } already.

There is a lot of redundancy and inconsistency in the rule names, everything of which should be addressed in 2.0.
Since this is opposite rule it wouldn't makes sense to get rid of it now, but totally should be done in the future.

Fixed the docs, used forEach, moved else check, removed check for case and default and associated tests, and made a isBlockStatement function

Coverage increased (+0.06%) when pulling 4ecc235a7edf47fe90fd3daca62d1e5f7c8f58c8 on hzoo:disallow-curly-braces into b4ab2287c1cd0052bf13a69c61302b8e24933035 on jscs-dev:master.

@hzoo, I don't see how this rule allows:
if (x) {
  a();
  b();
}

which it needs to allow. Can you also please add some tests for that?

Oops - yeah that's important! added a check for multilines and tests

Coverage increased (+0.02%) to 98.65% when pulling c76ecced456d61893ca8d9e95080a960afdd7b8e on hzoo:disallow-curly-braces into ca77989defdee0320f92fb029ca61fa062ed0f35 on jscs-dev:master.

Ok I see you meant report an error whenever there is a single statement  - you would want them to change it so its a single line if it takes up multiple like with the array one.

@hzoo, to be clear:
if (a) {
  b = [
    c
  ];
}

can be rewritten to be either:
if (a) b = [c];

or
if (a) b = [
  c
];

. Both are valid javascript.

Coverage increased (+0.02%) to 98.65% when pulling e9b52ac57b9bbd23d6bd01220428f24673652031 on hzoo:disallow-curly-braces into ca77989defdee0320f92fb029ca61fa062ed0f35 on jscs-dev:master.

OK, I have one minor last change, but I'll make it when landing the PR. Thanks again @hzoo

Ok cool

Thanks again @hzoo landed with a small change:
file.findPrevToken(
+                        file.getTokenByRangeStart(node.alternate.range[0]),
+                        'Keyword',
+                        'else'
+                    ));

to
file.getPrevToken(file.getFirstNodeToken(node.alternate))

for future reference.

Ok yeah I need to get more familiar with the API. We could also clean up requireCurlyBraces later

@hzoo if you'd like to clean up requireCurlyBraces, now is a good time to do that. Thanks again!

authors: coveralls hzoo markelog mikesherov zxqfox


text:
Missing workspace.json

When executing nx run workspace:version --sync-versions true --root-changelog false in my nx repo I get the following warning:
(node:7184) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, open 'project/workspace.json'
(Use `node --trace-warnings ...` to show where the warning was created)
(node:7184) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:7184) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

NX version: "@nrwl/workspace": "11.1.5"

@petergrau Could you provide a reproduction please? I will dig in it. However the path 'project/workspace.json' seems not correct  at first look but I need to have more context.

@petergrau Could you provide a reproduction please? I will dig in it. However the path 'project/workspace.json' seems not correct at first look but I need to have more context.

I added semver using ng add @jscutlery/semver and then executed nx run workspace:version --sync-versions true --root-changelog false. (Adding it complete without an error.)
(project was the replacement for the path to the nx workspace)

Oh ok I didn't noticed it was a warning. I see now, it's because we're reading the angular.json file this way :
return readJsonFile(resolve(workspaceRoot, 'workspace.json')).pipe(
  catchError(() => readJsonFile(resolve(workspaceRoot, 'angular.json')))
);

We should check if the file exist before reading it, but I don't get why an unhandled promise is raised, we're actually handling the error notification.

Thanks @petergrau for the issue.
There was actually a problem with the readJsonFile function as it is using from instead of defer. If the error is triggered before we subscribe and implicitly add an error catcher, it would crash. I am sharing a fix right now.
@edbzn Actually, I am more in favor of the pythonic approach of "Easier to Ask for Forgiveness than Permission" https://docs.python.org/3.9/glossary.html#term-eafp instead of https://docs.python.org/3.9/glossary.html#term-lbyl 🐍

I didn't know about these approaches and I love it! I use it in real life too, so why not in code. :smile:

It also works in the mountains. If I fall then it's a hole 😅.

authors: edbzn petergrau yjaaidi

repo: jscutlery/semver


text:
Run 'git add' at once after all changelog files have been generated

This PR addresses https://github.com/jscutlery/semver/issues/95 which is caused by trying to stage the changelog files concurrently. The solution is generating/updating all the changelog files then stage them all at once.

I rebased your branch to follow the semantic commit format and I added a test case (#109). Thank you so much for your time! :+1: :fire:

Thanks, there was a failing test and was working to fix it, but I didn't really have a clue. Now I see it was because the git module is mocked.

By the way, this was my first open source contribution, thanks for the opportunity :)

@Katona Oh sorry, I should have helped you instead, in any case I really appreciate your contribution. :blush:

authors: Katona edbzn


text:
3.6.7: Fix for "Do not know how to serialize a BigInt"

When I'm using BigInts in my code I get this error message Do not know how to serialize a BigInt.
I know how to fix this problem, but do not ask me to create a pull request (since I do not have any knowledge of how to do that or any interest).
To fix it replace line 142 in the file lib/jsdoc/util/dumper.js with:
result.push( JSON.stringify(walker.walk(arg), (key, value) => typeof value == 'bigint' ? value.toString() : value, 4) );

I have also run into this issue

JSDoc 3.6.10

Open  /node_modules/jsdoc/lib/jsdoc/src/astnode.js
Add function

function strReplacer (k, v) {
  if (typeof v === 'bigint') {
    return v.toString() + 'n'
  }
  return v
}

Replace all JSON.stringify(tempObject) to JSON.stringify(tempObject, strReplacer)

Yo

should jsdoc add that by default? manually editing a lib isn't quite right

Alternative solution without source patching: use .js config with this code:
// BigInt JSON serialization.
BigInt.prototype.toJSON = function() {
	return this.toString() + 'n';
}

Still monkey patch too 😅 .

Any news?

authors: JoakimCh Lexus274 aikawayataro datdinhquoc kongnet mahnunchik sg-p4x347

repo: jsdoc/jsdoc


text:
Classes and Namespaces not sorted

In the panel on the right the lists of classes and namespaces are not sorted alphabetically. This looks shoddy and compromises usability in that it can be hard to locate an item of interest if there are many such items (thus forcing the user to resort to the browser's built-in 'Find' capability).
For example, in the JSDoc for the REST interfaces of the enterprise-grade application on which I am currently working, there are 1552 classes distributed across 64 namespaces - this many items are simply not visually scannable.

I'm experiencing this too, it's quite rough. The classes seem to be alphabetically sorted by their slug, e.g. module-mymodule_mysubmodule.MyClass.html, but they need to be sorted by the actual text of the link, e.g. MyClass.

authors: demonfiddler stevenvergenz


text:
Make the augment module more efficient

The augment module currently iterates over all the doclets three times--once per doclet property that might cause us to augment the parse results. We should modify this so that if you call augmentAll, we gather all the dependencies in a single pass, rather than one pass per property. I expect this change to speed up the augmentation process considerably.
We should benchmark this change against a large JavaScript package such as Closure Library.

Well, so much for that idea! My "only iterates over the doclets once" code took ~28s to run for Closure Library, versus ~6s for the current implementation. Who knows why.
In any case, if it only takes ~6s to call augmentAll for Closure Library, there's no sense in obsessively optimizing augmentAll.


text:
Add circle icons

Allow the user to choose between square icons like 🟩🟩🟩🟩🟩🟨⬜⬜⬜⬜
buildMRRSquaresForTwitter(numOfTenRounded, GOAL, 'square')
or circular ones like: 🟢🟢🟢🟢🟢🟡⚪⚪⚪⚪
buildMRRSquaresForTwitter(numOfTenRounded, GOAL, 'circle')

Oh this is fantastic! Thanks @medyo ! 🎉

authors: jsjoeio medyo

repo: jsjoeio/twitter-stripe-mrr


text:
Nested Objects without globally unique ID

We are not quite sure how we should handle associations where the nested resource doesn't have a globally unique id.
This example demonstrates the issue:
We have a User model that has many Settings. A Setting has a unique id within the user, but another user could have the same setting-ids.
users = [
  {
    id: 123,
    settings: [
      {
        id: "settingA",
        value: true
      }
    ]
  }

  {
    id: 234,
    settings: [
      {
        id: "settingA",
        value: false
      }
    ]
  }
]

When we create a JSON-API response it wouldn't be clear which Setting belongs to which User.
{
  data: [
    {
      id: 123,
      type: "users",
      links: {
        settings: {
          type: "settings",
          ids: ["settingA"]
        }
      }
    },
    {
      id: 234,
      type: "user",
      links: {
        settings: {
          type: "settings"
          ids: ["settingA"]
        }
      }
    }
  ],
  linked: [
    {
      id: "settingA",
      type: "settings",
      value: true
    },
    {
      id: "settingA",
      type: "settings",
      value: false
    }
  ]
}

We didn't find any documentation or open issue for this topic. Our proposed solutions would be:

We could use temporary unique IDs within one request for each Setting. But this would not work with the restfulness of our API. Eg. updating a Setting through its restful URL wouldn't work with the artificial ID.

One way to generate such a temporary ID is to create a compound key. Eg. "user-123.settingA".

We could just embed the settings array as it is in the user. This would work for this simple example. If the data for the association is handled in a different service or database it could be more complicated or unwanted if the association should lazy loaded.
We could replace the string ID in the links section with an hash.

Example 1 uses an hash as ID. The ID of the Setting objects in the linked section is also replaced by an hash. So the query is somehow conform to the query by string. The drawback is that the objects in the linked section lose the original ID format.
Example 2 also uses an hash as ID. The query in the linked section works different than in Example 1. All attributes of the hash in the links section are used to match the objects attributes to find the associated object in the linked section. This solution makes the most sense from out point of view.

It would be great if you could give us feedback.
Hash ID Example 1
{
  data: [
    {
      id: 123,
      type: "users",
      links: {
        settings: {
          type: "settings",
          ids: [ { id: "settingA", user_id: 123 } ]
        }
      }
    },
    {
      id: 234,
      type: "user",
      links: {
        settings: {
          type: "settings"
          ids: [ { id: "settingA", user_id: 234 } ]
        }
      }
    }
  ],
  linked: [
    {
      id: { id: "settingA", user_id: 123 },
      type: "settings",
      value: true
    },
    {
      id: { id: "settingA", user_id: 123 },
      type: "settings",
      value: false
    }
  ]
}

Hash ID Example 2
{
  data: [
    {
      id: 123,
      type: "users",
      links: {
        settings: {
          type: "settings",
          ids: [ { id: "settingA", user_id: 123 } ]
        }
      }
    },
    {
      id: 234,
      type: "user",
      links: {
        settings: {
          type: "settings"
          ids: [ { id: "settingA", user_id: 234 } ]
        }
      }
    }
  ],
  linked: [
    {
      id: "settingA",
      type: "settings",
      user_id: 123,
      value: true
    },
    {
      id: "settingA",
      type: "settings",
      user_id: 234,
      value: false
    }
  ]
}

In what case do you have two different settings, but with the same ID?

we have a legacy system where we have a nested settings structure for users as described above. the first code block shows the structure within our database.

sorry for being so unresponsive.
with the latest changes of the spec our dilemma has improved a lot. but another related topic popped up:
is it allowed to reference an object without its ID but with other attributes, that define it uniquely?
 {
   "data": {
     "type": "some_object",
     "id": "1",
     "links": {
       "application": {
         "linkage": { "type": "applications", "version": "3.4.5", "key": "com.example.myapp" }
       }
     }
   },
   "included": [
     {
       "type":    "applications",
       "version": "3.4.5",
       "key":     "com.example.myapp"
     }
   ]
 }

in our case, the client doesn't know the ID of the application, only its version and key. the combination of version and key is uniqe.

@lister That isn't allowed, but why not just add an id member to each applications object, where the value of that member is some guaranteed-to-be-unique combination of the key and version members. So you might have:
"included": [
     {
       "id": "com.example.myapp+3.4.5"
       "type":    "applications",
       "version": "3.4.5",
       "key":     "com.example.myapp"
     }
   ]

This "id" key could be added in the serialization layer, and shouldn't require touching your database or any other code.

ic, thx for clarification

authors: ethanresnick lister steveklabnik

repo: json-api/json-api


text:
Callbacks Extension/Support

Hello, I am implementing jsonapi for my application and there's one part where I want to know if there's a convention/extension/set of ideas:
This application has a type which has many states, let's call it articles just for the sake of clarity. The starting point is when the client POST /articles  to create a new one (like specified on jsonapi).
Now, there will be a state machine in which the article can pass through many states, e.g.: drafted. published, closed, etc... And for each of these transitions I want to notify the client, sending additional data.
Is there a use case or any discussion about this related to jsonapi?
Possibly related: https://github.com/json-api/json-api/issues/247
Thanks!

And for each of these transitions I want to notify the client, sending additional data.

Do you want the client to receive state changes on all articles, or only ones it specifically requests to listen to?

@ethanresnick That's a good question. I have multiple clients in which the majority will not need this feature.
Maybe a solution for this would be to have an indication of the callback URL on the resource creation?

Ok, here's what I'd do:
Create a collection/resource type called "listeners" and have the client POST to that to register its callback. Something like:
POST /listeners

{
  "data": {
    "type": "listeners",
    "attributes": {
      "url": "http://uri-that-client-wants-called.com/...",
    },
    "relationships": {
       "subject": {
         "data": {"type": "articles", "id": "id-of-the-article-the-client-is-listening-about"}
       }
    }
  }
}

By defining each listener as its own resource, the client can remove a listener with a standard DELETE request, edit it with a PATCH, etc. It's then your choice how to connect the listener to the resource it's about. (Here, I've created a "subject" relationship on "listeners"—which could be renamed "subjects" if each listener can be used for more than one resource—but you could just as easily do the reverse and create a "listener" relationship on "articles".)
You'll note that adding a listener does take a separate request (i.e. it can't be created from scratch with the article POST), but this may be solved down the line by #536. And, for now, I don't think it's that big a burden.

I like this idea, is there any restriction on why I can't just use the relationships field of the resource POST?
Also, although this is an elegant solution for when all resources share the same callback url, it fails if the client wants to receive a token or a specific url per resource.

I like this idea, is there any restriction on why I can't just use the relationships field of the resource POST?

You can, if the listener's already been created, but that initial creation is still another request. See #536.

Also, although this is an elegant solution for when all resources share the same callback url, it fails if the client wants to receive a token or a specific url per resource.

Just create one listener resource for each callback url :)

So, the problem is that it's very important for me that I can use just one request. It has been already difficult to establish the use of jsonapi with my client, and I don't know if I'll be able to push the need for another request.
In this case I could circumvent this issue by simply associating an attribute for each resource and receiving this attribute on the resource creation. It's not like I disagree with the listeners model, but it's simply not reasible for me to have 2 requests for a single successful resource creation.

Why not use the meta key for this use case?

Yes, you could definitely put the contents of the proposed listeners resource as an attribute of the article instead (though this has some limitations around adding multiple listeners to the same article). You could also use meta as @daliwali suggests--that might be the best answer if multiple requests are out of the question.

Hmm. I'll consider using meta, it pretty much solves my problem. And I'll have just one listener.
I'll still ponder whether I'll use this as a resource attribute or as a meta object, since I'll probably have to write this attribute to the model anyway.
Thanks for the help!
Also, regarding the callback requests themselves, I guess they'll be pretty much like jsonapi but in the reverse?
E.G.: Each article status transition will be a PATCH sending the attributes in vnd.api+json?

I'm gonna give this a close, as the existing options have already been outlined. As I mentioned earlier, we're discussing extensions now in #795 to make this even easier. Here's how it would work with my proposal from #795:
POST /articles

{
  "data": {
    "type": "articles",
    "relationships": {
       "listeners": { "data": [{ "pointer": "/embedded/0" }] }
    }
  },
  "embedded": [{
    "type": "listeners",
    "attributes": { "callback-uri": "http://example.com/" }
   }]
}

This is, of course, also easily doable with the operations proposal in #795.

ok, thanks!

authors: badosu daliwali ethanresnick


text:
Don't allow additional members in error objects by default

This is a PR for #604

My implementation customizes the error object quite a bit. There is a fair amount of useful information that I'm not sure I could shoehorn into the allowed fields. At the very least, can we allow meta on error objects?

@csantero What are the extra fields you've added? Maybe we could include them in base spec. Or, if some of them really apply just to your api, they could always be declared in an extension.

@ethanresnick The additional keys I include in JSONAPI.NET at the moment are:

stackTrace for unhandled server exceptions
inner, which recursively serializes Exception.InnerException properties.

Eventually I'd like to support pluggable formatting on a per-exception type basis, to provide richer exception details. A user of the library could define a custom Exception class with 10 different fields, and there's no way those would map to any-predefined members on the json-api spec. A meta key would be perfect for that.

Ok, I've updated the PR to allow "meta" in errors, so the net effect of this is to continue to allow users to add properties to errors (which there's clearly a demand for), but require them to do it in "meta", so that we can standardize some of those property names down the line without conflict.

:+1:

authors: csantero dgeb ethanresnick


text:
Adding tests for referencing different schema versions

As requested here.  Merging is probably dependent upon resolution of that issue.
Added test for:

referencing draft 6 schema from a draft 4 schema
referencing draft 4 schema from a draft 6 schema
referencing draft 4 schema from a draft 7 schema

The referenced schemas include exclusiveMinimum which was a breaking change between drafts 4 & 6, so they should be a fairly good indicator that a validator supports referencing to different schema versions.
I have tested these with Manatee.Json.
(Feel free to cherry-pick out the .gitignore file.  It's just something I added because I have to work on a Mac for now (ew).)

Which model is this testing, again?

I think these tests would validate for the delegation model, but break for the inclusion model.  In fact, you may go so far as to say they'd be invalid for the inclusion model, which makes the decision in https://github.com/json-schema-org/json-schema-spec/issues/514 that much more important.

@gregsdennis Ok. So if I understand this right, either way, none of the existing tests would break because we've never tested this branch of behavior before.

That issue still has so much activity that I can't follow it at this point :), so apologies if this is still a dumb question, but while I can guess what this is after, does it really depend on remote retrieval? Are implementations not any more or less likely to do this incorrectly just from schemas within definitions inlined?

@Julian I don't know that this was intended to actually be merged.  For now, it serves more of a point in the context of the discussion.
Inlining these is specifically forbidden because $schema has been deemed to only be valid at the root of a document.  These scenarios specifically test compatibility when a referenced schema is defined by a different draft than the schema referencing it.

@handrews I've added your test cases.  They all pass for me.

Got it -- OK, I didn't recall that $schema had to be at the root of an object (actually, I don't think that's in the meta schema from last recollection, is it now?)
But in that case yeah seems reasonable enough.

The failed check by the way is telling you that unfortunately at the minute, any schema that's in remotes actually needs to be in two places, where you put it, but also in a second file.

@Julian I don't understand your comment about the second file.  Where else would I need to put it?

@gregsdennis it needs to go here too unfortunately: https://github.com/json-schema-org/JSON-Schema-Test-Suite/blob/master/bin/jsonschema_suite#L46-L59
(Happy to explain the reasons why, and how we can fix that, which I think I also mentioned in another ticket, but yeah, for now it needs to go there too as a Python object [and no that's not related to my actual personal implementation :)]. If you need help there on exactly the syntax I can help of course)

@Julian I think I missed something.  I thought I got it, but fell short.

I just realized maybe we should have a separate tree, such as tests/latest/ for tests detailing effects of proposed changes to the draft.

@gregsdennis think you did manage to get at least my part now, but there's some JS stuff failing... will have a look to see if I can tell what that is (or maybe someone else knows).

@Julian does the build actually eval the tests to make sure they're correct?  If that's the case, then it may not be set up to handle referencing one schema version from another.

It looks like that part is ajv related, so I don't actually know :) (though I hope not, the Python one does not IIRC, and though I've always had in mind to do so in a separate set of checks, this particular thing was always meant to be literally sanity checking for the tests themselves, not tests of implementation adherence.)
Presumably @epoberezkin might know what the failure means?
As for optional -- as I'd read it, they're not actually optional right? I think an implementation needs to have this behavior.

Ajv requires different configuration depending on which draft(s) you want to support. Even though it's possible to configure it to support 4, 6 and 7 at the same time, because all test suites required supporting only one draft it was configured in this way - different ajv instance is used for each draft.
I can make tests pass, but

Given that these tests are for all validators, it is not fair to require that any validator supports more than one draft, so I don't think they should be merged in any of the draft suites regardless of json-schema-org/json-schema-spec#514 outcome.
If we still want to add tests for validators supporting multiple drafts I suggest creating a separate top level folder, say /tests/draft467, otherwise the validators that want to implement only draft7 won't be able to use draft7 folder without filtering which tests to use. At the very least it should be a separate file.

As for optional -- as I'd read it, they're not actually optional right? I think an implementation needs to have this behavior.

If the validator supports multiple drafts, then it should allow referencing schemas that use different drafts from each other. But supporting multiple drafts is not mandatory...

Got it, fair point, sounds reasonable to stick it in optional then.

(Although if the intention isn't necessarily to even merge this, might not matter much until after our discussion)

@epoberezkin I'm on board for putting these tests in a separate "multi-schema" folder, but I disagree with you on the point that it's unfair to require validators to support multiple drafts.  If an implementor decides not to support a draft, then that's their choice.  For instance Manatee.Json doesn't support draft 3, but it does allow referencing a supported draft from another supported draft (because that's how I interpreted the spec).
It all hinges on the determined definition of $ref.  If it's defined in such a way that an external schema can be any draft, then I would suggest that implementations need to support that functionality.
Furthermore, I think it's more likely in the real world that this could occur, especially in a world where we share and catalog schemas.  See my example.

I would say put it in an existing directory/tree and allow optional schemas
to reference earlier meta-schemas.
On Dec 8, 2017 15:01, "Greg Dennis" notifications@github.com wrote:

@epoberezkin https://github.com/epoberezkin I'm on board for putting
these tests in a separate "multi-schema" folder, but I disagree with you on
the point that it's unfair to require validators to support multiple
drafts. If an implementor decides not to support a draft, then that's their
choice. For instance Manatee.Json doesn't support draft 3, but it does
allow referencing a supported draft from another supported draft (because
that's how I interpreted the spec).
It all hinges on the determined definition of $ref. If it's defined in
such a way that an external schema can be any draft, then I would suggest
that implementations need to support that functionality.
Furthermore, I think it's more likely in the real world that this could
occur, especially in a world where we share and catalog schemas
http://schemastore.org/json/. See my example
https://github.com/json-schema-org/json-schema-spec/issues/514#issuecomment-349752538
.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/json-schema-org/JSON-Schema-Test-Suite/pull/210#issuecomment-350393698,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAatDTejWOm_4C6oB1VZnw03E7oZHeCaks5s-b_AgaJpZM4Q5ASB
.

@awwright

allow optional schemas to reference earlier meta-schemas.

While I understand your intent here (older schema versions wouldn't be compatible with newer schema version), it doesn't address the upgrade scenario I mentioned where a referenced schema is upgraded to a new version.  And to be fair, newer schema versions aren't necessarily compatible with older ones, either.

@gregsdennis I also think these tests should be optional because they should pass only for validators that support multiple drafts - no validator must be required to support more than one draft to be compliant.

@epoberezkin correct, on two points: making these optional seems to be ideal, and validators only need to support those versions they wish to.
Regarding backwards compatibility, that was a response to @awwright's comment about earlier meta-schemas. I agree with you that this Isn't about backward compatibility, but rather schema independence at the $ref boundary.

So now that #514 seems to be resolve, are we waiting on me to move these into an optional folder?  Are we just closing this?  What are the next steps?

@gregsdennis I think we'll keep this open and resolve it after #514 actually gets a PR in.  Since it will technically be a change (the last time the behavior of $ref was explicitly defined, it was defined as inclusion), we'll need to decide how and if that shows up in the drafts where $ref's behavior was left a bit ambiguous.
I'd say rebase this on top of the current master (so the CI checks work again), and then we probably wait until we're closer to draft-08 going out or until (probably after the holidays) we have some consensus on whether we should be testing this with older drafts.
Clearly we would need to test draft-08 referencing older drafts.  What about the other way around?  What about draft-06 referencing draft-04?  What about draft-08 referencing draft-06 referencing draft-04?  We will nail that down during the PR process for #514 ( Everyone: PLEASE DO NOT DEBATE IT HERE!!!! )
If there's stuff you can do now about marking things as optional that's fine.

Yes, If it's in optional it should be ok. Please add it to excluded tests here as "optional/something" (assuming it's in optional folder of draft-07 only), I would later amend the test code so it is executed (and works correctly).

@epoberezkin are we going to proceed with this?  I need some help, if so.

@Julian @epoberezkin I'm not sure what I need to do to make this build.

@gregsdennis will try and have a look what the story was here

Sorry for leaving this hanging :/ I saw it likely required some ajv understanding and therefore wouldn't be a 5 second thing for me either -- but @gregsdennis definitely haven't forgotten about it, will see if I can eventually get some time to decipher what this is about...

Bleh, and not close the issue accidentally...

@gregsdennis I don't know what the heck GH did (in combination with whatever I did) which made this PR close and not be able to be reopened, but we never added these. Any chance you're interested in resubmitting it?

We probably need to consider how to write it precisely, since an implementation may support any possible subset of previous drafts...

I'll have a look tomorrow. 👍

I'm wondering how scalable this kind of test is.  Would we need to include tests for all of the draft combinations?

It doesn't scale very well, I think your implication is right, but in practice I suspect we can still be useful enough by simply starting with a few pairs of drafts as you did and deciding / waiting later to hear whether someone needs another combination we didn't yet add.
I.e. I think yeah ideally we'd have number-of-releases choose 2 scenarios which is 10 cases for {6, 7, 2019, 2020, next}, but if we just have 3 or 4 of the 10 which we think are the most likely then I think we're probably better off than not having it at all, personally. But yeah if you've got a better idea lemme know.

I'd ultimately want both directions, too.  Given to draft 6's, you can update either to 2020-12, and they shouldn't break in either case.  So it's number-of-releases permute 2.

Fair enough though the same applies I think -- we don't need 20 to say we've improved things, if we just have 4-6 we're probably covering enough?

I don't have this branch anymore.  I'm going to have to rebuild it anyway.

authors: Julian awwright epoberezkin gregsdennis handrews

repo: json-schema-org/JSON-Schema-Test-Suite


text:
"Uncaught TypeError: undefined is not a function"

title: value : formElement.titleMap[value] || value returns a constructor function when value == 'constructor'

The fix has been cherry-picked from @ulion, thanks a lot !

authors: sheymann tchapi

repo: jsonform/jsonform


text:
Update parameter name in experiment-options.md

Updated docs on "Choose whether you want keyboard choices/responses to be case-sensitive", where the mentioned "case_sensitive" parameter must be "case_sensitive_responses" instead, as it is otherwise correctly implemented and mentioned in other places in the documentation (e.g. "jspsych-pluginAPI.md" - starting at line 112 and "jspsych-core.md" at line 368). The "case_sensitive" variable is used only internally (e.g. "jspsych.js" - lines 2273 and 2411), but not exposed to the "jsPsych.init" method when creating an experiment. Tested with the latest release (6.3.1) with the "jspsych-html-keyboard-response" plugin and I can verify that by following the old documentation it doesn't work (for obvious reasons), but following the one I propose here it does work, as initially intended by the developers. Thanks!

@AndrianV you're absolutely right. Thanks very much for flagging this error and contributing the fix! I'll merge this and re-deploy the docs.

FYI, docs have been re-deployed so this change is live now 👍

authors: AndrianV becky-gilbert

repo: jspsych/jsPsych


text:
JAVA-3279: Handle null results for reactive applications

Throw an UnsupportedOperationException in onNext if the result is null.

I'm not sure what that would look like.  It would have to be a method on the reactive streams DistinctIterable interface, but then we'd have to add it to the callback-based one... But it occurs to me that we already have an option for this, implicitly: filter out nulls using the query filter.  We can just document that as the way to do it.
Isn't the driver the one calling the onNext method provided by the application?  Where would the driver throw the NPE from?

I'm not sure what that would look like. It would have to be a method on the reactive streams DistinctIterable interface, but then we'd have to add it to the callback-based one... But it occurs to me that we already have an option for this, implicitly: filter out nulls using the query filter. We can just document that as the way to do it.

As a work around, I don't think that is a great user experience. We know that you can never provide a null to onNext.  So the user experience would be to get a NPE and then, google / file a bug to Jira then find out they need to apply a filter, then apply the filter.  Wouldn't it be easier just not to call onNext with a null?

Isn't the driver the one calling the onNext method provided by the application? Where would the driver throw the NPE from?

I read it as we must throw the NPE to the caller because we are a Subscriber (or Observer in the driver) implementation even if we wrap the users Subscriber/Observer implementation.
We'd throw it in onNext - similar to SyncTriggeredDemandSubscriber

Throwing a NullPointerException from AbstractSubscription#onNext.

authors: jstewart-mongo jyemin rozza

repo: jstewart-mongo/mongo-java-driver


text:
Platform/Gtk: set MainWindow for size

These changes are necessary for having access to MainWindow in MauiGtkApplication. Initially, this field was always null and was never set. We needed access to MainWindow to do manual operations like resize on it because the applications might want to specify custom size of the window.

Sorry for closing, @jsuarezruiz or @lytico can you review?

repo: jsuarezruiz/maui-linux


text:
It would be nice to tag earlier releases if it's easy

We unfortunately have some code which depends on 1.9.3 (needs to be fixed, obviously), and it took me a while to work out which commit this was.  I think it's f036faeefc6ebb15742dc6471642cbe61fe1984b, but I'm not completely sure.
I guess all these got lost when it moved from ?google code?, but if it was easy to tag them that would be cool.

The 1.9.3 release was on here until the 1.9.5 release.  Are you having issues because there is no longer a 1.9.3 release of pyproj on github?
Is this an open source project or proprietary one?

I'm trying to get some code to run on a new set of machines.  It depends on pyproj, and the version installed on the donor platform is 1.9.3 (at least pyproj.__version__ thinks so).  On the new set of machines I'm using conda to construct an environment, and conda only has 1.9.4 (or perhaps 1.9.5).  The code's unit tests are failing for this version so I want to temporarily go back to 1.9.3 before I fix them (basically so I can fix the other failures), which I'm doing by cloning the git repo and then trying to work out which commit 1.9.3 was.  I'd like not to have to guess that last bit: more generally I'd like to be able, if I have something which claims to depend on vx.y of anything, to be able to reliably find vx.y, even if I have tor rebuild it myself.
(The code is a UK Met Office tool to convert climate model output to netCDF: it's BSD licensed.)

The tar.gz for 1.9.3 seems to still be on pypi even if it isn't listed on the website.  Just glancing at the archive it looks like the Changelog might have been one of the last files modified on 2013-01-12 at 10:45.

That doesn't give me much confidence but, well, never mind.

authors: micahcochran tfeb

repo: jswhit/pyproj


text:
Can't get hot module replacement to work with sass-loader version newer than 0.2.0

I'm trying to update my rails-webpack-reactjs tutorial project to the latest dependencies.
https://github.com/justin808/react-webpack-rails-tutorial/tree/update-to-latest
The only dependency that does not work is sass-loader. Any version greater than 0.2.0 gives the following error:
ERROR in ../~/css-loader!../~/sass-loader?outputStyle=expanded&imagePath=/assets/images&includePaths[]=/Users/justin/j/react/react-webpack-rails-tutorial/webpack/assets/stylesheets!./assets/stylesheets/test-sass-stylesheet.scss
TypeError: Object function (from) {
			return !!~this.indexOf(from);
		} has no method 'replace'

Thus, I'm stuck at 0.2.0. Any ideas on what I can do further pinpoint what change broke my app?
Has anybody else gotten the hot-reload server to work with a version greater than 0.2.0?
Thanks.

Mhmm I'm not quite sure ... could be an issue with sass-graph. Could you remove the calls of markDependencies() in your local installation of the sass-loader and check, if the problem still exists?

That does solve the error. What do you recommend next?

@jhnns I'm debugging your latest with the latest from sass-graph (1.0.1). Any reason you're locked in at an older version of sass-graph?

@jhnns I've tracked down the problem to sass-graph using for(var a in someArray) syntax and one of my dependencies must have added a method to array. Thus, crash, just as explained here: http://stackoverflow.com/a/3010848/1009332
https://github.com/xzyfer/sass-graph/blob/master/sass-graph.js#L54
  for (var i in imports) {
    [this.dir, cwd].forEach(function (path) {
      if (path && this.loadPaths.indexOf(path) === -1) {
        this.loadPaths.push(path);
      }
    }.bind(this));
    var resolved = resolveSassPath(imports[i], _.uniq(this.loadPaths));
    if (!resolved) return false;

    // recurse into dependencies if not already enumerated
    if(!_.contains(entry.imports, resolved)) {
      entry.imports.push(resolved);
      this.addFile(fs.realpathSync(resolved), filepath);
    }
  }

@justin808,
We submitted a pull request to sass-graph to fix some of the issues with sass-loader.
Since npm release was not made at that time, we tagged it to git commit.
Now @xzyfer is maintaining sass-graph and an npm release was made recently.
We should test it with sass-loader and migrate to latest version of sass-graph.

@akiran is there a fork/branch I should pull? I'm going to check that just changing the array iteration fixes my issue.

Now sass-graph is maintained at
https://github.com/xzyfer/sass-graph

Hey all, feel free to open issues and PR in sass-graph. I'm actively maintaining it.
There's a lot a clean up work to be done, which is coming.

https://github.com/xzyfer/sass-graph/pull/7

I've had a preliminary look at xzyfer/sass-graph#7. I have some feels about it.
One way or another expect a new npm release with this issue patched within 24hrs.

I've published sass-graph@1.0.3 that should address the issue raised by @justin808 .

I posted a fix to sass-loader to reference my own fork of sass-graph.
However, sass-graph just fixed my reported issue.

Please comment in this issue when this version sass-loader is updated to this version of sass-graph.

Did latest version of sass-graph fixed your issues ?
Then we can update sass-loader and make an npm release.

I've just published a sass-graph@1.0.3 which passes the test case added by @justin808 .

@akiran Can we update sass-loader? I just submitted a PR, albeit a very simple one, to update the version dependency.

Fixed?

We don't depend on sass-graph anymore.

authors: akiran jhnns justin808 xzyfer

repo: jtangelder/sass-loader


text:
Hookup the 'Tables' link to GET /items

When you hit index.html, there is a 'Tables' link, right now it goes nowhere. It should do a GET request to /items, populate the models, render the ui.

Right now, songs fetches from the test/data/songs.json file -- this allows for rapid development and the need to not run in the beets-web app all the time.

repo: jtemplet/beets-web


text:
5 top-level use-cases for k2

Based on last weeks meeting, I'd suggest there are two sets of stake-holders: 1) ASR researchers and 2) kaldi users.  From a very peripheral view I think the ASR researchers have two use-cases:

a researcher wants to reproduce results from someone else's paper, and then explore variants. A good reason for doing this is when a published result was produced with massive compute power but success credited to a novel technique with a cool name.
a researcher wants to develop a novel component to an ASR system, and uses kaldi to provide everything else -infrastructure, peripherals for experimentation, etc

For the users, a developer wants to have ASR as part of another project and, for whatever reason, doesn't want to use cloud services:
3) the developer wants a speech interface based on LVCS recognition and the classic pipeline model - sound to transcript to meaning - which works fine for speech "command" systems but not so well for unconstrained input.  For unconstrained input the cloud services work better (big computers and far more training data) and the developer should perhaps not be using kaldi.
4) the developer has a new language/vocabulary and wants to train kaldi models for use in a speech interface. In this case kaldi is [a good / the only] option.
5) the developer wants a speech interface for a dialog system where the vocabulary is limited (like command systems) but the input is not (like LVCS). The naive approach is to use "wild cards" in speech grammars or "word spotting". The point is that the developer's envisaged system can provide information that is useful for the ASR, possibly giving better performance (although not based on WER) than commercial LVCS systems for the task.
Of these, 1 is good science but not that interesting, and 3 is misguided. From what I saw it looks like 4 is a popular usage that makes sense.  I suspect that 2 and 5 are closely related, but requires far more conversation.  That is the conversation I would like to contribute to.
Can I also point out, Daniel, that kaldi is famous because people use it.  It could be more famous if more people use it successfully.  Having 'apt-get install' on a raspberry pi would guarantee lots of downloads and all though you may not want to do it, it would be good to do.   Could you find the money to pay someone perhaps, or perhaps someone might do it for you if you can put their name on a paper or two.

the developer wants a speech interface for a dialog system where the vocabulary is limited (like command systems) but the input is not (like LVCS).

Hi Peter. Very few people want to recognize commands these days. With few commands you get a toy system anyway because it is easier to press a big red button than to shout "left" and "right" and wait for half a second to respond. People get used to assistants and want to recognize large vocabulary, sometimes crazy large vocabulary of million words on Raspberry Pi. Here we have a problem. For example, you can install Vosk with pip on RPi3 but it is far from accurate due to CPU restriction (RPi is much slower than the phone). Some work to do on quantization and multithreading here.

Hi and thanks for the feedback - I was throwing this out there to get this kind of discussion going - I am in over my head with speech research - but that is how cross disciplinary research has to work.
I will agree that the "big success" of recent years is the Large Vocabulary Continuous Speech (LVCS) recognition - my wife is currently correcting automatic transcriptions of her lectures and the Word Error Rate (WER) is very low - she is impressed.  However, just because that is impressive does not mean people don't want to do other things.  The Echo is also impressive and that is not doing LVCS, but is rather doing what I call above, "command" recognition - just a stupidly large number of commands (that get mapped into a much smaller number of "intent"s).  More explicit examples of command recognition are the in car speech interfaces, and yes, you are right; people would prefer a button (with several caveats).
What one can not do effectively with LVCS, nor with command recognition, is implement the patterns in the ELIZA chatbot.  This mechanism is how most (and indeed all successful?) conversational AI systems work and, I claim, this is something lots of people want to do.  The problem is that these patterns contain "wild cards" - that is regex ".*" type of expressions.  I have been in a talk by serious AI people (EU 2020 project) in which the language understanding was achieved they said using a "magic regular expression" - which got a guilty laugh from everyone. I want to do something very similar to these regular expressions and am using the hardware used for Wake Word Detection to do "word spotting" in continuous speech, but in a rather convoluted way.  I believe there might be an opportunity for the kaldi community here.
Agree about RPi cpu being tiny (although Pi4 now has a grown up cpu with power comparable to a modern mobile phone) but the gpu on a pi has always been reasonable.  I have seen openCV doing object detection blindingly fast.  I think there would be a great demo and a very useful "peripheral" with Kaldi recognition running on even a RPi Zero's GPU.

Thank you Peter, I didn't understand that RPi has GPU before which is accessible through opencl. I'll take a look closer on it.

Glad to help.  Keep in mind that the latest raspberry pi is the Pi4 which has a significantly bigger CPU, but the ASR problem looks, to me, like the other things (eg ML vision) people have been doing on the GPU of a rpi for a while now. I think that the thread you opened called "Use VideoCore through OpenCL on RPi3" is there to run with this?  Great!
This is exciting, but I want to claim that there is another opportunity - a bigger opportunity :-)
That opportunity is to revisit the way down-stream Natural Language Understanding (NLU) can help the ASR process by providing expectations.  This is not (historically) a new idea, but it does seem to be have lost to history and might be an interesting thing to do with kaldi.

Peter, people indeed use Kaldi on devices, like smartphones and tablets, pretty much comparable in the CPU power with the Pi3 and Pi4. You reminded me I have a pending ticket for fixing the configure script for one of the cases. Most ARM v7 and v8 have NEON extensions (128 bit SIMD) that are taken advantage of by math libraries (ACL is more vision-oriented but certainly an option, ans, IIRC, OpenBLAS has kernels for NEON, too). For the ?gemm-heavy decode part (the AM), halving the precision to float16 more than doubles ?gemm perf (Pi4's A72 does indeed support float16_t), and reduces the model size in half, without sacrificing much accuracy with good engineering and/or good luck (it's data witchcraft, not data science anyway).
I do not think decoding on the GPU is common if used at all, as the current Kaldi is CUDA-only. That is likely to change, as the frameworks we are planning to support have device-optimized versions. Tensorflow would certainly make access to the GPU easier.
As for the proposed taxonomy of uses, I can think of areas that would be hard to fit. Education, is just one example.
The dichotomy between “researchers” and “users” is also far from hard and fast, as device limitation necessarily require architecting a suitable model. Not so much really novel, on the scale of the invention of LF-MMI or CTC, but certainly a lot of model building skills and literature research is required. Engineering constrains are much tighter, and tradeoffs are more significant, so it's possible that there is not even a single "apt install", one-size-fits-anything model even for a single language. If you are reducing precision, you are likely to account for that in training too. Pruning the network—and (Sze et al., 2017) has over 1K citations!—may provide significant benefits as well. As with nearly everything, pulling something out of the box and making it "just work" is only the starting point, especially on a resource-constrained hardware.
I do not really think the world has abandoned the idea ASR and NLU marriage. Recruiting attention for this very task was mentioned at the 3rd session (I forgot who the panelist was, my memory for names is nearly non-existent).

Sure i agree it is one big bowl of spagetti, but as someone said in the
first session, presenting it to the world that way really limits ones
market segment.  To which Daniel said "its free - no need to think about
market segments" and I guess it is that comment that made me want  to
distinguish between researchers and users.  Researchers (well, people
wearing their researcher hat) are doing it because it is interesting - and
successful researchers are doing it for the publications. Users (people
wearing their user hat) want to solve a problem they have with minimal
fuss. In this second case the APIs really matter.  I am in this second camp
and bring that perspective to the process I hope. My problem-to-solve is
speech for dialog, which is only one problem and quite specific, but I
think you'll agree it is a significant "market segment" in the current
climate.
For the ASR-NLU interface, I think the world has abandoned the idea of a
literature search.  My hero, Yorick Wilks once said in a review of a book
by Jackendorf that "the greatest asset in AI research is a memory that does
not go back more than 5 years" Ouch! - and that was in the 1880s!  The four
ASR-NLU interfaces I would like to highlight are:

LVCS | NLU (the pipeline model) which is poor for dialog systems for
several reasons (timing is a big one), and what is more, we can get better
WER by making the interface bidirectional.
"command" systems in which sound is divided up into segments (usu.
based on silence) and the entire segment is converted to text.  This, many
do not realise, is how the Echo works.
MRCP https://voicexml.org/static/Review/Oct2006/features/MRCP.html
was a standard argued out in the hayday of IVR systems
"word spotting" - this is hard and unreliable, but in the context of
a dialog system is my approach of choice.  A commercial API for this is
described here https://fortebit.tech/speech-recognition/

None of these are perfect for dialog systems; I think there is an
opportunity to do better. I do not know what that better would look like,
but I think I have stuff to contribute.
Thanks for the conversation btw :-)
P
On Sat, 3 Oct 2020 at 10:55, kkm000 notifications@github.com wrote:

Peter, people indeed use Kaldi on devices, like smartphones and tablets,
pretty much comparable in the CPU power with the Pi3 and Pi4. You reminded
me I have a pending ticket for fixing the configure script for one of the
cases. Most ARM v7 and v8 have NEON extensions (128 bit SIMD) that are
taken advantage of by math libraries (ACL is more vision-oriented but
certainly an option, ans, IIRC, OpenBLAS has kernels for NEON, too). For
the ?gemm-heavy decode part (the AM), halving the precision to float16 more
than doubles ?gemm perf (Pi4's A72 does indeed support float16_t), and
reduces the model size in half, without sacrificing much accuracy with good
engineering and/or good luck (it's data witchcraft, not data science
anyway).
I do not think decoding on the GPU is common if used at all, as the
current Kaldi is CUDA-only. That is likely to change, as the frameworks we
are planning to support have device-optimized versions. Tensorflow would
certainly make access to the GPU easier.
As for the proposed taxonomy of uses, I can think of areas that would be
hard to fit. Education, is just one example.
The dichotomy between “researchers” and “users” is also far from hard and
fast, as device limitation necessarily require architecting a suitable
model. Not so much really novel, on the scale of the invention of LF-MMI or
CTC, but certainly a lot of model building skills and literature research
is required. Engineering constrains are much tighter, and tradeoffs are
more significant, so it's possible that there is not even a single "apt
install", one-size-fits-anything model even for a single language. If you
are reducing precision, you are likely to account for that in training too.
Pruning the network—and (Sze et al., 2017) has over 1K citations!—may
provide significant benefits as well. As with nearly everything, pulling
something out of the box and making it "just work" is only the starting
point, especially on a resource-constrained hardware.
I do not really think the world has abandoned the idea ASR and NLU
marriage. Recruiting attention for this very task was mentioned at the 3rd
session (I forgot who the panelist was, my memory for names is nearly
non-existent).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jtrmal/kaldi2020/issues/37#issuecomment-703078531,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALY3LWO6RQXSBZGNJMMVKEDSI3YHZANCNFSM4SAMFEZQ
.

authors: kkm000 nshmyrev petercwallis


text:
Interrupted uploads may result in "object leaks"

What happened:
When copying large files to the file system, the copy operation is interrupted manually and an object leak can occur.
What you expected to happen:
Avoiding object leaks
How to reproduce it (as minimally and precisely as possible):
Manually interrupting a copy operation
Anything else we need to know?
Environment:

JuiceFS version (use juicefs --version) or Hadoop Java SDK version: 1.0.2+2022-10-13.514ef03
Cloud provider or hardware configuration running JuiceFS: normal pc
OS (e.g cat /etc/os-release): Ubuntu 22.04.1
Kernel (e.g. uname -a): Linux homenas 5.15.0-52-generic
Object storage (cloud provider and region, or self maintained): b2
Metadata engine info (version, cloud provider managed or self maintained): sqlite3
Network connectivity (JuiceFS to metadata engine, JuiceFS to object storage):
Others:

This happens when the network is particularly bad. Because juicefs is still trying to upload to the object store after the terminal copy.
To avoid intermediate files being misidentified as leaked objects, the juicefs gc defaults to skipping files uploaded within the last hour. The JFS_GC_SKIPPEDTIME environment variable can change this value.

repo: juicedata/juicefs


text:
Promise after restart

Hi, thanks for this awesome library!
I have this code:
const anim = anime({
    targets: 'rect',
    width: 200,
    height: 400
});
anim.finished.then(() => console.log('Animation finished'));

btn.addEventListener('click', e => {
    anim.reverse();
    anim.play();
    anim.finished.then(() => console.log('Reversed animation finished'));
});

The first promise works fine, the console.log is executed just after the animation is finished. The seconds promise is executed when the second animation starts. I guess it happens because it is the same promise than the first animation, not a new promise. Is there a way to have a promise resolved after the second animation ends?
I made a pen reproducing this issue: https://codepen.io/oscarotero/full/MXVpYJ
Thanks in advance

Found the bug with the Promise implementation and found a bug in anime where it does not reset the completed property when play() happens.
Sorry this took so long to respond to, but I'll issue a PR soon (if one isn't already there).

authors: oscarotero tbranyen

repo: juliangarnier/anime


text:
Doesn't work with inline-block or floats?

Correct me if I'm wrong, but this doesn't seem to work with display: inline-block or floated elements, does it? I can't get it to work on my own site and if I add display :inline-block to your .block class in the demo everything disappears.

Hi @drawingfrommemory
This is the .block class from the Scroll Reveal demo.
.block {
  border-radius: 5px;
  margin-bottom: 150%;
}

If you add display: inline-block to the .block class in Scroll Reveal demo, everything disappears because those elements don’t actually have any content. However, an easy way to fix this is to define a width. (And for the sake of it, let’s add float: left too.)
.block {
  border-radius: 5px;
  margin-bottom: 150%;
  display: inline-block;
  width: 48px;
  float: left;
}

Everything will still work as expected.
Beyond this, I cannot help you as you haven’t actually given any details about your situation.
It’s most helpful if you demonstrate (eg. with JS Bin or Codepen) what you’re trying to achieve, or a bug you’ve recreated. (Don’t forget to mention if you’re working with WordPress or other platforms/plug-ins.)

I had my stuff below the script instead of above it. Thanks for your help!

authors: drawingfrommemory julianlloyd


text:
Is nwjs(node-webkit) supported?

@julianshapiro
Hi, thank you for nice lib ;D
I'm now developing my app with Velocity on nwjs(node-webkit).
And I have to support both two nwjs versions below.
// maintained stable
node-webkit: "0.8.6"
chromium: "30.0.1599.66"
node: "0.10.22"
v8: "3.20.15.5"

and
// maintained latest
node-webkit: "0.11.6"
chromium: "38.0.2125.104"
node: "0.11.13-pre"
v8: "3.28.71.2"

My problem is "Error occurs only on maintained stable".
Minimal sample is below.
<!DOCTYPE html>

  <meta charset="UTF-8">
  <title>nwjs - Velocity</title>

Fadeout

Animation has completed but, it's end up with some error.
Uncaught TypeError: object is not a function velocity.js:3691
Uncaught TypeError: Property 'resolver' of object #<Object> is not a function velocity.js:3681

According to my examined, implementation of 'Promise' was different.
Latest one(with node v11) has native Promise, works propery.
But stable one has nwjs original? Promise, occurs error.
Both has window.Promise, so same code executed, but it works different...
Is there a way to avoid this?
Sorry to my poor english X(

Try including a library that implements it according to the Promises A+ spec and set its Promise to Velocity.Promise.

Thank you for the comment.
Is hard to say, but my problem is a little more complicated..
This error occurs in iframe contentWindow, so I can't fix Promise from outer.
Of course, I can load Promise A+ shim(like bluebird) on outer.
But it does not seem to affect the in iframe scope.

So this is not a Velocity issue, then.

Hmm, ok.
Thanks anyway.

If anyone stumbles here through google.
The posted solution works for me, on LG Smart TV's (nodeWebkit) Velocity does not work because the Promise implementation is incorrect.
Patching Velocity.Promise with bluebird solves the issue.
var velocity = require('velocity'),
    bluebird = require('bluebird');

velocity.Promise = bluebird;

authors: Duder-onomy leader22 ydaniv

repo: julianshapiro/velocity


text:
Re: .velocity({ rotateZ: 90, scale: 0.5 }) - Feature: SVG

An issue running the above exemplar code. Firefox appears to interpret code differently to Google Chrome, and Safari just fails. Google Chrome interprets CSS transform-origin: as belonging to the rect element, such that, transform-origin: 50% 50%; rotates about the rext element's centre. Whereas, Firefox interprets CSS transform-origin: as belonging to the rect element's parent svg element. Safari does not seem to support 3DTransform, and usually requires -webkit- prefix. All running on OS X.
I hope this helps and/or is of interest.
-u

Is this something velocity can/should help with? If so, you should provide a code example.
If not then it's better you close this here and open either on SO or the bug trackers of Chromium/Firefox/Safari.

Indeed, is this something Velocity can/should help with? Possibly, it is. You can find the example at http://julian.com/research/velocity/ (see codePen at Feature SVG).

I'll need live example of the issue you mentioned. The example you mention works the same on Chrome and Firefox.
SVG has many inconsistencies across platforms, and I don't believe Velocity could/should deal with all of these.

The example does not work the same on when tested on OS X.

Referring again to http://julian.com/research/velocity/ the reader will see that the section immediately below: Basics: Properties Map states: ‘Velocity auto-prefixes properties (e.g. transform becomes webkit-transform on WebKit browsers); do not prefix properties yourself.’
Nonetheless, properties such as ‘transform-origin: 0% 0%’ declared in a style-sheet (as in the example at Feature: SVG), or so it seems, do need to be prefixed. This is true for Safari, not Chrome. In addition, for cross browser consistency (amongst those tested) it may be best to avoid using the ‘%’ unit. This will side-step the behaviour described earlier.

Something simple like 50% 50% should be supported under all circumstances :cry:

@CoDEmanX Thanks.

See #501

authors: CoDEmanX Rycochet u-gajin ydaniv


text:
Update sbt-scalajs to 0.6.25

Updates

org.scala-js:sbt-scalajs
org.scala-js:scalajs-compiler
org.scala-js:scalajs-library
org.scala-js:scalajs-test-interface

from 0.6.23 to 0.6.25.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention @scala-steward in the comments below.
Have a nice day!

https://github.com/scala-js/scala-js/issues/3445

authors: scala-steward xuwei-k

repo: julien-truffaut/Monocle


text:
complement the definition of '#'

in pattern rules, the definition of '#' applies to the whole list of nodes that are declared in the supvisors section of the supervisor configuration file.
it could be considered to apply '#'to a subset of these nodes by declaring something like:
#, subnode1, subnode2

fixed in dev-0.5 branch


text:
[BUG] Compatibility with React v19

Describe the bug
Currently, when using React v19 (currently RC), it gives an error regarding ref objects being passed to hooks, see here:

To Reproduce
Simply follow the upgrade guide and install React v19 RC, then try to build the project using usehooks-ts.
Expected behavior
build step succeeds
Additional context
No response

@CHE1RON I was trying to replicate the problem but I was unable to. Can you confirm it is not caused by https://react.dev/blog/2024/04/25/react-19-upgrade-guide#ref-cleanup-required ?

thanks for letting me know, I'll confirm that and get back to you!

Same problem here. Had to cast :(
const containerElementRef = useRef<HTMLDivElement>(null)
const isHovering = useHover(containerElementRef as RefObject<HTMLDivElement>)
//                                              ^ 😭

Same problem here. Had to cast :(
const containerElementRef = useRef<HTMLDivElement>(null)
const isHovering = useHover(containerElementRef as RefObject<HTMLDivElement>)
//                                              ^ 😭

I'd sooner annotate with @ts-expect-error so the cast can be removed once the type error is resolved.
const containerElementRef = useRef<HTMLDivElement>(null)
// @ts-expect-error React 19 type compatibility, nullable ref can be ignored.
const isHovering = useHover(containerElementRef as RefObject<HTMLDivElement>)
//                                              ^ 😭

encountered the same problem with useResizeObserver. also outlined e.g. here: https://github.com/ZeeCoder/use-resize-observer/issues/108

Same happens for useOnClickOutside.

https://github.com/juliencrn/usehooks-ts/pull/665

authors: CHE1RON aaronmw fstaffa iwan-uschka rshackleton rtrembecky thany

repo: juliencrn/usehooks-ts