Lifts and Separates

[richmond62]

NO: overclockmind, this is NOT about Playtex bras . . .

It is about what the people who make the Edison microBrick have decided to do:

https://meetedison.com/why-edison-robot/

I have been using this robot, on and off, over the last 10 years:
-

meet-edison-v2.png (203.14 KiB) Viewed 1767 times

-
Using both their 'bar code' system, and their programming language:

https://meetedison.com/edware-retired/

Which, as far as I was concerned, had some of the benefits of LC/OXT:

"EdWare’s graphical icons are controlled by a unique feature, the properties box. This feature allows the main programming section to contain just a simple icon structure to represent the program, while the details of each icon are controlled individually in the properties box."

Emphases are mine.

NOW . . . they have 'retired' this language (a better euphemism than some other ones) in favour of 3 new "languages":

https://meetedison.com/robot-programming-software/

1. A very baby-baby thing:
-

EdBlocksExample_Resized.jpg (16.17 KiB) Viewed 1767 times

-
"a fully icon-based robot programming language that is super easy to use"

In fact it is, obviously, ment to be used by children who cannot read (either younger than 6 or ones who're mentally subnormal) and the
block icons have icons on them indication what they are supposed to effect . . .

The ultimate dumbing down until . . .
-

pullMe.jpg (3.26 KiB) Viewed 1767 times

-
I wonder what value that has, beyod children having fun, in terms of learning computer programming.

[richmond62]

2. A SCRATCH-derived dialect:

"EdScratch is a vertical block-based visual programming language based on Scratch. EdScratch combines the ease of drag-and-drop programming with powerful functionality and versatility. The result is a robot programming language that is easy to learn and offers a robust platform for computer science education for students 10+ years old."

Emphasis is mine.

So "computer science" has degenerated to SCRATCH: we are in trouble.
-

EdScratch_example_closeup_2-1.png (6.93 KiB) Viewed 1767 times

-
And THEN a huge conceptual leap (with no hand-holding to:

3. A Python dialect:

"EdPy is a highly versatile text-based programming language based on Python. EdPy makes text-based programming fun by letting students see their code come to life in their Edison robot. With EdPy, students are learning the core of a real programming language and are able to take their exploration of robotics and coding to a more advanced level — perfect for students 13+ years old."

Emphasis is mine.
-

EdPyExample2.jpg (20.4 KiB) Viewed 1767 times

-
Maybe that's for what my Granny in one of her 'less' racist moments would have termed, "stuff for the stupid colonials in Australia."

Certainly, having had children of 9 writing in 'a programming language' in LiveCode objects (buttons, mainly), I cannot help thinking that something is a bit odd over there.

[richmond62]

What I found particularly useful about the 'retired' Edison microBrick language (EdWare) was that is bridged the gap between icon blocks and actual programming . . .

. . . one could argue that this was the BRIDGE between SCRATCH/ENTRY programming and LC/OXT.

https://playentry.org/
-
While ENTRY does offer a choice of how to see one's programming:
-

SShot 2024-01-11 at 13.29.19.png (31.6 KiB) Viewed 1763 times

-

SShot 2024-01-11 at 13.31.37.png (127.05 KiB) Viewed 1761 times

-

SShot 2024-01-11 at 13.32.03.png (108.33 KiB) Viewed 1758 times

-
Firstly: the 2 ways of doing things are NOT visible onscreen at the same time, side-by-side (design fault).

Secondly: the blocks CHANGE between the 2 ways of doing things.

About 3 years ago I requested documentation for Entry in English on their website (which, at that time was available in Korean, Chinese, and English): within about 2 weeks they responded by changing their website to Korean-only: this does not surprise me having been physically attacked by Korean males twice in Scotland and having had a tough time defending myself (at the time, luckily, I was attending both Wado Karate and North Korean Taekwondo classes). However, it does make navigating round their webpage a bit like looking for a black cat in a cola cellar.

ENTRY is, however, available with an English-language interface (as you can see from my screen shots).

https://playentry.org/download/offline

[tperry2x]

Exactly as you've said Richmond, I'd agree and say:
Computer science lessons are in trouble, in my opinion. They teach Scratch to YR7s / YR8s here (age 11/12).
They then move straight to Python for YR9s to YR11s (all the way up to age 16).
There's absolutely no transition between Scratch and Python. No middle-ground.

They are expected to jump from something that is very basic and hand-holding, straight into text-only function/variable/handlers statements, while having to consider ints and strings without so much as batting an eyelid.

Of course, this area of middle-ground *should* be exactly where OpenXTalk sits, however there are things stopping that dead in it's tracks.

Most schools I know of have their IT dictated to them by the IT department. The IT department in turn, have a list of what they can and can't install handed down from several levels above (if not Senior Leadership, then usually by the Trust / board of governors etc). If you are lucky enough to be in the envious position where you have absolute control of the IT, without any outside interference, then you are one of the lucky few it would seem.

That certainly seems to be their mode of operation around here.

Having this in mind, what's stopping these 'decision makers' (I use the term loosely of course ) from allowing OpenXTalk onto School computers as a teaching aid?

Firstly they'd look at any perceived vulnerability in the engine and underlying code. If they deemed this a sufficient risk or capable of being used to elevate permissions (a stepping-stone attack), then they would block the installation of OpenXTalk (well, actually - the possibility of installing it would never even leave the meeting table).

To be clear: I'm not talking about CVE-2020-26894 which was patched in LC 9.6.2, I'm talking about vulnerabilities with the libraries/dlls used to build the engine at compile time.

So while we can come up with as many guides, materials, (PR if you like) - until any vulnerabilities that are currently documented regarding the LCC 9.6.3 engine are sorted out, then I can't see us having much hope of being in this 'middle ground' place between Scratch and Python that we need to occupy.

(topic moved to the education section)

[OpenXTalkPaul]

So while we can come up with as many guides, materials, (PR if you like) - until any vulnerabilities that are currently documented regarding the LCC 9.6.3 engine are sorted out, then I can't see us having much hope of being in this 'middle ground' place between Scratch and Python that we need to occupy.

(topic moved to the education section)

Which do you mean? Is there a list compiled somewhere?
For the core xTalk language I can't being any more of a security risk than C++, ObjC. JAVA, Python, JS, Lua... er..
The desktop engine (and particularly because there are libraries embedded instead of being linked which get outdated) It certainly is not as safe as running an xTalk inside an inherently sandboxed web browser... more reason to pursue that.

This is also why I say 'you shouldn't use it' to people who want to use this for some mission-critical task that would be better served by the support of a commercial company (LC). it's not that I don't want to update the binaries to be more secure, but I don't want us to be in anyway liable if someones using the engine for internet credit card transactions or something like that.

I've always kind of liked the idea of Squeak/lego style 'block-programming' but it's always an ugly cryptic-looking language underneath those blocks. IIRC, Squeak was based on SmallTalk which is an 1970s old OOP and a rather...er..small language that can look a bit like Objective C. I usually find difficult look at (https://squeak.org), I don't know why anyone would think its . Going from blocks directly into Python or JS is kind of a big jump, but let's face it, learning those languages will probably be more useful to students in the long run IF they manage to make the leap, than learning xTalk would be in its current state of having hardly any user base compared to those others.

[OpenXTalkPaul]

https://en.wikipedia.org/wiki/Blockly

It sounds like 'Blockly' (used by Scratch) can actually be used to create arbitrary 'Visual Coding Language', so I wonder if we could use that to get xTalk underneath those blocks... or at least create something similar to Blocky 'natively' within OXT UI.

[tperry2x]

until any vulnerabilities that are currently documented regarding the LCC 9.6.3 engine are sorted out... [blah].

Which do you mean? Is there a list compiled somewhere?

There wasn't a link for quick reference. You'd have to go through the various CVEs. Which I've done to save anyone else the bother:
https://www.dropbox.com/scl/fo/l6oqbw7i ... iv32w&dl=0

[OpenXTalkPaul]

until any vulnerabilities that are currently documented regarding the LCC 9.6.3 engine are sorted out... [blah].

Which do you mean? Is there a list compiled somewhere?

There wasn't a link for quick reference. You'd have to go through the various CVEs. Which I've done to save anyone else the bother:
https://www.dropbox.com/scl/fo/l6oqbw7i ... iv32w&dl=0

This list seems to be vuneralbilities in older versions of Perl & Python, which AFAIK are only used in the building scripts, but they're not used by the OXT Engine(s) after the binaries are built (unless you want to use them via shell() or open process). So these aren't OXT Engine vuneralbilities really are they? Its more that there may be vuneralbilities while using this dated build process to build the binaries.

BTW, I tested OXT Lite 1.0 Mac version (uploaded sometime yesterday), Thanks for all of your work!
However.... it has some serious issues.
I'll post them in the appropriate OXT Lite 1.0 comments thread...

[tperry2x]

This list seems to be vuneralbilities in older versions of Perl & Python, which AFAIK are only used in the building scripts, but they're not used by the OXT Engine(s) after the binaries are built (unless you want to use them via shell() or open process). So these aren't OXT Engine vuneralbilities really are they? Its more that there may be vuneralbilities while using this dated build process to build the binaries.

Judging by the shell scripts and the C++ bits, these libraries are pulled in and incorporated in the build when compiling, so they are indeed part of the binaries. (this is also why the final Linux standalone size has increased from approx 19.5MB to 21.7MB ish when updating the libs and dependencies to new ones. The libs it pulls in are via the release channels from their respective repositories).

BTW, I tested OXT Lite 1.0 Mac version (uploaded sometime yesterday), Thanks for all of your work!
However.... it has some serious issues.
I'll post them in the appropriate OXT Lite 1.0 comments thread...

Okay, I believe Richmond has a list. It may be the same, it may not be.
If these could be listed in the 'bugs found' section, and even better if any fixes can be found as I'm not on Sonoma so can't replicate any of the issues. (Works fine in Catalina without any app crashes, and I've left it running all day without it once complaining)
https://www.openxtalk.org/forum/viewforum.php?f=9

I see what you mean when you mentioned once that the IDE has bits interlinked all over itself, and changing one thing likely breaks multiple other things. I think I'm at that point now where changing things is beginning to break stuff elsewhere.
All my changes have my name next to them and the date I changed anything, but I haven't changed anything too drastic at any point as far as I know. It seems solid on anything other than Mac OS - not had that crash in Windows or Linux. But I have my doubts about it patching the binary with that hex patch has led to other issues for Sonoma. (We do already know that it draws an 'exit' menuitem instead of a 'quit' menuitem - seemingly at random, so I suspect that it's not 100% stable). The Mac builds would have this issue as they are patched with that binary patch file (supplied by Tom) - I just wonder if that's part of the issue since I don't get that behavior on Windows or Linux?

[OpenXTalkPaul]

Judging by the shell scripts and the C++ bits, these libraries are pulled in and incorporated in the build when compiling, so they are indeed part of the binaries. (this is also why the final Linux standalone size has increased from approx 19.5MB to 21.7MB ish when updating the libs and dependencies to new ones. The libs it pulls in are via the release channels from their respective repositories).

Are you saying the Engine itself contains chunks of Python and/or Perl?
That seems unlikely but I guess that would be legally OK (?) depending on how permissive the licenses are.
I assume the with the updated compiled dependency libraries the binaries are larger and so they would be a bit larger as compiled code when a library's symbol's bits are merged (compiled) into the main engine binary... and that Python, gyp, perl scripts are simply directing the whole toolchain dance. IIRC, the last time I tried building on macOS it was Python or Perl script that tried (unsuccessfully) to download prebuilt binaries for the included merg* Externals (Monte's Goulding's freebie goodies) which I have now (including source code).
But that list seem to be a list of vulnerabilities in (now old) specific versions of Perl and and Python, so that's why I'm questioning that effective relevance of that list in regards to the final built engine binary.

[OpenXTalkPaul]

We do already know that it draws an 'exit' menuitem instead of a 'quit' menuitem - seemingly at random, so I suspect that it's not 100% stable). The Mac builds would have this issue as they are patched with that binary patch file (supplied by Tom) - I just wonder if that's part of the issue since I don't get that behavior on Windows or Linux?

Yeah I've often called it 'spaghetti wiring', because it's so entangled from many years of tweaking scripts.

I wasn't aware of this issue on Sonoma, there's been other issues like that in the past (well before OXT) with earlier versions of macOS, like when they first added system wide Tabbed windows APIs (Sierra), I think a lot of that is related to the menubar manipulation and removing standard menus items. Like with those native window tab related items, if I quickly switched back and forth between the Finder and the IDE I could sometimes 'catch' the menu items before the resume stack scripts could remove those items again. Of course in my opinion, it would be much better to just support the native tabbed windows, rather than hiding the 'Window' menu items for that.

[tperry2x]

As I kind of mentioned before;
https://www.openxtalk.org/forum/viewtop ... 5685#p5685
I think you can only assume compatibility with MacOS 11 Big Sur at the most.

With these unofficial hacks to the system menus on MacOS, I would not be surprised if that causes that instability - that's my theory (and only a theory at this stage). I'd rather this be fixed at the compiler level, rather than some binary patch.

I wonder if Tom (not me, the other Tom who posted the binary batch files) could supply what needs to be changed in the c++ code for these menus to work in Sonoma+ ?

I'd rather do it that way, properly and see if that's any more stable.

[richmond62]

I have been running LC 963 + Sonoma hack, and OXT Lite .99 on MacOS 14 without any obvious problems or instability at all.

I have been running the former ever since the Sonama hack became available as running the 963 Windows version on MacOS 14 via WINE was a bit like trying to watch an HD movie through the bottom of a filthy beer glass from 50 feet away.

[richmond62]

Returning to the original topic of this thread: I have taught children both programming and what is called 'computational thinking' perfectly successfully without the 'benefit' of SCRATCH and co. Probably in the way I learnt to program with MINIFORTRAN without even access to a computer.

Part of the 'problem' is NOT in computer programming, it is inside many educators' heads and their obsession that absolutely everything in education has to be fun.

Wait until those snowflakes are out in the real world having to clean babies' bottoms!

I do not believe strapping code blocks on the front of xTalk is a good idea.

What IS a good idea is a step-by-step text book.

[tperry2x]

There was something floating around like that. I've lost the link now, but there was a reference to a "Livecode for beginners - second editon" or something like that. Wish I had the link now

[richmond62]

That book has been written for adults by a non-teacher.

[tperry2x]

That book has been written for adults by a non-teacher.

Oh dear. A non-teacher. Whatever next

Oh well. Never mind - there's a potential book in the making - "OXT - An educator's guide" or "OXT - Student Guides and Lessons, Volume 1" .... or even both.