Re: Notes from OpenEd 2015 Vancouver

[Ayotte, Dana]

correction: conference was tweeted at #opened15

On Nov 25, 2015, at 8:00 AM, Cheetham, Anastasia 
> wrote:




The conference was tweeted at #OpenEd2015.

A few fun twitter photos:
https://twitter.com/karlnelson/status/667770891296616448
https://twitter.com/waharnum/status/667016998518288386
https://twitter.com/waharnum/status/666800462230777857


--
Anastasia Cheetham – acheet...@ocadu.ca
Inclusive Design Research Centre
Inclusive Design Institute
OCAD University

___
fluid-work mailing list - 
fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Uglify modifies code in minified builds

[Michelle D'Souza]

Thanks for looking into this Justin. 

I think we should disable the compression options. Leaving the compression 
options on means that the minified code base is considerably different from the 
unminified code base. I don’t think the small change in file size is worth the 
increased complexity in code maintenance going forward.

Michelle


> On Nov 25, 2015, at 11:16 AM, Justin Obara  wrote:
> 
> 
> 
> I was code reviewing FLUID-5759 
>  this morning and was 
> looking into the change that was made. I was trying to step through the 
> debugger to compare the change against what had previously been in the 
> codebase. I went to the build site  to step 
> through the tests. First off the code for Infusion is all minified; however, 
> Safari does a decent job of separating the code to make it readable. 
> Unfortunately I still could not find the part of the code I was looking for. 
> 
> After more digging I found the line I wanted but noticed that the code was 
> actually different. I checked through the repository and confirmed that it 
> was not an issue with the code being out of sync. After running some local 
> builds it seems that the reason is the compression being done by Uglify 
> . It seems that be default 
> most of the compression options 
>  are enabled.
> 
> Example of the change:
> 
> In source:
> if (!fluid.isPrimitive(thisCompositeOptions.panels)) {
> fluid.each(thisCompositeOptions.panels, function 
> (subpanelArray, pref) {
> subPanelList = subPanelList.concat(subpanelArray);
> if (pref !== "always") {
> fluid.each(subpanelArray, function (onePanel) {
> fluid.set(subPanelRenderOn, onePanel, pref);
> });
> }
> });
> } else {
> subPanelList = thisCompositeOptions.panels;
> }
> 
> In minified:
> fluid.isPrimitive(thisCompositeOptions.panels)?subPanelList=thisCompositeOptions.panels:fluid.each(thisCompositeOptions.panels,function(subpanelArray,pref){subPanelList=subPanelList.concat(subpanelArray),"always"!==pref&(subpanelArray,function(onePanel){fluid.set(subPanelRenderOn,onePanel,pref)})})
> 
> So far it doesn’t seem to have caused any issues, and they do disable 
> “unsafe” compression options by default. In theory it should be safe to leave 
> these on. However, it will mean we have a difference in code between the 
> minified and source versions. Which, in the least, will make tracking down 
> code between the two more difficult. 
> 
> What are you thoughts, should we keep the full compression or use smaller 
> subset?
> 
> infusion-all.js with full default compression options is 831KB
> 
> infusion-all.js with the following options disabled, is 844KB
> 
> compress: {
> sequences: false,
> dead_code: false,
> conditionals: false,
> booleans: false,
> unused: false,
> if_return: false,
> join_vars: false,
> drop_console: false
> }
> 
> Thanks
> Justin
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca 
> 
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work 
> 
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Uglify modifies code in minified builds

[Colin Clark]

Hi all,

Infusion's build system has always been somewhat idiosyncratic (also ahead of 
its time, offering developers the ability to freely compose any Infusion module 
they want into a build), particularly in the way it packages and produces build 
artifacts in an either/or fashion. I think it needs to be updated.

We should define a set of "base profiles" of Infusion (such as a "framework 
only" build) and publish them as part of our npm module (using the "prepublish" 
script hook). Bower is now essentially a dead project and npm has emerged as a 
viable way of managing client-side dependencies. Both minified and non-minified 
versions of these builds should be created every time we publish our module.

I don't agree with Michelle that we should disable Uglify's more aggressive 
compression options unless they produce erroneous code. Obviously, we shouldn't 
be using Uglify's "unsafe" options, but other optimizations are worth 
maintaining. While it's undoubtedly a subject of significant debate, I for one 
still think that minimizing script size is a worthwhile endeavour. If it's easy 
to do and doesn't affect  source code (as opposed to built file) readability, 
every kilobyte saved is worthwhile.

