- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Gettext broken in Pharo 3.0

by Johan Brichau

Hi Usman, I committed a new version that fixes a number of things. More is needed because I notice the exporter is not detecting the domain<->categories mapping anymore. Johan On 28 Feb 2014, at 15:36, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > Hello, > > I encountered a problem when trying to export the Gettext file in Pharo 3.0. > In a Pharo 3.0 image, load Gettext and then do the following: > > TextDomainManager > registerCategoryPrefix: 'Fuel' > domain: 'Fuel'. > > GetTextExporter exportTemplate. > > Apparently, there are some deprecations and doing proceed on them shows a DNU: > "RBMethodNode does not understand isMessageNode" > > I can report the bug somewhere to later find some time to correct it but Pharo bug tracker might not be the right place. Any ideas where this bug should be reported? > > If someone knowledgeable about RB related stuff can have a look at it, it would be great. > > tx, > usman

March 1, 2014

Re: [Pharo-dev] ws vs st extensions

by Pharo4Stef

On 01 Mar 2014, at 00:17, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-02-28 18:26 GMT-03:00 Chris Cunningham <cunningham.cb(a)gmail.com>: >> On Fri, Feb 28, 2014 at 6:07 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> >> wrote: >>> >>> I have a naive question... >>> >>> Why if the BasicCodeLoader handler looks for .st files does the >>> Workpace offer .ws as the default extension? >> >> Well, the workspace doesn't just use chuck format - in fact, you rarely put >> in chunk format into a workspace (or do you? I certainly don't). Also, >> workspaces allow for dynamic local variables - which normal chunk loaders >> don't. The two things behave differently. .st is explicitly for runnable >> code - workspaces are for more than just code - more of a scratch pad. > > I know, but the cmd line handler isn't a chunk reader. It compiles the > content of the file and evaluate it all at once. And explicitly > expects for files with .st extension (I don't understand such > restriction). > > I don't put chunk in a workspace either (actually I don't know how to > properly read a chunk file in Pharo). > > tl;dr Frankly I don't like the .ws extension at all. It's a matter of habit. :) > > Regards! send a fix. For me saving workspace in file looks prehistorical age. just having method to manage code snippets is much more efficient > > > > Esteban A. Maringolo >

March 1, 2014

Re: [Pharo-dev] Help needed! ClassTest>>#testRenaming

by Pharo4Stef

> Hope we can sort this out, more and more fixes suffer from the wrong testing > failures and nothing new gets integrated. yes Iâm sorry about that. Marcus is burnt out. Esteban is on vacation and Iâm out of time managing our team and other duties. For the issues related to rpackage I will let esteban looked at them because he worked a lot on them. > 12996 ClassTest>>#testRenaming leaves dirty package Dummy-Tests-Class behind > 12995 CI ClassTest>>#testRenaming is failing > > available options: > 1. skip test > 2. test for nil in RPackageOrganizer>>#systemClassRenamedActionFrom: > before > rPackage updateDefinedClassNamed: oldName withNewName: newName. > 3. review changes for issue 12601 > (fix RPackageOrganizer>>#systemCategoryRemovedActionFrom: ann, to > unregister packages even if there are MCPackages (don't know about the > side effects) > > best solution would be number 3, but the recent submissions for > issue 12601 are quite complex, so I don't know. > > Nicolai

March 1, 2014

Re: [Pharo-dev] [squeak-dev] [ANN] Fuel 1.9.3

by HernÃ¡n Morales Durand

Thanks for the update. Cheers, HernÃ¡n 2014-02-26 18:13 GMT-03:00 Max Leske <maxleske(a)gmail.com>: > Dear fellow Smalltalkers > > Mariano, Martin and myself are happy to announce Fuel version 1.9.3 which > includes the follwing changes to 1.9 (1.9.1 and 1.9.2 were never officially > announced): > > - (feature) the #fuelReplacement selector offers the ability to statically > replace an object (e.g. with nil) during analysis. This can lead to > significantly smaller graphs and improved speed when serializing large > graphs > - (feature) serialize the same graph that was analyzed instead of > retrazing the graph during serialization. This prevents changes in the > graph from happening between analysis and serialization > - (change) store source when serializing CompiledMethod objects. Needed > because Opal does not allow decompilation > - (fix) migrate variables across hierarchy > - (feature) Object>>serializeToFileNamed: shortcut for serializing > arbitrary objects > - (fix) better compression for LargeNegativeIntegers ( > https://pharo.fogbugz.com/f/cases/12052/Fuel-could-store-LargeNegativeInteg… > ) > > Pharo30 already includes most of these changes (integration request: > https://pharo.fogbugz.com/f/cases/13000/Integrate-Fuel-1-9-3) > > This release runs with: > - Pharo: 1.1.1, 1.1.2, 1.2, 1.2.2, 1.3, 1.4, 2.0, 3.0 > - Squeak: 4.1, 4.2, 4.3, 4.4, 4.5 > > The documentation is not up to date yet but we will remedy that situatoin > within the next couple of days ( > http://rmod.lille.inria.fr/web/pier/software/Fuel) > If you encounter any bugs or have suggestions, please contact us on the > Fuel mailing list ( > http://lists.gforge.inria.fr/cgi-bin/mailman/roster/pharo-fuel) or create > a new issue in our bug tracker (https://code.google.com/p/fuel/) > > We want to thank everyone who contributed to this release (by keyboard or > opinion) and also all of those people who actively use Fuel. > > Cheers, > Max >

March 1, 2014

Re: [Pharo-dev] #new version #basicNew when materializing (SIXX/Fuel difference)

by Eliot Miranda

On Thu, Feb 27, 2014 at 5:29 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys, > > I found this a bit strange and arguable. Upon materialization, for normal > classes, Fuel uses #basicNew to instantiate objects and then sets its > instances variables values getting them from the stream.... > > Today I found that SIXX sends #new first (*and hence #initialize is sent*) > and after, if fails, it tries, #basicNew. > > This 2 approaches have different results. > > Which one would you expect? > Yours. SIXX's approach is doing unnecessary work. Answer it another way. Have you found any cases where using basicNew[:] leads to errors? If not, then it is the better approach because it is more efficient. -- best, Eliot

Feb. 28, 2014

Re: [Pharo-dev] ws vs st extensions

by Esteban A. Maringolo

2014-02-28 18:26 GMT-03:00 Chris Cunningham <cunningham.cb(a)gmail.com>: > On Fri, Feb 28, 2014 at 6:07 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: >> >> I have a naive question... >> >> Why if the BasicCodeLoader handler looks for .st files does the >> Workpace offer .ws as the default extension? > > Well, the workspace doesn't just use chuck format - in fact, you rarely put > in chunk format into a workspace (or do you? I certainly don't). Also, > workspaces allow for dynamic local variables - which normal chunk loaders > don't. The two things behave differently. .st is explicitly for runnable > code - workspaces are for more than just code - more of a scratch pad. I know, but the cmd line handler isn't a chunk reader. It compiles the content of the file and evaluate it all at once. And explicitly expects for files with .st extension (I don't understand such restriction). I don't put chunk in a workspace either (actually I don't know how to properly read a chunk file in Pharo). tl;dr Frankly I don't like the .ws extension at all. It's a matter of habit. :) Regards! Esteban A. Maringolo

Feb. 28, 2014

Re: [Pharo-dev] ws vs st extensions

by Chris Cunningham

On Fri, Feb 28, 2014 at 6:07 AM, Esteban A. Maringolo <emaringolo(a)gmail.com>wrote: > I have a naive question... > > Why if the BasicCodeLoader handler looks for .st files does the > Workpace offer .ws as the default extension? > Well, the workspace doesn't just use chuck format - in fact, you rarely put in chunk format into a workspace (or do you? I certainly don't). Also, workspaces allow for dynamic local variables - which normal chunk loaders don't. The two things behave differently. .st is explicitly for runnable code - workspaces are for more than just code - more of a scratch pad. -cbc > > Why not a single extension for Smalltalk files? (.st) and other for > chunked content (changesets?) > > :) > > > Esteban A. Maringolo > >

Feb. 28, 2014

Re: [Pharo-dev] Gettext broken in Pharo 3.0

by Pharo4Stef

thanks usman do you have the expression to load gettext in pharo 3.0 On 28 Feb 2014, at 15:36, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > Hello, > > I encountered a problem when trying to export the Gettext file in Pharo 3.0. > In a Pharo 3.0 image, load Gettext and then do the following: > > TextDomainManager > registerCategoryPrefix: 'Fuel' > domain: 'Fuel'. > > GetTextExporter exportTemplate. > > Apparently, there are some deprecations and doing proceed on them shows a DNU: > "RBMethodNode does not understand isMessageNode" > > I can report the bug somewhere to later find some time to correct it but Pharo bug tracker might not be the right place. Any ideas where this bug should be reported? > > If someone knowledgeable about RB related stuff can have a look at it, it would be great. > > tx, > usman

Feb. 28, 2014

Re: [Pharo-dev] ws vs st extensions

by Esteban A. Maringolo

I thought so. Esteban A. Maringolo 2014-02-28 18:09 GMT-03:00 Pharo4Stef <pharo4Stef(a)free.fr>: > > On 28 Feb 2014, at 15:07, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > >> I have a naive question... >> >> Why if the BasicCodeLoader handler looks for .st files does the >> Workpace offer .ws as the default extension? >> >> Why not a single extension for Smalltalk files? (.st) and other for >> chunked content (changesets?) > > legacy :) > >> >> :) >> >> >> Esteban A. Maringolo >> > >

Feb. 28, 2014

Re: [Pharo-dev] ws vs st extensions

by Pharo4Stef

On 28 Feb 2014, at 15:07, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > I have a naive question... > > Why if the BasicCodeLoader handler looks for .st files does the > Workpace offer .ws as the default extension? > > Why not a single extension for Smalltalk files? (.st) and other for > chunked content (changesets?) legacy :) > > :) > > > Esteban A. Maringolo >

Feb. 28, 2014