text:
Add channel points custom rewards creation feature

Update from twitch changelog 2021‑05‑24

Polls and Channel Points Predictions Twitch API endpoints have moved from public beta to general availability.
Polls and Channel Points Predictions EventSub subscription types have moved from public beta to version 1.

Update from twitch changelog 2021‑05‑21

Extension Bits Transaction Create EventSub subscription type has been added as a public beta.
Channel Points Custom Rewards - The API reference for Custom Rewards endpoints has been updated for consistency and to clarify conditional requirements for body parameters. For example, max_per_stream is required if a value for is_max_per_stream_enabled is also provided.

Update from twitch changelog 2021‑05‑14

Channel Prediction Lock EventSub subscription type - corrected the name of the lock timestamp to locked_at.
Channel Prediction End EventSub subscription type - removed the locked_at field due to edge cases with Predictions that are cancelled or closed early.
Create EventSub Subscription and Get EventSub Subscriptions - limit removed following the new EventSub subscription limit cost-based system.
Get Channel Information - Added delay to return values table and example payload.

Pull Request Test Coverage Report for Build 880004386

13 of 13 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.04%) to 96.127%

Totals

Change from base Build 847537501:
0.04%

Covered Lines:
968

Relevant Lines:
1007

💛  - Coveralls

source: gharchive/pull-request

authors: Scorfly coveralls

license: MIT

license_type: permissive

license_source: github-api


text:
chore(package): update babel-plugin-transform-class-properties to ver…

…sion 6.19.0
https://greenkeeper.io/

Coverage remained the same at 100.0% when pulling 0fcdaac97d8b1b07694c183b379e213bb4ad8f10 on greenkeeper/babel-plugin-transform-class-properties-6.19.0 into d9e1348cf66cd938b928ae2da69517f636294def on master.

Coverage remained the same at 100.0% when pulling 0fcdaac97d8b1b07694c183b379e213bb4ad8f10 on greenkeeper/babel-plugin-transform-class-properties-6.19.0 into d9e1348cf66cd938b928ae2da69517f636294def on master.

authors: coveralls nickschot

repo: nickschot/lux-jwt

license: mit

license_source: bigquery


text:
Fixed typo

Hi !
I'm not sure I'm good enough to help but I'm interested on this plugin as I find pytest and most of testing tools ugly in the Python ecosystem.
Dunno how I can help, in all cases I will use this plugin for my next Python project 😁

Thanks!

authors: joshuadavidthomas mickaelandrieu

repo: nicoddemus/pytest-rich


text:
[Feature Request] - Add Disarm Service

Although can do this with an alarm panel call, would be helpful to have the "Disarm" as a service the same as arm.
Again for doing push notification actions, as well as in my case, using NFC tag to disarm.

What would be the difference between alarm_control.panel.alarm_disarm vs a alarmo.disarm ?
I don't see the added value (other than a shorter name) in adding this.

I suppose it is partially consistency, if there is an alarmo.arm, why not alarmo.disarm?
If there is an arming service, would expect there to be a disarming service.
Also to avoid confustion, alarm_control_panel gives the impression of using the alarm_control_panel in lovelace (its really an HA issue with that naming convention), but can be helped by this integration.

This service is added in v1.5.7.
As said, alarm_control.panel.alarm_disarm and alarmo.disarm have the same behaviour.

source: gharchive/issue

authors: nielsfaber seanmccabe

repo: nielsfaber/alarmo


text:
Unable to reproduce examples

Hi, fantastic work! I am trying to run the examples in the repository. For example, I am trying to dump the Structurizr DSL for chatserver components view by running the following command, however it is currently crashing:
pystructurizr dev --view example.chatserver_componentview

Here's the stacktrace:
Setting up live preview of view example.chatserver_componentview...
Generating diagram...
Traceback (most recent call last):
  File "/home/dee/.pyenv/versions/3.8.14/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/home/dee/.pyenv/versions/3.8.14/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/home/dee/learn_xyz/learn_structurizr/pystructurizr/pystructurizr/cli.py", line 96, in <module>
    cli()
  File "/home/dee/.pyenv/versions/3.8.14/envs/pystructurizr/lib/python3.8/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/home/dee/.pyenv/versions/3.8.14/envs/pystructurizr/lib/python3.8/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/home/dee/.pyenv/versions/3.8.14/envs/pystructurizr/lib/python3.8/site-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/dee/.pyenv/versions/3.8.14/envs/pystructurizr/lib/python3.8/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/dee/.pyenv/versions/3.8.14/envs/pystructurizr/lib/python3.8/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/home/dee/learn_xyz/learn_structurizr/pystructurizr/pystructurizr/cli.py", line 21, in dump
    diagram_code, imported_modules = generate_diagram_code(view)
  File "/home/dee/learn_xyz/learn_structurizr/pystructurizr/pystructurizr/cli_helper.py", line 15, in generate_diagram_code
    module = importlib.import_module(view)
  File "/home/dee/.pyenv/versions/3.8.14/lib/python3.8/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1014, in _gcd_import
  File "<frozen importlib._bootstrap>", line 991, in _find_and_load
  File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 671, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 843, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/home/dee/learn_xyz/learn_structurizr/pystructurizr/example/chatserver_componentview.py", line 1, in <module>
    from example.workspace import workspace
  File "/home/dee/learn_xyz/learn_structurizr/pystructurizr/example/workspace.py", line 1, in <module>
    from pystructurizr.dsl import Workspace
  File "/home/dee/learn_xyz/learn_structurizr/pystructurizr/pystructurizr/dsl.py", line 255, in <module>
    class Style:
  File "/home/dee/learn_xyz/learn_structurizr/pystructurizr/pystructurizr/dsl.py", line 256, in Style
    def __init__(self, style_map: dict[str, str]):
TypeError: 'type' object is not subscriptable
Traceback (most recent call last):
  File "/home/dee/.pyenv/versions/pystructurizr/bin/pystructurizr", line 8, in <module>
    sys.exit(cli())
  File "/home/dee/.pyenv/versions/3.8.14/envs/pystructurizr/lib/python3.8/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/home/dee/.pyenv/versions/3.8.14/envs/pystructurizr/lib/python3.8/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/home/dee/.pyenv/versions/3.8.14/envs/pystructurizr/lib/python3.8/site-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/dee/.pyenv/versions/3.8.14/envs/pystructurizr/lib/python3.8/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/dee/.pyenv/versions/3.8.14/envs/pystructurizr/lib/python3.8/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/home/dee/.pyenv/versions/3.8.14/envs/pystructurizr/lib/python3.8/site-packages/pystructurizr/cli.py", line 56, in dev
    asyncio.run(observe_loop())
  File "/home/dee/.pyenv/versions/3.8.14/lib/python3.8/asyncio/runners.py", line 44, in run
    return loop.run_until_complete(main)
  File "/home/dee/.pyenv/versions/3.8.14/lib/python3.8/asyncio/base_events.py", line 616, in run_until_complete
    return future.result()
  File "/home/dee/.pyenv/versions/3.8.14/envs/pystructurizr/lib/python3.8/site-packages/pystructurizr/cli.py", line 50, in observe_loop
    modules_to_watch = await async_behavior()
  File "/home/dee/.pyenv/versions/3.8.14/envs/pystructurizr/lib/python3.8/site-packages/pystructurizr/cli.py", line 45, in async_behavior
    result = generate_diagram_code_in_child_process(view)
  File "/home/dee/.pyenv/versions/3.8.14/envs/pystructurizr/lib/python3.8/site-packages/pystructurizr/cli_helper.py", line 34, in generate_diagram_code_in_child_process
    child_output = run_child_process()
  File "/home/dee/.pyenv/versions/3.8.14/envs/pystructurizr/lib/python3.8/site-packages/pystructurizr/cli_helper.py", line 30, in run_child_process
    output = subprocess.check_output([sys.executable, "-m", "pystructurizr.cli", "dump", "--as-json", "--view", view])
  File "/home/dee/.pyenv/versions/3.8.14/lib/python3.8/subprocess.py", line 415, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "/home/dee/.pyenv/versions/3.8.14/lib/python3.8/subprocess.py", line 516, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['/home/dee/.pyenv/versions/3.8.14/envs/pystructurizr/bin/python3.8', '-m', 'pystructurizr.cli', 'dump', '--as-json', '--view', 'example.chatserver_componentview']' returned non-zero exit status 1.

For reference, I am running pystructurizr in Python version 3.8.14.

I've created a PR to fix this: https://github.com/nielsvanspauwen/pystructurizr/pull/2. I'm also able to run the examples now. Thanks for the work!

Thank you for your contribution!

authors: DhanshreeA nielsvanspauwen

repo: nielsvanspauwen/pystructurizr


text:
parse object

Have you considered supporting parsing objects?
e.g. SOME_VARIABLE={"test": "hello"}, currently, we get SOME_VARIABLE: '{"test": "hello"}', but since that string is JSON parsible, would be nice to parse it into an object.

PR welcome

authors: ShaneZhengNZ niftylettuce

repo: niftylettuce/dotenv-parse-variables


text:
Recommendation: Typora

Hi,
I came across your repo and first of all I want to say kudos! 🙏 I learned about several good apps and couple of better alternatives to what I currently use.
One recommendation I have is Typora for working with markdown files and projects. It has many features including file organization, themes, import/export to several file types, syntax highlighting, diagrams, and etc. It's also free while it's in beta stage.
I have used Marked before and find Typora more user friendly. I recommend you give it a try.
Again, thanks for the awesome repo!

I also love Typora! Only problem is that it does not yet seem stable. Crashes are not often but regular enough to be noticed.

thanks for suggestion but I use Sublime Text & Ulysses for wiring

authors: behroozk keehun nikitavoloboev

repo: nikitavoloboev/my-mac-os


text:
Standards compliant equality check

Implement deep comparison by value as mandated by the FEEL specification / DMN TCK.
[{b: [1]}, {b: [2.1,2.2]}, {b: [3]}, {b: [4, 5]}].b =
[[1], [2.1, 2.2], [3], [4, 5]]

Shipped with v0.30.0.

repo: nikku/feelin


text:
Viewing the built file or config to save the built file at a known location

Is there a way to view the built file after a test run? Of course, I can access it through the assets but because every time it changes the file name, I would rather have a specific location where I know where the built file is for me to check errors at specific locations. Thanks!

Specify autoWatch + bump up the LOG_LEVEL in order to get the path of the bundle file.
This way you may have a look into it, i.e. using Chrome or on the file system.

authors: gching nikku

repo: nikku/karma-browserify


text:
Bad Crop / Rendering

Hi,
Sometimes i have bad crop / rendering in my images.
It results with a black part on the bottom of the image.
Many times it works but sometimes it doesn't.
Here is a case, with the log, the html code, the jquery code and the screenshot of the page
Someone have an idea ?
Thank's in advance,
Quentin
Edit : I'm under html2canvas 0.5b4

log_html2canvas.txt
htmlcode.txt
javascript_code.txt

Is this still an issue with v1.0.0? If so, could you please share an example on jsfiddle.

authors: grka niklasvh


text:
Html medium

Description

added a simple form and wrote the complete css again
Additional Context

Merged

This is an automated message from Fork, Commit, Merge [BOT].

Thank you for your contribution! Your pull request has been merged. The files have been reset for the next contributor.
What's next?
If you're looking for more ways to contribute, I invite you to check out my other projects. Just click here to find more. These projects contain real issues that you can help resolve. You can also check out the Influences section in the README to find more projects similar to this one.
Also please leave a star to this project if you feel it helped you, i would really appreciate it.
I look forward to seeing your contributions!

repo: nikohoffren/fork-commit-merge


text:
License please?

Hi, this is really cool, it's something I've been anticipating doing for a project of mine.
Is there any chance you could add a license file?  I don't like using others' code without some idea of their intentions.
Personally, I've used the BSD license for some of my own stuff. I've also released pure public domain works, though I'm not sure what the formal license for that looks like.
Thanks!

Hi Nick,
I will definitely include license file. Thanks for suggestion. Let me know
if you find any bug or need any improvement.
Cheers,
Nikunj
On 27-Aug-2015 11:52 pm, "Nick Vargish" notifications@github.com wrote:

Hi, this is really cool, it's something I've been anticipating doing for a
project of mine.
Is there any chance you could add a license file? I don't like using
others' code without some idea of their intentions.
Personally, I've used the BSD license for some of my own stuff. I've also
released pure public domain works, though I'm not sure what the formal
license for that looks like.
Thanks!
—
Reply to this email directly or view it on GitHub
https://github.com/nikunjness/mongo-ambari/issues/1.

Haha, perfect. Thanks!

authors: nickvargish nikunjness

repo: nikunjness/mongo-ambari

license: WTFPL


text:
地址无效或者填充失败

直接用m3u的url报地址无效
https://live-hz.xxx.com/player/src/get?id=43aebI1Q051EHJaz&resolution=HD&line=1&session=1832079&token=7h7dgbeqk9fv0
然后尝试把m3u内容保存成文件下载报填充无效
LOG 2020/09/23
Save Path: E:\Download\M3U8\Logs
Task Start: 2020/09/23 16:06:57
Task CommandLine: "E:\Download\M3U8\N_m3u8DL-CLI_v2.7.4.exe" "e:\Download\M3U8\video.m3u" --workDir "E:\Download\M3U8" --saveName "gd" --maxThreads "10" --minThreads "2" --useKeyBase64 "39AC852681867A90AA11C855034B202A" --useKeyIV "19290e922a347cd6240e90d24e7b0891"
16:06:57.950 / (NORMAL) 开始解析 e:\Download\M3U8\video.m3u
16:06:57.980 / (NORMAL) 解析m3u8内容
16:06:57.986 / (NORMAL) 获取m3u8 key... base64:39AC852681867A90AA11C855034B202A
16:06:57.998 / (NORMAL) 写出meta.json
16:06:58.065 / (NORMAL) 开始下载文件
16:07:06.703 / (ERROR) 填充无效，无法被移除。
#EXT-X-KEY:METHOD=AES-128,URI="https://live-hz.xxx.com/player/authorize?id=43aebI1Q051EHJaz&session=1832079&token=47829osk0ai2a",IV=0x19290e922a347cd6240e90d2
KEY的URI要认证授权，怎么破？
meta.json:
{
"index": 0,
"method": "AES-128",
"key": "39AC852681867A90AA11C855034B202A",
"iv": "0x19290e922a347cd6240e90d24e7b0891",
"duration": 30.08,
"segUri": "https://video1-cdn.xxx.com/pub/43aebI1Q051EHJaz/HD/0.ts"
},

这是什么网站的内容呢

gaodun的，获取key要刷新token，只能手动

authors: nilaoda rickywu


text:
nimony: subscripts sans generic instantiations

Code is messy for now, will move out the bugfix addParLes and do the ArrayT reorder as mentioned in #192 first. Also a bug that let arrIndex1: int = x[0] gives got: (i -1) but wanted: (u -1)

I would have done it this way:

proc buildReadAccessor(c: var CheckContext; dest: var Tree; tree: Tree, n: NodePos, acc: string) =
  copyIntoKind(dest, Call, n.info):
    let accessor = c.m.strings.getOrIncl(acc)
    buildSymChoice(c, dest, accessor, n.info)
    for ch0 in sonsReadonly(tree, n):
      copyTree(dest, tree, ch0)

proc semBracketExpr(c: var SemContext; dest: var Tree; tree: Tree; n: NodePos;
                    preferredType: FullTypeId): FullTypeId =
  var tmp = createTempTree(c.thisModule)
  discard sem(c, tmp, tree, n.firstSon, autoType)
  var routines: seq[FullSymId] = @[]
  if isTypeExpr(c, tmp, StartPos):
    rollbackTo c.p, tmp, StartPos
    result = borrowPosition(c, dest)
    semDeclType(c, dest, tree, n, inLocalDecl)
  elif isGenericRoutine(c, tmp, StartPos, routines):
    rollbackTo c.p, tmp, StartPos
    result = semExplicitGenericRoutineInst(c, dest, tree, n, routines)
  else:
    rollbackTo c.p, tmp, StartPos
    buildReadAccessor(c, tmp, tree, n, "[]")
    result = sem(c, dest, tmp, StartPos, preferredType)

proc buildWriteAccessor(c: var CheckContext; dest: var Tree; tree: Tree; n: NodePos, acc: string) =
  copyIntoKind(dest, Call, n.info):
    let accessor = c.m.strings.getOrIncl(acc)
    buildSymChoice(c, dest, accessor, n.info)
    let (le, ri) = sons2(tree, n)
    # flatten the 'BracketExpr' away:
    for ch1 in sonsReadonly(tree, le):
      copyTree(dest, tree, ch1)
    # but not the 'value' of 'a[i] = value':
    copyTree(dest, tree, ri)

  of AsgnS:
    case n.firstSon.kind
    of BracketExpr:
      var tmp = createTempTree(c.thisModule)
      buildWriteAccessor(c, tmp, tree, n, "[]=")
      result = sem(c, dest, tmp, StartPos, preferredType)
    of CurlyExpr:
      var tmp = createTempTree(c.thisModule)
      buildWriteAccessor(c, tmp, tree, n, "{}=")
      result = sem(c, dest, tmp, StartPos, preferredType)
    else:
      semAsgn(c, dest, tree, n)

And then the system.nim adds [] and []= etc for arrays which are mapped to the magic: mArrPut etc.

This is ported from the old compiler, I looked into moving [] into overloads with it and there were some incompatibilities as outlined here but nothing that prevents it from working. Tuples would still have to be special cased I'm guessing.
So AtX would be the parsed expression tag, and then gets semchecked into ArrGetX/ArrPutX/maybe StrGetX/StrPutX etc? Does PatX still exist then?

Alright, your approach wins then.

I wasn't disagreeing with your approach, the incompatibilities are fine imo (namely arbitrary pointer dereference & lax index int type). The backends will probably still need the different magics (except maybe the assign ones), NIFC wouldn't correctly handle AtX with a string operand. Another option would be to change the parsed tag to something other than AtX.

NIFC wouldn't correctly handle AtX with a string operand.

Sure but it's not its job anyway. The lowerer translates it to (at (dot stringObject s +0) i) or something like that, you get the idea.

Another option would be to change the parsed tag to something other than AtX.

Well we need more than just AtX, AtX is nifler's way of saying "a[i]", we should have our specialized variants indeed.

It would be sad to lose this so we should move it to a semcompat.nim file that will do things the Nim v2 way. Prepass for generics & templates, etc yada yada.

authors: Araq metagn

repo: nim-lang/nif


text:
Configurable Path

Make paths configurable in all  NullAwayAutoFixer artifacts.

I would strongly prefer if there wasn't a global path, even as a default. Can we just make the checker fail with a configuration error if run with the autofix flag on and without an explicit value for -XepOpt:NullAway:AutoFixOutPutDirectory?
Also, reminder that another thing that needs to happen is that directory being write-only from the point of view of NullAway, and non-persistent from the point of view of the external toolchain, so the python scripts probably still need another directory to copy ongoing working data to (with the idea being that the AutoFixOutPutDirectory is cleared between compilations).

I would strongly prefer if there wasn't a global path, even as a default. Can we just make the checker fail with a configuration error if run with the autofix flag on and without an explicit value for -XepOpt:NullAway:AutoFixOutPutDirectory?
Also, reminder that another thing that needs to happen is that directory being write-only from the point of view of NullAway, and non-persistent from the point of view of the external toolchain, so the python scripts probably still need another directory to copy ongoing working data to (with the idea being that the AutoFixOutPutDirectory is cleared between compilations).

Ok sure will do that, I will apply these changes now. Thank you.

I would strongly prefer if there wasn't a global path, even as a default. Can we just make the checker fail with a configuration error if run with the autofix flag on and without an explicit value for -XepOpt:NullAway:AutoFixOutPutDirectory?
Also, reminder that another thing that needs to happen is that directory being write-only from the point of view of NullAway, and non-persistent from the point of view of the external toolchain, so the python scripts probably still need another directory to copy ongoing working data to (with the idea being that the AutoFixOutPutDirectory is cleared between compilations).

Hi @lazaroclapp, I have one question regarding configurable paths. Both script and NullAway should be informed about the output directory to interact with each other. In Gradle projects we can pass it via setting this flag -XepOpt:NullAway:AutoFixOutPutDirectory in tasks.withType(JavaCompile) function in build.gradle file and also should configure path in the python script. These two directories should be set in two places rather than only once place. Even if I find a way to automatically modify build.gradle files with python script, I am not sure how we can do it at Uber. Would you please tell me how we can address this issue or we can temporarily move forward with the current situation.

authors: lazaroclapp nimakarimipour

repo: nimakarimipour/Diagnoser


text:
Fixed importing issue

Relative importing caused "ImportError: No module named 'models'" in Python 3.4.

Thanks! In the near future I'll probably fix this further by adding from future import absolute_import everywhere and turning the implicit relative imports to explicit relative imports, then make a release.

Great, thanks for prompt merge!

authors: amadornimbis makukha

repo: nimbis/cmsplugin-forms-builder


text:
Improve addressbook local peer relays and addresses

Changelog

Removes the PrivatePeerInfo struct.
Adds methods to manage addresses for local peer to the AddressBook.
Adds methods to manage relay peers for local peer to the AddressBook.
Nimona now adds all bootstrap nodes as relays.

Pull Request Test Coverage Report for Build 366

7 of 18 (38.89%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+2.7%) to 30.621%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

dht/dht_query.go
0
1
0.0%

net/exchange.go
3
6
50.0%

dht/dht.go
0
7
0.0%

Totals

Change from base Build 360:
2.7%

Covered Lines:
587

Relevant Lines:
1917

💛  - Coveralls

authors: coveralls geoah

repo: nimona/go-nimona


text:
Update Page “index”

Automatically generated by Netlify CMS

👷 Deploy Preview for ninahorne processing.
🔨 Explore the source changes: a71bbc98f8c63cd92372904af53ae321b61af5f3
🔍 Inspect the deploy log: https://app.netlify.com/sites/ninahorne/deploys/612a9d4587f05800070a0315

repo: ninahorne/portfolio


text:
Question - Not possible to keep a connection state?

Hi!
I can't find any way to neither be informed about new connections - nor any possibility to update the initial state of a path handler.
Is there no way to achieve any of this? If things are needed to be done once per connection (without process jump for each request)?
Also we want to set DSCP for each connection - but at the same time be able to update the DSCP without restarting connections.
Is the only way currently to keep this externally e.g. an ets-table? Or wrap...
And for this we really need to be informed about when a connection is lost as well...

You can probably write a custom Ranch protocol that then defers to Cowboy's and do any modification you require there. For connection loss the process will exit so monitoring is probably the way to go.
For updating existing connections I don't think there's currently a built-in way to do this. On the other hand you can have your custom Ranch protocol pass the socket forward via the options and then write a stream handler that will process an arbitrary message to update the socket options.

Ok - thx.
I assume custom protocol means wrapping cowboy:start as well then?

Just using ranch:start_listener directly.

authors: JeppeTh essen

repo: ninenines/cowboy

license: isc


text:
Dangling symlinks prevents collecting unused fieldmaps

