Build stalled in python3

Details

Project URL: https://readthedocs.org/projects/serenata-toolbox/
Build URL : https://readthedocs.org/projects/serenata-toolbox/builds/4739105/
Read the Docs username: jonDel

Expected Result
Documentation build complete.
Actual Result
The build get stuck for some reason in the second command which I think has nothing to do with my particular build (seems like readthedocs related packages installation):
python /home/docs/checkouts/readthedocs.org/user_builds/serenata-toolbox/envs/latest/bin/pip install --use-wheel -U --cache-dir /home/docs/checkouts/readthedocs.org/user_builds/serenata-toolbox/.cache/pip sphinx==1.3.5 Pygments==2.1.3 setuptools==20.1.1 docutils==0.12 mkdocs==0.15.0 mock==1.0.1 pillow==2.6.1<EMAIL_ADDRESS>sphinx-rtd-theme==0.1.9 alabaster>=0.7,<0.8,!=0.7.5 commonmark==0.5.4 recommonmark==0.1.1
It only occurs when it is configured to run my setup.py install, which is odd, since it never gets to the point of installing my dependencies.
It is even stranger that the command related seems to be completed successfully, and nevertheless it never went to the execution of the next command.

Looks like this has been resolved, as the recent builds have happened properly. Let me know if this is still an issue.


Add Aragon DAOs to the indexer

From discussion Dec. 20. Let's get some DAOs indexed before the end of the year (DAODAO, Aragon), and then focus on improving data quality in the new year!

In conversation with them on this, waiting on their developer lead to provide the API details

Aragon DAO URI API is now up
Demo:
https://aragon-dao-uri.onrender.com/fetch_aragon_daos/base
https://aragon-dao-uri.onrender.com/aragon_dao/ethereum/0x02bbc496bebc9a06c239670cea663c43cead899f

Working on displaying the DAO URIs https://github.com/metagov/daostar/pull/202

Today, we had a discussion with Ivan to integrate the DAO URIs in Aragons API
I, Rashmi need to send a proposal to Aragon on what exactly the steps are and how does it benefit Aragon to Ivan

I shared a brief write up on Aragon EIP-4824 Integration, to Ivan
https://hackmd.io/@torchablazed/H1G0vOso6

Ivan had texted in the group that he can't attend Strike Team calls due to conflict. But... we still need to get in touch with their tech team.

[ ] Rashmi, please ping that thread
[ ] Josh, follow up as well after Rashmi pings that thread
[ ] If necessary, drive it all the way up to Anthony Leutenegger (CEO of Aragon)


kotlin: Add existing extension methods to Provenance coroutine-based client for feature parity

Description
For the Kotlin proto bindings:
Surface existing extension methods in the Provenance coroutine-based client for feature parity.

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md)
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Wrote unit and integration tests
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
[ ] Added relevant godoc comments.
[ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[ ] Re-reviewed Files changed in the Github PR explorer
[ ] Review Codecov Report in the comment section below once CI passes

@SpicyLemon @iramiller Any idea why the Login to Docker step is failing in https://github.com/provenance-io/provenance/actions/runs/6005004861/job/16286820705?pr=1665 ?


Disabling Epsagon function at a function level doesn't appear to be working correctly

I'm trying to disable epsagon on one of my functions, but it doesn't appear to be working correctly.
I added this configuration to my function, as per the documentation
  function1:
    handler: src/function1/handler.default
    epsagon:
      disable: true

But I get the following log output in verbose mode:
Serverless: [serverless-plugin-epsagon] Wrapping your functions with Epsagon...
Serverless: [serverless-plugin-epsagon] Epsagon is disabled for function undefined, skipping.

I confirmed that the listed log line only appears when I have the disable: true value, so it isn't triggering off of some other configuration.
Examining the relevant code, it appears that there are two issues.
        if (disable) {
          this.log(`Epsagon is disabled for function ${func.key}, skipping.`);
        }

The value func.key should probably be key
There is a missing return result; within that if block.

Fixed. #23


We need to update the "Terms" page in dmptool to change "Privacy policy" to "Privacy Statement"

Per Rachael Hu's request:
On this DMPTool page, we need to change the "CDL privacy policy" to read "CDL privacy statement".
The question is whether we should change all four instances of "privacy policy" to "privacy statement" on the page.
This is the updated CDL Privacy statement: https://cdlib.org/about/policies-and-guidelines/privacy-statement/

I made the update and created a PR: https://github.com/CDLUC3/dmptool/pull/591


Cargo caches failed cargo clippy -- --bad-arg

Problem
From https://github.com/rust-lang/rust-clippy/issues/12623#issuecomment-2034588171:

cargo new --lib demo && cd demo

cargo check
cargo clippy -- -x
cargo clippy

The first clippy/check creates the target dir including target/.rustc_info.json, it seems failures aren't recorded in .rustc_info.json if it doesn't exist yet
In the second command cargo records the result of the target info acquisition under a different hash
The third command uses the same hash to retrieve the previously failed result

The issue being CLIPPY_ARGS is not taken into account when creating the hash

Output:
    Creating library `demo` package
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
    Checking demo v0.1.0 (/.../demo)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.14s
error: process didn't exit successfully: `/.../rustc -vV` (exit status: 1)
--- stderr
error: Unrecognized option: 'x'

error: process didn't exit successfully: `/.../clippy-driver /.../rustc -vV` (exit status: 1)
--- stderr
error: Unrecognized option: 'x'

cargo clippy -- -x is expected to fail but the following cargo clippy is not
In normal operation clippy-driver gets far enough along to register CLIPPY_ARGS into the env depinfo but that doesn't happen here
Steps
No response
Possible Solution(s)
CLIPPY_ARGS could be added to the fingerprint as a special case, but the issue could also exist for other wrappers
Notes
No response
Version
No response

Note that cargo has no knowledge of CLIPPY_ARGS, one way or the other, to be able to fingerprint it.

Would not caching failed invocations in .rustc_info.json be an option?

The command being invoked is
$ /home/epage/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/clippy-driver /home/epage/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc -vV

So CLIPPY_ARGS is being passed through to this which is causing it to fail.
Trying 1.75, this wasn't a problem.  Looks like this might have been broken by #13659
CC @RalfJung

@RalfJung , I'm not seeing a problem statement in #10885.  Any further details on that?

Would not caching failed invocations in .rustc_info.json be an option?

Caching of failures was intentionally added in #9112 (cc5e9df64a7ed6b3657e9dd790e2e34387d33df5)

This commit updates the rustc info cache to cache failures to execute
rustc as well as successes. This fixes a weird issue where if you're
probing for flags the rustc_info_cache test fails on channels which
don't have the flag since previously a failure to execute rustc resulted
in never caching the result.

The problem in that case isn't too clear to me and would need further investigation to go down that route.

@RalfJung , I'm not seeing a problem statement in #10885. Any further details on that?

That issue explains the motivation, not sure what to add. Also, what good is a "wrapper" that doesn't actually get invoked for all rustc invocation? If the goal of the wrapper is to e.g. swap out which rustc is being called, it is crucial that all invocations are made through the wrapper.
Seems like the clippy wrapper is just blindly adding extra arguments to all invocations. Note that rustc -vV is not the only such "query invocation" cargo dues, it also does a rustc invocation to print all available targets, and that has always gone through the wrapper. So something must be treating that query different --  either that doesn't get cached for some reason 9seems unlikely) or clippy is already aware of it and avoids adding potentially faulty arguments, in which case it that logic needs to be extended to recognize other "queries" as well.

That issue explains the motivation, not sure what to add.

From my looking it came down to

This is causing us a bunch of pain right now since we need to figure out how to best intercept this -vV call.

without an explanation of why that call needs to be intercepted

Seems like the clippy wrapper is just blindly adding extra arguments to all invocations. Note that rustc -vV is not the only such "query invocation" cargo does, it also does a rustc invocation to print all available targets, and that has always gone through the wrapper. So something must be treating that query different -- either that doesn't get cached for some reason (seems unlikely) or clippy is already aware of it and avoids adding potentially faulty arguments, in which case that logic needs to be extended to recognize other "queries" as well.

This would be a good next step to investigate when considering all possible directions for resolving this.

Please also read the rest of the issue. :)
The context is that Miri and bootstrap use RUSTC_WRAPPER to completely replace the rustc being invoked, there is no a priori relationship between $RUSTC_WRAPPER rustc and the rustc in the path. Why they need to do that is not super relevant, it's exactly the kind of usecase that RUSTC_WRAPPER is designed for. Because $RUSTC_WRAPPER rustc  invokes a completely different binary, the result cargo gets by invoking rustc -vV without the wrapper is obviously bogus since it is talking to the wrong compiler.

It was an issue in 1.75 also
export RUSTUP_TOOLCHAIN=1.75
cargo new --lib demo && cd demo

cargo check
cargo clippy -- -x
cargo clippy

error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `...\clippy-driver.exe '...\rustc.exe'
- --crate-name ___ --print=file-names --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=split-debuginfo --print=crate-name --print=cfg` (exit code: 1)
  --- stderr
  error: Unrecognized option: 'x'

error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `...\clippy-driver.exe '...\rustc.exe'
- --crate-name ___ --print=file-names --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=split-debuginfo --print=crate-name --print=cfg` (exit code: 1)
  --- stderr
  error: Unrecognized option: 'x'

Skipping some steps if we encounter --print/etc is something I'll try on the clippy driver side

Yeah that is exactly the other "query invocation" I mentioned above. https://github.com/rust-lang/cargo/pull/13659 just made it so that both query invocations are fed through the wrapper consistently, but clippy's wrapper behavior in combination with caching was a problem even when just one of the queries is fed through the wrapper.

Skipping some steps if we encounter --print/etc is something I'll try on the clippy driver side

FWIW, this is Miri's logic for determining whether the invocation is an "info query" and hence needs to be treated differently:
https://github.com/rust-lang/miri/blob/471dcec041122b1bba8ab4fd8085f88e3bd275ff/cargo-miri/src/phases.rs#L298-L302

@RalfJung please assume people have made a good faith effort. In this case, I did look over the issue and another one it links to, multiple times in case I missed something.
Whats still not clear is the end-user side effect of what you are wanting, the end-user either being the RUSTC_WRAPPER author or their end user.  So far this is coming across as a purity argument ("its not that tool so its not that version").
Looking over the code, it looks like we primarily use it for MSRV checks and fingerprinting of rustc.  The first requires the result to be representative of the compiler / stdlib version being performed.  Unsure if there are other factors helping with fingerprinting or if that is ultimately what you are looking for here.

Yes, with the verification that that change didn't break rustc, it is no longer a blocker for this issue.  I'll copy the relevant notes to that issue.

