text:
Elastic 7.10: uint64 fields are indexed as text, not unsigned long

In Elastic 7.10 version, unsigned long field type was introduced to support uint64 fields. However, the uint64 fields we defined are indexed as text fields in Elasticsearch, not unsigned long.
message ToFlowStats {
	uint64 rxPackets = 1;
	uint64 rxBytes   = 2;
	uint64 txPackets = 3;
	uint64 txBytes   = 4;
}

We use the following API to send the logs to Elasticsearch:
res, err = es.client.Bulk(
	bytes.NewReader(event.Bytes()),
	es.client.Bulk.WithIndex(indexName),
	es.client.Bulk.WithDocumentType(ESDocumentType),
)

And we checked in Kibana, in the index the fields were indexed as text, but we expected them to be indexed as unsigned long:
"toFlowStats" : {
        "properties" : {
                "rxBytes" : {
                  "type" : "text",
                  "fields" : {
                    "keyword" : {
                      "type" : "keyword",
                      "ignore_above" : 256
                    }
                  }
                },
                "rxPackets" : {
                  "type" : "text",
                  "fields" : {
                    "keyword" : {
                      "type" : "keyword",
                      "ignore_above" : 256
                    }
                  }
                },
                "txBytes" : {
                  "type" : "text",
                  "fields" : {
                    "keyword" : {
                      "type" : "keyword",
                      "ignore_above" : 256
                    }
                  }
                },
                "txPackets" : {
                  "type" : "text",
                  "fields" : {
                    "keyword" : {
                      "type" : "keyword",
                      "ignore_above" : 256
                    }
                  }
                }
      }
}

I'm wondering what needs to be done to index uint64 fields as unsigned long. Thanks!

Hi @Anaethelion, thank you for replying to the issue. I got the idea of how to do that in Kibana, but in terms of using Golang, how to specify index mapping for a uint64 field to unsigned long in Golang?

repo: elastic/go-elasticsearch


text:
go build github.com/elastic/go-elasticsearch/v8/typedapi/types: /usr/lib/go-1.18/pkg/tool/linux_amd64/compile: signal: killed

I wonder how many RAM it take to build that package?

To my knowledge it can take up to 1.2gb of ram at peak usage considering the library and its dependencies.
If that's too much you can restrict the APIs with a custom client like so:
package main

import (
	"context"
	"log"
	"net/url"

	"github.com/elastic/elastic-transport-go/v8/elastictransport"

	"github.com/elastic/go-elasticsearch/v8"
	"github.com/elastic/go-elasticsearch/v8/typedapi/core/search"
)

type CustomAPI struct {
	Search search.NewSearch
}

type CustomClient struct {
	elasticsearch.BaseClient
	*CustomAPI
}

func main() {
	tp, err := elastictransport.New(elastictransport.Config{URLs: []*url.URL{
		{Scheme: "http", Host: "localhost:9200"},
	}})
	if err != nil {
		log.Fatal(err)
	}

	client := CustomClient{
		BaseClient: elasticsearch.BaseClient{Transport: tp},
	}

	_, _ = client.Search().Index("my-index").Do(context.Background())
}

This will prevent the compilation of every types in the API and thus reduce the amount of ram needed for compilation.

source: gharchive/issue

authors: Anaethelion KenLoong

license_type: permissive

license_source: github-api


text:
pid directory mode needs be writable

Employer EnableIT
If file resource is defined globally, its fails to start the elasticsearch process. so getting the mode set in first place is a right way to do it.
File { owner => root, group => root, mode => '0444' }

Thanks for the contribution! This looks like a great change, once you sign the CLA this should be good to go.

I have signed the CLA

Thanks for getting the CLA taken care of, @ashish1099. Can you merge in the latest changes in master into your PR? It's been a couple of months so there are several testing changes (and there are conflicts in config.pp)

@tylerjl I have fixed it.
It was quite a fun, since I got messed up my local branch.

Thanks for solving that mess @ashish1099 😄
It looks like the failures in Travis CI are legitimate. If you look at one of the failed tests you'll see that the puppet runs that test for idempotency are failing (that is, the second time puppet runs it still makes changes to the system so something either isn't being set right the first time or something on the system is changing the permissions after running puppet). I'm not entirely what this may be (since it happens on both SysV and systemd-based systems), so you may have to work with it to find what exactly is going on.

Hi there,
Firstly, thank you for taking the time to contribute, and apologies for the radio silence from Elastic on this PR.
I'm going to be working on this module over the next few weeks, with an ultimate aim of updating the module to support the elasticsearch 7.x and simplifying the module to make it easier to use.
I'll be reviewing all the open issues and PRs over the next few days, and will merge or provide feedback where appropriate.
So please hang in there whilst we give this module some TLC.
Thanks again.

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

source: gharchive/pull-request

authors: ashish1099 elasticmachine fatmcgav tylerjl

repo: elastic/puppet-elasticsearch


text:
event.dataTransfer undefined during drop event

onDrop event doesn't have a event.dataTransfer.

I was being stupid

repo: elbywan/bosket

license: mit

license_source: bigquery


text:
Chrome dev tools crashes on console type

[x] I have read the contribution documentation for this project.
[x] I agree to follow the code of conduct that this project follows, as appropriate.
[x] I have searched the issue tracker for an issue that matches the one I want to file, without success.

The program starts up, with dev tools open. All of the dev tools can be used but as soon as I type something the app crashes with no output on the console if using electon . but if I use npm start then therre is some output relating to chrome dev tools

Console output when you run electron-forge with the environment variable DEBUG=electron-forge:*. (Instructions on how to do so here). Please include the stack trace if one exists.
Put the console output here

What command line arguments are you passing?
electron-forge start

What does your config.forge data in package.json look like?
  "config": {
    "forge": {
      "make_targets": {
        "win32": [
          "squirrel"
        ],
        "darwin": [
          "zip"
        ],
        "linux": [
          "deb",
          "rpm"
        ]
      },
      "electronPackagerConfig": {
        "packageManager": "npm"
      },
      "electronWinstallerConfig": {
        "name": "testvue"
      },
      "electronInstallerDebian": {},
      "electronInstallerRedhat": {},
      "github_repository": {
        "owner": "",
        "name": ""
      },
      "windowsStoreConfig": {
        "packageName": "",
        "name": "testvue"
      }
    }
  },

Please provide either a failing minimal testcase (with a link to the code) or detailed steps to
reproduce your problem. Using electron-forge init is a good starting point, if that is not the
source of your problem.
After installing the Vue template by following the instructions as per website (Only difference the project named is VueTest2):
npm install -g electron-forge
electron-forge init my-new-project --template=vue
cd my-new-project
electron-forge start

Which gives me the output of :
[6976:0119/001536.330:ERROR:CONSOLE(7323)] "Extension server error: Object not found: <top>", source: chrome-devtools://devtools/bundled/inspector.js (7323)
npm ERR! code ELIFECYCLE
npm ERR! errno 3221225477
npm ERR! testvue2@1.0.0 start: `electron-forge start`
npm ERR! Exit status 3221225477
npm ERR!
npm ERR! Failed at the testvue2@1.0.0 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\Rehan\AppData\Roaming\npm-cache\_logs\2018-01-18T22_15_40_837Z-debug.log

The log file produced is as follows:
0 info it worked if it ends with ok
1 verbose cli [ 'C:\\Program Files\\nodejs\\node.exe',
1 verbose cli   'C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js',
1 verbose cli   'start' ]
2 info using npm@5.5.1
3 info using node@v8.9.3
4 verbose run-script [ 'prestart', 'start', 'poststart' ]
5 info lifecycle testvue2@1.0.0~prestart: testvue2@1.0.0
6 info lifecycle testvue2@1.0.0~start: testvue2@1.0.0
7 verbose lifecycle testvue2@1.0.0~start: unsafe-perm in lifecycle true
8 verbose lifecycle testvue2@1.0.0~start: PATH: C:\Program Files\nodejs\node_modules\npm\bin\node-gyp-bin;C:\Users\Rehan\Projects\Electron\TestVue2\node_modules\.bin;C:\ProgramData\Oracle\Java\javapath;C:\Program Files\Java\jdk1.8.0_151;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\PuTTY\;C:\Program Files\nodejs\;C:\Users\Rehan\.dnx\bin;C:\Program Files\Microsoft DNX\Dnvm\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Git\cmd;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\Amazon\AWSCLI\;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\Users\Rehan\AppData\Roaming\npm;C:\Android_SDK\newsdk\tools;C:\Android_SDK\newsdk\platform-tools;C:\Program Files\Java\jdk1.8.0_151;C:\Program Files\Gradle\gradle-4.4.1\bin;C:\OpenSSL\bin;C:\Program Files\Git\usr\bin\ssh.exe;C:\Users\Rehan\AppData\Local\Microsoft\WindowsApps;
9 verbose lifecycle testvue2@1.0.0~start: CWD: C:\Users\Rehan\Projects\Electron\TestVue2
10 silly lifecycle testvue2@1.0.0~start: Args: [ '/d /s /c', 'electron-forge start' ]
11 silly lifecycle testvue2@1.0.0~start: Returned: code: 3221225477  signal: null
12 info lifecycle testvue2@1.0.0~start: Failed to exec start script
13 verbose stack Error: testvue2@1.0.0 start: `electron-forge start`
13 verbose stack Exit status 3221225477
13 verbose stack     at EventEmitter.<anonymous> (C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\index.js:280:16)
13 verbose stack     at emitTwo (events.js:126:13)
13 verbose stack     at EventEmitter.emit (events.js:214:7)
13 verbose stack     at ChildProcess.<anonymous> (C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\lib\spawn.js:55:14)
13 verbose stack     at emitTwo (events.js:126:13)
13 verbose stack     at ChildProcess.emit (events.js:214:7)
13 verbose stack     at maybeClose (internal/child_process.js:925:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)
14 verbose pkgid testvue2@1.0.0
15 verbose cwd C:\Users\Rehan\Projects\Electron\TestVue2
16 verbose Windows_NT 10.0.14393
17 verbose argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "start"
18 verbose node v8.9.3
19 verbose npm  v5.5.1
20 error code ELIFECYCLE
21 error errno 3221225477
22 error testvue2@1.0.0 start: `electron-forge start`
22 error Exit status 3221225477
23 error Failed at the testvue2@1.0.0 start script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 3221225477, true ]

I have exactly the same issue using "electron-prebuilt-compile": "2.0.7"
{   "name": "wu",   "productName": "wu",   "version": "1.0.0",   "description": "World manipulation for 3DX",   "main": "src/index.ts",   "scripts": {     "start": "electron-forge start",     "package": "electron-forge package",     "make": "electron-forge make",     "publish": "electron-forge publish",     "lint": "tslint --project tsconfig.json --type-check --force"   },   "keywords": [],   "author": "cicely-f",   "license": "MIT",   "config": {     "forge": {       "make_targets": {         "win32": [           "squirrel"         ],         "darwin": [           "zip"         ],         "linux": [           "deb",           "rpm"         ]       },       "electronPackagerConfig": {         "packageManager": "npm"       },       "electronWinstallerConfig": {         "name": "wu"       },       "electronInstallerDebian": {},       "electronInstallerRedhat": {},       "github_repository": {         "owner": "",         "name": ""       },       "windowsStoreConfig": {         "packageName": "",         "name": "wu"       }     }   },   "dependencies": {     "electron-compile": "^6.4.3",     "electron-devtools-installer": "^2.2.4",     "electron-squirrel-startup": "^1.0.0",     "react": "^16.5.0",     "react-dom": "^16.5.0",     "react-hot-loader": "^4.3.6",     "tslib": "^1.9.3"   },   "devDependencies": {     "@types/electron-devtools-installer": "^2.2.0",     "@types/react": "^16.4.13",     "@types/react-dom": "^16.0.7",     "babel-plugin-transform-async-to-generator": "^6.24.1",     "babel-preset-env": "^1.7.0",     "babel-preset-react": "^6.24.1",     "electron": "^2.0.8",     "electron-forge": "^5.2.2",     "electron-prebuilt-compile": "2.0.7",     "tslint": "^5.11.0",     "typescript": "^3.0.3"   } }

@cicely-f it probably doesn't help that you're specifying both electron and electron-prebuilt-compile, and that they're contradictory versions.

authors: cicely-f gloventRehan malept

repo: electron-userland/electron-forge


text:
The code introduces the exe-icon-extractor package inconsistently with the package.json definition

The definition uses the @bitdisaster/exe-icon-extractor：
https://github.com/electron-userland/electron-wix-msi/blob/master/package.json#L36
The source code uses the exe-icon-extractor
https://github.com/electron-userland/electron-wix-msi/blob/master/src/utils/rc-edit.ts#L22
When I use electron-wix-msi to build a windows application, I get a message that exe-icon-extractor cannot be found
Can we standardize?

any solution?

authors: Sallyfafafa dineshmedloop

repo: electron-userland/electron-wix-msi

license: MIT


text:
Installation failed with Squirell: IT policies

Pre-flight checklist

[X] I have read the contribution documentation for this project.
[X] I agree to follow the code of conduct that this project uses.
[X] I have searched the issue tracker for a bug that matches the one I want to file, without success.

Electron Forge version
7.4.0
Electron version
30.0.7
Operating system
Windows 11 (22631)
Last known working Electron Forge version

Expected behavior
Installation without error messages
Actual behavior
If the executable is outside my development folder (personal computer, not enterprise) the installation fails with the message: Installation has failed. Unable to write to C:\ProgramData\username - IT policies may be restricting access to this folder
Steps to reproduce

yarn make
Move the exe to the Downloads folder
Double click or run as administrator

Additional information
Hello, I have an Electron application using Electron Forge and Vue.js3, and I'm using @electron-forge/maker-squirrel: 7.4.0 for building on Windows.
The build process completes successfully, but during installation, if I have my executable in my Downloads directory (or anywhere outside my development directory), I receive the following error:
"unable to write to c:\ProgramData/username - IT policies may be restricting access to this folder."
I followed the installation instructions on Electron Forge's documentation for Squirrel.Windows: https://www.electronforge.io/config/makers/squirrel.windows
Am I missing something in the configuration?
Thanks
package.json
{
  "name": "-",
  "productName": "-",
  "version": "0.5.1",
  "description": "-",
  "main": ".vite/build/main.js",
  "icon": "public/favicon.ico",
  "scripts": {
    "start": "electron-forge start",
    "package": "electron-forge package",
    "make": "electron-forge make",
    "publish": "electron-forge publish",
    "lint": "echo \"No linting configured\""
  },
  "devDependencies": {
    "@electron-forge/cli": "^7.4.0",
    "@electron-forge/maker-deb": "^7.4.0",
    "@electron-forge/maker-rpm": "^7.4.0",
    "@electron-forge/maker-squirrel": "^7.4.0",
    "@electron-forge/maker-zip": "^7.4.0",
    "@electron-forge/plugin-auto-unpack-natives": "^7.4.0",
    "@electron-forge/plugin-fuses": "^7.4.0",
    "@electron-forge/plugin-vite": "^7.4.0",
    "@electron/fuses": "^1.8.0",
    "@types/tar": "^6.1.13",
    "@vitejs/plugin-vue": "^5.0.4",
    "electron": "30.0.7",
    "eslint": "^9.3.0",
    "eslint-plugin-vue": "^9.26.0",
    "sass": "^1.77.2",
    "vite": "^5.2.11",
    "vite-plugin-electron-renderer": "^0.14.5"
  },
  "keywords": [],
  "author": {
    "name": "-",
    "email": "-"
  },
  "license": "-",
  "dependencies": {
    "@openid/appauth": "^1.3.2",
    "adm-zip": "^0.5.12",
    "archiver": "^7.0.1",
    "axios": "^1.7.2",
    "boxicons": "^2.1.4",
    "dayjs": "^1.11.11",
    "dotenv": "^16.4.5",
    "electron-log": "^5.1.4",
    "electron-squirrel-startup": "^1.0.1",
    "floating-vue": "^5.2.2",
    "form-data": "^4.0.0",
    "gsap": "^3.12.5",
    "pinia": "^2.1.7",
    "pinia-plugin-persistedstate": "^3.2.1",
    "primeicons": "^7.0.0",
    "primevue": "^3.52.0",
    "steam-game-path": "^2.2.3",
    "tree-kill": "^1.2.2",
    "unzipper": "^0.11.6",
    "vue": "^3.4.27",
    "vue-awesome-paginate": "^1.1.46",
    "vue-router": "4",
    "vue-sidebar-menu-akahon": "^1.0.2",
    "vue3-carousel": "^0.3.3",
    "vue3-toastify": "^0.2.1"
  }
}

forge.config.js
const { FusesPlugin } = require('@electron-forge/plugin-fuses')
const { FuseV1Options, FuseVersion } = require('@electron/fuses')
require('dotenv').config()

module.exports = {
  packagerConfig: {
    asar: true
  },
  rebuildConfig: {},
  makers: [
    {
      name: '@electron-forge/maker-squirrel',
      config: {
        loadingGif: "./public/install-gif.gif",
        setupIcon: "./public/favicon.ico",
      }
    },
    {
      name: '@electron-forge/maker-zip',
      platforms: ['darwin'],
    },
    {
      name: '@electron-forge/maker-deb',
      config: {},
    },
    {
      name: '@electron-forge/maker-rpm',
      config: {},
    },
  ],
  plugins: [
    {
      name: '@electron-forge/plugin-vite',
      config: {
        // `build` can specify multiple entry builds, which can be Main process, Preload scripts, Worker process, etc.
        // If you are familiar with Vite configuration, it will look really familiar.
        build: [
          {
            // `entry` is just an alias for `build.lib.entry` in the corresponding file of `config`.
            entry: 'src/electron/main.js',
            config: 'vite.main.config.mjs',
          },
          {
            entry: 'src/electron/preload.js',
            config: 'vite.preload.config.mjs',
          },
        ],
        renderer: [
          {
            name: 'main_window',
            config: 'vite.renderer.config.mjs',
          },
        ],
      },
    },
    // Fuses are used to enable/disable various Electron functionality
    // at package time, before code signing the application
    new FusesPlugin({
      version: FuseVersion.V1,
      [FuseV1Options.RunAsNode]: false,
      [FuseV1Options.EnableCookieEncryption]: true,
      [FuseV1Options.EnableNodeOptionsEnvironmentVariable]: false,
      [FuseV1Options.EnableNodeCliInspectArguments]: false,
      [FuseV1Options.EnableEmbeddedAsarIntegrityValidation]: true,
      [FuseV1Options.OnlyLoadAppFromAsar]: true,
    }),
  ],
}

It seems there's an issue with my Windows; the error doesn't occur on other Windows 11 machines.

repo: electron/forge


text:
chore: update version number

Supersedes #103, there's more places to update the version in src/rcedit.rc. Not sure why GitHub is considering that file a binary file (it always has in the repo history), but tried also changing the encoding to UTF-8 so that maybe future PRs will show diff properly. 🤷

Does updating the version number have any implication on breaking changes? Coming with no context from a semver perspective, going from v0.2.0 to v1.1.1 seems big.

It's not great, but I don't think so? 🤷 FWIW this also won't be released as-is, just more of an incremental step towards getting this repo back to shippable state. The next version we ship might just be a 2.0.0 since it's been so long and we don't have the context to ensure there are no breaking changes, as you point out.

repo: electron/rcedit


text:
Version 1.0.0: User interface, codebase rebuild

I am motivated to make Wemp more than just a system tray menu. If we're going to use Electron, let's do it right.
Wemp will get a user interface, so I have migrated to electron-vite with Vue. The whole codebase will be rebuilt.
Since we previously had problems with Electron Forge (which were never solved), the switch to electron-vite, which uses Electron Builder, made even more sense.
If you want to see the progress on the next version, you can look at the dev branch.
To-Do

[ ] User interface

[x] List of services with buttons to start, restart, stop, etc.
[ ] Settings and switching between different paths.
[ ] Console showing actions or error messages in the current session. Like XAMPP.

[ ] Service logic

[x] Download and extract the services.
[ ] Install the services and use the stubs to configure them.
[x] Start, restart and stop services.
[ ] Monitoring of changes to configuration files.

[ ] New readme with screenshots of the user interface.

Nice to have

