Code Monkey home page Code Monkey logo

yaktor-issues's People

Contributors

matthewadams avatar

Watchers

avatar avatar avatar avatar avatar

Forkers

huo-ju

yaktor-issues's Issues

[CLOSED] Put DSL files in target project's root dir

Issue by matthewadams
Thursday Nov 03, 2016 at 20:54 GMT
Originally opened as https://github.com/SciSpike/yaktor-auth/issues/10

See https://github.com/SciSpike/yaktor/blob/master/bin/package.json#L60

The default gen-src npm script of https://github.com/SciSpike/yaktor doesn't look for DSL files in dsl from the target project's root.

This issue addresses the problem by putting the DSL files provided by this plugin into the target project's root dir, allowing the default gen-src npm script to find them.

[CLOSED] Modify custom function signature generation for state transitions to change argument name "data" to name of event

Issue by gacord23
Wednesday Sep 14, 2016 at 16:14 GMT
Originally opened as https://github.com/SciSpike/yaktor-dsl-xtext/issues/7

This is purely a usability issue.

Given state transition
receives custom checkIn becomes waitingForAssistance sends checkedIn
the generator creates custom function signature
function(causedByEventName,meta,data,done)

Since the term data wasn't meaningful to me, I inadvertently overwrote it in my custom routine. Had the generator used the event name checkIn instead of data, like
function(causedByEventName,meta,checkIn,done)
it may have made things more obvious.

Add subcommand to `yak` that makes it easier to get a shell in a container defined in docker-compose.yml

From @matthewadams on November 17, 2016 17:23

Currently, ./yak bash gets you a bash shell in the app container. Keep that command & deprecate it, then add command ./yak shell [container [command]] where container is optional and defaults to app. This allows a convenient shortcut to get a shell in any of the known containers defined in docker-compose.yml:, like ./yak shell mongo for a shell or ./yak shell mongo mongo for the mongo client.

Copied from original issue: SciSpike/yaktor#36

[CLOSED] naming indexes/constraints

Issue by jkamke
Wednesday Sep 14, 2016 at 19:47 GMT
Originally opened as https://github.com/SciSpike/yaktor-dsl-xtext/issues/8

Support naming indexes in order to facilitate automatic updates when indexes gain/lose fields. Without defining a name mongo automatically generates a unique name, and your database ends up with multiple indexes where only one is desired.

Depends on mongoose/mongo having the ability to properly update the definition of existing indexes.

Name indexes/constraints

From @jkamke on September 14, 2016 19:47

Support naming indexes in order to facilitate automatic updates when indexes gain/lose fields. Without defining a name mongo automatically generates a unique name, and your database ends up with multiple indexes where only one is desired.

Depends on mongoose/mongo having the ability to properly update the definition of existing indexes.

Copied from original issue: SciSpike/yaktor-dsl-xtext#8

Allow an agent's type to be an entity instead of a message

From @matthewadams on November 8, 2016 20:46

Currently, the clause agent concerns thing requires thing to be a message, which is a valid & expected use case. However, a common use case is for an agent to concern an entity. In this scenario, a message must be created that is from the entity solely for the purpose of allowing the agent to concern the message. Instead, the agent should be able to concern the entity directly, avoiding the unnecessary declaration message thing from thing.

Copied from original issue: SciSpike/yaktor#31

Expand & organize FAQs

From @matthewadams on November 15, 2016 22:29

Possible sections/categories/tags of FAQs:

  • for users of yaktor
  • for developers of yaktor
  • for system admins deploying & administering yaktor applications
  • for developers of yaktor plugins

Copied from original issue: SciSpike/yaktor-docs#3

Refactor abstract conversation ecore model

From @matthewadams on September 28, 2016 14:29

