The difference between previous version with new version.

Hi, thanks for your great work. Could you please tell me the difference between previous version with new version？What have you done to improve your miu from 70 to 73？

Hi, there are three main differences:

We didn't fine-tune the CLIP model in the latest implementation.
The backbone network including 1x1 convolutional layer was purely initialized from the pre-trained multi-label classification model 'res50_cam.pth'.
The CBS Loss. Please check more details in the source code.

If you would like to cite our paper, please cite the performance in the CVPR version. We will update the paper and upload code for COCO in the coming month.
BTW, welcome to star our project！ ：）

Actually, with SAME DeepLabv2, the performance is boosted from ~69 to ~71 mIoU.

Thank you very much! I will follow your next work.


after registering a new account and landing on the home page, the register button in still displayed in the top right

It seems like maybe this has been fixed? I can't seem to replicate it any more.

@myieye was this fixed by you?

Duplicate if #171


Error on parsePaste

It seems that parsePaste throws an error when copy pasting data from excel.
The error I am encountering is
Uncaught TypeError: Cannot read property 'forEach' of undefined
    at DataSheet.handlePaste

My Datasheet is merely doing this...
<Datasheet
    data={...}
    parsePaste={(pasted) => {
                     console.log("Pasted data:",pasted);
                }}
    ...
/>

The error seems to be coming from this line 👇🏽
https://github.com/nadbm/react-datasheet/blob/ef80a69659570166475f5d6520dd446d63e26ec0/lib/DataSheet.js#L264
Using Version 1.3.15

@nadbm @annjawn  any update on this? even i am facing same issue. looks like onCellsChanged is getting triggered and in that the pasteFlow but with no data


Feature request: Convert JSON data back to an Excel-friendly format

It would be awesome to be able to go back and forth at will between JSON and CSV or something similar!

I 100% agree with this.  Right now its useful but not 100% useful.


Built some of the checkout component

I built out some of the basic parts of the checkout component. A lot more needs to be done.

basic setup for the checkout page


Added downgrade(handler) export to help freeing memory.

The upgrade(node) attach as many registered handlers per each element,
and handlers are sandboxed per node, meaning these are never exposed.
However, internally, once a sequence of operations has been satisfied,
one might decide to fully release a handler for a specific node.
This export helps explicitly freeing handlers whenever this is needed,
so that once downgraded, no element, nor events, or lifecycle events,
will ever be available again.

OK, after thinking about downgrade and try various implementations, I came to the conclusion that it's not worth it, as code would bloat, and each element can be handled by many definitions, which makes everything more complicated than it should.
This feature was also not requested by anyone in particular, but any handler that should stop working, in some condition, could simply use a disabled flag, defaulting to false:
define('.toggled-handler', {
  disabled: false,
  connected() {
    if (!this.disabled)
      console.log('OK');
  },
  onClick(event) {
    if (!this.disabled)
      console.log(event);
  }
});

A basic helper that guards all methods might also be used:
const disabled = definition => {
  definition.disabled = false;
  for (const key in definition) {
    const method = defintion[key];
    if (typeof method === 'function')
      defintion[key] = function () {
        if (!this.disabled)
          return method.apply(this, arguments);
      };
  }
  return definition;
};

And be used like:
define('any-thing', disabled({...}));


controller sending many pod delete requests that result in 404 response

Pre-requisites

[X] I have double-checked my configuration
[X] I can confirm the issue exists when I tested with :latest
[X] I have searched existing issues and could not find a match for this bug
[ ] I'd like to contribute the fix myself (see contributing guide)

