Ports over LongRAGPack, Corrective RAG Pack, and Self-Discover Pack to Workflows

Description
Changes the following LlamaPacks to use the new workflow feature, and adds examples under the workflow folder showcasing the usage of these workflows in the context of implementing the LlamaPacks.

LongRAGPack
Corrective RAG
Self-Discover

New Package?
Not a new package.
Version Bump?
Did I bump the version in the pyproject.toml file of the package I am updating? (Except for the llama-index-core package)

[x] Yes
[ ] No

Type of Change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Added new unit/integration tests
[x] Added new notebook (that tests end-to-end)
[x] I stared at the code and made sure it makes sense

Suggested Checklist:

[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[ ] I have added Google Colab support for the newly added notebooks.
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] I ran make format; make lint to appease the lint gods

Awesome @jonathanhliu21 !
I'm curious if you had any overall feedback (good or bad) after trying out the workflows syntax? 👀

Awesome @jonathanhliu21 !
I'm curious if you had any overall feedback (good or bad) after trying out the workflows syntax? 👀

Overall, I think that structuring workflows is pretty intuitive. In terms of feedback, I think being able to specify which step to run when run() is called at the beginning could be helpful when there are multiple steps that can take in a StartEvent. Additionally, defining event classes was somewhat tedious in the self-discover case, as all of the variables in the event class was the same type. However, I wasn't completely sure if this is the right way to use workflows, so please let me know if there's a cleaner way to define events.

I think being able to specify which step to run when run() is called at the beginning could be helpful when there are multiple steps that can take in a StartEvent.

That's tricky because ideally the workflow shouldn't depend on the order of the processed events. In other words, if two steps wait for a StartEvent, which one goes first shouldn't matter. If it matters, the step that needs to go after shouldn't probably take a StartEvent.
For context, what you ask is definitely doable with the current asyncio implementation, but might not be the case the moment we offer a different workflows "runtime".


fix: eb solution stack name

Issue #, if available:
Description of changes:
Fix: integration test failure
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #251 (3b7097f) into master (2b5a130) will decrease coverage by 1.24%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #251      +/-   ##
==========================================
- Coverage   79.36%   78.11%   -1.25%
==========================================
  Files          80       74       -6
  Lines        3159     2838     -321
==========================================
- Hits         2507     2217     -290
+ Misses        652      621      -31

Impacted Files
Coverage Δ

aws_xray_sdk/ext/aiobotocore/__init__.py
0.00% <0.00%> (-100.00%)
:arrow_down:

aws_xray_sdk/core/__init__.py
75.00% <0.00%> (-25.00%)
:arrow_down:

aws_xray_sdk/core/sampling/local/reservoir.py
88.88% <0.00%> (-11.12%)
:arrow_down:

aws_xray_sdk/core/utils/compat.py
85.71% <0.00%> (-9.53%)
:arrow_down:

aws_xray_sdk/core/patcher.py
83.20% <0.00%> (-4.00%)
:arrow_down:

aws_xray_sdk/ext/httplib/patch.py
72.63% <0.00%> (-3.16%)
:arrow_down:

aws_xray_sdk/core/sampling/connector.py
47.94% <0.00%> (-2.71%)
:arrow_down:

aws_xray_sdk/core/emitters/udp_emitter.py
61.11% <0.00%> (-2.05%)
:arrow_down:

aws_xray_sdk/ext/util.py
89.83% <0.00%> (-1.70%)
:arrow_down:

aws_xray_sdk/core/sampling/reservoir.py
57.69% <0.00%> (-1.57%)
:arrow_down:

... and 23 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2b5a130...3b7097f. Read the comment docs.


[10.1.x] ISPN-11228 Cross-Site Repl Docs

https://issues.redhat.com/browse/ISPN-11228

@oraNod it needs to rebase!

integrated! thanks @oraNod !


[BugFix] Fix table is lost bug where create/drop db and table concurrently

Fixes SR-19348
The following scenes will lose table:
T1: begin to create t (id=1) on db d(id=2)
T2: db d(id=2) is dropped
T3: db d(id=3) is created
T4: table t(id=1) is created to db d(id=2)
T5: table t(id=5) is created on db d(id=3)
T6: there are some data load on t(id=5)
When system restarts, there will be two create table log, but only the first will success, which is table t(id=1), but all the operations is based on t(id=5).
The key point is on time T4, the check of database existence is based on db name, if we check based on id, the creation of t(id=1) will fail.
What type of PR is this:

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[x] 3.1
[x] 3.0
[x] 2.5
[ ] 2.4

Looks like it's the same issue as #28940

[FE PR Coverage Check]
:disappointed: fail : 4 / 7 (57.14%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/transaction/DatabaseTransactionMgr.java
1
4
25.00%
[1527, 1528, 1529]

:large_blue_circle:
com/starrocks/server/LocalMetastore.java
3
3
100.00%
[]

[FE PR Coverage Check]
:heart_eyes: pass : 3 / 3 (100.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/server/LocalMetastore.java
3
3
100.00%
[]

@Mergifyio backport branch-3.1

@Mergifyio backport branch-3.0

@Mergifyio backport branch-2.5


MEF discovery error logged in VS2015 RTM, VFSPT 2.0.0

I was scanning the MEF composition log %LocalAppData%\Microsoft\VisualStudio\14.0\ComponentModelCache\Microsoft.VisualStudio.Default.err for an unrelated reason, and stumbled at this message:
FSharpVSPowerTools.Folders.FSharpProjectSystemService.ctor(dte): expected exactly 1 export of EnvDTE.DTE but found 0.
   part definition FSharpVSPowerTools.Folders.FSharpProjectSystemService

I do not know if it is expected or not. I cannot also tell if any functionality is impaired, but I may easily be missing something. Just thought you should know.

@kkm000 Thanks for letting us know.
The error comes from the Folder Organization feature. Could you enable the feature in General options dialog and try out whether it's still working?

Closing since there is no real error here.


Upgrade TriggerMetadata to an interface

Proposal
I've noticed when writing scalers I need to use TriggerMetadata (map[string]string) which just give KVPs. However I end up using arrays so just end up with comma separated strings. This makes charts etc for deploying scalers harder.
Could we add a new TriggerMetadata to an interface or similar so that arrays can be actual arrays in the manifests when deploying scaler instances?
example:
TriggerMetadata:
demands: "test,test1,test2"
vs:
demands:
  - test
  - test1
  - test2

Use-Case
Easier management of actual scalers through helm etc, especially when using a lot of them.
Is this a feature you are interested in implementing yourself?
Maybe
Anything else?
I can do it, but I suspect some design thought is needed here first.

added a sample of my thinking

Yeah, the initial decision behind TriggerMetadata structure is not ideal. It would be much better if we use a different approach. For example the one you proposed.
My only concern is backwards compatibility.

Well the only way to maintain backwards is to add a new variable to the scalerconfig or we need to rewrite every scaler to match. Don't see another way.

@zroubalik I can design something that will work with 2.x if you are interested, but happy to leave it to 3.x

Stupid question - Why can't we introduce a new API version that uses this new design? Implementation wide input scheme of TriggerAuth should be decouple from how scalers use that info, no?

@zroubalik ?


Improve env DX

This PR clarifies how to configure your development environment variables, and adds a check to the server-side code to make it more obvious what went wrong if you don't properly set a Replicate API token.
Hat tip to @nutlope for mentioning this. 🎩

Love it!


Benchmarks controls API

:warning: Note on feature completeness :warning:
We are narrowing the scope of acceptable enhancements to DefectDojo in preparation for v3. Learn more here:
https://github.com/DefectDojo/django-DefectDojo/blob/master/readme-docs/CONTRIBUTING.md
Describe the solution you'd like
It would be great to have an endpoint to modify benchmark's controls status or adding notes trough the API as we do for other objects such as Products, engagements or findings.

Thanks for the feature suggestion :+1:
This is an interesting idea - it's just not something we can take up right now.
I've labeled this "consider-for-3.0" so it won't get lost when we get to the point we can consider that change.


Can you indicate the time left until the object is created?

As shown in the picture above, can you display the time left until object creation? I'm not talking about how to display it as the basic function of the roll. I wonder if I can customize it like the picture.

duplicate of #82
Currently I do not know of a reliable way to get the type of the next dragon spawning, so I cannot implement this feature

duplicate of #82
Currently I do not know of a reliable way to get the type of the next dragon spawning, so I cannot implement this feature

oh i see thanks i'll find a way myself


Use parseuri instead of document.createElement() for parsing url.

This allows running on non-browser platforms, e.g. Angular Universal.
Yes, I know it seems strange to run a fake backend on a real backend, but it helps testing.

Not compatible!  Closing for now.


Saving from file editor updates both ctime and mtime

Describe the bug
Discovered this while editing posts in my microblog. I would visit the Markdown file directly and edit the text with the built-in editor. This shifted my posts around. However, the pfrazee-microblog script sorts by ctime. I used stat to compare the ctime and mtime - both had been updated to the same time when I saved.
To Reproduce
Steps to reproduce the behavior:

Go to your profile.
Click 'Editor' to edit the index.html.
Save changes.
Open the dev console and run: beaker.hyperdrive.stat('/index.html').then(console.log).
Compare ctime and mtime.

Expected behavior
I expected ctime to be preserved when saving from the built-in editor.
Desktop (please complete the following information):

OS: Windows
Version: 1.0.0-prerelease.2

Yeah I've seen this a couple times too. Thanks for reporting, I'll check into it.

I figured. No big deal at all. Just reporting it in case. Thanks!

Fixed!


Python 3.9 Support

Recently the Python requirement was changed to 3.9 from 3.6. The package is not installing via pip. A try except block for the Python version should be added.

I also encounter the same issue, what is going on..?

import setuptools
with open("README.md", "r", encoding="utf-8") as fh:
long_description = fh.read()
setuptools.setup(
name="lm_eval",
version="0.3.0",
author="Leo Gao",
<EMAIL_ADDRESS>description="A framework for evaluating autoregressive language models",
long_description=long_description,
long_description_content_type="text/markdown",
url="https://github.com/EleutherAI/lm-evaluation-harness",
packages=setuptools.find_packages(),
classifiers=[
"Development Status :: 3 - Alpha",
"Programming Language :: Python :: 3",
"License :: OSI Approved :: MIT License",
"Operating System :: OS Independent",
],
python_requires=">=3.9",
install_requires=[
"datasets>=2.0.0",
"jsonlines",
"numexpr",
"openai>=0.6.4",
"omegaconf>=2.2",
"peft>=0.2.0",
"pybind11>=2.6.2",
"pycountry",
"pytablewriter",
"rouge-score>=0.0.4",
"sacrebleu==1.5.0",
"scikit-learn>=0.24.1",
"sqlitedict",
"torch>=1.7",
"tqdm-multiprocess",
"transformers>=4.1",
"zstandard",
"accelerate>=0.17.1",
],
extras_require={
"dev": ["black", "flake8", "pre-commit", "pytest", "pytest-cov"],
"multilingual": ["nagisa>=0.2.7", "jieba>=0.42.1"],
"sentencepiece": ["sentencepiece>=0.1.98", "protobuf>=4.22.1"],
"auto-gptq": ["auto-gptq[triton] @ git+https://github.com/PanQiWei/AutoGPTQ"],
"anthropic": ["anthropic"],
},
)

3.9 should work now

why i still encounter errors while install lm-eval on python>=3.9
ERROR: Package 'lm-eval' requires a different Python: 3.8.10 not in '>=3.9'

I have python version 3.10 , getting same error


Add an option to not display the footer/pagination

If there is just one "page", the footer should not be displayed at all. Maybe there can be "showFooterForOnePage" option or something. If my tables contain a small amount of records, I end up with a 61px high empty block.

+1,  much needed config

+1

+1. Thank you.

+1

You can provide an own pagination template like this:

...

I am using the ng-table/pager.html template and only modified the following part:
Original element:

Replacement

 params.count()">

Like that the pagination is only shown, if the data doesn't fit in one page. (With the sideeffect, that you can't change the pagesize. But why should you want to?)
If you want this behaviour on all your ngTables you can use the following code to replace the default template used for pagination like this:
app.run(function($templateCache) {
            $templateCache.put('ng-table/pager.html', '
 params.count()">
 <button ng-repeat="count in params.settings().counts" type="button" ng-class="{\'active\':params.count()==count}" ng-click="params.count(count)" class="btn btn-default">  </button>

 «   …  »

 ');
        });

Please let me know what you are thinking of this workaround.
(I am using 0.5.4)

Thank you, Alex. That is the best workaround by now, I almost forgot about
this feature...
Still, I think  no-pagination should be standard, and the functionality
should be composable...

@viniciuspires I agree with that.

@AlexSchuetz  Thanks, that's very clever.
In your opinion, do you think this approach is worth the extra configuration over something like this?

 params.count()" class="custom-pagination">

It seems as thought the end result is essentially same, because we still end up loading an unnecessary pager, but I feel as though it's a bit cleaner. Not only do we not duplicate/overload the library template HTML for a single attribute, but we also don't pollute the run block  for the sake of hiding an element.

Use this to hide pagination section.

...
...

...


windows10，errors about glutInit occur when I run the DeepMimic.py

Excuse me, I met some problems about glutInit error. When I run the DeepMimic.py, The following will occur:
Traceback (most recent call last):
File "DeepMimic.py", line 319, in
main()
File "DeepMimic.py", line 311, in main
init_draw()
File "DeepMimic.py", line 269, in init_draw
glutInit()
File "C:\Program Files\Python35\lib\site-packages\OpenGL\GLUT\special.py", line 333, in glutInit
_base_glutInit( ctypes.byref(count), holder )
File "C:\Program Files\Python35\lib\site-packages\OpenGL\platform\baseplatform.py", line 425, in call
self.name, self.name,
OpenGL.error.NullFunctionError: Attempt to call an undefined function glutInit, check for bool(glutInit) before calling.
The configuration of freeglut, glew and so on are OK. I have successfully build DeepMimicCore project and generate DeepMimicCore.py.  My environment is Windows10, Visual studio 2015. python 3.5.4
Cloud you help me?

I have solved it. When I install PyopengL, I should install the 64-bit version.


chore(docs): added pnpm installation guide

Thanks but I prefer keeping just two options. People using pnpm know how to use it


Add capability to manage "Libraries" to the provider

Is your feature request related to a problem? Please describe.
We are currently setting up Segment in Terraform and would like to be able to utilise "Libraries" but currently can only use LIVE tracking plans not PROPERTY_LIBRARY or RULE_LIBRARY which is supported by the Public API. This means we will end up with repeated groups of events or attributes which will have to be maintained within the code.
Describe the solution you'd like
Ability to manage the resource type segment_tracking_plan with types PROPERTY_LIBRARY or RULE_LIBRARY which can then be linked to the LIVE tracking plan's.
Describe alternatives you've considered

Repeating blocks of events and/or attributes in each tracking plan
Reproduce this functionality using a common/shared file within TF
Use the Public API (but ideally want everything in TF)

Additional context
The PROPERTY_LIBRARY is probably more of a priority at this stage and the RULE_LIBRARY likely something we would want in the future.
Public API reference to types noted above: https://docs.segmentapis.com/tag/Tracking-Plans#operation/createTrackingPlan

Could you explain a bit more about what is preventing you from using those Tracking Plan types? I am able to use those on my end. Are you perhaps getting an error like this which is in the connection (Sources cannot be connected to non LIVE Tracking Plans) and not the Tracking Plan resource?
│ Error: Unable to create connection between Source and Tracking Plan
│
│   with segment_source_tracking_plan_connection.test,
│   on main.tf line 269, in resource "segment_source_tracking_plan_connection" "test":
│  269: resource "segment_source_tracking_plan_connection" "test" {
│
│ 403 Forbidden
│ {
│   "errors": [
│     {
│       "type": "forbidden",
│       "message": "Authz: User does not have permissions to perform this action. Tracking plan is not type Live."
│     }
│   ]
│ }

One of Tracking Plan's type is RULE_LIBRARY.
{
  "name": "Some Library",
  "description": "Some Library Desc"
  "type": "RULE_LIBRARY",
  "syncFromLibraries": [],
  "excludedRulesFromLibraries": []
}

Questions:

Do we have capabilities to create libraries?
As the mandatory field for segment_tracking_plan are name and rules, it it possible to use RULE_LIBRARY with the current provider?

@sco-at-scg

Do we have capabilities to create libraries?

Yes you can create libraries in the provider now, are you running into issues?

As the mandatory field for segment_tracking_plan are name and rules, it it possible to use RULE_LIBRARY with the current provider?

No, we do not support importing libraries at this point, but is on our future roadmap.

Hi @deanhuynh - so just to confirm the current terraform tracking plan capabilities allow us to:

Create a Tracking Plans (LIVE) and connect this to a source
Create Tracking Plan Libraries (but not connect it to anything)

What we do not have the capability to do is connect/synchronize a library of events/attributes with a tracking plan - is this correct?
Is there another way we should be using libraries or is this just a capability gap with the API/terraform provider? It seems that if we create one it is just orphaned and not connected to anything. Just want to check I am not missing something here. Thanks

What we do not have the capability to do is connect/synchronize a library of events/attributes with a tracking plan - is this correct?
Yes this is correct

It is a missing functionality at this point. We will consider prioritizing this early next year. Thanks!

@ranand - great - thanks for confirming and will work around this for now. Are we OK to keep this feature request open for the additional capability as it is something we are looking to utilise?


Add a new Filesystem::ensureParentDirectoryExists() method?

Could reduce repetition when we call Filesystem::ensureDirectoryExists(dirname$path))

It seems like a useful addition if it can simplify repetitive code and improve readability. If there are multiple instances where Filesystem::ensureDirectoryExists(dirname($path)) is being used, encapsulating it into Filesystem::ensureParentDirectoryExists() would make the intent clearer and reduce boilerplate.
This method would also be easier for developers to understand at a glance, as the name explicitly describes the purpose. However, it might not be necessary if this scenario is rare or if there’s no significant gain in terms of clarity or maintainability.
Before implementing, I’d consider:

Usage Frequency: How often does this pattern occur across the codebase?
Impact on Readability: Does this improve readability enough to justify adding another method to the Filesystem class?
Backwards Compatibility: Could this potentially cause confusion for existing users of the API, or is it purely additive?

If the answers are favorable, it sounds like a small but worthwhile enhancement!


Allow to pass custom path to list

I published my own list with cors support for testing, until it's merged/released
I did use it like that:
12:17 $ ns build -c 'list --cors' -p list-seb
> Deploying /private/var/folders/qm/y2hrgmys1q317t0nfk53mzqm0000gp/T/now-serve-419dd99ce51585c88ee6ec1e97c55117
> Using Node.js 6.9.0 (default)
> Ready! https://ns-edvokxmqio.now.sh (copied to clipboard) [5s]
> Upload [====================] 100% 0.0s
> Sync complete (138B) [3s]
> Initializing…
> Building
> ▲ npm install
> Installing package list-seb@latest
> ▲ npm start
> Deployment complete!

The problem is that this deployment does not show my files directly, but it shows /node_modules, /content and package.json.
now-server is clever and knows that it has to serve the /content folder instead of the root. It's like to be able to mimic this behavior when using ns with the --command option, so that I can use my own fork in the same way:
ns build -c 'list --cors --path "/content"' -p list-seb

list ./content

Obviously it's only when you open an issue that you finally see the solution :)


Replace "updated" with "modified" in Electra spec

This PR does the following:

Replace usages of "updated" with "modified" to be consistent with previous specs.
For modified functions, ensure there is a note about the changes.

I updated some of these notes to be consistent with other specs.
Some of these notes could be better 😅

Delete notes for new functions as we don't normally do this.

This was for process_withdrawal_request and process_deposit_request.

Replace "NOTE" with "Note" and "Electra:EIP-7251" with "Electra:EIP7251" for consistency.
Fix some excess blank lines & missing blank line nits.

@jtraglia I tried to save you some work by fixing a rebase in the web UI but it looks like I messed something up w/ the TOC
if you can plz fix im happy to merge this in, may just want to drop my commit and handle the conflicts that way

if you can plz fix im happy to merge this in, may just want to drop my commit and handle the conflicts that way

No worries! It was a simple fix. I think we should be good now.


[Docs] update JS environment documentation for Babel

This PR needs review for accuracy of the links, and to add links for those which aren't linked. I couldn't find references to them in the babel documentation.
Fixes #274

Awesome, thanks!
You can find the correct list here: https://github.com/facebook/react-native/blob/41859e594d0dbd0be43cf7cc1561051ac4b1b853/packager/transformer.js#L21-L35

@vjeux Yes, that list is what's now referenced in the docs. Does that mean we should take out ES5 reserved words?

all the environments that we run on are ES5 so you can actually use reserved words. I would keep it there since people may not know about it

Can you please mention .babelrc to customize the transformers? see #1451


update to new docs location

Codecov Report

Merging #31 (d3d546a) into master (132e9fd) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #31   +/-   ##
=======================================
  Coverage   33.72%   33.72%
=======================================
  Files          58       58
  Lines        3039     3039
  Branches      476      476
=======================================
  Hits         1025     1025
  Misses       1850     1850
  Partials      164      164

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 132e9fd...d3d546a. Read the comment docs.


pcdet/ops/iou3d_nms/src/iou3d_cpu.cpp:12:10: fatal error: cuda.h: No such file or directory

Hi, when I install the pcdet library with the command:python setup.py develop, there is a problem appealed:
pcdet/ops/iou3d_nms/src/iou3d_cpu.cpp:12:10: fatal error: cuda.h: No such file or directory
so, could you please give me some suggestions?

Hello,
Do you have CUDA 10.2 installed? Please install from here: https://developer.nvidia.com/cuda-10.2-download-archive

Closing due to inactivity.


reflect: gccgo+gotip1.6beta1 crashes on multi-line field tags

What version of Go are you using (go version)?

$ go version
go version go1.16beta1 linux/amd64
$ gccgo --version
gccgo (Debian 8.3.0-6) 8.3.0

Does this issue reproduce with the latest release?
No.
What did you do?
package main

import "fmt"
import "reflect"

type T struct {
	Z bool `optional:"yes" name:"zz
" default:"true"`
}

func main() {
	t := reflect.TypeOf(T{})
	z := t.Field(0).Tag
	fmt.Println(z.Lookup("optional"))
	fmt.Println(z.Lookup("default"))
	fmt.Println(z.Lookup("max"))
}

What did you expect to see?
gccgo will not crash in compiling.
And should z.Lookup("default") return  "" false instead?
What did you see instead?
$ go version
go version go1.16beta1 linux/amd64
$ go run a.go
yes true
true true
 false
$ go run -compiler=gccgo a.go
# command-line-arguments
/usr/bin/ld: $WORK/b001/_pkg_.a(_go_.o): in function `main.main..init0':
/tmp/go-build/b001/_gomod_.go:5: undefined reference to `runtime.setmodinfo'
collect2: error: ld returned 1 exit status
$ go version
go version go1.15.5 linux/amd64
$ go run a.go
yes true
true true
 false
$ go run -compiler=gccgo a.go
yes true
true true
 false

Closing as a dup of #42916.  I don't think this has anything to do with multi-line field tags as such.

So the workable multi-line field tag workaround is unintended, but they will be kept as such for compatibility?

Maybe I'm misunderstanding.  Are you saying that if you add or remove a multi-line field tag it changes the behavior on tip?

I just asked to confirm whether or not the writing way of the key-value pair default:"true" in field tags is intended to be valid.

The docs for struct tags say that the value string should use Go string literal syntax, so I think that putting a bare newline in a value string does not follow the documentation.

putting a bare newline in a value string does not follow the documentation.

I understand this. So I'm not surprised that the field Z doesn't have a name key in its tag.
But I'm uncertain whether or not I should be surprised that the field Z has a default key in its tag.
What is the principle difference to make the field Z has a default key in tag but the field W has not?
package main

import "fmt"
import "reflect"

type T struct {
	Z int `optional:"111" name:"22
	       2" default:"333"`
	W int `optional:"111"
	       name:"222" default:"333"`
}

func main() {
	t := reflect.TypeOf(T{})

	z := t.Field(0).Tag
	fmt.Println(z.Lookup("optional")) // 111 true
	fmt.Println(z.Lookup("name"))     //  false
	fmt.Println(z.Lookup("default"))  // 333 true

	w := t.Field(1).Tag
	fmt.Println(w.Lookup("optional")) // 111 true
	fmt.Println(w.Lookup("name"))     //  false
	fmt.Println(w.Lookup("default"))  //  false
}

The reflect.StructTag.Get method is only documented as handling struct tags that fit the documented format.  There is no prediction or guarantee made for struct tags that do not fit the documented format.  You can look at the code to see why the two cases behave differently if you like, but there is no promise that those cases will not change in some future release.  So while I'm sure your question has an answer, I don't think it's a very interesting one.

Thanks for confirming this is a unspecified behavior.


Improve wording on homepage features

is it for hacktoberfest ?

is it for hacktoberfest ?

Just signed up, so I guess yes

If you have more time, It would be awesome if you could look bit more throug the docu and if you dont understand or have questions point that out, as this parts need fixing :+1:

Sure. By the way, do you want me to copy my latest PR from gitea here?

go-gitea/gitea#21468

uh yes not a bad idea ... just do so

@yardenshoham just port the contrib pull to here


Speeding Up Computation Time of Inverse Dynamics

Dear Pinocchio Authors,
I am using Pinocchio's RNEA inverse dynamics computation in a real-time control loop at 1000 Hz, which means 1ms control window. However, I measured the RNEA computation time itself is 0.5ms. Is there anyway to make it compute faster?
Best Regards,
Giovanni Sutanto

Normal execution times are in the order of a few microseconds.
Are you sure you are compiling your project with the correct compilation flags? -O3 should give best performances

Oh yeah, you're right. Once I use Release mode and -O3 flag, the computation time goes down to 3 microseconds. Thanks a lot @gabrielebndn !

@gsutanto Just for information, what is the model of your robot? model.nq? model.nv?

Hi @jcarpent , model.nq=7, model.nv=7

You may have a look at the paper https://hal-laas.archives-ouvertes.fr/hal-01866228 which describes Pinocchio. And you will see some benchmarks on several robots.
You can expect to go below 1us for the RNEA. Can you run:
make bench
./benchmarks/timings

It will show the bench for a standard humanoid robot, but you can also do
./benchmarks/timings my_urdf_model.urdf

for your specific robot.
Thanks in advance for your reply.

Dear @jcarpent ,
I see. Thanks for the references. For now, this is fine for our need. If we need optimize further, we will refer to (and potentially re-open) this thread.
Thanks!
Best Regards,
Giovanni


Code for calculating predictable probabilities

Hi, I was wondering if this code that calculates the probability of prediction is calculated separately for each feature in the data?

Hi, what do you mean by "calculates the probability"? We are not doing probability prediction.


Reorder Examples Numbers

Problem
Current examples numbers have gaps,
Solution
Reorder the existing ones for V1.
To Consider
Remove the numbering of examples as they don't represent a strong meaning except for an identification.

Beyond just the gaps, there's not much rhyme or reason as to what the numbers are. They've just grown organically over time. It'd be nice if the whole examples thing was completely redone, with a markdown write-up that weaves a story from getting started through all the scenarios to the most complex, with references to the relevant portions of the runnable project. Some of the examples can also be simplified significantly; less is often more.

Finished with the reorganization of the "concept" samples


Bad Request After Session Timeout

If my session times-out, then I try to log back in, I get the following 400 Error - Bad Request:

Currently we have a one hour timeout - we will re-open if needed


fix: resolve missing target features to 'null'

I ran into an error where the evaluation of whether a dependency is used was accessing non-existent target values, and failing:
       at /nix/store/41ra1jaz5pn2rddqbf7j5csj0vn5whl8-services-crate2nix/crate/Cargo-generated.nix:4950:58:

         4949|             packageId = "curve25519-dalek-derive";
         4950|             target = { target, features }: ((!("fiat" == target."curve25519_dalek_backend")) && (!("serial" == target."curve25519_dalek_backend")) && ("x86_64" == target."arch"));
             |                                                          ^
         4951|           }

curve25519-dalek uses --cfg (target) values to switch between different cryptographic backends.
This kind of fallback is already present, but only for checking whether a value is defined, not for comparisons:
https://github.com/nix-community/crate2nix/blob/e5372757075fc93c7624131069fa5d22ed88c4fd/crate2nix/src/render.rs#L216
I chose null only as a value to which no string will compare positively, theoretically this could be any non-string value.
The alternative is probably to continue failing loudly, instead of covering up the lack of a cfg value.
If that is preferred, a way of setting them globally/per-crate should be documented (I didn't find it), but it might be tedious if many dependencies use a lot of these variables.

For a moment there, I was a bit confused by the operator precedence there.
Looks good to me, thank you.

Feel free to add yourself to the CHANGELOG.md in another PR!

Thanks for the quick review (and your continued maintenance)! :)
If it were a major improvement, or a breaking change, I'd add it to the changelog, but I'm not sure a minor compatibility fix needs to be in there.


Add additions and fixes at 2.0.0pre1 release

Still rough notes so far.

[x] description refresh
[x] add 3 multibag fixes

This is document update only. Merging.


Sound max_queue_time not functioning properly

Sounds with 'max_queue_time' property settings do not behave in the expected manner (do not expire in the queue and are played after their expiration time).

Mark I. ran into this issue while trying to tune sounds for the pop bumpers on his machine.  The max_queue_time parameter was set to 5ms in the sounds config section and yet when firing 10 rapid pop bumper switches with corresponding sounds, the sounds were queued and eventually played.
The log files showed that max_queue_time was still None even though it was set properly in the config files.  The problem was due to a default value in the sound_player config validator for max_queue_time of None.  The None from the sound_player was overriding the 5ms setting in the sounds config section. The sound_player parameters in the config_validator need to be removed as all parameters (other than action) are optional overrides of the settings in the sound asset so default values will override whatever settings the user has in the sound.

Decided to target this fix only to 0.31 and not back port to 0.30 since the release of 0.31 is only about two weeks away.

Fixed in 0.31.


set default for seconds per turn

how to:
Open Hasura console on localhost:9695 (to track migrations)
cd graphql-server
hasura console --admin-secret=myadminsecretkey

update default here:

check this out @wtachau

 [M-L] Improve Host/Join Experience


og:image in  tag are not resolved

Describe the bug
I have 11ty static website using eleventy-vite-plugin. When I build production site, all image paths are properly resolved to hashcode name, only <meta> tag with property="og:image" do not process content.
Example:

According to #7643, this should be done and supported, but it does not process on my project. This is the code that inserts og:image:
    {% if image %}
        <meta property="og:image" content="{{ image }}">
    {% elsif logo %}
        <meta property="og:image" content="{{ logo }}">
    {% endif %}

Link to code:  https://github.com/pbjadranje/web/blob/da6e818470c9dcd8f387a015ad1c0bf142b52d8e/src/_includes/base.html#L20
Project GH: https://github.com/pbjadranje/web
Reproduction
https://github.com/pbjadranje/web
Steps to reproduce
npm install
npm run build
<check dist/index.html>
System Info
System:
    OS: macOS 13.5.2
    CPU: (10) arm64 Apple M1 Pro
    Memory: 1.77 GB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.8.0 - /opt/homebrew/bin/node
    Yarn: 1.22.17 - ~/.yarn/bin/yarn
    npm: 10.2.0 - ~/devel/pbj/web/node_modules/.bin/npm
    pnpm: 8.9.0 - /usr/local/bin/pnpm
  Browsers:
    Brave Browser: <IP_ADDRESS>
    Safari: 16.6
  npmPackages:
    vite: ^4.4.11 => 4.4.11

Used Package Manager
npm
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

Duplicate of #7362


Use prqlc in Dev Container?

What's up?
Using a recent Dev Container, I was surprised that I could not use prqlc from the CLI.
vscode ➜ /workspaces/prql (main) $ echo "" | prqlc compiler
bash: prqlc: command not found

I imagine something needs to be added to the postCreateCommand hook, but don't know what.

Yes - that's a good solution. TL;DR...  Thanks

... and just so I don't have to re-create the command again, here's a here-doc as an input to prqlc...
cat <<'EOF' |  cargo run -p prqlc -- compile
from inv=invoices
join item=invoice_items (==invoice_id)

group { inv.billing_city } (

  group { item.name } (
    aggregate {
      ct1 = count inv.name,
    }
  )
)
EOF


Lack of Comments

Currently there is no documentation for an official way to comment out code despite you adding comments such as (blank line ending While block) in the minimalist FizzBuzz example. I don't know if you intended those to be actual comments or just info for the reader in that specific example but I think comments are something that the language probably needs. If you don't want to use parenthesis for official comments may I suggest starting comments with the phrase By the way or something else that's all words to continue the non-reliance on special characters.

Oh I didn't see #32 before opening this my bad


traefik-dashboard pod not created after microk8s enable traefik

Summary
microk8s enable traefik dosnt create the traefik-web-ui pod.
Indicated by:
microk8s kubectl port-forward -n traefik traefik-web-ui 18080:8080 returns Error from server (NotFound): pods "traefik-web-ui" not found
What Should Happen Instead?

i would expect the pod to be at least created.
Reproduction Steps

install ubuntu on a physical machine
microk8s enable metallb:<IP_ADDRESS>/24
microk8s enable traefik
microk8s kubectl port-forward -n traefik traefik-web-ui 18080:8080

Introspection Report

inspection-report-20240416_165158.tar.gz
Can you suggest a fix?
Are you interested in contributing with a fix?
yes

I also reproduced this behaviour on Ubuntu 22.04 LTS

same


 You’ve lost track of the groutine you just started.
Can you please show a real world example where the code is so short that saving two lines makes a significant impact on the readability of the function.

just saves 2 lines.

But it doesn't, that's the thing, to write defer go func() ... would spawn a goroutine with no relationship to the function that just exited. You wouldn't write this code if you cared about the result of the goroutine that was spun off. Instead you'd be doing the waitgroup dance, or passing around some result channel.
My point is, this saving of two lines in a 3 line function is immaterial when you're talking about saving two lines in a properly written function that tracks the lifetime of the goroutine that was fired off on the way out.

func foo() { go bar() }

...

defer foo()

As I said, saves 1-2 lines with no cluttering of the language spec.

Note that defer func() { go f() }() on a single line is Valid Go and left alone by gofmt.

@pjebs What do you expect with below? You want to spawn goroutine even if doAnotherThing return error?
func doSomething() error {
	defer go doLater()
	return doAnotherThing()
}

I guess, in most of cases, it should check err and return if err != nil. (before spawning goroutine). And if there are several conditions and next condition doesn't related on whether spawn the goroutine, defer go doLater() possibly become go doLater().

@mattn Yes. It needs to be run irrespective of outcome.
In reality, my proposal is not really about by use case. It's more about making the language spec feel more internally consistent - particularly if there is zero costs or ambiguity associated with it.

@pjebs Then, you can do it like below in caller of doSomething().
doSomething()
go doLater()

I'm thinking current spec have consistent.

I don't understand your suggestion?
There seems to be even more lines of code + I want to be able to apply defer at the very top, irrespective of the happy path or alternative paths. One of the benefits of defer is we don't need to think about when it's going to run. We just have the intention that we WANT IT TO RUN at some point.

We just have the intention that we WANT IT TO RUN at some point.

Are you ok with the goroutine never being scheduled?
Are you ok with the goroutine never completing and your program exhausting the heap?
I don’t think you want either of those things, so you want to have some control over the lifetime of that goroutine, and that will negate any LOC reduction this proposal asserts. .

On 24 Apr 2018, at 15:58, pjebs<EMAIL_ADDRESS>wrote:
We just have the intention that we WANT IT TO RUN at some point.

At least for the contrived example you mention, below code seems like fulfills your needs
func Foo() {
   go doLater()
   return doSomething()
}

Because:

doLater is run "irrespective of the happy path or alternative paths"
It fulfills "we don't need to think about when it's going to run"
It save s a few lines of code than defer func() { go f() }

And,

It doesn't require a language spec alteration

So we should all be happy :)

@davecheney
Are you ok with the goroutine never being scheduled?

The defer means it will get scheduled.
Are you ok with the goroutine never completing and your program exhausting the heap?

How is that different from current?
If we don't write defer and just use go f(), all those problems are still existent.
If you were to manually write go f() in every path before the function returns, your concerns are still valid, but it will be operating within the current spec.

Sorry, when I wrote scheduled in the first paragraph I meant something closer to “being given a chance to execute”
WRT go f() is not guaranteed to run irrespective of defer, you are correct. There is no difference. Which is my point, both of those patterns of fire and forgetting a goroutine are potential resource leaks.
I restate my assertion that optimising the syntax for this operation with a view to reducing the size of the code on the page is a non goal when the code written correctly to track the lifetime of a goroutine would dwarf any saving in lines from optimising for the trivial case.

On 24 Apr 2018, at 16:43, pjebs<EMAIL_ADDRESS>wrote:
@davecheney
Are you ok with the goroutine never being scheduled?
The defer means it will get scheduled.
Are you ok with the goroutine never completing and your program exhausting the heap?
How is that different from current?
If we don't write defer and just use go f(), all those problems are still existent.
If you were to manually write go f() in every path before the function returns, your concerns are still valid, but it will be operating within the current spec.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

At the end of a http request, I like to save some statistical data to a database that has no bearing on the response.

If you don't want to run out of memory and crash when the stats database is slow, you still need some kind of synchronization (e.g., a semaphore). That seems like it would disrupt the one-liner:
func logStats(f func()) {
	acquireStatsSem()  // or: if !acquireStatsSem() { return }
	go func() {
		defer releaseStatsSem()
		f()
	}()
}

func … {
	defer logStats(func() {
		…
	})

	…
}


Some strange behaviours of  for solid js

I found some strange behaviours of <Menu /> for solid js:

Menu does not appear in the expected place. Somehow it appear in the top
left corner of the page when menu is closed by clicking outside of menu
item. If I close the menu by clicking any menu item, the menu will appear
in the right place.
The button that triggers the menu to open, somehow accumulates it's classes.
Some data attributes in the rendered button is sometimes disappear and
reappear. It's related to the positioning of the menu. Because, when those
data attributes are gone, the menu will appear in the top corner.

Here's the reproducible code https://github.com/arch-mage/park-ui-menu-bug

This should be fixed with 2.0. We ran into an issue with asChild.

I tried this with Ark UI Solid 2.0.1 and it works.


error: missing field package

I tried to use cargo-call-stack on a project that uses a workspace, and the only output I got was
error: missing field `package`

The only semi-related information I found on internet was this closed issue on cargo-binutils. It feels that the issue could be fixed by replacing cargo-project by cargo-metadata.

