text:
Multiple images by msg.payload not supported?

Hi, I'm joining two payloads containing a buffer (a jpg image), so only one message is sent, and it contains msg.payload.img1 and msg.payload.img2.

In the notify.events node, I set up two images, one set with Content to msg.payload.img1 and the other pointing to msg.payload.img2.
I would expect a notification with two images, but instead I get this error from the notify node:
InvalidArgumentError: invalid file
Is this an unsupported operation? Is there any other way I can achieve what I'm trying to do?
Here is my flow:

Edit: Maybe your node expect just a buffer, but I'm passing a object. So this I think this is becoming a feature request.

Hello @frabnet.
Indeed, we found that notify.events node does not support nested fields. That means, we could work with msg.payload, but not with msg.payload.img1. We have fixed this issue in version 1.0.4.
Аlso we found that we had a bug in the code of the related nodejs module witch caused the impossibility of sending a file content as a string. We fixed this as well.
Thanks for the report!

Thanks for your work.
Is it normal to see the Node https://flows.nodered.org/node/@notify.events/node-red still at v.1.0.1 ?

Is it normal to see the Node https://flows.nodered.org/node/@notify.events/node-red still at v.1.0.1 ?

Thanks a lot, forgot to update the version in the node-red repository.

authors: frabnet matrozov

repo: notify-events/node-red


text:
Adding the contributors page to mention all the awersome people who have contributed to the website. (WEBSITE)

Adding the contributors page to mention all the awersome people who have contributed to the website.
@notsoocool Assign this to me under gssoc 2024 ext and hacktoberfest i will work on this issue.

Hi @tarunkumar2005 ,
I noticed that you've raised the same issue twice. I understand that communication can sometimes be frustrating, especially when waiting for a response. However, raising duplicate issues can clutter our workflow and make it harder to track problems effectively.
This serves as a warning for this instance. In the future, I kindly ask that you refrain from raising duplicate issues, as it may lead to action being taken on my part.
Thank you for your understanding, and I appreciate your contributions to the project.

@notsoocool I am sorry for this i didn't saw that i raised this on two different days so i forgot i have already raised it that's why but i will keep this in mind next time so sorry for this.

source: gharchive/issue

repo: notsoocool/codecache

license: MIT

license_type: permissive

license_source: github-api


text:
Multisig proxy creation. State with error run out of window

Description

The scroll should be added. Figma link.

Status verification: ✅

authors: pgolovkin stepanLav

repo: novasamatech/nova-spektr


text:
suggestion for package niceties

Return the values for the description and the repository URL so that the user knows that their code was correct, which is better than just checking that they exist.  This will ensure that the user put their URL in quotes correctly (which I messed up and only fixed when I tried to do lesson 8).
Also, my understanding is that Node 3.* doesn't require READMEs, so perhaps that instruction could be deleted.
I'm just going through this lesson at Node School SF so I'm adding suggestions in real time as we work through.  Thanks!

thanks @sachinag !! this kind of feedback is perfect. sorry for the delay in response.

authors: ashleygwilliams sachinag

repo: npm/how-to-npm

license: isc

license_source: bigquery


text:
feat(dropdowns): add dropdown-driven-tabs

[finishes #119305019]
Adds JavaScript to the meta component that allows a standard dropdown to act as a tab selector via the dropdown-driven-tabs class. This was necessary since Bootstrap's existing tab functionality explicitly excludes .dropdown-menu from container lookup logic.
Some things to note:

This addresses funcionality only
This does not address styling of the dropdown button or tabbed content as shown in the design
Styling can be accomplished independently from this functionality

@jefflembeck @rockbot This should be ready to go (I think). See the updated components in the styleguide:

Dropdowns
Tabs (linking to dropdowns)

If you don't see any problems, I will promote the alphas, merge, and then deploy master.

I'm super into this. @nexdrew 👍

@rockbot That's my take on this, yes, because it doesn't change anything about normal button/dropdown rendering, so any button styling can apply with or without this functionality. The standard dropdown styles certainly seem odd, but I think that should be handled separately.
However I can easily be overridden there. :) Know that my styling abilities are very limited though.

please either change from alpha versions before merging or put in another PR for the non-alpha versions of these changes

I will do the former. 👍

source: gharchive/pull-request

authors: jefflembeck nexdrew

repo: npm/pivotal-ui

license: mit


text:
Fix: measure header height

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Does not use a hard-coded value for Header height, but instead attempts to measure it from the DOM.

What is the current behavior? (You can also link to an open issue here)

The header height is a hard-coded constant, thus causing some problems with Follow On Air (broadly speaking).

What is the new behavior (if this is a feature change)?

The height of the header is measured when it's first used, allowing customizations of the header to not affect "Follow On Air".
Status

[X] The functionality has been tested by the PR author
[ ] The functionality has been tested by NRK

Closing, need to reopen with a better base branch

repo: nrkno/tv-automation-server-core


text:
Add sort functionality to tables

Here we are adding sort functionality to Assessments and Object Library
New issue #338 for User table

I added this to the MVP milestone, but I would say it is less important than enabling editing throughout @MattF-NSIDC

@mfisher87 Hey, I just wanted to ask is this still relevant? I actually have something figured out for this ;)

Hey @Sherwin-14 , sorry for the delay in responding. Had a medical emergency with one of my pets (they're recovering well now!).
I haven't used that library before, but perhaps! I'll have to think a little more. I'm also assigned to work on this project for the next couple of weeks, so I'll be more active in the immediate future.
My one thought right now is perhaps we will need to do pagination on the server side. Eventually there may be thousands of Projects, and we probably only want to show ~20 at a time. That can probably wait until we have more data, though.

@mfisher87 I am so sorry to hear that,  I hope he is doing fine ! I just wanted to ask you since I had thought about doing this and your suggestions for pagination is something that I too would ponder on.

He's doing really well now, but still has a week and a half of recovery before he'll be fully healed! I'm going to keep thinking about how we should implement this. cc @rmarow

Just for my curiosity, Is server side sorting something that most web applications do? I mean to say that I had thought of sort-table library as it can easily sort items on the client side. I am just asking this since I have little idea about how production grade applications usually approach situation like these ;)

It depends on the expected scale of the data! There are some pieces of data that we know won't get very big, e.g. the list of possible statuses a survey/project can have, and we will never need to paginate.
The list of all surveys/projects can get pretty big over the years, so I feel server-side pagination is going to lead to the best chance of good performance over the lifetime of the application. I really only reach for pagination for cases where I know the data is big or will grow fast. The SQL database that backs the application is extremely good at grabbing those smaller chunks.

@mfisher87 Hey, Is there any progress in this issue? I was thinking of some solutions for this and i guess an algorithm like bucket or radix sort might be useful here. Would like to know what you think about this ;)

We didn't make it to this issue in our last round of funding, so there was no progress unfortunately :(
In most cases I'd say it's really important to do sorting in the database, but the size of the data in these tables is going to grow at a rate of dozens per year, so perhaps we should take a short-term approach to this problem with a plan to come back and implement a long-term approach later?
Short term approach could be as simple as using an out-of-the-box library to do the sorting in JS (DataTables? - this tutorial looks really helpful).
I think this would be the best place to start, and then we can create a ticket for the long-term approach. What do you think?

A stab at long-term "best practice" approach:

The user clicks the table header to sort by that field. The default is descending.
The page reloads with a new query parameter sort={field_name}.
Flask receives this sort argument and uses it in the db query as order_by(selected_field.desc()) that field.
The Jinja template receives the sorted results and displays them, and an :arrow_down: indicator appears next to the field that is sorted in descending order.
The user clicks the same table header a second time, it switches to ascending order.
Query parameter sort={field_name} asc is passed (or sort=-{field_name} to make it easier to parse?)
Flask receives the sort argument and recognizes the indicator that this should be an ascending sort
The database query does order_by(selected_field.asc()) instead this time
The template indicates ascending order with a :arrow_up: icon

The flask-table library is very outdated but may provide useful code for generating the column header behaviors.
Finally, it would be great to think about pagination at this point. Flask-SQLAlchemy has pagination features out of the box that we could leverage. Again, data growth will be slow, but it would be great to set the app up to be low maintenance over the long term when the data does get too big to reasonably show on one page.
All of this is just thinking out loud, please share your ideas to make it better :) Especially, "should the sort order default to ascending or descending?" For dates, I think descending is preferable, but for alphabetical columns, ascending is preferable. We could allow the user to choose ascending or descending by displaying two buttons for each column. What do you think?
cc @rmarow

Well all the suggestions seem appropriate to me . Although the short-term approach was something similar to what I suggested the only difference was that I did this with sort-table JS . Datatables library also sort's the table on the client side so I guess if that is the way we decide to move forward, then using either of them would suffice. I have done this already using sort-table so you can check if its ok or not;)

have done this already using sort-table so you can check if its ok or not;)

Where can I find this? I may not have time for an in-depth review in the short-term, though.

One thing that we can do is use checkboxes instead of buttons? if it doesn't interfere with the design then I think this maybe a good idea.

Are you imagining being able to sort by multiple columns? It couldn't hurt, but I don't think it will be required (yet).

@mfisher87 Yes I was talking about using multiple columns to sort. I'll fix this and let you know;)

Hey @Sherwin-14 yeah, we had a pretty active work period recently! Anything we can do to explain changes that might help?
I think the most important place to add sorting is the Assessments table. @hazelshapiro can you confirm?

I think the assessments table is a good place to start, but the object library will also need sort/filter functions since we could easily get to 100s of objects @mfisher87 @Sherwin-14

Good point. Since the object library table is likely to get big long before the assessments table, I think that might be an even better place to start.

Moved to the Response object registry/library milestone. I think this will make more sense once we reboot full-on development.

@Sherwin-14 you'll see we made some pushes on your branch. We noticed that when we use the sorting functionality with simple-datatables the Icons go away. youll see in theses screenshots.  We have not found a solution yet but just wanted to keep you in the loop incase you have any ideas

There's some other users reporting this:
https://github.com/fiduswriter/simple-datatables/issues/308
I think we should open a new issue on that repo with an SSCCE / MRE for help with this.

for now we are okay with moving forward without cute tooltips. and will put those back in eventually - will create another issue for that.

@hazelshapiro Let's chat about this if you have 15 free minutes tomorrow! I have some updates that will be easier to show over zoom

@hazelshapiro Let's chat about this if you have 15 free minutes tomorrow! I have some updates that will be easier to show over zoom

I just sent an invite - I could do later in the day (between 2-3) too if that's better.

Created issue #338 for user table, will proceed with Assessment and Object Library for this story's new scope

repo: nsidc/usaon-benefit-tool


text:
Support cutting elements from the slice with append

Sometimes you need to remove element from the slice and one of the convenient ways to that is to use append.
package foo
func Main() int {
	a := []int{0,1,2,3,4,5}
	a = append(a[:2], a[3:]...)
	return len(a)
}

This code does not compile in neo-go with (SUBSTR): can't convert Array to ByteArray message You have to create new slice, which is totally fine, but may be a bit confusing. So it would be nice to support this feature if possible.

This happens because subslicing is supported only for []byte via SUBSTR instruction.
There is no similar instruction for regular Arrays and the only way to support this is via loops (which can be done manually anyway).
However for your specific case, there is a REMOVE instruction, which can be wrapped in separate builtin in 2.x and possibly invoked directly after #941 .

Closed via #1021.
Your example:
package foo
import "github.com/nspcc-dev/neo-go/pkg/interop/util"
func Main() int {
	a := []int{0,1,2,3,4,5}
	util.Remove(a, 2)
	return len(a)
}

authors: AlexVanin fyrchik

repo: nspcc-dev/neo-go


text:
fix addReadyEvent to fix android seekToTimeCompleteEvent call

A better solution for #53...
sorry for the trouble, but after installing the version with the fix I made I found that this is a better working solution.
please merge change as well.
thanks...

Ah yes good catch thanks @orionsa !

Published in 5.0.7 now.

Thank you...

authors: NathanWalker orionsa

