handleStateChange confusion around controlling isOpen

Problem description:
I'm trying to create a dropdown that contains a couple of choices that the user can select (a checkbox list one could say). It's basically a multiple select thingy.
So I wan't to keep the dropdown menu open while the user is interacting with it.
So, I know that I then have to to take "control" over the isOpen prop and supply that to downshift. That all works fine.
The issue that I'm facing is that if the user clicks outside the downshift component (the root component) the menu should close.
I found this piece of code in the example:
  handleStateChange = changes => {
    const {isOpen, type} = changes
    if (type === Downshift.stateChangeTypes.mouseUp) {
      this.setState({isOpen})
    }
  }

That seems to do the trick...but...for one it seems a little bit "complicated" (or how should I put it) and I really don't know why I need this and how it all works together.
Suggested solution:
Either better documentation about this type of situation or some other means to tell downshift that when the user clicks outside just close it, ignoring isOpen prop.
React Bootstrap has a prop called rootClose on its overlays that handles this for example.

Thanks for the issue @jole78, I knew we'd have to deal with this eventually.
Here's how things work... There are 4 parts of state in downshift: isOpen, highlightedIndex, selectedItem, and inputValue. We have an API that allows you to control the internal state of the component. When you're controlling any part of the state, then we need to only call setState for the parts of the state that downshift is controlling and we call onStateChange with anything that changed (whether or not it's controlled).
As noted above, when you control any state, we don't call setState internally and instead you're responsible for updating the state. In fact, we can't control any state that you're controlling or we'll get into really confusing situations. This is consistent with controlled form fields. Due to this fact, you need to make sure you update your own version of the state based on whatever criteria you determine. This is why onStateChange exists. It's suggestions to you. You can use the information to update your own state or not.
There are a lot of reasons state can change and it's not easily determinable without the type property on the changes object. The isOpen state in particular has at least 5 ways to change (probably more, I didn't actually check). So that's why the stateChangeTypes exists.
It's undocumented because I didn't love the API and most folks can get a long way without needing to know it exists. But I think that things have been around long enough to say that no better API will materialize and we can set this one in stone.

React Bootstrap has a prop called rootClose on its overlays that handles this for example.

Do they allow you to control the isOpen state like downshift does? I truthfully feel like this is a bit complicated because it's so powerful.
I'm thinking the solution is to simply document the stateChangeTypes and make it an official part of the API.
Happy to discuss alternative solutions.

@kentcdodds thx for the reply. It’s Friday night in Sweden so I’ll have to think this over and get back to you next week. Have a great weekend Kent.

@kentcdodds if I'm not misreading how React Bootstrap uses this they allow you to set rootClose on an overlay component and if you do you must specify an onHide event handler (that becomes a required prop). That usually involves you controlling the "show" prop on the overlay (via your state)...so yes, they allow you to control the isOpen state of the overlay. ref (https://react-bootstrap.github.io/components.html#overlays).
Is that perhaps a solution?? Something like you can set a prop on downshift (like rootClose or something) and then downshift will call your onHide event handler when that occurs withing downshift.
Truthfully I feel this code below forces me to know a little too much about the inner workings of downshift, as you also clearly agreed with...right?
    handleStateChange = changes => {
        const { isOpen, type } = changes;
        if (type === DownShift.stateChangeTypes.mouseUp) {
            this.isOpen = isOpen;
        }
    };

Another solution might be another stateChangeType which more clearly would indicate that the user clicked outside of the downshift component?

I can understand your concern. One thing that I want to avoid is adding a bunch of props to do things which can be done with what's already available.
However, I think this is a pretty common use case, so I'm willing to add a prop for an onOuterClick event handler which we would call here. The docs for onOuterClick would indicate that this is just a helper prop and the same could be accomplished using onStateChange.
I think the implementation should be quite simple. Just in time for hacktoberfest :wink:
Steps to solve:

Document the new prop in the README.
Test the new prop's functionality (probably easiest to just do it in downshift.misc.js).
Implement the new functionality by adding a prop type around here and calling it in the callback here (this.reset({type: Downshift.stateChangeTypes.mouseUp}, this.props.onOuterClick))

Please make sure to follow the CONTRIBUTING.md.
Thanks!

Note, first person to "claim" this issue by saying "I'm working on this right now" will have their PR iterated on and merged :)

I'm working on this right now

Looks fair enough. Saw that react-select has something similar called onClickOutside or something like that so it seems reasonable. Thx

Hey everyone, I've been playing around with Downshift and I realized that there may be a bug related to how onStateChange provides the wrong changeType if you have more than one Downshift component being rendered at the same time.
For example... I copied the provided 'Multiple Select' sample, and just made a modification by rendering an extra Downshift dropdown component below the first one.
With that said, when you click an item in the dropdown list, the changeType from onStateChange is now mouseUp ("autocomplete_mouseup"), when it should be something else (probably "autocomplete_controlled_prop_updated_selected_item"). Since it provides mouseUp here, the changes's isOpen property is false, and the dropdown state will be set to close.
Try it out for yourself here. https://codesandbox.io/s/8pywk9vo8
Any ideas how to resolve this?
  handleStateChange = changes => {
    const {isOpen, type} = changes
    if (type === Downshift.stateChangeTypes.mouseUp) {
      this.setState({isOpen})
    }
  }

https://codesandbox.io/s/0mq2y5wqrl

Yeah, that's a really odd thing you're doing there... I don't have the time to explain what's going on (someone else can take a crack at it if you want), but if you explain what you're trying to accomplish then maybe I can help you know how to do it properly...

Hi @kentcdodds. First of all, isn't the point of Downshift to also be a reusable component? It almost certainly is, except for this issue we're looking at. Then again, it is experimental...
Anyways, I'm trying to accomplish rendering a Downshift dropdown component in each accordion panel content of a Semantic-UI-React accordion. https://react.semantic-ui.com/modules/accordion#accordion-example-shorthand
Everything worked fine, until I wanted to essentially close a Downshift dropdown on blur, using this implementation:
  handleStateChange = changes => {
    const {isOpen, type} = changes
    if (type === Downshift.stateChangeTypes.mouseUp) {
      this.setState({isOpen})
    }
  }

This actually worked too for the first accordion panel. But when I started to add more than one accordion panels dynamically (with the Downshift dropdown component in the content of each accordion panel), then the bug occurs. I realized regardless of the accordion panels being open/closed, the content is always rendered but hidden in some way.
With that said I experimented further by just rendering two Downshift dropdown components next to each other and I also replicated the bug.
Earlier today, I was able to work around a fix for my situation by just rendering one of the Downshift dropdown components at a time based on the current active accordion. This way, no more than one Downshift component can be rendered at a time, working around the issue.
With all of that said, that's my story and how I came across this. :)

Ah, the problem is that you're sharing the isOpen state between the two. So if the first one collapses because I clicked on the second one, then they'll both collapse and that will happen before the second has a chance to select the item.
You can solve this by keeping the isOpen state separate. I suggest creating another component that's responsible for this state and renders the Downshift component, then you can render two versions of that component.
In any case, onOuterClick has been merged and released :tada: Thanks everyone!

@kentcdodds ah, duh... Thanks!  👍

@kentcdodds Found this issue to be useful; especially your rational for using handleStateChange.
So is it certain that the Downshift.stateChangeTypes will be an official part of the API? Or do you have an issue to gather consensus?

Yeah, I think we'll make the stateChangeTypes official. Anyone can feel free to make a pull request to document it.


Hans Mbua : Asynchronous Programming

Learning Objectives

[x] 🥚 You understand the JavaScript Event Loop and can demonstrate this by using setTimeout and setInterval to schedule simple tasks.
[x] 🥚 You can explain why Asynchronous Programming is important for programs that have blocking and non-blocking tasks.
[x] 🥚 You can explain the basics of the Client/Server model and HTTP requests and can fetch data from RESTful APIs.
[ ] 🥚 You can convert built-in Node modules from consuming callbacks being promises.
[x] 🐣 You can write and run JavaScript for Node.js or for the Browser. Both environments run JavaScript but they have some important differences!

[ ] use cases: You can explain some use cases that are unique to each runtime.
[ ] built-in APIs: You can list some of the key APIs available in each environment, and why they are not available in the other.
[ ] module systems: You can explain the difference between CommonJS Modules in Node.js and ES Modules in the Browser. You can write and use programs written with either system.

[x] 🐣 You can break down an asynchronous problem into smaller tasks and solve it using promises. This includes identify which tasks depend on each other and which are independent:

[ ] dependent tasks: The return value from one task is required to start the next task, these must be completed in a specific order - .then
[ ] independent tasks: These tasks do not use each other's return values, they can be completed at the same time - Promise.all

[x] 🐣 You can trace, refactor and write code that accesses the file system between these 3 different syntaxes:

[x] Callbacks

[x] Promises

[x] async/await

[ ] 🐣 You can step through a Node.js command-line application using the VSCode debugger.
[ ] You can write small programs with a Data Access layer that asynchronously uses data stored in different locations:

[ ] 🐣 Browser: You can write a small web page that fetches data from a RESTful API and renders it into the DOM.
[ ] 🐥 Node: You can write a small CLI program that reads user input from process.argv and reads/writes the file system.

Week 1, 2 and 3
Check-In
I Need Help With:
-

What went well?

Did some Exercise with my classmate Aviv and he made me understand how to go about the assignment

What went less well?
-

Lessons Learned

callBacks
Object Promise( )
interval: setTimeout and also setTimeInterval  which returns an ID that we can used to clear Interval on runtime

Sunday Prep Work

trying to finish off with the assignments


Bandainamco - It is duplicated on the website https://scrapers.peviitor.ro

ENVIROMENT: production
URL: https://scrapers.peviitor.ro
Browser: Chrome
Device: laptop
OS: Windows 11
STEPS TO REPRODUCE:

Open URL in browser
Search for "bandainamco" company
Check the names of the two folders listed, which are almost identical
Click on "bandainamcoent" folder
See that it has no logo, no link to the company's website and it has the same job as the "bandainamco" company
Go back to the previous page where the two folders are displayed
Click on "bandainamco" folder
See that the logo is ok, the link to the company's homepage is ok (https://www.bandainamcoent.ro/ro/careers/) and the same job is listed

EXPECTED RESULTS:
The company "bandainamco" appears only once after the search on the https://scrapers.peviitor.ro website
ACTUAL RESULTS:
The company "bandainamco" appears twice in the search on the https://scrapers.peviitor.ro website

Fixed!

Verificat! Este Ok acum!


Rename the reporter to AOSD2 to avoid confusion

Please have a look at the individual commit messages for the details.

Merging despite the unrelated ConanFunTest failure.


Increasing default page size for the connection type endpoint to 100

Closes #3297
Code Changes

[ ] Increased the default page size for the connection type endpoint to 100

Steps to Confirm

[ ] Verified through the Admin UI

Pre-Merge Checklist

[ ] All CI Pipelines Succeeded

@galvana this generally looked fine to me, but i thought it may be good to maintain the ability to allow for user-specified page/size params if desired. i know we don't use them now in the UI, but figured that sort of flexibility in an API never hurts. obviously the change to default to 100 as the page size needs to stay in place. https://github.com/ethyca/fides/pull/3298/commits/11c5b0375415f5ca2b1058d778d01a3cc11c0ffb should get us that functionality.
let me know if that looks alright to you! if it doesn't for whatever reason, perfectly happy to revert that commit.


Creating 'internal' users

Hi.
Thanks a lot for your provider.
Do you have any plans to write a resource for creating internal users?

@pcheliniy This feature is now available in v0.1.0
Cheers,
Brett Wright


CI: Update to cibuildwheel 2.20.0

cibuildwheel 2.20.0 uses the ABI stable Python 3.13.0rc1 and build Python 3.13 wheels by default.
Reference issue

#20992

I'll tentatively add a backport label if this is important for 3.13 support. Should we proceed with [wheel build] attempt?

This is fine to merge, but won't trigger a build in and of itself, as the [wheel build] is missing from the commit message.

[wheel build] is missing from the commit message.

Sorry, forgot indeed to add that.
I think a backport and a 1.14.1 release is an excellent approach to get Python 3.13 wheels on PyPI!


Version 1.1.2 breaks the parsing

Hi
The changes introduced in the 1.1.2 version breaks the old parsing mechanism.
Here you can find the example code:
<?php

use OviDigital\JsObjectToJson\JsConverter;

include 'vendor/autoload.php';

$input = '{sources:[],image:"http://<IP_ADDRESS>/sapsdvcx3kgq.jpg",duration:"3200",width:"100%"}';

var_dump(JsConverter::convertToJson($input));

Output with version 1.1.1:
string(91) "{"sources":[],"image":"http://<IP_ADDRESS>/sapsdvcx3kgq.jpg","duration":"3200","width":"100%"}"

Output with version 1.1.2:
string(30) "{"sources":[],"image:""http":""

                                 ^
                                 completly broken

I think the \OviDigital\JsObjectToJson\JsConverter::removeComments() is not production ready.

@kakaska thank you for reporting this. I will try to fix this today.

Thank you for fast response. Everything is working again with the new release.


Plumb the bug ID through to more of the log messages

Because the worker is threaded the log entries don't readily correlate with the bug ID logged earlier in the process, which makes manually following the processing of a bug in the logs more difficult.

Abandoning this approach in favour of https://github.com/google/osv.dev/pull/1430


allow cachedir override using env var

What does this do / why do we need it?
Allows to override the cache directory location using an environment variable(DEPCACHEDIR). Having the cache location depend on the gopath can negatively affect performance for anyone using multiple Go workspaces.
What should your reviewer look out for in this PR?
The source code change was simple enough but it was a bit challenging to write the tests. Please check if they look alright.
Do you need help or clarification on anything?
Tests.
Which issue(s) does this PR fix?
fixes #1066
Changelog

main - Read and use env var DEPCACHEDIR for instantiating dep context.
context

Add field Cachedir to struct Ctx. This holds the value of env var
DEPCACHEDIR.
Use Ctx.Cachedir while instantiating gps.SourceMgr if present, fallback
to $GOPATH/pkg/dep otherwise.

source_manager - Add a getter func Cachedir to facilitate testing in
context_test.go.
context_test - Add test to check gps.SourceMgr is instantiated with
appropriate cachedir.
integration_test - Add test to check environment variable DEPCACHEDIR is
loaded and used if present.

I am on a windows machine and the newly added tests were passing. However, the appveyor build failed while trying to git clone https://github.com/sdboyer/deptest. Does this happen often? Is there anything I would need to do to fix this?

appveyor tests can be pretty flaky, and network failures like that aren't uncommon. i kicked the test to rerun, but it revealed a new incompatibility that's popped up as a result of a push from a couple days ago, so you'll need to rebase and accommodate that change anyway.

@sdboyer I have rebased. However, I am not able to replicate the error on appveyor:
λ go test -run ^TestDepCachedir$ -v
=== RUN   TestDepCachedir
--- PASS: TestDepCachedir (0.40s)
PASS
ok      github.com/golang/dep   0.603s

ok, i'm gonna choose to think that whatever we saw was transient.
please update the CHANGELOG.md in the root of the repo - just a single line, consistent with the level of information recorded in other items there. then we can merge!

@sdboyer Do you think we should validate the value of env var DEPCACHEDIR? I could use the method described here - https://stackoverflow.com/questions/35231846/golang-check-if-string-is-valid-path

hmmm - fair point, that is definitely user input. yes, we should validate. the empirical approach there is fine - it'll also be a requirement to make sure that the directory exists in order for gps to work correctly with it, I think.

@sdboyer Wouldn't creating the directory, if it does not exist, make sense? I think it is a valid scenario where the user gives the dir as $HOME/.cache/dep.

@darkowlzz Small note, in the release notes for v0.3.2, the WIP section is also included which, IMHO, shouldn't be present in the release notes.

Rebased and resolved conflicts. Can we please merge this in? I can do the changes if any are required.

@sdboyer Could we move forward with this? The failure in CI is unrelated to changes in this PR as far as I can tell.

I'm still not back from vacation yet.
On November 11, 2017 7:43:45 AM GMT+01:00, Suhas Karanth<EMAIL_ADDRESS>wrote:

@sdboyer Could we move forward with this? The failure in CI is
unrelated to changes in this PR as far as I can tell.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/golang/dep/pull/1234#issuecomment-343645046

My apologies. Hope you enjoy your vacation 😄 .

ok, i'm back. thanks for your patience.
so, the only question i have at this point is re: the use of os.MkdirAll() instead of os.Mkdir() for creating the directory. my feeling - which is to say, not backed by clear research - is that most tools avoid recursively creating directories for situations like this. problem is, i can't put my finger on exactly what criteria constitute "like this," though i think it's probably related to the use of an env var or param for setting the topmost-level directory in which a tool then dumps a bunch of additional files.
i think i'd prefer we be more conservative initially with this, and use os.Mkdir(). we can always switch it to os.MkdirAll() later.

@sdboyer To be clear, I did not modify source_manager.go to add the MkdirAll. It was already there. If you are sure you want to change this to Mkdir, I can.

@sudo-suhas ah, i see.
yes, now that we're exposing a location for the cache dir, i'd prefer we use os.Mkdir() within source_manager.go. however, that's the second layer - there needs to be an earlier check, somewhere in dep, not gps, that the explicitly specified path exists, and attempt to os.Mkdir() if it does not.

@sdboyer It turns out this case is already handled by the empirical check for path validity. It tries to create an empty file in the given path which fails if the parent directory does not exist. However, I am not sure this is the right behavior for the function. Moreover, the error dep prints wouldn't be accurate in the case that the parent directory for given cache dir does not exist:
dep: $DEPCACHEDIR set to an invalid or inaccessible path: "C:\\non-existent-fldr\\cachedir"

I can handle the inaccurate errors with the following validation function:
func validateCachedir(cachedir string) error {
	if cachedir == "" {
		return nil
	}

	// We won't recursively create the directory. So check that the parent directory
	// exists.
	parentDir := filepath.Dir(cachedir)
	if ok, err := fs.IsDir(parentDir); !ok {
		if os.IsNotExist(err) {
			return fmt.Errorf("parent directory for $DEPCACHEDIR does not exist: %q", parentDir)
		}
		return errors.Wrap(err, "invalid parent directory for $DEPCACHEDIR")
	}

	if !fs.IsValidPath(cachedir) {
		return fmt.Errorf("$DEPCACHEDIR set to an invalid or inaccessible path: %q", cachedir)
	}
	return nil
}

One concern I have is that we try to check if the parent folder exists before we validate cachedir to be a valid path.

I am going to list all the scenarios just so that we(mostly me 😅) are clear.

$DEPCACHEDIR is not set. Same behavior as earlier, no confusion here.
$DEPCACHEDIR is set:

It is a valid path.

The parent directory exists. Everything works OK.
The parent directory does not exist. It errors out in cmd/dep/main.go when we call fs.IsValidPath. Since you are suggesting that the cache directory be created in with Mkdir in ctx.SourceManager(context.go), which will never even be called if the parent directory does not exist, I need a clarification. Should I change the behavior of fs.IsValidPath so that it does not return false for this particular scenario? And if yes, could you please help me figure out how?

It is not a valid path, maybe something like \000. Or the user does not have rw permissions to the given path. We error out in cmd/dep/main.go.

Since you are suggesting that the cache directory be created in with Mkdir in ctx.SourceManager(context.go)

i'm not suggesting that the cachedir be created there. I'm suggesting that filepath.Join(cachedir, "sources") be created there, much as it is now. it's the work of dep/cmd/main.go to create cachedir itself.
does that clarify sufficiently?

Thank you @sdboyer for being so patient with me. I have made the changes as per your suggestions.

The test doesn't produce consistent results. It failed for me once on my system.
I also tried to add some logging and it works correctly:
diff --git a/cmd/dep/integration_test.go b/cmd/dep/integration_test.go
index 0ecebaff..26e192de 100644
--- a/cmd/dep/integration_test.go
+++ b/cmd/dep/integration_test.go
@@ -82,6 +82,23 @@ func TestDepCachedir(t *testing.T) {
                        t.Logf("`dep ensure` error output: \n%s", testProj.GetStderr())
                        t.Errorf("got an unexpected error: %s", err)
                }
+               visit := func(path string, info os.FileInfo, err error) error {
+                       path = strings.Replace(path, cachedir, "[cachedir]", -1)
+                       if info.IsDir() {
+                               if info.Name() == ".git" {
+                                       return filepath.SkipDir
+                               }
+                               fmt.Println("dir:  ", path)
+                       } else {
+                               fmt.Println("file: ", path)
+                       }
+                       return nil
+               }
+
+               err := filepath.Walk(cachedir, visit)
+               if err != nil {
+                       t.Fatal(err)
+               }

                // Check that the cache was created in the cachedir. Our fixture has the dependency
                // `github.com/sdboyer/deptest`

Test output:
go test -v -timeout 120s github.com/golang/dep/cmd/dep -run ^TestDepCachedir$

=== RUN   TestDepCachedir
=== RUN   TestDepCachedir/env-cachedir
=== RUN   TestDepCachedir/env-invalid-cachedir
dir:   [cachedir]
dir:   [cachedir]\sources
dir:   [cachedir]\sources\https---github.com-sdboyer-deptest
file:  [cachedir]\sources\https---github.com-sdboyer-deptest\README.md
file:  [cachedir]\sources\https---github.com-sdboyer-deptest\deptest.go
--- PASS: TestDepCachedir (0.01s)
    --- PASS: TestDepCachedir/env-invalid-cachedir (0.01s)
    --- PASS: TestDepCachedir/env-cachedir (4.05s)
PASS
ok  	github.com/golang/dep/cmd/dep	5.851s
Success: Tests passed.

Not sure how I can fix it. Does it have anything to do with the parallel execution?

