December 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Cog in the cloud

by Sven Van Caekenberghe

> On 20 Dec 2014, at 10:00, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > This has been done before for Erlang: > > http://erlangonxen.org > > They can boot in 100ms, even per request. Like this http://zerg.erlangonxen.org Pretty impressive. >> On 20 Dec 2014, at 09:52, stepharo <stepharo(a)free.fr> wrote: >> >> I love this idea :) >> >> Le 20/12/14 05:08, Ben Coman a Ã©crit : >>> >>> Just some thoughts that arose as I skipped along the web... >>> >>> With the idea of using Pharo in the cloud, I was thinking of how PharoNOS[1] is basing off top of the Linux kernel, but the examples indicate its operating in User Mode. So I was wondering about performance being greater[2] if the CogVM ran in Kernel Mode. However maybe this could get tangled in the GPL license of the kernel. >>> >>> Now I believe FreeBSD/NetBSD license is compatible with COG's MIT license, so that seems a better option for eliminating layers of the operating system. They both[3][4] have pre-built Amazon Machine Images to run on EC2, as well as instructions[5] to build your own AMI. So potentially we could build an AMI with the CogVM linked to the FreeBSDKernel operating in Kernel Mode, with no User Mode. The lack of direct access to memory from the Image, and probably single application focus should be sufficient security to forgo User Mode, and run faster. >>> >>> But we could go a step further. Runing in the cloud relies heavily on virtualisation, and for performance[6], most likely on the OS's paravirtualisation interface - to Xen for example. So from Cog, why not interface direct to the Xen FrontEndDriver[7] and eliminate the DomU operating system all together. What I understand from [6] is that Xen's paravirtualisation hooks makes it much easier to boot, than booting on the bare metal of a fully-virtualised system. So the former seems more achievable than the latter (which was the only option in years past), and also be more portable as technology evolves, to any platform Xen runs on. >>> >>> Squeak/Pharo on Cog-Xen could be a good choice for a Cloud Operating System[8]. Maybe a good student research project? >>> >>> cheers -ben >>> >>> [1] http://pillarhub.pharocloud.com/hub/mikefilonov/pharonos >>> [2] http://blog.codinghorror.com/understanding-user-and-kernel-mode/ >>> [3] http://www.daemonology.net/freebsd-on-ec2/ >>> [4] http://wiki.netbsd.org/amazon_ec2/amis/ >>> [5] http://wiki.netbsd.org/amazon_ec2/build_your_own_ami/ >>> [6] http://wiki.xen.org/wiki/Virtualization_Spectrum >>> [7] http://wiki.xen.org/wiki/FrontendDriver >>> [8] http://wiki.xen.org/wiki/Cloud_Operating_Systems >>> >>> >>> >> >> >

Dec. 20, 2014

Re: [Pharo-dev] NativeBoost libraries hosting

by Ben Coman

Esteban Lorenzano wrote: > I donât think so. > We cannot pollute pharo file server with specific libraries :( > > we could in the future set up a service for that, but then we will need > to take into account licenses, etc. > my recommendation is that you do not include the library but > instructions on where they can download/build the proper libraries. > > Esteban > >> On 19 Dec 2014, at 12:24, Blondeau Vincent >> <vincent.blondeau(a)worldline.com >> <mailto:vincent.blondeau@worldline.com>> wrote: >> >> Hi, >> >> Some of us are developing some applications by using NativeBoost, >> which is a great tool for Pharo. >> But when we want to distribute our application, we have to give the >> libraries with it. >> We can integrate the library in the package, give a link to download >> an application and copy the libraries near the Pharo VM, or put it on >> dropbox, but it seems that are not good solutions. >> >> Maybe we should have a hosting platform for these libraries? >> Does http://smalltalkhub.com >> <http://smalltalkhub.com/> or http://files.pharo.org/ can do the hosting? >> >> Cheers, >> >> Vincent This is an interesting question I might have to deal with some time, so I had a look around for options. (As an aside, I came across this interesting article "How I moved my websites to DropBox and Github"... http://alexcican.com/post/guide-hosting-website-dropbox-github/ ) That makes me wonder what is wrong with using dropbox? You might use it with a custom domain name so that later you can move services transparently to users. http://hostlater.com/2014/04/dropbox-custom-domain-name-url-2246/ Github recommends using either "Releases" or Amazon S3 & CloudFront. Indeed it seems that "Releases" itself is built on top of CloudFront. https://help.github.com/articles/distributing-large-binaries/ https://github.com/blog/1547-release-your-software I followed this instruction as a trial... https://help.github.com/articles/creating-releases/ and found it quite straightforward - see... https://github.com/bencoman/Hello-World/releases (I just used a jpg as an example) cheers -ben

Dec. 20, 2014

Re: [Pharo-dev] [ANN] WKHTML2PDF for Pharo

by Torsten Bergmann

>Very interesting (especially for when we do have lots of tables and colors, which I do happen to have a lot :-) ). Yes, combined with Mustache for templates it is a nice reporting solution. Â >Now, is it working on Linux? Havent tried, but should be possible out of the box Bye T.

Dec. 20, 2014

Re: [Pharo-dev] spotter on global vars

by Nicolai Hess

Then, I will wait until it moved to pharo 4. Am 19.12.2014 12:24 schrieb "Marcus Denker" <marcus.denker(a)inria.fr>: > > > On 19 Dec 2014, at 12:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > That one only exists in Pharo 4. > > > > Yesâ¦ GT needs to move to Pharo4 or this will all be very boring soon. > > Marcus

Dec. 20, 2014

Re: [Pharo-dev] running MS Surface Pro 3 - test failures

by Nicolai Hess

The 2 errors happens on Windows 7 too. There is a bug entry. Am 19.12.2014 20:54 schrieb <sheridan(a)sheridan-mahoney.com>: > Hi all, > > I ran test case coverage using my MS Surface Pro 3 with the following > specs: > Processor: Intel(R)Core(TM) i5-4300U CPU @ 1.90 GHz 2.50 GHz > Installed RAM : 8 GB > System type: 64-bit operating system, x64-based processor > Windows Edition: Windows 8.1 Pro > > I recieved 11 test failures and 2 errors. > > Here's a snip attached of the failing tests. I hope it makes it through... > Otherwise I'll resend with the info. > > I was wondering if each failing test requires a bug report, or is this not > a supported machine? > > Cheers, > Sheridan

Dec. 20, 2014

Re: [Pharo-dev] Cog in the cloud

by Sven Van Caekenberghe

This has been done before for Erlang: http://erlangonxen.org They can boot in 100ms, even per request. > On 20 Dec 2014, at 09:52, stepharo <stepharo(a)free.fr> wrote: > > I love this idea :) > > Le 20/12/14 05:08, Ben Coman a Ã©crit : >> >> Just some thoughts that arose as I skipped along the web... >> >> With the idea of using Pharo in the cloud, I was thinking of how PharoNOS[1] is basing off top of the Linux kernel, but the examples indicate its operating in User Mode. So I was wondering about performance being greater[2] if the CogVM ran in Kernel Mode. However maybe this could get tangled in the GPL license of the kernel. >> >> Now I believe FreeBSD/NetBSD license is compatible with COG's MIT license, so that seems a better option for eliminating layers of the operating system. They both[3][4] have pre-built Amazon Machine Images to run on EC2, as well as instructions[5] to build your own AMI. So potentially we could build an AMI with the CogVM linked to the FreeBSDKernel operating in Kernel Mode, with no User Mode. The lack of direct access to memory from the Image, and probably single application focus should be sufficient security to forgo User Mode, and run faster. >> >> But we could go a step further. Runing in the cloud relies heavily on virtualisation, and for performance[6], most likely on the OS's paravirtualisation interface - to Xen for example. So from Cog, why not interface direct to the Xen FrontEndDriver[7] and eliminate the DomU operating system all together. What I understand from [6] is that Xen's paravirtualisation hooks makes it much easier to boot, than booting on the bare metal of a fully-virtualised system. So the former seems more achievable than the latter (which was the only option in years past), and also be more portable as technology evolves, to any platform Xen runs on. >> >> Squeak/Pharo on Cog-Xen could be a good choice for a Cloud Operating System[8]. Maybe a good student research project? >> >> cheers -ben >> >> [1] http://pillarhub.pharocloud.com/hub/mikefilonov/pharonos >> [2] http://blog.codinghorror.com/understanding-user-and-kernel-mode/ >> [3] http://www.daemonology.net/freebsd-on-ec2/ >> [4] http://wiki.netbsd.org/amazon_ec2/amis/ >> [5] http://wiki.netbsd.org/amazon_ec2/build_your_own_ami/ >> [6] http://wiki.xen.org/wiki/Virtualization_Spectrum >> [7] http://wiki.xen.org/wiki/FrontendDriver >> [8] http://wiki.xen.org/wiki/Cloud_Operating_Systems >> >> >> > >

