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

Re: [Pharo-users] CodeCity like visualization in Linux

by Rafael Luque

Thank you for your help Tudor. I'm trying with the CodeCity image I've downloaded from your post ( http://www.humane-assessment.com/blog/communicating-changes-in-pharo-3-0) and I get the error "MessageNotUnderstood: receiver of "platformId" is nil" in the NBMacGLContextDriver class>>supportsCurrentPlatform method. By this reason I thought it only works on Mac or maybe I must previously configure something to get the NativeBoost working on Linux. Thank you. â 2017-10-25 9:02 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > CodeCity only works in Pharo 3 (or maybe also 4). > > Doru > > > > On Oct 25, 2017, at 1:38 AM, Rafael Luque <rafael.luque.leiva(a)gmail.com> > wrote: > > > > Hi all, > > > > I'm working on an introductory talk about Pharo for a software > craftsmanship local meetup. > > > > The presentation will be mainly driven by demos and I'd like to show a > CodeCity-like visualization. I've been able to load it in Pharo 5, but it > get an error when select the "City" tag in GTInspector. It seems that > NBOpenGL does not work in Linux. > > > > Do you know any way to make it work in Linux? > > > > Thank you. > > â > > -- > www.tudorgirba.com > www.feenk.com > > "Presenting is storytelling." > > >

Oct. 25, 2017

Re: [Pharo-users] CodeCity like visualization in Linux

by Tudor Girba

CodeCity only works in Pharo 3 (or maybe also 4). Doru > On Oct 25, 2017, at 1:38 AM, Rafael Luque <rafael.luque.leiva(a)gmail.com> wrote: > > Hi all, > > I'm working on an introductory talk about Pharo for a software craftsmanship local meetup. > > The presentation will be mainly driven by demos and I'd like to show a CodeCity-like visualization. I've been able to load it in Pharo 5, but it get an error when select the "City" tag in GTInspector. It seems that NBOpenGL does not work in Linux. > > Do you know any way to make it work in Linux? > > Thank you. > â -- www.tudorgirba.com www.feenk.com "Presenting is storytelling."

Oct. 25, 2017

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

by Prof. Andrew P. Black

> On 24 Oct 2017, at 22:48 , Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > 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. Another way of looking at this is to ask yourself what is the granularity of the think that you are changing. In your original example, you made a new assignment to currentBlock, but the code (operating on the old value of currentBlock) does not re-read this variable each time aroind the loop. It reads it just once, before it starts looping. So changing it afterwards wonât matter. In contrast, suppose that you were to recompile a new version of Trasncript>>#show: while your loop is running. The version that is currently executing would finish, but the next time that #show: is sent to Transcript, you would execute the new version.

Oct. 25, 2017

Re: [Pharo-users] Can we halt on memory growth beyond a limit?

by Ben Coman

On Wed, Oct 25, 2017 at 4:15 AM, PAUL DEBRUICKER <pdebruic(a)gmail.com> wrote: > 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 > I don't know, but just to clarify, you are wanting in in-Image flag to use as a breakpoint in your application code? cheers -ben

Oct. 25, 2017

Re: [Pharo-users] Glorp: #includesKey:

by jtuchel＠objektfabrik.de

Herby, I must admit I've never used Dictionary Mappings with Glorp, so I don't have an answer. But I am a bit confused by your code examples. See below Am 24.10.17 um 20:27 schrieb 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 What SQL expression would you expect here? I would guess that you want to build a subquery like exists, because the way I understand the query, you want to find all instances of (whatever each is) that hold an Association in their tools dictionary where the key is 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 ] Hmm. This makes me wonder. Is #tools really a Dictionary? Inside the Block, I'd expect the :tool parameter to be an Association, and that doesn't understand #id,does it? I guess @each is the parameter within an Block like in self session read: MyClass where: [:each| each tools ...] If so, I have a hard time believing that anySatisfy: would work (never tried)... > > > Is it the bug / feature / problem in my approach? If bug, is it > planned to add #includesKey: translation to DictionaryMapping? > I don't know, but would guess it is not currently on the Todo-list. My first tip would be to try and find some slides (most likely made by Niall and presented at an ESUG) including the words "subquery", "glorp" and "exists". You won't find much, but that may be a starting point. Not sure this helps, ;-) 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. 25, 2017

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

by HernÃ¡n Morales Durand

2017-10-24 15:24 GMT-03:00 Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com>: > Gracias HernÃ¡n! > No problema :) > 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 know this should be as easy as adding a <gtInspectorPresentationOrder: ... > pragma gtInspectorViewIn: composite <gtInspectorPresentationOrder: 60> composite morph title: 'Territorial Map'; display: [ view build ] but still I have to investigate how to connect a RTView or TRMorph with GT inspector > 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 > Super! It would be nice to see usage in other scenarios! Let me know how it goes. Cheers, HernÃ¡n > 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. 25, 2017

CodeCity like visualization in Linux

by Rafael Luque

Hi all, I'm working on an introductory talk about Pharo for a software craftsmanship local meetup. The presentation will be mainly driven by demos and I'd like to show a CodeCity-like visualization. I've been able to load it in Pharo 5, but it get an error when select the "City" tag in GTInspector. It seems that NBOpenGL does not work in Linux. Do you know any way to make it work in Linux? Thank you. â

Oct. 24, 2017

Re: [Pharo-users] Can we halt on memory growth beyond a limit?

by ClÃ©ment Bera

Hi, You can start the VM with this parameter: --memory <size>[mk] use fixed heap size (added to image size) When the memory is reached you have an out of memory error. Check --help on the VM. On Tue, Oct 24, 2017 at 10:15 PM, PAUL DEBRUICKER <pdebruic(a)gmail.com> wrote: > 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 > -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Oct. 24, 2017

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

by Denis Kudriashov

Hi 2017-10-24 20:07 GMT+02:00 Herby VojÄÃk <herby(a)mailbox.sk>: > 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". > Probably you not used superclass execution logic where right metalevel logic is implemented (notice that in my example I call "super executeFor:") > > 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. Yes for all questions. And new test is added for this feature > > > 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] Multi-core Software Concurrency

by Michael J. Forster

To supplement the points raised by others, I never assume that someone asking me about "concurrency" understands the following: https://blog.golang.org/concurrency-is-not-parallelism -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 24, 2017

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

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

by HernÃ¡n Morales Durand

2017-10-24 1:21 GMT-03:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > 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. > TerritorialData-AMCharts-HernanMoralesDurand.3 or the latest version you find :) > 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] Territorial loading problems & alternative ways of loading data for making a choropleth map

by HernÃ¡n Morales Durand

2017-10-24 0:01 GMT-03:00 Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com>: > Hi, > > Answering myself: I was able to fix this problem by downloading the > "territorial_files" zip folder from the source repo and unzipping it to > the image folder. After that Metacello bleeding edge (not Monticello, my > mistake) installation worked properly. So, it seems that proper > downloading and unzipping of supporting files is not working. I have > found this also for the GADM files as reported in [1]. > Tomorrow I will check in Linux. > By the way, I have created a Grafoscopio notebook to take some > interactive notes on my learning of Territorial [2][3]. My first > impressions are that this is a pretty potent package, but still needs a > more fluid installation and the supporting files are huge, and I wonder > if there is any way to query/download the data on demand. > Thank you for the feedback Offray. This is an issue I should profile because some data sets are huge, and then think about how to provide maybe a customized installation or download spcific resource on demand. Cheers, HernÃ¡n > [1] https://github.com/hernanmd/Territorial/issues/2. > [2] > http://mutabit.com/repos.fossil/grafoscopio/finfo?name=Docs/En/Books/Territ… > [3] > http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Territori… > > Thanks and keep the good work, > > Offray > > On 23/10/17 20:59, Offray Vladimir Luna CÃ¡rdenas wrote: >> 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] Territorial loading problems & alternative ways of loading data for making a choropleth map

by HernÃ¡n Morales Durand

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] Territorial loading problems & alternative ways of loading data for making a choropleth map

by Offray Vladimir Luna CÃ¡rdenas

Hi, Answering myself: I was able to fix this problem by downloading the "territorial_files" zip folder from the source repo and unzipping it to the image folder. After that Metacello bleeding edge (not Monticello, my mistake) installation worked properly. So, it seems that proper downloading and unzipping of supporting files is not working. I have found this also for the GADM files as reported in [1]. By the way, I have created a Grafoscopio notebook to take some interactive notes on my learning of Territorial [2][3]. My first impressions are that this is a pretty potent package, but still needs a more fluid installation and the supporting files are huge, and I wonder if there is any way to query/download the data on demand. [1] https://github.com/hernanmd/Territorial/issues/2. [2] http://mutabit.com/repos.fossil/grafoscopio/finfo?name=Docs/En/Books/Territ… [3] http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Territori… Thanks and keep the good work, Offray On 23/10/17 20:59, Offray Vladimir Luna CÃ¡rdenas wrote: > 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] Territorial loading problems & alternative ways of loading data for making a choropleth map

by HernÃ¡n Morales Durand

I am revieweing this right now. Lot of work in the bioinformatics department! 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

Territorial loading problems & alternative ways of loading data for making a choropleth map

by Offray Vladimir Luna CÃ¡rdenas

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] [Seaside] [ANN] SeasideTesting recovered from oblivion

by Johan Brichau

I donât know... we maintained SeasideTesting at http://smalltalkhub.com/#!/~Seaside/SeasideTesting/ until we developed Parasol because it just covers some bare-bones html page testing. Forget about JavaScript and css influence on your tests in seaside testing. I think we prefer a slower but accurate testing proces, using Parasol. Johan > On 23 Oct 2017, at 22:22, Jon Paynter <kittle31(a)gmail.com> wrote: > > Great to hear! > > I use this on some older projects, and found the documentation helpful, but also sketchy. Hopefully you can update things. > > Will your resurected version work with Visualworks? > >> On Mon, Oct 23, 2017 at 3:04 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> 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 >> > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Oct. 23, 2017

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

by Richard Sargent

This is a great question, Abdelghani. It comes down to the meaning of the phrase "everything is an object". When you wrote "currentBloc value", that caused the block *[ 1 to:50 do: [:index |Transcript show: index. 100 milliSeconds asDelay wait]. Transcript cr. 1000 milliSeconds asDelay wait ]* to evaluate. The fact that you hold a reference to that block elsewhere and change what object is referenced at some point does not change the fact that the block itself is executing. Until your code executes *currentBloc value* again, it won't start the new block executing. 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. On Mon, Oct 23, 2017 at 1:53 PM, abdelghani ALIDRA via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: abdelghani ALIDRA <alidrandco(a)yahoo.fr> > To: <pharo-users(a)lists.pharo.org> > Cc: > Bcc: > Date: Mon, 23 Oct 2017 20:53:51 +0000 (UTC) > Subject: Dynamically changing code in a safe way > Hi, > > If I create a class HotSwapping with the instance variable currentBLoc > (and the corresponding accessors) and the following methods : > > HotSwapping>>initialize > currentBloc := [ 1 to:50 do: [:index |Transcript show: index. 100 > milliSeconds asDelay wait]. Transcript cr. 1000 milliSeconds asDelay wait ] > > HotSwapping>>run > [10 timesRepeat: [ currentBloc value ]] fork > > I then do : obj := HotSwapping new run > The âfunnyâ thing is that, when Transcript starts showing numbers, lets > say : 12345678910 (i.e. the bloc is in the middle of its execution), I do > obj currentBloc: [Transcript show: âHelloâ;cr. 1000 milliSeconds asDelay > wait ] > > The Transcript does not stop showing numbers. It shows the Hello message > only after the old bloc has finished executing (the entire line of number > form 0 to 50 has been printed in the Transcript) > > So why does not this happen this way? Why the assignment of the new code > is delayed until the end of the bloc execution? is it something related to > threads execution or does Pharo implement some safety hot swapping > mechanisms? > > Thanks in advance. > Abdelghani > > >

Oct. 23, 2017

Dynamically changing code in a safe way

by abdelghani ALIDRA

Hi, If I create a class HotSwapping with the instance variable currentBLoc (and the corresponding accessors) and the following methods : HotSwapping>>initialize currentBloc := [ 1 to:50 do: [:index |Transcript show: index. 100 milliSeconds asDelay wait]. Transcript cr. 1000 milliSeconds asDelay wait ] HotSwapping>>run [10 timesRepeat: [ currentBloc value ]] fork I then do : obj := HotSwapping new run The âfunnyâ thing is that, when Transcript starts showing numbers, lets say : 12345678910 (i.e. the bloc is in the middle of its execution), I do obj currentBloc: [Transcript show: âHelloâ;cr. 1000 milliSeconds asDelay wait ] The Transcript does not stop showing numbers. It shows the Hello message only after the old bloc has finished executing (the entire line of number form 0 to 50 has been printed in the Transcript) So why does not this happen this way? Why the assignment of the new code is delayed until the end of the bloc execution? is it something related to threads execution or does Pharo implement some safety hot swapping mechanisms? Thanks in advance. Abdelghani

Oct. 23, 2017

Re: [Pharo-users] About Ztimestamp

by Stephane Ducasse

Hi sven I read the class comments in fact :) and now rereading and your answer I start to understand. What the class comments did not convey to me was that you have to follow the 2001 example. The "#reference timestamp" was confusing to me. I could not undersrtand why you where talking about a method (that does not exist in fact). Then I could not understand how the numbering of the component of the example where related to the example you give below. And I can tell you that I browse the class side accessing but I could not find a simple date pattern. By the way using a number higher than 12 for days could help identifying the day from the month. And now I see that as I expected we can also pass a date and not be forced to pass a (ZTimestampFormat fromString: '03/02/2001') format: Date today. If you are interested I can try to propose a better class comment. And BTW I already used the formatter but more than one year ago. Stef On Sun, Oct 22, 2017 at 11:00 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Stef, > >> On 22 Oct 2017, at 17:45, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Hi sven >> >> I'm confused >> >> ft := ZTimestampFormat fromString: '02/11/2017'. >> ft format: DateAndTime now >> >> produces 10/11/1017060986 >> >> While I do not want time but just the date. >> and the date is wrong. >> >> So I will do it manually but I found sad that ZTimestampFormat cannot >> handle just handling days. >> I could then pass also a date and it would not ask for nanoseconds. >> >> Stef > > ZTimestampFormat works with example based format specifications. This works by making each component unique, using a sequential number. Consult the class comment for a full explanation. The class side's #formatSpecifications lists the tokens that are understood and their meaning. > > To go back to your issue, The year is the first component, written as 2001, the month the third and the day the second. So you probably want to do: > > (ZTimestampFormat fromString: '03/02/2001') format: DateAndTime now. > > => '22/10/2017' > > HTH, > > Sven > > >