i'm not sure what the problem is there, honestly, and i still don't have access to a windows box to be able to test it myself.
if it's working on your windows system, then honestly, i'd be OK with bypassing the test on windows, so long as an explanatory note is included in a comment.

I think this is fine. I've tried reproducing this failure 10 times in appveyor (with an intent to debug the issue), but couldn't reproduce the failure even once. And in the past, we have seen some weird failures on Windows due to parallel execution. This could be one of them.

I agree with @darkowlzz but I am okay with disabling the test on Windows. @sdboyer, what do you suggest?

yep, let's disable the test on windows, with a comment.

ok, in we go! 🎉 🎉 thanks for your patience.

Thank you for your guidance!

@sdboyer While I not the sharpest tool in the shed and need some hand-holding, I still enjoy contributing here immensely. If you think there is anything else I could work on, please do ping. I'd be delighted to.


Invalid Webhook

I have created 3 channels , voice and text, created webhooks, but your software it always tell me invalid hook.

I have created 3 channels , voice and text, created webhooks, but your software it always tell me invalid hook.

Conditions for it to consider a webhook legit:-

Webhook should start with "https://discord.com/api/webhooks/"
It should be valid

If the error still persists, you can download older versions too to check for yourself

All is ok. My webhook was with discordAPP.com , anyway, can you msg me to @mkdirnow , on telegram ?

as, when I am to step : ICON, is closing without any warnings

All is ok. My webhook was with discordAPP.com , anyway, can you msg me to @mkdirnow , on telegram ?

sorry I don't use tepegram

as, when I am to step : ICON, is closing without any warnings

Can you upload a video on how and what happens?

is Just close the window. That`s all. mkdiretc1#3992 this is my discord, I would like to discuss some technical problems.

Works fine of my and my other discord friends' devices. Check if your firewall or antivirus is blocking it or not. Can't use discord so please keepvyour issue here.

Also check if older versions are working or not


Mediator coordination protocol recipient role

Add mediator coordination protocol as recipient role.
Keylist update is already implemented. But the request mediation parts still need to be implemented.
Resources:

flow: https://github.com/hyperledger/aries-framework-javascript/issues/40
https://github.com/hyperledger/aries-rfcs/blob/master/features/0211-route-coordination/README.md
Issuer for mediator role: #63

@JamesKEbert I'm not able to assign you, but created this issue to track the recipient role part of the protocol

Perfect, thank you. We'll start digging in and working on this!

Fixed!


[WIP] Add checkbox atom component

What's the purpose of this pull request?

How it works?

How to test it?

References

I think we need a data attribute to state checked.

But the CSS already has it [data-store-checkbox]:checked

In the storybook, is it possible to create a boolean control to check the checkbox? Also, I'd like to see if we can add an action there too so we can listen to when a checkbox has been checked

@tlgimenes and @emersonlaurentino I did your request changes.

@igorbrasileiro the tip of @tlgimenes is great!

@igorbrasileiro the tip of @tlgimenes is great!

If I understood well, it's to create a control for checked property and an action for the click event, I did it also.

Also, is it possible to make the default story to appear with the checked option set to false?

The default value is already false, but it's not explicitly defined. It seems a bug because the query string on the URL doesn't work, but you can remove the query string or navigate to another story and go back.


BugFix: Fix typo in DLLEXPORT attributes for IfW C interface

Feature or improvement description

Compilation fix under Windows + GCC  (IfW_C_Binding.f90)
The DLLEXPORT attribute in the compiler directives must match the subroutine names, otherwise the compiler throws an error
Related issue, if one exists

Pull request https://github.com/OpenFAST/openfast/pull/720
Impacted areas of the software

Additional supporting information

Test results, if applicable

Thank you @pablo-benito!


Add cover page

This is a somewhat inelegant solution using pdfunite., I wasn't able to get pandoc to build the LaTeX source correctly. The pdfunite utility may also need to be added to the Docker image from good cross-platform support.
I'm open to suggestions on how to improve this integration process.

It looks like the date on the cover page is still November 2020, I can update that if needed

Thank you. I'll see if I can get turn it into a pandoc template to remove the need for pdfunite. I hadn't thought to use that utility, nice, simple solution. :)


Issues with 'Attempt Fix' Button Unresponsiveness and Prompt Size Limit Exceeding in Bolt

Describe the bug
I am currently facing two significant issues with the Bolt platform that are affecting my workflow:
'Attempt Fix' Button Unresponsiveness:
Problem: When I click the 'Attempt Fix' button in Bolt, nothing happens—there is no response from the platform.
Attempted Resolutions: I have tried resetting the browser, closing and reopening the browser, and even restarting my PC. I also tested this functionality in different browsers and in incognito mode to eliminate any issues caused by browser extensions or cache, but the problem persists.
Prompt Size Limit Exceeding Error:
Problem: Even when using short prompts in Bolt, I encounter an error message stating, "This project exceeds the total supported prompt size."
Symptoms: This error appears regardless of the prompt length, suggesting an underlying issue with how Bolt handles or calculates prompt sizes.
Impact:
These issues severely limit the functionality of Bolt for routine operations, hindering my ability to effectively manage and troubleshoot projects.
Expected Behavior:
The 'Attempt Fix' button should initiate a troubleshooting protocol or fix attempt, and the platform should be able to handle prompts without incorrectly triggering size limit errors.
I kindly request assistance in resolving these issues or guidance on any potential workarounds. Thank you for your support.
Link to the Bolt URL that caused the error
https://bolt.new/~/sb1-utapxs
Validations

[X] Please make your project public or accessible by URL. This will allow anyone trying to help you to easily reproduce the issue and provide assistance.

Steps to reproduce
1.Sign In using demo id
email<EMAIL_ADDRESS>password : demo123

Go to Sidebar Menu and Click Patients under Patient Management
Click New Patient Button

problem detected but when clicking the Attempt Fix button nothing happen

and
If write a prompt error show
This project exceeds the total supported prompt size. To see how to resolve this, visit https://bolt.fyi/prompt-too-long.

Expected behavior

The 'Attempt Fix' button should promptly respond by initiating a troubleshooting process or a fix attempt when clicked.
The platform should handle prompts correctly without incorrectly triggering 'prompt size limit exceeded' errors, regardless of the actual size of the prompt submitted.

Screen Recording / Screenshot
No response
Platform
OS: Windows 10 Pro, Version 22H2, OS build 19045.5247
Browsers:
Google Chrome Version 131.0.6778.205 (64-bit)
Microsoft Edge Version 131.0.2093.112 (64-bit)
Additional context
I am using a Pro plan on Bolt.
Each click on the 'Attempt Fix' button also erroneously consumes tokens, adding financial costs without providing any function.

Hi, i have the same problem, do you find the solution ?

Hi, i have the same problem, do you find the solution ?

Hi, I haven't found a solution yet and there hasn't been any response or fix from the StackBlitz tech support team regarding this issue


fix getBit and add test for getBit

Hi Corey,
I've been working with geohash and found something doesn't look right with getBit function. It sometimes produce wrong value with large geohash value due to precision. I suggest fixing it using right-shifting. I've added a test to make sure this works right.
Cheers,
P/S: I saw another pull request from another guy "faster getBit" with the same content. Actually, here, it's more serious than the speed is the correction of the function.

Cool.  Thanks!


How to remove a previously used choices class?

In one of my old migrations I have:
        migrations.AlterField(
            model_name='maintenancetask',
            name='state',
            field=django_choices_field.fields.IntegerChoicesField(blank=True, choices=[(1, 'Open'), (32767, 'Closed')], choices_enum=models.maintenance.MaintenanceTaskState, default=1),
        ),

Today, I want to remove the state field and the MaintenanceTaskState class along with it. But I can't, since it's referenced in the old migration.
Any tips on how to proceed @bellini666 ? :)

Hi @Mapiarz ,
I've had that issue as well =P. This is something that I want to improve in the future.
What I usually do is to go to those old migrations and create a copy of the old class in that file, and reference it in the choices_enum argument.
Tell me if that works out for you

That works for me, thanks @bellini666!


Error when provision service with cf cs

I've been working on this error for a while, with no result.  Any idea what I missed?
Thanks
Beth Tran
Here's my set up

One VM running mongodb (<IP_ADDRESS>), exposing port 27017
I can access Guest VM mongodb with my mongodb credentials (admin/admpass)

Another VM (<IP_ADDRESS>) running CloudFoundry
application.yml has mongodb credential set as admin/admpass)
This application is deployed as service broker

cf marketplace
service    plans                 description
Mongo DB   Default Mongo Plan*   A simple MongoDB service broker implementation

cf cs "Mongo DB" "Default Mongo Plan" bethMongodbserviceInstance

Log for mongodb did not log anything for the connection from step #4

"cf cs" generate this error - as Connection refused
Server error, status code: 502, error code: 10001, message: Service broker error: Timed out after 10000 ms while waiting to connect. Client view of cluster state is {type=Unknown, servers=[{address=<IP_ADDRESS>:27017, type=Unknown, state=Connecting, exception={com.mongodb.MongoException$Network: Exception opening the socket}, caused by {java.net.ConnectException: Connection refused}}]; nested exception is com.mongodb.MongoTimeoutException: Timed out after 10000 ms while waiting to connect. Client view of cluster state is {type=Unknown, servers=[{address=<IP_ADDRESS>:27017, type=Unknown, state=Connecting, exception={com.mongodb.MongoException$Network: Exception opening the socket}, caused by {java.net.ConnectException: Connection refused}}]

I have redeployed the broker application, and was able to make the connection from broker app to the external database engine.


Add Getting Started section to README

README update
Please add a getting started section to the README so folks know how to start with this project.

Test


Is there any way to prevent azcopy from failing when source blobs are modified or deleted?

Which version of the AzCopy was used?
10.20.0
Which platform are you using? (ex: Windows, Mac, Linux)
Windows 11 x64
What command did you run?
azcopy.exe copy 'https://...' 'https://...' --recursive --overwrite=ifSourceNewer
What problem was encountered?
2023/08/09 20:47:47 ERR: [P#51-T#1135] COPYFAILED: https://.... : 409 : 409 Copy source blob has been modified.. When Put Blob from URL.

2023/08/09 20:57:08 ERR: [P#68-T#9820] COPYFAILED: https://... : 404 : 404 The specified blob does not exist.. When Put Blob from URL.

How can we reproduce the problem in the simplest way?
Have you found a mitigation/solution?
No
Is there any way to make azcopy retry the transfer of modified source blobs and skip missing blobs, rather than mark them as failed?

Hi @andrei-faber , we do not have a way to ignore deleted source blobs. This will be treated as a failure. Also, we fail the transfer if the source has been modified to preserve the consistency of data. This behaviour will not be changed. Please make sure that the source remains constant while transfer is in progress.


Add BHNT80 hacks

Still some info missing - but at least a start - maybe  @TimDaub @jzilg @lavielle @qaismyname @herrmuellerluedenscheid @johnjohndoe can add more details?

Instead of
* Educkio by [Marius Kriegerowski](https://github.com/herrmuellerluedenscheid

maybe sth more explanatory?
* Renewable energy on the local power grid ([educk.io](https://educk.io)) by [Marius Kriegerowski](https://github.com/herrmuellerluedenscheid)

Renewable energy on the local power grid (educk.io) by Marius Kriegerowski

@HerrMuellerluedenscheid thanks - changed to this - did not know the details of that one


[Test Improvements] Create app testing helper methods

Background
Currently sometimes writing a test would take so much time on the test setup, due to wiring etc.
For example, if we want to test superfluid, we would have to manually create Balancer pool, create lock, register it as superfluid asset and then have it superfluid delegated.
As we can see, this is alot of boiler plate, it would take me more time to wire stuff down then actually start writing my test code in some instances.
Suggested Design
We can improve this by creating good helper methods beforehand for different modules.
Some of the helper methods that comes into my mind as I am writing this is

superfluid setup
CL pool setup
incentive and gauge setup
lock set up

and so on.
Also, most work should have been already done, its just that the helper methods are defined as helper methods within each module's keeper packages, and we want to mitigate this to app testing suite so that we can import and use these methods anywhere.

I think this has been solved? lets re-open if were still fighting similar problems


XDG desktop portals don't work

Hyprland Version
 System/Version info
Hyprland, built from branch  at commit f8857e6072bd85b95393499688872aaf7f088b5b  ().
Date: 2024-05-18
Tag: , commits:

flags: (if any)

System Information:
System name: Linux
Node name: nixos
Release: 6.9.1
Version: #1-NixOS SMP PREEMPT_DYNAMIC Fri May 17 10:18:09 UTC 2024

GPU information:
	Flags: bus master, VGA palette snoop, 66MHz, medium devsel, latency 64, NUMA node 0, IOMMU group 11
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU117 [GeForce GTX 1650] [10de:1f82] (rev a1) (prog-if 00 [VGA controller])

os-release: ANSI_COLOR="1;34"
BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"
BUILD_ID="24.05.20240517.4a6b83b"
DOCUMENTATION_URL="https://nixos.org/learn.html"
HOME_URL="https://nixos.org/"
ID=nixos
IMAGE_ID=""
IMAGE_VERSION=""
LOGO="nix-snowflake"
NAME=NixOS
PRETTY_NAME="NixOS 24.05 (Uakari)"
SUPPORT_URL="https://nixos.org/community.html"
VERSION="24.05 (Uakari)"
VERSION_CODENAME=uakari
VERSION_ID="24.05"

plugins:
  hyprexpo by Vaxry ver 1.0

Bug or Regression?
Bug
Description
Portals don't start, and even if started manually, picker doesn't show up (NixOS)
How to reproduce

Use NixOS
Install Hyprland using flake
Try to stream in discord (vesktop/firefox) or open obs
doesn't work

Crash reports, logs, images, videos
No response

great. xdg desktop portals are separate things. Unrelated to hyprland.


Plot 2 models side by side

What problem does your feature request solve?
Plot UM and Lfric data side by side
Adding further to this, attempting to plot the difference of the two plots too.
Describe the solution you'd like
Ideally we would like to be able to select two models from the ROSE gui and be able to plot them side by side using the same recipe.
Describe alternatives you've considered
As a temporary measure we have hacked CSET to read in both models from the same directory using file pattern naming and two recipes.

Screenshot of surface temperature from lfric model (left hand side) and um mode (right hand side).

No, this is what you helped me with on Tuesday. Thought it was good to document it somewhere. I am currently working on a new recipe to compute a difference of the two fields. If that works, it shouldn't be too difficult to plot two plots from the same recipe (I think).


Roadmap, enhancements and contribution?

A few things:

Am curious if you have a roadmap that I haven't noticed, or which is not currently visible
Any plans to move the library over to the mostjs organization so that it can be stand alongside relevant extensions and utilities?
Any scope for contributors to help you get the library over the line?
Would like to suggest exposing everything externally. As an example, I'm trying to make an overload of reduce, and have no way to access the Accumulate constructor.

Hey @axefrog!

roadmap that I haven't noticed

Unfortunately, I haven't written it down anywhere, though @davidchase and I have discussed a few things.  Bug me about it on gitter sometime, and I'll be happy to discuss.

Any plans to move the library over to the mostjs organization

Yeah, we should, though it's not quite clear yet what form that would take.  For example, @davidchase and I have talked about creating @most/core, which contains some minimal amount of the most core plus only the most essential combinators (like map and filter).  Then, most proper could depend on @most/core.
Any thoughts on that approach?

Any scope for contributors to help you get the library over the line?

I def welcome contributions.  This is, of course, related to the roadmap, which we can discuss on gitter.  I think a good goal would be to write down the roadmap and identify items where contributors could jump in.

Would like to suggest exposing everything externally

I do think most needs to expose some slightly more primitive public APIs.  However, I consider Accumulate and classes like it to be implementation details.  I would prefer to use functions instead, but that would require lots of scope chain capturing which would change the performance (cpu and memory) characteristics of the whole library.  I'd rather expose more primitive functions (implemented using Accumulate and the like) which allows generalized accumulation (or at least "more configurable" accumulation), rather than exposing these implementation detail classes.  Once we expose a constructor like Accumulate, it becomes extremely difficult to change or remove it.
I guess what I'm saying is that it feels more like there is a missing, slightly more general, public API.  I would prefer to fill that hole rather than expose the even-more-low-level implementation classes.

@most/core, which contains some minimal amount of the most core plus only the most essential combinators

I like this idea a lot for whatever it is worth. Maybe it would be a good place to implement the ES7 observable specification, while the other operators are "extras". Just and idea

I think a good goal would be to write down the roadmap and identify items where contributors could jump in.

:+1: I think this is a good idea as well, for any project.

see #180

I'm trying to make an overload of reduce

@axefrog I think this is the one item in your list that isn't covered by #180 yet.  Could you provide a bit more detail on the kind of accumulator you'd like to be able to create?  Left fold (aka reduce, or foldl) is pretty well defined. There are variations such as foldl1, associative and commutative folds, and CPS folds, though I'm not sure if any of those apply to a time-based event stream.
Thanks!

Hey, sorry for the delayed reply. Been a bit swamped. Actually my particular case was just that I needed to run reduce with a test scheduler and there was no way for me to do that without reimplementing the operator myself.

@axefrog got it, thanks!  I'll add a note to the roadmap.

Closing this in favor of #180, but if there's something here that you think isn't represented on the roadmap, please say so!


Can I compile the lib without GPU?

Hi i'm using macbook without CUDA supported GPU which means I cannot have cuda installed on my local computer...
but i saw your source code have both crop_and_resize.c and crop_and_resize_gpu.c files so I guess I can run it on CPU right?
so can I compile the lib without cuda?

You should be able to comment out the compilation of the cuda part. However I'm assuming cuda every where in my code.  You need also to modify that to run on CPU.

Thanks, I run the training part on GPU severs but I need to do some testing on my laptop.
I've done some google search and managed to install CUDA without GPU on my MacBook and it seems everything work out well.


Multipart Support for PUT method

This PR fixes #1262

@johanhaleby ping :)

@steve-todorov Sorry for the very late response but thanks for the PR :)
I just have a question regarding the "nio-multipart-parser" dependency, why is this necessary? I'm always hesitant to include additional transitive dependencies.

It looks like it works without this extra dependency so I'm going to merge it to master

Thanks for merging @johanhaleby! It looks like the nio-multipart-parser dependency is needed - the master is broken in Travis and on my machine as well. Adding the dependency back fixed it for me. Maybe @anki2189 can share more details if this needs to be scoped to only test or if it's actually needed? :)

By the way, do you plan to cut a release soon? We have a few tests which required this feature and had to disable them until this gets resolved.


Update site-wide settings

resolves #4

Codecov Report

Merging #8 (a767926) into master (0dd686b) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master       #8   +/-   ##
=========================================
  Coverage     72.15%   72.15%
  Complexity      399      399
=========================================
  Files            70       70
  Lines          1232     1232
  Branches        125      125
=========================================
  Hits            889      889
  Misses          311      311
  Partials         32       32

Continue to review full report at Codecov.

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

Thank you Zhi Bin!


Set astro cookies in LambdaEdge function response

Q
A

Fixed Issues?
Fixes #63

Patch: Bug Fix?
Bug Fix

Major: Breaking Change?
Use Astro.cookies instead of Astro.response.headers.set('set-cookie')

Minor: New Feature?
Astro.cookies now respected in LambdaEdge response

Tests Added + Pass?
Yes

Documentation PR Link

Any Dependency Changes?

License
MIT

Cookies set via Astro.cookies are now set in the LambdaEdge response.
One can still set a 'Set-Cookie' header directly, but cookies set via Astro.cookies will take precedence and would overwrite the directly set 'Set-Cookie' header.

Scenario 1:
Astro.response.headers.set('Set-Cookie', 'test=test')

Response headers:
'Set-Cookie': 'test=test'

Scenario 2:
Astro.cookies.set('test', 'test')
Astro.cookies.delete('otherCookie')

Response headers:
'Set-Cookie': 'test=test'
'Set-Cookie': 'otherCookie=deleted; Expires=Thu, 01 Jan 1970 00:00:00 GMT'

Scenario 3:
Astro.response.headers.set('Set-Cookie', 'manual=test')
Astro.cookies.set('viaAstro', 'test')

Response headers:
'Set-Cookie': 'viaAstro=test'

I need to fix the AWS account the test site deploys to. I will rerun CI when that is done.

I'm hoping to have this fixed today.

Thanks!
Do you also plan on releasing a new version?

@kasleet Yes. I am going to upgrade reps and then I will publish.


age transition and anime effect

Description:
Feature Request:
I would like to propose the addition of a new feature to the Face-X project – specifically, the implementation of an "age transition and anime effect." This feature would enhance the versatility of the project by allowing users to apply age transformation and anime-style effects to facial images.
Details:
Age Transition:
The age transition functionality would enable users to visualize how a person's face might change over time. This can be achieved by implementing algorithms that simulate the aging process and generate a transitioned image.
Anime Effect:
The anime effect feature would involve applying artistic filters or transformations to give facial images an anime-like appearance. This could include elements such as stylized eyes, facial expressions, and color palettes commonly seen in anime art.
Benefits and Use Cases:
Creative Expression: Users can use this feature for artistic expression, creating anime-style avatars or profile pictures.
Entertainment: Age transition can add a fun and entertaining aspect to the project, allowing users to see hypothetical future versions of their faces.
Educational: The feature could also be used for educational purposes, demonstrating the impact of age on facial features.

Hey @akshitagupta15june , I would love to work , you can assign me!

Hey @akshitagupta15june I have my works on it that's why I suggested this can you assign me to allow me put my small contributions to this amazing work! Thanks

I would like to contribute to this issue...could you please assign this to me?

Hey @akshitagupta15june I have worked on various computer vision problems and have a good experience with computer vision algorithms related to faces. I would love to contribute on this issue. I would be very happy to work on this issue and contribute to this awesome repo.
Thank You!

I agree to follow this project's Code of Conduct
I'm a GSSOC'24 contributor
I want to work on this issue


Equivocation without violating any rules

Description
If the node is unable to record the fact that it published an activation for a given epoch, e.g., by losing write access to the nipost challenge directory or database, and is then restarted, it will publish a second activation for the same epoch, thus equivocating.
Affected code
https://github.com/spacemeshos/go-spacemesh/blob/eb263c8e831d7d141e939e409d19b940be09972b/activation/activation.go#L502-L519
Proposed mitigation
The act of broadcasting the atx and recording this in local state should be atomic: it shouldn't be possible to do one without doing the other.
#5207 helps somewhat, in that the state location for nipost data is the same as the rest of the state, so it's unlikely that a node would lose write access to this location and still be able to run (as is possible in v1.2 branch today where nipost data is written to the post init location), but this operation should still be made atomic.
Also, the node should already have its own previous ATX in the database and should refuse to broadcast a second ATX targeting the same epoch!
Additional information
This happened yesterday to smesher 0x3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b (https://explorer.spacemesh.io/smeshers/0x3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b). Here are partial logs:
{
  "timestamp": "2023-12-14T22:22:19.793228Z",
  "help": "Node finished PoST execution using PoET challenge.",
  "postComplete": {
    "challenge": "pkb5POjzjuDlisOAg2jY3sktB6yjpKMB5s3GwT7c34M="
  }
}
{
  "timestamp": "2023-12-14T22:22:20.954380Z",
  "help": "Node committed malicious behavior. Identity will be canceled.",
  "malfeasance": {
    "proof": {
      "smesherId": {
        "id": "PITKduVnymwg1Qkx3gJ9HIw8W9ydvyt2eumme75/u3s="
      },
      "layer": {
        "number": 40320
      },
      "kind": "MALFEASANCE_ATX",
      "debugInfo": "generate layer: 40320\nsmesher id: 3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b\ncause: smesher published multiple ATXs in epoch 10\n1st message hash: 62332b4f1a7e2312600128db4bbfe9f0850ca37f62b31ee8d86b352f9bc19f28\n1st message signature: ded96ccf4dbb8041c22891eab3ae6c80bbe4e9309c4240d12b5
69dc792d3613177f682658f9629ad99149ca430ac4f0a6e0c54f33271eb909eb3014b27850c08\n2nd message hash: debf494f7b4b849fd2d1e017f291b96c833fdfa6899c6159203b164b7da3fd79\n2nd message signature: c7b6b404e2192e1f4b07c5b7946238ce8c6ee9a9fdac92dc56ba8f4bbf3557722036cb86ad36b1d74ebded351468f2c1be3e22f020f676a308f6de0449cd1a0b\n"
    }
  }
}
{
  "timestamp": "2023-12-14T22:25:00.331785Z",
  "help": "Node published activation for the current epoch. It now needs to wait until the target epoch when it will be eligible for rewards.",
  "atxPublished": {
    "current": 10,
    "target": 11,
    "id": "3r9JT3tLhJ/S0eAX8pG5bIM/36aJnGFZIDsWS32j/Xk=",
    "wait": "34499.668217s"
  }
}

2023-12-04T14:40:24.373-0500    INFO    3c84c.post      post setup completed    {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "post", "node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "commitment_atx": "813a3a65d6", "data_dir": "/Volumes/SMESHER04/post/7c8cef2b/", "num_units": "58", "labels_per_unit": "4294967296", "provider": "{0}", "name": "post"}
2023-12-04T14:40:24.385-0500    INFO    3c84c.atxBuilder        atx challenge is ready  {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxBuilder", "sessionId": "b817220f-7cce-40ee-8e30-6a5368782344", "current_epoch": "10", "publish_epoch": "10", "target_epoch": "11", "name": "atxBuilder"}
2023-12-04T14:40:24.385-0500    INFO    3c84c.nipostBuilder     building nipost {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "sessionId": "b817220f-7cce-40ee-8e30-6a5368782344", "poet round start": "2023-11-27T03:00:00.000-0500", "poet round end": "2023-12-10T15:00:00.000-0500", "publish epoch": "10", "publish epoch end": "2023-12-15T03:00:00.000-0500", "target epoch": "11", "name": "nipostBuilder"}
2023-12-04T14:40:24.423-0500    INFO    3c84c.nipostBuilder.poet        response received       {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "url": "https://poet-111.spacemesh.network/v1/info", "status": 200}
2023-12-04T14:40:24.927-0500    INFO    3c84c.nipostBuilder.poet        response received       {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "url": "https://poet-112.spacemesh.network/v1/info", "status": 200}
2023-12-04T14:40:25.062-0500    INFO    3c84c.nipostBuilder.poet        response received       {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "url": "https://backup-poet.spacemesh.network/v1/info", "status": 200}
2023-12-04T14:40:25.096-0500    INFO    3c84c.nipostBuilder.poet        response received       {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "url": "https://mainnet-poet-0.spacemesh.network/v1/info", "status": 200}
2023-12-04T14:40:25.230-0500    INFO    3c84c.nipostBuilder.poet        response received       {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "url": "https://mainnet-poet-1.spacemesh.network/v1/info", "status": 200}
2023-12-04T14:40:26.554-0500    INFO    3c84c.nipostBuilder.poet        response received       {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "url": "https://mainnet-poet-2.spacemesh.network/v1/info", "status": 200}
2023-12-04T14:40:26.554-0500    INFO    3c84c.nipostBuilder     waiting until poet round end    {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "sessionId": "b817220f-7cce-40ee-8e30-6a5368782344", "poet_id": "f115c42343303b7b895083451653a6fee4e32429de57d16274ca579a7e791bc6", "round": "9", "wait time": "144h19m47.277659151s", "name": "nipostBuilder"}
2023-12-04T14:40:26.601-0500    INFO    3c84c.nipostBuilder.poet        response received       {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "url": "https://poet-110.spacemesh.network/v1/info", "status": 200}
2023-12-04T14:40:26.601-0500    INFO    3c84c.nipostBuilder     waiting until poet round end    {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "sessionId": "b817220f-7cce-40ee-8e30-6a5368782344", "poet_id": "e69fe63ef9aa87076f7fc534195acdabff4837f1e6663e610a414b00dd388351", "round": "9", "wait time": "144h19m47.324342562s", "name": "nipostBuilder"}
2023-12-04T14:40:26.601-0500    INFO    3c84c.nipostBuilder     waiting until poet round end    {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "sessionId": "b817220f-7cce-40ee-8e30-6a5368782344", "poet_id": "c90d96d3d2eb3a2e23a263774e3e91af9210856316138f31606f6460a739facd", "round": "9", "wait time": "144h19m43.70253096s", "name": "nipostBuilder"}
2023-12-04T14:40:26.601-0500    INFO    3c84c.nipostBuilder     waiting until poet round end    {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "sessionId": "b817220f-7cce-40ee-8e30-6a5368782344", "poet_id": "7059ea092e68111ec6397e7bea83ed6a197107fd72f7968389b74aed11d01558", "round": "9", "wait time": "144h19m47.672109722s", "name": "nipostBuilder"}
2023-12-04T14:40:26.601-0500    INFO    3c84c.nipostBuilder     waiting until poet round end    {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "sessionId": "b817220f-7cce-40ee-8e30-6a5368782344", "poet_id": "f10aa089dfb7edec98ee293e100e3b35de53ad08d7a256efd8c7608abdb8dcda", "round": "9", "wait time": "144h19m48.8264983s", "name": "nipostBuilder"}
2023-12-04T14:40:26.601-0500    INFO    3c84c.nipostBuilder     waiting until poet round end    {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "sessionId": "b817220f-7cce-40ee-8e30-6a5368782344", "poet_id": "421d5e7f1638621a180445ca3d388727f6bb9f51ac965452cb079028ede3ee6d", "round": "9", "wait time": "144h19m48.016070619s", "name": "nipostBuilder"}
2023-12-04T14:40:26.601-0500    INFO    3c84c.nipostBuilder     waiting until poet round end    {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "sessionId": "b817220f-7cce-40ee-8e30-6a5368782344", "poet_id": "71a215d189b9f4bdd1a9b5402fa52b08fc2bfb3fa5c1ed93063e7b4169c082d3", "round": "9", "wait time": "144h19m12.661856577s", "name": "nipostBuilder"}
...
2023-12-10T15:13:55.536-0500    INFO    3c84c.nipostBuilder.poet        response received       {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "url": "https://mainnet-poet-0.spacemesh.network/v1/proofs/9", "status": 429}
2023-12-10T15:13:55.537-0500    WARN    3c84c.nipostBuilder     failed to get proof from poet   {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "sessionId": "b817220f-7cce-40ee-8e30-6a5368782344", "poet_id": "7059ea092e68111ec6397e7bea83ed6a197107fd72f7968389b74aed11d01558", "round": "9", "errmsg": "getting proof: doing request: GET https://mainnet-poet-0.spacemesh.network/v1/proofs/9 giving up after 11 attempt(s)", "name": "nipostBuilder"}
2023-12-10T15:13:55.537-0500    INFO    3c84c.nipostBuilder     got poet proof  {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "leaf count":<PHONE_NUMBER>9, "name": "nipostBuilder"}
2023-12-10T15:13:55.537-0500    INFO    3c84c.nipostBuilder     got poet proof  {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "leaf count":<PHONE_NUMBER>3, "name": "nipostBuilder"}
2023-12-10T15:13:55.537-0500    INFO    3c84c.nipostBuilder     got poet proof  {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "leaf count":<PHONE_NUMBER>2, "name": "nipostBuilder"}
2023-12-10T15:13:55.537-0500    INFO    3c84c.nipostBuilder     got poet proof  {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "leaf count":<PHONE_NUMBER>2, "name": "nipostBuilder"}
2023-12-10T15:13:55.537-0500    INFO    3c84c.nipostBuilder     got poet proof  {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "leaf count":<PHONE_NUMBER>8, "name": "nipostBuilder"}
2023-12-10T15:13:55.537-0500    INFO    3c84c.nipostBuilder     got poet proof  {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "leaf count":<PHONE_NUMBER>4, "name": "nipostBuilder"}
2023-12-10T15:13:55.539-0500    INFO    3c84c.nipostBuilder     selected the best proof {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "leafCount":<PHONE_NUMBER>2, "ref": "pkb5POjzjuDlisOAg2jY3sktB6yjpKMB5s3GwT7c34M=", "name": "nipostBuilder"}
2023-12-10T15:13:55.588-0500    INFO    3c84c.nipostBuilder     starting post execution {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "challenge": "pkb5POjzjuDlisOAg2jY3sktB6yjpKMB5s3GwT7c34M=", "name": "nipostBuilder"}
2023-12-10T15:13:55.764-0500    INFO    3c84c.nipostValidator   generating proof with PoW flags: RandomXFlag(FLAG_HARD_AES | FLAG_FULL_MEM | FLAG_JIT | FLAG_SECURE) and params: ProvingParams { difficulty:<PHONE_NUMBER>, pow_difficulty: [0, 0, 61, 181, 148, 179, 42, 102, 207, 114, 194, 52, 247, 44, 35, 79, 114, 194, 52, 247, 44, 35, 79, 114, 194, 52, 247, 44, 35, 79, 114, 194] }  {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostValidator", "module": "post::prove", "file": "src/prove.rs", "line": 276}
2023-12-10T15:14:37.062-0500    INFO    3c84c.nipostValidator   calculating proof of work for nonces 0..288     {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostValidator", "module": "post::prove", "file": "src/prove.rs", "line": 131}
...
2023-12-10T23:12:37.270-0500    INFO    3c84c.nipostValidator   Found proof for nonce: 28, pow:<PHONE_NUMBER>3202178 with [3584835803,<PHONE_NUMBER>6,<PHONE_NUMBER>6,<PHONE_NUMBER>0,<PHONE_NUMBER>4,<PHONE_NUMBER>6,<PHONE_NUMBER>0,<PHONE_NUMBER>3,<PHONE_NUMBER>7,<PHONE_NUMBER>4,<PHONE_NUMBER>1,<PHONE_NUMBER>7,<PHONE_NUMBER>9,<PHONE_NUMBER>5,<PHONE_NUMBER>8,<PHONE_NUMBER>75,<PHONE_NUMBER>79,<PHONE_NUMBER>76,<PHONE_NUMBER>28,<PHONE_NUMBER>61,<PHONE_NUMBER>77,<PHONE_NUMBER>21,<PHONE_NUMBER>89,<PHONE_NUMBER>05,<PHONE_NUMBER>03,<PHONE_NUMBER>59,<PHONE_NUMBER>26,<PHONE_NUMBER>52,<PHONE_NUMBER>86,<PHONE_NUMBER>93,<PHONE_NUMBER>77,<PHONE_NUMBER>98,<PHONE_NUMBER>21,<PHONE_NUMBER>78,<PHONE_NUMBER>32,<PHONE_NUMBER>08,<PHONE_NUMBER>60] indices      {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostValidator", "module": "post::prove", "file": "src/prove.rs", "line": 323}
2023-12-10T23:12:37.367-0500    INFO    3c84c.post      proving: generated proof        {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "post"}
2023-12-10T23:12:37.451-0500    INFO    3c84c.nipostBuilder     finished post execution {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "duration": "7h58m41.95018025s", "name": "nipostBuilder"}
2023-12-10T23:12:37.453-0500    WARN    3c84c.nipostBuilder     cannot store nipost state       {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "errmsg": "saving builder state: writing file: create temporary file /Volumes/SMESHER04/post/7c8cef2b/nipost_builder_state.bin.tmp: open /Volumes/SMESHER04/post/7c8cef2b/nipost_builder_state.bin.tmp: operation not permitted", "name": "nipostBuilder"}
2023-12-10T23:12:37.453-0500    INFO    3c84c.nipostBuilder     finished nipost construction    {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder"}
2023-12-10T23:12:37.453-0500    INFO    3c84c.atxBuilder        awaiting atx publication epoch  {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxBuilder", "pub_epoch": "10", "pub_epoch_first_layer": "40320", "current_layer": "43154", "name": "atxBuilder"}
2023-12-10T23:12:37.540-0500    INFO    3c84c.atxBuilder        atx published   {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxBuilder", "sessionId": "b817220f-7cce-40ee-8e30-6a5368782344", "event": true, "atx_id": "62332b4f1a", "challenge": "0xc757ce06980f388a2ec8d1cee8ba6f1dbb2740ce23f069ab783f0b02d4f1c49b", "smesher": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "prev_atx_id": "ea7e2ceb82", "pos_atx_id": "ea7e2ceb82", "coinbase": "sm1qqqqqqz3yyrkk4zr8wesmu04f77jxyel6pxvv9sxf8afx", "epoch": 10, "num_units": 58, "sequence_number": 4, "size": 1001, "name": "atxBuilder"}
2023-12-10T23:12:37.540-0500    WARN    3c84c.atxBuilder        failed to publish atx   {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxBuilder", "sessionId": "b817220f-7cce-40ee-8e30-6a5368782344", "layer_id": 43154, "epoch_id": 10, "errmsg": "discarding challenge after published ATX: discarding nipost challenge: remove /Volumes/SMESHER04/post/7c8cef2b/nipost_challenge.bin: operation not permitted", "name": "atxBuilder"}
2023-12-10T23:12:37.540-0500    WARN    3c84c.atxBuilder        unknown error   {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxBuilder", "sessionId": "b817220f-7cce-40ee-8e30-6a5368782344", "errmsg": "discarding challenge after published ATX: discarding nipost challenge: remove /Volumes/SMESHER04/post/7c8cef2b/nipost_challenge.bin: operation not permitted", "name": "atxBuilder"}
2023-12-10T23:15:00.411-0500    WARN    3c84c.atxBuilder        failed to load atx challenge    {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxBuilder", "sessionId": "ea68a4e0-af3e-4360-b712-c965159e5e77", "errmsg": "loading nipost challenge: reading file: open file /Volumes/SMESHER04/post/7c8cef2b/nipost_challenge.bin: open /Volumes/SMESHER04/post/7c8cef2b/nipost_challenge.bin: operation not permitted", "name": "atxBuilder"}
2023-12-10T23:15:00.411-0500    INFO    3c84c.atxBuilder        building new atx challenge      {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxBuilder", "sessionId": "ea68a4e0-af3e-4360-b712-c965159e5e77", "current_epoch": "10", "name": "atxBuilder"}
2023-12-11T02:01:06.975-0500    WARN    3c84c.atxBuilder        failed to publish atx   {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxBuilder", "sessionId": "ea68a4e0-af3e-4360-b712-c965159e5e77", "layer_id": 43188, "epoch_id": 10, "errmsg": "saving nipost challenge: writing file: create temporary file /Volumes/SMESHER04/post/7c8cef2b/nipost_challenge.bin.tmp: open /Volumes/SMESHER04/post/7c8cef2b/nipost_challenge.bin.tmp: operation not permitted", "name": "atxBuilder"}
2023-12-11T02:01:06.975-0500    WARN    3c84c.atxBuilder        unknown error   {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxBuilder", "sessionId": "ea68a4e0-af3e-4360-b712-c965159e5e77", "errmsg": "saving nipost challenge: writing file: create temporary file /Volumes/SMESHER04/post/7c8cef2b/nipost_challenge.bin.tmp: open /Volumes/SMESHER04/post/7c8cef2b/nipost_challenge.bin.tmp: operation not permitted", "name": "atxBuilder"}

...

2023-12-14T17:22:19.643-0500    INFO    3c84c.post      proving: generated proof        {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "post"}
2023-12-14T17:22:19.793-0500    INFO    3c84c.nipostBuilder     finished post execution {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "duration": "6h55m22.843336959s", "name": "nipostBuilder"}
2023-12-14T17:22:20.842-0500    INFO    3c84c.nipostBuilder     finished nipost construction    {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder"}
2023-12-14T17:22:20.842-0500    INFO    3c84c.atxBuilder        awaiting atx publication epoch  {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxBuilder", "pub_epoch": "10", "pub_epoch_first_layer": "40320", "current_layer": "44236", "name": "atxBuilder"}
2023-12-14T17:22:20.951-0500    WARN    3c84c.atxHandler        atx failed contextual validation        {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxHandler", "requestId": "c9c46686-4860-4c3a-badc-8de4ff7e577c", "atx_id": "debf494f7b4b849fd2d1e017f291b96c833fdfa6899c6159203b164b7da
3fd79", "smesher": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "errmsg": "last atx is not the one referenced", "name": "atxHandler"}
2023-12-14T17:22:20.952-0500    WARN    3c84c.atxHandler        smesher produced more than one atx in the same epoch    {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxHandler", "requestId": "c9c46686-4860-4c3a-badc-8de4ff7e577c", "smesher": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9d
bf2b767ae9a67bbe7fbb7b", "prev": {"atx_id": "62332b4f1a", "challenge": "0xc757ce06980f388a2ec8d1cee8ba6f1dbb2740ce23f069ab783f0b02d4f1c49b", "smesher": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "prev_atx_id": "ea7e2ceb82", "pos_atx_id": "ea7e2ceb82", "coinbase": "sm1qqqqqqz3yyrkk4zr8wesmu04f77jxyel6pxvv9
sxf8afx", "epoch": 10, "num_units": 58, "effective_num_units": 58, "sequence_number": 4, "base_tick_height": 84399, "tick_count": 9392, "weight": 544736}, "curr": {"atx_id": "debf494f7b", "challenge": "0xc757ce06980f388a2ec8d1cee8ba6f1dbb2740ce23f069ab783f0b02d4f1c49b", "smesher": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b76
7ae9a67bbe7fbb7b", "prev_atx_id": "ea7e2ceb82", "pos_atx_id": "ea7e2ceb82", "coinbase": "sm1qqqqqqz3yyrkk4zr8wesmu04f77jxyel6pxvv9sxf8afx", "epoch": 10, "num_units": 58, "effective_num_units": 58, "sequence_number": 4, "base_tick_height": 84399, "tick_count": 9392, "weight": 544736}, "name": "atxHandler"}
2023-12-14T17:22:20.954-0500    WARN    3c84c.atxHandler        failed to process atx gossip    {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxHandler", "requestId": "c9c46686-4860-4c3a-badc-8de4ff7e577c", "sender": "12D3KooWRByEPQFCypeTd45WN5UESWnxjKbVcF3LE6epzz4EgqkK", "errmsg": "c
annot process atx debf494f7b: cannot store atx debf494f7b: malicious atx", "name": "atxHandler"}
2023-12-14T17:22:20.954-0500    WARN    3c84c.atxBuilder        failed to publish atx   {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxBuilder", "sessionId": "0f8cdd3c-181c-487f-83ba-e38ed5e4bbda", "layer_id": 44236, "epoch_id": 10, "errmsg": "broadcast: failed to broadcast ATX: fail
ed to publish to topic ax1: validation ignored", "name": "atxBuilder"}
2023-12-14T17:22:20.954-0500    WARN    3c84c.atxBuilder        unknown error   {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxBuilder", "sessionId": "0f8cdd3c-181c-487f-83ba-e38ed5e4bbda", "errmsg": "broadcast: failed to broadcast ATX: failed to publish to topic ax1: validation igno
red", "name": "atxBuilder"}

...

2023-12-14T17:25:00.331-0500    INFO    3c84c.atxBuilder        atx challenge is ready  {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxBuilder", "sessionId": "dae41e3b-c4ce-476e-924d-d32688d6cc75", "current_epoch": "10", "publish_epoch": "10", "target_epoch": "11", "name": "atxBuilde
r"}
2023-12-14T17:25:00.331-0500    INFO    3c84c.atxBuilder        atx published   {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxBuilder", "sessionId": "dae41e3b-c4ce-476e-924d-d32688d6cc75", "event": true, "atx_id": "debf494f7b", "challenge": "0xc757ce06980f388a2ec8d1cee8ba6f1dbb2740ce23f069ab783f0b02d4f1c49b", "smesher": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "prev_atx_id": "ea7e2ceb82", "pos_atx_id": "ea7e2ceb82", "coinbase": "sm1qqqqqqz3yyrkk4zr8wesmu04f77jxyel6pxvv9sxf8afx", "epoch": 10, "num_units": 58, "sequence_number": 4, "size": 1001, "name": "atxBuilder"}
2023-12-14T17:25:00.333-0500    INFO    3c84c.atxBuilder        building new atx challenge      {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxBuilder", "sessionId": "7ed832dd-e5b9-4270-83c8-3383157ad048", "current_epoch": "10", "name": "atxBuilder"}
2023-12-14T17:25:00.333-0500    WARN    3c84c.atxBuilder        failed to publish atx   {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxBuilder", "sessionId": "7ed832dd-e5b9-4270-83c8-3383157ad048", "layer_id": 44237, "epoch_id": 10, "errmsg": "builder: atx expired: builder cannot to submit in epoch 10. poet round already started 86h25m0.333803s ago", "name": "atxBuilder"}

This issue appears in commit hash: eb263c8e831d7d141e939e409d19b940be09972b

i didn't understand the problem fully. but node always executes validation handler, that saves atx to database on successful validation. and only after that it publishes atx to the network.

My reading of the code above (Builder.PublishActivationTx) is that it builds the NIPost challenge, then creates the ATX, then publishes it, then removes the NIPost challenge. If the last step fails, it tries to publish again one epoch later, regardless of whether publishing succeeded or failed. I don't see a validation handler in this loop, LMK what I'm missing.

I may be missing something here - I hope I am - but where is the logic that prevents the node from publishing an ATX twice in the same epoch? I don't see that here, it seems to blindly proceed to generate and broadcast a new ATX whenever possible. CC @fasmat

For some reason this node succeeded in publishing its ATX the first time (despite the misleading log messages), but didn't manage to record its own ATX in its own database the first time. Is there any way the publish -> record in database loop could've broken? I can't find any other info in the logs.
In any case, given the severity of this sort of error, I still think that the operation of publishing one's own ATX should be atomic with recording it in the database (and, additionally, that a node should always check whether an ATX could be considered malicious before publishing it).

The logs are a bit misleading. The node will ALWAYS validate an ATX it publishes before it does so. broadcast has to go through the same validators as an incoming ATX has to go through, so only if those pass (and that includes a check that no other ATX for the same identity in the same epoch exists already) the ATX will actually be broadcasted.
The problem here is that the device the node tries to write its state to is read only. This also means the node you have posted the logs from is restarted it will have to skip a full epoch of rewards because it doesn't know that it already registered at a PoET.
We are right now in the process of refactoring the relevant code in the activation package. Part of that refactoring has already happened in https://github.com/spacemeshos/go-spacemesh/pull/5207. More is currently under review in https://github.com/spacemeshos/go-spacemesh/pull/5219 - planned to be merged with a group of other changes after 1.3.0 is released and part of the release after 1.3.0.
Additionally I'm planning on rewriting the relevant code in the activation package into a finite state machine which will ensure that a) state transitions are happening atomically at clearly defined events and b) current state of the ATX building process can be more clearly communicated to the user via the state the machine is in and events that can be emitted during state transitions.
In summary - I don't see a critical bug here; the logs are misleading and the node will after successfully publishing an ATX try to (unsuccessfully) publish another ATX. The quick fix for this issue is to allow writes to /Volumes/SMESHER04/post/7c8cef2b

The quick fix for this issue is to allow writes to /Volumes/SMESHER04/post/7c8cef2b

Doing this (plus a restart) caused the node to publish a second ATX and equivocate ;)

@fasmat I still don't understand how the node could have managed to publish its own ATX without recording that fact in the database. The state DB remained on a device that was writable, and everything else worked fine.

Here is what I think might have happened:
2023-12-14T17:22:19.643-0500    INFO    3c84c.post      proving: generated proof        {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "post"}
2023-12-14T17:22:19.793-0500    INFO    3c84c.nipostBuilder     finished post execution {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder", "duration": "6h55m22.843336959s", "name": "nipostBuilder"}
2023-12-14T17:22:20.842-0500    INFO    3c84c.nipostBuilder     finished nipost construction    {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "nipostBuilder"}
2023-12-14T17:22:20.842-0500    INFO    3c84c.atxBuilder        awaiting atx publication epoch  {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxBuilder", "pub_epoch": "10", "pub_epoch_first_layer": "40320", "current_layer": "44236", "name": "atxBuilder"}
2023-12-14T17:22:20.951-0500    WARN    3c84c.atxHandler        atx failed contextual validation        {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxHandler", "requestId": "c9c46686-4860-4c3a-badc-8de4ff7e577c", "atx_id": "debf494f7b4b849fd2d1e017f291b96c833fdfa6899c6159203b164b7da
3fd79", "smesher": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "errmsg": "last atx is not the one referenced", "name": "atxHandler"}
2023-12-14T17:22:20.952-0500    WARN    3c84c.atxHandler        smesher produced more than one atx in the same epoch    {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxHandler", "requestId": "c9c46686-4860-4c3a-badc-8de4ff7e577c", "smesher": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9d
bf2b767ae9a67bbe7fbb7b", "prev": {"atx_id": "62332b4f1a", "challenge": "0xc757ce06980f388a2ec8d1cee8ba6f1dbb2740ce23f069ab783f0b02d4f1c49b", "smesher": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "prev_atx_id": "ea7e2ceb82", "pos_atx_id": "ea7e2ceb82", "coinbase": "sm1qqqqqqz3yyrkk4zr8wesmu04f77jxyel6pxvv9
sxf8afx", "epoch": 10, "num_units": 58, "effective_num_units": 58, "sequence_number": 4, "base_tick_height": 84399, "tick_count": 9392, "weight": 544736}, "curr": {"atx_id": "debf494f7b", "challenge": "0xc757ce06980f388a2ec8d1cee8ba6f1dbb2740ce23f069ab783f0b02d4f1c49b", "smesher": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b76
7ae9a67bbe7fbb7b", "prev_atx_id": "ea7e2ceb82", "pos_atx_id": "ea7e2ceb82", "coinbase": "sm1qqqqqqz3yyrkk4zr8wesmu04f77jxyel6pxvv9sxf8afx", "epoch": 10, "num_units": 58, "effective_num_units": 58, "sequence_number": 4, "base_tick_height": 84399, "tick_count": 9392, "weight": 544736}, "name": "atxHandler"}
2023-12-14T17:22:20.954-0500    WARN    3c84c.atxHandler        failed to process atx gossip    {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxHandler", "requestId": "c9c46686-4860-4c3a-badc-8de4ff7e577c", "sender": "12D3KooWRByEPQFCypeTd45WN5UESWnxjKbVcF3LE6epzz4EgqkK", "errmsg": "c
annot process atx debf494f7b: cannot store atx debf494f7b: malicious atx", "name": "atxHandler"}
2023-12-14T17:22:20.954-0500    WARN    3c84c.atxBuilder        failed to publish atx   {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxBuilder", "sessionId": "0f8cdd3c-181c-487f-83ba-e38ed5e4bbda", "layer_id": 44236, "epoch_id": 10, "errmsg": "broadcast: failed to broadcast ATX: fail
ed to publish to topic ax1: validation ignored", "name": "atxBuilder"}
2023-12-14T17:22:20.954-0500    WARN    3c84c.atxBuilder        unknown error   {"node_id": "3c84ca76e567ca6c20d50931de027d1c8c3c5bdc9dbf2b767ae9a67bbe7fbb7b", "module": "atxBuilder", "sessionId": "0f8cdd3c-181c-487f-83ba-e38ed5e4bbda", "errmsg": "broadcast: failed to broadcast ATX: failed to publish to topic ax1: validation igno
red", "name": "atxBuilder"}

Node detected correctly that it already had published an ATX and did not publish it again.

something happened (node restart?) -

Node tried a 3rd time to publish and succeeded for some reason - I do not know why.

@fasmat I still don't understand how the node could have managed to publish its own ATX without recording that fact in the database. The state DB remained on a device that was writable, and everything else worked fine.

It did it even complained that it won't publish another ATX because there is already one in the DB.

Had a chat with @fasmat. We agreed:

We should make sure a node never generates and publishes a malfeasance proof against itself (which happened here)
@fasmat is working on rewriting all of this logic as a finite state machine, as mentioned above. We'll make sure that the state transitions of this machine are atomic to prevent this sort of issue in future.

Fixed in #5518


Yet another in(secure) patch

Do not consider all additional registries as secure. Check the list
of insecure registries before marking additional registry as secure.
This covers expecially the case of registries running on localhost.
Signed-off-by: Michal Minar<EMAIL_ADDRESS>

I think we should consider all Registries as secure, and force customers to identify insecure-registries.  Or is this doing that?  IE If I --add-registry foobar.com --insecure-registry=foobar.com

The case you mention works - foobar.com will be considered insecure (fallback to port 80 will work).
The cases that currently fail and should succeed (at least upstream succeeds):

--add-registry localhost:5000 unless --insecure-registry localhost:5000 is also passed
--add-registry <IP_ADDRESS>:5000 unless --insecure-registry <IP_ADDRESS>:5000 is also passed
--add-registry foobar.com:5000 --insecure-registry foobar.com

In other words additional registry must match exactly some entry in insecured registry list to be considered insecure.


No Github release nor Tag

1.5.2 - But it's already on https://play.google.com/store/apps/details?id=com.mattermost.rn

And again for 1.10.0

And for 1.11.0 again
Fixing #566 would help 👉👍

@enahum

published

https://github.com/mattermost/mattermost-mobile/releases/tag/v1.11.0

And for 1.18.0 ?

@enahum?

release for 1.18 https://github.com/mattermost/mattermost-mobile/releases/tag/v1.18.0

And again for 1.22.0...

Yet again for 1.29.0...

bump


Put safepoint before prologue (or before calls)

I think some of the sampling profiler's surprising results may be because it is overcharging small procs with time spent in their parent proc. We need to safepoint before entering a procedure so that time spent in the caller is accurately charged before entering the callee.

This would explain some surprising results that I saw.
On Nov 9, 2011, at 9:19 PM, Joe<EMAIL_ADDRESS>wrote:

I think some of the sampling profiler's surprising results may be because it is overcharging small procs with time spent in their parent proc. We need to safepoint before entering a procedure so that time spent in the caller is accurately charged before entering the callee.

Reply to this email directly or view it on GitHub:
https://github.com/slavapestov/factor/issues/379


:sparkles: Add idempotency to processing WAL events #689

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#692  👈 (View in Graphite)
#691
main

This stack of pull requests is managed by Graphite. Learn more about stacking.


Proposal: make pathItem oneOf object, array

The Swagger 2.0 schema defines pathItem as an object.
If either an object or an array were supported via oneOf or anyOf, all of the assorted requests about how to handle query string params or overloading of endpoint behavior could be dealt with in one shot.
This could be added to 2.0 without breaking backwards compatibility, and seems as though it would require only minor tooling changes. (I say this having gone through swagger-codegen pretty thoroughly.)

OpenAPI 2.0 will not be changed, but this could be one possible solution of #146 and related issues for 3.0.
Parent Issue: #574 .

FWIW, as voiced in other tickets, I'm pretty much against the usage of oneOf, anyOf, allOf or any JSON Schema construct usage outside the scope of the Schema Object to express such things. There are simpler ways to do it without making the structure of the spec a pain to write. Granted, it may not be cover all use cases, but it's a trade off.

As opposed to what @webron is against, we've merged the above constructs for 3.0.  Closing this.

@fehguy Where can I see this change manifested?  I've look through the 3.0 spec on the OpenAPI.next branch, but don't see anything obvious related to this.  In https://github.com/OAI/OpenAPI-Specification/issues/487, it is proposed that the pathItem definition be changed to use oneOf, allOf, etc., but I still see the individual operations defined as single Operation Object instances.
What am I missing?


504 gateway timeouts

Hi guys,
using one GPU works better than working with 4 GUPs e.g.
I am running it on LightningAI and not even one request goes through at all if running on 4 devices.
server = LitServer(SimpleLitAPI(), accelerator="cuda", devices=1, timeout=60)
vs
server = LitServer(SimpleLitAPI(), accelerator="cuda", devices=4, timeout=60)
Any hint?

This has regressed with the last changes. @aniketmaurya can you bisect?

hi @grumpyp, thank you for reporting. I am not able to reproduce this issue. Could you provide a reproducible example or maybe we can connect over a quick call to debug this quickly?

@aniketmaurya would love to hop on a call yes. I am on your Discord - same username - feel free to ping me once you're available. Appreciate your help!

thank you @grumpyp! DM'd you on Discord.


Fixed assert when calling cancel_alarm(0) (Fixes #1172)

Cancelling an alarm with ID 0 will currently trigger this assert: assert(alarm_id != pool->alarm_in_progress). This is due to the fact that alarm_pool_t::alarm_in_progress is set to 0 to denote that no alarm is in progress. The assert does not consider this and falsely assumes that there is an alarm of ID 0 in progress.
One might think that ph_contains_node(pool->heap, id) would return false because a node of 0 was never inserted. But this is not the case. The root_id of an empty heap is 0 and therefore 0 will be considered to be contained in it, even though it was never explicitly inserted using ph_insert_node(). This behavior could be considered a bug in itself, and is what probably lead to this issue,  it is not at all obvious to a user of the heap. However, I did not consider this with my fix.
This PR fixes the issue by returning early if an ID of 0 is provided.

did you encounter this in practice? an alarm_id of 0 is never a valid alarm id, so it is arguably a bug to pass it.

Yes, I did encounter this in practice. Not in code I wrote myself but in a project I was trying do debug. This is the pull request that fixes the issue in the project I was working on: https://github.com/OpenStickCommunity/GP2040-CE/pull/50
I understand the argument that 0 is an illegal value and therefore the assert is justified. But this is not mentioned in the documentation. Instead, the documentation says that cancel_alarm() will return false if the alarm does not exist. Which suggests that passing IDs to non-existent alarms is a legal operation. There is no way for the reader to learn that they can pass all IDs but 0.
Besides, many API users will intuitively initialize their alarm IDs with 0. I believe that forcing zero-checks into the client code for calls to cancel_alarm() makes for a bad developer experience.

fixes #1172


Bad readme link URL

The URL on the View days example in the readme points to localhost.
Nice library, thanks !

Oops. That was silly. Fixed it. Thanks


Adapter doesn't start when querying Air Quality

The problem
Cannot start adapter due to this error:
`

