Get Plane Normals In Gltf Model

Hi there!
I want to implement deterministic dice rolling with a physics engine and I wonder, how I can identify the side of the dice, which is on top. Ideally, I would have some named normals, to compare this with the up vector. But I have no idea, if this is possible with GLTF.
EDIT: I want this not only for six sides dies, but also for dice with 8, 10, 12 and 20 sides.
Do you have any ideas, how I could identify the sides of a loaded model?
Regards
Jonas

Hello!
Yes, you should be able to do that by checking the world transform of the model. Here is an example:
// Depending on the implementation of the physics, maybe it's not possible to do an exact compare "===". In that case you need to compare using some epsilon value.

if (model.worldTransform.up[1] === 1) {
    console.log("up")
}
if (model.worldTransform.up[1] === -1) {
  console.log("down")
}
if (model.worldTransform.up[0] === -1) {
  console.log("left")
}
if (model.worldTransform.up[0] === 1) {
  console.log("right")
}

Let's say the number 6 is the top of the gltf model, if the up vector of world transform is pointing up, then number 6 has landed pointing up. If you know one side, you can easily figure out the other sides as well.

Hi!
Thank you for your reply! I guess I forgot one important detail regarding my problem:
I want to implement this also for dice with 8, 10, 12 and 20 sides. Those dice don't have that regular plane orientation and therefor the planes/normals are (at least for me) not trivial to detect.
This is why I consider information inside the model much easier to process.
Any ideas how to do this?

In that case I would add a plane mesh for each side of the dice. That mesh should be rotated to match the normal of that side. If you do that you can easily read the "up" value of the transform. You can name these meshes so they can be identified in code.
let _1 = model.meshes.find(m => m.name === "1")
// ...
let _6 = model.meshes.find(m => m.name === "6")

