Generating Gitlab CI configuration causes stack trace

Thanks for the handy generator. I was testing the generation of a Gitlab CI config and I am getting the following stack trace (the monolith app that I created with default options did not have a .bowerrc file):
Welcome to the JHipster Continuous Integration Generator! v1.0.0

Reading the JHipster project configuration for your module
? Please choose your continuous integration: Gitlab-CI
   update .bowerrc

Unable to find .bowerrc. Reference to bowerrc parameter (key: allow_root, value:true) not added.

TypeError: this.debug is not a function
    at Object.addBowerrcParameter (/Users/gomesp/src/jhipster/node_modules/generator-jhipster/generators/generator-base.js:595:18)
    at child.writing (/Users/gomesp/src/jhipster/node_modules/generator-jhipster-ci/generators/app/index.js:97:26)
    at Object.<anonymous> (/Users/gomesp/src/jhipster/node_modules/yeoman-generator/lib/base.js:436:25)
    at /Users/gomesp/src/jhipster/node_modules/run-async/index.js:25:25
    at new Promise (<anonymous>)
    at /Users/gomesp/src/jhipster/node_modules/run-async/index.js:24:19
    at /Users/gomesp/src/jhipster/node_modules/yeoman-generator/lib/base.js:446:8
    at runCallback (timers.js:756:18)
    at tryOnImmediate (timers.js:717:5)
    at processImmediate [as _immediateCallback] (timers.js:697:5)

hi @gomesp
This module is not up-to-date and I'm pretty sure it's totally broken.
But the Gitlab CI configuration has been integrated to official generator-jhipster.  So you can use it directly:
jhipster ci-cd
Here the official documentation:
http://www.jhipster.tech/setting-up-ci/
And it's far better and this module :)

Thanks. Closing the issue then as the alternative works fine. 👍

you're welcome ;)


Fixed bug where the window-status plugin would not work if a user did…

Fixed bug where the window-status plugin would not work if a user did not explicitly set the WINDOW_STATUS optional variable.

Thank you, but this fix is already in master


create attending.io module

see https://github.com/barcelona-js/gitup/issues/14

I'm working on this one.


git on Windows treats symlinks as regular files

git on Windows treats symlinks as regular files.
Therefore even with fix #34 test targets having symlinks to common directory cannot be built on Windows.

#42 should have fixed this :) (god i can’t believe i ever thought symlinked submodules were a good idea…)


Select a column programmatically ?

Is there a way to programmatically select a column in my chart ?
The closest I've seen is this but tried it with this directive and seems not to
work.
http://jsfiddle.net/7xEhW/31/
Any help please ?

Well you can get a handle the chart object gt to the series via it. See how in the faq: https://github.com/pablojim/highcharts-ng#faq


Create akri as the default namespace

What this PR does / why we need it:
Solves #294
This creates a new default namespace (named "akri") for akri components and would be used if the user does not specify a particular namespace.
This particular implementation comes with pros and cons when dealing with helm templates, here is a summary.
Pros:
If a user doesn't specify a namespace it makes sense for it to be arranged in an organized namespace and creates a good standard for Akri usage.
By default Akri won't pollute the cluster's default namespace.
Cons:
Helm doesn't support creating new default namespace other than "default", so this particular implementation creates it via template.
What that means is that if the user specify the namespace during Akri's helm installation (for example "-n iot") it would still be deployed to the "akri" namespace. It is still possible to change it, but it is required to override the .Values.namespace.name variable to set a custom namespace, contradicting the helm already established conventions.
Since now a namespace creation is part of the template it could result in some problems, for example if the user uninstall Akri the namespace it was present would also be deleted, even if some non-akri related components were deployed there.
Conclusion:
My conclusion is that we should stick with Helms patterns and good practice conventions and not set a namespace via templates for now, leaving it to the user decide where to deploy Akri. It is still a good feature to keep in mind and this Issue could definitely be reviewed if we see any updates to this aspect of Helm.
We should still update our documentation in order to incentivize the creation of an Akri namespace during installation, so we could still hit our goal to cut the number of components on the default namespace.

My conclusion is that we should stick with Helms patterns and good practice conventions and not set a namespace via templates for now

@rodz given your conclusion -- and i agree it makes sense to use helm conventions -- should we close this PR and re-open if conventions ever change and instead create a PR that adds to our documentation setting namespace during helm installs:
helm instal akri ... -n akri

My conclusion is that we should stick with Helms patterns and good practice conventions and not set a namespace via templates for now

@rodz given your conclusion -- and i agree it makes sense to use helm conventions -- should we close this PR and re-open if conventions ever change and instead create a PR that adds to our documentation setting namespace during helm installs:
helm instal akri ... -n akri

Sure Kate! Will also make sure to reference this PR on the next one. Thanks for everyone that gave their feedback.


gptscript: 0.5.0 -> 0.8.2

Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[x] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Build fine on aarch64-darwin, but fails at runtime - you should try adding Security framework to propagatedBuildInputs

Result of nixpkgs-review pr 320386 run on x86_64-linux 1

1 package built:

gptscript


Picovoice Issue:

Make sure you have read the documentation, and have put forth a reasonable effort to find an existing answer.
Expected behaviour
Run picovoice_demo_mic with french files.
picovoice_demo_mic --access_key XXXXXXX --keyword_path bonjour-machine_fr_linux_v2_0_0.ppn --context_path test_fr_linux_v2_0_0.rhn
Actual behaviour
[ERROR] Keyword files (.PPN) and model file (.PV) should belong to the same language. Keyword files belongs to 'fr' while model file belongs to 'en'.
Steps to reproduce the behaviour
I'm sure to have selected 'french' when I've generated the test model so the test_fr_linux_v2_0_0.rhn file should be french, not english.

You need to pick the correct .PV file. It is documented here.


Adding Dockerfile for automated builds

This allows us to easily build this project on every release.
fixes #104

Simply select "Create" and then "create automated build" and select this repo.
Afterwards go to build settings and click the '+' and select tag and save the changes. and now we have automated builds

Thank you for merging. Please also update the docker hub image https://hub.docker.com/r/utkarshcmu/wizzy/ by following the instructions above. You might have to delete the dockerhub image first.
Cheers

@nielsole Thanks so much for this!

Will update the docker image tonight. Thank you guys!

Will update the docker image tonight!

Updated the docker image.... can any of you please test that it works as it should? Thanks!

Hey, that looks good, thanks. Whether the generation of tagged images is correct will only be observable, once you create a new git tag.

No tagged version in https://hub.docker.com/r/utkarshcmu/wizzy/tags/ yet :(

yes, but there also hasn't been a tagged commit yet since the changes. Could still be broken, but so far this is expected behaviour.


chore: Updated jhump/protoreflec (v1.17.0) package and go version to 1.21

To use api-linter with protocolbuffers/protobuf v28 need to update bufbuild/protocompile (from v0.10.0 to v0.14.1).

Hey @r9deyes thanks for the PR. We are going to need to also update the Go verison used in our workflows, like to use go-version-file: 'go.mod' instead of hard coding a version, like here

Looks like we will also need to suppress staticcheck here b.c it doesn't like that jhump/protoreflect/desc is deprecated...

I see a few ways to resolve the deprecation issue in jhump/protoreflect:

Update only bufbuild/protocompile to v1.14.1 and keep jhump/protoreflect at the stable version v1.16.0. This allows to use protobuf v28 as desired.
We can simply add //lint:ignore SA10019 above every import of the deprecated package, so staticcheck will ignore it.
Refactor all usages of jhump/protoreflect/desc. There are more than 100 files that depend on it. Refactoring internal packages and all rules will take time. Additionally, the new version of jhump/protoreflect/v2 could facilitate this, but currently, v2 is still in beta (v2.0.0-beta.2).
Personally, I prefer the first option: just a local update of protocompile. In future releases, we can refactor to use jhump/protoreflect/v2 once it is stable.

Update only bufbuild/protocompile to v1.14.1 and keep jhump/protoreflect at the stable version v1.16.0. This allows to use protobuf v28 as desired.
Personally, I prefer the first option: just a local update of protocompile.

Yes, I agree, let's get you unblocked.

In future releases, we can refactor to use jhump/protoreflect/v2 once it is stable.

We may need to bump to v1.17.0 sooner though, for Protobuf Editions support. v1.16.0 states it does not have desc/protoparse support for editions syntax, which is used for api-linter's rules/internal/testutils parsing proto file strings in tests...
It's almost looking like we should migrate off of jhump/protoreflect and use protobuf-go (in place of desc, as jhump/protoreflect suggests) + protocompile (in place of jhump/protoreflect/desc/protoparse also as is suggested) long term.
Since the Rule interfaces are public, we will have to take a v2 of this project to make this happen, so we better think good and long about what we want to do (which I have been in the background, but perhaps it should be done publicly :) )

Latest release v1.64.7 contains this change @r9deyes !

Excellent! Thanks for your assistance @noahdietz


Discrepancy between PyPI package and GitHub repository contents

Hi there,
I've noticed a significant difference between the content available in the GitHub repository and what gets installed via pip from PyPI.
When installing the package using pip install pipecat-ai, the installed version seems to be missing several modules and files that are present in the GitHub repository. Specifically, I encountered a ModuleNotFoundError for pipecat.transcriptions, which exists in the GitHub repo but not in the pip-installed package. CartesiaHttpTTSService also doesn't exist in pipecat.services.cartesia
Steps to reproduce:

pip install pipecat-ai
Try to import from missing modules, e.g., from pipecat.transcriptions.language import Language

Expected behavior: All modules present in the GitHub repository should be available after pip installation.
Actual behavior: Some modules are missing, leading to import errors.
Could you please look into this discrepancy and ensure that the PyPI package includes all necessary files? Alternatively, if there's a recommended way to install the full package that I'm missing, I'd appreciate some guidance.
Thank you for your time and for maintaining this project!

Same. I just take it as they're updating the package at a high rate right now. A discord post says the next released version is going to have a lot of new capabilities, and that is what you are seeing in the updates in their github.

+1 to what @jonnyjohnson1 said.  closing this for now but feel free to open a new issue if it happens again.  and remember to list what version of pipecat-ai you are using.  we are moving fast, so a lot of issues get resolved with a quick update of the package.


No WS_EX_NOREDIRECTIONBITMAP in WindowStylesEx

Hi,
Recently, I needed to use the CreateWindowEx to create a window without a redirection surface, but I found that there is no WS_EX_NOREDIRECTIONBITMAP value in WindowStylesEx. Will this enumeration value be added in a future version?

Looks like that value is 0x00200000. I'll get that added and it will show up in the next release.