- Pharo-dev - lists.pharo.org

SourceCity works

by Stephan Eggermont

Thank you Igor, This allowed me to successfully load, debug & run SourceCity on an 10.6.8 Mac. Steps taken: > just tried in latest 2.0 image. > > Pharo2.0 > Latest update: #20606 > > Gofer new > smalltalkhubUser: 'PharoExtras' project: 'NBOpenGL'; > package: 'ConfigurationOfNBOpenGL'; > load. > > (ConfigurationOfNBOpenGL project version: '2.0') load > > GLTTRenderingDemo new openInWorld Load the individual SourceCity packages from smalltalkhub: SourceCity-Core SourceCity-Importer SourceCity-Layout SourceCity-Tools remove display bindRenderBuffers from SourceCityGLVizualisationBuilder>fillRenderingList:pickingMode: SourceCityGLVizualisationRenderer>render see it work: SourceCity exampleRpackage Next step: fix code & configuration Stephan On 7 jun 2013, at 23:34, Igor Stasenko wrote: > On 7 June 2013 21:07, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Hi! >> >> I have installed NBOpenGL from http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL >> I have loaded Version 2.0 using the configuration >> >> The method NBMacGlAPI>>glApiCall: fnSpec index: fnIndex attributes: attributes context: contextToRetry refers to the class NBCallFailureHandler, which is not existing >> >> Apparently NBSTIvarLoader is also missing... >> I guess ConfigurationOfNBOpenGL is not loading everything... >> It would be nice to fix this. > > just tried in latest 2.0 image. > > Pharo2.0 > Latest update: #20606 > > Gofer new > smalltalkhubUser: 'PharoExtras' project: 'NBOpenGL'; > package: 'ConfigurationOfNBOpenGL'; > load. > > (ConfigurationOfNBOpenGL project version: '2.0') load > > GLTTRenderingDemo new openInWorld > > everything loads and works. > (it takes 5 minutes to load though... ) > >> >> Cheers, >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > > > > -- > Best regards, > Igor Stasenko. > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

June 8, 2013

Re: [Pharo-dev] For 2.0: links point to latest build on pharp-project.org

by StÃ©phane Ducasse