Dec. 20, 2014

Re: [Pharo-dev] Spec MenuModel not working

by stepharo

Hi nicolai could you publish your code somewhere? Le 20/12/14 01:32, Nicolai Hess a Ã©crit : > Stef refactored all dockingbar related things out of MenuMorph into > DockingBarMenuMorph, the > problem is, spec does not distinguish between > - create a popup menu from a spec > - create a dockbar menu from a spec I do not remember the use of DockingBarMenuMorph (sigh... doing too mnay things). But is it needed? > > I tried to implement this by providing a new buildWithSpecAsMenu and > changed the > MorphicMenuAdapter to create a MenuMorph (for popup menus) and > DockingBarMenuMorph (for the other one). > > But it turns out I had to duplicate all the xPopup methods: > buildWidgetPopup - buildWidgetMenu > adaptAsPopup - adaptAsMenu > buildWithSpecAsPopup - buildWithSpecAsMenu May be we should push your change. > > and this doesn't look right to me. As MorphicMenuAdapter is the only > MorphicAdapter that > implements special adaptAsX method, all this (popup-)menu related > build/adapt methods looks like a hack. > But I am not sure. It is certainly a hack. Menu were not really thought. > > Maybe someone with more knowledge about spec internals can take a look > on this issue. > > > nicolai > > > 2014-12-14 21:15 GMT+01:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > So then this is probably my mistake. Now I will not have the time > to work on it before at least a week. > Too many other things to do that are not Pharo related. > > Stef > > Le 14/12/14 17:24, Peter UhnÃ¡k a Ã©crit : >> >> in which version of Pharo are you? >> I cleaned a lot menu in 40 so this is probably related. >> Do you have an example I could execute? >> >> >> Yes this happens on Pharo 4. >> >> Yes, Pharo 4 >> >> >> ApplicationWithToolbar new openWithSpec >> then, open the "File"-menu >> -> MenuMorph(Object)>>doesNotUnderstand: >> #activatedFromDockingBar: >> >> >

Dec. 20, 2014

Re: [Pharo-dev] Cog in the cloud

by stepharo

I love this idea :) Le 20/12/14 05:08, Ben Coman a Ã©crit : > > Just some thoughts that arose as I skipped along the web... > > With the idea of using Pharo in the cloud, I was thinking of how > PharoNOS[1] is basing off top of the Linux kernel, but the examples > indicate its operating in User Mode. So I was wondering about > performance being greater[2] if the CogVM ran in Kernel Mode. However > maybe this could get tangled in the GPL license of the kernel. > > Now I believe FreeBSD/NetBSD license is compatible with COG's MIT > license, so that seems a better option for eliminating layers of the > operating system. They both[3][4] have pre-built Amazon Machine > Images to run on EC2, as well as instructions[5] to build your own > AMI. So potentially we could build an AMI with the CogVM linked to > the FreeBSDKernel operating in Kernel Mode, with no User Mode. The > lack of direct access to memory from the Image, and probably single > application focus should be sufficient security to forgo User Mode, > and run faster. > > But we could go a step further. Runing in the cloud relies heavily on > virtualisation, and for performance[6], most likely on the OS's > paravirtualisation interface - to Xen for example. So from Cog, why > not interface direct to the Xen FrontEndDriver[7] and eliminate the > DomU operating system all together. What I understand from [6] is > that Xen's paravirtualisation hooks makes it much easier to boot, than > booting on the bare metal of a fully-virtualised system. So the former > seems more achievable than the latter (which was the only option in > years past), and also be more portable as technology evolves, to any > platform Xen runs on. > > Squeak/Pharo on Cog-Xen could be a good choice for a Cloud Operating > System[8]. Maybe a good student research project? > > cheers -ben > > [1] http://pillarhub.pharocloud.com/hub/mikefilonov/pharonos > [2] http://blog.codinghorror.com/understanding-user-and-kernel-mode/ > [3] http://www.daemonology.net/freebsd-on-ec2/ > [4] http://wiki.netbsd.org/amazon_ec2/amis/ > [5] http://wiki.netbsd.org/amazon_ec2/build_your_own_ami/ > [6] http://wiki.xen.org/wiki/Virtualization_Spectrum > [7] http://wiki.xen.org/wiki/FrontendDriver > [8] http://wiki.xen.org/wiki/Cloud_Operating_Systems > > >