Minified code is for production, not for debugging during development. If we 
need to pursue a means for more easily toggling between builds, such as a daily 
build Node.js app that can serve up either version of our static resources, 
perhaps it is worth doing so. Or perhaps simply not linking against minified 
builds on the daily build server, but only on production sites.

Colin


> On Nov 25, 2015, at 12:11 PM, Justin Obara  wrote:
> 
> Currently the build process is either minified or source, and it looks like 
> the minified version is the one being used for the build site. It could be an 
> option to change the build process to produce both a minified and source 
> version, and to host both of these on the daily build site.
> 
> On November 25, 2015 at 11:33:09 AM, Tirloni, Giovanni (gtirl...@ocadu.ca 
> ) wrote:
> 
>> Changing those options seem to be trying to make the uglified code  
>> closer to the original version for understandability purposes. 
>> 
>> I wonder if it's not better to always use the non-uglified code when  
>> debugging and only switch focus to the uglified version if the issue  
>> can't be reproduced with the original code (which would point to a issue  
>> with the uglifier). Are we producing non-uglified code during the build  
>> process? 
>> 
>> Regarding file size, the difference is so small I'm sure it'll be made  
>> irrelevant by server-side compression before it arrives at the client. A  
>> worse problem is websites that load Infusion multiple times, but I guess  
>> that is not in scope here. 
>> 
>> On 11/25/2015 02:16 PM, Justin Obara wrote: 
>> > 
>> > 
>> > I was code reviewing FLUID-5759 
>> > > > > this morning and 
>> > was looking into the change that was made. I was trying to step through 
>> > the debugger to compare the change against what had previously been in 
>> > the codebase. I went to the build site 
>> > > to step 
>> > through the tests. First off the 
>> > code for Infusion is all minified; however, Safari does a decent job of 
>> > separating the code to make it readable. Unfortunately I still could not 
>> > find the part of the code I was looking for. 
>> > 
>> > After more digging I found the line I wanted but noticed that the code 
>> > was actually different. I checked through the repository and confirmed 
>> > that it was not an issue with the code being out of sync. After running 
>> > some local builds it seems that the reason is the compression being done 
>> > by Uglify > > >. It seems 
>> > that be default most of the compression options 
>> > > > > are enabled. 
>> > 
>> > Example of the change: 
>> > 
>> > In source: 
>> > if (!fluid.isPrimitive(thisCompositeOptions.panels)) { 
>> > fluid.each(thisCompositeOptions.panels, function 
>> > (subpanelArray, pref) { 
>> > subPanelList = subPanelList.concat(subpanelArray); 
>> > if (pref !== "always") { 
>> > fluid.each(subpanelArray, function (onePanel) { 
>> > fluid.set(subPanelRenderOn, onePanel, pref); 
>> > }); 
>> > } 
>> > }); 
>> > } else { 
>> > subPanelList = thisCompositeOptions.panels; 
>> > } 
>> > 
>> > In minified: 
>> > 
>> > 

RE: This week's community meeting

[Bates, Simon]

At standup this morning, Dana was asking if there would be good places to read 
more about the Smalltalk programming language.

Dan Ingalls' article "Design Principles Behind Smalltalk" is a very nice 
overview of some of the forces and motivations in the design of the language:

http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html

In terms of introductions to the actual language itself, it's a little harder 
to find satisfying online material. The best resource, I think, is the book 
"Smalltalk-80: The Language And Its Implementation". A scanned PDF is available 
online and the first few chapters introduce the language:

http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf

There is a quite nice "Terse Guide to Squeak" (the Smalltalk version I will 
demo today) but it's not an intro or tutorial:

http://squeak.org/documentation/terse_guide/

If I find other good resources, I'll definitely pass them along. (For those at 
IDRC in person, I brought in my copy of the Smalltalk-80 book, if you're 
interested in taking a look.)

Simon

From: fluid-work [fluid-work-boun...@lists.idrc.ocad.ca] on behalf of Bates, 
Simon [sba...@ocadu.ca]
Sent: Monday, November 23, 2015 8:47 AM
To: Fluid Work ‎[fluid-w...@fluidproject.org]‎
Subject: This week's community meeting

Hi everyone,

For this week's community meeting, we are going to continue with our series on 
Case Studies of User Creativity. On Wednesday we will have a look at Smalltalk 
and other work of Alan Kay and his collaborators.