This commit updates the rustc info cache to cache failures to execute
rustc as well as successes. This fixes a weird issue where if you're
probing for flags the rustc_info_cache test fails on channels which
don't have the flag since previously a failure to execute rustc resulted
in never caching the result.

Alex was referring to calls like
        let supports_split_debuginfo = rustc
            .cached_output(process.clone().arg("-Csplit-debuginfo=packed"))
            .is_ok();

which we do when we don't wait two releases before calling something.
If we reverted cc5e9df64a7ed6b3657e9dd790e2e34387d33df5, then the next time we add a probe, it will break the tests for our caching and the mixture of messages from the failure (not cached) and success (cached) cases would reduce the tests insight into what is working.  This test change would then need to be reverted if/when we remove the probe.
This wasn't called out but cc5e9df64a7ed6b3657e9dd790e2e34387d33df5 should have also reduced the overhead from the flag probing.
While miri and clippy can workaround this, it is a foot gun for anyone writing a RUSTC_WRAPPER and I'd prefer that we not have tests be negatively impacting the user experience like that.  I'm also not sure what we should change the tests to.  The most important aspect is that we don't have behavior regressions.  Personally, I tend to put a lower priority on testing "is an implicit cache giving us the right performance" because I don't think its usually worth the invasive changes to verify.

FWIW I don't think Miri is concerned with working around this. It anyway has to detect these "info queries" as they otherwise throw off our heuristics for whether the current rustc invocation is a "host" or a "target" build (which matters a lot for Miri because all "target" builds are just interpreted, not compiled to machine code).


Clear instructions for Offline configuration and opperation

Robot Model
Turtlebot4 Standard
ROS distro
Humble
Networking Configuration
Simple Discovery
OS
Ubuntu 22.04
Built from source or installed?
Installed
Package version
not applicable,
Type of issue
Networking
Expected behaviour
Connect to wired connection for packages and then connect to Wi-Fi for operation.
Actual behaviour
We need a clear method to utilize the Turtlebot 4 without internet connection.
Is it possible to configure the tb4 with a wired connection then connected to a local wireless network for operation.
If so please provide clear instructions .
thanks.
Error messages
No response
To Reproduce
not currently applicable.
Other notes
No response

Hi, these might be helpful to access the raspberry pi without connecting it to a network:
https://turtlebot.github.io/turtlebot4-user-manual/setup/basic.html#connect-to-the-access-point
https://turtlebot.github.io/turtlebot4-user-manual/setup/basic.html#recovering-the-raspberry-pi

Hi @Simba185
Did @mbergman257 suggestion help with interfacing to the RPi using ethernet?
Thanks @mbergman257 !
Regards,
Rusty

@RustyCPR
No unfortunately I am really looking for a system that would allow us to configure and use the turtlebot on a wifi network without internet.
I would need a way to host any files that are needed from the internet, and some method to tell the turtlebot that's where to get the files from.
This is still not an ideal setup. and is not an issue with the turtlebot, but an issues of access within my organization.
Any ideas are appreciated, Thanks.


Remove hooks functionality

The hook concept has been all but superseded by the new transaction API, which enables users to define a versioning workflow more naturally and make fine-grained decisions on when to do versioning, on which files etc.
Since the hooks are now only relevant for lower-level instrumentation, and we currently have no users using them, we remove them again. In a separate PR, we updated the demo notebook to use transactions everywhere, too.
Even though we only have the predefined client helpers on the transaction, which loses flexibility from the hook concept, the workflow using transactions is so superiorly readable and intuitive that most, if not all users should not be hindered.
Advertises transactions explicitly in the documentation as the tool to do versioning flows with.

cc @janwillemkl

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (4dcf421) 90.49% compared to head (245fc62) 88.64%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #139      +/-   ##
==========================================
- Coverage   90.49%   88.64%   -1.86%
==========================================
  Files           7        6       -1
  Lines         505      405     -100
  Branches       64       57       -7
==========================================
- Hits          457      359      -98
+ Misses         28       27       -1
+ Partials       20       19       -1

Files
Coverage Δ

src/lakefs_spec/__init__.py
66.66% <100.00%> (ø)

src/lakefs_spec/spec.py
86.80% <100.00%> (-2.22%)
:arrow_down:

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Qm external access

About the PR

Qquartermaster now has external access.
Why / Balance

The quartermaster is the head of cargo, and salvage specialists are their subordinates. If their subordinates have the access, they should have it too. Simple logic and the ability for QM to hire new salvage specialists without asking HoP to give them the external access.
Technical details

Nothing special, just a single line in .yml
Media

Requirements

[X] I have read and am following the Pull Request and Changelog Guidelines.
[X] I have added media to this PR or it does not require an ingame showcase.

:cl: pheenty

add: Quartermaster now has external access

makes sense

Hey, we had a maintainer discussion and vote and decided that it should be fine for the QM since salvagers also have externals access. Thank you for your contribution.
As a side note for anyone reading this: This does not mean the RD or CMO should have externals access as well.


[Tracking] FOSDEM conference Feb 4&5

Hey all, there is an opportunity at the FOSDEM2023 in Brussels early next year to push sustainability in the community. Some folks from the conference and LF contacted us if we would be interested in participating. They are planning a DevRoom around energy ⚡ .

FOSDEM has the concept of 'devrooms' to group content. It literally is a physical room and thereby can be equated to a track. And the context helps to group content and people together and foster a sense of community and the relations that come of it.
Together with some other people from LF Energy we have developed the idea to host a devroom on the topic of Energy at FOSDEM next year. The main goal is to grow a community that is wider in in scope than the LF groups and has attendees outside of industry and academia. The have been presentations on energy related topics on community conferences in the past, I even held one myself, but by having a devroom we would get some synergy going and really set the topic on the map by having a label for it.
Now more than ever energy is an important topic to discuss as the war in Ukraine and climate issues are driving up energy prices. The need for action and solutions is greater than ever.

At this moment we're with about 7 people involved in the organization. Currently we're preparing a proposal for the DevRoom to submit to the FOSDEM organizers when the Call for Devroom proposals is announced. As there are more devroom proposals than physical space, there is no guarantee the devroom will make it and we have to make the proposal as interesting as possible.
Here are some more details on the devroom and what is needed in terms of organization https://fosdem.org/2022/manuals/program/devroom/

Feel free to drop a comment if you are interested in participating, maybe we can organize something!
cc @nikimanoledaki (Marlow mention you might be interested 🙂 )

I dont know yet if I have time on the 4th and 5th.

I can help with the talk, not sure if I could make it to Brussels

Let me know how I can help. I can discuss with my employer potentially too. Happy to have a call to discuss.

If I can help, let me know. I can have a talk about kube-green on the sustainability topic!


Single epoch multi dataset encoding

As discussed yesterday in the call, dividing the confusion matrix cells in multiple areas is not optimal for the multi condition (dataset) comparison.
I suggest to switch to a simple line encoding (like a fuel bar) for the single epoch case where the line style represents the condition (e.g., DS1 = line, DS2 = stippled line, DS3 = dotted line).
This also has the advantage that the single epoch encoding would be very similar to the multi epoch encoding in the confusion matrix cells. This way, the user does not need to switch the mental model.

(I've updated the sketch in our GSlide deck accordingly: https://docs.google.com/presentation/d/1G5E-HJ_PRDsJ90YH6vd2Kf4L6wR-_SjkRns3BUD8u5g/edit#slide=id.g3445cf67de_0_13)
@HendrikStrobelt, @NMO13, @thinkh, @gfrogat: do you agree?

looks good to me, but we'll very likely encounter scaling issues assuming that all the cells will have the same range on the y-axis (we'll probably have some very large "buckets" and the remaining lines will be squashed at the bottom)

might be the case, yes. but was that different in our color encoding (one dark cell, rest almost white)?

Hendrik proposed the idea of adding a slider that controls the y range of the cells. This allows interactive "zooming". Squashed lines at the bottoms are easier to recognize this way. I think its not a bad idea.

how about this:

yes, that looks good. the single epoch case remains the same, right?

I thought about combining it, but we can also keep it as separate plot and only use the dotted slider for the transition

How about this?

The line stippling / dotting does not work on the small multiples.
We therefore decided to use color for encoding the different datasets.
dataset1: dark grey
dataset2: qualitative color1
dataset3: qualitative color2
etc.

Alternative to line-based cell encoding would be to use a heatmap. Advantage is that the single epoch case works the same way as the multi epoch case. Datasets/conditions can be stacked vertically within the cell.

Would look like this:

Not so easy to see small values...

Yes, because they are small. So that should be fine.
@NMO13 will post additional examples.

Here 3 images with 4 timelines selected and with changing epoch range:

Here images with 8

timelines and varying epoch ranges:

I like it! It's definitely much less cluttered than the line charts.
There are also interesting patterns that become obvious when looking at the visualizations. In this example (https://user-images.githubusercontent.com/3988444/38026296-ea90a7f8-328b-11e8-9cd8-139898430239.PNG), for instance, there is a particular epoch where the peak aligns in the horse predicted column. Seeing similar peak alignments for the ground truth would require to transpose the matrix or at least the cell heatmaps.

@NMO13, can you please also add the old line encoding for the same examples so that we have the direct comparison?

I added the same encoding to the single epoch case:

I added a single epoch marker:

I was initially a little skeptic whether the heatmaps would be useful, but it starts to grow on me.
What we definitely need is interaction, i.e. brushing and linking of all the plots in one column, so the lines for the currently selected cell are highlighted in the marginal lineplots (otherwise I'm lacking the context).
It would be also nice to be able to filter/brush certain lines in the detail view, and see them highlighted in the heatmaps.
Maybe even show both marginal plots (row- and columnwise aggretage linechart) in the detail view so one has the context.

...'it starts to grow on me' ;-)
yes, I agree that interaction is crucial.
@NMO13, if you use the Phovea heatmaps, they should support linking and brushing out of the box. @thinkh can you tell more about it tomorrow.

I close this issues, since we decided to implement the heatmap approach for the conf matrix (see #108) and the bar chart for single epoch will be discussed in #109.


405 error on forgot password

Couldn't create an account for my email. Tried to sign in (maybe there is already an account for me) didn't work, presented with forgot link ehich went to a 405 error (method not allowed)

This is a known bug (the feature was never added). Check issue #22.


Remove caching of OCI tests in CI

This removes caching of OCI tests in CI. This is regarding to #721 , and should work as a temporary solution to it. This will increase the CI time, but will always use the latest commit version. There might be some work-around such that we can cache and invalidate cache when new commits are added to OCi repo, but this does not address it, it can be done in a separate PR.

@utam0k This should potentially solve #721 for now. This might result in slightly bad CI times (integration tests needing 5-7 mins) but that is preferable than having broken/outdated integration tests
Please take a look :)

@YJDoc2 Thanks for your hard work!!! 💯


Getting error in shop page

Notice:  Trying to get property 'Inventory' of non-object in vendor\swordfox\silverstripe-shopify\src\model\Product.php on line 198

Looks like your Shopify product does not have any variants, pretty sure when you add a price it adds a variant.


More scenario's and details are welcome

Can this page be more detailed about the different scenarios and what will work and what not ? I have the feeling now it's mandatory to go read the OMA-URI as well, and even than.

@sXRaider Please indicate the document you are referring to and wish to give the feedback for its improvement. Thanks

https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/deploy-manage-removable-storage-intune?view=o365-worldwide#deploy-removable-storage-access-control-by-using-intune-user-interface
Op do 28 sep. 2023 10:20 schreef Yogesh Kumar @.***>:

@sXRaider https://github.com/sXRaider Please indicate the document you
are referring to and wish to give the feedback for its improvement. Thanks
—
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/microsoft-365-docs/issues/12874#issuecomment-1738693564,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXRJQVKICAI3P2QD3XJOBD3X4UXNTANCNFSM6AAAAAA5JT6WHE
.
You are receiving this because you were mentioned.Message ID:
@.***>

@Dansimp Please help us in resolving this issue. Thanks


Feature request: aggregate of non-ASCII/system file/directory characters

I'm enjoying digging into the lists of non-ASCII and troublesome characters. I think it could be useful to show an aggregate of the characters that appear in a report, and how often they appear. For example:
 characters outside of ASCII range: '0xc9, LATIN CAPITAL LETTER E WITH ACUTE: É' (248)
 characters outside of ASCII range: '0xf028, None: ' (4)
 non-recommended character: '0x5b, LEFT SQUARE BRACKET: [' (1474)

It could be useful so that during appraisal, if I know that latin letters with acutes are supported within the repository, but perhaps bullets or other characters are not, then it would speed up the process of identifying problematic characters.

Sorry it took a while to get back to this. It's a good suggestion. I need  some sample data so finally got round to creating a proper repo for some of my other test work here: https://github.com/ross-spencer/big-list-of-naughty-files which generates a lot of output that will appear in these kinds of aggregates. Unfortunately it breaks a few more things so I'll try and fix those first then add some more sample data to this issue to create the aggregates.


fix: upgrade deps

:tada: This PR is included in version 7.1.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Linear Kernel

What's the new feature?
Adds Linear kernel
What value does this add?
I think users will expect a Linear kernel to be available
Is there an alternative you've considered?
No response
Additional context
No response

Awaiting #583 (#544, #297).


cross-platform way to obtain UTF8 bytes

Currently there is no cross-platform way to convert a String to a UTF8 byte stream or array. I've long thought this was a bit silly, since it's an easy-enough operation in both Java and JS. We currently have ceylon.buffer.charset, but that's JVM-only, and carries a bunch of baggage.
I think this is a reasonable thing to add to the language module, but where should it go:

String itself?
process or runtime?

+1
I don't think that encoding belong to 'process' or 'runtime': despite some runtimes prefer some encodings, Ceylon tends to be agnostic to that choices.
As long as we are only encoding 'String's (say to UTF8, Unicode or whatever), 'String' itself sounds the natural place for me.
We may think about encoding other sources (i.e. base64 for binaries), but it seems not the right place for that discussion.

As long as we are only encoding 'String's (say to UTF8, Unicode or whatever), 'String' itself sounds the natural place for me.

Agree on this, unless the encoding function actually ends up taking a {Character*}, in which case it might make more sense as a separate, top-level function.

I've added an encode() function (on system for now, sorry guys!) but I suppose it needs a matching decode(). The charset is passed as an argument, and UTF-8 and UTF-16 are guaranteed to be supported.

I've added decode(). So the functionality is now compete, but we still need to decide if this operation  should be moved to String.

So, wait: is this functionality even a little bit useful without buffers? Because obviously this implementation is an extremely inefficient way to handle long strings of characters or bytes.
@FroMage?

good point, buffers sound good

buffers sound good

Right, but no way are we adding a buffer-like construct to the language module!
Though I suppose we might be able to use Array like a poor mans buffer.

Perhaps the signature of encode() could something like:
Integer encode(List<Character> string, Integer index, Array<Byte> outputBytes, String encoding)

where the return value is the number of characters written into the outputBytes (and the outputBytes would be padded with \0s).
And the signature of decode() could be:
void decode(StringBuilder builder, List<Byte> inputBytes, String encoding)

Integer encode(List<Character> string, Integer index, Array<Byte> outputBytes, String encoding)

Not {Character*} string ?
Who would want to calculate the length of outputBytes themselves? Always length of string * 4? I would like something like ByteArrayBuilder to be provided instead, which grows as necessary :)
Is index into string or outputBytes? I would guess the latter despite the imo "reverse" ordering

I would like something like ByteArrayBuilder to be provided instead, which grows as necessary :)

I'm pretty sure the real usecases don't call for that. We're trying to avoid allocating all the bytes into one big chunk of memory, no?

Is index into string or outputBytes? I would guess the latter despite the imo "reverse" ordering

Into the string. But hold on, it might be better to just have the function return the unwritten portion of the given list using sublist():
List<Character> encode(List<Character> string, Integer index, Array<Byte> outputBytes, String encoding)

But I dunno, all this is getting a bit messy now. If we can't come up with something sufficiently "clean" here, then it doesn't belong in the language module.

Oh! I just realized that, despite what I had thought, ceylon.buffer is cross-platform. Duh!

Well, given that, does anybody think there's a usecase for what I've already implemented? i.e. Being able to convert a short Strings to an Array<Byte> and back without any support for streaming/buffering?

@FroMage I need to know what you think of this.

Well, wait, perhaps the thing here is that I'm trying to work with whole Strings rather than just with Characters.
What if I added bytes() and forBytes() to Character?

I like the following API, with static methods on Character, probably:
class Character {
    shared static Integer encode(Character character, Array<Byte> array, Integer index, String encoding)
    shared static Character decode(Array<Byte> array, Integer index, String encoding)
}

The only problem with that is decode() doesn't give us a good way to discover the number of bytes read from the array. So I guess it should be something like this instead:
class Character {
    shared static void encode(Character character, Array<Byte> array, Integer index, String encoding)
    shared static Character decode(Array<Byte> array, Integer index, String encoding)

    shared Integer encodedLength(String encoding)
}

If something is to be added, I think it should be at the String granularity.
Character is too fine grained for performance ({Character*}s are slow), and converting Strings to Array<Byte>s isn't too bad memory wise (if you already have a String allocated, it's just 2x the memory).

Yeah, we usually work with Strings, and I think nobody uses arrays for IO anymore, only buffers, but that doesn't mean it shouldn't be possible to turn a String into a byte array. It's just, don't we already have support for encoding in the SDK?

Character is too fine grained for performance

Well I think with the API I just proposed, performance is going to be just fine:
String string = ... ;
Array<Byte> buffer = .... ;
variable Integer index = 0;
for (char in string) {
    Character.encode(char, buffer, index, encoding);
    index+=char.encodedLength(encoding);
}

With a native-level implementation of Character.encode(), I should be able to make that very efficient.
Likewise:
StringBuilder string = ... ;
Array<Byte> buffer = .... ;
variable Integer index = 0;
while (index < buffer.size) {
    value char = Character.decode(buffer, index, encoding);
    string.append(char);
    index+=char.encodedLength(encoding);
}

And by doing it at the Character level, we have something that is abstracted away from the higher-level data structures you're using (streams, arrays, buffers, lists, strings, string builders, etc).

for some reason I've always felt a bit scared of that module

Looking over it now, honestly I don't know why. I think I'm still stuck in the past when it was part of ceylon.io and a bit of a mess. Right now it looks like it offers a whole lot of functionality quite cleanly. I think the only thing it's really missing is some proper examples in the module-level (and package-level?) documentation.
The main problem is that there are no code examples anywhere of how to use a Buffer, a Codec, or an IncrementalCodec. (Also I don't understand the design of Charset.)

So, look, unless someone wants to speak up in favor of adding this in the form it is currently implemented (a way to get from Strings to Array<Character>a and vice versa, with no real support for streaming or buffering), I'm going to drop it for now. I've removed it from the 1.4 milestone.

While I think it IS a core feature to be able to transform between characters and bytes, I'm a bit divided on this.. At least I think the ceylon.buffer would perhaps be the suggested way (for developers) to do it and the most performant implementation would be available there. But the flexibility and natural feel of Ceylon also imo speaks for having support in the Character class, with a note that "this is slow, but still, here you go".

.. but from api quality perspective perhaps don't rush the implementation into existence either..

But the flexibility and natural feel of Ceylon also imo speaks for having support in the Character class, with a note that "this is slow, but still, here you go".

I'm not sure that Byte(s) -> Character really works, since until you perform most of the decoding work, you don't know how many bytes are necessary to form a Character. Instead, I think you would usually 1) decode an entire "document" at once into a String, or 2) decode a stream of bytes in chunks with a stateful decoder.

Folks I already gave up on doing it at the single Character level after seeing how difficult it was to implement that efficiently in terms of Java APIs.

Ok then, I’ll be sure not to discuss this any more :)

Well, but we could still add it for Strings.

Honestly, I for one would be perfectly happy leaving this in ceylon.buffer.


Make asset_manager configurable

What problem does this solve or what need does it fill?
Integrating the Bevy engine into an existing app may be a common scenario, but in this scenario it is difficult for the user to manually initialize the ndk-glue because the ANativeActivity parameter cannot be provided and the ndk-glue is not initialized which causes AndroidAssetIo::load_path panic.
What solution would you like?
Since ANativeActivity is only used in bevy to get asset_manager:
let asset_manager = ndk_glue::native_activity().asset_manager()

Allowing asset_manager to be made available through configuration would give users more freedom.
Additional context
Scenario demo: bevy-in-app

ndk-glue will be removed in https://github.com/bevyengine/bevy/pull/6830

@mockersf Thank you for the link, I learned how to customize AssetIoPlugin from https://github.com/bevyengine/bevy/pull/6830, now solved the configuration issue of asset_manager.


Letsencrypt "Connection refused" after changing domainname.