NB: This may not be exhaustive, but definitely gives you the gist.

  • Add the following new interfaces/classes:
    • Receivable extends Event with name:String, optional type:Projection attributes
    • PrivatelyReceivable extends Receivable with attribute transition:Transition
    • PubliclyReceivable extends Receivable with parent:Agent attribute
    • Sendable extends PubliclyReceivable
  • Remove the following, replacing usages with appropriate interfaces from above:
    • SubscribableByOthers (replaced with PubliclyReceivable)
    • PublishableByOthers (replaced with Sendable)
    • SubscribableByMe
    • PublishableByMe
    • PublicEvent
    • PubliclyPublishable (replaced with Sendable)
    • PubliclySubscribable (replaced with PubliclyReceivable)
    • PrivatePubSub (replaced with PrivatelyReceivable)
    • PublicPubSub
    • pubsub conversation DSL literal
  • Refactor Transition:
    • exCausedBy -> publiclyReceives:PubliclyReceivable
    • causedBy -> privatelyReceives:PrivatelyReceivable
    • triggers -> sends:Sendable
    • Remove exTriggers

Copied from original issue: SciSpike/yaktor-dsl-xtext#17

[CLOSED] Incorrect code generation of resource/find

Issue by pgraff
Thursday Jul 14, 2016 at 14:18 GMT
Originally opened as https://github.com/SciSpike/yaktor-dsl-xtext/issues/4

When generating code in the 'def' file for find, the generator inserts a constant for a variable.

E.g., say:
resource /foo over SomeType offers (... find) ...

Part of the find method is generated as:
converter.to('SomeType', domains, function(err, dtos, 0) {

The '0' is bad... It should probably have been:
converter.to('drivethrough.Chain', domains, function(err, dtos, total) {

Trademark Yaktor

From @matthewadams on June 6, 2016 14:46

We need to file a trademark for the name Yaktor. This also helps in getting the Twitter handle @yaktor (we're currently @yaktor1).

Copied from original issue: SciSpike/yaktor#7

[CLOSED] Remove support for sockjs

Issue by matthewadams
Monday Jun 06, 2016 at 14:50 GMT
Originally opened as https://github.com/SciSpike/yaktor/issues/10

We're going to use MQTT in favor of sockjs moving forward. Current MQTT code is better.

Files to touch:
/app/services/socketService.js
/index.js
/bin/static/public/socketApi.js
/test/socketApi.test.js

This will also affect repo engine-ui, specifically /template/shared/services/SocketService.js

(From https://github.com/SciSpike/cengine/issues/58)

Modify custom function signature generation for state transitions to change argument name "data" to name of event

From @gacord23 on September 14, 2016 16:14

This is purely a usability issue.

Given state transition
receives custom checkIn becomes waitingForAssistance sends checkedIn
the generator creates custom function signature
function(causedByEventName,meta,data,done)

Since the term data wasn't meaningful to me, I inadvertently overwrote it in my custom routine. Had the generator used the event name checkIn instead of data, like
function(causedByEventName,meta,checkIn,done)
it may have made things more obvious.

Copied from original issue: SciSpike/yaktor-dsl-xtext#7

[CLOSED] Depend on new mongoose-shortid

Issue by matthewadams
Monday Jun 13, 2016 at 14:06 GMT
Originally opened as https://github.com/SciSpike/yaktor/issues/13

Yaktor currently depends on https://github.com/SciSpike/mongoose-shortid, which is a forked version of https://github.com/lucasrudi/mongoose-shortid, which is a forked version of https://github.com/jjwchoy/mongoose-shortid.

If we can get jjwchoy to accept a pull request, then yaktor can depend on that version of mongoose-shortid. If not, we can rename https://github.com/SciSpike/mongoose-shortid to be something else, publish to npm, and have yaktor depend on it.

Don't make me say becomes {my current state}

From @jkamke on October 18, 2016 23:31

Consider the following:

infinite agent X:x {
  initially becomes here {
    while here {
      receives move becomes here sends moved // <1>
    }
  }
}

<1> syntax element becomes here could be inferred, and therefore should be optional

Copied from original issue: SciSpike/yaktor-dsl-xtext#24

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.