Smalltalk Internet Browser
Being connected to the internet is going to be a necessity for any piece of software in the immediate future. So every Smalltalk development environment or application should have that capability as default. To push that envelop, every image should have a Smalltalk native Internet Browser. By developing that Internet Browser, we are demonstrating the power of Smalltalk. There is no reason why Smalltalk cannot be as intimate to the World Wide Web as Javascript. We can have the IDE in Smalltalk, Internet Browser in Smalltalk and a WWW language in Smalltalk. As is uniquely Smalltalk, every bit of code is visible, modifiable and debuggable. This supped up environment will grow and grow to be a full OS. How can we gather the relevant Smalltalk code and necessary plugins to make an Internet Browser? I remember Croquet had internet browser and video player. What is missing? All the best, Aik-Siong Koh -- View this message in context: http://forum.world.st/Smalltalk-Internet-Browser-tp4944879.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2017-04-29 4:11 GMT+02:00 askoh <askoh@askoh.com>:
Being connected to the internet is going to be a necessity for any piece of software in the immediate future. So every Smalltalk development environment or application should have that capability as default. To push that envelop, every image should have a Smalltalk native Internet Browser. By developing that Internet Browser, we are demonstrating the power of Smalltalk. There is no reason why Smalltalk cannot be as intimate to the World Wide Web as Javascript. We can have the IDE in Smalltalk, Internet Browser in Smalltalk and a WWW language in Smalltalk. As is uniquely Smalltalk, every bit of code is visible, modifiable and debuggable. This supped up environment will grow and grow to be a full OS.
How can we gather the relevant Smalltalk code and necessary plugins to make an Internet Browser? I remember Croquet had internet browser and video player. What is missing?
All the best, Aik-Siong Koh
html5, javascript, etc... Good luck! What is the size of teams for building Firefox, Safari or Edge? Just browse https://github.com/mozilla for curiosity For example, just the core: https://github.com/mozilla/gecko-dev Not sure that the million $ that Tim is asking regularly would bring us any close to those references. You'll have to implement a bunch of technologies... At least, the good point is that it would make sure that we have a truly open smalltalk ;)
-- View this message in context: http://forum.world.st/ Smalltalk-Internet-Browser-tp4944879.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi. I remember Esteban integrated Chrome into Pharo. Would be interesting to know details. 2017-04-29 8:58 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
2017-04-29 4:11 GMT+02:00 askoh <askoh@askoh.com>:
Being connected to the internet is going to be a necessity for any piece of software in the immediate future. So every Smalltalk development environment or application should have that capability as default. To push that envelop, every image should have a Smalltalk native Internet Browser. By developing that Internet Browser, we are demonstrating the power of Smalltalk. There is no reason why Smalltalk cannot be as intimate to the World Wide Web as Javascript. We can have the IDE in Smalltalk, Internet Browser in Smalltalk and a WWW language in Smalltalk. As is uniquely Smalltalk, every bit of code is visible, modifiable and debuggable. This supped up environment will grow and grow to be a full OS.
How can we gather the relevant Smalltalk code and necessary plugins to make an Internet Browser? I remember Croquet had internet browser and video player. What is missing?
All the best, Aik-Siong Koh
html5, javascript, etc... Good luck! What is the size of teams for building Firefox, Safari or Edge? Just browse https://github.com/mozilla for curiosity For example, just the core: https://github.com/mozilla/gecko-dev Not sure that the million $ that Tim is asking regularly would bring us any close to those references. You'll have to implement a bunch of technologies... At least, the good point is that it would make sure that we have a truly open smalltalk ;)
-- View this message in context: http://forum.world.st/Smalltal k-Internet-Browser-tp4944879.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
And for simple HTML pages this might be interesting https://github.com/HPI-SWA-Teaching/Scamper (8 contributors, 380 commits) On 4/29/17, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi.
I remember Esteban integrated Chrome into Pharo. Would be interesting to know details.
2017-04-29 8:58 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
2017-04-29 4:11 GMT+02:00 askoh <askoh@askoh.com>:
Being connected to the internet is going to be a necessity for any piece of software in the immediate future. So every Smalltalk development environment or application should have that capability as default. To push that envelop, every image should have a Smalltalk native Internet Browser. By developing that Internet Browser, we are demonstrating the power of Smalltalk. There is no reason why Smalltalk cannot be as intimate to the World Wide Web as Javascript. We can have the IDE in Smalltalk, Internet Browser in Smalltalk and a WWW language in Smalltalk. As is uniquely Smalltalk, every bit of code is visible, modifiable and debuggable. This supped up environment will grow and grow to be a full OS.
How can we gather the relevant Smalltalk code and necessary plugins to make an Internet Browser? I remember Croquet had internet browser and video player. What is missing?
All the best, Aik-Siong Koh
html5, javascript, etc... Good luck! What is the size of teams for building Firefox, Safari or Edge? Just browse https://github.com/mozilla for curiosity For example, just the core: https://github.com/mozilla/gecko-dev Not sure that the million $ that Tim is asking regularly would bring us any close to those references. You'll have to implement a bunch of technologies... At least, the good point is that it would make sure that we have a truly open smalltalk ;)
-- View this message in context: http://forum.world.st/Smalltal k-Internet-Browser-tp4944879.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Let me clarify that this browser is to enhance software development and not for mainstream use - at least not yet. Imagine have the full power of Smalltalk IDE while browsing the internet. I click on a photo and run image processing on it to see if it is natural or artificial, recognize objects or people, etc. I can have my own algorithm to suppress ads or popups. I can invent and test security models. I can download and upload from within the environment. I can search the environment and web at the same time. Indeed, Smalltalk lacks many technologies. But internet technologies are so so important we must have them ASAP. Having a GOAL to create a Smalltalk native Internet Browser (SIB) inside the environment will ensure we are not left behind. The synergy (IDE+SIB) will bring software development to the next level. Again it's something Smalltalk can pioneer. Every Smalltalk application will be web enabled automatically. Javascript is popular because it is embedded into all internet browsers. Google intentionally embed Dart into Chrome. We can have Smalltalk in SIB. SIB will improve Smalltalk programming productivity. We start out by embedding Chrome inside the IDE. Make them communicate well. We then port bit by bit to Smalltalk based on needs and priorities. All the best, Aik-Siong Koh -- View this message in context: http://forum.world.st/Smalltalk-Internet-Browser-tp4944879p4944902.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
What you can try is to resurrect the old web browser plugin. Now if you want to help why don;t you join the community and help? Stef On Sat, Apr 29, 2017 at 7:00 PM, askoh <askoh@askoh.com> wrote:
Let me clarify that this browser is to enhance software development and not for mainstream use - at least not yet.
Imagine have the full power of Smalltalk IDE while browsing the internet. I click on a photo and run image processing on it to see if it is natural or artificial, recognize objects or people, etc. I can have my own algorithm to suppress ads or popups. I can invent and test security models. I can download and upload from within the environment. I can search the environment and web at the same time.
Indeed, Smalltalk lacks many technologies. But internet technologies are so so important we must have them ASAP. Having a GOAL to create a Smalltalk native Internet Browser (SIB) inside the environment will ensure we are not left behind. The synergy (IDE+SIB) will bring software development to the next level. Again it's something Smalltalk can pioneer. Every Smalltalk application will be web enabled automatically.
Javascript is popular because it is embedded into all internet browsers. Google intentionally embed Dart into Chrome. We can have Smalltalk in SIB. SIB will improve Smalltalk programming productivity.
We start out by embedding Chrome inside the IDE. Make them communicate well. We then port bit by bit to Smalltalk based on needs and priorities.
All the best, Aik-Siong Koh
-- View this message in context: http://forum.world.st/ Smalltalk-Internet-Browser-tp4944879p4944902.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2017-04-29 19:00 GMT+02:00 askoh <askoh@askoh.com>:
We start out by embedding Chrome inside the IDE. Make them communicate well. We then port bit by bit to Smalltalk based on needs and priorities.
I am wondering, when you said "we" what you mean? Did you found team to work on such project?
We means all communities of Smalltalk environments. Pharo is of course the biggest, hence my post here first. I am verifying the soundness of the idea of SIB and then do a student project on it. I am from the VisualWork community. I look forward to porting freeCAD: 3D CAD with Motion Simulation to Pharo when it has 64bit version on Windows. Aik-Siong Koh Denis Kudriashov wrote
2017-04-29 19:00 GMT+02:00 askoh <
askoh@
>:
We start out by embedding Chrome inside the IDE. Make them communicate well. We then port bit by bit to Smalltalk based on needs and priorities.
I am wondering, when you said "we" what you mean? Did you found team to work on such project?
-- View this message in context: http://forum.world.st/Smalltalk-Internet-Browser-tp4944879p4944919.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Did you tried Amber? Is Smalltalk on the browser. I believe that what you mean is embedding the V8 engine into Pharo. But man, thats a huge work. Really... my 2c. *Lic. Ignacio Sniechowski, MBA* *Prosavic SRL* â* (5411) 4542-6712* ð±* (54911) 6749-4721* On Sat, Apr 29, 2017 at 7:53 PM, askoh [via Smalltalk] < ml+s1294792n4944919h82@n4.nabble.com> wrote:
We means all communities of Smalltalk environments. Pharo is of course the biggest, hence my post here first. I am verifying the soundness of the idea of SIB and then do a student project on it. I am from the VisualWork community. I look forward to porting freeCAD: 3D CAD with Motion Simulation to Pharo when it has 64bit version on Windows.
Aik-Siong Koh
Denis Kudriashov wrote 2017-04-29 19:00 GMT+02:00 askoh <[hidden email] <http:///user/SendEmail.jtp?type=node&node=4944919&i=0>>:
We start out by embedding Chrome inside the IDE. Make them communicate well. We then port bit by bit to Smalltalk based on needs and priorities.
I am wondering, when you said "we" what you mean? Did you found team to work on such project?
------------------------------ If you reply to this email, your message will be added to the discussion below: http://forum.world.st/Smalltalk-Internet-Browser-tp4944879p4944919.html To start a new topic under Pharo Smalltalk Developers, email ml+s1294792n1294837h40@n4.nabble.com To unsubscribe from Pharo Smalltalk Developers, click here <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&nod...> . NAML <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant...>
----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Smalltalk-Internet-Browser-tp4944879p4944920.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
An interesting way would rather do something like electron. https://electron.atom.io/ In fact, I would even go so far as to add Pharo to electron. Phil On Sun, Apr 30, 2017 at 1:34 AM, nacho <0800nacho@gmail.com> wrote:
Did you tried Amber? Is Smalltalk on the browser. I believe that what you mean is embedding the V8 engine into Pharo. But man, thats a huge work. Really... my 2c.
*Lic. Ignacio Sniechowski, MBA* *Prosavic SRL* â* (5411) 4542-6712* ð±* (54911) 6749-4721*
On Sat, Apr 29, 2017 at 7:53 PM, askoh [via Smalltalk] <[hidden email] <http:///user/SendEmail.jtp?type=node&node=4944920&i=0>> wrote:
We means all communities of Smalltalk environments. Pharo is of course the biggest, hence my post here first. I am verifying the soundness of the idea of SIB and then do a student project on it. I am from the VisualWork community. I look forward to porting freeCAD: 3D CAD with Motion Simulation to Pharo when it has 64bit version on Windows.
Aik-Siong Koh
Denis Kudriashov wrote 2017-04-29 19:00 GMT+02:00 askoh <[hidden email] <http:///user/SendEmail.jtp?type=node&node=4944919&i=0>>:
We start out by embedding Chrome inside the IDE. Make them communicate well. We then port bit by bit to Smalltalk based on needs and priorities.
I am wondering, when you said "we" what you mean? Did you found team to work on such project?
------------------------------ If you reply to this email, your message will be added to the discussion below: http://forum.world.st/Smalltalk-Internet-Browser-tp4944879p4944919.html To start a new topic under Pharo Smalltalk Developers, email [hidden email] <http:///user/SendEmail.jtp?type=node&node=4944920&i=1> To unsubscribe from Pharo Smalltalk Developers, click here. NAML <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant...>
Nacho Smalltalker apprentice. Buenos Aires, Argentina.
------------------------------ View this message in context: Re: Smalltalk Internet Browser <http://forum.world.st/Smalltalk-Internet-Browser-tp4944879p4944920.html> Sent from the Pharo Smalltalk Developers mailing list archive <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> at Nabble.com.
Beyond the barrier of this being a huge vaporware effort, bare in mind that a large percentage of Browsers are implemented in C/C++ for performance reasons. In the cases of Firefox and Chrome its 50% in both cases that is made in C/C++. https://www.openhub.net/p/firefox https://www.openhub.net/p/chrome So immediately that means you have 3 options 1) Code it yourself/ your team in C/C++ that 50% 2) Use the existing code bases of either Firefox or Chrome 3) Code it all in pure Pharo (3) is the most attracting for Pharo devs and it will really prove that Pharo can make a Internet browser but you can forget about it. Pharo is around 10-50 times slower than C/C++ and if we take into account that Firefox alone can easily eat alive a quad core cpu and 1GB of memory , numbers that are unheard of to Pharo developer in large , it make the use of Pharo a non choice. So he erase (3) from the list. (1) Code it yourself C/C++ is again not doable since we are talking about milions and millions of lines of code , that means your browser will end up being 3-10 times larger to Pharo itself. Good luck with that. (2) is your realistic options that 50% that is coded in C/C++ will save you quite a lot of developing time and give you the performance you need but even this option comes with huge drawbacks of having to wrap millions and millions of lines of code so Pharo can have access to it, you could automate it to an extend but still A TON of work. Also do not be misled by that 50% if you think it covers 50% of the features, it does not. I would not be surprised if it covers 80-90% of the features so its not the 50% you can ignore or not focus on. Simply put Pharo is not a language designed for high performance coding. Bare in mind that we only recently got 64 bit support , something that would make C/C++ developers laugh. Not to exclude the sheer number of tools that C/C++ have that can debug and optimise code especially when it comes to memory management. We talking here not about 5-10 tools/libraries but an entire universe of options. I am not saying that Pharo is a bad language by any means. We would laugh at C/C++ coders with the way they try to implement OOP or dynamic coding. Pharo is amazing for low performance coding and if you want to quickly put together applications on the fly. If you want to do something realistic then your best bet will be to assist the PharoJS folks because the number one thing you need to even got the attention of web devs is excellent JS , HTML and CSS support out of the box. An area that I have worked with Pharo is IPC (Inter Process Communication) that makes it possible for Pharo to communicate with any software and language and use any tool, any library of any language etc. Embedding a browser inside Pharo could be beneficial for the community under a single scenario. Abandoning Morphic and Bloc and moving to QT. I know this is enough to start people throwing tomatoes at me but I do believe it would be of immense value to Pharo. QT is de facto THE KING of GUIs , not only QT can embed a browser , OpenGL contexts it can also embed itself inside mobile apps and web apps. Its an extremely powerful API that will open the doors for us to all enviroments and OSes, web dev, iOS, Android, Macos, Windows, Linux etc. But realistically this will never happen because it will require for Pharo devs to start coding in C++ to wrap QT for Pharo (its a C++ lib) and then they will stop throwing tomatoes at me and start throwing knifes and I would not even blame them. Good luck with anything you decide doing you are going needs tons of it and tons of patience.
A thoughtful description Mr. Kilon, couldn't agree more. Even if the solution is based in node/v8 or derivate technologies like electron it will be a nightmare to integrate that. And IMHO, electron should be killed!! It's really a bad bad idea. You have like 10 single apps that run a full V8/node stack. Atom, Discord, LightTable, Chrome itself...it's so RAM & CPU consuming. For me it is like saying that a desktop application is pure front-end development. best ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Smalltalk-Internet-Browser-tp4944879p4944954.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
And IMHO, electron should be killed!! It's really a bad bad idea. You have like 10 single apps that run a full V8/node stack. Atom, Discord, LightTable, Chrome itself...it's so RAM & CPU consuming. For me it is like saying that a desktop application is pure front-end development. best
The appeal of electron is not that it will be very good performance wise but that its much easier for a web dev to move his/her web app to desktop with minimum amount of effort. Of course minimum effort has the side effect of lousy performance but in the case of apps like Discord which they do not do much its ok. So electron makes sense. Whether we should support such a framework is something that is up to the Pharo devs themselves. Take a look at Ruby on Rails, it was started from a single person for his own needs. Like many of our own Pharo libraries. You make something you need, you release it and if people find it useful they will contribute , if not its still useful to you ;) Such libs/tools like Electron have zero appeal to us desktop developers mainly because even web devs do not like web development for the known problem it has. Also web devs tend to over exaggerate about the appeal of individual web frameworks , I read an article making the bold claims of massive success for Node.js as a server API , I did some research and I came in front page evidence of massive failure, servers remain firmly committed to Apache which yes its written in C. Not that I doubt for a second that an API for a dynamic language would be able to compete with the behemoth of performance that C really is on its own field, obviously servers needs top performance because of the big load they have to manage. I enjoy ninja attacking such web posts and expose them for what they really are, fake. The other day another web dev made the bold claim that web games are on the rise, took me a second to do my research and find one of the most highly regarded research surveys in game industry that clearly show not only that web games are no more than 4% but they going straight to the hell of 0%. Apparently the one ones excited to play games inside the web browser are web devs that want to make blog post with ridiculous claims. Web remains and will remain strictly inside the web browser, outside it, very few people like it and actually choose it as they are preferred way of development. The same way none would pick C/C++ for a non performance orientated app well at least most logical people, unless of course there is a very good reason for such a choice. Of course C devs do not feel the need , at least AFAIK , to exaggerate the usefulness of their own language in blog posts with zero reference to actual reliable sources. But they are no angels either. Personally I think the future of the Web which will only grow in popularity will be outside the browser and already desktop apps have taken advantage of this. We see this a lot with mobile apps that steal away the users of web browsers. How many people use the web browser to like and chat on facebook compared to the ones using the native mobile clients ? Not many.
Thanks everyone for your input. I am aware of Amber - worthy effort. I am more interested in Smalltalk IDE or app having a Browser. I am thinking more of Smalltalk calling Chromium Embedded Framework (CEF) via APIs. The browser is in direct two-way communication with the Smalltalk app. The complete API may be huge, but we can start with 1, 10, 100 APIs and still do useful stuff. Smalltalk missed out to Java because it did not embrace the internet. Let's not continue to miss out. Someone mentioned Pharo should be good with data analysis. Well, I think a lot, if not all, that data is going to come from the internet. Hence an embedded browser is a great helper. Python rode on C/C++. Ruby rode on Rails and on Web. What can Smalltalk ride on? VisualWorks Appex seems to be an attempt to ride on Javascript. VW Appex manages both Smalltalk and Javascript in the same image. Javascript edits in Appex are reflected to the Internet Browser when it is refreshed. Most interestingly, Javascript edits in the Internet Browser Dev Tools are picked up by Appex and put into the image. What do you think of this strategy? Aik-Siong Koh nacho wrote
Did you tried Amber? Is Smalltalk on the browser. I believe that what you mean is embedding the V8 engine into Pharo. But man, thats a huge work. Really... my 2c.
*Lic. Ignacio Sniechowski, MBA* *Prosavic SRL* â* (5411) 4542-6712* ð±* (54911) 6749-4721*
On Sat, Apr 29, 2017 at 7:53 PM, askoh [via Smalltalk] <
ml+s1294792n4944919h82@.nabble
wrote:
We means all communities of Smalltalk environments. Pharo is of course the biggest, hence my post here first. I am verifying the soundness of the idea of SIB and then do a student project on it. I am from the VisualWork community. I look forward to porting freeCAD: 3D CAD with Motion Simulation to Pharo when it has 64bit version on Windows.
Aik-Siong Koh
Denis Kudriashov wrote 2017-04-29 19:00 GMT+02:00 askoh <[hidden email] <http:///user/SendEmail.jtp?type=node&node=4944919&i=0>>:
We start out by embedding Chrome inside the IDE. Make them communicate well. We then port bit by bit to Smalltalk based on needs and priorities.
I am wondering, when you said "we" what you mean? Did you found team to work on such project?
------------------------------ If you reply to this email, your message will be added to the discussion below: http://forum.world.st/Smalltalk-Internet-Browser-tp4944879p4944919.html To start a new topic under Pharo Smalltalk Developers, email
ml+s1294792n1294837h40@.nabble
To unsubscribe from Pharo Smalltalk Developers, click here <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1294837&code=MDgwMG5hY2hvQGdtYWlsLmNvbXwxMjk0ODM3fC0xOTAxMTExODEy>; . NAML <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>;
-- View this message in context: http://forum.world.st/Smalltalk-Internet-Browser-tp4944879p4944991.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 29/04/17 04:11, askoh wrote:
Being connected to the internet is going to be a necessity for any piece of software in the immediate future. So every Smalltalk development environment or application should have that capability as default. To push that envelop, every image should have a Smalltalk native Internet Browser.
Web is a very bad platform from an engineering point of view. The amount of accidental complexity is astounding, as is the number of useless layers obfuscating this all. I don't think we are ready to waste the amount of engineering needed to do something useful at the browser implementation side of the web (except for things like amber, pharojs and squeakjs). Stephan
+1 i think the development of pharo should more focus on an "easy to use and adaptive live data analysis environment" which supports data science tasks with easy to use data retrieving, data preparation, data exploration, data modelling, scripting capabilities. We already have so many pieces and knowledge for this kind of platform around. I think only the cool story is missing .. And yes i know Moose, but i have the feeling this environment is not Moose. For me Moose is to much associated with software analysis ... Volkert Am 30.04.2017 um 17:06 schrieb Stephan Eggermont:
On 29/04/17 04:11, askoh wrote:
Being connected to the internet is going to be a necessity for any piece of software in the immediate future. So every Smalltalk development environment or application should have that capability as default. To push that envelop, every image should have a Smalltalk native Internet Browser.
Web is a very bad platform from an engineering point of view. The amount of accidental complexity is astounding, as is the number of useless layers obfuscating this all. I don't think we are ready to waste the amount of engineering needed to do something useful at the browser implementation side of the web (except for things like amber, pharojs and squeakjs).
Stephan
I tried to convince alex to focus on the missing pieces around roassal: On Sun, Apr 30, 2017 at 6:03 PM, volkert <volkert@nivoba.de> wrote:
+1
i think the development of pharo should more focus on an "easy to use and adaptive live data analysis environment" which supports data science tasks with easy to use data retrieving, data preparation, data exploration, data modelling, scripting capabilities. We already have so many pieces and knowledge for this kind of platform around. I think only the cool story is missing .. And yes i know Moose, but i have the feeling this environment is not Moose. For me Moose is to much associated with software analysis ...
Volkert
Am 30.04.2017 um 17:06 schrieb Stephan Eggermont:
On 29/04/17 04:11, askoh wrote:
Being connected to the internet is going to be a necessity for any piece of software in the immediate future. So every Smalltalk development environment or application should have that capability as default. To push that envelop, every image should have a Smalltalk native Internet Browser.
Web is a very bad platform from an engineering point of view. The amount of accidental complexity is astounding, as is the number of useless layers obfuscating this all. I don't think we are ready to waste the amount of engineering needed to do something useful at the browser implementation side of the web (except for things like amber, pharojs and squeakjs).
Stephan
- data manipulation - some math libraries - handling large file (yes you will not load 128 Gb file even in Java :) But so far I failed :) On Sun, Apr 30, 2017 at 7:33 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I tried to convince alex to focus on the missing pieces around roassal:
On Sun, Apr 30, 2017 at 6:03 PM, volkert <volkert@nivoba.de> wrote:
+1
i think the development of pharo should more focus on an "easy to use and adaptive live data analysis environment" which supports data science tasks with easy to use data retrieving, data preparation, data exploration, data modelling, scripting capabilities. We already have so many pieces and knowledge for this kind of platform around. I think only the cool story is missing .. And yes i know Moose, but i have the feeling this environment is not Moose. For me Moose is to much associated with software analysis ...
Volkert
Am 30.04.2017 um 17:06 schrieb Stephan Eggermont:
On 29/04/17 04:11, askoh wrote:
Being connected to the internet is going to be a necessity for any piece of software in the immediate future. So every Smalltalk development environment or application should have that capability as default. To push that envelop, every image should have a Smalltalk native Internet Browser.
Web is a very bad platform from an engineering point of view. The amount of accidental complexity is astounding, as is the number of useless layers obfuscating this all. I don't think we are ready to waste the amount of engineering needed to do something useful at the browser implementation side of the web (except for things like amber, pharojs and squeakjs).
Stephan
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)
On Apr 28, 2017, at 7:11 PM, askoh <askoh@askoh.com> wrote:
Being connected to the internet is going to be a necessity for any piece of software in the immediate future. So every Smalltalk development environment or application should have that capability as default. To push that envelop, every image should have a Smalltalk native Internet Browser. By developing that Internet Browser, we are demonstrating the power of Smalltalk. There is no reason why Smalltalk cannot be as intimate to the World Wide Web as Javascript. We can have the IDE in Smalltalk, Internet Browser in Smalltalk and a WWW language in Smalltalk. As is uniquely Smalltalk, every bit of code is visible, modifiable and debuggable. This supped up environment will grow and grow to be a full OS.
How can we gather the relevant Smalltalk code and necessary plugins to make an Internet Browser? I remember Croquet had internet browser and video player. What is missing?
All the best, Aik-Siong Koh
-- View this message in context: http://forum.world.st/Smalltalk-Internet-Browser-tp4944879.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
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.
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 craig@blackpagedigital.com +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
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 Craig Latta wrote
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
craig@
+31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
-- View this message in context: http://forum.world.st/Smalltalk-Internet-Browser-tp4944879p4945093.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
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 craig@blackpagedigital.com +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
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.
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.
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 craig@blackpagedigital.com +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"?
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 craig@blackpagedigital.com +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
On 4 May 2017 at 08:55, askoh <askoh@askoh.com> 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.
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. 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.
frank is it a browser plugin? On Thu, May 4, 2017 at 10:31 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
On 4 May 2017 at 08:55, askoh <askoh@askoh.com> 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.
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. 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/Smalltal k-Internet-Browser-tp4944879p4945606.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
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. Phil On Sun, Apr 30, 2017 at 10:37 PM, askoh <askoh@askoh.com> 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.
And the WebDriver protocol doesn't seem that intractable. https://www.w3.org/TR/webdriver/ On Tue, May 2, 2017 at 8:28 PM, phil@highoctane.be <phil@highoctane.be> 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.
Phil
On Sun, Apr 30, 2017 at 10:37 PM, askoh <askoh@askoh.com> 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/Smalltal k-Internet-Browser-tp4944879p4944998.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 5/2/17, phil@highoctane.be <phil@highoctane.be> 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 <askoh@askoh.com> 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 <hannes.hirzel@gmail.com> wrote:
On 5/2/17, phil@highoctane.be <phil@highoctane.be> 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.
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. Phil
--Hannes
Phil
On Sun, Apr 30, 2017 at 10:37 PM, askoh <askoh@askoh.com> 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 5/2/17, phil@highoctane.be <phil@highoctane.be> wrote:
On Tue, May 2, 2017 at 8:45 PM, H. Hirzel <hannes.hirzel@gmail.com> wrote:
On 5/2/17, phil@highoctane.be <phil@highoctane.be> 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 <askoh@askoh.com> 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 29 April 2017 at 03:11, askoh <askoh@askoh.com> wrote:
Being connected to the internet is going to be a necessity for any piece of software in the immediate future. So every Smalltalk development environment or application should have that capability as default. To push that envelop, every image should have a Smalltalk native Internet Browser. By developing that Internet Browser, we are demonstrating the power of Smalltalk. There is no reason why Smalltalk cannot be as intimate to the World Wide Web as Javascript. We can have the IDE in Smalltalk, Internet Browser in Smalltalk and a WWW language in Smalltalk. As is uniquely Smalltalk, every bit of code is visible, modifiable and debuggable. This supped up environment will grow and grow to be a full OS.
How can we gather the relevant Smalltalk code and necessary plugins to make an Internet Browser? I remember Croquet had internet browser and video player. What is missing?
All the best, Aik-Siong Koh
-- View this message in context: http://forum.world.st/Smalltal k-Internet-Browser-tp4944879.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I think the OP is speaking along these lines - other apparently smaller teams seem to have accomplished something like that: https://github.com/luakit/luakit https://github.com/felipedaragon/sandcat -- Frank Church ======================= http://devblog.brahmancreations.com
participants (15)
-
askoh -
Craig Latta -
Denis Kudriashov -
Dimitris Chloupis -
Eliot Miranda -
Frank Shearar -
H. Hirzel -
nacho -
Nicolas Cellier -
phil＠highoctane.be -
raffaello.giulietti＠lifeware.ch -
Stephan Eggermont -
Stephane Ducasse -
vfclists . -
volkert