Functional blocks#165
Conversation
There was a problem hiding this comment.
This comment suggests that given the blocks
(and A B), (not _)
if the "not" block is dragged onto the location of the "A" block, then you'd end up with:
(and (not A) B)
i.e. because the "not" operator has only one connection point that will accept the orphaned block. is that correct? FWIW this appears to be how it works with logical operators today:
There was a problem hiding this comment.
I just realized I commented on the comment that you removed. It would be helpful to explain what is being done to the orphan here besides "handling" it -- I'm curious if the old explanation is actually still accurate or not as it seems like it describes the behavior I would expect.
There was a problem hiding this comment.
It looks like this change does actually break the scenario you describe. I hadn't considered inputs that look like these. I'll look to add back that logic, and probably also expand on this comment.
2bc14d2 to
773fe0f
Compare
|
FYI, adding back the singleConnection_ logic. I think the new diff might also make it more clear that handleOprhan_ is mostly extracting some of the logic that is in connect (and then adding some handling for functional_input/output that didnt exist before). |
|
LGTM |
|
The bump behavior I'm seeing at staging.learn.code.org/2014/12 is a little wonky. Starting with (+ 0 _) |
|
That's the bug I'm fixing. My changes dont appear to be on staging yet. |
commit ac83da2 Merge: e91532b 773fe0f Author: Bjvanminnen <Bjvanminnen@gmail.com> Date: Mon Oct 13 14:47:02 2014 -0700 Merge pull request #165 from code-dot-org/functionalBlocks Functional blocks commit 773fe0f Author: Brent Van Minnen <bjvanminnen@gmail.com> Date: Mon Oct 13 14:37:03 2014 -0700 add back singleConnection_ logic commit 62fc7ff Author: Brent Van Minnen <bjvanminnen@gmail.com> Date: Fri Oct 10 15:39:49 2014 -0700 [Finishes #80230310] replacing functional blocks commit edd1d1d Author: Brent Van Minnen <bjvanminnen@gmail.com> Date: Fri Oct 10 15:30:50 2014 -0700 cleanup connection
|
Nice! However, now the "0" gets bumped to almost where it would appear as a parameter of the "-" block. Perhaps worth tweaking the bump constants to make it not land so close to the child block's inputs? |
|
Good catch. I'll look into it. On Mon, Oct 13, 2014 at 3:51 PM, davidsbailey notifications@github.com
|
Reduce the variety of sea creatures for the bias demo and reduce the …
Use main-next branch for GitHub Pages
Most of this diff is moving stuff around and/or renaming things in a way that makes them more clear to me.
The second part (commit #2) makes it so that when you try to replace the - block with the * block, it will properly move out the - block.
The reason this didn't work before is because there's some opportunity for confusion for how things are organized right now. Block connections have types (i.e. like next_statement, previous_statement, input_value, output value). These are used to ensure connections only matchup with other connections of the right type. Blocks then also have a set of connections (nextConnection, outputConnection, previousConnection) used to point at particular connections. These are also used to determine how to draw the block.
When I added the functional_input/output, I want it behaving like the existing input/output connections in some senses (i.e. inputs are drawn internal to the block, output represents the result of processing the block). However, I want it drawn more like next/previous connections. I accomplished this by having the block have a previousConnection of type FUNCTIONAL_OUTPUT, whereas before previousConnections would always be PREVIOUS_STATEMENT.
There might be opportunity to clean up some of that confusion in the future.