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

[Pharo-project] [update 2.0] #20528

by Marcus Denker

20528 ----- Issue 7460: Icons for TestCase in Nautilus, after a clean for production http://code.google.com/p/pharo/issues/detail?id=7460 Issue 7457: safe UsersManager usage in Monticello http://code.google.com/p/pharo/issues/detail?id=7457 Issue 6737: Test Runner: File out results http://code.google.com/p/pharo/issues/detail?id=6737 Issue 7359: CompositeFillStyle has unclassified methods http://code.google.com/p/pharo/issues/detail?id=7359 Issue 7456: Create a trait while a class is selected http://code.google.com/p/pharo/issues/detail?id=7456 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.1036.diff http://ss3.gemstone.com/ss/Pharo20/SUnit-UI-MarcusDenker.57.diff http://ss3.gemstone.com/ss/Pharo20/Nautilus-MarcusDenker.417.diff http://ss3.gemstone.com/ss/Pharo20/Monticello-MarcusDenker.762.diff http://ss3.gemstone.com/ss/Pharo20/Balloon-MarcusDenker.91.diff

Feb. 8, 2013

Re: [Pharo-project] Adding SCTP support to the VM/Network-Kernel

by Frank Shearar

On 29 January 2013 12:21, Holger Hans Peter Freyther <holger(a)freyther.de> wrote: > Hi, > > I require SCTP support for my work. I have implemented very basic > support in the unix version of the SocketPlugin[1], made modifications > to the CMake generation, the VMMaker part of the SocketPlugin and the > Network-Kernel. <snip> I'm very interested in seeing SCTP support in _all_ the VMs. Would you mind telling vm-dev about your work? frank > holger

Feb. 8, 2013

Re: [Pharo-project] Things i am working on now

by Igor Stasenko

okay.. things vent more or less smooth.. i finished patching missing stuff.. On 7 February 2013 18:00, Igor Stasenko <siguctua(a)gmail.com> wrote: > pff... > it finally built.. > > [ 99%] Building C object > CMakeFiles/Pharo.dir/C_/COG/blessed/platforms/win32/vm/sqWin32Prefs.c.obj > [ 99%] Building C object > CMakeFiles/Pharo.dir/C_/COG/blessed/platforms/win32/vm/sqWin32Utils.c.obj > Linking C executable /C/COG/blessed/results/Pharo.exe > Creating library file: c:/COG/blessed/results/libPharo.dll.a > [100%] Built target Pharo > > building all stuff from scratch takes a lot of time > (cairo , freetype, png, ssl ...) > > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

Feb. 8, 2013

[Pharo-project] [update 2.0] #20527

by Esteban Lorenzano

20527 ----- Issue 7284: Cannot run gofer load twice => Error: cannot remove non empty category http://code.google.com/p/pharo/issues/detail?can=2&q=7284 (part 2) Diff information: http://ss3.gemstone.com/ss/Pharo20/RPackage-Core-EstebanLorenzano.210.diff http://ss3.gemstone.com/ss/Pharo20/Monticello-EstebanLorenzano.761.diff

Feb. 8, 2013

[Pharo-project] [update 2.0] #20526

by Esteban Lorenzano

20526 ----- Issue 7284: Cannot run gofer load twice => Error: cannot remove non empty category http://code.google.com/p/pharo/issues/detail?can=2&q=7284 (part 1) Diff information: http://ss3.gemstone.com/ss/Pharo20/RPackage-Core-EstebanLorenzano.209.diff

Feb. 8, 2013

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

by Damien Cassou

On Thu, Feb 7, 2013 at 5:22 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > just checked the settings.. it should email me :/ you can add #pharo too -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Feb. 8, 2013

Re: [Pharo-project] Less than 50 issues!

by Sean P. DeNigris

Current stats: 37 Open 2.0 Issues (down from 41) 12 Ready to Review (down from 15) 03 Ready to Integrate ______ = 22 Outstanding Keep it up!! -- View this message in context: http://forum.world.st/Less-than-50-issues-tp4667961p4668520.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 8, 2013

[Pharo-project] OneClick for 2.0 available again

by Marcus Denker

Hi, We have again a one-click for 2.0: https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/artifact/Pharo2… This right now uses the same VM that we use to run the tests on the build server (NBCog from November). (Later we need to use the latest verified build from the server automatically) Marcus

Feb. 8, 2013

[Pharo-project] [update 2.0] #20525

by Marcus Denker

20525 ----- Issue 7447: optional UsersManager http://code.google.com/p/pharo/issues/detail?id=7447 Issue 7444: Morphic Settings appears twice, as its own group and as subgroup to Appearance http://code.google.com/p/pharo/issues/detail?id=7444 Diff information: http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.779.diff http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1348.diff

Feb. 8, 2013