Oct. 23, 2017

Re: [Pharo-users] UFFI with asynchronous callbacks

by phil＠highoctane.be

I've callbacks all over in https://github.com/Pharophile/XmppTalk They do work. Phil On Mon, Oct 23, 2017 at 8:13 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Mon, Oct 23, 2017 at 11:46 PM, Jan Cada <jan(a)cada.cz> wrote: > >> Hi, >> >> I would like to connect fingerprint reader to pharo - so far I am able to >> use C library to connect to it using UFFI, >> however the problem is that I can wait for fingerprint indefinitely ( >> blocking call to library) or register call-back for moment when fingerprint >> is available. >> The registration function returns immediately, so it is clear that the >> callback will be called from another thread. >> >> Is such situation supported by UFFI ? >> >> Thanks for any tip, >> >> Jan >> > > Callbacks are supported. Here is an example... > http://blog.openinworld.com/2016/09/pharo-libclang-ffi- > part-4-ast-walking-with-visitors-callbacks/ > > @Todd, How did find working through this part? > cheers -ben >

Oct. 23, 2017

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

by Stephane Ducasse

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. 23, 2017

Re: [Pharo-users] Multi-core Software Concurrency

by horrido

Thanks. Good answer. kilon.alios wrote > It all comes down to what you mean by "efficient". Obviously if you want > top performance on multiple cores you dont use any of those languages > including Pharo. Thats prettty much the sole reason why C++ is still a > relevant language. > > Now if you want ok performance you could use those languages. > > However in real case scenarios if you are worried about multi core support > then you have performance issues that you have to make sure its not the > code that has to be blamed before the language. > > For example yesterday I was loading a PNG file via Python to display on > screen via OpenGL and I was getting very slow performance 2.7 second for > 1.5 mb PNG. So my assumption as always "super slow python". But I decided > to give a try to another Python library and expected no more than 1.5 - 2 > seconds load time for the same file. It loaded in 0.03 seconds and took > some time to collect my jaw from the floor. > > Of course the previous library used a "pure python" approach , the other > library was the usual C library wrapped for Python. > > So the library and the code plays a massive role, and I mention this > example because Pharo works in a very similar way. If you do the code in > pure Pharo, Elixir or whatever you will be hit by the performance whale of > dynamic languages. Dynamic typing comes with a high cost as does a live > coding enviroment. Pharo is very lucky in that it has a JIT VM espeically > optimised for its language, so generally you wont get the slow speeds I > got. But still C will once more run circles around a Pharo implementation > , > especially if its an optimised library. > > Thus we have the UFFI. Esteban has done an excellent job and works like a > charm for using C libraries. > > Now if C also is proven slow then multi core wont help you much. > > You need the big guns , which is another name for "GPUs". A powerful GPU > is > even hundrends time faster than the most powerful CPU because it has > thousands of cores. But those cores are designed to compute similar tasks > hence why we dont throw CPUs away which are more versatile. > > So if you plan to do similar computations through millions of objects, > multi core wont help you much, you need the big guns a very expensive and > powerful GPU to do the heavy lifting. > > GPUs used to specialise only on Graphics, but 3d has become so complex > that > nowdays they can do all sort of computations and they have dedicate APIs > for accesing thousands of cores via OpenCL and CUDA. > > Unsuprisingly they run mainly on C/C++. > > The good news is that through the UFFI is possible to access a GPU via > Pharo, Ronie has done this. > > But to my experience most people dont realise what an extremely complex > field performance is and how it widely fluctuates from scenario to > scenario. So there is no "turbo" button to press. > > Now if you ask "but how I do this with pharo". Well technically you dont > do > this with Pharo because Pharo is made to run on CPU. > > GPUs run their own executables which means you have to use special > compilers , good news is that they can do compiling on the fly too so > Pharo > can leverage that. Again Ronie's works is relevant here. > > If you want to avoid all the complexity and go for the simplest solution , > then avoid the GPU. Because GPUs are kinda insane in terms of complexity. > > The easiest way is to fire up multiple Pharo and have them communicate > with > each other via socket or shared memory. The OS when it starts a new > process > it usually asigns it a core that is idle to take advantage of your > multiple > cores. > > Summary: > The answer is "Pharo can do this by accessing the GPU which much faster > than CPU or can access multiple cores through multiple instances running > at > the same time". > > So yes you can have top performance Pharo code if run this way, it wont be > up to C standards but it will be blazzing fast none the less. > > On Mon, Oct 23, 2017 at 4:28 PM horrido < > horrido.hobbies@ > > wrote: > >> With todayâs powerful multi-core processors, the demand for efficient >> software concurrency is high. We find strong support for such concurrency >> in >> the latest crop of âmodernâ languages such as Clojure, Elixir, Go, >> Haskell, >> and Scala. >> >> Whenever I present Smalltalk (Pharo) as a great language option, >> inevitably >> someone asks me about multi-core software concurrency. I have no response >> for them. >> >> Do I just say that if you need concurrency, Pharo is the wrong choice? >> After >> all, no programming language can be good at everything. You must always >> choose the right tool for the job. >> >> Do I say that doing concurrency right is very, very tough, even for the >> most >> experienced of developers? Let's focus on Pharo's strengths, instead. >> Sounds >> like an excuse. >> >> Can we safely ignore the multi-core reality? I welcome your feedback. >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 23, 2017

Re: [Pharo-users] UFFI with asynchronous callbacks

by Ben Coman

On Mon, Oct 23, 2017 at 11:46 PM, Jan Cada <jan(a)cada.cz> wrote: > Hi, > > I would like to connect fingerprint reader to pharo - so far I am able to > use C library to connect to it using UFFI, > however the problem is that I can wait for fingerprint indefinitely ( > blocking call to library) or register call-back for moment when fingerprint > is available. > The registration function returns immediately, so it is clear that the > callback will be called from another thread. > > Is such situation supported by UFFI ? > > Thanks for any tip, > > Jan > Callbacks are supported. Here is an example... http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-4-ast-walking-w… @Todd, How did find working through this part? cheers -ben

Oct. 23, 2017

Re: [Pharo-users] String >> #asSet

by Ben Coman

> > > On Oct 23, 2017, at 05:50, "Prof. Andrew P. Black" <black(a)cs.pdx.edu> > wrote: >> >> If you have a String (or a Symbol), and you sent it the message #asSet, what do you expect to get as an answer? >> >> A set of characters, one would think. But do you care what class is used to implement that set of characters? >> >> -- One argument says that it should be a Set, because thatâs what asSet answers when it is sent to other collections. Itâs conceivable that you might initially populate the set with Characters, but then add other kinds of object. >> >> -- Another argument says that it should be a CharacterSet (or a WideCharacterSet), because you know that the receiver contains characters. The expression 'abcd' asSet is a convenient way to create a CharacterSet with: $a with: $b with: $c with: $d >> >> -- A third argument says that you shouldnât care. If you really want a specific class, then you should use (aString as: Set) rather than aString asSet. >> >> Right now, in Pharo 7, there is a test in TConvertAsSetForMultiplinessTest that insists that the class of the result of asSet is actually Set. >> >> Hard coding a particular return class does seems to break the generality that make traits a good duck typing approach to testing. Instead you want to check it conforms to a series of tests like this... result := #(1 2 3 4) asSet. startSize := result size. result add: s anyOne. self assert: result size equals: startSize. but you don't want to repeat yourself reproduce similar tests by hand everywhere. One approach to reuse might be to refactor SetTest so it can be called like ... TConvertAsSetForMultiplinessTest>>testInQuestion result := self getResult. SetTest runDuckTestsFor: result where #runDuckTestsFor: would exclude Set instance creation tests and suchlike. Duck tests might all take a single argument, so SetTest could call them with a series of concrete cases. The leads me to a philosophical quesition... should methods providing concrete test samples be stored on the class-side. That is, its simple to use... MyClassTest >> someTest sample := self sample. etc... but would it be more correct to do... MyClassTest >> someTest sample := self class sample. etc... since #sample is unrelated to the state of any particularMyClass. And maybe its better to drive it all from the class side... SetTest>>runcase self samples do: [ :duck | self runDuckTestsFor: duck]. self runCreationTests. Now I'm not sure if the following is the RightThing(tm), but for discussion... SetTest>>runDuckTestsFor: duck self testsTakingOneArgument do: [ :method | self perform: method with: duck ]. cheers -ben

Oct. 23, 2017

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

by Volkert

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. 23, 2017

Re: [Pharo-users] Pharo/Win on a HiDPI display

by Torsten Bergmann

Hi Raffaello, see: http://forum.world.st/ANN-VistaCursor-now-scalable-td4961238.html Regards Torsten > Gesendet: Montag, 23. Oktober 2017 um 14:58 Uhr > Von: "Raffaello Giulietti" <raffaello.giulietti(a)lifeware.ch> > An: pharo-users(a)lists.pharo.org > Betreff: [Pharo-users] Pharo/Win on a HiDPI display > > Hi, > > not sure if this has already been discussed. > > I'm using Pharo/Win on a HiDPI (aka "retina") display scaled at 200%. > > Everything shows correctly scaled (widgets, fonts, icons, etc.), except > for the cursor, which is not scaled at all in Pharo, so it is rendered > half the expected size. Outside Pharo the cursor appears correctly. > > Is there something configurable in Pharo itself to overcome the tininess > of the cursor with respect to the rest of the GUI elements? > > (BTW, kudos for the otherwise excellent HiDPI support in Pharo. Nice work.) > > Greetings > Raffaello > >

Oct. 23, 2017

Re: [Pharo-users] Multi-core Software Concurrency

by Dimitris Chloupis

It all comes down to what you mean by "efficient". Obviously if you want top performance on multiple cores you dont use any of those languages including Pharo. Thats prettty much the sole reason why C++ is still a relevant language. Now if you want ok performance you could use those languages. However in real case scenarios if you are worried about multi core support then you have performance issues that you have to make sure its not the code that has to be blamed before the language. For example yesterday I was loading a PNG file via Python to display on screen via OpenGL and I was getting very slow performance 2.7 second for 1.5 mb PNG. So my assumption as always "super slow python". But I decided to give a try to another Python library and expected no more than 1.5 - 2 seconds load time for the same file. It loaded in 0.03 seconds and took some time to collect my jaw from the floor. Of course the previous library used a "pure python" approach , the other library was the usual C library wrapped for Python. So the library and the code plays a massive role, and I mention this example because Pharo works in a very similar way. If you do the code in pure Pharo, Elixir or whatever you will be hit by the performance whale of dynamic languages. Dynamic typing comes with a high cost as does a live coding enviroment. Pharo is very lucky in that it has a JIT VM espeically optimised for its language, so generally you wont get the slow speeds I got. But still C will once more run circles around a Pharo implementation , especially if its an optimised library. Thus we have the UFFI. Esteban has done an excellent job and works like a charm for using C libraries. Now if C also is proven slow then multi core wont help you much. You need the big guns , which is another name for "GPUs". A powerful GPU is even hundrends time faster than the most powerful CPU because it has thousands of cores. But those cores are designed to compute similar tasks hence why we dont throw CPUs away which are more versatile. So if you plan to do similar computations through millions of objects, multi core wont help you much, you need the big guns a very expensive and powerful GPU to do the heavy lifting. GPUs used to specialise only on Graphics, but 3d has become so complex that nowdays they can do all sort of computations and they have dedicate APIs for accesing thousands of cores via OpenCL and CUDA. Unsuprisingly they run mainly on C/C++. The good news is that through the UFFI is possible to access a GPU via Pharo, Ronie has done this. But to my experience most people dont realise what an extremely complex field performance is and how it widely fluctuates from scenario to scenario. So there is no "turbo" button to press. Now if you ask "but how I do this with pharo". Well technically you dont do this with Pharo because Pharo is made to run on CPU. GPUs run their own executables which means you have to use special compilers , good news is that they can do compiling on the fly too so Pharo can leverage that. Again Ronie's works is relevant here. If you want to avoid all the complexity and go for the simplest solution , then avoid the GPU. Because GPUs are kinda insane in terms of complexity. The easiest way is to fire up multiple Pharo and have them communicate with each other via socket or shared memory. The OS when it starts a new process it usually asigns it a core that is idle to take advantage of your multiple cores. Summary: The answer is "Pharo can do this by accessing the GPU which much faster than CPU or can access multiple cores through multiple instances running at the same time". So yes you can have top performance Pharo code if run this way, it wont be up to C standards but it will be blazzing fast none the less. On Mon, Oct 23, 2017 at 4:28 PM horrido <horrido.hobbies(a)gmail.com> wrote: > With todayâs powerful multi-core processors, the demand for efficient > software concurrency is high. We find strong support for such concurrency > in > the latest crop of âmodernâ languages such as Clojure, Elixir, Go, Haskell, > and Scala. > > Whenever I present Smalltalk (Pharo) as a great language option, inevitably > someone asks me about multi-core software concurrency. I have no response > for them. > > Do I just say that if you need concurrency, Pharo is the wrong choice? > After > all, no programming language can be good at everything. You must always > choose the right tool for the job. > > Do I say that doing concurrency right is very, very tough, even for the > most > experienced of developers? Let's focus on Pharo's strengths, instead. > Sounds > like an excuse. > > Can we safely ignore the multi-core reality? I welcome your feedback. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Oct. 23, 2017

Re: [Pharo-users] Multi-core Software Concurrency

by stephan

On 23-10-17 16:16, horrido wrote: > Yes, but isn't there an important class of concurrent software where > lightweight threads work on shared state? Isn't that the reason for > "goroutines" in Go, and STM in Clojure, and actors in Scala? There are lots of different concurrency and performance problems and solutions. For certain ones we have good solutions, others less. For some, running many images scales much better than doing something with immutable data. Solutions with good O() are not necessarily fast, nor scale well. As we run them on machines with limited capacity, the constants might dominate. Stephan

Oct. 23, 2017

UFFI with asynchronous callbacks

by Jan Cada

Hi, I would like to connect fingerprint reader to pharo - so far I am able to use C library to connect to it using UFFI, however the problem is that I can wait for fingerprint indefinitely ( blocking call to library) or register call-back for moment when fingerprint is available. The registration function returns immediately, so it is clear that the callback will be called from another thread. Is such situation supported by UFFI ? Thanks for any tip, Jan

Oct. 23, 2017

Re: [Pharo-users] String >> #asSet

by Richard Sargent