if (_1.worldTransform.up[1] === 1) {
  console.log("side 1 is pointing up)
}
if (_6.worldTransform.up[1] === 1) {
  console.log("side 6 is pointing up)
}

If you don't want to render that plane mesh you can make it transparent.
_6.material.transparent = true
_6.material.baseColor[3] = 0

Hi!
This looks good. I will try this out shortly and will be giving feedback then!
Regards
Jonas

Hi again!
As I am digging deeper into it, I came to the conclusion, that the whole process doesn't make sense, without having the correct physics body for the dice.
I now have very simple dice models (no additional polys) and I am loading them as a GLTF. The next step is to create a ConvexPolyhedron with Cannon-ES from those indices and vertices. This is where I am struggling right now. The D6 for example.

it has an integer indices buffer of length 36: 6 sides x 2 Tris x 3 Indices = 36. Great.
but the position buffer (vertex buffer I guess) holds 72 entries: 8 corners x 3 numbers (xyz) is 24. It says stride 12 though. Do I simply ignore those additional numbers? I am a little lost here.

I hope I could make myself clear and you are able to help me.
All the best
Jonas

OK, I realize, this is something pretty specific to the GLTF Format and I guess nothing exactly pixi3d related. I am trying to build a collider body from the Gltf data right now.
I'll keep you updated.

When creating the ConvexPolyhedron, it seems (according to the API) that it want points and faces. Cant you just read the values directly from the model and use those?
let faces = model.meshes[0].geometry.indices
let points = model.meshes[0].geometry.positions

Yes, but the number of positions seemed odd to me. I ignored my doubts and sticked to the receipe - which seems to work :)
I'll need to get the animations and physics going and will keep you in the loop.

It is - indeed -pretty simple to do this with TriMesh:
    createTriMesh(mesh: Mesh3D): CANNON.Trimesh {         return new CANNON.Trimesh(             mesh.geometry.positions.buffer as unknown as number[],             mesh.geometry.indices.buffer as unknown as number[]);     }


Using dot-notation in creation view

First of all, thanks for the great library.
I am using version 0.8 of the library. I tried using the ability to use dot notation introduced in https://github.com/marmelab/ng-admin/pull/549 and in listView it works fine.
However, if I use the same in creationView,
    bus.creationView()
        .fields([
            ...
            nga.field('driver', 'reference')
                .label('Usual driver')
                .targetEntity(driver)
                .targetField(nga.field('person.firstName'))
                .sortField('person.firstName')
                .sortDir('ASC'),
            ...
        ]);

does not seem to work.
The GET request looks like
http://.../driver?pageRows=30&pageStart=0&sortDir=ASC&sortField=person
Even though the server ignores the erroneous sortField and sends the correct JSON, I do not see a dropdown.

This issue has since been fixed.


This needs a few tests

I try running the tests and:
[08:05:30] Using gulpfile ~/tmp/nuka-carousel/Gulpfile.js
[08:05:30] Starting 'lint'...
[08:05:30] Finished 'lint' after 506 ms
[08:05:30] Starting 'karma'...
ERROR [config]: File /Users/jherri1/tmp/nuka-carousel/karma.conf.js does not exist!```

Tests are in!


https://github.com/openai/triton#compatibility Only supports Linux. (Or WSL2, but not guaranteed)

          > > https://github.com/openai/triton#compatibility Only supports Linux. (Or WSL2, but not guaranteed)

But someone did make it work:
pip install https://huggingface.co/r4ziel/xformers_pre_built/resolve/main/triton-2.0.0-cp310-cp310-win_amd64.whl

Thanks, you save my time, Triton is now installed in Windows 11
Originally posted by @MazenVR in https://github.com/openai/triton/issues/1560#issuecomment-1598131953
I don't know how to modify it
def default_cache_dir():
return os.path.join(os.environ["HOMEPATH"], ".triton", "cache")
def libcuda_dirs():
locs = subprocess.check_output(["whereis", "libcuda.so"]).decode().strip().split()[1:]
return [os.path.dirname(loc) for loc in locs]
File "C:\Users\b9713\AppData\Roaming\Python\Python310\site-packages\triton\compiler.py", line 1155, in _build
cuda_lib_dirs = libcuda_dirs()
File "C:\Users\b9713\AppData\Roaming\Python\Python310\site-packages\triton\compiler.py", line 1134, in libcuda_dirs
locs = subprocess.check_output(["whereis", "libcuda.so"]).decode().strip().split()[1:]
File "G:\ProgramData\anaconda3\lib\subprocess.py", line 421, in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "G:\ProgramData\anaconda3\lib\subprocess.py", line 503, in run
with Popen(*popenargs, **kwargs) as process:
File "G:\ProgramData\anaconda3\lib\subprocess.py", line 971, in init
self._execute_child(args, executable, preexec_fn, close_fds,
File "G:\ProgramData\anaconda3\lib\subprocess.py", line 1440, in _execute_child
hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
FileNotFoundError: [WinError 2]

Hi, I met the same problem. Have you solved it?


Offload parsing to a new server

That will keep from bogging down the public-facing server.

[x] stand up an EC2 Micro
[x] move over /includes/ and /cron/
[x] update the cron jobs to point at the new server
[x] modify the downloads script to use S3 (#15)

Done.


Extending Array breaks constructor

While playing around with the extending expressions feature added in 1.6, I noticed that extending
Array will somehow break the constructor.
TypeScript Version:
1.8.7
Code
class ExtArray<U> extends Array<U> {

   // Doesn't matter if this constructor is present or simply omitted
    constructor(...args : U[]) {
        super(...args);
    }

    public contains(element : U) : boolean {
        var i = this.indexOf(element);
        return i !== -1;
    }
}

var test : ExtArray<string> = new ExtArray("a", "b", "c");

test.push("y");

console.log(test.length); // 1

console.log(test[0]);  // y
console.log(test[1]);  // undefined
console.log("Has a: " + test.contains("a"));  // Has a: false
console.log("Has y: " + test.contains("y"));  // Has y : true

There is also a Typescript Playground version of this example.
Expected behavior:
The normal array constructor adds any parameters passed to it as elements to the array.
I would expect that the ExtArray constructor, given above, does the same.
Especially since I could not find anything contradicting this assumption in the documentation.
Actual behavior:
The elements passed to the constructor are not added to the array, but the push method still seems to works.
Additional Information:
I've already asked a question regarding this problem on stackoverflow.
As Nathan Friend points out in his answer there,
extending Array will also break JSON.stringify and it will lead to inconsistent result when checking if something is an array.
These problems might be related to the constructor issue in some way.

There isn't anything TypeScript can do about this -- it's just how Array's weird runtime behavior works.
See also http://perfectionkills.com/how-ecmascript-5-still-does-not-allow-to-subclass-an-array/

Okay I was afraid this would be the case, thanks for the confirmation anyway.
In that case you should consider adding a warning somewhere in the documentation,
since I used code similar to above in a project and if you only initialize empty things,
everything looks fine.
Then I needed to initialize the array with a default value and everything broke.
Took me quite a few moments to figure out what goes actually wrong.


Bonnell:Configure LED rollups for the missing FRUs

Some of the inventory FRUs LED configurations are missing in bonnell led config JSON which are addressed in this commit.

change ddimm to dime for all fault and identify

resolved


Method coverage result does not match with line coverage.

I have a method Signup and you can see on right hand side, my method's exception and one if condition isn't covered in unit test. In the Code Editor I can see correctly that my statements aren't covered in unit test.
On left hand side tree, you can see that it displays 100% for the signup method, I think left side report is only considering whether the method is covered or not.
I have written unit test for only one method in entire project. There is no other class with Signup method.

I cannot reproduce this, I checked a large project with many exceptions, and seems to work correctly.

Can you double click the method in the tree view, or press the source button when selected? This way we know it is the same method.
Can you check if the merge-by-hash option is enabled in settings?
Is the problem happening if you rerun the coverage report?

If that does not uncover the reason please try to make an example project demonstrating the issue.

Also if you check the image it says there is 3 lines in the method, while your method is clearly longer than that. Maybe it is still somehow a different method, e.g. an overload, or part of a base class.
Anyways double click it in the tree, and see where it leads you.

I found out the reason, method is same but it has an inline lambda. Most of code is inside inline lambda. Method is like...
       return Invoke( db =>
       {
                 ......
                 ......
                 ......
       });

       public ActionResult Invoke(Func<AppDbContext,ActionResult> dbFunc){
             try{
                  ...
                  var db = .... getdb();
                  ...
                  return dbFunc(db);
             }
             catch(Exception ex){
                 ....
             }
       }

Lambda expressions result in new functions and classes so they are shown elsewhere.

So I think this is OK behavior - while these anonymous types and methods show up kind of ugly with their mangled names, but in other update I am grouping them which will organize things better.
If you still have a problem please tell, otherwise I suggest to close the issue.

@axodox will update display correct coverage after adding up anonymous methods? I was able to drill down anonymous folder and was able to find fragments of method, but it is just difficult to calculate total coverage, you can close this for now and if in new update if things aren't clear then I will reopen the issue.

No, the coverage is correct right now and there is no plan to sum up these lambdas.
I will take your example to explain you why:

we see that Invoke is a normal function outside your method
we also see that db => ... is a function, which is defined in your method, but it is not part of it - e.g. you can store it, and use it elsewhere, just like other methods.

While you could say: but I can use my local variables inside db => ...
That is however just syntactic sugar, as in reality the compiler adds a class and stores the data and your db => ... method there.
Because of this we cannot sum db => ... coverage up to your method. As it could be called from multiple methods which would result in higher coverage than it really is. Just remember that in reality there is no difference in how Invoke and db => ... is called internally.
That being said I agree that the problem you describe is real - it is harder to read the coverage like this. But it is also harder to read the stack trace. I have a simple solution: limit your lambdas to short length, otherwise just define an ordinary method in your class, or if you need to store data, define a class to store it and use one of its methods to do the job. This is actually what the compiler does for you!

I believe this is still solvable as method has line number information from where it starts and where it ends, code editor perfectly displays lines that are covered and lines that are not, if you try to sum up lines, you might be able to get correct result.

So what you want is that if a anonymous method / lambda expression is defined inside another method, we should remove it from results, and add its branch and coverage points to the method defining it?
This would obviously have nothing to do with its being called from the given method or not. E.g. the method could put it in a queue, from which another thread could execute it later. Also lambdas outside methods would remain there as anonymous methods.
It would work though... Ok I might consider adding this as an option, but I would take it as low prio for now.

If my understanding is right we can add a new enhancement issue for this. We could title it: "Add option to include lambda coverage in parent method for easier comprehension of coverage report" - well something like this but shorter...

Yes, Methods today contain lambda expressions and think of new inline functions included in c# 7.0, this will be important for inline functions as well. I think added option would be nice.


Added button to set a project as default

Changes:

Added a button to set a project as default.
Added Indicator whether a project is default or not.

@skks1212
I have made the necessary changes that you indicated:

Removed hover effects and added disabled cursor for disabled buttons.
Removed border for "Set as default" button


Fixes computation of parent.

If there is a file without a basename in root, e.g. .htaccess,
#parent of another file in root finds .htaccess instead of
index.html.
Adding the .htaccess to the traversal-app fixture exposes this error.
The fix is to no longer scan for possible files if we know the parent
must be root.
Fixes #1463

Find adding a test case for this fix?

The middleman-core/fixtures/traversal-app/source/.htaccess file added in my PR already made features/sitemap_traversal.feature fail:
  expected "Path: directory-indexed.html\n\nSource: source/directory-indexed.html.erb\n\n  Parent: .htaccess\n\n  Child: directory-indexed/sibling.html\n  Child: directory-indexed/sibling2.html\n  Child: directory-indexed/sub2/index.html\n  Child: directory-indexed/fake.html\n  Child: directory-indexed/fake2.html\n\n\n    Data: {\"title\" => \"Title of Sibling One\"}\n    Data: {\"title\" => \"Title of Sibling Two\"}\n    Data: {}\n    Data: {}\n    Data: {}\n" to include "Parent: index.html"
  Diff:
  @@ -1,2 +1,19 @@
  -Parent: index.html
  +Path: directory-indexed.html
  +
  +Source: source/directory-indexed.html.erb
  +
  +  Parent: .htaccess
  +
  +  Child: directory-indexed/sibling.html
  +  Child: directory-indexed/sibling2.html
  +  Child: directory-indexed/sub2/index.html
  +  Child: directory-indexed/fake.html
  +  Child: directory-indexed/fake2.html
  +
  +
  +    Data: {"title"=>"Title of Sibling One"}
  +    Data: {"title"=>"Title of Sibling Two"}
  +    Data: {}
  +    Data: {}
  +    Data: {}
   (RSpec::Expectations::ExpectationNotMetError)
  ./lib/middleman-core/step_definitions/server_steps.rb:93:in `block (2 levels) in <top (required)>'
  ./lib/middleman-core/step_definitions/server_steps.rb:92:in `/^I should see "([^\"]*)"$/'
  features/sitemap_traversal.feature:67:in `Then I should see "Parent: index.html"'

Changing the code in traversal.rb made the tests green again.
What kind of test do you think is missing? Would you please give me a hint? Another cucumber feature? A unit test? I'll add one.

Ah, I get it. Nice. Everything's good then.


chore: clean up unused files

:tada: This PR is included in version 0.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Document or caveat schema change rollbacks

@lucy-zhang pointed out that some schema changes are not completely rolled back when run inside a transaction that fails. For example, it's possible that an ALTER TABLE RENAME COLUMN operation would succeed despite other statements in a transaction being rolled back. We now have an error code to alert users that this may occur, but this has not yet been added to the docs; we should add a "known limitation" to the schema change docs in the meantime.

Piggybacking on top of this, we don't actually document anywhere that I can find what happens when a schema change fails. Does the index need to be dropped? Is it rolled back automatically? What should the appdev do next?

Error code mentioned above is documented (as of Rich's PR).
Still need to fill out the schema docs, per Andy's questions.

from awerner: I believe that the answer is that it should be cleaned up automatically and the user does not need to do anything. paul is working on making sure this is true in the upcoming release right now.
lzhang: yeah, what andrew said, except that there are problems with rolling back schema changes in transactions to watch out for, already documented here: https://www.cockroachlabs.com/docs/v19.2/online-schema-changes.html#schema-change-ddl-statements-inside-a-multi-statement-transaction-can-fail-while-other-statements-succeed
will follow up with paul.


Rspack doesn't show error overlay in the FS project

@hyf0 is it fixed now?

nope

close for missing more information


All tensors must be on devices[0]: 0

🐛 Describe the bug
For https://github.com/hpcaitech/ColossalAI-Examples/tree/main/image/resnet, when use python -m torch.distributed.launch --nproc_per_node 2 --master_addr localhost --master_port 29500  run_resnet_cifar10_with_engine.py, there is an error that All tensors must be on devices[0]: 0
Environment
torch=1.8.1

Hi, did you build colossalai from source?

yes, using nproc_per_node 1 is ok. but nproc_per_node 2 will meet this error.

Ok, let me try to reproduce this error. May I know which GPU you are using and how many GPUs are available on your machine?

Tesla-V100 and 2GPUs are avaliable in my machine.

Got, let me try to reproduce this issue. I will get back to you soon!

Hi, sorry for my late reply. We only got A100 machines so it took a while for me to look for a V100 machine. This bug can be reproduced on torch 1.8 but not torch 1.10. This bug is due to an optional argument in pytorch DistributedDataParallel. This bug will be fixed in #194 .


index vs corpus for permanode-attr searches

Currently, there are two public APIs that allow a client to search for a given permanode by attribute. Specifically, client.Query and client.GetPermanodesWithAttr.
However, they have distinctly different performance characteristics.
Searching permanodes by attribute through Query hits the corpus, but does an O(n) scan through all permanodes.
Using the GetPermanodesWithAttr way ends up taking sub-linear time because the index has a mapping from signer to attribute to permanode.... though it only has that mapping for a small set of indexed attributes, and otherwise the method doesn't work at all, and it's probably hitting the disk depending on the indexer setup.
I think that we shouldn't have two independent ways to do the same thing, so I do think one of those methods should go away... and I think GetPermanodesWithAttr, being the older and less flexible method, is the obvious candidate to go.
That still leaves us with a few options for what to do however:

Keep the client API method, but have it internally translate to query and back, accept the significant slow-down.
As above, but optimize corpus (what query uses) to be fast for this too.
Delete the method entirely.
Give up on corpus entirely, translate query to work via index instead and gain the speedup that way.

Option 1 is obviously the easiest to do and 4 is the hardest. 2 includes a tradeoff of increased corpus memory usage (especially if we index all attributes in memory), but seems to be the right thing to do if we wish to continue using corpus in the medium term.
@mpl @bradfitz, I'm curious if either of you have strong opinions on what the future of index vs corpus should look like, either on a larger scale or for this specific case.
I worry that if we keep adding things to corpus and our memory usage keeps creeping up we may end up re-inventing leveldb or sqlite.... but on the other hand, it's possible we'll never actually hit the point where memory usage becomes unreasonable, at which point this will certainly save developer time and be quite fast.
I'd personally prefer the index approach vs the corpus approach in the long term, but it seems like corpus has advanced to the point where it's the pragmatic approach for the time being.
Note, I verified that the two methods have different performance characteristics by adding the following benchmark to pkg/search/handler_test.go:

func BenchmarkPermanodeQueries(b *testing.B) {
	defer index.SetVerboseCorpusLogging(true)
	index.SetVerboseCorpusLogging(false)

	idx := index.NewMemoryIndex() // string key-value pairs in memory, as if they were on disk
	idd := indextest.NewIndexDeps(idx)
	h := NewHandler(idx, owner)
	corpus, err := idx.KeepInMemory()
	if err != nil {
		b.Fatal(err)
	}
	h.SetCorpus(corpus)

	// arbitrary numbers
	numPermanodes := 20000
	numIndexed := numPermanodes / 10

	for i := 0; i < 20000; i++ {
		pn := idd.NewPermanode()
		if i < numIndexed {
			idd.SetAttribute(pn, "title", fmt.Sprintf("benchmark_permanode_%v", i))
		}
	}
	b.ResetTimer()

	b.Run("GetPermanodesWithAttr_all", func(b *testing.B) {
		for i := 0; i < b.N; i++ {
			res, err := h.GetPermanodesWithAttr(&WithAttrRequest{
				Signer: ownerRef.BlobRef(),
				Attr:   "title",
			})
			if err != nil {
				b.Fatalf("error getting permanodes with attr: %v", err)
			}
			if len(res.WithAttr) != numIndexed {
				b.Errorf("expected %v with title, got %v", numIndexed, len(res.WithAttr))
			}
		}
	})
	b.Run("Query_all", func(b *testing.B) {
		for i := 0; i < b.N; i++ {
			res, err := h.Query(context.Background(), &SearchQuery{
				Limit:    numPermanodes,
				Describe: &DescribeRequest{},
				Constraint: &Constraint{
					Permanode: &PermanodeConstraint{
						Attr: "title",
						ValueMatches: &StringConstraint{
							HasPrefix: "",
						},
					},
				},
			})
			if err != nil {
				b.Fatalf("error in query: %v", err)
			}
			if len(res.Blobs) != numIndexed {
				b.Errorf("expected %v with title, got %v", numIndexed, len(res.Blobs))
			}
		}
	})
	b.Run("GetPermanodesWithAttr_1", func(b *testing.B) {
		for i := 0; i < b.N; i++ {
			res, err := h.GetPermanodesWithAttr(&WithAttrRequest{
				Signer: ownerRef.BlobRef(),
				Attr:   "title",
				Value:  "benchmark_permanode_0",
			})
			if err != nil {
				b.Fatalf("error getting permanodes with attr: %v", err)
			}
			if len(res.WithAttr) != 1 {
				b.Errorf("expected 1 with title, got %v", len(res.WithAttr))
			}
		}
	})
	b.Run("Query_1", func(b *testing.B) {
		for i := 0; i < b.N; i++ {
			res, err := h.Query(context.Background(), &SearchQuery{
				Limit:    -1,
				Describe: &DescribeRequest{},
				Constraint: &Constraint{
					Permanode: &PermanodeConstraint{
						Attr: "title",
						ValueMatches: &StringConstraint{
							Equals: "benchmark_permanode_0",
						},
					},
				},
			})
			if err != nil {
				b.Fatalf("error in query: %v", err)
			}
			if len(res.Blobs) != 1 {
				b.Errorf("expected 1 with title, got %v", len(res.Blobs))
			}
		}
	})
}

Output:
BenchmarkPermanodeQueries/GetPermanodesWithAttr_all-4         	     200	  10516509 ns/op
BenchmarkPermanodeQueries/Query_all-4                         	     200	   9643742 ns/op
BenchmarkPermanodeQueries/GetPermanodesWithAttr_1-4           	  100000	     16773 ns/op
BenchmarkPermanodeQueries/Query_1-4                           	    3000	    527373 ns/op
PASS

iirc, after Query had stabilized, the plan was indeed to get rid of most of the index exported methods, such as GetPermanodesWithAttr. Or at least clean things up so the index Interface itself would not require to implement so many specific methods. We've just not done it because there wasn't any harm in keeping them so far.
On that note, I think we've also slowly moved towards other components just taking/using directly an *index.Index, instead of an index.Interface, because the abstraction did not seem very useful in the end.
As for the index VS corpus question, it seems to have worked pretty well so far to just optimize on a case by case basis. So yes, until it looks like the corpus size is actually a problem, I don't think we're going to give up on the corpus approach.
I mean, probably not unless someone else comes up with a good alternative plan, since we have other priorities.
Speaking of which, I think one of our more urgent concerns in this area is optimizing reindexing. @bradfitz already has ideas about it afaik.


Prepared statement support for JDBC Client

@mrigger this adds support for prepared statement in the JDBC driver. It should not affect you, but if it does, please let me know.

Okay, thanks for the info! I did not notice any differences since the PR has been merged.


lib/ not included in latest release

In the latest release, the lib/ folder is missing. Since the main property in package.json refers to lib/index.js, this crashes the tests.
I'll make a pull request so it automatically includes the transpiled babel files when publishing, so this never happens again.

Thank you for this help :) I published with your pr, pls report if its good and then we can close :)

