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.

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

Implemented setcursor #46

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

mravery
Copy link
Contributor

@mravery mravery commented Aug 6, 2015

setcursor allows you set a vector from which Logo will begin outputting from while preserving previous text outputs. This implementation clones new nodes based upon #overlay and renders them within the confines of the display context (i.e. <canvas>). The behavior of cleartext has been modified to account for this new rendering behavior.

Not to sure how to write a unit test for this. Also not sure if the assumption that a passed in vector is just a two element-primitive list is the correct one.

  Not to sure how to write a unit test for this. Also not sure if the
  assumption that a passed in vector is just a two element-primitive
  list is the correct one.
@inexorabletash
Copy link
Owner

This is an interesting approach.

It looks like ucblogo at least uses setcursor to position the text cursor as if it's in a text mode terminal with [ 0 0 ] in the top left corner. So:

setcursor [ 0 0 ] show "a setcursor [ 1 0 ] show "b setcursor [ 1 1 ] show "c setcursor [ 0 1 ] show "d

... leaves the upper left of the terminal as:

ab
dc

overwriting whatever was there previously.

I'm hesitant to spawn new text overlays on every call. As it stands, I'm not sure what the benefit of this PR's setcursor is over just hiding the turtle, moving it, and using label to position text.

IMHO, the "right" approach to match UCBLogo would be to implement a virtual terminal. That's not trivial; https://github.com/inexorabletash/jsbasic/blob/master/tty.js could be of some inspiration, but it's pretty Apple II-specific. Here at least it could use a PRE element as the display rather than having to use images for the characters. The stream interface would grow a setcursor() method like in this CL and track the cursor position as each character is output. Handling character wrapping would be annoying but feasible, and I'm not sure what you'd want to do on resize.

@mravery
Copy link
Contributor Author

mravery commented Aug 8, 2015

I'm not sure if you mean "interesting" in a polite way or you really think that my approach is really interesting. 😆 I recognize that communicating via Github (like most online communication) can be difficult, especially between strangers. If you were being polite, I appreciate that but I've got pretty thick skin. Feel free to critique in a straightforward manner. 😄

Ugh. Accidentally hit 'comment'. More below.

I would characterize the solution as 'simple' and 'straightforward'. My goal was just to mimic the behavior that I saw, from a user's POV, in UCBLogo, not necessarily ape the implementation. I agree with you though that this solution lacks elegance and is not scalable (i.e. what would happen if we had hundreds of thousands of setcursor calls?) So here are a couple of questions I had about what some of your goals were with jslogo:

  • What are some of the parameters for this project in terms of expectations for its use? For example, this implementation is sufficient if a student is just going to call setcursor a couple hundred times per session. But if the vision for this project is something different than I think this solution is untenable.
  • What are some of your expectations for participation in the development process? Would you like to encourage deeper co-development with others? Are you more of a "throw me your PR and if I like I'll take it" or a "I'm happy to have anything added"? The funny part about my pull request is that I had a much more naïve implementation before this one. I did all the rendering inside of logo.js before I realized that I should probably group the functionality with the stream object that you defined in index.js. Upon further thinking I was going to go even further and make the stream a proper JS class since it began to look more and more like it ought to be, but I wasn't sure how much you cared about a large scale change like that.

• Is it better to have no implementation or a simple/straightforward implementation that works now and can easily be refactored later? In my 'real job' I'm a product manager for a software component. There are pros and cons to this, but personally and professionally speaking I have been leaving the "it needs to be right the first time" camp for the "if it works now we can iterate and develop later".

So, it's fine if you don't take this pull request 😄 I sense that you're leaning that way and I'm totally ok with it (and I SHOULD be totally ok with that).

[DANG IT. I hit 'update' too early again.]

Just to let you know, I'm going through Brian Harvey's companion book to learning Logo and I'm implementing things that aren't implemented. readline is next. If you are interested in more people (including me) contributing to jslogo what would be helpful is to have a write-up for your vision for jslogo and explaining some of the design choices and idioms you're using in your code. Some of it is obvious, some of it isn't but if someone decides that want to invest time in this, it could be incredibly frustrating for both you and the would-be contributor to haggle over what goes in and what doesn't.

@mravery
Copy link
Contributor Author

mravery commented Aug 8, 2015

Feel free to close this pull-request. I'll submit a PR from time to time. I do appreciate the feedback given.

@inexorabletash
Copy link
Owner

I'm not sure if you mean "interesting" in a polite way or you really think that my approach is really interesting.

Ha! Well, a bit of the polite version, but honestly interesting in the "I hadn't thought of it that way at all..." sort of way.

I do want to understand the use case - i.e. what can you do with this that you can't do with label?

What are some of the parameters for this project in terms of expectations for its use?