Hi,
I was using docker-mailserver for months without issues (thanks!), but now I needed to modify my old domain name, so went into docker-compose.yml and replaced the old domain name with the new one, stopped than restarted the container using: "docker-compose up -d mail".
But now, I'm unable to generate new letsencrypt certificates using the bellow snippet (running it from the ~/mailserver/letsencrypt folder):
docker run --rm -ti -v $PWD/log/:/var/log/letsencrypt/ -v $PWD/etc/:/etc/letsencrypt/ -p 443:443 deliverous/certbot certonly --standalone -d mail.webx***.com
letsencrypt throws the following:
...
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for mail.webx***.com
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. mail.webxpert.click (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://mail.webx***.com/.well-known/acme-challenge/PHEMinEfz9nY88gXzaQnmY5FJM6RvlKdOlA4HckdNI4: Connection refused

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: mail.webx***.com
   Type:   connection
   Detail: Fetching
   http://mail.webx***.com/.well-known/acme-challenge/5hx234EUXkXxkv7bgJgUunJI-G1q3miDRjvOBzE_JEc:
   Connection refused

The A record exists for mail.webx***.com
I can send/receive test emails but without certificates

I have tackled with this all day but I can't figure out what the issue is. Is there maybe some other configuration or cache I need to delete/update?
I would really, really appreciate some help,
Thanks!
My config:
version: '2'

services:
  mail:
    image: tvial/docker-mailserver:latest
    hostname: mail
    domainname: webx***.com
    container_name: mail
    ports:
    - "25:25"
    - "143:143"
    - "587:587"
    - "993:993"
    volumes:
    - maildata:/var/mail
    - mailstate:/var/mail-state
    - ./config/:/tmp/docker-mailserver/
    - /home/ec2-user/mailserver/letsencrypt/etc/:/etc/letsencrypt/
    environment:
    - ENABLE_SPAMASSASSIN=1
    - ENABLE_CLAMAV=1
    - ENABLE_FAIL2BAN=1
    - ENABLE_POSTGREY=1
    - ONE_DIR=1
    - DMS_DEBUG=1
    - SSL_TYPE=letsencrypt
    cap_add:
    - NET_ADMIN

volumes:
  maildata:
    driver: local
  mailstate:
    driver: local

@tomav I have figured it out. Certbot started with a http-01 ACME protocol challenges (so far never happened to me) to prove the domain, so I had to append -p 80:80 as well to the command from the docs:
docker run --rm -ti -v $PWD/log/:/var/log/letsencrypt/ -v $PWD/etc/:/etc/letsencrypt/ -p 80:80 -p 443:443 deliverous/certbot certonly --standalone -d mail.webx***.com


Making A toggle button instead of 2 buttons

Astro Info
UI/UX Issue

If this issue only occurs in one browser, which browser is a problem?
Chrome
Describe the Bug
The toggle button can be made to toggle between light mode and dark mode instead of using 2 buttons which will increase the user experience.
What's the expected result?
The toggle button can be made to toggle between light mode and dark mode
Link to Minimal Reproducible Example
NA
Participation

[X] I am willing to submit a pull request for this issue.

Hi @Kritika30032002 — I’m not sure exactly what you’re referring to. Could you provide some more information please?
In the Astro docs we use an <input type="radio"> for the theme toggle and in the blog tutorial we use a single <button>, so I haven’t been able to find somewhere where we use 2 buttons as you describe.

Assign this to me.

Hey Kritika, this is a topic to discuss about but I would rather stick with current implementation for theme toggling as it provides smooth accessibility and generally lets user know which theme they would prefer to use. If you bring this to the Discussions, maintainers there will let you know how this Issue can be proceeded

okay

Closing this issue now as we are keeping the current site as is, and migrating to Starlight soon and using its theme toggle implementation!


NonMaxSuppression maybe not correct

In armnn/src/backends/reference/workloads/DetectionPostProcess.cpp: NonMaxSuppression(): Line 80:
    for (unsigned int i = 0; i < numAboveThreshold; ++i)
    {
        if (outputIndices.size() >= numOutput)
        {
            break;
        }
        if (!visited[sortedIndices[i]])
        {
            outputIndices.push_back(indicesAboveThreshold[sortedIndices[i]]);
        }
        for (unsigned int j = i + 1; j < numAboveThreshold; ++j)
        {
            unsigned int iIndex = indicesAboveThreshold[sortedIndices[i]] * 4;
            unsigned int jIndex = indicesAboveThreshold[sortedIndices[j]] * 4;
            if (IntersectionOverUnion(&boxCorners[iIndex], &boxCorners[jIndex]) > nmsIouThreshold)
            {
                visited[sortedIndices[j]] = true;
            }
        }
    }

should be changed to:
    for (unsigned int i = 0; i < numAboveThreshold; ++i)
    {
        if (outputIndices.size() >= numOutput)
        {
            break;
        }
        if (!visited[sortedIndices[i]])
        {
            outputIndices.push_back(indicesAboveThreshold[sortedIndices[i]]);
            for (unsigned int j = i + 1; j < numAboveThreshold; ++j)
            {
                unsigned int iIndex = indicesAboveThreshold[sortedIndices[i]] * 4;
                unsigned int jIndex = indicesAboveThreshold[sortedIndices[j]] * 4;
                auto iou = IntersectionOverUnion(&boxCorners[iIndex], &boxCorners[jIndex]);
                if ( iou > nmsIouThreshold)
                {
                    visited[sortedIndices[j]] = true;
                }
            }
        }
    }

I think if visited flag set true, it should not be visited any more.
For example, if we put 10 ordered boxes into  NonMaxSuppression:
Step 1: Suppose Box 2/3/6/8 are suppressed by Box 1. Box 4/5/7/9/10 survived.
Step2:
Correct way:  We use Box 4 to suppress the survive boxes.
But current way: Box 4 may be suppressed by Box 2, even Box 2 is already suppressed by Box 1...

PS: TOPK is slow way for NMS. You can reference:
https://android.googlesource.com/platform/frameworks/ml/+/refs/heads/master/nn/common/operations/GenerateProposals.cpp: hardNmsMultiClass()

Hi @antkillerfarm,
thanks for the patch, I will have a look into this and test your proposal.
In case you are interested, for this specific change or for the future, here is our Contributor Guide: https://github.com/ARM-software/armnn/blob/master/ContributorGuide.md. In particular we need the Signed-Off-By line, and ideally instead of a pull request we'd use a Gerrit review.
Thank you very much!

These changes have been merged. Thanks for the contribution, Antkillerfarm!


Directly write / read sockaddr_in and sockaddr_in6 from direct memory

without JNI
Motivation:
We want to keep the amount of JNI as small as possible to reduce the
performance overhead now that we eliminated the overhead of the need of
it for syscalls.
Modifications:
Write / read sockaddr_in / sockaddr_in6 via PlatformDependent and so
eliminate the need for JNI
Result:
Less JNI and so less overhead for crossing the border.

While this is interesting for connect and accept as well I mostly did this to reduce the overhead for UDP / Datagram which   will be using this as well.

As said I'm more then happy about this, just one warn: PlatformDependent::XYZ calls are not intrinsified vs pure Unsafe ones so now it means we're at the mercy of C2 and the inlining depth; we save JNI but we could be hit by granular not inlineable short/long access cost, so...Just be sure that the inlining depth is short enough

@franz1981 yes I know ... that said this should be not a problem :)

@1Jo1 in epoll it does not really matter as we need to enter JNI anyway for the actual sys call


Message Edit Support.

This PR include:

Adds inline KordEventAdapter class, for unifying the Kord Events (MessageCreateEvent and MessageUpdateEvent).

Adds support for invocation of command on message edits.

Adds CommandCache for data transfer between first/prior run and current command invocation, with test and an example.

CommandCache is conservative in nature, i.e. it is only instantiated and stored into the cache when execution block in CommandBuilder.invoke(args...) {args..., cache -> } takes exactly one more parameter than args passed.

If caching is not registered in bot configuration (as bot { registerCommandCache() }), a ConstantDisabledCache (singleton) is provided.

Adds support for edit of argument (KordEventAdapter#read) if previously failed (with ArgumentResult.Failure) or filtered, with test.

Adds same inline reply as kord 0.7.x to the KordEvent, allowing ease to directly reply to the message on KordCommandEvent.

Few minor changes such as:

Extracted KordEvent#read to KordEventAdapter#read due to the frequent use of KordErrorHandler (which was instantiating anonymous object on each call), KordEvent#read is still present but is delegated to KordEventAdapter#read.

Refactor Arguments to use KordEventAdapter as their context.

Refactor PrefixRules to use KordEventAdapter as their context.

Migrates deprecated github action similar to kord

This is a lot of code to make sense of, so I'll just be writing up some questions about rationale as I go, if you don't mind:
KordEventAdapter

Why make KordEventAdapter inline at all? It's used in so many generic contexts, won't wrapping and unwrapping the object that many times not be a cause of performance issues instead of gains?
Why provide a constructor that accepts such a broad type of events when we only accept two?

CommandCache

Why use the Kord cache to store types from another project?
Why limit the storage of cached values to one?
When are CommandCache values removed from the cache?
Is such a weak type safety on the cache okay? There can be considerable time between storage and retrieval, won't this make debugging more difficult?
Why make the cache optional? What's the point of storing stuff if it's not consistently present on the next edit?

KordEventAdapter

Why make KordEventAdapter inline at all? It's used in so many generic contexts, won't wrapping and unwrapping the object that many times not be a cause of performance issues instead of gains?

Welp, I have to rethink about it. Making it non-inline seems a good idea here :)

Why provide a constructor that accepts such a broad type of events when we only accept two?

Flow<Event>.filterAndMapToAdapter() filters the events. Though I should have made the class non-inlined and with a private or internal constructor. There was no other way of wrapping though, since the Events we want to capture were completely different from each other since they don't have a common interface.
Maybe we can have more discussion on it to make it better?
CommandCache

Why use the Kord cache to store types from another project?

Welp, that's because kordx-commands-runtime-kord is an extension to kord.

Why limit the storage of cached values to one?

That's up to the user to decide, as the cache only stores the reference of the value. He / She may add List or any other type for his own convenience.

When are CommandCache values removed from the cache?

CommandCache is just an interface. Regarding KordCommandCache, it depends on Kord's cache configuration done by user, already linked to an example. As such if lruCache is used it will get removed if maxCapacity has reached and its access was the oldest, if used default cache it won't be removed till max capacity reached by the Map.

Is such a weak type safety on the cache okay? There can be considerable time between storage and retrieval, won't this make debugging more difficult?

I couldn't think of a better way than this, I firstly thought to provide a generic CommandCache but since the kord.cache seems  to capture each generic type as a concrete type I couldn't make use of it.
Maybe we can discuss it further to make it better?

Why make the cache optional? What's the point of storing stuff if it's not consistently present on the next edit?

