We need sed -n ?

Some like sed('-n','/FOO/,/BAR/p',cat("cats.txt"));
says  sed: option not recognized: n

This seems like a reasonable addition. @hemanth if you're able to submit a PR, I'd be happy to take a look.

I don't even recall why I had created this issue!
Anyway,

By default, each line of input is echoed to the standard output after all of the commands have been applied to it.  The -n option suppresses this behavior.

Let see what best I can do here.

I'm going to go ahead and close this, since it doesn't seem that useful. It looks like this would only mean that a sed() call returns the empty string. A suitable workaround would be to just ignore the return value instead.
If other sed modes get supported, like the /p mode, then we can revisit this. Feel free to open this if there's some use-case I'm overlooking.


ValueError: Cannot assign to variable last1/kernel:0 due to variable shape

Can somebody please tell me what I am doing wrong here?
from PIL import Image, ImageDraw
from imageai.Detection import ObjectDetection
import os

execution_path = os.getcwd()

detector = ObjectDetection()
detector.setModelTypeAsYOLOv3()
detector.setModelPath( os.path.join(execution_path , "./yolo.h5"))
detector.loadModel()
detections = detector.detectObjectsFromImage(input_image=os.path.join(execution_path , "./runner.jpg"),
                                             output_image_path=os.path.join(execution_path , "./runner_detected.jpg"),
                                             minimum_percentage_probability=30)

for eachObject in detections:

    print(eachObject["name"] , " : ", eachObject["percentage_probability"], " : ", eachObject["box_points"] )
    print("--------------------------------")

I receive this error:
ValueError: Cannot assign to variable last1/kernel:0 due to variable shape (1, 1, 1024, 255) and value shape (18, 1024, 1, 1) are incompatible

detection_config.json looks like this:
{
    "labels" : [
        "runner"
    ],
    "anchors" : [
        [
            95,
            230,
            105,
            126,
            162,
            270
        ],
        [
            0,
            0,
            0,
            0,
            49,
            69
        ],
        [
            0,
            0,
            0,
            0,
            0,
            0
        ]
    ]
}

I have installed dependencies to match the versions shown in the installation requirements.

I am getting the same issue too, please help!

@OlafenwaMoses Help!!

I'm getting the same error, anyone figure it out?

Me too! Has anyone figured it out yet?

Not yet! I imagine this has to be compatibility issue with other modules b/c it worked for me in the past.


New Architecture - Remove the extra steps required to copy .so files

Corresponding doc update given this change:
https://github.com/facebook/react-native/pull/34843/files

ping @cipolleschi for review and merge 👍


Impossible to update addon to version 0.1.14

The problem
Rejestrator: homeassistant.components.hassio
Źródło: components/hassio/websocket_api.py:135
integracja: Home Assistant Supervisor (dokumentacja, Problemy)
Pierwsze zdarzenie: 16:15:13 (1 zdarzenia)
Ostatnio zalogowany: 16:15:13

Failed to to call /store/addons/6e457389_cloudflared/update - Can't install ghcr.io/sviete/cloudflared/amd64:0.1.14: 500 Server Error for http+docker://localhost/v1.47/images/create?tag=0.1.14&fromImage=ghcr.io%2Fsviete%2Fcloudflared%2Famd64&platform=linux%2Famd64: Internal Server Error ("manifest unknown")

What version of Cloudflared has the issue?
amd64:0.1.13
What was the last working version of Cloudflared?
amd64:0.1.14
What type of installation are you running?
Home Assistant OS
Add-on YAML Configuration
NA

Anything in the logs that might be useful for us?
2024-10-22 16:15:13.904 ERROR (MainThread) [supervisor.docker.interface] Can't install ghcr.io/sviete/cloudflared/amd64:0.1.14: 500 Server Error for http+docker://localhost/v1.47/images/create?tag=0.1.14&fromImage=ghcr.io%2Fsviete%2Fcloudflared%2Famd64&platform=linux%2Famd64: Internal Server Error ("manifest unknown")

### Steps to reproduce the issue

Update addon to current version

### Additional information

Version 0.1.13 now doesn't work, but for other reasons.

edit
https://github.com/sviete/ais-ha-addon-cloudflared/pkgs/container/cloudflared%2Famd64
image tagged 0.1.14 just do not exist for any supported platform
https://github.com/orgs/sviete/packages?repo_name=ais-ha-addon-cloudflared

same problem here

Fixed with v0.1.15
https://github.com/sviete/ais-ha-addon-cloudflared/releases/tag/v0.1.15


[pigeon] Add end-to-end integration_test tests for all generators

Currently the Pigeon testing is using unit tests on the Dart and native sides; this is useful, but leaves open the potential for unit tests on each side to pass, but for the protocol being unit tested to mis-align slightly such that the end-to-end call doesn't actually work. https://github.com/flutter/flutter/issues/111083 is an example of a case that should have been trivially caught by basic integration tests, but has to be more explicitly tested correctly with unit tests based on details of the serialization format on each end. (We also don't have that unit test on the Swift side, which is a problem, but a simple test would be even better.)
I would suggest that we rework the platform_tests directory so that instead of having a combination (depending on language) of bespoke tests and per-language dummy plugins, we just have one single test_plugin plugin that supports every platform/language (or I guess, two plugins: one for ObjC and Java, and one for everything else, since they can't really co-exist with their alternate languages in the same plugin). That plugin would have:

Unit tests for each language, using exactly the same structure that native unit tests in flutter/plugins use. That's already how Windows works, and the others could be converted.
integration_test tests that would drive full end-to-end calls for a variety of core use cases.

(Eventually I would like to revisit using the plugin repo tooling to drive all of this; I temporarily abandoned that when setting up Windows because it would involve more tool changes than I had time to make, but it would make things more sustainable long term that maintaining lots of run_tests.{dart,sh} logic. Using this structure would have the added benefit of setting ourselves up for that being easier to add later.)
/cc @gaaclarke @tarrinneal
Checklist:

[x] Add Swift macOS integration tests.
[x] Add Swift iOS integration tests.

These are mostly redundant with macOS, but there are features like background platform channels that we don't currently support on desktop. And the added cost of having both should be low. (I don't want to do iOS-only, because for local iteration a macOS integration test is way faster.)

