text:
Angular UI Router

Hi,
I see that single spa works with UI router on AngularJS.  Are there any issues integrating to UI Router with Angular 8/9?  Looks like the documentation refers to the inbuilt router.

Hey @dmeagor
It's been 7 months since this issue was opened and no one commented here thus I can take a look if it works correctly.
What do you mean by Are there any issues integrating to UI Router with Angular 8/9??

Does it mean that you have 2 coexisting microfrontends: the first microfrontend uses AngularJS and the second one uses Angular 8/9?
Does it mean that you've got 1 microfrontend written in AngularJS but components are written in new Angular and downgraded via ngUpgrade?

Hey @dmeagor
It's been a long time since this issue has been inactive. I really wish to help you but unfortunately I didn't get enough information.
Feel free to re-open it if you have something to add.

authors: arturovt dmeagor

repo: single-spa/single-spa-angular


text:
fill flutter text widget with whitespace

before:
Text(
  "hi".length < 4 ? "hi" + "\u2003\u2003" : "hi",
  style: TextStyle(fontSize: 14),
),

after:
TextWhitespace(
  "hi"
  style: TextStyle(fontSize: 14),
),

better:
Text(
  whitespace("hello", 10)
  style: TextStyle(fontSize: 14),
),

https://github.com/sinkcup/dart-whitespace

source: gharchive/issue

repo: sinkcup/flutter-text-whitespace

license: MIT

license_type: permissive

license_source: github-api


text:
Macros - preprocessing support

Currently #define and other macros do not work.

I'm trying to implement #define according to this.
This is what I have right now:
preproc_def: $ => seq(
    '#', 'define', $.uname, $.token_string
),

I've never worked with tree-sitter before, so I'm not sure if use of the uname is correct here and what exactly token_string should be.

I saw that Promela uses macros, but unfortunately I think they would be too hard to support fully, because it uses the C preprocessor so in theory it will have to support the full C expression grammar.

authors: filipfigzalski siraben

repo: siraben/tree-sitter-promela


text:
Kibana 5 - Webhook over HTTPS

Hello everyone!
I'm currently testing sentinl on Kibana 5. The problem is I can't send my webhook action over https by using options.protocol as suggested in #108 by adding few lines in actions.js, and i got the following error
Unhandled rejection Error: Protocol "https" not supported. Expected "http:"
    at new ClientRequest (_http_client.js:55:11)
    at Object.exports.request (http.js:31:10)

The workaround for me was changing the line in actions.js to var http = require('https')
I'm new to node js development, and from the error log i see, is it correct that node http api doesn't support https protocol? does the project plans on using the node https api?

Actually, "protocol" option has not been yet added on sentinl 5.0 branch.

We're getting there! SENTINL 5.x Release time should be by May.

@lmangani
Great news !
I'm impatient to test it !

authors: fbaligand lmangani rifqifatih

repo: sirensolutions/sentinl

license_source: bigquery


text:
Implements #813 - Add option to panic in test.NewNullLogger

Add a field in Logger for Exit implementation which defaults to Exit().
This can be used in NullLogger() to replace calls to os.Exit() with panic()

Hi @caalberts, thanks for your contribution. There is something important which needs to be changed in order to be backward compatible if we want to merge this PR in a v1 release.
With this implementation, the static declaration of a logger like
log = &Logger{
      Out: os.Stderr,
      Formatter: new(JSONFormatter),
      Hooks: make(LevelHooks),
      Level: logrus.DebugLevel,
}

will be broken and execute a null pointer upon a Fatal call.
We could add instead a method Exit on Logger object which will then check the value of the Exit field and call appropriatly the default method if nil.

Yeah I see what you mean. I can see how having a Exit method on the logger object will keep backward compatibility.
To keep the handlers executed, this Exit method will execute handlers before the final exit, be it os.exit() or panic().
We still need to keep logrus.Exit function around though, because it is exported.

@dgsb Let me know if these changes are ok

@caalberts thanks for your contribution

source: gharchive/pull-request

authors: caalberts dgsb

repo: sirupsen/logrus

license: mit


text:
Update README.md

Enhancing Readability.

Why would you make such a pull request ? :-1:

Sorry but I don't accept PR for docs


text:
Reference export

Is your feature request related to a problem? Please describe.
I'd like to be able see which tokens have been used where. Ideally on a component level. With traditional figma colors for example you can see the name and then use that to use the correct variable upon implementation. With the figma tokens plugin the value just gets set and I can't see which token has been used, and so I don't know which token to use when implementing a feature.
Describe the solution you'd like
An option to maybe export an abstract representation of references. Select a component and see an abstract hierarchy with for example the auto layout options, boxes, text and vectors as well as the tokens used for the values involved.
I know something like this is possible because the plugin already has these references (it updates the values in the document whenever you change a token). On top of that I know figma exposes these values with their API because I've built my own plugin to generate code (auto attributes based on variants and enums based on those values). I didn't use tokens, but my need for tokens lead me to Figma tokens.
Describe alternatives you've considered
I've considered grouping every value for every component. So button.primary.backgroundColor and button.primary.verticalPadding for example and then using those when implementing the button's primary variant. I don't like this because the components are then part of a pretty large list of tokens in an already (imo) unwieldy modal.
On top of that I also don't like the idea in case of specific screens. I could technically separate those out but it will quickly become a lot to keep track of.
Additional context
I think a feature like this could eventually lead to a pretty reliable code generator (probably not this plugin, but another plugin that depends on this one). Since I already have logic to figure out variants, enums, types, hierarchy in an AST this could be used to generate anything from swiftUI to react components (Style Dictionary but including code).
If this sounds useful to you as well and I'm not just dreaming about some silyl feature that makes no sense I'd be happy to help out with this. I'd need some insider info on the current structure of the project and maybe some sparring about the idea. There's only so much I can put in a github issue without making the readers fall asleep.

@RWOverdijk This sounds really awesome! Sorry for taking so long to respond. I think this is something that would be really incredible to work on, would gladly assist you in getting started or discussing this in a zoom call.


text:
lug configuration

I would recommend create two lug configuration. One for bootstrapping our mirror site, by using mirrors.tuna and mirrors.ustc. And another one for production use, where we synchronize files directly from official upstream.

[ ] lug config for bootstrapping
[ ] lug config for production
[ ] validate config with GitHub Action (refer to mirrors-docker repo for current CI config)

Please double check if the configuration contains any sensitive information (e.g. username/password of rsync endpoint). If so, please create issue for them.

Please include all repos in ftp.sjtu in our new mirror site.

working on "config for bootstrapping" now

[ ] lug config for bootstrapping
[x ] lug config for production   (almost done)
[ ] validate config with GitHub Action (refer to mirrors-docker repo for current CI config)

For the remaining two tasks, we now have a different approach.

We could sync directly from ftp.sjtu.edu.cn. Just set the source to be rsync://ftp.sjtu.edu.cn/<name>, and I'll contact the admin to expose them in rsync.
It seems that we haven't got a mature way to validate lug config. So you could just use tools to verify if it is a validate yaml file.

authors: doctormin skyzh

repo: sjtug/mirror-docker-siyuan


text:
Bitbucket:290 ツールバーのアイコン上にファイルをD&Dした際の挙動を変更可能にする

ほったん: https://groups.google.com/forum/#!topic/pe_development/Lw6QO7dclH0
現行では指定して実行ダイアログが表示される。
これを設定することにより

指定して実行ダイアログを表示
起動オプションに設定してアイテムを実行

を実現する。

BitBucket から移植

項目
内容

元課題
#290

起票日時
2015-08-16T16:15:25Z

起票者
sk_0520

resolved #290
→ 《cset 51e07c2071b7》

BitBucket から移植

項目
内容

元コメント
#290 コメント

コメント日時
2015-09-17T23:15:12Z

コメントユーザー
sk_0520

Removing component: PeMain-Toolbar (automated comment)

BitBucket から移植

項目
内容

元コメント
#290 コメント

コメント日時
2020-02-24T21:18:24Z

コメントユーザー
sk_0520

license: WTFPL


text:
Prototype sometimes doesn't get applied to the element when using native method

When defaulting to use document.registerElement to apply the prototype to the custom element, the prototype is sometimes not available in the ready() callback

Fixed in #326

repo: skatejs/skatejs


text:
Tip: busybox-w32 shell option -d allows you to specify the current directory of the new shell

A helpful feature I just found:

busybox-w32 has an undocumented shell option -d which allows you to specify the current directory of the new shell. This has to appear before the -s or -c options.

Source: https://github.com/rmyorston/busybox-w32/issues/211#issuecomment-792578645
With ..\w64devkit\bin in your PATH you could do the following in Windows PowerShell or cmd :
> sh -d \path\to\working\folder

and get in your busybox-w32 session:
/path/to/working/folder $

Yes, but I've also written:

Ssssh! Don't tell everyone, that's supposed to be undocumented.

and

I won't be sending a patch for the new ash options to upstream BusyBox. They'll remain non-portable oddities in busybox-w32 (until I can find a way of removing them, just to inconvenience anyone who's unwise enough to use them.).

You Have Been Warned.

authors: oboff rmyorston

license: Unlicense


text:
Add option to configure quiet zone

There are use cases, where predefined quiet zone is not desired. Currently,
there no way to configure it, only change hardcoded value.

I can implement it myself and send pull request (sorry for github slang)), but
it would be great to hear your answer and opinion before.

And thanks for the amazing library. The best golang QR library I've tried so
far. Also code is super easy to read and understand (especially after reading
code of other QR-encoding libraries).

Original issue reported on code.google.com by ivan.dan...@gmail.com on 24 Feb 2015 at 5:09

This has been fixed in https://github.com/skip2/go-qrcode/pull/24 . Borders are now made the minimum size possible. There's also now an option to disable borders entirely too.


text:
Поддержка и публикация версий

Хотим использовать этот пакет в своём решении для терминалов на Node.js
Хотелось бы периодических релизов и поддержки репозитория.
Могу взять поддержку на себя или помогать. Спасибо!

Это отличный вариант, т.к. библиотека была написана для разового проекта и доступа к оборудованию более нет, в этой связи поддержка становиться весьма затруднительной.


text:
Save and restore for tuneIn and spotify

Is it possible to add support for tuneIn and spotify for save/restore commands ?
What I want to achieveis to get back to the stream that was playing before cast command.
BTW: great project :)

I get
"Saving state of this kind of content is not supported" while trying to call save when tunein is streaming
so it looks like there is no cst.save_capability

TuneIn and Spotify use their own custom chromecast apps, so support for save/restore requires custom pychromecast controllers that know how to communicate with these apps.
AFAIK no such controller exists for TuneIn. A controller for Spotify is actually included in pychromecast, but looking at the code it does not seem to be capable of initiating playback of content.

authors: mcikosos theychx