Re: [Pharo-project] Voyage: GC collecting random objects?

by Esteban Lorenzano

it depends on the amount of objects, but yes... you can play with lazy/eager ways of retrieve subcollections but if you have 10k objects, it will take some time to bring them all :) Esteban On Feb 8, 2013, at 12:59 PM, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > OK! It looks like it's working now! Thank you so much! :) > > Bernat. > > p.s. After garbage collection, #selectAll is really slow. I guess this is normal as all objects have to be retrieved all over from the DB, is this right? > > > 2013/2/8 Esteban Lorenzano <estebanlm(a)gmail.com> > no, isVoyageRoot mark the objects of the graph that you want as roots. All the others are just embedded objects. > Just try adding enableMissingContent to class "D" (I don't know what is the real name in your case :) > > Esteban > > > > On Feb 8, 2013, at 12:39 PM, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > >> Hmm I'm not sure I understand. Now I've tried not even having the objects stored in a classvar at all, but saving them from a materialized fuel file straight away: >> >> (FLMaterializer materializeFromFileNamed: 'mongodb.obj') do: [ :each | each save ]. >> >> It's all ok and working, until I do Smalltalk garbageCollect and there goes the "Reference not found" error again, without me having removed any object. >> >> Would making ALL of my classes respond true to #isVoyageRoot fix the issue? >> >> Thanks again! >> >> Bernat. >> >> p.s. se entiende el idioma, no el contenido, pero eso es culpa mÃa! jeje >> >> >> 2013/2/8 Esteban Lorenzano <estebanlm(a)gmail.com> >> yes, this is what happens: >> >> You have a graph that can look like this: >> >> A->b->c->D >> >> where A and D represent roots of voyage (#isVoyageRoot = true) >> >> you removed D, but A is not updated (the logic for auto update references is too complex, and this is a known limitation of voyage). >> So, in a next cycle you try to bring A to the image, and A is trying to load eagerly an instance of D... which does not exists anymore, so you have the error. >> To prevent this kind of problems, I use something that I call "eventual integrity" :) you can configure your collection to not fail when you try to get it and it does not exists. For achieve that, you have to add a setting to the class you want to take as "lazy deletable" (is a very dangerous property to just allow it by defect). >> You have to do something like this: >> >> D class>>#mongoContainer >> <mongoContainer> >> >> ^VOMongoContainer new >> enableMissingContent; >> yourself >> >> note that who is enabling missing content is D, not A :) >> >> hope it helps. >> >> Cheers, >> Esteban >> >> ps: y si no se entiende nada, mandame un mail privado y lo explico en espaÃ±ol :) >> >> On Feb 8, 2013, at 12:12 PM, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: >> >>> It says "Reference not found", and the method signaling the error is VOMongoMaterializer >> #missingContentFor:id: >>> >>> I can try to set up a minimal test case and sent it to you, would that help? >>> >>> Thanks! >>> >>> >>> 2013/2/8 Esteban Lorenzano <estebanlm(a)gmail.com> >>> Hi, >>> >>> Voyage should keep a weak cache... objects should be disposed as soon as they are not used anymore. >>> Now... it is saying "Reference not found", or "Lazy reference not found"? >>> >>> Esteban >>> >>> On Feb 8, 2013, at 11:46 AM, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: >>> >>>> Hi! >>>> >>>> We've been trying to migrate the data of our Iliad webapp to Voyage, and so far everything was going great, until the garbage collector collected objects it shouldn't have... Here's what we did: >>>> >>>> We used to have all objects stored in an Instances classVar belonging to their own classes, so: >>>> >>>> I had our classes return true to #isVoyageRoot >>>> ourClasses do: [ :c | (c classVarNamed: #Instances) do: [ :i | i save ]] >>>> I checked MongoDB and all was looking great. From Pharo, we could get all our instances and explore all of their relationships by OurClass selectAll. Everything was working, so we thought we didn't need the image stored instances anymore, thus: >>>> ourClasses do: [ :c | c classVarNamed: #Instances put: nil ] >>>> Smalltalk garbageCollect >>>> RMUser selectAll â (long delay) â BOOM â 'Reference not found RMUser: OID(3725800612)' >>>> So, should we actually keep references to our instances in the image? I doubt this is the case, cos that'd mean we still have the 2Gb storage limitation, and then having an external DB would not be helping much... >>>> >>>> Thanks a lot in advance! >>>> >>>> Bernat. >>>> >>>> p.s. I've also tried saving copies of my objects, but the result's been the same, after garbage-collecting, I lose references. >>>> >>>> -- >>>> Bernat Romagosa. >>> >>> >>> >>> >>> -- >>> Bernat Romagosa. >> >> >> >> >> -- >> Bernat Romagosa. > > > > > -- > Bernat Romagosa.

Feb. 8, 2013