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

Re: [Pharo-users] [Ann] Blog entry about using Pharo / Smalltalk to build a bot

by john pfersich

+1 Sent from my iPhone > On Aug 17, 2017, at 06:11, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > there was one claim you made in that post that got me thinking > > ""No one else knows Smalltalk." > > So I wonder how many developers amount to "no one". > > Now my data is questionable to say the least but I dont think I am very far from the truth. > > According to a quick estimate I found online there are 18.500.000 developers , around half of that are pros > Now Tiobe Index has some numbers about language popularity, widely disputed but I will use that. Unfortunately Smalltalk does not even make top 50 but I think its close to that because it used to be in the top 50 of Tiobe Index once .... so .... 50th is around 0,4% which means that smalltalk is probably at least 0.1% Now if we multiply with the total amount of developers > > No | Name of Language | Percentage of Popularity | Amount of total develpers > --------------------------------------------------------------------------------------------------------- > 1) Java 13% = 2.405.000 > 2) C 6,5% = 1.202.500 > 3) C++ 5,5% = 1.017.500 > 4) C# 4,2% = 777.000 > 5) Python 3,7% = 684.500 > 6) VB .NET 2,6% > 7) PHP 2,3% > 8) Javascript 2,1% > 9) Pearl 2% > 10) Ruby 2% > 11) Swift 1,8% > 12) Delphi 1,8% > 13) Visual Basic 1,8% > 14) Assembly 1,8% > 15) R 1,8% > 16) Go 1,7% > 17) Matlab 1,6% > 18) Objective C 1,5% > 19) Scratch 1,5 % > 20) Dart 1,3% > 26) Cobol 1% = 185.000 > 28) Scala 0,9% > 31) Erlang 0,7% > 34) Lisp 0,7% > 35) Fortan 0,7% > 36) Lua 0,7% > 47) Haskell 0,5% > 120) Smalltalk 0,1% = 18.500 > > I made up the position of smalltalk and its percentage but if you see how percentages are from language to language you will have to agree that I cannot be very far. > So the bad news is the sources are questionable to say the least the good news is however that we are close to the truth because the Python devs have also reported 1 million users. Now if this is so close to the truth that means two massively important things. I also know for a fact that on its popular days Delphi used to also have 1 million devs so its percentage is close to reality as well. The general picture is that the math at least seems to hold up. > > So what is the conclusion out of this ? > > 1) The vast majority of the popular languages , apart from Java, are not anywhere near as popular as they imply. Especially Javascript with only 300k developer , by the noise they generate you would believe they are like 300 million. Once you leave the top 5 , pretty much every language is very close. > 2) 18.500 is nowhere near close to "no one" its actually closer to a small town or a very large village. So definitely a significant amount of Smalltalk devs. > 3) Coders use pretty much every language out there and they do not concentrate on few popular ones > > On the other hand there are all sort of numbers online , one source gives Java over 6 million devs. But I do not think that the exact matter matters rather the general picture. > > I have found the whole thing mind blowing to say the least and it completely reduces the meaning of "language popularity" showing that judging the popularity of the language by the noise it generates on the net is definitely a terrible metric. > > I am willing to bet that Pharo has around 3-6.000 users which is definitely not bad. > > Thank you for opening my eyes, I will from now on fight the illusion of language popularity. > > Oh yes I loved your post, very well written, excellent work > >> On Tue, Aug 15, 2017 at 9:24 PM sergio ruiz <sergio.rrd(a)gmail.com> wrote: >> Hey, all.. >> >> I just released a blog entry entitled: >> >> "Why I chose Pharo Smalltalk to build my Bot project" >> >> which can be viewed here: >> >> http://www.codeandmusic.com/why-i-chose-pharo-smalltalk-to-build-my-bot/?ut… >> >> I would appreciate (and probably create new posts about) any input.. >> >> Thanks! >> >> >> ---- >> peace, >> sergio >> photographer, journalist, visionary >> >> Public Key: http://bit.ly/29z9fG0 >> #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV >> http://www.Village-Buzz.com >> http://www.ThoseOptimizeGuys.com >> http://www.coffee-black.com >> http://www.painlessfrugality.com >> http://www.twitter.com/sergio_101 >> http://www.facebook.com/sergio101

Aug. 17, 2017

Re: [Pharo-users] [ANN] PharoLambda 1.5 - Pharo running on AWS Lambda now with saved Debug sessions via S3

by Guillermo Polito

On Thu, Aug 17, 2017 at 8:51 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Tim, > > On Thu, Aug 17, 2017 at 01:07:06PM +0100, Tim Mackinnon wrote: > > Just thought I would report back a bit more on this - > > > > The Unicode change doesn?t work in my case (possibly not for command > line Pharo > > as well) as I get an error where OS filename?s need unicode support > (actually I > > think this is where its trying to write to stdout, but I didn?t dig more > into > > this): > > > > Error: Instances of UndefinedObject are not indexable > > UndefinedObject(Object)>>error: > > UndefinedObject(Object)>>errorNotIndexable > > UndefinedObject(Object)>>size > > Unicode class>>isLetter: > > Character>>isLetter > > Path class>>isAbsoluteWindowsPath: > > Path class>>from:delimiter: > > MacStore(FileSystemStore)>>pathFromString: > > FileSystem>>pathFromString: > > ByteString(String)>>asPathWith: > > FileSystem>>pathFromObject: > > FileSystem>>referenceTo: > > ByteString(String)>>asFileReference > > FileStream class>>fullName: > > FileStream class>>fileNamed: > > SmalltalkImage>>openLog > > #size is only sent to UniCode's class variable GeneralCategory in > #isLetter:. > > Are you sure that while preparing your image for deployment you didn't > clear GeneralCategory accidentally? (in my image GeneralCategory is an > instance of a SparseLargeTable) > Indeed, he did it on purpose trying to save 1.5MB of memory :P > > HTH, > Alistair > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 17, 2017

Re: [Pharo-users] [ANN] PharoLambda 1.5 - Pharo running on AWS Lambda now with saved Debug sessions via S3

by Alistair Grant

Hi Tim, On Thu, Aug 17, 2017 at 01:07:06PM +0100, Tim Mackinnon wrote: > Just thought I would report back a bit more on this - > > The Unicode change doesn?t work in my case (possibly not for command line Pharo > as well) as I get an error where OS filename?s need unicode support (actually I > think this is where its trying to write to stdout, but I didn?t dig more into > this): > > Error: Instances of UndefinedObject are not indexable > UndefinedObject(Object)>>error: > UndefinedObject(Object)>>errorNotIndexable > UndefinedObject(Object)>>size > Unicode class>>isLetter: > Character>>isLetter > Path class>>isAbsoluteWindowsPath: > Path class>>from:delimiter: > MacStore(FileSystemStore)>>pathFromString: > FileSystem>>pathFromString: > ByteString(String)>>asPathWith: > FileSystem>>pathFromObject: > FileSystem>>referenceTo: > ByteString(String)>>asFileReference > FileStream class>>fullName: > FileStream class>>fileNamed: > SmalltalkImage>>openLog #size is only sent to UniCode's class variable GeneralCategory in #isLetter:. Are you sure that while preparing your image for deployment you didn't clear GeneralCategory accidentally? (in my image GeneralCategory is an instance of a SparseLargeTable) HTH, Alistair

Aug. 17, 2017

Re: [Pharo-users] Preference to for not showing hidden files in the FileBrowser?

by Peter Uhnak