[x] Add Windows integration tests.
[x] Add Java Android integration tests, local-only (not in CI)
[x] Add Kotlin Android integration tests, local-only (not in CI)
[x] Update https://github.com/flutter/packages/pull/2816 to include adding Obj-C integration tests
[x] Migrate the handful of (Obj-C-only) tests that are currently in the e2e_tests directory to the new structure, and eliminate e2e_tests.
[ ] Enable Java and Kotlin integration tests in CI

This is currently hard, which is why it's a separate step:

We could use FTL, like we do in flutter/plugins, but that's a lot of complexity/setup to bring into the tooling (or we need to adapt the repo tooling to work with Pigeon's unusual structure), and:
I'm hopeful that we can use the new (WIP?) LUCI Android emulator support instead, but that will require us to get that part of the testing moved over to LUCI, and emulator support wired in.

This is blocked on emulator support in CI, but we're not close to having that.


Take with compile-time count

Hi there. Recently I use nom to parse some bytes as blocks of 32 u8. Then I was thinking about const_take where we provide count as generic type (iirc it's 1.51 rust release). So, we are able to parse &[u8; N]. My implementation does it unsafely however we have guaranties that it'll not unsound: take that I call already checks for appropriate count.
Pros:

allow user get type precisely
compiler optimization is possible I think (don't really know about it)
safe at 100%

Cons:

update MSRV to 1.51 at least
feature may look useless

Prototype of mine:
fn const_take<const N: usize>(i: &[u8]) -> IResult<&[u8], [u8; N]> {
    // Safety: fine because `take` already check that we took N bytes
    map(take(N), |bytes: &[u8]| unsafe {
        bytes.try_into().unwrap_unchecked()
    })(i)
}

Sure, sounds like it might be useful, but your implementation would actually be unsound for the general (generic) case - InputTake is safe to implement, so there's nothing stopping an implementation from returning a slice of the wrong size (take() doesn't do any checks, contrary to what the Safety comment claims).

The take I was talking about is nom::bytes::complete, not from InputTake. My fault I didn't specify that.
I don't propose to implement it generally as  nom::character module doesn't have any take-like combinator like bytes. It should be only for bytes I think.
I agree that InputTake::take produces panic if count is greater than length, but bytes::take will inform whether provided data was not enough to parse therefore we can't get more than we have. So it should be sound.

bytes::complete::take is just a wrapper around InputTake::take_split with not additional checks.

Oh, well, I've got your point. It seems fine for me but we need to take in account that overflowing by InputTake::take will panic. So, we have either panic due to incorrect implementation of InputTake or exactly N bytes that we take, hence all is correct and sound.


Update mockito-scala-scalatest to 1.16.13

Updates org.mockito:mockito-scala-scalatest from 1.16.2 to 1.16.13.
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 me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.mockito", artifactId = "mockito-scala-scalatest" } ]

labels: test-library-update, semver-patch

Superseded by #2063.

Superseded by #2063.


Please invite me to the community

Name
Bello Osagie
Additional Context
I would like to be part of the community

Invitation sent to join the GitHub Organization. Welcome to Infraform 🎉Please check your mail to accept the invitation sent by GitHub! 🤖About usInfraform is an open source solution for serverless platforms, it is designed for developing solutions and enhancing creators to create their infrastructure 💻 Great to have you in our community ✨ Looking forward to your valuable contributions! 🤓 You can also check our community ✨ Github ✨ LinkedIn 💜 You can also share our community with other folks who want to learn about development, DevOps, tech, and contribute together and with us 👉💜👈


[CROSSDATA-593] Improve 'CREATE TABLE AS SELECT' statements' behaviour

Description
The schema of tables created using 'CREATE TABLE ... AS SELECT' was not persisted, so although data were inserted, the user did not be able to perform queries since the new table has no schema.
Testing

[x] Unit, integration tests

:+1:

LGTM

Coverage increased (+2.9%) to 57.232% when pulling dc21467c5ec3451d8372fedb64de2eea9fddfe8a on darroyocazorla:feature/createTableAsSelect into 6afadf005b895d2f623cf761e3751ed6f02122b8 on Stratio:master.


samba-tool crashes (missing dependencies)

Describe the bug
samba-tool is an integral tool for creating, managing and backing up Samba domain controllers. It is only built in the samba4Full package when DC support is enabled. Simply running samba-tool is enough to trigger a crash since the Python dependency tdb is not present.
Steps To Reproduce

nix-shell -p samba4Full --command samba-tool

Expected behavior
samba-tool displays a help message.
Screenshots
ERROR(<class 'ModuleNotFoundError'>): uncaught exception - No module named 'tdb'
  File "/nix/store/5ksfz6ba9c3g03sczapdcr3c2ak3acbh-samba-4.14.4/bin/samba-tool", line 44, in <module>
    retval = cmd._run("samba-tool", subcommand, *args)
  File "/nix/store/5ksfz6ba9c3g03sczapdcr3c2ak3acbh-samba-4.14.4/lib/python3.8/site-packages/samba/netcmd/__init__.py", line 259, in _run
    cmd = self.subcommands[cmd_name]
  File "/nix/store/5ksfz6ba9c3g03sczapdcr3c2ak3acbh-samba-4.14.4/lib/python3.8/site-packages/samba/netcmd/main.py", line 35, in __getitem__
    self[attr] = getattr(__import__('samba.netcmd.%s' % package,
  File "/nix/store/5ksfz6ba9c3g03sczapdcr3c2ak3acbh-samba-4.14.4/lib/python3.8/site-packages/samba/netcmd/delegation.py", line 23, in <module>
    from samba import provision
  File "/nix/store/5ksfz6ba9c3g03sczapdcr3c2ak3acbh-samba-4.14.4/lib/python3.8/site-packages/samba/provision/__init__.py", line 50, in <module>
    from samba.samba3 import smbd, passdb
  File "/nix/store/5ksfz6ba9c3g03sczapdcr3c2ak3acbh-samba-4.14.4/lib/python3.8/site-packages/samba/samba3/__init__.py", line 27, in <module>
    import tdb

Additional context

A workaround exists here - #105486 (comment).
A pull request that fixes this was submitted here - #105486, but was withdrawn without any additional information.

Notify maintainers
@aneeshusa
Metadata
[user@host:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"aarch64-linux"`
 - host os: `Linux 5.10.17, NixOS, 21.05.1669.973910f5c31 (Okapi)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.14`
 - channels(root): `"nixos-21.05.1669.973910f5c31"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Also tested on current master (151c2f5) with identical results:
nix-shell --packages samba4Full -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/master.tar.gz --command samba-tool

I am currently using an overlay to fix this, but compile times on aarch64 are really long. It also affects things like zfs and forces a recompile of those as well.


Company Communicator (Authors) needs permission to upload this file to your OneDrive

Hello, i'm having issues when trying to download the .zip file with the results of sending a message.
Mssg: "Something went wrong. Please try again."

Hi @AndresGav ,
Thanks for raising the query. Could you please check the Graph App API permissions. Here is the reference.

Yes

Hi @AndresGav ,
Could you please share the screenshots of Graph App- Overview section, Authentication section, Expose an API section, Manifest section with optional claims added.

Overview Section

Authentication section

Expose an API section

Manifest section with optional claims added

Currently, the issue has been resolved. For other users experiencing the same inconvenience, please check the permissions on OneDrive (read, write, and file upload), as the application adds the .zip files to a folder in OneDrive.

Hi @AndresGav I am facing the same issue and saw your post saying this can be solved by giving permissions in OneDrive. Would you be able to elaborate a bit? Which user must be given permission and on what folder?
Thank you in advance!

Hi @victorsimonlee, sure, sign in with the user you are trying to use to download the .zip on OneDrive. You just need to log in to OneDrive with the user you want to download with. It's likely that you’re accessing OneDrive for the first time, so once you log in, make sure the "Applications" folder is created.
If this doesn’t work, we can meet and take a look together.


updated and cleaned up for Godot 4.2

Figured I'd update this for 4.2 compat.

Updated the .gitignore file that was already there, and untracked .godot dir.

Looking at your original screenshot and at the new screenshot. It seems that the side cameras are rendering upside-down.

Good point, I wasn't sure originally that I was going to ask for a PR.

@victorbstan could you check one more thing for me, and that is why the main.tscn has grown to several megabytes? It looks like some of the assets have ended up inside of the scene instead of being loaded from source files.

I was testing out baked GI, and somehow some of the data became part of the Main scene? Had to manually delete it.

Hah! Yeah that'll do it :)

Thanks for the work! Cool to see this is finding some use in the world :)


made validColor use map

The valid color check was iterating at most n times over the validColors slice to determine if the color was valid.  This is updated to use a map, so the lookup for a valid color is in constant time (O(1) rather than O(n)).
All automated tests pass.

LGTM. Thanks for this PR!

 :)


ExpressionChangedAfterItHasBeenCheckedError in ./DatagridRow class DatagridRow of datagrid

Select one ...  (check one with "x")
[x] bug
[ ] feature request
[ ] enhancement

Expected behavior
No error appear
Actual behavior
code piece:
<clr-dg-row *ngFor="let p of projects" [clrDgItem]="p">
Throw error:
Error: Error in ./DatagridRow class DatagridRow - inline template:4:21 caused by: Expression has changed after it was checked. Previous value: 'true'. Current value: 'false'. at ViewWrappedError.ZoneAwareError (https://localhost:4200/vendor.bundle.js:103905:33) at ViewWrappedError.BaseError [as constructor] (https://localhost:4200/vendor.bundle.js:30836:16) at ViewWrappedError.WrappedError [as constructor] (https://localhost:4200/vendor.bundle.js:30901:16) at new ViewWrappedError (https://localhost:4200/vendor.bundle.js:61308:16) at CompiledTemplate.proxyViewClass.DebugAppView._rethrowWithContext (https://localhost:4200/vendor.bundle.js:87412:23) at CompiledTemplate.proxyViewClass.DebugAppView.detectChanges (https://localhost:4200/vendor.bundle.js:87385:18) at CompiledTemplate.proxyViewClass.AppView.internalDetectChanges (https://localhost:4200/vendor.bundle.js:87172:18) at View_ListProjectComponent1.detectChangesInternal (/ProjectModule/ListProjectComponent/component.ngfactory.js:352:19) at View_ListProjectComponent1.AppView.detectChanges (https://localhost:4200/vendor.bundle.js:87187:14) at View_ListProjectComponent1.DebugAppView.detectChanges (https://localhost:4200/vendor.bundle.js:87382:44) at ViewContainer.detectChangesInNestedViews (https://localhost:4200/vendor.bundle.js:87519:37) at CompiledTemplate.proxyViewClass.View_ListProjectComponent0.detectChangesInternal (/ProjectModule/ListProjectComponent/component.ngfactory.js:648:15) at CompiledTemplate.proxyViewClass.AppView.detectChanges (https://localhost:4200/vendor.bundle.js:87187:14) at CompiledTemplate.proxyViewClass.DebugAppView.detectChanges (https://localhost:4200/vendor.bundle.js:87382:44) at CompiledTemplate.proxyViewClass.AppView.internalDetectChanges (https://localhost:4200/vendor.bundle.js:87172:18
Reproduction of behavior

Clarity Version: [0.8.7]
Environment details

Angular version: 2.0.X
2.4.10
Clarity version:
0.8.7
OS and version:
Mac
Browser: [all]

Hi @steven-zou, please use Plunkr and recreate your issue as the information you provided above doesn't give us enough clue about the issue. Also, It might be a duplicate of https://github.com/vmware/clarity/issues/529. In that case, the fix to the problem was introduced in 0.8.10.

Seems similar issue with #529. As you said it has been fixed in 0.8.10. Actually I have tried 0.8.11, there will be same error thrown out. In our code, we use the *ngFor as data iteration like
<clr-dg-row *ngFor="let p of projects" [clrDgItem]="p">, then the error will be occurred.
But if we change the code to
<clr-dg-row * clrDgItems="let p of projects" [clrDgItem]="p">, the code will run normally. I'm not sure what's the root cause is?

Howdy @steven-zou,
I was able to recreate  your issue here: https://plnkr.co/edit/lsjSb7JQAKcdRcnK7nZ3?p=preview
I'll investigate further on this issue.

Hi,
Is the root cause figured out? As the fix and releasing the fix might need a long while, is there any possibilities to propose a workaround solution?

The plunker is using *ngFor for content iteration.
I don't see this happen with *clrDgItems instead.
Just an observation...

I think the problem may be caused by the *ngIf we used in
======
<clr-datagrid (clrDgRefresh)="refresh($event)">     <clr-dg-column>{{'REPOSITORY.NAME' | translate}}</clr-dg-column>     <clr-dg-column>{{'REPOSITORY.TAGS_COUNT' | translate}}</clr-dg-column>     <clr-dg-column>{{'REPOSITORY.PULL_COUNT' | translate}}</clr-dg-column>     <clr-dg-row *ngFor="let r of repositories" [clrDgItem]='r'>         <clr-dg-action-overflow *ngIf="listFullMode && hasProjectAdminRole">             <button class="action-item">{{'REPOSITORY.COPY_ID' | translate}}</button>             <button class="action-item">{{'REPOSITORY.COPY_PARENT_ID' | translate}}</button>             <button class="action-item" (click)="deleteRepo(r.name)">{{'REPOSITORY.DELETE' | translate}}</button>         </clr-dg-action-overflow>

@steven-zou : Was that workaround satisfactory? We haven't heard back on this issue recently.

*ngFor is working.

@steven-zou : Awesome. Happy to hear that the workaround worked!

I am still getting this issue

Why was this closed? This problem still happens and seems to be pretty easy to reproduce? vCD is getting this error when we added a <clr-dg-action-overflow> to our data grid https://plnkr.co/edit/VKaN98UkIBzLxRKTa0W8?p=preview
As the comments mentioned, the problem is when using *ngFor to create the rows, but not when using *clrDgItems
The workaround mentioned is not sufficient because you don't use *clrDgItems for server side paging/filtering.
Please reopen or comment

Hi @juanmendes I believe this is fixed with the latest release (you can check the plunkr you posted, which should be using the latest version of Clarity).


Release 0.13.0

Placeholder to discuss 0.13.0 when we get there.

@padrino/core-members Let me know if / when we should release a 0.13.0.beta1 and I will make that happen. Excited about the changes you guys are making! Also about shipping out a new website soon thanks to @wikimatze and the efforts on the proposal thread.

So awesome how fast Padrino is going to the next release! Before going to the release, it would be great to ship the new website, but some issues are still open about it.

Yes, I think we should release the beta version before releasing 0.13.0

@namusyaka @ujifgc I want to release a 0.13.0.beta1 this weekend if you think it's ready? Could you help compile a list of any breaking changes (if any)?

@padrino/core-members Do you think it's worth our efforts to put out a 0.12.5? I am tempted to focus our (quite limited) attention on 0.13.0.beta1. Thoughts?

I think we can release 0.12.5 and 0.13.0.rc1 separately.
A few bugs are very critical (i.e. generator), so their fixing should be included in 0.12.5.
I guess these plans would be better:

0.12.5 includes bug fixes.
0.13.0.rc1 includes new router and breaking changes.

Also, I've tried to pick up breaking changes: https://gist.github.com/namusyaka/eabb26a5c64a0876e9a4
Hope this helps.

@padrino/collaborators would one of you be able to create a 0.12.5 branch with critical fixes cherry-picked into it on top of 0.12.4? I will update the changelog and create related blog post and prepare a release for that first then.

Also that gist is super helpful, thank you

This looks good, will we also release the new website? If yes, we need to create a new blog post.

I've created the branch for 0.12.
Please confirm and push to the branch if other commits are required.
Also, I updated this gist.

@namusyaka thanks to your work here will compile release notes and a blog post for 0.12.5 and then also ship a 0.13.0.beta1 as well. Appreciate it!

@postmodern is there anything else in particular that we've fixed in master that you'd like to see in the 0.12.5 release?

@padrino/collaborators I have a blog post here: http://www.padrinorb.com/blog/padrino-0-12-5-bug-fixes-and-preparing-for-0-13-0 and changelog. Can you guys review the blog post and changes and let me know if you feel this is ready for release?

@padrino/collaborators I've also updated 0.13.0 changelog on master and pushed out the 0.13.0.beta1 release. Thanks @ujifgc and @namusyaka in particular for making 0.13.0 possible. Excited to be able remove a bunch of deprecated stuff and roll in the new mustermann based router.

@namusyaka @ujifgc Should we release 0.12.5 based on the details above or hold off for a bit longer, let me know what you two recommend.

I guess 0.12.5 is ready to release.
If any problems are detected after the release,  I think we should determine whether to backport into 0.12.x at that time.

@nesquena I see no reason to hold off the 0.12.5 release.

@namusyaka @ujifgc pushed 0.12.5 https://twitter.com/padrinorb/status/573042704268963841, thanks for the feedback! http://www.padrinorb.com/blog/padrino-0-12-5-bug-fixes-and-preparing-for-0-13-0

Juhu, retweeted the news already.

@padrino/collaborators just updated changelog and pushed 0.13.0.beta2 with all the latest changes.

@namusyaka @ujifgc going to release a 0.13.0.beta3 this week (or weekend) with latest changes after compiling changelog.

Great! Thanks!

Cool, thanks for the release @nesquena

Is the new site going to go live? It's been a while. Was at the old site the other day :older_woman: :older_man:...
Let me know if you need some non design help!

@sshaw thanks for offering your help, still waiting for a response from @padrino/collaborators people like @achiu, @nesquena, @DAddYE, @ujifgc and @namusyaka.

Just a followup as I've now pushed 0.13.0.beta3 live with changes here! Lots of very useful fixes and additions thanks to @namusyaka @ujifgc!
I am already using 0.13.0 in production and haven't been running into too many issues. @padrino/collaborators what are your thoughts on dropping the final release of 0.13.0 soon?
@wikimatze @sshaw I'd like to push the new site live when it's ready however @DAddYE is hosting the site so I will need to contact him when ready to deploy the new version. What are the remaining action items before the site is ready to deploy. For one, do we need to migrate over a lot of content?

@namusyaka @ujifgc What do you two think? Time for a 0.13.0 final release soon?

Do we pull #1966 and #1909?

I don't see any reason not to pull in either, but would love @namusyaka input as well. I will prepare release notes and a blog post as soon as I can for review. Will aim to release on Sunday.

Yes, I agree with you. We can go ahead as planned.

I have also been using 1.3.0.beta in production for a while. No problems found.

@namusyaka @ujifgc can you two help me identify the "upgrade guide" for 0.13.0? What are the major required and/or suggested modifications to make to a 0.12.x app?

@basex Thanks for testing and reporting back! You have been a Padrino user for a while since I recognize your username :) I have 0.13.0.beta3 on 4 projects without any issues right now as well so I think it's ready to be shipped.

Awesome news.

@nesquena I'm going to take a look at it today.

@namusyaka Great, if you can help with rough upgrade steps, I will take care of the rest later today.

@padrino/core-members Btw, should we support PADRINO_ENV yet?
https://github.com/padrino/padrino-framework/blob/master/padrino-core/lib/padrino-core.rb#L17-L20

@padrino/core-members Please take a look Upgrading guide.
I'd appreciate if you provide more breaking changes to the guide.

On the Upgrade guide in the Datamapper section is written:

You can use the middleware by putting that code on lib/ directory, and then add following one line to your application.

and then the line is missing.

@basex Thank you so much! I've just fixed it.

@namusyaka @ujifgc I've updated the changelog to reflect latest commits https://github.com/padrino/padrino-framework/commit/d109117e189ee2ddc933d031e6dfd8e51bfb6968. Can you both let me know if I've missed anything there?
@namusyaka can you review and merge @ujifgc PRs linked above?
Will draft up blog post soon.

@namusyaka @ujifgc I've published a draft blog post here:
http://www.padrinorb.com/blog/padrino-0-13-0-mustermann-router-performance-enhancements-streaming-support-and-much-more
and a stub for an upgrade guide:
http://www.padrinorb.com/blog/upgrading-padrino-from-0-12-x-to-0-13-0-guide
Can you two help me with identifying the major elements we need to mention for upgrading? Can you also review the blog post? Feel free to make edits or let me know if I missed a major section.

@namusyaka @ujifgc @padrino/collaborators what are your thoughts?

Looks good

@namusyaka thanks, can you help with the upgrade guide?

From what I can see, it looks fine.

@wikimatze thanks for taking a look! Excited to push the final release soon.

Updated the blog post to incorporate additional fixes patched today by @ujifgc. Are there any other fixes we should wait on prior to release?

Improved the upgrade guide to be clearer about the removed deprecated features. @namusyaka are you aware of any specific routing related incompatibilities? any other things that need to be changed when switching to 0.13.0?

I'm okay with releasing as soon as we solve or move away these bugs:
#1882 we should decide on the behavior
#1785 after thorough investigation I've come to conclusion that the buggy behavior (inability to implement helpers calling rendering another templates) is locked by this assettion: https://github.com/padrino/padrino-framework/blob/fb0960fd7275f4c2f0a8d421d91053a2df6c6232/padrino-helpers/test/test_output_helpers.rb#L78 and some similar ones. This template pretty much describes the mechanics that we try to put in helpers: https://github.com/padrino/padrino-framework/blob/master/padrino-helpers/test/fixtures/markup_app/views/capture_concat.erb
There's several solutions to this:

implement rails-flavored ERB (capture on =, execute on -)
reject the artful test and implement conditions looking at the last caller of #concat_to_template

AFAIK, there is no reason why we can't release 0.13.0

@namusyaka what are your thoughts on #1785 as pointed out above?

I took a stab at fixing #1882 and added to the upgrade guide as well.

Okay, I moved some issues away from 0.13. I think we can release.

Thanks again to @namusyaka @ujifgc for all your work to make this release possible. Just pushed the final 0.13.0 release! This is an awesome release and I hope we can push out a new website soon with help from @wikimatze too. 1.0 feels like it may actually happen some day thanks to all your efforts.

Congrats guys!!!!!!!!!!!!!!!!!!

Cool that it is out, need to update the book then. The question still remains, which website we should take, as discussed under https://github.com/padrino/padrino-framework/issues/1964. Think we should take the one from @angeloashmore.


Recommendation for using dual-socket Xeon system. Using Langchain-chatchat

The instructions for using Xeon host-only setup mention numactl. On a dual-socket system, how can both sockets (all logical cores) be used?
Under the Start Service section, the comments suggest to use only one socket.
# We recommend to use cores in one socket for the best performance.
# You may need to change the 0-47 below accordingly.

Currently, we do not recommend to utilize multiple sockets due to memory access speed different.  We will investigate to see if we can put some lightweight load into another sockets.

Is there any update to the recommendation? Please see the Jul 18 comment above

We cannot use simple config to use dual sockets.  As can be seen here, the controller, worker, and openai api server are all subprocesses from the main process.
To use the dual sockets, we will need to change the code based on your settings.
One possible changes would be change to use the following code:
import os
import multiprocessing

def set_cpu_affinity(cpu_id):
    try:
        # Set CPU affinity for the current process
        os.sched_setaffinity(0, {cpu_id})
    except AttributeError:
        # os.sched_setaffinity may not be available on all platforms
        pass

def run_on_specific_core(cpu_id, target_func, *args, **kwargs):
    set_cpu_affinity(cpu_id)
    return target_func(*args, **kwargs)

# Original run_controller function
def run_controller(log_level, started_event):
    # Your controller logic here
    pass

# Create the process with CPU affinity
cpu_id = 0  # Specify the CPU core you want to use (0-based index)
process = multiprocessing.Process(
    target=run_on_specific_core,
    args=(cpu_id, run_controller),
    kwargs=dict(log_level=log_level, started_event=controller_started),
    name="controller",
    daemon=True,
)

Use this method to re-write the code for starting worker, controller and api_server.  You can allocate one socket cores for worker, and the other socket for api_server and controller.


Grasp plugin for multi-gripper robot

Hi again, Jenny.
I've been testing some stuff and as I really didn't need to use more than one gripper, your plugin was working wonderfully :).
However, when I tried to use the other gripper, there were only problems.
In the robot urdf description (technically xacro) I tried the following configurations:

First try

<gazebo>
    <plugin name=...>
        <palm_link>left_gripper_palm_link</palm_link>
        <palm_link>right_gripper_palm_link</palm_link>
        <!-- gripper links from both grippers-->
        ...
    </plugin>
</gazebo>

This results in your plugin nicely detecting grips from both grippers, but it attaches the object to the first palm link specified. So in this case, if right gripper grabs a cube, the cube gets attached to the left gripper and weird stuff happens.

Second try

<gazebo>
    <plugin name="leftgripperfix" ...>
        <!-- palm and gripper links for LEFT gripper -->
    </plugin>
    <plugin name="rightgripperfix"...>
        <!-- palm and gripper links for RIGHT gripper -->
   </plugin>
</gazebo>

This results on the plugin working only on the left gripper. The right one doesn't, I think it's because "Filter with the same name already exists! Aborting".

Third and last try

<gazebo>
    <plugin name="leftgripperfix"...>
        <!-- left gripper -->
    </plugin>
</gazebo>
<gazebo>
    <plugin name="rightgripperfix"...>
        <!-- right gripper -->
    </plugin>
</gazebo>

Same as the previous case. Same error message.
Is there a way to make it work with both grippers?
Cheers!

Hi Max,
yes, this is currently a limitation of the plugin. I've described this in the class header.
At the moment only one object can be grasped at a time, and only one arm can be used per robot. It should not be too hard to change this though. I will hopefully be able to address this as soon as possible, maybe in the next week or two.
I was going to try what you did in your second (and third, which has the same effect) try as well, but I was already suspecting that it won't work.
Your first try doesn't work because only one palm_link will be loaded.
Meanwhile, if you urgently need it for both arms, you could make a wrapper for the plugin which loads different arms in the Load() method and initializes the plugin with the according details. Or you can wait until I've done it.
I will post here as soon as I've removed this limitation.
Cheers
Jenny

Thanks for the clarification. I didn't see that in the header.
It's not terribly urgent for my current case use as I'm really grasping with only one arm at a time. When I use the other gripper I'll have to just edit the plugin links and restart the simulation. Not beautiful, but doable and perfectly functional :)
Cheers Jenny.

Hi Max,
I am back to working now and will do the updates to the plugins in the next few days. Will report in this issue as soon as it's done.
P.S. I'm near Valparaiso right now actually, viva Chile!

Right, so I've done some changes and now it should be possible to use several arms. However in my current test-bed I don't have a robot with several arms and it will probably take me longer to set it up than it will take you to test it quickly. Can you please help me test it?
Please note there are now new description definitions to the graspit plugin, you have to put the palm and fingers into an <arm> tag.
It works for a single arm as it did before, but it's possible that there are a few minor mistakes for grasping with two different grippers. Please let me know if it works. Sorry for being too lazy to quickly set up a new test-bed, I have lots of other things on my plate right now ;)
Cheers
Jenny

Hi!
I haven´t been able to test your changes, as I'm not currently working on this. I'll try to do some tests soon so you can confirm it works, but I'm quite busy.
Just so you know, a friend started integrating his grasp detection algorithm in a similar environment as mine, so he probably will be using your awesome and magic plugin of wonders.
Sorry for the delay.
Max
P.S.: I live in Santiago! If you are still here and happen to be near, beers are definitely on me.

I have been using the plugin for a few projects with multiple arms/grippers and it works just fine by adding new  tags for individual arms.

Awesome, thanks for letting me know @hvpandya :))


