Closed maryfries closed 8 years ago
not sure what you mean with "up to date". That may just be the version that some IT "security" specialists believe is okay for poor students to work on. Right now the current Chrome version for general consumption (not any hackers preview thingy) is 46.0.2490.80. So, it's been a rather long time since v.29 was anywhere near "up-to-date". :-)
I noticed that, but Chrome was reporting that it was up to date and the computer was online... ??
Ugh... that's strange.
Oh, now I understand: The OS version must have been so old that Chrome stopped supporting it with newer versions. I have this on some of my really old computers (like Brian's old Mac), Chrome will tell that it's "up-to-date" because it's the last OS version it supports. Point is, though: The whole system is totally behind :-(
It was OS 10.9 though...
wait. That's not old. Strange...
Here's the note from Aankit:
This is the error JS thrown in the console Uncaught ReferenceError: Map is not defined
This is file and line number morphic.js:3055
This is line 3055 var map = new Map(), c;
Hope that's helpful!
Chrome's auto-updater is horribly broken on OS X for some install methods...
And yeah, that error would make sense for the older Chrome, though that means something else in Snap! isn't working right.
this is a somewhat serious issue. If “Map is undefined” on their computer they cannot run Snap. Basically nothing will work right. There is a work-around for Map we could add to Snap’s code, but for the next steps, especially for the Snapi-like objects I’m totally relying on Map. Map is a relatively new ES6 feature that is not yet fully supported in all browsers, especially IE. However, the little API Snap requires actually is totally supported by all current browsers as of two months ago.
Please, please have them update their browsers! They absolutely need support for the current (non-experimental, btw.) JavaScript standard!
To be clear: This is not an issue with Snap. Snap is fine, it's just that their old browser don't support JS features that have become standard in the meantime.
I didn't realize we removed the polyfill, which is why I thought something was broken.
(we could add back the polyfill...I mean, Snap! isn't broken but it is possible to prevent this from happening.)
Though not super recent, it seems like Map
things need some browser within the past year or two.
(Chrome 38-10/2014, IE 11, Safari 7.1 10/2013, FF13 7/2013), but with all of those, something more recent is better.
I do think we need some statement on the website as well as a policy as to what browsers and technology we expect people to have. For example, Snap! won't currently run on @brianharvey's Safari, though I'm guessing he never noticed. Always being up to date can be difficult in schools, and a blank screen is definitely not acceptable as a first thing a new user finds.
I wish we had data about how up to date school districts were in general...
especially for the Snapi-like objects I’m totally relying on Map
Native in Snap! ? :+1:
yes, those Map-based objects are going to be first-class and at the core of everything else in future Snap. I'm okay with (some) polyfills, but really only in cases where we're using experimental, non-standard features (such as perhaps the file API). However, Map is totally standard and supported by all browsers now, as is web-audio. For these I don't want polyfills.
Yeah, but I think the issue we run into is that schools often move dangerously slow. :( and updating isn't always even in the teacher's power.
Jens, can you suggest specific system and browser minimums that we can announce (knowing that this is a big thing to ask of teachers)? Michael is right; they may not even be able to update to our specifications. But at least if we have the information posted somewhere, they can point to that page and wave their fingers around until hopefully someone does something. (Or maybe their students can either do it or get it done!)
We could have a look at http://caniuse.com/#search=Map:
This is the absolute minimum requirement. Below this Snap fundamentals will not work correctly. If you also want web-audio (for playing notes), we can check http://caniuse.com/#search=web%20audio
but we can use:
But I can't really test these because I don't have old versions anymore, and I don't even know where to get them. However, according to the gurus, this should - kinda - work.
May be possible to solve this kind problems by making standalone Snap! version - for example based on http://electron.atom.io (the minimum OS X version supported is OS X 10.8; Windows 7 and later), it is Chromium/Chrome 45 now.
CanIUse's Map is just a measure of basic ES5 stuff (like Array.map
).
This gives a better graph for ES6, http://kangax.github.io/compat-table/es6/#Map
Also the Mozilla page for map: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map
I definitely think we should set some generic standards about how far back we should expect things to change, it would help with other projects like websites and tools we build.
May be possible to solve this kind problems by making standalone Snap! version - for example based on http://electron.atom.io (the minimum OS X version supported is OS X 10.8; Windows 7 and later), it is Chromium/Chrome 45 now.
I think @bromagosa Is infact working on this! :)
@brianharvey We should have those numbers on a website somewhere.
Working on it. Just have a few more presentations to go... Busy week!
I'm going to post these: Chrome 43 Safari 8.4 Firefox 38 Edge 12 Opera 32 cannot use IE
Anything else that should be on there?
About standalone Snap "I think @bromagosa Is infact working on this! :)"
Great!
Btw Snap4arduino https://github.com/edutec/Snap4Arduino is based on Node-WebKit (NW.js now)
May be standalone Snap can support arduino from the box. This will give possibility for physical computing field.
I think it's pretty good but we really should also have this on snap.berkeley.edu Because everyone going to Snap! should know. That's on Brian I guess.
Also is IE 11 really that bad? WebAudio I think is the only thing that's not working? I'd rather have that as a note than as "don't use this at all". (Also we might want to clearly point out that Chrome is the current recommendation. And then Safari or FF are tied for various reasons.)
The paragraph about updates is a little misleading. There are reasons where Chrome is perfectly able to run on older OSes but can't be auto updated because of computer access restrictions. :( It probably should just recommend checking chrome.google.com every few months.
I think this also means that we should try to preserve compatibility by at least 1 year back as many computers in schools only get updated once a year.
Also we probably do want to have a recommendation for mobile OSes as well.
iOS 8 and above should be totally fine with the exception that sound files uploaded can't be played in a script. (All iOS versions have this restriction.) in fact iOS 7 should be compatible too but iOS 8 will be a lot faster.
On Android I have no idea, but we should recommend using Chrome on android and not the stock browser that comes with some devices.
Michael Ball From my iPhone michaelballphoto.com
On Oct 30, 2015, at 12:54 PM, Mary notifications@github.com wrote:
Thoughts? http://bjc-edc.github.io/bjc-r/cur/teaching-guide/specifications.html
— Reply to this email directly or view it on GitHub.
Snap4Arduino is indeed based on nw.js. Actually, come to think about it, once I've updated Snap4Arduino to the latest Snap! version I could just remove the S4A part and the rest should work with minimal changes. All menus and OS interaction has already been taken care of in Snap4Aduino, so it may be easier to just take the Arduino part out than to start anew with a fresh Snap!. After all, all modifications to Snap! are performed dynamically at runtime, no Snap! source file is being changed at all.
Only trouble is with automatic updates. That should be looked into.
Good news is @elaval, early project collaborator, has just sent me the Win32 serial port plugin that I was missing to be able to update to the latest Snap! changes, so a new version should come out this week.
@bromagosa That's awesome! Is the S4A nw.js code open source?
Getting OT, but since it's on my mind: I was thinking if we had a packaged desktop app, we could build a small UI to manage extensions and then Snap! extensions that require the desktop could just be regular Node packages with a certain tag that Snap! knows about and could install on-demand.
Of course it is, Snap! and nw.js are both free software, so any derivative must be too :)
DISCLAIMER: This repo is a big ugly mess, and it weighs a million petabytes. I intend to fix it one of these days, but you know... human time is finite :(
This is exciting!! So, as we're about to merge Snapi functionality into the main Snap trunk as well, we'll be unifying most of the best branches once again!
@cycomachead How's this? http://bjc-edc.github.io/bjc-r/cur/teaching-guide/specifications.html
@maryfries Yes, I think that looks pretty good! :)
Still, going to say that @brianharvey should have something on the main snap.b.e webpage
Yep, I like it! And I also agree with Michael that it would be good to somehow make this information available on s.b.e, too. Thanks!
Thanks!
OK, will do.
Off-topic: do you have plans to migrate Snap site to github? Also for static site generation https://jekyllrb.com looks simple and good.
That one is on Brian. :smile: I'd be all for it, but Brain doesn't like git.
Info is on s.b.e
Moving to github over my dead body.
One day, you'll come around.
In NYC, students are having trouble loading Snap in Chrome. June Mark tried one of their machines, and it just comes up as a blank (white) screen. This was on OS 10.9 and Chrome 29.0.1547.76 (up to date at the time). Aankit found a clue in the JS that he will send to us.