Scratch

Hi Iwan,

Thank you for your interest in my lists and files implementation! Let me try to answer your questions:

accessing specific parts of a list by their indices
You can filter out any parts of a list into another one by copying the values you're interested in from the source list into the target list, e.g.

   add (sourceList at 2) to targetList
   add (sourceList at 4) to targetList
   add (sourceList at 6) to targetList
   ...

Of course you can accomplish this also using a loop and an index variable, if it's a regular series of intervals you're after.

Another way to copy a specific range of indices in a list is to use the range block:

   add sourceList (startIndex) to (endIndex) to targetList

Afterwards you can save the target using the

   write 'filename' for targetList

command block

accessing a specific value
If you don't know the index of the value you're interested in (e.g. if you want to parse certain parts of a concatenated list) you need to find its index first. You can accomplish this using the

   first pos/las pos of (num) in myList

reporter block (you can also achieve this by iterating through the whole list and comparing the values for each index).

the file format
The file format of the external list files is currently a binary one, which can only be read by the lists application. You cannot edit it in an external editor. For performance reasons (binary is much faster than text) I decided to make it a binary format, so even very long lists (with thousands of indices) can be stored/retreived at an instant. I have, however, plans to let the user eventually export lists in an XML format (I've already created the DOM/parser for that), which could then be edited in all kinds of external apps.

I like the idea of combining lists with the sensor board, btw!

Did that answer your questions?

That's extremely interesting, Iwan, and I'd like to learn more about what exactly you're experimenting with!

As I pointed out I already have an XML DOM/Parser for Scratch ready. Which format structure should these lists have? I have been considering something like:

<list>
   <value index="1">12</value>
   <value index="18">8</value>
   <value index="207">78</value>
   <value index="1067">3</value>
   ...
</list>

That way empty slots wouldn't have to be written/read. Would this help you?

Would you need to be able to export/import such text-based lists from presentation mode (i.e. with a command block), or would you prefer manually exporting/importing them using the context-menu in the IDE?

Okay, Iwan, let's discuss this a little further, I'm sure we can extend my current List implementation very quickly to meet your needs:

I understand that you would need XML list files to always include all slots, answering zero for nil (just the way how my Lists behave in the IDE). That shouldn't be a problem.

How about my second question: Do you need/prefer a command block for export/import, or rather an entry in a (context) menu in the IDE?

My suggestion would be to add an additional entry in the drop-down menu of the current file-block named "write XML". When reading an external list file the app would determine by itself if it is in binary or text form. What do you think?

Thanks, Iwan, for your answer. Your exciting project description has me got me hooked!

I'm not sure if or when Scratch will support lists, and if/how they will be exportable to disk. Lists are probably high on the Scratch developers' "nice-to-have-agenda", and I suspended integrating my own list implementation into Chirp because I don't really want to create an incompatible Scratch variant. However, I find your ideas so inspiring that I'd like to offer my feeble support.

list data export/import to XML
I think I can help you with the list part by extending my own prototypical implementation to include XML output/input of lists. That way you will be able to process such collected list data in external applications, such as data bases or spreadsheets.
(A side note: It might also be cool to evaluate this data in another Scratch project, drawing charts using the pen command blocks. That's why I have included a stats block in my lists-version...)

Once Scratch will officially have its own list extension I could support the XMl-file interface in Chirp, so you will still be able to use your (old) collected data in the new Scratch version. If you want to reuse your Scratch projects, however, you will eventually have to rebuild them in Scratch or Chirp...

I can't give you any estimate right now, when I'll have this ready, because I'm currently on a somewhat tight schedule, but it'll probably be within the next two weeks. Is that okay with you?

collecting data from time-division-multiplexed sub-sensors
Here all I can do is offer some wild guesses, since I'm neither an engineer (I'm just an attorney) nor do I yet own a ScratchBoard:

I'd suggest maintaining a separate list for each of your 16 "real world" sensors and constructing a demultiplexing mechanism using a combination of Scratch command blocks and an initial synchronized "senseable" outside event (like a flash of light or a <button pressed>), rather than project/sensor launch. Does that make any sense at all (perhaps someone knowledgeable from the community can chime into this, please....)?

Jens,

You’ve done an outstanding job.  You’ve designed a well-crafted set of highly-sought and badly needed extensions and you’ve done it a way that, at least to my eyes, would fit seamlessly into the Scratch IDE.

Because this would be such a major enhancement for Scratch, I hope you don’t mind if I take on the role of devil's advocate.  I don’t think the question is whether these features are needed or if they would be used enough by the Scratch community to make to it worth the effort by Scratch programming team to adopt your changes.   I think the question is what impact does this have on the intended community of Scratch users.

If the intended purpose of Scratch is to reach out to young people who have never programmed before then it is possible that Scratch best serves those users by remaining a minimalist language.  Of course one could suggest that the novice programmer just ignore these new blocks but will that be possible?  Isn’t it likely that once these features are added they will permeate every part of the Scratch culture.  They will be in the projects that a novice programmer will download to try and "creatively appropriate".  They will be talked about throughout the forums and will probably be mentioned in the advice given to them.

It’s understandable that programmers soon find the Scratch programming nest to be too confining and take wing.  Where do they go?  Who knows.  Java, Flash, Python, and other languages have been suggested.

What might best serve the Scratch community would be for Chirp to become its own official offering with your proposed extensions.  Then the migration path away from Scratch would be a more obvious and gentler hop.

Cyclone103 wrote:

If we had arrays or lists of any sort, here is what I would make in the first 5 minutes of getting them: http://www.onemorelevel.com/game/cursor10

Sorry Jens for this comment out of topic, but the game Cyclone103 would like to replicate is crazy and fun! Go ahead Cyclone103!

it doesn't download for me!!!