bthink-bgu / bpjs Goto Github PK

To express what exactly was violated.

Hi,
We faced the following problem: we didn't have context in this class, and we had to write "Context.enter()" and "Context.exit()" as it is written in SimpleEventSelectionStrategy.
Thanks!

Cleaner, more consistent interface, where all BP stuff is under bp.

• Create bp.sync
• Deprecate bsync
• Docs

BProgram.start is like Thread.run. Can BProgram be a Thread? Runnable?

E.g for when model checking a TTT program, one can add a simulated player for the model checking.

Thus it could also be immutable.

Where it is required, we can probably move to a Map<b-thread id, BSS>. The b-thread id is currently a String, which we might want to revisit too.

Another option - use Set<BThreadSyncSnapshot> instead of the map.

this is to allow

• easy to run executable jar, that users can d/l form GitHub
• a sane jar to include in builds.

General direction: Use a profile to make the FAT jar using shade plugin. Use default build for the normal .jar.

So users can validate from the command line, not just from Java programs.

In BThreadJSProxy, we can allow a shorthand where users pass just the name of the event and we generate the event for it. So the following lines of code are equivalent:

bsync({request:"A"});
bsync({request:bp.Event("A")});

Can also consider allowing a to-stringed integer. Other objects there should result in IllegalArgumentException.

Somethings along the lines of bprog.addToScope(obj,"myObj");

Maybe need to serialize and de-serialize the scopes, as we do in forks.

bp.registerBThread( function() {
foo();
});

function foo() {
bsync({...});
}

Currently leaning towards "yes", to make the addition of new types of violations easier.

Need to replace StreamLoggerListener with PrintBProgramRunnerListener

Currently throws "Exception", which is waaaaay too general. Might be better to use existing exception hierarchy, and maybe develop a sub-hierarchy for verification-related errors.

Crashes with message:

Caused by: org.mozilla.javascript.EcmaError: ReferenceError: "UseSimulatedPlayer" is not defined. (BPJSTicTacToe.js#12)
	at org.mozilla.javascript.ScriptRuntime.constructError(ScriptRuntime.java:4142)
	at org.mozilla.javascript.ScriptRuntime.constructError(ScriptRuntime.java:4120)
	at org.mozilla.javascript.ScriptRuntime.notFoundError(ScriptRuntime.java:4210)
	at org.mozilla.javascript.ScriptRuntime.nameOrFunction(ScriptRuntime.java:1952)
	at org.mozilla.javascript.ScriptRuntime.name(ScriptRuntime.java:1891)
	at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:1558)
	at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:815)
	at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:109)
	at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:399)
	at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3452)
	at org.mozilla.javascript.InterpretedFunction.exec(InterpretedFunction.java:120)
	at org.mozilla.javascript.Context.evaluateString(Context.java:1244)
	at il.ac.bgu.cs.bp.bpjs.model.BProgram.evaluate(BProgram.java:209)
	... 6 more

see discussion here:

https://groups.google.com/forum/#!topic/mozilla-rhino/_FpS27B_01k

