- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Spec MenuModel not working

by Nicolai Hess

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 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 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. 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>: > > 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] running MS Surface Pro 3 - test failures

by Alexandre Bergel

If you run a test, what do you get? For example, the error? Alexandre > On Dec 19, 2014, at 8:54 PM, sheridan(a)sheridan-mahoney.com wrote: > > 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<Capture.PNG> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 19, 2014

running MS Surface Pro 3 - test failures

by sheridan＠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. 19, 2014

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

by Hilaire

Thanks Hilaire Le 19/12/2014 10:47, Torsten Bergmann a Ã©crit : > Need an easy way to convert HTML into PDF for printing? The project > http://wkhtmltopdf.org can help you here. -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Dec. 19, 2014

Re: [Pharo-dev] ToolRegistry need to support multiple registrations per tool

by Henrik Johansen

There used to be a class called AppRegistry in Pharo, which was nothing more than a selection in a list, with an API's for adding/removing options and changing the current selection. (only through popups, but that could easily be extended to provide settings entries). The code might've needed a bit of cleanup (making collection of available options weak, for example), but the concept was sound. IMHO, rather than the delegation through ToolRegistry, it would've been nice to have built upon AppRegistry and have Inspector/Browser/Debugger as subclasses of that. Then you'd still maintain indirection of which ToolX are available / currently in use, and code would be nice and understandable like: ToolX open instead of ToolRegistry openToolX. When new tools classifications are added, you'd also avoid progressively extending ToolRegistry into a behemoth of #openToolX etc. methods (ref. UIManager). Sadly, SoundService was the only real App classification in use, and the code seems to have been removed in 4.0. Cheers, Henry > On 19 Dec 2014, at 2:08 , Nicolai Hess <nicolaihess(a)web.de> wrote: > > Issue > 10529 <https://pharo.fogbugz.com/default.asp?10529> > ToolRegistry need to support multiple registrations per tool > > My solution : > A ToolRegistry subclass (PharoCommonTools) that memorized all registered tools. > And, for some common tools, like browser, debugger, inspector, workspace, > it provides settings entry to reset the registration to a prior tool. > > What do you think? > > (maybe a subclass of ToolRegistry isn't need and we can merge this. > And I don't like to "hardcode" the tools support for inspector, debugger, ..., > but I don't know how we can add the settings interface without proper names, > maybe someone knows a more "generic" way to add the settings for every > key that is/was used for a tool registration ) > > > nicolai > > >

Dec. 19, 2014