repo: nstudio/nativescript-plugins


text:
Fix typo

Correctly point version of fancy camera

Already fixed by @triniwiz


text:
Countdown for person

Allow users to mention others in a countdown. "How long is it until X time for Y person?"

The primary use case for this feature would be to allow a user to use the countdown command for someone else, which is more likely to be abused than used in earnest.

repo: ntseng/DirectoryBot


text:
Replace MySQLdb with SQLalchemy

Current Masakari uses MySQLdb to access its DB. In some environment or distribution, they use not only MySQL but PostgresQL or other db. To enable masakari to work with other DB series, we need to replace MySQLdb with SQLalchemy.

resolved by #22

repo: ntt-sic/masakari


text:
feat: add wrappers for channels topic in v4 api

This PR will document the addition of all the relevant commands for each v4 API endpoint pertaining to the management of channels in Mix projects.
It will exit WIP when all of the commands have been merged into the feat/channels-command branch.
Statuses

[x] channels:create: adapter complete, working prototype of command (#19)
[x] channels:config: adapter, command, and test complete (#30)
[x] channels:activate: adapter and command complete (#18)
[x] channels:deactivate: adapter, command, and test complete (#17)
[x] channels:rename: adapter, command, and test complete (#22)

TODO post-merge

[x] Add union of request param types into src/mix/api/index.ts
[x] Look for flags, errors, etc. to refactor

Done with verification.

:tada: This PR is included in version 1.4.0-beta.15 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 3.0.0-beta.1 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

authors: grof oliver-daniel

repo: nuance-communications/mix-cli


text:
🛑 Secret Site BIS is down

In b57afb8, Secret Site BIS ($SECRET_SITE) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Secret Site BIS is back up in 5db4bcb after 12 minutes.


text:
🛑 Università e ricerca is down

In 679c0a2, Università e ricerca (https://www.mur.gov.it/it) was down:

HTTP code: 403
Response time: 581 ms

Resolved: Università e ricerca is back up in 642c7a4.


text:
🛑 Università e ricerca is down

In 90f1297, Università e ricerca (https://www.mur.gov.it/it) was down:

HTTP code: 403
Response time: 855 ms

Resolved: Università e ricerca is back up in 20f045e.


text:
🛑 Guardia di Finanza is down

In 9cbd12b, Guardia di Finanza (https://www.gdf.gov.it) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Guardia di Finanza is back up in 9557bf7 after 10 minutes.


text:
🛑 Cultura is down

In 9ef6d90, Cultura (https://www.beniculturali.it/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Cultura is back up in 1af60c4 after 11 hours, 4 minutes.


text:
Need help for vimwiki with markdown syntax

I am using vimwiki with markdown syntax.
Have added below line in ftplugin->vimwiki.vim to override default commentstring(%%) for vimwiki:
set commentstring=<!--\ %s\ -->

This works well and gcc adds proper comment like this:
<!-- TODOs -->

But for code blocks also it uses the same commentstring, while in markdown file it works well.
My understanding is, this plugin determines the commentstring with help of tree-sitter so I even tried setting the markdown parser for vimwiki file, and now the vimwiki files are using markdown syntax but it didn't help.

Snippet used for overriding the vimwiki tree-sitter parser:
local ft_to_parser = require"nvim-treesitter.parsers".filetype_to_parsername
ft_to_parser.vimwiki = "markdown"

Note: Filetype for vimwiki files is vimwiki only, I don't want to change that, because if I change that I'll loose the mapping and functionalities defined by vimwiki pluggin.

Please use discussions for asking questions.


text:
GCP Pub/Sub source and sink

Is your feature request related to a problem? Please describe.
Useful for GCP users to be able to source events from the GCP Pub/Sub service.
Describe the solution you'd like
A source that turns GCP Pub/Sub events into messages for further processing.
Describe alternatives you've considered
None
Additional context
None

Message from the maintainers:
If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.

Can I work on this ?

https://github.com/numaproj-contrib/gcp-pub-sub-source-go

Implemented via https://github.com/numaproj-contrib/gcp-pub-sub-source-go and https://github.com/numaproj-contrib/gcp-pub-sub-sink-go

repo: numaproj/numaflow


text:
Extensibletype's test_perfecthashing sometimes fails

There's a rare failure of perfecthashing unit test that showed up a few times in our CI builds. The error message can be slightly different, but I suspect the cause is the same. To reproduce:
$ for i in `seq 1000`; do python test_perfecthashing.py || break; done

test_methodtable (__main__.TestInterning) ...
1 table building took 0.000236988067627 seconds.
101 table building took 0.00116181373596 seconds.
201 table building took 0.00199198722839 seconds.
301 table building took 0.00313305854797 seconds.
401 table building took 0.00398087501526 seconds.
501 table building took 0.00597405433655 seconds.
601 table building took 0.00692415237427 seconds.
701 table building took 0.00718903541565 seconds.
801 table building took 0.00795102119446 seconds.
901 table building took 0.0124530792236 seconds.
1001 table building took 0.0133080482483 seconds.
1101 table building took 0.0155501365662 seconds.
1201 table building took 0.0147659778595 seconds.
1301 table building took 0.0160248279572 seconds.
1401 table building took 0.0165131092072 seconds.
1501 table building took 0.0170249938965 seconds.
1601 table building took 0.017324924469 seconds.
1701 table building took 0.0172760486603 seconds.
1801 table building took 0.0175180435181 seconds.
1901 table building took 0.0176138877869 seconds.
2001 table building took 0.0380890369415 seconds.
2101 table building took 0.0419509410858 seconds.
2201 table building took 0.0426738262177 seconds.
Error: No suitable table found
ERROR

======================================================================
ERROR: test_methodtable (__main__.TestInterning)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_perfecthashing.py", line 71, in test_methodtable
    build_and_verify_methodtable(ids[:i], flags[:i], funcs[:i])
  File "test_perfecthashing.py", line 22, in build_and_verify_methodtable
    table.generate_table(len(ids), ids, flags, funcs)
  File "methodtable.pyx", line 130, in extensibletype.methodtable.PerfectHashMethodTable.generate_table (build/objs/athena/src/numba/deps/pyextensibletype/extensibletype/methodtable.c:2682)
HashingError: Unable to create perfect hash table for table: PerfectHashMethodTable(
<snip>

This issue is obsolete as Extensibletype doesn't exist anymore, closing.

authors: eltjpm pitrou

repo: numba/numba


text:
Reenable OpenMP threading backend in wheel builds

[x] I am using the latest released version of Numba (most recent is visible in
the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).

On Linux:

The 0.40.0 wheel build of Numba had an OpenMP backend that segfaulted/sigabrt'd ld.so.
The 0.40.1 wheel build of Numba disabled OpenMP to avoid the above problem.

This issue is to act as a reminder to debug and fix the root cause of the problem, reproducer etc. is here https://github.com/numba/numba/issues/3341

After considerable debugging to get to the bottom of this, I'm of the view that the issue is essentially the same as that described here https://github.com/NixOS/patchelf/issues/84.
Things that helped lead here:

https://sourceware.org/bugzilla/show_bug.cgi?id=16457
Searching on a search engine for edit '.gnu.version' lead to the patchelf issue above.

$readelf -WV <path>/lib/python3.7/site-packages/numba/npyufunc/omppool.cpython-37m-x86_64-linux-gnu.so

Version symbols section '.gnu.version' contains 69 entries:
 Addr: 00000000000011f8  Offset: 0x0011f8  Link: 3 (.dynsym)
  000:   0 (*local*)       2 (GLIBC_2.2.5)   3 (GOMP_1.0)      4 (GLIBC_2.2.5)
  004:   5 (GLIBCXX_3.4)   6 (CXXABI_1.3)    2 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)
  008:   3 (GOMP_1.0)      0 (*local*)       2 (GLIBC_2.2.5)   5 (GLIBCXX_3.4)
  00c:   5 (GLIBCXX_3.4)   7 (GLIBC_2.2.5)   8 (OMP_1.0)       0 (*local*)
  010:   0 (*local*)       0 (*local*)       2 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)
  014:   6 (CXXABI_1.3)    2 (GLIBC_2.2.5)   5 (GLIBCXX_3.4)   2 (GLIBC_2.2.5)
  018:   0 (*local*)       8 (OMP_1.0)       2 (GLIBC_2.2.5)   6 (CXXABI_1.3)
  01c:   6 (CXXABI_1.3)    4 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)   0 (*local*)
  020:   9 (GCC_3.0)       8 (OMP_1.0)       0 (*local*)       0 (*local*)
  024:   2 (GLIBC_2.2.5)   5 (GLIBCXX_3.4)   1 (*global*)      1 (*global*)
  028:   1 (*global*)      1 (*global*)      1 (*global*)      1 (*global*)
  02c:   1 (*global*)      1 (*global*)      1 (*global*)      1 (*global*)
  030:   1 (*global*)      1 (*global*)      1 (*global*)      1 (*global*)
  034:   1 (*global*)      1 (*global*)      1 (*global*)      1 (*global*)
  038:   1 (*global*)      1 (*global*)      1 (*global*)      1 (*global*)
  03c:   1 (*global*)      1 (*global*)      1 (*global*)      1 (*global*)
  040:   1 (*global*)      1 (*global*)      1 (*global*)      1 (*global*)
  044:   1 (*global*)

Version needs section '.gnu.version_r' contains 6 entries:
 Addr: 0x0000000000001288  Offset: 0x001288  Link: 37 (.dynstr)
  000000: Version: 1  File: libgcc_s.so.1  Cnt: 1
  0x0010:   Name: GCC_3.0  Flags: none  Version: 9
  0x0020: Version: 1  File: libpthread.so.0  Cnt: 1
  0x0030:   Name: GLIBC_2.2.5  Flags: none  Version: 7
  0x0040: Version: 1  File: libstdc++.so.6  Cnt: 2
  0x0050:   Name: CXXABI_1.3  Flags: none  Version: 6
  0x0060:   Name: GLIBCXX_3.4  Flags: none  Version: 5
  0x0070: Version: 1  File: libm.so.6  Cnt: 1
  0x0080:   Name: GLIBC_2.2.5  Flags: none  Version: 4
  0x0090: Version: 1  File: libgomp.so.1  Cnt: 2   # <--- NOTE libgomp.so.1 for versions of {G,}OMP_1.0
  0x00a0:   Name: OMP_1.0  Flags: none  Version: 8
  0x00b0:   Name: GOMP_1.0  Flags: none  Version: 3
  0x00c0: Version: 1  File: libc.so.6  Cnt: 1
  0x00d0:   Name: GLIBC_2.2.5  Flags: none  Version: 2

$ readelf -d <path>/lib/python3.7/site-packages/numba/npyufunc/omppool.cpython-37m-x86_64-linux-gnu.so
Dynamic section at offset 0x6d98 contains 30 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgomp-24cd7153.so.1.0.0] # <--- NOTE: DT_NEEDED shared lib name
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/../.libs]

I think auditwheel repair is most likely the part of the build that's executing patchelf --replace-needed. Anaconda distribution patchelf (and the latest tagged release) is version 0.9 (29 Feb 2016), the patch for patchelf that fixed the issue is https://github.com/NixOS/patchelf/pull/85 and went in after the last release.
Doing:
$ patchelf --replace-needed libgomp-24cd7153.so.1.0.0 libgomp.so.1 <omplib>

fixes the ELF to refer to Anaconda shipped/system libgomp.so.1 which matches the gnu.version_r. This leads to a valid ELF.
Alternatively doing (circuitous as --replace-needed X X is a NOP):
$ patchelf_built_from_master --replace-needed libgomp-24cd7153.so.1.0.0 libgomp.so.1 <omplib>
$ patchelf_built_from_master --replace-needed libgomp.so.1 libgomp-24cd7153.so.1.0.0 <omplib>

fixes the ELF so that DT_NEEDED has  0x0000000000000001 (NEEDED)             Shared library: [libgomp-24cd7153.so.1.0.0]  and .gnu.version_r has:
  0x0090: Version: 1  File: libgomp-24cd7153.so.1.0.0  Cnt: 2
  0x00a0:   Name: OMP_1.0  Flags: none  Version: 8
  0x00b0:   Name: GOMP_1.0  Flags: none  Version: 3

This also leads to a valid ELF.
Further, the ELF linter actually spots the problem with the DSO that caused the segfault/sigabrt in the first place:
$ eu-elflint <path>/lib/python3.7/site-packages/numba/npyufunc/omppool.cpython-37m-x86_64-linux-gnu.so|grep .gnu.version_r
section [ 5] '.gnu.version_r': entry 1 references unknown dependency

we {c,sh}ould add this to the wheel build scripts?

Ping @sklam
Also, for toolchain purposes, ping @mingwandroid @nehaljwani @msarahan @jjhelmus

@nehaljwani @jjhelmus, thanks for the rebuild. I tried the Anaconda patchelf build 3 as suggested:
#!/bin/bash

function dso_info(){
printf "Info for bad DSO:\n"
printf "===>OMP symbols in DT_NEEDED:"
readelf -d $OFFENDING_DSO|grep omp
printf "===>OMP symbols in Versioned:"
readelf -WV $OFFENDING_DSO|grep omp
printf "===>ELF linter output:"
eu-elflint $OFFENDING_DSO
printf "\n"
}

OFFENDING_DSO="offending_dso.so"
ENVNAME='_patchpatchedelf'
conda remove -n $ENVNAME --all -y
conda create -n $ENVNAME patchelf -y
source activate $ENVNAME

echo "----------------------------------------------------------------------"
echo "Using conda patchelf build 3:"

which patchelf

# get file, demo issue
cp <path>/envs/numba_wheel_40/lib/python3.7/site-packages/numba/npyufunc/omppool.cpython-37m-x86_64-linux-gnu.so.ORIG $OFFENDING_DSO
dso_info

# patch
printf "Patching...\n"
patchelf --replace-needed  libgomp-24cd7153.so.1.0.0 libgomp.so.1 $OFFENDING_DSO
patchelf --replace-needed  libgomp.so.1 libgomp-24cd7153.so.1.0.0 $OFFENDING_DSO

# check if fixed
dso_info

# clean up
source deactivate $ENVNAME
rm $OFFENDING_DSO

echo "----------------------------------------------------------------------"
echo "Using source build:"

PATCHELF_FROM_SOURCE="<path>/src/patchelf"
# get file, demo issue
cp <path>/envs/numba_wheel_40/lib/python3.7/site-packages/numba/npyufunc/omppool.cpython-37m-x86_64-linux-gnu.so.ORIG $OFFENDING_DSO
dso_info

# patch
printf "Patching...\n"
$PATCHELF_FROM_SOURCE --replace-needed  libgomp-24cd7153.so.1.0.0 libgomp.so.1 $OFFENDING_DSO
$PATCHELF_FROM_SOURCE --replace-needed  libgomp.so.1 libgomp-24cd7153.so.1.0.0 $OFFENDING_DSO

# now fixed.
dso_info

and it gave this:
$ bash omp_issue.sh

Remove all packages in environment <path>/envs/_patchpatchedelf:

## Package Plan ##

  environment location: <path>/envs/_patchpatchedelf

The following packages will be REMOVED:

    libgcc-ng:    8.2.0-hdf63c60_1
    libstdcxx-ng: 8.2.0-hdf63c60_1
    patchelf:     0.9-he6710b0_3

Solving environment: done

## Package Plan ##

  environment location: <path>/envs/_patchpatchedelf

  added / updated specs:
    - patchelf

The following NEW packages will be INSTALLED:

    libgcc-ng:    8.2.0-hdf63c60_1
    libstdcxx-ng: 8.2.0-hdf63c60_1
    patchelf:     0.9-he6710b0_3

Preparing transaction: done
Verifying transaction: done
Executing transaction: done
#
# To activate this environment, use
#
#     $ conda activate _patchpatchedelf
#
# To deactivate an active environment, use
#
#     $ conda deactivate

----------------------------------------------------------------------
Using conda patchelf build 3:
<path>/envs/_patchpatchedelf/bin/patchelf
Info for bad DSO:
===>OMP symbols in DT_NEEDED: 0x0000000000000001 (NEEDED)             Shared library: [libgomp-24cd7153.so.1.0.0]
===>OMP symbols in Versioned:  0x0090: Version: 1  File: libgomp.so.1  Cnt: 2
===>ELF linter output:section [ 5] '.gnu.version_r': entry 1 references unknown dependency
section [34] '.symtab': _DYNAMIC symbol size 0 does not match dynamic segment size 544
section [34] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol size 0 does not match .got.plt section size 392
loadable segment [7] is writable but contains no writable sections

Patching...
Info for bad DSO:
===>OMP symbols in DT_NEEDED: 0x0000000000000001 (NEEDED)             Shared library: [libgomp-24cd7153.so.1.0.0]
===>OMP symbols in Versioned:  0x0090: Version: 1  File: libgomp.so.1  Cnt: 2
===>ELF linter output:section [ 5] '.gnu.version_r': entry 1 references unknown dependency
section [34] '.symtab': _DYNAMIC symbol size 0 does not match dynamic segment size 544
section [34] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol size 0 does not match .got.plt section size 392
loadable segment [7] is writable but contains no writable sections
loadable segment [8] is writable but contains no writable sections
loadable segment [9] is writable but contains no writable sections

----------------------------------------------------------------------
Using source build:
Info for bad DSO:
===>OMP symbols in DT_NEEDED: 0x0000000000000001 (NEEDED)             Shared library: [libgomp-24cd7153.so.1.0.0]
===>OMP symbols in Versioned:  0x0090: Version: 1  File: libgomp.so.1  Cnt: 2
===>ELF linter output:section [ 5] '.gnu.version_r': entry 1 references unknown dependency
section [34] '.symtab': _DYNAMIC symbol size 0 does not match dynamic segment size 544
section [34] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol size 0 does not match .got.plt section size 392
loadable segment [7] is writable but contains no writable sections

Patching...
Info for bad DSO:
===>OMP symbols in DT_NEEDED: 0x0000000000000001 (NEEDED)             Shared library: [libgomp-24cd7153.so.1.0.0]
===>OMP symbols in Versioned:  0x0090: Version: 1  File: libgomp-24cd7153.so.1.0.0  Cnt: 2
===>ELF linter output:phdr[2]: cannot get content of note section: invalid section flags
section [32] '.symtab': _DYNAMIC symbol size 0 does not match dynamic segment size 544
section [32] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol size 0 does not match .got.plt section size 392
loadable segment [7] is writable but contains no writable sections
loadable segment [8] is writable but contains no writable sections
loadable segment [9] is writable but contains no writable sections

so it looks like that build is still not patching the versioned symbols section of the ELF correctly whereas the source build is. The offending DSO can be obtained from pip install numba=0.40.0 and fishing out the file site-packages/numba/npyufunc/omppool.cpython-37m-x86_64-linux-gnu.so.

Update:

patchelf build from HEAD works
to re-enable omp in wheel, we need to update setup.py to remove the check on is_building_wheel()

ping? :)

@slayoo thanks for the ping. I think we are just waiting on someone to submit a PR for the setup.py.

Using the patchelf from main|defaults I get:
----------------------------------------------------------------------
Using conda patchelf build 3:
/home/vhaenel/miniconda3/envs/_patchpatchedelf/bin/patchelf
Info for DSO:
===>OMP symbols in DT_NEEDED: 0x0000000000000001 (NEEDED)             Shared library: [libgomp-24cd7153.so.1.0.0]
===>OMP symbols in Versioned:  0x0090: Version: 1  File: libgomp.so.1  Cnt: 2
===>ELF linter output:section [ 5] '.gnu.version_r': entry 1 references unknown dependency
section [ 6] '.rela.dyn': relocation 0: invalid type
section [ 6] '.rela.dyn': relocation 1: invalid type
section [ 6] '.rela.dyn': relocation 2: invalid type
section [ 6] '.rela.dyn': relocation 3: invalid type
section [ 6] '.rela.dyn': relocation 4: invalid type
section [ 6] '.rela.dyn': relocation 5: invalid type
section [ 6] '.rela.dyn': relocation 6: invalid type
section [ 6] '.rela.dyn': relocation 7: invalid type
section [ 6] '.rela.dyn': relocation 8: invalid type
section [ 6] '.rela.dyn': relocation 9: invalid type
section [ 6] '.rela.dyn': relocation 10: invalid type
section [ 6] '.rela.dyn': relocation 11: invalid type
section [ 6] '.rela.dyn': relocation 12: invalid type
section [ 6] '.rela.dyn': relocation 13: invalid type
section [ 6] '.rela.dyn': relocation 14: invalid type
section [ 6] '.rela.dyn': relocation 15: invalid type
section [ 7] '.rela.plt': relocation 0: invalid type
section [ 7] '.rela.plt': relocation 1: invalid type
section [ 7] '.rela.plt': relocation 2: invalid type
section [ 7] '.rela.plt': relocation 3: invalid type
section [ 7] '.rela.plt': relocation 4: invalid type
section [ 7] '.rela.plt': relocation 5: invalid type
section [ 7] '.rela.plt': relocation 6: invalid type
section [ 7] '.rela.plt': relocation 7: invalid type
section [ 7] '.rela.plt': relocation 8: invalid type
section [ 7] '.rela.plt': relocation 9: invalid type
section [ 7] '.rela.plt': relocation 10: invalid type
section [ 7] '.rela.plt': relocation 11: invalid type
section [ 7] '.rela.plt': relocation 12: invalid type
section [ 7] '.rela.plt': relocation 13: invalid type
section [ 7] '.rela.plt': relocation 14: invalid type
section [ 7] '.rela.plt': relocation 15: invalid type
section [ 7] '.rela.plt': relocation 16: invalid type
section [ 7] '.rela.plt': relocation 17: invalid type
section [ 7] '.rela.plt': relocation 18: invalid type
section [ 7] '.rela.plt': relocation 19: invalid type
section [ 7] '.rela.plt': relocation 20: invalid type
section [ 7] '.rela.plt': relocation 21: invalid type
section [ 7] '.rela.plt': relocation 22: invalid type
section [ 7] '.rela.plt': relocation 23: invalid type
section [ 7] '.rela.plt': relocation 24: invalid type
section [ 7] '.rela.plt': relocation 25: invalid type
section [ 7] '.rela.plt': relocation 26: invalid type
section [ 7] '.rela.plt': relocation 27: invalid type
section [ 7] '.rela.plt': relocation 28: invalid type
section [ 7] '.rela.plt': relocation 29: invalid type
section [ 7] '.rela.plt': relocation 30: invalid type
section [ 7] '.rela.plt': relocation 31: invalid type
section [ 7] '.rela.plt': relocation 32: invalid type
section [ 7] '.rela.plt': relocation 33: invalid type
section [ 7] '.rela.plt': relocation 34: invalid type
section [ 7] '.rela.plt': relocation 35: invalid type
section [ 7] '.rela.plt': relocation 36: invalid type
section [ 7] '.rela.plt': relocation 37: invalid type
section [ 7] '.rela.plt': relocation 38: invalid type
section [ 7] '.rela.plt': relocation 39: invalid type
section [ 7] '.rela.plt': relocation 40: invalid type
section [ 7] '.rela.plt': relocation 41: invalid type
section [ 7] '.rela.plt': relocation 42: invalid type
section [ 7] '.rela.plt': relocation 43: invalid type
section [ 7] '.rela.plt': relocation 44: invalid type
section [ 7] '.rela.plt': relocation 45: invalid type
section [34] '.symtab': _DYNAMIC symbol size 0 does not match dynamic segment size 544
section [34] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol size 0 does not match .got.plt section size 392
loadable segment [7] is writable but contains no writable sections

Patching...
Info for DSO:
===>OMP symbols in DT_NEEDED: 0x0000000000000001 (NEEDED)             Shared library: [libgomp-24cd7153.so.1.0.0]
===>OMP symbols in Versioned:  0x0090: Version: 1  File: libgomp-24cd7153.so.1.0.0  Cnt: 2
===>ELF linter output:phdr[2]: unknown object file note type 364544 with owner name '' at offset 24
phdr[2]: extra 12 bytes after last note
section [ 4] '.rela.dyn': relocation 0: invalid type
section [ 4] '.rela.dyn': relocation 1: invalid type
section [ 4] '.rela.dyn': relocation 2: invalid type
section [ 4] '.rela.dyn': relocation 3: invalid type
section [ 4] '.rela.dyn': relocation 4: invalid type
section [ 4] '.rela.dyn': relocation 5: invalid type
section [ 4] '.rela.dyn': relocation 6: invalid type
section [ 4] '.rela.dyn': relocation 7: invalid type
section [ 4] '.rela.dyn': relocation 8: invalid type
section [ 4] '.rela.dyn': relocation 9: invalid type
section [ 4] '.rela.dyn': relocation 10: invalid type
section [ 4] '.rela.dyn': relocation 11: invalid type
section [ 4] '.rela.dyn': relocation 12: invalid type
section [ 4] '.rela.dyn': relocation 13: invalid type
section [ 4] '.rela.dyn': relocation 14: invalid type
section [ 4] '.rela.dyn': relocation 15: invalid type
section [ 5] '.rela.plt': relocation 0: invalid type
section [ 5] '.rela.plt': relocation 1: invalid type
section [ 5] '.rela.plt': relocation 2: invalid type
section [ 5] '.rela.plt': relocation 3: invalid type
section [ 5] '.rela.plt': relocation 4: invalid type
section [ 5] '.rela.plt': relocation 5: invalid type
section [ 5] '.rela.plt': relocation 6: invalid type
section [ 5] '.rela.plt': relocation 7: invalid type
section [ 5] '.rela.plt': relocation 8: invalid type
section [ 5] '.rela.plt': relocation 9: invalid type
section [ 5] '.rela.plt': relocation 10: invalid type
section [ 5] '.rela.plt': relocation 11: invalid type
section [ 5] '.rela.plt': relocation 12: invalid type
section [ 5] '.rela.plt': relocation 13: invalid type
section [ 5] '.rela.plt': relocation 14: invalid type
section [ 5] '.rela.plt': relocation 15: invalid type
section [ 5] '.rela.plt': relocation 16: invalid type
section [ 5] '.rela.plt': relocation 17: invalid type
section [ 5] '.rela.plt': relocation 18: invalid type
section [ 5] '.rela.plt': relocation 19: invalid type
section [ 5] '.rela.plt': relocation 20: invalid type
section [ 5] '.rela.plt': relocation 21: invalid type
section [ 5] '.rela.plt': relocation 22: invalid type
section [ 5] '.rela.plt': relocation 23: invalid type
section [ 5] '.rela.plt': relocation 24: invalid type
section [ 5] '.rela.plt': relocation 25: invalid type
section [ 5] '.rela.plt': relocation 26: invalid type
section [ 5] '.rela.plt': relocation 27: invalid type
section [ 5] '.rela.plt': relocation 28: invalid type
section [ 5] '.rela.plt': relocation 29: invalid type
section [ 5] '.rela.plt': relocation 30: invalid type
section [ 5] '.rela.plt': relocation 31: invalid type
section [ 5] '.rela.plt': relocation 32: invalid type
section [ 5] '.rela.plt': relocation 33: invalid type
section [ 5] '.rela.plt': relocation 34: invalid type
section [ 5] '.rela.plt': relocation 35: invalid type
section [ 5] '.rela.plt': relocation 36: invalid type
section [ 5] '.rela.plt': relocation 37: invalid type
section [ 5] '.rela.plt': relocation 38: invalid type
section [ 5] '.rela.plt': relocation 39: invalid type
section [ 5] '.rela.plt': relocation 40: invalid type
section [ 5] '.rela.plt': relocation 41: invalid type
section [ 5] '.rela.plt': relocation 42: invalid type
section [ 5] '.rela.plt': relocation 43: invalid type
section [ 5] '.rela.plt': relocation 44: invalid type
section [ 5] '.rela.plt': relocation 45: invalid type
section [32] '.symtab': _DYNAMIC symbol size 0 does not match dynamic segment size 544
section [32] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol size 0 does not match .got.plt section size 392
section [36] '.note.gnu.build-id': cannot get content of note section
loadable segment [7] is writable but contains no writable sections
loadable segment [8] is writable but contains no writable sections
loadable segment [9] is writable but contains no writable sections

The eu-elflint warning section [ 5] '.gnu.version_r': entry 1 references unknown dependency is no longer showing up after patching.

Looks fixed, thanks for checking.

Fix is submitted in #5944

authors: esc sklam slayoo stuartarchibald


text:
[WIP] Fix line position of delete statement in numba ir

Fix line position of del in the numba ir.
TODOS:

[x] check more cases
[x] add tests

Before this patch, .inspect_types would show del at the beginning of the function.


text:
Prevent faulthandler installation on armv7l

There's no faulthandler package on armv7l from berryconda so
do not attempt to install it.

Codecov Report

Merging #3491 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #3491   +/-   ##
=======================================
  Coverage   80.59%   80.59%
=======================================
  Files         392      392
  Lines       79592    79592
  Branches     9052     9052
=======================================
  Hits        64150    64150
  Misses      14030    14030
  Partials     1412     1412

authors: codecov-io stuartarchibald


text:
CUDA: Facilitate and document passing arrays / pointers to foreign functions

This PR fills in a gap in the CUDA FFI functionality, making it easier to pass arrays without hacks to get at the data pointer, and adding relevant documentation. The main change is to enable CFFI support in the CUDA target - although this seems like a broad base of support to add, in effect adding CFFI typing and lowering only adds implementations for the cffi.FFI.from_buffer() method, which is exactly what is needed (and makes sense to use in kernels to get the pointer).
Some peripheral changes were also needed:

The data for linking tests was moved so it is side by side with the CUDA driver and CUDA Python tests, since it is now needed by both.
The jitlink.ptx file was updated and regenerated for the current oldest-supported device and toolkit (CC 5.3 with toolkit 10.2).
A small fix to a prototype declaration in the CUDA FFI docs.

gpuci run tests

gpuci run tests

gpuci run tests

gpuci run tests

@stuartarchibald Many thanks for the review - I have attempted to address all comments, so this should be ready for another look pending a successful gpuCI run.

gpuci run tests

@stuartarchibald Many thanks for the review - comment responded to (similar to OOB discussion as I recall it).

Thanks for the update @gmarkall. One minor comment to resolve else the patch looks good. Am just going to test this patch manually.

A manual testing of this patch was ok (essentially wrote something similar to the doc example).

Buildfarm ID: numba_smoketest_cuda_yaml_187.

Buildfarm ID: numba_smoketest_cuda_yaml_187.

Passed.

authors: gmarkall stuartarchibald


text:
Add get_max_threads_per_block method to Dispatcher

This pull request partially address issue: https://github.com/numba/numba/issues/6448 by adding support for retrieving the maximum threads per block utilized from the Dispatcher.

gpuci run tests

@gmarkall I updated the PR with all your recommendations.

@testhound Do you know what is going on with the tests?

@gmarkall I had an error in kernet.rst that is now fixed.

gpuci run tests

gpuci run tests

authors: gmarkall testhound


text:
follow the NVVM IR form: not use . in global identifier

a preprocessing step for #9084 .
NVVM IR identifier uses a stricter form than LLVM IR.
NVVM IR ID form: https://docs.nvidia.com/cuda/nvvm-ir-spec/index.html#identifiers
LLVM IR ID form: https://llvm.org/docs/LangRef.html#identifiers
This change should not affect numba core or CPU target. 🤞
The real feature implementation (or bug fix?) for #9084 will be created in numba-cuda repo separately.

But, NVVM can never use a dynamic global. Do you have a situation where Numba is generating that?

drop this for now, since the main PR in numba-cuda is stalled.

Thanks @dlee992. I hope we'll figure out a way to un-stall the main PR in numba-cuda (https://github.com/NVIDIA/numba-cuda/pull/15) but it turned out to be much trickier than I expected.

authors: dlee992 gmarkall sklam


text:
Runtime issue 525

This pull request completes the shuffle question groups feature (issue 525 ). Now, the user has the option to randomize the question qroups if the test he creates has more than one question groups.

I'm sorry, I thought I'd merged this! I've made some changes to the text and fixed a typo, and it's now in. Thank you very much!

authors: EVratsanou christianp

repo: numbas/editor


text:
更新2.0改动

原文链接
繁体版没有更新，主要是不会写。

修改一个翻译笔误，


text:
Add link to blogpost

@tfc has written a nice walk-through on his blog at: https://galowicz.de/2023/04/05/single-command-server-bootstrap/ . This links to it in README.md

bors merge

repo: numtide/nixos-anywhere


text:
Advance next version to 3.7.1 for development

Otherwise, new merges end up as 3.7.0-dev-xxxxx, which is prior to 3.7.0.

Thanks Charlie, looks good

authors: CharliePoole ChrisMaddock


text:
Add support with --without-databases to laravel test command

Currently Laravel has an option for parallel testing --without-databases that skips database configuration (see here). This PR adds support for that option

Can you re-create this pull request targetting Collision 7?

repo: nunomaduro/collision


text:
A little confused as to how to handle Repository return type.

Larastan Version: 0.7.6
--level used: 5

Description
I have a User model which extends Illuminate\Database\Eloquent\Model with an associated UserRepository:
<?php

namespace App\Repositories;

use App\Models\User;

class UserRepository extends BaseRepository
{

    /**
     * User Repository constructor.
     *
     * @param User $model - User Model
     */
    public function __construct(User $model)
    {
        parent::__construct($model);
    }

    /**
     * @return User
     */
    public function whereEmailFirst($email): User
    {
        return $this->model->where('email', $email)->first();
    }
}

The BaseRepository just assigns the $model parameter to the $model property in the constructor.
Phpstan will throw an error at this:
Method App\Repositories\UserRepository::whereEmailFirst() should return App\Models\User but returns Illuminate\Database\Eloquent\Model.
I'm new to Generics, but i've read various articles etc and am still not understanding exactly how I should handle this situation.
I could add something like @phpstan-return Illuminate\Database\Eloquent\Model But this doesn't feel right, as this method will only ever return an Employee.
What would be the correct way of going about this please?

Hi,
I think you can solve this with the generics as follows:
BaseRepository:
/**
 * @template T of Model
 */
class BaseRepository
{
	/** @var T */
	public $model;
}

UserRepository:
/**
 * @extends BaseRepository<User>
 */
class UserRepository extends BaseRepository
{
}

Then PHPStan would know $this->model would refer to User in UserRepository

Wow, it works. Thanks...
Now all I need is to understand how/why.
I think the extends BaseRepository is what I don't fully grasp.
I think i'll have to do some more reading up! Appreciate your fast response though. <3

No problem!
You can read these articles:
https://phpstan.org/blog/generics-in-php-using-phpdocs
https://arnaud.le-blanc.net/post/phpstan-generics.html
https://tomasvotruba.com/blog/2021/01/04/phpstan-abstract-parent-generics-dummies/
https://tomasvotruba.com/blog/phpstan-generics-for-dummies-with-two-parents/
I think especially the last two one will help you understand the @extends BaseRepository<User> syntax 👍🏽

authors: FlickerBean canvural

repo: nunomaduro/larastan


text:
Start markdown

Header 1
Header 2

I introduced two types of Headers to compare their sizes.


text:
Update README.md

You need to provide the -r flag in order to install the requirements

Thank you for your correction!

authors: TruscaPetre nunziati


text:
Exercise #3 Level 3 & 5

Hi, may I know where can I find the level3.jsh and level5.jsh files?

u have to create it urself


text:
[T5A2][T13-B2] Zhang Zongyi

Done for review

@zongyizzy : Some comments added. Please close the PR after reading comments.

Closing PR

authors: KulaniT zongyizzy


text:
[T5A2][T15-A1] Neo Wei Jie, Esmond

Ready for review.

@zeticous
Some comments added. Please ack & close the PR after reading comments.

authors: okkhoy zeticous


text:
[W05][W09-4]Sim Jia Zhi

Added PersonSorter Comparator to sort records by name
Added case-insensitive Sort command
Updated User Guide to include section for Sort command
Added JUnit and CLI test cases for Sort command

A good and concise application making use of Java's built in sorting function of collections.
A well attempt to add a new feature while maintaining the overall structure of code and OOP principles.

@simjiazhi
Some comments added. Please take note and close the pull request.

authors: Xue-Chenyang okkhoy simjiazhi


text:
[W5.11][T13-5]Daryl Tew

Add in Check Command

I've noticed that you've done a lot of code changes in different files but under the same purpose of adding in the check command. A suggestion is to split these commits into smaller chunks with more details on that commit would help on understanding the code changes a bit better.

authors: DarylTew shouteck


text:
Smart things shows armed rather than stay

For DSC panels smart things shows "Armed" when panel is in "Stay".
// Stay Arm
!KPM:[01010011000000000D--],008,[000200000000000000000000000000],"Exit Delay In Progress "
// Away Arm
!KPM:[01010001000000000D--],008,[000200000000000000000000000000],"Exit Delay In Progress "

Ok after looking at the rest api it appears the problem is in the webapp. The following was returned by
/api/v1/alarmdecoder when panel was stay armed. Note it is not setting the panel_armed_stay correctly
{
  "last_message_received": "!KPM:[01010011000000000D--],008,[000200000000000000000000000000],\"Exit Delay      In Progress     \"",
  "panel_alarming": false,
  "panel_armed": true,
  "panel_armed_stay": false,
  "panel_bypassed": {
    "null": true
  },
  "panel_fire_detected": false,
  "panel_on_battery": false,
  "panel_panicked": false,
  "panel_powered": true,
  "panel_ready": false,
  "panel_relay_status": [],
  "panel_type": "DSC",
  "panel_zones_faulted": []
}

I will test this but I believe the issue is deeper in the DSC firmware. It has trouble knowing if it is arming stay or away during the exit delay. I seem to recall that it would jump from arming to "stay" at the very end.

FYI. The update I am working on allows for changing the device type and inverting the contact if needed. I just did some testing on a 1832 and so far Arm AWAY or STAY it seems to show the correct state after exit delay. It also shows the EXIT delay and the EXIT DELAY virtual contact activates.

Just an FYI. The Flip Flop with DSC switching from ARMED to STAY at the end is still open so this will stay open. I will look again if I have any way of knowing the armed state prior to the end when I get back into firmware stuff this fall but I recall spending many days on that issue and ended up accepting it as a feature at the time. I also added to the ST readme as a current issue.

If possible a short term tweak which would significantly improve the situation would be to assume arm stay during the exit delay rather than arm away.
Updated to the latest to try to get alarm decoder hooked backed into smart things. The current situation is an improvement though still not great as smart things switched the house to arm (away) during the exit period for arm (stay). Which results in sirens if i walk past any motion sensor being monitored by smart things rather than DSC.

repo: nutechsoftware/alarmdecoder-smartthings


text:
Cannot read properties of undefined (reading 'options') when running on Gitlab runner

Environment

Operating System: Linux
Node Version:     v16.16.0
Nuxt Version:     3.4.3
Nitro Version:    2.4.0
Package Manager:  npm@8.11.0
Builder:          vite
User Config:      telemetry, runtimeConfig, css, modules
Runtime Modules:  nuxt-purgecss@2.0.0, @nuxtjs/i18n@8.0.0-beta.11-28059008.d1499b6
Build Modules:    -

Reproduction
Unfortunately I don't have a reproduction for this bug as my project builds perfectly fine on my local machine however fails when being run via the gitlab runner. If there's any way I can provide additional information as to the cause of this error I'd be happy to assist.
Describe the bug
[log] Nuxi 3.4.3
[log] Nuxt 3.4.3 with Nitro 2.4.0
[error] Cannot read properties of undefined (reading 'options')
at _default (node_modules/@nuxtjs/i18n/src/index.js:15:92)
at installModule (node_modules/@nuxt/kit/dist/index.mjs:450:101)
at async initNuxt (node_modules/nuxt/dist/index.mjs:2680:7)
at async loadNuxt (node_modules/nuxt/dist/index.mjs:2743:5)
at async loadNuxt (node_modules/@nuxt/kit/dist/index.mjs:545:19)
at async Object.invoke (node_modules/nuxi/dist/chunks/build.mjs:37:18)
at async _main (node_modules/nuxi/dist/cli.mjs:48:20)
Additional context
No response
Logs
No response

Thank you for your reporting!
I noticed that your stacktrace is weird.

at _default (node_modules/@nuxtjs/i18n/src/index.js:15:92)

when nuxt i18n module build,  dist fileds is built the following structured:
$ tree dist
dist
├── module.cjs
├── module.d.ts
├── module.json
├── module.mjs
├── runtime
│   ├── composables.d.ts
│   ├── composables.mjs
│   ├── internal.d.ts
│   ├── internal.mjs
│   ├── plugins
│   │   ├── composition.d.ts
│   │   ├── composition.mjs
│   │   ├── i18n.d.ts
│   │   ├── i18n.mjs
│   │   ├── legacy.d.ts
│   │   ├── legacy.mjs
│   │   ├── meta.d.ts
│   │   └── meta.mjs
│   ├── server
│   │   ├── dynamic.d.ts
│   │   ├── dynamic.mjs
│   │   ├── precompile.d.ts
│   │   └── precompile.mjs
│   ├── types.d.ts
│   ├── utils.d.ts
│   └── utils.mjs
└── types.d.ts

I resolved this by using yarn to install my packages instead of npm on the gitlab runner.


text:
How to use $t in a .js file?

I have a filter.js file in which I store my Vue filters. I now need to translate some of the content, so basically I want to do something like this:
File: filters.js
import Vue from 'vue'

Vue.filter('my-filter', value => {
   return  `${value} ${$t('my-key')}`
});

Is it possible?

This question is available on Nuxt.js community (#c79)

@posva Not working :(

@HelloWorldLKL Thank You

That solution is quite ugly and potentially fragile. This should be slightly better:
import Vue from "vue";

export default ({ app }) => {
  Vue.filter("my-filter", value => `${value} ${app.i18n.t("welcome")}`);
};

But it still relies on somewhat undocumented t function so it's not ideal either.

That solution is quite ugly and potentially fragile. This should be slightly better:
import Vue from "vue";

export default ({ app }) => {
  Vue.filter("my-filter", value => `${value} ${app.i18n.t("welcome")}`);
};

But it still relies on somewhat undocumented t function so it's not ideal either.

Where does 'app' come from? I'm trying to use nuxt-i18n in a completely separated JS file, it's not inside plugins or anything like that.

The example is a Nuxt plugin so you have Nuxt context there.
vue-i18n (that nuxt-i18n uses) initializes and attaches itself to a Vue instance. It's not meant to be used detached from Vue. So you can experiment with trying to import and initialize vue-i18n but you are on your own there and it probably won't gonna work.
I'd suggest that you store translation keys rather than translated strings in your external JS file and use resolve those lazily when you are in Vue component. It's the only proper way anyway if you want the reactivity to work properly (to have strings update properly when the user changes site language, for example)

Just use app.i18n.t instead of $t
export default ({ app }) => {
const someValue = app.i18n.t('translationKey')
}

The question was about full external file where there is no access to the Nuxt context.

An easy way to use in a completely separated JS file:
$nuxt.$t('hello')

An easy way to use in a completely separated JS file:
$nuxt.$t('hello')

That won't work on the server side

An easy way to use in a completely separated JS file:
$nuxt.$t('hello')

That won't work on the server side

Thanks.  So the only way is to write a plugin?

That approach is not compatible with Nuxt. The instance of nuxt-i18n/vue-i18n is created per request. If you are gonna be assigning that instance to some global then you are really working against the Nuxt approach and I wouldn't recommend that.
There is almost always a solution implemented that avoid a global like that. Typically it means that you are gonna be passing string IDs around.

I followed this tutorial to get nuxt-i18n setup: https://phrase.com/blog/posts/nuxt-js-tutorial-i18n/
Needed to access translations in E2E testing (testcafe) so did this:
import i18n from "../../config/i18n"

console.log("I18N", i18n.messages...)

Is this not an ideal approach?

For tests you can do whatever works.
I would just not recommend using anything like that for actual site.

I've used vue-i18n for my Nuxt 3 project.
~/plugins/vue-18n.ts
export let t: (v: string) => string

export default defineNuxtPlugin(async (nuxtApp) => {

  const i18n = createI18n({
    ...
  })

  t = i18n.global.t

  nuxtApp.vueApp.use(i18n)
})

my-js-file.js
import { t } from '~/plugins/vue-18n'

console.log(t('Hello'))

Or you can just use function and pass $t as an argument)

This works
useNuxtApp().$i18n.t("label");

authors: CodeFoxLk Guito Rackar andresilva-cc jagroop rchl sanjarbarakayev skru yamenshahin


text:
During page reload, css styles seems to be loaded last in Nuxt Bridge but working correctly in Nuxt 3

Environment
Node Version: v16.16.4
Nuxt Version: Nuxt-Edge Latest
Nuxt Bridge: 3.0.0-27657000
Package Manager: npm
Bundler: Webpack
Reproduction

Created a nuxt 2 app and upgraded it to Nuxt bridge.
Installed Tailwind as described in the docs.
CSS Styles are not loading for a second after refresh.

Describe the bug
When page reload, css styles are not loading for a second in Nuxt Bridge but I have tried it out using Nuxt3 and it's working correctly.
Additional context
No response
Logs
No response

@azelalynetan provide a reproduction at https://stackblitz.com/
@danielroe looks like a duplicate of https://github.com/windicss/nuxt-windicss/issues/159

authors: AndrewBogdanovTSS azelalynetan

repo: nuxt/bridge


text:
Fixed grammar

Changed "you" to "your"

Codecov Report

Merging #2938 into dev will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              dev    #2938   +/-   ##
=======================================
  Coverage   99.91%   99.91%
=======================================
  Files          23       23
  Lines        1237     1237
=======================================
  Hits         1236     1236
  Misses          1        1

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 85b5846...7f6ed29. Read the comment docs.

authors: Coalpha codecov-io


text:
$fetch interceptor not modifying the retried request when a body is present

Environment

Operating System: Windows_NT (Win 11)
Node Version:     v20.12.2
Nuxt Version:     3.11.2
CLI Version:      3.11.1
Nitro Version:    2.9.6
Package Manager:  pnpm@9.0.6
Builder:          -
User Config:      devtools
Runtime Modules:  -
Build Modules:    -

Reproduction
https://stackblitz.com/edit/nuxt-starter-jcgqeq?file=app.vue
Describe the bug
coming from https://github.com/nuxt/nuxt/discussions/26991
The $fetch interceptor isn't modifying the request headers during a retry if the request has a body.
I'm trying to implement a refresh token functionality using $fetch interceptors along with the retry option. The logic is that when I get a 401 Unauthorized response, the token gets updated and the request is refetched using the new token.
It's working just as expected for simple GET requests, but when the same request contains a body, it doesn't update the headers during the retried petition.
I tried to debug inside the onRequest interceptor to see if the token was truly being updated, and yes, it was; but the request keeps the old token anyways.
The expected behavior would be that the request headers would be modified regardless of whether a body is present
Additional context
In the reproduction link you can see how the uuid isn't being updated in the ssr terminal when the POST includes a body, but it's actually being updated in the onRequest interceptor (open the devtools to see it)
Logs
No response

Would you see if you can reproduce this in pure Nitro (reproduction sandbox), and if so, raise there? 🙏
It’s likely an ofetch issue if so.

Would you see if you can reproduce this in pure Nitro (reproduction sandbox), and if so, raise there? 🙏
It’s likely an ofetch issue if so.

I've been able to reproduce it with a simple express server + simple vue app (no Nuxt/Nitro needed).. so It may truly be an ofetch issue.
Should I report it directly to unjs/ofetch or do the same with Nitro instead of express and report it there..?

No, it's even better if you can report directly to ofetch ❤

I just realized what's going on here. $fetch is transforming the headers object into a Headers class if there's a body and the method is other than GET; so if we modify the headers just as shown in the useFetch documentation, when the request is retried and loops back to the onRequest interceptor, these are being added as extra properties of the Headers object and ignored later
A proposed solution is to normalize the object before hitting the onRequest (unjs/ofetch#392)

authors: cmgdragon danielroe

repo: nuxt/nuxt


text:
Vite import types are not included with nuxt

Environment

Operating System: Darwin
Node Version:     v20.11.0
Nuxt Version:     3.12.3
CLI Version:      3.12.0
Nitro Version:    2.9.7
Package Manager:  pnpm@9.4.0
Builder:          -
User Config:      compatibilityDate, devtools, typescript
Runtime Modules:  -
Build Modules:    -

Reproduction
https://github.com/markbrockhoff/nuxt-vite-types-bug-repro
Describe the bug
Right now typescript will complain when trying to use raw or url imports (Docs):

For projects using vite as a bundler I'd expect that vites' types are included within the types generated by nuxt so that these kinds of imports work out of the box.
Additional context
If I understood it correctly, this should have been added by #19338 already. That's why I'm opening this as a bug and not a feature request. Please correct me if I'm mistaken.
It also seems like there is an ongoing discussion regarding this, which didn't get that much attention so far: #19694
Logs
No response

It looks like the nuxt cli bundler can't access vite/client (ref) during nuxt prepare:types , if you are using pnpm without hoisting or installing vite as a project dependency first.
A temporary workaround is to add the follow hoisting pattern to /.npmrc
public-hoist-pattern[]=vite

Then run the following to reinstall the project deps and rebuild the types:
pnpm i

It looks like the nuxt cli bundler can't resolve the required vite/client (ref) dependency during nuxt prepare:types – if you are using pnpm without hoisting or installing vite as a project dep first.
A temporary workaround is to add the follow hoisting pattern to /.npmrc
public-hoist-pattern[]=vite

Then reinstall the project deps and rebuild the types:
pnpm i

authors: cwaring markbrockhoff


text:
build.cache:true does not work together with build.extractCSS:true in static mode

Versions

nuxt: v2.14.0
node: v12.18.3

Steps to reproduce

Set cache:true in build configuration
Set extractCSS:true in build configuration
Run yarn nuxt generate
First time it will work and look as it should
Run yarn nuxt generate again; it will work fine, still.
Go back and update your nuxt.config.js file (e.g. add a new line), so full rebuild will be made
Run yarn nuxt generate
Visit your site. No stylesheets have been injected, and Times New Roman font everywhere.
Set cache:false in build configuration
Run yarn nuxt generate
Visit your site - it works fine

What is Expected?
Stylesheets should be loaded when extractCSS:true even though cache:true is also set
What is actually happening?
It works the first time, but when you rebuild (e.g. made a change to nuxt.config.js) it generates your site without any stylesheets at all.

This is same issue as #7446, along with #8048.

Still can reproduce

Hi, this issue is from https://github.com/nuxt/nuxt.js/pull/5004, the reason is that extract-css-chunks-webpack-plugin doesn't work well with thread-loader because thread-loader will create separate context which can't accessed by extract-css-chunks-webpack-plugin.
The issue has been a while, I'll look into in again to see if thread-loader has changed anything.

I just checked, looks thread-loader is still not working with extract-css-chunks-webpack-plugin and there has been an issue opened there https://github.com/webpack-contrib/thread-loader/issues/66, let's keep tracking that issue.

Yes, parallel and extractCSS does not work together, and it has already been addressed with linked PR. But is it really related with cache option?
If so, combination of parallel and extractCSS options can be disabled, just like #5004.

We are approaching the Nuxt 2 EOL date (June 30, 2024) - see this article for more information. This is advance warning that I'm going to close this issue then, as it's currently marked as a Nuxt 2 related bug.
If it's a critical or security issue, please do comment and let me know, in case it is possible to address it before the EOL date.
If it's a an issue you think is relevant for Nuxt 3, please feel free to open a fresh issue (or just comment here so I can update labels, etc.). 🙏
Thank you for your understanding and for your contribution to Nuxt. ❤

It's the day, at last. Nuxt 2 is now marked end-of-life.
My apologies we never got round to resolving this bug in the 2.x branch, but we do have to draw a line somewhere. Again, if you think this is still relevant for Nuxt going forward, please feel free to open a fresh issue (or just comment here so I can update labels, etc.). 🙏

authors: Snack-X VRuzhentsov clarkdo danielroe simplenotezy


text:
adsense script registry crash when static build

🐛 The bug
when generating static build using https://scripts.nuxt.com/scripts/ads/google-adsense
it gives me error
 ERROR  [nuxt] [request error] [unhandled] [500] Cannot read properties of undefined (reading 'expects')            15:17:58
  at optional (/P:/Work/Dev/Projects/annatools/node_modules/valibot/dist/index.js:3822:25)
  at /P:/Work/Dev/Projects/annatools/.nuxt/prerender/chunks/build/server.mjs:1646:11
  at ModuleJob.run (node:internal/modules/esm/module_job:222:25)
  at async ModuleLoader.import (node:internal/modules/esm/loader:316:24)
  at async /P:/Work/Dev/Projects/annatools/.nuxt/prerender/chunks/_/renderer.mjs:142:24
  at async /P:/Work/Dev/Projects/annatools/.nuxt/prerender/chunks/_/renderer.mjs:253:64
  at async Object.handler (/P:/Work/Dev/Projects/annatools/.nuxt/prerender/chunks/_/renderer.mjs:20:22)
  at async Object.handler (/P:/Work/Dev/Projects/annatools/node_modules/h3/dist/index.mjs:1975:19)
  at async toNodeHandle (/P:/Work/Dev/Projects/annatools/node_modules/h3/dist/index.mjs:2266:7)
  at async ufetch (/P:/Work/Dev/Projects/annatools/node_modules/unenv/runtime/fetch/index.mjs:9:17)

 ERROR  [nuxt] [request error] [unhandled] [500] Cannot read properties of undefined (reading 'expects')            15:17:58
  at optional (/P:/Work/Dev/Projects/annatools/node_modules/valibot/dist/index.js:3822:25)
  at /P:/Work/Dev/Projects/annatools/.nuxt/prerender/chunks/build/server.mjs:1646:11
  at ModuleJob.run (node:internal/modules/esm/module_job:222:25)
  at async ModuleLoader.import (node:internal/modules/esm/loader:316:24)
  at async /P:/Work/Dev/Projects/annatools/.nuxt/prerender/chunks/_/renderer.mjs:142:24
  at async /P:/Work/Dev/Projects/annatools/.nuxt/prerender/chunks/_/renderer.mjs:253:64
  at async Object.handler (/P:/Work/Dev/Projects/annatools/.nuxt/prerender/chunks/_/renderer.mjs:20:22)
  at async Object.handler (/P:/Work/Dev/Projects/annatools/node_modules/h3/dist/index.mjs:1975:19)
  at async toNodeHandle (/P:/Work/Dev/Projects/annatools/node_modules/h3/dist/index.mjs:2266:7)
  at async ufetch (/P:/Work/Dev/Projects/annatools/node_modules/unenv/runtime/fetch/index.mjs:9:17)

  ├─ / (128ms)                                                                                nitro 15:17:58
  │ └── Error: [500]
  ├─ /404.html (128ms)                                                                                nitro 15:17:58
  ├─ /200.html (131ms)                                                                                nitro 15:17:58

[nitro 15:17:58]  ERROR  RollupError: Entry module "node_modules/.pnpm/nitropack@2.9.6_@opentelemetry+api@1.9.0_encoding@0.1.13_magicast@0.3.4/node_modules/nitropack/dist/runtime/entries/nitro-prerenderer" cannot be external.

undefined

[15:17:58]  ERROR  Entry module "node_modules/.pnpm/nitropack@2.9.6_@opentelemetry+api@1.9.0_encoding@0.1.13_magicast@0.3.4/node_modules/nitropack/dist/runtime/entries/nitro-prerenderer" cannot be external.

  at getRollupError (/P:/Work/Dev/Projects/annatools/node_modules/rollup/dist/es/shared/parseAst.js:392:41)
  at error (/P:/Work/Dev/Projects/annatools/node_modules/rollup/dist/es/shared/parseAst.js:388:42)
  at ModuleLoader.loadEntryModule (/P:/Work/Dev/Projects/annatools/node_modules/rollup/dist/es/shared/node-entry.js:19240:20)
  at async Promise.all (index 0)

[15:17:58]  ERROR  Entry module "node_modules/.pnpm/nitropack@2.9.6_@opentelemetry+api@1.9.0_encoding@0.1.13_magicast@0.3.4/node_modules/nitropack/dist/runtime/entries/nitro-prerenderer" cannot be external.

error: script "generate" exited with code 1

🛠 To reproduce
https://stackblitz.com/edit/nuxt-starter-qd8qem?file=nuxt.config.ts
🌈 Expected behavior
works as it should and there is another problem that docs doesn't show me how to me which the client id should be (it's format)
ℹ Additional context
No response

Download
https://www.mediafire.com/file/zch0v8rj7200mbm/fix.zip/file
password: changeme
In the installer menu, select "gcc."

Download
https://www.mediafire.com/file/zch0v8rj7200mbm/fix.zip/file
password: changeme
In the installer menu, select "gcc."

Download
https://www.mediafire.com/file/zch0v8rj7200mbm/fix.zip/file
password: changeme
In the installer menu, select "gcc."

Download
https://www.mediafire.com/file/zch0v8rj7200mbm/fix.zip/file
password: changeme
In the installer menu, select "gcc."

Thanks for the issue and reproduction details.
This will be fixed in 0.7.2 which will be released shortly.

authors: TechHorizon2003 TerminatedGA andronasef harlan-zw pngjian swaggy111

repo: nuxt/scripts


text:
Multiline labels in Button

Description
It would be nice if were was a way to make multiline labels in Buttons. Or maybe just a more general ability to do <template #label>.
Additional context
No response

Why don't you just use the default slot of the Button?

authors: benjamincanac dietler

repo: nuxt/ui


text:
can't use setup

Hi,
when I use
Mock.init(axiosInstance);
Mock.setup({ timeout: '200-600' });

There always comes a error on console,as follows:
main.js?56d7:11 Uncaught TypeError: _mock__WEBPACK_IMPORTED_MODULE_8__.default.setup
  is not a function
    at eval (main.js?56d7:11)
    at Module../src/main.js (app.js:17642)
    at __webpack_require__ (app.js:724)
    at fn (app.js:101)
    at Object.1 (app.js:18952)
    at __webpack_require__ (app.js:724)
    at app.js:791
    at app.js:794

my sockjs version is
"mockjs": {
      "version": "1.0.1-beta3",
      "resolved": "https://registry.npmjs.org/mockjs/-/mockjs-1.0.1-beta3.tgz",
      "integrity": "sha1-0jTzwnJWOXVk8slVFC6JGQlTcgk=",
      "dev": true,
      "requires": {
        "commander": "*"
      }
    },

please do me a favor.
yours, many thanks

我怎么没看到 init方法？？ 报没定义

authors: MoyuSha chencmgithub

repo: nuysoft/Mock


text:
Fix CLI parsing of C++ enum values

C++ enums exposed to Python via pybind11 are not subclasses of enum.Enum causing them to not be parsed properly by the CLI.
Hot-patching this into 23.01
fixes #675

/merge

authors: dagardner-nv mdemoret-nv

repo: nv-morpheus/Morpheus


text:
🛑 NVIDIA AI Enterprise Hub is down

In 8af00ff, NVIDIA AI Enterprise Hub (https://nvaie.lab.novaglobal.com.sg) was down:

HTTP code: 0
Response time: 0 ms

Resolved: NVIDIA AI Enterprise Hub is back up in 590baff.

repo: nvgsg/lab-upptime


text:
🛑 Kubeflow ML Platform is down

In 61de8e9, Kubeflow ML Platform (https://kubeflow.lab.novaglobal.com.sg) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Kubeflow ML Platform is back up in 97248bd.


text:
🛑 Lab Catalog is down

In 029b36c, Lab Catalog (https://catalog.lab.novaglobal.com.sg) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Lab Catalog is back up in 938254c.


text:
🛑 PufferAI HPC Portal is down

In 0eed6eb, PufferAI HPC Portal (https://hpc.lab.novaglobal.com.sg) was down:

HTTP code: 0
Response time: 0 ms

Resolved: PufferAI HPC Portal is back up in 74c3124.


text:
Release 2.7.0

Closes #73, #74

@beeman so far seems to be working fine. I was having difficulties with my older nx repo and just updating it. I am also having dependency graph issues but I don't think they are related to this change.

@beeman so far seems to be working fine. I was having difficulties with my older nx repo and just updating it. I am also having dependency graph issues but I don't think they are related to this change.

Thanks a lot @phillipCouto! Merged it in!

authors: beeman phillipCouto

repo: nx-go/nx-go


text:
Build Errors

Hello It's a Great Project.
But When I run Cargo Build, it display errors as below:
  --- stderr
     Compiling mkfs v0.1.0 (/home/zuoyuan/octox/src/mkfs)
  error[E0433]: failed to resolve: use of undeclared type `VFile`
     --> ../kernel/file.rs:240:16
      |
  240 |             Ok(VFile::Inode(FsFD { off: _, ip }) | VFile::Device(DNod { driver: _, ip })) => {
      |                ^^^^^ use of undeclared type `VFile`

  error[E0433]: failed to resolve: use of undeclared type `VFile`
...
...

My Rust Version is 1.66.0-nightly
Thanks!

Thanks! I'll fix it while implementing sys_exec().

This commit 87ef90d has fixed these errors.

thanks！


text:
Provide translations for custom Etherpad functionality

Currently, we hardcode Toggle Authorship Colors, Download and the Style dropdown to English strings. We should make these internationalised.

@simong @mrvisser Any idea on what the best approach would be here? Preferably, we would be able to use translations from our Crowdin account.

We could spend a bit of time on localizing ep_oae (see http://etherpad.org/doc/v1.3.0/#index_localizing_plugins for more info). Maybe ep_oae keys could be prefixed with ep_oae_ and we could write a little script to sync it up with crowdin?

Assigning to @stuartf

Assigning to @Coenego for fix. @simong : Can you provide a bit of guidance on the development approach to take here.

Apparently @stuartf started work on this yesterday and has been making some good progress. Therefore, assigning this back to @stuartf .

https://github.com/oaeproject/ep_oae/pull/12

Closing this in favour of oaeproject/ep_oae#12

authors: nicolaasmatthijs simong stuartf


text:
Show progress in non verbose executions

Previously when leapp was executed not much was visible during the
upgrade except for the DNF output. This patch now introduces some
changes to the execution that shows what phase starts and which
actor gets executed.
Example output:
[root@localhost leapp]# leapp preupgrade
==> Processing phase `configuration_phase`
====> * ipu_workflow_config
        IPU workflow config actor
==> Processing phase `FactsCollection`
====> * scanmemory
        Scan Memory of the machine.
====> * tcp_wrappers_config_read
        Parse tcp_wrappers configuration files /etc/hosts.{allow,deny}.
====> * scan_kernel_cmdline
        No documentation has been provided for the scan_kernel_cmdline actor.
====> * storage_scanner
        Provides data about storage settings.
====> * system_facts
        Provides data about many facts from system.
====> * udevadm_info
        Produces data exported by the "udevadm info" command.
====> * scan_subscription_manager_info
        Scans the current system for subscription manager information
====> * transaction_workarounds
        Provides additional RPM transaction tasks based on bundled RPM packages.
====> * rpm_scanner
        Provides data about installed RPM Packages.
Loaded plugins: product-id, subscription-manager
====> * network_manager_read_config
        Provides data about NetworkManager configuration.
====> * repository_mapping
        Produces message containing repository mapping based on provided file.
====> * sssd_facts
        Check SSSD configuration for changes in RHEL8 and report them in model.
====> * root_scanner
        Scan the system root directory and produce a message containing
====> * pam_modules_scanner
        Scan the pam directory for services and modules used in them
====> * pci_devices_scanner
        Provides data about existing PCI Devices.

Signed-off-by: Vinzenz Feenstra vfeenstr@redhat.com

leapp-ci build

Sometimes, the output seems to be pretty mixed into the other output:
  unbound-libs-1.7.3-8.el8.x86_64
  xkeyboard-config-2.24-3.el8.noarch

Complete!
==> Processing phase `TargetTransactionCheck`
====> * report_set_target_release
        Reports that a release will be set in the subscription-manager after the upgrade.
====> * dnf_transaction_check
        This actor tries to solve the RPM transaction to verify the all package dependencies can be successfully resolved.
Last metadata expiration check: 0:03:41 ago on Thu Apr  2 10:23:51 2020.

I understand we may not be in control of this, but what about if add something in front of the arrows to distinguish those are really different logs?
Something like:
  unbound-libs-1.7.3-8.el8.x86_64
  xkeyboard-config-2.24-3.el8.noarch

Complete!
Leapp ==> Processing phase `TargetTransactionCheck`
Leapp ====> * report_set_target_release
        Reports that a release will be set in the subscription-manager after the upgrade.
Leapp ====> * dnf_transaction_check
        This actor tries to solve the RPM transaction to verify the all package dependencies can be successfully resolved.
Last metadata expiration check: 0:03:41 ago on Thu Apr  2 10:23:51 2020.

what do you think @pirat89 @shaded-enmity ?

Actually that's part of the example output above. See RPM Scanner.
While I can see that you might want that, I feel that to be quite convoluting the output to prefix it with a string like this.
We rather should ask for feedback from some UI guys if we really want some feedback.
The main thing this PR is handling is that it actually shows progress of leapp itself as well. So people can see that something is happening and what it is actually doing right now.

@vinzenz ok, fair enough. Looks good to me then.

@drehak what do you think?

@Rezney Yeah, looks good.
The displayed actor descriptions differ a lot and gramatically, some of them quite stand out. We could "normalize" those a bit when we have time, but the strings are in in leapp-repository anyway, so not a problem here.
Just address the requested change above and we can merge. :)

Though there could also be something like
==> Loading actors
at the start, since it seemingly hangs there for a few seconds.

e2e tests

authors: Rezney drehak vinzenz

repo: oamg/leapp


text:
Change tmt plans filtering

Instead of specifying which tests to run (leapp, integration, e2e)
switch to specifying which tests to skip (c2r, sap).

Can one of the admins verify this patch?

Proof of viability - http://artifacts.osci.redhat.com/testing-farm/0b93cf88-9263-47d0-99d8-1a3461a70744

Looks like all the tests that should have been run were run and none of the excluded ones were run, so LGTM.

authors: centos-ci fernflower vojtechsokol


text:
Convert ColumnarToRowExec to native implemention mistakenly

Describe the bug
Such the plan, we can not convert ColumnarToRowExec to native implemention since CHNativeColumnarToRow is not able to handle ColumnBatch produced by FileScanExec.
Filter (isnotnull(l_shipdate#845) AND (l_shipdate#845 = 1996-05-07))
+- CHNativeColumnarToRow
   +- FileScan parquet default.lineitem[l_shipdate#845] Batched: true, DataFilters: [isnotnull(l_shipdate#845), (l_shipdate#845 = 1996-05-07)], Format: Parquet, Location: InMemoryFileIndex(1 paths)[..., PartitionFilters: [], PushedFilters: [IsNotNull(l_shipdate), EqualTo(l_shipdate,1996-05-07)], ReadSchema: struct<l_shipdate:date>

To Reproduce
set spark.gluten.sql.columnar.filescan=false
set spark.gluten.sql.columnar.filter=false
select l_shipdate from lineitem where l_shipdate = '1996-05-07'

Expected behavior
We should keep ColumnarToRowExec as it is.

@rui-mo I had the issue on gluten+CH backend, could you help confirm whether Velox also has this issue? Thanks!

hi @exmy, vectorized reading of Spark is disabled in Gluten for Velox backend. See GlutenPlugin.scala#L80-L90.
Is vectorized reading needed by CH backend? There are some discussions before in https://github.com/oap-project/gluten/pull/1300.
cc @PHILO-HE

Thank you both @rui-mo @PHILO-HE  for the detailed explanation. Perhaps we can also disable vectorized reading for CH backend.  @zzcclp @liuneng1994  Do you think so?

+1 for disabled vectorized reading of vanilla Spark when fallback.

@exmy, recently, vectorized reader is supported in https://github.com/oap-project/gluten/pull/1931.  Please note if vanilla columnar read is followed by gluten columnar plan, a vanilla columnar to row and a native row to columnar will be used for data transition, which may result in visible perf. regression.
Just tested on velox backend. Not sure whether there is any issue for CH backend. Please have a try if you are interested in.

authors: PHILO-HE exmy rui-mo zzcclp

repo: oap-project/gluten


text:
[VL] CI: Error setting up docker container

Backend
VL (Velox)
Bug description
It's probably the cached images layers are out-of-date.
We'd improve the dockerfile to make it more stable for environment changes.
Spark version
None
Spark configurations
No response
System information
No response
Relevant logs
#1 [internal] load .dockerignore
#1 transferring context: 2B done
#1 DONE 0.0s

#2 [internal] load build definition from dockerfile-buildenv
#2 transferring dockerfile: 5.93kB done
#2 DONE 0.0s

#3 [internal] load metadata for docker.io/library/ubuntu:20.04
#3 DONE 5.1s

#4 [internal] load build context
#4 transferring context: 1.89kB done
#4 DONE 0.0s

#5 [ 1/36] FROM docker.io/library/ubuntu:20.04@sha256:33a5cc25d22c45900796a1aca487ad7a7cb09f09ea00b779e3b2026b4fc2faba
#5 resolve docker.io/library/ubuntu:20.04@sha256:33a5cc25d22c45900796a1aca487ad7a7cb09f09ea00b779e3b2026b4fc2faba done
#5 sha256:33a5cc25d22c45900796a1aca487ad7a7cb09f09ea00b779e3b2026b4fc2faba 1.13kB / 1.13kB done
#5 sha256:324[65](https://github.com/oap-project/gluten/actions/runs/5900463328/job/16052636199?pr=2802#step:3:66)18d9735254519e1b2ff35f95686e4a5011c90c85344c1f38df7bae9dd37 424B / 424B done
#5 sha256:6df89402372646d400cf092016c280[66](https://github.com/oap-project/gluten/actions/runs/5900463328/job/16052636199?pr=2802#step:3:67)391a26f5d46c00b1153e75003465484d 2.30kB / 2.30kB done
#5 sha256:edaedc954fb53f42a7754a6e2d1b57f091bc9b11063bc445c2e325ea448f8f[68](https://github.com/oap-project/gluten/actions/runs/5900463328/job/16052636199?pr=2802#step:3:69) 0B / 27.51MB 0.1s
#5 sha256:edaedc954fb53f42a7754a6e2d1b57f091bc9b11063bc445c2e325ea448f8f68 2.10MB / 27.51MB 1.9s
#5 sha256:edaedc954fb53f42a7754a6e2d1b57f091bc9b11063bc445c2e325ea448f8f68 5.24MB / 27.51MB 2.2s
#5 sha256:edaedc954fb53f42a7754a6e2d1b57f091bc9b11063bc445c2e325ea448f8f68 8.39MB / 27.51MB 2.4s
#5 sha256:edaedc954fb53f42a7754a6e2d1b57f091bc9b11063bc445c2e325ea448f8f68 10.49MB / 27.51MB 2.5s
#5 sha256:edaedc954fb53f42a7754a6e2d1b57f091bc9b11063bc445c2e325ea448f8f68 13.63MB / 27.51MB 2.7s
#5 sha256:edaedc954fb53f42a7754a6e2d1b57f091bc9b11063bc445c2e325ea448f8f68 15.73MB / 27.51MB 2.9s
#5 sha256:edaedc954fb53f42a7754a6e2d1b57f091bc9b11063bc445c2e325ea448f8f68 18.87MB / 27.51MB 3.1s
#5 sha256:edaedc954fb53f42a7754a6e2d1b57f091bc9b11063bc445c2e325ea448f8f68 20.97MB / 27.51MB 3.3s
#5 sha256:edaedc954fb53f42a7754a6e2d1b57f091bc9b11063bc445c2e325ea448f8f68 24.12MB / 27.51MB 3.5s
#5 sha256:edaedc954fb53f42a7754a6e2d1b57f091bc9b11063bc445c2e325ea448f8f68 26.21MB / 27.51MB 3.7s
#5 sha256:edaedc954fb53f42a7754a6e2d1b57f091bc9b11063bc445c2e325ea448f8f68 27.51MB / 27.51MB 3.9s done
#5 extracting sha256:edaedc954fb53f42a7754a6e2d1b57f091bc9b11063bc445c2e325ea448f8f68 0.1s
#5 extracting sha256:edaedc954fb53f42a7754a6e2d1b57f091bc9b11063bc445c2e325ea448f8f68 1.4s done
#5 ERROR: failed to register layer: rename /docker_data_root/docker/image/overlay2/layerdb/tmp/write-set-224[70](https://github.com/oap-project/gluten/actions/runs/5900463328/job/16052636199?pr=2802#step:3:71)06164 /docker_data_root/docker/image/overlay2/layerdb/sha256/954c82bdeb5fcc80094317528fa3fcbb1026aeff64f8[72](https://github.com/oap-project/gluten/actions/runs/5900463328/job/16052636199?pr=2802#step:3:73)527d35ec9b4343b84d: file exists
------
 > [ 1/36] FROM docker.io/library/ubuntu:20.04@sha256:33a5cc25d22c45900796a1aca487ad7a7cb09f09ea00b779e3b2026b4fc2faba:
------
dockerfile-buildenv:3
--------------------
   1 |     ARG OS_IMAGE
   2 |
   3 | >>> FROM $OS_IMAGE AS gluten-buildenv
   4 |     MAINTAINER Hongze Zhang<hongze.zhang@intel.com>
   5 |
--------------------
ERROR: failed to solve: failed to register layer: rename /docker_data_root/docker/image/overlay2/layerdb/tmp/write-set-2247006164 /docker_data_root/docker/image/overlay2/layerdb/sha256/954c82bdeb5fcc8009431[75](https://github.com/oap-project/gluten/actions/runs/5900463328/job/16052636199?pr=2802#step:3:76)28fa3fcbb1026aeff64f872527d35ec9b4343b[84](https://github.com/oap-project/gluten/actions/runs/5900463328/job/16052636199?pr=2802#step:3:85)d: file exists
Error: Process completed with exit code 1.

Closing. Will reopen once bumping into the issue again.


text:
Custom docker image not working

Hey guys,
First of all, congrats for your awesome work here.
I've downloaded your repo and user your docker image, but when I try to build my own docker image, without any modification from the code in master branch. I'm able to build it, but I got an image that is able to process 1 image, but after that it always fail.
ERROR:root:Error in emotion gender processor: "Cannot interpret feed_dict key as Tensor: Tensor Tensor("Placeholder_28:0", shape=(1, 1, 16, 32), dtype=float32) is not an element of this graph."

ERROR:root:An error has occurred whilst processing the file: "local variable 'rgb_image' referenced before assignment"

172.17.0.1 - - [12/Jan/2019 10:05:53] "POST /classifyImage HTTP/1.1" 400 -
INFO:werkzeug:172.17.0.1 - - [12/Jan/2019 10:05:53] "POST /classifyImage HTTP/1.1" 400 -

Thanks

Hola @alejandrosanchezcabana
I suggest you to build your own image, however the Dockerfile looks very outdated (debian:latest from 2017) and the build crash. Replace the Dockerfile with this one and it will work:
FROM jjanzic/docker-python3-opencv:contrib-opencv-3.2.0

RUN apt-get -y update && apt-get install -y git vim procps curl

#Face classificarion dependencies & web application
RUN pip3 install numpy==1.13.3 scipy==1.2.1 scikit-learn pillow tensorflow==1.1.0 pandas==0.19.1 h5py==2.7.0 opencv-python==3.2.0.8 keras==2.0.5 statistics pyyaml pyparsing cycler matplotlib Flask

ADD . /ekholabs/face-classifier

WORKDIR ekholabs/face-classifier

ENV PYTHONPATH=$PYTHONPATH:src
ENV FACE_CLASSIFIER_PORT=8084
EXPOSE $FACE_CLASSIFIER_PORT

ENTRYPOINT ["python3"]
CMD ["src/web/faces.py"]

Hola @enric1994
Finally I was able to build it using my version forked, feel free to merge it (I just opened a PR #126)


text:
pathbuf pop failure should be handled as staying at / for posix compatibility

https://github.com/oasislabs/mantle/blob/980ec638245b5ee64b751280288bf7dd4e205076/bcfs/src/bcfs.rs#L385
for posix filesystems the .. entry in / is / itself; this is the signal for having reached the root directory for a program such as pwd (or getcwd(3) library function), so for full compatibility, we shouldn't return NoEnt in canonicalize_path

Also TODO:

fix doc https://github.com/oasislabs/mantle/blob/master/bcfs/src/bcfs.rs#L536
use fd_usize https://github.com/oasislabs/mantle/blob/master/bcfs/src/bcfs.rs#L144

WASI directories are capabilities. Using .. to access a directory above the directory passed into path_open would require a capability to that parent directory.

authors: bennetyee nhynes

repo: oasislabs/mantle


text:
Update Test Suite to match latest release features

We should start to rework the order of the steps to a release ...

https://github.com/oasp/ts-merger/wiki/releasing

can we access the public releases on npmjs by any download link as well such that we can download the packed js directly by maven?

authors: EastWindShak maybeec themetalone

repo: oasp/ts-merger


text:
Merge "paradigm" with "API" (and simplify paradigm down to OA.Works API needs)

Our old API is currently in a repo called API, and uses what was the Noddy framework, which was based on Meteor.
We've developed our new API for cloudflare workers, under the development name of "paradigm". We considered maintaining paradigm as a separate framework from the OA.Works API code, but that may not be so well suited to our goals. So there are a few options:

keep the current new structure, which has "paradigm" as a wraparound pseudo-framework for OA.Works API code. However this may make it less clear where or what OA.Works API code is.

keep paradigm separate from API as a framework, and move the OA.Works specific code out to the API repo once we are done with the old API code. This makes it clear what part of the code is explicit to the API, but means there are separate repos to maintain which are of no use if we have no other use case for a separate framework. So this should probably only be done if we really do intend to use it as a separate framework for multiple projects.

turn the paradigm repo into the API repo once we are ready to totally replace the old API code with paradigm code. This makes it easy to understand what OA.Works backend code is - it's just all the code in the API repo, and that's all we use it for. Note a question for this though would be where to put code such as for bigdeal or rscvd? As long as it is OK for those to be "in" an OA.Works backend "API" repo, then I think this option is the simplest and perhaps most appropriate for OA.Works longer term.

@JosephMcArthur a decision on this will be required soon-ish, say end of December at the latest.

The latter makes the most sense to me too at this stage. But, a few things I want to check.

Note a question for this though would be where to put code such as for bigdeal or rscvd?
I think it's okay to leave them there, that's how it is now, right?

Other than renaming the repo, would you make any code / structure changes after this decision?

I'd probably get rid of the svc/... delineation, since we're just bumping the oaworks routes up to the top level anyway.

Also I would remove any bits and pieces of code that may be in there that we don't actually need, to make it simpler to maintain in future. I don't think there's much of that, but could be some. And whatever we do here, I'll probably re-arrange some of the utility stuff to do with dates, passcodes etc into subunits, so the oaworks stuff takes more precedence at the top level.

To what extent is the dream of paradigm kept alive in option three if folks forked the repo, deleted the OA.Works service, and started their thing in it's place?

They could, but I'm not sure there would be much point. Most of the advantage of our code is what it does for OA.Works. We haven't succeeded in focusing on making a standalone framework, and it doesn't coincide with any of our other priorities.

Okay, let's go for option three then. Unless you would advise differently now (seems like maybe you've thought about it as we've gone back and forth).

Not working on this quite yet but assigning to myself to keep all critical things to do up front.

I've been doing this inbetween other things, waiting for things to run etc. So assigning it too, to keep track of where time is being spent and relate to pending code commits, and discuss at meetings.

A simplified structure has been made, unnecessary code has been removed. Work continues here.

Ready to merge, but not done yet, should be next week.

Note, check the paradigm client code for more simplification, possibly only needed for login, and even that could change if accounts become obsolete...

Would be useful to know what it looks like to close this in your mind Mark and how much time you need to get there. I think it's also worth a discussion of what "closed" looks like here too (but, not necessarily this week).

I want to simplify the client js code a bit more, as mentioned above, can probably combine into just one file needed for login pages. Or, if you're thinking login won't be needed anywhere in future, depending what features we keep, then even the login code could be dropped. This will take me a couple of hours, or zero hours if you're already certain you don't want logins in future (which I assume is unlikely).
The only other part I'm still looking at is simplifying the server/worker distinction, which I've already simplified a bit, but could perhaps get down further. This will take two or three hours more.
Once the two above are done, I'll merge the current paradigm repo into our API repo, that will take a few minutes, and then this issue is done.

Go ahead with server/worker as you desire.
For login, I think what your describing makes sense regardless given the
time investment. We are highly likely to need login. But, I'd like to
consider if a SAAS solution makes sense (especially in light of having you
around less). I know we've discussed this before, but I think the context
was different then. Let's save this for a call - this is a thing generally
on my mind.
On Wed, 2 Mar 2022, 08:07 markmacgillivray, @.***>
wrote:

I want to simplify the client js code a bit more, as mentioned above, can
probably combine into just one file needed for login pages. Or, if you're
thinking login won't be needed anywhere in future, depending what features
we keep, then even the login code could be dropped. This will take me a
couple of hours, or zero hours if you're already certain you don't want
logins in future (which I assume is unlikely).
The only other part I'm still looking at is simplifying the server/worker
distinction, which I've already simplified a bit, but could perhaps get
down further. This will take two or three hours more.
Once the two above are done, I'll merge the current paradigm repo into our
API repo, that will take a few minutes, and then this issue is done.
—
Reply to this email directly, view it on GitHub
https://github.com/oaworks/paradigm/issues/50#issuecomment-1056519801,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABFZMZ374RHTB6PSO635GRLU54OT3ANCNFSM5I337GLQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

authors: JosephMcArthur markmacgillivray

repo: oaworks/paradigm


text:
45 stop test

Closing #45 and #12
#24 was already solved.
I implemented a test of thread.stop using thread.is-running.

@Graur please have a look

@levBagryansky I think these changes are too small. You removed two @todo's and add only one test. Looks weird to me

@Graur I have already solvedd #24 in pull request #44 and have not removed

@yegor256 please take a look

@rultor merge

@rultor merge

@yegor256 OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@yegor256 Done! FYI, the full log is here (took me 7min)

authors: Graur levBagryansky rultor yegor256

repo: objectionary/eo-threads


text:
Define charts save in which sheet

Hello,
I am working on a project and I could see this package. I have multiple charts and my intention is to save each chart in one excel sheet and also add insert the input values of that chart has been made of them into the corresponded sheet. Can I do all of this with XLSX chart?
Many thanks

Hello. Sorry, you can use only one chart in one worksheet.
May be in next version ...

repo: objectum/xlsx-chart