It's fine now! Thank you!!


How to get AudioSet-V2A?

Could you please release the url list of this subset for AudioSet? Or upload this to Huggingface dataset? This is kinda important if anyone want to compare with your model.

Any update on this? @luosiallen

Hi, I have the same question.

What video-ids are in AudioSet-V2A?
How do you filter these videos?


High load on raspberry

I have a raspberry pi3 with two SDM630 attached via USB connector on one bus running at 9600 baud. When the http daemon is running the load is 0.65 when a single browser window is connected load is 1.25.
This seems rather high given that the pi3 is quite capable?

I am currently testing on Raspberry Pi 1 Model B+ and cpu usage is 75% only by sdm630_httpd.

im with RPI3 and besides the high cpu, it uses 900 MB of memory and stops responding every few days. is there a way to just get single measurement without starting the server?

Had to put baudrate to 2400 baud to get 4 seconds latency (tested by pulling out devices). 9600 baud gave me a whopping 20 seconds. (using RaPi Model B 1, so yeah. But it works.)

Imho the problem is not the http daemon but the fact that the longpoll library constantly hits the httpd. I'm working on moving from longpoll to websockets which should improve the load.

Closing as duplicate of #13

See https://github.com/gonium/gosdm630/pull/38 for a websocket implementation- i would appreciate test feedback


port CI changes

ports decoupled CI changes to v4.0.13 which is released at
https://www.swiftnav.com/resource-library?product=Swift+Console&category=Installer&release=Latest&search=Swift+Console&filters=no&title=Swift+Console

Do we need the Cargo.lock changes?

Do we need the Cargo.lock changes?

maybe not but since the main issue is sysinfo/ntapi not being updated maybe just keep

Should this be merged into this branch? https://github.com/swift-nav/swift-toolbox/tree/swift-toolbox-v4.0.0-branch

Should this be merged into this branch? https://github.com/swift-nav/swift-toolbox/tree/swift-toolbox-v4.0.0-branch

both branches are identical
oh didn't realize there already is a branch for that. 👍

Assuming there are changes to the CI repo that we'll need too? Do we need to branch the CI repo?

yep we do, currently here:
https://github.com/swift-nav/swift-toolbox-ci/pull/11
there are some issues with mac signing which looks odd 🤔
https://github.com/swift-nav/swift-toolbox-ci/actions/runs/4933517260/jobs/8818076340
other than that it seems like it would release just fine

https://github.com/swift-nav/swift-toolbox/releases/tag/v4.1.11
release was successful after retry

Frontend and Release Workflow Started here

oops, didn't mean to close the PR

Frontend and Release Workflow Started here

Decoupled CI is working, just taking a bit longer, I think we adjust the timeout to 45 minutes it should pass cleanly: https://github.com/swift-nav/swift-toolbox-ci/actions/runs/4942658545


Unique over the records of current tenant only

Description

What if I want a record to be unique only over the records of the current tenant, not across the entire table?

Here, name is unique within the current business (tenant), but different business can have the same name.
Code style

[x] composer cs command has been run.

Testing

[x] Changes have been visually tested.

Documentation

[ ] Documentation is up-to-date.

The form builder can be installed outside of the panel builder. Having a feature like this would cause issues for people who use it like that.

This can be implemented in userland using the modifyRuleUsing parameter of unique()


Removed Scene.sunColor property

fixes #8517

Thank you so much for the pull request @YoussefV! I noticed this is your first pull request and I wanted to say welcome to the Cesium community!
The Pull Request Guidelines is a handy reference for making sure your PR gets accepted quickly, so make sure to skim that.

:x: Missing CONTRIBUTORS.md entry.

Please add yourself to the contributors file!

:heavy_check_mark: Signed CLA found.
:grey_question: Unit tests were not updated.

Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

Perfect!


Diary posts on our progress

Per convo at gitter, we will line up a series of OpenStreetMap diaries.  Intent is to:

update the community on the progress of this import,
share what we built to do execute the import (tools, processes, etc)
invite the community to participate

Here's a couple of ideas, we can divide them into a series of posts for each of us to work on:

[ ] Status of the import (stats, events, etc);
[x] Quality of data we are importing (not just building shapes but also height, year built, building types, etc);
[x] Tools we built (data conversion, tagging, Tasking Manager customizations, JOSM plugin); @maning
[ ] Working with the community (mapathons, coordination with LA City planning office). @jschleuss

At the end of the posts, lets invite the community to join in the effort and see us present at the SOTM-US next month.
More ideas?
@almccon @jschleuss @cityhubla

This sounds great to me. I can take the community angle.

Tools diary post: https://www.openstreetmap.org/user/manings/diary/38969

Data quality post: http://www.openstreetmap.org/user/manings/diary/39081

Community post: https://www.openstreetmap.org/user/schleuss/diary/39161
Will do another one with the government help/communication.

Also posted this https://www.openstreetmap.org/user/schleuss/diary/39136
which is related

All done here. Closing.


Spike a GitVersionControlSystem

This spike just shows as a proof of concept how we can generically
approach version control system integration. This spike demonstrates:

The use of a VersionControlSpec to define the url of the
remote repository.
The use of a VersionControlSystem as the high-level abstraction
for all version control systems.
A very rudimentary implementation of the populate method
for a GitVersionControlSystem
An initial fixture for testing our Git integration.

The spike does not yet cover:

How to get an instance of the correct type of version control
system based on the type of the version control spec that was
provided. But, we'll probably use some version control
system registry.
Sophisticated handling for many common scenarios when
populating a working directory from a repository.

Working directory exists and has correct remote.
Working directory exists but is not a git repository.
Working directory exists but has other remote.
Multiple working directories for the same remote.
Poorly formed user-input.

@big-guy, the more I've been looking into how to add resource-locking, the more I feel like it should be done as a separate pull request on top of this one (and maybe even on top of what you are working on in #2773)
Here's my reasoning. I think the VersionControlSystemRegistry really should be part of the SourceControl implementation.  Also, the files in this pull request are not actually responsible for implementing the resource locking. So, from the point of view of separation of concerns, that functionality really belongs in a different part of the codebase.  I think this pull request is a good increment toward what we really want to build, and we can improve on top of it later as we wire the parts of the system together.


initial list of Red Hat authors

resolves https://github.com/rht-labs/rht-labs-library/issues/6

Sweet! Merged!


Lot's of http 0's

I've been trying to track errors from colly which I would think mostly amount to bad links. However, as soon as I started tracking via the OnError callback:
c.OnError(func(r *colly.Response, err error) {
		if r.StatusCode >= 400 || r.StatusCode < 200 {
			log.Printf("Bad link found <%d>: %s\n", r.StatusCode, r.Request.URL.String())
			bad_links = append(bad_links, r.Request.URL.String())
		}
	})

Now I see that a large % of requests return Bad link found <0>:... in the logs for all test sites I use. When I curl some at random, I get 200 every time and the response is fast so it shouldn't be a timeout issue. I've also considered there might be a blocking issue although my test sites are people's personal sites that should have close to no protection so I tried with a proxy gateway that requests from a different proxy on each request and got the same results - a large percentage of Bad link found <0>:....
All of these errors are net/http: request canceled (Client.Timeout exceeded while awaiting headers)
I will debug more but wanted to bring this up in case you had some idea of why this would happen. One of the test sites I am using is http://peaksmaker.com

Ok so a bit more information - all of these errors are net/http: request canceled (Client.Timeout exceeded while awaiting headers)

Do you have a test URL where I can reproduce the error?

@asciimoo Btw - I will try the limit rule soon and see if that helps.  Two URL's I have issues for:
http://peaksmaker.com
https://www.millcreekhtg.com/
I can probably give you 100 if you want 'em!

I confirmed the issue is the server


KAFKA-8356: add static membership info to round robin assignor

The purpose here is to leverage static membership information during round robin consumer assignment, because persistent member id could help make the assignment remain the same during rebalance.
The comparison logic is changed to:

If member A and member B both have group.instance.id, then compare their group.instance.id
If member A has group.instance.id, while member B doesn't, then A < B
If both member A and B don't have group.instance.id, compare their member.id

Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Retest this please

Retest this please

Could you rebase?

Retest this please

retest this please

@guozhangwang rebased, let me know your thought!

Retest this please

clients:checkstyleTest failed.

Retest this please

Retest this please


Your session crashed after using all available RAM

I am using Free Google Colab-Notebook and GPU
I want to quantize a 7B model but am not able to quantize even getting an error when downloading the model from hugging face I simply pass the model id-"senseable/WestLake-7B-v2" but when it starts to download it occupied all the RAM. even though I passed Cuda to use Free Colabe GPU it again loaded on RAM and gave me an error that it uses all available RAM.

when I use BitsAndBytes quantization I simply pass BitsAndBytesConfig to AutoModelForCausalLM and it quantizes the model during Downloading on 4bit quantization it almost takes 5.5 GB of GPU so I use free Colab GPU
bnb_config = BitsAndBytesConfig(
load_in_4bit=True,
bnb_4bit_compute_dtype=torch.bfloat16,
bnb_4bit_quant_type= "nf4",
bnb_4bit_use_double_quant=False,
)
model= AutoModelForCausalLM.from_pretrained(
"senseable/WestLake-7B-v2",
device_map="auto",
quantization_config=bnb_config,
trust_remote_code=True,
use_flash_attention_2=False,
torch_dtype=torch.bfloat16,
)

Can I perform HQQ-Quantization using AutoModelForCausalLM, I did not want to download the model and then perform HQQ quantization it may not be possible on free Colab GPU.
How can I perform HQQ-Quantization during downloading of the model as I did in BitsAndBytes-Quantization during downloading the model ?

The current version requires the model to be on CPU, because the library is designed to work on any model, not necessarily a Hugging Face model. You'll need about 14GB of RAM (not Vram) to store the 7B model as fp16 on the CPU, free Google colab doesn't offer enough RAM that's why it crashed.
If you want to HQQ quantize Hugging Face models like how BNB does, you can use our branch of transformers that implements HQQ, which allows dynamic loading and quantization and that RAM issue shouldn't happen: https://github.com/huggingface/transformers/pull/29637


Interpolation with non-default templating