I'd like to suggest that in advance of Wednesday's meeting, we read one of his 
papers from 1977, written with Adele Goldberg, called "Personal Dynamic Media". 
This paper presents their vision for personal computing and for portable 
computers called "Dynabooks".

I've found 2 versions of the article online: a version with an introduction 
that appeared in a 2003 collection called "The New Media Reader" and a scan of 
the original:

- http://www.newmediareader.com/book_samples/nmr-26-kay.pdf
- https://www.computer.org/csdl/mags/co/1977/03/01646405.pdf

(The whole New Media Reader book is really good and I'll bring it in on 
Wednesday, if anyone is interested in taking a look at it.)

At the meeting I will show a running Smalltalk system and I think it would also 
be awesome to discuss the Personal Dynamic Media paper together.

Looking forward to the conversations on Wednesday.

Simon
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Uglify modifies code in minified builds

[Antranig Basman]

This remark:

> "Minified builds aren't intended for development. They're designed
> for production, and we shouldn't be either surprised or terribly
> concerned by the idea that somehow magically the code changed in
> layout or structure as a result of minification. That's what it's for!"

i) reacts to a partial reading of my posting - the first paragraph of 
which contains (part of) exactly the same point you are making here - 
that we should not be surprised that the layout of code has changed due 
to minification
ii) cuts against one of our core principles - that we should treat 
different parts of our authorial lifecycle - development, maintenance, 
production, or any other deployment context - as part of the same 
process. We should expect to be able to debug or work with any kind of 
deployment of Infusion on equal terms. Infusion is about equality of 
authorial access.


If we can't effectively debug something in a production context, we 
shouldn't deploy it that way.


The suggestion that we cease to offer builds is interesting - but I'm 
not sure that it addresses the core issue. By leaving users on their 
own, as well as doing them an unnecessary disservice, we also increase 
the risk of incurring support problems that we're not equipped to handle.



Cheers,

A

On 25/11/2015 18:55, Colin Clark wrote:

Hi Antranig,


On Nov 25, 2015, at 1:48 PM, Antranig Basman  
wrote:

If we don't have time for this, the 13K savings through disabling the extra 
optimisations seem neither here nor there - and having code without any 
whitespace appear in the debugger seems equivalently obstructive to having the 
optimised version you showed - even if Safari can deal with this, the other 
browsers can't. I would say that until we're prepared to deploy SOURCE MAPS, we 
should go with simple concatenation in our builds.


I disagree quite significantly, but I find the discussion very interesting.

Minified builds aren't intended for development. They're designed for 
production, and we shouldn't be either surprised or terribly concerned by the 
idea that somehow magically the code changed in layout or structure as a result 
of minification. That's what it's for!

Shipping Infusion out of the box in a way that doesn't support production 
deployers is a poor idea, and the toolchain you propose as an alternative is 
entirely worthwhile but will take some time to get our heads around and use 
appropriately. We're already behind the times in this regard and there's a lot 
of catching up and learning to do. In the meantime, let's just stop expecting 
to be able debug viably within a minified build.

Alternatively, I propose that we simply stop offering builds of Infusion at 
all, and be explicit about the fact that our users are entirely on their own in 
this regard. That doesn't sound like an appealing option to me, but hopefully 
you see my point.

Colin



___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Uglify modifies code in minified builds

[Antranig Basman]

Thanks for the response, Colin - sorry for misreading your previous 
message. The difference in size between the minified and concatted 
builds is very significant and I agree that we shouldn't go forward 
without our existing minified build as part of our set of standard builds.


This, to me, represents a substantial support risk, and I'd like to see 
us try to bridge the gap between your points 2. and 3. with some kind of 
cheaper, transitional strategy. This might be as simple as just tweaking 
our uglify options to include "sourceMap: true" -


https://github.com/gruntjs/grunt-contrib-uglify#sourcemap

Even if we don't have any formal process for distributing the map, we 
would at least know that it had once existed and could be regenerated, 
and that, presumably, the special comment indicating that a source map 
exists will be added end of the built file:


http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/

That is - should we unexpectedly find ourselves in the position of 
having to debug a production usage of Infusion, all we might need to do 
is drop an extra file (the map) into the production server. The mere 
presence of the maps might also promote some opportunistic exploration 
of using them in the intervening time.


Cheers,
Antranig

On 25/11/2015 20:34, Colin Clark wrote:

Antranig,