Workaround:
store relevant fields of the objects in JS vars (e.g. get the last event's name rather than storing it as-is).

Possible solution pointer:
Implement a state serializer that uses Rhino's ScriptableObjectOutputStream. This solution was implemented by the Spring folks when faced with a similar problem:
https://sourceforge.net/p/rhinoinspring/code/HEAD/tree/trunk/rhinoInSpring/src/java/org/szegedi/spring/web/jsflow/support/FlowStateSerializer.java#l240

a. Not sure if this is needed at all. Currently its only use is setInterruptHandler, which might be replaceable using ThreadLocals at the BPEngineTasks, or even by cancelling this option, and passing the handler at the bp.sync site.
b. If we keep it, and since it has no state of its own, it should be pointless to keep it around when not running. Ideally, we'll create a proxy and a scope just before running the b-thread, and let the GC have it when the b-thread hits its next bp.sync.

Currently it's part of BProgram itself. But seems to be used only in the runner context (both theoretically and practically).

cc: @geraw

So lazy-generate the context.

Need to prevent situations where people install eclipse when they just want to try and play with BPjs.

Should terminate with an error.

For general political correctness. Seems "fat jar" is not used anymore.

Also document that this is a hard stop and people should maybe look into calling setDaemon(false) before using this.

To allow methods like .and, .or, .inverse etc.

At the moment, when a programmer is doing "weird" stuff (e.g. block an event while requesting it), BPjs prints a message to stderr. This works, but a better way would be to report a warning to a listener. This will allow IDEs or embedded runtimes (such as web servers) to report the errors to the user.

Also, need to think on maybe creating/using a logging framework for this.

As we can't use closures in BPjs, we need another mechanism to pass data from parent syntactical scopes to their descendants. An option:

var x=...
var y=...
bp.regBT( "child", function(a,b){...}, x,y)
// or
bp.regBT( "child", function(a,b){...}, [x,y] )

Where on invocation of the child, a<-x and b<-y.

Consider the following BThread:
bp.registerBThread("Test", function() {
bp.sync({ waitFor:[ bp.Event('Click', {row: 0, col: 0}) ] });
});

It is easy to request this event from JS, however it is impossible to request it from external event. The reason is that the data of the event created in JS is converted to a Rhino object.

Another related issue is that data objects in JS has a string representation, however in Java they are [object Object] - which makes it very hard to debug.

@potashkeren

@michbarsinai Editing after talking with @eggsterino:

We need a way for:

1. importing external objects as if they were created JS (e.g. parsing JSON on the Java side and then putting it into objects in JS). This should allow objects created in Java to be the same as those created in JS.
2. Reading objects created in JavaScript as Java objects.

Note that these objects are not necessarily JSON-like, so we can allow complex objects as keys, as long as they have a working equals method. Further translation to/from JSON is another story, but should be considered as part of this issue as well.

Minimal:

if ( bp.fork() ) {
   doChild();
} else {
   doParent();
}

Currently, it prints nicely(?) to the console. We might want to add a format there, so it can log into JSON or XML, for better post-execution log analysis.

At the moment, functions are stored in the continuation itself. This causes a lot of duplication, especially in template b-threads. Need to move them to a common storage, and keep only stubs at the serialized form.

At the moment, also "equals" etc. are exposed.

Equals should be done at the semantic set level, as much as possible.

e.g:

• None and empty array should be same (this could be handled during event set conversion)
• an event and an array containing only it should be the same (this could be handled during event set conversion)
• two arrays containing the same events, even in different order, should be the same.

Note the delicate interplay with hashCode on this - we might need to implement our own BProgramSyncSnapshot sets.

I use BPjs program when running an external framework (robocode). I set daemon mode to false when completing the run (battle), but I still get log prints on threads that are still running:
Waiting for robot il.ac.bgu.cs.bp.bpjsrobot.BPjsRobot* to stop thread ForkJoinPool-1-worker-1
Waiting for robot il.ac.bgu.cs.bp.bpjsrobot.BPjsRobot* to stop thread ForkJoinPool-1-worker-2
Waiting for robot il.ac.bgu.cs.bp.bpjsrobot.BPjsRobot* to stop thread ForkJoinPool-1-worker-3
Waiting for robot il.ac.bgu.cs.bp.bpjsrobot.BPjsRobot* to stop thread ForkJoinPool-1-worker-4
Waiting for robot il.ac.bgu.cs.bp.bpjsrobot.BPjsRobot* to stop thread ForkJoinPool-1-worker-5
Waiting for robot il.ac.bgu.cs.bp.bpjsrobot.BPjsRobot* to stop thread ForkJoinPool-1-worker-6
Waiting for robot il.ac.bgu.cs.bp.bpjsrobot.BPjsRobot* to stop thread ForkJoinPool-1-worker-7

Allow it to accept multiple resources (variable arity, collections). Remove the "Single" part from the name.

As pre reader comments.