If you are using django or some other backend framework that uses  mustache style syntax {{ }} will this work? I noticed that some of the code already includes {{ in the templating. Vue.js allows you to config it with whatever templating you want but here not sure if that is possible. For instance:
delimiters

Type: Array<String>

Default: ["{{", "}}"]

Usage:

// ES6 template string style
Vue.config.delimiters = ['${', '}']

Your backed templating framework most likely provides a way to escape the braces. For example Blade uses @ before the opening brace for that purpose.

Django does allow me to change delimiters just like vue.js does... this framework doesn't though
Guess I'll have to use https://github.com/JosephusPaye/Keen-UI/blob/master/dist/keen-ui.js
because my django project is huge and used internationally can't just change global configuration for 100s of companies one day and say good luck.

You shouldn't really care about the templates of third-party components (e.g. vue-strap), because templates are encapsulated in the components and will not affect your code. And you can always use  instead of {{ value }}.
Also I have looked it up, and Jango provides {% verbatim %} ... {% endverbatim %} to for escaping.

Thanks for looking that up it would be annoying/difficult to do that but it might be easier to do that I think I would still need to use that verbatim every time I have script and not globally reconfigure my delimiter, because this library assumes that Vue will compile the {{ and Vue will no longer be looking for that... either way I can with not too much re-architecture things so that its always rendered in a partial with the verbatim active.


End user navigation between process tasks

Description
When we give the app developers more possible tasks in a process, including the ability to define what tasks are possible to move between, we need to show the end user using the app in altinn.no how to navigate between the tasks.
Ideas

Create classes to represent different parts of a process. Class for the process itself, classes for tasks, sequences, conditions etc.
Create a system for "running" generic tasks.

In scope

To what degree do we need / want to show the user how far in a process they have gotten?
How do we enable navigating to the next / previous task?
When/how do we allow navigating to/from the inbox (or other parts of SBL)?

Out of scope
This analysis should not define new possible tasks in a process - use tasks already identified at the start of the analysis as foundation.
Consideration
Return back to previous task
We need to use BPMN to design the process that supports a return to a previous task. In BPMN this is the current template with only "one way"

<bpmn2:definitions id="Altinn_Data_Confirmation_Process_Definition">
  <bpmn2:process id="Altinn_Data_Confirmation_Process" isExecutable="false">
    <bpmn2:startEvent id="StartEvent_1">
      <bpmn2:outgoing>SequenceFlow_1</bpmn2:outgoing>
    </bpmn2:startEvent>
    <bpmn2:task id="Task_1" name="Fyll ut skjema" altinn:tasktype="data">
      <bpmn2:incoming>SequenceFlow_1</bpmn2:incoming>
      <bpmn2:outgoing>SequenceFlow_2</bpmn2:outgoing>
    </bpmn2:task>
    <bpmn2:task id="Task_2" name="Bekreft skjemadata" altinn:tasktype="confirmation">
      <bpmn2:incoming>SequenceFlow_2</bpmn2:incoming>
      <bpmn2:outgoing>SequenceFlow_3</bpmn2:outgoing>
    </bpmn2:task>
    <bpmn2:endEvent id="EndEvent_1">
      <bpmn2:incoming>SequenceFlow_3</bpmn2:incoming>
    </bpmn2:endEvent>
    <bpmn2:sequenceFlow id="SequenceFlow_1" sourceRef="StartEvent_1" targetRef="Task_1" />
    <bpmn2:sequenceFlow id="SequenceFlow_2" sourceRef="Task_1" targetRef="Task_2" />
    <bpmn2:sequenceFlow id="SequenceFlow_3" sourceRef="Task_2" targetRef="EndEvent_1" />
  </bpmn2:process>
 </bpmn2:definitions>

To support return the BPMN process need to add explicit flows for the return. The below diagram and BPMN file describe the above process with added return flow from Task 2 to Task 1. To implement

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions id="Definitions_10dklqb">
  <bpmn:process id="Process_1so39gt" isExecutable="false">
    <bpmn:startEvent id="StartEvent_1s67p7b" />
    <bpmn:startEvent id="Event_Start">
      <bpmn:outgoing>SequenceFlow_1</bpmn:outgoing>
    </bpmn:startEvent>
    <bpmn:task id="Task_1" name="Fyll ut skjema" altinn:tasktype="data">
      <bpmn:incoming>SequenceFlow_1</bpmn:incoming>
      <bpmn:incoming>SequenceFlow_3</bpmn:incoming>
      <bpmn:outgoing>SequenceFlow_2</bpmn:outgoing>
    </bpmn:task>
    <bpmn:sequenceFlow id="SequenceFlow_1" sourceRef="Task_1" targetRef="Task_2" />
    <bpmn:task id="Task_2" name="Bekreft skjemadata" altinn:tasktype="confirmation">
      <bpmn:incoming>SequenceFlow_2</bpmn:incoming>
      <bpmn:outgoing>SequenceFlow_3</bpmn:outgoing>
    </bpmn:task>
    <bpmn:sequenceFlow id="SequenceFlow_2" sourceRef="Task_1" targetRef="Task_2" />
    <bpmn:exclusiveGateway id="Gateway_1">
      <bpmn:incoming>SequenceFlow_3</bpmn:incoming>
      <bpmn:outgoing>SequenceFlow_4</bpmn:outgoing>
      <bpmn:outgoing>SequenceFlow_5</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:sequenceFlow id="SequenceFlow_3" sourceRef="Task_2" targetRef="Gateway_1" />
    <bpmn:sequenceFlow id="SequenceFlow_5" sourceRef="Gateway_1" targetRef="Task_1"  altinn:taskaction:leave="true" />
    <bpmn:endEvent id="Event_End">
      <bpmn:incoming>SequenceFlow_4</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:sequenceFlow id="SequenceFlow_4" sourceRef="Gateway_1" targetRef="Event_End" />
  </bpmn:process>
  </bpmn:definitions>

Optional / conditional tasks
A common scenario is to skip tasks based on business rules. The following diagram shows a flow with a optional signing step. This is a common scenario where the business rule could be based on data in form. (example minimum sales amount)

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:dc="http://www.omg.org/spec/DD/20100524/DC" xmlns:di="http://www.omg.org/spec/DD/20100524/DI" id="Definitions_1y7mtx0" targetNamespace="http://bpmn.io/schema/bpmn" exporter="bpmn-js (https://demo.bpmn.io)" exporterVersion="8.7.2">
  <bpmn:process id="Process_04vnahs" isExecutable="false">
    <bpmn:startEvent id="StartEvent">
      <bpmn:outgoing>Flow1</bpmn:outgoing>
    </bpmn:startEvent>
    <bpmn:task id="Task1">
      <bpmn:incoming>Flow1</bpmn:incoming>
      <bpmn:incoming>Flow5</bpmn:incoming>
      <bpmn:incoming>Flow7</bpmn:incoming>
      <bpmn:outgoing>Flow2</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task2">
      <bpmn:incoming>Flow2</bpmn:incoming>
      <bpmn:outgoing>Flow3</bpmn:outgoing>
    </bpmn:task>
    <bpmn:exclusiveGateway id="GateWay1">
      <bpmn:incoming>Flow3</bpmn:incoming>
      <bpmn:outgoing>Flow5</bpmn:outgoing>
      <bpmn:outgoing>Flow4</bpmn:outgoing>
      <bpmn:outgoing>Flow8</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:task id="Task3">
      <bpmn:incoming>Flow4</bpmn:incoming>
      <bpmn:outgoing>Flow6</bpmn:outgoing>
    </bpmn:task>
    <bpmn:exclusiveGateway id="Gateway2">
      <bpmn:incoming>Flow6</bpmn:incoming>
      <bpmn:outgoing>Flow7</bpmn:outgoing>
      <bpmn:outgoing>Flow9</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:sequenceFlow id="Flow1" sourceRef="StartEvent" targetRef="Task1" />
    <bpmn:sequenceFlow id="Flow2" sourceRef="Task1" targetRef="Task2" />
    <bpmn:sequenceFlow id="Flow3" sourceRef="Task2" targetRef="GateWay1" />
    <bpmn:sequenceFlow id="Flow5" sourceRef="GateWay1" targetRef="Task1" />
    <bpmn:sequenceFlow id="Flow4" sourceRef="GateWay1" targetRef="Task3" />
    <bpmn:sequenceFlow id="Flow6" sourceRef="Task3" targetRef="Gateway2" />
    <bpmn:sequenceFlow id="Flow7" sourceRef="Gateway2" targetRef="Task1" />
    <bpmn:endEvent id="EndEvent">
      <bpmn:incoming>Flow9</bpmn:incoming>
      <bpmn:incoming>Flow8</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:sequenceFlow id="Flow8" sourceRef="GateWay1" targetRef="EndEvent" />
    <bpmn:sequenceFlow id="Flow9" sourceRef="Gateway2" targetRef="EndEvent" />
  </bpmn:process>
</bpmn:definitions>

If we use an exclusive gateway the next method could identify that there are multiple flows and trigger a new App interface method that the app developer controls. That method could then be populated with logic that decided what the next task is.
Task validation
The current behavior is to validate if a task can be ended. That includes validating if the required attachment is attached and all data models connected to the task are valid. But this is not relevant if you are going back in the process.
We need to update the code so when the process is going backward this validation is not required.  The BPMN needs to define which flows that does not require validation. See suggestion in XML
Valid scenarios
We need to define what kind of scenarios Altinn Apps really want to support.

[ ]  Go back from ConformationTask to previous data task? Suggestion Yes
[ ]  Go back from SigningTask to previous data task? Suggestion Yes

The following flows would be invalid to set up in an Altinn Apps application

Go back to a signing task when signing has been completed
Go back from a data task
Go back passing a data task
Go back passing a signing task (reason: Signatures might be already downloaded and processed)
Go back passing a complete confirmation task (reason: Data might be already downloaded and processed)

Technical flows
Return to previous task
Technical flow when the instance is in Task 2 and user want to go back to Task1

Optional
In this process, the user does not dictate the next task, but the business logic decides based on the instance, possible the data and other aspects which task is next.

To support this we need a new method in App interface that let app developer build custom code to define which route from a gateway. Input to this needs to be instance and the process/gateway info.
In this way the logic can rely on the instanceValues or the data from the instance (using storage API)
Process navigation in frontend
The current views just expect that the only way to move in the process is forward. When there are multiple ways to go from a current task frontend needs to present the options to the users that they can go back to the defined

Frontend needs a way to get the Process options from current task. For that we need a new API that presented the current options, the title on that option and some indication which direction it is.
Task Authorization
We need to support the authorization of the user that chooses to move the process backward.
It is defined for each task type what is required to perform forward movement of process but it is not described what is required to backward.
Suggestion: User is authorized for Read at current task.
Default flows
We need to consider defining default flows if there are multiple flows out from a gateway. This to simplyfi API calls and to make it possible to trigger CompleteProcess.
See suggested example.
Coded Gateways.
Specification task

[ ] Define how a process flow can define that it is backward and does not need a valid current task to leave

Development task

[x] Update BPMN reader next elements to support gateways to identify possible
[x] Update CanTaskBeEnded to support taking in next element and based on that identify that task does not need to be validated since it is a backward direction
[ ] Update
[ ] Create OnProcessTaskRevisit method that unlock data
[ ] Update RegisterEventWithEventsComponent to support publishing of revisitTask
[x] Update AuthorizeAction and calling code so it nows it is a "backward" movement

Alternative technical approach
In the current implementation, lots of business logic is located inside the process controller and the  BMPN reader just for information about the process. The process is not responsible for doing any work.
Another approach is to introduce and ProcessEngine that is responsible for performing all business logic and trigger all other components that need to do work related to BPMN process.
See Altinn/altinn-studio#7067 for details
TBA
Analysis
Points discussed during a meeting Thursday 9. September:

Being able to navigate backwards in the process should require an explicit sequence flow going out of the current task and back to a earlier task in the process. It should not be possible to go back in a process if there are no such sequence flow declared in the BPMN.
It should already be possible to perform the "back" sequence by providing the id of the task the user want to go to as input to the "go next" API. The process "engine" will validate and ensure that it is valid by checking for a sequence flow.
One major hurdle is to unlock locked data elements. If the current task is a confirm "step", data elements have been locked, preventing any updates even if the process goes back to an earlier task. The data elements must bee opened again at some point.
Possible solutions:

Logic attached to a sequence flow performs the unlock. The logic could be triggered based on a naming convention of a sequence flow or a custom, Altinn specific, attribute on the sequence flow declaration.
Declaring a new type of task that can be automatically executed by the App. This is almost identical to the first suggestion. Instead of having the sequence flow point directly back to the earlier task it points to the automated "unlock task" which in turn points to the earlier process task. This is more complex, but we avoid attaching business logic to a sequence flow.
The issue here is the visual representation and added complexity for the app developer when working with the process. "Why do we need this weird task?" A tiny remedy could be to also have a separate task for locking, to pair up with unlocking.
We no longer lock the data elements when moving into a confirm task. Instead we prevent changes from being performed through authorization rules.

Instead of letting external systems (like the frontend) "navigate" the process by calling next, the decision making is moved to the process itself. The idea is that tasks declare themselves complete with some sort of end state and give control to the process that provides a new task (or end event) based on the situation.

The tricky bit here would be to provide the process the necessary information to determine what to do. Gateways can be coded and allowed access to instances that could be expanded with additional properties if needed. The logic could also get access to the data elements and even the actual data if needed.

Conclusion
TBD
Tasks

[ ] Is this issue labeled with a correct area label?
[ ] QA has been done

Resolved by https://github.com/Altinn/app-lib-dotnet/issues/192


Crash on Calendar Setup on Release Build Variant

Hello,
I am facing an error with the 1.0.0 version of the library when I setup my calendar.
The crash only happens in release build variants and seems to be related to #209.
Here the crashlog :
Fatal Exception: java.lang.NoSuchMethodError: No virtual method compareTo(Lj$/time/YearMonth;)I in class Lj$/time/YearMonth; or its super classes (declaration of 'j$.time.YearMonth' appears in /data/app/pro.leanor.app.staging-d0SAjD2iDbnaMpbwZSE4pQ==/base.apk:classes2.dex)
       at com.kizitonwose.calendarview.model.MonthConfig$Companion.generateBoundedMonths(MonthConfig.kt:49)
       at com.kizitonwose.calendarview.model.MonthConfig.<init>(MonthConfig.kt:23)
       at com.kizitonwose.calendarview.CalendarView.setup(CalendarView.kt:668)
       [...]

Gradle Version: 4.1.1
Kotlin Version: 1.4.21
Min SDK: 21 - Target SDK: 29
CoreLibraryDesugaring Version : 1.1.1

I am really not sure what causes this. Can you try using the same version of desugar in the library in your project?

Okay, this seems to work with the 1.0.10 version of desurgar.
But to achieve this, I had to remove completely desugar from my project, update my min SDK version to 26 to allow the use of the Java 8 methods, then readd a previous version of desugar and return to my previous min SDK version. Just downgrade the version of desugar do not fix the crash (even with a cleaned cash).
This is odd, but the issue is certainly on desugar newest version.
Anyway, thank you for your reply and for this great library !

Okay, this seems to work with the 1.0.10 version of desurgar.
But to achieve this, I had to remove completely desugar from my project, update my min SDK version to 26 to allow the use of the Java 8 methods, then readd a previous version of desugar and return to my previous min SDK version. Just downgrade the version of desugar do not fix the crash (even with a cleaned cash).
This is odd, but the issue is certainly on desugar newest version.
Anyway, thank you for your reply and for this great library !

I have the same issue with the 1.0.10 version of desugar :/

I have the same issue with the 1.0.10 version of desugar :/

I ran several tests to see where is the issue but I could not find any solution. This problem drives me crazy...
But I can tell you the issue is not coming from the library: I clone the repo and change the Gradle settings and dependencies version and the sample project did not crash in release build variant on any cases.
I do not know how, but I think there is an issue between my project settings and the lib' settings, because desugar methods like YearMonth.comparTo are available in my code and do not crash on Release build.
I am running out of time to investigate further, so I downgraded the lib' to the 0.3.5 version (before desugar implementation). If someone faces the same issue, I will be happy to help.
Thank you for this great lib and the support !

I ran several tests to see where is the issue but I could not find any solution. This problem drives me crazy...
But I can tell you the issue is not coming from the library: I clone the repo and change the Gradle settings and dependencies version and the sample project did not crash in release build variant on any cases.
I do not know how, but I think there is an issue between my project settings and the lib' settings, because desugar methods like YearMonth.comparTo are available in my code and do not crash on Release build.
I am running out of time to investigate further, so I downgraded the lib' to the 0.3.5 version (before desugar implementation). If someone faces the same issue, I will be happy to help.
Thank you for this great lib and the support !

This is rather unfortunate. Hopefully, someone can provide repro steps.

This is rather unfortunate. Hopefully, someone can provide repro steps.

Had almost the same issue, which was resolved when returned testCoverageEnabled to true inside release buildTypes. Somehow non-debuggable APK (i.e. testCoverageEnabled = false) didn't include all methods into the dex files.
In case of debuggable APK there was about 40-50 dex files, while non-debuggable APK was containing about 10 dex files.

Had almost the same issue, which was resolved when returned testCoverageEnabled to true inside release buildTypes. Somehow non-debuggable APK (i.e. testCoverageEnabled = false) didn't include all methods into the dex files.
In case of debuggable APK there was about 40-50 dex files, while non-debuggable APK was containing about 10 dex files.

Faced very similar issue today, found a solution for my case. I'm pretty sure it is just the same as #271 .
So I got java.lang.NoSuchMethodError and only in Release build too.
The reason was proguard obviously.
I had following code:
calendarView.monthViewClass = CalendarMonthView::class.java.name
But for release build proguard was obfuscating my class CalendarMonthView while it should be created by name inside library:
val userRoot = viewConfig.monthViewClass?.let {
            val customLayout = (Class.forName(it)
                .getDeclaredConstructor(Context::class.java)
                .newInstance(context) as ViewGroup)
            customLayout.apply {
                setupRoot(this)
                addView(rootLayout)
            }
        } ?: rootLayout.apply { setupRoot(this) }

(Code from com.kizitonwose.calendarview.ui.CalendarAdapter)
So I just added rule for proguard:
-keep class com.my.project.calendar.CalendarMonthView {
    <init>(android.content.Context);
}

And it solved the issue for me. Hope this will help someone else in future!

Closing this as it's been a while now.


Upgrade dependencies

Upgrade the following dependencies to latest version
spring boot to 1.5.14
tokens to 0.11.0

Codecov Report

Merging #40 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #40   +/-   ##
=======================================
  Coverage   74.85%   74.85%
=======================================
  Files          12       12
  Lines         346      346
  Branches       20       20
=======================================
  Hits          259      259
  Misses         72       72
  Partials       15       15

Continue to review full report at Codecov.

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

@lmontrieux Thanks for the PR. We updated some more parts in the library as well as dependencies you mentioned.

spring-boot 1.5.14.RELEASE
tokens 0.12.1

Please try out the latest release and let us know if you have any issues with it.


SFTP : two sided sftp views

Feature description

two sided sftp, so you can move things server to server or to local ...

From https://github.com/isontheline/pro.webssh.net/issues/990

Totally agree with request: I miss this feature too.


Service scope feature

Hi,
Did you think about the implementation of something like Spring bean's scope (https://www.tutorialspoint.com/spring/spring_bean_scopes.htm) for services? Like the following:
@Service
@Scope('request')
export class BlaBlaService { ...

For example: default scope is a singleton which is a single instance per IoC container. But it's also possible to choose request scope where instance exists only in the context of current HTTP request.
It would be useful to store user profile data which was obtained in the middleware for example. Of course, data from middleware can be stored within express context as a param, but it's not very comfortable to provide type safety and it isn't object oriented way :)

it's actually a really good topic to discuss. I like this idea.

Hi @RevanScript ,
Good proposal RevanScript ;). I think it's possible, but it's big improvement and I need some examples with usecase to do that.
My question, where is injected the Service  when you use the Scope("request") decorator ?
@Service
@Scope('request')
export class BlaBlaService {

}

export class BlablaCtrl {
       constructor(private blablaService: BlablaService) { // here ?
       }
       @Get('/')
       getMethod(blablaService: BlablaService) { // or here ?

       }
}

See you,
Romain

Here's an example how i'd like to use it:
/*
** Service which contains user details
** UserDetailsService instance should be created on request and destroyed after (in the last middleware)
*/

@Service
@Scope('request')
export default class UserDetailsService {
    private _profile: IProfile;

    get profile() {
        return this._profile;
    }

    set profile(profile: IProfile) {
        this._profile = profile;
    }
}

/*
** Middleware which checks auth and gets user profile
*/

@Middleware()
export default class TokenMiddleware implements IMiddleware {

    // Inject service into middleware
    constructor(public userDetailsService: UserDetailsService) {

    }

    use(@Request() request: Express.Request,
        @EndpointInfo() endpoint: Endpoint,
        @Response() response: Express.Response,
        @Next() next: Express.NextFunction) {

        ...
        this.userDetailsService.profile = user;
        ...
    }

}

/*
** Controller
*/

@Controller()
export class SomeController {

    // Inject service into controller
    constructor(public userDetailsService: UserDetailsService) {
        super();
    }

    @Get('/profile')
    @TokenRequired('profile')
    profile() {
        return this.userDetailsService.profile;
    }

}

But i see that there's a problem with injecting such services into the class constructor, because constructor is called once and doesn't create instance each request. It looks like a problem :)
Not sure, but maybe this problem can be solved with Proxy. Scoped service can't be injected on mounting, but it can be injected on fly.
Here's what i mean:

Route can use controller instance wrapped with Proxy
Proxy will handle access to injected scoped properties. If property is scoped, new instance can be created within express request context

@RevanScript thanks for your example :)
I can planed this enhancement for the v1.5 or v1.6 maybe.

@Romakita ok, it's great. will look forward to it :)

Hi @RevanScript ,
Just to say you. @Scope exists in ts-express-decorators, to change the controller behavior.
When a controller is annotated by @Scope, the controller will be instantiate for each request.
Maybe that can help you ;)