I can confirm it's not working if used within a workspace

I can also confirm it's not working on a workspace when you run the cargo command from the workspace root.
Additionally if you change the working directory to the workspace member that contains the binary and then try the build works but opening the .elf file fails as the binary appears under <workspace root>/target/... instead of <current directory>/target/....
The error you get when you try from the package directory is:
error: couldn't open ELF file `\\?\<absolute-path-to-workspace-member-directory>\target\thumbv7em-none-eabihf\release\<target-elf>`: The system cannot find the path specified. (os error 3)

I created an example workspace for testing, attached below, and here's the output from various commands:
$ cat rust-toolchain.toml
[toolchain]
channel = "nightly-2022-11-16"
components = [ "rust-src", "rustfmt", "llvm-tools-preview" ]
targets = [ "thumbv7em-none-eabihf", "thumbv7m-none-eabi" ]
$ cargo --version
cargo 1.67.0-nightly (a3dfea71c 2022-11-11)
$ cargo call-stack -V
cargo-call-stack 0.1.13
$ cargo call-stack --bin recursive --target=thumbv7em-none-eabihf -v
error: Parse: missing field `package`
$ cargo call-stack --bin recursive_tail --target=thumbv7em-none-eabihf -v
error: Parse: missing field `package`
$ tree
.
├── Cargo.lock
├── Cargo.toml
├── crates
│   ├── example-bin
│   │   ├── Cargo.toml
│   │   └── src
│   │       ├── bin
│   │       │   ├── recursive
│   │       │   │   └── recursive.rs
│   │       │   └── tail_recursive
│   │       │       └── tail_recursive.rs
│   │       ├── lib.rs
│   │       └── panic
│   │           └── panic_handler.rs
│   └── example-lib
│       ├── Cargo.toml
│       └── src
│           └── lib.rs
└── rust-toolchain.toml

9 directories, 10 files
$ cd crates/example-bin/
$ cargo call-stack --bin recursive --target=thumbv7em-none-eabihf -v
"cargo" "rustc" "--target" "thumbv7em-none-eabihf" "--bin" "recursive" "--release" "-Zbuild-std=core,alloc,compiler_builtins" "--color=always" "--" "--emit=llvm-ir,obj" "-C" "embed-bitcode=yes" "-C" "lto=fat"
warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
package:   D:\Users\Hydra\Documents\dev\playground\rust\example-workspace\crates\example-bin\Cargo.toml
workspace: D:\Users\Hydra\Documents\dev\playground\rust\example-workspace\Cargo.toml
warning: D:\Users\Hydra\Documents\dev\playground\rust\example-workspace\crates\example-bin\Cargo.toml: unused manifest key: bin.0.check
warning: D:\Users\Hydra\Documents\dev\playground\rust\example-workspace\crates\example-bin\Cargo.toml: unused manifest key: bin.1.check
   Compiling core v0.0.0 (D:\Users\Hydra\.rustup\toolchains\nightly-2022-11-16-x86_64-pc-windows-gnu\lib\rustlib\src\rust\library\core)
   Compiling compiler_builtins v0.1.82
   Compiling rustc-std-workspace-core v1.99.0 (D:\Users\Hydra\.rustup\toolchains\nightly-2022-11-16-x86_64-pc-windows-gnu\lib\rustlib\src\rust\library\rustc-std-workspace-core)
   Compiling alloc v0.0.0 (D:\Users\Hydra\.rustup\toolchains\nightly-2022-11-16-x86_64-pc-windows-gnu\lib\rustlib\src\rust\library\alloc)
   Compiling example-lib v0.1.0 (D:\Users\Hydra\Documents\dev\playground\rust\example-workspace\crates\example-lib)
   Compiling example-bin v0.1.0 (D:\Users\Hydra\Documents\dev\playground\rust\example-workspace\crates\example-bin)
    Finished release [optimized + debuginfo] target(s) in 19.37s
error: couldn't open ELF file `\\?\D:\Users\Hydra\Documents\dev\playground\rust\example-workspace\crates\example-bin\target\thumbv7em-none-eabihf\release\recursive`: The system cannot find the path specified. (os error 3)

example-workspace-20221121-1822.zip

After looking at the source to cargo-project (also written by @japaric, the author of this tool), it appears there's a workaround.

cd into the crate containing the bin you want to build.
manually specify the normal target directory by adding CARGO_TARGET_DIR="<relative-target-path>" to the cargo call-stack ... command.

For example, while taking my example project above:
$ cd crates/example-bin
$ CARGO_TARGET_DIR="../../target" cargo call-stack --bin tail_recursive --target=thumbv7em-none-eabihf -v
"cargo" "rustc" "--target" "thumbv7em-none-eabihf" "--bin" "tail_recursive" "--release" "-Zbuild-std=core,alloc,compiler_builtins" "--color=always" "--" "--emit=llvm-ir,obj" "-C" "embed-bitcode=yes" "-C" "lto=fat"
warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
package:   D:\Users\Hydra\Documents\dev\playground\rust\example-workspace\crates\example-bin\Cargo.toml
workspace: D:\Users\Hydra\Documents\dev\playground\rust\example-workspace\Cargo.toml
warning: D:\Users\Hydra\Documents\dev\playground\rust\example-workspace\crates\example-bin\Cargo.toml: unused manifest key: bin.0.check
warning: D:\Users\Hydra\Documents\dev\playground\rust\example-workspace\crates\example-bin\Cargo.toml: unused manifest key: bin.1.check
   Compiling core v0.0.0 (D:\Users\Hydra\.rustup\toolchains\nightly-2022-11-16-x86_64-pc-windows-gnu\lib\rustlib\src\rust\library\core)
   Compiling compiler_builtins v0.1.82
   Compiling rustc-std-workspace-core v1.99.0 (D:\Users\Hydra\.rustup\toolchains\nightly-2022-11-16-x86_64-pc-windows-gnu\lib\rustlib\src\rust\library\rustc-std-workspace-core)
   Compiling alloc v0.0.0 (D:\Users\Hydra\.rustup\toolchains\nightly-2022-11-16-x86_64-pc-windows-gnu\lib\rustlib\src\rust\library\alloc)
   Compiling example-lib v0.1.0 (D:\Users\Hydra\Documents\dev\playground\rust\example-workspace\crates\example-lib)
   Compiling example-bin v0.1.0 (D:\Users\Hydra\Documents\dev\playground\rust\example-workspace\crates\example-bin)
    Finished release [optimized + debuginfo] target(s) in 19.40s
digraph {
    node [fontname=monospace shape=box]
    0 [label="_start\nmax >= 16\nlocal = 8"]
    1 [label="example_lib::recurse\nmax >= 8\nlocal = 8"]
    1 -> 1
    0 -> 1

    subgraph cluster_0 {
        style=dashed
        fontname=monospace
        label="SCC0"
        1
    }
}

The issue stems from the fact that the target directory is not retrieved from cargo correctly in cargo-project.  Helpfully though cargo-project does read the value from CARGO_TARGET_DIR first, which can be seen here:
https://github.com/japaric/cargo-project/blob/v0.3.0/src/lib.rs#L92
I did have a quick look at what the cargo-bin-utils guys did to support cargo-metadata but as they noted, it's quite an invasive change, this is what they did:
https://github.com/rust-embedded/cargo-binutils/pull/50/files
Suggest the same is eventually done in this tool and that cargo-project is deprecated in favor of a more robust solution (cargo-metadeta) which requires less on-going maintenance as it uses machine-generated output instead of making assumptions about how cargo works.


Help replicating the scifar experiment?