+1 > > To explain: > > We have the major version > > Pharo2 > Pharo3 > Pharo4 > > These are released once per year. > > While developing, we do updates. At some point (e.g. #553) we release. Then we continue to do do updates. > > So Pharo images are always 100% identifiable by Major+UpdateNumber. > > When you go to pharo.org, you download the *latest* update. Else we end up getting bug reports for already fixed issues constantly > (this happend now already multiple times, and I feel to bad that someone takes such a huge effort to report a bug that we fixed > weeks ago). > > If you want to re-download the version you go weeks ago, there is > > http://files.pharo.org/image/20/ > > with a complete history, and it is very easy to download exactly what you downloaded weeks ago, yet all the new people get the newest > download. > > Marcus

June 8, 2013

Re: [Pharo-dev] FogBugz (Case [Issue]10840) Collection - WeakSet>>#size utterly broken

by Igor Stasenko

Here is a simple solution for you: set asArray size. But come on, why asking for weak container size??? What you gonna do with this information? Iterate over it? And besides, there is #slowSize. A size is left as it is. Because it is fast. There is no way to get accurate size of weak container either way, because at the very next message, GC can be triggered and some items turn garbage => size is invalid. So, it doesn't matters if you calculate size slow or fast, it will be always inaccurate. And issue is invalid. -- Best regards, Igor Stasenko.

June 8, 2013

Re: [Pharo-dev] Moving PostgresV2 from SS to Shub. Any objection?

by Yanni Chiu

> On 07 Jun 2013, at 14:44, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> Hi guys, >> >> I was going to commit something on PostgresV2 in SS but then I though it is a good opportunity to moved it to SmalltalkHub. >> >> Any objection? Please move it to SmalltalkHub. Thanks for moving it. Wow. IIRC, PostgresV2 was coded around 1999, and first uploaded to some (now long gone) server provided by my ISP, and was listed in SqueakMap. When squeaksource became available, it was migrated there. Now, it's migrating to SmalltalkHub. It was part of my "grand plan", but now I use Fuel instead. I guess relational DB's still pay the bills.

June 8, 2013

Re: [Pharo-dev] For 2.0: links point to latest build on pharp-project.org

by Marcus Denker

On Jun 8, 2013, at 1:43 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Jun 7, 2013, at 8:03 PM, btc(a)openinworld.com wrote: > >> Marcus Denker wrote: >>> Hi, >>> >>> I changed all links to point to the latest 2.0 build on files.pharo.org >>> >>> Reason: >>> >>> -> We are fixing bugs, yet people downloading 2.0 do not see the fix >>> -> We had multiple times that people wasted quite some effort re-reporting bugs >>> that are already fixed. >>> >>> Notes >>> -> the file name "latest.zip" is not good for the image. It should encode that it is the image only and the version number maybe? >>> -> I did not change any VM related download links, but I think we should do the same there. >>> >>> >>> Marcus >>> >> That is great that 2.0 is continuing to improve. >> >> +100 for including version numbers on the web page - something like [1]. For the purpose of reproducibility and least surprise, at [2] where it currently says "2.0 (release)" and "Pharo2.0 (win)" I would expect that link to download the _exact_ same file every time, except today that zip file contains files dated today, so obviously is not the same file as last week. You might get away with following "latest" with a link called "Pharo2 (win)" without the minor-version number, but by including a a minor-version number I would expect that it is the constant point-in-time snapshot of the _2.0 release_. > This is what we had. But we fixed bugs already, yet people where reporting those bugs again. So what do we do? We can *not* change the link for every updateâ¦ I spend already today around 30 minute to fix all the links. Should I do that > every time we do an update? To explain: We have the major version Pharo2 Pharo3 Pharo4 These are released once per year. While developing, we do updates. At some point (e.g. #553) we release. Then we continue to do do updates. So Pharo images are always 100% identifiable by Major+UpdateNumber. When you go to pharo.org, you download the *latest* update. Else we end up getting bug reports for already fixed issues constantly (this happend now already multiple times, and I feel to bad that someone takes such a huge effort to report a bug that we fixed weeks ago). If you want to re-download the version you go weeks ago, there is http://files.pharo.org/image/20/ with a complete history, and it is very easy to download exactly what you downloaded weeks ago, yet all the new people get the newest download. Marcus

June 7, 2013

Re: [Pharo-dev] For 2.0: links point to latest build on pharp-project.org

by Marcus Denker

On Jun 7, 2013, at 8:03 PM, btc(a)openinworld.com wrote: > Marcus Denker wrote: >> Hi, >> >> I changed all links to point to the latest 2.0 build on files.pharo.org >> >> Reason: >> >> -> We are fixing bugs, yet people downloading 2.0 do not see the fix >> -> We had multiple times that people wasted quite some effort re-reporting bugs >> that are already fixed. >> >> Notes >> -> the file name "latest.zip" is not good for the image. It should encode that it is the image only and the version number maybe? >> -> I did not change any VM related download links, but I think we should do the same there. >> >> >> Marcus >> > That is great that 2.0 is continuing to improve. > > +100 for including version numbers on the web page - something like [1]. For the purpose of reproducibility and least surprise, at [2] where it currently says "2.0 (release)" and "Pharo2.0 (win)" I would expect that link to download the _exact_ same file every time, except today that zip file contains files dated today, so obviously is not the same file as last week. You might get away with following "latest" with a link called "Pharo2 (win)" without the minor-version number, but by including a a minor-version number I would expect that it is the constant point-in-time snapshot of the _2.0 release_. This is what we had. But we fixed bugs already, yet people where reporting those bugs again. So what do we do? We can *not* change the link for every updateâ¦ I spend already today around 30 minute to fix all the links. Should I do that every time we do an update? Marcus

June 7, 2013

Re: [Pharo-dev] OpenGL: NBMacGlAPI missing?

by Igor Stasenko

On 7 June 2013 21:07, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > I have installed NBOpenGL from http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL > I have loaded Version 2.0 using the configuration > > The method NBMacGlAPI>>glApiCall: fnSpec index: fnIndex attributes: attributes context: contextToRetry refers to the class NBCallFailureHandler, which is not existing > > Apparently NBSTIvarLoader is also missing... > I guess ConfigurationOfNBOpenGL is not loading everything... > It would be nice to fix this. just tried in latest 2.0 image. Pharo2.0 Latest update: #20606 Gofer new smalltalkhubUser: 'PharoExtras' project: 'NBOpenGL'; package: 'ConfigurationOfNBOpenGL'; load. (ConfigurationOfNBOpenGL project version: '2.0') load GLTTRenderingDemo new openInWorld everything loads and works. (it takes 5 minutes to load though... ) > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- Best regards, Igor Stasenko.

June 7, 2013

Re: [Pharo-dev] For 2.0: links point to latest build on pharp-project.org

by Camillo Bruni

On 2013-06-07, at 20:03, btc(a)openinworld.com wrote: > Marcus Denker wrote: >> Hi, >> >> I changed all links to point to the latest 2.0 build on files.pharo.org >> >> Reason: >> >> -> We are fixing bugs, yet people downloading 2.0 do not see the fix >> -> We had multiple times that people wasted quite some effort re-reporting bugs >> that are already fixed. >> >> Notes >> -> the file name "latest.zip" is not good for the image. It should encode that it is the image only and the version number maybe? >> -> I did not change any VM related download links, but I think we should do the same there. >> >> >> Marcus >> > That is great that 2.0 is continuing to improve. > > +100 for including version numbers on the web page - something like [1]. For the purpose of reproducibility and least surprise, at [2] where it currently says "2.0 (release)" and "Pharo2.0 (win)" I would expect that link to download the _exact_ same file every time, except today that zip file contains files dated today, so obviously is not the same file as last week. You might get away with following "latest" with a link called "Pharo2 (win)" without the minor-version number, but by including a a minor-version number I would expect that it is the constant point-in-time snapshot of the _2.0 release_. > [1] http://www.python.org/download/ > [2] http://www.pharo-project.org/pharo-download > > Also, revisiting (major.minor.bugfix) semantic versioning in the context of Pharo, an important part of configuration management for a user is matching versions of VM to Image. For me, I simply this when I update by always taking the fat zip which include both - but it would be nice to have the confidence to just take the image. So it would be good if the VM/Image dependency could be encoded by the version numbers. Something like the following... > > My shallow understanding of the CI infrastructure is that to "some degree" : > 1. the Image CI runs against a constant VM version the image is tested against the latest stable vm (ex. http://files.pharo.org/vm/pahro/linux/stable.zip) since stable VMs are promoted manually we can consider them being constant. > 2. the VM CI runs against a constant Image version true, https://ci.inria.fr/pharo/view/VM/job/PharoVM-tests/ shows that we run against the latest image (2.0 in this case) and a fixed image (vm-test.zip in this case). Currently the CI infrastructure is suffering from a network failure, that's why the more runs than usual are red. > So considering Case 1... > a. Image updates would bump only the bugfix number. b. VM updates would bump the minor number. > This would make is easy for a user to always determine that Image version 2.2.x was tested against VM Pharo22.exe. > To avoid excessively incrementing the minor version number, considering Case 2... > c. (for example) you would begin testing VM updates against constant Image 2.0.0 > d. when a required VM update breaks a test in Image 2.0.0, then increment the minor version number. Work to get latest VM and latest Image both green. These then become Pharo21.exe and Image 2.1.0, which are used as a the next starting point for Case 1. Further VM updates are now tested against constant Image 2.1.0. this scheme will work fine once we release VM's for each Pharo release (which I guess is planned at some point). Currently this is not yet the case, so the objective is to make the VM work with every image...

June 7, 2013

Re: [Pharo-dev] For 2.0: links point to latest build on pharp-project.org

by Camillo Bruni

On 2013-06-07, at 20:16, Bernardo Ezequiel Contreras <vonbecmann(a)gmail.com> wrote: > Marcus, > imho, the filename "latest.zip" is very good because i can have a unique > url to that image. i.e. http://files.pharo.org/image/20/latest.zip yes exactly that is the reason. we follow no 2 paths: a) the url encodes all the params e.g. http://files.pharo.org/image/20/latest.zip b) the file encodes all the params http://files.pharo.org/image/20/Pharo-Image-2.0-latest.zip we use a) in tools (like get.pharo.org) and b) for the link on the website. btw, you can see the list of files under http://files.pharo.org/

June 7, 2013

Re: [Pharo-dev] FogBugz (Case [Issue]10840) Collection - WeakSet>>#size utterly broken

by StÃ©phane Ducasse

Hi eliot probably a really stupid question. But why count the number of finalization would have a link with the size? Is there an invariant that would mean that there is a one one relations between object in the set and their garbage collection. I mean if two objects of the same weakset are garbage collected will the finalization process runs twice I did not look at the class comment because may be it explains it and now I 'm dead. Stef

June 7, 2013