Unfortunately, this issue remains and had escaped my previous tests.
Even if now fmriprep do no run fieldmap estimation on fmaps not listed in b0 intents (https://github.com/nipreps/fmriprep/pull/3025) , the wrangler still lists/instantiates all fieldmap objects and crash when finding broken symlinks (datalad) on line https://github.com/nipreps/sdcflows/blob/master/sdcflows/fieldmaps.py#L202 . As we run jobs in parallel on temporary clones on the HPC, we only pull the strictly required data from the session to process, and thus it crashes.
An alternative would be to relax
https://github.com/nipreps/sdcflows/blob/master/sdcflows/fieldmaps.py#L202
and let broken symlink pass if only metadata are required to instantiate the fieldmap object ( which I am not sure about).
In the reason mentioned no to apply session filters, the case where one wants to use fieldmaps from another session would still work by default if they provide no bids_filters for fmap or provide bids_filters that do not specify session, or include the other session, right?
Originally posted by @bpinsard in https://github.com/nipreps/sdcflows/issues/359#issuecomment-1793980990

@bpinsard I think it does make sense to defer checking for file existence until we actually want to use them. Hopefully we can make validation a specific call, rather than an obligatory part of building a list of potential estimators.

repo: nipreps/sdcflows


text:
version_parts() does not allow for pre-release suffixes

The regexp in version_parts() does not allow for any suffixes such as "rc1", "a" etc.
See my other comment on parsing the distro files, and make the format of versions consistent.

This requires some more thinking. version_parts() is meant to provide major, minor and patch/build numbers. We need to standardize this. Let's leave this for later.

It seems to me that there is some potential for incompatible changes. So once we declare the project ready, this would be harder to do, for compatibility reasons.
There is one more issue with version_parts(): There are distros that have three parts in the version: major, minor, fixlevel. The fixlevel is not really a build number; it is part of the release and internally there were multiple different build numbers one of which was released under the version major, minor, fixlevel.
On build number: I think the build number is not a subordinate number in the major, minor, fixlevel sequence, but more like an additional identifier, that stands separate. Also, where do we get the build number from? That is not clear to me at all. In the versions of the distros in our unit test cases, I did not see a build number. Do you have examples?
On the suffixes: It seems to me that they should be considered part of the last provided version number. For example: major.minor-suffix, or major.minor.fixlevel-suffix. Their nature is temporary, before the so flagged version becomes final. They could simply show up in the respective part of the version.

In order to move forward, I think this one should be left for later.


text:
Remove unnecessary package install in README

On Debian systems, the rubygems package has been rolled into the ruby package.

@nirvdrum please merge this!

Missed it.  Thanks!

authors: edpbx nirvdrum psexton


text:
[Snyk] Fix for 4 vulnerabilities

Snyk has created this PR to fix 4 vulnerabilities in the npm dependencies of this project.
Snyk changed the following file(s):

package.json
package-lock.json

Vulnerabilities that will be fixed with an upgrade:

Issue
Score

Asymmetric Resource Consumption (Amplification) SNYK-JS-BODYPARSER-7926860
  149

Cross-site Scripting SNYK-JS-EXPRESS-7926867
  107

Cross-site Scripting SNYK-JS-SEND-7926862
  80

Cross-site Scripting SNYK-JS-SERVESTATIC-7926865
  80

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Cross-site Scripting

🎉 Snyk hasn't found any issues so far.
✅ code/snyk check is completed. No issues were found. (View Details)

repo: nirw-snyk/nodejs-goof


text:
doc/commands: introduce INI commands

This PR introduces commands related to package.ini files:

CmdIniDescription: return the package description from the package.ini file
CmdIniGitUrl: return the package Git URL from the package.ini file
CmdIniCloneCommand: return the package git clone command from the package.ini file
CmdIniIssuesUrl: return the package issues URL from the package.ini file
CmdIniMaintainer: return the maintainer name from the package.ini file
CmdIniContributors: return the contributors list from the package.ini file
CmdIniLicense: return the license string from the package.ini file
CmdLicenseFile and CmdLicenseFileContent: return the LICENSE.md file and its content
CmdContribFile and CmdContribFileContent: return the CONTRIBUTING.md file and its content

reroll @privat removed the trims

repo: nitlang/nit


text:
chore: Impl Serialize and Deserialize

Impl Serialize and Deserialize for any types
fix #18

已发布

authors: Pylogmon niuhuan


text:
When i convert the content to HTML format, highlight tags go missing.

        const contentHTML = convertFromHTML(editor_text);
        const state = ContentState.createFromBlockArray(contentHTML.contentBlocks, contentHTML.entityMap);
        const content = JSON.stringify(convertToRaw(state));

Here is the sample image

When converted to HTML:
Hello [=PercentageDiscount] [=FixedAmountDiscount]

[=PercentageDiscount]

[=FixedAmountDiscount]
[=PercentageDiscount]
[=FixedAmountDiscount]
As clear, other styling is there except highlighting.

Seems this is a problem of your HTML converter.

authors: Khushboo-Mishra niuware

repo: niuware/mui-rte


text:
[BUG] Spellchecking doesn't work without treesitter?

Field
Description

Plugin
treesitter, spell

Nixpkgs
unstable

[x] I have read the FAQ and my bug is not listed there.

Description
The presence of treesitter seems to affect German (non-English in general?) spell checking: When the plugin is absent, the spell checker fails to find (or download) word lists.
In detail: Setting opts.spell = true and opts.spelllang = ["de"] in an otherwise empty configuration, I expect German spell checking to be enabled everywhere. However, when I open any file, I get, in order, the following messages (and spell checking does not work):
spellfile#LoadFile(): No (writable) spell directory found.
Press ENTER or type command to continue

Failed to create: /home/carl/.local/share/nvim/site/spell
Press ENTER or type command to continue

Warning: Cannot find word list "de.utf-8.spl" or "de.ascii.spl"
Press ENTER or type command to continue

Now, the funny bit: If I set plugins.treesitter.enable = true, the problem disappears.
I haven't investigated this further. Maybe this has something to do with the fact that treesitter may depend on files outside the nix store (grammars installed with TSInstall), and therefore "opens the door", which was forgotten for spelling, because of the prevalence of English-only configs?
Minimal, Reproducible Example (MRE)
Using the following flake:

nix run .#bad -- foo.txt to see the error
nix run .#good -- foo.txt to see it work, when treesitter is present.

{
  inputs.nixvim.url = "github:nix-community/nixvim";
  outputs = {nixvim, ...}: let
    system = "x86_64-linux";
  in {
    packages.${system} = with nixvim.legacyPackages.${system}; {
      bad = makeNixvim {
        opts.spell = true;
        opts.spelllang = ["de"];
      };
      good = makeNixvim {
        opts.spell = true;
        opts.spelllang = ["de"];
        plugins.treesitter.enable = true;
        plugins.treesitter.grammarPackages = []; # just to save some bandwidth; doesn't change the outcome
      };
    };
  };
}

flake.lock
{
  "nodes": {
    "devshell": {
      "inputs": {
        "nixpkgs": [
          "nixvim",
          "nixpkgs"
        ]
      },
      "locked": {
        "lastModified": 1722113426,
        "narHash": "sha256-Yo/3loq572A8Su6aY5GP56knpuKYRvM2a1meP9oJZCw=",
        "owner": "numtide",
        "repo": "devshell",
        "rev": "67cce7359e4cd3c45296fb4aaf6a19e2a9c757ae",
        "type": "github"
      },
      "original": {
        "owner": "numtide",
        "repo": "devshell",
        "type": "github"
      }
    },
    "flake-compat": {
      "locked": {
        "lastModified": 1696426674,
        "narHash": "sha256-kvjfFW7WAETZlt09AgDn1MrtKzP7t90Vf7vypd3OL1U=",
        "rev": "0f9255e01c2351cc7d116c072cb317785dd33b33",
        "revCount": 57,
        "type": "tarball",
        "url": "https://api.flakehub.com/f/pinned/edolstra/flake-compat/1.0.1/018afb31-abd1-7bff-a5e4-cff7e18efb7a/source.tar.gz"
      },
      "original": {
        "type": "tarball",
        "url": "https://flakehub.com/f/edolstra/flake-compat/1.tar.gz"
      }
    },
    "flake-parts": {
      "inputs": {
        "nixpkgs-lib": [
          "nixvim",
          "nixpkgs"
        ]
      },
      "locked": {
        "lastModified": 1726153070,
        "narHash": "sha256-HO4zgY0ekfwO5bX0QH/3kJ/h4KvUDFZg8YpkNwIbg1U=",
        "owner": "hercules-ci",
        "repo": "flake-parts",
        "rev": "bcef6817a8b2aa20a5a6dbb19b43e63c5bf8619a",
        "type": "github"
      },
      "original": {
        "owner": "hercules-ci",
        "repo": "flake-parts",
        "type": "github"
      }
    },
    "flake-utils": {
      "inputs": {
        "systems": "systems"
      },
      "locked": {
        "lastModified": 1710146030,
        "narHash": "sha256-SZ5L6eA7HJ/nmkzGG7/ISclqe6oZdOZTNoesiInkXPQ=",
        "owner": "numtide",
        "repo": "flake-utils",
        "rev": "b1d9ab70662946ef0850d488da1c9019f3a9752a",
        "type": "github"
      },
      "original": {
        "owner": "numtide",
        "repo": "flake-utils",
        "type": "github"
      }
    },
    "git-hooks": {
      "inputs": {
        "flake-compat": [
          "nixvim",
          "flake-compat"
        ],
        "gitignore": "gitignore",
        "nixpkgs": [
          "nixvim",
          "nixpkgs"
        ],
        "nixpkgs-stable": [
          "nixvim",
          "nixpkgs"
        ]
      },
      "locked": {
        "lastModified": 1726745158,
        "narHash": "sha256-D5AegvGoEjt4rkKedmxlSEmC+nNLMBPWFxvmYnVLhjk=",
        "owner": "cachix",
        "repo": "git-hooks.nix",
        "rev": "4e743a6920eab45e8ba0fbe49dc459f1423a4b74",
        "type": "github"
      },
      "original": {
        "owner": "cachix",
        "repo": "git-hooks.nix",
        "type": "github"
      }
    },
    "gitignore": {
      "inputs": {
        "nixpkgs": [
          "nixvim",
          "git-hooks",
          "nixpkgs"
        ]
      },
      "locked": {
        "lastModified": 1709087332,
        "narHash": "sha256-HG2cCnktfHsKV0s4XW83gU3F57gaTljL9KNSuG6bnQs=",
        "owner": "hercules-ci",
        "repo": "gitignore.nix",
        "rev": "637db329424fd7e46cf4185293b9cc8c88c95394",
        "type": "github"
      },
      "original": {
        "owner": "hercules-ci",
        "repo": "gitignore.nix",
        "type": "github"
      }
    },
    "home-manager": {
      "inputs": {
        "nixpkgs": [
          "nixvim",
          "nixpkgs"
        ]
      },
      "locked": {
        "lastModified": 1726902823,
        "narHash": "sha256-Gkc7pwTVLKj4HSvRt8tXNvosl8RS9hrBAEhOjAE0Tt4=",
        "owner": "nix-community",
        "repo": "home-manager",
        "rev": "14929f7089268481d86b83ed31ffd88713dcd415",
        "type": "github"
      },
      "original": {
        "owner": "nix-community",
        "repo": "home-manager",
        "type": "github"
      }
    },
    "nix-darwin": {
      "inputs": {
        "nixpkgs": [
          "nixvim",
          "nixpkgs"
        ]
      },
      "locked": {
        "lastModified": 1726742753,
        "narHash": "sha256-QclpWrIFIg/yvWRiOUaMp1WR+TGUE9tb7RE31xHlxWc=",
        "owner": "lnl7",
        "repo": "nix-darwin",
        "rev": "c03f85fa42d68d1056ca1740f3113b04f3addff2",
        "type": "github"
      },
      "original": {
        "owner": "lnl7",
        "repo": "nix-darwin",
        "type": "github"
      }
    },
    "nixpkgs": {
      "locked": {
        "lastModified": 1726755586,
        "narHash": "sha256-PmUr/2GQGvFTIJ6/Tvsins7Q43KTMvMFhvG6oaYK+Wk=",
        "owner": "NixOS",
        "repo": "nixpkgs",
        "rev": "c04d5652cfa9742b1d519688f65d1bbccea9eb7e",
        "type": "github"
      },
      "original": {
        "owner": "NixOS",
        "ref": "nixos-unstable",
        "repo": "nixpkgs",
        "type": "github"
      }
    },
    "nixvim": {
      "inputs": {
        "devshell": "devshell",
        "flake-compat": "flake-compat",
        "flake-parts": "flake-parts",
        "git-hooks": "git-hooks",
        "home-manager": "home-manager",
        "nix-darwin": "nix-darwin",
        "nixpkgs": "nixpkgs",
        "nuschtosSearch": "nuschtosSearch",
        "treefmt-nix": "treefmt-nix"
      },
      "locked": {
        "lastModified": 1727050833,
        "narHash": "sha256-uq8pP+WsJsZ3QA+GoSftUsAvhx3btBOCWAqKQSFcL1M=",
        "owner": "nix-community",
        "repo": "nixvim",
        "rev": "a9345dcfc31519734361fecd246d32164feafbca",
        "type": "github"
      },
      "original": {
        "owner": "nix-community",
        "repo": "nixvim",
        "type": "github"
      }
    },
    "nuschtosSearch": {
      "inputs": {
        "flake-utils": "flake-utils",
        "nixpkgs": [
          "nixvim",
          "nixpkgs"
        ]
      },
      "locked": {
        "lastModified": 1726816132,
        "narHash": "sha256-AbB0lgc0IbzLIxj1O3cosiMNAVQak4KJtvq9q8MjHhs=",
        "owner": "NuschtOS",
        "repo": "search",
        "rev": "7733a39a1321057172d87e6251ded7cdeb67171e",
        "type": "github"
      },
      "original": {
        "owner": "NuschtOS",
        "repo": "search",
        "type": "github"
      }
    },
    "root": {
      "inputs": {
        "nixvim": "nixvim"
      }
    },
    "systems": {
      "locked": {
        "lastModified": 1681028828,
        "narHash": "sha256-Vy1rq5AaRuLzOxct8nz4T6wlgyUR7zLU309k9mBC768=",
        "owner": "nix-systems",
        "repo": "default",
        "rev": "da67096a3b9bf56a91d16901293e51ba5b49a27e",
        "type": "github"
      },
      "original": {
        "owner": "nix-systems",
        "repo": "default",
        "type": "github"
      }
    },
    "treefmt-nix": {
      "inputs": {
        "nixpkgs": [
          "nixvim",
          "nixpkgs"
        ]
      },
      "locked": {
        "lastModified": 1726734507,
        "narHash": "sha256-VUH5O5AcOSxb0uL/m34dDkxFKP6WLQ6y4I1B4+N3L2w=",
        "owner": "numtide",
        "repo": "treefmt-nix",
        "rev": "ee41a466c2255a3abe6bc50fc6be927cdee57a9f",
        "type": "github"
      },
      "original": {
        "owner": "numtide",
        "repo": "treefmt-nix",
        "type": "github"
      }
    }
  },
  "root": "root",
  "version": 7
}

cc @GaetanLepage this is one of the edge-cases I was worried our current "pure rtp when wrapRC is enabled" implementation would lead to.
Do you recall if we had any real-world issues with impurities coming from the "site" directory or was that just included in the rtp-purification on the assumption it'd be needed?
Personally I think we should:

de-couple purifying the rtp from wrapping the init file
not remove "site" even when purifying (at least by default)

I think most issues we had was superfluous init.lua files

Hm, maybe we can have something like:
isolatedRuntime = mkOption {
  type = types.bool;
  default = config.wrapRc;
  defaultText = literalExpression "config.wrapRc";
  description = ''
    Whether to isolate vim's runtimepath by removing impure directories.

    Recommended when using `wrapRc`.

    The following directories will be removed:
    - ~/.config/nvim
    - ~/.config/nvim/after

    > [!NOTE]
    > ~/.local/share/nvim/site will **not** be removed for compatibility reasons
  '';
}

authors: MattSturgeon carlhammann traxys

repo: nix-community/nixvim


text:
project.scripts not made available as binaries in the devShell

I'm not sure if it's intended to do so, but I note that if you have a [project.scripts] section like so:
[project.scripts]
foo = "foo.cli:main"

then the foo executable is not made available when you enter the devShell. It does get created if you nix build . the package; but I had hoped it would be available in the shell too!
Is this something we can get working somehow?

This is semi-intended.
To make scripts available in the development shell we'd have to set them up on $PATH somewhere, this implies creating a package.
Poetry2nix has a utility function to do this transformation: https://github.com/nix-community/poetry2nix/blob/master/shell-scripts.nix.
That utility function would have to be added to somewhere. I'd prefer it if it was added to nixpkgs rather than here.

Implementation note:
https://github.com/nix-community/poetry2nix/blob/e31b5e4/shell-scripts.nix#L18-L19 is a hack to achieve loading a local path.
This should probably be solved with an editable install instead if mutable behaviour is desired.
Related issue: https://github.com/nix-community/pyproject.nix/issues/114

See https://github.com/NixOS/nixpkgs/pull/339228

authors: adisbladis silky


text:
sys::socket adding GetOnly TCP_FUNCTION_ALIAS for freebsd.

to complete TCP_FUNCTION_BLK as to get the alias name, if existent, of the TCP stack.

sure but then that would be for TCP_FUNCTION_BLK too as there is none for it.

repo: nix-rust/nix


text:
Remove unnecessary flutter dependency

I want to use this package in a dart-only project, but it depends on flutter. That dependency seems unnecessary, so I removed it.

I will merge this pull request.
Thanks for making those changes, I will widen the use of this package into dart programs too.
Actually, I mostly code for flutter programs, So I didn't realize this requirement.
Thank you.
@nixrajput :)