[ ] Download progress bar for each service.
[ ] Get version of services automatically from its website. Probably needs to be hosted somewhere.
[ ] Manual version setting for services. (kinda tricky because PHP's download file name often changes)
[ ] Multiple language support.
[ ] Maybe a new icon and logo for Wemp.

I recently started using WEMP. Awesome! Is it still ongoing project or you dont have time anymore ?

I recently started using WEMP. Awesome! Is it still ongoing project or you dont have time anymore ?

Hey, glad you like it. I'm still working on it but the new version will take a while.

I'm a fullstack-backend dev. If you need some help with something I could help you. I've been using xampp and it is garbage :D +1 request, redis maybe

Redis was already suggested but there was no official Windows support then, not sure how it is now. But I would like to keep Wemp minimal.

The original redis has no official windows support. But I think i was running:

Other project
https://github.com/zkteco-home/redis-windows

I understand the minimalistic approach. Maybe it would be possible then create something like addon ? aka you can create own config, something like service.redis.cfg and have required stuff like what to run where to find it etc. That would give possibility for people to add own stuff. For example I like running pocket base for some projects. But yeah thats just an idea

I've decided to stick with the tray menu for now, so I'm closing this.
New update will follow as soon as phpMyAdmin has fixed the problems with PHP 8.4.

authors: OfficialAudite electronfriends

repo: electronfriends/wemp


text:
Two Modules Within Same Extension

Problem Description
When I add a second module under the [extension name]/includes/modules, the second module loaded from within VB doesn't display fields defined in the get_fields function.  The second module is present in VB, just the properties in get_fields are not displayed.
I've played around with this a little bit and noticed it isn't class specific, rather only the first class loaded from the loader gets the additional needed custom fields.  The second classes fields never get displayed from within the builder.
I'm not sure where to go from here, wondering if anyone else has experienced this?
Steps To Reproduce

Screenshot and/or gif

Had a similar issue when adding new fields to my modules. Usually a local window.localStorage.clear() on the browsers console together with a force reload (holding shift while reloading) does the trick.

@dlight20 Could you share a .zip with your extension?

@VladET
test-multi-modules.zip
This is just an example - if you try to view fields for the second module they will not be displayed.  To get the file uploaded, I removed the node_modules libraries so you'll need to re-import them.
I appreciate any guidance you can provide.

@dlight20 Thank you, that is perfect. It's working great on my end.

Do you see any errors in your terminal?

@VladET
From the VB screen above mine is working as expected too.  I have attached an image displaying where I am seeing the issue, I apologize for a possible terminology mistake, I am a newbie to WordPress/Divi...

Thanks again!

Have you tried to clear your local storage?

So for clarification purposes, if I intended to create multiple modules that were all complimentary of each other, I could just put them all in an 'extension' plugin? Which technically means if I intended to develop Custom Post Types with Custom Divi Modules I could just include them ALL in one extension because Extensions are also Plugins?

Yes, you can use the plugin file in the root folder for your functions (e. g. adding post types, meta boxes etc.) and the /includes/modules/ can be filled with as many Divi modules as you desire

authors: VladET dlight20 randomblink xxtesaxx

repo: elegantthemes/create-divi-extension


text:
Auto delete test tables in Snowflake

Is your feature request related to a problem? Please describe.
Test result which gets stored in the tables are not easy to clear. After a while they start taking too much space.
Describe the solution you'd like
It would be great if there's a way to automatically get them clear up after a certain number of days.

Closing in favour of https://github.com/elementary-data/elementary/issues/937.

repo: elementary-data/elementary


text:
auto start the Weather-Station

I try my best, but I can't get your program to start automatically.
I wrote a bash-script (start_weather.sh) with the following call:
#!/bin/bash cd ~/pi-weather-station/ npm start
and made it executable.
chmod +x /home/pi/start_weather.sh
If I enter:
 $ /home/pi/start_weather.sh
it starts like it should.
But if I put it in a crontab nothing hapend.
0 9 * * * /home/pi/start_weather.sh
Try the same with your bash https://github.com/elewin/pi-weather-station/issues/12 (just without chromium):
#!/bin/bash cd ~/pi-weather-station/ /usr/local/bin/npm start ~/pi-weather-station/server/index.js
unfortunately without success
Do you have an idea where the problem could be or what I can still try ?
Edit:
I have figured out that it works when I start the script via LXDE.
But why doesn't crontab work?

I was able to get mine to start automatically during boot using crontab

Try changing your crontab entry to @reboot instead of the 0 9 ***. That way it starts on reboot and stays running. What you have now is every 9 minutes it tries to start whether it's running or not.
@reboot /home/pi/start_weather.sh

@k5map  can you share your crontab  commands?

@carl1961 ...  Definitely; here are the steps to get the app to start on boot:

crontab -e
enter this at the bottom —  @reboot bash /home/pi/weather-start.sh  (the name of the bash script can be anything you want)

Here is what I have in my script in my home directory:

cd $HOME/pi-weather-station/
npm start &

Thanks @k5map  another question is what is your remedy to get full screen when it starts up. I am setting up this for my wife as a 7 inch screen with no key board and mouse. so if power fail reboot it boots to full screen

@carl1961 ... I don't know the answer to your question.  For my setup, I'm using the app on a RPi and accessing the webpage remotely from my different computers.  If you Google Pi Weather Station, I think you'll find multiple YouTube videos which might give you the information to make that setting.

Thanks @k5map  thats what I been finding , found this and going to try
https://github.com/xieby1/fullscreen

@k5map Got it all working, this is what I had t do. I did everything you told me,  could not get browser to pop up and learned you cannot start browser through crontab    https://forums.raspberrypi.com//viewtopic.php?t=231987
did what this link showed for chromium-brower to start full screen https://raspberrypi.stackexchange.com/questions/69204/open-chromium-full-screen-on-start-up
what I put at bottom of  autostart file        sudo nano /etc/xdg/lxsession/LXDE-pi/autostart
@xset s off
@xset -dpms
@xset s noblank
@chromium-browser --start-fullscreen http://localhost:8080
chrontab -e    starts the npm start  as you told in your post at boot
/etc/xdg/lxsession/LXDE-pi/autostart starts chromium-browser at boot

repo: elewin/pi-weather-station


text:
🛑 UNER - Diaguita is down

In abca4a8, UNER - Diaguita (https://diaguita.uner.edu.ar) was down:

HTTP code: 500
Response time: 988 ms

Resolved: UNER - Diaguita is back up in 96a97c9.

repo: elfoche/monitoreo


text:
🛑 MCU - Owncloud is down

In 374d426, MCU - Owncloud (https://cloud.cdeluruguay.gob.ar/login?redirect_url=/apps/dashboard/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MCU - Owncloud is back up in d5bc2c7 after 24 minutes.


text:
🛑 UCU - Maraton is down

In 2d65854, UCU - Maraton (https://maraton.ucu.edu.ar/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: UCU - Maraton is back up in 0f87762.


text:
🛑 UNER - DDJJ is down

In 5dfd544, UNER - DDJJ (https://autogestion.uner.edu.ar/) was down:

HTTP code: 502
Response time: 708 ms

Resolved: UNER - DDJJ is back up in c8a87ed.


text:
Minting breaks if Allowlist has more than 15 wallets

Hey,
If you have more than 15 wallets, the instruction gets big and it breaks. Any idea how to fix it ?

@RocKhalil Yeah, a way to solve this is by using the signAllTransactions function through the useWallet hook, to build as many txs as necessary. Ping me on Discord, and I'm able to help: eliagoris#2665

#5

authors: RocKhalil eliagoris

repo: eliagoris/pnfts-mint


text:
Feature python3 support

Creating a PR to get the tests to run. If you want to take a look @seanwiseman I tried to add Python 3 support while also supporting Python 2 following some of the recent patterns we've followed.

:+1:

Fixes https://github.com/elifesciences/elife-pubmed-feed/issues/70


text:
MSID: 99767 Version: 1 DOI: 10.48550/arXiv.2301.12812v5

MSID: 99767
Version: 1
Preprint DOI: https://doi.org/10.48550/arXiv.2301.12812v5
Step 1. Awaiting reviews
Editorial to post reviews via hypothesis
Useful links:

DocMap: https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v2/by-publisher/elife/get-by-manuscript-id?manuscript_id=99767
New model tracking: https://docs.google.com/spreadsheets/d/1_fHaoOy7hjyocptKtVJRijeNpUY4hBS7Ck_aVmx6ZJk/
Reviews on sciety: https://sciety.org/articles/activity/10.48550/arXiv.2301.12812v5

For trouble shooting (e.g. no Docmaps available):

DocMap issue addressing: https://miro.com/app/board/uXjVNCwK6EI=/
Explore DataHub DocMaps API: https://lookerstudio.google.com/reporting/4c2f0368-babb-4beb-b5b3-497e7e7b0f08/page/ejphD
Unmatched submissions and preprints: https://lookerstudio.google.com/u/0/reporting/9f86204f-3bf7-477c-9b18-5c5ef141bf69/page/p_gxi57ha93c
Unmatched manuscripts spreadsheet: https://docs.google.com/spreadsheets/d/15QcK8w-ssB7109RQEDtFpJPZ0J5HTGxoHa_2TtpMBbg/edit#gid=1336081641

Step 2. Preview reviewed preprint
Production QC content ahead of publication
Instructions:

QC preview: https://prod--epp.elifesciences.org/previews/99767v1
Update ticket with any problems (add blocked label)
When QC OK, add QC OK label to ticket and add publication date and time to https://docs.google.com/spreadsheets/d/1amAlKvdLcaDp5W8Z8g77NmkwbMF5n_u89ArSqPMO8jg
Move card to next column
(At end of the day post link in #enhanced-preprint and ask for PDF to be generated)

Useful links:

Preprint DOI :  https://doi.org/10.48550/arXiv.2301.12812v5
Confirm reviews returned by EPP: https://prod--epp.elifesciences.org/api/reviewed-preprints/99767/v1/reviews
To update the MECA path in the docmap: https://docs.google.com/spreadsheets/d/1mctCQuNFBjSn97Lihy7_vBO6z7-N-oqyLv4clyi6zHg

Step 3: Awaiting search reindex
This step adds the reviewed preprint to the homepage: https://elifesciences.org
The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.
Useful links:

Jenkins pipeline to reindex search can be triggered sooner or monitored here: https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 4: Published! PDF requested
Waiting for PDF to be generated
Useful links:

PDF tracking: https://docs.google.com/spreadsheets/d/106_XeDjmuBae7gexOTNzg60lapeqjl2aRn9DzupGyS8/

Step 5: Introduce PDF to data folder and git repo
Upload PDF to relevent folder in git repo https://github.com/elifesciences/enhanced-preprints-data/
Step 6: Done!

[ ] Kettle is on!

Thanks @ameenanaji - please let us know once this has been added

Thanks Ameena

Reloading to fix supplementary figure placement.

authors: JGilbert-eLife fred-atherden


text:
MSID: 100086 Version: 1 DOI: 10.1101/2024.06.30.601440

MSID: 100086
Version: 1
Preprint DOI: https://doi.org/10.1101/2024.06.30.601440
Step 1. Awaiting reviews
Editorial to post reviews via hypothesis
Useful links:

DocMap: https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v2/by-publisher/elife/get-by-manuscript-id?manuscript_id=100086
New model tracking: https://docs.google.com/spreadsheets/d/1_fHaoOy7hjyocptKtVJRijeNpUY4hBS7Ck_aVmx6ZJk/
Reviews on sciety: https://sciety.org/articles/activity/10.1101/2024.06.30.601440

For trouble shooting (e.g. no Docmaps available):

DocMap issue addressing: https://miro.com/app/board/uXjVNCwK6EI=/
Explore DataHub DocMaps API: https://lookerstudio.google.com/reporting/4c2f0368-babb-4beb-b5b3-497e7e7b0f08/page/ejphD
Unmatched submissions and preprints: https://lookerstudio.google.com/u/0/reporting/9f86204f-3bf7-477c-9b18-5c5ef141bf69/page/p_gxi57ha93c
Unmatched manuscripts spreadsheet: https://docs.google.com/spreadsheets/d/15QcK8w-ssB7109RQEDtFpJPZ0J5HTGxoHa_2TtpMBbg/edit#gid=1336081641

Step 2. Preview reviewed preprint
Production QC content ahead of publication
Instructions:

QC preview: https://prod--epp.elifesciences.org/previews/100086v1
Update ticket with any problems (add blocked label)
When QC OK, add QC OK label to ticket and add publication date and time to https://docs.google.com/spreadsheets/d/1amAlKvdLcaDp5W8Z8g77NmkwbMF5n_u89ArSqPMO8jg
Move card to next column
(At end of the day post link in #enhanced-preprint and ask for PDF to be generated)

Useful links:

Preprint DOI :  https://doi.org/10.1101/2024.06.30.601440
Confirm reviews returned by EPP: https://prod--epp.elifesciences.org/api/reviewed-preprints/100086/v1/reviews
To update the MECA path in the docmap: https://docs.google.com/spreadsheets/d/1mctCQuNFBjSn97Lihy7_vBO6z7-N-oqyLv4clyi6zHg

Step 3: Awaiting search reindex
This step adds the reviewed preprint to the homepage: https://elifesciences.org
The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.
Useful links:

Jenkins pipeline to reindex search can be triggered sooner or monitored here: https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 4: Published! PDF requested
Waiting for PDF to be generated
Useful links:

PDF tracking: https://docs.google.com/spreadsheets/d/106_XeDjmuBae7gexOTNzg60lapeqjl2aRn9DzupGyS8/

Step 5: Introduce PDF to data folder and git repo
Upload PDF to relevent folder in git repo https://github.com/elifesciences/enhanced-preprints-data/
Step 6: Done!

[ ] Kettle is on!

warn: [journal-ref-text-content] This journal reference (id c1) has untagged textual content - .  (Ed.), . Is it tagged correctly?


text:
Add SVG image?

I want to use this lock image. I downloaded it into images/lock.svg.
My goal is to display it large, in red with a heavy stroke. So far I was only to display it in default size using jp.Div. I failed with Svg & Img. Div displays an image and I was able to set the size of the Div and change the background color but not the color used in the drawing. How would you start this?
    d = jp.Div(classes='w-7/8 m-2 p-3 border rounded-lg ', a=wp)
    jp.Svg(image='images/lock.svg', a=d)
    jp.Svg(svg='images/lock.svg', a=d)
    jp.Svg(script='images/lock.svg', a=d)
    jp.Img(src='images/lock.svg', a=d)
    lock = jp.Div(a=d, inner_html=open('images/lock.svg').read())
    lock.height = 100  # Copied from [Specific Attributes](https://justpy.io/tutorial/html_components/#specific-attributes)
    lock.width = 100
    lock = jp.Div(a=d, inner_html=open('images/lock.svg').read(), classes='w-64 h-64 fg-red-700 bg-blue-500 hover:bg-blue-700')

The simplest way to do this is the following:
import justpy as jp

svg_html = """
<svg xmlns="http://www.w3.org/2000/svg" class="icon icon-tabler icon-tabler-lock"
     color="red" width="240" height="240"
     viewBox="0 0 24 24" stroke-width="2"
     stroke="currentColor" fill="none" stroke-linecap="round" stroke-linejoin="round">
  <path stroke="none" d="M0 0h24v24H0z"/>
  <rect x="5" y="11" width="14" height="10" rx="2" />
  <circle cx="12" cy="16" r="1" />
  <path d="M8 11v-4a4 4 0 0 1 8 0v4" />
</svg>

"""

def svg_example():
    wp = jp.WebPage()
    d = jp.Div(a=wp)
    d.inner_html = svg_html
    return wp

jp.justpy(svg_example)

Another more general way that allows you more flexibility is to use the parse_html function:
import justpy as jp

svg_html = """
<svg xmlns="http://www.w3.org/2000/svg" class="icon icon-tabler icon-tabler-lock"
     viewBox="0 0 24 24" stroke-width="2"
     stroke="currentColor" fill="none" stroke-linecap="round" stroke-linejoin="round">
  <path stroke="none" d="M0 0h24v24H0z"/>
  <rect x="5" y="11" width="14" height="10" rx="2" />
  <circle cx="12" cy="16" r="1" />
  <path d="M8 11v-4a4 4 0 0 1 8 0v4" />
</svg>

"""

def svg_example():
    wp = jp.WebPage()
    for i in range(5, 500, 50):
        svg_element = jp.parse_html(svg_html, a=wp)
        svg_element.width = i
        svg_element.height = i
        svg_element.color = 'red'
    return wp

jp.justpy(svg_example)

Thanks.
Now I'm trying to size the SVG image to combine with some header text. Below I force it to match the header size by manually translating the Tailwinds text size 'text-3xl' used for the header to '1.875rem' used for the lock image. I got the translation from the Tailwinds Font Size doc.
Is there a better way to match the size of the header so that if I change the header size then the lock image will automatically adjust? Can I interrogate the header to find out it's height in pixels?
d = jp.Div(classes='w-7/8 m-2 p-3 border rounded-lg ', a=wp)
header = jp.P(text='Six month history', a=d, classes='text-3xl')
svg_html = open('images/lock.svg').read()
svg_element = jp.parse_html(svg_html, classes='hover:bg-blue-200', a=d)
#svg_element.width = svg_element.height = 'text-3xl'  # Fail, gigantic.
svg_element.width = svg_element.height = '1.875rem'
header = jp.P(text='Six month history for '+phone_number, a=d, classes=f'text-3xl')

If this is something you would reuse then you can make the header and the svg element a custom component. If this is of interest to you I can show you how to do this.
Another simple solution is to add your own attribute to the header, call it font_size for example:
    d = jp.Div(classes='w-7/8 m-2 p-3 border rounded-lg ', a=wp)
    header = jp.P(text='Six month history', a=d)
    header.font_size = '1.875rem'
    header.style = f'font-size: {header.font_size}'
    svg_html = open('images/lock.svg').read()
    svg_element = jp.parse_html(svg_html, classes='hover:bg-blue-200', a=d)
    #svg_element.width = svg_element.height = 'text-3xl'  # Fail, gigantic.
    svg_element.width = svg_element.height = header.font_size

You can parse a file to html directly using parse_html_file('images/lock.svg')

Thanks, that works. And thanks for the parse_html_file() tip.
Now I'm trying to add support for SVG images in a table. I was using jp.AutoTable. It treats all elements as text so I tried to modify it.  Here's an example that didn't work. I don't know what arguments are allowed for table cell so I'm guessing. How can I find what arguments are support for Td?
                for item in row:
                    #Td(text=item, classes=self.td_classes, a=tr)  # Original code.
                    #Td(src='images/lock.svg', classes=self.td_classes, a=tr)  # Fails
                    Td(http_src='images/lock.svg', classes=self.td_classes, a=tr)  # Fails

Td is equivalent to the HTML td tag https://www.w3schools.com/tags/tag_td.asp which is just a cell in the table. You can add elements to it like you add to a Div.
The example below creates a simple table with the svg element in the cells. Just so that it is not too boring, I made the svg size dependent on the column:
import justpy as jp

svg_html = """
<svg xmlns="http://www.w3.org/2000/svg" class="icon icon-tabler icon-tabler-lock"
     viewBox="0 0 24 24" stroke-width="2"
     stroke="currentColor" fill="none" stroke-linecap="round" stroke-linejoin="round">
  <path stroke="none" d="M0 0h24v24H0z"/>
  <rect x="5" y="11" width="14" height="10" rx="2" />
  <circle cx="12" cy="16" r="1" />
  <path d="M8 11v-4a4 4 0 0 1 8 0v4" />
</svg>

"""

def svg_table_example():
    wp = jp.WebPage()
    table = jp.Table(a=wp)
    thead = jp.Thead(a=table)
    tr = jp.Tr(a=thead)
    for item in ['Header 1', 'Header 2', 'Header 3']:
        jp.Th(text=item, classes='', a=tr)
    tbody = jp.Tbody(a=table)
    for row in range(5):
        tr = jp.Tr(a=tbody)
        for col in range(1, 4):
            td = jp.Td(a=tr)
            svg_element = jp.parse_html(svg_html, a=td)
            svg_element.width = col * 10
            svg_element.height = col * 10
            svg_element.color = 'red'
    return wp

jp.justpy(svg_table_example)

So simple. Thanks.

authors: elimintz johnmudd

repo: elimintz/justpy


text:
Dev

updated data model with bsSeq template
Created processes to split data model, update with new terms, and tests for generating manifests

Need to rework the github actions. I checked the data model manually this time.

repo: eliteportal/data-models


text:
Specifying an unsupported logging level causes a runtime crash

Brief
If you specify an unsupported logging level (i.e. not debug, info, warn, or error) by setting log_level for My.Repo (that uses Ecto.Repo) you get runtime crashes whenever Ecto attempts to log. Instead, I would have expected a compile-time error thereby allowing me to catch my configuration mistake early.
Environment

Elixir is 1.3.4 on Erlang/OTP 19.
Ecto is 1.1.8, but the code in question is the same for 1.1.9.
This was against PostgreSQL 9.6.0, but that has no effect.
The adapter (postgrex) is 0.11.2.
This originally showed up on Ubuntu 16.04 and was recreated on macOS Sierra.

Current Behaviour
If you set log_level for your repository to an unsupported logging level, i.e. not debug, info, warn, or error,  you get crashes whenever Ecto attempts to log.
config/prod.exs
config :app, My.App.Repo,
  # Accidentally use PostgreSQL logging levels because it's been a long day.
  log_level: :notice

This causes a crash when this autogenerated code is called.
def log(entry) do
  Logger.unquote(@log_level)(fn ->
    {_entry, iodata} = Ecto.LogEntry.to_iodata(entry)
    iodata
  end, ecto_conn_pid: entry.connection_pid)
end

With an UndefinedFunctionError because it attempts to call Logger.notice/2.
Expected Behaviour
When log_level is unsupported* a compile-time error would be preferred to a runtime error.
Looking at the Logger.level() type spec, it appears the four prescribed levels are the only levels allowed, so the check is rather easy: @log_level in ~w(error info warn debug)a.

I'll try to tackle this one. Anyone else interested?

Please go ahead. :)
On Wednesday, October 19, 2016, Thiago Arrais notifications@github.com
wrote:

I'll try to tackle this one. Anyone else interested?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/elixir-ecto/ecto/issues/1744#issuecomment-254802377,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAlbsoSaw-MNdpoh7MMUT1X23QuvG-1ks5q1hHAgaJpZM4KVgy_
.

--
José Valim
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R&D

Bear with me here, I'm both an Elixir as an Ecto n00b... :-)
I'm having trouble reproducing the bug. How can I force the problematic log function to be called?
Here's what I'm trying (based on https://hexdocs.pm/ecto/getting-started.html): https://github.com/thiagoarrais/ecto-1744-friends
I've created a database and a table as per the ecto getting started guide, but I'm not getting any error when running this:
$ iex -S mix
Erlang/OTP 19 [erts-8.1] [source] [async-threads:10] [hipe] [kernel-poll:false]

Interactive Elixir (1.3.4) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> p = %Friends.Person{first_name: "Ryan", last_name: "Bigg", age: 28}
%Friends.Person{__meta__: #Ecto.Schema.Metadata<:built, "people">, age: 28,
 first_name: "Ryan", id: nil, last_name: "Bigg"}
iex(2)> Friends.Repo.insert(p)

20:05:42.932 [debug] QUERY OK db=54.6ms decode=0.1ms
INSERT INTO "people" ("age","first_name","last_name") VALUES ($1,$2,$3) RETURNING "id" [28, "Ryan", "Bigg"]
{:ok,
 %Friends.Person{__meta__: #Ecto.Schema.Metadata<:loaded, "people">, age: 28,
  first_name: "Ryan", id: 3, last_name: "Bigg"}}
iex(3)>

These tests may be of help.
I also noticed you're testing against 2.x.y.

If the error is already fixed in 2.x then we can close this issue. This is a nice to have, so we catch mistakes early, so we won't be backporting to 1.x.

I've managed to reproduce the error with 1.x. The exact error is not reproducible in 2.x. Would there be any interest in yielding a compile error on invalid log levels?
If so, what do you think should be the "Ecto way"? I mean: should it just replace the user's unsupported log level with a sensible default one or should it force the user choose a valid option?

@thiagoarrais raising at compile time would be the best, yes.

My bad. This actually reproduces in 2.x. You need to use loggers: [{Ecto.LogEntry, :log, [:notice]}] instead of log_level: :notice.

@thiagoarrais Are you still working on this? If not, I'd be happy to take a stab at it :)

Go ahead. It would be nice to see someone that knows this stuff doing it.
'cause I have no idea what I'm doing here.
:-D
On Thu, 24 Nov 2016 17:57 Linus Pettersson, notifications@github.com
wrote:

@thiagoarrais https://github.com/thiagoarrais Are you still working on
this? If not, I'd be happy to take a stab at it :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/elixir-ecto/ecto/issues/1744#issuecomment-262843841,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAALxukrdxm8QYuGKkDlRsT6UnM70F_Xks5rBfpUgaJpZM4KVgy_
.

@josevalim Is it ok if I take this issue? You can assign it to me if you'd like :)

I tried to get this working today but I'm not sure how we can do this in a good way though. You can pass custom loggers now and we don't know what log levels they support, right?
So, what we can do is special case the Ecto.LogEntry logger in this macro code:
https://github.com/elixir-ecto/ecto/blob/master/lib/ecto/repo.ex#L93-L100
This code works, but it's a bit ugly. I don't like to duplicate the list of log levels for instance.
      loggers =
        Enum.reduce(config[:loggers] || [Ecto.LogEntry], quote(do: entry), fn
          mod, acc when is_atom(mod) ->
            quote do: unquote(mod).log(unquote(acc))
          {mod, fun, args}, acc ->
            case {mod, fun, args} do
              {Elixir.Ecto.LogEntry, :log, [l]} when not l in [:error, :info, :warn, :debug] ->
                IO.warn("The log level #{inspect(l)} is not supported", Macro.Env.stacktrace(__ENV__))
              _ -> true
            end
            quote do: unquote(mod).unquote(fun)(unquote(acc), unquote_splicing(args))
        end)

Any better ideas on how to handle this?

@Linuus we should check only for Ecto.LogEntry so I would write it like this or similar:
     loggers =
        Enum.reduce(config[:loggers] || [Ecto.LogEntry], quote(do: entry), fn
          mod, acc when is_atom(mod) ->
            quote do: unquote(mod).log(unquote(acc))
          {Ecto.LogEntry, :log, [level]}, _acc when not l in [:error, :info, :warn, :debug] ->
            raise "the log level #{inspect level} is not supported in Ecto.LogEntry"
          {mod, fun, args}, acc ->
            quote do: unquote(mod).unquote(fun)(unquote(acc), unquote_splicing(args))
        end)

Wouldn't it be better to do this check at runtime in the Ecto.LogEntry.log/1 guard?

@michalmuskala We could do that but the whole point of the issue was to catch this at compile time to avoid runtime issues.

As far as I can tell, logging levels can only be one of the prescribed. Unless that is an ambiguity in their specification. If so, the relevant documentation and typesecs need to be adjusted.

@mtwilliams Yes, for Ecto.LogEntry there are a set list of log levels. But what if I have a custom logger, can that have other log levels or do they all have to conform to the same list of log levels?

We should check only for LogEntry because for other loggers I believe it is not even required for the first argument to be a log level.

authors: Linuus josevalim michalmuskala mtwilliams thiagoarrais

repo: elixir-ecto/ecto


text:
Recursive CTEs not allowing direct selection into struct

Currently there is no way to explicitly use the recursive selection and select directly in a struct.
The only workaround I could accomplish is to inner join with the same table and extract the values from that join:
category_tree_initial_query =
  Category
  |> where([c], c.id == 1)

category_tree_recursion_query =
  Category
  |> join(:inner, [c], ct in "category_tree", on: c.parent_id == ct.id)

category_tree_query =
  category_tree_initial_query
  |> union_all(^category_tree_recursion_query)

"custom_cte"
|> recursive_ctes(true)
|> with_cte("custom_cte", as: ^category_tree_query)
|> join(:inner, [c], c1 in Category, on: c.id == c1.id, as: :cat)
|> select([cat: cat], cat)

The issue here is that you are not starting the query with a schema, you are using "custom_cte". You can attach a schema to it by using a tuple {"custom_cte", Category} |> with_cte(...) |> ....

Thank you! The example in documentation is a little misleading, I thought the syntax is for selecting a touple.


text:
Drop avatars from attachments

Something I have in mind, but never tracked, I would really see at some point the option to upload avatars as attachments to go away.
Attachments should be just that, not mixture of stuff.
Avatars should just be uploaded to a directory and directly accessible from the outside world.
Of course that would require attention to possible tricky files (re-encoding should be a must... even though that would make animated gif a little hard to deal with unless we can rely on Image Magick), but it would clean up a lot of mess. IMO.

Not just animated GIFs. You'd probably increase the file size of just about any file I'm likely to attach. To quote a bit of my attachment philosophy (but it's equally applicable to avatars).

A screenshot of your comment is 16kB in PNG. Subsequently running pngquant gives a 6.2kB result with no discernible loss in quality. A libjpeg optimized JPEG looks alright at 14-18kB, but it has some relatively minor artifacts. You can easily reach about 6kB with JPEG as well, but the artifacts then become really distracting to the point where it looks more like one of those illegible CAPTCHAs.
These results indicate that the system should check how filesize compares between e.g. carefully crafted PNGs and its own low-quality JPEGs, otherwise it shoots itself in the foot (emphasis added). For that matter, it really shouldn't add another layer of noise to a properly optimized JPEG either. In the past I've uploaded a JPEG to Facebook, which consequently made the file bulkier and uglier.
Above all, however, this blog is not Facebook. Like I indicated before, screenshots are doubtless the primary use case, not photos. I'd say simply reject all images over 200kB, or possibly even as little as 50kB. Give some pointers about how to optimize files, but don't let the system muck about with it. I know, tough love, but I see no added value in shrunk low-quality JPEG images.

Well, it's not that you have an infinite amount of avatars, and usually are just tiny crappy images anyway, not 5Mpx photo, just tiny 150x150px simple images of about... 20kb? Multiplied, in the worst case, by the number of members of your board. And let's not forget that if the avatar is bigger than the defined size, it is resized (with GD or IM), so it doesn't really change that much, unless you resize all the avatars of your members... are you?
Have avatars in the attachments system is a P.I.T.A. because it forces us to query the database any time we need to know the avatar of a user, having the avatars directly accessible from the outside with a defined naming scheme (e.g. {id_member}_avatar_b.png, {id_member}_avatar_m.png, {id_member}_avatar_s.png for big, medium, small) would give us the option to even forget about the img tag and use instead CSS for avatars as well (no idea if it is worth, just an option).

Oh, there really shouldn't be any special DB queries on a per avatar basis. That's just stupid. ;) The only thing that makes sense is something like a has_avatar column for a little check where avatars are displayed.
On your 150x150px, I'd say that with "HiDPI" monitors being standard now[1] that should really be x2 with e.g. srcset and sizes (and some kind of JS polyfill for browsers that don't support this stuff natively). Generating the "regular" size image is something the server should probably do. My concern with image size is page loading time and (mobile) data waste, not server storage space.
Taking my own avatar with a purposefully reduced color palette (for artsy reasons) on ElkArte.net as an example.

The regular optipng -o7 PNG is 15.8 kiB while the pngquant version is 8.2 kiB. Resaving it with ImageMagick results in 15.8 kiB again. So even if everyone had my minuscule avatar, that might easily approach over 200 kiB extra per forum page, because who goes with the extremely low default of 15 posts per page anyway? =P
$ du -h avatar.png
16K	avatar.png
$ pngquant avatar.png
$ du -h avatar-fs8.png
8.0K	avatar-fs8.png
$ convert avatar-fs8.png avatar-resaved.png
$ du -h avatar-resaved.png
16K	avatar-resaved.png

And since JPEG results in quality loss, imo as a rule of thumb only PNG is acceptable and nothing should be done if the resulting image after processing is of a bigger size than the original. Unfortunately, as far as I'm aware PHP only typically comes with ImageMagick modules and nothing like OptiPNG. pngquant is also unacceptable because that is (or easily can be) lossy, and it's not available anyway.
tl;dr Some people optimize their images and undoing their work Facebook style is like a slap in the face. Even more so because ElkArte, like its relative Wedge, is "like Facebook, but not for dummies" (source).
[1] I might be getting ahead of myself there, but I've had mine for over a year and it's fantastic.

Yeah I really wanted to eliminate the db query stuff in 1.0 but there were bigger problems to fix.
I'd like to see Avatars with a thumbnail (120x120?) and normal (250x250?) sizes, just like attachments.  The thumb is used (and css smaller ones of that thumb) as needed in most places, board index, etc
In some areas, like profile, the thumb links to the larger image, like Github does as well as some other forum packages.
The file-size is an interesting item ... could check to see if the created is > what was uploaded and act accordingly but I can see some issues with that as well.

This was addressed in 2.0

authors: Frenzie Spuds emanuele45

repo: elkarte/Elkarte


text:
convert all sql IFNULL to COALESCE

Crafting a regex to search with is difficult.

/me feels like a search&replace went somehow bad.


text:
opening an exclusive window on hyprland crashes it [BUG]

Checklist before submitting an issue

[X] I have searched through the existing closed and open issues for eww and made sure this is not a duplicate
[X] I have specifically verified that this bug is not a common user error
[X] I am providing as much relevant information as I am able to in this bug report (Minimal config to reproduce the issue for example, if applicable)

Description of the bug
My configuration is rather simple.
(defwindow bar
           :monitor 0
           :geometry (geometry :x "0%"
                               :y "97.5%"
                               :width "100%"
                               :height "2.5%"
                               :anchor "top center")
           :stacking "fg"
           :exclusive true
           :namespace "eww_bar"
  "wyli")

a simple what should be bar that takes up the bottom strip of the screen.
However, when I run this on hyprland, this first resets the screen so that I can only see the wall paper and the bar at the bottom. And then upon further interaction (when i attempt to spawn a kitty terminal with a keybind) crashes hyprland and sends me back to sddm's login screen.
This does not occur when it is set as :exclusive false
In plasma's wayland variant. this works as expected and there is a bar that can also be focused on.
furthermore, eww log only shows this.

Reproducing the issue
On endeavour os using the linux zen kernel 6.2.10-zen1-1-zen
build eww using the wayland feature flag
cargo build --release --no-default-features --features=wayland
set your ~/.config/eww.yuck as
(defwindow bar
           :monitor 0
           :geometry (geometry :x "0%"
                               :y "97.5%"
                               :width "100%"
                               :height "2.5%"
                               :anchor "top center")
           :stacking "fg"
           :exclusive true
           :namespace "eww_bar"
  "wyli")

and clear eww.scc
start the eww daemon
eww daemon
open the bar
eww open bar
Expected behaviour
For Hyprland to not remove all windows and then crash when opening an eww window and provide exclusive space to the bar.
Additional context
neofetch for additional system information:

the bar:

I also forgot to mention the additional debug logs if that may help
(eww:233501): Gtk-WARNING **: 23:05:40.596: Theme parsing error: gtk.css:1649:16: '-gtk-icon-size' is not a valid property name

(eww:233501): Gtk-WARNING **: 23:05:40.596: Theme parsing error: gtk.css:1652:16: '-gtk-icon-size' is not a valid property name
 2023-04-29T15:05:40.610Z DEBUG eww::server > Initializing script var handler
 2023-04-29T15:05:40.628Z INFO  eww::ipc_server > IPC server initialized
 2023-04-29T15:05:41.928Z DEBUG eww::ipc_server > received command from IPC: Ping
 2023-04-29T15:05:41.928Z DEBUG eww::ipc_server > Waiting for response for IPC client
 2023-04-29T15:05:41.928Z DEBUG eww::app        > Handling event: NoOp
 2023-04-29T15:05:41.928Z DEBUG eww::ipc_server > received command from IPC: OpenWindow { window_name: "bar", screen: None, pos: None, size: None, anchor: None, should_toggle: false }
 2023-04-29T15:05:41.929Z DEBUG eww::ipc_server > Waiting for response for IPC client
 2023-04-29T15:05:41.929Z DEBUG eww::app        > Handling event: OpenWindow { window_name: "bar", pos: None, size: None, anchor: None, screen: None, should_toggle: false, sender: DaemonResponseSender(UnboundedSender { chan: Tx { inner: Chan { tx: Tx { block_tail: 0x7fe7d8001570, tail_position: 0 }, semaphore: Semaphore(0), rx_waker: AtomicWaker, tx_count: 1, rx_fields: "..." } } }) }
 2023-04-29T15:05:41.929Z INFO  eww::app        > Opening window bar
Gdk-Message: 23:06:11.909: Error reading events from display: Broken pipe

Hyprland crashes after
2023-04-29T15:05:41.929Z INFO  eww::app        > Opening window bar
furthermore, the exact signal given is
fish: Job 1, 'Hyprland' terminated by signal SIGABRT (Abort)play error: Connection reset by peer_Tp&, const _Tp&) with [_Tp = double]: Assertion \!(__hi < __lo)` falied.

@vaxerski, I assume this is more of a hyprland issue than an eww issue 🤔

You've got the nerve to say my software has issues 😤

authors: elkowar vaxerski wylited

repo: elkowar/eww


text:
Login trouble

Hi :)
I'm having issues logging in the default API server from my laptop. I believe I had registered an account from another machine but all login attempts from laptop result in:
atuin login -u philn -p snip-is-not-real-password-dont-try-yourself
Please enter encryption key [blank to use existing key file]: snip
Error: invalid login details: user not found

Location:
    /var/home/phil/.cargo-home/registry/src/github.com-1ecc6299db9ec823/atuin-client-13.0.1/src/api_client.rs:83:9

Can you check if your API server db has a philn user?
I apologize in advance if this isn't the right forum, we can follow-up by e-mail if needed.

Hey! Drop me an email or DM on discord and we can sort it out there
I'll need to ask a few questions to confirm you are you, then we can sort it out

authors: ellie philn

repo: ellie/atuin


text:
panic: unknown node type: 'BuiltinAttr 0x10db7b0 <> Inherited Implicit 749'

Hey, I have this problem:
`panic: unknown node type: 'BuiltinAttr 0x10db7b0 <> Inherited Implicit 749'
goroutine 13 [running]:
github.com/elliotchance/c2go/ast.Parse({0xc0002c6549, 0x3d})
/home/smayer/go/pkg/mod/github.com/elliotchance/c2go@v0.26.10/ast/ast.go:294 +0x22d4
main.convertLinesToNodes({0xc0002ce5f0, 0x1c, 0x0?})
/home/smayer/go/pkg/mod/github.com/elliotchance/c2go@v0.26.10/main.go:89 +0x115
main.convertLinesToNodesParallel.func1.1({0xc0002ce5f0?, 0x0?, 0x0?}, 0x0?)
/home/smayer/go/pkg/mod/github.com/elliotchance/c2go@v0.26.10/main.go:113 +0x39
created by main.convertLinesToNodesParallel.func1
/home/smayer/go/pkg/mod/github.com/elliotchance/c2go@v0.26.10/main.go:111 +0x1a5`
Can you help me with that ? I just can't get any further here.
Best regards

Hi,
Is there any solution for this or similar panic?
What does it mean?
What does the number after Implicit mean. What will the value 996 mean?
Regards,
Rajeev


text:
Durability (& reliability) versus performance

First I'd like to say I like the decision to strictly conform to a (modern) SQL standard. I think this might be one of the selling points - "it was tested against vsql" would have a huge meaning in the bright future I envision :wink:.
Here I'd like to discuss probably the biggest PITA any DB has to clearly decide and define. It's durability guarantees, i.e. a "fault model". This also determines the maximum achievable performance of the DB due to physical limitations.
So I always envisioned the following:

to have a DB API requiring one to specify on per-request basis whether it shall be treated as best-effort (i.e. no guarantee but presumably faster and with lower delays) or as guaranteed operation. See e.g. my rant https://github.com/redis/redis/issues/6200#issue-464233707 .
Note that best effort might to lead incorrect data compared to the surrounding global context but it must not lead to internally incorrect data within a transaction - e.g. if in one transaction I fetch two different rows from two different tables it still must guarantee that the data (i.e. both rows) returned are exactly the data from the point in time when the transaction began (i.e. mutually correct).

Guarantee durability in the very maximum technically possible way POSIX allows us to and the knowledge of HW-originated errors allows us to. Namely the same fault model as TigerBeetle has. SQLite3 allows almost for what TigerBeetle does (e.g. commit both the parent directory structure as well as the DB file itself and then fsync) but there are still some rough corners.

The first step would be to focus on calling fsync and waiting for it to finish (see below) after each transaction which has the potential to modify data.
Note also that Linux fsync is synchronous (and will stay so in the upcoming years) but on many other systems it's asynchronous with system-specific calls to wait for its return.
What do you think about implementing both points (1) and (2)?

First I'd like to say I like the decision to strictly conform to a (modern) SQL standard. I think this might be one of the selling points - "it was tested against vsql" would have a huge meaning in the bright future I envision 😉.

Thanks! Despite the 1700 pages that describe just part of the base SQL language, it's amazing how much is left to the "up to the database implementation". Still, it is a strong foundation I'll be able to follow for a while yet.

to have a DB API requiring one to specify on per-request basis whether it shall be treated as best-effort (i.e. no guarantee but presumably faster and with lower delays) or as guaranteed operation. See e.g. my rant ACID & strict serializability versus best effort on a per request basis redis/redis#6200 (comment) .

What does a request mean in this case? It could be a single query or a single roundtrip that might contain multiple (read or write) queries? Would this be affected by BEGIN/COMMIT/ROLLBACK passed in different roundtrips?

Note that best effort might to lead incorrect data compared to the surrounding global context but it must not lead to internally incorrect data within a transaction - e.g. if in one transaction I fetch two different rows from two different tables it still must guarantee that the data (i.e. both rows) returned are exactly the data from the point in time when the transaction began (i.e. mutually correct).

Isn't this the motivation for READ UNCOMMITED serialization mode? Where a reading query is blocked by nothing, but may include some rows that should not be visible. I imagine this is great for scenarios like reporting queries, that might go over many rows where absolute correctness is not the goal, but rather just to get it done despite the inflight rows.

Guarantee durability in the very maximum technically possible way POSIX allows us to and the knowledge of HW-originated errors allows us to. Namely the same fault model as TigerBeetle has. SQLite3 allows almost for what TigerBeetle does (e.g. commit both the parent directory structure as well as the DB file itself and then fsync) but there are still some rough corners.

This is a more interesting point of discussion in my opinion. Certainly one extreme is to fsync everything and always. However, even the file system and hardware itself might not give these guarantees as there as several layers between the software and physical storage that may cache/write later that could be influenced by a poorly timed power failure.
Without getting into the weeds too much, I think there is a reasonable balance where we should trust the fsync (if it says it's been written) and treat all queries as atomic and requiring an fsync at the end always. That is, a modification (such as a UPDATE) requires all dirty pages to be flushed before the query can be returned.
Since there is no shared memory, hard flushing on basically all operations is required. Even an incomplete transaction would probably not be able to keep dirty pages beyond a single query for risk of page conflicts that might happen when they get written later.
That being said, this allows the file system to be the database tuning. Modern file systems can treat an fsync like a memory update and as long as the machine can guarantee that page gets written eventually and all other processes see the same virtual page in memory, it can avoid writing to the medium until later. I suspect this is why the file system benchmarks are shown as being as fast (or even faster!) than the memory-only runs: https://github.com/elliotchance/vsql/blob/main/docs/benchmark.rst#results

to have a DB API requiring one to specify on per-request basis whether it shall be treated as best-effort (i.e. no guarantee but presumably faster and with lower delays) or as guaranteed operation. See e.g. my rant ACID & strict serializability versus best effort on a per request basis redis/redis#6200 (comment) .

What does a request mean in this case? It could be a single query or a single roundtrip that might contain multiple (read or write) queries? Would this be affected by BEGIN/COMMIT/ROLLBACK passed in different roundtrips?

A request is a collection of commands determined by the user as "one request". In its simpliest form (and accounting for the absolute vast majority) it's one transaction. But the user can determine that e.g. two consecutive commands can be treated as best effort and they should be understood as a special type of transaction wrapping the inner commands.

Note that best effort might to lead incorrect data compared to the surrounding global context but it must not lead to internally incorrect data within a transaction - e.g. if in one transaction I fetch two different rows from two different tables it still must guarantee that the data (i.e. both rows) returned are exactly the data from the point in time when the transaction began (i.e. mutually correct).

Isn't this the motivation for READ UNCOMMITED serialization mode? Where a reading query is blocked by nothing, but may include some rows that should not be visible. I imagine this is great for scenarios like reporting queries, that might go over many rows where absolute correctness is not the goal, but rather just to get it done despite the inflight rows.

Yeah, in a sense it's a bit similar but still it's quite different :wink:. Generally what I mean by best effort vs guaranteed is just about delay and trading it for fairness. Suppose I have 4 incoming transactions (each representing a separate request) on the server in an incoming buffer, all of them SERIALIZABLE. But they are of different kinds: best effort, guaranteed, best effort, guaranteed (in this order).
Now suppose the server will start executing first (best effort) transaction and during this execution finds out that the next transaction (guaranteed) would get delayed if it proceeded with the current (best effort) transaction. In that case it'd drop the best effort transaction (rolling it back) and continued only with guaranteed transactions while dropping & cancelling (i.e. notifying the client about aborted transaction) all best effort transactions on the way until it can again keep up with guaranteed transactions already accepted into the incoming buffer.
Of course, if there are only best effort transactions in the buffer, then we'll proceed with processing the oldest ones and just drop one or two most recent ones from the buffer to make space for a newly incoming one (this artificially made space ensures guaranteed ones are at least partially accepted even under high load).
Note this algorithm couldn't be implemented exactly this way to work efficiently. It's just to showcase the idea :wink:. In practice you'd probably want to use two separate buffers (one for best effort and one for guaranteed requests) and then in a work-stealing fashion choose which one to process, etc.

This is a more interesting point of discussion in my opinion. Certainly one extreme is to fsync everything and always. However, even the file system and hardware itself might not give these guarantees as there as several layers between the software and physical storage that may cache/write later that could be influenced by a poorly timed power failure.
Without getting into the weeds too much, I think there is a reasonable balance where we should trust the fsync (if it says it's been written) and treat all queries as atomic and requiring an fsync at the end always. That is, a modification (such as a UPDATE) requires all dirty pages to be flushed before the query can be returned.
Since there is no shared memory, hard flushing on basically all operations is required. Even an incomplete transaction would probably not be able to keep dirty pages beyond a single query for risk of page conflicts that might happen when they get written later.
That being said, this allows the file system to be the database tuning. Modern file systems can treat an fsync like a memory update and as long as the machine can guarantee that page gets written eventually and all other processes see the same virtual page in memory, it can avoid writing to the medium until later. I suspect this is why the file system benchmarks are shown as being as fast (or even faster!) than the memory-only runs: https://github.com/elliotchance/vsql/blob/main/docs/benchmark.rst#results

Yep, these are all interesting problems. There are some tricks to force a sooner writing to disk. But this doesn't change anything on the fact, that it's system-specific how to determine whether fsync() already finished or not. Linux is the only exception I know about which really guarantees (PG devs had very serious discussion with kernel devs about this few years ago), that after fsync() returns it's actually on disk. This is of course different from flush() (or alike) which doesn't fsync() and is thus subject to all the non-guarantees you talk about.
Btw. the benchmarks you did are actually something more or less to expect - I'm pretty certain it's because you don't wait for fsync() to actually finish on macOS and only wait for the return from the fsync() function call which is on macOS an asynchronous call running in background (so you should use macOS-specific call to find out whether it finished or not or use macOS-specific synchronous alternative if available).

authors: dumblob elliotchance

repo: elliotchance/vsql


text:
Adds .env.example

No secrets were exposed in the creation of this PR.

👍

authors: colinta steam

repo: ello/ello-ios


text:
Zoom to fit resulting in client side crash for some large pipelines

In Watson Studio pipelines, we're seeing a client side crash when using the zoom to fit function on some very large pipelines:

The crash does not happen every time zoom to fit is invoked, only some of the time, but we haven't been able to isolate why.  I thought it might be related to the validation / save flow, but we do not have any issue resizing while validation is running on smaller pipelines.
This was discussed previously in IBM slack here: https://ibm-analytics.slack.com/archives/C598XEX8S/p1650897161402039.
The associated IBM internal issue is: https://github.ibm.com/AILifecycle/tracker/issues/3340.
When the crash occurs, the console errors look like this:

The associated pipeline json has been provided in the internal issue here: https://github.ibm.com/AILifecycle/tracker/issues/3340#issuecomment-43517349.
Please advise if you need any additional information from our side.  Thanks.

@chrisj-ibm
I believe this is caused by the zoom to fit calculating a zoom scale amount which is smaller than that allowed by the schema. This can happen with a large number of nodes so the nodes occupy a lot of coordinate space. This smaller-than-allowed scale value is then saved in the pipeline flow document -- I'm assuming you are running with the config property enableSaveZoom set to "Pipelineflow".  When the pipeline flow is loaded back into common-canvas the schema validation throws an error because it sees the scale amount is too small.
I have fixed it by making the pipeline flow, that is returned by common-canvas, always conform to the schema. When do you need the fix. I can do a patch release next week if necessary.

@tomlyn A patch release next week would be amazing if you can contain it.  We would like to get this fix into our 4.5 release, with a target date of next Friday for our release candidate.  If not containable, we can document this particular issue as a known issue.  Thanks so much for the prompt support, as always.

@chrisj-ibm
OK I'll see what I can do.
Are you running with schemaValiation config property set to true when running in production? That feature can slow down loading of pipeline flows considerably when there are a lot of nodes.

Are you running with schemaValiation config property set to true when running in production? That feature can slow down loading of pipeline flows considerably when there are a lot of nodes.

Yes, appears so.  I will discuss this further with Rafal to see if we want to revise our approach here.

@chrisj-ibm
Hi Chris -- I realized my fix to the code might not work 100% of the time so I decided to go in a different direction to resolve this issue. So now I have changed the pipeline schema file to remove the zoom scale restrictions. This means that any zoom scale amount in the pipeline flow document can be read in, with schema validation switched on, without a problem.
To pick up this change you don't need a patch release, you just need to do an npm install to refresh your node_modules which should pick up the latest @elyra/pipeline-schemas (v3.0.57) which will contain the change.

This is fixed by a change to the pipeline schema.

authors: chrisj-ibm tomlyn

repo: elyra-ai/canvas


text:
Write tests for new bottom panel

We need tests that check whether the new bottom panel is appearing correctly

Fixed

authors: nabilIbm tomlyn


text:
Python editor: current working directory behavior is unexpected

Create the following setup:

the file browser lists no files
create a python script script1.py that produces a file ./file1.txt
run script1.py in the editor. ./file1.txt is created in the same directory
create a subdirectory dir2
in dir2 create a python script script2.py that produces a file ./file2.txt
run script2.py in the editor. ./file2.txt is created in the parent directory

I do realize that when one runs python dir2/script2.py in a terminal window, cwd is ..  However, in JL I expected cwd to be the directory where the Python script is located, since a drill down in the file browser should be semantically equivalent to a cd dir2. The script name in the editor also lists script2.py not dir2/script2.py, which seems to imply that cwd is the location of the script, not the base directory in the file browser.
Related issue: https://github.com/elyra-ai/elyra/issues/1045

I suspect this could have something to do with how the editor is starting the kernel that will run the script.
@karlaspuldaro - I believe kernel launch from the editor can specify things like a path in addition to the kernel name.  Do you know if that's true and/or what parameters are allowed in the start request body?
When path is set, the server will, I believe, equate that to what will become the kernel process's working directory.

@kevin-bates Yes I think that's correct, according to ISessionOptions a path can be also passed in as in this example.

Thanks @karlaspuldaro.  For this issue, we might want to explore setting path to the directory (relative to the root) in which the python script is located.  This path will then get used as the cwd for the kernel.   The example shows it reflecting the notebook filename, but where it gets converted to the kernel_pathin session creation, a pure directory is tolerated.

@kevin-bates Makes sense, I can take a look at that.

Reassigning to try to get this to the 1.4 release

authors: karlaspuldaro kevin-bates lresende ptitzler

repo: elyra-ai/elyra


text:
Auto-arrange function in pipeline editor ignores note nodes

Describe the issue
Auto-arrange function in pipeline editor ignores note nodes
To Reproduce
Create a pipeline with multiple nodes and notes, click on auto-arrange
Nodes are not arranged
Screenshots or log output
https://user-images.githubusercontent.com/5694071/148662097-863a8f63-b0a5-44a8-9579-e5225b2b97d3.mp4
Deployment information
Describe what you've deployed and how:

Elyra version: v3.2.2
Operating system: RHEL 8.3
Installation source: pypi
Deployment type: local (pypi venv)

Pipeline runtime environment
If the issue is related to pipeline execution, identify the environment where the pipeline is executed

Local execution

This is a Canvas functionality and should be transferred to that repo.

authors: lresende romeokienzler


text:
private PKI: optional trusted CA for HTTPS request.get in  Apache Airflow package operator catalog and  Apache Airflow provider package operator catalog

Is your feature request related to a problem? Please describe.
This is an extension of the enhancement request in https://github.com/elyra-ai/elyra/issues/2787 (BasicAuth and Proxy).
I tested with an enterprise-internal, noproxy Artifactory location that has anonymous access enabled. This led to another issue with https connections.
We have an enterprise-internal public key infrastructure for SSL Certificates of our repository servers, such as Artifactory and Harbor.
The main issue with https connections against those urls is that CA certificates issued by such a private PKI are not publicly trusted, which is an issue in client applications referencing the server url.
Thus, we get the following message when connecting the the, in our case, Artifactory Https Url
"[E 2022-06-24 06:11:24.955 ElyraApp] Error retrieving operator list from Airflow package  https://repo.private.domain/ui/native/folder/airflow_packages_core_operators/apache_airflow.py3-none-any.whl:  HTTPSConnectionPool(host='repo.private.domain', port=443):  Max retries exceeded with url: /ui/native/folder/airflow_packages_core_operators/apache_airflow.py3-none-any.whl  (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1125)')))"
Describe the solution you'd like
@akchinSTC
In Java applications running on openshift, we added the private CA / pem certificate via a secret or configmap and mounted it into a container-internal file system location that Java then added as trusted CAs.
https://docs.openshift.com/container-platform/4.8/networking/configuring-a-custom-pki.html#certificate-injection-using-operators_configuring-a-custom-pki
e.g. in the namespace, add an empty configmap like so:
https://github.com/trevorbox/reloader-operator/blob/f07d1858825cc8515f45c2cf03b84c23e994aa7e/helm/app/templates/configmap-trusted-cabundle.yaml
and mounting it into a location in the container that python than uses for request.get trust later
https://github.com/trevorbox/reloader-operator/blob/f07d1858825cc8515f45c2cf03b84c23e994aa7e/helm/app/templates/app-nginx-echo-headers.yaml#L50
The general idea is to go with the openshift standard of defining trusted PKI CAs / CA Bundles only once at a cluster level and then to have those additional CAs available in the configmap via injection, then in the container via reference.
It would be cool to have someone with Openshift know how verify this proposed approach.
Since private PKIs are not all that unusual in enterprise environments, we should look for a way to trust a private PKI root CA in python, with a good way to get it into the filesystem. In a first step, GUI-based only perhaps, but it would be better container filesystem-based.
I found the following with regards to python, last quarter of the article  https://realpython.com/python-https/
"If you want to avoid this message, then you have to tell requests about your Certificate Authority"
Describe alternatives you've considered
For our internal systems, we have no other way than enterprise-internal PKI
Additional context
Add any other context or screenshots about the feature request here.

The general idea is to go with the openshift standard of defining trusted PKI CAs / CA Bundles only once at a cluster level and then to have those additional CAs available in the configmap via injection, then in the container via reference.

This sounds like a pretty straightforward approach (I'll probably regret saying this later!). We'd have to provide the user (or admin, who installs JupyterLab/Elyra) with the ability to specify the mounted file system location where the certificates can be found. Not sure we'll manage to set up/get access to a system to fully test this out, but if we were to provide you temporarily with a custom build would you be able to deploy that in a sandbox for testing/feedback?

I have a sandbox I could use in the form of a namespace on an openshift 4.x Cluster, yes, I would gladly try it out then.

Patrik, for your part of the code and requests.get, I verified that when providing the ca-bundle file in pem Format in the form of root CA followed by, if any, intermediate CA pem, the SSLVerifyError disappears and the file can be downloaded.
response = requests.get(   ....   ....   verify='/opt/app-root/src/root_followed_by_intermediate_ca_pem.pem'   )
Thus, now we just need the jupyterhub-odh folks to allow mapping the configmap into the filesystem.

authors: ptitzler shalberd


text:
feat: add jina-v3 into model list

Checklist

[ ] Run tests locally to make sure nothing is broken using make test.
[ ] Run the formatter to format the code using make lint.

Adding datasets checklist

Reason for dataset addition: ...

[ ] I have run the following models on the task (adding the results to the pr). These can be run using the mteb -m {model_name} -t {task_name} command.

[ ] sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2
[ ] intfloat/multilingual-e5-small

[ ] I have checked that the performance is neither trivial (both models gain close to perfect scores) nor random (both models gain close to random scores).
[ ] If the dataset is too big (e.g. >2048 examples), considering using self.stratified_subsampling() under dataset_transform()
[ ] I have filled out the metadata object in the dataset file (find documentation on it here).
[ ] Run tests locally to make sure nothing is broken using make test.
[ ] Run the formatter to format the code using make lint.

Adding a model checklist

[ ] I have filled out the ModelMeta object to the extent possible
[ ] I have ensured that my model can be loaded using

[ ] mteb.get_model(model_name, revision) and
[ ] mteb.get_model_meta(model_name, revision)

[ ] I have tested the implementation works on a representative set of tasks.

@Samoed @KennethEnevoldsen i'll close my PR and focus on review and testing #1319 as it is already in a better state

repo: embeddings-benchmark/mteb


text:
Update URLs in package.json

The metadata still points to the old repository. Although GitHub does the redirect for us, might as well point to the proper place.

Thank you @locks.

authors: bertdeblock locks

repo: ember-cli/watch-detector


text:
Upstream strict syntax checks

[x] Block names must start with lowercase letters:
<FancyList>
  <:Foo>...</:Foo>
  ~~~~~~
  Syntax Error: <:Foo> is not a valid named block: `Foo` is not a valid
  block name
</FancyList>

[x] Named blocks cannot be self-closing:
<FancyList>
  <:foo />
  ~~~~~~~~
  Syntax Error: <:Foo> is not a valid named block: named blocks cannot be
  self-closing
</FancyList>

[x] Passing named blocks to HTML elements:

  <:foo>...</:foo>
  ~~~~~~
    Syntax Error: Unexpected named block <:foo> inside
 HTML element

[x] Mixing named blocks and other non-whitespace, non-comment content:
<FancyList>
  {{!-- comments are allowed --}}

  <:header>My Header</:header>

Some content

  ~~~~~
  Syntax Error: Unexpected content inside <FancyList> component invocation:
  when using named blocks, the tag cannot contain other content
</FancyList>

[x] Block params on component invocations with named blocks:
<FancyList as |item|>
~~~~~~~~~~~~~~~~~~~~~
Syntax Error: Unexpected block params list on <FancyList> component
invocation: when passing named blocks, the invocation tag cannot take block
params
  <:row>The {{item}}</:row>
</FancyList>

[x] Passing arguments, attribues or modifiers to named blocks:
<FancyList>
  <:header class="row">My Header</:header>
            ~~~~~~~~~~~
            Syntax Error: named block <:header> cannot have attribues or
            arguments
</FancyList>

[x] Passing the same named blocks more than once:
<FancyList>
  <:header>My Header</:header>
  <:header>It's me again!</:header>
  ~~~~~~~~~
  Syntax Error: Cannot pass named block <:header> twice in the same
  invocation
</FancyList>

<FancyList>
  <:else>The else block</:else>
  <:inverse>The inverse block</:inverse>
  ~~~~~~~~~~
  Syntax Error: Cannot pass named blocks <:else> and <:inverse> in the same
  invocation
</FancyList>

[x] Passing invalid arguments to {{yield}}, {{has-block}} and
{{has-block-params}} or passing anything other than a string literal for
the block name argument:
{{yield block="foo"}}
              ~~~~~
              Syntax Error: Cannot pass block named argument to {{yield}}

{{has-block this.block}}
            ~~~~~~~~~~
            Syntax Error: {{has-block}} can only accept a string literal
            argument

[ ] Other miscellaneous checks not directly related to named blocks (search the plugin code for assert(...) and check(...))

main and default are not aliases, so the error above doesn't not seem correct. main only existed as an internal name for the default block.
For inverse and else, this means upstreaming a change making them aliases, c? At the moment you cannot  use <:inverse> because internally rename inverse to else.
I am not sure what "Passing invalid arguments to {{yield}}…" is demonstrating. Is the block named argument saying that you cannot pass named arguments to yield other than to?

Can you explain why block params are prohibited?

Block params on component invocations with named blocks:
<FancyList as |item|>
~~~~~~~~~~~~~~~~~~~~~
Syntax Error: Unexpected block params list on <FancyList> component
invocation: when passing named blocks, the invocation tag cannot take block
params
  <:row>The {{item}}</:row>
</FancyList>

I think this is actually a very valid use-case and it's not apparent to me, why it should be forbidden.
Thanks. 🙏

Ah. Sorry. I looked at the RFC now and yes of course this restriction makes sense. You would yield block params on the blocks, not the root invocation.
<FancyList>
  <:row as |item|>The {{item}}</:row>
</FancyList>

This works.

Ah, was writing up a response xD Yes, exactly. You cannot use the implicit default block and named blocks at the same time, so you couldn't yield out the values.

This is done

This is done

authors: buschtoens chancancode locks


text:
Fix problema TAG Facebook (Issue #123)

Si potrebbe anche aggiungere un if nel caso il titolo della pagina non fosse presente ma mi è sembrato superfluo in quanto ogni pagina ha un suo titolo.

Hai ragione @mfortini il problema però è nella home dove verrebbe Terremoto Centro Italia | Terremoto Centro Italia.
E anche se usiamo il {{page.title | remove 'Terremoto Centro Italia'}} | {{site.title}} rimane comunque " | Terremoto Centro Italia" come titolo in home.

@mfortini  Corretto! :+1:

@mfortini  con {{page.title}} | {{site.title}} funziona si, il problema però rimane in home dove viene "Terremoto Centro Italia | Terremoto Centro Italia".

per risolvere lil bug della home potrebbe essere così:
{% if page.url == '/' %}{{ page.title }}{% else %}{{ page.title }} | {{ site.title }}{% endif %}

Grazie @tailot provo subito

Mi piace. Controllerei soltanto se ci sia una variabile tipo
site.baseurl con il link di base perché adesso abbiamo '/' ma non si sa
mai in futuro e poi si rompe tutto.
Il 30/08/2016 11:28, Vincenzo Tilotta ha scritto:

per risolvere lil bug della home potrebbe essere così:
{% if page.url == '/' %}{{ page.title }}{% else %}{{ page.title }} |
{{ site.title }}{% endif %}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/emergenzeHack/terremotocentro/pull/125#issuecomment-243384150,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDcHty9MFjlmuaE2RU5eyXK6SWMUVAsks5qk_ewgaJpZM4JwS2u.

@Pinzauti va corretto anche per il tag og:title altrimenti è anche li

sisi avevo corretto solo il titolo per provare

Posso fare mette?

Merge ?

authors: Pinzauti iltempe mfortini tailot

repo: emergenzeHack/terremotocentro


text:
problem with go imap compilation

Hi,
firstly, when I try:
$ go get -u github.com/emersion/neutron
I get:
# github.com/emersion/go-imap-idle
../go/src/github.com/emersion/go-imap-idle/client.go:28: cannot use res (type *Response) as type responses.Handler in argument to c.c.Execute:
	*Response does not implement responses.Handler (missing Handle method)
../go/src/github.com/emersion/go-imap-idle/response.go:13: undefined: imap.RespHandler
../go/src/github.com/emersion/go-imap-idle/response.go:27: select case must be receive, send or assign recv
../go/src/github.com/emersion/go-imap-idle/server.go:17: undefined: imap.ContinuationResp
# github.com/emersion/go-imap-quota
../go/src/github.com/emersion/go-imap-quota/client.go:28: invalid operation: c.c.State & imap.AuthenticatedState (mismatched types func() imap.ConnState and int)
../go/src/github.com/emersion/go-imap-quota/client.go:46: invalid operation: c.c.State & imap.AuthenticatedState (mismatched types func() imap.ConnState and int)
../go/src/github.com/emersion/go-imap-quota/client.go:56: cannot use res (type *Response) as type responses.Handler in argument to c.c.Execute:
	*Response does not implement responses.Handler (missing Handle method)
../go/src/github.com/emersion/go-imap-quota/client.go:72: invalid operation: c.c.State & imap.AuthenticatedState (mismatched types func() imap.ConnState and int)
../go/src/github.com/emersion/go-imap-quota/client.go:82: cannot use res (type *Response) as type responses.Handler in argument to c.c.Execute:
	*Response does not implement responses.Handler (missing Handle method)
../go/src/github.com/emersion/go-imap-quota/commands.go:100: undefined: utf7.Encoder in utf7.Encoder.String
../go/src/github.com/emersion/go-imap-quota/commands.go:119: undefined: utf7.Decoder in utf7.Decoder.String
../go/src/github.com/emersion/go-imap-quota/responses.go:78: undefined: imap.RespHandler
../go/src/github.com/emersion/go-imap-quota/responses.go:127: undefined: utf7.Decoder
../go/src/github.com/emersion/go-imap-quota/responses.go:155: undefined: imap.RespHandler
../go/src/github.com/emersion/go-imap-quota/responses.go:127: too many errors

My environment:
Ubuntu 17.10 64bit
go version go1.8.3 linux/amd64
nodejs --version v6.11.4
npm --version 3.5.2

secondly, when I try:
cd $GOPATH/src/github.com/emersion/neutron
I get:
bash: cd: /src/github.com/emersion/neutron: No such file or directory

Okay, that's why go dep is really needed. Will fix this tonight.

Seems more complicated than I thought. Apparently macaron.v1 is broken.

If I can help in anything, like test something, I would like to do it.

repo: emersion/neutron


text:
New image API in 0.23 doesn't fit: static uri

Why from_bytes takes a static uri?
pub fn from_bytes(uri: impl Into<Cow<'static, str>>, bytes: impl Into) -> Self {
This completely breaks my usages so I've to stay with RetainedImage.
And in general are the lifetimes really needed here? They only complicate things IMO.
Another thing that makes the new API less good is that some things require the image to be mutable.
Like image.tint() - this is a paint option, not an image altering option. The new image struct contains data that doesn't belong there. It may be good for java/c/c++ to throw everything into one object but with rust/borrowing this requires more thought. I've places where I don't have a mutable image but I need the paint options.
What should I do there? (ATM I use cloning)
The Image API needs more changes - this way it's way less usable than the old one in my opinion. Even if it's nicer in some cases overall it's not as usable and that is what counts.
General note: The Image API requires too much cloning.
For example:
ui.add(ImageButton::new(IMAGE.clone())).clicked()
Because ImageButton consumes the image. Doesn't really seem to be efficient.

Ok fixed the main aissue.

repo: emilk/egui


text:
TextEdit::singleline: lost_focus not triggered on enter key

Hi,
For some reason, the following code doesn't panic when the enter key is pressed while the text field is focused:
let mut my_string = String::new();
let response = ui.add(egui::TextEdit::singleline(&mut my_string));
if response.lost_focus() && ui.input().key_pressed(egui::Key::Enter) {
    panic!()
}

If I remove response.lost_focus() &&, panic is executed (but also if the text field isn't focused).
When I press enter, the cursor flashes one time, so something seems to happening, but lost_focus isn't triggered.
I'm using egui_miniquad (in case this could be relevant).

To add on to this, for now response.has_focus() seems like a suitable alternative, and then subsequently calling response.surrender_focus() if you rely on the loss of focus.
For some reason, however, the response.clicked() event also triggers when you press Enter, which seems like incorrect behaviour.

Good find! The problem is that Enter is treated as a click (so you can click selected buttons with enter), and so the TextEdit widget incorrectly thinks it was clicked and should gain focus (even though it just lost it).

authors: Hirtol d4h0 emilk


text:
Move default fonts to new crate epaint_default_fonts

This allows license checking tools to omit the OFL and UFL licenses when default_fonts are turned off.
There was some discussion of versioning on the original issue; I have chosen to label this version as 0.28.1 to match the other crates. Happy to adjust the version as needed.

Closes https://github.com/emilk/egui/issues/2321
[X] I have followed the instructions in the PR template

We should also add epaint_default_fonts to https://github.com/emilk/egui/blob/64d5f948e43b4be93e3a4541c87dcce74c948df4/.github/workflows/labels.yml#L32

Ok, comments addressed!

Thanks!

authors: alex-pinkus emilk