There's no such option. I've created File Dialog ( https://github.com/peteruhnak/file-dialog ) which will be in P7 when I find the time to go through the incorporation process... which practically means September... Peter On Thu, Aug 17, 2017 at 01:05:25PM +0200, Guillermo Polito wrote: > On Wed, Aug 16, 2017 at 1:26 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > > > Hello > > > > Is there a preference for not showing hidden files in the FileBrowser? > > > > I don't think such preference exists, sorry... Maybe implementing it would > not be so hard? > > > > I checked menu 'System' -> 'Settings' searching for 'hidden'. > > This is on Ubuntu, i.e. hidden files start with a dot. > > > > Thank you for the answer in advance > > > > Hannes > > > > > > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13

Aug. 17, 2017

Re: [Pharo-users] Looking for small boards and tiny computers which can run Pharo

by Marcus Denker

> On 24 Jul 2017, at 21:30, Steven Costiou <steven.costiou(a)kloum.io> wrote: > > Hi, > > i am looking for: > > - small hardware, boards/computers, "embeddable" devices, etc. that can run Pharo (except Raspberry pi that i already know) > > - robots, flying drones or things alike with an open linux which can possibly run Pharo > > For Drones, this looks interesting: http://beagleboard.org/blue <http://beagleboard.org/blue> Itâs compatible to the beaglebone black (itâs a beagle bone black + lots of I/O for robotics). Another nice platform is the NanoPI, we have managed to run Pharo on this: http://www.friendlyarm.com/index.php?route=product/product&path=69&product_… <http://www.friendlyarm.com/index.php?route=product/product&path=69&product_…> There are now many variations/newer versions (64bit, wirelessâ¦). Marcus

Aug. 17, 2017

Re: [Pharo-users] [Ann] Blog entry about using Pharo / Smalltalk to build a bot

by Dimitris Chloupis

there was one claim you made in that post that got me thinking ""No one else knows Smalltalk." So I wonder how many developers amount to "no one". Now my data is questionable to say the least but I dont think I am very far from the truth. According to a quick estimate I found online there are 18.500.000 developers , around half of that are pros Now Tiobe Index has some numbers about language popularity, widely disputed but I will use that. Unfortunately Smalltalk does not even make top 50 but I think its close to that because it used to be in the top 50 of Tiobe Index once .... so .... 50th is around 0,4% which means that smalltalk is probably at least 0.1% Now if we multiply with the total amount of developers No | Name of Language | Percentage of Popularity | Amount of total develpers --------------------------------------------------------------------------------------------------------- 1) Java 13% = 2.405.000 2) C 6,5% = 1.202.500 3) C++ 5,5% = 1.017.500 4) C# 4,2% = 777.000 5) Python 3,7% = 684.500 6) VB .NET 2,6% 7) PHP 2,3% 8) Javascript 2,1% 9) Pearl 2% 10) Ruby 2% 11) Swift 1,8% 12) Delphi 1,8% 13) Visual Basic 1,8% 14) Assembly 1,8% 15) R 1,8% 16) Go 1,7% 17) Matlab 1,6% 18) Objective C 1,5% 19) Scratch 1,5 % 20) Dart 1,3% 26) Cobol 1% = 185.000 28) Scala 0,9% 31) Erlang 0,7% 34) Lisp 0,7% 35) Fortan 0,7% 36) Lua 0,7% 47) Haskell 0,5% 120) Smalltalk 0,1% = 18.500 I made up the position of smalltalk and its percentage but if you see how percentages are from language to language you will have to agree that I cannot be very far. So the bad news is the sources are questionable to say the least the good news is however that we are close to the truth because the Python devs have also reported 1 million users. Now if this is so close to the truth that means two massively important things. I also know for a fact that on its popular days Delphi used to also have 1 million devs so its percentage is close to reality as well. The general picture is that the math at least seems to hold up. So what is the conclusion out of this ? 1) The vast majority of the popular languages , apart from Java, are not anywhere near as popular as they imply. Especially Javascript with only 300k developer , by the noise they generate you would believe they are like 300 million. Once you leave the top 5 , pretty much every language is very close. 2) 18.500 is nowhere near close to "no one" its actually closer to a small town or a very large village. So definitely a significant amount of Smalltalk devs. 3) Coders use pretty much every language out there and they do not concentrate on few popular ones On the other hand there are all sort of numbers online , one source gives Java over 6 million devs. But I do not think that the exact matter matters rather the general picture. I have found the whole thing mind blowing to say the least and it completely reduces the meaning of "language popularity" showing that judging the popularity of the language by the noise it generates on the net is definitely a terrible metric. I am willing to bet that Pharo has around 3-6.000 users which is definitely not bad. Thank you for opening my eyes, I will from now on fight the illusion of language popularity. Oh yes I loved your post, very well written, excellent work On Tue, Aug 15, 2017 at 9:24 PM sergio ruiz <sergio.rrd(a)gmail.com> wrote: > Hey, all.. > > I just released a blog entry entitled: > > "Why I chose Pharo Smalltalk to build my Bot project" > > which can be viewed here: > > > http://www.codeandmusic.com/why-i-chose-pharo-smalltalk-to-build-my-bot/?ut… > > I would appreciate (and probably create new posts about) any input.. > > Thanks! > > > ---- > peace, > sergio > photographer, journalist, visionary > > Public Key: http://bit.ly/29z9fG0 > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > http://www.Village-Buzz.com <http://www.village-buzz.com/> > http://www.ThoseOptimizeGuys.com <http://www.thoseoptimizeguys.com/> > http://www.coffee-black.com > http://www.painlessfrugality.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 >

Aug. 17, 2017

Re: [Pharo-users] [ANN] PharoLambda 1.5 - Pharo running on AWS Lambda now with saved Debug sessions via S3

by Tim Mackinnon

Actually it looks like that extra 1.5mb is not worth having as It seems that something does end up using the class organisation and so it must recompute when the image is launched. Tim > On 17 Aug 2017, at 13:07, Tim Mackinnon <tim(a)testit.works> wrote: > > Just thought I would report back a bit more on this - > > The Unicode change doesnât work in my case (possibly not for command line Pharo as well) as I get an error where OS filenameâs need unicode support (actually I think this is where its trying to write to stdout, but I didnât dig more into this): > > Error: Instances of UndefinedObject are not indexable > UndefinedObject(Object)>>error: > UndefinedObject(Object)>>errorNotIndexable > UndefinedObject(Object)>>size > Unicode class>>isLetter: > Character>>isLetter > Path class>>isAbsoluteWindowsPath: > Path class>>from:delimiter: > MacStore(FileSystemStore)>>pathFromString: > FileSystem>>pathFromString: > ByteString(String)>>asPathWith: > FileSystem>>pathFromObject: > FileSystem>>referenceTo: > ByteString(String)>>asFileReference > FileStream class>>fullName: > FileStream class>>fileNamed: > SmalltalkImage>>openLog > > I was able to improve on Guilleâs warning about how to safely clear up monticello/metacello (and not use become: String new) with the following (I actually think Metacello should provide a #cleanUp method, so I raised a pr for consideration) > logger cr; nextPutAll: '>Removing Clearing MC Registry'. > MetacelloProjectRegistration resetRegistry. > > Iâm then able to be by image down from 22mb to 13.8 (which is pretty good). > > As a further experiment I also noticed that there is a fair amount of space trapped in Protocols and ClassOrganisation - so I tried clearing those out (as they are lazily cached) with: > Smalltalk allClassesAndTraits do: [:c | c basicOrganization: nil ]. > This seems to give me a further 1mb back (but I haveât tried performance tests on this, but my naive assumption is that in a running system that isnât adding/manipulating code - that I donât think Protocols are used?). So Iâm now at 21mb. > > Tim > >> On 16 Aug 2017, at 10:53, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >> >> >> >> On Wed, Aug 16, 2017 at 11:46 AM, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >> Hi, tracing through your changes - it looks like: >> >> Smalltalk cleanUp: true except: #() confirming: false. >> Takes care of all the non-unicode changes you proposed (and it seems like its a known cleanup protocol). >> >> I based my script on #cleanupForRelease ^^. But I did not just blindly execute it as is because I wanted to understand the implications of each line. >> >> I wonder if the Unicode change is worth it/risky as many web based services I might connect to with Zinc do support Unicode so maybe I should keep that one in. (I will for now - might verify how much of a difference it really makes) >> >> No, it should not break any encoding/decoding. The changes I proposed will just nil out two things: >> >> - the uppercase/lowercase mapping unicode tables that says for each codepoint if the codepoint is uppercase/lowercase and allows transformations from/to uppercase/lowercase. This means that these may not work as expected: >> >> aChar asLowercase >> aChar asUppercase >> aChar toLowercase >> aChar toUppercase >> >> - the unicode classification table that says if a character is letter or digit, and so on. This means that these may not work as expected: >> >> aChar isLetter >> aChar isDigit >> aChar isAlphaNumeric >> >> I think my next port of call is cleanUp for Monticello/Metacello as I see a fair amount of that stuff floating around in my image (after Iâve used it to bootstrap my code). >> >> Tim >> >>> On 16 Aug 2017, at 02:32, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >>> >>> Actually it happens first that monticello is "nicely" coupled with the changeset system and logs all the source code loaded in change sets :D :/ Â¬Â¬. Also, the first two strings in terms of size are related to unicode tables (we should put them in files instead of in the image and load them on demand), and the two biggest arrays also to unicode. I just tried the following in a clean bootstrapped "minimal" image (metacello): >>> >>> "Careful, this will make that #isLetter, #isUppercase #isLowercase, #toLowercase and #toUppercase only work on ascii" >>> Character characterSet: nil. >>> Unicode classPool at: #GeneralCategory put: nil. >>> Unicode classPool at: #DecimalProperty put: nil. >>> >>> UnicodeDefinition removeFromSystem. >>> ChangeSet removeChangeSetsNamedSuchThat: [ :each | true ]. >>> ChangeSet resetCurrentToNewUnnamedChangeSet. >>> MCDefinition clearInstances. >>> Undeclared removeUnreferencedKeys. >>> Smalltalk garbageCollect. >>> >>> like this: >>> >>> ./vm/pharo Pharo7.0-metacello-32bit-fa236b7.image eval --save "Character characterSet: nil. Unicode classPool at: #GeneralCategory put: nil. Unicode classPool at: #DecimalProperty put: nil. UnicodeDefinitions removeFromSystem. ChangeSet removeChangeSetsNamedSuchThat: [ :each | true ]. ChangeSet resetCurrentToNewUnnamedChangeSet. MCDefinition clearInstances. Undeclared removeUnreferencedKeys. Smalltalk garbageCollect." >>> >>> and my image went down from 11MB to 6.6MB (7.0 MB if I don't change back to ascii with the first three lines) >>> >>> Then I tried a tally: >>> >>> ./vm/pharo Pharo7.0-metacello-32bit-fa236b7.image save spacetally >>> >>> ./vm/pharo spacetally.image eval --save "repo := MCFileTreeRepository new directory: '../src' asFileReference. version := repo loadVersionFromFileNamed: 'Tool-Profilers.package'. version load." >>> >>> re-clean since i loaded some packages >>> >>> ./vm/pharo spacetally.image eval --save "ChangeSet removeChangeSetsNamedSuchThat: [ :each | true ]. ChangeSet resetCurrentToNewUnnamedChangeSet. MCDefinition clearInstances. Undeclared removeUnreferencedKeys. Smalltalk garbageCollect." >>> >>> This image is now 6.6MB (7.1MB with the unicode large arrays), 4.1% of strings (274k) what seems reasonable. Remaining big strings are Pharo's licence, the buffer of the changes file and then some class comments (shouldn't they be fetched from disk as any other method source code?). >>> >>> Making again a tally shows that ~30% of the space is taken by Arrays and 21.9% by compiled methods. But, BUT! :) I have ~30k arrays and lots of collections also: >>> >>> "MethodDictionary" 2872 + >>> "IdentitySet" 12781 + >>> "OrderedCollection" 4398 + >>> "Set" 2959 + >>> "Dictionary" 1997 + >>> "IdentityDictionary" 454 >>> ----------------------------------------------- >>> 25461 >>> >>> So there are ~5k arrays that are used outside collections. >>> >>> Worth exploring a bit more I think. >>> >>> On Wed, Aug 16, 2017 at 1:23 AM, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >>> >>> >>> On Tue, Aug 15, 2017 at 11:26 PM, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >>> Hi Guille/Ben - I got a quick moment to try the SpaceTally (aside: it seems very convoluted to load a single package into the image, I was trying to avoid having to create a baselineOf for something so simple - I ended up with: >>> >>> I know, I also believe we have to simplify this. In any case, baselines are healthy as they allow to also express dependencies. Otherwise you'll end up loading dependencies by hand. We'll fix this soon I hope. >>> >>> >>> repo := MCFileTreeRepository new directory: './bootstrap' asFileReference. >>> version := repo loadVersionFromFileNamed: 'Tool-Profilers.package'. >>> version load. >>> >>> Anyway - in my minimal image, like in the fat image there seems to be a surprising amount of bytestrings (4mb worth?). I think that might need some digging into? It seems like a lot somehow. Although Benâs neat experiment of zipping strings shows thatâs not a real route. >>> >>> In a deployed minimal image - maybe I can get rid of some other things like MethodChangeRecords or MCMethodDefiniionâs (but they are smaller wins - but noticeable) >>> >>> Class code space # instances inst space percent inst average size >>> ByteString 2640 37365 4823848 21.50 129.10 >>> Array 3742 53002 3961944 17.60 74.75 >>> CompiledMethod 19159 30481 2912968 13.00 95.57 >>> Association 1148 58348 1867136 8.30 32.00 >>> MethodChangeRecord 431 34312 1097984 4.90 32.00 >>> ByteArray 4605 290 908728 4.00 3133.54 >>> ByteSymbol 1698 22689 840168 3.70 37.03 >>> IdentitySet 408 19076 610432 2.70 32.00 >>> MethodDictionary 3310 3520 608688 2.70 172.92 >>> WeakArray 1758 3024 597824 2.70 197.69 >>> MCMethodDefinition 4318 6659 426176 1.90 64.00 >>> Protocol 1679 8382 268224 1.20 32.00 >>> OrderedCollection 6555 5509 220360 1.00 40.00 >>> >>> As an aside - my Gitlab project is public, the scripts that load things up are in ./scripts (build.sh, and minimal.st <http://minimal.st/> and loadlocal.st <http://loadlocal.st/>) >>> >>> Tim >>> >>>> On 15 Aug 2017, at 08:02, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >>>> >>>> >>>> >>>> On Mon, Aug 14, 2017 at 4:42 PM, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >>>> Hi Guille - just running SpaceTally on my dev image to get a feel for it. It turns out that in the minimal images youâve been creating, its not loaded (makes sense). >>>> >>>> Yup, it's loaded afterwards. >>>> >>>> All packages are loaded through metacello baselines. We should start refactoring and making standalone projects, each one with a baseline for himself, and his own dependencies described. >>>> >>>> I was checking on your gitlab and I have probably no access: how are you finally loading packages in the bootstrap image? Can you share that with us in text? I'd like to improve that situation. >>>> >>>> Iâm wondering if there is an easy way to import it in (I guess that package should be in the Pharo git tree I cloned to get Fuel loaded right? Or is there a separate standalone source?). >>>> >>>> Yes it is, you can get the package programatically doing >>>> >>>> SpaceTally package name >>>> >>>> And furthermore, get the baseline that currently is loading by doing >>>> >>>> package := SpaceTally package name. >>>> BaselineOf subclasses select: [ :e | >>>> e project version packages anySatisfy: [ :p | p name = package ]]. >>>> >>>> >>>> Thanks for all the support, and your email about why the contexts stack up is very well received (I will comment over there). >>>> >>>> By the way - it looks like Martin Fowler picked up on this announcement - so maybe we might get some interest from his mass of followers. >>>> >>>> Tim >>>> >>>>> On 14 Aug 2017, at 10:49, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >>>>> >>>>> Hi Tim, >>>>> >>>>> On Mon, Aug 14, 2017 at 11:41 AM, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >>>>> Hey guys, thanks for your enthusiasm around this - and I cannot stress enough how this was only possible because of the work that has gone into making Pharo (in particular the 64bit image, as well as having a minimal image, and some great blog posts on serialising contexts) as well as the patience from everyone in answering questions and helping me get it all working. >>>>> >>>>> Iâm still quite keen to get my execution time back down under 800ms and Iâd like to actually get back to writing a few skills to automate a few things around my house. >>>>> >>>>> To Answer Denisâ question - >>>>> >>>>> My final footprint is 30.4mb - thats composed of a 22mb image (with a simple example that pulls in Fuel, ZTimestamp and the S3 Library which depends on XMLParser) and then the VM (from which I removed obvious dllâs). >>>>> >>>>> In my original experiments with a 6.0 minimal image - I did manage to get to a 13.4mb image (which started out as 12mb original size, and then loaded in STON and had only a simple clock example). I think the sweet spot is around 20mb total footprint as that seems to get me into the 450ms-900ms range. >>>>> >>>>> The 7.0 min image now starts out at 15mb and then Iâm not sure why loading Fuel, S3 and XMLParser takes 7mb (it seems big to me - but Iâve not dug into that). >>>>> >>>>> You can do further space analysis using the following expression >>>>> >>>>> SpaceTally new printSpaceAnalysis >>>>> >>>>> You can do that in an eval and check what's taking space. With measures we can iterate and improve :). >>>>> >>>>> Iâve also found (and this on the back of unserialising the context in my example) that the way we build images has 15+ saved stack sessions that have saved on top of each other from the way we build up the images. I donât yet know the implications of size/speed of these - but we need a better way of folding executions when we snapshot headless images. Iâm also not clear if there are any other startup tasks that take precious time (this also has implications for our fat development images as they take much longer to appear than they really should). >>>>> >>>>> I'm working on this as I'm writing this mail ;) >>>>> >>>>> https://pharo.fogbugz.com/f/cases/20309 <https://pharo.fogbugz.com/f/cases/20309> >>>>> https://github.com/pharo-project/pharo/pull/196 <https://github.com/pharo-project/pharo/pull/196> >>>>> >>>>> I'll write down the implications further in a different thread. >>>>> >>>>> >>>>> Iâll be exploring some of these size/speed tradeoffâs in follow on messages. >>>>> >>>>> But once again, a big thanks - Iâve not enjoyed programming like this for ages. >>>>> >>>>> Tim >>>>> >>>>>> On 12 Aug 2017, at 16:26, Ben Coman <btc(a)openInWorld.com <mailto:btc@openInWorld.com>> wrote: >>>>>> >>>>>> hi Tim, >>>>>> >>>>>> That is..... AWESOME! >>>>>> >>>>>> Very nice delivery - it flowed well with great narration. >>>>>> >>>>>> I loved @2:17 "this is the interesting piece, because PharoLambda has serialized the execution context of its application and saved it into [my S3 bucket] ... [then on the local machine] rematerializes a debugger [on that context]." >>>>>> >>>>>> There is a clarity in your video presentation that really may intrigue outsiders. As a community we should push this on the usual hacker forums - ycombinator could be a good starting point (but I'm locked out of my account there). >>>>>> An enticing title could be... >>>>>> "Debugging Lambdas by re-materializing saved execution contexts on your local machine." >>>>>> >>>>>> cheers -ben >>>>>> >>>>>> On Fri, Aug 11, 2017 at 3:37 PM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >>>>>> This is cool Tim. >>>>>> >>>>>> So what image size you deployed at the end? >>>>>> >>>>>> 2017-08-10 15:47 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: >>>>>> I just wanted to thank everyone for their help in getting my pet project further along, so that now I can announce that PharoLambda is now working with the V7 minimal image and also supports post mortem debugging by saving a zipped fuel context onto S3. >>>>>> >>>>>> This latter item is particularly satisfying as at a recent serverless conference (JeffConf) there was a panel where poor development tools on serverless platforms was highlighted as a real problem. >>>>>> >>>>>> In our community weâve had these kinds of tools at our fingertips for ages - but I donât think the wider development community has really noticed. Debugging something short lived like a Lambda execution is quite startling, as the current answer is âadd more loggingâ, and we all know that sucks. To this end, Iâve created a little screencast showing this in action - and it was pretty cool because it was a real example I encountered when I got everything working and was trying my test application out. >>>>>> >>>>>> Iâve also put a bit of work into tuning the excellent GitLab CI tools, so that I can cache many of the artefacts used between different build runs (this might also be of interest to others using CI systems). >>>>>> >>>>>> The Gitlab project is on: https://gitlab.com/macta/PharoLambda <https://gitlab.com/macta/PharoLambda> >>>>>> And the screencast: https://www.youtube.com/watch?v=bNNCT1hLA3E <https://www.youtube.com/watch?v=bNNCT1hLA3E> >>>>>> >>>>>> Tim >>>>>> >>>>>> >>>>>>> On 15 Jul 2017, at 00:39, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >>>>>>> >>>>>>> Hi - Iâve been playing around with getting Pharo to run well on AWS Lambda. Itâs early days, but I though it might be interesting to share what Iâve learned so far. >>>>>>> >>>>>>> Usage examples and code at https://gitlab.com/macta/PharoLambda <https://gitlab.com/macta/PharoLambda> >>>>>>> >>>>>>> With help from many of the folks here, Iâve been able to get a simple example to run in 500ms-1200ms with a minimal Pharo 6 image. You can easily try it out yourself. This seems slightly better than what the GoLang folks have been able to do. >>>>>>> >>>>>>> Tim >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Guille Polito >>>>> >>>>> Research Engineer >>>>> French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> >>>>> >>>>> >>>>> Web: http://guillep.github.io <http://guillep.github.io/> >>>>> Phone: +33 06 52 70 66 13 <tel:+33%206%2052%2070%2066%2013> >>>> >>>> >>>> >>>> -- >>>> >>>> Guille Polito >>>> >>>> Research Engineer >>>> French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> >>>> >>>> >>>> Web: http://guillep.github.io <http://guillep.github.io/> >>>> Phone: +33 06 52 70 66 13 <tel:+33%206%2052%2070%2066%2013> >>> >>> >>> >>> -- >>> >>> Guille Polito >>> >>> Research Engineer >>> French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> >>> >>> >>> Web: http://guillep.github.io <http://guillep.github.io/> >>> Phone: +33 06 52 70 66 13 <tel:+33%206%2052%2070%2066%2013> >>> >>> >>> -- >>> >>> Guille Polito >>> >>> Research Engineer >>> French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> >>> >>> >>> Web: http://guillep.github.io <http://guillep.github.io/> >>> Phone: +33 06 52 70 66 13 <tel:+33%206%2052%2070%2066%2013> >> >> >> >> -- >> >> Guille Polito >> >> Research Engineer >> French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> >> >> >> Web: http://guillep.github.io <http://guillep.github.io/> >> Phone: +33 06 52 70 66 13 >

Aug. 17, 2017

Re: [Pharo-users] [ANN] PharoLambda 1.5 - Pharo running on AWS Lambda now with saved Debug sessions via S3

by Tim Mackinnon

Just thought I would report back a bit more on this - The Unicode change doesnât work in my case (possibly not for command line Pharo as well) as I get an error where OS filenameâs need unicode support (actually I think this is where its trying to write to stdout, but I didnât dig more into this): Error: Instances of UndefinedObject are not indexable UndefinedObject(Object)>>error: UndefinedObject(Object)>>errorNotIndexable UndefinedObject(Object)>>size Unicode class>>isLetter: Character>>isLetter Path class>>isAbsoluteWindowsPath: Path class>>from:delimiter: MacStore(FileSystemStore)>>pathFromString: FileSystem>>pathFromString: ByteString(String)>>asPathWith: FileSystem>>pathFromObject: FileSystem>>referenceTo: ByteString(String)>>asFileReference FileStream class>>fullName: FileStream class>>fileNamed: SmalltalkImage>>openLog I was able to improve on Guilleâs warning about how to safely clear up monticello/metacello (and not use become: String new) with the following (I actually think Metacello should provide a #cleanUp method, so I raised a pr for consideration) logger cr; nextPutAll: '>Removing Clearing MC Registry'. MetacelloProjectRegistration resetRegistry. Iâm then able to be by image down from 22mb to 13.8 (which is pretty good). As a further experiment I also noticed that there is a fair amount of space trapped in Protocols and ClassOrganisation - so I tried clearing those out (as they are lazily cached) with: Smalltalk allClassesAndTraits do: [:c | c basicOrganization: nil ]. This seems to give me a further 1mb back (but I haveât tried performance tests on this, but my naive assumption is that in a running system that isnât adding/manipulating code - that I donât think Protocols are used?). So Iâm now at 21mb. Tim > On 16 Aug 2017, at 10:53, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > On Wed, Aug 16, 2017 at 11:46 AM, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: > Hi, tracing through your changes - it looks like: > > Smalltalk cleanUp: true except: #() confirming: false. > Takes care of all the non-unicode changes you proposed (and it seems like its a known cleanup protocol). > > I based my script on #cleanupForRelease ^^. But I did not just blindly execute it as is because I wanted to understand the implications of each line. > > I wonder if the Unicode change is worth it/risky as many web based services I might connect to with Zinc do support Unicode so maybe I should keep that one in. (I will for now - might verify how much of a difference it really makes) > > No, it should not break any encoding/decoding. The changes I proposed will just nil out two things: > > - the uppercase/lowercase mapping unicode tables that says for each codepoint if the codepoint is uppercase/lowercase and allows transformations from/to uppercase/lowercase. This means that these may not work as expected: > > aChar asLowercase > aChar asUppercase > aChar toLowercase > aChar toUppercase > > - the unicode classification table that says if a character is letter or digit, and so on. This means that these may not work as expected: > > aChar isLetter > aChar isDigit > aChar isAlphaNumeric > > I think my next port of call is cleanUp for Monticello/Metacello as I see a fair amount of that stuff floating around in my image (after Iâve used it to bootstrap my code). > > Tim > >> On 16 Aug 2017, at 02:32, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >> >> Actually it happens first that monticello is "nicely" coupled with the changeset system and logs all the source code loaded in change sets :D :/ Â¬Â¬. Also, the first two strings in terms of size are related to unicode tables (we should put them in files instead of in the image and load them on demand), and the two biggest arrays also to unicode. I just tried the following in a clean bootstrapped "minimal" image (metacello): >> >> "Careful, this will make that #isLetter, #isUppercase #isLowercase, #toLowercase and #toUppercase only work on ascii" >> Character characterSet: nil. >> Unicode classPool at: #GeneralCategory put: nil. >> Unicode classPool at: #DecimalProperty put: nil. >> >> UnicodeDefinition removeFromSystem. >> ChangeSet removeChangeSetsNamedSuchThat: [ :each | true ]. >> ChangeSet resetCurrentToNewUnnamedChangeSet. >> MCDefinition clearInstances. >> Undeclared removeUnreferencedKeys. >> Smalltalk garbageCollect. >> >> like this: >> >> ./vm/pharo Pharo7.0-metacello-32bit-fa236b7.image eval --save "Character characterSet: nil. Unicode classPool at: #GeneralCategory put: nil. Unicode classPool at: #DecimalProperty put: nil. UnicodeDefinitions removeFromSystem. ChangeSet removeChangeSetsNamedSuchThat: [ :each | true ]. ChangeSet resetCurrentToNewUnnamedChangeSet. MCDefinition clearInstances. Undeclared removeUnreferencedKeys. Smalltalk garbageCollect." >> >> and my image went down from 11MB to 6.6MB (7.0 MB if I don't change back to ascii with the first three lines) >> >> Then I tried a tally: >> >> ./vm/pharo Pharo7.0-metacello-32bit-fa236b7.image save spacetally >> >> ./vm/pharo spacetally.image eval --save "repo := MCFileTreeRepository new directory: '../src' asFileReference. version := repo loadVersionFromFileNamed: 'Tool-Profilers.package'. version load." >> >> re-clean since i loaded some packages >> >> ./vm/pharo spacetally.image eval --save "ChangeSet removeChangeSetsNamedSuchThat: [ :each | true ]. ChangeSet resetCurrentToNewUnnamedChangeSet. MCDefinition clearInstances. Undeclared removeUnreferencedKeys. Smalltalk garbageCollect." >> >> This image is now 6.6MB (7.1MB with the unicode large arrays), 4.1% of strings (274k) what seems reasonable. Remaining big strings are Pharo's licence, the buffer of the changes file and then some class comments (shouldn't they be fetched from disk as any other method source code?). >> >> Making again a tally shows that ~30% of the space is taken by Arrays and 21.9% by compiled methods. But, BUT! :) I have ~30k arrays and lots of collections also: >> >> "MethodDictionary" 2872 + >> "IdentitySet" 12781 + >> "OrderedCollection" 4398 + >> "Set" 2959 + >> "Dictionary" 1997 + >> "IdentityDictionary" 454 >> ----------------------------------------------- >> 25461 >> >> So there are ~5k arrays that are used outside collections. >> >> Worth exploring a bit more I think. >> >> On Wed, Aug 16, 2017 at 1:23 AM, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >> >> >> On Tue, Aug 15, 2017 at 11:26 PM, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >> Hi Guille/Ben - I got a quick moment to try the SpaceTally (aside: it seems very convoluted to load a single package into the image, I was trying to avoid having to create a baselineOf for something so simple - I ended up with: >> >> I know, I also believe we have to simplify this. In any case, baselines are healthy as they allow to also express dependencies. Otherwise you'll end up loading dependencies by hand. We'll fix this soon I hope. >> >> >> repo := MCFileTreeRepository new directory: './bootstrap' asFileReference. >> version := repo loadVersionFromFileNamed: 'Tool-Profilers.package'. >> version load. >> >> Anyway - in my minimal image, like in the fat image there seems to be a surprising amount of bytestrings (4mb worth?). I think that might need some digging into? It seems like a lot somehow. Although Benâs neat experiment of zipping strings shows thatâs not a real route. >> >> In a deployed minimal image - maybe I can get rid of some other things like MethodChangeRecords or MCMethodDefiniionâs (but they are smaller wins - but noticeable) >> >> Class code space # instances inst space percent inst average size >> ByteString 2640 37365 4823848 21.50 129.10 >> Array 3742 53002 3961944 17.60 74.75 >> CompiledMethod 19159 30481 2912968 13.00 95.57 >> Association 1148 58348 1867136 8.30 32.00 >> MethodChangeRecord 431 34312 1097984 4.90 32.00 >> ByteArray 4605 290 908728 4.00 3133.54 >> ByteSymbol 1698 22689 840168 3.70 37.03 >> IdentitySet 408 19076 610432 2.70 32.00 >> MethodDictionary 3310 3520 608688 2.70 172.92 >> WeakArray 1758 3024 597824 2.70 197.69 >> MCMethodDefinition 4318 6659 426176 1.90 64.00 >> Protocol 1679 8382 268224 1.20 32.00 >> OrderedCollection 6555 5509 220360 1.00 40.00 >> >> As an aside - my Gitlab project is public, the scripts that load things up are in ./scripts (build.sh, and minimal.st <http://minimal.st/> and loadlocal.st <http://loadlocal.st/>) >> >> Tim >> >>> On 15 Aug 2017, at 08:02, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >>> >>> >>> >>> On Mon, Aug 14, 2017 at 4:42 PM, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >>> Hi Guille - just running SpaceTally on my dev image to get a feel for it. It turns out that in the minimal images youâve been creating, its not loaded (makes sense). >>> >>> Yup, it's loaded afterwards. >>> >>> All packages are loaded through metacello baselines. We should start refactoring and making standalone projects, each one with a baseline for himself, and his own dependencies described. >>> >>> I was checking on your gitlab and I have probably no access: how are you finally loading packages in the bootstrap image? Can you share that with us in text? I'd like to improve that situation. >>> >>> Iâm wondering if there is an easy way to import it in (I guess that package should be in the Pharo git tree I cloned to get Fuel loaded right? Or is there a separate standalone source?). >>> >>> Yes it is, you can get the package programatically doing >>> >>> SpaceTally package name >>> >>> And furthermore, get the baseline that currently is loading by doing >>> >>> package := SpaceTally package name. >>> BaselineOf subclasses select: [ :e | >>> e project version packages anySatisfy: [ :p | p name = package ]]. >>> >>> >>> Thanks for all the support, and your email about why the contexts stack up is very well received (I will comment over there). >>> >>> By the way - it looks like Martin Fowler picked up on this announcement - so maybe we might get some interest from his mass of followers. >>> >>> Tim >>> >>>> On 14 Aug 2017, at 10:49, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >>>> >>>> Hi Tim, >>>> >>>> On Mon, Aug 14, 2017 at 11:41 AM, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >>>> Hey guys, thanks for your enthusiasm around this - and I cannot stress enough how this was only possible because of the work that has gone into making Pharo (in particular the 64bit image, as well as having a minimal image, and some great blog posts on serialising contexts) as well as the patience from everyone in answering questions and helping me get it all working. >>>> >>>> Iâm still quite keen to get my execution time back down under 800ms and Iâd like to actually get back to writing a few skills to automate a few things around my house. >>>> >>>> To Answer Denisâ question - >>>> >>>> My final footprint is 30.4mb - thats composed of a 22mb image (with a simple example that pulls in Fuel, ZTimestamp and the S3 Library which depends on XMLParser) and then the VM (from which I removed obvious dllâs). >>>> >>>> In my original experiments with a 6.0 minimal image - I did manage to get to a 13.4mb image (which started out as 12mb original size, and then loaded in STON and had only a simple clock example). I think the sweet spot is around 20mb total footprint as that seems to get me into the 450ms-900ms range. >>>> >>>> The 7.0 min image now starts out at 15mb and then Iâm not sure why loading Fuel, S3 and XMLParser takes 7mb (it seems big to me - but Iâve not dug into that). >>>> >>>> You can do further space analysis using the following expression >>>> >>>> SpaceTally new printSpaceAnalysis >>>> >>>> You can do that in an eval and check what's taking space. With measures we can iterate and improve :). >>>> >>>> Iâve also found (and this on the back of unserialising the context in my example) that the way we build images has 15+ saved stack sessions that have saved on top of each other from the way we build up the images. I donât yet know the implications of size/speed of these - but we need a better way of folding executions when we snapshot headless images. Iâm also not clear if there are any other startup tasks that take precious time (this also has implications for our fat development images as they take much longer to appear than they really should). >>>> >>>> I'm working on this as I'm writing this mail ;) >>>> >>>> https://pharo.fogbugz.com/f/cases/20309 <https://pharo.fogbugz.com/f/cases/20309> >>>> https://github.com/pharo-project/pharo/pull/196 <https://github.com/pharo-project/pharo/pull/196> >>>> >>>> I'll write down the implications further in a different thread. >>>> >>>> >>>> Iâll be exploring some of these size/speed tradeoffâs in follow on messages. >>>> >>>> But once again, a big thanks - Iâve not enjoyed programming like this for ages. >>>> >>>> Tim >>>> >>>>> On 12 Aug 2017, at 16:26, Ben Coman <btc(a)openInWorld.com <mailto:btc@openInWorld.com>> wrote: >>>>> >>>>> hi Tim, >>>>> >>>>> That is..... AWESOME! >>>>> >>>>> Very nice delivery - it flowed well with great narration. >>>>> >>>>> I loved @2:17 "this is the interesting piece, because PharoLambda has serialized the execution context of its application and saved it into [my S3 bucket] ... [then on the local machine] rematerializes a debugger [on that context]." >>>>> >>>>> There is a clarity in your video presentation that really may intrigue outsiders. As a community we should push this on the usual hacker forums - ycombinator could be a good starting point (but I'm locked out of my account there). >>>>> An enticing title could be... >>>>> "Debugging Lambdas by re-materializing saved execution contexts on your local machine." >>>>> >>>>> cheers -ben >>>>> >>>>> On Fri, Aug 11, 2017 at 3:37 PM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >>>>> This is cool Tim. >>>>> >>>>> So what image size you deployed at the end? >>>>> >>>>> 2017-08-10 15:47 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: >>>>> I just wanted to thank everyone for their help in getting my pet project further along, so that now I can announce that PharoLambda is now working with the V7 minimal image and also supports post mortem debugging by saving a zipped fuel context onto S3. >>>>> >>>>> This latter item is particularly satisfying as at a recent serverless conference (JeffConf) there was a panel where poor development tools on serverless platforms was highlighted as a real problem. >>>>> >>>>> In our community weâve had these kinds of tools at our fingertips for ages - but I donât think the wider development community has really noticed. Debugging something short lived like a Lambda execution is quite startling, as the current answer is âadd more loggingâ, and we all know that sucks. To this end, Iâve created a little screencast showing this in action - and it was pretty cool because it was a real example I encountered when I got everything working and was trying my test application out. >>>>> >>>>> Iâve also put a bit of work into tuning the excellent GitLab CI tools, so that I can cache many of the artefacts used between different build runs (this might also be of interest to others using CI systems). >>>>> >>>>> The Gitlab project is on: https://gitlab.com/macta/PharoLambda <https://gitlab.com/macta/PharoLambda> >>>>> And the screencast: https://www.youtube.com/watch?v=bNNCT1hLA3E <https://www.youtube.com/watch?v=bNNCT1hLA3E> >>>>> >>>>> Tim >>>>> >>>>> >>>>>> On 15 Jul 2017, at 00:39, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >>>>>> >>>>>> Hi - Iâve been playing around with getting Pharo to run well on AWS Lambda. Itâs early days, but I though it might be interesting to share what Iâve learned so far. >>>>>> >>>>>> Usage examples and code at https://gitlab.com/macta/PharoLambda <https://gitlab.com/macta/PharoLambda> >>>>>> >>>>>> With help from many of the folks here, Iâve been able to get a simple example to run in 500ms-1200ms with a minimal Pharo 6 image. You can easily try it out yourself. This seems slightly better than what the GoLang folks have been able to do. >>>>>> >>>>>> Tim >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Guille Polito >>>> >>>> Research Engineer >>>> French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> >>>> >>>> >>>> Web: http://guillep.github.io <http://guillep.github.io/> >>>> Phone: +33 06 52 70 66 13 <tel:+33%206%2052%2070%2066%2013> >>> >>> >>> >>> -- >>> >>> Guille Polito >>> >>> Research Engineer >>> French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> >>> >>> >>> Web: http://guillep.github.io <http://guillep.github.io/> >>> Phone: +33 06 52 70 66 13 <tel:+33%206%2052%2070%2066%2013> >> >> >> >> -- >> >> Guille Polito >> >> Research Engineer >> French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> >> >> >> Web: http://guillep.github.io <http://guillep.github.io/> >> Phone: +33 06 52 70 66 13 <tel:+33%206%2052%2070%2066%2013> >> >> >> -- >> >> Guille Polito >> >> Research Engineer >> French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> >> >> >> Web: http://guillep.github.io <http://guillep.github.io/> >> Phone: +33 06 52 70 66 13 <tel:+33%206%2052%2070%2066%2013> > > > > -- > > Guille Polito > > Research Engineer > French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> > > > Web: http://guillep.github.io <http://guillep.github.io/> > Phone: +33 06 52 70 66 13

Aug. 17, 2017

Re: [Pharo-users] What is proper fix for this?

by Esteban A. Maringolo

2017-08-17 6:51 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 17 Aug 2017, at 11:34, jtuchel(a)objektfabrik.de wrote: > > Am 17.08.17 um 11:31 schrieb Esteban Lorenzano: > >>> On 17 Aug 2017, at 11:28, jtuchel(a)objektfabrik.de wrote: > >>> > >>> Herby, > >>> > >>> back when Alan was maintaining Glorp, he took care for portability, he even maintained the port to VA Smalltalk, IIRC. Niall and Tim(?) at Cincom also try not to break any dialect in their changes and they also work on keeping things portable. I am not sure there ever was any (semi-)automated process to keep ports in sync, my guess would be that that is not the case. > >>> > >>> What I am very sure of is that the ppl at Cincom would welcome any volunteers to support them in keeping things portable and improve the ecosystem for this. > >>> Is any of you going to be at ESUG? > >> I will, but I will not maintain Glorp portâ¦ I have just too much work :) > > Same for me. I am not a regular Pharo user, so I cannot do it. > > yeahâ¦ too bad :( > âunofficial maintainerâ of Glorp port is Esteban Maringolo. But since he has to make a living (and right now he is working on VW, not Pharo), he cannot do it but lightly. > Other maintainers should be the people using it, so the addition of Herby is welcome (Esteban M. will check at when he has timeâ¦ but at least now is available for other people to check). Glorp was built with portability in mind, but it's too "old school", the packaging itself is a nightmare. And most of the design, and "portable" parts are designed around VW database layers. The code sharing is a thing in its own, I had to "adapt" a Monticello exporter in VW to get better package names instead of a single "Glorp" package. FileTree is stilll not available in Cincom, Martin McLure said they're working in a new Cypress spec that'd work in VW as well, I look forward to see that, because I'd need it to move code back/forth Pharo and VW. Last year I did a port to Pharo from the latest availalable version in Cincom and tried to keep both in sync, but the feedback loops are quite different in Pharo than Cincom, skillsets are also different (I'm still struggling with Store), and even with some support, Cincom doesn't have portability as a main objective, Glorp today is a means to and end, and that end is their SCM, Store. So modifying a core tool just to be more portable is not a priority for them. Also the way Glorp is made portable is very differently from how Seaside is done, Glorp has a lot of #isVW, #isSqueak, #isPharo, etc... which I removed from the latest port. The last time I did not dare to "hard-fork" the whole project and refactor it, maybe the next time. > I myself keep track of my own beast: Voyageâ¦ but thankfully I can just check time to time since we have a small but active community around it. Ideal situation for Glorp would be having the same. I'm a "happy"[1] user of ORMs, and used them in Smalltalk for over a decade (in Pharo for a couple of years), unfortunately for Glorp, I've been coding for GemStone based projects and now also Glorp but in VW, with SQLite for a minimal part of the application. So, bottom line, it takes me some time to catch-up and get into ORM "mode", since it's something I'm not doing every day. Best regards! Esteban A. Maringolo

Aug. 17, 2017

Re: [Pharo-users] How to find where pharo is killing processor power?

by Dimitris Chloupis

Are you aware of the profile tools inside Pharo ? They capture execution and offer detailed analysis of how much time is spent on each task. One of it can be found in World Menu -> Tools -> Time Profiler Generally speaking a while loop that runs all the time without any kind of delays is a very popular way to consume 100%. Even if the while loop does nothing it will still consume %100 because even executing an empty loops has costs. Two solution is inserting a delay in the loop so the loop have to wait for 1 millisecond or less depending your demands or just make sure the loop has a very specific condition so it executes only when you need to. On Wed, Aug 16, 2017 at 10:04 PM sergio ruiz <sergio.rrd(a)gmail.com> wrote: > > hey all.. my current pharo implementation is running super serious > processor power, but it shouldnât be doing much. > > [image: Activity_Monitor__All_Processes__and_Pharo_image.jpg] > > how would I go about tracking this inside the pharo image? > > Thanks! > > > ---- > peace, > sergio > photographer, journalist, visionary > > Public Key: http://bit.ly/29z9fG0 > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > http://www.Village-Buzz.com <http://www.village-buzz.com/> > http://www.ThoseOptimizeGuys.com <http://www.thoseoptimizeguys.com/> > http://www.coffee-black.com > http://www.painlessfrugality.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 >

Aug. 17, 2017