When did cache became optional? It is conservative i.e. for the commands which takes an extra cache parameter. If invoke function has been called with exactly 1 more parameter than the arguments, then cache will always be given to that. While commands which does not need any caching can implicitly tell to not use cache for them at the compile time by taking no extra parameter in the lambda.

Maybe we can have more discussion on it to make it better?

I suggest making this a sealed class instead, we're needlessly introducing checks where the type system could help us instead. Additionally, making it sealed allows us to specialize the different types.

Welp, that's because kordx-commands-runtime-kord is an extension to kord.

I find this poor reasoning, we're depending on a cache of which we have no control in terms of implementation, we don't even know if the user enabled it.
If we are going to add this feature, we should manage our own implementation instead.

That's up to the user to decide, as the cache only stores the reference of the value. He / She may add List or any other type for his own convenience.

This sounds completely insufficient.

CommandCache is just an interface. Regarding KordCommandCache, it depends on Kord's cache configuration done by user, already linked to an example. As such if lruCache is used it will get removed if maxCapacity has reached and its access was the oldest, if used default cache it won't be removed till max capacity reached by the Map.

This highlights another problem I brought up, if we're using a LRU cache then we cannot guarantee the value to be present. If we try to guarantee the message to be present then we end up with a de facto memory leak.

When did cache became optional?

It's optional because it does not guarantee being present in the next edit invocation.

Maybe we can discuss it further to make it better?

CommandCache is a misnomer, it's not a cache for commands, it's a way to retain information between invocation of the same command coming from a common source. The concept doesn't translate to non-fora environments. You cannot edit command invocations in a CLI, HTTP call, etc. So if (and when) we support those targets the feature would be dead weight.
To be honest, the whole feature seems to be contrived. The current concept is lacking is both implementation and features. Additionally, this seems trivially easy to introduce by the user themselves. via DI and metadata.
Personally I'd scrap the idea.

This sounds completely insufficient.

:(
I mean different command has different purpose, some commands (like for some searching) may only cache the Message or the id of message and channel, some may require caching of previous response and so on.

It's optional because it does not guarantee being present in the next edit invocation.

Yes, if the message is like way older and not in cache then bot should just treat it as a new invocation. We cannot store infinite cache in the system, if it doesn't allow to.

You cannot edit command invocations in a CLI, HTTP call, etc. So if (and when) we support those targets the feature would be dead weight.

Yeah 😅, I have to rethink about this later some day. For now I'm closing this :)


Eldritch Smite Soft Locks on Gargantuan Creatures

Solasta Version: 1.5.94
UB Version: <IP_ADDRESS>
Description: When using Eldritch Smite on a gargantuan creature, game soft locks.
Reproduce: Have Eldritch Smite, hit gargantuan creature, use Eldritch Smite, Game soft locks.
Expected: Damage from attack, damage from Eldritch Smite, damage from other sources, enemy NOT knocked prone.
Save File:
AutoSave_1.zip
Character in question has both Smite and Eldritch Smite is the first one to go in initiative. Tested with basic warlock on other various gargantuan creatures. Still does not work correctly on those either.
Note: Eldritch Smite works as expected on Huge or smaller creatures immune to the prone condition.

If whoever is working on it has questions, go ahead and ping/@ me on discord (Pikachar) and i'll try to do what I can to answer anything.

BTW, that save file throws multiple errors on load and correct character was last to act.

Good to know.  I should probably just do a reinstall of both the mod and the game just to get a clean slate then.


[feature] Add config options: skip typing generation, skip missing docstring generation

As per the title, it would be great if there were options to configure the output more precisely.
Specifically, it would be nice to skip generating type keywords like :type: and :rtype:. They are kind of redundant when there is typing information already in the code, and can cause issues if the docstring and typing are not in sync.
Further, it would be nice to not generate new docstring for methods, functions, etc. as it can override docstrings from abstract classes.

I do not see why it can actually overwrite docstrings from abstract class specifically and I would be happy to have a short example of python file that fools the module... But anyway, in version 0.7.1 you have the option to prevent the missing docstring automatic generation. You also have the possibility to prevent type hinting. Try --noadd and --notype options in command line ;)

I'm closing this issue for the time being as the request has been processed. If you had a docstring overwriting problem, I encourage you to make an other issue. I've actually had quite a few similar problems in my tests when detecting docstring in some tricky cases that led to overwriting but I thought I'd sorted that out...

It won't overwrite the actual docstring, but many IDE's use the docstring from the abstract method if the implementation does not have one.
We have this tool that needs to handle a number of different databases, and while each of the handler classes has a different behaviour in the background, they implement the same abstract methods and return the same objects. Copying the same docstring over and over would just lead to us forgetting to update them when/if the abstract method changes, so we leave the implementations empty.

Ok interesting!


Integrated terminal unable to determine cwd on launch

VSCode Version: 1.32.0-insider
OS Version: 10.14.3

Steps to Reproduce:

Was using fisher v2, update to fisher v3 via curl https://git.io/fisher --create-dirs -sLo ~/.config/fish/functions/fisher.fish
Restart VSCode

I'm not sure how reproducible this error is because it seems like a rather narrow use-case. On load, the terminal's working directory defaults to /, however, ls lists the default cwd for VSCode, which is ~/Sites. I am though, unable to navigate within my ~/Sites because the pwd is indeed /.

Does this issue occur when all extensions are disabled?: Yes

I tried clean uninstalling vscode and reinstalling but that did not fix the problem.

Does this issue occur if you remove/uninstall your prompt and use something else or the fish shell default prompt?

Happening to me as well. The combo of fish + omf + vscode seems to not be working. Only broken with the vscode terminal though, works fine in Terminal and Hyper.

No issue if I revert to bash. However, after I encountered the issue, even removing fisher and just using fish shell alone did not fix the problem.

@huijing Yeah, the issue must be somewhere in your VSCode configuration.

I'm seeing the same issue but this occurred when I updated fish from 3.0.0 to 3.0.1. I was already using fisher 3. Now every time I open the terminal the cwd is /.

It could be fish too, now that it seems more than one person is having this issue. I suggest affected users ask in the official gitter channel too.

This is https://github.com/fish-shell/fish-shell/issues/5647.

Workaround that I'm using for now:
{
    "terminal.integrated.shell.linux": "/bin/bash",
    "terminal.integrated.shellArgs.linux": ["-c", "exec fish"]
}

fish 3.0.2 with the fix is released (https://github.com/fish-shell/fish-shell/issues/5671) and available in Homebrew. It works for me.

I can also verify 3.0.2 resolves the problem. I will close this issue now.


The api_id/api_hash combination is invalid

The api_id/api_hash combination is invalid
my api not working even if the credentials are correct

https://github.com/GentlemanHu/TelegramForwarder/blob/f2ca9d7b832a8d197413a306648d9239aa68876a/config.py#L10
you can manually configure it in config.py.
I will fix the env loading bug later.

fixed


Propagate content type for pubsub data.

Description
Propagate content type for pubsub data.
Issue reference
We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.
Please reference the issue this PR will close: #2080
Checklist
Please make sure you've  completed the relevant tasks for this PR, out of the following list:

[X] Code compiles correctly
[ ] Created/updated tests
[X] Unit tests passing
[ ] End-to-end tests passing
[ ] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Specification has been updated / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Provided sample for the feature / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

/ok-to-test

/ok-to-test


184097170-Add-Panos-GPG-key

Description:

Add Panos GPG key

🚨⚠ Please do not merge this pull request via the GitHub UI ⚠🚨

GPG key is already in file so closing this PR.


Update for lodash v4. compatibility

Modifications to support lodash v4.

‘this’ can’t be passed as the final argument in things like _.each,
and must instead be bound explicitly via _.bind.
‘invoke’ is now ‘invokeMap’, but underscore lacks ‘invokeMap’. To run
with both underscore and lodash, convert to an _.each loop.
‘contains’ is now ‘includes’. As underscore has ‘includes’ as an
alias for ‘contains’, convert to ‘includes’.

Ha. I swapped these out a couple years back (#157) because I like the 3rd arg style a bit more.
I don't really like the rest of the lodash changes either as I think they make the code harder to read, but thanks for going through this and cleaning up places.
Finally, I think we're at the point where we can use Function.prototype.bind instead of _.bind. We can also use the old var self = this or var _this = this pattern instead of bind, which I think uglies up the code.

Well, so far as bind vs. _.bind vs self, doesn't much matter to me. However, since you "don't really like the rest of the lodash changes either", that's pretty much a nonstarter, so probably best just to close the PR.

No I mean I don't much like the changes JDD has made. But if this helps people with compatibility happy to merge in. Wanna tweak the minor fixes and then we can :shipit:

JDD's ways are such a mystery to us all.
So I think this nets out to replacing all the _.bind calls with native bind, which seems to affect only IE8 types, which seems like acceptable losses. All straightforward changes but for the 'destroyFns' loop, which I need to get my head around -- suggestions welcome on that one.

Sure, that sounds reasonable.
Forget my second point, I got confused :)

Changed to use native bind().


Remove proto distance request

You can also nuke src/main/java/com/traveltime/sdk/dto/requests/protodistance


Support datatype and language

Overview

Refactors the "property" and "backlink" interfaces, now renamed to "OutgoingTriple" and "IncomingTriple" respectively.
The main difference is that there is no more property "type", but the object of the property is now an object (instead of a string) that adheres closely to the RDFjs Term interface.
There are 6 types of objects for outgoing triples:

Literal
NamedNode
BlankNode (with limited support)
ContentLiteral
ResourceNode
LiteralNode

and 2 for incoming triples:

ResourceNode
LiteralNode

which should be pretty self-explanatory.
In particular, Literal, LiteralNode and ContentLiteral objects now also have datatype and language attributes, again analogous to the rdfjs interfaces (this is of course the main reason for the PR).
These attributes are now also parsed and serialized correctly.
To support this, there is also a major overhaul included of the add/edit modals for both "properties" and "relationships". I've kept the separation still in the UI.
For this, I made a generic form that can handle all types of outgoing properties.
Additionally, cause I needed some validation anyway, I went ahead and added the yup validation library, along with schemas for each of the object types, and even a custom curie validator for predicates, namednode object values, and datatypes.
Was this a smart time to do this? absolutely not. But I fell in the form rabbithole and couldn't get out. At least it will prevent us from chasing down bugs arising from invalid RDFA values. And I did enjoy using the library, it's very well typed and has a good set of builtin validators, and has builtin support for async validation.
As a bonus, it is now also possible to edit relationships.
connected issues and PRs:

Setup

How to test/reproduce

Challenges/uncertainties

Checks PR readiness

[x] npm lint

It seems that 'content-literals' are not correctly serialized/parsed. Content-literals are reparsed as normal literals.

yep working on it, cheers

still issues with linking to literalNodes

Screencast from 2024-01-26 15-33-36.webm Found another bug with the datatype parsing/serialization.

on ti

@elpoelma should be fixed now

The issue seems solved indeed :)

