- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Deploying without .changes and .sources files

by Sven Van Caekenberghe

SmalltalkImage checkSourcesFileAvailability: false; checkChangesFileAvailability: false. And then save the image. On 07 Feb 2013, at 09:59, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Hi, > > Norbert asked about the possibility to deploy a pharo image without > .changes and .sources files > > http://stackoverflow.com/questions/14737695/is-it-possible-to-deploy-a-phar… > > Could people participate to the discussion there? I think it is important. > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

Feb. 7, 2013

[Pharo-project] Deploying without .changes and .sources files

by Damien Cassou

Hi, Norbert asked about the possibility to deploy a pharo image without .changes and .sources files http://stackoverflow.com/questions/14737695/is-it-possible-to-deploy-a-phar… Could people participate to the discussion there? I think it is important. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Feb. 7, 2013

[Pharo-project] github repository

by Camillo Bruni

I just killed all the file-tree noise (mostly metacello version info) Now we can properly see what changed between pharo versions over all packages: https://github.com/pharo-project/pharo-core/commit/cea99d02a2d0d743880cd7a8… => this will be my major source for debugging information when looking for newly introduced bugs! => using git-bisect it will be super easy to find these bugs

Feb. 7, 2013

[Pharo-project] [update 2.0] #20519

by Marcus Denker

20519 ----- Issue 7438: [ENH]: Nautilus Help http://code.google.com/p/pharo/issues/detail?id=7438 Issue 7427: failing test for SmalllintManifestCheckerTest http://code.google.com/p/pharo/issues/detail?id=7427 Issue 7424: [Bug]: Removing a class does not mark the package as dirty http://code.google.com/p/pharo/issues/detail?id=7424 Issue 7209: ChangesBrowser should execute refactorings in order http://code.google.com/p/pharo/issues/detail?id=7209 Diff information: http://ss3.gemstone.com/ss/Pharo20/Spec-Widgets-MarcusDenker.92.diff http://ss3.gemstone.com/ss/Pharo20/RPackage-Core-MarcusDenker.207.diff http://ss3.gemstone.com/ss/Pharo20/NautilusRefactoring-MarcusDenker.71.diff http://ss3.gemstone.com/ss/Pharo20/Nautilus-MarcusDenker.415.diff http://ss3.gemstone.com/ss/Pharo20/Monticello-MarcusDenker.756.diff

Feb. 7, 2013

[Pharo-project] [update 2.0] #20518

by Marcus Denker

Feb. 7, 2013

[Pharo-project] OpenCl and Pharo..

by S Krish

Python OpenCL binding: http://mathema.tician.de/software/pyopencl<https://amsprd0611.outlook.com/owa/redir.aspx?C=WlIrEQ1IDUSvE0cBwBZ7hn8LUF9…> Is there any effort on Smalltalk + OpenCL or any known limitation... one can visualize..

Feb. 7, 2013

Re: [Pharo-project] TextModel review and discussion

by Igor Stasenko

On 6 February 2013 16:05, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Cool :) > > We really need to kill this ugly monster, and make it turn into a nice > butterfly for 3.0 :) > > > Just a tiny question: Shouldn't the code belong to RMoD team instead of Igor > on SmalltalkHub ? i am not sure about it. right now it is developed by Denis and Tristan, who are not members of rmod team. btw thanks for question: it raising interesting question about smalltalkhub functionality: it would be nice if project ownership can be transferred between groups/individuals without physically copying files. > > Ben > > On Feb 6, 2013, at 3:56 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > Hi, today, me, Tristan and Camillo took some overview on existing > code and discussed further steps. > > TxAttributes > 'contents' should be private (no getter/setter) > > because if you can directly manipulate the underlying collection, then > what is the point of having separate class? > > Text Attributes in general: > > - we discussed and decided that it would be better that model will > keep abstract attributes for text , like > - bold > - italic > - font family name > > the view then can compute the real font to use, but model don't have > to deal with real font(s). > > This will imply having more complex attribute(s): you will be forced > to visit them all to determine all of the font properties > of a final font to use. > > The attributes in span should behave like a set (you cannot apply same > attribute once), > and hence implement #= and #hash properly. > > Also, i think, since neither bold, nor italic attributes don't need to > be represented by multiple instances of same class, > we could use convenience methods (by introducing them) in TxAttribute > class to get a singletons for those ones, e.g.: > > selection applyAttribute: TxAttribute bold > > Layout: > - right now, when you do layout it will split spans of txmodel. Which > should not happen. > > We discussed about it and agreed that layouts(views) should not modify > anything in text model. > Instead the information about where line has to be split (like when > you need to wrap a text) should be kept > separately by a view. > > We thought that it would be nicer to implement a new span type > (layoutspan), which will hold > an text-interval (pos1, pos2) and probably any additional information > (like caching the width/height) > to not recalculate this stuff if nothing changed in model. > > > We did some cosmetic changes to configuration.. to merge Tristan's > code into it and load most recent packages: > > Gofer it > smalltalkhubUser: 'sig' project: 'TxText'; > package: 'ConfigurationOfTxText'; > load. > > (ConfigurationOfTxText project version: '0.3') load: 'Tests' > > -- > Best regards, > Igor Stasenko. > > -- Best regards, Igor Stasenko.

Feb. 6, 2013

[Pharo-project] new Cog VMs available

by Eliot Miranda

http://www.mirandabanda.org/files/Cog/VM/VM.r2678 CogVM binaries as per VMMaker.oscog-eem.264/r2678. Fix snapshot primitive failure in the StackVM and Cogit. The primitive should fail, not merely return the receiver. Also if in Cogit, need to back-up instruction pointer on failure. Make reportMinimumUnusedHeadroom more informative (also print available headroom). -- best, Eliot

Feb. 6, 2013

Re: [Pharo-project] files.pharo.org

by Camillo Bruni

thanks! I'll update the scripts to use the new domain. On 2013-02-06, at 19:23, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > Now there is a DNS entry and forwarder > > http://files.pharo.org > > this works for all files there, e.g. > > http://files.pharo.org/image/20/latest.zip > > We will keep these links, even when we move to a dedicated file server. > (We have requested one and it should be ready soon, we hope) > > Marcus >

Feb. 6, 2013

[Pharo-project] files.pharo.org

by Marcus Denker

Hi, Now there is a DNS entry and forwarder http://files.pharo.org this works for all files there, e.g. http://files.pharo.org/image/20/latest.zip We will keep these links, even when we move to a dedicated file server. (We have requested one and it should be ready soon, we hope) Marcus

Feb. 6, 2013