Proxy will handle access to injected scoped properties. If property is scoped, new instance of service can be created within express request context

I understand that that is possible, but it can lead to some strange behaviors. For example:
@Middleware()
export default class TokenMiddleware implements IMiddleware {
    private currentProfile: IProfile;
    // Inject service into middleware
    constructor(public userDetailsService: UserDetailsService) { }

    use(@Request() request: Express.Request,
        @EndpointInfo() endpoint: Endpoint,
        @Response() response: Express.Response,
        @Next() next: Express.NextFunction) {

        ...
        this.userDetailsService.profile = user;
        this.currentProfile = user; // seems pretty harmless but this has a totally different effect
        ...
    }
}

These kind of things are also done in the Java world (with CDI) and it can be a real head-scratcher at times.
Maybe it would be more clear if request scoped dependencies can only be used in other request scoped services/middlewares/controllers. For example:
@Middleware()
@Scope('request') // leaving out this line could give a clear error message: "Service of type `UserDetailsService` can not be injected as it is request scoped, while `TokenMiddleware` is singleton scoped"
export default class TokenMiddleware implements IMiddleware {
    // Inject service into middleware
    constructor(public userDetailsService: UserDetailsService) { }

    use(@Request() request: Express.Request,
        @EndpointInfo() endpoint: Endpoint,
        @Response() response: Express.Response,
        @Next() next: Express.NextFunction) {

        ...
        this.userDetailsService.profile = user;
        ...
    }
}

Just a suggestion, I've got no clue how difficult it would be to implement.

Hi @nicojs,
Totally agree :)

https://github.com/Romakita/ts-express-decorators/pull/181


Update powerapps-powershell.md

Added non administrator option for the installation steps.

@Pieter-Veenstra
Thanks for the suggestion! We've incorporated into the topic.


Tesseract dApps/Wallet integration native mobile libraries proposal

Project Abstract
This follow-up grant proposal aims to reduce the integration barriers of the mobile dApp/Wallet integration protocol built during the previous grant.
Tesseract dApp/Wallet integration protocol implemented in our previously finished grant provides excellent UX enhancement capabilities to the Polkadot Substrate ecosystem. Its current version allows native mobile applications to request public keys and transaction signatures through seamless integration with any Tesseract-compatible wallet installed on the same smartphone. You can see the Polkadoot dApp interacting with a wallet demo here: https://www.youtube.com/watch?v=0AlDYB3Qglc.
Though, to start providing value to the Polkadot/Substrate community, we need to lower the current technical integration barriers. Tesseract is built in Rust for its reliability, robustness, and cross-platform nature. While being a great benefit, it also imposes a technical barrier by being labor-intensive to integrate into mobile dApps and Wallets. To eliminate this, we propose to build a set of native Swift and Kotlin libraries that wrap Tesseract’s Rust implementation under the hood and provide mobile developers with a straightforward way to integrate Tesseract within minutes, thus significantly improving the UX of mobile dApps within Polkadot/Substrate ecosystem.
Application Checklist

[x] The application template has been copied and aptly renamed (dapp_wallet_integration_native_mobile_libraries.md).
[x] I have read the application guidelines.
[x] Payment details have been provided (bank details via email or BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (USDT) address in the application).
[x] The software delivered for this grant will be released under an open-source license specified in the application.
[x] The initial PR contains only one commit (squash and force-push if needed).
[x] The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
[ ] I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

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

Thanks for the application @dileping formatting looks good. A few initial questions:

For this grant I understand you will only be focusing on the prerequisite of the Swift/Kotlin Tesseract libraries. After this is complete, how do you plan to fund building the library for the Swift/Kotlin bridges for cross-platform frameworks?
A lot of software has been built since the completion of your previous grant 3 years ago. For example swift-bridge and SwiftWasm. Have you done research recently to ensure that these wrappers are still needed? Or any projects you can collaborate with?
Will the project integrate light clients at some point? For example in this forum post they debate the possibilities of being able to run Smoldot on mobile devices.

Thanks for the question, @keeganquigley. Please, see my comments below inline.

Thanks for the application @dileping formatting looks good. A few initial questions:
* For this grant I understand you will only be focusing on the prerequisite of the Swift/Kotlin Tesseract libraries. After this is complete, how do you plan to fund building the library for the Swift/Kotlin bridges for cross-platform frameworks?

I think there is some confusion. Please, let me clarify.
The proposal is to build the fully functioning Swift and Kotlin libraries wrapping all the functionality of Tesseract. Not just the prerequisites. All the developers using Swift and Kotlin for their mobile work will be able to use Tesseract just like any other library.
As for the cross-platform libraries (ReactNative, Flutter, etc.), they are notfeasible without having the Swift and Kotlin libraries built first (I think this is the source of confusion here).

* A lot of software has been built since the completion of your previous grant 3 years ago. For example [swift-bridge](https://github.com/chinedufn/swift-bridge) and [SwiftWasm](https://swiftwasm.org/). Have you done research recently to ensure that these wrappers are still needed? Or any projects you can collaborate with?

I agree; a lot of progress has been made in the Rust interop. I was monitoring it from time to time and researched this topic before preparing the proposal. Despite the progress, I still find the projects lacking a lot of what we need (i.e., asynchronous communication).
While working on the previous grant, we developed a set of libraries that makes the interop process much easier. Here you can check them out:

For Swift:

Rust side: https://github.com/tesseract-one/Tesseract.swift/tree/master/rust/tesseract_utils

Swift side: https://github.com/tesseract-one/Tesseract.swift/tree/master/Sources/TesseractUtils

For Kotlin:

Rust side: https://github.com/tesseract-one/Tesseract.android/tree/main/rust/interop

Kotlin side: https://github.com/tesseract-one/Tesseract.android/tree/main/java/interop-rust

These libraries provide us with pretty much everything we need and handle our edge cases very well. I think working around the limitations of other libraries will take more time and effort for us than doing how we have approached the interop so far.
Also, we are planning to extract them eventually and make them more friendly for other developers. So they should end up in separate repos soon.

* Will the project integrate light clients at some point? For example in this [forum post](https://forum.polkadot.network/t/developing-for-the-webkit-browser-engine/2940/8) they debate the possibilities of being able to run [Smoldot](https://github.com/paritytech/smoldot) on mobile devices.

Any client library (assuming it doesn't have private keys functionality hardcoded) can be used with Tesseract as a signature provider. Here is an example of how we did it for subxt in our Polkadot Chat dApp Demo: https://github.com/tesseract-one/polkachat.rs/blob/main/common/src/substrate/signer.rs
We thought about an idea to possibly provide ready-made Tesseract signature providers for the most popular Polkadot client libraries in the future.

Thanks @dileping for the thorough explanations. Regarding my first comment, yes I just wasn't sure if the prerequisites you mentioned were part of this grant or not. Thanks for your clarifications there.
I will mark the application as ready for review and ping the rest of the committee to take a look. I will also ping my colleague @CrackTheCode016 in case he has time and is able to give a quick review, as he is more familiar with Rust than I.

Thanks @dileping for the thorough explanations. Regarding my first comment, yes I just wasn't sure if the prerequisites you mentioned were part of this grant or not. Thanks for your clarifications there.
I will mark the application as ready for review and ping the rest of the committee to take a look. I will also ping my colleague @CrackTheCode016 in case he has time and is able to give a quick review, as he is more familiar with Rust and mobile libraries than I.

Thanks for moving the status forward, @keeganquigley! Glad my explanations were clear. Will be happy to answer more questions as they come up.

Thank you for submitting! I have left a few comments. As I understand, this proposal aims to do the following:
Provide Substrate-specific wrappers for Tesseract, which will allow for chain-specific signing capabilities to be possible. Basically, allow someone to use Substrate signing and extrinsic construction libs in native mobile environments through IPC to whatever wallet contains the private key?
Thank you again!

Hi @CrackTheCode016, thanks for reviewing the proposal!
I think you can say so - allow mobile developers to use Substrate and use the signing capabilities of whatever wallets. That's the goal; however, I want to add some details which I believe should bring more clarity.
Actually, we have already implemented the Substrate chain-specific capabilities in Rust during the previous grant. Here is what the interface for the Substrate communication protocol looks like: https://github.com/tesseract-one/Tesseract.rs/tree/master/protocols/substrate. Currently, it's the only blockchain protocol we support, though more can be added fairly easily. Regarding the Substrate integration, within this grant proposal scope, we aim to provide Swift and Kotlin APIs for the protocol we already have.
However, the proposal is not limited to only wrapping the Substrate integration. Instead, it aims to provide the whole Tesseract together with Substrate protocol for the mobile native environment in the form of native libs: Kotlin and Swift. This is necessary because Tesseract is written in Rust, and although it's possible to use Rust in native mobile apps, it's hardly an easy and enjoyable process. As an example, please, take a look at two demos we created as a part of the previous grant (both using Tesseract in its Rust form):

PolkaChat demo dApp - a simple, smart contract chat application that uses Tesseract for transaction signing.
Develper Wallet - a wallet that we provide for the dApp developers to test their dApps working with Tesseract protocol easily.

Also, I will go ahead and comment inline on your review.

@dileping Thank you for the clarification!
Based on this, this will serve as native wrappers for Tesseract as a whole, which subsequently includes Substrate.
On a personal note, I don't see many native wallets in this ecosystem, but that is primarily due to the barrier to development (everything is either in Rust or Typescript), so cross-platform apps are de facto.   As a former native app developer, there are many pros to native development from both a performance and security standpoint.
Re-light client support might become relevant to pass in other information (proof or finality justification) from wallets and/or light clients on the device (as this is the future of client-side in web3).   As an example, it is not farfetched for wallets to effectively become light clients themselves.
Would you foresee Tesseract being able to provide this sort of support to dapps directly from this sort of setup?

@CrackTheCode016, thanks for the detailed reply! Please, see my comments below.

@dileping Thank you for the clarification!
Based on this, this will serve as native wrappers for Tesseract as a whole, which subsequently includes Substrate.

Exactly!

On a personal note, I don't see many native wallets in this ecosystem, but that is primarily due to the barrier to development (everything is either in Rust or Typescript), so cross-platform apps are de facto. As a former native app developer, there are many pros to native development from both a performance and security standpoint.

I agree. There are some, but definitely not a lot. There are a couple of things I think are important as well for consideration here:

I believe that once there is more tooling available, more native dApps and Wallets get developed. As I mentioned earlier, for that reason, we also have developed and recently released Substrate.swift. This library is also W3F grant funded.
We are planning to provide cross-platform APIs wrappers as well. For mobile, it probably is going to be ReactNative and Flutter. For the dApp-side, maybe even something like Cordova support would be nice. However, to build cross-platform libs, we first need a native API anyway. Hence native API is a prerequisite to cross-platform.

Re-light client support might become relevant to pass in other information (proof or finality justification) from wallets and/or light clients on the device (as this is the future of client-side in web3). As an example, it is not farfetched for wallets to effectively become light clients themselves.
Would you foresee Tesseract being able to provide this sort of support to dapps directly from this sort of setup?

I think I started understanding what you and @keeganquigley are talking about when mentioning the light nodes. As I understand, you mean using Tesseract not only for querying pub keys and signing transactions but also to query other types of data from a local wallet/light node instead of querying a pub node, am I right? From a technical perspective - I think it's totally possible. I'd love to chat with you more about it and hear more details, like what use cases exactly you have encountered and what potential use scenarios you see. Sounds very interesting.

Hi @dsm-w3f, thanks for the review! Please, see my comments below inline.

@dileping thank you for the application. I read the comments and the application. As far as I understood, the value added here is to have a native API to connect with Tesseract both in Kotlin/Swift.

I'd add to this that the added value is to provide the Substrate community with a realistic way to start using Tesseract. With just the Rust APIs available, it's a huge barrier because of the complexity of Rust interop. The way we want to approach it - that's totally correct - the main deliverables are Swift and Java libraries for the dApp and Wallet sides, providing wallet integration through the Tesseract protocol.

This could help native mobile developers to connect to some Polkadot wallet, in case Tesseract.

Not sure I understood you correctly. Just to ensure there is no misunderstanding: we don't plan to make our own wallet for production. Just the Developer Waller, which is made only for the developers to test their dApps easier. Instead, we want to provide the community wallets and dApps with a new integration option.

However, I'm trying to understand why they would do that. There are other ways to connect with wallets using native interfaces. For example, they would wallet connect native kotlin or Swift SDK to connect to Nova Wallet or SubWallet. In this case, what would make the developer to select Tesseract instead of an approach like that?

Can't disagree. Though, we believe there is a big room for improvement in how the dApps and Wallets play together. Tesseract brings its own perspective to solving the problem, which in our opinion, provides a superior user experience plus some other benefits. Here are a couple of links to the documents we've created that analyze how exactly Tesseract's approach is different and what improvements such an approach brings to the table:

Our previous grant proposal, which we recently finished: #508
An article on medium: Why do we need better dApp/Wallet connectors, and how did we come up with the Tesseract protocol?
A demo video of how Tesseract integration looks and feels: Tesseract on iOS

Another doubt is the extent of the integration with Tesseract, what would be the functions/capabilities covered? Where you say all capabilities and features, what do you mean? I searched in the Tesseract examples and found three functions being used, I think would be more than that. Where we can figure out what exact capabilities we are talking about?

I think there is some confusion here. In the demo dApps, we didn't expose the Tesseract APIs directly to Kotlin or Swift. Instead, we opted for a "cross-platform app with a native UI." We have built the whole logic of the application in Rust and made a narrow point of contact between the thin UI layer and the Rust logic implementation. To make it clear - the example file you encountered is not a part of Tesseract's API, but rather how the UI and the Core (cross-platform part) of the example communicate with one another.
Tesseract Rust APIs are mainly located in the Tesseract.rs. There you can find the APIs in various groups. Firstly divided by the location where they are used:

Client (dApp side)
Service (Wallet side)

Secondly, divided by the API category:

main entry point
transports
connections
protocols
services
etc.

As for the examples of some use cases, I'd suggest, for starters going to the following subrepos where the Rust APIs are used directly in a dApp and a Wallet:

PolkaChat rust core
Developer wallet rust core

@dileping thank you for the answer. I understood that the Tesseract is an interconnection library between the Dapp and Wallet as WalletConnect is. Could you please give me more details on the affirmation "in our opinion, (Tesseract) provides a superior user experience plus some other benefits"? I read the application and saw that there are some characteristics that you claim that Tesseract could be better than other libs with the same purpose. Could you compare for example with WalletConnect, using native libs (see the links in my previous comment), and provide some of these characteristics that Tesseract could do that WalletConnect can't? Or in what way Tesseract is different from WalletConnect that could influence the decision of developers to use Tesseract and not WalletConnect?

@dileping thank you for the answer. I understood that the Tesseract is an interconnection library between the Dapp and Wallet as WalletConnect is. Could you please give me more details on the affirmation "in our opinion, (Tesseract) provides a superior user experience plus some other benefits"? I read the application and saw that there are some characteristics that you claim that Tesseract could be better than other libs with the same purpose. Could you compare for example with WalletConnect, using native libs (see the links in my previous comment), and provide some of these characteristics that Tesseract could do that WalletConnect can't? Or in what way Tesseract is different from WalletConnect that could influence the decision of developers to use Tesseract and not WalletConnect?

@dsm-w3f, thanks for the question! It's quite a challenge to provide you with a succinct answer here, but I'll do my best.
Tesseract does not aim to bring more features. Instead, it aims to do the dApp and Wallet interaction better. Even though from the technical perspective, Tesseract and WalletConnect are based on completely different technologies, and I'd love to start with it, let's rather jump first to some obvious consequences of the different technological choices:

The UX:

Wallet connect requires some setup (selecting a wallet that the user wants to connect to from a big list). In contrast, Tesseract relies on the underlying operating system, which provides the user with the list of installed and compatible with the dApp wallets that the user has on the smartphone. The selection UI is provided by the OS itself at the moment the dApp sends the first request. Thus the UI is truly native and cohesive with the OS.
WalletConnect switches the apps to present the Wallet, while Tesseract allows the Wallet to present the UI as a "sheet" on top of the dApp, which looks more like a proper modal UX (which it truly is under the hood). Looks especially well on iOS. Again, more cohesive with the OS.
Tesseract does not require the user to "follow the instructions" to switch back to the dApp as WalletConnect does. Instead, the Wallet view is closed automatically once the transaction is signed and the user is returned back to the dApp. Hence, Tesseract requires less education and understanding from the user and is more intuitive.
Tesseract will never take the user to a wallet that doesn't support their network or even the network version.

Connection

Tesseract doesn't need internet and can work locally

Decentralization

Tesseract doesn't need wallets to register to appear on the lists. Instead, any wallet that supports Tesseract will be available for the user once installed.
Tesseract doesn't use the internet or servers and passes data to and from the Wallet directly using local IPC, which is more secure and is truly in the decentralization spirit.

The above is not a comprehensive list of differences but rather is what the end-user may experience right away.
The differences become even more apparent once we start talking about the technological differences. The main one is the approach chosen - WalletConnect uses the internet connection as its main data transfer mechanism, plus some additional ones for connection initiation or app switching. Tesseract is built with a totally different approach - each use case is unique and requires a different connection technology. For example, a dApp and a Wallet on the same phone are best to connect locally through IPC, while a dApp on a laptop would benefit the best from a Bluetooth connection to the Wallet on the phone. WalletConnect, however, chooses to use the Internet for both scenarios.
Tesseract encapsulates all these complexities with various connection types under the hood, thus allowing the dApps and Wallets to benefit from the best available data transport while not having to implement each one separately. For now, we have managed to implement only local data transports for mobile, allowing the mobile native dApps to interact with the wallets the best way we know, but the more data transports (Bluetooth, NFC, etc.) we implement, the more radical differences we will see in these two approaches.

@dileping thank you for the answer. I understood that Tesseract work locally and don't need internet connection to interact between the wallet and Dapp, what is good, with the other functionalities presented. I think is a good feature set to have, so I'll go forward with this application.
Just to add an opinion, I still think that the argumentation to convince people to use Tesseract is weak and needs more effort to show in a clear way the advantages of using it and the risks/disadvantages of connecting wallets in other ways. This is more from a marketing perspective than a technical one. Anyway, from the technical perspective looks good to me.

@keeganquigley and @dsm-w3f, thanks a lot for approving our proposal and for going through all the info I sent!
As for the weak marketing - I agree, we need to improve it. For that, we may need some help. Maybe the substrate builders program you've mentioned before? If you have any suggestions, please, let me know.

@dileping I think SBP gives better support for creating a business than W3F grants program. I think a good time for applying to SBP is after successfully delivering a grant final milestone, but feel free to apply.

@dileping, there are no payment details in either document. Could you add those?

@semuelle, thanks for accepting our proposal!
I agree we need to involve the community - that's the goal. This particular grant is a milestone towards getting there by making Tesseract much easier usable. As for the rest - I'll send you an e-mail now.


Various fixes to adopt the out_es_ha_support branch for master

Various fixes to be able to get the out_es_ha_support branch functional vs master.
It has been test both with and without upstream servers configuration.
There is a memory leak when running without upstream servers due to the ec->index and ec->type being flb_strdup'ed. Have not yet figured out how the cleanup can be made support both configurations. I hope that you might be able to help out here.

I do believe that the PR now is fully functional and without memory leaks.
Still a bit confused about the configuration. E.g. if some configuration shall be read from the fluent bit conf file section or if all parameters need to be defined in the upstream servers configuration file. E.g. the Http_User and Http_Passwd are read from the conf file and ignored if set in the upstream servers file. Same is true for all logstash parameters.
I think this is a bit messed up for the forward output plugin as well.

I tested around a little bit with your branch, and it totally works for me :+1:
except I cant reproduce the memory leak error:
when adding flb_strdup() to the string values in your second commit, but keep the tmp = flb_upstream_node_get_property  part, everything works as excepted...
for the upstream config I used:
[INPUT]
    Name  stdin

[OUTPUT]
    Name     es
    Upstream es-balancing.conf
    Time_Key flb_time

and
[UPSTREAM]
    name       es-balancing

[NODE]
    name       es-1
    host       x.x.x.1
    port       9200

[NODE]
    name       es-2
    host       x.x.x.2
    port       9200

[NODE]
    name       es-3
    host       x.x.x.3
    port       9200

for the simple config:
[INPUT]
    Name  stdin

[OUTPUT]
    Name     es
    Host     x.x.x.1
    Port     9200
    Time_Key flb_time

my elasticsearch instances are running in 3 docker containers locally

The latest pull request from me would have addressed the memory leak issue.
So its a good sign that you don't see any.
So please merge and rebase my fixes to your pull request. There is no need
for you to mention me nor contribute anything.
I am just glad if we can get it into main tip of development.
-- Magnus
On Wed, Mar 18, 2020 at 4:18 PM claralui<EMAIL_ADDRESS>wrote:

I tested around a little bit with your branch, and it totally works for me
👍
except I cant reproduce the memory leak error:
when adding flb_strdup() to the string values in your second commit, but
keep the tmp = flb_upstream_node_get_property part, everything works as
excepted...
for the upstream config I used:
[INPUT]
Name  stdin

[OUTPUT]
Name     es

Upstream es-balancing.conf

Time_Key flb_time

and
[UPSTREAM]
name       es-balancing

[NODE]
name       es-1

host       x.x.x.1

port       9200

[NODE]
name       es-2

host       x.x.x.2

port       9200

[NODE]
name       es-3

host       x.x.x.3

port       9200

for the simple config:
[INPUT]
Name  stdin

[OUTPUT]
Name     es

Host     x.x.x.1

Port     9200

Time_Key flb_time

my elasticsearch instances are running in 3 docker containers locally
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/claralui/fluent-bit/pull/3#issuecomment-600683154,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFNDREFLODFMZYLK7TBOEC3RIDQ45ANCNFSM4LFKGM5A
.


Convert templates in packages

Fixes #214
Fixes #198
TODO

[x] Publish packages
[x] Update documentation

This PR is of your interest, @damaru-inc.

@fmvilas

We are pretty inconsistent when writing about "default"
here https://github.com/asyncapi/generator/pull/219/files#diff-04c6e90faac2675aa89e2176d2eec7d8R49 and here https://github.com/asyncapi/generator/pull/219/files#diff-2cce40143051e25f811b56c79d619bf5R68
We use forms like:

defaults
default is
By default -> this one with error as without comma at the end

Would be awesome if you could address it :D, or just fix comman in the ones that you added

What about https://github.com/asyncapi/generator/pull/219#pullrequestreview-358947608 ?

Test

Good catch. It's fixed now.
Regarding the "defaults", I unified everything except the --force-install one, which I think it makes sense to have a longer sentence.

Would be almost super cool but I have to be picky on this error message that we show when I provide a name of the template that doesn't exist:
Template "my_custom_template" does not exist.
Code behind this error message only checks if directory exists and not if it is a template. If I would have a directory with my_custom_template the installation would go forward.
2 options here:

Change the error message to just say that directory doesn't exist
At least check if package.json & tp-config.json files exist

2 is better but I can live with 1 too :)

Implemented 2. However, the .tp-config.json file is not required so I'm not going to check for it. Also, when #228 is implemented there will only be package.json files.

LGTM. Awesome stuff!!! merge and release and let us go forward with rest of improvements

Thanks for the great review mate!


Add Tailmin admin dashboard template

Name
Link

Tailmin
https://github.com/otezz/tailmin

Resource description here

[x] My item is in the right category
[x] My item is logically grouped below similar items
[x] My item's name and description respects the conventions of the list
[x] My item is awesome
[x] My item is in line with the Tailwind brand usage guidelines
[x] I have read and followed the contribution guidelines

PR updated


[Japanese] improve the Japanese messages

Improve the localized (Japanese) messages.
And I remove the gettext log messages.
(apps/jobbrowser/src/jobbrowser/views.py and apps/jobbrowser/src/jobbrowser/yarn_models.py)
I think localization isn't necessary for these messages because these messages will be logged out using LOGGER.

Thanks a lot Tatsuo!
And yes, we should not internationalize debug messages.
https://github.com/cloudera/hue/commit/b2b903c84ca72b0c63fb631d2a70ba361954193c
https://github.com/cloudera/hue/commit/973fdf7053da39c3d36750677b5b72f75c0e6888

Thank you Romain!


fix: update to lingua v1.0.2

fix: update to lingua v1.0.2

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

npm package (@latest dist-tag)
GitHub release
v15.0.2

Your semantic-release bot :package::rocket:


Can you share code for inferencing Aria on videos using a single A100 80 GB GPU ?( docs/inference.md)

https://github.com/rhymes-ai/Aria/blob/main/docs/inference.md#aria-model-inference-methods
Here, the code does not mention how to use it for videos, and only the image usage is specified. Can you share the code for testing on videos ?

Following the Commit 1f2e91a, I tried modifying the code for (inference/notebooks/04_video_understanding_vllm.ipynb)
I ran into the following error:
ValueError: Model architectures ['AriaForConditionalGeneration'] are not supported for now.

The existing 04_video_understanding_vllm .ipynb file seems to be running on the older version, so can you tell how to modify it so that I can run it using vllm?

Thank You.  I was able to resolve it .


Screenshots of apps in main README file

Description
New visitors face many difficulties in finding the apps of their interest.
To overcome this problem we can add screenshots or links or names of all apps into the README file So that he/she can redirected to the particular directory easily.
@Ovenoboyo  @Swanand-Wagh  @garvitraj  @AyushSingh22  @Atif0604  kindly assign this issue to me.
Screenshots
No response
Additional information
No response

@AyushSingh22  thanks for assigning the issue. Will start working on it


API and download/extract don't normalize versions

This happens for functools32, which has a version "3.2.3-2" which parses as "3.2.3-post2" and that's what Poetry gives for a solve.  That alternate spelling of the version also works ok in pip.  Honesty should support the same.

deps now reports the normalized version, and  download and extract accept either.
(.venv) [tim@rygel honesty]$ python -m honesty deps --python-version=2.7.6 flake8
flake8 (==3.8.1) via *
. pyflakes (==2.2.0) via <2.3.0,>=2.2.0
. pycodestyle (==2.6.0) via <2.7.0,>=2.6.0a1
. mccabe (==0.6.1) via <0.7.0,>=0.6.0
. configparser (==4.0.2) ; python_version < "3.2" via *
. functools32 (==3.2.3.post2) ; python_version < "3.2" via * no whl
. enum34 (==1.1.10) ; python_version < "3.4" via *
. typing (==<IP_ADDRESS>) ; python_version < "3.5" via *
. importlib-metadata (==1.6.0) ; python_version < "3.8" via *
. . zipp (==1.2.0) via >=0.5
. . . contextlib2 (==0.6.0.post1) ; python_version < "3.4" via *
. . pathlib2 (==2.3.5) ; python_version < "3" via *
. . . six (==1.14.0) via *
. . . scandir (==1.10.0) ; python_version < "3.5" via *
. . contextlib2 (==0.6.0.post1) (already listed) ; python_version < "3"
. . configparser (==4.0.2) (already listed) ; python_version < "3"
(.venv) [tim@rygel honesty]$ python -m honesty extract functools32==3.2.3-2
/home/tim/.cache/honesty/ext/functools32-3.2.3-2.tar.gz/functools32-3.2.3-2
(.venv) [tim@rygel honesty]$ python -m honesty extract functools32==3.2.3.post2
/home/tim/.cache/honesty/ext/functools32-3.2.3-2.tar.gz/functools32-3.2.3-2


Added inhomogeneous_poisson function and relative tests

Added function to generate no-stationary poisson spike trains

Sorry did not realize I added a file which does not belong here (test_non_stat_poiss_nonstat.py)