August 2016 - Pharo-users - lists.pharo.org

[ann] Lam Research evaluates Pharo

by Tudor Girba

Hi, We are very happy to make the following announcement: Lam Research, a leading supplier of wafer fabrication equipment and services to the global semiconductor industry, is an experienced user of the Smalltalk programming language. Smalltalk is a key component in Lam's software control system for a broad range of the equipment it manufactures. Tudor Girba is a leading member of the tools and environment development effort in Pharo, having architected the Glamorous Toolkit for live programming. Eliot Miranda is author of the Cog virtual machine that underlies Pharo and other Smalltalk dialects. Lam has engaged Tudor and Eliot to explore potential enhancements in Lam's use of Smalltalk. These enhancements range from running highly optimized Smalltalk on low cost, single board computers, to enhancing Lam's Smalltalk development practices with state-of-the-art live programming. During the engagement, Tudor and Eliot successfully moved a key communication component of the control system to Pharo. It was a challenging task aimed at extending the reach of Lamâs system to the Pharo world including the option of executing on ARM processors. Cheers, Tudor Girba, Eliot Miranda and Chris Thorgrimsson

Aug. 25, 2016

[ann] GTExamples alpha

by Tudor Girba

Hi, Over the last coupe of years Stefan Reichhart and the rest of the GT team worked on an implementation of examples. The work is inspired from previous work done by Markus Gaelli and Adrian Kuhn. As one of the goals of GT is to offer a live programming environment, one important issue is how to move from the static code to live objects as fast as possible. That is why we worked on this library as a solution to provide a link between the static code and live objects. Furthermore, this examples library also enables the definition of assertions on the examples, and this provides the possibility of rethinking the way we construct tests throughout our system. Tests are great as they help us create live objects and then to assert live properties. However, they do not allow us to leverage the objects we create, and this can be a tremendous resource for understanding systems. In our vision, examples should be everywhere and they should be explicitly linked to the static code they exemplify. That is why the library comes with an initial integration in existing tools (such as Nautilus, Spotter, Inspector). The current solution works well and it is the result of several rewrites. We think that the solution is complete in terms of features, but there are still several things to improve and iterate on. To this end, I kindly ask you to take a look at it while distinguishing between the concrete implementation choice (e.g., the current extensive use of pragmas) and the conceptual benefits of the approach. To ease the discussion, we put together a short documentation: http://gtoolkit.org/doc/Examples/examples.html That being said, you can get it with the full GToolkit in Pharo 6.0: http://gtoolkit.org/#install (easiest is to download the ready made image for now) For those that are at ESUG, I will try to provide a short overview during the Show Us Your Project session from today. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."

Aug. 25, 2016

Re: [Pharo-users] [Pharo-dev] websockets in pharo?

by Guillaume Larcheveque

Yes and it works very well!! (I'm using it for Telescope) There is a chapter in the pharo for enterprise book about websockets 2016-08-24 14:28 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Zinc-WebSocket-* packages in the repository http://mc.stfx.eu/ > ZincHTTPComponents > > -- Pavel > > 2016-08-24 14:20 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> Can anyone tell me if there is a Websocket implementation for Pharo? >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "From an abstract enough point of view, any two things are similar." >> >> >> >> >> >> > -- *Guillaume Larcheveque*

Aug. 24, 2016

Re: [Pharo-users] [Pharo-dev] websockets in pharo?

by Pavel Krivanek

Zinc-WebSocket-* packages in the repository http://mc.stfx.eu/ZincHTTPComponents -- Pavel 2016-08-24 14:20 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > Can anyone tell me if there is a Websocket implementation for Pharo? > > Cheers, > Doru > > -- > www.tudorgirba.com > www.feenk.com > > "From an abstract enough point of view, any two things are similar." > > > > > >

Aug. 24, 2016

websockets in pharo?

by Tudor Girba

Hi, Can anyone tell me if there is a Websocket implementation for Pharo? Cheers, Doru -- www.tudorgirba.com www.feenk.com "From an abstract enough point of view, any two things are similar."

Aug. 24, 2016

Re: [Pharo-users] standalone/runtime executable

by stepharo

> <<Pharo has the easiest deployment in any language I have used.>> > > Only if you think deployment means shipping your entire development > environment to users and telling them to get on with it. > > Pharo is absolutely the worst language for deployment in the world. This is > why, after all these years, there have only ever been three desktop > applications written in it - phratch, dr geo, and the a legal database > thing. (i suppose you could be generous and include pharo launcher as well - > though that's a bit incestuous). We are concerned with that aspect. This is not by accident that Guillermo spent 3 years working on bootstrapping a kernel. This is not by accident that Pavel is producing small images. This is not by accident that we want to manage the ***Complete*** image and eco systems with dependencies and that we are fighting with cycles and layers. This is not by accident that we are revisiting all the places that write on disc believing that they can. Now we should probably invest in a solution like the one of Hernan to build application wrapper I think that also having a better abstraction for user deployment is needed. Right now we are working on a bootstrap in production for multiple reason but the main one is to get a clean 'small' kernel so that we can build using normal dependency small applications. If you think that we are going slowly. We are getting slowly and too slow for my taste. I did you analysis back in 2002 :) Now if you want to help us going faster. Help the community fixing bugs. The less other things we have to do the more we can focus. Stef > > All other applications written in pharo are web apps so deployment is not an > issue. > > There may be good reasons for the lack of attention paid to the deployment > of apps but pretending there is no problem is crazy. > > > > > -- > View this message in context: http://forum.world.st/standalone-runtime-executable-tp4911677p4912370.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Aug. 24, 2016

Re: [Pharo-users] Google building new OS with Dart

by askoh

Kilon: Thanks for your input. That is indeed brainstorming. I know the importance of doing too. But the value of brainstorming is big. A farmer does a lot of work but is not valued much. Watson and Crick brainstormed a lot and discovered the double helix. I don't want Smalltalk to miss that power. Your description of your work and the work of other Smalltalkers shows the amount of work already done. I too have done CAD and Motion Simulation work using VisualWorks, C#, SpaceClaim, Inventor. But there is no killer app or killer use case in all of Smalltalk! How did Python's and Ruby's popularity leapfrog Smalltalk's? How can we get some attention so that we have resources to really grow? China have been widely accused of copying. But I noticed that they have also picked up discarded technologies that are excellent technologies. Examples are solar cells, wind turbines, high speed rail, nuclear power, Alpha chip, MIPS chip, manufacturing, Kylin OS, etc. Perhaps we can make some nation see Smalltalk for the great technology it has for programming productivity. Brainstorming is free speech at its best. Please everyone join. Aik-Siong Koh -- View this message in context: http://forum.world.st/Google-building-new-OS-with-Dart-tp4911649p4912398.ht… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 24, 2016

Re: [Pharo-users] standalone/runtime executable

by HernÃ¡n Morales Durand

2016-08-23 16:26 GMT-03:00 kmo <voxkmp(a)gmail.com>: > <<Pharo has the easiest deployment in any language I have used.>> > > Only if you think deployment means shipping your entire development > environment to users and telling them to get on with it. > > Pharo is absolutely the worst language for deployment in the world. This is > why, after all these years, there have only ever been three desktop > applications written in it - phratch, dr geo, and the a legal database > thing. (i suppose you could be generous and include pharo launcher as well > - > though that's a bit incestuous). > > You forgot to mention PhyloclassTalk which also includes a Windows Installer written in Unicode NSIS. I have two generators for this: A code generator written in Pharo to generate the NSIS script, and an image builder batch script which downloads image from ZeroConf, loads everything through Metacello, and launches NSIS to generate the executable file. I probably do the same for CPack, but now I am busy finishing a paper. You were right in part, deployment in Pharo is not easy and other fashion industry languages perform better, but it is not impossible. > All other applications written in pharo are web apps so deployment is not > an > issue. > > There may be good reasons for the lack of attention paid to the deployment > of apps but pretending there is no problem is crazy. > > I agree with you on this one. We (Smalltalkers) need mountains of self-criticism and slow reading. HernÃ¡n

Aug. 24, 2016

Re: [Pharo-users] standalone/runtime executable

by Dimitris Chloupis

Correction: Actually I was wrong, you dont even need to delete shortcuts to make the IDE completely inaccessible to user. The moment you create the morph that covers the Pharo window, that morph can also receive all events which means no Pharo shortcuts will be able to trigger unless of course you make the morph to return the events back to the object that can trigger the IDE tools. And what I am describing here is not some advanced concept this is super basic Pharo development. No magic, nothing special. On Tue, Aug 23, 2016 at 11:31 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > "Only if you think deployment means shipping your entire development > environment to users and telling them to get on with it." > > No > > Including the Pharo enviroment is a great idea because it makes remote > debugging a possibility. Pharo has tools to connect to another running > image and control its execution and debugging capabilites which give you > the massive advantage of being able to examine bugs up close and personal > without the need of the user filling bug reports. You can do this online > and offline. Thats the appeal of Pharo anyway. You user can message you > and you can connect to his image , fix the error and allow him to continue > execution without losing his live data. Try that with you dream deployment > tool. > > Actually its standard practice in deployment when something goes wrong you > are basically screwed. Fine grained error correction is not even a question > , just stone age uninstall and re install. > > Hiding the IDE from the user is very simple. > > I fail to see how Pharo is worse from pretty much every other language > that requires installation in order to work when Pharo is just a standalone > folder. > > We must be living in parallel universes. > > "All other applications written in pharo are web apps so deployment is not > an > issue." > > Why you think thats a problem for dekstop apps ? Its actually pretty > simple, pharo allows you to create a window or a frame that covers its > entire window the moment this happens the user will no longer be able to > trigger the world menu, unless he uses shortcuts which can be removed too. > > This is the approach that PharoLauncher, Phratch and DrGeo follow. > > The debugger will still trigger in case of error but then you will need a > form of error reporting anyway, unless you prefer your pharo app freezing > with no error message which obviously is not the standard practice in any > dynamic programming language. Sure if you come from C/C++ crash and burn > maybe acceptable but is not acceptable for Pharo standards. I suspect it > wont be very acceptable for your user either. > > "There may be good reasons for the lack of attention paid to the deployment > of apps but pretending there is no problem is crazy." > > We read question like this from time to time in the mailing list from > beginners but for experienced pharo coder I never read any serious > complain. > > "Also, it gives people with more limited bandwidth connections the options > of downloading the entire thing, or a highly stripped version that is much > smaller." > > There are plans to modularize pharo image , there is even an image that > offers a minimal set of libraries though its not recommended for general > consumption. It can be used as template if size is such a big concern. > > There is also project Spoon that managed to deploy Squeak (Pharo's > ancestor) apps that were down to kbs in size. But smaller you go the more > power and flexibility you sacrifice. Suffice to say devs did not care so > much about Spoon. > > Size wise zipped Pharo folder is 30mbs , probably even less if you use > 7zip or some other more efficient compression. My connection is > 100-200kbs/sec which means it does not take more than 3-4 minutes to > download. So I fail to see where is the actual problem. > > Yeah sure if you are on dial up it will take you forever but then the > whole internet will take you forever anyway. People play games that are > tens of Gigabytes in size of download and they don't complain about size. > > This whole get the IDE together with the app is no longer a Smalltalk > breakthrough anyway. > > Python the language I was coding in before porting to Pharo comes with a > ton of tools that range from inspectors, debugger, live refactoring tools > and even profilers , error reporting tools, testing tools or even > manipulation of the syntax itself through the AST module. And this is > common for most if not every dynamic language out there. > > Even games nowadays ship with their own error reporting tools, profilers, > anylitics, benchmark tools etc. and of course the usual modding tools. > > > On Tue, Aug 23, 2016 at 10:28 PM kmo <voxkmp(a)gmail.com> wrote: > >> <<Pharo has the easiest deployment in any language I have used.>> >> >> Only if you think deployment means shipping your entire development >> environment to users and telling them to get on with it. >> >> Pharo is absolutely the worst language for deployment in the world. This >> is >> why, after all these years, there have only ever been three desktop >> applications written in it - phratch, dr geo, and the a legal database >> thing. (i suppose you could be generous and include pharo launcher as >> well - >> though that's a bit incestuous). >> >> All other applications written in pharo are web apps so deployment is not >> an >> issue. >> >> There may be good reasons for the lack of attention paid to the deployment >> of apps but pretending there is no problem is crazy. >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/standalone-runtime-executable-tp4911677p4912370.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >>

Aug. 23, 2016

Re: [Pharo-users] standalone/runtime executable

by Dimitris Chloupis

"Only if you think deployment means shipping your entire development environment to users and telling them to get on with it." No Including the Pharo enviroment is a great idea because it makes remote debugging a possibility. Pharo has tools to connect to another running image and control its execution and debugging capabilites which give you the massive advantage of being able to examine bugs up close and personal without the need of the user filling bug reports. You can do this online and offline. Thats the appeal of Pharo anyway. You user can message you and you can connect to his image , fix the error and allow him to continue execution without losing his live data. Try that with you dream deployment tool. Actually its standard practice in deployment when something goes wrong you are basically screwed. Fine grained error correction is not even a question , just stone age uninstall and re install. Hiding the IDE from the user is very simple. I fail to see how Pharo is worse from pretty much every other language that requires installation in order to work when Pharo is just a standalone folder. We must be living in parallel universes. "All other applications written in pharo are web apps so deployment is not an issue." Why you think thats a problem for dekstop apps ? Its actually pretty simple, pharo allows you to create a window or a frame that covers its entire window the moment this happens the user will no longer be able to trigger the world menu, unless he uses shortcuts which can be removed too. This is the approach that PharoLauncher, Phratch and DrGeo follow. The debugger will still trigger in case of error but then you will need a form of error reporting anyway, unless you prefer your pharo app freezing with no error message which obviously is not the standard practice in any dynamic programming language. Sure if you come from C/C++ crash and burn maybe acceptable but is not acceptable for Pharo standards. I suspect it wont be very acceptable for your user either. "There may be good reasons for the lack of attention paid to the deployment of apps but pretending there is no problem is crazy." We read question like this from time to time in the mailing list from beginners but for experienced pharo coder I never read any serious complain. "Also, it gives people with more limited bandwidth connections the options of downloading the entire thing, or a highly stripped version that is much smaller." There are plans to modularize pharo image , there is even an image that offers a minimal set of libraries though its not recommended for general consumption. It can be used as template if size is such a big concern. There is also project Spoon that managed to deploy Squeak (Pharo's ancestor) apps that were down to kbs in size. But smaller you go the more power and flexibility you sacrifice. Suffice to say devs did not care so much about Spoon. Size wise zipped Pharo folder is 30mbs , probably even less if you use 7zip or some other more efficient compression. My connection is 100-200kbs/sec which means it does not take more than 3-4 minutes to download. So I fail to see where is the actual problem. Yeah sure if you are on dial up it will take you forever but then the whole internet will take you forever anyway. People play games that are tens of Gigabytes in size of download and they don't complain about size. This whole get the IDE together with the app is no longer a Smalltalk breakthrough anyway. Python the language I was coding in before porting to Pharo comes with a ton of tools that range from inspectors, debugger, live refactoring tools and even profilers , error reporting tools, testing tools or even manipulation of the syntax itself through the AST module. And this is common for most if not every dynamic language out there. Even games nowadays ship with their own error reporting tools, profilers, anylitics, benchmark tools etc. and of course the usual modding tools. On Tue, Aug 23, 2016 at 10:28 PM kmo <voxkmp(a)gmail.com> wrote: > <<Pharo has the easiest deployment in any language I have used.>> > > Only if you think deployment means shipping your entire development > environment to users and telling them to get on with it. > > Pharo is absolutely the worst language for deployment in the world. This is > why, after all these years, there have only ever been three desktop > applications written in it - phratch, dr geo, and the a legal database > thing. (i suppose you could be generous and include pharo launcher as well > - > though that's a bit incestuous). > > All other applications written in pharo are web apps so deployment is not > an > issue. > > There may be good reasons for the lack of attention paid to the deployment > of apps but pretending there is no problem is crazy. > > > > > -- > View this message in context: > http://forum.world.st/standalone-runtime-executable-tp4911677p4912370.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Aug. 23, 2016