create loot functions

[x] a deleteAll method to clear the list.
[x] a way to target a token (or assigned character) and add the list of items to that actor.
[ ] create Item Pile if Item Piles is active. (possibly with WG integration as well)
[ ] way to turn loot actor into an item pile.

It would be neat if the ItemPile creation call would return the created pile so it can be passed to the itempile API should further changes be wanted.

Closing this and leaving all module integrations for future PRs.


Chapter1/homework/4

This one was a little tricky and I had to redo test a couple of times before I (hopefully) got what was expected :v

// Something weird happened with commiting, it's just a copy of lesson 3 homework and missing all my edits afterward.


offcanvas menu delay on display

Off-Canvas
After opening the off-canvas menu by clicking on the menu button. De off-canvas will slided open and displayed the content. On Mozilla Firefox when you open the menu. After de menu is opened,  the content will displayed with a delay. It's also on the example page of Foundation.
http://foundation.zurb.com/docs/components/offcanvas.html

I've tested this on Firefox 35.0.1, couldn't see the problem. What version of FF are you using?
Any problem with other browsers ?

It looks like that's specific on Firefox 35.0 on Mac OS X. After upgrading to 35.0.1 it's working as normal.
Problems with:

Firefox 35.0 ( Mac OS X Yosemite )
Firefox 35.0 ( Mac OS X Mavericks, tested on BrowserStack )

No problems with:

Firefox 34 - 30 ( Mac OS X Yosemite, tested on BrowserStack )
Firefox 35 + 35.01 ( Windows 8 )
Firefox 35 - 30 ( Windows 7 & 8, tested on BrowserStack )

This might be related to this Firefox bug, which was indeed patched in version 35.0.1. If you scroll down and look at the attachments, there's a .mov file demonstrating the bug, and it's the same thing: when the animation finishes, the content briefly disappears and then snaps back into place.


Question about GRU module

Hello,
Thanks for your work on ERC. After reading the paper, I got a question about the GRU module, since all inputs to GRU is of size [batch_size,1,hid_dim], which means it did not take sequential information into the model  due to the seq_len = 1, am I right? Did you try different architectures?
Thanks for your help !

Hi, you can check line 112-119 in model.py. We use a for loop to process each utterance iteratively, in this architecture each utterance recieves the hidden states of all its predecessors, so the sequential information is considered.

Hi, thanks for response.
I notice that in your paper, the input to GRU is the aggregated message from previous utterances, so do you mean this is your consideration of sequential information, even considering input to GRU of length 1?
And how to update the first utterance's repersentation since it does not have any predecessors ?

I notice that in your paper, the input to GRU is the aggregated message from previous utterances, so do you mean this is your consideration of sequential information, even considering input to GRU of length 1?

Yes , for each layer, each utterance is updated iteratively in the same GRU unit, that works similarly to the traditional GRU recurrent networks. Except for the only difference that in our network at each time step the utterance reveive all the predecessors' hidden state, while in the traditional GPU recurrent networks only the t-1's hidden state is received.

And how to update the first utterance's repersentation since it does not have any predecessors ?

In our implementation the first utterance's predecessor is set to 0, it works just like that in RNN, the initial state h_0 is 0.


Reduce impact to upper application once SSM sever is down

TestDFSIO read 30 file, each of size 2m,  task execution time burst from 42s to 284s when SSM is down.

Done!


Dont send video optimization - proto side

The PR provides first part of implementation for #43 with an extension of .proto files to distinguish:

Media type split to Optional (video, screen share), Mandatory (Audio), Management (new type that will be used for notifications and subscription control)
Dedicated Packet for MediaManagement that allow to communicate subscription commands from user to server and notification about ongoing stream that a user can subscribe to.

Following the above PR, the next steps will cover:

[ ] Client's side "AutoSubscribe"  handling:  in order not to break functionality, Clients will auto subscribe to each new peer
[ ] Server's side subscription handling: full implementation of "on-demand" media transfer and subscription handling  and "ONGOING_STREAM" notifications
[ ] Client's side handling of "ONGOING_STREAM" notification.
[ ] Client's side "Pin Peer" capability: enabling User decision to select Peers to be followed

@mkamonMdt why is audio a 'mandatory' media type?

@mkamonMdt why is audio a 'mandatory' media type?

So the Optionality comes from the use case when a user cannot follow more video/screen-share streams than the canvas limit (which can also be specified by a user e.g. changing layout to 2x2 or 5x2 etc) or wants to "Pin" (few) selected peers, So it is End User decision.
The audio (and maybe chat in the future) is kind of different nature. Usually a user cannot make decision which peers it wants to listen to. In some cases there is a special User(s) like host that have supernatural power of giving voice (or receiving all chat messages while other users will not all - e.g. gathering content for Q&A session during a meeting). In that regard, from the perspective of regular meeting participant the audio channel feels mandatory as it's Management is determined by a remote entity.

also, would you kindly share a sequence diagram with how subscription should work?

Sure, good idea. I will prepare a diagram for it :)

The basic idea behind the Optional Media Packet is presented on the following sequence diagram. In summary:

A Producer sends a Optional media content (VIDEO or SCREEN_SHARE) that server forwards only to users that subscribed for the Producer.
Since unsubscribed users cannot know that there is ongoing Media stream, the Producer must provide lightweight notifications as long as the stream continuous.
The notification can be sent in lesser frequency than Optional Media Packets themself.

The subscription process in its first iteration will realize "AutoSubscribe" strategy (i.e. default mechanism that will be used until a User manually provides it's preferences -> clicks on "Pin to Peer" button), that is it will subscribe to any Peer whose ONGOING_STREAM notification it receives (within CANVAS_LIMIT).

Unsubscribe mechanism will start at removing a Peer from SubscribedPeerList. The communication to the Server will be triggered by reception of OptionalMedia Packet from a Peer that User is no longer subscribed to

Hey @mkamonMdt:
First of all thank you for the comprehensive explanation and the clear diagrams, it really helps to understand the feature.
I do want to keep the media signaling as simple as possible, to this effect I propose the following:

I would like to accept the addition of MEDIA_MANAGEMENT for peers to subscribe to peers media and to indicate that there's an ongoing stream, I think these are great ideas!!

Hey @mkamonMdt:
First of all thank you for the comprehensive explanation and the clear diagrams, it really helps to understand the feature.
I do want to keep the media signaling as simple as possible, to this effect I propose the following:
1. I would like to accept the addition of `MEDIA_MANAGEMENT` for peers to subscribe to peers media and to indicate that there's an ongoing stream, I think these are great ideas!!

Thanks :)

2. Regarding optional media, I do feel a bit anxious about it because they introduce a layer of complexity, but seems like we do need it.

The problem with MEDIA was that the server needs to distribute OPTIONAL packet according to "subscriptions" while letting MANDATORY packets like AUDIO or HEARTBEAT as it was. In general only thing that the server knows about the content of PacketWrapper is PacketType  and source user as the data might be encrypted (and we would like to avoid parsing 'data' anyway I guess). Similar solution would be to lift up MediaType to PakcetType level.
Other solution could involve different Actix endpoint, for Packets of different kind.

@mkamonMdt thank you again for your awesome diagrams!
I do feel strongly that the protobuf contract shouldn't change.
How can we meet halfway?


Feature: use 'cls' property to instantiate a map using a class name.

It should be better to use {el: '.className'}


'Package container-interop/container-interop is abandoned', please tag a release

Getting a message Package container-interop/container-interop is abandoned. There is a merged PR, can this be tagged as 3.0.7 to remove this warning?

3.0.7 is tagged


feat: automatically set git-cliff remote from git remote

This automatically sets git cliff's config.remote.*.owner / .repo, so that it matches the git-cliff CLI behavior and more of git-cliff's example templates work by default.

Thanks! Can you update release-plz docs here https://release-plz.ieni.dev/docs/changelog-format#context ?

I've added a little bit of documentation! Hopefully, that's sufficient 😅

That pr is now released 👍


Roughly searchable is causing my Fabric Instance to crash

https://paste.ee/p/KMxj9
Here's a copy of the error log. I've tried running it with no other mods installed and it still happens
https://paste.ee/p/lWrBr
This is a copy of the error log with just REI, Roughly Searchable, and their dependencies active.
I'm using MultiMC, in case that makes a difference.

Someone else had a similar issue, with that version of REI you need to update to RS 2.4.1

It works now, Thanks!


chore(META): make relative paths of cjs and es6 build the same

ISSUES CLOSED: #694

[ ] I added new tests for the issue I fixed/built
[x] I ran make test FOO for the package FOO I'm modifying
[x] I used make commit instead of git commit

This PR contains basicly three things:

Compile cjs to lib/cjs and not lib to keep the path for the source maps the same
Add adaptStream to global object instead of free variable (needed to avoid a breaking change when importing @cycle/run/lib/adapt
Fix import paths in the tests

@staltz Anything left to do?

@jvanbruegge I did a simple refactor of adapt.ts, just to avoid object property lookups like globalObj.Cyclejs, by making the globalObj be that globalObj.Cyclejs itself.
About the HTTP bug, I think it's just TypeScript complaining on some test files. I can put a commit for that as well, wouldn't bother that it's under this branch because it's refactor of tests.

Ok

In this case it was very useful to fix TypeScript complaints because it turned out to show me a bug with http/rxjs-typings.d.ts, see latest commit. I'll wait for Travis builds now

@staltz can you merge? We would need new version for all packages

This is marked work in progress because I want to first release a major version of cycle/dom with #709 before releasing cycle/dom major with #690. That is, let's bundle two major versions of cycle/dom together so that migration is easier. After that, we can merge this PR and release minor versions for all packages.

Oh, one thing that's missing in this PR is updating .scripts/make-api-docs.js

Waiting for Travis CI to become green.