February 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] What is Phlow?

by Tudor Girba

Hi, First, thanks for reviewing the code :). Phlow is a small engine that makes it possible to link Brick slots to one another to enable flow of data. Cheers, Doru On Mon, Feb 9, 2015 at 1:46 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > For example GLMBrick subclass: #GLMPhlowBrick > in category: 'Glamour-Morphic-Brick-Phlow' > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 9, 2015

Re: [Pharo-dev] get.pharo.org/travis+vm failing: Package 'pharo-vm-core:i386' has no installation candidate

by Dale Henrichs

On 02/09/2015 12:10 PM, stepharo wrote: > Dale > > I'm trying to understand. Do we need to update something on our side? > I'm not a linux users and I would use Nix because damien maintain the > distribution the Nix is cool. > Now the ubuntu package was updated recently. > > Stef The get.pharo.org/travis+vm zeroconf script started failing 3 days ago (was working 6 days ago) with the following error in my log file: Fetched 18.5 kB in 4s (4,214 B/s) Reading package lists... Done Reading package lists... Done Building dependency tree Reading state information... Done Package pharo-vm-core:i386 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'pharo-vm-core:i386' has no installation candidate This failure is occuring when run in Ubunut12.04 by hand and up on travis[1]. I assume that something has changed on the pharo side, but I don't know what changed or why it stopped working. I rely on travis for testing my code and I rely on pharo to download and install on travis for the tests (and the things that I'm testing) to work ... with the travis builds failing with the above error, I have to stop doing my normal development and trouble shoot this particular problem ... I am a user of zero conf scripts so I have spent the morning trying to understand how they work and I am in the process of attempting to work around the travis script problem... It looks like I've been able to get the pharo4.0 and pharo3.0 scripts working again[2], without using the travis scripts, but I am now having issues with the older pharo versions and squeak (they all worked a month ago[3], the last time I had to touch builderCI) --- when you change something that was working you always open yourself up for other things to start breaking and I'm getting hit with that now:( Ideally there would have been tests in place for the travis zeroconf script, so that the failure could have been nipped in the bud or there is a failure at some other part of the zeroconf mechanism I don't have a clue ... I'm just trying to get to the point where I can return to my regular development ... Dale [1] https://travis-ci.org/dalehenrich/tode/jobs/49776435 [2] https://travis-ci.org/dalehenrich/builderCI/builds/50107976 [3] https://travis-ci.org/dalehenrich/builderCI/builds/46642969

Feb. 9, 2015

Re: [Pharo-dev] Reducing the activity of the image

by phil＠highoctane.be

Can't the box be setup 5o do some WoL thing and go back to sleep when idling for a while? This CPU usage is really annoying indeed. Phil Le 9 fÃ©vr. 2015 21:11, "Norbert Hartl" <norbert(a)hartl.name> a Ã©crit : > I have an installation where a pharo powered hardware is used in a closed > case. Over time that collects quite some heat. One reason for this is that > the pharo vm is taking approx. 6% CPU all the time. The only thing that > happens is network/sockets. I suspended the ui thread in the image but on > this platform it doesn't help. > Are there any tweaks to lower the polling and the activity of the image/vm > even more? > > thanks, > > Norbert > > >

Feb. 9, 2015

Re: [Pharo-dev] Reducing the activity of the image

by stepharo

> I have an installation where a pharo powered hardware is used in a closed case. Over time that collects quite some heat. One reason for this is that the pharo vm is taking approx. 6% CPU all the time. The only thing that happens is network/sockets. I suspended the ui thread in the image but on this platform it doesn't help. > Are there any tweaks to lower the polling and the activity of the image/vm even more? Right now having an event driven VM is the way but it is not on the horizon. JB was starting to look at that when he worked on the android part. > > thanks, > > Norbert > > >

Feb. 9, 2015

About AST instance variable naming

by stepharo

Hi today during a lecture I was quite surprised to see the name of the AST variables. There is no easy way to see that a variable is a position in the text or a subtree. Example RBValueNode subclass: #RBArrayNode instanceVariableNames: 'left right statements periods' classVariableNames: '' category: 'AST-Core-Nodes' RBValueNode subclass: #RBBlockNode instanceVariableNames: 'left right colons arguments bar body scope' classVariableNames: '' category: 'AST-Core-Nodes' Annoying because you have always to think (yes I know I'm stupid not knowing by heart the tree structure) to know if you get a tree under your fingers. We can definitively better in terms of code habilitability. We cleaned the visitor and since then the code is much much much better. I would do the following RBValueNode subclass: #RBArrayNode instanceVariableNames: 'leftParenthesisPosition rightParenthesisPosition statements periodsPosition' classVariableNames: '' category: 'AST-Core-Nodes' I would be also ok with RBValueNode subclass: #RBArrayNode instanceVariableNames: 'leftPosition rightPosition statements periodsPosition' classVariableNames: '' category: 'AST-Core-Nodes' RBValueNode subclass: #RBBlockNode instanceVariableNames: 'leftPosition rightPosition colonsPosition arguments barPosition body scope' classVariableNames: '' category: 'AST-Core-Nodes'

Feb. 9, 2015

Re: [Pharo-dev] Parsing float difference between 2.0 and 3.0, was it on purpose?

by stepharo

Hi nicolas. > > No it's not strange. > 2 different parsers respond to 2 different syntax and expectations. > > To me it's quite clear: > > - The SmalltalkNumberParser was there to parse a Smalltalk syntax > (badly named SqNumberParser in the ages...) > It should do this thru Number readSmalltalkSyntaxFrom: '1.0e4' > > - The ExtendedNumberParser was there to parse an extended syntax > (the one most apps handling data from oustide world will wish to parse). > It should do this thru Number readFrom: '1.0e+4' I have a question: is ExtendedNumberParser parsing SmalltalkNumberParser numbers? Because we could use by default ExtendedNumberParser. Else we can have an external package to maintain ExtendedNumberParser part of the ecosystem. > > - The FortranNumberParser was just an unused experiment. > Its sole goal was to expose an example of how a GenericNumberParser > could be subclassed. > Such class has a better place in a cook-book than in the image, so > Bye bye. We could add it to the PharoExtras. > > Date readFrom: '2015/02/06' readStream does not have to follow a > Smalltalk syntax, so why Number readFrom: '1.0e+4' readStream would > have to? > > As Yuriy underlined, we might extend the Smalltalk syntax to embrasse > some of external world patterns, why not, but it's limited and is > going to be a problem with formats like '.2' or '2.e0'. > > Whether the extended parser should be in the core image or not is a > valid question. > We all agree that Pharo is all but finished and need to be constantly > cleaned up. > The challenge is how can Pharo change but remain > application-writer-friendly? > So two different things are: > - the value of the feature: is it worth maintaining it or not? > If yes, should it be maintained outside the core, or inside by the > Pharo-team? > I agree that removing incomplete features is a valid strategy when > the team is too small > - the quality of implementation > > And there are two ways of cleaning: > - clean a dirty implementation, but keep the feature (eventually with > a different API) > - remove the feature, based on a value/cost analysis > > Here, I feel like it's the dictatorship which sounds questionnable. > Were the feature understood? > There were unit tests and class comments, so pretending to not > understand is not really an excuse. > > Were the value of the features discussed? > Maybe in a small core team... From outside, we don't really know. No discussion should happen in the mailing-list but the problem is that the mailing-list is like a stream. I forget things. This is why we should have a better process but if I could get less things to do it would also help me a lot (and I do not mean pharo things :)). > Were an externalisation of the feature and transfer of maintenance to > a 3rd party discussed? > I'm not aware of. I'm sure it would have been a better decision. > > So from my POV, such decision process remains to improve. It sounds > too light and arbitrary. > In some cases, I have the impression that the volunty of cleaning is > too much dogmatic. I agree. This happens when we are too mcuh stress. When I feel that I want to throw away half of the system (menu, fonts... and many others :)) I just close pharo and do something else > I agree that too much pragmatism won't lead to a clean image any time > soon... > I agree that Pharo team has a licence to change things and should > decide, otherwise let's all stick to Squeak ;) > But a bit of democratie, argumentation and COORDINATION does not hurt. Yes. > > Then how can user support be improved? > - Is it possible to write release notes helping the transition? > (were is located the add-on package that enables compatibility, who > maintains it, is there a new and better API, etc...) > - Could some automated AST-based refactorings be prepared and applied > auto-magically? > It's not necessarily the sole business of Pharo-team, user community > could help writing such notes. So what would be a reasonable plan. I have no problem to maintain a nice package in PharoExtras if it helps. Stef

Feb. 9, 2015

Re: [Pharo-dev] Howto create a new configuration?

by stepharo

Tx!!! Le 8/2/15 15:36, Juraj Kubelka a Ã©crit : > Hi, > >> 8. 2. 2015 v 8:26, Nicolai Hess <nicolaihess(a)web.de >> <mailto:nicolaihess@web.de>>: >> >> 2015-02-07 13:17 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de >> <mailto:nicolaihess@web.de>>: >> >> >> >> 2015-02-06 22:02 GMT+01:00 Juraj Kubelka <juraj.kubelka(a)gmail.com >> <mailto:juraj.kubelka@gmail.com>>: >> >> I have changed two methods of the configuration: >> >> -=-=- >> stable: spec >> <symbolicVersion: #stable> >> >> spec for: #'pharo2.x' version: '2.1'. >> "after some modification in NB made it incompatible with 3.0" >> spec for: #'pharo3.x' version: '2.3'. >> *spec for: #'pharo4.x' version: '2.7â. â<<== added, maybe >> instead of pharo4.x could be common"* >> -=-=- >> development: spec >> <symbolicVersion: #'development'> >> >> spec for: #'common' version: '*2.3-baseline*â. â<<== it is >> likely not necessary" >> -=-=- >> >> I have changed it, because I think there should be two lines >> in Versioner: one with development label, second with stable >> label. >> Then everything works. >> Let me know if it helps. >> Juraj >> >> >> Thank you Juraj, >> that works .... better, but now, commiting the new configuration >> shows a bunch of "Critical Issues" >> Critical Warning missing recommend field... >> Critcal Warning The name of package x does not match file name x.7 >> Critical Warning No Version specified. >> .... >> >> Not that easy. Maybe, the ConfigurationOfAthens was only written >> and updated by hand, does not work with Versionner? >> >> >> >> >> I think, for now I will try to change the Configuration by hand >> without versionner. >> >> > > There three warnings revealed by: (MetacelloToolBox > validateConfiguration: ConfigurationOfAthens). > It is easy to fix, well I guess. The one is a misspelling, two are > about missing #versionString: and I suppose there should be > versionString: #âstableâ. > It is fixed in ConfigurationOfAthens-JurajKubelka.46.mcz. > > Then I have created by hand version 2.8. The âstrangeâ think is that > development do not point to the latest version. Is the 2.8 supposed to > be stable or development version? > ConfigurationOfAthens-JurajKubelka.46.mcz contains the 2.8 version as > development version. > > Cheers, > Juraj > > > > >

Feb. 9, 2015

Re: [Pharo-dev] Howto create a new configuration?

by stepharo

Christophe I also wonder if this is not the configuration we discussed with igor with the pattern/workflow he wanted (and made sense) but that was not supported by versionner. Stef Le 9/2/15 09:18, Christophe Demarey a Ã©crit : > Hello Nicolai, > > Le 5 fÃ©vr. 2015 Ã 22:28, Nicolai Hess a Ã©crit : > >> 2015-02-05 21:56 GMT+01:00 Juraj Kubelka <juraj.kubelka(a)gmail.com >> <mailto:juraj.kubelka@gmail.com>>: >> >> I am just guessing: try to click on âdevelopmentâ item on the >> left side. >> >> >> >> -> "Information: Nothing to save" >> > > With Versionner, when you want to edit (i.e. add/remove a dependency, > a group) you always edit the development version. When you do not need > to update anything but just do a release to fix dependencies version > numbers, you select the development version and then click on > 'release'. The 'save' button is only useful if you did some changes > related to dependencies/groups. > That said, Versionner does not manage platform specific versions. It > implies Versionner miss some information if the configuration has > platform specific variants and Versionner may generates new incomplete > versions. For configurations with platform specific information, I > suggest to do not use Versionner. I will see if the support of > platform specifics parts could be added to Versionner. > > Best regards, > Christophe. >

Feb. 9, 2015

Reducing the activity of the image

by Norbert Hartl

I have an installation where a pharo powered hardware is used in a closed case. Over time that collects quite some heat. One reason for this is that the pharo vm is taking approx. 6% CPU all the time. The only thing that happens is network/sockets. I suspended the ui thread in the image but on this platform it doesn't help. Are there any tweaks to lower the polling and the activity of the image/vm even more? thanks, Norbert

Feb. 9, 2015

Re: [Pharo-dev] get.pharo.org/travis+vm failing: Package 'pharo-vm-core:i386' has no installation candidate

by stepharo

Dale I'm trying to understand. Do we need to update something on our side? I'm not a linux users and I would use Nix because damien maintain the distribution the Nix is cool. Now the ubuntu package was updated recently. Stef Le 9/2/15 20:05, Dale Henrichs a Ã©crit : > > On 02/09/2015 10:40 AM, Nicolai Hess wrote: >> 2015-02-09 19:32 GMT+01:00 Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com >> <mailto:dale.henrichs@gemtalksystems.com>>: >> >> Norbert, >> >> The travis script explicitly downloads the pharo-vm-core:i386 >> package and fails then downloads the vm ... so I'm not sure why >> the pharo-vm-core:i386 is needed separately ... >> >> >> the i386 package is needed on 64 bit linux, it defines the >> dependencies to the 32bit libraries for the x11 display plugin, sound >> plugin ... . >> if you just download the vm (get.pharo.org/vm >> <http://get.pharo.org/vm>) you'll get a 32bit vm too (and pharos >> plugins), but it may not start if the other 32 bit libraries are missing. >> (I think, even starting the pharovm headless does not work with out >> the 32 bit libraries). >> > > Nicolai, > > Thank you very much! ... This helps a lot! ... > > My builderCI[1] scripts explicitly installed the "required" 32 bit > libs needed for Pharo and Squeak, and when I converted to zero conf, I > used the travis+vm script because I am running the tests on travis > (being otherwise ignorant of the purpose of the travis script), but I > did not remove the 32 bit lib install step, soooo I just might be able > to get away without the travis script ... > > If I am missing additional libraries I can add them to the "explicit > install list" ... BTW, when I look at the install log files, no > libraries are installed after the pharo-vm-core:i386 library, so I'm > guessing that that means that the necessary libs were already there? > > I've got my fingers crossed:) > > Dale > > [1] https://github.com/dalehenrich/builderCI

Feb. 9, 2015