On Nov 25, 2015, at 2:24 PM, Antranig Basman  
wrote:


"Minified builds aren't intended for development. They're designed
for production, and we shouldn't be either surprised or terribly
concerned by the idea that somehow magically the code changed in
layout or structure as a result of minification. That's what it's for!"


i) reacts to a partial reading of my posting - the first paragraph of which 
contains (part of) exactly the same point you are making here - that we should 
not be surprised that the layout of code has changed due to minification


I did indeed read that part of your post, and was intending to reinforce it 
with my agreement. I apologize if that agreement wasn't clear; I don't think 
our positions are terribly far apart.


ii) cuts against one of our core principles - that we should treat different 
parts of our authorial lifecycle - development, maintenance, production, or any 
other deployment context - as part of the same process. We should expect to be 
able to debug or work with any kind of deployment of Infusion on equal terms. 
Infusion is about equality of authorial access.


I understand this principle and agree with it. My concern is largely specific: 
dispensing with minification for Infusion right now will put a particular 
category of users in an awkward position. We have users of UI Options, for 
example, who expect to be able to take a bundle of JavaScript and a small 
number of HTML templates and embed them directly in their websites. No build 
process, no in-depth knowledge of JavaScript production packaging techniques, 
and not even an understanding of what all the pieces and parts are that compose 
UI Options.

The unminified UI Options build is over 50% larger than the minified version. 
So we're not talking about 13K here or there, but quite a lot more. I think 
it's important to give users a minimal, out-of-the-box distribution of UI 
Options that they don't have to process or manipulate in any way. We're not 
quite there (in that users still have to follow a tutorial on how to make a 
custom build), but we shouldn't go backwards in this regard. I worry that if we 
dispense with minification entirely, it will be a step back. Perhaps I was 
misunderstanding your argument.

What I'm suggesting, and I apologize if it wasn't clear in my earlier 
responses, is this:

1. We don't try to debug minified builds. If we expect to use our daily build 
server as a place to do debugging and troubleshooting (and I think we should), 
it should always employ unminified builds.

2. We retain uglification with its default options, making it available for users (such 
as "plug and play" UI Options users) on their production sites (by creating a 
--source false build).

3. When we find the cycles, to a) add source maps support for our minified builds, and b) 
update our build system to produce both minified and unminified versions of 
"standard profiles" of Infusion such as framework-only, UIO-only, etc. and 
publish them via an npm prepublish script.

In the longer term, after #3, we should consider a much more in-depth process that will 
enable applications to be seamlessly moved from more to less "compiled" form 
and back again for authorial and debugging purposes throughout the application lifecycle.

What are your thoughts on this?

Colin



___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Uglify modifies code in minified builds

[Colin Clark]

Antranig,

> On Nov 25, 2015, at 2:24 PM, Antranig Basman  
> wrote:
> 
> > "Minified builds aren't intended for development. They're designed
> > for production, and we shouldn't be either surprised or terribly
> > concerned by the idea that somehow magically the code changed in
> > layout or structure as a result of minification. That's what it's for!"
> 
> i) reacts to a partial reading of my posting - the first paragraph of which 
> contains (part of) exactly the same point you are making here - that we 
> should not be surprised that the layout of code has changed due to 
> minification

I did indeed read that part of your post, and was intending to reinforce it 
with my agreement. I apologize if that agreement wasn't clear; I don't think 
our positions are terribly far apart.

> ii) cuts against one of our core principles - that we should treat different 
> parts of our authorial lifecycle - development, maintenance, production, or 
> any other deployment context - as part of the same process. We should expect 
> to be able to debug or work with any kind of deployment of Infusion on equal 
> terms. Infusion is about equality of authorial access.

I understand this principle and agree with it. My concern is largely specific: 
dispensing with minification for Infusion right now will put a particular 
category of users in an awkward position. We have users of UI Options, for 
example, who expect to be able to take a bundle of JavaScript and a small 
number of HTML templates and embed them directly in their websites. No build 
process, no in-depth knowledge of JavaScript production packaging techniques, 
and not even an understanding of what all the pieces and parts are that compose 
UI Options.

The unminified UI Options build is over 50% larger than the minified version. 
So we're not talking about 13K here or there, but quite a lot more. I think 
it's important to give users a minimal, out-of-the-box distribution of UI 
Options that they don't have to process or manipulate in any way. We're not 
quite there (in that users still have to follow a tutorial on how to make a 
custom build), but we shouldn't go backwards in this regard. I worry that if we 
dispense with minification entirely, it will be a step back. Perhaps I was 
misunderstanding your argument.

What I'm suggesting, and I apologize if it wasn't clear in my earlier 
responses, is this:

1. We don't try to debug minified builds. If we expect to use our daily build 
server as a place to do debugging and troubleshooting (and I think we should), 
it should always employ unminified builds.

2. We retain uglification with its default options, making it available for 
users (such as "plug and play" UI Options users) on their production sites (by 
creating a --source false build).

3. When we find the cycles, to a) add source maps support for our minified 
builds, and b) update our build system to produce both minified and unminified 
versions of "standard profiles" of Infusion such as framework-only, UIO-only, 
etc. and publish them via an npm prepublish script.

In the longer term, after #3, we should consider a much more in-depth process 
that will enable applications to be seamlessly moved from more to less 
"compiled" form and back again for authorial and debugging purposes throughout 
the application lifecycle. 

What are your thoughts on this?

Colin

___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Uglify modifies code in minified builds

[Steve Lee]

When I use libraries like jQuery (not sure about frameworks) I expect
a choice of ways too include the JS

* Hosted on a CDN non minified (probably gzipped)
* Hosted on a CDN minified
* Download a tarball with minified and non minifed versions
* Download through a package manager
* Build custom versions from source

Thus I choose which to use. Doesn't that apply here?

Steve Lee
OpenDirective http://opendirective.com


On 25 November 2015 at 20:34, Colin Clark  wrote:
> Antranig,
>
>> On Nov 25, 2015, at 2:24 PM, Antranig Basman  
>> wrote:
>>
>> > "Minified builds aren't intended for development. They're designed
>> > for production, and we shouldn't be either surprised or terribly
>> > concerned by the idea that somehow magically the code changed in
>> > layout or structure as a result of minification. That's what it's for!"
>>
>> i) reacts to a partial reading of my posting - the first paragraph of which 
>> contains (part of) exactly the same point you are making here - that we 
>> should not be surprised that the layout of code has changed due to 
>> minification
>
> I did indeed read that part of your post, and was intending to reinforce it 
> with my agreement. I apologize if that agreement wasn't clear; I don't think 
> our positions are terribly far apart.
>
>> ii) cuts against one of our core principles - that we should treat different 
>> parts of our authorial lifecycle - development, maintenance, production, or 
>> any other deployment context - as part of the same process. We should expect 
>> to be able to debug or work with any kind of deployment of Infusion on equal 
>> terms. Infusion is about equality of authorial access.
>
> I understand this principle and agree with it. My concern is largely 
> specific: dispensing with minification for Infusion right now will put a 
> particular category of users in an awkward position. We have users of UI 
> Options, for example, who expect to be able to take a bundle of JavaScript 
> and a small number of HTML templates and embed them directly in their 
> websites. No build process, no in-depth knowledge of JavaScript production 
> packaging techniques, and not even an understanding of what all the pieces 
> and parts are that compose UI Options.
>
> The unminified UI Options build is over 50% larger than the minified version. 
> So we're not talking about 13K here or there, but quite a lot more. I think 
> it's important to give users a minimal, out-of-the-box distribution of UI 
> Options that they don't have to process or manipulate in any way. We're not 
> quite there (in that users still have to follow a tutorial on how to make a 
> custom build), but we shouldn't go backwards in this regard. I worry that if 
> we dispense with minification entirely, it will be a step back. Perhaps I was 
> misunderstanding your argument.
>
> What I'm suggesting, and I apologize if it wasn't clear in my earlier 
> responses, is this:
>
> 1. We don't try to debug minified builds. If we expect to use our daily build 
> server as a place to do debugging and troubleshooting (and I think we 
> should), it should always employ unminified builds.
>
> 2. We retain uglification with its default options, making it available for 
> users (such as "plug and play" UI Options users) on their production sites 
> (by creating a --source false build).
>
> 3. When we find the cycles, to a) add source maps support for our minified 
> builds, and b) update our build system to produce both minified and 
> unminified versions of "standard profiles" of Infusion such as 
> framework-only, UIO-only, etc. and publish them via an npm prepublish script.
>
> In the longer term, after #3, we should consider a much more in-depth process 
> that will enable applications to be seamlessly moved from more to less 
> "compiled" form and back again for authorial and debugging purposes 
> throughout the application lifecycle.
>
> What are your thoughts on this?
>
> Colin
>
> ___
> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: This week's community meeting

[Steve Lee]

One final thought from Alan Kay on the equally inspiring C2 wiki.

Just a gentle reminder that I took some pains at the last OOPSLA to try to
remind everyone that Smalltalk is not only NOT its syntax or the class
library, it is not even about classes. I'm sorry that I long ago coined the
term "objects" for this topic because it gets many people to focus on the
lesser idea.

The big idea is "messaging" - that is what the kernal of Smalltalk/Squeak
is all about (and it's something that was never quite completed in our
Xerox PARC phase). The Japanese have a small word - ma - for "that which
is in between" - perhaps the nearest English equivalent is "interstitial".
The key in making great and growable systems is much more to design how its
modules communicate rather than what their internal properties and
behaviors should be. Think of the internet - to live, it (a) has to allow
many different kinds of ideas and realizations that are beyond any single
standard and (b) to allow varying degrees of safe interoperability between
these ideas.

http://c2.com/cgi/wiki?AlanKayOnMessaging
Steve Lee
OpenDirective http://opendirective.com


On 25 November 2015 at 19:52, Steve Lee  wrote:
> You want detail on the Dynabook?
>
> http://tkbr.ccsp.sfu.ca/dynabook/
> Steve Lee
> OpenDirective http://opendirective.com
>
>
> On 25 November 2015 at 19:34, Steve Lee  wrote:
>> A lone time ago I played around with Tim Budd's Tiny Smalltalk
>> designed for CS education and written in C. It seems to have vanished
>> except for some later versions in Java. It was not smalltalk 80
>> compliant
>>
>> This is the closest I can find
>>
>> https://github.com/kyle-github/littlesmalltalk
>> Steve Lee
>> OpenDirective http://opendirective.com
>>
>>
>> On 25 November 2015 at 17:41, Bates, Simon  wrote:
>>> At standup this morning, Dana was asking if there would be good places to 
>>> read more about the Smalltalk programming language.
>>>
>>> Dan Ingalls' article "Design Principles Behind Smalltalk" is a very nice 
>>> overview of some of the forces and motivations in the design of the 
>>> language:
>>>
>>> http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html
>>>
>>> In terms of introductions to the actual language itself, it's a little 
>>> harder to find satisfying online material. The best resource, I think, is 
>>> the book "Smalltalk-80: The Language And Its Implementation". A scanned PDF 
>>> is available online and the first few chapters introduce the language:
>>>
>>> http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf
>>>
>>> There is a quite nice "Terse Guide to Squeak" (the Smalltalk version I will 
>>> demo today) but it's not an intro or tutorial:
>>>
>>> http://squeak.org/documentation/terse_guide/
>>>
>>> If I find other good resources, I'll definitely pass them along. (For those 
>>> at IDRC in person, I brought in my copy of the Smalltalk-80 book, if you're 
>>> interested in taking a look.)
>>>
>>> Simon
>>> 
>>> From: fluid-work [fluid-work-boun...@lists.idrc.ocad.ca] on behalf of 
>>> Bates, Simon [sba...@ocadu.ca]
>>> Sent: Monday, November 23, 2015 8:47 AM
>>> To: Fluid Work ‎[fluid-w...@fluidproject.org]‎
>>> Subject: This week's community meeting
>>>
>>> Hi everyone,
>>>
>>> For this week's community meeting, we are going to continue with our series 
>>> on Case Studies of User Creativity. On Wednesday we will have a look at 
>>> Smalltalk and other work of Alan Kay and his collaborators.
>>>
>>> I'd like to suggest that in advance of Wednesday's meeting, we read one of 
>>> his papers from 1977, written with Adele Goldberg, called "Personal Dynamic 
>>> Media". This paper presents their vision for personal computing and for 
>>> portable computers called "Dynabooks".
>>>
>>> I've found 2 versions of the article online: a version with an introduction 
>>> that appeared in a 2003 collection called "The New Media Reader" and a scan 
>>> of the original:
>>>
>>> - http://www.newmediareader.com/book_samples/nmr-26-kay.pdf
>>> - https://www.computer.org/csdl/mags/co/1977/03/01646405.pdf
>>>
>>> (The whole New Media Reader book is really good and I'll bring it in on 
>>> Wednesday, if anyone is interested in taking a look at it.)
>>>
>>> At the meeting I will show a running Smalltalk system and I think it would 
>>> also be awesome to discuss the Personal Dynamic Media paper together.
>>>
>>> Looking forward to the conversations on Wednesday.
>>>
>>> Simon
>>> ___
>>> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
>>> To unsubscribe, change settings or access archives,
>>> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>>> ___
>>> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
>>> To unsubscribe, change settings or access archives,
>>> see 

RE: This week's community meeting

[Bates, Simon]

Another good read on the context and history of Smalltalk is Alan Kay's "The 
Early History of Smalltalk":

http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html

Simon

From: fluid-work [fluid-work-boun...@lists.idrc.ocad.ca] on behalf of Bates, 
Simon [sba...@ocadu.ca]
Sent: Wednesday, November 25, 2015 12:41 PM
To: Fluid Work ‎[fluid-w...@fluidproject.org]‎
Subject: RE: This week's community meeting

At standup this morning, Dana was asking if there would be good places to read 
more about the Smalltalk programming language.

Dan Ingalls' article "Design Principles Behind Smalltalk" is a very nice 
overview of some of the forces and motivations in the design of the language:

http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html

In terms of introductions to the actual language itself, it's a little harder 
to find satisfying online material. The best resource, I think, is the book 
"Smalltalk-80: The Language And Its Implementation". A scanned PDF is available 
online and the first few chapters introduce the language:

http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf

There is a quite nice "Terse Guide to Squeak" (the Smalltalk version I will 
demo today) but it's not an intro or tutorial:

http://squeak.org/documentation/terse_guide/

If I find other good resources, I'll definitely pass them along. (For those at 
IDRC in person, I brought in my copy of the Smalltalk-80 book, if you're 
interested in taking a look.)

Simon

From: fluid-work [fluid-work-boun...@lists.idrc.ocad.ca] on behalf of Bates, 
Simon [sba...@ocadu.ca]
Sent: Monday, November 23, 2015 8:47 AM
To: Fluid Work ‎[fluid-w...@fluidproject.org]‎
Subject: This week's community meeting

Hi everyone,

For this week's community meeting, we are going to continue with our series on 
Case Studies of User Creativity. On Wednesday we will have a look at Smalltalk 
and other work of Alan Kay and his collaborators.

I'd like to suggest that in advance of Wednesday's meeting, we read one of his 
papers from 1977, written with Adele Goldberg, called "Personal Dynamic Media". 
This paper presents their vision for personal computing and for portable 
computers called "Dynabooks".

I've found 2 versions of the article online: a version with an introduction 
that appeared in a 2003 collection called "The New Media Reader" and a scan of 
the original:

- http://www.newmediareader.com/book_samples/nmr-26-kay.pdf
- https://www.computer.org/csdl/mags/co/1977/03/01646405.pdf

(The whole New Media Reader book is really good and I'll bring it in on 
Wednesday, if anyone is interested in taking a look at it.)

At the meeting I will show a running Smalltalk system and I think it would also 
be awesome to discuss the Personal Dynamic Media paper together.

Looking forward to the conversations on Wednesday.

Simon
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Re: Uglify modifies code in minified builds

[Colin Clark]

Hi Antranig,

> On Nov 25, 2015, at 1:48 PM, Antranig Basman  
> wrote:
> 
> If we don't have time for this, the 13K savings through disabling the extra 
> optimisations seem neither here nor there - and having code without any 
> whitespace appear in the debugger seems equivalently obstructive to having 
> the optimised version you showed - even if Safari can deal with this, the 
> other browsers can't. I would say that until we're prepared to deploy SOURCE 
> MAPS, we should go with simple concatenation in our builds.

I disagree quite significantly, but I find the discussion very interesting.

Minified builds aren't intended for development. They're designed for 
production, and we shouldn't be either surprised or terribly concerned by the 
idea that somehow magically the code changed in layout or structure as a result 
of minification. That's what it's for!

Shipping Infusion out of the box in a way that doesn't support production 
deployers is a poor idea, and the toolchain you propose as an alternative is 
entirely worthwhile but will take some time to get our heads around and use 
appropriately. We're already behind the times in this regard and there's a lot 
of catching up and learning to do. In the meantime, let's just stop expecting 
to be able debug viably within a minified build.

Alternatively, I propose that we simply stop offering builds of Infusion at 
all, and be explicit about the fact that our users are entirely on their own in 
this regard. That doesn't sound like an appealing option to me, but hopefully 
you see my point.

Colin
___
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work