Scratch

nXIII wrote:

does anyone have a really fast dictionary class?

Here's my hashtable project.  Constant time lookup and insert.  But, as Jens says, not worth it unless you have 100-odd items probably.  (I haven't done timing measurements to find the exact break-even point.)

Lucario621 wrote:

that project gives me an error when I click on the stage...

Doesn't happen for me even the first time.     Was it just a red Error balloon, or a Smalltalk error?

dictionary class


what is it?

nXIII wrote:

Yes, but that depends how big the function list is! It might not be so reasonable after all! 
The problem is that I also used associative lists for variables, so they're a little slow, but that's the only dictionary that's used at runtime, the rest is compiled (YAY!).
I just need a few more than 3 or 4 functions, and maybe some special-casing with assignment/operators (I haven't made operators yet  )
Sadly, no lambdas yet, but they're on the list! Remarkably, they would be quite easy to implement, it just means a little more work by the parser.
EDIT: Actually, the work would be in the evaluator because it would just leave the compiled code as it is instead of evaluating it.

I made a little compiler thingy at one point. What I did for the variables was that while the code is compiled, it replaces every variable with a number index for a list called 'tempVars'. How would it know that it was a variable and not a number? It used a command called VAR: to access a variable.

Hopes this helps, and I can't wait to see this!

New release 3.0.4:

Jens wrote:

this release introduces the following changes, new features and bugfixes:

new features:
-------------------

1) block variables have been eliminated

The new block editor doesn't have a variables pallette pane any more. Instead of the old "make a block variable" button you should use the SCRIPT VARIABLES block mechanism instead. Block variables in existing projects are automatically migrated into script variables when BYOB reads the project file, so you should not encounter any compatibility issues, else it's a bug.

As a result I've also been able to make the block editor's default / minimum extent smaller.

Please note that you can use any number of SCRIPT VARIABLE blocks at any position within a single script. Also (accidentally) declaring a script variable more than once does no harm.

2) inline variable templates can now be deleted individually

Variable templates in lambda blocks (formal parameters) and in the SCRIPT VARIABLES block can now be deleted individually via their context menu, i.e. you can now remove var blobs "in the middle" of the list.

3) turning script variables into inputs

As an alternative way of declaring inputs you can also drag and drop script variables onto custom block prototypes (and then delete them from the SCRIPT VARIABLES block or rename them there)

bug fixes:
-------------

- variadic inputs of type unevaluated boolean now show up correctly
- variadic inputs of type predicate, reporter, command or C-Slot now save their contents correctly
- inputs slots of type unevaluated boolean no longer cause "funny" blocks to appear when their type gets changed
- embedded reporters with attached comments no longer cause program crashes when saved
- changing a new custom block's shape no longer triggers an internal error message
- some more I've forgotten right now  :-)

Thanks for all the testing and the excellent bug reports! Some RETURN block related issues remain to be fixed soon in a more experimental release.

- Enjoy!

Hmm, nXIII, good point.

    But inputs and script variables are lexically scoped and the block editor is modeless. This opens up ways around having to "scroll all the way to the top SIX TIMES and then let autoscroll take you back down very slowly", because for those kinds of variables it doesn't matter where they originate from. Instead all that counts it their name.

For example,

    (1) you can deposit any number of copies of inputs or script variables in the main window's scripting pane or in another block editor instance, before scrolling to their destination.

    (2) you can also duplicate the SCRIPT VARS block to somewhere else (the main window) and drag off variable blobs from there (and afterwards delete the SCRIPT VARS block again).

    (3) you can drag in any other same-named input from either another open block editor or from another lambda block (THE SCRIPT WITH INPUTS / THE BLOCK WITH INPUTS), script variable or even upvar of another custom block instance.

    (4) come on - autoscrolling isn't that slow    (should I make it faster?)

Jens wrote:

it doesn't matter where they originate from. Instead all that counts it their name.

If this is true then we might as well give them a Panther-style variable blob with text input.  (I guess this is an argument for scope coloring; it could be a brown blob.)

But as I said on bugzilla I think the whole scope business needs to be rethought.

Meanwhile, what I generally do is find a nearby reference and control-click-duplicate it.

Jens wrote:

(1) you can deposit any number of copies ...

(2) you can also duplicate the SCRIPT VARS block ...

(3) you can drag in any other same-named input ...

These are much too clever.  We can't rely on kids inventing such techniques.  There's something to nXIII's idea of a hovering SV block, or else maybe the Variables palette should have a variable blob with a pulldown like the one in the SET block.

Last edited by bharvey (2010-09-15 16:39:05)

bharvey wrote:

Ooh, if you turn scope coloring on, the pulled-down list of variables should have the top half against an orange background and the bottom half brown. 

even better, make the preview icons be images!

bharvey wrote:

Sample projects gratefully accepted. 

By imitating JFK " The question is to ask what Byob can't make for you,  but to ask what you can already do with Byob..."

At this time Byob is very comprehensive programming language, a genial cross-fertilization between Scratch, Lambda and First-class languages like Lisp and Logo. It has a tremendous potential of applications in a large range of domains. Byob "raises the ceiling and widen the walls" of Scratch-like applications.

Of course it lacks a lot of features used by everyone with many other languages. The list of "absent" features of Byob can be endless : Byob is not done for flle management, not for real-time applications, not for the kind of tinkery used in Windows HMI like pick-lists, buttons, choice-lists, check boxes. And so what ?

Look at the million of applications already written  with Scratch which is much less powerful, comprehensive and versatile than Byob... There is already "a lot of grain to grind"...

What if a collapsable Script Variables pane was brought back but with the add/remove buttons taken out...instead it just contained blobs for all the variables you've created with [script vars]. It sounds like interface bloat, but NXIII is right. Blobs in general are a pain to work with, and anything that makes them hard to find isn't doing anything to streamline the program. Just my two cents. 

Also, the 3.04 link that was posted apparently still links to 3.03!

fullmoon wrote:

What if a collapsable Script Variables pane was brought back but with the add/remove buttons taken out...

Yeah, that might be a good compromise.