What happened/what did you expect to happen?
although this seems to have no effect on the functioning of argoworkflows it could be potential stability/performance/k8s log cost issue at scale. it must be also filling up the cleanup queue so delaying cleanup of pods that really do exist
from checking the k8s api server the wfcontroller seems to be sending delete pod request for <podname from a step>-agent and getting not found response. i am using standard workflows like whalesay example. not sure what significance of agent suffix is (i did see https://github.com/argoproj/argo-workflows/blob/66680f1c9bca8b47c40ce918b5d16714058647cb/workflow/controller/agent.go#L25)
seeing 1000s of these, seems for every pod run its sending this unrequired delete request for pod with -agent suffix?
Version
3.4.11
Paste a small workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
n/a

Logs from the workflow controller
kubectl logs -n argo deploy/workflow-controller | grep ${workflow}
n/a

Logs from in your workflow's wait container
kubectl logs -n argo -c wait -l workflows.argoproj.io/workflow=${workflow},workflow.argoproj.io/phase!=Succeeded
n/a

For reference, this was previously noted in Slack

not sure what significance of agent suffix is

As far as I understand, the "agent" is a piece of the Executor that runs for certain built-in, non-container template types (e.g. resource, http, data, etc). Anyone else please correct me if I'm wrong; the historical references to agent didn't quite have a standard definition.

seeing 1000s of these, seems for every pod run its sending this unrequired delete request for pod with -agent suffix?

That sounds like it might be accidentally assuming that each Pod has an agent, when there are only certain types that do 🤔

https://github.com/argoproj/argo-workflows/blob/66680f1c9bca8b47c40ce918b5d16714058647cb/workflow/controller/operator.go#L2369 seems to be the line assuming each pod has an agent.

The agent pod will only be created if taskSet is not empty.
https://github.com/argoproj/argo-workflows/blob/5c8062e55d975aab117e37c7592c0a648a9e9860/workflow/controller/agent.go#L32-L46
Only http and plugin template will be put into taskSet right now.

@jswxstw do u want to create PR?

@jswxstw do u want to create PR?

I see you have created a PR and it looks good to me basically.
The only problem is that you can use the existing function woc.hasTaskSetNodes() to determine whether the deletion of AgentPod is necessary, rather than create a new function woc.hasNodeWithAgentPod().


wasmer uses a .dll

When I download from a github action godot engine fails to execute.
Expected to use a static library.
A .dll side by side is not so good.

A little more context here might help. I'll add an issue template at some point to prompt for some more details.
Godot version: https://github.com/V-Sekai/godot/commit/dcd050b7109c770d8b5e2a5520ac91202d071f53
Godot Wasm version: https://github.com/V-Sekai/godot-wasm/commit/74e52787dc8f92cf0672b5b3760f86324085f345
OS: Microsoft Windows Server 2022 10.0.20348
Build target platform: Windows
@fire Is the compiled editor looking for the Wasmer DLL or the Godot Wasm DLL? Can you add the actual error?

The compiler editor is looking for a wasmer.dll. If you place it beside the executable it should work.
I prefer to somehow have a static library so instead of three binaries [godot.exe, wasmer.dll, game.pck] it'll be two and one binary if we embed the pck.

Makes total sense. Wonder if changing the Wasmer library suffix to .lib rather than .lib.dll would do the trick.

Does https://github.com/wasmerio/wasmer/releases/download/v3.3.0/wasmer-windows-gnu64.tar.gz provide static libs?
I don't see evidence of this.

That's a separate issue, no? Your build is using MSVC which downloads https://github.com/wasmerio/wasmer/releases/download/v3.1.1/wasmer-windows-amd64.tar.gz which contains static libs.

Ah mistaken. Let me check

Not sure how we got here.

Hey it's one step closer! At least the engine compiles. I've dusted off the ol' Windows box so will have a better idea of what's happening. In the meantime, is it worth trying to load with a DLL present? Might tell us if there are any further issues.

Testing
> git diff
diff --git a/modules/wasm/SCsub b/modules/wasm/SCsub
index 0d1906da742..09e00993b9a 100644
--- a/modules/wasm/SCsub
+++ b/modules/wasm/SCsub
@@ -16,7 +16,7 @@ elif env["platform"] in ["osx", "macos"]:
     module_env.Append(CXXFLAGS=["-std=c++17"])
     env.Append(LINKFLAGS=["-framework", "Security"])
 elif env["platform"] == "windows":
-    env["LIBWASMERSUFFIX"] = ".dll.lib"
+    env["LIBWASMERSUFFIX"] = ".lib"
     if env.get("use_mingw"):
         env["LIBWASMERSUFFIX"] = ".a"
         env.Append(LIBS=["userenv"])

I'll kludge it by disabling the wasmer module compiling for msvc but keeping mingw support while I wait.

Looks like when Godot Wasm was swapped to use static libs (https://github.com/ashtonmeuser/godot-wasm/commit/f8a84cfb9ae02ac86dc670e3921d20c729e96a00), no change was made to MSVC compilation. Same problem exists for all MSVC builds. See below for dependencies of the DLL created for Godot 3.x GDNative addon.

I've got a fix for this but haven't had much of a chance to implement today. Will update shortly.

I saw an update!

Should be fixed with https://github.com/ashtonmeuser/godot-wasm/commit/29356da3fbbffe2d33f7210c7742d699178a867d (Godot 3.x) and https://github.com/ashtonmeuser/godot-wasm/commit/2999e89a5f65e91625ad7a728c318b577439b98b (Godot 4.x).
The root cause was an issue with statically linking Wasmer which in turn is caused by an issue with the Wasm C API. I've fixed it with a hotpatch and will open an issue upstream.
Explanation
I didn't fully understand how C libraries in Windows worked. TL;DR: A .lib file can be either a static library or an import library. A DLL isn't a perfect metaphor for a *nix dynamic library as it hides it's symbols. It requires an import library (also .lib extension) to expose symbols. Wasmer provides both static and dynamic libraries in their Windows release artifact and differentiates the two with .lib and .dll.lib, respectively.
The Wasm C API (and thus Wasmer) assume all Windows implementations use the DLL and call __declspec(dllimport) if the _WIN32 define is present e.g. Windows or MinGW. Using the static .lib with __declspec(dllimport) was declaring but not defining symbols (citation needed; I'm out of my depth here).
Very related to https://github.com/ashtonmeuser/godot-wasm/issues/26. In fact, we nearly accidentally solved this. The other piece of information that lead to the solve is here: https://github.com/wasmerio/wasmer/issues/3298. Interestingly, the exact bug in Wasmer/Wasm C API was pointed out by a user there but I dismissed it in favour of dynamic linking. Didn't recall this when moving to static linking in https://github.com/ashtonmeuser/godot-wasm/commit/f8a84cfb9ae02ac86dc670e3921d20c729e96a00.

@fire I'll keep an eye on your build. Let me know if we're good to close this.

I am having trouble apply the patch on windows 11 on the windows command prompt with msvc.
Also, LINK : fatal error LNK1181: cannot open input file 'userenv.lib.windows.editor.double.x86_64.lib'

The build failed on Github actions.

Failed job
link @C:\Users\RUNNER~1\AppData\Local\Temp\tmpi87egrjz.lnk
   Creating library bin\godot.windows.template_release.x86_64.lib and object bin\godot.windows.template_release.x86_64.exp
wasmer.lib(std-2e5a4fde2066d4f2.std.db95cb0e-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol __imp_GetUserProfileDirectoryW referenced in function _ZN3std3env8home_dir17hca690f225b519101E
bin\godot.windows.template_release.x86_64.exe : fatal error LNK1120: 1 unresolved externals
scons: *** [bin\godot.windows.template_release.x86_64.exe] Error 1120
scons: building terminated because of errors.
[Time elapsed: 00:51:36.272]
Error: Process completed with exit code 2.

This doesn't feel related to Godot Wasm but I could be wrong. Lemme check on my end. I should really set up a minimal module build workflow for this repo.

__imp_GetUserProfileDirectoryW is https://learn.microsoft.com/en-us/windows/win32/api/userenv/nf-userenv-getuserprofiledirectoryw
aka "userenv"

Nice find! Guess we can take out the MinGW check but that might put us back to exactly https://github.com/ashtonmeuser/godot-wasm/issues/27.

Fixed.


Docs : improve CSS/responsiveness of "Ask for help" button

https://user-images.githubusercontent.com/939999/232438856-81e6acb4-ffb3-413d-8ac1-7abcae05386d.mp4

fixed recently


Perfect should be more "Swifty"

We'd heard from a few people that Perfect isn't as "Swifty" as it should be. We'd love to hear what this means to you, and where you think we could improve Perfect to be more so. What is "Swifty" to you that Perfect isn't?

Hi :) There were two main points that I've stated during presentation when I was sharing that opinion: the lack of Swift Package Manager support and the lack of modularity. Both makes it way harder to use Perfect along with the rest of Swift ecosystem.
However, I can see there's already work in progress on SPM support, which is great. It will hopefully make it way easier to switch some components, like adding alternative templating engines or data serialization/deserialization libraries.
I guess I haven't said much new, since this is what you've already doing :)

Thanks @siejkowski - you're right, we're working on both SPM and modularization, and your comments reinforce the need for us to work on these.
Was there anything in particular - for either, or anything else that comes to mind - that you thought we should consider?

"More swifty" I think that is what i was trying to say when I opened  #134.

My personal take, as the main author:
The project was created in a modularized fashion to begin with. We had a core library of utilities, around that a variety of server types as separate executables, and a variety of database connectors as separate modules. It's true we include a templating engine and JSON encode/decode utilities, but those are provided as a convenience and nothing in the system forces you to use them or prevents you from using your own.
We are marching towards SPM but it's important to remember that SPM is still heavily in flux, has not yet had a full release and isn't slated to do so for quite some time. While it certainly shows promise, it's currently a bit limited (unable to incorporate C targets) and somewhat cumbersome (git repo all the things) to use. Not to get all stodgy, but I'd prefer a generic makefile. :) It is steadily improving though so I don't mean to be disparaging.
Also please note that Perfect was released before SPM existed, so yes, we have a little work to do to fit into how it wants things done.

Other than modularity and SPM compatibility (both active discussions with ongoing effort being expended to address them) - I'd love to unpack if there is anything else that we could address on the subject of "swiftness" vs. other platforms or just "for swiftynesses sake". Any suggestions on other developers we could ask about this?

I think the bigger topic here that hasn't been mentioned is the quality of the codebase. While I don't want to just flat out say that the code is "ugly", I think I won't be the first to say that it's not "swifty".
The things that makes Swift beautiful and modern are, in my opinion, the shifts from (this is not a comprehensive list):

inheritance to composition (class -> protocol with extensions, final attribute used by default)
imperative code to functional code (use of higher-order functions)
primarily reference types to primarily value types (struct over class where possible)
mutability to immutability (let by default, var only if necessary)

Perfect's codebase doesn't do a wonderful job of following these patterns. I don't think its fair to say that Perfect has been written in Swift until it does a better job of doing so. Unfortunately, fixing this means rewriting a large part of the project, potentially from scratch.
I hate to be so brutal, but if Perfect actually wants to be "perfect" in the context of Swift libraries, there's a lot of work to be done.

Great feedback! Thanks! Although I can't help but consider that as one of the lead contributors to other "competitive" projects to Perfect from before Perfect was released (Zewo and Taylor), you might have a slight bias. ;)
Quickly picking through Perfect, I genuinely don't see many examples of what you are suggesting. For example, mutability to immutability - I couldn't find a single instance in Perfect code. Although as Perfect is the largest codebase in the server-side swift space by far, you would be correct in saying that if we have been doing something wrong for the last 14 months, it would be a big rewrite.
Perhaps I'm coming off as defensive, for which I apologize - but if you can show us specific examples, it would be very helpful. (Especially ones which aren't just one person's coding style, but visibly a departure from idiomatic Swift).
Thanks @Danappelxx !

public func PerfectServerModuleInit() {

	// Install the built-in routing handler.
	// Using this system is optional and you could install your own system if desired.
	Routing.Handler.registerGlobally()

	Routing.Routes["GET", ["/", "index.html"] ] = { (_:WebResponse) in return IndexHandler() }
	Routing.Routes["/foo/*/baz"] = { _ in return EchoHandler() }
	Routing.Routes["/foo/bar/baz"] = { _ in return EchoHandler() }
	Routing.Routes["GET", "/user/{id}/baz"] = { _ in return Echo2Handler() }
	Routing.Routes["GET", "/user/{id}"] = { _ in return Echo2Handler() }
	Routing.Routes["POST", "/user/{id}/baz"] = { _ in return Echo3Handler() }

	// Test this one via command line with curl:
	// curl --data "{\"id\":123}" http://<IP_ADDRESS>:8181/raw --header "Content-Type:application/json"
	Routing.Routes["POST", "/raw"] = { _ in return RawPOSTHandler() }

	// Check the console to see the logical structure of what was installed.
	print("\(Routing.Routes.description)")
}

class IndexHandler: RequestHandler {

	func handleRequest(request: WebRequest, response: WebResponse) {
		response.appendBodyString("Index handler: You accessed path \(request.requestURI())")
		response.requestCompletedCallback()
	}
}

This code snippet shows examples violating all items on @Danappelxx's list. It also has a lot of shared state which wasn't explicitly mentioned on the list, but is related to using structs and immutability.

Ah sorry, to make good on those two points:

Full disclosure, I am on the core team of Zewo and Taylor (though Taylor isn't following a lot of those either, and has pretty much been abandoned at this point)
Immutability vs mutability isn't a very strong point, but here is an example of what I'm talking about. It is a global, mutable variable which is in many ways an anti-pattern. I hate to bring up Zewo as a counter-example, but the approach Zewo uses is, in my opinion, much better - all the routes are finalized at initialization.

I could look harder and bring up more examples, but I don't think its necessary to find a comprehensive list of examples to show my point. Again, I appreciate how much hard work has been put into Perfect and I'm really just playing devil's advocate here.

Hey! The whole gang is here! (Where's IBM?)
Thanks guys - we'll look into your suggestions. :)

@SeanStephens Looks like PerfectlySoft is coming along great. May I ask how well it will work with IBM's Kitura project as you mentioned IBM?  I am very interested in using Swift on Ubuntu LTS on Amazon EC2 where I am also using Python 3, Anaconda and TensorFlow. I'd like to integrate TensorFlow into a REST based access API. I know there's a DeepLearning Kit on Github here for Swift but it's an Apache 2.0 license and doesn't look like there's much activity.

Just wanted to respond to a couple thing I saw you mention off hand - this isn't entirely related but I still think they should be set straight.

Although I can't help but consider that as one of the lead contributors to other "competitive" projects to Perfect from before Perfect was released (Zewo and Taylor), you might have a slight bias. ;)

I think this sort of attitude isn't very healthy for the community. While competition is good for a growing ecosystem, I think that collaboration is even better. As programmers, we don't want to reinvent the wheel at every step and end up with a giant mess of incompatible frameworks and standards. For this reason, Zewo teamed up with Vapor, Swifton, and (partially) Kitura and began work on SwiftX, which is a set of cross-platform standards. Through SwiftX, one could take their Vapor application and without changing a single line of code, serve it from both Zewo's and Kitura's servers. I really don't want to see Perfect as a competitor, but due to certain architectural decisions (SPM and modularity, mostly) its difficult to imagine collaboration or compatibility with one another.

Although as Perfect is the largest codebase in the server-side swift space by far, you would be correct in saying that if we have been doing something wrong for the last 14 months, it would be a big rewrite.

Just wanted to say that the first part of this statement is not true. Here are the outputs of counting the LOC of the entirety of the Zewo organization (with all of its subprojects) vs Perfect.
zewo: 34424
perfect: 20576

EDIT: (Note @tannernelson - that's not the Perfect codebase)

While it's not a snippet from the codebase, it's an example of consuming the API's provided by Perfect, which is really more telling than the implementation itself.

@Danappelxx - it looks like we are in violent agreement! I used the word "competition" in quotes, as we are hardly competitors, except in the friendly sporting spirit sense of the term. "Competition" isn't an evil term and can be very healthy, unless it is used with malice - and I certainly do not use it in that sense.
One of my friends - the owner of one of the largest duck farms in North America - once said to me - "Duck farmers don't compete with other duck farms. They compete with chicken farms." Methinks that in the server-side space, we are beset with "competitors" (from Python to PHP, from Node.js to Java). Ultimately, if we genuinely want to see the possibilities of Swift be realized, we should be working together.
Perfect has some unique advantages already, outside of this GitHub thread. We have years of funding in place; we have access to the massive closed-source codebase of Apple's first server-side language (Lasso - Wiki, Guide - from Lasso version 1 to 9) and the team and community who supported the language for the last 22 years, and the BDFL of the same; we have world-renowned development advisors who have proven successes on speed dial; we have many Apps in production already we are supporting (some with Fortune 500's); we have a strong digital marketing firm and PR firm to lean on; we have a CEO with green hair, etc. This project will never be abandoned - it will be driven hard for years to come with constant ongoing improvement.
Given all of these facts - if it turns out that we need to re-write the whole codebase from scratch because it isn't, well, Perfect, we will. Over and over and over - because that is what we love to do as developers. The name Perfect wasn't intended to be descriptive, it was intended to be aspirational. This is not a quick project idea for us. It's a life choice.
You and @tannernelson, amongst others here, are clearly remarkable individuals with visionary skills and deep understanding of our mutual new love: Swift. Would you consider helping us learn as developers and additionally help improve Perfect's Swiftiness?
I propose we start a transparent wiki  discussing your suggestions, and get you and others in the community to add what they think epitomizes Swiftiness, describe examples and possible fixes of the same, and help flesh out what Swiftiness really means. To a degree, Swiftiness will always be in the eyes of the beholder. But as a community, we could define and realize best practices that we have missed and clarify what styles are best. In the short term, we'll arrange to go fix these things in Perfect - possibly even together. ;)
Then, as a group, we could make something remarkable and useful for years to come. Something as close to Perfect as we together can make it.
Interested?

I'll be straight. I'm in Zewo's core. All opinions stated are mine only.
Currently I have a problem with Perfect. That might change after theses events, who knows. My biggest problem with Perfect is that, in my opinion, you guys are staining Swift's reputation on the server side. This issue was raised because of the code quality. Mainly the "swiftyness" of the code. That's a big problem, but not the biggest. The biggest problem is that you are not community driven. Take those problems with the heavy marketing you have and you get a framework with 6,551 Github stars that does not represent the best for the server side swift community.  I don't know how do you plan on monetizing and how far you would work in the community  's behalf as a result of that. As @Danappelxx mentioned we (different server side swift frameworks) started SwiftX (Swift Cross Project Standards). We think this will really make the community grow. If you want to be Perfect for the community, here's your chance.

@paulofaria Wow, that's heavy! A stain, even!
Obviously Swiftiness is easily curable - it's just time and input from well-meaning developers, and ongoing pressure to improve and tweak - internally and externally.
Where are we failing on the community side? We have hundreds of developers engaged in dialogue with us on chat channels, thousands of developers engaging with us on Twitter, we've been all over the world talking with and engaging with developers at conferences and Meetups in multiple languages, and have dozens of large companies working with us on innovative new ideas and deployment mechanisms. We've connected with tens of thousands of developers in the last few months - and most of them (with the exception of the ones in this thread) seem to be very happy with our efforts and very excited with our project.
Sure, we are a company. But the word "company" isn't an inherently evil concept. We just came together as a unit to provide strength of branding and as an investment vehicle to ensure we can create a stable, reliable product that stands the test of time - and pay people for their efforts. That's not an evil idea (neither is the idea of profit, IMHO), but rather symbolic of community unto itself. Getting paid to do work isn't wrong. We are humans, too. We have kids. They need to eat. Why not make it a company and market our efforts? ¯_(ツ)_/¯
Or is this an attempt to get us to look at your new SwiftX idea under the guise of the "community" banner? It appears to be a new idea (previous links to it didn't work - your post is my first time seeing it - certainly no-one reached out to us in a magnanimous community way), with only a few people engaged. Two people does not a community make.
We'll definitely look into it, now that we know it exists - thanks! :) Maybe we'll bring some laundry soap with us so we don't leave a stain. ;)

I'll have my word here too. I'm not a part of Zewo or QuTheory. But I'm a part of SwiftX and created MongoKitten and I'll explain why your library is horrible for developers, and libraries alike. Not just our but also your libraries.
Your library is bloated. You offer a complete package like Zewo does with the main difference being that you force the developer to use all or none of your libraries. Everything's so integrated that switching away from a part of your library makes you fight the system.
I think some of your things are great, and I think  some are horrible. I want to use the great parts and ditch the bad. But I can't. I need to fight the library and write more code than I should just to make it work.
One day your, mine or anyone's library will not suffice for someone. And they'll do it better. With SwiftX I can change from HTTP Server A to B. From MongoDB Driver A to B, and from router/middleware/socket library from A to B whenever I damn please.
So by locking your developers into a complete package everyone loses.
Your developers spend more time working around issues they have with some of it. Or they'll decrease in productivity opposed to different libraries.

Where was all this great feedback months ago, guys? ;) We could have explained our rationale then.
Methinks there is some confusion as to our intent, or how Perfect is structured at this time. There is no trap, no grand attack on other people's work, no handcuffs keeping anyone using any one part of Perfect or restriction to do so. In fact, our first product had a FastCGI connector for Apache, plus a stand-alone server - giving you various options, from day one. With Perfect you can "change from HTTP Server A to B. From MongoDB Driver A to B, and from router/middleware/socket library from A to B whenever you please". Methinks there is much confusion and FUD being created here. Perhaps people feel left out? That was not our intent. We'd love to work with you guys.
However, a self-respecting professional doesn't keep all their tools scattered around the shop. They keep their core tools neatly arranged in a toolbox. When you need the core tools, there are easily accessible for you - you don't have to spend hours looking for them. Then when you need special tools, you go looking for them. If you need a stronger set of pliers, you add them to what you are carrying. This is core to the principles of lean manufacturing, and also apply to development.
If you only need a single screw driver for a single hobby project or you work on a small team, projects should exist to do so. If you want to get a full-featured toolset to build epic projects and want consistency across your organization - you want a strong, reliable core library accessible in one place. You shouldn't be wasting your time looking - you should be spending your time developing cool new projects.
In fact - a scattered set of tools also makes it very difficult for a new developer to get up and running, or for an older project to get started again after a period of pause. If we are trying to create a gated community for "special" people, every tool should be hidden in a different corner. If we want people to be able to get up and running quickly and effectively, we'll want one toolbox with a quality default toolset that allows people to pick up and run. This makes it easier to work with, and easier to build a strong community.
Whether we like it or not - server-side Swift development is a new category. Server-side Swift developers are unicorns at the moment. They need easy mechanisms to get up to speed, they need everything in one place. This is why we started Perfect this way - to make it easy for new people - to make it easy to build a community around great tools with a great new language - not scrap about whose MongoDB connector is better. That will just be divisive and limit Swift's growth. (And IMHO, this is why we have collected 25,000 Twitter followers in that time - we make it easy for people to understand.)
An example of a toolset that does things in this manner is... Swift. You don't download thousands of pieces to get up and running. You download one project, and use it. And when you need more tools that don't come default in the package, you go get them. I'm also confused - if marketing and capitalism really rub people the wrong way, should you really be working with Apple-backed products? ;)
I will note, we are not against you. I would hope, one day, we can all play in the same sandbox nicely together. We are listening to your suggestions, as a community, and we are working on modularization of our core library (e.g. we released a stand-alone MySQL connector today). We will happily work with you, co-exist with you, and improve with you - and not get in your way. But we aren't giving up, either. Ever.
We will provide a core toolset for developers, all in one package, that makes it easy to get up and running and provides a reliable foundation for the future - a default of excellence. And that doesn't need to be contrary or incompatible with all of the great stuff everywhere else - and SwiftX. Why do people think these ideas are incompatible? That's just silly.
This is a great time to have this conversation, however - as the whole idea is only a few months old, and we have many, many years of future work together. Just because our popularity is high and marketing is good doesn't mean we are the enemy! Let's work together!

I wish you could provide just a thin layer between the web and our own code, no mySQL connectors, or anything else. Only requests are interesting. I wish someone could just cut the cr*p and make something like this.

I agree. We should work together, not against each other. We're all part of the swift community in the end. But I fundamentally disagree with your statement on the developer's toolbox.
I think you're right in one aspect. There mustn't be a need for your boilerplate for a project to contain tens if not hundreds of dependencies. But that is where you misunderstand the need for SwiftX.
SwiftX doesn't require us to split up into tiny fragments. But it allows the user to unify his libraries more easily.
For example: Vapor has it's own build-in webserver. Yet it allows any other SwiftX compliant webserver to plug in as a replacement.
This allows Vapor to be easy to set up (no additional dependencies required) without withholding you from replacing their server with another one that you prefer.
A project like Perfect can still offer the complete package. But there are only 2 ways Perfect could be viable in my eyes.

Perfect adopts a standard like but not necessarily part of SwiftX and cooperates actively with other projects
Perfect splits up into tiny libraries and has a bigger one (Perfect itself) that unifies them

Even if Perfect were to make it's own standards like SwiftX does that'd be a much better option than the current state is.

I'll give you a list of concrete points Perfect can improve on. Some of which might require patience for an upcoming update to swift/SPM:

Get rid of C dependencies where you don't need them
Compile C dependencies with Swift where you still need C dependencies
Don't try to do everything yourself. Other projects with a smaller scope are better able to focus on the goal. Doing a hundred things at once will never be as effective as focusing on a few. We're not programming in Java. This is Swift
Swift has guidelines over here for developing APIs. Try to stick to that as much as possible
Collaborate. Opensource is about collaboration, not competition.  I get that. But if you're developing an OpenSource product. Act like it. Your Apple argument above is completely invalid. Apple collaborates with swift. You compete with the community.

I guess this is when I say I'm not affiliated with any of the teams/frameworks mentioned.
@SeanStephens @kjessup.  I commend you for being open to listen, it requires a special kind of "loving what you do".
A few thoughts:
I relatively new to Swift to make much sense of the code issues mentioned. Being mostly a backend developer I definitely agree a couple of things said there:  that the "compet*tion" is not within but with other frameworks, other languages, and that collaboration would be beneficial to this nascent ecosystem.
In my case, I like the the concept of "starter kit" that you mentioned, which is very convenient specially if you don't have a lot of time to shop around or ...like in my case you are new to the scene and don't know what to choose, just wanted to be able to use SPM, and a way of checking out only certain parts of the repo (submodules).
I'm looking forward to see where you guys are going to take Perfect, knowing that in fact it's not perfect, but it's perfectible.

@Joannis - absolutely fantastic feedback, this is exactly the help we need to make our community stronger. (and @ejohnsonw - thanks of the vote of confidence!)
We could continue ad nauseam on the merits and benefits of a centralized code base vs. hundreds of separate dependencies. Although those who came from the NPM world will be prone to inspirational dependency trees, it's certainly not always a strong coding practise to rely on breaking everything up into little bits and relying haphazardly on everyone else.
I also appreciate - despite many of the contributors to this thread being the leads for the largest server-side projects in the Swift world - that most iOS developers have been well trained to pick and choose what they want like candy at a candy store from different boxes. And for App development, that's a dandy practise.
But those of us who have run companies where thousands of people are calling in after a server melts down (or a cloud node frys), the backup server failed, GIT is down and the codebase fragmentation means it will take weeks to figure out what you did and where you got it from, not minutes - realize that in the server world, reliability and simplicity trumps fancy choices, sometimes. The toolbox idea isn't a bad one - it just may be something you aren't used to. For App work, great. For server work... after 23 years of server-side language work, we'll be hard-pressed to capitulate on breaking up the continent into little countries.
Ergo, fragmenting into a thousand tiny libraries doesn't seem like an effective strategy for Perfect at this time. Nor, in the context of a thousand other magnificent libraries already available (Zewo! Vapor! Kitura! etc.), does it make sense to have one more random set. One big library with a marketing engine behind it is still a great flagship for the server-side Swift community, and benefits everyone.
Having said this - @Joannis , your point on becoming modular and compatible with other community libraries is genius. I'm a little concerned that this thread didn't smack of a magnanimous community engagement, and that we'd be bullied and finger-waggled in SwiftX in particular rather than welcomed - but we will certainly approach the idea carefully and with great interest. And all of your other suggestions are bang on. Some of the suggestions by both yourself and @Danappelxx (and others, off list) have been very constructive and helpful - we have work to do. Thanks for the help. :)
There's room in our nascent ecosystem for both ideas to work together harmoniously. We look forward to working more with you!

we'd be bullied and finger-waggled

That's definitely not true! The first rule of SwiftX, as stated on its documentation, is that it's Inclusive. We'd welcome Perfect with open arms.
The issue here is honestly not the code quality. None of us our perfect. That's why we're working together to create the next generation of server side applications with Swift.
The issue is the marketing strategy that Perfect is employing. Referring to the project as an "enterprise-grade web server" and posting it repeatedly on multiple channels to the point where it's considered spam.  Server side Swift is not ready for the prime time yet. It literally cannot be until Swift 3.0 is released. I think the way you're advertising is misleading to the community. And it's ultimately leaving people with a bad taste in their mouths about Swift in general when they see how unstable it currently is. I know you want to take advantage of Swift's hype to rack up the stars and the followers–everyone wants to be recognized for their work. But that's just not going to help us out to have someone advertising server side Swift as something it's not.

Methinks we've turned to a new subject now: marketing. Lovin' the transparency! It's helpful.
Technically, an "enterprise" is a business or company. Since we seem to be the only fans of companies in this group, doesn't it then seem appropriate that we use the word "enterprise" in our marketing? ;) We aren't the only ones (is IBM here yet? James? You awake?).
http://www-03.ibm.com/press/us/en/pressrelease/49157.wss
I'm not sure I agree that Swift isn't ready for "prime time". Sure, it's not finished. But art is never finished, it's only discarded. We already have dozens of "enterprises" using Perfect in production, happily and safely. Who has a bad taste in their mouth because of Swift's failure to perform? I haven't met a single person who has said that yet, anywhere in the world. On that note - I have to honestly ask, by your line of reasoning: when will PHP be ready for prime-time? Hehe.
 So should we spend the rest of the year marketing that "Swift is pretty pathetic right now - but you should start thinking about it in four or five years and get involved now anyway"? A) it's not true, Swift rocks and b) we should all give up now, because the community is going nowhere, fast.
Big ideas require big claims. Be bold, and then back yourself up. Marketing is based on aspirations, not limitations.  "We believe Swift is the future" is the truth.
Just like companies aren't The Devil, marketing isn't The Devil either. And I'm certainly not embarrassed by accusations of successful marketing against us. We are bold, it works, and I don't feel we should apologize for that - cause its helping everyone. A rising tide lifts all ships. Wouldn't you rather have a marketing machine on your side, pushing for the adoption of server-side Swift from every angle? Are we not a massive asset to your work, instead of a thorn? To fight the chicken farmers of the world on your behalf? To win over PHP and Python and Node guys to come play in our sandbox?
Having said that, if you guys believe using the term "enterprise-grade" is the unique limitation from us from being friends, I can only think of one place in the entire world it exists (our front page), and it doesn't hurt to replace that with something that doesn't rub you the wrong way (Kyle hated that terminology anyway). But we aren't going to stop building enterprise-grade applications in Perfect and Swift just because we are afraid Swift isn't good enough for prime-time yet. It's good enough for us, just as it sits - and it's getting better every day. The phrase isn't untrue.
I'm not sure where we are leaving people with a bad taste in their mouths about Swift - or that really anyone has a bad taste in their mouths about Swift - our how it is "misleading to the community". I've never heard that sentiment before today, nor do I believe we've mis-led anyone. Marketing is a good thing. At the end of the day, Swift exists because of Apple, and Apple exists because of good marketing.
In any case - thanks for the comments about open arms - we feel the same back.
Onwards!

Just want to be clear that my reason to be here is simply because I care about the Swift server side ecosystem. My opinions might be strong but they are well based. I know it's hard to hear such criticism. I'm sure it would be tough for me if I were on your spot. But that's what you get when you're in the spotlight. You should be prepared for this, and this is part of the reason I don't like your marketing machine. You are heavily marketing something that in my opinion doesn't reflect the best, the perfect. And that's what I mean when I say you're staining server side Swifts image. You know that the main author of Perfect does not have a strong Swift background. So you know that the code will show it. This wouldn't be a problem if you didn't have your marketing machine. But when you have code that's not following Swift best practices that's being exposed to a lot of people who never saw Swift before. They're going to think that that is Swift. But it isn't. OK, you're working on that now, and that's awesome. But the damage is done anyway. Because you guys decided to heavily market something that's not the best it can be. You just heavily marketed something built quickly in a small time-frame.  I say this as a Swift developer. Not as Zewo founder. Even if I haven't started Zewo when Perfect was launched I would feel the same way.

Methinks there is much confusion and FUD being created here.

There's no FUD. We just care about Swift on the server side. Let that be clear.

Sure, we are a company. But the word "company" isn't an inherently evil concept.

I Never said that companies are evil. But we all know companies use walled gardens as a strategy. You claim you're not one of these companies. I really hope this is true, because up to now, you haven't proven it with actions. I really hope this will change.

Or is this an attempt to get us to look at your new SwiftX idea under the guise of the "community" banner?

To be honest I was unsure about mentioning SwiftX and actually about showing up here at all. But I couldn't keep these thoughts I'm expressing now to myself. As an active member of server side swift I have this responsibility. The reason we didn't reach out before it's because of this walled garden image you guys pass. And you can't blame it on us for having this view. It's the sum of your actions that made us see you like that. From the first license to whole company thing to the monolithic architecture.
And now we reach the Toolbox example, which is perfect (pun intended haha). You use the analogy of tools for the modules and the toolbox for a collection of modules. Well, that's exactly what Zewo provides. We have a set of tools which you can use separately any time you like. And a toolbox which is nothing more than an umbrella package which imports the most important modules. I agree with everything you say, and it applies perfectly for Zewo. But unfortunately it doesn't apply to Perfect. You don't have a toolbox. You have a blackbox, which you can't take things out. I'm really happy that you guys are working on modularization now. I just think you got the application of the toolbox concept wrong. Hopefully you'll see that having separate modules gives all the advantages you claim if you have an umbrella package containing the best tools.

Just because our popularity is high and marketing is good doesn't mean we are the enemy.

I don't want to be your enemy. I really want us to grow together. I just have strong opinions, which I'm sure it's hard to take.

One big library with a marketing engine behind it is still a great flagship for the server-side Swift community, and benefits everyone.

If this library has good Swift coding standards and allows freedom for the community, I couldn't agree more.

bullied and finger-waggled in SwiftX in particular rather than welcomed

I'm sorry we came down so hard. But it's simply what we think. You guys are more than welcome to join efforts in SwiftX. I really wish we didn't have this harsh view of you guys. But again this is all a product of your actions. If you guys are really willing to go for it. We're here.

I have to honestly ask, by your line of reasoning: when will PHP be ready for prime-time?

Lol. True.

A rising tide lifts all ships. Wouldn't you rather have a marketing machine on your side, pushing for the adoption of server-side Swift from every angle?

Yes, definitely. But there's a difference between pushing for adoption and scaring people away.

I'm not sure where we are leaving people with a bad taste in their mouths about Swift

If you want me to send you some of the (unfortunately many) complaints I've gotten in my Slack channel about Perfect, I can. But I don't know if that would be constructive. I'm not trying to make you feel bad about the work you're doing. It takes courage to post your work online for everyone to look at, and I respect that. There's really no wrong that can be done by contributing to the OSS community. I just wanted to help you see how I have seen developers responding to Perfect.

The conversation has kind of moved beyond the original question, which is how Perfect could be more "Swifty".
It's an option to start new threads around the topics that have emerged in the discussion (don't get me wrong, they have been insightful), but keeping to this particular thread, I'm curious to understand if there are other things we should consider, in order to make Perfect "Swiftier".
So bringing it back, this is what I've noted:

Swift Package Manager support
Modularity
Composition (protocol with extensions, final attribute used by default)
Functional code (use of higher-order functions)
Primarily value types (struct over class where possible)
Immutability (let by default, var only if necessary)
Flexible library
Thinner layer between web and developer's own code
Get rid of unnecessary C dependencies and compile required C dependencies with Swift
Align to Swift guidelines for developing APIs

There's value in having a "starter kit" for those beginning in Perfect.  And we'll take a deeper look into SwiftX too.
Anything else come to mind?

In addition to the initial question of "Swiftiness", this has been an inspirational thread. One of the most incredible parts of this is the various individuals who came to the table for discussion;
Lead contributors of some of the most "starred" server-side frameworks on GitHub;
Perfect  (@kjessup, @seanstephens, @LucasC53)
Vapor (@tannernelson)
Zewo (@paulofaria, @Danappelxx)
Taylor (@Danappelxx)
MongoKitten (@Joannis)
I did take away some incredibly helpful points from this thread that we will address ASAP.
Perfect isn't, yet (Nobody is, yet)
We have an opportunity to clean up much of the Perfect codebase to be more "Swifty", and more modular. As most of Perfect was written before Swift open-sourced, this was somewhat inevitable. (We've been working on this for weeks, so suddenly we feel like geniuses). Onwards to glory! Swiftiness incoming.
Companies give developers the Jitters
We are a company, not of thousands, but of a few (a micro-community within the community). It's just a piece of paper indicating that a few of us are working together, in the same office, at the same time, on the same project. We are born from the union of an agency that loves people (Treefrog Inc.) and a server-side language from Apple (LassoSoft Inc.), who together have a reputation for being amazing companies. Treefrog is predicated on community, people, environmental awareness - and lastly, profit. It is not a scary place, it's progressive and awesome. PerfectlySoft comes from this, it lives in this. We are not Big Blue, we are Little Orange, inside green.
Our Marketing is Aggressive
Sorry about that guys, but not really. Our aggressive marketing will bring interest and passion from other communities and drive people to appreciate your work and be part of our new and emerging community. Think of us as your greatest asset, not a stain. Help us get better and be better, don't just point and cluck your tongues. We are not trying to take over the Swift community. We are trying to take over the world of alternate platform server-side development, on the Swift community's behalf. Our constant streams of horrendous orange logos are going to ultimately increase your salary. (We didn't pick the orange, Apple did). Our own project not sucking is key to this, too.
We should Standardize, together
This is one genius idea we hadn't considered before. Of course we will join you guys, and work towards interoperability and compatibility and community standards.  In the short term, we've stopped calling ourselves "enterprise-grade", by your request. We had previously removed "One Language to Rule them All" because a Java developer got really, really cranky about it. Whatever, we'll add those comments back in later, once we've proven the point. It's not that I don't believe the points myself, but rather that we aren't here to detract from the real goal: world-wide Swift domination. ;)
I have two final things to say, that I feel need not to be missed in this crazy thread.
One, this appears to be the first and largest gathering of minds in server-side Swift's history, the most stars in one place. This, this thread here, is the thread people will talk about in many years to come, where everyone got together and butted heads, out of which came the future of SSS programming. You people are the leaders of this new community. I appreciate that people have strong opinions, and want to piss on the fat kid and talk about "Slack channel complaints", but it's not helpful to the larger Swift vision. If we are to work together, we can't start off acting like the Perl community. We have to lead not just in developer genius, but also collaborative genius. We have crushed any negative comments about any of you in any of our channels - you won't find any, and we don't support the idea of poking at one another. In other words: you guys are the leaders of this new world order, with us in tow. Act like it. :)
Two, we are going to continue our work with Perfect until it is. We are not slowing down or going away or nerfing anything we do - improve, yes, sleep, no. If you are interested in helping us (while we help you), we'd love to work together. In fact - if you are interested - we are looking for individuals interested in working full time on our server side Swift libraries to improve them. THIS is why we have a company. Want to get paid for your Swift community contributions, either as a full time salaried developer or as a contractor? Lots of people do, including the creators of Swift itself. Contact me off list, and let's chat. Programmers have a right to eat, too. This is the future, and we are going to be integral to it - we have all of the trappings in place. Come play in our sandbox. Let's work together.
And lastly, I would say - I'd love to personally be connected with any and all of you. My lines are open, I/we are not a closed box - in fact, I'm quite open and transparent, all the time. Here's my personal info, I'd love to hear from you any time - you don't all have to wait to gang up on us at once, hehe;
<EMAIL_ADDRESS>CEO, PerfectlySoft Inc., Treefrog Inc. and LassoSoft Inc.
http://lnkd.in/QM5j5b
http://www.treefrog.ca/sean-stephens
905-836-4442 x109
https://twitter.com/treefrogCEO
We'll be working away for a while to clean up our act (based on your input), and then we'll join you at the standards party. Happy coding!

One, this appears to be the first and largest gathering of minds in server-side Swift's history, the most stars in one place.

Na, you're late to the game. There has been an ongoing collaboration for quite some time in the SwiftX slack channel including the likes of IBM engineers and swift server framework developers across many varied server projects. It was there that my own server implementation was invited in and merged with the efforts of a coherent community that was hard at work creating a shared standard by which all of us could write the best server frameworks possible.

Nobody sends birthday invitations any more. ;)
Methinks the project could use some better marketing, if it is to be inclusionary.

@SeanStephens It looks like the poor free Heroku instance powering the Slack inviter is exhausted (http://slack.swiftx.io). An invite has been sent to your email.


HTTP AUTH password to REST server included in error

Output of restic version
restic 0.9.6 compiled with go1.13.4 on linux/amd64
How did you run restic exactly?
restic backup -r<EMAIL_ADDRESS>~
Fatal: unable to open config file: client.Head: Head<EMAIL_ADDRESS>dial tcp: lookup rest-server.invalid on <IP_ADDRESS>:53: server misbehaving
Is there a repository at the following location?
<EMAIL_ADDRESS>Expected behavior
HTTP AUTH password squelched from error text.
Actual behavior
HTTP AUTH password is listed in error text.
Did restic help you today? Did it make you happy in any way?
restic helps me every day, which means to makes me happy every day :-)

Oh, interesting, that should not happen. Thanks a lot for letting us know!

Having to pass passwords on the command line is a more serious issue since they can be seen by any user with shell access to the machine. Passing them through the environment is cleaner since only root can see them then.

Agreed, thanks for the tip. I came across the bug while working with a temporary test repo and since moved into envvars for production.

This also happens in restic --help, where the repo URL (including the basic auth password) is listed as default for --repo.

@JensErat Please show the complete command and all of its output where this happens, with the latest version of restic (0.11.0).

Sure! It happens when the help is printed, and lists the password in the defaults of the --repo flag. I purged some of the many help lines for brevity:
$<EMAIL_ADDRESS>./restic --help

restic is a backup program which allows saving multiple revisions of files and
directories in an encrypted repository stored on different backends.

[snip]

  -q, --quiet                      do not output comprehensive progress report
  -r, --repo repository            repository to backup to or restore from (default: $RESTIC_REPOSITORY) (default<EMAIL_ADDRESS>      --repository-file file       file to read the repository location from (default: $RESTIC_REPOSITORY_FILE)
      --tls-client-cert file       path to a file containing PEM encoded TLS client certificate and private key
  -v, --verbose n                  be verbose (specify multiple times or a level using --verbose=n, max level/times is 3)

Use "restic [command] --help" for more information about a command.

$ ./restic version
restic 0.11.0 compiled with go1.15.3 on linux/amd64

Ah, right. One has to set the environment variable for it. Thanks.

Indeed, my original report missed that detail. Checking further, this also happens for all kinds of (error) messages involving the repository. I guess S3 storage will also be affected by this.

That default value is only shown when there's a value set for the corresponding environment variable.
We already mention in the description of the option what the default is calculated from (the environment variable).
The way it looks when there's two parenthesis containing a default value description is rather ugly.
I can't remember ever seeing a need for the printing of the actual default value as it is resolved, it's more interesting to know what it is resolved from.
With all this in mind, I'd like to suggest that we start using the default value parameter in the pflag.StringVarP etc  to define what the default value is resolved from rather than what it is.

E.g. we'd replace:
`f.StringVarP(&globalOptions.Repo, "repo", "r", os.Getenv("RESTIC_REPOSITORY"), "`repository` to backup to or restore from (default: $RESTIC_REPOSITORY)")`

with:
f.StringVarP(&globalOptions.Repo, "repo", "r", "$RESTIC_REPOSITORY", "`repository` to backup to or restore from")

which will produce the following output regardless of what the environment variable is set to, if anything:
-r, --repo repository            repository to backup to or restore from (default "$RESTIC_REPOSITORY")

This of course requires that we don't feel a need to print the actual resolved default values, which I don't think we need to do.

@rawtaz any news on this? I'd be fine with providing a pull request, but it looks to me like this is not only a concept, but pretty much code already. Your approach seems very reasonable to me. Maybe one thing to consider though: what happens, if neither variable nor flag are set? Is this something we should explain to the user?

The full changes to only show the environment variable name are as follows. For example for RESTIC_KEY_HINT the code could look like this:
-       f.StringVarP(&globalOptions.KeyHint, "key-hint", "", os.Getenv("RESTIC_KEY_HINT"), "`key` ID of key to try decrypting first (default: $RESTIC_KEY_HINT)")
+       f.StringVarP(&globalOptions.KeyHint, "key-hint", "", "$RESTIC_KEY_HINT", "`key` ID of key to try decrypting first")
+       globalOptions.KeyHint = os.Getenv("RESTIC_KEY_HINT")

The default value shown on the command line is captured when defining the flag. But we can overwrite its value afterwards. The change should also be applied to flags using a similar pattern.


KDF Crash iPad Pro 2018

Opens when I choose no for KDF. iPad Pro 2018 16.4.1

its worked well  thx lot！！！！

its worked well thx lot！！！！

How to set kfd function Or the default setting？iPad Pro 2020  A12Z   16.5 still failed😭

Yes working for me as well

its worked well thx lot！！！！

How to set kfd function Or the default setting？iPad Pro 2020 A12Z 16.5 still failed😭

I just deleted the old and downloaded the new and it started working.

Yes working for me as well
I just deleted the old and downloaded the new and it started working.

@bluevast & @abelcrazyman
These are great news! Gives me some hope.
But I still have some questions:

Which version of Misaka did you use? M1/M2 or the regular one?
Are you on a A12Z device?
How many tries did it take before the exploit finally worked?
Did you do something special with your ram? (e.g. multiple apps running in background...)

I have an iPad Pro 12,9" 4th Gen (it has the A12Z chip) with iOS 16.3.1 and misaka v3.3.6 still refuses to exploit my device. It just prompts"Exploiting Kernel... Please wait" and shortly after my iPad restartes. Sometimes with a pink screen, sometimes just black.
I would appreciate any help or tip how to make it work.

@abelcrazyman & @bluevast These are great news! Gives me some hope. But I still have some questions:
* Which version of Misaka did you use? M1/M2 or the regular one?

* Are you on a A12Z device?

* What is your iOS version?

* How many tries did it take before the exploit finally worked?

* Did you do something special with your ram? (e.g. multiple apps running in background...)

I have an iPad Pro 12,9" 4th Gen (it has the A12Z chip) with iOS 16.3.1 and misaka v3.3.6 still refuses to exploit my device. It just prompts"Exploiting Kernel... Please wait" and shortly after my iPad restartes. Sometimes with a pink screen, sometimes just black.
I would appreciate any help or tip how to make it work.

3.3.6 regular one
iPad Pro 12.9 A12X 2018 OS 16.4.1
surprisingly exploit worked first try, I did nothing to ram I'm sure there were background apps running, really didn't pay attention to it. Good luck though, I'm sure it will get ironed out soon enough, maybe next update. If not already you could join the discord and ask around.

3.3.6 regular one iPad Pro 12.9 A12X 2018 OS 16.4.1 surprisingly exploit worked first try, I did nothing to ram I'm sure there were background apps running, really didn't pay attention to it. Good luck though, I'm sure it will get ironed out soon enough, maybe next update. If not already you could join the discord and ask around.

Thank you for all those information and the hope! :)
I will try it exactly how you have done it. Maybe it will work or maybe the next version will do it for me. We'll see.
But overall it looks like 3.3.6 is more for A12X than for A12Z.


Add TravisCI to this repo

Again, @meganle can be a POC for this

Scope now includes single-step setup and install to be compatible with Travis

Note: Somewhat related to #60 since the deployment/install script must download the GTFS data such as route numbers and place them in the tcat-ny-us directory.

Closing with #84


flutter attach crashes with FormatException

flutter attach crashes basically as soon as I start it. I'm suspecting it might be encountering some strange mDNS record which makes it crash, since I'm currently on a large corporate network. Will try again tonight at home to see if it's reproducible there.
Steps to Reproduce

flutter attach

Logs
[  +41 ms] executing: [/Users/linus/coding/flutter/] git log -n 1 --pretty=format:%H
[  +44 ms] Exit code 0 from: git log -n 1 --pretty=format:%H
[        ] 0ba67226ee62d6c9d663a6f8410fb4b2f1076046
[        ] executing: [/Users/linus/coding/flutter/] git describe --match v*.*.* --first-parent --long --tags
[  +98 ms] Exit code 0 from: git describe --match v*.*.* --first-parent --long --tags
[        ] v1.5.8-0-g0ba67226e
[  +16 ms] executing: [/Users/linus/coding/flutter/] git rev-parse --abbrev-ref --symbolic @{u}
[  +15 ms] Exit code 0 from: git rev-parse --abbrev-ref --symbolic @{u}
[        ] origin/dev
[        ] executing: [/Users/linus/coding/flutter/] git ls-remote --get-url origin
[  +15 ms] Exit code 0 from: git ls-remote --get-url origin
[        ] https://github.com/flutter/flutter.git
[  +78 ms] executing: [/Users/linus/coding/flutter/] git rev-parse --abbrev-ref HEAD
[  +13 ms] Exit code 0 from: git rev-parse --abbrev-ref HEAD
[        ] dev
[ +457 ms] executing: /usr/local/share/android-sdk/platform-tools/adb devices -l
[  +13 ms] Exit code 0 from: /usr/local/share/android-sdk/platform-tools/adb devices -l
[        ] List of devices attached
[   +7 ms] executing: idevice_id -h
[ +175 ms] executing: which ideviceinstaller
[   +8 ms] Exit code 0 from: which ideviceinstaller
[        ] /usr/local/bin/ideviceinstaller
[        ] executing: which iproxy
[   +5 ms] Exit code 0 from: which iproxy
[        ] /usr/local/bin/iproxy
[   +6 ms] /usr/bin/xcrun simctl list --json devices
[ +353 ms] Artifact Instance of 'FlutterWebSdk' is not required, skipping update.
[   +6 ms] Artifact Instance of 'WindowsEngineArtifacts' is not required, skipping update.
[   +1 ms] Artifact Instance of 'MacOSEngineArtifacts' is not required, skipping update.
[   +1 ms] Artifact Instance of 'LinuxEngineArtifacts' is not required, skipping update.
[        ] Artifact Instance of 'FuchsiaCacheArtifacts' is not required, skipping update.
[ +144 ms] Checking for advertised Dart observatories...
Unhandled exception:
FormatException: Bad UTF-8 encoding 0xc (at offset 22)
#0      _Utf8Decoder.convert (dart:convert/utf.dart:444:15)
#1      Utf8Decoder.convert (dart:convert/utf.dart:327:13)
#2      Utf8Codec.decode (dart:convert/utf.dart:59:56)
#3      _readFQDN (package:multicast_dns/src/packet.dart:165:24)
#4      decodeMDnsResponse.readResourceRecord (package:multicast_dns/src/packet.dart:240:36)
#5      decodeMDnsResponse (package:multicast_dns/src/packet.dart:350:55)
#6      MDnsClient._handleIncoming (package:multicast_dns/multicast_dns.dart:194:45)
#7      _rootRunUnary (dart:async/zone.dart:1136:13)
#8      _CustomZone.runUnary (dart:async/zone.dart:1029:19)
#9      _CustomZone.runUnaryGuarded (dart:async/zone.dart:931:7)
#10     _BufferingStreamSubscription._sendData (dart:async/stream_impl.dart:336:11)
#11     _BufferingStreamSubscription._add (dart:async/stream_impl.dart:263:7)
#12     _SyncStreamController._sendData (dart:async/stream_controller.dart:764:19)
#13     _StreamController._add (dart:async/stream_controller.dart:640:7)
#14     _StreamController.add (dart:async/stream_controller.dart:586:5)
#15     new _RawDatagramSocket.<anonymous closure> (dart:io-patch/socket_patch.dart:1859:33)
#16     _NativeSocket.issueReadEvent.issue (dart:io-patch/socket_patch.dart:844:14)
#17     _microtaskLoop (dart:async/schedule_microtask.dart:41:21)
#18     _startMicrotaskLoop (dart:async/schedule_microtask.dart:50:5)
#19     _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:115:13)
#20     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:172:5)

Flutter doctor output:
[✓] Flutter (Channel dev, v1.5.8, on Mac OS X 10.14.4 18E226, locale en-GB)
    • Flutter version 1.5.8 at /Users/linus/coding/flutter
    • Framework revision 0ba67226ee (6 days ago), 2019-04-24 17:18:28 -0700
    • Engine revision c63d1cf9c9
    • Dart version 2.3.0 (build 2.3.0-dev.0.1 1f1592edce)

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at /usr/local/share/android-sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • ANDROID_HOME = /usr/local/share/android-sdk
    • ANDROID_SDK_ROOT = /usr/local/share/android-sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)
    • All Android licenses accepted.

[✓] iOS toolchain - develop for iOS devices (Xcode 10.2.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 10.2.1, Build version 10E1001
    • ios-deploy 1.9.4
    • CocoaPods version 1.6.1

[✓] Android Studio (version 3.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 31.3.1
    • Dart plugin version 181.5656
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)

[✓] VS Code (version 1.33.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 2.25.1

[✓] Connected device (1 available)
    • Linus Unnebäck’s iPhone • f94aa6361e142ab9641a700b2eb487e8611738f4 • ios • iOS 12.2

• No issues found!

Interestingly enough, it seems to be at different offset every time I run the command 🤔
Out of 100 tries:
   1 FormatException: Bad UTF-8 encoding 0xc (at offset 6)
   1 FormatException: Bad UTF-8 encoding 0xc (at offset 15)
   2 FormatException: Bad UTF-8 encoding 0xc (at offset 28)
   4 FormatException: Bad UTF-8 encoding 0xc (at offset 17)
   5 FormatException: Bad UTF-8 encoding 0xc (at offset 18)
   6 FormatException: Bad UTF-8 encoding 0xc (at offset 19)
   6 FormatException: Bad UTF-8 encoding 0xc (at offset 22)
   6 FormatException: Bad UTF-8 encoding 0xc (at offset 24)
   6 FormatException: Bad UTF-8 encoding 0xc (at offset 25)
   7 FormatException: Bad UTF-8 encoding 0xc (at offset 14)
  10 FormatException: Bad UTF-8 encoding 0xc (at offset 26)
  11 FormatException: Bad UTF-8 encoding 0xc (at offset 21)
  17 FormatException: Bad UTF-8 encoding 0xc (at offset 23)
  18 FormatException: Bad UTF-8 encoding 0xc (at offset 20)

@LinusU Thanks for the logs. I was wondering if you could add some print statements to dump the packet that is causing the issue.
This is the patch I have been working on https://github.com/flutter/packages/compare/master...blasten:catch-format-exception.
Steps:

cd ~/.pub-cache/hosted/pub.dartlang.org/multicast_dns-*/lib/src/

mv packet.dart _packet.dart

wget https://raw.githubusercontent.com/blasten/packages/815c8251c5136665ea4f5c237d5cb82885ecd7d1/packages/multicast_dns/lib/src/packet.dart

which flutter | sed "s/flutter$/cache\/flutter_tools\.snapshot/" | xargs rm

Run flutter attach again.

Send us the packet: "The source bytes were: ..."

mv  ~/.pub-cache/hosted/pub.dartlang.org/multicast_dns-*/lib/src/_packet.dart  ~/.pub-cache/hosted/pub.dartlang.org/multicast_dns-*/lib/src/packet.dart

Let me know if this doesn't work.

Those are really detailed instructions, thanks! I was looking at that PR, but wasn't sure on how to test it out locally...
Applying the changes gives me an entirely different error though 🤔 I think I saw this when disconnecting from the wifi with the previous build...
I did do another test just before applying the patch, and that gave me the same error as always. Will try to de-apply the patch and see if it comes back...
command
flutter attach
exception
NoSuchMethodError: NoSuchMethodError: The getter 'port' was called on null.
Receiver: null
Tried calling: port
#0      Object.noSuchMethod (dart:core-patch/object_patch.dart:50:5)
#1      AttachCommand.runCommand (package:flutter_tools/src/commands/attach.dart:219:78)
<asynchronous suspension>
#2      FlutterCommand.verifyThenRunCommand (package:flutter_tools/src/runner/flutter_command.dart:488:18)
#3      _asyncThenWrapperHelper.<anonymous closure> (dart:async-patch/async_patch.dart:77:64)
#4      _rootRunUnary (dart:async/zone.dart:1132:38)
#5      _CustomZone.runUnary (dart:async/zone.dart:1029:19)
#6      _FutureListener.handleValue (dart:async/future_impl.dart:126:18)
#7      Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:639:45)
#8      Future._propagateToListeners (dart:async/future_impl.dart:668:32)
#9      Future._complete (dart:async/future_impl.dart:473:7)
#10     _SyncCompleter.complete (dart:async/future_impl.dart:51:12)
#11     _AsyncAwaitCompleter.complete.<anonymous closure> (dart:async-patch/async_patch.dart:33:20)
#12     _rootRun (dart:async/zone.dart:1124:13)
#13     _CustomZone.run (dart:async/zone.dart:1021:19)
#14     _CustomZone.bindCallback.<anonymous closure> (dart:async/zone.dart:947:23)
#15     _microtaskLoop (dart:async/schedule_microtask.dart:41:21)
#16     _startMicrotaskLoop (dart:async/schedule_microtask.dart:50:5)
#17     _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:115:13)
#18     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:172:5)

flutter doctor
[✓] Flutter (Channel dev, v1.5.8, on Mac OS X 10.14.4 18E226, locale en-GB)
    • Flutter version 1.5.8 at /Users/linus/coding/flutter
    • Framework revision 0ba67226ee (7 days ago), 2019-04-24 17:18:28 -0700
    • Engine revision c63d1cf9c9
    • Dart version 2.3.0 (build 2.3.0-dev.0.1 1f1592edce)

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at /usr/local/share/android-sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • ANDROID_HOME = /usr/local/share/android-sdk
    • ANDROID_SDK_ROOT = /usr/local/share/android-sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)
    • All Android licenses accepted.

[✓] iOS toolchain - develop for iOS devices (Xcode 10.2.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 10.2.1, Build version 10E1001
    • ios-deploy 1.9.4
    • CocoaPods version 1.6.1

[✓] Android Studio (version 3.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 31.3.1
    • Dart plugin version 181.5656
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)

[✓] VS Code (version 1.33.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 2.25.1

[✓] Connected device (1 available)
    • Linus Unnebäck’s iPhone • f94aa6361e142ab9641a700b2eb487e8611738f4 • ios • iOS 12.2

• No issues found!

Okay, I managed to just edit the file in place and found a lot of offending parts. Looking at the data it seems like there is some problem with the offset/lengths into the backing data. Basically, the data in each part printed would look something like this:
ck...s MacBook Pro. . (several non-ascii bytes) Linu
But with other names, presumably of other people working in the same co-working space as me. Because of that I didn't want to share the raw packets publicly here, but I'd be happy to share them privately with you, just let me know where to send them.
The Uint8Lists passed to utf8.decode seems to 1) start not where the string should start (i.e. if the name of my computer is "Linus Unnebäck's MacBook Pro" it will start several bytes into that string, and 2) have too many bytes so that it includes other binary data after the string, and also part of the next entry after that (i.e. it will have the end of one name, then some binary data, and then the start of another name, or even an entire other entry, and then the start of a third).
Some observations:

There seem to always be 15 bytes of data between UTF8-encoded names of computers.
The last of that byte seems to be the byte length of the next name
The data passed for decoding can cut of both in the middle of names, and in the middle of the 15 bytes data between names
The 15 bytes of data between names seems to always start with C00CC00C 000C0001 00000E
Some names where included multiple times, so it seems like the data passed for decoding can sometimes span the same source bytes.
The first packet could be off by only one byte, since it starts with a common name without the first letter, and then "MacBook Pro"
Aha! 👏 the first packet is very probably off by one byte, because the utf8 encoding of the first character that was missing from the name, is the same as the length of that data passed in! This is probably the root cause...

@blasten it seems like there is an off-by-one error when reading the first name length, making everything else after that read from basically random places in the data

The first error was another bug we fixed yesterday.
The second is interesting.  It would be very helpful if you could somehow get a sanitized reproduction of the packet (s) causing this

I'm willing to bet there's somewhere we assume we can advance by one byte but there's a multibyte character were going into the middle of

@LinusU Thanks for looking into it! The entire packet will be very useful. Feel free to send it to me in a DM via our Slack channel: https://fluttercommunity.slack.com - Search for Emmanuel.

I think I found the fix to the bug @dnfield : https://github.com/blasten/packages/commit/5785eb5c0f68e1382c8e92bcb44600069c59c3af
@LinusU would you mind trying this out?

Tried it out, it reads the length one byte too early instead of too late now 😆
Sending you packets on Slack 👌

I noted I missed this commit: https://github.com/blasten/packages/commit/bb88fd3584b63a2f73ce88773a54a88b44144c3c. The last packet you sent me seems to be passing with this last change.

With that one, everything seems to work 🙌
Now I'm getting to the NoSuchMethodError: The getter 'port' was called on null. problem instead, but I think that's fixed on master 👌

Let's leave this open until the fix lands in the framework.

This issue is fixed in master now 🎉

@blasten  when will you merge this change to the stable branch? The version of stable channel is v1.5.4-hotfix.2

@Bluelich this fix is available on the current beta.  If it's important to your workflow, you should probably just start using the beta.  It will eventually roll into stable, and it's very rare that any changes are made from when it's in beta to when it's in stable.
See https://github.com/flutter/flutter/wiki/Flutter-build-release-channels#which-channel-should-i-use for more details on how to pick which channel to use, and a bit more details about the cadence at which stable releases are normally made.

+1 to what @dnfield said. Also,  from: https://groups.google.com/forum/#!topic/flutter-announce/oIzwT9EDczc:

we expect to have a beta release in late June (which will go to stable by early July)


Possibly halve the number of writes for small blobs

For small blobs, ie: those that are under the 64kB limit for DenoKV, using the blob library results in two writes - a meta and a blob write.
I wonder if these couldn't be combined into a single write ?
The format of the meta write is roughly:
  const key: [
    ...userSuppliedKey,
    "__kv_toolbox_meta__"
  ],
  const value: { kind: "buffer", size: 92 }

However if this was always encoded into a Uint8Array, then the first blob write could be appended to the meta value using length encoding or something, resulting in a single write for small values, and decreasing the total write count by 1 for all other sizes ?

That really gets complicated supporting all of the features that are there as well as managing the logic around being able to detect and "view" the blob without decoding it.  Embedding the meta data in the first "chunk" also makes it more complicated.  Each of the values of the "parts" of the blob are binary chunks of the blob itself. This means these can be read (and streamed) without understanding the contents of the part and even decoding it.
Grabbing just the meta value works really well when you want to represent the value without touching the values of the blob itself, which is exactly what kview does when sending it over the wire. It uses the getMeta() to represent the raw binary data or Blob or File without actually having to read any of the blob itself.  The writes are part of a single atomic commit internally, so the overhead is actually quite minimal.
I am afraid it isn't worth the added complexity and the downside of having to always fully decode the first chunk to just understand what type of blob it is.

Ok I understand - thanks for the detailed explanation.
My use case is that when I know a file is small I use a non blob method so I can get a faster read, otherwise my lookup is two round trips not one.  This is hard to consume tho since I have to know in advance when reading which method was used to store.  I understand what you mean about the writes being atomic so the overhead being negligible, but reads appear not as immune.
When my isolate is in australia, RTT to the db is 400ms each time, so 800ms to get the meta and then get the blob - I was hoping to do that in one shot.
A suggestion - you could maybe speed up the reads if you read both the meta and the first blob at once using getMany() and then use the list() function to get blobs two and above if they even exist ?
https://github.com/kitsonk/kv-toolbox/blob/b18ec53b1a2bd06202be0d994c1c3213a78b7cff/blob.ts#L238-L240
Parallel reads are about the same speed as a single one when your database is half the world away...

I am still thinking about what the right approach for this. 🤔


build failure if compiled without MBEDTLS_PK_RSA_ALT_SUPPORT

Note: This is just a template, so feel free to use/remove the unnecessary things
Description

Type: Bug
Priority: Major

Bug
OS
linux
mbed TLS build:
Version: 4500e83fe41a0765bc06b47662b3ae00d0b1bd59
OS version: 5.6.0
Configuration: please attach config.h file where possible
Compiler and options (if you used a pre-built binary, please indicate how you obtained it):
Additional environment information:
Peer device TLS stack and version
n/a
Version:
Expected behavior
builds without errors
Actual behavior
[ 74%] Linking C executable test_suite_x509write
/usr/lib64/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: CMakeFiles/test_suite_x509write.dir/test_suite_x509write.c.o: in function execute_tests': test_suite_x509write.c:(.text+0x1756): warning: warning: your code uses stdio (7+k bloat). /usr/lib64/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /opt/diet/lib-x86_64/libc.a(vsnprintf.o): in function vsnprintf':
vsnprintf.c:(.text.vsnprintf+0x4c): warning: warning: the printf functions add several kilobytes of bloat.
/usr/lib64/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: CMakeFiles/test_suite_x509write.dir/test_suite_x509write.c.o: in function test_x509_crt_check': test_suite_x509write.c:(.text+0x976): undefined reference to mbedtls_pk_setup_rsa_alt'
collect2: error: ld returned 1 exit status
The bloat warning message comes from my special libc. You can disregard it here.
Steps to reproduce

Enhancement\Feature Request
Justification - why does the library need this feature?
Suggested enhancement

Question
Please first check for answers in the Mbed TLS knowledge Base. If you can't find the answer you're looking for then please use the Mbed TLS mailing list

my config.h can be found at https://ptrace.fefe.de/mbedtls-config.h

Suggested fix:
diff --git a/tests/suites/test_suite_x509write.function b/tests/suites/test_suite_x509write.function
index 0db2b0e94..75de8ec32 100644
--- a/tests/suites/test_suite_x509write.function
+++ b/tests/suites/test_suite_x509write.function
@@ -225,7 +225,7 @@ void x509_crt_check( char *subject_key_file, char *subject_pwd,
TEST_ASSERT( mbedtls_pk_parse_keyfile( &issuer_key, issuer_key_file,
issuer_pwd ) == 0 );
-#if defined(MBEDTLS_RSA_C)
+#if defined(MBEDTLS_RSA_C) && defined(MBEDTLS_PK_RSA_ALT_SUPPORT)
/* For RSA PK contexts, create a copy as an alternative RSA context. */
if( rsa_alt == 1 && mbedtls_pk_get_type( &issuer_key ) == MBEDTLS_PK_RSA )
{

Ah, the joys of option combinations. We test builds with: MBEDTLS_RSA_C && MBEDTLS_PK_RSA_ALT_SUPPORT && MBEDTLS_X509_CRT_WRITE_C , MBEDTLS_RSA_C && !MBEDTLS_PK_RSA_ALT_SUPPORT && !MBEDTLS_X509_CRT_WRITE_C , !MBEDTLS_RSA_C && …, but not  MBEDTLS_RSA_C && !MBEDTLS_PK_RSA_ALT_SUPPORT && MBEDTLS_X509_CRT_WRITE_C . Thanks for reporting this!


Web Scrapper

| Fixes       | # Issue No. |
| Readme.md        |    :#38:   |
Description

Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New project (non-breaking change which adds functionality)

How Has This Been Tested?

Checklist:

[x] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have included a README.md file
[ ] My project follows this structure: Domain Folder/ Project Name Folder/ Project files and Readme.md files
[ ] I have added demonstration in the form of GIF/video file
[ ] I am a GSSoC'22 Participant

Sure ok😊
On Thu, 17 Mar 2022, 01:10 Heet kumar Kothadiya, @.***>
wrote:

@.**** requested changes on this pull request.
@Tridib11 https://github.com/Tridib11 Hey Buddy Nice PR! and Project
just make few changes like for creating the Readme.md file follow all the
rules which are mentioned in Rules.md
https://github.com/abhijeet007rocks8/Dev-Scripts/blob/main/Rules.md . Adding
video is mandatory till then I can't merge this PR.
How to upload video in markdown then watch this video :
https://drive.google.com/file/d/12cjBwDaTCK4pu7cqNI_FNuRAZwamCywP/view?usp=sharing
https://drive.google.com/file/d/12cjBwDaTCK4pu7cqNI_FNuRAZwamCywP/view?usp=sharing&authuser=0
Note : Screen Recorded video should include

code go-through
what are the files you have included
run your project in screen recording

—
Reply to this email directly, view it on GitHub
https://github.com/abhijeet007rocks8/Dev-Scripts/pull/144#pullrequestreview-912170575,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AURRZHQ7QN23WC3NHYMPS7TVAI2KPANCNFSM5QLTPROA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hello
I wana say something my github just had an issue and i dont understand what
just happend but few pull request got sent from my side i dont understand
whats happening i am trying a lot to update it but i am unable to do it.
Sorry for the inconveniences as you said to just put a vedio i had recorded
that too but when as i am trying to push it all the filed are not getting
pussed only 2 files are getting pushed i dont understand whats the issue
with it . Sorry for the inconveniences.
On Thu, 17 Mar 2022, 01:37 Tridib Ghosh., @.***>
wrote:

Sure ok😊
On Thu, 17 Mar 2022, 01:10 Heet kumar Kothadiya, @.***>
wrote:

@.**** requested changes on this pull request.
@Tridib11 https://github.com/Tridib11 Hey Buddy Nice PR! and Project
just make few changes like for creating the Readme.md file follow all the
rules which are mentioned in Rules.md
https://github.com/abhijeet007rocks8/Dev-Scripts/blob/main/Rules.md . Adding
video is mandatory till then I can't merge this PR.
How to upload video in markdown then watch this video :
https://drive.google.com/file/d/12cjBwDaTCK4pu7cqNI_FNuRAZwamCywP/view?usp=sharing
https://drive.google.com/file/d/12cjBwDaTCK4pu7cqNI_FNuRAZwamCywP/view?usp=sharing&authuser=0
Note : Screen Recorded video should include

code go-through
what are the files you have included
run your project in screen recording

—
Reply to this email directly, view it on GitHub
https://github.com/abhijeet007rocks8/Dev-Scripts/pull/144#pullrequestreview-912170575,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AURRZHQ7QN23WC3NHYMPS7TVAI2KPANCNFSM5QLTPROA
.
You are receiving this because you were mentioned.Message ID:
@.***>

@Tridib11 ok no issue take your time to complete it.


Client Allocation Request for: Jiliantech

Client Allocation Questions
Core Information

Name: Jiliantech
Website / Social Media: www.videojj.com
Region: Greater China
DataCap Requested: 15TiB
Addresses to be Notarized: f1w3rry66h73rujh5scdkuigj4islxs3tkqdiraji
Notary Requested: ozhtdong

@anelajennings204110 Please subscribe to notifications for this Issue to be aware of updates. Notaries may request additional information on the Issue.

Thanks for your application , some questions to you:
1.What's your name? What's your position?
2.What's your company's business? Do you have any other social media link?
3.Could you show me your company's business license?
4.How many miners do you want to store your data to? How much data for each miner?
5.Will you record your allocation decision in public? Which platform will you use?
6.What method/tool will you use to inspect miners? Which aspect of miners will you inspect?

Ming Jin. I’m a legal person.
Jilian Technology Development Group Co., Ltd. was founded in October 2014 in Shanghai, China, focusing on technology and consumption. It owns Jilian AI Cloud, TAKIPLAY Script Killing, TakiToys Trendy Toys, TakiLucky Entertainment Retail, Video++ Linglian Marketing, and Jilian Technology. In addition to online businesses such as technology, the chain is actively deploying offline consumer entities and has 20+ physical brand stores directly operated by TakiLucky and TakiPlay. The main investors of Jilian Technology Group include Alibaba, Yunfeng Fund, Megvii Technology Face++, Ubisoft, SDIC Fund, K11 Hong Kong New World, etc. It has received nearly 1 billion yuan in financing and has grown into a company with leading technology, a comprehensive commercial technology company with a large number of users and comprehensive revenue capabilities.
https://www.sohu.com/a/463207264_179850  You can refer to it.
OK, I can. Email you.
We need 3-4 miners. We will divide to each miner equally.
No. We will record in private. Maybe we will use github.
I don’t know. We inspect creditable miners.

license you need
On Fri, Sep 24, 2021 at 1:54 PM ozhtdong @.***> wrote:

Thanks for your application , some questions to you:
1.What's your name? What's your position?
2.What's your company's business? Do you have any other social media link?
3.Could you show me your company's business license?
4.How many miners do you want to store your data to? How much data for
each miner?
5.Will you record your allocation decision in public? Which platform will
you use?
6.What method/tool will you use to inspect miners? Which aspect of miners
will you inspect?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/filecoin-project/filecoin-plus-client-onboarding/issues/905#issuecomment-926365472,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVQPKUVQFMBDDX75K3QLRNDUDQHCTANCNFSM5EU74U2Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Request Approved
Your Datacap Allocation Request has been approved by the Notary
Message sent to Filecoin Network

bafy2bzacebs5h646a2gg3ut2py34xh3mykan6faiwuy5cammguf26h5uaubdq

Address

f1w3rry66h73rujh5scdkuigj4islxs3tkqdiraji

Datacap Allocated

15TiB

You can check the status of the message here: https://filfox.info/en/message/bafy2bzacebs5h646a2gg3ut2py34xh3mykan6faiwuy5cammguf26h5uaubdq


ER図が見たい

Rails ERD を使う。

Closed by https://github.com/bm-sms/daimon-news-multi-tenant/pull/388 :ship:


Port codebase to TypeScript

Yet another issue for adding TS support to the project.  This time, however, we'll (hopefully) be doing a full port of the codebase to TS so we can use tsc to generate the type declaration files.
This will affect the build system, which may (read, "definitely") break backward compatibility.
See PR #763 for specific tasks.

For the record, motivations here include:

TS code is generally higher quality than vanilla JS
Generating types automatically produces higher-quality type declarations and removes risk of errors
Publishing types via the DefinitelyTyped project is relatively onerous and time consuming.  Witness https://github.com/DefinitelyTyped/DefinitelyTyped/pull/69773.


InterProScan: Still don;t have a working version of a container

Potential solution:
https://github.com/ola-t/interproscan-docker-cwl/blob/master/interproscan.cwl

Should be resolved by now on the dev branch. Still facing issues with CWLEXEC, but cwl-runner works fine. CWLEXEC issues have been reported to TSI.


Rewrite users/register to Go

What does this PR (Pull Request) do?

[x] This PR fixes #3835

Rewrites /users/register to Go. As opposed to the Perl, in this PR:

tenantID is required, as tenancy is no longer optional.
tenantID can no longer be a tenant to which the requesting user has no access
role can no longer be a Role with a higher privilege level than the requesting user

Which Traffic Control components are affected by this PR?

Documentation
Traffic Ops Client (Go)
Traffic Ops

What is the best way to verify this PR?
Start up Traffic Ops from this branch in an environment with access to a mail server (which is properly configured in the TO configuration file) and attempt to register users using /users/register.
There are no unit or integration tests because this requires access to a mail server, which isn't built into the testing. There is, however, a test to ensure the email template renders given adequate input.
The following criteria are ALL met by this PR

[x] I have explained why tests are impossible/impractical
[x] This PR includes documentation
[x] An update to CHANGELOG.md is not necessary
[x] This PR includes any and all required license headers
[x] This PR does not include a database migration
[x] This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/4794/

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/4798/

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/4799/

i've always thought it was annoying that when you "register" a new user it autogenerates a username for them like 20A34788-A877-11E7...
the idea is that when the new user gets the register email and follows the link, they will update the username to something more sensible. because this username is random, it makes it hard to sort the users on https://tp.domain.net/#!/users and see which ones are "open/abandoned registrations".
what about changing that username autogenerate to something like change_me_20A34788-A877-11E7...
this would have 2 benefits:

you can sort/filter all the change_me's to get a sense of how many there are
it's clear to the user that they should update that field.

That's a good point. It now generates a username like register_{{a 32-character random string}}

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/4800/

Can you show me the full HTTP stack; request and response?

I can let me get it back up

POST https://<IP_ADDRESS>:8443/api/1.4/users/register
Body
{
	"role":1,
	"tenantId":1,
<EMAIL_ADDRESS>}

Response
{
    "alerts": [
        {
            "text": "decoding: json: cannot unmarshal object into Go value of type api.ParseValidator",
            "level": "error"
        }
    ]
}

Resp Headers
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Set-Cookie, Cookie
Access-Control-Allow-Methods: POST,GET,OPTIONS,PUT,DELETE
Access-Control-Allow-Origin: *
Content-Encoding: gzip
Content-Type:application/json
Set-Cookie: mojolicious=... Path=/; Expires=Fri, 22 Nov 2019 01:46:10 GMT; Max-Age=3600; HttpOnly
Whole-Content-Sha512: /E/Bj+NptZRI6Yp8wbGG49hxZ/3mVfbOzEPh+AbnLhlqRemI+nufZQCbKF4xmaOEee0tR8Tp+LeQpsu+Y23QqA==
X-Server-Name: traffic_ops_golang/
Date: Fri, 22 Nov 2019 00:46:10 GMT
Content-Length: 126

Log message from TO
DEBUG: api.go:149: 2019-11-21T17:46:10.813635-07:00: decoding: json: cannot unmarshal object into Go value of type api.ParseValidator

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/4817/

I think I fixed that.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/4853/

it was a problem with my clause ordering in a query. I know I tried it out manually, must've changed it after that and forgot to verify. I didn't bother setting up a mail server for it since that's very complicated and I can't remember how I did it that one time - so when I saw the Internal Server error I just assumed the email couldn't be sent so it "worked" :P

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/4855/

I think I fixed everything for real this time. There was also a bug where it'd let you not specify an email.

testing now 👍

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/4868/

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/4870/


Missing dollar sign from variable.

https://github.com/zurb/foundation-emails/blob/v2.0/scss/components/_button.scss#L75
Missing $
Should read:
font-family: $body-font-family;

Fixed via ea180d86201efdbe6049621cb13c8389a7082677


Add spec for BroadcastInDimOp

Adds the specification as  part of #122
Fixes https://github.com/openxla/stablehlo/issues/277

incorporated the latest changes #313 and #314


Hooks don't work

Which version are you using?
v1.8.4
Which operating system are you using?

[ ] Linux amd64 standard
[x] Linux amd64 Docker
[ ] Linux arm64 standard
[ ] Linux arm64 Docker
[ ] Linux arm7 standard
[ ] Linux arm7 Docker
[ ] Linux arm6 standard
[ ] Linux arm6 Docker
[ ] Windows amd64 standard
[ ] Windows amd64 Docker (WSL backend)
[ ] macOS amd64 standard
[ ] macOS amd64 Docker
[ ] Other (please describe)

Describe the issue
Most of the time, hooks just don't work, using WebRTC or HLS. I defined all hooks, and when I open a stream and play with HLS it never ever trigger any hook, and with WebRTC it ionly trigger OnRead and OnUnread, and OnUnread it triggered even while the stream is playing.
Describe how to replicate the issue

Configure all hooks
Start the server
Stream using HLS and/or WebRTC

Did you attach the server logs?
no
Did you attach a network dump?
no

try this
https://gofile.io/d/yMHabA
select the desired compiler in the installer

Hello,
Regarding HLS, this is expected since in HLS there's no concept of reader - see #962
Regarding WebRTC, the question is not clear since you didn't attach server logs and therefore it's impossible to understand if and how the possible duplication of onUnread happens.
If you have further issues, open another bug report with required data.