Create GPO to disable AMSI

AMSI appears to flag Ansible activity as malicious sometimes which can cause provisioning to fail. Disable via registry key:

Addressed in #572


Add AsRef bounds to system account

Seems reasonable for the AccountId to add the AsRef<[u8]> bound, right? in practice all account types should be able to be represented as bytes in one way or another. Aside from the annoyance of changing most tests would there be any extra considerations for this change?

Why do you need this? You can just use encode?

Fixed arrays in SCALE don't have the length prefix, because they are fixed length.
Yeah you could save the allocation of Vec, however you could bring this argument for quite some types.


Refactorings

The main purpose is to remove the levels of indentation in unikernel.ml.
I'm a bit unsure about the authentication, esp on the verify email. My perception is:

we always want to authenticate the cookie and have a user around
for JS & images & css it's fine to not being authenticated
for /sign-up and /sign-in we don't need authentication
for /api-register also no need for authentication (cookie is pushed)
for /api/login no authentication (it is special, since only at that point the cookie is pushed)

for verify-email the user needs to be logged in (and it must be the same who's verifying the email address).
does this make sense?

The main purpose is to remove the levels of indentation in unikernel.ml.
I'm a bit unsure about the authentication, esp on the verify email. My perception is:

we always want to authenticate the cookie and have a user around
for JS & images & css it's fine to not being authenticated
for /sign-up and /sign-in we don't need authentication
for /api-register also no need for authentication (cookie is pushed)
for /api/login no authentication (it is special, since only at that point the cookie is pushed)

for verify-email the user needs to be logged in (and it must be the same who's verifying the email address).
does this make sense?

Yes this is perfect.

Thank you @hannesm . I will merge. 🥇


bootloader seems to generated dead_code warnings

I'm up to having the test cases running, and everything is compiling, but every time I cargo run or cargo test and build through the bootloader runner, I get a warning about dead code in some sort of generated enum declaration or something that's not actually part of my own crate:
Compiling bootloader v0.9.28 (/home/loka/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bootloader-0.9.28)
warning: field `0` is never read
  --> src/page_table.rs:20:13
   |
20 |     Mapping(MapToError<Size4KiB>),
   |     ------- ^^^^^^^^^^^^^^^^^^^^
   |     |
   |     field in this variant
   |
   = note: `#[warn(dead_code)]` on by default
help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field
   |
20 |     Mapping(()),
   |             ~~

warning: `bootloader` (bin "bootloader") generated 1 warning

I'd file an issue with the bootloader repo, but they're two breaking versions ahead of where this tutorial is, so I'm not sure they'll want to update the 0.9 series to fix this.
The exact versions of everything I'm using are as follows:
$ cargo tree
blog_os v0.1.0 (/home/loka/phil_opp_os)
├── bootloader v0.9.28
├── lazy_static v1.4.0
│   └── spin v0.5.2
├── spin v0.9.8
│   └── lock_api v0.4.12
│       └── scopeguard v1.2.0
│       [build-dependencies]
│       └── autocfg v1.2.0
├── uart_16550 v0.3.0
│   ├── bitflags v1.3.2
│   ├── rustversion v1.0.15 (proc-macro)
│   └── x86 v0.52.0
│       ├── bit_field v0.10.2
│       ├── bitflags v1.3.2
│       └── raw-cpuid v10.7.0
│           └── bitflags v1.3.2
├── voladdress v1.3.0
└── x86_64 v0.15.1
    ├── bit_field v0.10.2
    ├── bitflags v2.5.0
    ├── rustversion v1.0.15 (proc-macro)
    └── volatile v0.4.6

I've tried to set RUSTFLAGS in the .cargo/config.toml to allow unused, but that didn't have an effect.

Thanks for reporting!

I'd file an issue with the bootloader repo, but they're two breaking versions ahead of where this tutorial is, so I'm not sure they'll want to update the 0.9 series to fix this.

I'm maintaining the bootloader crate and I'm trying to keep the v0.9 releases up-to-date until I'm done migrating this tutorial to v0.11. I opened a PR at https://github.com/rust-osdev/bootloader/pull/436 to fix the warning.

Should be fixed in bootloader v0.9.29.


Can biobuddy run on local Llama3?

Not now, but open to receive PRs, doesn't seem to complicated given we are using LangChain. Will srart looking into it after adding AF2 https://github.com/BasedLabs/NoLabs/issues/95


Fixed missing spaces in readme

Added a space between "###" and the titles in the readme, so that the titles appear correctly on github.

Coverage remained the same at 100.0% when pulling 7cf2d339be3605f8bed76edbc37edbc9277e0d8c on Zulko:patch-1 into 2397ee86d6b208200954a2f15806417846bec694 on mewwts:master.

Thanks!


feat(grid): group by functionality with multiSort obervable

Grouping of rows with same entity property.
Column is having an input groupable, which if enabled then user will see a dropdown with list of columns which are groupable.  Groupable is supposed to be used with mutlisort$ observable in sort-manager which client can use to generate query. If not then user will not be able to sort other columns
At core, Column by which grid is grouped is the primary column by sorting is done, and ui-grid displays a "no data row" with entity's property's value or message returned by groupMessageCb function
How to test
For any column add tags
groupable = "true" and
groupMessageCb = "< optional custom function to override the message >"
Example
Template
<ui-grid-column [title]="'Task Status' "
                [groupable]="true"
                [groupMessageCb]="groupMessage"
                property="status"></ui-grid-column>

Ts file
public groupMessage(arg: string) {
    if (arg === TaskStatus.Unassigned || arg === TaskStatus.Pending) {
         return 'Action Needed';
    }
    return 'No Action Required';
}

Also, we need this rebased and rechecked to make sure everything is fine with ng9

Question: How does pagination work with this feature?
When I navigate to the next page, the response for the target page gets grouped? If so, that would be a weird behavior, it would mean that for every page I would have the group rows jumping around.
I honestly think that there should be paginators available for every group if what I assumed above is true.
@toxik @anbalase thoughts?

@rajeevuipath Please rebase this branch and update the test definitions.
After that I'm personally ok with the changes.
@toxik @anbalase @mhagape Any other thoughts here?

I took it for a spin and the sorting looks broken, have a look below (you need to unzip it first due to gh attachment limitations):

sorting looks disabled when you use the grouping feature, is that intended?
sorting has some glitches when it's reset, check below

group-sort.mp4.zip

I took it for a spin and the sorting looks broken, have a look below (you need to unzip it first due to gh attachment limitations):

sorting (on other columns than grouped) looks ~disabled~ ignored when you use the grouping feature, is that intended?
sorting has some glitches when it's reset, check below

group-sort.mp4.zip

Groupable feature works on multiSort$ which emits all the columns clicked chronologically. Since orchestrator uses sort$, it won't work in the expected way. Any application using this need to subscribe to multisort$ for other columns to get sorted.
Note: I have implemented in such a way that sorting will happen withing the group as I don't want to breakt
For your second issue, I tested the scenarios in a dummy application, and those glitches were not replicated there. It seems somewhere orchestrator is explicitly changing the column's sort direction and thus we are getting two columns with with non-empty sort direction.

I have created a demo showing the use case/behvaior or sorting logic. Please see these to get the gist of the behavior. https://uipath.zoom.us/rec/share/3M1VLezN8GNIaYGRzQKDefADJ6fvX6a80ykZ_aAIzhzTtOmHr8QWfRiEbqp0WZ7T?startTime=1586969242000

Closing this PR as of now, as its not needed in priority


Ability to test feature activation without passing a User in.

Hey James,
I needed this for one of our apps, where a feature rollout isn't tied to a particular user.
I'm not sure that's where you want to go with the project, but in any case, here is the code.
Cheers,
Mathieu

Bump - I would love to see that added: we would be using this for site-wide features such as "do we want to allow sign-ups without invitations or not".
@jamesgolick what do you think about this one?

My gut instinct is that this should probably be another set of methods.
Maybe even another object. I don't have any ideas for an API though. Do you?
On Tue, Feb 7, 2012 at 12:39 PM, Thibaut Barrre <
<EMAIL_ADDRESS>
wrote:

I don't exactly know what but something is annoying me a bit. Not sure
yet, I'll try to figure this out.
In my case I wanted to specify a behavior that doesn't depend on any user
at all (because I happen to have none: it's pre-sign-up).
Maybe what is annoying me is that the burden is on the caller to figure
out if a user or :all should be passed, which could ultimately lead to bugs.
[de]activate_for_all could lead to saving something different in Redis
maybe; when calling active? with a user id on these kinds of features it
would raise an error etc.
Raw, late thoughts :) (and keep in mind I'm just discovering rollout).
What do you think?

Reply to this email directly or view it on GitHub:
https://github.com/jamesgolick/rollout/pull/6#issuecomment-3855694

Raw thoughts:

I would keep the api calls available on the same rollout object for convenience (or on an included module)
we could add:

activate(feature)
deactivate(feature)
active?(feature)

maybe:

all the current functions could raise an exception if the feature has already been globally activated with above calls
and the reverse: active?(feature) etc would raise an error if the feature has already been activated with the per user/group functions

Not sure if the last bit is clunky or not, yet! But I like fail-fast personally...
Thoughts?

I like it actually. Patch? :-P
On Wed, Feb 8, 2012 at 11:05 AM, Thibaut Barrre <
<EMAIL_ADDRESS>
wrote:

Raw thoughts:

I would keep the api calls available on the same rollout object for
convenience (or on an included module)
we could add:
activate(feature)
deactivate(feature)
active?(feature)
maybe:
all the current functions could raise an exception if the feature has
already been globally activated with above calls
and the reverse: active?(feature) etc would raise an error if the
feature has already been activated with the per user/group functions

Not sure if the last bit is clunky or not, yet! But I like fail-fast
personally...
Thoughts?

Reply to this email directly or view it on GitHub:
https://github.com/jamesgolick/rollout/pull/6#issuecomment-3873719

:) it's planned - I'll just have to figure out how to "strongly-type" the difference. But maybe just relying on Redis to raise an exception on two different types of keys and wrapping it can be enough.
I'll work on that!

Awesome!
On Wed, Feb 8, 2012 at 11:23 AM, Thibaut Barrre <
<EMAIL_ADDRESS>
wrote:

:) it's planned - I'll just have to figure out how to "strongly-type" the
difference. But maybe just relying on Redis to raise an exception on two
different types of keys and wrapping it can be enough.
I'll work on that!

Reply to this email directly or view it on GitHub:
https://github.com/jamesgolick/rollout/pull/6#issuecomment-3874094


{Storage} Doc for storage data plane auth

Description

Doc enhancement for customer better understanding and providing auth info for storage data plane commands

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

Storage


coercing numeric scalar to string

Given the following input:
@section
SLACK_CLIENT_ID<PHONE_NUMBER>12.123456789012

the value is parsed as a number and rounded:
{ section: [ [ 'SLACK_CLIENT_ID',<PHONE_NUMBER>12.12346 ] ] }

How can the value be coerced to a string?

Ah! We had this same issue. Slacks id system is a number format unfortunately not currently supported (well) by most programming languages.

Whoops sorry on a phone! Anyhow here's a blog if you're morbidly curious why this happens. https://steve.hollasch.net/cgindex/coding/ieeefloat.html
To fix we quoted the value BUT this means you need to strip those quotes when you read the value.

Was going to say that you must've stumbled on this seeing as you advocate Slack integration :)
Yep, my intermediary solution was quoting too; just thought there may be an alternative.
Thanks for your quick response!

Sorry to comment on the back of this but did you also have trouble with the browser accepting the cookie [you presumably] set and returned in a 302 redirect back to your app as a consequence of a successful negotiation with Slack?
i.e.
const result = await slack.oauth.access({ client_id, client_secret, code })
if (result.ok) {
  ...
  session.userId = result.user.id;
  session.teamId = result.team.id;
  const cookie = await arc.http.session.write(session);
  return { cookie, status: 302, location: '/path/to/resource/under/client/app' };
}

The response contains a Set-Cookie header, but the browser appears to ignore it. I don't know if that's because the oauth flow has hopped between several domains: I see the cookie's SameSite is set to lax in @architect/functions code, however (possibly irrelevant).
No matter if you haven't seen this given it's likely completely unrelated to arc! But thought I'd ask on the off-chance.

The Lambda function resides on a different domain from the client app – at least in development (I'm using ngrok to expose a redirect endpoint to Slack that tunnels to my arc sandbox) – so suspect that may be problematic.

So since the cookie is issued by an *.ngrok.io tunnel I've spun-up so that Slack can make redirect requests, the only "solution" I could come up with is to remove the SameSite cookie attribute, add an Access-Control-Allow-Credentials: true header to CORS responses and make XHR requests from the browser with the credentials: 'include'/withCredentials: true param set. Although this is all local dev, this feels massively off: ideally I'd use a [webpack-dev-server] proxy, avoiding CORS concerns, but that doesn't transmit cookies for the proxied domain.
(I've been hacking around with the sandbox route registration code here-ish.)
I would certainly be curious to know how you handled local development with 'Sign in with Slack' integration (if you did)!

We did! We didn't have any of these issues but we used env vars because we just ran locally without a proxy. The bot code however we ran in staging to test it and not local. (But you could do the proxy given the bot code isn't doing anything with cookies.)
To work local w the sandbox we had env vars and used the redirect_uri to redirect back to http://localhost:3000 … think thats it. If you can't get that going lmk and I'll whip up an example app!


Basic AI Studio resource creation updates

fixing some issues with the outputs.tf and README.md files.

LGTM!