Pharo-dev

By thread

pharo-dev@lists.pharo.org

1 participants
144632 messages

pullup instance variable is wrong

by StÃ©phane Ducasse

Hi when you do a pull up one class, the system pull the instance variable on the originating class. When you try on the superclass you cannot access the iv of the subclasses. So we cannot do a pull up iv at all. Stef

June 25, 2013

Please review 10950 10983

by Gisela Decuzzi

Subj. to see if we can integrate them and keep working on that.

June 25, 2013

Re: [Pharo-dev] Object >> #is:

by StÃ©phane Ducasse

On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-06-24, at 18:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> the isBlah is not optimal now it is just there and we cannot rewrite everything. >> I still think that is: is a nice way to kill some of the isPlague in Object. > > I still don't see what you solve, and the idea to use symbols for #is: is also > wrong, for me that's going back to string-based programming. Not only :) > anyway, this topic has been discussed with enough hot air so far and no progress, > which means it is absolutely not important. there are more urgent things to doneâ¦ I agree

June 24, 2013

Re: [Pharo-dev] Object >> #is:

by Camillo Bruni

On 2013-06-24, at 18:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > the isBlah is not optimal now it is just there and we cannot rewrite everything. > I still think that is: is a nice way to kill some of the isPlague in Object. I still don't see what you solve, and the idea to use symbols for #is: is also wrong, for me that's going back to string-based programming. anyway, this topic has been discussed with enough hot air so far and no progress, which means it is absolutely not important. there are more urgent things to done...

June 24, 2013

Re: [Pharo-dev] Object >> #is:

by StÃ©phane Ducasse

the isBlah is not optimal now it is just there and we cannot rewrite everything. I still think that is: is a nice way to kill some of the isPlague in Object. Stef >> But I hate more isPlague in Object. > > I think that plage mostly arises when people do not like to use Visitors / DoubleDispatch. > > Conceptually the #is: message IS exactly the same, instead of doing a dynamic dispatch > you write procedural code with if checks, no?

June 24, 2013

Re: [Pharo-dev] Object >> #is:

by Camillo Bruni

On 2013-06-24, at 18:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > But I hate more isPlague in Object. I think that plage mostly arises when people do not like to use Visitors / DoubleDispatch. Conceptually the #is: message IS exactly the same, instead of doing a dynamic dispatch you write procedural code with if checks, no?

June 24, 2013

Re: [Pharo-dev] Object >> #is:

by StÃ©phane Ducasse

But I hate more isPlague in Object. Stef On Jun 24, 2013, at 12:55 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > I never liked it, so I vote for removal :) > > On Jun 24, 2013, at 11:27 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > >> >> On Jun 23, 2013, at 10:08 PM, Tudor Girba wrote: >> >>> Just remove it :) >>> >>> Doru >> >> Alternatively, start using it, and remove the rest of the is* methods on Object, which was the initial intent :P >> >> Of course, there's a tradeoff between locality of implementation and discoverability with (default) tools here, in that you get less implementors, and Object is cleaner, but at the cost that finding the actual meaning of is: in use in a specific piece of code outside of a debugger *can* be a painâ¦ >> >> In my mind, what's currently in use is the better tradeoff for day-to-day programming and maintenance . >> >> Extensions that don't require contrived protocol names for tool support would be a neat thing :) >> >> Cheers, >> Henry > >

June 24, 2013

Re: [Pharo-dev] Cloud Hosting why/when?

by James Foster

Do Amazon's data centers outside the US qualify for EU usage? On Jun 24, 2013, at 7:36 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Another issue is, at least in the EU, the Data Protection Directive. > AFAIK no cloud provider from the US or with US ownership can > currently comply with that. > > Stephan > >

June 24, 2013

Re: [Pharo-dev] Cloud Hosting why/when?

by Sven Van Caekenberghe

Hi Steven, Thanks for the insights, very interesting. It is good to know that people with your profile are on this mailing list. What is your take on persistency and virtual hardware ? The performance difference between say Postgresql running on real hardware vs on ec2+ebs is challenging to say the least. Sven On 24 Jun 2013, at 16:56, Steven Baker <steven(a)stevenrbaker.com> wrote: > I've had quite a lot of experience helping teams who use both cloud-based and physical-server hosting. > > The promise of the cloud is that you can start/stop servers to meet dynamic demand. In the simple case, run ten servers during the day in your timezone, and only one at night to keep the lights on. In a slightly more complicated case, have some software tools (that you probably have to write yourself) that spin up and add new servers to the pool when server load reaches a certain threshold. In the usual case, spin up new servers to do computationally intensive background workers. > > Since you typically pay for cloud services by the running hour, very careful management of this can lead to lower costs. In theory. > > In practice, people don't really do this. They spin up some servers, deploy their stuff. When they need more, they spin up some more, and never really manage growth or two to manage expenses. In fact, because it's *so* easy to spin up a new server, folks will often end up with far more than they need very quickly. > > My experience has been that the average non-profitable startup will spend between $10,000 and $30,000 per month on their cloud hosting. For hosting that can be adequately served by two $2500 servers for $250/mo in co-location fees. I have literally gone to clients, moved them off of cloud provider to real hardware for significant and nearly immediate gains. One month of their hosting fees can typically pay for my time (and I'm not cheap), the new hardware, and a year of co-location fees. > > There are rare cases when this is reasonable. Also, since I'm in Canada, companies typically can't store their data in the US because of the Patriot Act, and that makes Rackspace Cloud one of the few options we have. Finally, you can install VMware's vCloud Director (or similar; they have many products) on your own hardware and have "the cloud" on your own hardware. It's amazing. > > That said, there are some good reasons to us cloud-based services: hardware management, backups, security. > > - Hardware management is the most obvious. When you use a product like Rackspace Cloud, you don't ever have to think about disks, servers, locations, network configurations, etc. When you want more power, you click a button. Someone else manages all of that. When there's a bad disk, you don't notice, because it's someone else's job to swap out the bad one and make sure that everything was redundant. > > - Backup and reliability are a really important feature that cloud providers offer. All will offer redundant disks and the like, but most go further than that. Most cloud providers have multiple datacentres and can spread out your servers, or move your data between them quickly. In Canada, we have one cloud provider who will transparently fail over your stuff from Vancouver to Toronto and vice versa. > > - Security is probably the most often overlooked point. Most cloud providers will manage firewalls, and do the "infrastructure bits" of PCI compliance and related things which significantly reduces the work you have to do yourself. > > In the end, it depends on the business. My experience is that it's foolish to use cloud providers for anything more than small VPSes without taking a hard look at the costs. Most businesses will have someone on staff who can manage the building and deployment of these servers, and well managed servers don't need babysitters anyhow. Plus, as software developers, we'll automate everything (they call that Devops now) and make it even easier. > > I have recommended two past clients switch to the cloud. They had a rack full of aging servers, and were paying a staff of four system administrators ~ USD$80k/yr to manage those. Moving to the cloud was cheaper for them in both the short and long term. But it's rare. > > Finally, when your stack is "simple Rails app running on MySQL", which is a completely boneheaded stack in the first place, it's *easy* to scale and can be done nearly transparently. Plus, do you really want the Rails kids touching infrastructure bits? Some things are best left to the experts, and using a cloud provider makes that easy even if it is more expensive. > > Cheers! > > -Steven > > > > > On 2013-06-21, at 8:29 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > >> When I see the enthousiast reactions to the cloud hosting tip, >> I often wonder why? What do you see as the advantages, >> and where does it provide a good fit? I can understand the >> 5 euro/month vps for a single instance case. >> >> As soon as I need redundancy, monitoring and scaling, >> I still need to understand so much of the underlying infrastructure >> that the step to DevOps seems awfully small. Neiher Heroku, >> nor AWS make scaling transparent, AFAIK. That is to say, they'll >> start up new instances just fine. That only helps when processing >> is the problem, not internal bandwidth. And solving the wrong >> problem only leads to high costs. >> >> The cost figures I've seen published on the web suggest that most >> larger scale usage would be better of with at least their regular demand >> covered by dedicated servers. I know hosting in the US is much more >> expensive than in Europe. Digitalocean at least seems to give more >> reasonable price/performance. AWS vs Hetzner seems uncomparable >> >> Your thoughts? >> >> Stephan >> >> >> > >

June 24, 2013

Re: [Pharo-dev] Cloud Hosting why/when?

by Sabine KnÃ¶fel

Amazon has a datacenter in ireland. Sabine Am 24.06.2013 16:36 schrieb "Stephan Eggermont" <stephan(a)stack.nl>: > Another issue is, at least in the EU, the Data Protection Directive. > AFAIK no cloud provider from the US or with US ownership can > currently comply with that. > > Stephan > >

June 24, 2013

Jump to page: