Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Dragging/Dropping of values in the function position #1

Closed
schanzer opened this issue Dec 7, 2015 · 2 comments
Closed

Dragging/Dropping of values in the function position #1

schanzer opened this issue Dec 7, 2015 · 2 comments
Assignees
@pcardune
Milestone
M1

Comments

@schanzer
Copy link
Member

schanzer commented Dec 7, 2015

In the blocks for (star 50 "solid" "red"), I should be able to:

  1. drag the 'star' value out of the block
  2. drag any other block on top of the star literal, replacing it
  3. double-clicking on it should make it editable

Use-case: the following (semantically-incorrect) code should be buildable: ((+ 1 2) 50 "red")
See "User Interactions > Dragging" and "User Interactions > Typing in a value" in the spec.
@pcardune pcardune self-assigned this Dec 9, 2015
@pcardune pcardune added this to the M1 milestone Dec 9, 2015
@pcardune pcardune assigned pcardune and unassigned pcardune Dec 9, 2015
pcardune added a commit that referenced this issue Dec 9, 2015
@pcardune
make function operators into literals
bf6c97b 
needed for #1
@pcardune
Copy link
Collaborator

pcardune commented Dec 9, 2015

(1) and (3) are now working.

Although question regarding (1). Once you drag the 'star' value out of the block, you are left with a syntactically incorrect piece of code. What should happen in this scenario?

@schanzer
Copy link
Member Author

schanzer commented Dec 9, 2015

(50 "solid" "red") is syntactically valid, and should be allowed. In WeScheme, this is a runtime error that highlights the relevant code. Depends on #11 to make this work.

You can see a demo of the desired behavior in this scenario at http://circles.wescheme.appspot.com/openEditor?definitionsText=(50%20%22solid%22%20%22red%22)

pcardune pushed a commit that referenced this issue Jun 9, 2016
Merge pull request #1 from farmanrl/farmanrl-parser
2c9d661 
tokenizer and input added
schanzer pushed a commit that referenced this issue Jul 3, 2020
attempt #1: read the errors on travis, and follow their instructions
26cbb79
schanzer pushed a commit that referenced this issue Jul 3, 2020
attempt #1: read the errors on travis, and follow their instructions (#…
2ad8002 
…298)
schanzer pushed a commit that referenced this issue Jul 3, 2020
attempt #1: switch the coverage reporter back on and see what happens
eefeeef
schanzer pushed a commit that referenced this issue Jul 3, 2020
Try to fix coveralls (#299)
30f2e27 
* attempt #1: switch the coverage reporter back on and see what happens

* remove erroneous coverage folder

* load coverage before coveralls

* attempt #2: try adding the coverage-istanbul reporter

* attempt #3: try some karma configs proposed in stack overflow

* attempt #2: resolve conflict between parallelism and coveralls

* try speeding up travis builds by caching rvm

* try caching yarn as well

* test yarn cache speed

* try removing some karma plugins

* test speed
@schanzer schanzer mentioned this issue Dec 19, 2021
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@pcardune pcardune

Labels
None yet
Projects
None yet
Milestone
M1
Development

No branches or pull requests
2 participants
@schanzer @pcardune