In general, when desiring a specific class, to see (Specific collection class withAll: someOtherCollectionInstance). When sending a message, you don't typically expect a given class. Rather, you should expect a set of behaviour. (In this case, an object that behaves like a set.) On Oct 23, 2017, 05:50, at 05:50, "Prof. Andrew P. Black" <black(a)cs.pdx.edu> wrote: >If you have a String (or a Symbol), and you sent it the message #asSet, >what do you expect to get as an answer? > >A set of characters, one would think. But do you care what class is >used to implement that set of characters? > >-- One argument says that it should be a Set, because thatâs what asSet >answers when it is sent to other collections. Itâs conceivable that >you might initially populate the set with Characters, but then add >other kinds of object. > >-- Another argument says that it should be a CharacterSet (or a >WideCharacterSet), because you know that the receiver contains >characters. The expression 'abcd' asSet is a convenient way to create >a CharacterSet with: $a with: $b with: $c with: $d > >-- A third argument says that you shouldnât care. If you really want a >specific class, then you should use (aString as: Set) rather than >aString asSet. > >Right now, in Pharo 7, there is a test in >TConvertAsSetForMultiplinessTest that insists that the class of the >result of asSet is actually Set. This test is already overridden once, >in IdentityBagTest, because the result of sending asSet to an >IdentityBag is not a Set â itâs an IdentitySet. So, indeed, there is >already a precedent for asSet returning a set object that is not an >instance of Set. > >I think that the test is bad, and should be changed. But this raises >the larger question: if you want to know whether or not a collection >has set-like behaviour, what is the right way of finding out? >(aCollection isKindOf: Set) reads OK, but is actually wrong, because >itâs testing the implementation, and not the behaviour. A predicate >on all collections (isSet would be the obvious name) would seem to be >indicated. And thatâs what the test should be using. > >(You might ask why CharacterSet and WideCharacterSet are not subclasses >of Set. This answer is that subclassing Set implies inheriting a hash >table, and the raison dâÃªtre for CharacterSet is that it does not use a >hash table.)

Oct. 23, 2017

Re: [Pharo-users] Multi-core Software Concurrency

by Richard Sargent

That's the GemStone model. It works well for our customers. On Oct 23, 2017 07:03, "stephan" <stephan(a)stack.nl> wrote: > On 23-10-17 15:27, horrido wrote: > >> Do I just say that if you need concurrency, Pharo is the wrong choice? >> After >> all, no programming language can be good at everything. You must always >> choose the right tool for the job. >> > > No, you tell them to use many images and/or vms. We can effectively use > state-full micro services. Immutable data is still rather inefficient and > in many cases we can avoid needing that. > > Stephan > > >

Oct. 23, 2017

Re: [Pharo-users] Multi-core Software Concurrency

by horrido

Yes, but isn't there an important class of concurrent software where lightweight threads work on shared state? Isn't that the reason for "goroutines" in Go, and STM in Clojure, and actors in Scala? Stephan Eggermont-3 wrote > On 23-10-17 15:27, horrido wrote: >> Do I just say that if you need concurrency, Pharo is the wrong choice? >> After >> all, no programming language can be good at everything. You must always >> choose the right tool for the job. > > No, you tell them to use many images and/or vms. We can effectively use > state-full micro services. Immutable data is still rather inefficient > and in many cases we can avoid needing that. > > Stephan -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 23, 2017

Re: [Pharo-users] Multi-core Software Concurrency

by stephan

On 23-10-17 15:27, horrido wrote: > Do I just say that if you need concurrency, Pharo is the wrong choice? After > all, no programming language can be good at everything. You must always > choose the right tool for the job. No, you tell them to use many images and/or vms. We can effectively use state-full micro services. Immutable data is still rather inefficient and in many cases we can avoid needing that. Stephan

Oct. 23, 2017

Multi-core Software Concurrency

by horrido

With todayâs powerful multi-core processors, the demand for efficient software concurrency is high. We find strong support for such concurrency in the latest crop of âmodernâ languages such as Clojure, Elixir, Go, Haskell, and Scala. Whenever I present Smalltalk (Pharo) as a great language option, inevitably someone asks me about multi-core software concurrency. I have no response for them. Do I just say that if you need concurrency, Pharo is the wrong choice? After all, no programming language can be good at everything. You must always choose the right tool for the job. Do I say that doing concurrency right is very, very tough, even for the most experienced of developers? Let's focus on Pharo's strengths, instead. Sounds like an excuse. Can we safely ignore the multi-core reality? I welcome your feedback. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 23, 2017

Re: [Pharo-users] Smalltalk Argument

by horrido

Of all the responses here, I like this one the best because it's right on the money. In my long career, I've been dropped into many software projects where I had to quickly ramp up with a new programming language. The employer didn't hire me for my language expertise; they hired me for my programming skill and ability to deliver good quality software on time. The programming tool used was a mere technicality, and hardly an obstacle. There is not a software developer alive who can coast through their entire career without ever needing to pick up another programming language. This is simply not an issue except for the most myopic of employers. Pharo Smalltalk Users mailing list wrote > Hi Paulo, > > I think this is not the right question to ask. > The problem is not "Where to find Smalltalk developers?", the problem is > rather > "How much effort does it take to help a good experienced OO developer to > transition to Smalltalk?" > > OO developers have to steadily gain and learn new technologies and > frameworks... > So why not Smalltalk? > Those developers that are not willing to learn a new language just > because they consider the trade-offs of not finding a job in that field > that easily, might not be the best choice for your team anyway... > > That is my experience... I know more developers missing the "Smalltalk > experience" than those hating Smalltalk once they left a team... > > Sebastian > > > On 2017-10-19 12:04 AM, Paulo R. Dellani wrote: >> Dear all, >> >> after using Smalltalk for several years I developed a passion for the >> language (how not to?), and Pharo is just so great to develop with. >> So thank you guys for keeping this wonderful project running. >> >> Unfortunately, it is not easy to always point out why Smalltalk >> should be employed as "main development language" in a team >> or for a project. In the last discussion of this sort I was confronted >> with the question "where are we going to get new smalltalk >> developers if our startup grows or if you go?". Well, I had no >> good answer to that. What would have you answered? >> >> Cheers, >> >> Paulo >> >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 23, 2017

Pharo/Win on a HiDPI display

by Raffaello Giulietti

Hi, not sure if this has already been discussed. I'm using Pharo/Win on a HiDPI (aka "retina") display scaled at 200%. Everything shows correctly scaled (widgets, fonts, icons, etc.), except for the cursor, which is not scaled at all in Pharo, so it is rendered half the expected size. Outside Pharo the cursor appears correctly. Is there something configurable in Pharo itself to overcome the tininess of the cursor with respect to the rest of the GUI elements? (BTW, kudos for the otherwise excellent HiDPI support in Pharo. Nice work.) Greetings Raffaello

Oct. 23, 2017

String >> #asSet

by Prof. Andrew P. Black

If you have a String (or a Symbol), and you sent it the message #asSet, what do you expect to get as an answer? A set of characters, one would think. But do you care what class is used to implement that set of characters? -- One argument says that it should be a Set, because thatâs what asSet answers when it is sent to other collections. Itâs conceivable that you might initially populate the set with Characters, but then add other kinds of object. -- Another argument says that it should be a CharacterSet (or a WideCharacterSet), because you know that the receiver contains characters. The expression 'abcd' asSet is a convenient way to create a CharacterSet with: $a with: $b with: $c with: $d -- A third argument says that you shouldnât care. If you really want a specific class, then you should use (aString as: Set) rather than aString asSet. Right now, in Pharo 7, there is a test in TConvertAsSetForMultiplinessTest that insists that the class of the result of asSet is actually Set. This test is already overridden once, in IdentityBagTest, because the result of sending asSet to an IdentityBag is not a Set â itâs an IdentitySet. So, indeed, there is already a precedent for asSet returning a set object that is not an instance of Set. I think that the test is bad, and should be changed. But this raises the larger question: if you want to know whether or not a collection has set-like behaviour, what is the right way of finding out? (aCollection isKindOf: Set) reads OK, but is actually wrong, because itâs testing the implementation, and not the behaviour. A predicate on all collections (isSet would be the obvious name) would seem to be indicated. And thatâs what the test should be using. (You might ask why CharacterSet and WideCharacterSet are not subclasses of Set. This answer is that subclassing Set implies inheriting a hash table, and the raison dâÃªtre for CharacterSet is that it does not use a hash table.)

Oct. 23, 2017

Re: [Pharo-users] Smalltalk Argument

by horrido

To quote from The Wisdom of the Crowd <https://hackernoon.com/the-wisdom-of-the-crowd-c7aff954bd5f> : The crowd is indeed wise. This wisdom shows up in the latest StackOverflow survey <https://insights.stackoverflow.com/survey/2017#technology-most-loved-dreade…> , as well. Under âMost Loved Languages,â Smalltalk shows up in clear second place (after Rust and before TypeScript, Swift, Go, Python, Elixir, and C#). This shows that people whoâve used Smalltalk love the language and are loyal to it. It also shows, by inference, that the programming community is not aware of how good Smalltalk is. Most in the community wallow in ignorance over it. /If they were to try Smalltalk programming, the language would very likely become popular./ itlists(a)schrievkrom.de wrote > I do not want to spoil the party (perhaps I've done this already) - but > has anyone done a serious inspection of this number: 67%. > > They have interviewed 64000 persons and 67% of the people should "love" > Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the > user already using Smalltalk "love" that. > > By the way - the most loved platform is Linux (69%) ... > > > Marten > > Am 20.10.2017 um 09:19 schrieb Paulo R. Dellani: > >> >> The second most loved language by 67% of developers surveyed cannot >> simply >> be ruled out because of unfounded concerns. (Thanks again for the > > > -- > Marten Feldtmann -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 23, 2017

Restoring an Alto

by Ben Coman

An interesting side story... A Digibarn Xerox Alto arrives for restoration https://www.youtube.com/watch?v=JSPlr4AZsKQ cheers -ben

Oct. 23, 2017

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

by Denis Kudriashov

Hi Herby. 2017-10-20 18:49 GMT+02:00 Herby VojÄÃk <herby(a)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. With help of new subclass of MockExpectedOriginalMethodCall: MockExpectedMethodResultStub>>executeFor: anOccurredMessage realMethodResult := super executeFor: anOccurredMessage. realMethodResult stub. ^realMethodResult. MockExpectedMessage>>willStubRealResult self will: MockExpectedMethodResultStub new And then you will be able specify expectations for all Foo instances: (Instance of: Foo) stub someMessage willReturn: #const 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. > >> So now you can just use simple mock which will be returned as simple >> stub from concrete constructor of your class: >> >> some := Mock new. >> >> some stub askForName: 'new'. >> >> Something stub new willReturn: some. >> >> >> I think it looks not not bad and no crazy magic is evolved. And of >> course you can replace mock with real instance if you want: >> >> some := Something new. >> >> some stub askForName: 'new'. >> >> Something stub new willReturn: some. >> >> >> >> 2017-10-20 14:21 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com >> <mailto:dionisiydk@gmail.com>>: >> >> Yes, but in that case you stub messages to the class itself. For >> your example it means: >> >> Something stub askForName willReturn: 'new'. >> >> Something askForName should be: 'new' >> >> >> >> 2017-10-20 13:58 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com >> <mailto:i.uhnak@gmail.com>>: >> >> Thanks Denis, that did the trick. >> >> But I thought that I can also mock at the class level (at least >> it was shown in the docs). >> >> Peter >> >> On Sat, Oct 7, 2017 at 11:24 AM, Denis Kudriashov >> <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> Hi Peter. >> >> You should stub instance instead of class: >> s := Something new. >> s stub askFor... >> >> 7 Ð¾ÐºÑ. 2017 Ð³. 9:18 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Peter UhnÃ¡k" >> <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: >> >> >> Hi, >> >> maybe I am missing something fundamental, because this >> seems like an obvious scenario >> >> I have a class Something with two methods >> >> Something>>askForName >> ^ UIManager default request: 'Name' >> >> Something>>name >> ^ self askForName , ' suffix' >> >> Now I want to mock out askForName, so I can run it >> automatically in tests... >> >> I've tried just stubbing it... >> >> SomethingTest>>testRenameStub >> Something stub askForName willReturn: 'new'. >> Something new name should be: 'new suffix' >> >> however it still opens the window to ask for the name, >> so the original method is being called. >> >> Right now I have to stub it with metalinks, which >> doesn't play well with some tools (hapao) >> >> SomethingTest>>testRenameMeta >> | link newName | >> link := MetaLink new >> metaObject: [ 'new' ]; >> control: #instead. >> (Something >> #askForName) ast link: link. >> [ newName := Something new name ] >> ensure: [ link uninstall ]. >> self assert: newName equals: 'new suffix' >> >> Thanks, >> Peter >> >> >> >> >> > >

Oct. 23, 2017

[ANN] SeasideTesting recovered from oblivion

by Esteban Lorenzano

Hi, I spend some days last week woking with the guys of AFI (http://afi-sa.fr <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 <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… <http://www.shaffer-consulting.com/david/Seaside/TestingComponents/TestingCo…> - some slides here (on squeak): http://esug.org/data/ESUG2005/Wednesday/2005-ESUG-Shaffer.pdf <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

Oct. 23, 2017

Re: [Pharo-users] perspective request for those earning a living from Smalltalk

by jtuchel＠objektfabrik.de

Petr, I've been working as a Consultant for many big corporations (mainly in VA Smalltalk) since 1996. The situation you describe is very well known to me. But in my opinion there is no technical reason for this. It's a managerial problem. Ever since IBM went out to their customers and told them to move to Java for the better ini the mid-90ies, managers wanted the Smalltalk projects to go away as fast as possible. Nobody asked why IBM was still happily using VisualAge Smalltalk internally at that time frame.... So the Smalltalk projects were declared legacy by Management. Replacement projects were started with big efforts and optimism. Some went well, some somewhat came to fly in a bit more than double the time and much more times the costthan planned, some failed miserably. One thing was in common to the replacement projects all over the place: they took much longer, turned out to be much mor complicated and took a lot more manpower than anybody had ever imagined. So two important things happened: 1) People were told the old Smalltalk stuff would be gone soon, so if you wanted to be a valued and appreciated staff member, you better stay away from these projects 2) The people who knew the business and technical side of the existing projects were moved to the new projects. Some liked it (because of 1) some were frustrated (because they knew / feared the new project was going to be a death march) Over the first 2 years or so, nobody realized how bad the situation really was. It was easy to postpone user requirements to the new project, accumulate more and more manpower in the new project and still keep up green flags everywhere. ...until yellow was the new green and users/stakeholders wanted the new features NOW - and not one day when the replacement project would become real. So the remaining manpower in the old project (not the ones with lots of experience and knowledge) had to extend the old system, integrate it with the new system (thereby implementing all the stuff that IBM once told their management would never be possible in Smalltalk) and keep it up and ranning year after year. Nobody ever said Thank You or would appreciate the work they did. Because that was old stuff anyways and was already irrelevant. Some of these old systems still exist today, serving users every single day, while some of the new systems never appeared. No manpower was ever added to these projects, and never would anybody ever say: okay, guys, you won. They still work on legacy code and try to do their best to fulfill user requirements. While on other projects that never see the light of day, people get appreciation, are allowed to work with new technologies and do cool stuff. Nobody ever asked the Smalltalkers whether they could do that as well, because "if you want to do web, you need to do Java". IBM said so, you know (and many other consultants as well). So this is why new people try to stay away from these old projects. This is why the remaining staff is frustrated and this is why nobody allows them to do the cool things that Smalltalk can do as well as the others. They are just required to fix bugs, add new features in the old GUIs and else keep silent. Some of them were trying to fight this and tried to prove Smalltalk's strengths, but back then nobody would listen. One day they gave up. Management still frustrates people every. single. day. Just my opinion Joachim Am 22.10.17 um 18:56 schrieb Petr Fischer: > Here. (But from one point of view, it's a litte misery, 10-20 year old code sometimes, a mess, old VAST, absolutely no interest from young colleagues with no experience to willingly learn something about Smalltalk etc etc.). > > If I bring up enough arguments, we will use Gemstone+Pharo tools in the future, which is a dream for me... but, we will see... > > pf > >> At https://news.ycombinator.com/item?id=15523807 >> the question is asked... "Does anyone on here program in Smalltalk >> professionally? Not to get off topic, but I'm curious and would like to >> know how it stacks up compared to what they did previously? " >> >> If you've earning a living from programming Smalltalk, please drop a >> comment there. >> >> cheers -ben > -- ----------------------------------------------------------------------- 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. 23, 2017

