October 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Dynamically changing code in a safe way

by Peter UhnÃ¡k

> Why the assignment of the new code is delayed until the end of the bloc execution? The assignment is performed immediately, but the old code is still being executed. Once the value was sent to the block, the block started executing and is no longer under the control of the HotSwapping object. On Tue, Oct 24, 2017 at 10:03 PM, Prof. Andrew P. Black <black(a)cs.pdx.edu> wrote: > > > On 23 Oct 2017, at 23:12 , Richard Sargent <richard.sargent@ > gemtalksystems.com> wrote: > > > > Imagine if I were to hand you a loaf of bread and tell you to feed it to > the dog. If I were then to hand you another loaf of bread, the dog would > continue eating the first loaf. We never told the dog to do anything else. > > If your dog is anything like my dog, telling her to do something else > wouldnât change the situation very much. ;-) > > Andrew >

Oct. 24, 2017

Can we halt on memory growth beyond a limit?

by PAUL DEBRUICKER

I'm trying to get some understanding about a process that uses a lot of RAM when it runs. Is there a way to halt if/when RAM use doubles ? Thanks Paul

Oct. 24, 2017

Re: [Pharo-users] Dynamically changing code in a safe way

by Prof. Andrew P. Black

> On 23 Oct 2017, at 23:12 , Richard Sargent <richard.sargent(a)gemtalksystems.com> wrote: > > Imagine if I were to hand you a loaf of bread and tell you to feed it to the dog. If I were then to hand you another loaf of bread, the dog would continue eating the first loaf. We never told the dog to do anything else. If your dog is anything like my dog, telling her to do something else wouldnât change the situation very much. ;-) Andrew

Oct. 24, 2017

Glorp: #includesKey:

by Herby VojÄÃk

Hello! I am using a DictionaryMapping in my code, and I wanted to use #includesKey: in #where: clause (something akin each tools includesKey: aToolId ) to select only rows for which DictionaryMapping uses certain key. It failed with the error in the lines of "#tools does not resolve to field". I had to come up with each tools anySatisfy: [ :tool | tool id = aToolId ] Is it the bug / feature / problem in my approach? If bug, is it planned to add #includesKey: translation to DictionaryMapping? Thanks, Herby

Oct. 24, 2017

Re: [Pharo-users] Territorial loading problems & alternative ways of loading data for making a choropleth map

by Offray Vladimir Luna CÃ¡rdenas

Gracias HernÃ¡n! This is working fine. I would like to put the displayed map inside the GT playground right panel, to get something similar to what you get when you execute "RTMapLocationExample new exampleSeismOnEarth" from a playground. Do you have any planned support for that? I could try to use some similar approach to the one I take on the Panama Papers choropleth map [1][2] to export some Territorial data for visualizations in a light format (120kb file example at: [3]), if you're interested. [1] http://mutabit.com/offray/blog/en/entry/panama-papers-1 [2] http://mutabit.com/repos.fossil/panama-papers/doc/tip/index.html [3] http://mutabit.com/repos.fossil/panama-papers/doc/tip/territories.ston Cheers, Offray On 23/10/17 23:21, HernÃ¡n Morales Durand wrote: > Hola Offray, > > I tried loading in Windows 8.1 and it loads fine using: > > Metacello new > smalltalkhubUser: 'hernan' project: 'Territorial'; > configuration: 'Territorial'; > version: #bleedingEdge; > load. > > Then load TerritorialData-AMCharts-HernanMoralesDurand.2 from the repository. > > I published some "fixes" related to Spec and Roassal. (I have to > review them because I'm porting other packages to Pharo 6.1, but it > should work for displaying maps). > > The following expression displays a window with Colombia departments: > > TerritorialAMChartsMapsProvider viewHighResCountry: 'Colombia' > > For a choropleth with a heatmap or centroids have a look at how I did > it in PhyloclassTalk in SmalltalkHub, again I should update it to work > in Pharo 6.1. > > Cheers, > > HernÃ¡n > > > > 2017-10-23 22:59 GMT-03:00 Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com>: >> Hi, >> >> I would like a choropleth map of Colombian departments [1]. The first >> approach would be to use Territorial, but loading it is not working on >> Pharo 6.1 (used on Manjaro Linux): It doesn't appears in the Catalog, >> Gopher load gives me: "XMLFileException: File does does not exist: >> /home/offray/Programas/Pharo/6.1a/Dev24/territorial_files/fao/fao_country_names.xml" >> and loading Monticello bleeding edge gives me "FileDoesNotExist: File @ >> /home/offray/Programas/Pharo/6.1a/Dev24/territorial_files/opengeocode/wc-ASCII.csv". >> There is another way to make such choropleth map? >> >> [1] https://en.wikipedia.org/wiki/Departments_of_Colombia >> >> Thanks, >> >> Offray >> >> >>

Oct. 24, 2017

Re: [Pharo-users] using mocketry to mock subcall

by Herby VojÄÃk

Denis Kudriashov wrote: > Hi Herby. > > 2017-10-20 18:49 GMT+02:00 Herby VojÄÃk <herby(a)mailbox.sk > <mailto:herby@mailbox.sk>>: > > > I had this problem. I tried something like (though not exactly w/ > this code): > > Foo stub new will: [ :aMessage | > | original | > original := MockExpectedOriginalCall new executeFor: aMessage. > original stub. > ^ original ] > > but IIRC it failed on doing #stub inside will: block. > > > So the arguments of block in message #will: are expected to be arguments > of stubbing message (not a full message instance). > We can introduce new kind of expected action to automatically stub any > result of message send: > > Foo stub new willStubRealResult. Yeah, exactly, something like that is useful. > With help of new subclass of MockExpectedOriginalMethodCall: > > MockExpectedMethodResultStub>>executeFor: anOccurredMessage > > realMethodResult := super executeFor: anOccurredMessage. > > realMethodResult stub. > > ^realMethodResult. > > MockExpectedMessage>>willStubRealResult > > self will: MockExpectedMethodResultStub new Actually I tried this path myself but it failed badly during doing the sub-#stub with lots of "go one metalevel down" etc. calls in stack, so I gave up with "I don't understand this to make it work atm". Does your solution actually work? > And then you will be able specify expectations for all Foo instances: > > (Instance of: Foo) stub someMessage willReturn: #const As in, would `Foo new someMessage should be: #const`? In that case, great and thanks. > And you will be able assert any message which was sent to Foo instances: > > (Instance of: Foo) should receive someRequiredMessage which should > equal: #expectedValue > > I committed this code to the dev branch. But I am wondering that such > kind of behaviour is really needed. Probably it is useful as you ask > about it. Herby

Oct. 24, 2017

Re: [Pharo-users] Zinc HTTP Component HTTP/2?

by Volkert

I am not sure what Svens plan with the Zinc HTTP Component is, but a bounty is a good idea ... On 23.10.2017 22:12, Stephane Ducasse wrote: > We could run a bounty. Now here we are full of work. > > On Mon, Oct 23, 2017 at 6:59 PM, Volkert > <volkert(a)komponentenwerkstatt.de> wrote: >> So currently no plans and/or no sponsors, right? >> >> >> On 22.10.2017 12:26, Esteban Lorenzano wrote: >>> Hi Holger, >>> >>> We talked a bit about this last ESUG. >>> Sadly, it requires serious work to have it so we hadnât put this in any schedule yet :( >>> >>> Esteban >>> >>>> On 21 Oct 2017, at 16:26, Volkert <volkert(a)komponentenwerkstatt.de> wrote: >>>> >>>> Dear all, >>>> >>>> the world is moving to http/2. Any plans for Zinc HTTP Components to >>>> support this standard? >>>> >>>> BW, Volkert >>>> >>>> >>>> >>

Oct. 24, 2017

Re: [Pharo-users] Smalltalk Argument

by David Mason

PharoJS is working to give you that mobile app/browser app experience. As with others, we're not there yet, but getting there. See http://pharojs.org The 67% loved means that 67% of people using Smalltalk (or perhaps have ever used it) want to continue - so it's presumably a high percentage of a smallish number of people. On 20 October 2017 at 03:23, jtuchel(a)objektfabrik.de < jtuchel(a)objektfabrik.de> wrote: > First of all: I'd say the question itself is not a question but an excuse. > I am not arguing there are enough Smalltalkers or cheap ones. But I think > the question is just a way of saying "we don't want to do it for reasons > that we ourselves cannot really express". If you are a good developer, > learning Smalltalk is easy. If you are a good developer you've heard the > sentence "we've taken the goos parts from x,y,z and Smalltalk" at least > twice a year. So you most likely would like to learn it anyways. > > A shortage of developers doesn't exist. What exists is an unwillingness of > companies to get people trained in a technology. If Smalltalk was cool and > great in their opinion, they wouldn't care. It's that simple. As a > consultant, I've heard that argument so often. Not ferom Startups, but from > insurance companies, Banks or Car manufacturers who spend millions on > useless, endless meetings and stuff instead of just hiring somebody to > teach a couple of developers Smalltalk. It's just a lie: the shortage of > Smalltalk developers is not a problem. > > And, to be honest: what is it we actually are better in by using Smalltalk? > Can we build cool looking web apps in extremely short time? No. > Can we build mobile Apps with little effort? No. > Does our Smalltalk ship lots of great libraries for all kinds of things > that are not availabel in similar quality in any other language? > Are we lying when we say we are so extremely over-productive as compared > to other languages? > > I know, all that live debugging stuff and such is great and it is much > faster to find & fix a bug in Smalltalk than in any other environment I've > used so far. But that is really only true for business code. When I need to > connect to things or want to build a modern GUI or a web application with a > great look&feel, I am nowhere near productive, because I simply have to > build my own stuff or learn how to use other external resources. If I want > to build something for a mobile device, I will only hear that somebody > somewhere has done it before. No docs, no proof, no ready-made tool for me. > > > Shortage of developers is not really the problem. If Smalltalk was as cool > as we like to make ourselves believe, this problem would be non-existent. > If somebody took out their iPad and told an audience: "We did this in > Smalltalk in 40% of the time it would have taken in Swift", and if that > something was a must-have for people, things would be much easier. But > nobody has. > > > I am absolutely over-exaggerating, because I make my living with an SaaS > product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk > and - as you - am convince that many parts of what we've done so far > would've taken much longer or even be impossible in other languages. But > the advantage was eaten by our extremely steep learning curve for web > technologies and for building something that works almost as well as tools > like Angular or jQuery Mobile. > > Smalltalk is cool, and the day somebody shows me something like Google's > flutter in Smalltalk, I am ready to bet a lot on a bright future for > Smalltalk. But until then, I'd say these arguments about productivity are > just us trying to make ourselves believe we're still the top of the food > chain. We've done that for almost thirty years now and still aren't ready > to stop it. But we've been lying to ourselves and still do so. > > I don't think there is a point in discussing about the usefulness of a > language using an argument like the number or ready-made developers. That > is just an argument they know you can't win. The real question is and > should be: what is the benefit of using Smalltalk. Our productivity > argument is a lie as soon as we have to build something that uses or runs > on technology that has been invented after 1990. > > > Okay, shoot ;-) > > Joachim > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > >

Oct. 24, 2017

[ANN] Pharo Consortium New Platinum Member: IngenieurbÃ¼ro fÃ¼r Bauwesen Schmidt GmbH

by Marcus Denker

The Pharo Consortium is very happy to announce that IngenieurbÃ¼ro fÃ¼r Bauwesen Schmidt GmbH has joined the Consortium as a Platinum Member. About - IngenieurbÃ¼ro fÃ¼r Bauwesen Schmidt GmbH: http://bauing-schmidt.de - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: - http://association.pharo.org

Oct. 24, 2017

Re: [Pharo-users] [Seaside] [ANN] SeasideTesting recovered from oblivion

by Norbert Hartl

Cool. Need to think where it is useful. On the one hand testing without external components is good. On the other hand you can only test very simple stuff with it. But there might be a place. Btw. you donât need selenium with parasol. You can use chrome-standalone which implements the same protocol. Norbert > Am 23.10.2017 um 12:04 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > Hi, > > I spend some days last week woking with the guys of AFI (http://afi-sa.fr, yes they also use Pharo in some of their projects) and together we recovered SeasideTesting from Davis Shaffer to be used for their TDD experience. > > you can check it out here: https://github.com/Afibre/SeasideTesting > > Whatâs SeasideTesting? A package to test Seaside components. > Why we do not use Parasol? Because it is based on selenium and that makes the process slow. > Where can I know more? > - there is some documentation here (for VW, I think): http://www.shaffer-consulting.com/david/Seaside/TestingComponents/TestingCo… > - some slides here (on squeak): http://esug.org/data/ESUG2005/Wednesday/2005-ESUG-Shaffer.pdf > but all that is old. Best way is to just install and see the tests, as always, > > > cheers! > Esteban > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Oct. 24, 2017