Scratch

Well, I can go on the forums again. Say Brian, any chance us special Snappers can play around with a prototype? 

  Everything was updated! What did you change? 

Jens wrote:

MathWizz wrote:

  Everything was updated! What did you change? 

... a lot of changes in most modules, most of which you probably (hopefully, actually) don't see, unless you're using Mac OS X Lion, in which case you should see some rendering improvements, especially with widgets (dialog boxes, buttons etc.). I've also started working on the input slot dialog (short form), but it's still under construction and not yet functional.

Suggestion: can the text box input, rather than rendering a real text box, be a label that when clicked uses a JavaScript prompt() box to take an input? It would save on rendering time a LOT.

Jens wrote:

How would it save any time, does it take long for you to enter a string? I want to design our own complex input boxes and be independent of native OS stuff that I can't totally control myself 

And your Dialog Box looks much better than the natives...
But there is a gitch when you try to close them:
It needs very much time, the same when you make a variable.

ElectricSparx wrote:

Though I have to criticize the cluttered Block Area.

Don't worry; the UI part of the development has barely begun.  It'll be a tabbed palette as before, more or less.

Hardmath123 wrote:

Yeah, it does take much longer. Why not add a "settings" panel where a user can choose the preferred system?

@Hardmath:  Aargh, we're having enough trouble meeting deadlines just implementing things once!  Plus, what you suggest would be an ongoing support nightmare.  "My project doesn't work."  "Please tell me all the settings of every option in your preferences so I can debug it for that particular combination of features."

@Jens:  But it's true that typing into input slots is slow to echo.  I have that problem also.  But then, so is just dragging a block.  My computer at work is a few years old, so maybe if I had an up-to-the-minute computer it'd be better, but I'm probably not the only one with a slow computer.  Once we get things working at all, we'll have to think about UI speedup as well as the evaluation speedup that I mostly worry about.

nXIII wrote:

We should be using native texboxes overlaid on the canvas, which would be much faster and support all input methods and ATs.

Don't forget, it's not just about filling the input slots.  You also have to drag the input slots along when dragging a block.  I can just imagine the textbox not quite keeping up with the block...

EDIT:  I  suppose it'd be possible to create the text box only when you click in the input slot.  But then as the user types into the text box, it has to grow, and the block underneath has to grow with it.  Sounds like a can of worms to me.

Last edited by bharvey (2012-01-07 14:17:20)

ElectricSparx wrote:

bharvey wrote:

ElectricSparx wrote:

Though I have to criticize the cluttered Block Area.

Don't worry; the UI part of the development has barely begun.  It'll be a tabbed palette as before, more or less.

Any way we can help?

Dunno,  We've been reluctant to throw more people at this because the time to completion of a project is generally quadratic in the number of programmers.  But let's see what our plan is after Jens and I meet this week.  (Tuesday!)

(EDIT:  Jens arrived; he's currently asleep in my guest room.  Tomorrow we start working.)

Last edited by bharvey (2012-01-10 21:58:46)

Jmpessanha wrote:

Just a question to BYOB experts: I am using recursion on a user defined BYOB block that solves cryptarithmetic  problems using a tree search approach. It seems that when a solution is not possible and we must come back more than one tree level the instance of the procedure is lost.
Do you recognize this behavior?

I aslo would like to take this opportunity to congratulate Brian and Jens for the work that is being done. I found BYOB when I was trying to find a simple language to teach my younger daughter to program. I imagined to have something like Lego representing programming blocks. Ten minutes after my first google search I was already making some fancy cartoon dancing in a stage. Fantastic!
I have to confess that I'm programming in BYOB much more than my daughter.

can u upload the block?
i cannot really do anything without it, description too unclear 

I will try to be more clear: suppose iI want to find the values of the letters that verifies the
rquation a+b+c=de. Of course each letter must correspond to a different number. This is a simple exercise with a lot of solutions but is only to illustrate the problem. The algorithm starts by trying 1 for a, then 2 for b and then 3 for c. I do this by calling the solver block several times. In the next call it is clear that e must be 6 and d zero. But d cannot be zero. So this solution is impossible. The algorithm should go back trying all the values for c and if no solution is found try a new value for b, etc. In this process of going back it seems that Byob could not remember where it was when executed the recursive block and it had fixed the value of c.defined the value for c.
I have tried similar approaches to different search problems in C, objective c, perl, visual basic, etc and normaly the call back works perfectly. I was just wondering if it is a normal behavior in BYob.

Was the timer there before? I can't seem to remember.
In any event, the refresh rate of the watcher is pretty low. Will that change?

shadow_7283 wrote:

Was the timer there before? I can't seem to remember.
In any event, the refresh rate of the watcher is pretty low. Will that change?

The timer reports the precise time whenever you ask it, but the stage watcher only updates twice a second. Wait, twice per second that's faster than my wristwatch 

I don't plan to change the refresh rate for stage watchers, because I'd rather assign more resources to evaluating the scripts.

Last edited by Jens (2012-01-15 14:22:33)