Dec. 20, 2014

Cog in the cloud

by Ben Coman

Just some thoughts that arose as I skipped along the web... With the idea of using Pharo in the cloud, I was thinking of how PharoNOS[1] is basing off top of the Linux kernel, but the examples indicate its operating in User Mode. So I was wondering about performance being greater[2] if the CogVM ran in Kernel Mode. However maybe this could get tangled in the GPL license of the kernel. Now I believe FreeBSD/NetBSD license is compatible with COG's MIT license, so that seems a better option for eliminating layers of the operating system. They both[3][4] have pre-built Amazon Machine Images to run on EC2, as well as instructions[5] to build your own AMI. So potentially we could build an AMI with the CogVM linked to the FreeBSDKernel operating in Kernel Mode, with no User Mode. The lack of direct access to memory from the Image, and probably single application focus should be sufficient security to forgo User Mode, and run faster. But we could go a step further. Runing in the cloud relies heavily on virtualisation, and for performance[6], most likely on the OS's paravirtualisation interface - to Xen for example. So from Cog, why not interface direct to the Xen FrontEndDriver[7] and eliminate the DomU operating system all together. What I understand from [6] is that Xen's paravirtualisation hooks makes it much easier to boot, than booting on the bare metal of a fully-virtualised system. So the former seems more achievable than the latter (which was the only option in years past), and also be more portable as technology evolves, to any platform Xen runs on. Squeak/Pharo on Cog-Xen could be a good choice for a Cloud Operating System[8]. Maybe a good student research project? cheers -ben [1] http://pillarhub.pharocloud.com/hub/mikefilonov/pharonos [2] http://blog.codinghorror.com/understanding-user-and-kernel-mode/ [3] http://www.daemonology.net/freebsd-on-ec2/ [4] http://wiki.netbsd.org/amazon_ec2/amis/ [5] http://wiki.netbsd.org/amazon_ec2/build_your_own_ami/ [6] http://wiki.xen.org/wiki/Virtualization_Spectrum [7] http://wiki.xen.org/wiki/FrontendDriver [8] http://wiki.xen.org/wiki/Cloud_Operating_Systems

Dec. 20, 2014

Re: [Pharo-dev] NativeBoost libraries hosting

by HernÃ¡n Morales Durand

Hi Esteban, 2014-12-19 8:31 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > I donât think so. > We cannot pollute pharo file server with specific libraries :( > > I know you have some concern, but I ask you for reconsider because R has many users and the whole download size of required .dll is actually a 2Mb zip. > we could in the future set up a service for that, but then we will need to > take into account licenses, etc. > my recommendation is that you do not include the library but instructions > on where they can download/build the proper libraries. > The problem is some of us cannot waste time manually downloading libraries for each build :( Torsten said that GitHub could be an option, I didn't knew it could host binary files. HernÃ¡n > > Esteban > > On 19 Dec 2014, at 12:24, Blondeau Vincent <vincent.blondeau(a)worldline.com> > wrote: > > Hi, > > Some of us are developing some applications by using NativeBoost, which is > a great tool for Pharo. > But when we want to distribute our application, we have to give the > libraries with it. > We can integrate the library in the package, give a link to download an > application and copy the libraries near the Pharo VM, or put it on dropbox, > but it seems that are not good solutions. > > Maybe we should have a hosting platform for these libraries? > Does http://smalltalkhub.com or http://files.pharo.org/ can do the > hosting? > > Cheers, > > Vincent > > > ------------------------------ > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. > > >

Dec. 20, 2014