Re: [Pharo-users] About Ztimestamp

by Sven Van Caekenberghe

Hi Stef, > On 22 Oct 2017, at 17:45, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi sven > > I'm confused > > ft := ZTimestampFormat fromString: '02/11/2017'. > ft format: DateAndTime now > > produces 10/11/1017060986 > > While I do not want time but just the date. > and the date is wrong. > > So I will do it manually but I found sad that ZTimestampFormat cannot > handle just handling days. > I could then pass also a date and it would not ask for nanoseconds. > > Stef ZTimestampFormat works with example based format specifications. This works by making each component unique, using a sequential number. Consult the class comment for a full explanation. The class side's #formatSpecifications lists the tokens that are understood and their meaning. To go back to your issue, The year is the first component, written as 2001, the month the third and the day the second. So you probably want to do: (ZTimestampFormat fromString: '03/02/2001') format: DateAndTime now. => '22/10/2017' HTH, Sven

Oct. 22, 2017

Re: [Pharo-users] perspective request for those earning a living from Smalltalk

by Stephane Ducasse

Push petr! We are trying hard to make Pharo really a different programming experience and slowly we are getting there. Stef On Sun, Oct 22, 2017 at 6:56 PM, Petr Fischer <petr.fischer(a)me.com> wrote: > Here. (But from one point of view, it's a litte misery, 10-20 year old code sometimes, a mess, old VAST, absolutely no interest from young colleagues with no experience to willingly learn something about Smalltalk etc etc.). > > If I bring up enough arguments, we will use Gemstone+Pharo tools in the future, which is a dream for me... but, we will see... > > pf > >> At https://news.ycombinator.com/item?id=15523807 >> the question is asked... "Does anyone on here program in Smalltalk >> professionally? Not to get off topic, but I'm curious and would like to >> know how it stacks up compared to what they did previously? " >> >> If you've earning a living from programming Smalltalk, please drop a >> comment there. >> >> cheers -ben >

Oct. 22, 2017

[Pharo 70] Integration log

by Stephane Ducasse

Oct. 22, 2017

[Pharo 70] Integration log

by Stephane Ducasse

Oct. 22, 2017

Re: [Pharo-users] perspective request for those earning a living from Smalltalk

by Petr Fischer

Here. (But from one point of view, it's a litte misery, 10-20 year old code sometimes, a mess, old VAST, absolutely no interest from young colleagues with no experience to willingly learn something about Smalltalk etc etc.). If I bring up enough arguments, we will use Gemstone+Pharo tools in the future, which is a dream for me... but, we will see... pf > At https://news.ycombinator.com/item?id=15523807 > the question is asked... "Does anyone on here program in Smalltalk > professionally? Not to get off topic, but I'm curious and would like to > know how it stacks up compared to what they did previously? " > > If you've earning a living from programming Smalltalk, please drop a > comment there. > > cheers -ben

Oct. 22, 2017

About Ztimestamp

by Stephane Ducasse

Hi sven I'm confused ft := ZTimestampFormat fromString: '02/11/2017'. ft format: DateAndTime now produces 10/11/1017060986 While I do not want time but just the date. and the date is wrong. So I will do it manually but I found sad that ZTimestampFormat cannot handle just handling days. I could then pass also a date and it would not ask for nanoseconds. Stef

Oct. 22, 2017

Re: [Pharo-users] perspective request for those earning a living from Smalltalk

by Mariano Martinez Peck

Done :) On Sun, Oct 22, 2017 at 10:33 AM, Ben Coman <btc(a)openinworld.com> wrote: > At https://news.ycombinator.com/item?id=15523807 > the question is asked... "Does anyone on here program in Smalltalk > professionally? Not to get off topic, but I'm curious and would like to > know how it stacks up compared to what they did previously? " > > If you've earning a living from programming Smalltalk, please drop a > comment there. > > cheers -ben > -- Mariano http://marianopeck.wordpress.com

Oct. 22, 2017

perspective request for those earning a living from Smalltalk

by Ben Coman

At https://news.ycombinator.com/item?id=15523807 the question is asked... "Does anyone on here program in Smalltalk professionally? Not to get off topic, but I'm curious and would like to know how it stacks up compared to what they did previously? " If you've earning a living from programming Smalltalk, please drop a comment there. cheers -ben

Oct. 22, 2017

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

by Esteban Lorenzano

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. 22, 2017

Zinc HTTP Component HTTP/2?

by Volkert

Dear all, the world is moving to http/2. Any plans for Zinc HTTP Components to support this standard? BW, Volkert

Oct. 21, 2017

Re: [Pharo-users] Bloc texts font size

by Steven Costiou

Thanks Alex. Not much success with this trick however, do you use scaleTo:, scaleBy:.. ? and on the BlTextElement or on the BrRopedText ? It also seems that some sizes work better, like 45, 55, and 70 are ok aswell as everything under 40. I'll try to avoid the problematic sizes for the moment. Unfortunately i am on linux and have trouble with brick and Moz2D, specifically on raspberry pi - but otherwise just bloc works fine so i'll stick with it for now :) Steven. Le 2017-10-20 19:52, Aliaksei Syrel a Ã©crit : > Hi Steven, > > It is a known Cairo + Freetype bug. If you are on OSX try to install #development version of Bloc/Brick that uses Moz2D as rendering backend. > Cairo does not support named fonts because it there is no system fonts lookup. Moz2D supports it. > > One way to fix strange font size is to apply scaling by 1.0001. Text measurement will still be broken, though... > > Other than that you code looks good! > > Cheers, > Alex > On 20 October 2017 at 15:04, Steven Costiou <steven.costiou(a)kloum.io> wrote: > >> Hi, >> >> i am trying to set the font size of a BlTextElement, and i do not have much success. I use the following code to add the text element, where 'model' is a string. >> >> First, if the string is '0.0' then the font size is correct (see screenshot). But, if for example the value is '21.0' then the font size is wrong (see the other screenshot). I don't understand, i've tried variants but it seems to me that this code was the right way to do it. Sometimes, a '9' would be displayed at the correct font size, sometimes not. Any ideas ? >> >> text := BlTextElement new >> text: >> ((BrRopedText string: model) >> attributes: >> {(BrTextForegroundAttribute paint: (Color green alpha: 0.8)). >> (BrFontSizeAttribute size: 60). >> (BrFontWeightAttribute weight: 50). >> (BrFontGenericFamilyAttribute monospace). >> "(BrFontFamilyAttribute named: 'Source Sans Pro')"}); >> yourself. >> >> text >> constraintsDo: [ :c | >> c frame horizontal alignCenter. >> c frame vertical alignCenter ]. >> >> "text is added to a parent BlElement" >> self addChild: text >> >> Second, i don't have the impression that changing the font family does have any effect (but maybe its my local setup i don't know...). >> >> Steven.

Oct. 20, 2017

Re: [Pharo-users] Bloc texts font size

by Aliaksei Syrel

Hi Steven, It is a known Cairo + Freetype bug. If you are on OSX try to install #development version of Bloc/Brick that uses Moz2D as rendering backend. Cairo does not support named fonts because it there is no system fonts lookup. Moz2D supports it. One way to fix strange font size is to apply scaling by 1.0001. Text measurement will still be broken, though... Other than that you code looks good! Cheers, Alex On 20 October 2017 at 15:04, Steven Costiou <steven.costiou(a)kloum.io> wrote: > Hi, > > i am trying to set the font size of a BlTextElement, and i do not have > much success. I use the following code to add the text element, where > 'model' is a string. > > First, if the string is '0.0' then the font size is correct (see > screenshot). But, if for example the value is '21.0' then the font size is > wrong (see the other screenshot). I don't understand, i've tried variants > but it seems to me that this code was the right way to do it. Sometimes, a > '9' would be displayed at the correct font size, sometimes not. Any ideas ? > > text := BlTextElement new > text: > ((BrRopedText string: model) > attributes: > {(BrTextForegroundAttribute paint: (Color green alpha: > 0.8)). > (BrFontSizeAttribute size: 60). > (BrFontWeightAttribute weight: 50). > (BrFontGenericFamilyAttribute monospace). > "(BrFontFamilyAttribute named: 'Source Sans Pro')"}); > yourself. > > > text > constraintsDo: [ :c | > c frame horizontal alignCenter. > c frame vertical alignCenter ]. > > > "text is added to a parent BlElement" > self addChild: text > > Second, i don't have the impression that changing the font family does > have any effect (but maybe its my local setup i don't know...). > > Steven. >

Oct. 20, 2017

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

by Herby VojÄÃk

Denis Kudriashov wrote: > So you want to stub message to *any* instance of class. Right? > > Conceptually, in Mocketry/StateSpecs way, it should looks like: > > (Instance of: Something) stub askForName willReturn: 'new'. > > or: > > (Kind of: Something) stub askForName willReturn: 'new'. > > > But it will not really works. It will work only on instances which are > already "stubbed". > Making it really transparent will require crazy magic underhood. And I > am not sure that it is really possible. > Because generally it should cover existing instances and not just newly > created during test. > And for simple case: to automatically stub new instances their classes > should be stubbed with special constructors. But system do not know what > exact class side messages are constructors. 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 now you can just use simple mock which will be returned as simple > stub from concrete constructor of your class: > > some := Mock new. > > some stub askForName: 'new'. > > Something stub new willReturn: some. > > > I think it looks not not bad and no crazy magic is evolved. And of > course you can replace mock with real instance if you want: > > some := Something new. > > some stub askForName: 'new'. > > Something stub new willReturn: some. > > > > 2017-10-20 14:21 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com > <mailto:dionisiydk@gmail.com>>: > > Yes, but in that case you stub messages to the class itself. For > your example it means: > > Something stub askForName willReturn: 'new'. > > Something askForName should be: 'new' > > > > 2017-10-20 13:58 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com > <mailto:i.uhnak@gmail.com>>: > > Thanks Denis, that did the trick. > > But I thought that I can also mock at the class level (at least > it was shown in the docs). > > Peter > > On Sat, Oct 7, 2017 at 11:24 AM, Denis Kudriashov > <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > > Hi Peter. > > You should stub instance instead of class: > s := Something new. > s stub askFor... > > 7 Ð¾ÐºÑ. 2017 Ð³. 9:18 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Peter UhnÃ¡k" > <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > > Hi, > > maybe I am missing something fundamental, because this > seems like an obvious scenario > > I have a class Something with two methods > > Something>>askForName > ^ UIManager default request: 'Name' > > Something>>name > ^ self askForName , ' suffix' > > Now I want to mock out askForName, so I can run it > automatically in tests... > > I've tried just stubbing it... > > SomethingTest>>testRenameStub > Something stub askForName willReturn: 'new'. > Something new name should be: 'new suffix' > > however it still opens the window to ask for the name, > so the original method is being called. > > Right now I have to stub it with metalinks, which > doesn't play well with some tools (hapao) > > SomethingTest>>testRenameMeta > | link newName | > link := MetaLink new > metaObject: [ 'new' ]; > control: #instead. > (Something >> #askForName) ast link: link. > [ newName := Something new name ] > ensure: [ link uninstall ]. > self assert: newName equals: 'new suffix' > > Thanks, > Peter > > > >

Oct. 20, 2017

CfP <Programming> 2018: Research Papers Third Submission Deadline

by Sylvia Grewe

<Programming> 2018 : The Art, Science, and Engineering of Programming Mon 9 - Thu 12 April 2018 Nice, France http://2018.programming-conference.org/ In 2017, we started a new conference and journal focused on everything to do with programming, including the experience of programming, called <Programming> for short. The first edition of <Programming> was a great success (see http://twitter.com/programmingconf for testimonies). Paper submissions and publications are handled by the affiliated journal (http://programming-journal.org/) Accepted papers must be presented at the conference. ******************************************************** CALL FOR PAPERS ******************************************************** <Programming> 2018 accepts papers that advance knowledge of programming. Almost anything about programming is in scope, but in each case there should be a clear relevance to the act and experience of programming. UPCOMING SUBMISSION DEADLINES: December 1 2017 (Research Papers Third Submission Deadline, for journal Vol. 2, Issue 3) We accept submissions covering several areas of expertise. These areas include, but are not limited to: â¢ General-purpose programming â¢ Distributed systems programming â¢ Parallel and multi-core programming â¢ Graphics and GPU programming â¢ Security programming â¢ User interface programming â¢ Database programming â¢ Visual and live programming â¢ Data mining and machine learning programming â¢ Interpreters, virtual machines and compilers â¢ Modularity and separation of concerns â¢ Model-based development â¢ Metaprogramming and reflection â¢ Testing and debugging â¢ Program verification â¢ Programming education â¢ Programming environments â¢ Social coding ******************************************************** IMPORTANT UPCOMING DATES ******************************************************** Research paper submissions: December 1 2017 (Research Papers Third Submission Deadline, for journal Vol. 2, Issue 3) Research paper first notification (for third submission deadline): February 1 2018 Research paper revised submission (for third submission deadline): March 1 2018 Research paper final notification (for third submission deadline): March 7 2018 Camera-ready copy (for third submission deadline): March 15 2018 Student Research Competition Abstracts Submission: January 22 2018 All important dates of the journal throughout the year can also be found at http://programming-journal.org/timeline/ ******************************************************** ORGANIZATION ******************************************************** General Chair: Manuel Serrano, INRIA France Local Organizing Chair: Tamara Rezk, INRIA France Organizing Committee: Stefan Marr (workshops co-chair), University of Kent, United Kingdom Jennifer B. Sartor (workshops co-chair), Software Languages Lab, Vrije Universiteit Brussel Belgium Philipp Haller (student research competition chair), KTH Royal Institute of Technology, Sweden Tobias Pape (web technology), HPI - University of Potsdam Sylvia Grewe (publicity), Technische UniversitÃ¤t Darmstadt Germany Minh Ngo (volunteers chair), INRIA France Etienne Lozes (grants committee chair), UniversitÃ© de Nice Sophia-Antipolis, France Yves Roudier (poster chair), UniversitÃ© de Nice Sophia-Antipolis, France Program Committee: Guido Salvaneschi (program chair), Technische UniversitÃ¤t Darmstadt, Germany Davide Ancona, University of Genova, Italy Alberto Bacchelli, Delft University of Technology, Netherlands Shigeru Chiba, University of Tokyo, Japan Yvonne Coady, University of Victoria, Canada Susan Eisenbach, Imperial College London, UK Patrick Eugster, TU Darmstadt, Germany & Purdue University, United States Antonio Filieri, Imperial College London, UK Matthew Flatt, University of Utah, United States Lidia Fuentes, Universidad de MÃ¡laga, Spain Richard P. Gabriel, Dream Songs, Inc. & HPI, California Jeremy Gibbons, University of Oxford, UK Yossi Gil, Israel Institute of Technology Elisa Gonzalez Boix, Vrije Universiteit Brussel, Belgium Phlipp Haller, KTH Royal Institute of Technology, Sweden Matthew Hammer, University of Colorado, Boulder, United States Felienne Hermans, Delft University of Technology, Netherlands Robert Hirschfeld, Hasso Plattner Institute (HPI), Germany Roberto Ierusalimschy, Pontifical Catholic University of Rio de Janeiro, Brazil Jun Kato, National Institute of Advanced Industrial Science and Technology, Japan JÃ¶rg Kienzle, McGill University, Canada Neelakantan R. Krishnaswami, University of Cambridge, UK Ralf LÃ¤mmel, University of Koblenz-Landau, Germany Hidehiko Masuhara, Tokyo Institute of Technology, Japan Mira Mezini, Technische UniversitÃ¤t Darmstadt, Germany Emerson Murphy-Hill, North Carolina State University, United States Mario SÃ¼dholt, IMT Atlantique, Nantes, France Sam Tobin-Hochstadt, Indiana University, United States Eelco Visser, Delft University of Technology, Netherlands Tijs van der Storm, CWI & University of Groningen, Netherlands ******************************************************** <Programming> 2018 is kindly supported by: ACM In-Cooperation SIGPLAN (In-cooperation) SIGSOFT (In-cooperation) INRIA France AOSA ********************************************************

Oct. 20, 2017

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

by Jimmie Houchin

Thanks for the reply and for your explanation and Pharo's position on this idea and on the subject of namespaces and modules. I was simply offering a solution that was presented at Smalltalks conference. My use of Pharo is in the small. I do not in general see or know the problems associated with namespaces. I may see consequences in other people's software I use in Pharo because of the naming of classes. But it is them that dealt with the problem. I am very unqualified to comment or address either of these issues. I just didn't know who had seen the video and if it offered a solution or not. Thank you for engaging the conversation so that we have a position on record regarding a publicly available video which offers their view on a solution. You addressed one of the things I do love about Pharo and its expressed goals is that it seeks to offer real working solutions. I am okay that the hard things take time, and am happy that they are being addressed even if it takes some time. Pharo is shaping up very nicely. Thanks. Jimmie On 10/20/2017 04:07 AM, Stephane Ducasse wrote: > For the record at ESUG at Prague there was a really interesting > discussion about namespace and some people working with newspeak > mentioned that the namesapce there was a hell. And I trust these > people. So good luck. > > For the record we are working and we are making progress on module > system for Pharo but as I explained at ESUG this year. We do not want > just to have a namespace. We want a system that does not kill the live > programming experience. > Imagine you have two browsers opened: > > - in N3 one one you inherit from a class A import from N1 > - then in N1 you decide to move that class A to N2 > > Should the system discard all the subclasses from A n N3 because it > cannot find anymore the class A? > > This is why we are working on > - during year we remove harcoded reference to Smalltalk > - Undefined classes (read the IWST 2017 paper) > - new class definition > - model for class definition > - real life programming supporting module system. > > So each time I hear about namespace, I think that the best way to get > a namespace system for Pharo is to help doing something else. > This way we can concentrate on building a real working solution for > Pharo. But since we have many other things to do then it takes time. > > Stef > > > > > > On Fri, Oct 20, 2017 at 2:30 AM, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >> Absolutely. I have contemplated giving it a try. But when I go look at the >> mailing list, it looks like such a lonely place. I still might give it a go. >> It looks interesting. >> >> Jimmie >> >> >> On 10/19/2017 05:20 PM, Ben Coman wrote: >> >> btw, are you aware that Newspeak is developed on top of the CogVM that >> Pharo, Squeak, Cuis all share? >> cheers -ben >> >> On Fri, Oct 20, 2017 at 12:27 AM, Jimmie Houchin <jlhouchin(a)gmail.com> >> wrote: >>> I watched this video a year ago and was intrigued. I have not thought >>> about it deeply and do not know consequences of this model. However, Gilad >>> is a smart man who has thought deeply about these things and has experienced >>> consequences as a language designer. But it does sound interesting and I >>> wonder if it would potentially be a solution to the namespace or modularity >>> problems. >>> >>> https://youtu.be/pM0Hz4pFDZM >>> >>> He is talking about Newspeak in 2016 and what I refer to is its use of >>> Nested Classes. >>> >>> No Global Namespace >>> No Global Variables >>> No Pool Variables >>> No Class Variables >>> No Class Instance Variables >>> >>> I have no idea if it would work for Pharo or what would be involved in >>> implementing such. Or even if the community or leaders would even care to >>> explore that direction. I have not seen it discussed here. >>> >>> Just wanted to toss his discussion of these ideas into the arena of ideas >>> for Pharo. >>> >>> Jimmie >>> >>> >>> >>> On 10/13/2017 07:53 AM, Esteban A. Maringolo wrote: >>>> 2017-10-13 5:55 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: >>>>>> Am 13.10.2017 um 10:24 schrieb stephan <stephan(a)stack.nl>: >>>>>> >>>>>> On 13-10-17 09:55, Thierry Goubier wrote: >>>>>>> Because namespaces, by essence, come with serious issues. I won't take >>>>>>> someone seriously on namespaces until he can cite those faithfully. >>>>>> Let's start with the misconception that namespaces are about >>>>>> modularisation >>>>>> >>>>> +1 >>>> +1 to this as well. >>>> >>>> Having modularization is like having security, very hard to add them >>>> later if you didn't include it in the original design. >>>> >>>> I'm using VisualWorks these days, and I find its namespaces something >>>> more of a hassle than a real use. >>>> >>>> If we could name Classes with a dot, that could solve most of what >>>> namespaces are used for in practice: avoiding name colissions. >>>> That's why most of the popular frameworks have prefixes like Zn, WA, >>>> RB, and so on and so forth. But now I'm used to prefixes, I don't need >>>> them. :) >>>> >>>> Modularity is a different beast, if you look at how some modules work >>>> in JS, like AMD, you see that in practice they avoid collisions by >>>> importin what they need from a module, and assign it to a "namespace" >>>> (it is not, but works as such), so they get modules first, and >>>> namespacing later. >>>> >>>> Regards, >>>> >>>> Esteban. >>>> >>> >>

Oct. 20, 2017

ANN: Smalltalk Express Blog

by Peter Fisk

Hi everyone, I have started a new blog to discuss the "Smalltalk Express" framework. https://smalltalkexpress.quora.com/ Smalltalk Express is web development framework using a Smalltalk interpreter written in the "Go" language. The first blog post provides some details and a video. A few months ago, I built an experimental framework called "Rails Express" which had an interactive interpreter based on Ruby. The feedback that I have received has been fantastic. "Smalltalk Express" uses all the same UI techniques and is designed to be capable of production deployment. I am intending to offer "Smalltalk Express" initially as a service based on Google's App Engine, but I would be happy to hear any ideas of how to market the product. The product website will be "smalltalk.express" (smalltalk - dot - express). Thoughts and feedback are welcome. Cheers, -- Peter -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 20, 2017

Re: [Pharo-users] Smalltalk Argument

by Peter Fisk

Thank you Joachim! That is the most honest assessment of the situation of Smalltalk in 2017 that I have ever seen. And I agree with you 100%. We need a new Smalltalk which is both "cool" and can seamlessly integrate with all of the latest web technologies. I will be releasing a new Smalltalk framework very shortly called "Smalltalk Express". The interpreter is written in the "Go" language and can run on all of the major web platforms such as Google, Heroku, etc. I use Pharo to manage the Smalltalk code. Here is a new blog that I have started to discuss the project. https://smalltalkexpress.quora.com/ Also, I have reserved the web address "smalltalk.express" for use once the code goes live. There is a video in the blog post so you can get an idea of where things stand right now. -- Peter On Fri, Oct 20, 2017 at 3:23 AM, 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. 20, 2017

Re: [Pharo-users] Smalltalk Argument

by Dimitris Chloupis

Actually you need to read the small letters bellow the graph "% of developers who are developing with the language or technology and have expressed interest in continuing to develop with it" which means basically "Smalltalkers love Smalltalk !!!|" . Actually I am surpised its only 67% of Smalltalkers that actually love Smalltalk and that Rust comes first. I was expecting a 90%. But then Rust has been the most hyped language these past few years. But does not change the fact that maybe 99% of the coders have not even heard of Smalltalk and a 60% of Rust. The bottom line is that the excuses for not using a language can no longer stand in 2017 (1) But I wont find coders for it (2) But I wont find libraries for it (3) But I wont find documentation for it Let's take (1) , why you even need to find someone that already knows the language? Do we realise there are people with zero coding experience that have made built milti million dollar empires . Almost 2 decades ago I remember reading about q surfer that loved to surf but also made surf boards. So inside his naiveness said "well let's make an e-shop" and he made alone one of the first e-shops selling surf boards and he made millions. So we have this guy that knows nothing about coding, I think I remember him saying that he did not even know how to use a computer before, on one side that in a period of few years has made a multi million dollars software. On the other side we have experienced coders, that most likely have battled with code bases of millions of lines of code , university degree, masters and doctorate and they cannot do what a surfer did ? Seriously.... (2) That's my favourite , libraries. We live in 2017 when even my grandmother's language run on JVM and has JS compiler and we still debate libraries availability ? Seriously. You can use ANY library from ANY language and is not even hard. I made Pharo use Python libraries and it took me a few hundreds lines of code just to make a simple socket bridge. (3) This one is the most logical, even when I i started coding in Pharo and to be fair Pharo was still on very early releases there was minimal documentation and the one I found was outdated. Still no problemo, I am a coder, I can read code. You will be reading tons and tons of code anyway, documentation in any language will never take you far. Why ? Because the vast majority of users prefer the easy and generic features. A minority of people dive deep into a library and the ones they do rare document it. You are more likely to find specialised information in mailing and forums than in documentation documents. Of course even there you may get no answer so you end up testing and learning yourself. Wont mattter even if it is Java. Plus there are tons and ton of project made in languages very unpopular that did great, Ruby On Rails is an example. One library it was all it took to put Ruby on map. Even C was introduce through the Unix operating system. New language, out of nowhere and wait those people using an unknown language wanted to make one of the best OSes of all time. So no, even though I rarely get into a language debate because of how religious people , there is no for not using Pharo but any unpopular language out there. Because in the end what it will matter the most is the determination of the coder to output efficient code. If you are passionate about something nothing can stop you and especially these bad excuses. Pretty much the most important ingredient for any very successful software product. On Fri, Oct 20, 2017 at 11:37 AM Paulo R. Dellani <dellani(a)pobox.com> wrote: > I also do not believe my eyes: > > > https://insights.stackoverflow.com/survey/2017#most-loved-dreaded-and-wanted > > > On 10/20/2017 10:20 AM, Marten Feldtmann wrote: > > I do not want to spoil the party (perhaps I've done this already) - but > > has anyone done a serious inspection of this number: 67%. > > > > They have interviewed 64000 persons and 67% of the people should "love" > > Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the > > user already using Smalltalk "love" that. > > > > By the way - the most loved platform is Linux (69%) ... > > > > > > Marten > > > > Am 20.10.2017 um 09:19 schrieb Paulo R. Dellani: > > > >> The second most loved language by 67% of developers surveyed cannot > simply > >> be ruled out because of unfounded concerns. (Thanks again for the > > > > >

Oct. 20, 2017

Bloc texts font size

by Steven Costiou

Hi, i am trying to set the font size of a BlTextElement, and i do not have much success. I use the following code to add the text element, where 'model' is a string. First, if the string is '0.0' then the font size is correct (see screenshot). But, if for example the value is '21.0' then the font size is wrong (see the other screenshot). I don't understand, i've tried variants but it seems to me that this code was the right way to do it. Sometimes, a '9' would be displayed at the correct font size, sometimes not. Any ideas ? text := BlTextElement new text: ((BrRopedText string: model) attributes: {(BrTextForegroundAttribute paint: (Color green alpha: 0.8)). (BrFontSizeAttribute size: 60). (BrFontWeightAttribute weight: 50). (BrFontGenericFamilyAttribute monospace). "(BrFontFamilyAttribute named: 'Source Sans Pro')"}); yourself. text constraintsDo: [ :c | c frame horizontal alignCenter. c frame vertical alignCenter ]. "text is added to a parent BlElement" self addChild: text Second, i don't have the impression that changing the font family does have any effect (but maybe its my local setup i don't know...). Steven.

Oct. 20, 2017

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

by Denis Kudriashov

So you want to stub message to *any* instance of class. Right? Conceptually, in Mocketry/StateSpecs way, it should looks like: (Instance of: Something) stub askForName willReturn: 'new'. or: (Kind of: Something) stub askForName willReturn: 'new'. But it will not really works. It will work only on instances which are already "stubbed". Making it really transparent will require crazy magic underhood. And I am not sure that it is really possible. Because generally it should cover existing instances and not just newly created during test. And for simple case: to automatically stub new instances their classes should be stubbed with special constructors. But system do not know what exact class side messages are constructors. So now you can just use simple mock which will be returned as simple stub from concrete constructor of your class: some := Mock new. some stub askForName: 'new'. Something stub new willReturn: some. I think it looks not not bad and no crazy magic is evolved. And of course you can replace mock with real instance if you want: some := Something new. some stub askForName: 'new'. Something stub new willReturn: some. 2017-10-20 14:21 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Yes, but in that case you stub messages to the class itself. For your > example it means: > > Something stub askForName willReturn: 'new'. > > Something askForName should be: 'new' > > > > 2017-10-20 13:58 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> Thanks Denis, that did the trick. >> >> But I thought that I can also mock at the class level (at least it was >> shown in the docs). >> >> Peter >> >> On Sat, Oct 7, 2017 at 11:24 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> Hi Peter. >>> >>> You should stub instance instead of class: >>> s := Something new. >>> s stub askFor... >>> >>> 7 Ð¾ÐºÑ. 2017 Ð³. 9:18 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Peter UhnÃ¡k" <i.uhnak(a)gmail.com> >>> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: >>> >>> Hi, >>>> >>>> maybe I am missing something fundamental, because this seems like an >>>> obvious scenario >>>> >>>> I have a class Something with two methods >>>> >>>> Something>>askForName >>>> ^ UIManager default request: 'Name' >>>> >>>> Something>>name >>>> ^ self askForName , ' suffix' >>>> >>>> Now I want to mock out askForName, so I can run it automatically in >>>> tests... >>>> >>>> I've tried just stubbing it... >>>> >>>> SomethingTest>>testRenameStub >>>> Something stub askForName willReturn: 'new'. >>>> Something new name should be: 'new suffix' >>>> >>>> however it still opens the window to ask for the name, so the original >>>> method is being called. >>>> >>>> Right now I have to stub it with metalinks, which doesn't play well >>>> with some tools (hapao) >>>> >>>> SomethingTest>>testRenameMeta >>>> | link newName | >>>> link := MetaLink new >>>> metaObject: [ 'new' ]; >>>> control: #instead. >>>> (Something >> #askForName) ast link: link. >>>> [ newName := Something new name ] >>>> ensure: [ link uninstall ]. >>>> self assert: newName equals: 'new suffix' >>>> >>>> Thanks, >>>> Peter >>>> >>>> >> >

Oct. 20, 2017

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

by Peter UhnÃ¡k

Ah, right. I was expecting that other objects sending the message will receive the mocked result. Thanks, Peter On Fri, Oct 20, 2017 at 2:21 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Yes, but in that case you stub messages to the class itself. For your > example it means: > > Something stub askForName willReturn: 'new'. > > Something askForName should be: 'new' > > > > 2017-10-20 13:58 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> Thanks Denis, that did the trick. >> >> But I thought that I can also mock at the class level (at least it was >> shown in the docs). >> >> Peter >> >> On Sat, Oct 7, 2017 at 11:24 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> Hi Peter. >>> >>> You should stub instance instead of class: >>> s := Something new. >>> s stub askFor... >>> >>> 7 Ð¾ÐºÑ. 2017 Ð³. 9:18 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Peter UhnÃ¡k" <i.uhnak(a)gmail.com> >>> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: >>> >>> Hi, >>>> >>>> maybe I am missing something fundamental, because this seems like an >>>> obvious scenario >>>> >>>> I have a class Something with two methods >>>> >>>> Something>>askForName >>>> ^ UIManager default request: 'Name' >>>> >>>> Something>>name >>>> ^ self askForName , ' suffix' >>>> >>>> Now I want to mock out askForName, so I can run it automatically in >>>> tests... >>>> >>>> I've tried just stubbing it... >>>> >>>> SomethingTest>>testRenameStub >>>> Something stub askForName willReturn: 'new'. >>>> Something new name should be: 'new suffix' >>>> >>>> however it still opens the window to ask for the name, so the original >>>> method is being called. >>>> >>>> Right now I have to stub it with metalinks, which doesn't play well >>>> with some tools (hapao) >>>> >>>> SomethingTest>>testRenameMeta >>>> | link newName | >>>> link := MetaLink new >>>> metaObject: [ 'new' ]; >>>> control: #instead. >>>> (Something >> #askForName) ast link: link. >>>> [ newName := Something new name ] >>>> ensure: [ link uninstall ]. >>>> self assert: newName equals: 'new suffix' >>>> >>>> Thanks, >>>> Peter >>>> >>>> >> >

Oct. 20, 2017

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

by Denis Kudriashov

Yes, but in that case you stub messages to the class itself. For your example it means: Something stub askForName willReturn: 'new'. Something askForName should be: 'new' 2017-10-20 13:58 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Thanks Denis, that did the trick. > > But I thought that I can also mock at the class level (at least it was > shown in the docs). > > Peter > > On Sat, Oct 7, 2017 at 11:24 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> Hi Peter. >> >> You should stub instance instead of class: >> s := Something new. >> s stub askFor... >> >> 7 Ð¾ÐºÑ. 2017 Ð³. 9:18 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Peter UhnÃ¡k" <i.uhnak(a)gmail.com> >> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: >> >> Hi, >>> >>> maybe I am missing something fundamental, because this seems like an >>> obvious scenario >>> >>> I have a class Something with two methods >>> >>> Something>>askForName >>> ^ UIManager default request: 'Name' >>> >>> Something>>name >>> ^ self askForName , ' suffix' >>> >>> Now I want to mock out askForName, so I can run it automatically in >>> tests... >>> >>> I've tried just stubbing it... >>> >>> SomethingTest>>testRenameStub >>> Something stub askForName willReturn: 'new'. >>> Something new name should be: 'new suffix' >>> >>> however it still opens the window to ask for the name, so the original >>> method is being called. >>> >>> Right now I have to stub it with metalinks, which doesn't play well with >>> some tools (hapao) >>> >>> SomethingTest>>testRenameMeta >>> | link newName | >>> link := MetaLink new >>> metaObject: [ 'new' ]; >>> control: #instead. >>> (Something >> #askForName) ast link: link. >>> [ newName := Something new name ] >>> ensure: [ link uninstall ]. >>> self assert: newName equals: 'new suffix' >>> >>> Thanks, >>> Peter >>> >>> >

Oct. 20, 2017

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

by Peter UhnÃ¡k

Thanks Denis, that did the trick. But I thought that I can also mock at the class level (at least it was shown in the docs). Peter On Sat, Oct 7, 2017 at 11:24 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi Peter. > > You should stub instance instead of class: > s := Something new. > s stub askFor... > > 7 Ð¾ÐºÑ. 2017 Ð³. 9:18 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Peter UhnÃ¡k" <i.uhnak(a)gmail.com> > Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > > Hi, >> >> maybe I am missing something fundamental, because this seems like an >> obvious scenario >> >> I have a class Something with two methods >> >> Something>>askForName >> ^ UIManager default request: 'Name' >> >> Something>>name >> ^ self askForName , ' suffix' >> >> Now I want to mock out askForName, so I can run it automatically in >> tests... >> >> I've tried just stubbing it... >> >> SomethingTest>>testRenameStub >> Something stub askForName willReturn: 'new'. >> Something new name should be: 'new suffix' >> >> however it still opens the window to ask for the name, so the original >> method is being called. >> >> Right now I have to stub it with metalinks, which doesn't play well with >> some tools (hapao) >> >> SomethingTest>>testRenameMeta >> | link newName | >> link := MetaLink new >> metaObject: [ 'new' ]; >> control: #instead. >> (Something >> #askForName) ast link: link. >> [ newName := Something new name ] >> ensure: [ link uninstall ]. >> self assert: newName equals: 'new suffix' >> >> Thanks, >> Peter >> >>

Oct. 20, 2017

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

by Stephane Ducasse

For the record at ESUG at Prague there was a really interesting discussion about namespace and some people working with newspeak mentioned that the namesapce there was a hell. And I trust these people. So good luck. For the record we are working and we are making progress on module system for Pharo but as I explained at ESUG this year. We do not want just to have a namespace. We want a system that does not kill the live programming experience. Imagine you have two browsers opened: - in N3 one one you inherit from a class A import from N1 - then in N1 you decide to move that class A to N2 Should the system discard all the subclasses from A n N3 because it cannot find anymore the class A? This is why we are working on - during year we remove harcoded reference to Smalltalk - Undefined classes (read the IWST 2017 paper) - new class definition - model for class definition - real life programming supporting module system. So each time I hear about namespace, I think that the best way to get a namespace system for Pharo is to help doing something else. This way we can concentrate on building a real working solution for Pharo. But since we have many other things to do then it takes time. Stef On Fri, Oct 20, 2017 at 2:30 AM, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > Absolutely. I have contemplated giving it a try. But when I go look at the > mailing list, it looks like such a lonely place. I still might give it a go. > It looks interesting. > > Jimmie > > > On 10/19/2017 05:20 PM, Ben Coman wrote: > > btw, are you aware that Newspeak is developed on top of the CogVM that > Pharo, Squeak, Cuis all share? > cheers -ben > > On Fri, Oct 20, 2017 at 12:27 AM, Jimmie Houchin <jlhouchin(a)gmail.com> > wrote: >> >> I watched this video a year ago and was intrigued. I have not thought >> about it deeply and do not know consequences of this model. However, Gilad >> is a smart man who has thought deeply about these things and has experienced >> consequences as a language designer. But it does sound interesting and I >> wonder if it would potentially be a solution to the namespace or modularity >> problems. >> >> https://youtu.be/pM0Hz4pFDZM >> >> He is talking about Newspeak in 2016 and what I refer to is its use of >> Nested Classes. >> >> No Global Namespace >> No Global Variables >> No Pool Variables >> No Class Variables >> No Class Instance Variables >> >> I have no idea if it would work for Pharo or what would be involved in >> implementing such. Or even if the community or leaders would even care to >> explore that direction. I have not seen it discussed here. >> >> Just wanted to toss his discussion of these ideas into the arena of ideas >> for Pharo. >> >> Jimmie >> >> >> >> On 10/13/2017 07:53 AM, Esteban A. Maringolo wrote: >>> >>> 2017-10-13 5:55 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: >>>>> >>>>> Am 13.10.2017 um 10:24 schrieb stephan <stephan(a)stack.nl>: >>>>> >>>>> On 13-10-17 09:55, Thierry Goubier wrote: >>>>>> >>>>>> Because namespaces, by essence, come with serious issues. I won't take >>>>>> someone seriously on namespaces until he can cite those faithfully. >>>>> >>>>> Let's start with the misconception that namespaces are about >>>>> modularisation >>>>> >>>> +1 >>> >>> +1 to this as well. >>> >>> Having modularization is like having security, very hard to add them >>> later if you didn't include it in the original design. >>> >>> I'm using VisualWorks these days, and I find its namespaces something >>> more of a hassle than a real use. >>> >>> If we could name Classes with a dot, that could solve most of what >>> namespaces are used for in practice: avoiding name colissions. >>> That's why most of the popular frameworks have prefixes like Zn, WA, >>> RB, and so on and so forth. But now I'm used to prefixes, I don't need >>> them. :) >>> >>> Modularity is a different beast, if you look at how some modules work >>> in JS, like AMD, you see that in practice they avoid collisions by >>> importin what they need from a module, and assign it to a "namespace" >>> (it is not, but works as such), so they get modules first, and >>> namespacing later. >>> >>> Regards, >>> >>> Esteban. >>> >> >> > >

Oct. 20, 2017

Re: [Pharo-users] Smalltalk Argument

by stephan

On 20-10-17 09:23, jtuchel(a)objektfabrik.de wrote: > And, to be honest: what is it we actually are better in by using Smalltalk? Making software that stays maintainable. It might be survivor bias, but smalltalk systems continue to be maintained by far smaller groups of developers than competing technologies. Stephan

Oct. 20, 2017

Engineer Position 1 year

by Stephane Ducasse

Engineer Position 1 year INRIA RMoD are looking for a full-time engineer for helping with developing Pharo in the context of IoT.The focus of this job is "Pharo on embedded and mobile devices for the internet of things" With Pharo, we have developed over the last two years an interactive, remote development environment. It allows embedded, headless software running on typical raspberry pi class hardware to be developed and debugged in an interactive way. It allows programmers to explore and change running headless embedded programs from their desktop development machine. The next step will be to extend this infrastructure to cover the use case of industrial use: Deployment. We want to build a middle-ware to manage, authenticate and script deployed Pharo embedded installations. The engineer will help to develop the Pharo IoT infrastructure, especially with a focus on industrial use: Â·I mprove Pharo for a platform with an industrial focus. Â· Work on a middleware to manage deployed Pharo instances. Â·Realize two small demos: First, as an industrial IoT example, a demo deployed on 20+ devices. Demo 2: Pharo deployed on multiple mobile autonomous robots. Â·Help with creating a website for PharoIOT. We are looking for a candidate with some prior experience with Pharo. In addition: Â· Knowledge in Dynamic Languages (Pharo is a plus but not required) Â·Experience with embedded development is a plus but not required Â·English Work in a research lab, but no paper writing, no teaching, no administration. In addition: Centrally located (one hour from Paris, 1h20 from London, 35 min from Brussels) Try a lot of good beer (our office is just 10km from the border to Belgium) Program with Pharo all day! Lille is an active city but not expensive (lot of students...), centrally located with good connections by train to everywhere (including CDG and Brussels airports). Duration: 12 + 12 months Starting date: Feb or March 2016 Salary: 2600-3200 euros brut (french brutto = potentially one month of taxe per year) / month, depending on experience - (56000 Euros paid by the employer before any taxes). Location: Lille (no remote job possible) More about Pharo: http://www.pharo.org INRIA RMOD: http://rmod.lille.inria.fr INRIA Lille: http://www.inria.fr/lille INRIA in General: http://www.inria.fr Lille: http://en.wikipedia.org/wiki/Lille http://wikitravel.org/en/Lille Do not hesitate to contact us for more information. -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Oct. 20, 2017

Re: [Pharo-users] Smalltalk Argument

by Paulo R. Dellani

On 10/20/2017 10:38 AM, Pavel Krivanek wrote: > > > 2017-10-20 10:20 GMT+02:00 Marten Feldtmann <itlists(a)schrievkrom.de > <mailto:itlists@schrievkrom.de>>: > > I do not want to spoil the party (perhaps I've done this already) > - but > has anyone done a serious inspection of this number: 67%. > > They have interviewed 64000 persons and 67% of the people should > "love" > Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the > user already using Smalltalk "love" that. > > > As far as I understand it, the question was different. They asked, if > you use Smalltalk, would you like to use it the next year too (or > something like that). Then the number makes more sense. > You are right, look at the legend of the graphic: "% of developers who are developing with the language or technology and have expressed interest in continuing to develop with it" Cheers, Paulo

Oct. 20, 2017

Re: [Pharo-users] Smalltalk Argument

by Pavel Krivanek

2017-10-20 10:20 GMT+02:00 Marten Feldtmann <itlists(a)schrievkrom.de>: > I do not want to spoil the party (perhaps I've done this already) - but > has anyone done a serious inspection of this number: 67%. > > They have interviewed 64000 persons and 67% of the people should "love" > Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the > user already using Smalltalk "love" that. > As far as I understand it, the question was different. They asked, if you use Smalltalk, would you like to use it the next year too (or something like that). Then the number makes more sense. -- Pavel > > By the way - the most loved platform is Linux (69%) ... > > > Marten > > Am 20.10.2017 um 09:19 schrieb Paulo R. Dellani: > > > > > The second most loved language by 67% of developers surveyed cannot > simply > > be ruled out because of unfounded concerns. (Thanks again for the > > > -- > Marten Feldtmann > >

Oct. 20, 2017

Re: [Pharo-users] Smalltalk Argument

by Paulo R. Dellani

I also do not believe my eyes: https://insights.stackoverflow.com/survey/2017#most-loved-dreaded-and-wanted On 10/20/2017 10:20 AM, Marten Feldtmann wrote: > I do not want to spoil the party (perhaps I've done this already) - but > has anyone done a serious inspection of this number: 67%. > > They have interviewed 64000 persons and 67% of the people should "love" > Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the > user already using Smalltalk "love" that. > > By the way - the most loved platform is Linux (69%) ... > > > Marten > > Am 20.10.2017 um 09:19 schrieb Paulo R. Dellani: > >> The second most loved language by 67% of developers surveyed cannot simply >> be ruled out because of unfounded concerns. (Thanks again for the >

Oct. 20, 2017

Re: [Pharo-users] Smalltalk Argument

by Marten Feldtmann

I do not want to spoil the party (perhaps I've done this already) - but has anyone done a serious inspection of this number: 67%. They have interviewed 64000 persons and 67% of the people should "love" Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the user already using Smalltalk "love" that. By the way - the most loved platform is Linux (69%) ... Marten Am 20.10.2017 um 09:19 schrieb Paulo R. Dellani: > > The second most loved language by 67% of developers surveyed cannot simply > be ruled out because of unfounded concerns. (Thanks again for the -- Marten Feldtmann

Oct. 20, 2017

Re: [Pharo-users] Smalltalk Argument

by Paulo R. Dellani

I think you have nailed it, Joachim! The development environment is per se very productive and easy to use and learn but at the moment you need something that isn't present in your code library, things can get very hard. Well, that's not really new and not only a problem that concerns Smalltalk, but with the greater number of developers in other languages chances are that someone already wrote some code concerning your needs. Well I will go back to my coding here now ;-) Cheers, Paulo On 10/20/2017 09:23 AM, 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 > >

Oct. 20, 2017

Re: [Pharo-users] Smalltalk Argument

by jtuchel＠objektfabrik.de

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. 20, 2017

Re: [Pharo-users] Smalltalk Argument

by Paulo R. Dellani

Dear Ben, Jimmie, Stephane, Tim, Dimitris, Marten, Davorin, Stephan, Sebastian and James, thank you for your feedback! Your excellent replies will sure help me with my "Smalltalk Argument". Obviously the language cannot be employed to efficiently implement solutions for problems in all domains, but it cannot simply be ruled out just because it is not so visible as other languages clamoring for the spotlight, as Jimmie pointed out. So far I got good results that can talk for themselves thanks to Pharo/Smalltalk. So the problem here, I believe, is really Smalltalk not being the "cool kid in town", which leads to a misperception of the language by the non-versed. This can be certainly be blamed to the lack of a good business oriented OSS Smalltalk years ago, as Ben guessed, but certainly there are other factors, which are not the scope of this discussion. The fact that a good OO-software developer can learn and start to get productive in Smalltalk in a relatively short amount of time, as pointed out by several of you, will make a good argument against the concerns of my colleagues here, which are mainly non-software developers. And surely the willingness to learn a new language is a sign to be looked at in a candidate, as pointed by you too. The second most loved language by 67% of developers surveyed cannot simply be ruled out because of unfounded concerns. (Thanks again for the information, Jimmie). I think there is really a great potential here, and surely there is a greater pool of developer candidates to "draw from" than one can initially imagine/see. Cheers, Paulo On 10/20/2017 12:17 AM, Ben Coman wrote: > > > On Thu, Oct 19, 2017 at 3:04 PM, Paulo R. Dellani <dellani(a)pobox.com > <mailto:dellani@pobox.com>> wrote: > > Dear all, > > after using Smalltalk for several years I developed a passion for the > language (how not to?), and Pharo is just so great to develop with. > So thank you guys for keeping this wonderful project running. > > Unfortunately, it is not easy to always point out why Smalltalk > should be employed as "main development language" in a team > or for a project. In the last discussion of this sort I was confronted > with the question "where are we going to get new smalltalk > developers if our startup grows or if you go?". Well, I had no > good answer to that. What would have you answered? > > Cheers, > > Paulo > > > > When Smalltalk comes up on reddit, news.ycombinator, etc, > I often see comments "Used Smalltalk 10 years ago, loved it, but not > in my day job for years ..." > The guess the lack of a good business oriented OSS Smalltalk years ago > may be to blame. > Only supposition, but with the long history of Smalltalker, the pool > to draw from may be greater than first apparent. > The main problem may be that these people are not searching for > Smalltalk jobs due to the perceived availability of jobs. > > > There would obviously be some lag, but for longer term planning, talk > to your local education providers about introducing Smalltalk as the > "best" environment for teaching OO, > and then take the talented students from there.Â Consider contacting > the academic partners here... > http://consortium.pharo.org/ > > > Another approach depending on the project structure might be to "just" > prototype in Smalltalk (because its highly productive to explore a > domain with itsÂ built in data persistence) > and per Fred Brooks plan to throw it away to cleanly implement in a > mainstream language once you "know" what needs to be done.Â Â > I remember seeing one case reported here that the prototype worked so > well that the client didn't bother with the second step. > > > cheers -ben

Oct. 20, 2017

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

by Jimmie Houchin

Absolutely. I have contemplated giving it a try. But when I go look at the mailing list, it looks like such a lonely place. I still might give it a go. It looks interesting. Jimmie On 10/19/2017 05:20 PM, Ben Coman wrote: > btw, are you aware that Newspeak is developed on top of the CogVM that > Pharo, Squeak, Cuis all share? > cheers -ben > > On Fri, Oct 20, 2017 at 12:27 AM, Jimmie Houchin <jlhouchin(a)gmail.com > <mailto:jlhouchin@gmail.com>> wrote: > > I watched this video a year ago and was intrigued. I have not > thought about it deeply and do not know consequences of this > model. However, Gilad is a smart man who has thought deeply about > these things and has experienced consequences as a language > designer. But it does sound interesting and I wonder if it would > potentially be a solution to the namespace or modularity problems. > > https://youtu.be/pM0Hz4pFDZM > > He is talking about Newspeak in 2016 and what I refer to is its > use of Nested Classes. > > No Global Namespace > Â Â Â No Global Variables > Â Â Â No Pool Variables > Â Â Â No Class Variables > Â Â Â No Class Instance Variables > > I have no idea if it would work for Pharo or what would be > involved in implementing such. Or even if the community or leaders > would even care to explore that direction. I have not seen it > discussed here. > > Just wanted to toss his discussion of these ideas into the arena > of ideas for Pharo. > > Jimmie > > > > On 10/13/2017 07:53 AM, Esteban A. Maringolo wrote: > > 2017-10-13 5:55 GMT-03:00 Norbert Hartl <norbert(a)hartl.name > <mailto:norbert@hartl.name>>: > > Am 13.10.2017 um 10:24 schrieb stephan > <stephan(a)stack.nl <mailto:stephan@stack.nl>>: > > On 13-10-17 09:55, Thierry Goubier wrote: > > Because namespaces, by essence, come with serious > issues. I won't take > someone seriously on namespaces until he can cite > those faithfully. > > Let's start with the misconception that namespaces are > about modularisation > > +1 > > +1 to this as well. > > Having modularization is like having security, very hard to > add them > later if you didn't include it in the original design. > > I'm using VisualWorks these days, and I find its namespaces > something > more of a hassle than a real use. > > If we could name Classes with a dot, that could solve most of what > namespaces are used for in practice: avoiding name colissions. > That's why most of the popular frameworks have prefixes like > Zn, WA, > RB, and so on and so forth. But now I'm used to prefixes, I > don't need > them. :) > > Modularity is a different beast, if you look at how some > modules work > in JS, like AMD, you see that in practice they avoid collisions by > importin what they need from a module, and assign it to a > "namespace" > (it is not, but works as such), so they get modules first, and > namespacing later. > > Regards, > > Esteban. > > > >

Oct. 20, 2017

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

by Ben Coman

btw, are you aware that Newspeak is developed on top of the CogVM that Pharo, Squeak, Cuis all share? cheers -ben On Fri, Oct 20, 2017 at 12:27 AM, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > I watched this video a year ago and was intrigued. I have not thought > about it deeply and do not know consequences of this model. However, Gilad > is a smart man who has thought deeply about these things and has > experienced consequences as a language designer. But it does sound > interesting and I wonder if it would potentially be a solution to the > namespace or modularity problems. > > https://youtu.be/pM0Hz4pFDZM > > He is talking about Newspeak in 2016 and what I refer to is its use of > Nested Classes. > > No Global Namespace > No Global Variables > No Pool Variables > No Class Variables > No Class Instance Variables > > I have no idea if it would work for Pharo or what would be involved in > implementing such. Or even if the community or leaders would even care to > explore that direction. I have not seen it discussed here. > > Just wanted to toss his discussion of these ideas into the arena of ideas > for Pharo. > > Jimmie > > > > On 10/13/2017 07:53 AM, Esteban A. Maringolo wrote: > >> 2017-10-13 5:55 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: >> >>> Am 13.10.2017 um 10:24 schrieb stephan <stephan(a)stack.nl>: >>>> >>>> On 13-10-17 09:55, Thierry Goubier wrote: >>>> >>>>> Because namespaces, by essence, come with serious issues. I won't take >>>>> someone seriously on namespaces until he can cite those faithfully. >>>>> >>>> Let's start with the misconception that namespaces are about >>>> modularisation >>>> >>>> +1 >>> >> +1 to this as well. >> >> Having modularization is like having security, very hard to add them >> later if you didn't include it in the original design. >> >> I'm using VisualWorks these days, and I find its namespaces something >> more of a hassle than a real use. >> >> If we could name Classes with a dot, that could solve most of what >> namespaces are used for in practice: avoiding name colissions. >> That's why most of the popular frameworks have prefixes like Zn, WA, >> RB, and so on and so forth. But now I'm used to prefixes, I don't need >> them. :) >> >> Modularity is a different beast, if you look at how some modules work >> in JS, like AMD, you see that in practice they avoid collisions by >> importin what they need from a module, and assign it to a "namespace" >> (it is not, but works as such), so they get modules first, and >> namespacing later. >> >> Regards, >> >> Esteban. >> >> > >

Oct. 19, 2017

Re: [Pharo-users] Smalltalk Argument

by Ben Coman

On Thu, Oct 19, 2017 at 3:04 PM, Paulo R. Dellani <dellani(a)pobox.com> wrote: > Dear all, > > after using Smalltalk for several years I developed a passion for the > language (how not to?), and Pharo is just so great to develop with. > So thank you guys for keeping this wonderful project running. > > Unfortunately, it is not easy to always point out why Smalltalk > should be employed as "main development language" in a team > or for a project. In the last discussion of this sort I was confronted > with the question "where are we going to get new smalltalk > developers if our startup grows or if you go?". Well, I had no > good answer to that. What would have you answered? > > Cheers, > > Paulo > > > When Smalltalk comes up on reddit, news.ycombinator, etc, I often see comments "Used Smalltalk 10 years ago, loved it, but not in my day job for years ..." The guess the lack of a good business oriented OSS Smalltalk years ago may be to blame. Only supposition, but with the long history of Smalltalker, the pool to draw from may be greater than first apparent. The main problem may be that these people are not searching for Smalltalk jobs due to the perceived availability of jobs. There would obviously be some lag, but for longer term planning, talk to your local education providers about introducing Smalltalk as the "best" environment for teaching OO, and then take the talented students from there. Consider contacting the academic partners here... http://consortium.pharo.org/ Another approach depending on the project structure might be to "just" prototype in Smalltalk (because its highly productive to explore a domain with its built in data persistence) and per Fred Brooks plan to throw it away to cleanly implement in a mainstream language once you "know" what needs to be done. I remember seeing one case reported here that the prototype worked so well that the client didn't bother with the second step. cheers -ben

Oct. 19, 2017

Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

by Jimmie Houchin

I watched this video a year ago and was intrigued. I have not thought about it deeply and do not know consequences of this model. However, Gilad is a smart man who has thought deeply about these things and has experienced consequences as a language designer. But it does sound interesting and I wonder if it would potentially be a solution to the namespace or modularity problems. https://youtu.be/pM0Hz4pFDZM He is talking about Newspeak in 2016 and what I refer to is its use of Nested Classes. No Global Namespace Â Â Â No Global Variables Â Â Â No Pool Variables Â Â Â No Class Variables Â Â Â No Class Instance Variables I have no idea if it would work for Pharo or what would be involved in implementing such. Or even if the community or leaders would even care to explore that direction. I have not seen it discussed here. Just wanted to toss his discussion of these ideas into the arena of ideas for Pharo. Jimmie On 10/13/2017 07:53 AM, Esteban A. Maringolo wrote: > 2017-10-13 5:55 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: >>> Am 13.10.2017 um 10:24 schrieb stephan <stephan(a)stack.nl>: >>> >>> On 13-10-17 09:55, Thierry Goubier wrote: >>>> Because namespaces, by essence, come with serious issues. I won't take >>>> someone seriously on namespaces until he can cite those faithfully. >>> Let's start with the misconception that namespaces are about modularisation >>> >> +1 > +1 to this as well. > > Having modularization is like having security, very hard to add them > later if you didn't include it in the original design. > > I'm using VisualWorks these days, and I find its namespaces something > more of a hassle than a real use. > > If we could name Classes with a dot, that could solve most of what > namespaces are used for in practice: avoiding name colissions. > That's why most of the popular frameworks have prefixes like Zn, WA, > RB, and so on and so forth. But now I'm used to prefixes, I don't need > them. :) > > Modularity is a different beast, if you look at how some modules work > in JS, like AMD, you see that in practice they avoid collisions by > importin what they need from a module, and assign it to a "namespace" > (it is not, but works as such), so they get modules first, and > namespacing later. > > Regards, > > Esteban. >

Oct. 19, 2017

Anoying bug fond in Artefact running in Windows 10

by casimiro.barreto＠gmail.com

When you insert a jpeg from a file, for some reason the file descriptor (stream) is kept open (at least in the Windows end of things). Then, if a second page is to be generated, the following error is shown: 'MessageNotUnderstood: receiver of "reset" is nil PDFJpegElement>>stream: JPEGReadWriter aJPEGReadWriter JPEGReadWriter(ImageReadWriter)>>on: nil Sample code: aPage := PDFPage new. imageStream := FileStream fileNamed: 'lsi-tec.jpg'. aPage add: ((PDFJpegElement fromStream: imageStream) from: 15 mm @ 20 mm; dimension: 40 mm @ 40 mm). imageStream close. Generated report is in annex The only way to recover is to close pharo, start it again. Then the file descriptor (stream) is released and it is possible to go on. Has anyone faced this problem? How to solve it? Best regards, Casimiro Barreto

Oct. 19, 2017

Re: [Pharo-users] Smalltalk Argument

by Jimmie Houchin

In addition to the excellent replies you have already received I would like to offer this from Stack Overflow. In their 2017 Developer Survey,Â Smalltalk was the second most loved language at 67% of developers surveyed. This is a regular occurrence. Now if you look at the rest of the survey you will see that these are not people using Smalltalk in their job. Smalltalk doesn't appear elsewhere in the survey. It isn't on the radar. However, developers love Smalltalk. Should a shop be open minded enough to use Smalltalk, I do not think it would be difficult to find people who would love to have that opportunity. A good developer can become proficient at Smalltalk in a reasonable amount of time. In addition to the natural virtues of Smalltalk. You also have wonderful communities eager and ready to help people join the family and become productive. The Pharo and Squeak mailing lists are very friendly, with plenty of extremely knowledgeable programmers ready to help. The other nice thing about Smalltalk is that it has history. It is not a fad. It is not an immature child. Many Smalltalkers have more years experience in Smalltalk than some of the creators of other languages have birthdays. There is a vast amount of knowledge and experience in this community that doesn't exist in most places. Because of this environment, an experienced programmer can receive wisdom and understanding and become a better programmer. Do not underestimate the value of gray beard Smalltalkers. A person can read the survey and come away thinking that Smalltalk is irrelevant. It is very relevant. It just isn't as visible as other languages clamoring for the spotlight. It is mature. It doesn't care to be the cool kid. Yes, OSS Smalltalks have some weaknesses that are actively being worked on. We haven't arrived. But we are well on the journey. And to quote our favorite prophet Alan Kay, "The best way to predict the future is to invent it." Join us. Help invent the future. Use Pharo to invent the future you want. There are people out there who want to be a part of this. But they have to pay the bills. Help more people pay the bills with Smalltalk. :) Jimmie On 10/19/2017 02:04 AM, Paulo R. Dellani wrote: > Dear all, > > after using Smalltalk for several years I developed a passion for the > language (how not to?), and Pharo is just so great to develop with. > So thank you guys for keeping this wonderful project running. > > Unfortunately, it is not easy to always point out why Smalltalk > should be employed as "main development language" in a team > or for a project. In the last discussion of this sort I was confronted > with the question "where are we going to get new smalltalk > developers if our startup grows or if you go?". Well, I had no > good answer to that. What would have you answered? > > Cheers, > > Paulo > >

Oct. 19, 2017

Re: [Pharo-users] [Moose-dev] Cannot update GLMTabulator containing list with Separators

by Andrei Chis

Hi, Indeed, seems that #resetElements is missing in GLMFastListOutlineDataSource. I added in in the latest version of Moose/FastTable for Pharo 6.1. Cheers, Andrei On Wed, Oct 18, 2017 at 12:05 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > apparently it is not possible to update a GLMTabulator if it contains a > list pane with separators. Tested in P6 & P7. > > ``` > data := { { #one. #two. #three } asOrderedCollection. { #alpha. #beta } > asOrderedCollection } asOrderedCollection. > > browser := GLMTabulator new. > > browser column: #list; column: #actions. > > browser transmit to: #list; andShow: [ :a | > a fastList > withSeparators > ]. > > browser transmit to: #actions; andShow: [ :a | > a actionList > act: [ :actionList | data last add: #dynamic. browser update ] entitled: > 'Add Item'; > act: [ :actionList | data last remove: #dynamic ifAbsent: [ ]. browser > update ] entitled: 'Remove Item'. > ]. > > browser openOn: data. > ``` > > [image: Inline image 1] > > Thanks, > Peter > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > >

Oct. 19, 2017

Re: [Pharo-users] Smalltalk Argument

by Stephane Ducasse

This is super easy. - You ask here, - Second then you try to grab the best open-minded guys you know and they will use the super cool mooc and learn Pharo in a week or two. You can tell them that we are not teaching Pharo and still students good in Java learn it before their internships. For a good dev it takes really no time to catch up. Stef On Thu, Oct 19, 2017 at 9:04 AM, Paulo R. Dellani <dellani(a)pobox.com> wrote: > Dear all, > > after using Smalltalk for several years I developed a passion for the > language (how not to?), and Pharo is just so great to develop with. > So thank you guys for keeping this wonderful project running. > > Unfortunately, it is not easy to always point out why Smalltalk > should be employed as "main development language" in a team > or for a project. In the last discussion of this sort I was confronted > with the question "where are we going to get new smalltalk > developers if our startup grows or if you go?". Well, I had no > good answer to that. What would have you answered? > > Cheers, > > Paulo > >

Oct. 19, 2017

Re: [Pharo-users] Smalltalk Argument

by Tim Mackinnon

I'm sure this comes up with many less main stream languages - I think there is a strong argument (particularly if we get the GitHub piece operating smoothly) that the language is so simple that what you creating is domain understanding (not language/tools prowess). Any good developer (particularly a Ruby, Groovy, JS, Objective C or even Python) dev will find Smalltalk a doddle. The complexity is actually in the domain. We also have a vibrant and active community that has been around a long time and is willing to help as well as lots of free online training materials. Put another way - you can use a language like Java but if you left, the complexity of build and deployment and understanding the domain is a huge hurdle even though it's s popular language. I've dipped in and out of Smalltalk throughout my career and a few years ago came back after 10+ years (so had basically forgotten most of it) and was stunned that I was productive in that team after 1 day once they showed me how to inspect items in the UI and navigate to tests. I've never encountered that on a project before. Tim Sent from my iPhone > On 19 Oct 2017, at 08:04, Paulo R. Dellani <dellani(a)pobox.com> wrote: > > Dear all, > > after using Smalltalk for several years I developed a passion for the > language (how not to?), and Pharo is just so great to develop with. > So thank you guys for keeping this wonderful project running. > > Unfortunately, it is not easy to always point out why Smalltalk > should be employed as "main development language" in a team > or for a project. In the last discussion of this sort I was confronted > with the question "where are we going to get new smalltalk > developers if our startup grows or if you go?". Well, I had no > good answer to that. What would have you answered? > > Cheers, > > Paulo > >

Oct. 19, 2017

Re: [Pharo-users] Smalltalk Argument

by Dimitris Chloupis

I would have followed the Python approach. When Guido created Python , it did not try to convince his co-workers about how superior it was compared to other languages. At the time he did not intend to use it even as programming language. That worked to his advantage. Instead it used it for small tasks, usually tiny command line utilities that none would notice. But some did notice and expressed interest , they tried Python for small tiny tasks again mainly command line utilities. The co workers came back with suggestions how to improve it and the rest as they say itâs history. Any project has cracks that you can squeeze another language , the curious will the express interest and wonder âwhat this Pharo is ?â. I think that probably the best way to promote a language instead of trying to convince them how great it is. When language is used for such small tasks none will ask where they will find Smalltalk devs because itâs easy to learn any language for very simple tasks. Humans are curious by nature and they love a nice mystery. You donât have to convert an entire project to Pharo, the import thing is to ignite interest. Or as the saying goes âactions speak louder than wordsâ ;) On Thu, 19 Oct 2017 at 10:05, Paulo R. Dellani <dellani(a)pobox.com> wrote: > Dear all, > > after using Smalltalk for several years I developed a passion for the > language (how not to?), and Pharo is just so great to develop with. > So thank you guys for keeping this wonderful project running. > > Unfortunately, it is not easy to always point out why Smalltalk > should be employed as "main development language" in a team > or for a project. In the last discussion of this sort I was confronted > with the question "where are we going to get new smalltalk > developers if our startup grows or if you go?". Well, I had no > good answer to that. What would have you answered? > > Cheers, > > Paulo > > >

Oct. 19, 2017

Re: [Pharo-users] Smalltalk Argument

by itlists＠schrievkrom.de

Hello Paulo, its a problem to get Smalltalkers - simple as it is. I had contacts with Smalltalkers who wanted to do Smalltalk-"only" jobs - thats impossible to guarantee in a smaller company and perhaps a mind I would not expect from Smalltalker. And the point about "Main Development Language" ... well, the other developers have also their "beloved" language and it would be a much better idea to put their "loved" together with your "loved" language. There are *very* good reason out there to write Windows FAT-Clients in .NET languages or even Mac/Linux/Windows Clients with Xamarin/Microsoft tools or even Java-world languages and HTML-Clients with some good JS-libraries. You have to have very good reasons (and this is NOT productivity) to argue against this and tell the other developers, that you develop superior solutions just because you are doing Smalltalk. This may be true for very specific libraries (and thats not only Roassal) - not available in other systems - but in the normal case, they will simply win (because of the huge amount software written in other languages). The only Smalltalk technology I found out to be worthwhile fighting for (because other are not able to offer a similar solution) today is an object oriented database (e.g. Gemstone/S). Perhaps the Smalltalk community should concentrate on the idea to make their technology open/accessable for other languages in an easy way. This is especially true for database vendors. Database vendors offering Java, C# and python object support and Smalltalk as an integrated script language - that could be a very good argument and a place where Smalltalk can survive. So, the answer is: don't depend on the language, look for developers working with more than one language and insert Smalltalk technology where you *really* get benefit. And the area where Smalltalk is so much better is getting smaller and smaller these days. Marten Am 19.10.2017 um 09:04 schrieb Paulo R. Dellani: > Dear all, > > after using Smalltalk for several years I developed a passion for the > language (how not to?), and Pharo is just so great to develop with. > So thank you guys for keeping this wonderful project running. > > Unfortunately, it is not easy to always point out why Smalltalk > should be employed as "main development language" in a team > or for a project. In the last discussion of this sort I was confronted > with the question "where are we going to get new smalltalk > developers if our startup grows or if you go?". Well, I had no > good answer to that. What would have you answered? > > Cheers, > > Paulo > > -- Marten Feldtmann

Oct. 19, 2017

Re: [Pharo-users] Smalltalk Argument

by Davorin Rusevljan

One way to address this issue is to factor in your development grooming of young Smalltalk developers, which can act as pool of potential full developers for your project. If you can add some of your domain specific issues to their grooming, you could increase your project HR safety quite a lot. Davorin Rusevljan On Thu, Oct 19, 2017 at 9:04 AM, Paulo R. Dellani <dellani(a)pobox.com> wrote: > Dear all, > > after using Smalltalk for several years I developed a passion for the > language (how not to?), and Pharo is just so great to develop with. > So thank you guys for keeping this wonderful project running. > > Unfortunately, it is not easy to always point out why Smalltalk > should be employed as "main development language" in a team > or for a project. In the last discussion of this sort I was confronted > with the question "where are we going to get new smalltalk > developers if our startup grows or if you go?". Well, I had no > good answer to that. What would have you answered? > > Cheers, > > Paulo > > >

Oct. 19, 2017

Re: [Pharo-users] Smalltalk Argument

by James Ladd

Nice response Sent from my Commodore 64 > On 19 Oct 2017, at 7:02 pm, Sebastian Heidbrink <sheidev(a)yahoo.de> wrote: > > Hi Paulo, > > I think this is not the right question to ask. > The problem is not "Where to find Smalltalk developers?", the problem is rather > "How much effort does it take to help a good experienced OO developer to transition to Smalltalk?" > > OO developers have to steadily gain and learn new technologies and frameworks... > So why not Smalltalk? > Those developers that are not willing to learn a new language just because they consider the trade-offs of not finding a job in that field that easily, might not be the best choice for your team anyway... > > That is my experience... I know more developers missing the "Smalltalk experience" than those hating Smalltalk once they left a team... > > Sebastian > > >> On 2017-10-19 12:04 AM, Paulo R. Dellani wrote: >> Dear all, >> >> after using Smalltalk for several years I developed a passion for the >> language (how not to?), and Pharo is just so great to develop with. >> So thank you guys for keeping this wonderful project running. >> >> Unfortunately, it is not easy to always point out why Smalltalk >> should be employed as "main development language" in a team >> or for a project. In the last discussion of this sort I was confronted >> with the question "where are we going to get new smalltalk >> developers if our startup grows or if you go?". Well, I had no >> good answer to that. What would have you answered? >> >> Cheers, >> >> Paulo >> >> >> > >

Oct. 19, 2017

Re: [Pharo-users] Smalltalk Argument

by stephan

On 19-10-17 09:04, Paulo R. Dellani wrote: > Unfortunately, it is not easy to always point out why Smalltalk > should be employed as "main development language" in a team > or for a project. In the last discussion of this sort I was confronted > with the question "where are we going to get new smalltalk > developers if our startup grows or if you go?". Well, I had no > good answer to that. What would have you answered? Regularly I go to the Esug Conference and the Pharo Days, and this year I had to cancel plans to go to Smalltalks. Those are places where I talk to smalltalkers, new and experienced. Every year there are good developers there who are looking for work, as intern, as a contractor or as an employee. By being there regularly I know who to talk to for different kinds of jobs, and for recommendations. Once in a while I also visit RMoD and HPI, to talk with people teaching smalltalk. The Pharo consortium maintains a list of consultants doing smalltalk work. For a company dependent on Smalltalk, I'd develop a systematic approach to ensuring attractiveness to smalltalk developers. Participation in the Pharo Consortium and presenting at conferences about open source contributions would be part of that, as might be defining research topics or summer jobs for students. Stephan

Oct. 19, 2017