Talk:Activities/Turtle Art-0.86

discussion thread about collaboration

<walterbender> bemasc: have a minute to talk about collaboration?

<bemasc> walterbender: sure.

<bemasc> I was a bit disappointed to get exactly zero response on my e-mail.

<walterbender> bemasc: the one about terminal?

<walterbender> bemasc: sounds very cool, but I haven't had a chance to try it yet

<walterbender> bemasc: I am wondering about how to support multiple styles of collaboration within one activity

<walterbender> bemasc: maybe tomeu knows: are there plans to be able to share clipboard entries?

<walterbender> or do we save them to the Jpournal and them share them from there?

<bemasc> so we definitely have the ability to do the second thing

<walterbender> I ask because probably the most useful share in TA is to share a stack of code.

<walterbender> but to go through all those steps is tediuos.

<bemasc> I haven't heard a proposal recently to push clipboard entries around, but technically it shouldn't be hard

<bemasc> My immediate question is: where does it go, on the recipient's side?

<walterbender> my default share is "joined at the hip" sharing... which I find cumbersome

<walterbender> bemasc: on to their clipboard...

<bemasc> walterbender: that's fine, but then it should be indicated differently from a Journal->Journal transfer in the UI

<bemasc> so that the user knows what to expect when they accept the transfer

<walterbender> If clipboard sharing were easy, I could use it instead of add it to my activity explciitly

<bemasc> I'm a strong proponent of "universal collaboration" tech of this sort.

<walterbender> bemasc: +1

<bemasc> I put this in the same category with overlay chat and push-to-talk

<walterbender> bemasc: maybe if two people are collaborating, then to share a clipboard entry doesn't need confirmation, it just happens

<walterbender> bemasc: sort of what the bulletin board was supposed to be...

<bemasc> walterbender: that's a good point

<bemasc> the problem is: the clipboard is system-wide

<silbe> tomeu: might be #330 - the description is a bit too vague to be sure

<homunq> It should not go on top, in the way of your clipboard entry

<bemasc> I don't think allowing other users to push things to your clipboard arbitrarily is a wise design.

<homunq> the good thing is that the colors already make a perfect visual cue that it's not yours, but that's only if you pull up the frame for drag&drop

<homunq> bemasc: even if it went somewhere besides the top of your clipboard stack?

<bemasc> walterbender: what if we reuse the "incoming file transfer" system, but have that notification appear on the left side

<bemasc> homunq: resource exhaustion attacks galore.

<walterbender> homunq: but this is someone you are already sharing with...

<homunq> bemasc: but only from your friends with whom you're currently sharing

<homunq> heh

<walterbender> this line of thought helps, but I still have a problem in that I want to support multiple types of sharing

<bemasc> I am of the right age to remember the "punting" attacks that were common on AOL

<homunq> well, it's adding complication, but you could put some limits.

<bemasc> walterbender: I'm not sure what you mean by that. Could you elaborate?

<walterbender> I already support the kind of sharing bemasc uses in Terminal... everyone sees everything everyone else does.

<walterbender> bemasc: but I also want to support a different kid of sharing, where we each do our own thing and only share the output of our individual turtles

<silbe> sdziallas: thx! won't be able to review it today, but maybe i can get a look at it tomorrow in the bus

<sdziallas> silbe: sure ;)

<walterbender> bemasc: and the sharing blocks function is a third type, but we have a potential system-wide solution for that.

<silbe> sdziallas: (bluntly assuming you're interested in a review :) )

<bemasc> walterbender: Are the second and third not handled sufficiently by passing around Journal objects?

<walterbender> bemasc: the third, yes. But I wasn't clear about the second one.

<walterbender> I want one canvas but independent turtles

<walterbender> that is different from everyone sharing one turtle

<bemasc> walterbender: do the turtles each need to be owned by one user?

<walterbender> actually, sharing one turtle but not sharing the code is a fourth possibility...

<bemasc> maybe you could support multiple-turtle operation, independent of whether there are multiple users

<walterbender> bemasc: the idea would be for each of us to program our own solution to a problem but see the display of all of our efforts in one place

<walterbender> bemasc: then we could share the code (through the journal) if necessary

<bemasc> well, one way to do this is is to enforce "program our own solution" socially rather than technically

<walterbender> bemasc: I could/should support multiple turtles, but my problem is more general.

<walterbender> bemasc: let's take terminal for example.

<bemasc> so N users join, each creates a turtle, and each edits their own turtle's code.

<walterbender> what if I want to share only most of what I type?

<walterbender> bemasc: I can do that, but how to have some mode where we share one turtle?

<bemasc> Well, Terminal is a particularly weird example, since it's not a from-scratch creation. Its behavior is limited by the underlying technologies, which are bash, ssh, screen, xterm, etc.

<bemasc> in that case, N users join, but only one of them creates a turtle

<bemasc> and they all agree to edit that turtle's code

<walterbender> bemasc: I guess I need to think about the UI flow a bit more

<bemasc> or N users join, 3 of them make turtles, and then they divide into three teams, plus two "helpers"

<bemasc> each team works on their own turtle, but the helpers look at all the code and offer advice to all of them

<bemasc> (and maybe ensure that they stay in sync, if all 3 are supposed to be doing something choreographed)

<bemasc> The possible complexity of use cases is unlimited

<bemasc> and at some point, one inevitably decides that some complex use case is simply too much work to get right.

• homunq remembers when he was a kid, there was a great book named "turtle geometry" (actually my uncle did the typesetting) and it had multiple turtles illustrating cool interactions - they could detect each other. I never figured out how to make that happen on my apple II, though (I'm sure I could work it out now).

<walterbender> bemasc: I'll have to think about how the invitation process would work

<homunq> that book is how I learned special relativity at about age 10-15. (I never read it cover-to-cover but just browsing the illustrations and reading a bit I "got it" over those 5 years)

<walterbender> bemasc: I suppose you join to a particular turtle and see everything associated with that turtle

<cjb> homunq: gosh

<walterbender> and only the output of the other turtles...

<bemasc> walterbender: you are working awfully hard to prevent people from seeing each other's code.

<walterbender> bemasc: it is a matter of clutter...

<bemasc> walterbender: there's already a system to show/hide the code

<homunq> honestly, it is more impressive about the book than about me. I have never seen another explanation of special relativity that even came close to being that comprehensible.

<walterbender> bemasc: yes, so maybe I need to invoke it only for the turtles you aren't controlling

<bemasc> walterbender: I think it might be easier to extend that mechanism to multiple turtles

<walterbender> so many turtles, so little time :)

<bemasc> One obvious thing to do would be to spawn a new workspace for each turtle

<bemasc> so each turtle draws on a separate canvas

<walterbender> bemasc: I could just run multiple instances of TA

<bemasc> and then additionally have an "All turtles" canvas that shows them all, composited together.

<walterbender> bemasc: but I want to share the canvas

<walterbender> bemasc: that is an idea...

<bemasc> The "All turtles

<bemasc> argh

• homunq wants them in same canvas. Still remembers the illustrations of predator-prey strategies between two turtles.

<bemasc> For simplicity, maybe the "All turtles" canvas never shows any code; it's view-only.

<walterbender> "All turtles" could be a daemon user that joins all the activities

<walterbender> it'd launch separately

<bemasc> I don't think that's how I would implement it, but I don't know much about TurtleArt's internals.

<walterbender> bemasc: I am thinking it might be easy to just let the current sharing scheme do what it does and just use All Turtles to aggregate the results of the various actvities being shared

<homunq> I mean, being able to get a bearing/distance for other turtles and put them in variables would be a great block.

• homunq goes back to own bikeshed.

<bemasc> walterbender: that depends on whether the turtles can interact

<bemasc> which, I imagine, is what you want.

<bemasc> In that case, it's not merely an aggregation problem.

<walterbender> bemasc: right now they cannot, but "All Turtles" could be the medium for their interaction.

<bemasc> Yes, but communication between different shared instances is somewhere between impossible and inadvisable.

• homunq has one more comment about your bikeshed: on the apple II, the default canvas was toroidal, and I liked that better.

<walterbender> homunq: in most Logos, that is a switch

<homunq> yes

<walterbender> homunq: it would be easy enough to add to TA

<walterbender> homunq: right now, I explicitly turn it off when I export to Logo

<homunq> but kids will not find the switch until they're bigger. I think toroidal is the best default.

<walterbender> homunq: let me play with it. It was a design decision I inherited from Brian

<homunq> (though my daughter went through a phase at 3 when the invisible canvas was hilarious, now at 4 it annoys her. So it's actually a tough choice.)

<walterbender> anyway, lots to think about. thanks everyone.

<homunq> I mean, getting the turtle lost. When she went in straight lines all the time she thought it was cool.

• homunq supposes that an infinite cylinder would have the best of both worlds. You never get totally lost, but you are pushed to think of abstract space....

debugging code from roberto

[[0, u'show', 0, 309, [None, 1, None]], [1, [u'string', u'text'], 74, 319, [0, None]], [2, u'forward', 55, 526, [None, 12, 3]], [3, u'left', 55, 565, [2, 4, 5]], [4, [u'number', u'90'], 129, 574, [3, None]], [5, u'show', 55, 604, [3, 6, None]], [6, [u'string', u'text'], 129, 614, [5, None]], [7, u'start', 229, 151, [None, 8]], [8, u'forever', 241, 201, [7, 9, None]], [9, u'kbinput', 322, 215, [8, 10]], [10, u'print', 322, 269, [9, 11, None]], [11, u'keyboard', 396, 278, [10, None]], [12, [u'number', u'100'], 129, 535, [2, None]], [-1, u'turtle', 1.4210854715202004e-14, 199.99999999999997, 270.0, 0, 50, 5]]