meteoblue.0
2024-11-11 14:26:42.590
error
[getMeteoblueData]: parameter sigmalevel (m above ground) needs to be specified

`
Version of Node.js
20.18.0
Version of ioBroker js-controller
7.0.2
Version of "meteoblue"-adapter
0.1.0-beta.14
Version of "admin"-adapter
7.2.6
Operating system incl. version running ioBroker
Raspianx64
Checklist of files to include below

[ ] iobroker.current.log (Please share the logs in debug mode and check that there are no personal information)
[x] Contents of the JavaScript browser console (always include in cases of issues with the user interface)

Additional information & file uploads
Api request from browser is working

Ok just found out the adapter start is aborted when "air-quality" is selected. However, that's exectly what I want


Folder list has vanished

After logging in and choosing a project the folder list is empty.

Thanks för your answer !
I have logged in and out many times and the result is always the same.
Other projects work fine for me so it most likely related to this specific project.
The repo is at
https://github.com/callistaenterprise/callistaenterprise.github.io.git

Seems like the project is private, is there any way I can make is accessible for you anyway ?

If you don't care to keep it private, you could easily make it public. However, I would double check that you don't have any secure credentials in any files, and that you don't have any sensitive information (ssh keys, etc) in the repo or in the git history.
https://help.github.com/articles/making-a-private-repository-public/

You can also send me a screenshot of your browser's console, that might help.
In your browser, navigate to the repo that's causing problems, open your console, and refresh the page. If it's producing an error it should be readable in the console. You can google how to open the console for the browser you're using.

Ok, teh console contains prose.js:34 Mixed Content: The page at 'https://prose.io/#callistaenterprise/callistaenterprise.github.io' was loaded over HTTPS, but requested an insecure script 'http://beta.callistaenterprise.se/api/prose/persons.jsonp'. This request has been blocked; the content must be served over HTTPS.

I see that we have references to the beta site and its not https so the error is obvious. Need to change to https or remove the references.

Thanks for the advice on looking at the console.


Add RFC 007, PageConfigs

Rendered

I've renumbered it, as suggested.

I agree this aspect of Wagtail is badly in need of a clean-up - thanks for tackling it @timheap!
I like the idea of 'wrapping' models in helper classes that provide the configuration for a particular problem domain, instead of cramming the base model with peripherally-relevant settings and methods - like django.contrib.admin does with ModelAdmin classes, and Django Rest Framework does with serializers. We should absolutely do more of that. (I'm sure the design pattern folks must have a name for this - I really should read the Gang Of Four book some day...)
Do we gain anything from having a central PageConfig registry for these things, rather than each module defining their own distinct wrapper? (It seems to me that PageConfigs are liable to get just as bloated as Page models do at the moment.)
There are a few things I'm reluctant to offload to a wrapper class - to me subpage_types and parent_page_types are fundamentally model-level properties. While all the things I've talked about above (API, search, sitemap, Django admin, Wagtailadmin) are effectively different views on the data model, subpage_types / parent_page_types are part of the data model - business rules about how the page tree is structured (which wagtailadmin, the API etc are in turn expected to adhere to).
Probably the toughest decision for me here is what to do about the whole page template rendering infrastructure. The principle of Page being "a model that knows how to render itself in response to requests" was basically the whole premise Wagtail was built on - yes, it does break MVC, and that was a conscious design choice, on the basis that a content-managed website is not the same thing as a conventional web app (in a web app, views exist in fixed locations; on a content-managed site, they move around, so it's appropriate for our 'views' to actually be database objects). That doesn't mean we have to set that design in stone, though... The other benefit of wrapper objects (besides splitting up the code) is the ability to have multiple wrappers for the same model - something often seen in DRF's serializers, where you often want 'summary' and 'full' serialisations of the same model - and that's something that could be very relevant here, allowing multiple renderings of a page in line with the whole "create once publish everywhere" philosophy.

I agree that individual configurations would be technically cleaner, but I don't think it strikes the right balance between technical purity and developer usability. Consider the configuration for a searchable, sitemappable, static-generatable page:
from .models import MyPage

@register_page_config(MyPage)
class MyPageConfig(PageConfig):
    subpage_types = []
    base_form_class = MyPageForm
    content_panels = [
        # ...
    ]

@register_search_config(MyPage)
class MyPageSearchConfig(SearchConfig):
    search_fields = [
        # ....
    ]

@register_sitemap_config(MyPage)
class MyPageSitemapConfig(SitemapConfig):
    def get_sitemap_urls(self, page):
        return ['/', '/foo/', '/bar/']

And then repeat this for another few pages. I think we will loose a considerable amount of convenience and developer friendliness that currently exists with the way Wagtail groups everything together. Split across multiple files, and the sheer number of files with tiny snippets of configuration would become unmanageable in a different way. It would also make interactions between different mixins difficult. Consider a RoutablePage that knew how to automatically fill out get_sitemap_urls, for example. Finally, sharing any common code for a Page type between multiple configuration classes would be difficult.
If you swap how you think about the models vs. configurations, I think I can convince you that the PageConfig class is the correct place for the parent_page_types/subpage_types. Currently, the Page model class is the sole source of truth about what a Page is. This proposal turns this on its head completely, making the PageConfig class what makes a Page a Page. The model just happens to be where the data for a Page instance is stored. The PageConfig defines all the behaviour of how a Page interacts with the Wagtail system, including where Wagtail should look to find data for this Page type. The model becomes the secondary class, and the PageConfig is the real deal.
This then makes it clear where the rendering functionality should live: on the PageConfig, which is what makes a Page a Page. The model merely stores the data for the PageConfig to use later when needed. It also adheres more to the MVC ideal, and opens up the possibility of multiple renderings for the same underlying datastore.

On a sidenote, I feel like the Proxy page models RFC https://github.com/torchbox/wagtail/pull/1736 is meant to solve some of the same issues: i.e. having a separate entity in the admin that renders the page with a different template, without duplicating the data definition. But instead of registering a page config, it works by subclassing a page. Although, I guess it doesn't make things much more MVC-like.


kCFErrorDomainCFNetwork error 304

Consistent message when trying to use Hermes on a system with the following specs:
macOS High Sierra
Version 10.13.3 (17D102)
Model Name:	MacBook Pro
Model Identifier:	MacBookPro11,4
Processor Name:	Intel Core i7
Processor Speed:	2.2 GHz

I have the same problem.

I had the same issue days after resolving the expired cert issue. I signed out and back in of my pandora account and it worked again.

This solved it.


How to get involved in the community

Description
A brief description of the question or issue:
You can also join the discord community here
Feel free to check out other cool repositories of EddieJoaude Community here

How do I get to contribute to an open source project for beginners

hi @Antonynans I see you closed the issue, I will still reply 🤓
Invitation sent for the GitHub Organisation. Welcome to the community 🎉
Don't forget after accepting to make it public so it appears on your github profile for everyone else to see, you can do this by finding your name in the github organisation list and change the dropdown to public https://github.com/orgs/EddieJaoudeCommunity/people
Tips for practicing:
Customise your GitHub profile, here is a live stream on it https://www.youtube.com/watch?v=cT6GXCuS0Zo
Practice repo, instructions how to add your name to the README in the README https://github.com/EddieJaoudeCommunity/hacktoberfest-practice
Remember contributing to open source is not just about code, its about collaboration, communication and adding value
I hope that helps


correct Ippon blog URL

Previous URL was leading nowhere

Thanks!

Feel free to send more zuul related links/articles our way. We will link them here.