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

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40420 Home: https://github.com/pharo-project/pharo-core

Dec. 22, 2014

[pharo-project/pharo-core] dca64b: 40420

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: dca64b2e8f2fbb76d3215b9f070ae02bdc0f9c84 https://github.com/pharo-project/pharo-core/commit/dca64b2e8f2fbb76d3215b9f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-12-22 (Mon, 22 Dec 2014) Changed paths: M Nautilus.package/Nautilus.class/class/opening/openInEnvironment_.st M Nautilus.package/Nautilus.class/class/opening/openOnClass_inEnvironment_.st M Nautilus.package/Nautilus.class/class/opening/openOnMethod_inEnvironment_.st M Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/buildPackageSearch.st A Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/class_matchPackagePatternString_.st A Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/createPackagePattern_.st M Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/packageMatchPattern_.st M Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/packagePattern.st M Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/packageSearchUpdate_.st A Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/package_matchPackagePattern_.st A Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/useLastPackagePatternString.st A Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/useLastPackagePatternStringForClass_.st A Nautilus.package/SharedPackageFilterPatternsHolder.class/README.md A Nautilus.package/SharedPackageFilterPatternsHolder.class/class/accessing/instance.st A Nautilus.package/SharedPackageFilterPatternsHolder.class/definition.st A Nautilus.package/SharedPackageFilterPatternsHolder.class/instance/accessing/at_.st A Nautilus.package/SharedPackageFilterPatternsHolder.class/instance/accessing/firstOrNil.st A Nautilus.package/SharedPackageFilterPatternsHolder.class/instance/accessing/indexOf_.st A Nautilus.package/SharedPackageFilterPatternsHolder.class/instance/accessing/lastValue.st A Nautilus.package/SharedPackageFilterPatternsHolder.class/instance/accessing/lastValue_.st A Nautilus.package/SharedPackageFilterPatternsHolder.class/instance/accessing/size.st A Nautilus.package/SharedPackageFilterPatternsHolder.class/instance/accessing/value.st A Nautilus.package/SharedPackageFilterPatternsHolder.class/instance/accessing/value_.st A Nautilus.package/SharedPackageFilterPatternsHolder.class/instance/adding/addFirst_.st A Nautilus.package/SharedPackageFilterPatternsHolder.class/instance/enumerating/collectWithIndex_.st A Nautilus.package/SharedPackageFilterPatternsHolder.class/instance/initialization/initialize.st A Nautilus.package/SharedPackageFilterPatternsHolder.class/instance/removing/remove_ifAbsent_.st R Nautilus.package/SharedValueHolder.class/README.md R Nautilus.package/SharedValueHolder.class/class/accessing/instance.st R Nautilus.package/SharedValueHolder.class/definition.st R Nautilus.package/SharedValueHolder.class/instance/accessing/at_.st R Nautilus.package/SharedValueHolder.class/instance/accessing/indexOf_.st R Nautilus.package/SharedValueHolder.class/instance/accessing/size.st R Nautilus.package/SharedValueHolder.class/instance/accessing/value.st R Nautilus.package/SharedValueHolder.class/instance/accessing/value_.st R Nautilus.package/SharedValueHolder.class/instance/adding/addFirst_.st R Nautilus.package/SharedValueHolder.class/instance/enumerating/collectWithIndex_.st R Nautilus.package/SharedValueHolder.class/instance/initialization/initialize.st R Nautilus.package/SharedValueHolder.class/instance/removing/remove_ifAbsent_.st M NautilusCommon.package/NautilusHistoryEntry.class/definition.st M NautilusCommon.package/NautilusHistoryEntry.class/instance/accessing/selectedMethod.st M NautilusCommon.package/NautilusHistoryEntry.class/instance/accessing/selectedMethod_.st A NautilusCommon.package/NautilusHistoryEntry.class/instance/accessing/selectedSelector.st A NautilusCommon.package/NautilusHistoryEntry.class/instance/accessing/selectedSelector_.st M NautilusCommon.package/NautilusHistoryEntry.class/instance/private/with_.st M NautilusCommon.package/NautilusHistoryEntry.class/instance/protocol/=.st M NautilusCommon.package/NautilusHistoryEntry.class/instance/protocol/applyTo_.st M NautilusCommon.package/NautilusHistoryEntry.class/instance/protocol/asHistoryString.st M NautilusCommon.package/NautilusHistoryEntry.class/instance/protocol/hash.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script420.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40420.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Shout.package/SHParserST80.class/instance/parse support/parsingBlockarguments.st Log Message: ----------- 40420 14634 Package Filter in Nautilus should use the last used filter when a new window is opened https://pharo.fogbugz.com/f/cases/14634 14620 Jump from history entry does not work https://pharo.fogbugz.com/f/cases/14620 14630 Pipes method highlighting https://pharo.fogbugz.com/f/cases/14630 http://files.pharo.org/image/40/40420.zip

Dec. 22, 2014

Re: [Pharo-dev] GSpotter fonts of evaluation results

by Tudor Girba

Good point. That is a theme issue but it should be fixed. Doru On Fri, Dec 19, 2014 at 9:46 AM, stepharo <stepharo(a)free.fr> wrote: > The fonts used by GSpotter to display results does not change when > changing size and > this should be fixed for demo for example. > > Stef > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 22, 2014

Re: [Pharo-dev] [Vm-dev] Re: Cog in the cloud

by Ben Coman

Ben Coman wrote: > > (whoops forgot to cross-post) > > Eliot Miranda wrote: >> Hi Ben, >> >> >> On Dec 19, 2014, at 8:08 PM, Ben Coman <btc(a)openInWorld.com> wrote: >> >>> 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? >> >> This sounds really cool, but could you analyse a bit further? >> >> - what key economic and managerial benefits accrue from this >> configuration? > > I'll put some more thought into this, but just off the top of my head > (so it turned out more technical than economic/managerial): > > * Eliminates performance overhead of system call context switching. > Although this is replaced by hypercalls, it removes one layer on > hypervisor systems, which plausibly is going to be EVERYTHING in the > future. > > * Eliminate performance overhead of OS networking stack > http://roscidus.com/blog/blog/2014/08/15/optimising-the-unikernel/ > > * Data from virtual devices is event driven. > > * More easily portable to different ARM platforms. Xen will present a > common interface to hide platform idiosyncrasies. > --> More widespread embedded use Cog. > http://www.slideshare.net/xen_com_mgr/free-rtos-xensummit > > * Run databases in their own domain. > > * Isolate plugin memory space. Rather than linking plugins into Cog, > potentially threatening its stability, run them in a separate domain and > use high-speed inter-domain shared memory. > http://www.cs.ucsb.edu/~nanli/projects/cs270.pdf > > * Have a cloud community of thousands** of Images running each in their > own domain, communicating with high-speed inter-domain shared memory. > ** presumptive figure - would need to check scaling ability > > * Data sharing on high density hosting providers. Not sure if its there > yet, but may get Copy-On-Write > http://www-archive.xenproject.org/files/xensummit_fall07/18_GregorMilos.pdf > > * In very large Images, which Spur will allow, perhaps a better way to > snapshot an Image is via virtual machine snapshotting using Copy-On. > http://www.cercs.gatech.edu/tech-reports/tr2010/git-cercs-10-05.pdf > > * Rather than convert the Cog/Image to be multi-threaded, could have > many grid nodes running their own domain, communicating with high speed > shared memory. > http://www.cs.ucsb.edu/~nanli/projects/cs270.pdf > http://osnet.cs.binghamton.edu/publications/hines07memx.pdf > > * AMD's hardware virtualisation eliminated a Ring and also segmented > memory protection used by virtualisation to separate address spaces, so > 64-bit AMD can be slower. Eliminating the OS kernel layer probably > bypasses this limitation since there would be only two levels - > Hypervisor & Cog. > https://lse.epita.fr/data/2011-lse-summer-week/xen.pdf > > * Its where all the cool kids hang out --> marketing opportunity > * Security versus lines of code... Linux = 15.9 million (3.6 Kernel) OSX = 86 million FreeBSD = 6.25 million OpenSolaris = 10 million Windows = 64 million Xen-ARM = 90,000 Xen-x86 = 140,000 https://www.google.com/fusiontables/DataSource?docid=12Eg7Ru1CH5MIjomcfjaGK… http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions_whitepaper > > >> >> - what infrastructure is missing? (e.g. what key drivers need >> implementing?) > > I'll need to understand Cog more. As a start, here are some porting and > API docs... > > http://events.linuxfoundation.org/sites/events/files/slides/Porting%20FreeB… > > > http://oss.org.cn/ossdocs/server_storage/xen/interface/interface.html > > http://www.informit.com/articles/article.aspx?p=1160234&seqNum=4 > > https://lse.epita.fr/data/2011-lse-summer-week/xen.pdf > > https://github.com/cloudius-systems/osv/blob/master/drivers/xenfront-xenbus… > > > 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 >> >> >> Eliot (phone) >> > > > >

Dec. 22, 2014

Re: [Pharo-dev] NativeBoost libraries hosting

by HernÃ¡n Morales Durand

Thank you for the links, I am reading some of them now. HernÃ¡n 2014-12-20 6:20 GMT-03:00 Ben Coman <btc(a)openinworld.com>: > 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@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. 21, 2014

Re: [Pharo-dev] NativeBoost libraries hosting

by HernÃ¡n Morales Durand

2014-12-21 19:02 GMT-03:00 Tommaso Dal Sasso <tommaso.dalsasso(a)gmail.com>: > What about writing some glue classes that check for the presence of the > libraries and download them automatically if the libraries are not present? > In this way, the developer would only have to specify a download url (or > at most one for each supported platform). > Yes, actually I am using that "mechanism" - only 6 methods - for several of my projects (see ConfigurationOfBioSmalltalk in 'doits' category). I think it could be included in Metacello. The problem is getting a host which could be - Reliable = no downtime (Dropbox is ok, GitHub is ok) - Allows to link multiple accounts (Dropbox ??, GitHub ??) - Custom URLs (DropBox is ok, GitHub is ok) - Easy to link (Dropbox somewhat, GitHub ??) - Easy to update (Dropbox is ok, GitHub not) HernÃ¡n This sort of "caching" mechanism could be included in NativeBoost to reduce > the problem of hosting the libraries and would also reduce the application > size, since it would only download the binaries of the current platform. > > Tommaso > > > > On 20/12/14 10:20, Ben Coman wrote: > >> 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@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. 21, 2014

Re: [Pharo-dev] Cog in the cloud

by Ben Coman

Eliot Miranda wrote: > Hi Ben, > > > On Dec 19, 2014, at 8:08 PM, Ben Coman <btc(a)openInWorld.com> wrote: > >> 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? > > This sounds really cool, but could you analyse a bit further? > > - what key economic and managerial benefits accrue from this configuration? I'll put some more thought into this, but just off the top of my head (so it turned out more technical than economic/managerial): * Eliminates performance overhead of system call context switching. Although this is replaced by hypercalls, it removes one layer on hypervisor systems, which plausibly is going to be EVERYTHING in the future. * Eliminate performance overhead of OS networking stack http://roscidus.com/blog/blog/2014/08/15/optimising-the-unikernel/ * Data from virtual devices is event driven. * More easily portable to different ARM platforms. Xen will present a common interface to hide platform idiosyncrasies. --> More widespread embedded use Cog. http://www.slideshare.net/xen_com_mgr/free-rtos-xensummit * Run databases in their own domain. * Isolate plugin memory space. Rather than linking plugins into Cog, potentially threatening its stability, run them in a separate domain and use high-speed inter-domain shared memory. http://www.cs.ucsb.edu/~nanli/projects/cs270.pdf * Have a cloud community of thousands** of Images running each in their own domain, communicating with high-speed inter-domain shared memory. ** presumptive figure - would need to check scaling ability * Data sharing on high density hosting providers. Not sure if its there yet, but may get Copy-On-Write http://www-archive.xenproject.org/files/xensummit_fall07/18_GregorMilos.pdf * In very large Images, which Spur will allow, perhaps a better way to snapshot an Image is via virtual machine snapshotting using Copy-On. http://www.cercs.gatech.edu/tech-reports/tr2010/git-cercs-10-05.pdf * Rather than convert the Cog/Image to be multi-threaded, could have many grid nodes running their own domain, communicating with high speed shared memory. http://www.cs.ucsb.edu/~nanli/projects/cs270.pdf http://osnet.cs.binghamton.edu/publications/hines07memx.pdf * AMD's hardware virtualisation eliminated a Ring and also segmented memory protection used by virtualisation to separate address spaces, so 64-bit AMD can be slower. Eliminating the OS kernel layer probably bypasses this limitation since there would be only two levels - Hypervisor & Cog. https://lse.epita.fr/data/2011-lse-summer-week/xen.pdf * Its where all the cool kids hang out --> marketing opportunity > > - what infrastructure is missing? (e.g. what key drivers need implementing?) I'll need to understand Cog more. As a start, here are some porting and API docs... http://events.linuxfoundation.org/sites/events/files/slides/Porting%20FreeB… http://oss.org.cn/ossdocs/server_storage/xen/interface/interface.html http://www.informit.com/articles/article.aspx?p=1160234&seqNum=4 https://lse.epita.fr/data/2011-lse-summer-week/xen.pdf https://github.com/cloudius-systems/osv/blob/master/drivers/xenfront-xenbus… 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 > > > Eliot (phone) >

Dec. 21, 2014

Re: [Pharo-dev] NativeBoost libraries hosting

by Tommaso Dal Sasso

What about writing some glue classes that check for the presence of the libraries and download them automatically if the libraries are not present? In this way, the developer would only have to specify a download url (or at most one for each supported platform). This sort of "caching" mechanism could be included in NativeBoost to reduce the problem of hosting the libraries and would also reduce the application size, since it would only download the binaries of the current platform. Tommaso On 20/12/14 10:20, Ben Coman wrote: > 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. 21, 2014

Re: [Pharo-dev] Cog in the cloud

by Eliot Miranda

Hi Ben, On Dec 19, 2014, at 8:08 PM, Ben Coman <btc(a)openInWorld.com> wrote: > > 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? This sounds really cool, but could you analyse a bit further? - what key economic and managerial benefits accrue from this configuration? - what infrastructure is missing? (e.g. what key drivers need implementing?) > 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 Eliot (phone)

Dec. 21, 2014

Re: [Pharo-dev] Cog in the cloud

by Michael J. Forster

Thanks, Ben! -Mike -- View this message in context: http://forum.world.st/Cog-in-the-cloud-tp4796514p4796597.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 21, 2014