repo: nixrajput/get-time-ago


text:
[#5, #8, #9] [Integrate] As a user, I can sign in with email and password + [UI] As a user, I cannot sign in if my email, password format is invalid.

#5, #8, #9
What happened

Implemented logic on login feature.
validated email, password format with error text.

Insight

Managed App's Navigation by creating AppState.
Saved Token to KeychainAccess after successful signed-in.
Defined SError for error validation and API response.
Created LoadingView for displaying the loading activity indicator.

On logic login:

If user logins successfully, it'll save response to Keychain and navigate to the Home Screen.
If failure, it'll show an alert with error's description.

On email, password format validation:

Login button is only valid if email, password are both valid.
When Textfield's format is invalid, there's a small red text below their field in order to show the error description.

Note: - This doesn't include UnitTest, UITest.
Proof Of Work
https://user-images.githubusercontent.com/25881847/183020727-88a2095b-01c4-414c-9782-237afc09f158.mp4

Refer https://nimblehq.co/compass/development/code-reviews/. I think next time you should avoid merge multi-story (issues) into one Pull Request
Separate each story into a distinct pull request.


text:
Review concept-versie door werkgroepleden

Actie Harm: sessie met Marco, Erwin, Tim en Gerbert, Romano om de tabellen van de huidige disciplines te reviewen

Besproken 12-12-2023: Geen aparte sessie organiseren; Iedereen lijst zelf nalopen (zie #114). Erwin naar contact op met Paul om af te stemmen of de Excell af gereed is.

Besproken 11-3-2024: Is nog niet gereed. Paul heeft wel al samen met Erwin er naar gekeken. Excel ligt nu weer bij Paul/collega. Over een paar dagen excel gereed en bespreekt Paul met Erwin en Marco en zet de excel op Github.
Daarna de andere leden een check op de objecten uitvoeren.

Hierbij de Excel-bladen van de hoofdgroepen ES, IS en SB :
ES-Energievoorziening Spoor 20240424.xls
IS-Installaties spoorwegen 20240424.xls
SB-Spoorbouw 20240424.xls

Hierbij de Excel-bladen, incl. de verbeeldingen. Deze betreffende aanvullingen op de huidige hoofdgroepen:
AL-Algemeen 20240424.xls
AM-Assen en Metrering 20240424.xls
GR-Groen 20240424.xls
IE-Inrichtingselementen 20240424.xls
KG-kadastrale informatie en grenzen 20240424.xls
KL-Kabels en Leidingen 20240424.xls
OG-Ondergronden 20240424.xls
RI-Riolering 20240424.xls
VH-Verhardingen 20240424.xls
VW-Verkeerskunde Wegen 20240424.xls

AL verwerkt; ASSETGRENS opgenomen in hoofdgroep Kadastrale Informatie en Grenzen
Ik heb maar als linetype CONTINUOUS opgenomen, was niet ingevuld, ook lineweight maar als 0.35 bij nieuwe objecten
werkzaamheden op tekenbladen toch maar als B niet als N, gek om bij Algemeen iets anders te gebruiken dan B trouwens maar ik snap het wel bij asset nummer
Trouwens, moet asset beschrijving, asset kader, asset nummer niet onder ZZ komen, omdat de asset wel een object is die onder een bepaalde hoofdgroep valt?

assen en metrering
AS bestaat al generiek, ik heb de bestaande kleuren niet aangepast
AS_SPOOR bestond ook al, heb ik de kleuren wel van aangepast
AS_SPOOR_TRAM_AFWIJKING_ONBEKEND is hetzelfde als AS_SPOOR_TRAM_AFWIJKING en heb ik daarom niet overgenomen, gezien alle discussies over "onbekend" en "overig"

Energievoorziening Spoor. Het valt me op dat lineweight en linetype niet de in de standaard gebruikelijke waarden zijn, ik ga straks in de beheeromgeving standaard B 0.18, N,T en V 0.35 lineweight geven, en alle lijnen op continuous zetten.
Als er voor de gebruikte nummers een lijntype gedefinieerd wordt conform NLCS kan ik andere lijntypes opnemen.

GR verwerkt
GRAS bestaat al, met andewre kleuren, heb ik niet gewijzigd

IE verwerkt
Voor de MUPI heb ik gewoon de standaard kleuren van meubilair overgenomen
Voor de trammast idem

IS verwerk (importsheet opgesteld)
zijn de masten in IS anders dan in ES? Wat zijn dit voor "masten"?

KG verwerkt, al twijfel ik een beetje of grenzen voor landmeten niet in ZZ horen, zodat je ze op elke hoofdgroep kunt plaatsen?

KL verwerkt, TRACE bestond al, alles daaronder geplaatst

RI, STIPDRAIN verwerkt. Vraag is, moet dit andere kleur hebben dan andere drains?

SB verwerkt.
Vraagje, zijn alignementen strict gesproken niet ook assen en metrering?

VH verwerkt

VW geeft vraag, de blindengeleideroute is meer zoiets als een as of metrering,  maar omdat het wordt ingevuld door een type tegels zou je dit ook onder verhardingen kunnen plaatsen? Ik zet het voor nu onder VW

ik sluit hiermee deze issue af, omdat de verdere review nu plaats gaat vinden via het testen van de concept-publicatie 5.1 in september

AL verwerkt; ASSETGRENS opgenomen in ZZ: GRENS_ASSET

:thumbsup:
Zijn er actuele versies van de excel bestanden dan de versies die hier gepost zijn?
*-**-AL-ASSETKADER-G/S
Moet dat niet zijn: AL-TEKENBLAD_KADER_ASSET ?
Hoe worden *-**-AL-ASSETBESCHRIJVING-G/S en *-**-AL-ASSETNUMMER-G/S toegepast? Op het tekenblad? In een tabel? Of moeten deze juist naar de ZZ-groep?
*-**-AL-TABEL-G/S
*-**-AL-TABEL_BESTELTEKENINGEN-G
*-**-AL-TABEL_PLAATSBEPALING-G
*-**-AL-TABEL_PLAATSBEPALING_TRAVERSEN-G
*-**-AL-TABEL_UITSLAG-G
*-**-AL-TABEL_UITZETTING-G

Ik vind deze best uitgebreid en specifiek. Mij is niet direct duidelijk waar deze lagen 'algemeen' voor gebruikt worden.
Is alleen AL-TABEL-G niet voldoende?
Ik neem aan dat het niet AL-TEKENBLAD_TABEL is omdat de tabellen ook in het ontwerp model worden geplaatst?
Waarvoor dienen de lagen :
*-**-AL-TEKENBLAD_WERKZAAMHEDEN-G/S
*-**-AL-TEKENBLAD_WERKZAAMHEDEN_LIJN-G
*-**-AL-TEKENBLAD_WERKZAAMHEDEN_LIJST-G
*-**-AL-TEKENBLAD_WERKZAAMHEDEN_NUMMER-G/S

Zijn al die lagen algemeen nodig? Moeten al deze onderdelen aparte eigenschappen krijgen/apart gefilterd kunnen worden?
Staan die WERKZAAMHEDEN niet ook in een TABEL ?
Wat mij betreft die lagen sterk beperken, de lagen met subobjecten niet (allemaal) toevoegen.

Hoi Sander,
Een paar van de zaken die je noemt kan ik wel verklaren, de rest weten Erwin Hensing en Marco Linnenbank waarschijnlijk beter.
ES-SCHAKELAAR_GESLOTEN
ES-SCHAKELAAR_OPEN
Als ik het goed zeg heb je twee typen schakelaars:

Schakelaar die in ruststand ‘gesloten’ staat
Schakelaar die in ruststand ‘open’ staat
Het gaat hier dus niet om de fysieke status van de schakelaar (bedrijfstoestand zoals we bij kabels en leidingen zeggen) maar echt om het type.

Wat is een 'ZIJWAARTSE':
ES-OPHANGCONSTRUCTIE_UITLEGGER
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE_DRIEHOEK
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE_ENKEL
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE_PARALLEL
Dat zijn geen type uitleggers? Optie;
ES-OPHANGCONSTRUCTIE_UITLEGGER
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE DRIEHOEK
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE ENKEL
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE PARALLEL
Ik denk dat je bij deze gelijk hebt en dat we jouw optie moeten volgen voor de ophangconstructie. Komende donderdag zit ik weer met Erwin en Marco om tafel, dan zal ik deze meenemen.
Met vriendelijke groet,
Paul Haffmans
Senior consultant,
@.***
Bentley Qualified trainer
for MicroStation
@.***http://www.thepeoplegroup.nl/
The People Group | Software & Trainingen
Middelweg 2 | 5253 CA, NIEUWKUIJK | Nederland
M +31(0)6 55 165 140tel:+31655165140 | T +31(0)85 22 40 000tel:+31852240000
Click for disclaimerhttps://www.thepeoplegroup.nl/e-mail-disclaimer/
Van: Sander Nijhof @.>
Verzonden: Monday, 12 August 2024 16:44
Aan: nl-digigo/NLCS @.>
CC: Paul Haffmans | The People Group @.>; Assign @.>
Onderwerp: Re: [nl-digigo/NLCS] Review concept-versie door werkgroepleden (Issue #190)
ik sluit hiermee deze issue af, omdat de verdere review nu plaats gaat vinden via het testen van de concept-publicatie 5.1 in september
5.1? Ik ging er zomaar vanuit dat 'milestone NLCS 5.3' betekent dat deze met release 5.3 wordt meegenomen en niet 5.1.
Heb even snel naar ES-Energievoorziening.Spoor.20240424.xls gekeken.
De kleuren in de tabellen kloppen inhoudelijk niet met de basisregels FB, die verdienen nog wat aandacht.
De lagen:
ES-AFSPANCONSTRUCTIE
ES-AFSPANNING
Beogen niet hetzelfde object?
De laag:
ES-DRAAGKABEL_LIGGING
Dat is een object? Volstaat ES-DRAAGKABEL niet?
Ik zie bijvoorbeeld ook laagnamen als:
ES-SCHAKELAAR_GESLOTEN
ES-SCHAKELAAR_OPEN
Zijn dat uitvoeringen of toestanden? Of gaan we in de groep ES hier anders mee om dan in de andere hoofdgroepen?
Wat is een 'ZIJWAARTSE':
ES-OPHANGCONSTRUCTIE_UITLEGGER
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE_DRIEHOEK
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE_ENKEL
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE_PARALLEL
Dat zijn geen type uitleggers? Optie;
ES-OPHANGCONSTRUCTIE_UITLEGGER
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE DRIEHOEK
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE ENKEL
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE PARALLEL
(met spaties)
Heeft het nog zin dat ik er nog wat beter naar kijk en de rest ook nog doorloop?
—
Reply to this email directly, view it on GitHubhttps://github.com/nl-digigo/NLCS/issues/190#issuecomment-2284179342, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BCNET7LMWHDBM4K7OEOZAKTZRDC4XAVCNFSM6AAAAAA7BJJGXKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBUGE3TSMZUGI.
You are receiving this because you were assigned.Message ID: @.@.>>

ES-SCHAKELAAR_GESLOTEN ES-SCHAKELAAR_OPEN Als ik het goed zeg heb je twee typen schakelaars: 1. Schakelaar die in ruststand ‘gesloten’ staat 2. Schakelaar die in ruststand ‘open’ staat

:thumbsup: Die lagen zijn goed dus.
Is ES-DRAAGKABEL_TRACE een bespreekbaar alternatief voor ES-DRAAGKABEL_LIGGING ?
'TRACE' wordt nl. vaker in de NLCS toegepast en lijkt me een gangbare term.

De kleuren in de tabellen kloppen inhoudelijk niet met de basisregels FB, die verdienen nog wat aandacht.

:exclamation: :exclamation: Niet alleen de kleuren, maar ook de lijnstijlen en diktes verdienen aandacht :exclamation: :exclamation:
Aandachtspunten:

Volgens mij kent AutoCAD kleur 0 niet, bij voorkeur kleur 7 gebruiken.
De (standaard) toe te passen kleurenserie voor lijnen en arceringen is genoemd in de Formele Beschrijving paragraaf 3.5.9. Daar wordt vooral van afgeweken.
De NLCS maakt onderscheid tussen 'bestaand' en 'nieuw' door nieuwe objecten een dikkere lijndikte te geven. De minimale lijndikte voor status N is dan '1' en status B krijgt de dunste lijndikte t.o.v. de andere statussen.
De tabellen van Stedelijk Spoor maken gebruik van verschillende kleuren per status. Het resultaat is altijd een kleuren afdruk. De kleuren zijn conform NLCS (in de regel) voor alle statussen gelijk. Onderscheid tussen bestaand/oud/nieuw wordt niet gemaakt met kleuren. Toepassen van kleuren op de afdruk is per uitzondering toegestaan maar zijn bij StedelijkSpoor regulier toegepast.
Voor de lijnstijlen zijn nummers gebruikt. We hebben afgesproken dat lijnstijl 0 = lijnstijl CONTINUOUS, maar de overige lijnstijlnummers liggen niet vast en kunnen per CAD-pakket afwijken. Hiervoor dus bestaande NLCS_lijnstijlen gebruiken of nieuwe lijnstijlen definiëren.

Niet dat ik het met alle regels eens ben of fan ben van de NLCS-kleurentabel, maar hier wordt met StedelijkSpoor wel sterk afgeweken van de overige objecten in de NLCS. Ook krijg ik niet de indruk dat op de afdruk duidelijk is te zien welke objecten bestaand zijn en welke nieuw.
Gebruik van kleuren in (presentatie)tekeningen zou worden opgepakt met "(display) thema's".

Hoi Sander,
Eerst maar even punt 1:
Enige tijd geleden is afgesproken dat met name binnen MicroStation kleur 0 ook is toegestaan omdat kleur 7 bij Autocad en kleur 0 bij MS beide de basiskleur wit zijn. Als het goed is, is dat ook in de FB opgenomen.
De andere punten zal ik van de week ook met Marco en Erwin bespreken.
Gr,
Paul
~~
Met vriendelijke groet,
Paul Haffmans
Senior consultant,
@.***
Bentley Qualified trainer
for MicroStation
@.***http://www.thepeoplegroup.nl/
The People Group | Software & Trainingen
Middelweg 2 | 5253 CA, NIEUWKUIJK | Nederland
M +31(0)6 55 165 140tel:+31655165140 | T +31(0)85 22 40 000tel:+31852240000
Click for disclaimerhttps://www.thepeoplegroup.nl/e-mail-disclaimer/
Van: Sander Nijhof @.>
Verzonden: Tuesday, 13 August 2024 12:33
Aan: nl-digigo/NLCS @.>
CC: Paul Haffmans | The People Group @.>; Assign @.>
Onderwerp: Re: [nl-digigo/NLCS] Review concept-versie door werkgroepleden (Issue #190)
De kleuren in de tabellen kloppen inhoudelijk niet met de basisregels FB, die verdienen nog wat aandacht.
❗ ❗ Niet alleen de kleuren, maar ook de lijnstijlen en diktes verdienen aandacht ❗ ❗
Aandachtspunten:

Volgens mij kent AutoCAD kleur 0 niet, bij voorkeur kleur 7 gebruiken.
De (standaard) toe te passen kleurenserie voor lijnen en arceringen is genoemd in de Formele Beschrijving paragraaf 3.5.9. Daar wordt vooral van afgeweken.
De NLCS maakt onderscheid tussen 'bestaand' en 'nieuw' door nieuwe objecten een dikkere lijndikte te geven. De minimale lijndikte voor status N is dan '1' en status B krijgt de dunste lijndikte t.o.v. de andere statussen.
De tabellen van Stedelijk Spoor maken gebruik van verschillende kleuren per status. Het resultaat is altijd een kleuren afdruk. De kleuren zijn conform NLCS (in de regel) voor alle statussen gelijk. Onderscheid tussen bestaand/oud/nieuw wordt niet gemaakt met kleuren. Toepassen van kleuren op de afdruk is per uitzondering toegestaan maar zijn bij StedelijkSpoor regulier toegepast.
Voor de lijnstijlen zijn nummers gebruikt. We hebben afgesproken dat lijnstijl 0 = lijnstijl CONTINUOUS, maar de overige lijnstijlnummers liggen niet vast en kunnen per CAD-pakket afwijken. Hiervoor dus bestaande NLCS_lijnstijlen gebruiken of nieuwe lijnstijlen definiëren.

Niet dat ik het met alle regels eens ben of fan ben van de NLCS-kleurentabel, maar hier wordt met StedelijkSpoor wel sterk afgeweken van de overige objecten in de NLCS. Ook krijg ik niet de indruk dat op de afdruk duidelijk is te zien welke objecten bestaand zijn en welke nieuw.
Gebruik van kleuren in (presentatie)tekeningen zou worden opgepakt met "(display) thema's".
—
Reply to this email directly, view it on GitHubhttps://github.com/nl-digigo/NLCS/issues/190#issuecomment-2285920029, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BCNET7MPVULIRCSXXPJ76R3ZRHOELAVCNFSM6AAAAAA7BJJGXKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBVHEZDAMBSHE.
You are receiving this because you were assigned.Message ID: @.@.>>

https://github.com/nl-digigo/NLCS/issues/190#issuecomment-2272764722
Nee, deze objecten zijn nodig voor onze beheerskaart. Met ONTWERP wordt in onze beheerskaarten projecten in uitvoering aangeduid en waarvan de revisie meting nog uitgevoerd moer worden. Zodra een revisiemeting is verwerkt worden deze objecten geüpdatet naar een laag met AFWIJKING.

https://github.com/nl-digigo/NLCS/issues/190#issuecomment-2272964599
Dit zijn andere masten met andere diameters en lengtes

https://github.com/nl-digigo/NLCS/issues/190#issuecomment-2284179342
Correct, de Stedelijke Spoor bedrijven zouden eerst testen met ons voorgestelde lagen en deze finetunen. Na het finetunes zouden de lagen als concept/review versie voor andere beschikbaar worden gesteld.

Nee, deze objecten zijn nodig voor onze beheerskaart. Met ONTWERP wordt in onze beheerskaarten projecten in uitvoering aangeduid en waarvan de revisie meting nog uitgevoerd moer worden. Zodra een revisiemeting is verwerkt worden deze objecten geüpdatet naar een laag met AFWIJKING.

Dit gaat over de laag AS_SPOOR_TRAM_ONTWERP.
De NLCS hanteert een methodiek voor bestaande objecten en nieuwe objecten. Lijkt mij niet raadzaam van die methodiek af te wijken met "_ONTWERP" lagen. Als hier onduidelijkheid over is dan is dit wel een belangrijk bespreekpunt.

Hallo Sander,
Hierbij reactie op:
De laag:
ES-DRAAGKABEL_LIGGING
Dat is een object? Volstaat ES-DRAAGKABEL niet?
Akkoord op voorstel
Hierbij reactie op:
Wat is een 'ZIJWAARTSE':
ES-OPHANGCONSTRUCTIE_UITLEGGER
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE_DRIEHOEK
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE_ENKEL
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE_PARALLEL
Dat zijn geen type uitleggers? Optie;
ES-OPHANGCONSTRUCTIE_UITLEGGER
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE DRIEHOEK
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE ENKEL
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE PARALLEL
(met spaties)
Akkoord op voorstel
Overige vragen heb ik nagevraagd, maar nog geen reactie ontvangen.
Met vriendelijke groet,
Erwin
Ik werk op maandag en vrijdag thuis
Van: Sander Nijhof @.>
Verzonden: maandag 12 augustus 2024 16:44
Aan: nl-digigo/NLCS @.>
CC: Hensing, E.G. (Erwin) @.>; Assign @.>
Onderwerp: Re: [nl-digigo/NLCS] Review concept-versie door werkgroepleden (Issue #190)
LET OP: Deze e-mail komt van buiten de organisatie. Wees voorzichtig met het openen van links en bijlagen, tenzij je de afzender herkent en zeker weet dat de inhoud veilig is.
ik sluit hiermee deze issue af, omdat de verdere review nu plaats gaat vinden via het testen van de concept-publicatie 5.1 in september
5.1? Ik ging er zomaar vanuit dat 'milestone NLCS 5.3' betekent dat deze met release 5.3 wordt meegenomen en niet 5.1.
Heb even snel naar ES-Energievoorziening.Spoor.20240424.xls gekeken.
De kleuren in de tabellen kloppen inhoudelijk niet met de basisregels FB, die verdienen nog wat aandacht.
De lagen:
ES-AFSPANCONSTRUCTIE
ES-AFSPANNING
Beogen niet hetzelfde object?
De laag:
ES-DRAAGKABEL_LIGGING
Dat is een object? Volstaat ES-DRAAGKABEL niet?
Ik zie bijvoorbeeld ook laagnamen als:
ES-SCHAKELAAR_GESLOTEN
ES-SCHAKELAAR_OPEN
Zijn dat uitvoeringen of toestanden? Of gaan we in de groep ES hier anders mee om dan in de andere hoofdgroepen?
Wat is een 'ZIJWAARTSE':
ES-OPHANGCONSTRUCTIE_UITLEGGER
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE_DRIEHOEK
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE_ENKEL
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE_PARALLEL
Dat zijn geen type uitleggers? Optie;
ES-OPHANGCONSTRUCTIE_UITLEGGER
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE DRIEHOEK
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE ENKEL
ES-OPHANGCONSTRUCTIE_ZIJWAARTSE PARALLEL
(met spaties)
Heeft het nog zin dat ik er nog wat beter naar kijk en de rest ook nog doorloop?
—
Reply to this email directly, view it on GitHubhttps://github.com/nl-digigo/NLCS/issues/190#issuecomment-2284179342, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BCN5QGPBYBFWI26PKLR3CADZRDC4XAVCNFSM6AAAAAA7BJJGXKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBUGE3TSMZUGI.
You are receiving this because you were assigned.Message ID: @.@.>>

DISCLAIMER:
“Als de informatie in dit e-mailbericht onverhoopt niet voor jou bestemd is, meld dit aan de afzender en wis vervolgens het bericht. Wees altijd voorzichtig met het delen van e-mails waarin persoonsgegevens staan en bewaar deze niet langer dan noodzakelijk."

Disclaimer:
De informatie in dit e-mailbericht is uitsluitend bestemd voor de geadresseerde. Verstrekking aan en gebruik door derden is niet toegestaan. Als dit bericht niet voor u bestemd is, wordt u vriendelijk verzocht dit aan de afzender te melden en het bericht te wissen. Door de elektronische verzending van het bericht kunnen er geen rechten worden ontleend aan de informatie. Indien u twijfelt aan de correctheid of volledigheid van dit e-mail bericht, neemt u dan contact op met de verzender. HTM sluit elke aansprakelijkheid uit wanneer informatie in dit e-mail bericht niet correct, onvolledig of niet tijdig overkomt of wanneer er schade ontstaat ten gevolge van dit e-mail bericht. De hoofdvestiging van HTM Personenvervoer N.V. is gevestigd aan het Koningin Julianaplein 10 te Den Haag (KvK nummer 27014495) – www.htm.nl/over-htm.
This email message is intended solely for the addressee. This email (including any attachments) may be privileged or confidential. If this email is received by mistake, please notify the sender by return e-mail and delete this message from your system. When in doubt whether this message is correct or complete, please contact the sender. This message shall not constitute any rights or obligations. HTM Personenvervoer N.V. has its registered office in The Hague (Companies’ Register 27014495) – www.htm.nl/over-htm.

ik kan zeker nog verbeteringen doorvoeren vóór de concept-release stuur dit vooral door!

Zoals gezegd: In de Excel tabellen zijn waarden 1 t/m 7 opgenomen voor lijnstijlen. Dit zijn (waarschijnlijk Microstation) lijnstijlen, die zowel AutoCAD als de NLCS niet kennen. Ik weet niet wat de software daarmee gaat doen, waarschijnlijk foutmeldingen(?) of terugvallen op CONTINUOUS voor lijnstijlen die niet gevonden kunnen worden.
De kleuren in de tabellen matchen niet met de systematiek van de NLCS-standaard. Ik weet niet wat discipline SPOOR nu aan kleuren, lijnstijlen en lijndikten gebruikt/nodig heeft voor de presentatie van haar tekeningen, dus lastig om daar voorstellen voor te doen.
Onderscheid in STATUS is in de NLCS m.n. door lijndikten en lijnstijlen, beslist niet door toepassen van verschillende kleuren (niet op de afdruk en niet op het scherm). We kunnen daar wel van afwijken, maar dan wel graag volgens een beschreven systematiek en niet willekeurig.
Welke lijnstijlen en kleuren gebruikt discipline SPOOR nu? Kunnen we met de NLCS daar (zoveel mogelijk) op aansluiten zodat de tekeningen herkenbaar blijven voor SPOOR?
Zijn er bestaande normen en/of standaarden waar rekening mee gehouden moet worden?

AL-Algemeen 20240912.xls
AM-Assen en Metrering 20240912.xls
ES-Energievoorziening Spoor 20240912.xls
GR-Groen 20240912.xls
GW-Grondwerk 20240912.xls
HC-Houtconstruties 20240912.xls
IE-Inrichtingselementen 20240912.xls
IS-Installaties spoorwegen 20240912.xls
KG-kadastrale informatie en grenzen 20240912.xls
KL-Kabels en Leidingen 20240912.xls
KW-Kunstwerken 20240912.xls
OG-Ondergronden 20240912.xls
RI-Riolering 20240912.xls
SB-Spoorbouw 20240912.xls
SC-Staalconstructies 20240912.xls
VH-Verhardingen 20240912.xls
VW-Verkeerskunde Wegen 20240912.xls
ZZ-Voorallehoofdgroepen 20240912.xls
Bijgevoegde lijsten zijn vanmorgen met Marco Linnenbank en Paul Haffmans doorgenomen of een object een symbool nodig heeft

10-04-2024 Bijgewerkte Excel-bestanden.

Bestaande NLCS objecten zijn uit deze bestanden verwijderd
Symbolen zoveel mogelijk toegevoegd, deze zijn bij issue #118 geupload.
Lijndiktes in mm, i.p.v. Microstation nummer

AL-Algemeen 20241004.xls
AM-Assen en Metrering 20241004.xls
ES-Energievoorziening Spoor 20241004.xls
GR-Groen 20241004.xls
IS-Installaties spoorwegen 20241004.xls
KG-kadastrale informatie en grenzen 20241004.xls
KL-Kabels en Leidingen 20241004.xls
OG-Ondergronden 20241004.xls
RI-Riolering 20241004.xls
SB-Spoorbouw 20241004.xls
VH-Verhardingen 20241004.xls
VW-Verkeerskunde Wegen 20241004.xls
ZZ-Voorallehoofdgroepen 20241004.xls

Ik heb de tabellen voor AL, AM en ES even kort bekeken:
Kleuren eindigend op ‘2’ zijn gereserveerd voor arceringen (al is dat niet consequent doorgevoerd in de NLCS-tabellen). Kan i.p.v. kleur 92 voor AM-AS-SPOOR_TRAM_RECHT ook kleur 90 worden toegepast?
AL-VERWIJZING_DOORSNEDE is een bestaande NLCS-laag met lijndikte 0.18mm , in de tabel voor AL-Algemeen 20241004.xls is dezelfde laag opgenomen met lijndikte 0.25mm, dat is tegenstrijdig.
Wat is het verschil tussen deze lagen:
?-??-AM-AS_SPOOR_TRAM_AFWIJKING-G
?-??-AM-AS_SPOOR_TRAM_AFWIJKING_ONBEKEND-G
Deze lagen hebben alleen voor status ‘B’ verschillende presentatie eigenschappen, die weer afwijken van de overige statussen voor deze objecten, waarbij geen onderscheid in presentatie eigenschappen is gemaakt. Ofwel: alleen bij status 'B' zien deze 2 lagen er verschillend uit.

In principe zijn kleuren voor alle NLCS-statussen gelijk
Als iets (nog) niet bekend is vul je dat volgens het principe van de NLCS niet in, dus dan geldt: ?-??-AM-AS_SPOOR_TRAM_AFWIJKING-G = ?-??-AM-AS_SPOOR_TRAM_AFWIJKING_ONBEKEND-G.

Mij valt op dat onderscheid in status word gemaakt met kleuren en niet met lijndikten. Zowel deze systematiek als de gekozen kleuren en lijndikten zijn niet conform NLCS. Dat wil niet zeggen dat dit niet mogelijk is, maar er is wel een betere afstemming met de NLCS nodig! Zowel qua laageigenschappen als qua Formele Beschrijving NLCS.

@SanderNijhof dank voor de input, er gaat een NLCS expert betaald aan het werk om een voorstel te maken voor kleuren en lijntypes conform NLCS, dit gebeurt tijdens de reviewperiode van het concept 5.1. In het concept zullen dus de verkeerde lijnen en kleuren gepubliceerd worden, maar dan kaunnen al wel de objecten gereviewed worden.

Gekregen van michel bestanden: https://github.com/nl-digigo/NLCS/tree/main/ontwikkeling/stedelijk spoor/2024-10-28
Met mail:
In de ZIP zit:

Een word bestandje, waar ik per hoofdgroep mijn vragen heb gesteld.
De excelstaten, waarin ik met een kleur heb aangegeven waar mijn vragen over gaan, voor de herleidbaarheid.
Een .LIN file met de (op dit moment) op te nemen lijntypes, deze zal nog uitgebreid worden, dus zie het als een tussentijds resultaat).
Alle symbolen, welke zijn bijgewerkt volgens de NLCS 5.1 regels. Dit is al met al nog een hele operatie geweest. 😓

Het lijjkt me goed om het Wordbestand met de werkgroep te bespreken én vooral te spiegelen aan de NLCS regels.
Ik bemerk zo links en rechts dat de manier van tekenen waaraan ze gewend zijn niet helemaal strookt met de NLCS gedachte.
Hierbij is ook raakval met issue: [Omgang status 'Vervallen' i.r.t. allerlei beheer wensen / presentatie vervallen met scraps versus rood · Issue #251
Stedelijk spoor wil geen SCRAPS in de vervallen lagen, dat is mij wel duidelijk geworden. 😉

Goed werk Michel!
Ik hoop dat we bij een volgend NLCS-EC de reacties van de werkgroep op jouw vragen kunnen bespreken.
Heb je zelf lijnstijlen en symbolen gemaakt of zijn die aangeleverd vanuit de werkgroep?
Je stelt voor om LIGGING_PROFIELDRAAD te wijzigen naar PROFIELDRAAD_LIGGING.
Is 'LIGGING' wel geen object/subobject, of meer een verwijzing of feit.

Wat is qua betekenis het verschil tussen de lagen LIGGING_PROFIELDRAAD of PROFIELDRAAD_LIGGING en PROFIELDRAAD ? Zijn dit meerdere lagen met dezelfde betekenis? Voor mij i.i.g. verwarrend welke wanneer te gebruiken. Is het niet logisch dat een profieldraad ligt waar die is getekend?
M.a.w. : Wat gaat er mis als we deze lijn op dezelfde laag zetten: PROFIELDRAAD.

@SanderNijhof
De vragen die ik gesteld heb hoop ik met de werkgroep spoor al te kunnen ondervangen, zodat we voor de NLCS-EC gewoon een concreet stuk hebben zonder open eindjes.
De lijnstylen heb ik zelf gemaakt, met de imput vanuit de spoor werkgroep.
De symbolen zijn aangeleverd door de werkgroep, maar die heb ik wel allemaal moeten bijpoetsen om te voldoen aan de NLCS.
Je vragen zijn terecht en gaan ook zeker besproken worden. ;-)

Vragen en feedback voorstel stedelijk spoor - reactie EGH en MLI.docx
In dit document staat de gezamenlijk reactie van GVB en HTM op de opmerkingen/vragen van Michel van der Hulst

authors: ElisabethKloren HarmdHerripon MvanderHulst PHaffmans SanderNijhof ehensing

repo: nl-digigo/NLCS


text:
ext2dump.exe failed to extract system.img.ext4

https://samfrew.com/download/GALAXY__Note3__/nO5r/TPL/N9005XXSGBRI2/N9005TPLGBRJ1/

it will work with ext2rd.
problem is that ext2dump is quite old, I just kept it around for historical reasons.
now deleted from the repository to avoid confusion.

ext2rd dump failed. what should i do?
C:\extfstools>ext2rd.exe system.img.ext4 ./:testdir
sparse: v00000001 h:001c c:000c b:00001000 nblk:00090000 ncnk:00000fea,  cksum:00000000
end of sparse: 90000000
4074 entries in sparse map
first: 0-1000: copy from 28
last:  8b18a000-90000000: fill with 00000000
EXCEPTION - did you specify -B for a block device?
ERROR (2)No such file or directory: appending testdir/./VODB/lib/libMyScript2D.so

ext2rd will now create directories on windows.
But there still seems to be another problem, you will get 'blocknr too large'  during extraction.
also, if you look at the output of 'ext2rd -d system.img'  you will notices at some point you get invalid data.
I am looking into this.

I think the problem is in this ext4fs feature, which is not yet supported by ext2rd:

Flexible block group metadata location (EXT4_FEATURE_INCOMPAT_FLEX_BG)

Note that I will not solve this right away, it may be a while before I have time to do this.

repo: nlitsme/extfstools


text:
ci: push benchmark results to dedicated branch

Motivation
The current benchmarking system does not compare
the results with previous benchmarks, as we have
no place to store the results.
This commit ensures that this is no longer the
case by pushing the benchmark results to a
dedicated branch called benchmark-results.
Changes
After pushing the benchmark results to GitHub pages, a json is now created and automatically
committed to the benchmark-results branch.
Rejected alternatives
Use actions/cache to store the results. The
reason why this was not done is that the entries
in the cache will expire after a set amount of
time, which is likely to happen. In such a
scenario there will be additional burdens on the
developers to manually update the cache.
Quirks
The benchmark results had to be moved out of the
working directory because of conflicts with the
checkout actions.

This is how the commits created by this PR will look like: https://github.com/trym-b/warchaeology/commit/9b5fc902dd986018115ccf322c29a3b1ec6e2e56

repo: nlnwa/warchaeology


text:
Fully remove nose in favor of pytest

The most immediate followup of https://github.com/nltk/nltk/pull/2595 is to stop using nose in the repo entirely.
Also cleaned up:

A few pytest warnings (there's a few more)
A few random test code things (like unneeded / unreachable code)

I'm honestly not sure about all those skipped tests as well. I'm tempted to suggest to delete them, but since none of them are in the scope of my regular contributions/maintenance work I think it's best you try to ping the folks who wrote them (use git blame to find that out).

re: skipped tests, totally! i spun out a new issue for CoreNLP. i'd rather not tie this diff into that conversation. (after all, maybe that test code is helpful and should stay)

Thanks @dannysepler, @iliakur! Nice milestone 👍

This change means that pytest is an undeclared dependency of nltk and this seems to break things with the new 3.6. release
https://github.com/nltk/nltk/releases/tag/3.6 breaks any https://github.com/nexB/scancode-toolkit pip installation

authors: dannysepler iliakur pombredanne stevenbird

repo: nltk/nltk


text:
Customize nfs

Added the ability to set the IP Ranges and/or Hosts to the NFS Exports which are allowed to mount
(was Previously statically set to knode{1..3})

@CBeerta I've been hacking heavily on this for the last few days.  If you review my MR I support this with many other enhancements.  Have a look and let me know what you think.

Indeed, this will be not necessary when @travisghansen PR will be merged.

@CBeerta OK, my branch has been merged.  While certainly possible to replicate previous behavior, the defaults do not replicate previous behavior.  I can give guidance if you need help or if possible to 'start over' then you may just do that.

Ill just close this MR. What @travisghansen did is so much better than this!
Thanks!

@CBeerta thanks!  Let know how it goes.  Any feedback you have would be great!

authors: CBeerta nmaupu travisghansen

repo: nmaupu/freenas-provisioner


text:
add option to include summary biomass time series in DERIVED_QUANTITIES

As noted in https://github.com/r4ss/r4ss/issues/524, summary biomass is a useful metric for many models as an approximation for available biomass and a common framework to compare models that have different maturity or fecundity relationships (as is sometimes then case when comparing new vs old assessments of the same stock).
@IJStewart pointed out that such comparisons would be even more useful if the uncertainty in summary biomass were available.
I'm guessing that the hardest part of this request would be figuring out the best input format for the switch.
It could utilize More_Std_Input(13) (currently reserved for future use within the Dynamic B0 setup #75 as shown at
https://github.com/nmfs-stock-synthesis/stock-synthesis/blob/main/SS_readcontrol_330.tpl#L4189.
Alternatively a new Do_More_Std == 3 option could be added which would extend the inputs beyond the 13 values currently associated with Do_More_Std == 2.

Thanks Ian for queueing this up neatly.
Since there probably are very few users who are using  Do_More_Std==2, I support inplementing this as a modification of that option that will now require input for   Do_SmryBio_se=More_Std_Input(13) immediately after the current input for Bzero.  After that, the code for implementing this will largely be the same as what was done for Bzero.

I realized that unlike other time series quantities that are included in DERIVED_QUANTITIES, Summary Biomass is calculated in each season for a multi-season model. I'm guessing that it would be just fine to provide those values only from Season 1.

I have completed this augmentation.
A question - location in the output.
Option A (implemented):
remove the old SmryBio output that was located in the Biology section at end of ss_summary
insert new SmryBio section, with se, right after the ln(SSB) output and before the other extra_std quantities.  This was easy because all are components of the extra_std vector.  Note that the change in order will cause a Jenkins fail and may need r4ss update.
Option B (a lot more work, but possible):  keep smrybio output in same place but now let it have se.
This is more work because of the order in which labels are created for the std quantities.
Let me know if you really, really want option B.

While working on this, I noted that the values of SmryBio and TotBio in forecast years kept increasing.  Turns out that the accumulator code in SS_benchfore was not working properly.
Fixed this and ran a compare of these quantities as reported in ss_summary.sso, to the independently calculated quantities in TimeSeries of report.sso.  They match.  Case closed.

control.ss_new now looks like:
2 # (0/1/2) read specs for more stddev reporting: 0 = skip, 1 = read specs for reporting stdev for selectivity, size, and numbers, 2 = add options for M and Dyn Bzero
1 1 -1 5 # Selectivity: (1) 0 to skip or fleet, (2) 1=len/2=age/3=combined, (3) year, (4) N selex bins; NOTE: combined reports in age bins
1 5 # Growth: (1) 0 to skip or growth pattern, (2) growth ages; NOTE: does each sex
1 -1 5 # Numbers-at-age: (1) 0 or area(-1 for all), (2) year, (3) N ages;  NOTE: sums across morphs
0 0 # Mortality: (1) 0 to skip or growth pattern, (2) N ages for mortality; NOTE: does each sex
2 # Dyn Bzero: 0 to skip, 1 to include, or 2 to add recr
1 # SmryBio: 0 to skip, 1 to include

The way you've implemented it seems just fine to me.
Is the only change in Report.sso is the addition of the SmryBio rows after ln(SSB) in DERIVED_QUANTITES?
I would change the first line in control.ss_new from
2 = add options for M and Dyn Bzero
to
2 = add options for M, Dyn Bzero, and SmryBio.
Here are a few more things to do before closing this issue (if there are no other concerns about how it's implemented):

[ ] change SS tests to adapt to difference in ss_summary.sso (and maybe modify one of the test models to use this new option)
[ ] change r4ss as needed
[ ] add documentation of the new SmryBio option to the User Manual
[ ] document Dyn Bzero option 2 (@Rick-Methot-NOAA, can you explain what the "2 to add recr" does?)

The option 2 to add Dyn Recr simply appends the time series of Recruitment
after the time series of SSB in the dynamic Bzero section.
On Thu, May 6, 2021 at 8:33 AM Ian Taylor @.***> wrote:

The way you've implemented it seems just fine to me.
Is the only change in Report.sso is the addition of the SmryBio rows after
ln(SSB) in DERIVED_QUANTITES?
I would change the first line in control.ss_new from
2 = add options for M and Dyn Bzero
to
2 = add options for M, Dyn Bzero, and SmryBio.
Here are a few more things to do before closing this issue (if there are
no other concerns about how it's implemented):

change SS tests to adapt to difference in ss_summary.sso (and maybe
modify one of the test models to use this new option)
change r4ss as needed
add documentation of the new SmryBio option to the User Manual
document Dyn Bzero option 2 (@Rick-Methot-NOAA
https://github.com/Rick-Methot-NOAA, can you explain what the "2 to
add recr" does?)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nmfs-stock-synthesis/stock-synthesis/issues/168#issuecomment-833619600,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABPV4IGRBEPXMS2UWEIBT73TMKZFRANCNFSM435PZBSQ
.

This creates a breaking change for anyone who was using option 2 just for natural mortality inputs in previous versions of SS. We may want to note this in the change log and perhaps a warning in r4ss.

I don't understand how this interacts with natural mortality.  Does this
seem fixable easily?
On Fri, May 21, 2021 at 8:43 AM Kathryn Doering @.***>
wrote:

This creates a breaking change for anyone who was using option 2 just for
natural mortality inputs in previous versions of SS. We may want to note
this in the change log and perhaps a warning in r4ss.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nmfs-stock-synthesis/stock-synthesis/issues/168#issuecomment-846045896,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABPV4IGJKZUB5BV37FASCM3TOZ5SBANCNFSM435PZBSQ
.

I think in 3.30.16 (and 15?), option 2 inputs looked like:
2 # (0/1/2) read specs for more stddev reporting: 0 = skip, 1 = read specs for reporting stdev for selectivity, size, and numbers, 2 = add options for M
1 1 -1 5 # Selectivity: (1) 0 to skip or fleet, (2) 1=len/2=age/3=combined, (3) year, (4) N selex bins; NOTE: combined reports in age bins
1 5 # Growth: (1) 0 to skip or growth pattern, (2) growth ages; NOTE: does each sex
1 -1 5 # Numbers-at-age: (1) 0 or area(-1 for all), (2) year, (3) N ages; NOTE: sums across morphs
0 0 # Mortality: (1) 0 to skip or growth pattern, (2) N ages for mortality; NOTE: does each sex

In 3.30.17 with the new dynamic b0 and smry biomass options, more inputs are needed (2 extra values at the bottom)
2 # (0/1/2) read specs for more stddev reporting: 0 = skip, 1 = read specs for reporting stdev for selectivity, size, and numbers, 2 = add options for M and Dyn Bzero
1 1 -1 5 # Selectivity: (1) 0 to skip or fleet, (2) 1=len/2=age/3=combined, (3) year, (4) N selex bins; NOTE: combined reports in age bins
1 5 # Growth: (1) 0 to skip or growth pattern, (2) growth ages; NOTE: does each sex
1 -1 5 # Numbers-at-age: (1) 0 or area(-1 for all), (2) year, (3) N ages; NOTE: sums across morphs
0 0 # Mortality: (1) 0 to skip or growth pattern, (2) N ages for mortality; NOTE: does each sex
2 # Dyn Bzero: 0 to skip, 1 to include, or 2 to add recr
1 # SmryBio: 0 to skip, 1 to include

I think this means that 3.30.16 models that used variance of M options previously would no longer work with 3.30.17, because they are missing 2 values.
I suspect there are not too many models like this, so maybe it is ok to make a breaking input change? An alternative s to add an option 3 for read specs for more stddev reporting.

The M options are still there in 3.30.17, but now they are followed by the
Dyn Bzero options
On Fri, May 21, 2021 at 9:05 AM Kathryn Doering @.***>
wrote:

Reopened #168
https://github.com/nmfs-stock-synthesis/stock-synthesis/issues/168.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nmfs-stock-synthesis/stock-synthesis/issues/168#event-4780156586,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABPV4IFYYFTMLF4MMPBI4E3TO2AENANCNFSM435PZBSQ
.

Yes, but that means an older model that has used the M options won't have the Dyn Bzero/ Summary biomass options inputs (because they weren't expected inputs at the time) and won't be parsed correctly when reading into SS (I assume this model would error with 3.30.17).
There's nothing internally wrong with the implementation in SS, but we just need to decide if we are OK with this being  a breaking input change for previous users of option 2 and make sure this is communicated.

sounds good, Rick. I am making a note in the documentation now.

repo: nmfs-stock-synthesis/stock-synthesis


text:
Fix multi-dataset bar highlighting and bar highlight color logic

Bar graphs are not highlighting each bar properly due to faulty logic that this corrects (lines 2338-2341).
Also, when a bar graph contains multiple data sets and any of the datasets are incomplete (ie: no data yet for April through December of this year), the activeBar objects without a data point at that location received by this.getBarsAtEvent(evt) are undefined. This includes a check prior to attempting to access its properties (lines 2374-2375).
The rest of the changes in the un-minified file are whitespace fixes done automatically by Phpstorm.

:clap: :+1:

@davidcochrum can you please PR the files from the src dir instead of the built file? Otherwise the changes will be lost when the next build happens.

Haha oops ... no problem

Updated src and reverted built files

authors: davidcochrum etimberg mcloide


text:
nnstreamer/apptest: improve readability of log file

This commit is trivial. This commit is to improve a readability of the
log file that is generated by NNstreamer apptest module to evaluate
the GUI application in the Cloud (e.g., Amazone AWS EC2).
The test scenario to evaluate sample applications, is as following:
a. Start a producer
b. Start consumer(s)
- Connect the producer to open a session for virtual display environment.
- Run an application while 2 seconds arbitrarily
c. - Kill a process of the application after 2 seconds. Otherwise, the process runs forever.
d. Report the execution result with a webhook API.
Signed-off-by: Geunsik Lim geunsik.lim@samsung.com

:memo: Version: 1.20190225. Thank you for submitting PR #515. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://nnsuite.mooo.com/.

authors: leemgs taos-ci

repo: nnsuite/TAOS-CI


text:
🛑 Underdev is down

In d3d6a97, Underdev (https://underdev.net/pi.php) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Underdev is back up in 413e279 after 10 minutes.

repo: nocturo/status


text:
🛑 Rur is down

In 3612c96, Rur (https://www.rur.rs) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Rur is back up in 446a546 after 10 minutes.


text:
iOS Push Notification Error: {reason: 'TopicDisallowed'}

Please read carefully before closing. I'm struggling to resolve notifications for more than a week and still it's half way resolved.

I'm using the production certificate.
It's working fine sometimes and suddenly starts throwing: { reason: 'TopicDisallowed' }
It's working perfectly fine on localhost.
It works fine sometimes on the server too (the issue is unstable). It automatically starts working and stops.

Here is the provider config:
const apn = require('apn'); // version: "apn": "^2.2.0"
const iosOptions = {
  token: {
    key: path.resolve('./lib/AuthK*********.p8'),
    keyId: '*********',
    teamId: '*******'
  },
  production: true
};

const apnProvider = new apn.Provider(iosOptions);

const apnNotification = new apn.Notification();
apnNotification.sound = 'default';
apnNotification.title = 'Hello';
apnNotification.body = 'Hello message';
apnNotification.aps.threadId = 'thread_id';
apnNotification.topic = topic;
apnNotification.payload = payload;

return apnProvider.send(apnNotification, token)

Is there anything wrong with the config?
Error message: reason: 'TopicDisallowed'
Please help if someone knows the solution.

I have resolved it by replacing the apn package with the @parse/node-apn (npm i @parse/node-apn) package.

I monitored the results and it seems it wasn't resolved with the parse community package either. Please help.

Finally, I've resolved it by removing the package and writing a custom notification sender with Apple's official documentation for https://api.push.apple.com.
Here's more: https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html#//apple_ref/doc/uid/TP40008194-CH11-SW3

repo: node-apn/node-apn


text:
"List Operations" in sidebar does not include flows with embedded link out/in pairs

I tracked down why my new http endpoint was not showing in the Swagger sidebar... the code searches from the http in node until it finds a connected http response node -- and if it doesn't find one, it won't show in the Operation List.
This check is good -- however, in my case, the http response node IS connected, but through a link out/in pair, which is causing my api to be excluded from the Operations list. The function that does this validation is:
    function checkWiresForHttpResponse (node) {
        var wires = node.wires[0];
        for(var i in wires){
            var newNode = RED.nodes.getNode(wires[i]);
            if(newNode.type == "http response"){
                return true;
            } else if(checkWiresForHttpResponse(newNode)){
                return true;
            }
        }
        return false;
    }

I tried to "hop over" the link nodes, by checking if node.type === "link out", then use the node.links array (instead of wires[0]).  Although node.links exists in the flows.json file, once it is loaded into the runtime, that attribute is no longer available... (?) hmmm
So it probably requires an intermediate node lookup, something like this (untested)?
            var newNode = RED.nodes.getNode(wires[i]);
            if (newNode.type == "link out") {
                newNode = RED.nodes.getNode(node.links[0]);
            }

However, this assumes there is only one link in connected to each link out -- so some iteration will probably be needed. And will this work for wires connected to subflows? Probably not, which makes me wonder if this validation is even necessary.
Today, any http in node wired to an http response node will appear in the list of Swagger Operations. Instead, I suggest we eliminate the checkWires validation, and only include those http in nodes that have a swagger-doc node defined. I'd be happy to submit a PR with these and any other necessary changes, if you agree with my assessment.

Another broken condition related to this issue -- the node-link traversal seems to only follow wires from the 1st output port of a switch node (and probably other nodes with multiple output ports?).
While developing most of my http "endpoint" flows, I use inject nodes as an alternate way to test the logic of the flow. So at the end of the flow is a switch node that checks if msg.req is not null, and sends the response to an http response node (or a debug node, if not initiated from an http in node). If I test for null first (connected to the debug node) then my endpoint does not show up in the swagger sidebar -- even though there is an http response node at the end of the flow.

repo: node-red/node-red-node-swagger


text:
Node's sendEvents object canb contain invalid cloneMessage info.

Current Behavior
In the runtime library, the Node.js contains a blurp:
When two or more messages are sent through the Node.send([{payload:'msg1'}, {payload:'msg2'}, {payload:'msg3'}]), the sendEvents object in the runtime library (@node-red/runtime/lib/nodes/Node.js::~446) is filled with source and destination information and sent to the flow.
However, there's a field called, cloneMessage, that is set to true (by the msgSent variable) as soon as the first message has been handled.
This works if you have only one message, but when sending in multiple messages, the following messages 'msg2' and 'msg3' (in this case) will be flagged as cloned and then in (@node-red/runtime/lib/flows/Flow.js::~813) the flag is checked and cloning all initial messages.
Expected Behavior
I would've guessed that each message is its own and the clone is used to clone individual messages (The msgs, and not the sendEvents).
If this is the case, the msgSent shouldn't be used for the sendEvents.cloneMessage field.
Steps To Reproduce
Execute:
Node.send([{payload:'msg1'}, {payload:'msg2'}, {payload:'msg3'}])
Put a breakpoint or log in Flow.js::handlePreRoute of the @runtime library.
The 'msg2' and 'msg3' is cloned even though they're the initials. 'msg1' however isn't cloned.
Example flow
paste your flow here

Environment

Node-RED version: 3.0.2
Node.js version: 18.4.0
@runtime library bug

In you example, msg2 and msg3 are not guaranteed to be 'initials' as you call them and must get cloned.
Instead of:
Node.send([{payload:'msg1'}, {payload:'msg2'}, {payload:'msg3'}])

Consider the code:
const msg = { payload: 'msg1' }
Node.send([msg, msg, msg])

Here the same object is passed multiple times. The first instance can be passed through uncloned. The others must get cloned to break the link.

That is completely true.
You could do something like this:
if (sendEvents.find(e=>e===curentMessage).length == 1) // not cloned (on top level).
But it could be a subobject used in both objects.
I back down. Continue as is "Great job"

authors: TLacke knolleary

repo: node-red/node-red


text:
Fix exec node error tests on Windows

Hi @dceejay,
I fixed several error tests which occurred only on Windows environment.
I also noticed that there are two results that the payload length becomes 6 or 8 on the following test case.
"exec node calling spawn should spawn a simple command and return binary buffer"
I'm not sure the exact condition but in my environment, the payload length is 6 on Windows 7, and the one is 8 on Windows 10.
So I fixed to accept both of them.

Coverage increased (+0.07%) to 87.131% when pulling 2912f35b7306645f7c692d35e39c18a03a454111 on Kazuki-Nakanishi:0.17 into 11ee1a7dcb7c537ad6b8fe62e5654da6111de0aa on node-red:0.17.

Coverage increased (+0.07%) to 87.131% when pulling 2912f35b7306645f7c692d35e39c18a03a454111 on Kazuki-Nakanishi:0.17 into 11ee1a7dcb7c537ad6b8fe62e5654da6111de0aa on node-red:0.17.

authors: Kazuki-Nakanishi coveralls


text:
Add Larson Carter (larson-carter) into the community committee

I'm wanting to join the community committee and work amongst all other amazing people.

Our current path to becoming a CommComm member is through doing work in the CommComm Initiatives. As far as I can see, you've not yet participated in any of our initiatives in an impactful and sustained way - totally happy to be wrong here, of course!
Generally, the framing we try to have with the committees in the Node.js project is that all the work we do is in Working Groups, Teams, and Initiatives - the TSC and CommComm are just meta admin bodies that do the overhead coordination work that has to be done. If you're interested in doing impactful CommComm work, I'd definitely recommend taking a look at our initiatives list and seeing which areas you could meaningfully help out - many of the initiatives need a lot of help right now ❤

Since there has been no further comment from CommComm members, I'm going to close this for now. If the aforementioned status changes, please feel free to ping me or any CommComm member.

authors: bnb larson-carter

repo: nodejs/community-committee


text:
[Snyk] Upgrade commander from 9.5.0 to 10.0.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade commander from 9.5.0 to 10.0.0.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

Warning: This is a major version upgrade, and may be a breaking change.

The recommended version is 1 version ahead of your current version.
The recommended version was released 21 days ago, on 2023-01-14.

Release notes

Package name: commander

10.0.0 - 2023-01-14Added

wrap command description in help (#1804)

Changed

Breaking: Commander 10 requires Node.js v14 or higher

9.5.0 - 2023-01-07Added

.getOptionValueSourceWithGlobals() (#1832)
showGlobalOptions for .configureHelp{} and Help (#1828)

    from commander GitHub release notes

Commit messages

Package name: commander

8b03ab7 10.0.0
d0dac4c Update CHANGELOG (#1840)
2bdd631 Merge branch 'master' into release/10.x
5f3f004 *: update dev deps and make tweaks
04fc0fd Add Command.options to TypeScript (#1827)
e0f6173 Merge remote-tracking branch 'origin/develop' into release/10.x
f3880f7 Update dependencies (#1826)
c897329 Update minimum version of node in README (#1815)
ef88d70 Bump supported versions (#1808)
186f0c8 Wrap command description in help (#1804)

Compare

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Codecov Report
Base: 92.36% // Head: 91.98% // Decreases project coverage by -0.39% :warning:

Coverage data is based on head (3276d3b) compared to base (59390eb).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #168      +/-   ##
==========================================
- Coverage   92.36%   91.98%   -0.39%
==========================================
  Files           9        9
  Lines         262      262
==========================================
- Hits          242      241       -1
- Misses         20       21       +1

Impacted Files
Coverage Δ

lib/function-loader.js
88.46% <0.00%> (-3.85%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

authors: codecov-commenter pacostas

repo: nodeshift/faas-js-runtime


text:
Test Coverage for CommonLogger

relates to #414
https://coveralls.io/builds/28840134/source?filename=lib/common-log.js

@lholmquist I'll take this one

authors: alexalikiotis lholmquist

repo: nodeshift/nodeshift


text:
src: updates kubernetes-client and fix deprecation warnings

Related to https://github.com/nodeshift/openshift-rest-client/issues/140

Pull Request Test Coverage Report for Build 488

3 of 3 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 486:
0.0%

Covered Lines:
44

Relevant Lines:
44

💛  - Coveralls

authors: coveralls helio-frota

repo: nodeshift/openshift-rest-client


text:
Licence Management

ability to manage software and operating system licences
Tasks

[ ] plan feature

added 2m of time spent

marked this issue as related to #19

adding #19 as related as this module may be able to use the licence information from the packages

added 1m of time spent