After a reload, the backlink contains both a language and a datatype property.
When loading the RdfaTest sample document, the outgoing title links have the datatype http://www.w3.org/2001/XMLSchema#string (even if these do not occur in the source document). After a reload they are gone.

no idea where those string types come from
I'm assuming the parser adds them as defaults, ill look into it tomorrow

no idea where those string types come from I'm assuming the parser adds them as defaults, ill look into it tomorrow

It seems so: https://www.npmjs.com/package/rdf-data-factory#creating-literals

I tested with a few other data-factory packages (@rdfjs/data-model and graphy) and they gave the same results. So the default http://www.w3.org/2001/XMLSchema#string seems to be following spec (as well as the default langString datatype when a language is provided)

What if we take the following approach?:

When a literal/content-node has a language => set the datatype always to xml:langString.
The user can only set the language of a literal property when the datatype is set to xml:langString; or if the datatype is empty (in this case we implicitly set the datatype to xml:langString. => we disable the language input-element if datatype is other than xml:langString/empty.
When creating a new literal property, prefill the datatype with xml:string; or leave it empty and implicitly set the datatype  to xml:string when no other datatype is provided and no language is provided.

This way we still follow spec (default datatype of xml:string or xml:langString in case of provided language), if another datatype is provided, do not allow the language attribute.

so what I ended up doing was just using a proper datafactory implementation: https://github.com/rubensworks/rdf-data-factory.js
I also updated the types to be more in line with rdfjs, and another small tweak to the IncomingTriple interface to be more consistent as well
I still see a problem with resourcenodes that multiple links to literals on the same predicate, but with different language/datatypes. I don't think thats a regression from these latest commits, I think that's been broken from the beginning. I have an idea where to look but ill do that tomorrow

I didn't do anything clever in the form, it just shows language if there and datatype if not
I'm relying on the parser to properly ignore language if there is a datatype attribute
I also updated the serializer to prioritize language for that reason
It's a bit mind-bending to think about cause it seems like the opposite of the rdfa spec but it works out in the end.


Remove remnants of separate count calculation

There are still come code parts that refer to the count calculation, causing errors when trying to run the GGIR part of HabitusGUI.

closing, because this is a HabitusGUI repo issue


Slow Embeddings With Ollama

Checked other resources

[X] I added a very descriptive title to this issue.
[X] I searched the LangChain documentation with the integrated search.
[X] I used the GitHub search to find a similar question and didn't find it.
[X] I am sure that this is a bug in LangChain rather than my code.
[X] The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

Example Code

from langchain.document_loaders import PyPDFDirectoryLoader
from langchain.embeddings.ollama import  OllamaEmbeddings
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_chroma import Chroma
import tqdm
print('done loading imports')

def main(args):

    # Get the directory path from arguments
    directory_path = args.directory

    loader = PyPDFDirectoryLoader(directory_path)
    print('loading docs')
    docs = loader.load()

    splitter = RecursiveCharacterTextSplitter(chunk_size=400,chunk_overlap=200)
    print('splitting docs')
    splits = splitter.split_documents(docs);

    embedAgent = OllamaEmbeddings(model='llama2',show_progress=True)
    print('generating embeddings')

    vectStore = Chroma.from_documents(documents=splits,embedding=embedAgent,persist_directory=directory_path)

import ollama

def testOllamaSpeed(args):
    # Get the directory path from arguments
    directory_path = args.directory

    loader = PyPDFDirectoryLoader(directory_path)
    print('loading docs')
    docs = loader.load()

    splitter = RecursiveCharacterTextSplitter(chunk_size=1000,chunk_overlap=200)
    print('splitting docs')
    splits = splitter.split_documents(docs);

    txts = []

    print('making txt')
    for doc in tqdm.tqdm(docs):
        txts.append(str(doc))

    print('making embeddings')
    mbeds = []
    for txt in tqdm.tqdm(txts):
       mbeds.append(ollama.embeddings(model='llama2',prompt=txt))

if __name__ == '__main__':

    # Create the argument parser
    parser = argparse.ArgumentParser(description="Script to process a directory path")

    # Add the -d argument for directory path
    parser.add_argument('-d', '--directory', type=str, required=True, help='Path to the directory')

    # Parse the arguments
    args = parser.parse_args()

    #main(args)
    testOllamaSpeed(args)

Error Message and Stack Trace (if applicable)
n/a
Description
Calls to Ollama embeddings API are very slow (1000 to 2000ms) . GPU utilization is very low. Utilization spikes 30% - 100% once every second or two.  This happens if I run main() or testOllamaSpeed() In the example code. This would suggest the problem is with Ollama. But If I run the following code which does not use any langchain imports each call completes in 200-300ms and GPU utilization hovers at a consistent 70-80%. The problem is even more pronounced if I use mxbai-embed-large with the example code taking 1000 to 2000ms per call and the code below taking ~50ms per call. VRAM usage is never above 4ish GB (~25% of my total VRAM).
For reference my environment is:
Windows 11
12 Gen i9-1250HX
128GB RAM
NVIDIA  RTX A4500 Laptop
16GB VRAM
Ollama 0.1.38
import ollama
import os
import PyPDF2
import tqdm
import argparse

def read_pdfs_from_directory(directory_path):
    pdf_texts = {}

    for filename in os.listdir(directory_path):
        if filename.endswith('.pdf'):
            file_path = os.path.join(directory_path, filename)
            pdf_texts[filename] = read_pdf(file_path)

    return pdf_texts

def read_pdf(file_path):
    pdf_text = ""

    with open(file_path, 'rb') as file:
        pdf_reader = PyPDF2.PdfReader(file)
        for page_num in range(len(pdf_reader.pages)):
            page = pdf_reader.pages[page_num]
            pdf_text += page.extract_text()

    return pdf_text

def split_into_chunks(input_string, chunk_size):
    # Use list comprehension to create chunks of the specified size
    chunks = [input_string[i:i+chunk_size] for i in range(0, len(input_string), chunk_size)]
    return chunks

def main(args):

    dir = args.directory

    print('Reading pdfs')
    allFiles = read_pdfs_from_directory(dir)

    print('chunking')
    chunks = []
    for k,v in allFiles.items():
        chunks.extend(split_into_chunks(v,1000))

    print('Generating embeddings')
    for chunk in tqdm.tqdm(chunks):
        ollama.embeddings(model='llama2',prompt=chunk)
        #ollama.embeddings(model='mxbai-embed-large',prompt=chunk)
    print('done')

if __name__ == '__main__':

    # Create the argument parser
    parser = argparse.ArgumentParser(description="Script to process a directory path")

    # Add the -d argument for directory path
    parser.add_argument('-d', '--directory', type=str, required=True, help='Path to the directory')

    # Parse the arguments
    args = parser.parse_args()

    main(args)

System Info
langchain==0.2.0
langchain-chroma==0.1.1
langchain-community==0.2.0
langchain-core==0.2.0
langchain-text-splitters==0.2.0

Yes, I faced a similar situation since Ollama does not support concurrency. To overcome this issue, I started multiple containers of Ollama and distributed the embedding requests across the containers in a round-robin manner.

Maybe OllamaEmbeddings can be more performant by concurrently calls to ollama server? llama supports concurrent request since a few versions ago, but langchain OllamaEmbeddings is not using it.


Added 96x96 and 128x96 display support

Added support for 96x96 and 128x96 display support
Level bottom tile row is duplicated for bottom out of screen area
Faster clear HUD background method
96x96 demo: https://youtu.be/cqxtg_TaXj0

Better fork this into a version for other devices ...

Hi MrBlinky,
I'm writing this post you in order to learn something more about 96x96 screen, I bought the screen with IC SSD1329 as same as you mentioned "https://youtu.be/cqxtg_TaXj0", because of its retro look. you connected succesfully, but I can not. Board of screen has GND, 3V3, RS, MOSI, SCK, CS terminals and D/C is missing.
Could you help/share schematic the connections of 96x96 screen and arduino.
I used different screens my modified arduboy (I made my own, If you interest, I can summerize later, keywords: sd card arduboy and gamebuino games "2in 1", different screens, IR remote game pad etc.)
Thanks for your help.
Fatih ONCUL
email<EMAIL_ADDRESS>


Detect more than one error

Hi!
I wanted to use rstcheck to get warnings in my rst files, but rstcheck currently returns only the first found error, does not try to process the whole document. Is this intended or a misconfiguration?
*******
Chapter
*******
Section
====
.. code::
The example should return 2 errors (1. underline to short, 2. missing content-block)

I can reproduce the issue on CLI and as plugin in VSCode.

I figured it out. There was an option I set in the closing commit to not halt on an error.


agrep: fix build failure

changed to compile option '-ansi' and patched Makefile
Description of changes
agrep failed to build on the all platforms. It needs to be built with C89 and Unix target, so I added a patch file to the Makefile and changed the compiler cc to gcc ansi.
I also added myself to its maintainers, as it is no longer maintained by anyone.

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[x] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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


Missing parameter was causing error in instance detail

Missing parameter was causing error in instance detail

ag 'count_only_or_objects[^(]*\((?!count_only)' seems to agree that this is the only place where it's missing.. :)

This was introduced in #11139


[qt5-base:x64-windows, qt5-base:x86-windows] build failure

Host Environment

OS: Windows 10 Pro, Version 20H2 (OS build: 19042.804 Experience: Windows Feature Experience Pack 120.2212.551.0)
Compiler: revision

To Reproduce
Run the below command line from a fresh vcpgk installation root (although the below output is with all dependencies installed):
PS C:\src\vcpkg> .\vcpkg.exe install --triplet=x64-windows qt5-base
Failure logs

Command line output
PS C:\src\vcpkg> .\vcpkg.exe install --triplet=x64-windows qt5-base

Computing installation plan...
warning: vcpkg appears to be in a Visual Studio prompt targeting x86 but is installing packages for x64-windows. Consider using --triplet x86-windows or --triplet x86-uwp.
The following packages will be built and installed:
    qt5-base[core]:x64-windows -> 5.15.2#1
Detecting compiler hash for triplet x64-windows...
Could not locate cached archive: C:\Users\osksod\AppData\Local\vcpkg\archives\12\1248760b6d03d65046b2c865036d6a2eb4f08d87.zip
Starting package 1/1: qt5-base:x64-windows
Building package qt5-base[core]:x64-windows...
-- Figuring out qt target mkspec. Target arch x64
-- Target mkspec set to: win32-msvc
-- Host mkspec not set. Qt's own buildsystem will try to figure out the host system
-- Using cached C:/src/vcpkg/downloads/qtbase-everywhere-src-5.15.2.tar.xz
-- Cleaning sources at C:/src/vcpkg/buildtrees/qt5-base/src/5.15.2-70178539f6.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source C:/src/vcpkg/downloads/qtbase-everywhere-src-5.15.2.tar.xz
-- Applying patch patches/winmain_pro.patch
-- Applying patch patches/windows_prf.patch
-- Applying patch patches/qt_app.patch
-- Applying patch patches/gui_configure.patch
-- Applying patch patches/icu.patch
-- Applying patch patches/xlib.patch
-- Applying patch patches/egl.patch
-- Applying patch patches/zstdd.patch
-- Applying patch patches/mysql_plugin_include.patch
-- Applying patch patches/mysql-configure.patch
-- Applying patch patches/Qt5BasicConfig.patch
-- Applying patch patches/Qt5PluginTarget.patch
-- Applying patch patches/create_cmake.patch
-- Applying patch patches/Qt5GuiConfigExtras.patch
-- Using source at C:/src/vcpkg/buildtrees/qt5-base/src/5.15.2-70178539f6.clean
-- Using msys root at C:/src/vcpkg/downloads/tools/msys2/50864d9fae363d6e
-- Configuring x64-windows-dbg
-- Configuring x64-windows-dbg done
-- Configuring x64-windows-rel
-- Configuring x64-windows-rel done
-- Building x64-windows-dbg
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:144 (message):
    Command failed: C:/src/vcpkg/downloads/tools/jom/jom-1.1.3/jom.exe /J 5
    Working Directory: C:/src/vcpkg/buildtrees/qt5-base/x64-windows-dbg
    See logs for more information:
      C:\src\vcpkg\buildtrees\qt5-base\build-x64-windows-dbg-out.log
      C:\src\vcpkg\buildtrees\qt5-base\build-x64-windows-dbg-err.log

Call Stack (most recent call first):
  ports/qt5-base/cmake/install_qt.cmake:92 (vcpkg_execute_build_process)
  ports/qt5-base/portfile.cmake:348 (install_qt)
  scripts/ports.cmake:133 (include)

Error: Building package qt5-base:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: qt5-base:x64-windows
  Vcpkg version: 2021-01-13-768d8f95c9e752603d2c5901c7a7c7fbdb08af35

PS C:\src\vcpkg> .\vcpkg.exe install --triplet=x86-windows qt5-base
PS C:\src\vcpkg> .\vcpkg.exe install qt5-base
Computing installation plan...
The following packages will be built and installed:
  qt5-base[core]:x86-windows -> 5.15.2#1
Detecting compiler hash for triplet x86-windows...
Could not locate cached archive: C:\Users\osksod\AppData\Local\vcpkg\archives\b6\b666a8f8b2245397d2e0b897585137f42ea5f1a0.zip
Starting package 1/1: qt5-base:x86-windows
Building package qt5-base[core]:x86-windows...
-- Figuring out qt target mkspec. Target arch x86
-- Target mkspec set to: win32-msvc
-- Host mkspec not set. Qt's own buildsystem will try to figure out the host system
-- Using cached C:/src/vcpkg/downloads/qtbase-everywhere-src-5.15.2.tar.xz
-- Cleaning sources at C:/src/vcpkg/buildtrees/qt5-base/src/5.15.2-70178539f6.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source C:/src/vcpkg/downloads/qtbase-everywhere-src-5.15.2.tar.xz
-- Applying patch patches/winmain_pro.patch
-- Applying patch patches/windows_prf.patch
-- Applying patch patches/qt_app.patch
-- Applying patch patches/gui_configure.patch
-- Applying patch patches/icu.patch
-- Applying patch patches/xlib.patch
-- Applying patch patches/egl.patch
-- Applying patch patches/zstdd.patch
-- Applying patch patches/mysql_plugin_include.patch
-- Applying patch patches/mysql-configure.patch
-- Applying patch patches/Qt5BasicConfig.patch
-- Applying patch patches/Qt5PluginTarget.patch
-- Applying patch patches/create_cmake.patch
-- Applying patch patches/Qt5GuiConfigExtras.patch
-- Using source at C:/src/vcpkg/buildtrees/qt5-base/src/5.15.2-70178539f6.clean
-- Using msys root at C:/src/vcpkg/downloads/tools/msys2/50864d9fae363d6e
-- Configuring x86-windows-dbg
-- Configuring x86-windows-dbg done
-- Configuring x86-windows-rel
-- Configuring x86-windows-rel done
-- Building x86-windows-dbg
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:144 (message):
  Command failed: C:/src/vcpkg/downloads/tools/jom/jom-1.1.3/jom.exe /J 5
  Working Directory: C:/src/vcpkg/buildtrees/qt5-base/x86-windows-dbg
  See logs for more information:
    C:\src\vcpkg\buildtrees\qt5-base\build-x86-windows-dbg-out.log
    C:\src\vcpkg\buildtrees\qt5-base\build-x86-windows-dbg-err.log

Call Stack (most recent call first):
ports/qt5-base/cmake/install_qt.cmake:92 (vcpkg_execute_build_process)
ports/qt5-base/portfile.cmake:348 (install_qt)
scripts/ports.cmake:133 (include)

Error: Building package qt5-base:x86-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
Package: qt5-base:x86-windows
Vcpkg version: 2021-01-13-768d8f95c9e752603d2c5901c7a7c7fbdb08af35

Additionally, attach any relevant sections from the log files above.

Log files:
build-x64-windows-dbg-err.log
build-x64-windows-dbg-out.log
build-x86-windows-dbg-err.log
build-x86-windows-dbg-out.log

Error 2 indicates a file not found error. The logs don't tell anything else so I would assume either you are running low on HDD space or your Virus protection removed moc.exe

Error 2 indicates a file not found error. The logs don't tell anything else so I would assume either you are running low on HDD space or your Virus protection removed moc.exe

So moc.exe was indeed missing from C:\src\vcpkg\buildtrees\qt5-base\x64-windows-dbg\bin however it is still present in C:\src\vcpkg\buildtrees\qt5-base\x86-windows-dbg\bin but if the virus protection caused this then it might have messed up other things. Here is the output from ls -Force -Recurse -Name .\qt5-base\
qt5-base-files.txt
Though I guess it also shows that the issue with build qt5-base:x86-windows is different from when trying to build qt5-base:x64-windows. Please tell me if I should open a separate issue edit this one in any way.
There should not be any issue with space unless qt5-base requires more than 400gb.

OK, so new day and a new attempt to install in case there is a difference and lo and behold, qt5-base:x86-windows installs without trouble today. I still get the same errors when trying to install qt5-base:x64-windows though moc.exe is no longer missing in C:\src\vcpkg\buildtrees\qt5-base\x64-windows-dbg\bin

@Natr1x Please note that any generated unsigned binary may be blocked by anti-virus.


[move source language] Add aliasing to spec contexts

Motivation

Spec functions and schemas added to a Modules set of module members

Implies implicit aliasing
Cannot conflict with function/struct/constant names

Added restriction to spec schema names (same as structs/constants)

Test Plan

new tests
cargo test

We could also perhaps add the list of builtin functions to this PR already, avoiding the need of the changes in libra_account.

Maybe there was some confusion. Adding a list of builtin functions could simplify some work on the move-prover side. But it would not change the behavior in libra_account.
The only thing that would change the behavior in libra_account is if you could do
use exists; // refers to the builtin exists
....

These builtin names are in the top level namespace, and can be shadowed in any inner name space. The same thing works for any other name-spacing layering. For example:
address 0x1 {
module M {
  fun foo() { ... }
  fun bar() { ... }
  fun baz() {
    use 0x1::M::bar as foo; // bar as foo shadows Self::foo as foo
    foo(); // resolves to Self::bar
  }
}
}

This works the same way in LibraAccount in that LibraAccount::exists shadows exists. You then need some new use to then reselect `exists into the current namespace

We could also perhaps add the list of builtin functions to this PR already, avoiding the need of the changes in libra_account.

Maybe there was some confusion. Adding a list of builtin functions could simplify some work on the move-prover side. But it would not change the behavior in libra_account.
The only thing that would change the behavior in libra_account is if you could do
use exists; // refers to the builtin exists
....

These builtin names are in the top level namespace, and can be shadowed in any inner name space. The same thing works for any other name-spacing layering. For example:
address 0x1 {
module M {
  fun foo() { ... }
  fun bar() { ... }
  fun baz() {
    use 0x1::M::bar as foo; // bar as foo shadows Self::foo as foo
    foo(); // resolves to Self::bar
  }
}
}

This works the same way in LibraAccount in that LibraAccount::exists shadows exists. You then need some new use to then reselect exists into the current namespace

It appears we had a misunderstanding. This is unfortunate but I'm OK to move forward with this.

@bors-libra r=wrwg

:pushpin: Commit 0971bfc has been approved by wrwg

:hourglass: Testing commit 0971bfcbdf3a7021ec43f2651f079985dd7b5a13 with merge 7e8d9de6270a85f8c13451c5c6689baf3c24a292...

@sblackshear @bob-wilson @tzakian
The sort of sticking point here after talking to @wrwg is whether or not we should keyword the builtins? The consequences of this are, should you be able to shadow the builtins.
Allowing shadowing can be confusing
It can be misleading and confusing when reading a module. E.g
module Confuse {
  resource struct R { }
  // no relation to real exists, shadows
  public fun exists(a: addr): u64 { 0 }
  // no relation to real move_to, shadows
  public fun move_to(_s: &signer, r: R) {
    R { } = r;
  }
  ...
  fun foo(s: &signer) {
    ::move_to(s, R {})
  }
}

If they were keyworded, you could have the wrapper but it would have to be named differently, i.e.
module LibraAccount {
  ...
  public fun exists_(a: address): bool {
    ::exists<Account>(a)
  }
  public fun has_account(a: address): bool {
    ::exists<Account>(a)
  }
}

Allowing shadowing can be helpful
All of the builtins for a module are private, so by creating public wrappers, you can "expose" the behavior. But it shadows the function internally. We do this in LibraAccount:
module LibraAccount {
  ...
  public fun exists(a: address): bool {
    ::exists<Account>(a)
  }
}

More generally you could imagine an all of the builtins (except the borrows) being exposed
module MyResource {
    resource struct MyResource { ... }

    public fun move_to(s: &signer, r: MyResource) {
        ::move_to(s, r)
    }

    public fun move_from(a: address): MyResource {
        ::move_from<MyResource>(a)
    }

    public fun exists(a: address): bool {
        ::exists<MyResource>(a)
    }
    ...
}

This might be natural in that situation we (@sblackshear  @tzakian) discussed where the module name might match up with the resource, i.e.the module has one key resource
The downside is you might want to add aliasing to help with certain cases, which makes the whole thing more confusing, e.g.
module LibraAccount {
  ...
  public fun exists(a: address): bool {
    ::exists<Account>(a)
  }

  public fun has_Foo_and_Bar(a: address): bool {
    use exists;
    assert(Self::exists<Account>(a), 42);
    exists<Foo>(a) && exists<Bar>
  }
}

I could see us going either way here. The key things to weigh are (1) How much are we concerned about the confusing aspect? (2) How useful do we think these same-name wrappers being?

:sunny: Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow
Approved by: wrwg
Pushing 7e8d9de6270a85f8c13451c5c6689baf3c24a292 to master...

I don't have a strong opinion on either part of the question, but I'm generally in favor of allowing shadowing of builtins. I see the potential for confusion, but for me, that is just an indication that we need to be careful to avoid using that ability in confusing ways.
How much of this discussion is being driven by the conflicting "exists" builtins for the Move language vs. the prover? I haven't been in the loop on all the discussions, but that's the impression I get. If so, maybe the solution is to rename one or the other (or both). Regardless of this issue, it seems like a bad idea to overload the same builtin name with different meanings in those different contexts.

Two thoughts:

I'm wondering why you are making builtins private to a module. This seems very unusual to me. If you do not want that an external module can say exists<OtherModule::R>(a), I would find it much more natural to just make this a special context condition. The error message would be much cleaner. If you want to "export" the ability to check for a module's resource, you should use a different, more abstract name. E.g. LibraAccount::account_exists_at(addr).
Or maybe I'm missing some other reason why you are doing this? Anyway, in most programming languages I know, builtins are either in some special namespace which is implicitly imported into each module (and not automatically re-exported), or they are hardwired in the syntax.

I think shadowing is something which should be avoided in "readable" source code as much as possible if it comes to global symbols. If a global symbol is ambiguous, qualification should be the preferred way to resolve this. I understand that "writing" code is easier with this feature, but in my opinion "reading" Move source code is the more important and frequent use case.


fix quentity_decoder issue

#95

Coverage increased (+0.001%) to 51.747% when pulling 8a2aeec6196970f81d4203b164e66200bffdbf99 on anton44eg:issue_95 into 34686396a933827a003d9487d54739a7947fcfd8 on ethereum:develop.

@anton44eg Could you please show the steps to reproduce the issue on the pyethapp? e.g. how do you start pyethapp and how is it configured?


Enumerate pages for ifetch website

All of the above seems pretty reasonable to me to be published as a tech blog on the ifetch website. Thanks for the background work conducted here, @pmoreirac

Created issues #49, #50 and #51 to review the article contents before pushing to the website.
@iFetch-chatbot/farfetch-ifetch-team


Avoid linefeed in /proc/self/coredump_filter

On Alpine Linux, the default shell is ash. To build .NET Core, we
explicitly install bash.
If we run the following command:
echo 0x3F > /proc/self/coredump_filter

in bash, it raises the exception:

echo: write error: Invalid argument

while with ask, it works fine.
Problem is that, when echo is run from bash, it adds a trailing
linefeed which kernel seems to reject.
Adding -n avoids adding the linefeed.
Original exception while building CoreRT:
chmod +x /corert/Tools/dotnetcli//dotnet
/corert/bin/Linux.x64.Debug/ILCompiler.DependencyAnalysisFramework.Tests/RunTests.sh: line 67: echo: write error: Invalid argument
/corert/Tools/dotnetcli//dotnet xunit.console.netcore.exe ILCompiler.DependencyAnalysisFramework.Tests.dll  -xml testResults.xml -notrait Benchmark=true -notrait category=nontests -notrait category=nonlinuxtests  -notrait category=OuterLoop -notrait category=failing

@jkotas, this together with https://github.com/dotnet/buildtools/pull/1688 are required to fix the error.

cc @sergiy-k

Thanks @janvorli! Could you please review dotnet/buildtools#1688, both of these changes were required to fix the echo error. :)


[Feature-request] Remove cursor

I would like the multi cursor to behave like this plugin - https://atom.io/packages/multi-cursor
This plugin allows to remove last created cursor by adding new cursor in oposite direction.
Exaple.
some text|
some text 2
some text 3

add cusor down
some text|
some text| 2
some text 3

add cursor dows
some text|
some text| 2
some text| 3

add cursor up
some text|
some text| 2
some text 3

add cursor up
some text|
some text 2
some text 3

this also works with ctrl - d command.

@alexdima Hey, could u please tell me - did I misunderstood? 20 thumbs up - and bot shoud move it to backlog?

Can anyone give bot some medicine please?

ping @JacksonKearl @chrmarti


feat ✨ : Add closeness centrality and floyd warshall feature

Hi, i'm marco, a students from the university of Bologna.
For my final project i want to contribute this repository adding the closeness centrality and the floyd warshall algorithms  for numpy.
The closeness centrality use the newly implemented floyd warshall.
The parallelized floyd warshall is a version of tiled FW referenced in the code.

@Fre0Grella nx-parallel algorithms receive a ParallelGraph object, so you need to convert it back to the nx.Graph object to run the usual graph object methods on it. That's why you'll see the following lines in all the nx-parallel algorithms
if hasattr(G, "graph_object"):
        G = G.graph_object

Hopefully this will make the tests pass.
Thanks!

@Schefflera-Arboricola Hi, thanks for the first advice, i hope you could help with this one too.
Running the test i got an error that i don't understand;
on the closeness.py file, when i use joblib Parallel to call the _closeness_measure function (that from a row of the adjacency matrix get the value of closeness for the node rappresented by the row) i get the error in the joblib code saying TypeError: 'numpy.float64' object is not callable.
I tried changing the data format thinking that joblib doesn't support numpy data structure but he kept saying in this case TypeError: 'float' object is not callable.

Hi @Fre0Grella, Thank you for your contribution :)
Is this PR ready for review? I will aim to get to it as soon as possible, though I cannot provide a specific timeline at the moment. I'm also tagging @dschult in case he would like to review it.
Additionally, could you let us know if there is a deadline for your final project and if this PR needs to be merged before then?
Thank you :)

Hi @Schefflera-Arboricola, the PR is ready for review although i aim to improve the performance further. The dead line of the project is due the 18 of September.
I doesn't need the PR to be merged before that

Thanks @Fre0Grella! I think instead of nxp.cpu_count using nxp.get_n_jobs would have fixed the failing CI tests because we renamed it recently. If you still have the bandwidth please feel free to merge the main branch again. Really sorry for the delayed review!

Thanks @Fre0Grella! I think instead of nxp.cpu_count using nxp.get_n_jobs would have fixed the failing CI tests because we renamed it recently. If you still have the bandwidth please feel free to merge the main branch again. Really sorry for the delayed review!

Not sure if i'm doing something wrong but replacing nxp.cpu_count to nxp.get_n_jobs isn't working. On the test i get AttributeError: module 'nx_parallel' has no attribute 'get_n_jobs'

All the tests are passing now and the style test should also pass once you update this PR branch with the recent fix that got merged. Thank you :)

It would be awesome if we can merge this PR before 1st of october so i can present the project directly from the NetworkX repository to the exam commision. Thanks a lot for the support along the project. I'm also interest in further contribuition to the NetworkX project

@Schefflera-Arboricola hey, the PR is ready to be merged, it only need a Review

@Fre0Grella -- I should mention (since I haven't yet) that this is excellent work. @Schefflera-Arboricola-- hopefully after the remaining polishing we can get this thing merged?


Nuxt initialization npm failure

Ubuntu Linux 22
Node v22.11.0
npm 10.9.0
npx nuxi@latest init app-demo
✔ Which package manager would you like to use?
npm
◐ Installing dependencies...                                                                                9:25:33 a.m.
npm error code EAI_AGAIN
npm error syscall getaddrinfo
npm error errno EAI_AGAIN
npm error request to<EMAIL_ADDRESS>failed, reason: getaddrinfo EAI_AGAIN r.cnpmjs.org
ERROR  Error: Command failed with exit code 1: npm install                                                                                11:37:59 a.m.
Only with  npm, yarn works fine, also npm on any other project initialization  be it vite with vue, or anything else, all works fine only npm with nuxt.
When installing a new package using npm on nuxt too, it keeps freezing and loading stops and never completes installation.
See also time from 9:25:33 a.m. to 11:37:59 a.m.
I have tried to  npm config set registry https://registry.npmjs.org/
npm config delete proxy and npm config delete https-proxy
but all to a deadend.

Haven't found a lot to help you. But this seems like rather a DNS issue than something related to nuxt ?
https://stackoverflow.com/questions/63010779/npm-err-code-eai-again-error-when-trying-to-install-express


How to create a BGP HA with shortest down time

This is actually a question.
setup:
I have setup Calico to advertise service IP using externalIP to the outside world.
The outside world BGP-peer is connected to two Calico BGP-peers.
The advertised IP service address appears on the outside BGP-peer and the route is via one of the Calico BGP peer IP address.
If the Calico BGP peer IP is down, the outside world BGP-peer detects in 3 seconds the unavailable Calico BGP peer and started to switch to the other to other Calico peer.
So this means that during 3 seconds the route is unavailable.
The 3 second is the lowest value that can be achieved, as it is configured in bird.conf on the outside world BGP-peer (hold time = 3 x keepalive_time see below).
For my application, I would like to have zero down time. How can I achieve this?
protocol bgp m0{
description "m0 bird";
hold time 3;
keepalive time 1;      # defaults to hold time / 3
local as 65000;
neighbor <IP_ADDRESS> as 64512;
source address <IP_ADDRESS>;   # What local address we use for the TCP connection
import all;     # Accept all prefixes from our neighbor
export none;    # Don't send the neighbor any prefixes
}
protocol bgp w0{
description "w0 bird";
hold time 3;
keepalive time 1;      # defaults to hold time / 3
local as 65000;
neighbor <IP_ADDRESS> as 64512;
source address <IP_ADDRESS>;   # What local address we use for the TCP connection
import all;     # Accept all prefixes from our neighbor
export none;    # Don't send the neighbor any prefixes
}

I think this has less to do with Calico and maybe more about BGP networking infra setup. If you have any more questions about this, join our Slack (https://calicousers.slack.com/) - perhaps another Calico user has looked into this area.


improve reduce logs from memtable memory limiter

Proposed changes
Print logs only if limit status changed or a certain amount of time (1s) elapsed.
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall