September 2015 - Pharo-users

Re: [Pharo-users] New Pharo based solution in the wild

by phil＠highoctane.be

Hi Esteban, Sad news about the app indeed. It is true that time to market is key to adoption. Nevertheless, I wish you well for the future. Keep in touch via other channels. Phil On Tue, Sep 8, 2015 at 5:16 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hi all, > > I'm bumping this thread with sad news. > > Unfortunately this solution was decommissioned more than two months ago, > after more than one and a half year of perfect uptime and no technical nor > user-requested features shortcomings. > > The reasons given weren't technical, it had more to do with a change of > our customer's top manager, who also was it's internal sponsor. The new > management "inherited" this ongoing project which wasn't fully deployed at > that moment, and their stance regarding it wasn't as proactive as with the > previous one. That plus the local economic woes during the last years > created the ideal scenario for a budget cut that let us hanging. > > Had the project been fully deployed earlier, I guess the story would have > been different. Also we heard that the new manager tried to replace our > solution with one that "he brought" without success until now. > > I'm sharing this with you in order to update the Success section of > Pharo's website. We still have the other small project, but it's future > doesn't look promising either, the current context for it is similar with > the added decline of sales (it's a mobile sales app). > > Regards, > > Esteban A. Maringolo > > ps: On the personal level these bad news were overly compensated with the > birth of my first daughter two months ago. :) > > > 2014-01-04 18:33 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > >> Great, impressive work, Esteban, thanks for sharing. >> >> I wish you luck in completing your pilot. >> >> Let us known if you need help in critical areas. >> >> Sven >> >> On 04 Jan 2014, at 20:16, Esteban A. Maringolo <emaringolo(a)gmail.com> >> wrote: >> >> > Hi all, >> > >> > After one year of negotiations (demos, quotes, etc.) and a couple of >> > months of development, by the end of December we released a pilot >> > version of our pharo based solution. >> > The solution consists of a native mobile app (Android), with Pharo 2.0 >> > servers, using Seaside for the web UI, Seaside-REST for the mobile app >> > API and Zinc Websockets to certain "live" features of the web. The >> > persistence is GLORP using the native PostgreSQL driver. >> > >> > I can't disclose much more about the customer or the solution yet, it >> > is a private solution for a multinational consumer goods company >> > operating in Argentina. >> > >> > But I can comment on the numbers: >> > * The pilot will end in ~40 days >> > * It involves 50 mobile users of the Android app using it daily. >> > * An nginx frontend for static files and http proxying to the pharo app >> servers >> > * Two pharo images as servers, one for the web interface, and one for >> > the REST API. The image is the same, they work as two separate app >> > servers to make use of each server and for improved reliability (I >> > don't want the seaside failures, which has been none yet, to affect >> > the REST API). >> > * Everything running in DigitalOcean droplets based in NYC (they add >> > ~180ms of latency from here but their price/value equations is >> > unmatched). >> > >> > Some performance numbers: >> > * The Pharo server uptime has been no less than perfect, the first 10 >> > days with uninterrupted uptime. Only shutdown to upgrade the image >> > (yesterday night). >> > * The load is minor, with peaks of ~30 concurrent mobile users during >> > a few "business" moments of the day, the server never passed 15% of >> > CPU use. The disk I/O is also small, but the database is small too >> > (growing daily). >> > >> > If the pilot succeeds the plan is to extend the user base to ~1000 >> > mobile users. But some water must pass under the bridge before >> > thinking of that. And if it ever happens, it is going to be gradual. >> > >> > Some anecdotal info >> > I quit my Smalltalk full time job at InfOil (after 9 years of >> > employment) to dedicate 100% to my new company. So I'm betting big on >> > this. By now I'm the sole Smalltalk developer (devops?) of the >> > company. Time has never been more scarce than nowadays. >> > >> > Why Pharo? >> > * Because it is the best open source Smalltalk ("inspired") out there. >> > * Because I have 10+ years of experience with Smalltalk I can't throw >> > away in the context of rapid prototyping and business domain modelling >> > (emphasis on this). >> > * It was a key advantage during the negotiations, we could show a >> > wireframed live app even before our competition prepared a PowerPoint >> > presentation. >> > >> > The development process with Pharo has been rudimentary, only >> > Monticello packages and a couple of workspace scripts to provision new >> > images. >> > I still can't get my head around Metacello. But honestly I haven't >> > dedicated as much time as it needs to be learnt. Having used VAST >> > ENVY's ConfigurationMaps successfully in the past is a proof I can >> > learn Metacello. >> > >> > During the last years at InfOil we were using git with Dolphin >> > Smalltalk, with CI after every git push to the main repo. This was >> > also linked with our issue tracking system, in order to know in which >> > build a certain issue was fixed. We used Dolphin's PAX's files (CVS >> > friendly), Gitlab, JetBrain's TeamCity and YouTrack >> > I'd like to do the same using Monticello's FileTree, BitBucket and >> > JIRA (CI server to be defined). >> > >> > Hopefully with some time, I'll be able to dive deeper into this. >> > My learning of Pharo tooling hasn't been straightforward, but maybe >> > because I'm old and spoiled with other Smalltalk dialects (VSE, VAST, >> > Dolphin). >> > I was managing the Android code (java) with git branching and merging >> > way before I learnt how to use Monticello. Managing the code (files) >> > was the only advantage of working with Eclipse/Java. Everything else >> > was a burden compared with Pharo. >> > >> > I wanted to share my experiences through a blog, but haven't had time >> > to set it up as I'd like, and by now this email is going to be all I >> > can share. After the pilot, we can talk about reporting a success >> > story for Pharo. I felt like this during the last week: >> > >> http://devopsreactions.tumblr.com/post/68251866244/successful-deployment-at… >> > >> > >> > Best regards, >> > >> > Esteban A. Maringolo >> > CTO (aka DevOps), http://trentosur.com >> > >> >> >> >

Sept. 8, 2015

Personal consultancy/development offer

by Esteban A. Maringolo

Hi all, As I shared in other mail, a few months ago one of our customers shut down the biggest project (Pharo based) of my small company, that had a big impact on the economic side but also freed a lot of my committed time. That, plus the birth of my first daughter kept me away from the keyboard from a couple of months. But now I'm coming back to the game :) My company have other prospects which, if sold, will use Pharo as a solution, but meanwhile I'm looking to work freelance in Pharo (or Smalltalk) related projects. If you know of anybody who needs a Pharo/Smalltalk developer, please let me know. Thank you! Esteban

Sept. 8, 2015

[ANN] The next Pharo Sprints at Lille

by Marcus Denker

Hello, We looked at the calendar and fixed the dates for all public sprints that we will do this year here locally. These are all Fridays: Sept 11 Oct 23 Nov 27 Dec 18 Here is the invitation for this Friday: âââââââââââââââââââââââ We will organize a Pharo sprint / Moose dojo Friday, 11th September, starting at 10:00am. (Local Time Lille). It will be at the Inria Lille, Building B, third floor (RMoD offices). Remotely, you can join us on the official IRC channel #pharo on irc.freenode.net server. During the sprint, we will try to synchronize local and remote Pharo sprinters. As the building is not open to the public, please contact us before if you plan to come.

Sept. 8, 2015

Re: [Pharo-users] New Pharo based solution in the wild

by Esteban A. Maringolo

Hi all, I'm bumping this thread with sad news. Unfortunately this solution was decommissioned more than two months ago, after more than one and a half year of perfect uptime and no technical nor user-requested features shortcomings. The reasons given weren't technical, it had more to do with a change of our customer's top manager, who also was it's internal sponsor. The new management "inherited" this ongoing project which wasn't fully deployed at that moment, and their stance regarding it wasn't as proactive as with the previous one. That plus the local economic woes during the last years created the ideal scenario for a budget cut that let us hanging. Had the project been fully deployed earlier, I guess the story would have been different. Also we heard that the new manager tried to replace our solution with one that "he brought" without success until now. I'm sharing this with you in order to update the Success section of Pharo's website. We still have the other small project, but it's future doesn't look promising either, the current context for it is similar with the added decline of sales (it's a mobile sales app). Regards, Esteban A. Maringolo ps: On the personal level these bad news were overly compensated with the birth of my first daughter two months ago. :) 2014-01-04 18:33 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Great, impressive work, Esteban, thanks for sharing. > > I wish you luck in completing your pilot. > > Let us known if you need help in critical areas. > > Sven > > On 04 Jan 2014, at 20:16, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > > Hi all, > > > > After one year of negotiations (demos, quotes, etc.) and a couple of > > months of development, by the end of December we released a pilot > > version of our pharo based solution. > > The solution consists of a native mobile app (Android), with Pharo 2.0 > > servers, using Seaside for the web UI, Seaside-REST for the mobile app > > API and Zinc Websockets to certain "live" features of the web. The > > persistence is GLORP using the native PostgreSQL driver. > > > > I can't disclose much more about the customer or the solution yet, it > > is a private solution for a multinational consumer goods company > > operating in Argentina. > > > > But I can comment on the numbers: > > * The pilot will end in ~40 days > > * It involves 50 mobile users of the Android app using it daily. > > * An nginx frontend for static files and http proxying to the pharo app > servers > > * Two pharo images as servers, one for the web interface, and one for > > the REST API. The image is the same, they work as two separate app > > servers to make use of each server and for improved reliability (I > > don't want the seaside failures, which has been none yet, to affect > > the REST API). > > * Everything running in DigitalOcean droplets based in NYC (they add > > ~180ms of latency from here but their price/value equations is > > unmatched). > > > > Some performance numbers: > > * The Pharo server uptime has been no less than perfect, the first 10 > > days with uninterrupted uptime. Only shutdown to upgrade the image > > (yesterday night). > > * The load is minor, with peaks of ~30 concurrent mobile users during > > a few "business" moments of the day, the server never passed 15% of > > CPU use. The disk I/O is also small, but the database is small too > > (growing daily). > > > > If the pilot succeeds the plan is to extend the user base to ~1000 > > mobile users. But some water must pass under the bridge before > > thinking of that. And if it ever happens, it is going to be gradual. > > > > Some anecdotal info > > I quit my Smalltalk full time job at InfOil (after 9 years of > > employment) to dedicate 100% to my new company. So I'm betting big on > > this. By now I'm the sole Smalltalk developer (devops?) of the > > company. Time has never been more scarce than nowadays. > > > > Why Pharo? > > * Because it is the best open source Smalltalk ("inspired") out there. > > * Because I have 10+ years of experience with Smalltalk I can't throw > > away in the context of rapid prototyping and business domain modelling > > (emphasis on this). > > * It was a key advantage during the negotiations, we could show a > > wireframed live app even before our competition prepared a PowerPoint > > presentation. > > > > The development process with Pharo has been rudimentary, only > > Monticello packages and a couple of workspace scripts to provision new > > images. > > I still can't get my head around Metacello. But honestly I haven't > > dedicated as much time as it needs to be learnt. Having used VAST > > ENVY's ConfigurationMaps successfully in the past is a proof I can > > learn Metacello. > > > > During the last years at InfOil we were using git with Dolphin > > Smalltalk, with CI after every git push to the main repo. This was > > also linked with our issue tracking system, in order to know in which > > build a certain issue was fixed. We used Dolphin's PAX's files (CVS > > friendly), Gitlab, JetBrain's TeamCity and YouTrack > > I'd like to do the same using Monticello's FileTree, BitBucket and > > JIRA (CI server to be defined). > > > > Hopefully with some time, I'll be able to dive deeper into this. > > My learning of Pharo tooling hasn't been straightforward, but maybe > > because I'm old and spoiled with other Smalltalk dialects (VSE, VAST, > > Dolphin). > > I was managing the Android code (java) with git branching and merging > > way before I learnt how to use Monticello. Managing the code (files) > > was the only advantage of working with Eclipse/Java. Everything else > > was a burden compared with Pharo. > > > > I wanted to share my experiences through a blog, but haven't had time > > to set it up as I'd like, and by now this email is going to be all I > > can share. After the pilot, we can talk about reporting a success > > story for Pharo. I felt like this during the last week: > > > http://devopsreactions.tumblr.com/post/68251866244/successful-deployment-at… > > > > > > Best regards, > > > > Esteban A. Maringolo > > CTO (aka DevOps), http://trentosur.com > > > > >

Sept. 8, 2015

Re: [Pharo-users] Modifying the AST of a method

by Marcus Denker

> On 08 Sep 2015, at 03:02, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > From GÃ¼nter Khyo: > > GÃ¼nter Khyo wrote >> Hello! >> >> I want to replace particular nodes of an AST (such as Assignments or Self >> sends) with my own nodes. >> Is there an easy (high-level) way to do this without being familiar with >> the entire compiler infrastructure? >> >> The problem I am having is that AST nodes maintain internal state such as >> parent links and, in the case of RBVariables, links to scopes and >> bindings. There might be many other dependencies I am missing and missing >> one of them can trigger exceptions with stack traces buried deep in the IR >> Code-Generator and visitor calls. >> >> For example, if I want to replace an assignment such as >> >> Morph>>position: aPoint >> >> "box := self fullBounds." >> >> with something like >> >> "self assignAndNotifiyDependents: self fullBounds to: 'box' " >> >> Btw: I know there is a rewrite tool, but I want to do it programmatically. Hello, With Pharo5 there are two mechanism that can help you. 1) MetaLinks (aka reflectivity). ======================= They allow you to reflectively define that a meta object to be called before/after or instead of an AST node. as you want to do something in addition here, you can add the notification as a #before link: link := MetaLink new metaObject: #object; selector: #assignAndNotifiyDependents:; arguments: #(newValue). this is a link that when installed on an AssignmentNode, will call #assignAndNotifiyDependents on the object with the new value (the to be assigned value) as the argument. To install this on all ivar assignments, do: MyClass assignmentNodes do: [ :each | each variable isInstance ifTrue: [each link: link ]]. to get rid of the link: link uninstall But MetaLinks are very hidden: you do not see them in your design. So they should be used with care. 2) First class Instance variable (aka Slots). ================================= In your example, what you really want is a âspecialâ kind of variable that always notifies depends. Wouldnât it be nice if you could define such a special kind of Variable and, in the class definition of you class, specify that the ivar âboxâ is that special kind? In Pharo5, you can do just that. 1) define your special variable. IndexedSlot subclass: #NotifyDependsSlot slots: { } classVariables: { } category: 'Demoâ change what it means to write these kind of variables by implementing: write: aValue to: anObject super write: aValue to: anObject. anObject assignAndNotifiyDependents: aValue. Now change the class definition of your class to make âboxâ into this special kind of variable: Object subclass: #MyClass slots: { #box => NotifyDependsSlot } classVariables: { } category: âDemo' DONE. Ah, but reflective slot write is slow, so if you use this a lot, add these two method: emitValue: methodBuilder methodBuilder pushInstVar: index. emitStore: methodBuilder | tempName | tempName := Object new. methodBuilder addTemp: tempName; storeTemp: tempName; pushReceiver; pushTemp: tempName; send: #assignAndNotifiyDependents:; popTop; storeInstVar: index. These generate byte code inline for the read and write instead of calling the #write:to: method. (I attach a fillout of MyClass that i used to test this)

Sept. 8, 2015

Re: [Pharo-users] Mathex: Generating latex math from Pharo.

by Damien Cassou

Julien Delplanque <julien(a)tamere.eu> writes: > On 07/09/15 13:56, Damien Cassou wrote: >> Julien Delplanque <julien(a)tamere.eu> writes: >>> >>> (Phi equal: ((1 asMathex + 5 asMathex sqrt) // 2)) equation asString. >>> >>> and get: >>> >>> \begin{equation} >>> \phi=\frac{ 1 +\sqrt{ 5 }}{ 2 }\end{equation} >> >> I think that's great news! One of Pillar's feature requests is to let >> users write LaTeX (e.g., formulas) in their pillar document and get nice >> results in all exports (LaTeX, HTML, ePub...): >> https://github.com/pillar-markup/pillar/issues/18. I'm not sure how this >> request fits in your work, but there might be some intersection. >> > I guess if a latex math parser is created, it is possible to use objects > from Mathex to represent an equation as Mathex objects. > > After that the translation to html should be easy. > > Maybe I'll give a try if I have some time. we could ask the Pillar users to write using Mathex directly so we don't have to write a LaTeX parser. The only remaining thing is to generate png pictures from Mathex objects for inclusion in HTML. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Sept. 8, 2015

Re: [Pharo-users] Creating class with empty Catagory!

by Ben Coman

On Tue, Sep 8, 2015 at 5:28 PM, Volkert <volkert(a)komponentenwerkstatt.de> wrote: > Would it be nicer to open a Alert box? > Yes. Now maybe it should not be done directly from here... SlotClassBuilder >> category: aCategory aCategory isEmpty ifTrue: [ InvalidPackageName signal: 'The Category should not be empty' ]. category := aCategory ...since that might(?) introduce a dependency from the kernel to the UI. But maybe further down the stack in one of... PackageTreeNautilusUI(AbstractNautilusUI) >> compileAClassFrom: aString notifying: aController >> compileSource: aText notifying: aController there could be an error handler. Would you like to have a go at it? cheers -ben

Sept. 8, 2015

Re: [Pharo-users] Creating class with empty Catagory!

by Marcus Denker

Yes, this could definitely be inmproved. An idea would be a dialog with a pre-filled class definition that has useful defaults. This way when demoing, you can just accept the empty and nevertheless a class is created just by pressing âokâ in this dialog. > On 08 Sep 2015, at 11:28, Volkert <volkert(a)komponentenwerkstatt.de> wrote: > > Would it be nicer to open a Altert box? > > BW, > Volkert > > <gabhajcb.png>

Sept. 8, 2015

Re: [Pharo-users] "Create initializer with inst vars" is broken

by Volkert

Done https://pharo.fogbugz.com/f/cases/16514/Create-initializer-with-inst-vars-i… On 08.09.2015 10:25, Marcus Denker wrote: > I donât tjhink soâ¦ can you add an issue to the issue tracker? > >> On 08 Sep 2015, at 09:34, Volkert <volkert(a)komponentenwerkstatt.de> wrote: >> >> >> >> Is this a known bug? >> >> <iffeijhg.png> >> >> >> leads to ... >> >> <egjiahcj.png> >> >> Pharo 4.0 / build 40621 >> >> BW, >> Volkert >> >> >> >

Sept. 8, 2015

Creating class with empty Catagory!

by Volkert

Would it be nicer to open a Altert box? BW, Volkert

Sept. 8, 2015