Good question. So far it's been a hobby for me and feedback from a handful of teachers and parents using it. So development priorities:

  • keep the basics simple for the end users
  • keep development easy, since it's a hobby and time commitment will be low

Together those eschew anything that adds too much complexity. One thing that I'm handling in another set of PRs is localization so non-English users can be supported more easily.

What are some of your expectations for participation in the development process? Would you like to encourage deeper co-development with others?

Absolutely! But of course since so far it's been mostly just me there isn't an active community or articulated vision - just what's in my head. At this point I'd suggest the best approach is to file a feature request issue with an offer to maybe do the work and ask for guidance or suggest an approach.

Are you more of a "throw me your PR and if I like I'll take it" or a "I'm happy to have anything added"?

As noted, I'm likely to say "no" to anything that adds unwarranted complexity since it makes future changes more difficult. But complexity can be in the eye of the beholder.

I wasn't sure how much you cared about a large scale change like that.

Best to ask first. Of course, it depends on how much you like iteration and how much time you have. It's acceptable to have a discussion by starting off with a fleshed out PR if you don't mind being told "nope, let's take a different approach". That's a fairly common in my day job, but I don't want to scare off hobbyist contributors here.

Is it better to have no implementation or a simple/straightforward implementation that works now and can easily be refactored later?

Throwing industry jargon back at you: depends on the amount of technical debt!

So, it's fine if you don't take this pull request 😄 I sense that you're leaning that way and I'm totally ok with it (and I SHOULD be totally ok with that).

Again, let's figure out if this setcursor functionality is actually beneficial and a net win over label. If so I can look at the patch in detail. Use cases and maybe some demos would help.

what would be helpful is to have a write-up for your vision for jslogo and explaining some of the design choices and idioms you're using in your code

Noted. And of course this is now ~10 year old code mostly belted out in a day or two that's been prodded at in spare moments, and I know far more about the Web platform, JS and Logo itself than I did when I started, so the code may not actually reflect my vision. I'd write a lot of it differently now, e.g. having everything being an implicit closure over the interpreter instance means breaking out the library into a separate file will be a lot of work, etc.

In lieu of that, easy guidance: if the change is a single library function that's a no-brainer. If it requires intrusive changes to other code start with an issue/discussion if it doesn't seem obvious. But I definitely welcome help in plugging the gaps!

@mravery
Copy link
Contributor Author

mravery commented Aug 9, 2015

Re: my expectations/goals

I'm hoping to use this in a Chinese teaching environment (I live in China). I like Brian Harvey's written curriculum; it is VERY dated but the beautiful thing is that all of the content is relevant even though most of the cultural references aren't. 😆

Re: use case of setcursor

I'm not going to pretend that setcursor is an invaluable part of Logo. 😄

One reason to implement setcursor is to complete jslogo as a port of UCBLogo. On the surface, I don't think this is a very compelling reason; we shouldn't just ape UCBLogo for the sake of being "complete". But I do think having the terminal features are important because they easily allow for a student to be able to do I/O with text. So I think we're faced with a couple questions here: "Does jslogo want a set of terminal like features? Why/why not?" If we do I think we can see value in separating label, which is a graphics context feature, from setcursor. Architecture wise I think it's good to separate the graphics layer from the terminal/text layer; thus the need for 'setcursor'.

In this case, I think the technical debt is very minimal. My solution is NOT complex and it would be easy to rip it out in favor of a more sophisticated (i.e. complex and complete haha) solution.

Another reason to want to port UCBLogo completely is that all the documentation and specification is there already. Someone could just pick up the UCBLogo spec (circa 1997) and not worry about figuring out how to use a workaround (e.g. "Use label instead of setcursor).

From a pedagogical position, I like NOT having to rewrite curriculum. I'm trying to see if I can just use Brian Harvey's curriculum in Chinese (translated by me); I would love to not have to rewrite his examples and exercises. Thus my own personal desire to see setcursor implemented.

Re: my own contribution

I am a poor man's computer scientist/programmer. I enjoy teaching (I teach software development at a vocational school in a rural part of China) and I do enjoy programming but I'm more gifted in management and product development. A nice way of saying this is that I'm a big idea person that can help manage people and projects with great communication skills. A crude way of describing this is that I am good at bossing people around. That said, I'd be happy to help you formulate some of your own vision for jslogo including doing an architectural writeup; perhaps it would be useful for you to see how another set of eyes understands your code. You could then edit and modify it as you see fit. I think this could really help people that are interested in contributing by giving them an idea of where the project is going.

In any case, I think the spirit of Github is that I should feel free to make my own changes in my own repo as I see fit and you would accept submitted PRs as you see fit. Ideally, though, it would be nice if both repos would benefit from mutual development; it would be a pain if the delta between two codebases became so great that it made no sense to share code. Right now, I'm in the frame of mind that I want my repo to be as close to yours as possible for this reason.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants