Hi Aik-Siong-- > I want to go to a web page, select a body of text and have Smalltalk > code analyze the text in some way and return the answer in the > browser or in the Smalltalk app or file output. There should be > two-way communication between app and browser. I would like to do > live debugging too. Ah, it sounds like you want something that would work with arbitrary websites you happen to visit. I would do that by making a SqueakJS-powered extension for an existing web browser (e.g., a Chrome extension). The JavaScript bridge in SqueakJS gives you full two-way livecoding access to the host browser's JS engine, and I'd probably use it for the Smalltalk app's UI (driving some JS front-end library, like React). And there's no reason the object memory can't be Pharo. At this point, I think it makes much more sense to run Smalltalk in a web browser rather than building a Smalltalk web browser. I find SqueakJS easily fast enough for useful things, like the Cog app streaming Eliot mentioned. WebAssembly will enable web browsers to run Cog directly (although subject to web security constraints), making JavaScript completely optional. Yes, the web platform is full of astounding accidental complexity, as Stephen pointed out. Still, there's a lot of great work, community energy, and reach in which Smalltalk can now participate, and I'm enjoying it. (Thanks again, Bert, Dan and all!) -C -- Craig Latta Black Page Digital Amsterdam :: San Francisco [hidden email] +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
Administrator
|
Craig:
Thanks for the reply. I think I see your point. WebAssembly lives in the browser and is supposed to be almost as fast as native Assembly. So the Smalltalk VMs, which are mostly C, can be compiled to WebAssembly to run inside browsers everywhere and be fast too. Wow. Is WebAssembly released yet? When can we expect such a VM running a standard Smalltalk? What are the pros and cons compared to native apps? All the best, Aik-Siong Koh
|
In reply to this post by askoh
Here is a workable solution: Headless Chrome This HN thread has some interesting things we could take inspiration from. We can drive it from Pharo and grab the screen, and then show that in a Morph. Then capture clicks and send then to the headless chrome. Will not do everything, but can be decent. Phil On Sun, Apr 30, 2017 at 10:37 PM, askoh <[hidden email]> wrote: Yes. It is a novel way of remote desktop. Perhaps Craig can tell if it can do |
And the WebDriver protocol doesn't seem that intractable. On Tue, May 2, 2017 at 8:28 PM, [hidden email] <[hidden email]> wrote:
|
In reply to this post by philippeback
On 5/2/17, [hidden email] <[hidden email]> wrote:
> Here is a workable solution: Headless Chrome > > https://developers.google.com/web/updates/2017/04/headless-chrome > > This HN thread has some interesting things we could take inspiration from. > > We can drive it from Pharo and grab the screen, and then show that in a > Morph. Then capture clicks and send then to the headless chrome. > > Will not do everything, but can be decent. +1 Thanks for this link, Phil. Seems to be an exercise with some OSProcess calls. The result might as well have an application for the testing of web site rendering. Though there are many tools (e.g. http://phantomjs.org/) which do this it is convenient to do the scripting in Smalltalk. --Hannes > > Phil > > On Sun, Apr 30, 2017 at 10:37 PM, askoh <[hidden email]> wrote: > >> Yes. It is a novel way of remote desktop. Perhaps Craig can tell if it >> can >> do >> the following. >> I want to go to a web page, select a body of text and have Smalltalk code >> analyze the text in some way and return the answer in the browser or in >> the >> Smalltalk app or file output. There should be two-way communication >> between >> app and browser. I would like to do live debugging too. >> >> Aik-Siong Koh >> >> >> Hi Askoh, >> >> are you also aware of Snowglobe >> https://thiscontext.com/2016/10/31/app-streaming-with-snowglobe/ ? This >> allows one to use a standard Smalltalk image running on the native Cog VM >> to >> render in a web browser. >> >> _,,,^..^,,,_ (phone) >> >> >> >> >> -- >> View this message in context: http://forum.world.st/ >> Smalltalk-Internet-Browser-tp4944879p4944998.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> > |
On Tue, May 2, 2017 at 8:45 PM, H. Hirzel <[hidden email]> wrote: On 5/2/17, [hidden email] <[hidden email]> wrote: More like REST calls ( https://w3c.github.io/webdriver/webdriver-spec.html ) against chromedriver executable driving headless chrome.
PhantomJS maintainer stepped down upon the news of ChromeHeadless becoming available. Phil
|
On 5/2/17, [hidden email] <[hidden email]> wrote:
> On Tue, May 2, 2017 at 8:45 PM, H. Hirzel <[hidden email]> wrote: > >> On 5/2/17, [hidden email] <[hidden email]> wrote: >> > Here is a workable solution: Headless Chrome >> > >> > https://developers.google.com/web/updates/2017/04/headless-chrome >> > >> > This HN thread has some interesting things we could take inspiration >> from. >> > >> > We can drive it from Pharo and grab the screen, and then show that in a >> > Morph. Then capture clicks and send then to the headless chrome. >> > >> > Will not do everything, but can be decent. >> >> +1 >> Thanks for this link, Phil. >> >> Seems to be an exercise with some OSProcess calls. >> > > More like REST calls ( https://w3c.github.io/webdriver/webdriver-spec.html > ) against chromedriver executable driving headless chrome. Ok, this makes it easier, in fact. Thanks for the clarification. > >> >> The result might as well have an application for the testing of web >> site rendering. >> >> Though there are many tools (e.g. http://phantomjs.org/) which do this >> it is convenient to do the scripting in Smalltalk. >> > > PhantomJS maintainer stepped down upon the news of ChromeHeadless becoming > available. Good to know. --Hannes > Phil > >> >> --Hannes >> >> >> > >> > Phil >> > >> > On Sun, Apr 30, 2017 at 10:37 PM, askoh <[hidden email]> wrote: >> > >> >> Yes. It is a novel way of remote desktop. Perhaps Craig can tell if it >> >> can >> >> do >> >> the following. >> >> I want to go to a web page, select a body of text and have Smalltalk >> code >> >> analyze the text in some way and return the answer in the browser or >> >> in >> >> the >> >> Smalltalk app or file output. There should be two-way communication >> >> between >> >> app and browser. I would like to do live debugging too. >> >> >> >> Aik-Siong Koh >> >> >> >> >> >> Hi Askoh, >> >> >> >> are you also aware of Snowglobe >> >> https://thiscontext.com/2016/10/31/app-streaming-with-snowglobe/ ? >> This >> >> allows one to use a standard Smalltalk image running on the native Cog >> VM >> >> to >> >> render in a web browser. >> >> >> >> _,,,^..^,,,_ (phone) >> >> >> >> >> >> >> >> >> >> -- >> >> View this message in context: http://forum.world.st/ >> >> Smalltalk-Internet-Browser-tp4944879p4944998.html >> >> Sent from the Pharo Smalltalk Developers mailing list archive at >> >> Nabble.com. >> >> >> >> >> > >> >> > |
In reply to this post by askoh
> So the Smalltalk VMs, which are mostly C, can be compiled to > WebAssembly to run inside browsers everywhere and be fast too. Wow. > Is WebAssembly released yet? It's enabled by default in Chrome 57 and Firefox 52 and later. See [1] and [2] for ongoing status and instructional material. > When can we expect such a VM running a standard Smalltalk? I expect it'll happen this year, although I don't know when the Safari and Edge web browsers will enable it. > What are the pros and cons compared to native apps? For me, the pros are zero-installation ubiquity and integration with other web tech, and the con is restricted access to local resources. -C [1] https://developer.mozilla.org/en-US/docs/WebAssembly [2] http://webassembly.org -- Craig Latta Black Page Digital Amsterdam :: San Francisco [hidden email] +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
In reply to this post by askoh
On 29 April 2017 at 03:11, askoh <[hidden email]> wrote: Being connected to the internet is going to be a necessity for any piece of I think the OP is speaking along these lines - other apparently smaller teams seem to have accomplished something like that: |
Administrator
|
In reply to this post by Craig Latta
Thanks everyone for digging out the various possibilities. It is heartening to know the community is healthy and engaging.
Let me summarize the possibilities: 1) Recompile Smalltalk VM from C to WebAssembly to run inside a browser at near native speed. This means a complete Smalltalk IDE inside a browser with full access to the browser innards. 2) Embed Chromium or ChromeHeadless or WebKit inside the Smalltalk IDE. Browser access is through the exposed APIs. 3) Enhance Scamper, a basic browser written in Smalltalk, to include more and more of the capabilities of Chrome say. All the best, Aik-Siong Koh |
2017-05-04 17:55 GMT+02:00 askoh <[hidden email]>:
There is also Firefox. And we already use part of it in Bloc project: Moz2D library |
In reply to this post by askoh
If I understand the proposal correctly, something similar was tried in
project Lively Kernel (https://www.lively-kernel.org/), which is dead since long and was marginally relevant perhaps only in the academic field and not at all in the real world. Personally, I think there are better ways to spend the scarce but otherwise good human resources involved in the Smalltalk world: but anyway, good luck. Greetings Raffaello On 04/05/17 17:55, askoh wrote: > Thanks everyone for digging out the various possibilities. It is heartening > to know the community is healthy and engaging. > > Let me summarize the possibilities: > 1) Recompile Smalltalk VM from C to WebAssembly to run inside a browser at > near native speed. This means a complete Smalltalk IDE inside a browser with > full access to the browser innards. > 2) Embed Chromium or ChromeHeadless or WebKit inside the Smalltalk IDE. > Browser access is through the exposed APIs. > 3) Enhance Scamper, a basic browser written in Smalltalk, to include more > and more of the capabilities of Chrome say. > > All the best, > Aik-Siong Koh > > > > -- > View this message in context: http://forum.world.st/Smalltalk-Internet-Browser-tp4944879p4945606.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > |
In reply to this post by askoh
On 4 May 2017 at 08:55, askoh <[hidden email]> wrote: Thanks everyone for digging out the various possibilities. It is heartening It's not WebAssembly but Squeak running in a browser is already old news, thanks to Bert Freudenberg - see http://try.squeak.org/#url=http://files.squeak.org/5.0/&zip=[Squeak5.0-15113.zip,SqueakV50.sources.zip] and https://squeak.js.org/. I don't know about interop between that image running in the browser, and the browser itself. frank 2) Embed Chromium or ChromeHeadless or WebKit inside the Smalltalk IDE. |
In reply to this post by raffaello.giulietti
Raffaello writes: > If I understand the proposal correctly, something similar was tried in > project Lively Kernel (https://www.lively-kernel.org/), which is dead > since long... That project is alive, actually. > ...and was marginally relevant perhaps only in the academic > field and not at all in the real world. As far as I know, the most Lively activity is at the Hasso-Plattner Institute, but it was also very well received at industry conference JSConf. Frank writes: > ...Squeak running in a browser is already old news, thanks to > [SqueakJS by] Bert Freudenberg... Right, I mentioned it earlier in this very thread, along with WebAssembly. > I don't know about interop between that image running in the browser, > and the browser itself. Since there's a two-way JavaScript bridge in SqueakJS, you can do anything with the browser that any other script can do. It works well. -C -- Craig Latta Black Page Digital Amsterdam :: San Francisco [hidden email] +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
On 05/05/17 12:25, Craig Latta wrote:
> > Raffaello writes: > >> If I understand the proposal correctly, something similar was tried in >> project Lively Kernel (https://www.lively-kernel.org/), which is dead >> since long... > > That project is alive, actually. > The last news and copyright notices are from 2012, the last release is from February 2014, the last mailing list entry is from August 2016 and its gzipped volume in the last year is less than 5 KB. Would anybody honestly call such a project "alive"? |
In reply to this post by Frank Shearar-3
frank is it a browser plugin? On Thu, May 4, 2017 at 10:31 PM, Frank Shearar <[hidden email]> wrote:
|
In reply to this post by raffaello.giulietti
Raffaello writes: > > > If I understand the proposal correctly, something similar was > > > tried in project Lively Kernel (https://www.lively-kernel.org/), > > > which is dead since long... > > > > That project is alive, actually. > > The last news and copyright notices are from 2012, the last release is > from February 2014, the last mailing list entry is from August 2016 > and its gzipped volume in the last year is less than 5 KB. > > Would anybody honestly call such a project "alive"? As long as there are people using it, then yes, it's alive. I would say the best indication of activity is the HPI Lively Kernel page[1], and its associated wiki, which has content from 2017. You might also be interested in the consulting work done for Daimler with Lively, and other real-world projects described in the paper "A World of Active Objects for Work and Play: The First Ten Years of Lively", by Ingalls et al[2]. For me, the most relevant example of Lively's real-world impact is Bert Freudenberg's use of it to create SqueakJS. You can read about that in the paper "SqueakJS - A Modern and Practical Smalltalk That Runs in Any Browser"[3]. I'm using SqueakJS now to create in-browser JavaScript IDEs (for livecoding JS front-end frameworks like React), and distributed systems that federate native apps with web browsers across multiple machines. Stéphane writes: > ...is [SqueakJS] a browser plugin? No, it's a JS framework written in normal JavaScript, loadable by any HTML page via a <script> tag. One could package it as a web browser extension, though (or a node.js package, etc.). You can get all the details, and try it out, at [4]. thanks, -C [1] https://tinyurl.com/l3uxuzp (hpi.uni-potsdam.de) [2] https://tinyurl.com/lad3mqw (hpi.uni-potsdam.de) [3] https://tinyurl.com/lnwhbov (hpi.uni-potsdam.de) [4] https://squeak.js.org -- Craig Latta Black Page Digital Amsterdam :: San Francisco [hidden email] +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
Free forum by Nabble | Edit this page |