repo: skorokithakis/catt


text:
Nested code blocks aren't handled properly

Describe the bug
Code blocks (triple backticks) nested into the top level code block (triple backticks) aren't handled properly — only the opening triple backticks are escaped and additional triple backticks are added at the end. Also, the language identifier is removed.
To Reproduce
Convert this:
# h1

```markdown

# h1

```python
foo = 'bar'
```

```

Expected behavior
*h1*

```markdown

# h1

\`\`\`python
foo = 'bar'
\`\`\`

```

Observed behavior
*h1*

```

# h1

\\`\\`\\`python
foo = 'bar'
```

```

```

TelegramError: 400: Bad Request: can't parse entities: Can't find end of Pre entity at byte offset 58
Additional context
Version 1.2.1

Quadruple backticks for the top level code block partially fixes the issue but the output is not expected either.
In:
# h1

````markdown

# h1

```python
foo = 'bar'
```

````

Out:
*h1*

```

# h1

\\`\\`\\`python
foo = 'bar'
\\`\\`\\`

```

Sounds like a bug, I'll check it but it will take some time

authors: nikogosovd skoropadas

repo: skoropadas/telegramify-markdown


text:
update privacy policy

I have added some text in the privacy policy section.

Share the link.

https://codervivek5.github.io/HealhUb/

You have done a good job.


text:
Set (or allow to be configured with) X509_V_FLAG_PARTIAL_CHAIN for openssl

From https://docs.openssl.org/1.1.1/man3/X509_VERIFY_PARAM_set_flags/#verification-flags
The X509_V_FLAG_PARTIAL_CHAIN flag causes intermediate certificates in the trust store to be treated as trust-anchors, in the same way as the self-signed root CA certificates. This makes it possible to trust certificates issued by an intermediate CA without having to trust its ancestor root CA. With OpenSSL 1.1.0 and later and set, chain construction stops as soon as the first certificate from the trust store is added to the chain, whether that certificate is a self-signed "root" certificate or a not self-signed intermediate certificate. Thus, when an intermediate certificate is found in the trust store, the verified chain passed to callbacks may be shorter than it otherwise would be without the X509_V_FLAG_PARTIAL_CHAIN flag.

It appears to me that Proton needs to be enhanced to support the flag or even make it the default behaviour, which appears to be fairly normal in other TLS implementations.
In the mean time, I believe you can "mark" an intermediate CA certificate to be treated as a trusted root anchor by OpenSSL.  You can do this at the time you create your trust store and do not need access to any of the private keys for the rootCA or intermediateCA.
It may be possible to just substitute this "marked" certificate where you would otherwise insert an externally provided CA.
If I use the generated intermedca-certificate.pem as the CA file to verify a server using Proton, I get the expected failure.
If I use the "marked" version, intermedca_trust_anchor.pem, it succeeds.
I have not tested further.  Presumably you would also have to add "-addtrust clientAuth" if using the CA for mutual TLS.
make_ica.txt

authors: cliffjansen grs

repo: skupperproject/skupper-router


text:
Add method (GET/POST) to form

https://github.com/skybrud/Skybrud.Forms/blob/v1/main/src/Skybrud.Forms/Models/Form.cs

Implemented in v1.0.0-beta008 😎

authors: abjerner tnielsenskybruddk


text:
[core] Jadx deobfuscates valid identifiers

Hey!
The latest version deobfuscates valid identifiers in apps that are not obfuscated. This behavior wasn't present before. Sample app: https://drive.google.com/file/d/1NEIPWFwukzv1BgJDHpaqKZAznMf25lqW/view?usp=sharing
When you open the kotlin package, you will see the following contents:

However, I believe, those classes shouldn't be deobfuscated

@skylot
I have the following configuration:
{
  "flattenPackage": false,
  "checkForUpdates": false,
  "fontStr": "",
  "smaliFontStr": "",
  "editorThemePath": "/org/fife/ui/rsyntaxtextarea/themes/default.xml",
  "lafTheme": "FlatLaf Light",
  "langLocale": {
    "locale": "en_US"
  },
  "autoStartJobs": false,
  "excludedPackages": "",
  "autoSaveProject": false,
  "showHeapUsageBar": false,
  "alwaysSelectOpened": false,
  "useAlternativeFileDialog": false,
  "codeAreaLineWrap": true,
  "srhResourceSkipSize": 3,
  "srhResourceFileExt": ".xml|.html|.js|.json|.txt",
  "searchResultsPerPage": 50,
  "useAutoSearch": true,
  "keepCommonDialogOpen": true,
  "smaliAreaShowBytecode": false,
  "lineNumbersMode": "AUTO",
  "mainWindowVerticalSplitterLoc": 300,
  "debuggerStackFrameSplitterLoc": 300,
  "debuggerVarTreeSplitterLoc": 700,
  "adbDialogPath": "",
  "adbDialogHost": "localhost",
  "adbDialogPort": "5037",
  "codeCacheMode": "MEMORY",
  "usageCacheMode": "NONE",
  "jumpOnDoubleClick": true,
  "treeWidth": 601,
  "dockLogViewer": true,
  "settingsVersion": 18,
  "skipResources": false,
  "skipSources": false,
  "exportAsGradleProject": false,
  "threadsCount": 8,
  "decompilationMode": "AUTO",
  "showInconsistentCode": true,
  "useImports": false,
  "debugInfo": true,
  "addDebugLines": false,
  "inlineAnonymousClasses": false,
  "inlineMethods": true,
  "moveInnerClasses": true,
  "allowInlineKotlinLambda": true,
  "extractFinally": true,
  "replaceConsts": false,
  "escapeUnicode": true,
  "respectBytecodeAccessModifiers": false,
  "userRenamesMappingsMode": "READ",
  "deobfuscationOn": true,
  "deobfuscationMinLength": 2,
  "deobfuscationMaxLength": 64,
  "generatedRenamesMappingFileMode": "READ",
  "deobfuscationUseSourceNameAsAlias": true,
  "resourceNameSource": "AUTO",
  "useKotlinMethodsForVarNames": "APPLY",
  "renameFlags": [
    "CASE",
    "VALID",
    "PRINTABLE"
  ],
  "integerFormat": "AUTO",
  "fsCaseSensitive": false,
  "cfgOutput": false,
  "rawCfgOutput": false,
  "fallbackMode": false,
  "useDx": true,
  "commentsLevel": "NONE",
  "pluginOptions": {}
}

it’s useful! In 10% of apps

Oh, nice! Maybe we can enable this option by default :smile:

worked perfectly a few commits ago?

I am pretty sure these "few commits" are a big batch of changes I merged into master after 1.4.7 release. These changes contain a big refactoring of deobfuscator and rename visitors to improve API for scripts and plugins :slightly_smiling_face:

authors: bagipro skylot

repo: skylot/jadx


text:
Concept of SharedComponents across multiple entities

I just recently stumbled upon this gem of yours and I am really glad about your design principles. Currently I am attempting to write custom wrappers around EnTT to formalize its use in my context using things such as Worlds, EntityManagers, ComponentSystems, EntityArchetypes and Chunks.
However I noticed you are using rather generic Components and seemingly have no concept of what I call SharedComponents. Assume a large amount of entities that all have the very same Component attached to it, such as a MeshRendererComponent or maybe an AgentBehaviourComponent for AI-related things. Something that all of those entities have in common. Instead of having N components attached to N entities that all hold the very same data it would be nice to have variant where a SharedComponent is only stored once and letting all entities point to this single instance of the SharedComponent.
Is this a feature you already have implemented (which I just haven't seen at all) or something that you might consider adding to EnTT?

I just recently stumbled upon this gem of yours and I am really glad about your design principles.

Thank you. Do not forget to star the project if you like it and use it! :+1:

Instead of having N components attached to N entities that all hold the very same data it would be nice to have variant where a SharedComponent is only stored once and letting all entities point to this single instance of the SharedComponent

Ok, let's consider this. I'll try to explain you why you don't need it.
In order to have N entities that point to the same shared component, you need at least N pointers of type T * and one or more instances of T stored somewhere else. Right?
So far, so good. In C++, if you define a class with only a public data member of type T *, it will have the size of its data member. So, call this class C and assign an instance of this class to each entity, you occupied exactly the same memory you would have occupied with N pointers of type T *, with the sole difference that you called them components and you put them in an heterogeneous container that treats them as any other type. Moreover, you still have your instances of T stored somewhere else.
Do you spot the difference? No, because there is not.
I did it recently. I have a resource cache that returns a tiny handle (for simplicity, consider it a pointer) to a 2D sprite that can be shared between different entities.
If you define your component as:
class Sprite {
    Handle handle;
};

You have exactly what you're looking for.
It's called flyweight, it's a well known pattern, no matter how Unity calls it and if they hide it behind a graceful interface.
There is no way you can occupy less then what you'd occupy by putting a pointer in a component and by assigning instances of that component to entities.
Moreover, there is no way you can have a performance boost using a built-in solution, because you cannot get rid of the indirection.
So, to sum up, you're asking to integrate in EnTT something that already exists, to do something that is already possible, just because someone called it differently (so that it looked smarter than a design pattern everybody knows about probably). :-)
Did I convince you?

Frankly, I was wearing mindcuffs and thus neglected the option to just store a pointer. In Unity there are various high performance mechanisms that lay out the data sequentially in the memory and parallelize systems using threads as much as possible. One caveat is that you can only use blittable types and pointer are neither directly available in C# nor considered blittable unless you do some shenannigans.
With that in mind I just haven't really thought about using pointers. Thanks for the very thorough explanation 👍

You're welcome. Thanks for using EnTT.

authors: NearAutomata skypjack

repo: skypjack/entt


text:
🛑 Rex's Jellyfin is down

In 5c3b472, Rex's Jellyfin (https://jellyfin.rexsky-blog.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Rex's Jellyfin is back up in c0a34d1 after 18 minutes.

repo: skywalkerRex/RexSky-Blog-Uptime


text:
Is it possible to send scheduled bot message as user.

I have a bot that collects user data using a modal and then sends the collected data as a message as a user in a channel.
This works as expected when I use chat.postMessage method.
Now I want to send this message at a scheduled time instead of posting it immediately in the channel. So I am using chat.scheduleMessage now. But in this case the message is posted as bot despite of providing the username and icon_url properties to the argument object. Also set the as_user property to true
client.chat.scheduleMessage({
        channel: channelId,
        post_at: scheduleTime.local().unix(),
        icon_url: userInfo?.image_192,
        username,
        as_user: true,
        blocks: [Data],
        text: "Message",
        attachments: responseMarkdown,
      })

Reproducible in:
The Slack SDK version
"slack/bolt": "^3.12.2",
"slack/web-api": "^6.8.1"

Node.js runtime version
v18.15.0
OS info
MacOS Monterey
Expected result:
The message should be posted as a user on using chat.scheduleMessage method
Actual result:
The message is posted as a bot on using chat.scheduleMessage
Requirements
For general questions/issues about Slack API platform or its server-side, could you submit questions at https://my.slack.com/help/requests/new instead. 🙇
Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

Hi, @ayushdevelop! Thanks for submitting your question. 🙌
Unfortunately, the as_user property for chat.scheduleMessage is only a valid argument for legacy Slack apps (more info here). Unlike chat.postMessage, chat.scheduleMessage does not accept an icon_url and username properties.
If it suits your use case, you could use a user token for your app and then it should send messages as the user that the token belongs to (typically the user that installs and/or authenticates the app). You can find more information on implementing using a user token here.
With using the user token, you'd need to make sure the scopes chat:write, chat:write:user, and chat:write:bot are added so you can use chat.scheduleMessage successfully.
I hope this helps!

@hello-ashleyintech Thank you for answering my question.
I have a follow up question on using user token
Currently I am using bot token to initialize the app
export const boltRunner = new AppRunner({
  token: process.env.SLACK_BOT_TOKEN,
  signingSecret: process.env.SLACK_SIGNING_SECRET!,
  logLevel: LogLevel.DEBUG,
});

Will there be any demerits or issues caused by using user token instead of bot token for initializing the app instance?

Hi, @ayushdevelop! Instead of using the user token to initialize the app instance, I believe you can do a token override in your chat.scheduleMessage call, similar to what is described here. chat.scheduleMessage accepts a token parameter, so you can pass in your user token as a token parameter when you make the API call.

Sure @hello-ashleyintech. Thank you for your help.

authors: ayushdevelop hello-ashleyintech

repo: slackapi/bolt-js


text:
Subscribe to Slack Events

Hi,
I just have few questions w.r.t to Slack Events Subscription.  I tried this:

But my url needs access token, and I don't see any way in slack to supply token.  Can someone help here with how to supply the token?
Secondly, I tried using RTM API. https://api.slack.com/methods/rtm.connect  Do we have SDK for this RTM as well?  Any ref?

@seratch , any thoughts from ur side on this?

Hi @Syed-SnapLogic! Happy to help with this. 🙂
We don't support adding custom tokens to HTTP requests for authenticated gateways, so the best option would be to use RTM, as you've indicated you've attempted to do already.
For our knowledge and to hopefully eventually provide better support, would you mind letting us know what kind of gateway you're using?
As for RTM, below are two documents that we recommend reading through to get you set up:
https://github.com/slackapi/java-slack-sdk/blob/main/docs/guides/rtm.md
https://www.javadoc.io/doc/com.slack.api/slack-api-client/latest/com/slack/api/rtm/RTMClient.html
Hope that's helpful! If we can answer any more questions as you move forward, please don't hesitate to reach out. Else, if you think this has answered your question and resolved the issue, feel free to close it.

@misscoded , thank you so much for the response.  I tried, but I am getting "missing scope" error.
Can I know what scope should I add to my token to get this done?  If I pass "client" scope, I am getting error as that scope is deprecated.  Pls help.

@Syed-SnapLogic

But my url needs access token, and I don't see any way in slack to supply token. Can someone help here with how to supply the token?

For the url verification when setting up Events API, your endpoint just need to echo the challenge value in  payload. Here is the code that does it in Bolt for Java. https://github.com/slackapi/java-slack-sdk/blob/v1.2.1/bolt/src/main/java/com/slack/api/bolt/App.java#L944-L950
For a classic app setup for RTM API, try the following steps:

Create a classic app from https://api.slack.com/apps?new_classic_app=1
Go to Features > OAuth & Permissions > Scopes

Click "Add an OAuth Scope"
Search "bot" and choose it

Go to Features > App Home

Click "Add Legacy Bot User"
Input "Display Name" and "Default username"
Click "Add"

Go to Settings > Install App

Click "Install App to Workspace"
Complete the OAuth flow

@Syed-SnapLogic Was my previous comment helpful? Let me close this issue after waiting for your response for a few days.

@seratch , I still didn't try it out.  I was using URL based listeners so far.  I shall try it out sooner, and update you if any thing needed.  Good that you closed it for now.  Thnx.

authors: Syed-SnapLogic misscoded seratch

repo: slackapi/java-slack-sdk


text:
use of lombok detracts from otherwise very useful code

request: please consider removing lombok
it clutters things up and obscures more than it helps. Most IDE's have the trivial constructor, getter, setter, toString, equals etc. all built in already.
All we're left with is something that generates chaining operations.
first thing I'm going to do with this code is strip out the lombok dependency. Less is more. SImple is better than complex

Hi, thanks for taking the time to write in and the suggestion!
As you mention, we can do the same with Lombok's accessor/constructor/toString/equals generation by utilizing IDE's code generation feature (although the generated code tends to have so many lines of code).
Also, I do understand your point from the library user perspective. When you download the source code and use code jump to this SDK, your IDE may not link to plain Java code.

All we're left with is something that generates chaining operations.

I guess you indicated the @Builder annotation by this. It is a key feature we rely on, and if we get rid of Lombok, the lines of code we have to add to keep the same level of usability and backward compatibility would be huge. Also, the builder code support is not yet available in the latest JDK, Kotlin, and any other alternatives (even if the latest JDK supports something, we cannot drop supports for older JDKs, though). As you know, the feature enables us to provide the following interface. We want to avoid manually crafting these for a large number of API request classes.
ChatPostMessageRequest.builder().channel("C111").text("Hi there!").build();
Slack.getInstance().methods("xoxb-").chatPostMessage(req -> req.channel("C111").text("Hi there!"));

App app = new App(AppConfig.builder()
  .signingSecret("secret")
  .clientId("123")
  .scope("commands,chat:write")
  .classicAppPermissionsEnabled(true)
  .build()
);

If we have something nice supporting the builder feature in the future, we may consider getting rid of Lombok. But for now, we are not planning to do so. Thanks again for the suggestion here, but I would appreciate it if you could understand this.

authors: PaulAndersonHSI seratch


text:
Improve EventRequest context information loss

#629 changed the behavior of the EventRequest to return the team_id from the first authorizations element instead of the team_id in the top-level of the event payload. This results in a few problems.

This fixes a problem where Bolt apps could not determine the team_id associated with the app's install context when the event occurs within a shared channel, but it breaks the app's ability to know the team_id where the event itself occurred.

The team_id is in the payload, but the payload is parsed once and then thrown away. The team_id is still in the request body, but extracting it requires the Bolt app to re-parse the request body again.

When the app is installed into an enterprise grid, the authorization element will have an enterprise_id set but the team_id will be absent. This results in the EventRequest having a null team_id. The consequence is that an app installed into an enterprise grid has no idea which team is associated with any event even if there are no shared channels at all.

This abstraction in Bolt Java results in information loss which breaks the use cases above.
Proposal
It seems more correct to change the code to do the following:

Revert the change in #629 so that EventRequest always sets its context to the top-level properties in the event request. This change fixed a problem associated with shared channels but resulted in information loss which created other new problems.
Add authorizations as a new property on EventRequest.

This fixes the information loss problem and defers the decision to the app to decide what to do. Furthermore, this change would allow Bolt Java apps to see exactly what Slack sends natively and make their own decisions about what to do with that information. Then the app has all the information it needs to make the right decision in every circumstance. This allows Bolt Java to continue as an SDK without the negative consequences of hiding some of the information Slack sends in its requests. It also gives apps all the authorizations that are included in the request from Slack, which today are hidden from Bolt Java apps.
This would technically be a breaking change from the current code's semantics and should be advertised as such. But it reverts back to a more accurate state and provides an alternative fix to #629 that does not incur the current problems. The changes in #629 were also a breaking change, so it just seems that the approach taken resulted in an unforeseen side effect which should be remedied.
Category

[x] bolt (Bolt for Java)
[ ] bolt-{sub modules} (Bolt for Java - optional modules)
[ ] slack-api-client (Slack API Clients)
[ ] slack-api-model (Slack API Data Models)
[ ] slack-api-*-kotlin-extension (Kotlin Extensions for Slack API Clients)
[ ] slack-app-backend (The primitive layer of Bolt for Java)

I misinterpreted the meaning of the event context and missed the fact that this information is all available in the EventsApiPayload, including the authorizations. Because of that, this is not a real issue at all, so I'm closing this.
Thanks @seratch for the insights.


text:
Uncaught TimeoutError

Description
When auto_reconnect = True, the client should start the reconnect procedure on a connection timeout error.
What type of issue is this? (place an x in one of the [ ])

[ ] bug
[ ] enhancement (feature request)
[x] question
[ ] documentation related
[ ] testing related
[ ] discussion

Requirements (place an x in each of the [ ])

[x] I've read and understood the Contributing guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.
[x] I've searched for any related issues and avoided creating a duplicate issue.

Bug Report
Reproducible in:
slackclient version: 1.3.2
python version: 3.6
OS version(s): Ubuntu 18.04
Steps to reproduce:

Connect using client.rtm_connect(auto_reconnect=True)
Start listening for messages using client.rtm_read()
Disconnect internet
Wait

Expected result:
Since auto_reconnect = True, the connection timeout error should be caught and server.rtm_connect(reconnect=True) should be invoked. This situation might resolve itself in the 5 connection attempts.
Actual result:
server.websocket_safe_read only reconnects on WebSocketConnectionClosedException, so when websocket.recv throws a TimeoutError, the app goes down.
Traceback:
Exception in thread Thread-6:
Traceback (most recent call last):
  File "/usr/lib/python3.6/threading.py", line 916, in _bootstrap_inner
    self.run()
  File "/home/anukul/docs/storyscript/microservices/slack/app/bot.py", line 110, in run
    for msg in slack.rtm_read():
  File "/home/anukul/.virtualenvs/slack/lib/python3.6/site-packages/slackclient/client.py", line 235, in rtm_read
    json_data = self.server.websocket_safe_read()
  File "/home/anukul/.virtualenvs/slack/lib/python3.6/site-packages/slackclient/server.py", line 283, in websocket_safe_read
    data += "{0}\n".format(self.websocket.recv())
  File "/home/anukul/.virtualenvs/slack/lib/python3.6/site-packages/websocket/_core.py", line 310, in recv
    opcode, data = self.recv_data()
  File "/home/anukul/.virtualenvs/slack/lib/python3.6/site-packages/websocket/_core.py", line 327, in recv_data
    opcode, frame = self.recv_data_frame(control_frame)
  File "/home/anukul/.virtualenvs/slack/lib/python3.6/site-packages/websocket/_core.py", line 340, in recv_data_frame
    frame = self.recv_frame()
  File "/home/anukul/.virtualenvs/slack/lib/python3.6/site-packages/websocket/_core.py", line 374, in recv_frame
    return self.frame_buffer.recv_frame()
  File "/home/anukul/.virtualenvs/slack/lib/python3.6/site-packages/websocket/_abnf.py", line 361, in recv_frame
    self.recv_header()
  File "/home/anukul/.virtualenvs/slack/lib/python3.6/site-packages/websocket/_abnf.py", line 309, in recv_header
    header = self.recv_strict(2)
  File "/home/anukul/.virtualenvs/slack/lib/python3.6/site-packages/websocket/_abnf.py", line 396, in recv_strict
    bytes_ = self.recv(min(16384, shortage))
  File "/home/anukul/.virtualenvs/slack/lib/python3.6/site-packages/websocket/_core.py", line 449, in _recv
    return recv(self.sock, bufsize)
  File "/home/anukul/.virtualenvs/slack/lib/python3.6/site-packages/websocket/_socket.py", line 81, in recv
    bytes_ = sock.recv(bufsize)
  File "/usr/lib/python3.6/ssl.py", line 997, in recv
    return self.read(buflen)
  File "/usr/lib/python3.6/ssl.py", line 874, in read
    return self._sslobj.read(len, buffer)
  File "/usr/lib/python3.6/ssl.py", line 633, in read
    v = self._sslobj.read(len)
TimeoutError: [Errno 110] Connection timed out

Attachments:
The code is from https://github.com/omg-services/slack
But the traceback should be enough to identify the problem.

As we're no longer actively working on the v1.x series, please allow me to close this issue now. We appreciate your understanding. :bow:
If you have similar issues with the latest version, let us know the issue.

authors: anukul seratch

repo: slackapi/python-slackclient


text:
im_open requires positional arg, user key gives user_id

Summary
This is to fix some bug in the tutorial code:

payload['user'] gives user_id
WebClient#im_open expects positional user argument

Requirements (place an x in each [ ])

[x] I've read and understood the Contributing Guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


text:
SwiftUI sample/boilerplate

I know you are not really accepting contributions, so feel free to close this, just wanted to demonstrate an approach to use Circuit with SwiftUI.
Highlights

The SwiftUI "navigator" is shared through the SwiftUIPresenter
1 extension is needed in a client project to link the Swift an Kotlin implementations
With some code generation it might even be possible to auto generate the iOS screen classes
Requires iOS 16 due to the use of NavigationStack

Demo
I have added a PrimeView to the iOS sample similar to the desktop sample.
Otherwise the UI hasn't changed much (git isn't smart enough to detect this after the file rename..).
https://github.com/slackhq/circuit/assets/7353419/3e6cb2c1-000a-4e7c-9634-48fde9549e20
Components
There are a couple main components required to make this work.
SwiftUIPresenter
It's a small wrapper around an existing Presenter and is the main link between Kotlin and Swift.
SwiftUIPresenter exposes a function to set a listener that is used to notify Swift of any state changes.
Besides exposing the state to SwiftUI it also provides a way for SwiftUI to store a navigator and cancel the coroutine scope.
SwiftUINavigator / CircuitNavigator
Which brings us to SwiftUINavigator. It forwards navigation actions to a Swift navigator.
To accomplish that it relies on a ObjC protocol that is implemented in the Swift part of the library.
CircuitPresenter
Is a helper protocol. It allows us to rely on our Kotlin code. User just need to add the following line to their iOS project:
extension Circuit_swiftuiSwiftUIPresenterProtocol: CircuitPresenter { }

CircuitNavigationStack
It is a wrapper around NavigationStack.
You provide it with a CircuitNavigator and a closure that generates a CircuitView based on the provided screen.
It also stores the CircuitNavigator as an environment object such that CircuitViews can access it.
CircuitView
This view connects a presenter to a SwiftUI view. It observes the SwiftUIPresenter and forwards the navigator to it.
Usage
So how do you use this in an iOS project? First you need to add the above mentioned extensions.
After that you'll go ahead and create your views. There is nothing special about those. They are just SwiftUI views accepting a state value:
struct CounterView: View {
  var state: CounterScreenState
  var body: some View { }
}

The only thing remaining is to connect the presenters to their view and setup the navigator:
@main
struct iOSApp: App {

    // We create a CircuitNavigator with the initial root screen
    @StateObject private var navigator = CircuitNavigator(IosCounterScreen.shared)

    var body: some Scene {
        WindowGroup {
            // And here we map screen objects to a CircuitView
            CircuitNavigationStack(navigator) { screen in
                switch screen {
                case let screen as IosCounterScreen:
                    CircuitView(screen.presenter(), CounterView.init)
                case let screen as IosPrimeScreen:
                    CircuitView(screen.presenter(), PrimeView.init)
                default:
                    fatalError("Unsupported screen: \(screen)")
                }
            }
        }
    }
}

This is great! Going to take a deeper dive into the code in a bit, but in the meantime could you do three things for us?

Can you fill out the description a bit more. Assume none of us have much iOS experience 😅. Especially with how it differs from what our current sample does. Eager to learn more
Could you add build/development instructions to the description?
Could you add a screenrecording or screenshot of the new UI?

Could you also merge latest main or articulate why some of the dependencies were lowered? Also any commented code bits

Could you also merge latest main or articulate why some of the dependencies were lowered? Also any commented code bits

Ah right forgot to mean that. Was having some issues building the iOS counter project due to the following change:
 add(NATIVE_COMPILER_PLUGIN_CLASSPATH_CONFIGURATION_NAME, libs.androidx.compose.compiler)

Removing that just left me with some errors about incompatible Compose/Kotlin version, which is why I downgraded them.
Not sure what the above line is supposed to do, but can take another look at it if you like.
Will merge the latest main and take a look at your other questions 👍🏻.

@ZacSweers I updated the description, let me know if there are other areas of which you would like some more details.

Could you add build/development instructions to the description?

Not much has changed. I have added a local Swift package dependency to the sample project.
It uses a relative path, so it should work right away.

Apologies for the delays, we haven't had much time to pick this up again yet. I'd be curious for your thoughts on SKIE though? The biggest annoyance I had in my own sample was getting UI state updates propagating to swift and it looks like this can help with that, possibly with molecule.
https://touchlab.co/skie-is-open-source

No problem.

The biggest annoyance I had in my own sample was getting UI state updates propagating to swift

OMG that is genius! We have been thinking about this way to much from the Kotlin side.
So short answer: I don't think you'll need SKIE (or any library/tool).
Long answer:
So I am no wear near done reading up on SKIE, but at it's core it helps with Kotlin - ObjC - Swift interop by generating Kotlin and Swift boilerplate. Basically there are two areas where SKIE could possibly help (based on the current PR):

Flow to AsyncSequence
Generating Swift boilerplate for Circuit (although that isn't supported out-of-the box)

However your comment made me realise we don't need anything like this.
What SwiftUI needs is something like the following:
class CircuitPresenter: ObservableObject {
    @Published var state: State
}

That's it, we don't need a Flow, just a property that will notify subscribers of any changes.
I think we can completely drop all external dependency (except for Molecule).
Using ObjC interfaces should be enough to remove 99% of the boilerplate.
I guess the only thing we can't remove is the CircuitView initialiser (due to the issues with generics).
SKIE could technically generate that for use, though not out-of-the-box.
IMO it wouldn't make sense to invest in the generation of a single extension that could be easily copy-pasted.
Will try and see if I can update the PR without external dependencies if I find some time 😁.

Updated the implementation to only depend on Molecule. Was even able to remove the extension on CircuitView from the client project with an additional abstraction and some Swift magic.
The CircuitView will convert the Kotlin SwiftUIPresenter to an ObservableObject which sets a listener on the presenter to get notified about state changes.

Maybe it's even possible to move the "entry point" from the SwiftUIPresenter to the IosScreen and convert:
case let screen as IosCounterScreen:
    CircuitView(screen.presenter(), CounterView.init)

to something like:
case let screen as IosCounterScreen:
    screen.present(CounterView.init)

I am not really sure what you mean. When the goal is to use SwiftUI for the UI and Circuit for the presentation logic you'll need a way to tell SwiftUI about state changes and navigation events. In order to do that and provide that functionality as a library you'll need some way to connect the Circuit Kotlin code with the Circuit Swift code.
What part of the Swift code do you feel rewrites much of circuit's runtime?

What part of the Swift code do you feel rewrites much of circuit's runtime?

CircuitNavigator + CircuitSwiftUINavigator + SwiftUINavigator seem to recreate Navigator, CircuitPresenter and SwiftUIPresenter seem to recreate Presenter, CircuitNavigationStack seems to recreate BackStack, etc. Some of the core circuit concepts are also conflated here, like the iOS screens being presenter factories or CircuitView replacing CircuitContent but without the automatic bindings.
I don't think we want to re-implement so much of this in SwiftUI to make it work there, my hope was that we would only need a thin bridge layer to convert Presenter state emissions to an observable SwiftUI state and more or less limit it to that. What's the need for a custom Swift navigator and backstack implementation? And if so, can those be implemented in a way that doesn't feel like it's a parallel set of swift analogues of existing Circuit APIs?

@chrisbanes would be curious for your thoughts in this space as well since you've been using some of circuit's stuff on iOS already

My direct experience with Circuit on iOS is fully within Compose, however I have spent a while recently hooking up Decompose at work, and this has ended up looking very similar.
I guess there's a bigger decision here: does using Circuit makes much sense without Compose UI? 🤔
By using Swift UI (or even Android Views) you lose a lot of benefits from having a single composition,  consistent navigation system, cross-cutting concept (CompositionLocals), and much more.
My $0.02 would be that Circuit should be Compose only, and make that as good as it can be. There are other libraries out there which are focused on the more general x-platform problem.

CircuitNavigator + CircuitSwiftUINavigator + SwiftUINavigator seem to recreate Navigator, CircuitPresenter and SwiftUIPresenter seem to recreate Presenter, CircuitNavigationStack seems to recreate BackStack, etc.

Correct. Although most of it is just glue code. CircuitNavigator is the Swift implementation of Navigator, CircuitSwiftUINavigator and SwiftUINavigator are only needed for the interop.
SwiftUIPresenter combined with ObservablePresenter is the "thin bridge layer" you are talking about with CircuitPresenter being the glue code.

I don't think we want to re-implement so much of this in Swift (±UI) to make it work there, my hope was that we would only need a thin bridge layer to convert Presenter state emissions to an observable SwiftUI state and more or less limit it to that.

Alright. In that case I am wondering what responsibilities you were seeing for SwiftUI?
I was going for SwiftUI interface with Circuit presentation logic.

What's the need for a custom Swift navigator and backstack implementation? And if so, can those be implemented in a way that doesn't feel like it's a parallel set of swift analogues of existing Circuit APIs?

They add navigation support, allowing you to trigger navigation actions from the presenter.

I guess there's a bigger decision here: does using Circuit make much sense without Compose UI? 🤔

That is indeed a great question. To be honest, I am not sure if it does make much sense.
I completely agree that Circuit should be focused on Compose.
However the power of KMP is in "share what you want, when you want, how much you want".
So in that context it would be awesome if you could use Circuit with a SwiftUI interface.

authors: ZacSweers chrisbanes rickclephas

repo: slackhq/circuit


text:
Add a merge script.

Should currently work with any Scala repo. Would be nice to generalize
for others – basically comes down to handling different version files.

Uhh … there’s no travis file. Don’t know why it tried to build.

I mistyped the repo name and got a confusing error:
> merge quasar-analytisc/quasar 1110
curl: (22) The requested URL returned error: 404 Not Found
error: quasar-analytisc/quasar#1110 has already been merged

Playing with JR's current PR, a couple of things I notice:
There are two merge commits in the history. Both seem to come from the script (and have me as the author):
15ea04e Merge branch 'jedesah-topic/upgrade_sbt'
cd0183e Merge branch 'topic/upgrade_sbt' of https://github.com/jedesah/Quasar into jedesah-topic/upgrade_sbt
620c5f2 Upgrade to sbt 0.13.11

Also, since he didn't have a revision.md, there's no version bump :(

To be fair though. That PR is just bumping the sbt version so I don't think it warrants a quasar version bump.

I also notice that echo $old_version prints 4., and new_version seems to be 4.1.1 (should be 4.1.3).

But the script should probably error out or emit a warning in that case.

@jedesah: it looks like the version didn't get bumped because the script doesn't work, not because of anything you did, not that we have a way to say "no need to release with this commit".

I hate that you can’t reply to specific comments …

typoed-repo-name: Yeah, that error is because of the lack of -e, otherwise, you’d just get the “requested URL returned error” message (which, c’mon curl, include the URL!)
2a. I think there are two merge commits because his branch isn’t rebased. I tried that PR earlier, but it didn’t work because of merge conflicts, which is good.
2b. Hrmm, I was getting increments without a revision.md … I don’t think not having that file should prevent an increment (although it will fail the script once I make the change mentioned above)
Every change to the repo warrants a version bump.
4a. old-version is an array – you’re only seeing the first value when you echo it.
4b. ah-ha! The incrementing must actually just be setting to “1”. I was testing on a matryoshka PR, so it was going from 0→1, but 3→1 is clearly not correct.

@sellout I am not sure I agree about a change to the Readme, bumping the
version of quasar.
On Feb 26, 2016 5:02 PM, "Greg Pfeil" notifications@github.com wrote:

I hate that you can’t reply to specific comments …

typoed-repo-name: Yeah, that error is because of the lack of -e,
otherwise, you’d just get the “requested URL returned error” message
(which, c’mon curl, include the URL!) 2a. I think there are two merge
commits because his branch isn’t rebased. I tried that PR earlier, but it
didn’t work because of merge conflicts, which is good. 2b. Hrmm, I was
getting increments without a revision.md … I don’t think not having
that file should prevent an increment (although it will fail the script
once I make the change mentioned above)
Every change to the repo warrants a version bump. 4a. old-version
is an array – you’re only seeing the first value when you echo it. 4b.
ah-ha! The incrementing must actually just be setting to “1”. I was testing
on a matryoshka PR, so it was going from 0→1, but 3→1 is clearly not
correct.

—
Reply to this email directly or view it on GitHub
https://github.com/slamdata/devtools/pull/5#issuecomment-189531604.

README is documentation, docs are versioned.

Depends on what kind of doc. Scaladoc is packaged in the jar so it makes
sense to bump the artifact version. However the Readme is not published in
the jar, that's not to say it is not versioned, but it's versioned by git,
not our artifact version.
On Feb 26, 2016 5:18 PM, "Greg Pfeil" notifications@github.com wrote:

README is documentation, docs are versioned.
—
Reply to this email directly or view it on GitHub
https://github.com/slamdata/devtools/pull/5#issuecomment-189534441.

Ping, re: new commits.

LGTM

authors: jedesah mossprescott sellout

repo: slamdata/devtools


text:
Cyclic data structures

At Scala by the Bay I asked @sellout if recursion schemes could be used on data structures which are not only recursive, but actually contain cycles. If you ever figure it out, please let me know. Thanks!

Haven't tried this route myself but there's an algebraic characterization of graphs which perhaps may be useful in this context (i.e. represent the cyclic bits of your structure as a graph and embed that in your ADT). Rewriting this may prove to be harder depending on what you try to do.
https://github.com/snowleopard/alga

@boggle Thanks, I'll take a look.

authors: boggle durban

repo: slamdata/matryoshka


text:
Proposal: Existentially hidden query algebra

Currently the component query algebra is part of the public interface of a component. This makes it difficult to implement transparent HOCs because the types become infectious. I propose that we existentially hide a component's query algebra.
In #515 I proposed adding a separate library algebra for lifecycle events:
component = H.component { render, eval, lifecycle }
  where
  lifecycle :: H.Lifecycle Input -> HalogenM ... Unit
  lifecycle = case _ of
    H.Initialize -> ...
    H.Receive input-> ...
    H.Finalize -> ...

I'm going to propose we actually just make this eval and add two more constructor so that it looks like this.
data HalogenQ' f g i a
  = Initialize a
  | Finalize a
  | Receive i a
  | Internal (f a)
  | External (g (Maybe a))

data HalogenQ (g :: Type -> Type)  i a

eval :: forall f g i. HalogenQ' f g i ~> HalogenM s f ps o m

This takes the Halogen.Component.Proxy functionality and makes it first class. We separate a public query algebra from an internal query algebra which means type parameters are no longer infectious or invariant. We can even recover the existing component spec definitions in terms of this by making f ~ g.
Using this we can write an encapsulated HOC where no extra types leak.
type QueryI o a
  = Toggle Boolean a
  | Raise o a

type State i =
  { visible :: Boolean
  , input :: i
  }

type ChildSlots g o =
  ( child :: H.Slot g o Unit
  )

toggleHoc :: forall g i o m. Component HH.HTML g i o m -> Component HH.HTML g i o m
toggleHoc inner = component { initialState, render, eval }
  where
  initialState :: i -> State i
  initialState i =
    { visible: true
    , input: i
    }

  render :: State i -> HH.ComponentHTML QueryI (ChildSlots g o) m
  render state =
    HH.div_
      [ HH.button
          [ HP.onClick (HE.input_ (Toggle (not state.visible))) ]
          [ HH.text "Toggle" ]
      , if state.visible
          then HH.slot (SProxy :: SProxy "child") unit inner state.input (HE.input Raise)
          else HH.text ""
      ]

  eval :: HalogenQ' (QueryI o) g i ~> HalogenM (State i) f (ChildSlots g o) m
  eval = case _ of
    Initialize next -> pure next
    Finalize next -> pure next
    Receive input next -> H.modify _ { input = input } $> next
    Internal (Toggle visible next) -> H.modify _ { visible = visible } $> next
    Input (Raise o next) -> H.raise o $> next
    External q -> H.query (SProxy :: SProxy "child") unit q

Note I used External (g (Maybe a)) which means external queries can be partial. This is always the case anyway since a component may not be mounted, but this allows the inner component to control that partiality as well.

Here are some more types, and shows how you can recover a backwards compatible spec from this formulation.
data RequestBox g a b = RequestBox (g b) (Maybe b -> a)

data HalogenQ (f :: Type) (g :: Type -> Type) (i :: Type) (a :: Type)
  = Initialize i
  | Receive i
  | Handle f
  | Request (Exists (RequestBox g a))
  | Finalize

data HalogenM f s ps o m a

type ComponentEval f g i s ps o m = HalogenQ f g i ~> HalogenM f s ps o m

type Component' h f g i s ps o m =
  { initialState :: i -> s
  , render :: s -> h (ComponentSlot h ps m f) f
  , eval :: ComponentEval f g i s ps o m
  }

data Component h g i o m

eval
  :: forall f g i s ps o m
   . { initialize :: i -> HalogenM f s ps o m Unit
     , receive :: i -> HalogenM f s ps o m Unit
     , handle :: f -> HalogenM f s ps o m Unit
     , request :: forall b. g b -> HalogenM f s ps o m (Maybe b)
     , finalize :: HalogenM f s ps o m Unit
     }
  -> ComponentEval f g i s ps o m
eval { initialize, receive, handle, request, finalize } = case _ of
  Initialize i -> initialize i
  Receive i -> receive i
  Handle f -> handle f
  Request req -> runExists (\(RequestBox g k) -> k <$> request g) req
  Finalize -> finalize

compatEval
  :: forall g i s ps o m
   . { initializer :: Maybe (g Unit)
     , finalizer :: Maybe (g Unit)
     , receiver :: i -> Maybe (g Unit)
     , eval :: g ~> HalogenM (g Unit) s ps o m
     }
  -> ComponentEval (g Unit) g i s ps o m
compatEval { initializer, finalizer, receiver, eval } = case _ of
  Initialize i -> for_ initializer eval
  Receive i -> for_ (receiver i) eval
  Handle f -> eval f
  Request req -> runExists (\(RequestBox g k) -> k <<< Just <$> request g) req
  Finalize -> for_ finalizer eval

To be honest, I'd remove i from Initialize case and simply run two commands in interpreter (i.e. Initialize and Receive).
Alternative to removing algebra at all is
data HalogenQ (f :: Type) (r :: Type -> Type) a
  = Initialize i
  | Request (r a)
  | Handle f
  | Finalize

data HalogenM f s ps o m a

type ComponentEval f r s ps o m = HalogenQ f r ~> HalogenM f s ps o m

data Component h r o m

The slot changes to something like (not in HOC case in HOC case it remains the same)
HH.slot (SProxy :: SProxy "child") unit inner (Const state.input) Handle

But I don't quite sure how to formulate profunctor.
BTW, why not make Component a profunctor w/o newtype? It has no any other instances on it

If I understand that first proposal Maxim, you’re saying we should remove the ability to query child components at all? I think we lose something pretty important there, almost the defining feature of what Halogen is.
I’m not sure what the second one is saying, is it not the same as Nate’s proposal, but without the internal/external distinction?

If we completely remove the query, then we don't even need a natural transformation, since everything is Unit. I'm not proposing we do that, because we lose a big part of Halogen's functionality as @garyb said.
One "thing" with my proposal is that it means top-level queries through HalogenIO become partial as well. I admit this is awkward, but I don't see a solution for that.

I think your second proposal is the same as mine, except I've added the RequestBox wrapper

Not exactly, I propose to remove i parameter as well and use g instead.

we lose a big part of Halogen's functionality as @garyb said

Currently components have

public query
public input
public output
private state

We want to add private messages and make public query partial. In that case we would have

public partial query
public injput
public output
private state
private messages

Since public partial query is needed only for requests, i.e. all actions could be described via input. It's kinda interesting that this g functionality is a copy of pair i * o.
I agree that it seems that request is very important part of halogen, but honestly why do we think so? What will we lost exactly?

I'm strongly against using inputs for actions, I'd rather lose inputs entirely if we were specifically trying to cut down the communication options between components. Trying to make a continuous stream of things discrete is one of my least favourite things about FRP. It's especially weird in Halogen as it ties rendering to action-sending, you end up having to keep the action-that-we-are-currently-sending in the state of the parent, have the action implement Eq so it can be determined when it changes, things like that.
The thing that requests give us is a sensible interface for interacting with 3rd party components. It's impractical to try and keep a copy of the state of a component not under our control in our component's state, so the only way to solve that is to instead use requests to ask for the state instead. There are some cases with just normal HTML that this happens actually, state things that the virtual dom is unaware of like cursor positions in inputs.
You could argue that requests aren't strictly necessary, as you could send an input that is supposed to trigger an output with the reply, but that's unpleasant as it's like programming against event-based interfaces. It makes following the intent difficult as code gets split up between request-making and response handling, and can easily leave the component in broken states unless you're careful to ensure that every response is treated as optional.
Keep in mind we don't need to expose all these options all the time as part of the component interface - if we add these capabilities to make HOC stuff have less overhead, and allow remapping more easily (that was one of Nate's goals with moving the lifecycle algebra into the component), we can still provide a simplified interface for the normal cases. We could even provide the input-output only version for people who like FRP :wink:

The point of view where g :: Type -> Type is actually public state not public io has much more sense for me, yep.

I'd rather lose inputs entirely if we were specifically trying to cut down the communication options between components

This is really good point. One problem with initializers and receivers that they're sending actions instead of directly use HalogenM. And if we have Receive | Initialize as part of HalogenQ maybe this could work too?
data HalogenQ f (g :: Type -> Type) a
  = Initialize a
  | Rerender a
  | Handle f a
  | Finalize a
  | Request (g a) -- I'm not sure if this should be exist'ed

I.e. we have Rerender function
type ComponentEval s f g ps o m = HalogenQ f g ~> HalogenM s f ps o m
data Component h g o m

type QueryI o
  = Toggle Boolean
  | Raise o

type State =
  { visible :: Boolean
  }

type ChildSlots g o =
  ( child :: H.Slot g o Unit
  )

toggleHoc :: forall g o m. Component HH.HTML g o m -> Component HH.HTML g o m
toggleHoc inner = component { initialState, render, eval }
  where
  initialState :: State
  initialState = { visible: true }

  render :: State -> HH.ComponentHTML QueryI (ChildSlots g o) m
  render state =
    HH.div_
      [ HH.button
          [ HP.onClick (HE.input_ (Toggle (not state.visible))) ]
          [ HH.text "Toggle" ]
      , if state.visible
          then HH.slot (SProxy :: SProxy "child") unit inner (HE.input Raise)
          else HH.text ""
      ]

  eval :: HalogenQ (QueryI o) g ~> HalogenM State f (ChildSlots g o) m
  eval = case _ of
    Initialize next -> pure next
    Finalize next -> pure next
    Rerender next -> pure next
    Handle (Toggle visible) next -> H.modify _ { visible = visible } $> next
    Handle (Raise o) next -> H.raise o $> next
    Request q -> H.query (SProxy :: SProxy "child") unit q

Note, that since we Rerender is called on rerender, there is no need in proxy for this case.

who like FRP

Not me definitely, removing algebras and making communication channels only i * o is much more like true OOP from Erlang processes. But of course FRP could be built on top of it.

Unless we do want to use halt for the partial case

Does it mean we need this?
Request q -> H.query (SProxy :: SProxy "child") unit q *> halt

I don't feel like this example illustrates what Rerender is or does since you aren't even using it.

I'd rather lose inputs entirely if we were specifically trying to cut down the communication options between components

Why? How else do you keep something in sync? If we did this, things like halogen-select would cease to work.

Not me definitely, removing algebras and making communication channels only i * o is much more like true OOP from Erlang processes.

I mean, that doesn't mean it's good just because someone else does it.

Oh, like this
eval = case _ of
  Rerender next -> do
    st <- H.get
    H.query (SProxy :: SProxy "child") unit $ H.action $ DoSomething st.usedToBeInput
    pure next
  ...

Doesn't that defeat the point of "declarative", if we have to imperatively update everything to  keep it in sync?

I have no problem adding a Rerender hook, btw. I just don't think it's a great replacement for inputs.

Well, querying isn't declarative too :)
Inputs are just queries, right? We send i to receiver, it constructs Query a and then eval is called. This i lives in parent component. All that declarativity is simply sugar propagated to type signature.

I mean, that doesn't mean it's good just because someone else does it.

But this is not so bad idea too. This approach is very old and solid.
What I'm trying to say is that we have too much public interfaces in component. And too much type parameters. If we want to introduce lifecycle algebra, then we could take a chance to remove at least one type parameter. g if we ok with async communication (BTW, it looks like this thing could be synchronous as well) or i if we want to preserve component algebra.
Actually, i functionality could be implemented via g, and g could be implemented via i * o :)

Well, querying isn't declarative too :)

I'm not saying that there shouldn't be imperative querying. I'm saying that only having imperative querying is not good, and makes the library strictly less useful. If we are using a pure functional language, why would we make imperative, effectful updates the only means of communication? I just don't see why this would be desirable.

All that declarativity is simply sugar propagated to type signature.

It is sugar, but it's not sugar you can easily recover if you remove it from the library. Could you tell me how I could realistically recover declarative updates if we removed the sugar from the library?

But this is not so bad idea too. This approach is very old and solid.

My point is that it isn't a goal of Halogen to conform to Erlang, so saying "This is how Erlang does it" isn't a motivation or reason to accept a proposal.
If we remove g in favor of always async communication (while it can potentially be synchronous, it is semantically async), then I guarantee you will immediately try to recover requests by piecing together some baroque, out-of-band AVar communication. Decoupling the two is terrible for the use case that requests solve.

I agree, having to mess with UUIDs/AVars whatnot to match request/responses is always worse when a synchronous interface is possible instead.

Why? How else do you keep something in sync?

I'm not suggesting we do it at all, I'm saying if we were pushing to cut down the communications options (not that I think we should particularly), I dislike inputs-as-queries enough that I'd rather lose inputs than queries. 😜

Because communication is effectful and imperative, right?

I don't fully understand what point you are trying to make. Can you clarify?

I couldn't of course, because it's almost impossible. I agree that w/o i and Rerender component is less powerful stuff. But with Rerender there is no any difference.

Maybe it's not just sugar then, if it isn't something you can recover? I would say there is a difference. Take for example a list of components. Right now there is a single (declarative) source of truth for coordinating a component's position and parameters. A post-render hook would mean I now have to split that logic into two and make two traversals manually, which just introduces the opportunity for them to drift. I don't agree that these are "the same". You can maybe achieve the same end-result, but post-hook is clearly much more brittle and inefficient.
request :: i -> HalogenM f s ps o m (Maybe o)

This is not equivalent to a request though. Requests have well-typed responses specifically so you don't have to deal with partiality and the bugs it introduces. By only making the result o, you are saying "this could be relevant or not relevant at all". You can't even return a single o, since you can raise any number of times, or not at all. I don't agree that this simplifies anything, it just introduces more edge cases.

Because communication is effectful and imperative, right?

Nevermind, I described different concept with word communication. Now I see your point.
Hm... You've convinced me about preserving i. I've just recollected that before i we used to use slots for this type of stuff, and that wasn't cool at all.
request :: i -> HalogenM f s ps o m (Maybe o)

I still think that there is a way of unification g and i * o preserving current semantics. But straightforward removing of one or another wouldn't work, yep. Thanks for discussion, that was really helpful 😃

I'd say there's a semantic difference between what g is for and i * o too:

No i value is ever guaranteed to raise an o, but with g, aside from infinitely waiting or other "lies" there's no way to avoid providing a reply to a request
os can arise without any kind of i having happened - they can arise from within the component itself, for example, via intervals, websockets, etc. as well as interactions with the DOM

We could definitely take a more fundamentalist approach to how some of these things work, removing forking and such so that every o would have to arise from an i, so the component has to send is to itself again, but we've been down that road with an older iteration of Halogen and I'm not sure it's any better.
I think simplicity of implementation is a nice goal, but for a library like this, where there are a wide variety of uses and no real strong underlying model that covers all of them naturally, providing an interface that provides easy ways to do things the "right" way (in our opinion - derived from experience of doing it other ways and finding them harder to work with) is the better way to go.
Perhaps some unifications will arise again in the future that result in things being simplified again (I have some ideas that I'd like to experiment with that would reduce or maybe erase the interface difference between elements and child components, for example). But as long as we don't end up with a sprawling interface with many different entirely equivalent ways to solve the same problem, I think we're still good.

And FWIW, I agree that it would be nice to have fewer type variables, but with this proposal it's not any more unique parameters than what we currently have since we are removing one by using rows for children. I also agree that we should bikeshed parameter order some.
I also don't think that this fundamentally makes anything more complex. In fact it makes a lot of use cases far simpler since inputs don't have to be functors. With rows for slots, component modules can export their own slot constructors, so it's easy to write simpler Component newtypes (rather than aliases) that can be unpacked in the slot constructor. I don't love having lots of Component variations, but I think it lets us better encapsulate opinionated use cases (in other libraries maybe).

In reference to this specific proposal, I'd really like to hear some ideas around handling the partiality of proxied requests. I don't like that it makes top-level requests partial, but it may be inevitable since you can halt anyway.

Could we have g a and then use g ~ MaybeT g' for the non-root case? Or would that introduce too much parameter junk, etc?

The problem I have with that is that it special cases the root component. That would mean if I had a root component, and then decided to wrap it in some way, I would have to go back and change it so that it works under MaybeT.

One thing we could do is just keep the root request as "total", and insert a halt if the request returns Nothing. I don't think that's any less total than what we have now since anyone can halt at any time.

Yeah, that sounds reasonable to me... so Nothing becomes Halt in the DriverIO query result basically?

Yes, but we can also just go ahead and return a Maybe. If someone wants to use note to unwrap it, they can. 🤷♂

Bike-shedding parameter order:
data Component g m i o

data HalogenQ g i a

data HalogenM s ps f o m a

data HTML ps f

-- Encourage this type synonym which has parameters in the
-- same order as HTML and Component.
type HalogenEval s ps f g m i o = HalogenQ g i ~> HalogenM s f ps o m

Don't we need the parameter for the HTML argument still?
I'd vote the m coming pretty close to the front if it's not at the end - maybe like Component h m g i o - that way the things that change within an app are all grouped at the end, and the h m that must be consistent throughout are up front, and could even be synonym'ded; MyAppComponent = Component HTML Aff. I'd also like to keep the argument order consistent in all places that it occurs, to make it somewhat possible to remember / figure out at least.

Don't we need the parameter for the HTML argument still?

Yes, of course. I knew I was forgetting something.

I'd also like to keep the argument order consistent in all places that it occurs, to make it somewhat possible to remember / figure out at least.

I would too, but I think the problem is the MonadTrans instance, which requires the m to be second to last. Would we remove that? Or are you just referring to the synonym? Do you have suggestions for the other types?

Damn, you're right. I'll take another look at this later today.

I'm excited about this 👍

authors: cryogenian garyb kRITZCREEK natefaubion paulyoung

repo: slamdata/purescript-halogen


text:
Support time-based triggers for process managers

To allow long running process managers to handle timeouts.
A process manager may request to be notified after a given period or at an exact date and time.
When the time arrives the process manager is notified and it may dispatch commands in response.
Requires consideration of how to persist these time-based triggers to survive application restarts and process crashes.

It feels weird to have commands that are dispatched later.
It seems better to have some kind of timed process (which should be a PM probably, and we already talked about PMs and timers) which just sends the command later. Just a ExpireOrder command that changes the state of the Order, no? Besides, a PM can control the expiring process if the command is dropped for any reason, something you can't do if you just send a delayed command once.

It's possible to implement time-based triggers using an external job scheduler and by raising events to set the callback time period (date time, recurring interval) and command to dispatch.
An standard event hander would then configure the job scheduler at the requested period to dispatch the command. This requires no changes to Commanded itself. It could be implemented as a standalone library.

Why? Is there anyone who needs this?
I agree with @Papipo that it should be done in PM. This seems to me like a business concern, and so it should not be done in a framework. Unless you need timers for things like periodic snapshotting etc. But that is not what you're talking about here, I think.

Closing, could be implemented as an external library.

authors: Papipo drozzy slashdotdash

repo: slashdotdash/commanded


text:
Purple border color

He3 seems to suffer from a strange purple border. Would be nice to get rid of it.

Somehow it just disappeared. Fixed I guess 😂

Ok, it occasionally appears again. Would be nice to not have that issue 🚀

Yeah, it's nod to the window's drag state - dragging something into the view will lite it, kinda a visual handle bar.
The intent was to give a visual cue while dragging into the view.
Fixed post build 8418 - "might" make it to 1.0.4 in review.

I've got this too. Would definitely prefer not to have it.
Would be nice to have non-rounded corners on the window as a whole too but not sure what's possible.

authors: Cygnusfear paulmist slashlos


text:
CDC Streaming to support data sinks and event driven architectures

Is your feature request related to a problem? Please describe.
I'd like to be able to continually capture writes happening in SlateDB and stream these to downstream sinks e.g. to populate Delta or Iceberg tables for analytics use cases.
Describe the solution you'd like
Given a Db struct, I'd like a way to access a Stream trait impl (or something similar) that yields all events after a given point in the log.
It would be great for this to allow a choice of either a committed or uncommitted event stream.
Ideally this would also support back-pressure onto the log that is already on object storage.

@pragmaticanon, @flaneur2020, and @vigneshc have been thinking about snapshots, range queries, and transactions. I think the CDC streaming feature is most like range queries since both open iterators (although quite different).
This is going to require an RFC. I can think of a few ways to implement this:

The iterator can tail the WAL.
The iterator can tail L0.

We need to consider how to make sure the compactor and writer don't advance the WAL low water mark or delete L0 SSTs that the CDC iterator hasn't gotten to yet.

One note: Regardless of whether we do WAL or L0 tailing, CDC streams will not see in-memory writes that were overwritten or deleted. For example, if we have a timeline like this:
t0 put(k1, v1)
t1 put(k1, v2)
t3 flush()

The WAL will contain only (k1, v2).  And the WAL would not contain an entry at all if we had t2 delete(k1). We could theoretically change the behavior of the WAL to contain all writes, not just the final per-key writes. I'm hesitant to do that, though.

@agavra this might also be an opportunity to have the CDC iterator work by timestamp. For example, db.iterator(start_instant);.

This is a great use case and as @criccomini shared in the earlier comment, it is a combination of range queries, snapshots and transactions.
Expanding on @adammilnesmith 's description of the solution, and reducing the scope to committed data only, I see the requirement as.

There is an external system that needs to be kept in sync with state of slateDB.
This sync happens at some discrete points. i.e. Sync1 happens, some changes to slateDB happens and then Sync2 copies the changes committed after Sync1.
Sync2 should work even in the presence of compaction, garbage collection.
It is more a mechanism for copying the state than a stream of all changes, Chris shared the example of two writes.

Manifest is already a log of mutations to SlateDB. I think adding few more restrictions to the kind of mutations allowed would enable this scenario.
We would need

A mechanism to iterate all the records on a snapshot. This would already exist after #54 .
A mechanism to iterate the records between two snapshots. This would be new. We should be able to leverage most of the iterator code. It is essentially a mini slateDB with a subset of the state (i.e. just the files between two snapshots).
Garbage collection would already not delete the files that are contained in snapshots. Likely no changes are needed.
Compaction has no restriction on the kind of files that it selects for compaction. One issue that could happen is that the "CDC iterator" would not be able to take advantage of compaction. Adding a small restriction to compaction logic, to not have compaction mix files before snapshot and after snapshot would solve this. For example, say Sync1 was on Snapshot1. Compaction can either be i) Sources, Destinations are all contained in Snapshot1 [or] ii) Sources, Destinations are all not contained in Snapshot1, they are created after.

CDC iterator would delete Snapshot1 after it copies data until Snapshot2, and after that compaction's restriction would be based on Snapshot2.

@criccomini I suspect it probably makes more sense to have the API use sequence numbers so you can get deterministic semantics of where it starts off from. That does mean that we'd have to expose an API to get the current sequence number. It would be useful to also expose a (best effort) mapping from timestamp -> sequence number similar to what Kafka does for mapping timestamp -> offset.

authors: adammilnesmith agavra criccomini vigneshc

repo: slatedb/slatedb


text:
Allow "subject is randomized" type idea in expression engine

Gives more flexibility in writing new expressions/checks. E.g. "subject is randomized and X-design is missing".
Sort of similar to issue #594

Reopening this issue as it will help define reports via API better by being able to state that a subject is randomized.

authors: mrueschman remomueller

repo: sleepepi/slice


text:
Router not working properly on subdir

Hi all, I discovery this framework yday and I loved it. I have a small problem though, locally on my apache server everything was working fine, on the shared hosting though I have a problem on routing, basically all the first level routes works like a charm:
GET blabla.com/subdir/api/items
GET blabla.com/subdir/api/ping
GET blabla.com/subdir/api/blabla

the problem appear once I try to access to more complex routes
GET blabla.com/subdir/api/items/2/blabla

I think it must be something related to the .htaccess, which, again locally was working.
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [QSA,L]

i put this in the same dir as the index.php file so /www/subdir/api
Is that a problem of my hosting or someone else had this problem before? I was searching around either in the issues here and in the forum but I could not find anything related.
Thank you in advance

How does your code look like?

I am terribly sorry, I just realize that I was missing some files and so was not a route problem. thank you the same, and apologize

repo: slimphp/Slim


text:
Is it possible to colour the tokens based on some client side logic?

Hi,
I would like to colour the tokens various colours based on some business logic. Can someone point me in the right direction of what event to hook and how to do this?

You can use the hook
          .on('tokenfield:createdtoken', function (e) {
                // Perform your logic here
               if(true) {
                 $(e.relatedTarget).addClass('green-token');
               } else {
                 $(e.relatedTarget).addClass('red-token');
               }

           })

authors: Ajeey natiki

repo: sliptree/bootstrap-tokenfield


text:
Animation

Hi, did you try to animate this? I'd like to use HoroscopeDrawer in my project and I'm thinking of how to approach animation. Imagine you could move planets traversing the horoscope.

Hi @agatac! Thanks for your question. Unfortunately, I do not have time to further develop this project atm. However, for further versions I wanted to add especially aspects. Animations have not been planned. I fear, though, that a rewrite with react+d3 would help to make this code more scalable. Feel free to contribute! Cheers, Samuel

authors: agatac slissner

repo: slissner/HoroscopeDrawer


text:
Add Kubernetes storage ID validation

Closes #179

Codecov Report

Merging #180 into master will increase coverage by 0.87%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #180      +/-   ##
==========================================
+ Coverage   75.77%   76.65%   +0.87%
==========================================
  Files          27       27
  Lines        1218     1221       +3
==========================================
+ Hits          923      936      +13
+ Misses        218      213       -5
+ Partials       77       72       -5

Impacted Files
Coverage Δ

internal/storage/kubernetes/kubernetes.go
92.30% <100.00%> (+8.05%)
:arrow_up:

Continue to review full report at Codecov.

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

authors: codecov-io slok

repo: slok/kahoy


text:
How to extract the named entity from the text

I need to find the named entity or entity from the text. But i did not find anything related in the docs.
I got a something from the textblob library
`
from polyglot.text import Text
blob = """The Israeli Prime Minister Benjamin Netanyahu has warned that Iran poses a "threat to the entire world"."""
text = Text(blob)
text = Text(blob, hint_language_code='en')
print text.entities
[I-ORG([u'Israeli']), I-PER([u'Benjamin', u'Netanyahu']), I-LOC([u'Iran'])]
`
This is using the polyglot. Is any way to find entites using the textblob library ?

[thing[0] for thing in blob.tags if thing[1] == u'NNP']

repo: sloria/TextBlob


text:
Feature/PreprintView Improvements

Purpose

Adds a create_index method to BaseMetric (might not be needed)
Add save method to Metric which adds timestamp and index before saving
Moves date format to settings
Deletes indices before and after every test
Add test_create_document and test_create_index

TODOS

[ ] https://github.com/sloria/django-elasticsearch-metrics/pull/5#discussion_r205784707
[ ] https://github.com/sloria/django-elasticsearch-metrics/pull/5#discussion_r205802781

Changes made @sloria, remaining todos are listed here.  I propose merging this, and these todos can be addressed in subsequent PR's

I made issues for the TODO items: #14 #15

authors: pattisdr sloria

repo: sloria/django-elasticsearch-metrics


text:
Μοντελο Προπαρασκευης

Καλησπερα, θα ηθελα να κανω μια ερωτηση για το DNN της προπαρασκευης. Πειραζει, αν για το binary classification χρησιμοποιησουμε το crossentropy και οχι το BGE, καθως δεν ειμαι πολυ σιγουρος για το πως να το χρησιμοποιησω ειχα κανει μια προσπαθεια αλλα δεν μου βγαζε καθολου καλα αποτελεσμα και δοκιμασα με το crossentropy και για το trainset βγαζω accuracy κοντα στη μοναδα και για το testset 80%.

Καλημέρα, καταλαβαίνω ότι το νευρωνικό που χρησιμοποιείς έχει 2 εξόδους (νευρώνες στο τελευταίο layer). Στην περίπτωση αυτή, μπορείς να χρησιμοποιήσεις το CrossEntropyLoss αντί του BCEWithLogitsLoss. Μια σχετική συζήτηση μπορεί να βρεθεί εδώ.

Ναι ακριβως αυτο γινεται. Ωραια σας ευχαριστω πολυ.

authors: mpektkd pxaris

repo: slp-ntua/slp-labs


text:
[e2e]: go schedule main noldflags-multi-uses slsa3

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/7648971608
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.go.schedule.main.noldflags-multi-uses.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.go.schedule.main.noldflags-multi-uses.slsa3.yml
Trigger: schedule
Branch: main
Date: Thu Jan 25 02:21:50 UTC 2024

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/7663087358
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.go.schedule.main.noldflags-multi-uses.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.go.schedule.main.noldflags-multi-uses.slsa3.yml
Trigger: schedule
Branch: main
Date: Fri Jan 26 02:17:42 UTC 2024
Tests are passing now. Closing this issue.

repo: slsa-framework/slsa-github-generator


text:
Database connection pool leaking

I found that the database connection pool leaking in use with sftl file,
However the direct use of annotation such as  '@ Query' doesn't have this problem,
So I need something for help.  @stormning

please use
if you are using spring-boot, please set spring.jpa.open-in-view=true
otherwise setup  org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter
this is the same issue: https://github.com/slyak/spring-data-jpa-extra/issues/2

authors: onlychan stormning

repo: slyak/spring-data-jpa-extra


text:
Can't work fine if format is "yyyymm"

datetimepicker seems can't parse a "yyyymm" string properly.
Is there any solution ?
Thx.

datetimepicker seems can't parse a "yyyymmdd" string properly too.

@Redx126 @netmou - Appears to be working from this jsfiddle: https://jsfiddle.net/g4Lbfveq/ maybe you should consider using the latest version.

same issue #641.

repo: smalot/bootstrap-datetimepicker


text:
Publish to maven central

json-logic-kotlin is published only to jcenter. Please consider publishing it also to mavenCentral, as jcenter is shutting down in May.

jCenter() has now shutdown, and since this lib isn't yet in mavenCentral() is causing builds to fail.
Of course we can just build from source ourselves ( OSS fwd 👍  ), though if the library author has time to re-publish it in mavenCentral() it'd be nice :)

authors: KushtrimPacaj jaxxar


text:
Transcript logging on every image save

The method ScriptStarter class>>#startUp in the Scripting package makes this:
	IsResuming ifFalse: [ Transcript show: 'ScriptStarter did not execute a given script, since it assumes to be executed after a snapshot and not during startup.'.
		^ self. ].

Which means that this class writes the text to Transcript on every normal image save. Moreover, it does not end it with cr which makes it even more annoying.

Sorry, all I can say is: PRs welcome :)

authors: pavel-krivanek smarr

repo: smarr/SMark


text:
HSV struct fields are named inconsistent

The RBG struct in https://crates.io/crates/rgb names the fields "r", "g" and "b". This crate uses "hue", "sat" and "val".
This is a change that would break dependent applications, but I it would be more consistent to use "h", "s" and "v".

I personally prefer the longer abbreviations for the hsv fields, since it's easier to remember what they refer to that way. With rgb, it's not an issue, so the shorter ones are fine (there are also no obvious tlas).

authors: david-sawatzke jounathaen

repo: smart-leds-rs/smart-leds


text:
Create login authN page for CLI

Modeling how the OpenShift client works, we want to create a login endpoint that could return a message like the following to let you know where the /oauth/token/request page is located:
$ oc login
You must obtain an API token by visiting https://foo.bar/oauth/token/request

This does not have to be a protected endpoint since this is general info.
Maybe /login?

@marshallmcdonnell And presumably if there is no oauth or you presented valid credentials to it, it returns an HTTP OK?

@SmithRWORNL yes, that sounds good! Except with Username and Password, it won't really "log you in" for now :grin:

Closed via https://github.com/smart-spectral-matching/ssm-service-catalog/pull/4

authors: SmithRWORNL marshallmcdonnell


text:
add licenses and break up readme's

Adds Licensing and breaks up readme's for new project structure

Codecov Report

Merging #989 into feature/sdl_java_base will increase coverage by 0.05%.
The diff coverage is n/a.

@@                     Coverage Diff                     @@
##             feature/sdl_java_base     #989      +/-   ##
===========================================================
+ Coverage                    44.27%   44.32%   +0.05%
- Complexity                    3541     3542       +1
===========================================================
  Files                          430      430
  Lines                        19603    19603
  Branches                      2137     2137
===========================================================
+ Hits                          8679     8690      +11
+ Misses                       10492    10480      -12
- Partials                       432      433       +1

Impacted Files
Coverage Δ
Complexity Δ

...smartdevicelink/encoder/VirtualDisplayEncoder.java
28.97% <0%> (+4.54%)
8% <0%> (ø)
:arrow_down:

...tdevicelink/Dispatcher/ProxyMessageDispatcher.java
61.76% <0%> (+8.82%)
4% <0%> (+1%)
:arrow_up:

Continue to review full report at Codecov.

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

authors: BrettyWhite codecov-io


text:
Feature/sync cloud methods

expose getAuthToken in SdlManager
add logic in LifecycleManager to download cloud icons onSystemRequest

Codecov Report

Merging #992 into feature/sdl_java_base will not change coverage.
The diff coverage is n/a.

@@                   Coverage Diff                    @@
##             feature/sdl_java_base     #992   +/-   ##
========================================================
  Coverage                    44.28%   44.28%
  Complexity                    3542     3542
========================================================
  Files                          430      430
  Lines                        19603    19603
  Branches                      2137     2137
========================================================
  Hits                          8682     8682
  Misses                       10490    10490
  Partials                       431      431

Continue to review full report at Codecov.

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


text:
feat: Customize clusterctl

Deploy Cluster API common providers, infrastructure VirTink providers
https://github.com/smartxworks/cluster-api-provider-virtink/blob/dd04979a2321417b9523477c3a461893121326b5/README.md#deploy-cluster-api-provider-virtink

@carezkh The commit message doesn't sound right. We are not customizing clusterctl, but are trying to adapt to it


text:
.loop centered chrome problem

I like this carousel alot, but in chrome (win xp and win 7)  the loop option gives an unwanted lazyload effect on the duplicated images. So when it slides there is a blank space for about .5 sec. I use loop together with the center option. Hope there is a solution. Thanks.
I also noticed the images are a bit blurry in chrome, other main browsers work ok. Maybe i should go to chromes forum about this.

Can someone verify that this is still an issue?

@joeyjoejoejr yes, I can reproduce it on Mac Chrome 40.0.2214.111 (64-bit).
The solution from https://github.com/smashingboxes/OwlCarousel2/issues/599 works well.
Hope it helps.

authors: basscan dani-z joeyjoejoejr


text:
add base CLI with --help and --version (solves #3)

basic API with --help and --version commands. supposed to be a base for future commands

still have to write tests ✅

this has a follow up task: #17

@Philipp1221 I added "setuptools>=46.1.0", "setuptools_scm>=5" to setup.cfg.
this installs the dependencies for --version

repo: smaxtec/sxapi


text:
Prompts

Prompts
User Story
AS AN employee with access to sensitive data
I WANT to randomly generate a password that meets certain criteria
SO THAT I can create a strong password that provides greater security
Acceptance Criteria
GIVEN I need a new, secure password
WHEN I click the button to generate a password
THEN I am presented with a series of prompts for password criteria

This has been completed


text:
Ensure permissions on /etc/hosts stay intact

Fixes issue https://github.com/smdahlen/vagrant-hostmanager/issues/160

Thanks! This looks reasonable.

authors: seth-reeser tonylambiris

repo: smdahlen/vagrant-hostmanager


text:
Problem in filtering library by discipline

As you can see in the screenshot below, not all cards with Spiritus appears if I apply the filter.
I didn't tested if other disciplines have the same problem.
I can help with fixing the problem if needed

Some filters were broken after last update (especially when using multi-filtering with [+] button), I'll try to fix in in the next few days.
If I'll feel I need help I'll let you know, thanks!

Fixed in 78d5a217e27e95206cac79c43f53080d27fd8588 (not yet at https://vdb.im, will be there in the next update).

authors: SimoParmeg smeea

repo: smeea/vdb


text:
Upgraded the busboy package to latest version and updated the relevant code

Fix: I have come across one dependency issue of package dicer
I have came across that latest busboy package is no longer using the dicer package.
So I have updated the dependencies and bit of code change to support the formats and error push methods.
(to make sure unit test is passing)

Hi @smeijer
Can you review this? This is my first PR, and I'm not sure if I have completed everything as expected.

hi @PandiyanCool , thanks for the contribution! Much appreciated.
I've reverted some of your changes, as removing testing logic to make it pass, is really a no-go, and many of the source/formatting changes were simply unneeded.
I'm going ahead and merge & release this now. Thanks again!

Cheers!

@all-contributors please add @PandiyanCool for code

authors: PandiyanCool smeijer

repo: smeijer/next-runtime


text:
docker image

Hi,
Thanks very much for creating this pipeline! I'm just trying to get started. I'm on OSX and need Fay&Wu's H in particular so I'll be using docker. Unfortunately I'm not able to find your images in the repository.
$ sudo docker build -t selectiondocker/selectiontools selectionTools/docker/
sends back
FATA[0000] stat selectionTools/docker/: no such file or directory
$ docker search selectiontools
finds nothing
$ docker search selection
finds packages by thedutchselection, so it seems docker search is working.
Thanks very much for your help!

Hi,
Great to hear you're interested in our pipeline!
I'm still pretty new to docker so only worked out enough to make a dockerfile to build an image. I haven't committed it to the docker repository so that is why you won't find it there.
My first thought is it could be an issue with where you are running the command from.
my dir structure is:
/home/murray/selectionTools/docker
and I ran the command  sudo docker build -t selectiondocker/selectiontools selectionTools/docker/  from /home/murray/ and it worked for me
Let me know if that resolves the problem
Murray

Hi Murray,
That totally makes sense. I thought the command was meant to pull it from the docker repository rather than from a local file. I should have had a look at the directory. It's installing now.
Thanks very much!
Stevan

Thanks,
I'll update the documentation to make this clearer
Murray

authors: murraycadzow stevanspringer

repo: smilefreak/selectionTools