Would it be possible to clarify which hyperparameter settings (including choice of hardware) led to the reported 90.25% Multi-head GRU accuracy on sequential CIFAR reported in Table 2? (https://arxiv.org/pdf/2309.12252)
Looking at the configs currently in the github (config0.yaml and config_rnn2.yaml), they both seem to correspond to different sections of the discussion in Appendix B.4. https://github.com/machine-discovery/deer/tree/main/experiments/05_rnn_scifar/configs
In particular, config0.yaml seems to match up in terms of optimization hyperparmeters, while config_rnn2.yaml seems to match up in terms of model architecture hyperparamters (except for the the fact that the architecture used is RNNNet2, which is stated to "follow the architecture from https://github.com/thjashin/multires-conv/blob/main/classification.py"
This is confusing because MultiresNet (Shi et al., 2023) 93.15% is listed as a different entry in Table 2.
When I try to run the code, using config0.yaml, I get 79% test set accuracy instead of the reported 90% test accuracy, and the log records 182,154 parameters while Appendix B.4 of the paper reports 1,347,082 parameters.
As a final minor note, it appears that the text in Section 4.4 is not agreement with Table 2. The text says "Table 2 shows that multi-head GRU can achieve 89.35% test accuracy," whereas the table reports 90.25% accuracy.
It would be a great help for replicability if the expected test accuracy and the hyperparameters (including choice of hardware) needed to attain this accuracy could be clarified.

If I remember it correctly, we ran the experiment for quite long time, so by looking at config0.yaml vs config_rnn2.yaml, it's using the latter one with 500k steps. About my comment "following the architecture from ...", I think it's because I just copied some part of the architecture (like the arrangement of embedding + linear + time mixing in a block), but a quick glance between those 2 architectures, they are not the same. MultiResnet is using convolution while RNNNet2 is using nonlinear RNN.

Thank you for clarifying. What hardware did you use?


Multicurrency causes opp import failure when batch is larger than 100 records

When multiple currencies are enabled for an organization, opportunity imports will crash if batch is larger than 100 records due to the SOQL query limit being exceeded during OCR creation.  It appears that OPP_OpportunityNaming.getOppNamesAfterInsert() is causing a SELECT CurrencyIsoCode on every opp record and so the import crashes at 100 records.
A workaround is to disable OPP_OpportunityContactRole_TDTM and create OCRs via the data import itself.
Note: A custom opp name format is defined in this instance.

Thanks for the report @davidchengIC - team is working on optimization around rollups/multicurrency now so timing for this is good. FYI @njjc

**lurch: add

Tracking W-018654

we should see about getting CurrencyIsoCode selected in the initial soql so that we don't keep requerying for it.

Here is where the issue is, here is the caller. I think we'll have to change the design from passing the ID to passing the whole SObject and assuming the SObject has the CurrencyIsoCode field populated.

Included in beta release 3.107 (Beta 7)

Included in production release rel/3.107


Stacktrace when loading plugin installed in 'develop' mode

In GitLab by @tlater on Oct 11, 2017, 12:44
Loading a plugin installed through pip install -e or setup.py develop results in particularly cryptic error messages: pip_e.txt.
Since users writing plugins will presumably often use this method of installation for convenience, this error should either be fixed or at least result in a slightly more understandable error message.

In GitLab by @tlater on Oct 12, 2017, 14:56
mentioned in merge request !107

In GitLab by @tristanvb on Oct 13, 2017, 08:37
Fixed by merge of !107

In GitLab by @tristanvb on Oct 13, 2017, 08:37
closed


feat(component):  fixes #5

Related Ticket(s)
{{Provide url(s) to the related ticket(s) that this pull request addresses}}
Description
{{Add a human-readable description / detail summary of what the PR is changing and any details around how and why}}
{{If applicable, include a screenshot indicating an example or examples of what the PR is changing in the application}}
Changelog
New

{{new thing}}

Changed

{{changed thing}}

Removed

{{removed thing}}

Going to close this, but I ended up updated the stalebot configuration as I think 15 days is too aggressive.


failed to install the package

hi when I tried to install the package in the coda, here is the issue I face: the Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source. Could you help to sort it out?

Hey @yangyijane, thanks for reaching out!
Could you give me some more information? Did you use an environment file, or how did you create the environment?
Preferably you provide a minimal working example where the installation fails. In that case I can help you better.
Best, Tim


feat(events): add participants name on event item

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#91
#90  👈
#89
#88
#86
#85
#84
#83
#82
#81
#80
#79
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @xdjeremy and the rest of your teammates on  Graphite


perf: ensure we do not provide callback to native if no callback provided from app

Summary
As discussed with @KrzysztofMoch a possible optimization is to avoid giving callback functions (starting with 'on*') to native if application didn't provide it
Motivation
performances improvements.
Additionnally, we must keep the useCallback as paramters of the function are differents between native & applicative, for exemple:
    const _onTimedMetadata = useCallback(
      (e: NativeSyntheticEvent<OnTimedMetadataData>) => {
        onTimedMetadata?.(e.nativeEvent);
      },
      [onTimedMetadata],
    );

send e.nativeEvent to application
Changes
Just add ternary to check to avoid giving the callback to native
Test plan
Basic tests done on android/ios with the sample

I also think we should do "early returns" - because we don't need to load tracks data if user don't revive it
I will send you patch for iOS later

Good catch agin, thank you !
I integrate some of the swift fix you proposed to me also ! (but not all)


Key callback doesn't work

I dont know why, but when I compile glfw3 from sources
cd glfw/
cmake .
make && sudo make install

... and use simple example:
CC = g++
CFLAGS = -std=c++11 -Wall -g -pedantic
LFLAGS = -lm -lGL -lGLU -lX11 -lXxf86vm -lXrandr -lpthread -lXi -ldl -lXinerama -lXcursor
GLFW = -L/usr/local/lib -lglfw3
...

#include <iostream>
#include <GLFW/glfw3.h>

using namespace std;

void key_callback(GLFWwindow* window, int key, int scancode, int action, int mods) {
  cout << "Key: " << char(key) << endl;
}

int main(void) {
  GLFWwindow* window;

  if (!glfwInit()) {
    return -1;
  }

  window = glfwCreateWindow(640, 480, "Hello World", NULL, NULL);
  if (!window) {
    glfwTerminate();
    return -1;
  }

  glfwMakeContextCurrent(window);
  // !!!
  glfwSetKeyCallback(window, key_callback);

  while (!glfwWindowShouldClose(window)) {
    glfwSwapBuffers(window);
    glfwPollEvents();
  }
  glfwTerminate();
  return 0;
}

When i'm running an app, and press key, nothing is happened.
p.s.: sorry for my english
Thanks!

Try the events test in tests folder. Does it work?

@shurcooL,
After compiling events.c:
./events
000000de to 1 at 57.621: Character 0x00000064 (d) with modifiers (with no mods) input
000000df to 1 at 57.621: Character 0x00000064 (d) input

I am confused,  because my test app still not working and i dont know why

@boddicheg Is that an official release or a repo snapshot? A bug similar to what you describe was just fixed in master.

@elmindreda, repo snapshot
git clone git@github.com:glfw/glfw.git
cd glfw/
cmake .
make && sudo make install

Thanks, i am trying to reproduce bug in 3.1.1 release

Works on 3.1.1. Thanks a lot

@boddicheg What is the XMODIFIERS environment variable set to?

@elmindreda,
$ echo $XMODIFIERS
@im=none

@boddicheg Thank you. The snapshot you used at first, which commit is it on?

@elmindreda, last commit on Jul 21, 2015, [460e5d7] (https://github.com/glfw/glfw/commit/460e5d792dac0d2de16ba0a38a1181a1e4340f2c)

@boddicheg Do you have time to test an up-to-date repo snapshot? The bug should be fixed as of 527952102a13d0caad479a75a4385950f10d79d7.

@elmindreda, pull last changes and test. Works perfect:)

@boddicheg Thank you for testing.